コグノスケ

ネットワークの不調

ある日、部屋のネットワークをシェア（ネットワークの契約や管理は私がやっています）している隣人から「インターネットに繋げない。」って言われました。うーん、何も変えてないぞ？

自分のデスクトップマシン（有線）で試すとインターネットに繋げました。プロバイダやVDSL回線は正常のようです。

隣人のPCは無線接続なので無線が原因？と考えて、手持ちの無線機器（VAIOとNintendo DS-i）で試してみました。結果VAIOは正常に通信できましたので、無線に問題はなさそうです。しかしDS-iはインターネットに接続できません。

何が違うのか

VAIOとDSの差というと、VAIOは固定IP、DSはDHCPから動的割り当てに設定したくらいしか思い浮かびません。試しにDSに固定IPを振ってみると、DSからインターネットに接続できました。どうやらDHCPサーバがおかしくなっているようです。

しかしCTUのDHCPサーバ設定を見ても異常はないし、ログを見ても攻撃されている様子はないので、CTUが原因とは考えにくいです。他に起動しているのはデスクトップマシンくらいなものですから、デスクトップマシンが原因でしょう。おそらく。

デスクトップマシンを調べるとVirtualBoxが起動している時のみ、DHCPが192.168.56.xという変なアドレスを振ってくることがわかりました。仮想マシン内でLinuxを動かしていたのでそれが原因かと思いきや、仮想マシン内でWindows 2000を動かしても同じ症状が出ます。もしやVirtualBox自体が原因か？

DHCPサーバをみつけたぞ

調べるとVirtualBoxは独自のDHCPサーバを持っていることがわかりました（※1）。Host-only Adapterの先にあるネットワーク（つまりホスト - 仮想マシン間ネットワーク）からのアドレス要求に答えて、アドレスを割り当てるためです。

部屋のネットワークとVirtualBoxのホスト - 仮想マシン間ネットワーク

上図のように、CTUのDHCPサーバは192.168.1.1〜254のアドレスを割り当てます。またVirtualBoxのDHCPサーバはホスト - 仮想マシン間ネットワーク上の機器に、192.168.56.101〜254のプライベートアドレスを割り当てるように設定されています。

VirtualBoxのDHCPサーバが振るアドレスと、さきほど判明した変なアドレスが一致していますので、DSを困らせるDHCPサーバはVirtualBoxで間違いなさそうです。

（※1）VirtualBoxのDHCPサーバの設定は、
[ファイル] - [環境設定] - [ネットワークタブ] - [Host-only Adapterのリストから適切なものを選択] - [ドライバーマークのボタン] - [DHCPサーバータブ]
にあります。かなりわかりづらいです。

ブリッジの弊害

ホスト - 仮想マシン間ネットワーク用のDHCPサーバのはずなのに、部屋のネットワーク上にある機器にアドレスを振っているのはなぜでしょう？実は訳あって（※2）部屋のネットワークとホスト - 仮想マシン間ネットワークをブリッジしていたのです。

部屋のネットワークとVirtualBoxのホスト - 仮想マシン間ネットワーク、ブリッジ後

上図のように、部屋のネットワークと、ホスト - 仮想マシン間ネットワークをブリッジすると、VirtualBoxのDHCPサーバに部屋のネットワークからのアドレス要求が届いてしまいます。さらにVirtualBoxのDHCPサーバはCTUのDHCPサーバより早く応答していたため、部屋のネットワークからのアドレス要求に対してVirtualBoxのDHCPサーバの応答が優先されてしまうのです。

その結果、DSはVirtualBoxのDHCPサーバが割り振るアドレスを受け取り、ホスト - 仮想マシン間ネットワーク（青線）へ参加してしまいます。これは当然CTUのDHCPサーバが割り振るのアドレスとは異なりますので、DSは部屋のネットワーク（赤線）上のCTUと通信できず、インターネットへアクセスできないのです。

今回の教訓は、ネットワークをブリッジするときは、ブリッジする2つのネットワークに被害が出ないことを確認してからやりましょう、かな。

