2013-07-02

RHEL5.7: rsync doesn't work

久しぶりにハマった件について。

[rhel57]# rsync -az --delete --inplace --timeout=10 \
                -e 'ssh -i /path/to/key' \
                remote-host:/path/to/sync/ /path/to/sync
usage: ssh [-1246AaCfgkMNnqsTtVvXxY] [-b bind_address] [-c cipher_spec]
           [-D [bind_address:]port] [-e escape_char] [-F configfile]
           [-i identity_file] [-L [bind_address:]port:host:hostport]
           [-l login_name] [-m mac_spec] [-O ctl_cmd] [-o option] [-p port]
           [-R [bind_address:]port:host:hostport] [-S ctl_path]
           [-w tunnel:tunnel] [user@]hostname [command]
rsync: writefd_unbuffered failed to write 4 bytes to socket [receiver]: Broken pipe (32)
rsync error: unexplained error (code 255) at io.c(1525) [receiver=3.0.6]

いつも通り rsync を動かしたら、何か ssh のヘルプ出てきた。何これ、訳分かんない。

これにハマった理由は、

  • 見た目が如何にも ssh の引数不備に見えた。
  • 実際に動かなくなったスクリプトも ssh を使っていた。
  • とはいえ、この間は確かに RHEL5.9 で動いていたのを確認済み。

これらに惑わされて原因の特定に手間取ってしまった。結局、「RHEL5.7 同梱の rsync でのみ発生する不具合」というオチだった。

原因は分かったので、後は自作インストーラー側での対処。勿論、rsync をアップデートして貰えば解決する問題だが、「RHEL5.7 だったら rsync をアップデートしてね」とお願いするくらいなら、最初からインストーラー側で対処すべき。やることが「明確」ならば、自動化するのがセオリーだ。(逆に「臨機応変」が求められるものは、人間がやるべき)

バグ持ち rsync のバージョンは分かっているので、RHEL バージョンよりも rsync バージョンで判断する方がベター、ということでこんな感じ。

if [ 3.0.6-4.el5 = "`rpm -q --qf '%{VERSION}-%{RELEASE}' rsync`" ] ; then
    rpm -Uvh rsync-3.0.6-4.el5_7.1.x86_64.rpm
fi

修正はこれで良いとして、いい加減、OS のマイナーアップデートでパッケージのメジャーバージョンを上げるのは止めて欲しい。

[rhel56]# rpm -q rsync
rsync-2.6.8-3.1
[rhel57]# rpm -q rsync
rsync-3.0.6-4.el5

RHEL に求めるのは安定性であって、最新パッケージを使いたかったら自分でビルドするか rpm を拾ってくるし。特に今回、基本的なツールである rsync が動かなくなったことで、泣かされた人も(当時は)多かったのではなかろうか。今回の不具合の拙さを考えると、「安易にパッケージのメジャーバージョンを上げるからだ」と言われても仕方ない。

2013-06-04

HP SPP makes system slow

暫く前に HP サーバーをセットアップした時のこと。

  • Proliant DL380e
  • RHEL5.9
  • HP Service Pack for ProLiant (2013.02.0)

SPP (Service Pack for ProLiant)をインストールした途端、サーバーに断続的な負荷が掛かるようになった。

# top
top - 18:43:29 up  2:31,  3 users,  load average: 0.36, 0.37, 0.30
Tasks: 183 total,   2 running, 181 sleeping,   0 stopped,   0 zombie
Cpu0  : 41.9%us,  1.0%sy,  0.0%ni, 57.1%id,  0.0%wa,  0.0%hi,  0.0%si,  0.0%st
Cpu1  : 23.0%us,  1.0%sy,  0.0%ni, 76.0%id,  0.0%wa,  0.0%hi,  0.0%si,  0.0%st
Cpu2  :  7.6%us,  0.3%sy,  0.0%ni, 92.0%id,  0.0%wa,  0.0%hi,  0.0%si,  0.0%st
Cpu3  : 25.2%us,  0.7%sy,  0.0%ni, 74.1%id,  0.0%wa,  0.0%hi,  0.0%si,  0.0%st
Mem:   7992008k total,   576248k used,  7415760k free,    33204k buffers
Swap: 10482404k total,        0k used, 10482404k free,   262040k cached

  PID USER      PR  NI  VIRT  RES  SHR S %CPU %MEM    TIME+  COMMAND
 9695 root      23   0  6600 1252  396 R  2.3  0.0   0:00.07 lsusb
30295 root      15   0 12764 1184  840 R  0.3  0.0   0:03.24 top
    1 root      18   0 10372  684  580 S  0.0  0.0   0:01.04 init
<...snip...>
# pstree -ap
<...snip...>
  |-cmastdeqd,4029 -p 30 -l /var/log/hp-snmp-agents/cma.log
  |   `-sh,9806 -c /opt/hp/hp-snmp-agents/utils/usb-device.sh\0402>/dev/null
  |       `-sh,9807 -c /opt/hp/hp-snmp-agents/utils/usb-device.sh\0402>/dev/null
  |           `-sh,9862 -c /opt/hp/hp-snmp-agents/utils/usb-device.sh\0402>/dev/null
  |               |-grep,9864 bInterfaceSubClass
  |               |-lsusb,9863 -v -s 002 002
  |               `-sed,9865 -e s/^\040*bInterfaceSubClass\040\+[0-9]\+\040//
# sar | tail -n 5
18:10:01          all      6.04      0.00      0.40      0.00      0.00     93.56
18:20:01          all      8.40      0.01      0.47      0.00      0.00     91.12
18:30:01          all      8.65      0.00      0.47      0.00      0.00     90.88
18:40:01          all      8.81      0.00      0.48      0.00      0.00     90.71
Average:          all      3.90      0.00      0.34      0.00      0.00     95.76

cmastdeqd が数十秒毎に lsusb を大量に実行するのが原因。lsusb 単発は微々たるものだが、全体では相当な負荷になっていて、USB キーボードを使っていたりすると酷い目に遭う。文字が入らなかったり、一度に何文字も入ったり。特にシャドウパスワードが最悪(何が入ったか見えないの)で、まともにログインすらできない。

USB HDD の取り外しを検出するのが目的らしいが、USB HDD なんて付けるつもりはないし、例え付けたとしてもこんなものは速攻で無効にすべき。

ところが、cmastdeqd の自動起動を off にすると、あろうことかサーバーが起動しなくなった。どうやら cmastdeqd を見ている別のサービスがあって、cmastdeqd が起動するまで 永遠に 待ち続けるらしい。全く、何というクソ実装。

仕方がないので、usb-device.sh (lsusb の呼び出し元)の方を無効にすることにした。

# pwd
/opt/hp/hp-snmp-agents/utils
# cp -p usb-device.sh usb-device.sh.orig
# echo : >usb-device.sh

結果、

# sar | tail -n 10
18:10:01          all      6.04      0.00      0.40      0.00      0.00     93.56
18:20:01          all      8.40      0.01      0.47      0.00      0.00     91.12
18:30:01          all      8.65      0.00      0.47      0.00      0.00     90.88
18:40:01          all      8.81      0.00      0.48      0.00      0.00     90.71
18:50:01          all      8.80      0.00      0.47      0.00      0.00     90.73
19:00:01          all      2.16      0.00      0.29      0.00      0.00     97.55
19:10:01          all      0.17      0.00      0.24      0.00      0.00     99.59
19:20:01          all      0.17      0.01      0.23      0.00      0.00     99.59
19:30:01          all      0.17      0.00      0.24      0.00      0.00     99.59
Average:          all      3.48      0.00      0.32      0.00      0.00     96.19