（※2）この時はBridge Adapterが何故か使えなかった（2009年4月29日の日記参照）ため、Host-only Adapterを一つ作って、デスクトップのネットワークインタフェースとWindowsのブリッジ機能でブリッジしていました。

不幸中の幸い

幸いなことに今回のケースではVirtualBoxのDHCPサーバの応答速度が、CTUのそれに対して圧勝していたため、問題の発覚が早かったです。これがもし場合によってVirtualBoxのDHCPサーバが勝ったり負けたり、という状況だったら、さらに解析が困難でした。不幸中の幸い、でしょうか。

バージョンアップ

またVirtualBoxの話です。

VirtualBoxを2.2.0から2.2.2にバージョンアップした際に、何回やってもインストーラが失敗メッセージを出して終了してしまい、アップデートできません。症状を見るにRemoving Files... と出た後、何かが失敗してセットアップのRollbackが始まっているようです。

初めて役に立った

セットアップが削除したいファイルが使用中なのかなあ？と思って、Host-only Adapterを削除したり、Windowsの再起動直後にアップデートしたりしましたが、改善せず。何が悪いのやら？

もう2.2.0をアンインストールするしかないかなあと思いつつ、最後にダメもとでVirtualBox 2.2.0の修復セットアップを行った（私の環境ではWindowsの再起動が必要でした）後、2.2.2へのアップデートを行ったところ無事アップデートできました。

今までMicrosoft Officeくらいでしか修復セットアップを試したことがなくて、しかも大抵失敗するだけで何の役にも立たないイメージだったのですよ。今日、初めて修復セットアップが役立ったというか、きちんと動作したことに感動しました。

で、感動はさておき、古いセットアッププログラムが手に入らない場合は、素直に2.2.0をアンインストールしてから、2.2.2を新規にインストールすればうまくいくと思います。

親切設計

家ではVirtualBoxを使って、デスクトップに仮想Linuxマシンを作っています。

VirtualBoxはバージョンアップの際に設定ファイルを勝手に引き継ぐので、バージョンアップの際に再設定などは必要ありません。今使っている設定ファイルも1.xの時代から使ってきたものです。

使えたり使えなかったり？

しかし最近はネットワーク周りの変更で良く引っかかります。

以前VirtualBoxを2.2.0にバージョンアップした際に、どういうわけか今まで使っていたBridged Adapter（※1）が使えなくなってしまって、仕方なくHost-only Adapter（※2）に変更しました。

で、最近2.2.2にバージョンアップしたら、またBridged Adapterが使えるようになっていました。何でだろう。使えるのか使えないのか、良くわからん…。

（※1）VirtualBoxがホストのネットワークインタフェースと仮想マシンのネットワークインタフェースをブリッジする方法。Windowsのブリッジ機能とは違います。

（※2）仮想マシンのネットワークインタフェースと通信するためのインタフェースを新たに作成する方法。Windowsのブリッジ機能で、ホストマシンのネットワークインタフェースとHost-only Adapterをブリッジすると、Bridged Adapterでやっていたこととほぼ同等のことができます。

旅行記

かなりいまさらですけど。

• 3月8日のラーメン博物館旅行（2009年3月8日の日記参照）
• 3月28日の飛鳥旅行（2009年3月28日の日記参照）
• 3月29日の嵐山旅行（2009年3月29日の日記参照）

以上3旅行の写真と日記を上げました。写真がいっぱいあるとめんどくさいのねー。

順番メチャクチャだけど

そうだ3月28日に書き損ねた話をここに書こう。

じょーと飛鳥に向かう前に、梅田スカイタワー地下のお好み焼き屋「きじ」に行きました。「きじ」ではメニューを店主のおっちゃんに注文して、おっちゃんが焼いてくれるのを待つというスタイルを取っています。

一応メニューは壁に貼ってあるんですが、店が混んでるので遠くてよくわからんのよね。そういうときは迷わず「おまかせでー！」っておっちゃんに言えばオススメ品を焼いてくれます。

何が出てくるかわかりませんが、好き嫌いのない人なら損はしないと思います。おっちゃんも「ネギは食えるか？」など好き嫌いを聞いてから焼き始めていたので、全く食えない物が出てくることはないはず。