今回の件で、SPP はロクな品質でないことを確信した。私はこれにハマる前に別の地雷を踏んでいるから、そう断言できる。以下はその体験談。

  • サーバーのファームウェアをオンラインアップデートできるらしいので、やってみる。
  • アップデートのチェックに「数分かかるかも」と出る。
  • 実際は、百個程度の項目を 1 個ずつサイトへ接続してチェックするので、最短でも十数分は掛かる。
  • サイトが重いのか、チェックに時間が掛かったり、止まったりする。
  • タイムアウト・リトライ処理がないらしく、一度止まると永遠に止まる → リセット。
  • マグレでチェック処理が終わったので、先に進む。
  • 途中、前の画面はどうだったっけ?と「戻る」ボタンを押してみる。
  • 「前の画面」ではなく、全てが無かったことにされて一番最初のメニューまで戻される。
  • 気を取り直して、メニューから再びアップデート。
  • データにゴミが残っているらしく、エラーで先に進めず → リセット。
  • 再びマグレでチェックが終わり、今度は絶対に「戻る」なんて押すもんか、と心に誓って先へ進む。
  • 最後、アップデートの実行ボタンを押す。wktk
  • メッセージも何もない空白のダイアログが出て止まる → 呆然 → リセット。
  • 再びマグレで最後まで進み実行ボタンを押す → 当たり前のように空白ダイアログが出て止まる → give up。
  • その後、SPP DVD をダウンロードすればオフラインでアップデートできることを知る。
  • 実際、それでサクッと完了。オレの 1 日を返せ。

今まで触ったソフトウェアで、これほど殺意を覚えたのは初めてかも知れない。どうせ他の部分も似たような品質に違いない。永遠に止まるところなど、作った人が同じか、同じレベルであることを物語っている。

この様なものを見せられては、正直もう HP サーバーは使いたくない。本当は SPP もインストールしたくなかったが、デバイスドライバー系があるので、入れない訳にもいかないのが歯痒いところ。

2013-05-07

Can't install IE9 offline on Windows 7

下記の環境で、

IE9 のインストールに失敗する。スタンドアロン版インストーラーのくせに、こともあろうかインストール時に Windows Update に繋ごうとして失敗している。オプション /update-no や /passive も試してみたが効果なし。こういう時に /update-no が使えなくて、いつ使えというのだろう。

IE9 がインストールできない現象は様々にあるようだが、今回の場合、

で記載されている下記の更新プログラムをインストールすることで解決した。

こういう面倒を見てくれる所まで含めて、スタンドアロン版インストーラーと言うのではなくて?

2013-04-30

Animes in the 1st quarter of 2013

アニメは IT エンジニアの必須科目です。 ということで簡単なレビューを。

まず先に、原作を未読なのを謝罪しておく。話の内容より、テンポが速過ぎてまるでアメリカのアニメを見ているようだった。これがジョジョらしいのか私には判断不能だが、新鮮な感覚ではあった。中だるみがないので見るのは苦でなかったが、声優のチョイスはあれで良かったのか疑問が残る。

女子向けとかいう以前に、まずヒロインに問題あり。自己主張が乏しく、始終相手に流されっ放しでフラストレーションが溜まる。更に相棒がそれに輪を掛けて役立たずで、見ていて爆発しそうになる。途中から開き直って、何処までつまらないか見届けるつもりになったら、楽になった。OP が良かったのがせめてもの救い。

この辺から原作をチラ見していた。なので気付いたが、アニメ版は結構と端折られているらしい。話は、前作までを見ているなら安定して見れる。ただ「熱さ」は若干薄れたように思う。正直、原作を読んだ方が面白いような気もする。あと、アニメで見返してみても、扉絵のネタは凝りすぎて全然ウマくない思うのは私だけだろうか。

本編(絶チル)とは逆のシリアス路線は、完全に失敗だったと思う。ギャグの無い本シリーズなんて、つまらないにも程がある。何よりも致命的なのは、本作の女子キャラが可愛くないこと。原作のパティが何故あんな風になるのか、責任者を小一時間ほど問い詰めたい。このシリーズは原作を読むのが一番という結論。

見始めたときは、まさか一年続くとは思わなかった。知ってたら見なかったと思う。前宣伝通り声優陣は豪華で、ギャグがイマイチな分を声優の力量で補ってもらった感が大きい。今回の演技では、神谷浩史、森川智之を見直した。当初は笹子さん目当てで見ていたのだが、作画のブレが大きく、何か途中からどうでも良くなった。

企画自体は数年前から進行中らしく、キャラ付けはできている模様。聞いたことの無い声優を使うのは構わないが、歌がヘタなのが問題。逆に歌が上手い声優は演技がダメという。話も、1 クールしかないんだからメンバー集めに四苦八苦する描写とか要らなかった。決して嫌いでは無いのだが、イマイチ感の残る作品だった。