僕らの後ろにいたカップルがミックスを注文していたのですが、おっちゃんに「ミックスはどこでも食えるよ〜？別のにしなよ〜、絶対うまいよ〜。」とかなんとか言って、別のお好み焼きに誘導されてました。なんか面白いおっちゃんだなあ。

定額給付金

ポストに定額給付金を振り込みました、というはがきが届いていました。はがきには4月16日と日付が打ってあります。

定額給付金の振り込み（※）

口座をチェックするとお金も入っている様子。4月21日に振り込まれたそうです。はがきの日付と全く合ってないが、まあいいか…。

（※）画像はネットバンクの画面キャプチャですが、残高を示す表が無駄にでかかったのでかなり端折っています。

同じはずの環境

サーバでプログラムをmakeすると、挙動が違うことに気づきました。

例えばsed-4.1.5ですと、デスクトップのVM上でコンパイルすると何事もなく成功するのに、サーバでコンパイルするとsed-4.1.5/po以下の *.poファイルを更新しようとして失敗し、コンパイルがコケてしまいます。

デスクトップ、サーバともにDebian GNU/Linux 5.0（Lenny）ですから、コンパイラを始めとしたツールの差はなく、環境変数も同じですし、全く同じソースを利用しています。にも関わらずコンパイルに成功したり、しなかったりするのはなんなのでしょうか？

違いを追え

どうやら使っているツールや環境変数、ソースコードまで同じなのに動作が異なるという現象が起きうるようです。

まずはオーソドックスな手順（※）でコンパイルを進めてみて、違いが出る場所を調べました。configureのログは違いなしですが、makeのログは一行目から既に違っています。

make  all-recursive
make[1]: Entering directory `/home/katsuhiro/build/sed-4.1.5'
Making all in intl
make[2]: Entering directory `/home/katsuhiro/build/sed-4.1.5/intl'
（... 以下、略 ...）

デスクトップではビルド用のディレクトリ（build/sed-4.1.5）に入って、コンパイルが始まります。

cd /home/katsuhiro/src/sed-4.1.5 && /bin/sh /home/katsuhiro/src/sed-4.1.5/config/missing --run aclocal-1.9 -I config
 cd /home/katsuhiro/src/sed-4.1.5 && /bin/sh /home/katsuhiro/src/sed-4.1.5/config/missing --run automake-1.9 --gnits
doc/Makefile.am:29: docdir was already defined in condition TRUE, which includes
 condition BUILD_HTML ...
（... 以下、略 ...）

対するサーバではソース用のディレクトリ（src/sed-4.1.5）に入って、configureやMakefileの更新が始まります。

なぜこんな違いが出るかというと、ビルドディレクトリのMakefile（build/sed-4.1.5/Makefile）にある、ACLOCAL_M4ターゲットが適用されるか、されないかが異なるためです。

（... 関係ない部分なので略 ...）

48: ACLOCAL_M4 = $(top_srcdir)/aclocal.m4
49: am__aclocal_m4_deps = $(top_srcdir)/config/codeset.m4 \r（... 中略 ...）
60: 	$(top_srcdir)/config/strverscmp.m4 $(top_srcdir)/configure.ac

（... 関係ない部分なので略 ...）

92: ACLOCAL = ${SHELL} /home/katsuhiro/src/sed-4.1.5/config/missing --run aclocal-1.9

（... 関係ない部分なので略 ...）

260: $(ACLOCAL_M4):  $(am__aclocal_m4_deps)
261: 	cd $(srcdir) && $(ACLOCAL) $(ACLOCAL_AMFLAGS)

（... 関係ない部分なので略 ...）