京アニということで視聴。キャラがけい○ん!を彷彿とさせるのは置いておいて、見る分には退屈することは無かった。しかし、この作品を京アニが作った意図が分からない。今までの作品は何らかチャレンジ精神的なものを感じたのだが、今回はそれを感じ取れなかった。まあ、某鳥が Gu-Gu ガ○モっぽい件は挑戦と言えなくも無い。

魔王と勇者、在り来たりな題材をどう料理するのかと思ったら、魔法は使わず経済で世界に挑むという予想外の展開。普通なら勇者一行の人外の強さがバランスを崩すところだが、バトルは本質では無いので何とか保っている。ただ話が少し難解。もっとバカ向けに「おっぱい」を前面に持ってきて良かった、というか寧ろそれを希望。

オーソドックスなファンタジーかと思いきや、銀魂臭の漂うギャグ作品。OP のルビ振りは一度は見ておくべき。しかし、見るべきものはそれだけ。肝心のギャグは面白くないのに加え、作ってる連中は面白いと思っている感が伝わってきて、特に後半になる程に鬱陶しい。真面目路線で作ってハズすのよりは幾分マシか、という所。

絵は綺麗。OP を見れば、製作陣のこの作品に対する思いが伺える。しかし中身がそれに付いていっていない。四人目の登場で猛烈な挽回を見せるが、というか、もうこの娘がメインヒロインで良くね? という程にヒロインのキャラが弱い。いっそのこと、主人公を除くヒロイン全員が中二病、という設定の方が面白かったのでは。

前期からの視聴。そのまま楽しく歌っていれば良かったものを、苦悩や葛藤を織り込んだせいで、在り来たりな話になった。また、メインキャラとサブキャラがはっきり分かれてしまい、前期でいい味を出しつつあったサブキャラがこぞって潰れてしまった。色んな意味で前期からデグレードしたと思う。

鍵っ子が生まれる理由に興味があり視聴。筋肉バカは論外として、最初はベタなキャラばかりの印象を受けるが、2 クールかけて各キャラを掘り下げていくため、感情移入もあって気にならなくなる。しかし結局キャラ紹介に終始した感があり、どう終わらせるのかと思ったら、まさか続くとは思わなかった。OP・ED は良い。

一般に相棒が頼りになる奴の場合、その相方は引っ込み思案で内気キャラというのが相場だが、本作では中々に強かで度胸のあるキャラで好感が持てる。しかしそれも前半の話。後半はとても同じ作者が作ったとは思えないくらい、見ていられない話になる。これ本当に同一人物が作った? 前半で期待しただけ、残念な結果だった。

影のあるイケメンが沢山出てきて適度に絡む、という女子向け作品に良くあるパターン。男子にとって一番つまらないパターンとも言う。唯一、浜路の存在が救い。彼女にだけは萌えられる。ただ女子的に需要が無いのだろう、出番が少ないのが悲しい。次回はもっと浜路を頼む。最早それだけがこの作品を見るモチベーション。

原作は序盤でリタイア。アニメで魅力を発見できるかと思ったが、やはり叶わなかった。まず主人公に魅力が無い。アリババは正義感をかざすくせにウジウジで見ててイライラする。モルさんはもっと萌えるキャラにできたはず。やはりこの作者は王道ファンタジーではなく、すもも(前半)のようなノリが合っていると思う。

思ったよりも早い再開だったな、と思ったら、やっぱり早すぎた模様。それも「原作」ではなく「製作」の方が、というのが問題。映画と平行のせいか、製作が追いつかないなら素直に止めた方が良かったのでは。これでは映画の宣伝がやりたかっただけ、と思われても仕方がない。次回は万全の状態でお願いしたい。

最初、凝ってはいるが地味な作品だと思ったが、最後まで見て評価が変わった。世界観は一貫してブレが無く、ギャグも息抜きも無いシリアス一辺倒でありながら、見るのが苦にならず最後まで見ることができた。OP/ED も含め、隅々まで製作者の拘りを感じる。目を惹く華やかさは無いが、大人が楽しめる良作。