一応補足しておくと260行目の定義は「ソースディレクトリのaclocal.m4がconfig/*.m4より古かったら、missing --run aclocal-1.9を実行してね。」という意味です。

つまりデスクトップではaclocal.m4が古いとみなされないのに、サーバではaclocal.m4が古いとみなされるという違いがあるのです。

（※）sedに限らずGNU autotoolsを使ったソースコードをコンパイルする際は、ソースを展開したディレクトリ（例: ~/src/sed-4.1.5）の他に、ビルド用のディレクトリ（例: ~/build/sed-4.1.5）を作成し、ビルド用のディレクトリでコンフィグおよびコンパイル（例: cd ~/build/sed-4.1.5 && ~/src/sed-4.1.5/configure && make && make install）ができます。

更新時刻が違う

どうやらデスクトップとサーバではファイルの新旧が異なるようです。

ではmakeがファイルの新旧をどう判断しているかというと、実はファイルの更新時刻を比較しているだけです。ですからデスクトップではaclocal.m4とconfig/*.m4が同じ更新時刻になっているが、サーバでは更新時刻が異なっていてなおかつaclocal.m4の方が古い時刻になっている、と考えられます。

ファイルの更新時刻はlsコマンドでわかりますが、より詳しい更新時刻を見るためにls --full-timeオプションをつけて調べます。

$ ls --full-time aclocal.m4 config/*.m4
-rw-r--r-- 1 katsuhiro katsuhiro 31965 2009-04-08 21:59:07.000000000 +0900 aclocal.m4
-rw-r--r-- 1 katsuhiro katsuhiro   894 2009-04-08 21:59:07.000000000 +0900 config/codeset.m4
-rw-r--r-- 1 katsuhiro katsuhiro  1394 2009-04-08 21:59:07.000000000 +0900 config/getline.m4
（... 中略 ...）
-rw-r--r-- 1 katsuhiro katsuhiro   733 2009-04-08 21:59:07.000000000 +0900 config/strverscmp.m4

デスクトップではナノ秒の部分は全て0に設定されており、どのファイルも同じ更新時間です。

$ ls --full-time aclocal.m4 config/*.m4
-rw-r--r-- 1 katsuhiro katsuhiro 31965 2009-04-08 22:00:53.953952850 +0900 aclocal.m4
-rw-r--r-- 1 katsuhiro katsuhiro   894 2009-04-08 21:59:33.965953865 +0900 config/codeset.m4
-rw-r--r-- 1 katsuhiro katsuhiro  1394 2009-04-08 21:59:33.977953882 +0900 config/getline.m4
（... 中略 ...）
-rw-r--r-- 1 katsuhiro katsuhiro   733 2009-04-08 21:59:34.005955390 +0900 config/strverscmp.m4

一方、サーバではナノ秒の部分にも数値が設定されており、どのファイルも異なる更新時間です。

ファイルシステムが違う

どうやらデスクトップとサーバではファイルの更新時刻が違うらしいことがわかりました。何が原因かというと、実はファイルシステムが違っていたのです。

デスクトップで使用しているReiserFSやext3では、更新時間のナノ秒部分に常に0を代入します。対してサーバで使用しているXFSでは、更新時間のナノ秒部分まできっちり時間を設定します。

結果、ReiserFSやext3上では同時刻と判断されmakeに無視されるようなファイルも、XFS上では更新時刻が異なると判断され、makeがあちこちのファイルを更新して回る現象が起きてしまうわけです。

おそらくtarなどはアーカイブの展開時にutimeで更新時刻を秒単位で上書きしているはずです。XFSに対して更新時刻を秒単位でいじると、同じ時刻に設定したつもりでも、ナノ秒部分が残ってしまって異なる時刻と判断される、なんてことが起きている可能性がありますね。これは追々調べたいと思います。

そもそも悪いのは

デスクトップとサーバではファイルシステムが違うせいでmakeの動作が変わることがわかりました。が、問題はそこではなくて、きちんとコンパイルできないのはsedが悪いのであって、ファイルシステムのせいではありません。本来、ReiserFSでもXFSでもコンパイルできないといけないはずです。

しかしコンパイルで問題が出るのは大抵GNU autotoolsやGNU gettextですから、100％sedが悪いとも言えません。こやつらはバージョン間で仕様がメチャクチャに変わりまくるので、ちょっとバージョンが違うとトラブルが起きます（※2）。

結局、悪いのは誰なのか良くわかりません。長々書いたわりに歯切れが悪い…。

（※2）バージョン間の差を理解してさっと直せれば良いのですが、GNU autotoolsやGNU gettextの激変する仕様について行くのは至難の業です。