見る前からフラウ坊のイメージしかない作品だが、この作品の不幸は前作(シュタインズ)が偉大過ぎたこと。普通ならば十分に良作だと思うが、相対的に評価が下がってしまうのは仕方が無いところ。しかし OP/ED の作詞・作曲までをも手掛ける志倉千代丸のマルチタレント性は、悔しいが認めざるを得ない。

見た感じで期待はしていなかったが、大方は予想通りだった。各キャラの個性が微妙な上に、全体的に取って付けたような話で終始している。所詮はパチンコが出自の作品か。ただ例外として、第十一話だけは面白かった。ああいうノリで全編を通していたら、もっと評価は違ったと思う。

心が読めてしまう超能力者、まともに描けば重くなるのは必至。いきなり初話で重い話を突きつけられるが、二話目で救われる。以降も周りキャラの明るさに助けられるので、安心して見ていられる。やはりアニメはこうでないと。○○ロ○ネクトも少しは見習って欲しい。ただ、森谷さんは途中でキャラが変わり過ぎだと思う。

パステル調の絵に惹かれて視聴。何というか、青緑色が目に心地よい。この作品は部長が可愛いと思えるかが全てだと思う。私は三話目くらいから可愛く見えてきたので問題なし。今回は内田真礼の頑張りを評価。あと途中参加のタマの必要性が疑問だったが、意外に SD キャラが一番可愛いのがタマで、これも問題なかった。

弱小コミュニティの成り上がり物語かと思ったら、最後の方は何か違った。主人公が万能過ぎるのと最後の謎解きが独りよがりなのがマイナスポイント。前半の話は嫌いではなかったが、最終的にはラノベをアニメにしました、という以上にはならなかったように思う。

2013-03-31

RHEL6: ifconfig is obsolete!

前回エントリで、expand_config を見て気付いたことがある。

RHEL6 では、インターフェイスに複数の IP アドレスを設定できるらしい。そういえば OS インストール時のネットワーク設定画面では、複数 IP アドレスが登録できそうな UI になっていた。今まで試したことはなかったが、実際にそこで複数 IP アドレスを設定してみると、ifcfg-* は次のようになる。

RHEL6.4: /etc/sysconfig/network-scripts/ifcfg-eth0:

DEVICE=eth0
TYPE=Ethernet
UUID=7f36ffb3-0b2a-48d5-9e81-18b685396f06
ONBOOT=yes
NM_CONTROLLED=yes
BOOTPROTO=none
HWADDR=00:0C:29:94:42:BD
IPADDR=192.168.0.1
PREFIX=24
IPADDR2=192.168.0.2
PREFIX2=24
IPADDR3=192.168.0.3
PREFIX3=24
DEFROUTE=yes
IPV4_FAILURE_FATAL=yes
IPV6INIT=no
NAME="System eth0"

これは完全に意図通りに動く。もう仮想インターフェイスなんて(eth0:1 とか)必要ない。ていうか、できるんだったらもっと早く(略)。尤も、IP アドレス毎に ifup / ifdown する必要があるなら、仮想インターフェイスは相変わらず有用ではある。

しかしインターフェイスに複数の IP アドレスを設定できるなら、今現在インターフェイスで有効な IP アドレスを知る手段も必要になる。これらは 2 つで 1 つ、どちらか一方だけでは意味がない。しかし残念ながら、ifconfig はその役には立たないらしい。

[rhel64]# ifconfig eth0
eth0      Link encap:Ethernet  HWaddr 00:0C:29:94:42:BD
          inet addr:192.168.0.1  Bcast:192.168.0.255  Mask:255.255.255.0
          inet6 addr: fe80::20c:29ff:fe94:42bd/64 Scope:Link
          UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
          RX packets:42649 errors:0 dropped:0 overruns:0 frame:0
          TX packets:18439 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:1000
          RX bytes:26605808 (25.3 MiB)  TX bytes:2001382 (1.9 MiB)

困った時の、man 頼み。

[rhel64]# man ifconfig
NAME
       ifconfig - configure a network interface

SYNOPSIS
       ifconfig [interface]
       ifconfig interface [aftype] options | address ...

NOTE
       This  program  is obsolete!  For replacement check ip addr and ip link.
       For statistics use ip -s link.

obsolete! と言ってくれたところで、一体どれだけの人が気付くというのか。今回のことがなければ、私も man を読もうとは思わなかったし。それはともかく、これからは ip addr を使え、と。

[rhel64]# ip addr show eth0
2: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UP qlen 1000
    link/ether 00:0c:29:94:42:bd brd ff:ff:ff:ff:ff:ff
    inet 192.168.0.1/24 brd 192.168.0.255 scope global eth0
    inet 192.168.0.2/24 brd 192.168.0.255 scope global secondary eth0
    inet 192.168.0.3/24 brd 192.168.0.255 scope global secondary eth0
    inet6 fe80::20c:29ff:fe94:42bd/64 scope link
       valid_lft forever preferred_lft forever

この ip addr は RHEL5 でも動く。(RHEL4 以前は知らない)

以上より、

もう ifconfig は時代遅れらしいよ。

ちなみに前回の話に出た Webmin (1.620)だが、やはりこの複数 IP アドレスには対応していない。2 番目以降の設定は Webmin 画面からは見えないし、変更することもできない。よって Webmin でネットワーク設定を行うつもりなら、この複数 IP アドレス機能も使わない方が良い。

2013-03-27

RHEL6: PREFIX overrides NETMASK in `ifcfg-*'

RHEL6 インストール画面で固定 IP アドレスを設定すると、ifcfg-* には NETMASK の代わりに PREFIX という項目が記入される。名前から NETMASK の代替であることは分かるし、実際にそう動く。しかし、もし PREFIX と NETMASK の両方が設定され、その内容が矛盾していたらどうなるのか。

似た関係に NETMASK / NETWORK / BROADCAST があるが、これは公式ドキュメントに記載がある。

BROADCAST=address
where address is the broadcast address. This directive is deprecated, as the value is calculated automatically with ipcalc.
NETMASK=mask
where mask is the netmask value.
NETWORK=address
where address is the network address. This directive is deprecated, as the value is calculated automatically with ipcalc.

曰く、「NETWORK と BROADCAST は非推奨です」と。しかし、PREFIX については何処にも記述が見当たらない。試しに grep -i prefix /etc/sysconfig/network-scripts/* してみると、この辺りの処理を行っている場所は 1 か所しかない。

RHEL6.4: /etc/sysconfig/network-scripts/network-functions:

expand_config ()
{
    local i=0 val
    for idx in '' {0..255} ; do
        ipaddr[$i]=$(eval echo '$'IPADDR$idx)
        if [ -z "${ipaddr[$i]}" ]; then
           [ "$idx" ] && [ $idx -gt 2 ] && break
           continue
        fi
        prefix[$i]=$(eval echo '$'PREFIX$idx)
        netmask[$i]=$(eval echo '$'NETMASK$idx)
        broadcast[$i]=$(eval echo '$'BROADCAST$idx)
        arpcheck[$i]=$(eval echo '$'ARPCHECK$idx)

        if [ "${prefix[$i]}x" != "x" ]; then
            val=$(/bin/ipcalc --netmask "${ipaddr[$i]}/${prefix[$i]}")
            netmask[$i]=${val##NETMASK=}
        fi

        if [ "${netmask[$i]}x" = "x" ]; then
            val=$(/bin/ipcalc --netmask "${ipaddr[$i]}")
            netmask[$i]=${val##NETMASK=}
        fi

        if [ "${prefix[$i]}x" = "x" ]; then
            val=$(/bin/ipcalc --prefix ${ipaddr[$i]} ${netmask[$i]})
            prefix[$i]=${val##PREFIX=}
        fi

        if [ "${broadcast[$i]}x" = "x" ]; then
            val=$(/bin/ipcalc --broadcast ${ipaddr[$i]} ${netmask[$i]})
            broadcast[$i]=${val##BROADCAST=}
        fi

        if [ "${arpcheck[$i]}x" != "x" ]; then
            arpcheck[$i]=${arpcheck[$i]##ARPCHECK=}
            arpcheck[$i]=${arpcheck[$i],,*}
        fi

        i=$((i+1))
    done

    if [ -z "${NETWORK}" ]; then
        eval $(/bin/ipcalc --network ${ipaddr[0]} ${netmask[0]})
    fi
}

これによると、

  1. PREFIX が設定されていれば、PREFIX から NETMASK が計算される。
  2. NETMASK が未設定(空)であれば、IPADDR から NETMASK が計算(推測)される。
  3. PREFIX が未設定(空)であれば、IPADDR / NETMASK から PREFIX が計算される。

つまり、PREFIX は NETMASK より強い。ついでに言うと、公式ドキュメント通り BROADCAST と NETWORK はどちらも IPADDR / NETMASK から自動計算されるが、それは値が未設定(空)である場合に限られる。

念のため RHEL5 でも確認しておくと、

RHEL5.9: /etc/sysconfig/network-scripts/network-functions:

expand_config ()
{
    if [ -z "${NETMASK}" ]; then
	eval `/bin/ipcalc --netmask ${IPADDR}`
    fi

    if [ -z "${PREFIX}" ]; then
	eval `/bin/ipcalc --prefix ${IPADDR} ${NETMASK}`
    fi

    if [ -z "${BROADCAST}" ]; then
	eval `/bin/ipcalc --broadcast ${IPADDR} ${NETMASK}`
    fi

    if [ -z "${NETWORK}" ]; then
	eval `/bin/ipcalc --network ${IPADDR} ${NETMASK}`
    fi
}
  1. NETMASK が未設定(空)であれば、IPADDR から NETMASK が計算(推測)される。
  2. PREFIX が未設定(空)であれば、IPADDR / NETMASK から PREFIX が計算される。

これだけではどちらが強いのか分からないが、合わせて expand_config の呼び出し元(/etc/sysconfig/network-scripts/ifup-eth)を見ると、実際に使われるのは PREFIX の方だと分かる。

よって RHEL5 でも、PREFIX は NETMASK より強い。RHEL4 以前は使ってないので知らない。

そもそも何故こんなことを気にするかというと、現在の Webmin (1.620)が PREFIX に対応してないっぽいから。Webmin は NETMASK を設定するが、PREFIX には一切関与しない(消しもしない)。よって PREFIX と NETMASK の両方が ifcfg-* に記述される状況が生まれてしまう。もし Webmin でネットワーク設定を行うなら、事前に全ての PREFIX を NETMASK に変換しておいた方が良い。でないと、いつか痛い目を見る可能性がある。


2014-06-19 追記

今更だが、Webmin 1.630 にて PREFIX 対応が行われた。

2013-02-27

RHEL6: ssh-keygen: Permission denied

SSH 鍵を作ろうとすると、「Permission denied」と言われる。

[rhel62]# mkdir ~/.ssh

[rhel62]# chmod 700 ~/.ssh

[rhel62]# ls -dl ~/.ssh
drwx------. 2 root root 4096 Feb 27 09:04 /root/.ssh

[rhel62]# ssh-keygen -t rsa -N '' -f ~/.ssh/id_rsa ; echo $?
Generating public/private rsa key pair.
open /root/.ssh/id_rsa failed: Permission denied.
Saving the key failed: /root/.ssh/id_rsa.

パーミッションに抜かりなどある訳がない。失礼な。こういう時、真っ先に疑うべきは SELinux。

/var/log/audit/audit.log:

type=AVC msg=audit(1361923639.970:20915): avc:  denied  { create } for  pid=1932 comm="ssh-keygen" name="id_rsa" scontext=unconfined_u:unconfined_r:ssh_keygen_t:s0-s0:c0.c1023 tcontext=unconfined_u:object_r:admin_home_t:s0 tclass=file
type=SYSCALL msg=audit(1361923639.970:20915): arch=c000003e syscall=2 success=no exit=-13 a0=7f6f3282cb80 a1=241 a2=180 a3=fffffff7 items=0 ppid=1875 pid=1932 auid=0 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 tty=pts3 ses=2 comm="ssh-keygen" exe="/usr/bin/ssh-keygen" subj=unconfined_u:unconfined_r:ssh_keygen_t:s0-s0:c0.c1023 key=(null)

案の定、何か文句を言っている。~/.ssh のコンテキストを確認すると、

[rhel62]# ls -dZ ~/.ssh
drwx------. root root unconfined_u:object_r:admin_home_t:s0 /root/.ssh

何処が気に入らないのかは良く分からないが、ともかく restorecon してみる。

[rhel62]# restorecon ~/.ssh

[rhel62]# ls -dZ ~/.ssh
drwx------. root root unconfined_u:object_r:ssh_home_t:s0 /root/.ssh

何か修正されたっぽいので、リトライ。

[rhel62]# ssh-keygen -t rsa -N '' -f ~/.ssh/id_rsa
Generating public/private rsa key pair.
Your identification has been saved in /root/.ssh/id_rsa.
Your public key has been saved in /root/.ssh/id_rsa.pub.
The key fingerprint is:
a7:14:6f:f0:8a:72:64:20:01:55:2b:24:4c:aa:a7:30 root@rhel62
The key's randomart image is:
+--[ RSA 2048]----+
|=++..            |
|.+ . .           |
|. o o   o        |
|.  o .   =       |
|E .   o S =      |
|.+   o o =       |
|.   . o o        |
|     o           |
|                 |
+-----------------+

動いた。ちなみに ~/.ssh を作るのを ssh-keygen に任せると、何もしなくても上手くいく。

[rhel62]# rm -fr ~/.ssh

[rhel62]# ls -dl ~/.ssh
ls: cannot access /root/.ssh: No such file or directory

[rhel62]# ssh-keygen -t rsa -N '' -f ~/.ssh/id_rsa ; echo $?
Generating public/private rsa key pair.
Created directory '/root/.ssh'.
Your identification has been saved in /root/.ssh/id_rsa.
Your public key has been saved in /root/.ssh/id_rsa.pub.
The key fingerprint is:
e6:83:f6:38:dc:fc:eb:6a:45:f1:39:05:34:7d:ad:68 root@rhel62
The key's randomart image is:
+--[ RSA 2048]----+
|           .+o  .|
|          .  .o o|
|           o + o |
|          . E .  |
|        S. . .   |
|       +  .      |
|     .ooo.       |
|     .oo+.       |
|      .oo++.     |
+-----------------+

これは理屈としては理解できるが、非常に分かり辛い動作だと思う。

この理屈に従うと、作ったファイル・ディレクトリが SELinux のポリシーに沿っているかどうか、逐一確認しなければならくなってしまう。そういうことを平気で要求する SELinux の気が知れない。だから「SELinux 氏ね」とか言われるんだよ。:-p

ところでコンテキストの修正は restorecon で行えるが、現在のコンテキストが正しいかどうかはどうやって確認すれば良いのか。

matchpathcon を使え、と。

[rhel62]# rm -fr ~/.ssh

[rhel62]# mkdir ~/.ssh

[rhel62]# chmod 700 ~/.ssh

[rhel62]# matchpathcon -V ~/.ssh ; echo $?
/root/.ssh has context unconfined_u:object_r:admin_home_t:s0, should be system_u:object_r:ssh_home_t:s0
1

[rhel62]# restorecon ~/.ssh

[rhel62]# matchpathcon -V ~/.ssh ; echo $?
/root/.ssh verified.
0

注意点として、matchpathcon には絶対パスを渡す必要がある。でないと判定に失敗する。

[rhel62]# ls -dZ .ssh
drwx------. root root unconfined_u:object_r:ssh_home_t:s0 .ssh

[rhel62]# matchpathcon -V .ssh ; echo $?
.ssh has context unconfined_u:object_r:ssh_home_t:s0, should be <<none>>
1

これも理解できる動作ではあるが、やはり分かり辛い。もう少しマシなメッセージは出せないのかと文句を言いたい。

と、いうようなことを実は 1 年以上前にやっていたのだが、最近になって RHEL6.3 では本現象が起こらないことに気が付いた。調べてみると、この辺か。

「理解できる」と言っておいてアレだが、どうやら仕様ではなかったらしい。