Xen や KVM などの完全仮想化と異なり、 OpenVZ はホストOS のカーネルがゲスト OS のカーネルとしても使われる。 つまり VPS (Virtual Private Server) サービスのユーザが別のカーネルを立ち上げることができない (ServersMan@VPS Perfect は完全仮想化だが月額 3150円と高いのでここでは考えない)。 OS は CentOS, Debian, ubuntu から選ぶことになる。

しかしながら、 私が個人的に管理しているサーバは、 全て OS を独自の 「my distribution」 (便宜上ここでは GCD OS と呼ぶ) に統一していて、 全サーバでディスクの内容を同期させている。 つまりある特定のサーバ固有の設定情報も、 全サーバが共有している。 共有していないのは各サーバのホスト名と、 秘密鍵などごく一部の情報だけ。 だからサーバが壊れた場合も、 新しいマシンを用意して他のサーバからディスク内容を丸ごとコピーするだけで済む。

私個人で管理しているサーバ (もちろん会社で運用しているサーバは除く) は、 仮想環境も含めると 20台ほどになるので、 異なる OS はできれば管理したくない。 ServersMan@VPS で提供されるカーネルを使うのは (OpenVZ の仕組み上) 仕方がないとして、 ディスクの内容は GCD OS と入れ替えることにした。

稼働中のサーバをいじるとき重要なのが、 トラブった時に 「元に戻せるか?」 ということ。 元に戻せるなら多少の失敗を恐れることはない。 ほとんどの VPS サービスは、 最悪の事態に陥っても初期化すれば元通りになるので、 操作をミスっても一からやり直せばいいのだが、 OS を入れ替えようとする場合は (当然) 新しい OS 一式を送り込む必要があり、 初期化するとこれが消えてしまうので再度転送する羽目になる。 GCD OS は最小セットで 7GB 近くあるので、 何度も転送を繰り返したりすると VPS サービスの契約ネットワーク帯域を使いきってしまう。

幸い、 ServersMan@VPS に帯域制限は無いが、 一日に 何十GB も転送していたら、 きっと管理者に睨まれるはず。 そこで、 どんなに失敗しても、 再起動すれば ssh でログインできる状態に戻るような OS 入れ替え手順を考えてみた。 ssh でログインできさえすれば後は何とでも修復できる。 逆に言うと ServersMan@VPS のようなコンソールが提供されない VPS サービスでは ssh でログインできなくなると万事休す、 残された復旧手段は初期化しかない。

まず ServersMan@VPS Standard プランを契約 (月額 980円) して、 Ubuntu(64bit) の最小構成 (シンプルセット) を選択。 ssh でログインして netstat でソケットを開いているデーモンを調べ、 片っ端から dpkg --purge (アンインストール) する。 もちろん sshd (ssh サーバ) だけは purge してはいけない。 syslog や cron などフツーは決して purge しないデーモンも遠慮無く purge する。 ps したとき sshd のプロセスのみが表示されるような状態になるまで purge しまくる。 で、 一通り purge し終わったら念のため再起動してみる。 もしここで ssh でログインできなくなってしまっていたら、 初期化して振出しに戻る。

この時、 sshd が 22番ポートで listen している場合は、 GCD OS が起動する sshd と衝突するので、 22番ポート以外に変えておく。 幸い ServersMan@VPS の場合は sshd が初めから 3843番ポートで listen する設定になっていた (なぜ?) ので、 そのままにしておく。

次に、 デーモン類以外のパッケージも、 残しておくとディスクの肥やしになるだけなので、 できるだけ purge する。 とはいっても、 多くのパッケージが数MB 以下で容量的には誤差の範囲なので、 無理に purge して再起不能状態に陥るリスクを冒すより、 ディスクの肥やしにしておいた方がマシ。 で、 一通り purge し終わったら念のため再起動してみる。 もしここで ssh でログインできなかったら、 初期化して振出しに戻る。

こうして netstat -nap しても ps axf しても sshd 以外のプロセスが一切残っていない状態になったら、 いよいよ GCD OS 一式を送り込む。

senri:/ # mirror -v -r /usr/local/gcd -e 'ssh -p 3843' 'core64[183.181.54.38]' > /tmp/serversman &

mirror というのはサーバ間で GCD OS の同期を行なうためのスクリプト。 64bit (x86_64) の最小セットをコピーするために引数として 「core64」 を指定した。 このスクリプトは、 同期すべきファイルのリストを作成して rsync を呼び出す。 「-e 'ssh -p 3843'」 オプションは、 そのまま rsync に渡される。 このコマンド列で GCD OS 最小セット約 7GB が VPS の /usr/local/gcd ディレクトリ以下へ丸ごとコピーされる。 7GB の転送にどのくらいかかるかと思っていたら、 わずか 10分弱で終わってしまった。 100Mbps 以上の帯域ということになる。 結構すごい。

ホスト名を chiyoda.gcd.org に設定し、 このサーバ専用の秘密鍵を作成すれば GCD OS のインストールが完了。 あとは、 /usr/local/gcd 以下へ chroot して GCD OS を起動するだけ。 次のような GCD OS 起動スクリプト /etc/init.d/chroot を書いてみた。

#!/bin/sh
root=`echo $0 | sed -e 's@/etc/init.d/chroot$@@'`
if [ ! -d $root ]; then
   echo "Can't find root: $root"
   exit 1
fi
mount -obind /lib/modules $root/boot/lib/modules
chroot $root sh <<EOF
mount -a
svscanboot &
/etc/rc.d/rc.M
EOF

このスクリプトも GCD OS 一式をコピーするときに /usr/local/gcd/etc/init.d/chroot へコピーされる。 で、/usr/local/gcd/etc/init.d/chroot を、 とりあえず手動で実行。 手動で実行するところがミソで、 もしこのスクリプトにバグがあって異常事態に陥っても、 再起動すれば元に戻る。

上記 /usr/local/gcd/etc/init.d/chroot は、 chroot /usr/local/gcd sh を実行して、 chroot 環境下で svscanboot と /etc/rc.d/rc.M を実行する。 svscanboot は daemontools の起動スクリプト。 GCD OS のほとんどのデーモン類は daemontools の管理下で起動される。 一方 /etc/rc.d/rc.M は、 GCD OS のブートスクリプトで、 ファイアウォールなどネットワークまわりの設定や、 個々のサーバ特有の設定、 および一部のデーモン類の起動を行なう。

普通の Linux OS だと init から直接起動されるデーモンもあるが、 GCD OS の場合 init が起動するのは /etc/rc.d/rc.S と /etc/rc.d/rc.M および svscanboot だけ。 /etc/rc.d/rc.S は、 OpenVZ 環境下では不要な処理ばかりなので実行する必要はない。

こうして chroot 環境下で GCD OS が起動したら、 chroot /usr/local/gcd sh などと実行して GCD OS 環境へ入ることができる。 各種設定が正しく機能しているか、 デーモン類が正しく動いているか確認する。

ServersMan@VPS で使われているカーネルが、 2.6.18-194.3.1.el5.028stab069.6 と、 かなり古い (2.6.18 などという 5年も昔のカーネルを使い続けないでほしい ＞ RHEL) ので、 GCD OS をきちんと動かすには問題があった。 特に困ったのが、 iptables の owner モジュールが使えない点:

chiyoda:/ # uname -rv
2.6.18-194.3.1.el5.028stab069.6 #1 SMP Wed May 26 18:31:05 MSD 2010
chiyoda:/ # iptables -t nat -j REDIRECT -p udp --dport 53 --to-port 2053 -A dnscache.lo -s 127.0.0.1 -d 127.0.0.1 -m owner ! --uid-owner Gdnscache
iptables: No chain/target/match by that name.

このエラーは、 カーネルに CONFIG_NETFILTER_XT_MATCH_OWNER の設定がないのが原因。 NETFILTER_XT_MATCH_OWNER が導入されたのは 2.6.25 以降なので、 そもそも元から 2.6.18 には存在しない。

なぜ --uid-owner が必要かと言えば、 GCD OS では tinydns と dnscache を、 同じ IP アドレスで動かすことが基本になっているから。 つまり、 通常の名前解決に 127.0.0.1 の dnscache を利用するのだが、 dnscache (Gdnscache 権限で動作) が 127.0.0.1 に問合わせる時に限り mydns が返事をするようにしたい。

仕方がないので、 iptables に --uid-owner を指定してエラーになる場合は、 --uid-owner 抜きで iptables を再実行するように修正した:

nsredirect="-t nat -j REDIRECT --dport 53 --to-port $PORT"
chain=dnscache.lo
iptables -t nat -N $chain 2>/dev/null || iptables -t nat -F $chain
nsinner="$nsredirect -A $chain -s 127.0.0.1 -d 127.0.0.1 \
	-m owner ! --uid-owner Gdnscache"
iptables -p udp $nsinner
if [ $? -ne 0 ]; then
    nsinner="$nsredirect -A $chain -s 127.0.0.1 -d 127.0.0.1"
    iptables -p udp $nsinner
fi
iptables -p tcp $nsinner

このような修正を、 chiyoda.gcd.org だけでなく、 GCD OS をインストールしている全サーバで一斉に行なう点がミソ。 サーバごとにファイルの内容が微妙に異なっていたりしたら、 GCD OS を使う意味がない。

当然、 --uid-owner 抜きで iptables を実行した場合は、 dnscache が 127.0.0.1 の mydns に問合わせをすることができないが、 127.0.0.1 以外、 つまり 183.181.54.38 あるいは 2001:2e8:634:0:2:1:0:2a ならば mydns に問合わせることができるので問題無い。

じゃ、 なんのために、 わざわざ --uid-owner を使って 127.0.0.1 の mydns に問合わせられるようになっているかというと、 127.0.0.1 以外の IP アドレスが動的に変わるサーバ (ノートPC など) も想定しているから。 GCD OS は VirtualBox や Xen などの完全仮想化環境だけでなく、 coLinux や今回の OpenVZ など、 仮想化環境としてはやや異質なものもサポートしている。

以上のような細かい修正を行なっていって、 GCD OS が問題無く立ち上がるようになったら、 /usr/local/gcd/etc/init.d/chroot の呼び出しを (ubuntu の) /etc/rc.local に追加して、 VPS の起動時に自動的に GCD OS が起動されるようにする。

GCD OS が正しく立ち上がれば、 外部から 22番ポートに対して ssh ログインして GCD OS が使える。 22番ポートでログインできることが確認できたら、 3843番ポートの sshd は止めてもよい。 chroot 環境からはいつでも脱出できるので、 3843番ポートを止めても本来の (chroot する前の) ubuntu 環境にアクセスすることが可能:

senri:~ # ssh chiyoda.gcd.org
Enter passphrase for key '/root/.ssh/id_rsa':
Last login: Sat Jul 30 09:14:54 2011 from 2409:82:5fff:0:5542:d84e:971a:9656
Linux 2.6.18-194.3.1.el5.028stab069.6.
chiyoda:~ # ls -F /					↓ GCD OS
bin@   dev/  ftp/   lib/    proc/  run/   sys/  usr/
boot/  etc/  home/  lib64@  root/  sbin@  tmp/  var/
chiyoda:/ # chroot_escape /bin/bash			← chroot から脱出
groups: cannot find name for group ID 11
groups: cannot find name for group ID 14
root@chiyoda:/# ls -F --color=never			↓ ubuntu
aquota.group@  boot/  fastboot  lib32/  mnt/   sbin/     sys/  var/
aquota.user@   dev/   home/     lib64@  proc/  selinux/  tmp/
bin/           etc/   lib/      media/  root/  srv/      usr/
root@chiyoda:/# cat /etc/debian_version
squeeze/sid
root@chiyoda:/# lsb_release -r
Release:	10.10
root@chiyoda:/# exit
chiyoda:~ # 						↓ GCD OS

「chroot_escape /bin/bash」 が、 chroot 環境から脱出するコマンド。 脱出して、 「本来の」 root 環境 (この例では ubuntu) 下で、 引数のコマンド 「/bin/bash」 を実行する。 この bash を使って ubuntu の操作ができて、 exit すると元の GCD OS へ戻る。 まるで chroot 下の GCD OS の方が 「主」 で、 本来の root が 「従」 のように見える ;-)。

なお、 chroot_escape コマンド実行時の 「groups: cannot find name for group ID 〜」 というエラーは、 GCD OS の /etc/group と ubuntu の /etc/group が異なるため。 つまり GCD OS の root は ID 11 と 14 のグループに属しているが、 ubuntu には ID が 11 と 14 のグループが存在しないため、 このようなエラーが表示される。

ここまでやるなら、 chroot といわず root に GCD OS をインストールしてしまえば? という声が聞こえてきそうであるが、 ServersMan@VPS ではコンソールが利用できないため、 トラブったときのために何らかの 「バックドア」 は残しておきたい。 GCD OS がどのような状況に陥っても、 3843番ポートの sshd (init から起動されるので kill しても再起動する) にログインできれば、 ubuntu 環境で GCD OS の修復が可能。

というわけで一週間ほど ServersMan@VPS Standard プランを使っているが、 意外に (失礼!) 使えるので驚いた。 実は、 OpenVZ な 512MB ということであまり期待していなかった。 OpenVZ は swap を使えないので、 メモリ 512MB だと、 ちょっと重い処理をさせるだけですぐ OOM Killer が動き出すのだろうと思っていた。 ところが、

chiyoda:~ $ free
             total       used       free     shared    buffers     cached
Mem:       2097152     425020    1672132          0          0          0
-/+ buffers/cache:     425020    1672132
Swap:            0          0          0

512MB というのは実メモリ? の割当量のようで、 見かけ上は 2GB のメモリがある。 OpenVZ な VPS サービスによっては、 これをメモリ 2GB と言い張るところもあるんじゃないかと思うので、 ServersMan@VPS は良心的。

どのくらいのパフォーマンスなのか、 この日記 (WordPress を使用) の処理時間を測ってみる。 senri.gcd.org から ApacheBench でアクセスすると:

senri:~ $ /usr/apache2/bin/ab -n 10 http://chiyoda.gcd.org/blog/
This is ApacheBench, Version 2.3 <$Revision: 655654 $>
	...
Connection Times (ms)
              min  mean[+/-sd] median   max
Connect:        6    7   0.3      7       7
Processing:   992 1116  94.1   1139    1259
Waiting:      305  403  78.3    380     561
Total:        998 1122  94.1   1146    1265

これを、 Linode Xen 512MB プラン (fremont.gcd.org) と比較する。 fremont.gcd.org は米国西海岸にある VPS なので、 同じく西海岸にある prgmr.gcd.org から ApacheBench でアクセスすると:

prgmr:~ $ /usr/apache2/bin/ab -n 10 http://fremont.gcd.org/blog/
	...
              min  mean[+/-sd] median   max
Connect:        2    3   0.1      3       3
Processing:   996 1081  73.8   1084    1197
Waiting:      354  391  30.5    388     450
Total:        999 1084  73.8   1086    1200

両者は、 ほとんど同等のパフォーマンスであることが分かる。 Linode Xen 512MB プランは、 ディスク 20GB で月額 $19.95 (約 1600円) なので、 ServersMan@VPS Standard プラン (ディスク 30GB, 月額 980円) の方がコストパフォーマンスが良い。

もちろん、 ServersMan@VPS Standard には、 カーネルのバージョンが古すぎ、という問題点があるし、 メモリ 512MB を超える部分のパフォーマンスは、 ホストOS 側の負荷状況に左右されると思われるので、 単純に比較すべきではない。

NGN のサービス情報サイト (NGN からでないとアクセスできない) のページで 「サービス申込受付」 をクリック。 「お客様ID」 と 「アクセスキー」 を入力してログインすると、 「フレッツ・v6オプション」 を申し込むことができる (このページから申し込むと無料)。

申込み後、 NGN から流れてくる IPv6 ルータ広告 (RA, Router Advertisement) を tcpdump で監視していたら、 34分経過した頃にプレフィックスが突然変わった。 NGN の契約以来、 今まで一度も変わったことがなかったプレフィックス 2408:82:5fff:86a::/64 が、 2408:282:5fff::/64 になった。 これはきっとインターネットと通信できるプレフィックスに違いないと思って、 他のサイトから ping6 を打ってみた。 が、 NGN からは RA 以外は何も流れてこない。 うーん。 ちなみに RA の送信元 (NGN のエッジ・ルータ) は fe80::21e:13ff:fec2:69c2 のまま変わらず。

その後 1時間ほど放置してみたが何も状況が変化しなかったので、 「フレッツ・v6オプション」 って何? と思い直して (サービス内容をよく確認せずに申し込んでしまっていた)、 あらためて FAQ を見ると、

　Q

「フレッツ・v6オプション」を利用してインターネットへの接続はできますか？

　A

「フレッツ・v6オプション」 は、NTT東日本が構築するNGN内での通信が可能ですが、 「フレッツ・v6オプション」 のみではインターネットへの接続はできません。 インターネットへの接続には、 別途プロバイダサービスをお申し込みいただく必要があります。

インターネットへ接続するには、 フレッツ・v6オプションとプロバイダ契約の両方が必要らしい。 では、 どのプロバイダの、 どんなサービスを申し込めばいいんだろう? と思って、 フレッツ 光ネクスト IPv6 IPoE対応プロバイダを調べてみると、 神奈川県だと現時点で対応しているのは IIJmio だけだった (神奈川県だけでなく他県も同様)。 IIJ は今まで契約したことがなかったが、 他に選択肢が無いのであれば仕方がない。 さくっとクレジットカード番号を入力して IIJmio FiberAccess/NF を契約した (月額 2100円)。 これで半固定 IPv6 アドレスによる IPoE サービスと、 動的割当て IPv4 アドレスによる PPPoE サービスが利用できる。

Ether 上に IP を流すのはごくごく普通のことなので、 あらたまって 「IPoE」 (IP over Ether) と表現されると何だか妙な感じ。 「半固定」 というのも微妙な表現だが、 注意書きには 「お客様の移転、フレッツ回線の品目変更やNTTのメンテナンスにより、 変更になる場合があります」 と書いてあるので、 普通に使ってる限りプレフィックスが変わることは無さそう。

mio FiberAccess/NFサービスは、 インターネットマルチフィード株式会社が提供する 「transix (トランジックス)」 サービスを利用して、 NTT東西の 「インターネット（IPv6 IPoE）接続」 に対応したIPv6接続を提供します。 IPv6接続に加えて、 PPPoE接続方式によるIPv4接続もあわせて提供するため、 お客様は一つのサービスでIPv6、 IPv4の両方の接続環境を利用することができます。

IIJmio FiberAccess/NF概要 から引用

IPv6 接続は全て transix が担っていて、 IIJmio はネットワーク的には何の役割も果たしていない。 IIJmio がやってるのは課金などユーザ管理関連だけ。 プロバイダである IIJmio が絡むから、 IPv4 接続も提供するなどという抱き合わせ商法になる。 動的割当の IPv4 PPPoE 接続サービスなんて要らないから、 もう少し安いプランがあればいいのにと思う。

本来、 ネイティブ方式の IPv6 接続サービスは、 NTT東西だけで提供するのが自然な形だった。 ところが、 NGN を持っていて地域独占な NTT東西が接続サービスまで提供してしまっては、 他のプロバイダの出る幕がなくなると猛反発されて、 BBIX, JPNE, インターネットマルチフィード の三社が接続サービスを提供することになった。 なぜ三社だけかといえば、 プロバイダを増やすと経路情報の処理量が膨大になって NGN の各ルータの処理能力の限界を超えてしまうから。

ところが、 三社だけでは少なすぎると他のプロバイダ達が反対したので、 その他大勢の中小プロバイダにも参入の余地を無理矢理作ったということなのだろう。 でも、 やってることは単なるユーザ管理なので、 通信事業者じゃなくてもできる簡単なお仕事。 この期に及んで業界保護みたいなことはやめてほしい。 インターネット接続サービスは既にコモディティ化しているのだから、 体力のないところは淘汰されるべき。

FiberAccess/NF を契約してから 1時間が経過したとき、 NGN から流れてくる RA のプレフィックスが 2409:82:5fff::/64 に変わった。 今度こそ疎通したかと思い、 senri.gcd.org に IPv6 アドレス 2409:82:5fff::3c20:55dc を割当てて、 他のサイトから 2409:82:5fff::3c20:55dc に対して ping6 を打ってみる。 すると無事、NGN IPoE 経由で senri.gcd.org に ICMPv6 パケットが届いた。

ただし、 まだ senri.gcd.org の routing 設定を行なっていないので、 返りパケットは PPPoE 経由で OCN 側へ行ってしまう (おそらく OCN 内部で捨てられる)。 そこで、 とりあえずの対策として NGN から届いたパケットは NGN へ返すように、 policy routing rule を設定した:

senri:/ # ip -6 rule add from 2409:82:5fff::/64 table 100 pref 25600
senri:/ # ip -6 route add default table 100 via fe80::21e:13ff:fec2:69c2 dev eth1

つまり、 送信元アドレスが 2409:82:5fff::/64 なパケットは routing table 100 を参照するようにして、 routing table 100 において default route を、 fe80::21e:13ff:fec2:69c2 (NGN のエッジ・ルータ) へ向ける。

これで ping に対して応答できるようになった。

fremont:~ $ ping6 -c 3 2409:82:5fff::3c20:55dc
PING 2409:82:5fff::3c20:55dc(2409:82:5fff::3c20:55dc) 56 data bytes
64 bytes from 2409:82:5fff::3c20:55dc: icmp_seq=1 ttl=49 time=122 ms
64 bytes from 2409:82:5fff::3c20:55dc: icmp_seq=2 ttl=49 time=122 ms
64 bytes from 2409:82:5fff::3c20:55dc: icmp_seq=3 ttl=49 time=122 ms

--- 2409:82:5fff::3c20:55dc ping statistics ---
3 packets transmitted, 3 received, 0% packet loss, time 2003ms
rtt min/avg/max/mdev = 122.479/122.526/122.591/0.289 ms
fremont:~ $ tcpspray 2409:82:5fff::3c20:55dc
Transmitted 102400 bytes in 0.491628 seconds (203.406 kbytes/s)

RTT (Round Trip Time, 往復所要時間) が 122ms もかかってるのは、 fremont.gcd.org が米国の西海岸にあるため。 2400:400d:100::3c20:55dc (OCN の PPPoE 接続) 宛の場合↓ と比べると、 transix は RTT で 50ms ほど速く、 帯域 (tcpspray による簡易測定) で倍くらい広い。

fremont:~ $ ping6 -c 3 2400:400d:100::3c20:55dc
PING 2400:400d:100::3c20:55dc(2400:400d:100::3c20:55dc) 56 data bytes
64 bytes from 2400:400d:100::3c20:55dc: icmp_seq=1 ttl=49 time=174 ms
64 bytes from 2400:400d:100::3c20:55dc: icmp_seq=2 ttl=49 time=174 ms
64 bytes from 2400:400d:100::3c20:55dc: icmp_seq=3 ttl=49 time=174 ms

--- 2400:400d:100::3c20:55dc ping statistics ---
3 packets transmitted, 3 received, 0% packet loss, time 2002ms
rtt min/avg/max/mdev = 174.046/174.386/174.593/0.539 ms

fremont:~ $ tcpspray 2400:400d:100::3c20:55dc
Transmitted 102400 bytes in 0.905523 seconds (110.433 kbytes/s)

参考までに IPv4 60.32.85.216 (OCN の PPPoE 接続) の場合も測ってみた。 すると RTT も帯域も transix と同程度だった。 つまり OCN の IPv6 PPPoE だけが突出して遅く、 帯域も狭い。

fremont:~ $ ping -c 3 60.32.85.216
PING 60.32.85.216 (60.32.85.216) 56(84) bytes of data.
64 bytes from 60.32.85.216: icmp_req=1 ttl=51 time=130 ms
64 bytes from 60.32.85.216: icmp_req=2 ttl=51 time=130 ms
64 bytes from 60.32.85.216: icmp_req=3 ttl=51 time=129 ms

--- 60.32.85.216 ping statistics ---
3 packets transmitted, 3 received, 0% packet loss, time 2002ms
rtt min/avg/max/mdev = 129.377/129.903/130.202/0.559 ms

fremont:~ $ tcpspray 60.32.85.216
Transmitted 102400 bytes in 0.518052 seconds (193.031 kbytes/s)

米国西海岸から transix までの IPv6 の経路はこんな感じ:

fremont:~ $ tracepath6 2409:82:5fff::3c20:55dc
 1?: [LOCALHOST]                        0.021ms pmtu 1500
 1:  2600:3c01:ffff:0:ca4c:75ff:fef5:d63f                  0.558ms
 1:  2600:3c01:ffff:0:ca4c:75ff:fef5:d63f                  0.480ms
 2:  10gigabitethernet2-3.core1.fmt1.he.net                3.149ms
 3:  10gigabitethernet1-2.core1.sjc2.he.net               11.042ms
 4:  equi6ix.sv.iij.com                                    1.834ms asymm  5
 5:  sjc002bf00.iij.net                                    9.384ms asymm  7
 6:  2001:48b0:bb00:8016::71                             120.588ms asymm  7
 7:  tky009bb11.IIJ.Net                                  120.730ms asymm  8
 8:  tky009ip50.IIJ.Net                                  121.048ms
 9:  2001:240:bb5c:1008::cafe                            120.365ms
10:  2404:8e00:feed:101::2                               121.852ms
11:  no reply
12:  no reply
13:  no reply
14:  no reply
15:  no reply
16:  2409:82:5fff::3c20:55dc                             127.409ms reached
     Resume: pmtu 1500 hops 16 back 49

「IIJmio はネットワーク的には何の役割も果たしていない」 が、 日米間の回線は IIJ が担っているようだ (あれっ? ^^;)。 日本に上陸後 (6 以降) はほとんど遅延していない。

OCN の PPPoE の場合だと、こんな感じ:

fremont:~ $ tracepath6 2400:400d:100::3c20:55dc
 1?: [LOCALHOST]                        0.047ms pmtu 1500
 1:  2600:3c01:ffff:0:ca4c:75ff:fef5:d63f                  3.935ms
 1:  2600:3c01:ffff:0:ca4c:75ff:fef5:d63f                  0.852ms
 2:  10gigabitethernet2-3.core1.fmt1.he.net                7.978ms
 3:  10gigabitethernet1-2.core1.sjc2.he.net                2.532ms
 4:  xe-0.equinix.snjsca04.us.bb.gin.ntt.net               2.018ms asymm  5
 5:  as-1.r21.osakjp01.jp.bb.gin.ntt.net                 168.074ms asymm 11
 6:  ae-0.ocn.osakjp01.jp.bb.gin.ntt.net                 167.792ms asymm 14
 7:  2001:380:8060:6::1                                  159.446ms asymm 13
 8:  2001:380:8170:4::1                                  167.630ms asymm 14
 9:  2001:380:8030:16::1                                 168.401ms asymm 15
10:  2001:380:8110:d::1                                  170.344ms asymm 14
11:  2001:380:8110:f::2                                  178.503ms asymm 13
12:  2001:380:8130:11::13                                178.131ms asymm 13
13:  2001:380:8270:8::2                                  172.448ms
14:  2001:380:4d:101::2                                  179.036ms
15:  2001:380:4d:182::2                                  181.317ms
16:  no reply
17:  2001:380:4d:181::2                                  173.127ms pmtu 1454
17:  senri.v6.gcd.org                                    183.023ms reached
     Resume: pmtu 1454 hops 17 back 49

日米間に 160ms もかかっている上に、 日本に上陸後 (5 以降) も 15ms ほど遅延がある。 なぜこんなに遅いのだろう? また、PPPoE なので mtu が 1454 になっている。

同じ OCN の PPPoE でも、 IPv4 だと遅くない (というか transix より若干速い) ので、 OCN の IPv6 PPPoE 接続サービスには、 なにか問題がありそう。 まあ、 追加料金無しのサービスなので、 IPv4 のオマケ的な位置づけなのかも?

fremont:~ $ tracepath 60.32.85.216
 1:  fremont.gcd.org                                       0.169ms pmtu 1500
 1:  184.105.143.85                                        1.702ms
 1:  184.105.143.85                                        0.418ms
 2:  10gigabitethernet2-3.core1.fmt1.he.net                0.665ms
 3:  10gigabitethernet1-1.core1.pao1.he.net                8.907ms
 4:  sjo-bb1-link.telia.net                                1.297ms asymm  5
 5:  verio-119529-sjo-bb1.telia.net                        4.568ms
 6:  ae-8.r20.snjsca04.us.bb.gin.ntt.net                   1.922ms
 7:  as-2.r20.tokyjp01.jp.bb.gin.ntt.net                 112.093ms asymm  8
 8:  ae-1.ocn.tokyjp01.jp.bb.gin.ntt.net                 119.692ms asymm 11
 9:  60.37.27.137                                        120.641ms asymm 10
10:  60.37.55.158                                        119.549ms asymm 11
11:  122.1.173.238                                       121.243ms
12:  118.23.5.78                                         128.853ms asymm 14
13:  no reply
14:  118.23.8.9                                          128.712ms pmtu 1454
14:  gcd.org                                             123.788ms reached
     Resume: pmtu 1454 hops 14 back 52

7月26日追記:

西海岸から ping6 を打つのは 2階から目薬もびっくりなので、 国内の IPv6 が使える VPS を急遽契約して (2ヵ月無料キャンペーン)、 ping6 を打ってみた。

chiyoda:~ $ ping6 -c 3 senri
PING senri(2409:82:5fff::3c20:55dc) 56 data bytes
64 bytes from 2409:82:5fff::3c20:55dc: icmp_seq=1 ttl=49 time=6.96 ms
64 bytes from 2409:82:5fff::3c20:55dc: icmp_seq=2 ttl=49 time=6.72 ms
64 bytes from 2409:82:5fff::3c20:55dc: icmp_seq=3 ttl=49 time=6.51 ms

--- senri ping statistics ---
3 packets transmitted, 3 received, 0% packet loss, time 2001ms
rtt min/avg/max/mdev = 6.515/6.734/6.969/0.208 ms

chiyoda:~ $ tcpspray -n 10000 2409:82:5fff::3c20:55dc
Transmitted 10240000 bytes in 0.864344 seconds (11569.468 kbytes/s)

さすがに国内からだと速くて広い。 93Mbps 出れば普通の用途には充分。 OCN PPPoE の IPv6 および IPv4 でも測ってみたが、 有意な差は見られない:

chiyoda:~ $ ping6 -c 3 2400:400d:100::3c20:55dc
PING 2400:400d:100::3c20:55dc(2400:400d:100::3c20:55dc) 56 data bytes
64 bytes from 2400:400d:100::3c20:55dc: icmp_seq=1 ttl=54 time=8.84 ms
64 bytes from 2400:400d:100::3c20:55dc: icmp_seq=2 ttl=54 time=6.58 ms
64 bytes from 2400:400d:100::3c20:55dc: icmp_seq=3 ttl=54 time=6.46 ms

--- 2400:400d:100::3c20:55dc ping statistics ---
3 packets transmitted, 3 received, 0% packet loss, time 2001ms
rtt min/avg/max/mdev = 6.465/7.298/8.843/1.097 ms

chiyoda:~ $ tcpspray -n 10000 2400:400d:100::3c20:55dc
Transmitted 10240000 bytes in 0.844327 seconds (11843.752 kbytes/s)

chiyoda:~ $ ping -c 3 60.32.85.216
PING 60.32.85.216 (60.32.85.216) 56(84) bytes of data.
64 bytes from 60.32.85.216: icmp_req=1 ttl=53 time=6.62 ms
64 bytes from 60.32.85.216: icmp_req=2 ttl=53 time=6.64 ms
64 bytes from 60.32.85.216: icmp_req=3 ttl=53 time=6.95 ms

--- 60.32.85.216 ping statistics ---
3 packets transmitted, 3 received, 0% packet loss, time 1999ms
rtt min/avg/max/mdev = 6.623/6.740/6.955/0.152 ms

chiyoda:~ $ tcpspray -n 10000 60.32.85.216
Transmitted 10240000 bytes in 0.842140 seconds (11874.510 kbytes/s)

経路は、 それぞれ以下のような感じ:

transix IPv6 IPoE:

chiyoda:~ $ tracepath6 2409:82:5fff::3c20:55dc
 1?: [LOCALHOST]                        0.016ms pmtu 1500
 1:  2001:2e8:634:0:2:2:0:1                                0.054ms 
 1:  2001:2e8:634:0:2:2:0:1                                0.038ms 
 2:  2001:2e8:22:202::2                                    1.192ms asymm  4 
 3:  2001:2e8:20::22:11                                    1.466ms asymm  5 
 4:  2001:7fa:7:1::2497:1                                 53.299ms asymm  6 
 5:  tky008bf01.IIJ.Net                                    3.417ms asymm  6 
 6:  tky009bb10.IIJ.Net                                    2.622ms asymm  8 
 7:  tky009ip50.IIJ.Net                                    2.763ms asymm  8 
 8:  2001:240:bb5c:1008::cafe                              3.188ms asymm  9 
 9:  2404:8e00:feed:101::2                                 3.911ms asymm 10 
10:  no reply
11:  no reply
12:  no reply
13:  no reply
14:  no reply
15:  2409:82:5fff::3c20:55dc                               8.107ms reached
     Resume: pmtu 1500 hops 15 back 49 

OCN IPv6 PPPoE:

chiyoda:~ $ tracepath6 2400:400d:100::3c20:55dc
 1?: [LOCALHOST]                        0.019ms pmtu 1500
 1:  2001:2e8:634:0:2:2:0:1                                0.058ms 
 1:  2001:2e8:634:0:2:2:0:1                                0.037ms 
 2:  2001:2e8:22:202::2                                    2.505ms asymm  4 
 3:  2001:2e8:20::22:11                                    2.464ms asymm  5 
 4:  2001:380:0:2516::1                                    3.111ms asymm  6 
 5:  2001:380:8280:f::1                                   19.584ms asymm  7 
 6:  2001:380:8150:f::12                                   3.486ms asymm  8 
 7:  2001:380:8270:7::2                                    5.817ms asymm  8 
 8:  2001:380:4d:100::2                                    4.504ms asymm  9 
 9:  2001:380:4d:181::2                                   14.276ms asymm 10 
10:  no reply
11:  2001:380:4d:181::2                                    7.015ms pmtu 1454
11:  senri.v6.gcd.org                                      7.457ms reached
     Resume: pmtu 1454 hops 11 back 54 

OCN IPv4 PPPoE:

chiyoda:~ $ tracepath 60.32.85.216
 1:  v-183-181-54-38.ub-freebit.net                        0.117ms pmtu 1500
 1:  v-183-181-55-247.ub-freebit.net                       0.040ms 
 1:  v-183-181-55-247.ub-freebit.net                       0.022ms 
 2:  202.216.248.129                                       0.515ms asymm  3 
 3:  no reply
 4:  oi-gate-1.otemachi4.dti.ad.jp                         1.899ms asymm  6 
 5:  122.28.177.109                                        2.830ms asymm  7 
 6:  118.23.146.121                                        8.064ms asymm  8 
 7:  118.23.168.8                                          3.123ms asymm  9 
 8:  60.37.55.154                                          5.095ms asymm  9 
 9:  122.1.173.238                                         4.176ms asymm 10 
10:  118.23.5.74                                           5.482ms asymm 12 
11:  no reply
12:  118.23.8.9                                            5.328ms pmtu 1454
12:  gcd.org                                               7.036ms reached
     Resume: pmtu 1454 hops 12 back 53 

「国際区間で遅延が大きめなのは、 OCNから fremont.gcd.org への帰りのパケットが香港経由になってるため」 というコメントを頂いたので、 返りの経路も調べてみた。 確かに、 hkix.net 経由になっていて、 東京-香港間に 50ms ほどかかっている:

senri:/ # traceroute6 -s 2400:400d:100::3c20:55dc fremont.gcd.org
traceroute to fremont.gcd.org (2600:3c01::f03c:91ff:fe96:f285) from 2400:400d:100::3c20:55dc, 30 hops max, 24 byte packets
 1  2001:380:4d:1ff::3 (2001:380:4d:1ff::3)  4.876 ms  3.907 ms  4.369 ms
 2  2001:380:4d:181::1 (2001:380:4d:181::1)  3.104 ms  2.888 ms  3.556 ms
 3  2001:380:4d:100::1 (2001:380:4d:100::1)  5.911 ms  6.002 ms  5.581 ms
 4  2001:380:8270:7::1 (2001:380:8270:7::1)  4.072 ms  4.156 ms  3.969 ms
 5  2001:380:8150:f::18 (2001:380:8150:f::18)  4.622 ms  4.689 ms  4.584 ms
 6  ae-5.r20.tokyjp01.jp.bb.gin.ntt.net (2001:218:0:5000::d)  4.54 ms  4.172 ms  4.577 ms
 7  ae-2.r25.tokyjp01.jp.bb.gin.ntt.net (2001:218:0:2000::1c6)  5.063 ms  4.27 ms  4.511 ms
 8  as-3.r21.newthk02.hk.bb.gin.ntt.net (2001:218:0:2000::13e)  56.208 ms  56.149 ms  55.959 ms
 9  xe-2-1.r01.newthk01.hk.bb.gin.ntt.net (2001:218:0:2000::159)  101.451 ms  57.473 ms  57.487 ms
10  ae-3.a02.newthk01.hk.ra.gin.ntt.net (2001:218:0:6000::156)  56.489 ms  56.368 ms  107.274 ms
11  hurricaneelectric-RGE.hkix.net (2001:7fa:0:1::ca28:a19e)  57.228 ms  57.492 ms  57.619 ms
12  gige-g3-7.core1.lax1.he.net (2001:470:0:16b::1)  174.14 ms  173.967 ms  174.26 ms
13  10gigabitethernet7-4.core1.fmt2.he.net (2001:470:0:18d::1)  180.178 ms  188.238 ms  181.149 ms
14  gige-g4-18.core1.fmt1.he.net (2001:470:0:2d::1)  173.357 ms  173.099 ms  173.85 ms
15  2001:470:1:1db::2 (2001:470:1:1db::2)  173.973 ms  173.424 ms  178.249 ms
16  2600:3c01::f03c:91ff:fe96:f285 (2600:3c01::f03c:91ff:fe96:f285)  174.287 ms  174.162 ms  174.175 ms

8月24日追記:

「fremont.gcd.org と senri.gcd.org 間のIPv6の遅延は改善されたんじゃないか」 というコメントを頂いたので、 再度調べてみた:

senri:/ # traceroute6 -s 2400:400d:100::3c20:55dc fremont.gcd.org
traceroute to fremont.gcd.org (2600:3c01::f03c:91ff:fe96:f285) from 2400:400d:100::3c20:55dc, 30 hops max, 24 byte packets
 1  asao.v6.gcd.org (2400:400d:100::3c20:55dd)  0.239 ms  0.152 ms  0.14 ms
 2  2001:380:4d:1ff::3 (2001:380:4d:1ff::3)  4.61 ms  4.696 ms  3.957 ms
 3  2001:380:4d:181::1 (2001:380:4d:181::1)  3.445 ms  3.73 ms  3.347 ms
 4  2001:380:4d:100::1 (2001:380:4d:100::1)  5.994 ms  5.893 ms  5.813 ms
 5  2001:380:8270:7::1 (2001:380:8270:7::1)  3.727 ms  3.58 ms  3.82 ms
 6  2001:380:8150:f::18 (2001:380:8150:f::18)  4.51 ms  4.119 ms  4.769 ms
 7  ae-5.r20.tokyjp01.jp.bb.gin.ntt.net (2001:218:0:5000::d)  4.353 ms  4.446 ms  4.526 ms
 8  ae-3.r20.osakjp01.jp.bb.gin.ntt.net (2001:218:0:2000::da)  14.744 ms  14.429 ms  14.338 ms
 9  as-2.r20.snjsca04.us.bb.gin.ntt.net (2001:218:0:2000::7d)  122.714 ms  122.792 ms  122.84 ms
10  ae-0.r21.snjsca04.us.bb.gin.ntt.net (2001:418:0:2000::66)  130.233 ms  130.342 ms  176.712 ms
11  10gigabitethernet2-3.core1.sjc2.he.net (2001:504:0:1::6939:1)  132.712 ms  122.997 ms  122.804 ms
12  10gigabitethernet1-1.core1.fmt1.he.net (2001:470:0:2f::1)  132.042 ms  141.087 ms  132.982 ms
13  2001:470:1:1db::2 (2001:470:1:1db::2)  124.032 ms  124.21 ms  124.141 ms
14  2600:3c01::f03c:91ff:fe96:f285 (2600:3c01::f03c:91ff:fe96:f285)  125.249 ms  124.642 ms  125.253 ms

確かに、 ntt.net から直接 he.net へ行く経路に変わっていて、 香港に迂回していた時と比べ、 50ms ほど速くなっている。 1hop目が asao になっているのは、 asao と senri で冗長構成になっていて、 前回は senri が master だったが現在は asao が master に切り替わっているため。

いまどき Web で申し込めないなんて、 と思いつつ 8ページにもわたる申込書 (いつも感じるが OCN の申込書は無駄にページ数が多い *_*) を FAX で送付。 すると翌日電話がかかってきて、 開通日は 10日後などとおっしゃる。 それじゃ World IPv6 Day に間に合わないじゃんと思ったが、 どんな変更でも申込みから 7営業日は最低でもかかるらしいので仕方がない。 なお、 工事費および月額使用料は無料。

OCN には元々月額 315円の 「OCN IPv6」 というサービスがあるが、 OCN IPv6 はフレッツ網に PPPoE によるトンネルを張って IPv4 を通し (OCN フレッツ光)、 その IPv4 上に L2TP (Layer 2 Tunneling Protocol) によるトンネルを張って PPP セッションを通し、 その PPP 上に IPv6 を通すという屋上屋を架す方式だったのに対し、 6月1日から始まった 「IPv6インターネット接続」 はフレッツ網に PPPoE によるトンネルを張って IPv6 を通す方式。

つまり OCN フレッツ光の IPv4 の部分を IPv6 でそのまま置き換えたシンプルな方式。 もちろんフレッツ網に IPv6 を直接通す 「ネイティブ方式」 が一番シンプルだが、 ネイティブ方式に関しては 「平成23年7月を目途に提供を予定」 ということなので、 どのようなサービスが始まるのか今のところ不明 (もう来週には 7月が始まってしまうのだが)。 7/24追記: ネイティブ方式サービスが始まった！

開通日の 2日前に郵便で届いた 「ご利用内容のご案内」 の欄外の注釈に、

IPv6 でインターネットに接続する際、 認証ID の @ 右側を “@bizf.ocn.ne.jp” の場合は “@bizf6.ocn.ne.jp” に、 “@bizd.ocn.ne.jp” の場合は “@bizd6.ocn.ne.jp” に変更してご利用下さい。

と書いてあった。 IPv6 での接続に関する説明はこの部分だけなので、 あとは推測するしかない (サポートに接続方法を聞いても、 単に IPv6トンネル対応ルータを購入してくれと言われる)。

とりあえず、 ふだん IPv4 で接続するときに使ってる PPPoE スクリプト (RP-PPPoE) を、 認証ID を “xxxx@bizf.ocn.ne.jp” から “xxxx@bizf6.ocn.ne.jp” に変更して走らせてみる:

20:39:13 senri pppd[16587]: Plugin /etc/ppp/plugins/rp-pppoe.so loaded.
20:39:13 senri pppd[16587]: RP-PPPoE plugin version 3.10 compiled against pppd 2.4.5
20:39:13 senri pppd[16587]: pppd 2.4.5 started by root, uid 0
20:39:13 senri pppd[16587]: PPP session is 6394 (0x18fa)
20:39:13 senri pppd[16587]: Connected to 00:1e:13:c2:69:c2 via interface eth1
20:39:13 senri pppd[16587]: Using interface ppp0
20:39:13 senri pppd[16587]: Connect: ppp0 <--> eth1
20:39:13 senri pppd[16587]: Couldn't increase MTU to 1500
20:39:13 senri pppd[16587]: Couldn't increase MRU to 1500
20:39:13 senri pppd[16587]: PAP authentication succeeded
20:39:13 senri pppd[16587]: peer from calling number 00:1E:13:C2:69:C2 authorized
20:39:13 senri pppd[16587]: local  LL address fe80::fd61:ff9b:eb97:1f93
20:39:13 senri pppd[16587]: remote LL address fe80::0090:1a00:41a3:d3f3

PPP は 1 つ以上のネットワーク層プロトコルを選択できるので、 IPCP (IP Control Protocol) と IPv6CP (IPv6 Control Protocol) の両方が流れてくるのかと予想したのだが、 流れてきたのは IPv6CP のみだった。 つまり “@bizf.ocn.ne.jp” で IPv4 用、 “@bizf6.ocn.ne.jp” で IPv6 用、 計 2本の PPPoE セッションを張ることになる。

上記ログから分かる通り Link Local とはいえ IPv6 なアドレス fe80::fd61:ff9b:eb97:1f93 が割り振られたのだから、 IPv6 で通信できるはず。 試しに PPP の対向サーバへ ping を打ってみると、 ちゃんと応答が返ってきた:

senri:~ $ ping6 -c 3 fe80::0090:1a00:41a3:d3f3%ppp0↓
PING fe80::90:1a00:41a3:d3f3%ppp0 (fe80::90:1a00:41a3:d3f3%ppp0): 48 data bytes
56 bytes from fe80::90:1a00:41a3:d3f3%ppp0: icmp_seq=0 ttl=255 time=3.936 ms
56 bytes from fe80::90:1a00:41a3:d3f3%ppp0: icmp_seq=1 ttl=255 time=4.050 ms
56 bytes from fe80::90:1a00:41a3:d3f3%ppp0: icmp_seq=2 ttl=255 time=4.176 ms
--- fe80::0090:1a00:41a3:d3f3%ppp0 ping statistics ---
3 packets transmitted, 3 packets received, 0% packet loss
round-trip min/avg/max/stddev = 3.936/4.054/4.176/0.098 ms
senri:~ $ 

じゃ、 Global なアドレス (固定アドレス契約なのでプレフィックスが 「ご利用内容のご案内」 に書かれていた) を付けて routing 設定を行なえば Global に通信できそうと思い、 試してみると...

senri:/ # ifconfig eth0 add 2400:400d:100::1/56↓
senri:/ # ip -6 route add default via fe80::0090:1a00:41a3:d3f3 dev ppp0↓
senri:/ # ping6 www.kame.net↓
PING www.kame.net (2001:200:dff:fff1:216:3eff:feb1:44d7): 48 data bytes
^C--- www.kame.net ping statistics ---
15 packets transmitted, 0 packets received, 100% packet loss
senri:/ # 

う〜ん、ダメか。 tcpdump を使って ppp0 に届く IPv6 パケットを監視してみたが、 OCN へ送信したパケットのみが表示され、 OCN 側からは何のパケットも届かない。

しかも、 他のサイトから 2400:400d:100::1 に対して ping6 を打ってみても何も届かない。 仮にこちらの設定に何か間違いがあったとしても、 OCN 側で 2400:400d:100::1 宛のパケットを routing していれば、 パケット自体は流れてきそうな気がするのだが... 少なくとも IPv4 の場合なら、 こちらの IP アドレス設定が間違っていても、 受け取れないだけでパケット自体は流れてくる。

ひょっとして、 「ご利用内容のご案内」に書かれていた 「2400:400d:100::」 というプレフィックスが間違っているんじゃ? と、 途方に暮れる。

仕方がないので 「次世代ネットワークに関する情報」 で提供されている仕様書にざっと目を通してみる。 すると、 NGN IPv6 ISP接続＜トンネル方式＞UNI仕様書の 7ページに、 IPv6 通信開始までの通信シーケンス図があった:

現在は IPv6CP まで完了している段階だから、 次は DHCPv6-PD Prefix 付与フェーズということになる。 この時まで、 DHCP (Dynamic Host Configuration Protocol) は自動設定のための仕掛けだから、 固定プレフィックスの場合は PD (Prefix Delegation, プレフィックス委譲) してもらうまでもないと思い込んでいた。 少なくとも IPv4 の場合は、 DHCP クライアントを動かさずに勝手に IP アドレスを割当てても通信できる。

OCN 側から一切パケットが流れてこないということは、 プレフィックス委譲してもらわなければ通信できない、 ということになる。 なぜ OCN は、 そんな不便な仕様にしているのか? と疑問に思いつつも、 WIDE-DHCPv6 をインストールして dhcp6c (DHCPv6 クライアント) を実行してみる:

senri:/ # cat /tmp/dhcp6c.conf↓
interface ppp0 {
	send ia-pd 0;
};
id-assoc pd 0{
	prefix-interface eth0 {
		sla-len 0;
	};
};
senri:/ # dhcp6c -c /tmp/dhcp6c.conf ppp0↓

「send ia-pd 0」 が solicit message (要請メッセージ) を OCN のルータ (上記シーケンス図では 「IP通信網」) へ送信するための設定。 「ia-pd」 というのは Identity Association for Prefix Delegation (プレフィックス委譲ID) の意味で、 複数の委譲を行ないたいときにそれぞれを区別するための ID らしいが、 今回は一つだけなのでデフォルトの 0 を指定。

「id-assoc pd 0」 がプレフィックス委譲ID が 0 のもの (今回は一つだけなので 0 しかない) に関する設定で、 「prefix-interface eth0」 と指定することによって、 OCN から委譲されたプレフィックスを eth0 インタフェースに割当てる。

dhcp6c を実行しつつ tcpdump で ppp0 での通信を監視してみると:

senri:/ # tcpdump -i ppp0↓
tcpdump: WARNING: ppp0: no IPv4 address assigned
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on ppp0, link-type LINUX_SLL (Linux cooked), capture size 65535 bytes
23:38:43.826300 IP6 fe80::fd61:ff9b:eb97:1f93.546 > ff02::1:2.547: dhcp6 solicit
23:38:43.831744 IP6 fe80::90:1a00:41a3:d3f3.547 > fe80::fd61:ff9b:eb97:1f93.546: dhcp6 advertise
23:38:44.871958 IP6 fe80::fd61:ff9b:eb97:1f93.546 > ff02::1:2.547: dhcp6 solicit
23:38:44.876597 IP6 fe80::90:1a00:41a3:d3f3.547 > fe80::fd61:ff9b:eb97:1f93.546: dhcp6 advertise

無事、 solicit message が OCN へ送られ、 シーケンス図通り OCN から advertise が返ってきていることが分かる。 IPv6 のアドレスは桁数が多くて目がチラチラする (^^; ので、 こちら側 (シーケンス図では 「端末機器」) のアドレス fe80::fd61:ff9b:eb97:1f93 を緑色で表した。

シーケンス図によると advertise を受け取った後、 端末機器は Request を送らなければならないのだが、 なぜか 1秒待って solicit を再送している。 これが今回唯一のハマったところ。 原因を探るために DHCPv6 の仕組みを一通り調べる羽目になった。

原因は分かってみれば単純で、 単に ip6tables で advertise パケットを落とす設定になっていただけ。 そのため dhcp6c が advertise パケットを受け取れず、 solicit の再送を繰り返していた。 Link Local からの UDP 546番ポート宛のパケットを受け入れるよう設定したら、 無事 DHCPv6-PD のシーケンスも完了して IPv6 通信を開始することができた。

より正確に言えば、元々 「-m conntrack --ctstate ESTABLISHED,RELATED」 などと送信パケットと関連があるパケットは受け入れる設定にしていたが、 DHCPv6 の solicit は ff02::1:2 宛、 つまり全ルーターアドレス宛のマルチキャストであるのに対し、 OCN から返ってくる advertise は (当然) ユニキャストであるため、 関連があるパケットとは見なされず落としてしまっていた。

以下のような ipv6-up / ipv6-down スクリプト (IPv6 接続/切断時に pppd が呼び出すスクリプト) を書いて、 dhcp6c および radvd が自動的に起動/終了するようにした。

#!/bin/sh
PATH=/usr/bin:/usr/sbin:/bin:/sbin
. /etc/rc.d/hostname
command=$0
interface=$1
device=$2
speed=$3
local=$4
remote=$5
ipparam=$6
echo `date "+%F %T"` "$0" "$@" >> /var/log/pppd-ip6.log
case $command in
    *ipv6-up)
	updown="up"
	cat > /var/run/dhcp6c.$interface.conf <<EOF
interface $interface {
	send ia-pd 0;
};
id-assoc pd 0{
	prefix-interface $INNER_DEV {
		sla-len 0;
	};
};
EOF
	dhcp6c -c /var/run/dhcp6c.$interface.conf -p /var/run/dhcp6c.$interface.pid $interface
	;;
    *ipv6-down)
	updown="down"
	if [ -f /var/run/dhcp6c.$interface.pid ]; then
	    kill `cat /var/run/dhcp6c.$interface.pid`
	fi
	;;
    *)
	exit 1
esac
case $ipparam in
    ngn6)
	if [ $updown = "up" ]; then
	    ip -6 addr add 2400:400d:100::1 dev $INNER_DEV
	    ip -6 route add default via $remote dev $interface
	    radvd -C /usr/etc/radvd.conf
	else
	    ip -6 addr del 2400:400d:100::1 dev $INNER_DEV
	    if [ -f /var/run/radvd.pid ]; then
		kill `cat /var/run/radvd.pid`
	    fi
	fi
	;;
    *)
	exit 1
esac

dhcp6c によって自動的に割当てられる IPv6 アドレスの他に、 対外サービス用として 2400:400d:100::1 も割当てるようにしている。

実は、 最初は 「さくらのVPS」 を申し込んだのだが、 rootパスワードが見つからない事件でイカってキャンセルしてしまった。 申し込んだ直後に VPS が起動できたので、 さくら++ と思いつつ root でログインしようとしたらパスワードが分からず Web じゅう探しまわる羽目に。 万策尽きてサポートに電話したら 15分以上待たされ、 しかも担当者には root と言っても話が通じず、 別の番号にかけなおせと言われる始末。 後ほど届いた 「仮登録完了のお知らせ」 メールに root パスワードが書いてあったのだが、 メールが届く前に VPS のコントロールパネルをいじれて、 起動までできてしまう現在の仕様はいかがなものか。

Osukini サーバの場合 OS は CentOS, Ubuntu, Debian から選べるが、 「my distribution」 以外は使う気が起きないので、 どうやって私の 「独自OS」 をインストールするか、 方法を考えてみた。 もちろん、 Osukini サーバのサポートの範囲外なので、 インストールする方法だけでなく、 トラブった時の復旧方法を考えておくことが重要。

Osukini サーバでは 仮想コンソール (hvc console, リモートコンソール) が提供されない。 OS の外部から操作する手段がほとんどなく、 ブートスクリプトの設定ミスなどで OS にリモートログインできなくなってしまったら最後、 OS の再インストールしか復旧手段はない (と思う)。 しかも、 (サポートの範囲外である) 独自OS の再インストールを支援してもらえるはずはないので、 せっかくインストールした独自OS は跡形もなく消えてしまう。

再起動すれば復旧できる一時的な障害はここでは考えない。 設定ファイルなどを不適切な内容に書き換えてしまった結果、 再起動してもリモートログインできない状態が続くケースのみを考える。 実際、 サーバを運用しているとそういうトラブルはよくある。 ネットワーク設定を間違えて通信不能になるだけで、 他は全く正常でもリモートログインはできなくなるし、 あるいは sshd の設定を間違えて sshd が起動しなくなっただけでもリモートログインできなくなる。
ネットワークが全く使えなくても、 sshd が立ち上がらなくなってしまっても、 OS 自体が正常に起動していれば init から起動される getty は生きていることが多いので、 仮想コンソールさえ使えれば、 大抵はログインできて修復できる。

他の VPS, 例えば Linode や prgmr などでは、 仮想コンソールが利用できる。 さらに、 両者とも GRUB が使えるので、 複数 OS をインストールしておいて切り替えて使うこと (いわゆる 「デュアルブート」) ができる。 つまり一つの OS 上で何かトラブルが起きて OS が立ち上げ不能になっても、 別の OS (いわゆるレスキュー用 OS) を立ち上げて、 トラブった OS を修復することができる。

リアルサーバでは、 (仮想ではなく物理的な) コンソールが利用できる (当たり前)。 さらに、 トラブった時はレスキュー用の CD-ROM / USBメモリからブートして復旧作業を行なったりする。 VPS でもリアルサーバでも、 イザというときに備えて、 通常使う OS とは別に、 修復作業を行なうためのレスキュー用の OS を用意しておくことが極めて重要。

ところが、 レスキュー用 OS が一切利用できないばかりか、 仮想コンソールから操作することすらできないのが Osukiniサーバ。 トラブルに対して極めて脆弱であると言わざるを得ない。

VPS にとって仮想コンソールは必須の機能だと思っていたので、 Osukiniサーバのコントロールパネルを見て驚いた。 「再起動」 「停止」 などの操作と、 OS の初期化しかできない (値段相応? でも、 仮想コンソール機能は Xen 標準なのに...)。

OS の初期化をすれば、 全てが消えてしまう。 いわば、 クリーンインストールしかできない CD-ROM からブートするようなもの。 トラブったからといって、 即クリーンインストールしたいという人がどれだけいると言うのか?

嘆いていても仕方がないので、 どうやってレスキュー用 OS 相当のことを実現するか考えてみる。 レスキュー用 OS を立ち上げることさえできれば、 独自 OS をインストールすることも可能になる。 こんなこともあろうかと、 2年前 (2008年10月) に作っておいた ptyd (Pseudo TTY Daemon) が役に立ちそう。

ptyd はリモートログインを可能にする簡易サーバ。 initramfs の中に入れておいて、 リモートからのメンテナンスを実現する目的で作った。 特長はそのサイズで、 わずか 12KB 〜 17KB しかない。 sshd (400KB 以上) あるいは dropbear (100KB 程度) では initramfs に入れるには大きすぎるので作ってみた次第。 今まで (仮想)コンソールが使えない状況に陥ったことがなかったので、 ptyd の出番はほとんどなかったのだが、 Osukiniサーバのおかげで日の目を見ることとなった。

initramfs というのは Linux OS 起動時に、 root ファイルシステムをマウントするために一時的に起動される簡易OS のこと。 マウントしたボリュームの /sbin/init へ処理を引き継いで短い役割を終える。 (昔の Unix を知ってる) 古い人には 「ミニルート」 (mini root) と言った方が通りがよいかも。 initramfs は 2MB 程度と極小であるにも関わらず OS としての機能は一通り備えているので、 「レスキュー用」 として使えなくもない (そもそも昔のレスキュー用ディスクはフロッピーディスク一枚に収まった)。 ptyd があれば、 initramfs がリモートからログイン可能なレスキュー用 OS になるというわけ。

senri:~ $ ls -l ptyd
-rwxr-xr-x 1 sengoku user 17200 Mar  5 09:20 ptyd
senri:~ $ ./ptyd
@(#) $Id: ptyd.c,v 1.2 2011/03/03 10:29:43 hiroaki_sengoku Exp $
Usage: ptyd <opt>.. <prog> <arg>..
opt: -p <port>  ; listen port
     -c <sec>   ; wait <sec> for connection
     -i <sec>   ; <sec> before terminate idle connection
     -a <file>  ; read secret from <file>
     -d <level> ; debug level
senri:~ $ cat /tmp/SEED 
abcdefg
senri:~ $ ./ptyd -p 1234 -a /tmp/SEED /bin/sh

などと ptyd を起動すると、 1234番ポート (-p オプションで指定, デフォルトは 9000番) で listen する。 放っておくと 10秒 (-c オプションで変更可能) でタイムアウトする。 -a オプションは今回追加した機能で、 リモートログインを受付ける際に認証を要求する。 「-a /tmp/SEED」 と指定することによりパスワードを /tmp/SEED から読み込む。

試しにリモートからログインしてみる:

asao:~ $ telnet senri 1234
Trying 192.168.1.15...
Connected to senri.
Escape character is '^]'.
1299285953@1234:

認証方法はチャレンジ&レスポンス方式 (APOP などと同じ)。 プロンプト 「1299285953@1234:」 にパスワード (上記 /tmp/SEED の内容) を追加した文字列の MD5 値を入力すればよい。 例えば /tmp/SEED の内容が 「abcdefg〈改行〉」 であるなら、

asao:~ $ echo '1299285953@1234:abcdefg' | openssl md5
ee5478287007435a75dd875e0e56270a

なので、 「ee5478287007435a75dd875e0e56270a」 を入力する。 認証が成功すると、 ptyd は引数のコマンド (上記の例では /bin/sh) を実行し、 その標準入出力を疑似端末経由 (ptyd の名前の由来) でリモートからアクセスできるようにする。 つまり上記の例だと ptyd を実行したマシン (senri) 上で実行した /bin/sh を、 telnet を実行したマシン (asao) から操作できる。

initramfs の中の /init スクリプトで ptyd を呼ぶようにしておけば、 ブート時にレスキュー用 OS に切り替えることができる。 つまり何かトラブルが起きて (再起動しても) VPS にリモートログインできなくなってしまったとしても、 コントロールパネルで 「再起動」 あるいは 「強制停止」 ボタンを押し、 再起動中に ptyd がタイムアウトするまえにリモートからログインすればよい。 ログインしなければ ptyd がタイムアウト (デフォルトは 10秒) して、 OS が起動する。

具体的には以下のような感じ。 ptyd が listen するタイミングをとらえるために ping を打っておく。 再起動にともなってパケットが途絶えた後 (icmp_seq=6 以降)、 再びパケットが返ってくるようになった (icmp_seq=17 以降) ことを確認してから、 1234番ポートに対して telnet を試みる。

senri:~ $ ping meguro
PING meguro.gcd.org (163.43.176.212): 48 data bytes
56 bytes from 163.43.176.212: icmp_seq=0 ttl=52 time=6.447 ms
56 bytes from 163.43.176.212: icmp_seq=1 ttl=52 time=6.303 ms
56 bytes from 163.43.176.212: icmp_seq=2 ttl=52 time=8.697 ms
56 bytes from 163.43.176.212: icmp_seq=3 ttl=52 time=8.132 ms
56 bytes from 163.43.176.212: icmp_seq=4 ttl=52 time=6.226 ms
56 bytes from 163.43.176.212: icmp_seq=5 ttl=52 time=7.810 ms

56 bytes from 163.43.176.212: icmp_seq=17 ttl=52 time=9.881 ms
56 bytes from 163.43.176.212: icmp_seq=18 ttl=52 time=5.948 ms
  C-c --- meguro.gcd.org ping statistics ---
19 packets transmitted, 8 packets received, 57% packet loss
round-trip min/avg/max/stddev = 5.948/7.431/9.881/1.329 ms
senri:~ $ telnet meguro 1234
Trying 163.43.176.212...
Connected to meguro.
Escape character is '^]'.
1299285953@1234:ee5478287007435a75dd875e0e56270a
# df
Filesystem           1K-blocks      Used Available Use% Mounted on
/dev/xvda3           112292896   6574080 100062332   6% /mnt
# cat /proc/mounts
rootfs / rootfs rw 0 0
none /proc proc rw,relatime 0 0
none /sys sysfs rw,relatime 0 0
none /dev/pts devpts rw,relatime,mode=600,ptmxmode=000 0 0
/dev/xvda3 /mnt ext3 ro,relatime,errors=continue,barrier=0,data=writeback 0 0
# ls --color=never /mnt
bin         home        lost+found  proc        srv         var
boot        initrd.img  media       root        sys         vmlinuz
dev         lib         mnt         sbin        tmp
etc         lib64       opt         selinux     usr

ptyd のプロンプト 「1299285953@1234:」 に対して、 MD5 を算出して正しいレスポンス 「ee5478287007435a75dd875e0e56270a」 を入力することにより無事ログインできた。

「#」 は initramfs の /bin/sh のプロンプト。 通常起動時に root ディレクトリとなるボリューム /dev/xvda3 が /mnt ディレクトリにマウントされている。 このボリュームには、 Osukiniサーバ契約時にインストールしてもらった Debian squeeze がインストールされている。

この Debian を /mnt/mnt/saases ディレクトリ以下に待避:

# mount -oremount,rw null /mnt
# mkdir /mnt/mnt/saases
# cd /mnt
# mv -i [a-i]* lib* media [o-z]* mnt/saases/
# ls --color=never 
lost+found  mnt
# 

この Debian を使う予定はないので、 待避せずに消しちゃってもいいのだが、 まあディスク容量が余ってるのでとりあえず保存しておくということで。

そして、 あらかじめ /mnt/mnt/root にコピーしておいた my distribution 一式を、 /mnt (つまり /dev/xvda3 ボリュームの root ディレクトリ) へ展開:

# cd mnt/root
# ls --color=never -la
drwxr-xr-x   14 0        0            4096 Mar  2 11:27 .
drwxr-xr-x    4 0        0            4096 Mar  4 11:09 ..
lrwxrwxrwx    1 0        0               7 May  3  2008 bin -> usr/bin
drwxr-xr-x    4 0        0            4096 Jan 12 10:03 boot
drwxr-xr-x    2 0        0            4096 Mar  2 10:21 dev
drwxr-xr-x   35 0        0            4096 Mar  1 10:34 etc
drwxr-xr-x    3 0        0            4096 Feb 22 05:59 home
drwxr-xr-x    3 0        0            4096 Dec 12 15:19 lib
lrwxrwxrwx    1 0        0               3 Oct 11  2009 lib64 -> lib
drwxr-xr-x    3 0        0            4096 Mar  2 11:27 mnt
drwxr-xr-x    2 0        0            4096 Mar  2 10:20 proc
drwxr-xr-x    3 0        0            4096 Mar  4 01:09 root
lrwxrwxrwx    1 0        0               8 Oct  9  2009 sbin -> usr/sbin
drwxr-xr-x    2 0        0            4096 Mar  2 10:21 sys
drwxrwxrwt    3 0        0            4096 Mar  4 00:57 tmp
drwxr-xr-x   15 0        0            4096 Feb 28 11:52 usr
drwxr-xr-x   12 0        0            4096 Jan 31 02:01 var
# mv -i * /mnt/
mv: overwrite '/mnt/mnt'? n
# mount -oremount,ro null /mnt
# exit
Connection closed by foreign host.
senri:~ $ 

以上で、 Debian squeeze と、 my distribution との入れ替えが完了。 exit すれば ptyd が終了して、 /initramfs のブートシーケンスが再開し、 my distribution が起動する。

senri:~ $ ssh meguro
Last login: Sat Mar  5 22:41:49 2011 from gcd.org
Linux 2.6.35.11-x86_64.
meguro:~ $ df
Filesystem           1K-blocks      Used Available Use% Mounted on
rootfs               112292896  21192732  85443680  20% /
/dev/xvda3           112292896  21192732  85443680  20% /
none                    511188        20    511168   1% /dev
none                    511188         0    511188   0% /dev/shm
/dev/xvda3           112292896  21192732  85443680  20% /usr/bin/.suid
/dev/xvda3           112292896  21192732  85443680  20% /var/root/usr/bin/.suid
meguro:~ $ free
             total       used       free     shared    buffers     cached
Mem:       1022380    1005408      16972          0     195024     235496
-/+ buffers/cache:     574888     447492
Swap:      2104508        572    2103936
meguro:~ $

広〜い (^^)。 これが月額 980円なのだからスゴイ。

prgmr.com ならば、 RAM 512MB, ディスク 12GB が月額 $12 (年一括払いなら $115.2) で済むので乗り換えてみた。 Linode のようなユーザフレンドリーな Web ユーザインタフェースは無いし、 時々新規申込みの受付を中止したりする (今も RAM 1024MB 以上のプランは受付けていない) が、 逆に言えば Web インタフェースが不要な人 (含む私) にとっては prgmr.com のシンプルさがむしろ望ましく、 レスキュー用のブートイメージなど必要最低限のものは揃っているので、 不便と感じることはない。 また、 いったん申込みが完了してしまえば受付の一時停止は関係ないわけで、 むしろサーバリソースに見合ったユーザ数しか受付けない姿勢は好感が持てる。

Web から Signup すると、 以下のようなメールが届く。

you ordered a xen vps, 512MiB ram, 12GiB Disk 80 GiB transfer Xen VPS,  $12/month username sengoku 

Before I can set you up, I need to know what distro you would like and an OpenSSH format public key (on a *NIX, run ssh-keygen  and send me either the id_dsa.pub or id_rsa.pub file in an attachment)    

on putty/windows, see

http://www.unixwiz.net/techtips/putty-openssh.html#keypair

and scroll down to the screen shot where it says 'openssh format public key for pasting into authorized_keys' - that is what I need.

thanks. 

OpenSSH の公開鍵くらい Web から登録させればいいのにと思いつつ、 「I need to know what distro you would like」 などと聞いてくるということは多少の融通は聞くのかと思い、 パーティションの切り方をついでにリクエストしてみた (6/4 15:46)。 つまり、 自分で作った Linux distro (配布していないから 「distribution」 と呼ぶのは正確性に欠けるのだが、 それなら何て呼んだらいいのだろう?) をインストールしたいから、 最小のパーティション (例えば 2GB) に ubuntu をインストールしておいてもらえるか？ などとリクエストしてみた:

Hi,

At Fri, 04 Jun 2010 05:48:05 +0000,
support@prgmr.com wrote:

> Before I can set you up, I need to know what distro you would like and
> an OpenSSH format public key (on a *NIX, run ssh-keygen and send me
> either the id_dsa.pub or id_rsa.pub file in an attachment)

I'd like to use my own linux-based image that is running on
fremont.gcd.org (linode) now.  Is it possible to make two partitions
(plus swap partition) ?  One is for a normal ubuntu, and the other is
for my own image.  I'd like to switch these two OSs by pv-grub.

Please minimize the ubuntu partition in order to maximize my own image.
For example, 2GiB for ubuntu, 1GiB for swap, and 9GiB for me.

I've attached my public key id_dsa.pub at the end of this mail.


#9860.
http://www.gcd.org/sengoku/		Hiroaki Sengoku <sengoku@gcd.org>

すると、 4日後の 6/8 09:03 に返事が来た。 リクエストはあっさり無視されて、 ディスク一杯に ubuntu をインストールした状態の VPS が提供されただけ。 個別対応しないのであれば、 自動化したほうがいいような。

Your vps is setup now, your host server is whetstone.prgmr.com.
Login with your username and ssh key and follow the instructions
at http://book.xen.prgmr.com/mediawiki/index.php/Quickstart
For more information about repartitioning, see
http://book.xen.prgmr.com/mediawiki/index.php/Repartition
The default root password for the vps is password, and you
should receive a bill soon by email. If you have any questions
please email support@prgmr.com. Thanks very much.
Nick Schmalenberger

言われた通り ssh でログインしてみる:

senri:/home/sengoku % ssh whetstone.prgmr.com
The authenticity of host 'whetstone.prgmr.com (65.49.73.105)' can't be established.
RSA key fingerprint is 97:52:07:d4:52:8d:c0:cc:13:c7:fb:5d:5d:1b:ab:b4.
Are you sure you want to continue connecting (yes/no)? yes
Warning: Permanently added 'whetstone.prgmr.com,65.49.73.105' (RSA) to the list
of known hosts.
Name                                        ID   Mem VCPUs      State   Time(s)
sengoku                                    xxx   512     1     -b----     11.5

Options for sengoku
1. console
2. create/start
3. shutdown
4. destroy/hard shutdown
5. reboot
6. swap i386/amd64 bootloaders (pvgrub)
7. exit
press the number> 

「6. swap i386/amd64 bootloaders (pvgrub)」 が目を引くが、 PV-GRUB は DomainU 側で実行されるので、 PV-GRUB にて 32bit/64bit の両方のカーネルを立ち上げることができず、 PV-GRUB を実行する前にどちらか一方に決めておく必要がある、 ということのようだ。 デフォルトは (残念なことに) 32bit になっていて、 セットアップしてもらった ubuntu も 32bit 版だった。

「1」 を入力して VPS のコンソールを表示させてみる:

press the number> 1

Ubuntu 10.04 LTS sengoku.xen.prgmr.com hvc0

sengoku.xen.prgmr.com login: root
Password:
Last login: Mon May 31 23:51:42 UTC 2010 on hvc0
Linux sengoku.xen.prgmr.com 2.6.32-22-generic-pae #33-Ubuntu SMP Wed Apr 28 14:57:29 UTC 2010 i686 GNU/Linux
Ubuntu 10.04 LTS

Welcome to Ubuntu!
 * Documentation:  https://help.ubuntu.com/
root@sengoku:~# df
Filesystem           1K-blocks      Used Available Use% Mounted on
/dev/xvda1            11812024   1068124  10143876  10% /
none                    249488       136    249352   1% /dev
none                    253744         0    253744   0% /dev/shm
none                    253744        28    253716   1% /var/run
none                    253744         0    253744   0% /var/lock
none                    253744         0    253744   0% /lib/init/rw
none                  11812024   1068124  10143876  10% /var/lib/ureadahead/debugfs
root@sengoku:~# 

前掲のメールに書いてあった通り、 ユーザ 「root」 パスワード 「password」 でログインできた。 初めてログインしたのに 「Last login: Mon May 31 23:51:42 UTC 2010 on hvc0」 などと出ているが、 この ubuntu イメージを作ったとき試しに root でログインしたのが残ってしまったのだと思われる。 新規ユーザのセットアップのたびに、 5/31 に作ったイメージを使いまわしているのだろう。

ディスク 12GB のプランのはずなのに 1GB ほど足りないのは swap パーティションがあるから？と思い、 fdisk で確認してみる:

root@sengoku:~# fdisk -l /dev/xvda

Disk /dev/xvda: 12.8 GB, 12884901888 bytes
255 heads, 63 sectors/track, 1566 cylinders
Units = cylinders of 16065 * 512 = 8225280 bytes

    Device Boot      Start         End      Blocks   Id  System
/dev/xvda1               1        1494    12000523+  83  Linux
root@sengoku:~# 

シリンダの最大値は 1566 なので、 72 (=1566-1494) シリンダが使われずに余っている。 試しにパーティションを割当ててみたら普通に使えた。

自前 distro 10GB, swap 1GB, ubuntu 1GB といった切り分けかたにするため、 レスキュー用のカーネル 「CentOS 5.5 rescue」 をブートしてみる:

    GNU GRUB  version 0.97  (65536K lower / 0K upper memory)

 +-------------------------------------------------------------------------+
 | user bootloader configuration                                           |  
 | CentOS 5.5 rescue (2.6.18-194.3.1.el5xen)                               |
 | CentOS 5.5 installer                                                    |
 | NetBSD 5.0.2 installer                                                  |
 | Ubuntu 10.04 LTS installer                                              |
 |                                                                         |
 |                                                                         |
 |                                                                         |
 |                                                                         |
 |                                                                         |
 |                                                                         |
 |                                                                         |  
 +-------------------------------------------------------------------------+
    Use the ^ and v keys to select which entry is highlighted.
    Press enter to boot the selected OS, 'e' to edit the
    commands before booting, or 'c' for a command-line.

二行目の 「CentOS 5.5 rescue (2.6.18-194.3.1.el5xen)」 を選択してブート。 root でログイン (パスワードは無し) して fdisk を使ってパーティションを切り直した。 せっかくセットアップしてもらった Ubuntu も、 3分と使わずにお別れ。

CentOS release 5.5 (Final)
Kernel 2.6.18-194.3.1.el5xen on an x86_64

sengoku.xen.prgmr.com login: root
[root@sengoku ~]# 
	...
[root@sengoku ~]# fdisk -l /dev/xvda

Disk /dev/xvda: 12.8 GB, 12884901888 bytes
255 heads, 63 sectors/track, 1566 cylinders
Units = cylinders of 16065 * 512 = 8225280 bytes

    Device Boot      Start         End      Blocks   Id  System
/dev/xvda1               1        1306    10490413+  83  Linux
/dev/xvda2            1307        1438     1060290   82  Linux swap / Solaris
/dev/xvda3            1439        1566     1028160   83  Linux
[root@sengoku ~]# mount /dev/xvda1 /mnt
[root@sengoku ~]# 

私は個人で管理している Linux マシン (自宅と職場と VPS 合わせて十数台, もちろん商用サービスを行なっているサーバではない) のディスクの内容を、 コマンド一発で同一に保てるようにしている (つまりマスタで変更/追加/削除したファイルを各マシンへコピー/各マシンで削除)。

もちろん、 各マシンの性能や 32bit/64bit などの CPU 種別、 ディスクの容量に応じて違う部分もあるわけで、 この同期コマンドは同期先の各マシンに合わせてコピーしないファイルのリストを生成した上で rsync を実行している。 なので、 新しくマシンを増やすときもマスタ上で同期コマンドを実行するだけで、 インストールが完了するはずだが...

senri.gcd.org:/ # mirror -v -r /mnt 'core64[sengoku.xen.prgmr.com]'
BEGIN core64[sengoku.xen.prgmr.com] Tue Jun  8 13:59:14 JST 2010
type: core64
target: sengoku.xen.prgmr.com
rsync --relative -a --numeric-ids --delete -v /bin /etc /lib /sbin /boot /lib64 /usr32 sengoku.xen.prgmr.com:/mnt/
bash: rsync: command not found
rsync: connection unexpectedly closed (0 bytes received so far) [sender]
rsync error: remote command not found (code 127) at io.c(600) [sender=3.0.6]
senri.gcd.org:/ # 

ありゃ、レスキュー用のディスクには rsync がインストールされていないのか...

レスキュー用のディスクは (当然) 書き込みができないので、 rsync をインストールするのも (tmpfs をマウントすれば可能だが) 面倒。 そこで先に /dev/xvda3 パーティション (1GB) に ubuntu をインストールすることにする。 幸い /dev/xvdf で CentOS, Debian, Ubuntu, NetBSD それぞれのディスクを tar+gzip で固めたもの (tar ball) が提供されているので、 64bit 版 ubuntu と思われる ubuntu64.tar.gz を /dev/xvda3 へ展開:

[root@sengoku ~]# mkdir /tmp/xvdf
[root@sengoku ~]# mount /dev/xvdf /tmp/xvdf
mount: block device /dev/xvdf is write-protected, mounting read-only
[root@sengoku ~]# ls -ln /tmp/xvdf
total 1295052
-rw-r--r-- 1 500 500 242130294 May 17 18:10 centos32.tar.gz
-rw-r--r-- 1 500 500 264319597 May 17 16:25 centos64.tar.gz
-rw-r--r-- 1   0   0 184512292 Jun  3 23:30 debian32.tar.gz
-rw-r--r-- 1   0   0 185773340 Jun  3 11:35 debian64.tar.gz
drwx------ 2   0   0     16384 May 24 04:08 lost+found
-rw-r--r-- 1 500 500   4999925 Feb 28 00:46 netbsd64.tar.gz
-rw-r--r-- 1   0   0 219621325 Jun  3 11:30 ubuntu32.tar.gz
-rw-r--r-- 1   0   0 223411583 Jun  3 11:30 ubuntu64.tar.gz
[root@sengoku ~]# mkdir /tmp/xvda3
[root@sengoku ~]# mount /dev/xvda3 /tmp/xvda3
[root@sengoku ~]# tar xzf /tmp/xvdf/ubuntu64.tar.gz -C /tmp/xvda3
[root@sengoku ~]# vi /tmp/xvda3/boot/grub/menu.lst

この tar ball は /dev/xvda1 に展開することを想定しているらしく、 /boot/grub/menu.lst に (hd0,0) と書いてあるので全て (hd0,2) に置換。 /dev/xvda1 にも /boot/grub/menu.lst を置いて以下の行を追加し、 /dev/xvda3 の menu.lst も起動できるようにしておく。

title  Ubuntu
root (hd0,2)
configfile /boot/grub/menu.lst

前述した 「swap i386/amd64 bootloaders (pvgrub)」 を選択して PV-GRUB を 64bit に切り替えておいて、 このインストールしたばかりの Ubuntu を立ち上げる。 そして前述した mirror コマンドをマスタで実行すれば、 /dev/xvda1 への自前 distro のインストールが完了する。

もちろん、 ホスト名などの設定ファイルや /etc/fstab など各マシンで固有のファイル、 /var/log, /tmp などのディレクトリは mirror コマンドではコピー対象外だが、 これらのファイルやディレクトリが存在しない場合は、 ブートスクリプトにおいて勝手に生成する仕掛けになっている。

Using a kernel.org kernel under xen に書かれているように、 Linux カーネルを Xen のゲスト OS として動かすには Paravirtualized guest support (CONFIG_PARAVIRT_GUEST) を有効にしておく必要がある。
また、xen_blkfront.ko (CONFIG_XEN_BLKDEV_FRONTEND) と xen_netfront.ko (CONFIG_XEN_NETDEV_FRONTEND) の両モジュールも必要。 もちろんカーネルに組み込んでおいてもいいが、 私は実サーバと仮想サーバの両方で同じカーネルを使いたいので、 モジュールにしている。

これで /dev/xvda1 からブートすれば、 使いなれた自前 distro 環境が立ち上がるはず...

root (hd0,0)
 Filesystem type is ext2fs, partition type 0x83
kernel /boot/linuz-2.6.31.13-x86_64 root=/dev/xvda1
initrd /boot/initz-2.6.31.13-x86_64

ERROR Invalid kernel: xc_dom_probe_bzimage_kernel unable to LZMA decompress kernel

xc_dom_bzimageloader.c:393: panic: xc_dom_probe_bzimage_kernel unable to LZMA decompress kernel
ERROR Invalid kernel: xc_dom_find_loader: no loader found

xc_dom_core.c:517: panic: xc_dom_find_loader: no loader found
xc_dom_parse_image returned -1

Error 9: Unknown boot failure

Press any key to continue...

うっ、 LZMA 圧縮したカーネル (CONFIG_KERNEL_LZMA) には対応していないのか。 Linode の場合は非圧縮のカーネルのみブートできたのだが、 prgmr.com の場合は gzip 圧縮したカーネル (CONFIG_KERNEL_GZIP) のみブートできるようだ。 VPS ごとに起動できるカーネルの種類が異なっていて面倒。

gzip 圧縮したカーネル 「linuz-2.6.31.13-gz-x86_64」 を用意して再度挑戦:

root (hd0,0)
 Filesystem type is ext2fs, partition type 0x83
kernel /boot/linuz-2.6.31.13-gz-x86_64 root=/dev/xvda1
initrd /boot/initz-2.6.31.13-x86_64

close blk: backend at /local/domain/0/backend/vbd/xxx/51712
close blk: backend at /local/domain/0/backend/vbd/xxx/51776
close blk: backend at /local/domain/0/backend/vbd/xxx/51792
[    0.000000] Initializing cgroup subsys cpuset
[    0.000000] Initializing cgroup subsys cpu
[    0.000000] Linux version 2.6.31.13-x86_64 (sengoku@senri.gcd.org) (gcc version 4.3.4 (GCC) ) #1 SMP Tue Apr 13 17:48:44 JST 2010
[    0.000000] Command line: root=/dev/xvda1
	...
[    0.003333] installing Xen timer for CPU 0
[    0.003333] Calibrating delay loop (skipped), value calculated using timer frequency.. 4003.20 BogoMIPS (lpj=6669120)
	...

Welcome to Linux 2.6.31.13-x86_64.

none.gcd.org login:

無事ブートした。

あとは Linode の時と同様に、 自宅サーバ gw.gcd.org との間にトンネルを設置したり、 gw.gcd.org 上の MySQL から VPS 上の MySQL に対してレプリケーションを行なうようにしたり、 MyDNS を動かしたり、 ns4.gcd.org を 65.49.73.116 へ向けたり、 等々...

最後に、 www.gcd.org の IP アドレスとして VPS の IP アドレス 65.49.73.116 を追加した。

すなわち、 いま読者の皆さんが読んでるこのページは、 1/2 の確率で prgmr.com の VPS が送信したページということになる。 すでに一週間近くこの状態を続けているが、 Linode 360 のときよりはメモリに余裕がある:

prgmr:/home/sengoku % free
             total       used       free     shared    buffers     cached
Mem:        534796     501456      33340          0      35568     114452
-/+ buffers/cache:     351436     183360
Swap:      1060280        556    1059724

つまりサーバをリモートから (ネットワーク経由で ssh ログインして) いじっていると、 ちょっとしたミスで操作不能に陥ってしまうことがある。 例えば NIC を down してしまった、 iptables で DROP する設定にしてしまった、 sshd を殺してしまった、 等々。 あるいは、 リモートから再起動を行なう場合、 起動スクリプトのほんの些細な設定ミスで、 リモートからは操作不能になってしまう。

こんなとき、 2台のサーバのシリアルポート同士を RS-232C クロスケーブル (シリアルケーブル) で接続しておけば、 生きている方のサーバからシリアルケーブル経由でログインできて、 リモートからは操作不能に陥ったサーバのネットワーク設定を修復したり、 sshd を起動し直したり、 あるいは再起動の場合であれば、 GRUB を操作することができる (ML115 などであれば BIOS 設定までいじれる)。

職場のサーバ群は、 もちろん IPMI を利用していて大抵の操作は IPMI でできてしまうのでシリアルケーブルの出番はあまりないのだが、 それでもやはり最後の命綱がある安心感は何ものにも代えがたい。 しかも数百円のケーブル一本で済むのだから、 掛けておくべき保険だろう。

シリアルケーブル経由でサーバにログインするには、 そのサーバの /dev/ttyS0 (シリアルポート COM1 の場合) で getty を動かしておく必要がある。 例えば GCD の場合 mgetty を使っているので、 /etc/inittab に

# Dialin lines
s0:25:respawn:/usr/sbin/mgetty ttyS0

などと設定している。 シリアルケーブルでつながった 2台の Linux サーバ senri と asao において、 asao から senri へシリアルケーブル経由でアクセスすると、 senri のシリアルコンソールが表示される:

asao:/home/sengoku % cu ttyS0
Connected.

Welcome to Linux 2.6.31.13-x86_64.


senri.gcd.org!login: root
otp-md5 299 se5047 ext
Response or Password:
Last login: (null) on /dev/ttyS0

senri.gcd.org:/root # tty
/dev/ttyS0
senri.gcd.org:/root # 

たとえ senri のネットワーク機能が全滅していたとしても、 mgetty は /sbin/init から直接起動されるので影響を受けない。 シリアルコンソールから root でログインして復旧作業を行なうことができる。 逆に、 asao のネットワーク機能が全滅したときは、 senri へ ssh ログインした上で asao へシリアルケーブル経由でアクセスすればよい。 ネットワーク機能が麻痺する可能性があるような危険な作業を senri と asao の両方で同時に行なったりしないようにすれば、 何が起きてもどちらかは生きていることが保証できる。

さて、 両サーバで mgetty が動いているときは以上で問題無いのだが、 どちらかのサーバを再起動するときなど、 mgetty 以外のものが動くときは状況が変わってくる。

例えば asao を再起動すると、 まず GRUB2 が動く。

以前は GRUB Legacy を使っていたのだが、 ハードディスクを入れ替えたとき (数年ごとに 2〜3倍の容量のハードディスクと交換している) 勢い余って root パーティションまで ext4 にしてしまい、 GRUB Legacy だと ext4 をサポートしていないことに気付き、 慌てて GRUB2 をインストールした。

GRUB2 では、 /boot/grub/grub.cfg に

serial --unit=0 --speed=115200 --word=8 --parity=no --stop=1
terminal_input serial console
terminal_output serial console

などと設定しておくことにより、 VGA コンソール (/dev/tty1) とシリアルコンソール (/dev/ttyS0) の両方で GRUB の操作 (つまり起動するパーティション/カーネルを選択する等) を行なうことができる。 つまり VGA コンソールで操作しているときも、 同じ画面がシリアルコンソールでも出力され、 途中からシリアルコンソールで操作することも可能。

GRUB Legacy では、 最初にキー入力があった側のコンソールでの操作が有効になる仕様だった。 最初に VGA コンソール (つまり PC に直接接続された PS/2 or USB キーボード) からキー入力を行なえば、 以後キーボードからの操作が有効になり、 最初にシリアルコンソールからキー入力を行なえば、 以後シリアルケーブル経由の操作が有効になる。

一見 GRUB2 の仕様のほうが便利のように見えるが、 二つの Linux サーバをシリアルケーブルでつないでいると、 GRUB2 の仕様は少し困る。 つまり以下のような GRUB2 のメニュー画面が常にシリアルケーブルへも出力されてしまい、 それが相手サーバの mgetty への入力として扱われてしまうので、 mgetty が余計な動きをする。

                             GNU GRUB  version 1.97

 +--------------------------------------------------------------------------+
 |GNU/Linux 2.6.31.13-x86_64                                                |
 |GNU/Linux 2.6.31.13-i386                                                  |
 |GNU/Linux 2.6.31.12-x86_64                                                |
 |GNU/Linux 2.6.31.12-i386                                                  |
 |GNU/Linux 2.6.31.11-x86_64                                                |
 |GNU/Linux 2.6.31.11-i386                                                  |
 |GNU/Linux 2.6.30.9-x86_64                                                 |
 |GNU/Linux 2.6.30.9-i386                                                   |
 |GNU/Linux 2.6.27.34-x86_64                                                |
 |GNU/Linux 2.6.27.34-i386                                                  |
 |Memtest86+                                                                |
 +--------------------------------------------------------------------------+

      Use the ^ and v keys to select which entry is highlighted.
      Press enter to boot the selected OS, 'e' to edit the commands before
      booting or 'c' for a command-line.

すなわち mgetty は何かキー入力があると、 前述したような 「Welcome to Linux ...」 メッセージとログインプロンプト 「senri.gcd.org!login: 」 を出力する。 この出力がそのまま相手サーバの GRUB2 への入力として扱われてしまう。

つまり 「Welcome to Linux ...」 メッセージは前と後ろに 「改行コード」 が出力されるので、 GRUB2 へ改行が入力されてしまう (改行コード以外のアルファベットが GRUB2 によってコマンドとして認識されると、 もっと面倒なことになる)。 すなわち VGA コンソールに表示された GRUB2 メニューにおいて、 どの OS を起動しようか選ぼうとする間もなく、 改行キーが (シリアルコンソールから) 入力されたことになってしまってデフォルトの OS が勝手に起動してしまう。

一方、 GRUB Legacy の場合は、 何かキー入力があるまでシリアルケーブル側へは何も出力されない (正確に言うと 「Press any key to continue.」 というメッセージのみ出力される)。 相手サーバの mgetty が何か出力すると破綻してしまうが、 以下のような簡単なパッチを GRUB Legacy にあてることにより、 「any key」 ではなく mgetty が出力しないコードを入力したときのみ シリアルコンソールへ切り替えるようにできる。 以下のパッチでは ^G (コントロールキーを押しながら G) をシリアルコンソールで入力したときのみ、 GRUB Legacy のメニュー画面がシリアルコンソールに表示されるようにしている。

diff -ur grub-0.97.org/stage2/builtins.c grub-0.97/stage2/builtins.c
--- grub-0.97.org/stage2/builtins.c	2005-02-16 06:58:23.000000000 +0900
+++ grub-0.97/stage2/builtins.c	2009-04-06 13:31:02.288106510 +0900
@@ -4208,10 +4208,13 @@
 		{
 		  if (term_table[i].checkkey () >= 0)
 		    {
-		      (void) term_table[i].getkey ();
-		      default_term = i;
-		      
-		      goto end;
+                      int term_key_code;
+                      term_key_code = term_table[i].getkey();
+		      if( ( (char)term_key_code ) == 7 )
+                      {
+		      	default_term = i;
+		      	goto end;
+                      }
 		    }
 		}
 	    }
@@ -4227,7 +4230,7 @@
 		    if (term_bitmap & (1 << i))
 		      {
 			current_term = term_table + i;
-			grub_printf ("\rPress any key to continue.\n");
+			grub_printf ("\rPress Ctrl+G key to continue.\n");
 		      }
 		  
 		  /* Restore CURRENT_TERM.  */

GRUB2 でも同様のパッチを作ろうと思ったのだが、 GRUB2 は GRUB Legacy と違って、 シリアルと VGA を切り替える仕組みにはなっておらず、 GRUB Legacy の時のような一行パッチでは済みそうにない。

また、 GRUB2 はまだ開発途上ということもあり、 バージョンが上がるたびにパッチを作るのも大変そうである。 GRUB2 以外のブートローダに乗り換える可能性もあるかもしれない。 一方 mgetty は既に枯れたソフトウェアと言ってよい。 そこで mgetty にパッチをあてて、 mgetty が 「Welcome to Linux ...」 メッセージとログインプロンプトを出力するのを抑制することにした。 mgetty が寡黙になりさえすれば、 相手サーバで GRUB2 だろうがその他のブートローダだろうが、 何が動いていても問題は起きない。

シリアルコンソールから ^G を入力したときのみ、 mgetty が 「Welcome to Linux ...」 メッセージとログインプロンプトを出力し、 ^G が入力されない限りは何も出力しないようにするパッチを作ってみた:

--- mgetty.c.org	2006-01-02 02:13:18.000000000 +0900
+++ mgetty.c	2010-04-17 14:20:54.149714734 +0900
@@ -706,6 +706,11 @@
 	       
 	    if ( c_bool(direct_line) )			/* no RING needed */
 	    {
+		char ch;
+		signal(SIGALRM, sig_goodbye);
+		alarm(ring_chat_timeout);
+		int r = mdm_read_byte(STDIN, &ch);
+		if (r <= 0 || ch != 0x07) break;	/* ^G */
 		mg_get_ctty( STDIN, devname );		/* get controll.tty */
 		mgetty_state = St_get_login;
 		break;

このパッチにより、 ^G が入力された時 (ch != 0x07 が不成立) のみ状態 「St_get_login」 へ遷移する。 つまりシリアルコンソールへログインプロンプトを出力する。 ^G 以外が入力されると、 上記パッチ中の if 文の条件が成立し、 状態変数 mgetty_state が更新されず、 状態 「St_wait_for_RINGs」 に留まる。 つまり何も出力されない。

蛇足だが、 状態 「St_wait_for_RINGs」 というのは、 mgetty がモデムからの 「RING」 送信を待っている状態。 モデムに (公衆回線から) 着呼要求が届いたとき (いわゆる電話機が鳴ってる状態)、 モデムは RS-232C 経由で PC に対して 「RING」 を一定間隔で送信する。 mgetty は RING の回数を数えて指定回数を超えれば、 「ATA」 コマンドをモデムに送信して着呼する (いわゆる受話器を取った状態)。

短時間とはいえブログが見えないようなことがあると、 たまたまそのタイミングで (検索エンジン等で見つけて) 訪れた人が、 ブログが既に閉鎖してしまったものと勘違いしてしまうかもしれない。 ここは一つ自宅以外の場所にもサーバを立てて、 回線断の影響を受けないようにしたいところ。 海外のサーバなら地域分散もできてなおよい。

道楽で運営している自宅サーバにそこまで可用性を求めるのは、 やりすぎの感もあるが、 近頃流行りの VPS (Virtual Private Server, 仮想専有サーバ) は、 月額 $20 (初期費用無し) 程度で利用できるらしい。 $20 なら試しに使ってみるのも悪くない。

VPSLink 以外は最安のプランで比較した。 VPSLink には、 メモリ 64MB で月額 $7.95 の Link-1 プラン、 メモリ 128MB で月額 $13.95 の Link-2 プランもあるが、 256MB 未満のメモリではできることも限られてしまうので比較対象から外した。

月額基本料だけを比較すると、 ServerAxis が格安に見えるが、 これは帯域課金が含まれていないためで、 例えば 100GB (送受信の合計バイト数) 使うと $5 加算されて $20 と他社並になる。

データセンタの場所 (というかネットワーク上での位置) によって遅延時間が変わってくるので、 どこのデータセンタを使っているかも重要。 例えば同じ Linode でもデータセンタによって、 日本からアクセスしたときの RTT (Round Trip Time, 往復にかかる時間, ミリ秒) が倍以上変わってくる。 それぞれ 10回ずつ ping を打って、 RTT の最小/平均/最大を比較してみる:

米国西海岸だと RTT は 130msec 程度で済むが、 東海岸は 200msec を超えてしまい、 英国はもっと遠い。 西海岸にデータセンタがあるのは Linode と VPSLink だが、 Linode がデータセンタの情報を詳細に公開しているのに対し、 VPSLink は、 Spry Hosting のシアトルのデータセンタを使用している、 ということ以上の情報を公開していない (しかもこのページは 2006年8月の内容のまま) のが少し気になる。

サポートしている Linux ディストリビューションは、 各社だいたい共通で、 CentOS, Debian, Gentoo, Ubuntu の各バージョンが利用できるが、 VPSLink Ubuntu Plan のページに Ubuntu 9.10 Karmic が書かれていない点も、 ちょっと気になった (ちゃんとポリシーを持って 9.10 をサポートしないのならいいのだが、 どうもそうではなく単に運用の手を抜いているだけのような気配がする)。 Web 界隈での評判も Linode のほうがよさげだったので、 Linode を使ってみることに決めた。

サポートしているディストリビューションのバージョンが古くてもアップグレードできるのだろうが、 帯域で課金されるので最初から新しいバージョンをインストールできる方が好ましい。

おそらく各社ともカーネルも入れ替えることができるのだと思うが、 Linode 以外は使っていないので未確認。 Linode の場合は pv_ops (paravirtualization) を有効にしておけば任意のカーネルを利用できる。 したがって (帯域課金さえ気にしなければ ;-) 任意のディストリビューションの利用 (あるいは完全なカスタマイズ) が可能 (私はまだそこまではやっていない)。

なお、VPS サービスは探すといろいろあるようだ。 前述した 4社と比べると公開している情報が不十分 (特に Virtuozzo/OpenVZ な VPS は実際のパフォーマンスを予想しにくく、 実地に使ってみないとなんとも...) なので私は比較検討対象から外したが、 ダメ元で使ってみるのも面白いかもしれない:

と、いうわけで、 Linode 360 を契約してみた。

Linode のページで、 Linode 360 プランを選んで 「Sign Up Now!」をクリック。 氏名、住所、クレジットカード番号を入力し、 月々払い (Month to month) を選んで申し込むと、 $9.27 の注文書が表示された。 最初の月は月割りで月末までの分を注文するということのようだ (ということは短期間試してみたいときは月末近くに申し込めばよい?)。

米ドル支払いなので、 私が米国に滞在するとき使っている米銀のデビットカード (SSN がないとクレジットカードを発行してもらうのは難しい) を試しに使ってみたら、 何の問題もなく普通に使えた (もちろんクレジットカードならどこの国のカードでも普通に使えるはず)。 日本のデビットカード (J-Debit) はキャッシュカードなので取扱店でしか使えず、 J-Debit が使える店の大半はクレジットカードも使えるので、 J-Debit を使うのは家電量販店くらいのものだが、 米国のデビットカードは (決裁までの期間が短い点以外は) クレジットカードと同等なので便利。

2/17 13:18 に「Complete Order」 ボタンを押して注文を確定すると、 「Payment Receipt」 がメールで届き、 1分後に 「Linode Account Activation」 メールが届いた (13:19)。

そのメールに書いてあった Member's area にログインすると、 データセンタの選択画面が表示されたので、 迷わず米国西海岸の Fremont, CA を選ぶ。 パーティションの設定をして、 インストールするディストリビューションとして 「Ubuntu 9.10 64bit」 を選び、 root のパスワードの設定すると、 インストールが始まって 25秒ほどで完了 (13:22)。

注文してからここまで約5分。

ステータス表示が 「Powered Off」 になっているので、 「Boot」 ボタンを押す (13:29) と 8秒で起動が完了し、 ステータス表示が 「Running」 になった。 試しに手元の PC から ssh でログインしてみる (13:31)。 先ほど設定した root のパスワードを入力すると、 無事ログインできた。

注文してからここまで 15分かかっていない。
あっけないほど簡単に VPS が使える状態になった。

次に、 ssh 公開鍵を設定して鍵認証で ssh ログインできることを確認した上で、 sshd_config を修正して sshd に HUP シグナルを送って、 パスワード認証ではログイン出来ないように設定。 続いて、 csh, tcsh, emacs, screen, stone, dbndns, daemontools, apache2, php5, mysql-server, mysql-client, php5-mysql などを apt-get で次々インストールしていく。 実は stone を apt-get で入れたのは初めての経験。 ちゃんと最新版 stone 2.3e がインストールされてちょっと感動 (*^_^*)。 ありがとうございます ＞ 北目さま。

最後に chsh コマンドでシェルを /bin/csh (私の愛用シェルは今でも csh ^^;) に変更して、 私のホームディレクトリの環境一式を手元の PC から rsync で送り込んで、 emacs を起動すれば、 私の作業環境一式が VPS 上でも使えるようになる。

注文してからここまで 1時間かかっていない。

Linode では逆引きを設定させてくれるので、 私の VPS の IP アドレス 74.207.241.21 の逆引きを fremont.gcd.org に設定した。 あとは、 dnscache を動かして外部のキャッシュサーバに頼らず名前を引けるようにしたり、 私の自宅サーバ gw.gcd.org との間にトンネルを設置したり、 gw.gcd.org 上の MySQL からローカルの MySQL に対してレプリケーションを行なうようにしたり、 等々...

もちろん、 Linode でもキャッシュサーバを提供しているので、 自前のキャッシュサーバを VPS 上で動かす必要は必ずしもないが、 名前引きができないことはあらゆるトラブルの元なので、 可能な限り自前で名前を引きに行くようにしたい。 なお、VPS は自身の IP アドレスを DHCP サーバに問合わせて設定しているので、 /etc/resolv.conf を直接書き換えても DHCP クライアントによって書き戻されてしまう。 そこで /etc/dhcp3/dhclient.conf に 「prepend domain-name-servers 127.0.0.1;」 を追加する (元々コメントアウトされているので先頭の # を取り除く)。

普通の ubuntu マシンをいじってるのと何ら変わらず、 しかも ssh でログインしたときのレスポンスも、 日本にあるサーバへアクセスしたときと同程度に速いので普通に使える。 apt-get しまくったので WordPress を動かす準備はすぐ整った。 VPS 上の MySQL のアカウントは、 gw.gcd.org とは (当然) 異なるパスワードを設定し、 WordPress からローカルの (つまり VPS 上の) MySQL へつなぐよう設定する。 これで (万一) gw.gcd.org 側が落ちても VPS 側だけでブログを表示できる。

一点注意すべきなのは、 レプリケーションは gw.gcd.org から fremont.gcd.org への一方通行なので、 VPS 上の MySQL へ何を書込んでもそれは gw.gcd.org へは反映されないという点。 したがってブログへコメントを書込むときは、 fremont.gcd.org ではなく gw.gcd.org 側へアクセスするように、 ブログの URL http://www.gcd.org/blog/ とは別に、 コメントやトラックバックの URL として http://feedback.gcd.org/blog/ を用意した (feedback.gcd.org は gw.gcd.org のエイリアス)。

もちろん双方向レプリケーションを行なうことも可能だが、 Linode の仮想環境に万一脆弱性があった場合に備えて Linode 側で何が起きても構わないように一方通行にしておく方が無難だろう。 さらに、 Linode 側からレプリケーション用の ID 以外で gw.gcd.org の MySQL をアクセスしようとしても、 たとえパスワードが一致しても通信を遮断する仕掛けを gw.gcd.org 側で組み込んである。

そして WordPress が設定するクッキーのドメインを gcd.org に変更して、 feedback.gcd.org なページ (コメント書込み、トラックバック受付) で設定したクッキーを www.gcd.org なページで参照できるようにする。 wordpress/wp-config.php に以下のコードを入れておけばよい:

if ( !defined('COOKIE_DOMAIN') )
	define('COOKIE_DOMAIN', "gcd.org");

最後に、 www.gcd.org の IP アドレスとして VPS の IP アドレス 74.207.241.21 を追加した。

% dnsqr a www.gcd.org
1 www.gcd.org:
61 bytes, 1+2+0+0 records, response, noerror
query: 1 www.gcd.org
answer: www.gcd.org 12657 A 74.207.241.21
answer: www.gcd.org 12657 A 60.32.85.216

すなわち、 いま読者の皆さんが読んでるこのページは、 1/2 の確率で Linode の VPS が送信したページということになる。 すでに一週間近くこの状態を続けていて、 今のところ 360MB のメモリで一応足りているが、 アクセスが増えてくるとどうなるか少し心許無い。

fremont:/home/sengoku % free
             total       used       free     shared    buffers     cached
Mem:        351508     264236      87272          0       4444      35316
-/+ buffers/cache:     224476     127032
Swap:       262136      39656     222480

統合といっても両ブログは微妙(?)に読者層が異なると思われるし、 何よりページの体裁が大きく変わってしまっては読者の方々を戸惑わせてしまうので、 CTO日記を 「仙石浩明の日記」 の一カテゴリという位置付けにして、 かつページの体裁は WordPress のテーマを切り替えることによって、 どちらのブログもあまり大きな変化がないようにしている。

「仙石浩明CTO の日記」 http://sengoku.blog.klab.org/ をアクセスすると、 次のような PHP スクリプトを走らせた上で、 WordPress を呼び出す (末尾の require 文):

<?php
$new = NULL;
if ($_SERVER['REQUEST_URI'] == "/") {
    $new = "/blog/category/cto/";
} elseif ($_SERVER['REQUEST_URI'] == "/feed/") {
    $new = "/blog/category/cto/feed/";
} elseif (preg_match('@^/\d+/\d+/\d+/@',
		     $_SERVER['REQUEST_URI'], $matches)) {
    $new = $_SERVER['REQUEST_URI'];
...(中略)...
}
if ($new) {
    ...(中略)...
    $ORIG_SERVER_NAME = $_SERVER['SERVER_NAME'];
    $host = "www.gcd.org";
    $_SERVER['SERVER_NAME'] = $host;
    $_SERVER['REQUEST_URI'] = $new;
    $_SERVER['SCRIPT_NAME'] = $new;
    $_SERVER['PHP_SELF'] = $new;
    $abspath = "/usr/local/www/wordpress/";
    $themepath = "${abspath}wp-content/themes/sengoku_cto/";
    define('WP_USE_THEMES', true);
    define('TEMPLATEPATH', $themepath);
    define('STYLESHEETPATH', $themepath);
    require("${abspath}wp-blog-header.php");
...(中略)...
}
?>

つまり http://sengoku.blog.klab.org/ へのアクセスは、 パス名に 「/category/cto/」 を追加することによって、 CTO日記カテゴリへのアクセスに変換する。

ページの体裁については、 「wp-content/themes/sengoku_cto/」 ディレクトリが、 CTO日記のテーマフォルダで、 二つの PHP 定数 TEMPLATEPATH と STYLESHEETPATH をこのディレクトリへ設定することによって、 テーマの切り替えを行なっている。

テーマフォルダの中にあるテーマ関数ファイル 「functions.php」 は、 WordPress の初期化中に読み込まれるので、 ここに PHP スクリプトを書いておくことによって WordPress の挙動を変更することができる。 例えばブログのタイトルを 「仙石浩明CTO の日記」 に変更するには、 以下のスクリプトを functions.php に追加しておけばよい:

function option_blogname_cto() {
    return '仙石浩明CTO の日記';
}
add_filter('pre_option_blogname', 'option_blogname_cto');

つまり、 pre_option_blogname フックに、 option_blogname_cto フィルタを登録する。

WordPress では、 ブログのタイトルなど各種オプションの設定値 (DB に格納している) を、 get_option($setting) 関数を呼び出すことで参照している。 例えばタイトルは get_option('blogname') を呼び出すことで得られ、 URL は get_option('home') で得られる。

get_option($setting) 関数は wp-includes/functions.php で定義されていて、 以下のようにフィルタフック pre_option_* が定義されている:

function get_option( $setting, $default = false ) {
    global $wpdb;

    // Allow plugins to short-circuit options.
    $pre = apply_filters('pre_option_' . $setting, false);
    if ( false !== $pre )
	return $pre;
    ...(中略)...
}

つまり、 「pre_option_設定名」 というフックに登録されたフィルタが値を返すなら、 get_option はオプションの設定値ではなくフィルタが返した値を返すようになる。 前述の例なら、 「pre_option_blogname」 フックに登録された 「option_blogname_cto」 フィルタが 「仙石浩明CTO の日記」 という値を返すので、 get_option('blogname') も 「仙石浩明CTO の日記」 という値を返すようになり、 結果としてブログのタイトルを変更できる、というわけ。

ただし、 前述したように CTO日記は 「仙石浩明の日記」 の一カテゴリという位置付けなので、 ブログのタイトルを変更しただけだと、 ブログ 「仙石浩明CTO の日記」 の 「仙石浩明CTO の日記」 カテゴリということで、 ページのタイトル等が 「仙石浩明CTO の日記 » 仙石浩明CTO の日記」 という冗長なものになってしまう。 そこで、 以下のようなスクリプトを 「functions.php」 に追加して、 タイトルとカテゴリ名が同じときはカテゴリ名が表示されないようにする:

function single_cat_title_cto($category_name) {
    $name = get_option('blogname');
    if ($category_name == $name) return "";
    return $category_name;
}
add_filter('single_cat_title', 'single_cat_title_cto');

single_cat_title フックは、 wp-includes/general-template.php で定義されていて、 ページのタイトルなどに表示されるカテゴリ名を変更することができる。

以上で、 「仙石浩明の日記」 の一カテゴリを 「仙石浩明CTO の日記」 の体裁で見せることができるようになる。 しかし、 元が 「仙石浩明の日記」 であるだけに、 リンク先が全て 「仙石浩明の日記」 のページになってしまう。 例えば、 「仙石浩明CTO の日記」 のトップページの一番下に、 「古い投稿 »」 というリンクがあるが、 このリンク先が http://www.gcd.org/blog/page/2/ になってしまい、 たどると 「仙石浩明の日記」 のトップページの 2ページ目へ遷移してしまう。

また、 本文中 (あるいはサイドバー) に現れるリンクも、 DB のデータは 「仙石浩明の日記」 のパーマリンクを用いているので、 たとえそれが 「仙石浩明CTO の日記」 カテゴリに含まれていても、 そのリンクをたどると 「仙石浩明の日記」 の記事として表示されてしまう。

そこで、 遷移先も 「仙石浩明CTO の日記」 として表示したいリンクを、 フィルタで書き換えることにした。 つまり DB のデータは 「仙石浩明の日記」 へのリンクのままで、 ブラウザに送信する前に都度書き換える。

対象となるリンクは、 記事本文中だけでなく、 前述したページナビ 「古い投稿」 「新しい投稿」 や、 サイドバー (「人気記事」 や 「最近の投稿」) にも現れる。 ページ丸ごと (つまり HTTP レスポンス丸ごと) HTML を書き換えられるフックがあるとよかったのだが、 残念ながらそういうフックは定義されていないようだ。 以下のフックそれぞれについてリンクを書き換えればよさげ:

書き換え対象のリンクを決めるために、 まず CTO日記カテゴリに属す記事の ID を取得する:

function setup_cto_id() {
    global $wpdb;
    global $is_cto_id;
    $result = $wpdb->get_results("SELECT object_id FROM wp_term_relationships WHERE term_taxonomy_id=17", ARRAY_N);
    foreach ($result as $row) {
	$is_cto_id[$row[0]] = 1;
    }
}

あるカテゴリに属す記事ID のデータを取得する関数など、 WordPress に含まれているんじゃないかと探してみたのだが、 見つからなかったので DB に問合わせて取得するようにしてみた。 毎回 DB アクセスが発生してしまうが、 キャッシュとかはアクセス数が増えてから考える (^^;)。 「term_taxonomy_id=17」 が CTO日記のカテゴリ (決め打ち ^^;)。 CTO日記カテゴリに属す記事は、 配列 $is_cto_id[記事ID] に 1 を代入しておく。

次に URL を書き換えるスクリプト:

function replace_URL_cto($matches) {
    global $is_cto_id;
    global $ORIG_SERVER_NAME;
    if (!is_array($is_cto_id)) {
	setup_cto_id();
    }
    if (is_null($matches[2])) {
	if ($matches[1] == "category/cto/") return "http://$ORIG_SERVER_NAME/";
	return "http://$ORIG_SERVER_NAME/$matches[1]";
    } elseif ($is_cto_id[$matches[2]]) {
	return "http://$ORIG_SERVER_NAME/$matches[1]";
    }
    return $matches[0];
}

function convert_URLs_cto($text) {
    $textarr = preg_split("/(<.*>)/U", $text, -1, PREG_SPLIT_DELIM_CAPTURE);
    $stop = count($textarr);
    for ($i = 0; $i < $stop; $i++) {
	$content = $textarr[$i];
	if (strlen($content) > 0) {
	    $content = preg_replace_callback(
		    '@http://www.gcd.org/blog/(\d+/\d+/(\d+)|category/cto/)@',
		    'replace_URL_cto', $content);
	}
	$output .= $content;
    }
    return $output;
}

顔文字を画像に変換して表示するフィルタ wptexturize (wp-includes/formatting.php で定義されている) を参考にさせてもらった。 preg_replace_callback() を使って書き換え対象リンクを探し、 replace_URL_cto で記事ID がCTO日記カテゴリに属す ($is_cto_id[$matches[2]] が TRUE) 場合のみ書き換える。

最後に、 この書き換えフィルタ replace_URL_cto を前述したフィルタフックに追加:

add_filter('the_content', 'convert_URLs_cto');
add_filter('the_category', 'convert_URLs_cto');
add_filter('get_pagenum_link', 'convert_URLs_cto');
add_filter('post_link', 'convert_URLs_cto');
add_filter('widget_text', 'convert_URLs_cto');
add_filter('wp_list_categories', 'convert_URLs_cto', 12000);
add_filter('category_feed_link', 'convert_URLs_cto');

wp_list_categories にフィルタを追加すると Category Order プラグインと衝突するので、 優先順位を下げて Category Order プラグインの後で実行されるようにしている。

また、 the_category, post_link, widget_text, category_feed_link 各フックは、 2つ以上の引数を持つが、 第1引数 (書き換え対象の HTML あるいは URL) のみ使用するので引数の数 (add_filter の第3引数) を省略している。

例えば、 HTML文法エラーを修正できない問題点を見つけたときや、 ブログのサイドバーにある 「livedoor Reader」 「RSS」 「livedoor Blog」などのバナーを非表示にしていたら、 ライブドアから警告メールが来て、 やむなくバナー表示を復活させたときなど。 なかでも、 昨年ブログ管理画面 (有料プラン) がリニューアルされたときは、 とても大きなフラストレーションを感じた。 ライブドアはよかれと思ってリニューアルしているのだろうが、 JavaScript を多用した新管理画面は、 私にとっては使いにくいことこのうえないし、 生ログ取得スクリプトも使えなくなった。

そして、 今年に入って 「ブログ共通ヘッダー」 (最上端に表示される livedoor Blogのロゴ, 所属カテゴリ, テキスト広告) が勝手に表示されるようになったのが最後の背中のひと押しとなった。 これを非表示にしたければ PRO プラン (月額 315円) ではなく ADVANCE プラン (月額 840円) に変更しろという趣旨 (要は値上げ) なのだと思うが、 何の連絡もなく画面の一番目立つ最上端に、 醜悪なヘッダー (ADVANCE プランへの移行を促すためにわざと醜悪にしている? *_*) を勝手に挿入するデリカシーの無さに驚き呆れ、 自前サーバへの引越を決めた。

ブラウザ画面最上端 ↑ の 「ブログ共通ヘッダー」 (所属カテゴリ 「IT > プログラミング 」 と 「受験にまつわるエピソードを教えてください」 という広告? 表示) は、 ライブドアのサーバが HTML 中に自動挿入する以下の JavaScript (settings/header.js) によって body 要素へ追加 (appendChild) されている。

(function () {
    var hd = document.createElement('div');
    var str = '';
    str += '<div id="header2" style="z-index:10001"><table cellspacing="0" class="blog-common-header" id="header">';
	...(中略)...
    hd.innerHTML = str;
    document.body.appendChild(hd);
	...(後略)...

ユーザがカスタマイズ可能な範囲の外であるため、 この JavaScript の実行そのものを止めることは無理っぽいが、 追加された子要素を削除する JavaScript を実行して消すことは可能。 例えば以下のようなコードを HTML ファイルのどこかに入れておけばよい。

<script type="text/javascript" src="http://www.gcd.org/sengoku/docs/livedoor.js"></script>

livedoor.js は、 body 要素の子要素 「header2」 を取り除く (removeChild) だけの JavaScript:

(function () {
    var element = document.getElementById("header2");
    element.removeChild(element.childNodes.item(0));
})();

正月早々 「ブログ共通ヘッダー」 が勝手に表示されるようになったことに気付き、 直ちにこの対策を行なって非表示にしたのだが、 以前バナーを非表示にしたときライブドアから警告メールが来たことを考えれば、 今回も警告メールが来るのは時間の問題だろうと、 引越を急いだ次第。

私はブログを書くときも HTML で書いていて、 あまり CMS 的な機能は必要としないので、 トラックバックとコメントを受付けるだけの簡単な Web アプリを書こうと思っていたのだが、 試しにインストールしてみた WordPress が思いの外シンプルな作りで、 ちょっといじっているうちに簡単にカスタマイズできてしまったので、 これを使うことにした。

livedoorブログでエクスポートしたデータを (Movable Type / TypePad のデータとして) WordPress でインポートしたら、 (pre 要素なのに) 行頭の空白文字が削除されてしまって往生したが、 大した量でもなかったので手作業で修正してしまった。 もう少し量が多かったら真面目に PHP コードを追ったのだが...

こんなに簡単にできるなら、 もっと早く WordPress へ移行すればよかった。 既存のテーマを見よう見まねでいじっただけなのだが、 以前のデザインをほとんどそのまま踏襲することができた (むしろ余計な div 要素を排除できたので、よりシンプルになった)。

livedoorブログと WordPress では URL (パーマリンク, permalink) の形式が異なる。 例えば、 あるエントリの URL は、 livedoorブログ (旧URL) と WordPress (新URL) で次のようになる:

一見して、 WordPress のパーマリンクの方が分かりやすい。 正確に言えば、 WordPress のパーマリンクの形式は任意に設定できて、 livedoorブログ (Movable Type ベース) の形式に合わせることも可能だが、 エントリID (上記の例だと 51168556 と 154) が異なるので形式を合わせること自体にはあまり意味はない。

livedoorブログを利用していた時の URL がそのまま使えるように、 旧URL を新URL へ変換する以下の PHP スクリプトを書いた (switch 文で URL ごとにずらずら case を並べただけ)。

<?php
$new = NULL;
if ($_SERVER['REQUEST_URI'] == "/") {
    $new = "/blog/";
} elseif ($_SERVER['REQUEST_URI'] == "/atom.xml") {
    $new = "/blog/feed/atom/";
} elseif ($_SERVER['REQUEST_URI'] == "/index.rdf") {
    $new = "/blog/feed/rdf/";
} elseif (preg_match('/^\/archives\/(20\d\d)-(\d\d)\.html$/',
		     $_SERVER['REQUEST_URI'], $matches)) {
    $year = $matches[1];
    $mon = $matches[2];
    $new = "/blog/$year/$mon/";
} elseif (preg_match('/^\/archives\/cat_(\d+)\.html$/',
		     $_SERVER['REQUEST_URI'], $matches)) {
    $id = $matches[1];
    $new = "/blog/category/";
    switch ($id) {
    case 50026701: $new .= "enlighten/";   break;
    case 50026704: $new .= "business/";    break;
    case 50026703: $new .= "engineer/";    break;
    case 50026699: $new .= "system/";      break;
    case 50035671: $new .= "hardware/";    break;
    case 50026700: $new .= "programming/"; break;
    case 50021362: $new .= "stone/";       break;
    case 50035209: $new .= "la-fonera/";   break;
    case 50041534: $new .= "hawaii/";      break;
    case 50045637: $new .= "hongkong/";    break;
    case 50026702: $new .= "others/";      break;
    default: $new = NULL;
    }
} elseif (preg_match('/^\/archives\/(\d+)\.html$/',
		     $_SERVER['REQUEST_URI'], $matches)) {
    $id = $matches[1];
    $new = "/blog/";
    switch ($id) {
    case 50071073: $new .= "2006/03/8/"; break;
	...(中略)...
    case 51168556: $new .= "2008/04/154/"; break;
	...(中略)...
    case 51552583: $new .= "2009/12/184/"; break;
    case 51555097: $new .= "2010/01/185/"; break;
    default: $new = NULL;
    }
}
if ($new) {
    $host = "www.gcd.org";
    $_SERVER['SERVER_NAME'] = $host;
    $_SERVER['REQUEST_URI'] = $new;
    $_SERVER['SCRIPT_NAME'] = $new;
    $_SERVER['PHP_SELF'] = $new;
    define('WP_USE_THEMES', true);
    require('/usr/local/www/wordpress/wp-blog-header.php');
} else {
    header("HTTP/1.1 301 Moved Permanently");
    header("Location: http://www.gcd.org/blog/");
    exit();
}
?>

http://blog.gcd.org/* にアクセスすると、 ↑ この PHP スクリプトが実行される。

これに加え、 逆方向の変換、 つまり新URL から旧URL への変換も必要。 例えば 「はてなブックマーク」 へ頂いたコメント (例えば前述したエントリに対するコメント一覧) は旧URL に紐づいているので、 各エントリに旧URL を登録しておく必要がある。 WordPress には カスタムフィールド という機能があって、ひとつのエントリに複数の 「キー」 と、 各キーにその値を登録することができる。 そこで沢山の 「ブックマーク」 を頂いたエントリには、 「hatena_b」 というキーで旧URL を登録しておくことにした。 すると、以下のような PHP スクリプトでブックマーク数 を表示できる。

<?php
  $hatena_b = get_post_meta($post->ID, "hatena_b", true);
  if ($hatena_b)
    echo ' <a href="http://b.hatena.ne.jp/entry/' . $hatena_b
       . '"><img style="border:0;" src="http://b.hatena.ne.jp/entry/image/'
       . $hatena_b . '" alt="" /></a>';
?>

最後に、 ネームサーバの設定変更を行なって、 blog.gcd.org レコード (TTL = 3時間) の値を 「CNAME blog-01.livedoor.jp」 から 「CNAME www.gcd.org」 へ変更した。 1/26 19:35 に変更を行なったところ、 19:46 には最初のアクセスが www.gcd.org へ届き、 20時台には大半のアクセスが www.gcd.org へ届くようになった。 20時台にライブドア側へ届いた blog.gcd.org へのアクセスはわずかに 7件、 その後は 1 時間〜数時間ごとに、ぱらぱらアクセスがあるという状況が続いている。 旧レコードを保持しているキャッシュネームサーバが残っていて、 そのネームサーバを使ってるブラウザからのアクセスのみが、 ライブドア側へ届いているといった感じ。

同日 20:20 追記:

そろそろ帰ろうかと思っていたら、 ひろせ31さんからチャットを頂いた:

(19:05:46) ひろせ: curl -I http://www.gcd.org/blog/ | grep X-Pingback
到達不可なヘッダついてますよー
(19:06:46) 仙石: ども、ご無沙汰してます。
(19:06:53) ひろせ: どもどもー
(19:08:21) 仙石: そっか、ヘッダに残ってましたか～
(19:08:34) 仙石: チェックするのを忘れていました。ありがとうございます
(19:08:40) ひろせ: いえいえー

確かにヘッダに 「X-Pingback:」 フィールドがついている。↓

% curl -I http://www.gcd.org/blog/
HTTP/1.1 200 OK
Date: Thu, 28 Jan 2010 10:08:54 GMT
Server: Apache
X-Pingback: http://gt.gcd.org/wordpress/xmlrpc.php
Content-Type: text/html; charset=UTF-8

Pingback って何だろう (^^;) と思いつつ、 「gt.gcd.org」 は GCD (私の個人サイト) 内部でのみ有効なホスト名 (IPアドレスは 192.168.1.1) なので、 このフィールドの目的が何であれ取り除いた方がいい。 実は、 HTTP レスポンス中にも 「gt.gcd.org」 は出力されていて、 ↓

<link rel="EditURI" type="application/rsd+xml" title="RSD" href="http://gt.gcd.org/wordpress/xmlrpc.php?rsd" />
<link rel="wlwmanifest" type="application/wlwmanifest+xml" href="http://gt.gcd.org/wordpress/wp-includes/wlwmanifest.xml" /> 

これは公開前に気付いて取り除いたのだが、 HTTP ヘッダの方はチェックするのを忘れていた。orz

上記二つの link 要素は、 それぞれ rsd_link と wlwmanifest_link というフィルタが出力しているので、 このフィルタを wp_head フックから取り除いてやればよい。 具体的には、 現在のテーマの functions.php ファイルに、 以下のようなコードを追加する:

remove_action('wp_head', 'rsd_link');
remove_action('wp_head', 'wlwmanifest_link');

ひろせ31さんから指摘を受けて、 条件反射的に WordPress の PHP コードを検索してみた:

% find /usr/local/www/wordpress -type f | xargs grep X-Pingback
/usr/local/www/wordpress/wp-includes/classes.php:	 * Sets the X-Pingback header, 404 status (if 404), Content-type. If showing
/usr/local/www/wordpress/wp-includes/classes.php:		$headers = array('X-Pingback' => get_bloginfo('pingback_url'));

classes.php の該当箇所を見てみると、

	function send_headers() {
		$headers = array('X-Pingback' => get_bloginfo('pingback_url'));
		...

ありゃ、ハードコードされてる...

前述した link 要素のように、 フィルタで出力するようになっていれば、 そのフィルタを無効化するだけで済むのに... (*_*)

さて、どうしたものか。 この send_headers() 関数は、 $headers 配列にフィールドを加えていって、 最後に $headers を HTTP ヘッダとして送信する、 という処理の流れのようだ。

さらに読み進めていくと、

		...
		$headers = apply_filters('wp_headers', $headers, $this);
		...

ありがたいことにフィルタ・フックが定義されていた。 この wp_headers フックに、 X-Pingback: フィールドを取り除くフィルタを登録すれば、 うまくいきそうだ。

(19:12:57) 仙石: X-Pingback はハードコードされてますねぇ... > WordPress
(19:13:12) ひろせ: うひー
(19:13:22) 仙石: フィルタで削除するしかないのかな... あるいは WordPress のコードを直接書き換えるか...
(19:13:22) ひろせ: gt.gcd.orgって、内部ホストなんですかね？
(19:13:26) 仙石: です
(19:13:43) 仙石: 管理用なので、外部からはアクセスできないようにしたいです
(19:16:46) ひろせ: Apacheで、 Header unset X-Pingback で消えるかもすね。
(19:17:58) 仙石: なるほど

現在のテーマの functions.php ファイルに、 以下の PHP コードを追加してみた:

function remove_X_Pingback($headers) {
	unset($headers['X-Pingback']);
	return $headers;
}
add_filter('wp_headers', 'remove_X_Pingback');

初めて書く WordPress のフィルタだったが (実をいうと PHP も書き慣れているわけではないので、 配列の要素を削除する方法もマニュアルを調べながら書いた ^^;)、 うまく動いているようだ:

% curl -I http://www.gcd.org/blog/
HTTP/1.1 200 OK
Date: Thu, 28 Jan 2010 10:29:33 GMT
Server: Apache
Content-Type: text/html; charset=UTF-8

めでたく、X-Pingback: フィールドが出力されなくなった。

(19:30:23) 仙石: 取り除きました。＞ X-Pingback:
(19:30:33) ひろせ: oo
(19:30:38) 仙石: functions.php に、
function remove_X_Pingback($headers) {
        unset($headers['X-Pingback']);
        return $headers;
}
add_filter('wp_headers', 'remove_X_Pingback');
(19:30:51) 仙石: を加えました。

ありがとうございました。＞ ひろせ31さん

10/16日に NTT東日本 0120-116116 に電話して申し込んだところ、 回線切替工事まで最短で 10営業日かかり、 工事の予約状況によると最速で 11/1(日) の工事になるらしい。 続いて NTT コミュニケーションズ 0120-506-506 に電話して、 200Mbps に変更したときプロバイダ (OCN) 側の変更が必要か確認。 個人向けサービス (OCN 光 with フレッツ) は元々 200Mbps に対応しているから契約変更は必要無しとのことだったが、 あいにく私が契約しているのは法人向けサービスであるところの OCN 光アクセス IP8/IP16「Bフレッツ」プラン である。 この場合、 OCN 光アクセス IP8/IP16「フレッツ 光ネクスト」プラン への契約変更が必要となる。

NTT コミュニケーションズの担当者の話によると、 認証サーバの設定を変更するらしい。 PPPoE のユーザ名とパスワードはそのまま同じものを使っていい (新しいユーザ名も付与されるので新旧どちらのユーザ名も使える) が、 認証サーバ側の設定を変更すると旧回線 (つまり Bフレッツ) からの認証は拒否されるらしい。 すなわち認証サーバの設定変更後は、 新回線 (つまり フレッツ 光ネクスト) からでないと認証が通らない。 したがって、 回線が切り替わる前に PPPoE セッションが切れると、 旧回線のままでは再接続できなくなってしまう。 さらに、 設定変更は平日の未明 0:00 ～ 5:00 の間にしか実施しないらしい。

ということはつまり、 11/1(日) に回線工事を行なうには、 10/30(金) の未明に認証サーバの設定変更を行なうことになる。 10/30 未明から 11/1 の回線工事まで丸二日間、 もし PPPoE セッションが何らかの原因によって切れてしまうと、 工事完了後まで二度と再接続できなくなる。 最長丸二日間切れたままというのはあまりに不便なので、 11/2(月) の未明に認証サーバの設定変更を行ない、 同日午前 9:00-12:00 に回線切替工事を行なうことにした。 これなら PPPoE セッションが切れても数時間の切断で済む。

工事当日 11/2 朝、 すでに認証サーバの設定変更が行なわれたはずだから、 いま PPPoE セッションが切れると終わりだな～ とドキドキしながら回線切替工事を待つ。 10:06 に、 日本コムシスの工事担当者から電話があった。 これから工事に伺うとのこと。 ONU の置き換えだけだと私は思っていたのだが、 宅外の光ファイバ引き込み部分で光ファイバのつなぎ替えも行なうらしい。 そういえば何日か前、 光ファイバの敷設 (電柱の上なので架設?) 作業を近所で行なっていた。 もしかすると私の自宅にファイバを引くためだけに、 敷設作業を行なっていたのかもしれない。

twitter で実況したように、 10:18 に ONU の電源を落として工事開始。 B フレッツ用の ONU (品名 B-PONHA B-ONU-E1 日立製作所製) から光ファイバを外し、 超小型可視光レーザー光源 (フジクラ製) をつなぐ。

何のためにレーザを光ファイバに入れるのかと工事担当者に質問してみた。 光ファイバの断線を検知するためと、 宅外で光ファイバをつなぎ替える際、 つなぐファイバを間違えないようにするためらしい。 宅外のつなぎ替えが終わると、 フレッツ 光ネクスト用の ONU (品名 GE-PON <M>A GE-PON-ONU 三菱電機製) に光ファイバをつないで工事完了。

正確に言うと、光ファイバのコネクタ (SC コネクタ) の付け替えも行なった。 旧ONU は 2004年12月18日に Bフレッツを契約したとき設置したものだが、 当時は宅内配線用の外装 (PVC被覆) 付き光ファイバケーブル (ドロップ光ファイバ, 写真↑ 上から伸びている白っぽいケーブル) にコネクタを直結できなかったらしく、 コネクタ付き光ファイバケーブル (写真↑ レーザ光源につないでいる黄色のケーブル) と、 宅内配線用ケーブル双方の光ファイバを露出させて (細く黒っぽい色なので写真↑ では見えにくい) 接続していた (メカニカルスプライス法)。 今はドロップ光ファイバに直接コネクタを取りつけることができるらしい。 コネクタを取りつけた後、 光レベルを測定していた (-15.96dBm のようだが詳細不明)。

フレッツ 光ネクストには、 Bフレッツの 「FLET'S SQUARE」 に相当するものはなく、 代わりに IPv6 ベースの 「FLET'S SQUARE NEXT」 がある。 フレッツ速度測定 (IPv6) サイト で測定してみる。

フレッツ速度測定(IPv6)サイトでは、お客様PC端末からNGNを経由して、
フレッツ・スクウェア ネクスト(NGN内に設置したIPv6速度測定サーバ) までの、
IPv6プロトコルを使った通信速度をご確認いただけます。

フレッツ速度測定 (IPv6) サイト から引用

IPv6 なので (ルータを介さずに) WAN 側に直接 PC をつなぐか、 あるいはブルータを利用する必要がある。 私の自宅内LAN では、 WAN 側セグメントと LAN 側セグメントをルータ (というか Linux マシン) で分離しているので、 LAN 側から NGN へ IPv6 で通信することはできないが、 (ルータ代わりの二台の Linux マシンの他に) 一台だけ両セグメントにつながっている Windows XP マシン がある。 この XP マシンで速度測定をやってみる。

ところが何度やっても 100Mbps 未満の値しかでず、 何のためにわざわざ回線工事を行なったのやら、 と嘆いていたら、 この XP マシンの二つの NIC のうち一つは 100baseT (Mother Board 上の Intel Pro 10/100 LAN) だったことを思い出した (もう片方は 玄人志向 GbE-PCI2)。 二本の ether ケーブルを逆につないで速度測定をやり直したところ、 無事 200Mbps 以上の値がでるようになった。 そして、 なぜか 200Mbps 以上の値が出てしまった。

Bフレッツの時はフレッツ速度測定サイトで 80Mbps ほどの値だったので、 回線切替してよかったと言えるのかもしれないが、 NGN までの帯域が広くても、 その先の OCN (プロバイダ) の方があまり変っていない (巷の速度測定サイトで 40Mbps ～ 60Mbps) ように感じられる (まあ料金が変らないので文句も言えないが)。 それより、 従来は勤務先の LAN までフレッツ網経由で 40Mbps くらい出ていたのが、 NGN とフレッツ網は相互に通信できないらしく、 勤務先の LAN へ IPv6 で直接通信できなくなってしまったのが痛い。 いったんプロバイダ経由でインターネットに出て通信せざるを得なくなり、 帯域が 1/4 以下になってしまった (勤務先が OCN でないのが影響している?)。 なお、 遅延 (latency) は切替前後でほとんど差がない。

senri:/usr/local/src/glibc-2.10.1.i386 % ../glibc-2.10.1/configure
	...
senri:/usr/local/src/glibc-2.10.1.i386 % make
	...
/usr/local/src/glibc-2.10.1.i386/libc_pic.os: In function `__libc_fork':
/usr/local/src/glibc-2.10.1/posix/../nptl/sysdeps/unix/sysv/linux/i386/../fork.c:79: undefined reference to `__sync_bool_compare_and_swap_4'
/usr/local/src/glibc-2.10.1.i386/libc_pic.os: In function `__nscd_drop_map_ref':
/usr/local/src/glibc-2.10.1/nscd/nscd-client.h:320: undefined reference to `__sync_fetch_and_add_4'
	...
/usr/local/src/glibc-2.10.1.i386/libc_pic.os: In function `*__GI___libc_freeres':
/usr/local/src/glibc-2.10.1/malloc/set-freeres.c:39: undefined reference to `__sync_bool_compare_and_swap_4'
collect2: ld returned 1 exit status
make[1]: *** [/usr/local/src/glibc-2.10.1.i386/libc.so] Error 1
make[1]: Leaving directory `/usr/local/src/glibc-2.10.1'
make: *** [all] Error 2

__sync_bool_compare_and_swap_4 は gcc の組み込み関数なので、 関数が未定義であることを示す 「undefined reference to ...」 というエラーメッセージは、 誤解を招く不親切なメッセージだと思う。

__sync_bool_compare_and_swap_4(mem, oldval, newval) は、 mem が指し示すメモリの値 (4バイト分) が oldval であれば newval に変更する、 という操作をアトミックに行なう組み込み関数。 アトミック (不可分) 操作とは、 操作の途中が存在してはいけない操作のことで、 この例なら比較 (メモリの値が oldval か?) と代入 (newval に変更) が必ず 「いっぺん」 に行なわれ、 「比較だけ行なったけどまだ代入は行なわれていない」 という状態が存在しないことを意味する。

アトミックに行なうためには、 当然ながら CPU でその操作をサポートしている必要がある (複数個の命令の列で実現しようとすると、 命令列の半ばを実行中の状態が必ず存在してしまう) わけだが、 残念ながら Intel 386 プロセッサでは、 この compare_and_swap (CMPXCHG 命令) をサポートしておらず、 サポートするのは Intel 486 以降の CPU である。 テストプログラムを書いて試してみる:

#include <stdio.h>

int main() {
    int mem[1], oldval, newval;
    oldval=0;
    newval=1;
    mem[0] = 0;
    __sync_bool_compare_and_swap(mem, oldval, newval);
    printf("mem[0]=%d\n", mem[0]);
    return 0;
}

見ての通り、 mem[0] の値を oldval の値 (0) と比較し、 一致していたら newval の値 (1) を代入し、 mem[0] の値を表示するだけのプログラムである。

関数名が 「__sync_bool_compare_and_swap」 であって、 後ろに 「_4」 がついていないことに注意。 gcc が引数の型 (この例では int) を見て、 その型のビット長を後ろにつけてくれる (この例では int 型は 4 バイトなので 「_4」 をつけてくれる)。

gcc では 「-march=タイプ」 オプションを指定することによって CPU タイプを指定できる。 -march オプションを指定しなかったり (この場合は全 CPU でサポートされる組み込み関数のみ利用できる)、 あるいは -march=i386 を指定したりすると、 コンパイル時にエラーになる:

% gcc -Wall test.c
/tmp/cc4eNX6L.o: In function `main':
test.c:(.text+0x3b): undefined reference to `__sync_bool_compare_and_swap_4'
collect2: ld returned 1 exit status
% gcc -Wall -march=i386 test.c
/tmp/cc6chtFj.o: In function `main':
test.c:(.text+0x36): undefined reference to `__sync_bool_compare_and_swap_4'
collect2: ld returned 1 exit status
% gcc -Wall -march=i486 test.c
% ./a.out
mem[0]=1

いまさら i486 というのもアレなので、 今なら i686 を指定するのがよさげ。 私の手元にはいまだ PentiumIII マシンがあるものの、 PentiumIII より古いマシンはない (昨年 ML115 と SC440 を買ったとき PentiumII マシンを引退させた) ので、 pentium3 を指定すれば SSE (Streaming SIMD Extensions) が利用できるようになるが、 glibc をビルドするときに必要かというと、 たぶん必要ない。

というわけでエラーの原因は分かったが、 では glibc をビルドするときは、 どうすればいいだろうか？

とりあえず google で検索してみたら、 gcc の configure オプションに 「--with-arch=i686」 を指定して gcc をビルドする必要がある、 と書いてあるページが見つかった。

--with-arch オプションは、 -march のデフォルトを設定するための configure オプションである。 つまり 「--with-arch=i686」 を指定して gcc を再インストールすると、 gcc に -march オプションをつけなくてもデフォルトが i686 になる。 なるほど確かにそうすれば、 glibc 側で何も変更せずに __sync_bool_compare_and_swap_4 関数が使えるようになりそうである。

いまどき i686 以前の CPU 用のコードが必要になりそうなケースは滅多にないだろうから、 -march オプションのデフォルトを i686 にするのも悪い選択ではないように思えた。 gcc をビルドし直すのは面倒だなーと思いつつも、 ついでに gcc のバージョンを上げておこうと gcc-4.3.4 をダウンロードしてきて 「--with-arch=i686」 付でビルドしてみた。

ところが！

「--with-arch=i686」付でビルドした gcc を使って glibc をビルドしようとすると、 先ほどコンパイラエラーが出た場所より前の段階で、 アセンブラがエラーを出力して make が止まってしまった:

senri:/usr/local/src/glibc-2.10.1.i386 % make
	...
../sysdeps/i386/fpu/s_frexp.S: Assembler messages:
../sysdeps/i386/fpu/s_frexp.S:66: Error: invalid identifier for ".ifdef"
../sysdeps/i386/fpu/s_frexp.S:66: Error: junk at end of line, first unrecognized character is `1'
	...
../sysdeps/i386/fpu/s_frexp.S:66: Error: ".endif" without ".if"
../sysdeps/i386/fpu/s_frexp.S:66: Error: junk `.get_pc_thunk.dx' after expression
make[2]: *** [/usr/local/src/glibc-2.10.1.i386/math/s_frexp.os] Error 1
make[2]: Leaving directory `/usr/local/src/glibc-2.10.1/math'
make[1]: *** [math/subdir_lib] Error 2
make[1]: Leaving directory `/usr/local/src/glibc-2.10.1'
make: *** [all] Error 2

こちら (コンパイラ側) を立てれば、あちら (アセンブラ側) が立たず、 な二律背反状態。

「invalid identifier for ".ifdef"」 というエラーメッセージが (ぱっと見には) 意味不明である。 続いて 「junk at end of line, first unrecognized character is `1'」 と言っているから、 「.ifdef 1」 みたいなコードなのだろうか？ エラーが起きた sysdeps/i386/fpu/s_frexp.S の 66行目あたりは以下のようになっている。 LOAD_PIC_REG の行が問題の 66行目:

	cmpl	$0x00100000, %eax
	jae	2f

	fldl	VAL0(%esp)
#ifdef	PIC
	LOAD_PIC_REG (dx)
#endif
	fmull	MO(two54)
	movl	$-54, %ecx
	fstpl	VAL0(%esp)
	fwait
	movl	VAL1(%esp), %eax
	movl	%eax, %edx
	andl	$0x7fffffff, %eax

おそらく LOAD_PIC_REG マクロを展開した結果がおかしいのだろうと、 LOAD_PIC_REG マクロの定義 (sysdeps/i386/sysdep.h) を調べてみる:

# define SETUP_PIC_REG(reg) \
  .ifndef __i686.get_pc_thunk.reg;					      \
  .section .gnu.linkonce.t.__i686.get_pc_thunk.reg,"ax",@progbits;	      \
  .globl __i686.get_pc_thunk.reg;					      \
  .hidden __i686.get_pc_thunk.reg;					      \
  .type __i686.get_pc_thunk.reg,@function;				      \
__i686.get_pc_thunk.reg:						      \
  movl (%esp), %e##reg;							      \
  ret;									      \
  .size __i686.get_pc_thunk.reg, . - __i686.get_pc_thunk.reg;		      \
  .previous;								      \
  .endif;								      \
  call __i686.get_pc_thunk.reg

# define LOAD_PIC_REG(reg) \
  SETUP_PIC_REG(reg); addl $_GLOBAL_OFFSET_TABLE_, %e##reg

プリプロセッサの出力を確認してみると、 66行目は次のようにマクロ展開されている:

 .ifndef 1 .get_pc_thunk.dx; .section .gnu.linkonce.t. 1 .get_pc_thunk.dx,"ax",@progbits; .globl 1 .get_pc_thunk.dx; .hidden 1 .get_pc_thunk.dx; .type 1 .get_pc_thunk.dx,@function; 1 .get_pc_thunk.dx: movl (%esp), %edx; ret; .size 1 .get_pc_thunk.dx, . - 1 .get_pc_thunk.dx; .previous; .endif; call 1 .get_pc_thunk.dx; addl $_GLOBAL_OFFSET_TABLE_, %edx

確かに、いきなり 「.ifndef 1」 となっているので、 エラーになるのは明らか。 上記 SETUP_PIC_REG マクロ定義内の 「__i686」 がことごとく 「1」 に展開されていて、 意味不明なコードになってしまっている。

というわけで、 原因に思い当たった。 プリプロセッサで自動的に定義されるマクロを表示させてみる:

% gcc -E -dM -x c /dev/null
#define __DBL_MIN_EXP__ (-1021)
#define __pentiumpro__ 1
#define __FLT_MIN__ 1.17549435e-38F
#define __DEC64_DEN__ 0.000000000000001E-383DD
#define __CHAR_BIT__ 8
	...
#define __i686 1
	...
#define __i686__ 1
	...

「#define __i686 1」 だから当然そういうマクロ展開が行なわれる、 というわけ。 gcc と glibc では違うソフトウェアであるとはいえ、 gcc のプリプロセッサで自動的に定義される 「#define __i686 1」 とバッティングするようなラベル 「__i686.get_pc_thunk.reg」 をマクロ中で使うというのは、 いかがなものか。＞ glibc

「--with-arch=i686」付でビルドした gcc, あるいは 「-march=i686」 オプション付で実行した gcc は、 -march を指定しない gcc と比べて、 プリプロセッサにおいて以下の定義が追加されるようだ:

#define __GCC_HAVE_SYNC_COMPARE_AND_SWAP_1 1
#define __GCC_HAVE_SYNC_COMPARE_AND_SWAP_2 1
#define __GCC_HAVE_SYNC_COMPARE_AND_SWAP_4 1
#define __GCC_HAVE_SYNC_COMPARE_AND_SWAP_8 1
#define __i686 1
#define __i686__ 1
#define __pentiumpro 1
#define __pentiumpro__ 1

ちなみに、 SETUP_PIC_REG マクロ定義内で定義されている __i686.get_pc_thunk.reg は、 eip の値をレジスタ reg へ代入するための関数 (というかサブルーチン)。 サブルーチン名の末尾の 「reg」 はマクロ引数で置換される。 この例では dx。 つまり SETUP_PIC_REG マクロを展開することにより __i686.get_pc_thunk.dx というサブルーチンが定義される。

そして、 このサブルーチンを呼び出す (call __i686.get_pc_thunk.dx) と、 スタックトップをレジスタへ代入 (movl (%esp), %edx) して復帰 (ret) する。 つまりプログラムカウンタ (スタックトップに積まれた戻りアドレス) の値がレジスタ edx へ代入される、というわけ。

続いて、 edx に $_GLOBAL_OFFSET_TABLE_ を加算することにより edx にグローバル変数領域へのポインタが代入される (addl $_GLOBAL_OFFSET_TABLE_, %edx)。

__i686.get_pc_thunk.bx は、 gccが用意してくれる関数で、 PC (プログラムカウンタ、EIP レジスタの値) を ebx にコピーします。
　(中略)
なんでここで PC が必要かというと、 グローバル変数にアクセスしたいからです。 PIC/PIE の場合、 実行時に自分自身 (ELF バイナリ) がどの仮想アドレスに mmap されるかはわかりませんので、 アドレス決め打ちで変数にアクセスはできません。 でも、 いま実行している命令 (61d:) から変数までのオフセットは *.o をリンクして so にした時点で判明します (so ファイルのナカミがほぼそのままメモリに貼られるわけなんで)。
　(中略)
mov 0xほげ(%eip) ふが; とか出来れば一番いいんですが(x86_64はできる)、 x86はそういうPC相対のアドレス指定はできません。 というか、eipを直接的に得ることすら出来ません。 なんで、仕方なく一度call命令を発行して、 リターンアドレス（callを発行した命令の次の命令のアドレス） をスタック上に自動push させて、 __i686.get_pc_thunk.bx内でebxレジスタにpopしてます。 x86だと、PIC/PIEなコードでグローバル変数を触るだけで、 関数呼び出しと同じようなコストがかかるんざますよ！奥様。

memologue 2006-09-07 から引用

glibc でどんなグローバル変数にアクセスしているのかと思って、 ちょっと調べてみた:

この sysdeps/i386/fpu/s_frexp.S は、 そのファイル名の通り frexp(3) のアセンブリ言語による実装。 C による実装は sysdeps/ieee754/dbl-64/s_frexp.c にある。 ディレクトリ名から分かるように、 IEEE 754 (IEEE 浮動小数点数演算標準) に基づいている。

double frexp(double x, int *exp) は、 浮動小数点実数 x を正規化小数と指数に分解し、 指数を *exp に格納した上で正規化小数を返す。 浮動小数点実数 x が非正規化数であるとき frexp は x に 2^54 を乗じた上で *exp に -54 を返すのだが、 この 2^54 = 18014398509481984 という定数を double 型で保持するために、 グローバル変数 two54 を使用している。

話が脱線したので元に戻すと、 要は 「--with-arch=i686」 付でビルドした gcc だと、 C のソースだろうとアセンブリ言語で書かれたソースだろうと見境なく 「#define __i686 1」 を定義してしまうので、 相手が C のソースの時のみ 「-march=i686」 を付けて gcc を実行すればよい。 つまり、 gcc は 「--with-arch=i686」 付でビルドしてはいけない。

ではどうすればいいか？ いろいろ方法はあると思うが、 glibc をビルドするときに CFLAGS を 「CFLAGS="-g -O2 -march=i686"」 などと指定して configure を実行するのも一つの解決策。 CFLAGS は C のソースをコンパイルするときだけ使われて、 アセンブルするときには使われないので、 前述したようなコンパイラ/アセンブラ二律背反問題を回避できる。 というわけで、 無事 glibc 2.10.1 をビルドすることができた:

senri:/usr/local/src/glibc-2.10.1.i386 % ../glibc-2.10.1/configure CFLAGS="-g -O2 -march=i686"
	...
senri:/usr/local/src/glibc-2.10.1.i386 % make
	...

mysql> CREATE DATABASE test;
Query OK, 1 row affected (0.05 sec)

mysql> USE test
Database changed
mysql> CREATE TABLE user ( name VARCHAR(255) ) CHARSET=utf8;
Query OK, 0 rows affected (0.05 sec)

などと 「CHARSET=utf8」 を指定すれば、 文字列を UTF-8 エンコーディングで格納する。 「CHARSET」 すなわち 「文字集合」 と、 エンコーディング (文字符号化) は本来別の概念であるが、 MySQL の場合は両者をまとめて CHARSET ないし character_set と呼んでいるので、 ここではそれを踏襲してキャラクタセットと呼ぶことにする。 MySQL のシステム変数のうちキャラクタセットに関連するものは、 以下のように沢山ある。

mysql> SHOW VARIABLES LIKE 'character\_set\_%';
+--------------------------+--------+
| Variable_name            | Value  |
+--------------------------+--------+
| character_set_client     | latin1 |
| character_set_connection | latin1 |
| character_set_database   | latin1 |
| character_set_filesystem | binary |
| character_set_results    | latin1 |
| character_set_server     | latin1 |
| character_set_system     | utf8   |
+--------------------------+--------+
7 rows in set (0.00 sec)

たくさんあってややこしいが、 重要なのは 「character_set_client」 と 「character_set_connection」 「character_set_results」 で、 この3変数はクライアントがクエリを送信し、 クエリ結果を受信するときのキャラクタセットを設定する。 charset コマンド (あるいは SET NAMES) を使うと、 クライアント側のキャラクタセットに関係するこの3変数を一度に変更できるので、 特に必要がなければこの3変数は常に同じキャラクタセット、 すなわちクライアント側で送受信するキャラクタセットに一致させておくとよい (PHP スクリプトから MySQL をアクセスするときは、 mysql_set_charset() を使ってクライアント側のキャラクタセットを設定する)。

mysql> CHARSET utf8
Charset changed
mysql> SHOW VARIABLES LIKE 'character\_set\_%';
+--------------------------+--------+
| Variable_name            | Value  |
+--------------------------+--------+
| character_set_client     | utf8   |
| character_set_connection | utf8   |
| character_set_database   | latin1 |
| character_set_filesystem | binary |
| character_set_results    | utf8   |
| character_set_server     | latin1 |
| character_set_system     | utf8   |
+--------------------------+--------+
7 rows in set (0.00 sec)

mysql> INSERT INTO user VALUES ('仙石　浩明');
Query OK, 1 row affected (0.00 sec)

mysql> SELECT name, HEX(name) FROM user;
+-----------------+--------------------------------+
| name            | HEX(name)                      |
+-----------------+--------------------------------+
| 仙石　浩明      | E4BB99E79FB3E38080E6B5A9E6988E |
+-----------------+--------------------------------+
1 row in set (0.00 sec)

このように 「select HEX()」 で確認すると、 文字列が正しく UTF-8 エンコーディングで格納されていることが確認できる。

蛇足だが、mysql クライアントが GNU readline を使っている場合は、 ~/inputrc などで 「set convert-meta Off」 を設定しておく。 デフォルトの readline では convert-meta が On なので、 キャラクタの最上位ビット (MSB) を 0 にしてしまう。 つまり UTF-8 (および EUC-JP や Shift_JIS) などの 8bit キャラクタセットだと、 MSB が 1 である文字が正しく送信されない。 例えば 「あ」 (UTF-8 で E3 81 82) を入力しようとしても、 MSB が落ちた 「c^A^B」 (63 01 02) が送られてしまう。

「character_set_server」 が latin1 になっていて気持ち悪いかも知れないが、 このシステム変数は新しく database を作るときのデフォルトを設定するものなので、 (latin1 な database は金輪際作らないというのでも無い限り) 変更する必要はない。

latin1 になっているもう片方の変数 「character_set_database」 は、 デフォルト database に合わせて (つまり USE コマンドを発行するごとに) サーバがこの変数を変更するので、 これもユーザが変更する必要はない。

前置きが長くなったが、これからが本題。

UTF-8 なテーブルを読み書きする際は、 「charset utf8」 コマンドを送信してクライアント側のキャラクタセットを UTF-8 に設定すればよいのであるが、 デフォルトが latin1 であるクライアントも多い。 PHP などから MySQL サーバにアクセスする場合なども、 (PHP のビルド方法にも依存するが) デフォルトは latin1 になっている (PHP の場合 mysql_client_encoding() で確認できる)。 このようなクライアントをデフォルトの latin1 のままで使うとどうなるだろうか？

クライアント側のキャラクタセットが latin1 のままで、 UTF-8 なデータをテーブルに挿入してみる:

mysql> DELETE FROM user;
Query OK, 1 row affected (0.03 sec)

mysql> INSERT INTO user VALUES ('仙石　浩明');
Query OK, 1 row affected (0.00 sec)

mysql> SELECT name, HEX(name) FROM user;
+-----------------+--------------------------------------------------------------------+
| name            | HEX(name)                                                          |
+-----------------+--------------------------------------------------------------------+
| 仙石　浩明 | C3A4C2BBE284A2C3A7C5B8C2B3C3A3E282ACE282ACC3A6C2B5C2A9C3A6CB9CC5BD |
+-----------------+--------------------------------------------------------------------+
1 row in set (0.00 sec)

文字化けせずに読み書きできているし、 同様に (latin1 な) PHP スクリプトからこのレコードを読んでも、 正しい UTF-8 な文字列として読み込むことができる。 ところが、 HEX() 演算子で文字列のコードをチェックしてみると、 全く違うコード (しかも正しい UTF-8 コードが 15バイトであるのに対し、 2倍以上長い 33バイト) になってしまっていることがわかる。

文字化けしていれば誰でも気付くし、 直そうとするので問題は少ないのであるが、 このように文字化けしない場合は、 問題が放置されたままになりかねないので注意を要する。

例えば google で検索してみると、 mysqldump で文字化けしないようにするための 「ノウハウ」 として、 「--default-character-set=latin1」 オプションを指定すればよい、 と書かれているページが沢山見つかる。 おそらく、 latin1 なクライアント (例えば PHP スクリプト) で、 非 latin1 文字列 (例えば漢字文字列) をデータベースに書込んでしまったために、 mysqldump でバックアップを取るときに latin1 を指定しないと文字化けしてしまう状況なのだろう。

もちろんこれは間違った対処法である。 UTF-8 なテーブルをバックアップするときは 「--default-character-set=utf8」 オプションを指定すべきだし、 もしこのオプションで文字化けするなら、 テーブルに格納されたデータが間違っているわけで、 修正すべきはテーブル内のデータであって、 指定するオプションではない。

上述した実行例のように、 HEX() 演算子で文字列のコードをチェックすれば、 テーブルに正しいエンコーディングで格納されているか確認できるが、 クエリ結果の罫線がずれていないかでも間違いに気付くことはできる。 上記の例ではクエリ結果に 「仙石　浩明」 という漢字文字列が正しく表示されているものの、 その次の罫線キャラクタ「|」の位置がずれている。 これは mysql クライアントが、 長さ 15 文字の latin1 文字列を出力したつもりになっていることを意味している。 その latin1 な 15 文字を、 端末側が勝手に UTF-8 な (全角) 5文字として解釈したため 「|」 の位置がずれてしまった、 というわけ。

では、なぜテーブル内のデータがこんな長大なコードになってしまうのか？

正: E4BB99E79FB3E38080E6B5A9E6988E
誤: C3A4C2BBE284A2C3A7C5B8C2B3C3A3E282ACE282ACC3A6C2B5C2A9C3A6CB9CC5BD

INSERT 文で 「仙石　浩明」 という値のレコードを挿入したとき、 送信したデータは正しい UTF-8 文字列なのであるが、 クライアント側のキャラクタセットの設定が latin1 なので、 MySQL サーバは受信したデータを latin1 文字列と見なす。 つまり、 「E4 BB 99 E7 9F B3 E3 80 80 E6 B5 A9 E6 98 8E」 というデータは 「ä » ™ ç Ÿ ³ ã € € æ µ © æ ˜ Ž」 (見易くするため文字と文字の間に空白を挟んだ) という latin1 文字列として扱われる。

「ä」 (小文字のａウムラウト) の UTF-8 コードは、 「C3 A4」 である。以下同様に、
「»」 (right-pointing double angle quotation mark) は 「C2 BB」
「™」 (trade mark sign) は 「E2 84 A2」
「ç」 (latin small letter c with cedilla) は 「C3 A7」
「Ÿ」 (latin capital letter Y with diaeresis) は 「C5 B8」
「³」 (superscript three) は 「C2 B3」
「ã」 (latin small letter a with tilde) は 「C3 A3」
「€」 (euro sign) は 「E2 82 AC」
「æ」 (latin small letter ae) は 「C3 A6」
「µ」 (micro sign) は 「C2 B5」
「©」 (copyright sign) は 「C2 A9」
「˜」 (small tilde) は 「CB 9C」
「Ž」 (latin capital letter Z with caron) は 「C5 BD」

したがって、テーブルには 「C3 A4 C2 BB E2 84 A2 C3 A7 C5 B8 C2 B3 C3 A3 E2 82 AC E2 82 AC C3 A6 C2 B5 C2 A9 C3 A6 CB 9C C5 BD」 という 33バイトの UTF-8 コードが格納される。

自宅の無線LAN を WPA2-EAP (WPA2 エンタープライズ) にして 1ヶ月になるが、 すこぶる快適。 アクセスポイントがエンタープライズモードに対応していなければいけないのと、 RADIUS サーバが必要である上、 EAP-TLS を用いる場合は SSL クライアント証明書を発行する 認証局 (CA) を作る必要まであるので、 自宅LAN での導入にはややハードルが高いが、 いったん導入してしまえば WPA/WPA2 パーソナルより手間がかからない。

WPA/WPA2 パーソナルだと、 秘密のパスワードを全ての無線LAN 端末で共有するので、 端末の台数が増えてくるとどんどん漏洩のリスクが高まる。

自宅LAN でそんなに端末があるのか？ という突っ込みが入りそうだが、 格安 NetBook や、 無線LAN 機能付スマートフォンなどを買っていると、 自宅LAN とはいえ、 「エンタープライズ」 的なニーズが出てくる。

WPA2 エンタープライズで認証方式として EAP-TLS を使うと、 無線LAN 端末にはそれぞれ個別の証明書をインポートしておくだけでよく、 万一その端末を紛失しても、 その端末の証明書を無効にするだけで済む。

EAP-TLS には対応機器/OS が多いというメリットもある。 無線LAN 端末として、 Windows VISTA, Windows XP, Ubuntu 8.04 LTS などを使ってみたが、 いずれもあっけないくらい簡単に接続できてしまった。 証明書さえインポートしておけば (Windows ならダブルクリックだけ)、 あとはパスワードを入力しなくてもいいぶん WPA/WPA2 パーソナルより設定が簡単。

既存の OS (Linux の場合はディストリビューション) で無線接続できるようになったので、 次は私が独自に構築した GNU/Linux (いわば my distribution) 上で WPA2 EAP-TLS 接続を試みた。

まず wpa_supplicant 0.5.11 をダウンロードしてコンパイル。 続いて設定ファイルである wpa_supplicant.conf を書く。

network={
	ssid="XXXXXXXXXX"
	key_mgmt=WPA-EAP
	eap=TLS
	identity="olevia"
	ca_cert="/usr/local/ssl/certs/GCD_Root_CA.pem"
	client_cert="/usr/local/ssl/certs/olevia.pem"
	private_key="/usr/local/ssl/private/olevia.pem"
	private_key_passwd=""
}

「ca_cert=」 「client_cert=」 「private_key=」 にそれぞれ CA の公開鍵、端末の公開鍵、端末の秘密鍵のファイル名を指定している。 で、wpa_supplicant を実行。

# wpa_supplicant -i eth1 -c /etc/wpa_supplicant.conf -d -D wext
Initializing interface 'eth1' conf '/etc/wpa_supplicant.conf' driver 'wext' ctrl_interface 'N/A' bridge 'N/A'
Configuration file '/etc/wpa_supplicant.conf' -> '/etc/wpa_supplicant.conf'
Reading configuration file '/etc/wpa_supplicant.conf'
Priority group 0
   id=0 ssid='XXXXXXXXXX'
Initializing interface (2) 'eth1'
EAPOL: SUPP_PAE entering state DISCONNECTED
EAPOL: KEY_RX entering state NO_KEY_RECEIVE
EAPOL: SUPP_BE entering state INITIALIZE
EAP: EAP entering state DISABLED
	...(中略)...

wpa_supplicant はデバッグモード (-d オプション) にすると大量のログを出力するので動作を追いにくいが、 wpa_supplicant のプログラムは状態遷移機械 (オートマトン) として動作するよう書かれているので、 「EAP: EAP entering state」 の部分を追っていくとよい。 「DISABLED」 と出力されているのが、 その時点におけるオートマトンの状態。

状態遷移機械 (オートマトン) と言ってしまうと、 コンピュータ/プログラムは全てオートマトンなのであるが (^^;)、 プログラミングの方法として状態遷移機械 (state machine) と言うときは、 各状態に名前を付けて、 各状態ごとの動作を (switch 文や if ... else if ... 文などで) 分けて書く方法を指す。

状態には INITIALIZE, DISABLED, IDLE, RECEIVED, GET_METHOD, METHOD, SEND_RESPONSE, DISCARD, IDENTITY, NOTIFICATION, RETRANSMIT, SUCCESS, FAILURE の 13状態がある。 もちろん 「SUCCESS」 が受理状態。 SUCCESS 状態は、 アクセスポイントが接続を許可した状態を意味する。

ところが、ログを追っていくと、

EAP: EAP entering state RECEIVED
EAP: Received EAP-Success
EAP: EAP entering state FAILURE
CTRL-EVENT-EAP-FAILURE EAP authentication failed

FAILURE 状態 (非受理状態) に遷移している (*_*)。当然、接続できず。
その直前に 「Received EAP-Success」 と出ているにもかかわらず！

アクセスポイント側 (正確に言うと RADIUS サーバ) のログを調べてみると、 ちゃんと接続を許可している (EAP-Success を送っているのだから当然だが)。 一体これはどうしたことか？

私がコンパイルした wpa_supplicant に問題があるのかと思って、 この wpa_supplicant を、 既に接続できることが確認済みの Ubuntu 上にコピーして実行してみる。 「Received EAP-Success」 をログの中から探してみると、

EAP: EAP entering state RECEIVED
EAP: Received EAP-Success
EAP: EAP entering state SUCCESS
CTRL-EVENT-EAP-SUCCESS EAP authentication completed successfully

ちゃんと SUCCESS 状態に遷移しているし、接続もできた。
同一バイナリなのに、異なる環境 (ディストリビューション) だと、 どうして結果が異なるのか？

どのような可能性が考えられるだろうか？ 腕に覚えがあるかたは、 この続きを見ずに (といっても、既にタイトルでネタバレしてしまっているが ^^;) 原因を推測してみてはいかがだろうか？

同一バイナリと言っても、 動的リンクしているので、 リンクしているライブラリは異なる。

% ldd /usr/local/sbin/wpa_supplicant
	linux-gate.so.1 =>  (0xffffe000)
	libssl.so.0.9.8 => /usr/local/lib/libssl.so.0.9.8 (0xf7f68000)
	libcrypto.so.0.9.8 => /usr/local/lib/libcrypto.so.0.9.8 (0xf7e41000)
	libdl.so.2 => /lib/libdl.so.2 (0xf7e3d000)
	libc.so.6 => /lib/libc.so.6 (0xf7d0b000)
	/lib/ld-linux.so.2 (0xf7fbf000)

OpenSSL のライブラリである libssl.so.0.9.8 と libcrypto.so.0.9.8 が怪しそう。 試しにこの 2 ファイルを Ubuntu 上へコピーしてみる。 wpa_supplicant を再度実行してみると、 果たせるかな FAILURE 状態に遷移した。

といってもこの 2 ライブラリに問題があると決めつけるのは早計である。 実はこのライブラリは、 アクセスポイントが使用している RADIUS サーバにあるものと同一のもの (RADIUS サーバも、私独自の my distribution 上で動いている)。 もしこのライブラリに問題があるなら他でも問題が出るはず。 一応、 念のため OpenSSL のバージョンを最新版の 0.9.8i に上げてみたが、 症状は変わらず FAILURE 状態に遷移する。

もうちょっとログを詳しく調べてみることにした。 SUCCESS に遷移するログ (Ubuntu に含まれる OpenSSL ライブラリを使用) と、 FAILURE に遷移するログ (自前でコンパイルしたライブラリを使用) とを、 「Received EAP-Success」 の時点から遡って比較してみる。

Ubuntu に含まれる OpenSSL ライブラリを使った場合:

EAP: EAP entering state METHOD
SSL: Received packet(len=69) - Flags 0x80
SSL: TLS Message Length: 59
SSL: (where=0x1001 ret=0x1)
SSL: SSL_connect:SSLv3 read finished A
SSL: (where=0x20 ret=0x1)
SSL: (where=0x1002 ret=0x1)
SSL: 0 bytes pending from ssl_out
OpenSSL: tls_connection_handshake - Failed to read possible Application Data error:00000000:lib(0):func(0):reason(0)
SSL: No data to be sent out
EAP-TLS: Done
EAP-TLS: Derived key - hexdump(len=64): [REMOVED]
EAP-TLS: Derived EMSK - hexdump(len=64): [REMOVED]
SSL: Building ACK
EAP: method process -> ignore=FALSE methodState=DONE decision=UNCOND_SUCC
EAP: EAP entering state SEND_RESPONSE

METHOD 状態というのは、 Server Hello メッセージ (SSL 通信開始時のハンドシェークを参照) の中の compression_method を読み終えた状態。 compression_method は Server Hello メッセージの最後のデータなので、 ログに 「SSL: SSL_connect:SSLv3 read finished A」 と出力し、 wpa_supplicant は続いて送信状態 SEND_RESPONSE へ遷移する。

一方、自前でコンパイルした OpenSSL ライブラリを使った場合:

EAP: EAP entering state METHOD
SSL: Received packet(len=1024) - Flags 0xc0
SSL: TLS Message Length: 1290
SSL: Need 276 bytes more input data
SSL: Building ACK
EAP: method process -> ignore=FALSE methodState=MAY_CONT decision=FAIL
EAP: EAP entering state SEND_RESPONSE

METHOD 状態に遷移して compression_method を読み終えたはずなのに、 まだデータがある (Need 276 bytes more input data)。

...というところまでログの意味が理解できた時点で、 原因に思い当たった。 後者は Server Hello メッセージではなく、 Extended Server Hello メッセージだった。 Extended Server Hello メッセージにおいては、 compression_method が最後ではなく server_hello_extension_list が後に続く (RFC 3546 参照)。

なぜ同じ RADIUS サーバが Server Hello メッセージを送信したり、 Extended Server Hello メッセージを送信したり、 という違いが生じるかと言えば、 Ubuntu に含まれるライブラリを使った場合は、 wpa_supplicant が Client Hello メッセージを送信するのに対し、 自前でコンパイルしたライブラリを使った場合は、 Extended Client Hello メッセージを送信するから。

つまり、私が OpenSSL をコンパイルするときは、 TLS拡張 (TLS Extensions, RFC 3546) のサポートを有効にしていたから、 このような差が生じたのだった (RADIUS サーバが使用する OpenSSL も TLS拡張のサポートを有効にしていた、という点もミソ)。 だから、試しに TLS拡張のサポートを無効にして OpenSSL をコンパイルし直してみると、 無事 SUCCESS 状態に遷移して接続することができた。

動的ライブラリで TLS拡張のサポートを無効にしてしまうと、 TLS拡張を使用するプログラム (例えば stone) を実行するとき困るので、 TLS拡張のサポートを無効にしたライブラリを、 wpa_supplicant と静的リンクしておくことにした。

OpenSSL 側で TLS拡張のサポートを無効にすれば対処できるとはいえ、 wpa_supplicant が正しく Extended Server Hello メッセージを解釈できたほうが、 より望ましいに違いない。

そこで、 開発元のバグ報告ページ に、 バグレポートを出してみた:

Summary: wpa_supplicant linked with TLSEXT-enabled OpenSSL always fails in WPA-EAP

wpa_supplicant linked with TLSEXT-enabled OpenSSL 0.9.8i always enters
`state FAILURE' in WPA-EAP although radius server authorizes.

OpenSSL supported TLS Extensions (RFC 3546) since 0.9.8 and if you want
to make TLSEXT enabled OpenSSL library, do:

  $ ./config enable-tlsext
  $ make

With this library, wpa_supplicant sends Extended Client Hello (see RFC
3546 Section 2.1), then TLSEXT-enabled radius server*1 responds with
Extended Server Hello (Section 2.2).  But unfortunately
wpa_supplicant-0.5.11 won't expect `server_hello_extension_list' field
in the Extended Server Hello, and enters the state FAILURE in spite of
receiving EAP-Success.

*1 TLSEXT-disabled radius server simply ignores
   `client_hello_extension_list' field in Extended Client Hello

EAP: EAP entering state RECEIVED
EAP: Received EAP-Request id=9 method=13 vendor=0 vendorMethod=0
EAP: EAP entering state METHOD
SSL: Received packet(len=1024) - Flags 0xc0
SSL: TLS Message Length: 1290
SSL: Need 276 bytes more input data
SSL: Building ACK
EAP: method process -> ignore=FALSE methodState=MAY_CONT decision=FAIL
EAP: EAP entering state SEND_RESPONSE
EAP: EAP entering state IDLE
EAPOL: SUPP_BE entering state RESPONSE
EAPOL: txSuppRsp
EAPOL: SUPP_BE entering state RECEIVE
RX EAPOL from XX:XX:XX:XX:XX:XX
EAPOL: Received EAP-Packet frame
EAPOL: SUPP_BE entering state REQUEST
EAPOL: getSuppRsp
EAP: EAP entering state RECEIVED
EAP: Received EAP-Success
EAP: EAP entering state FAILURE
CTRL-EVENT-EAP-FAILURE EAP authentication failed

I examined wpa_supplicant linked with TLSEXT-disabled OpenSSL library,
and it works perfectly.

そもそも、なぜ init(8) を起動する前に /bin/sh を実行したいかというと、 ミニルート (initramfs) 上で 作業を行ないたいから。 initramfs の init (これは init(8) ではなくシェル・スクリプト) の中で、 BusyBox の /bin/sh (/bin/ash) を exec する (つまり PID=1) ことによって、 initramfs 上での作業を可能にする。

init(8) は、 GNU/Linux OS の全てのプロセスの親プロセスだが、 その万物の親すら生まれていない創世記以前に作業を行なえるメリットは数多い。 例えば、ルート・ファイル・システム (root file system) すらマウントしていない段階なので、 マウント後 (つまり init(8) 起動後) には実行不可能な操作 (xfs_repair などのファイルシステム修復操作とか) を行なうことができる。 しかもこのシェルはプロセスID が 1番なので、 このシェル環境上で root file system を「/」にマウントし、 続いて init(8) を exec すれば、 そのまま GNU/Linux OS を起動することができる。

root file system のメンテナンス等は、 別の起動ディスク (CD-ROM や USB メモリ等) からブートして行なうのが一般的だが、 CD-ROM ドライブや USB メモリを準備したり、 あるいは CD-ROM や USB メモリの抜き差しが必要になったりと、 なにかと面倒である。 メンテナンス用の起動パーティションを root file system とは別に用意する、 という方法も考えられるが、 メンテナンス専用のパーティションを維持管理するのが面倒くさい (普段使わないものほど陳腐化して、いざというとき役に立たない)。
initramfs だとハードディスクすら不要 (例えば PXE ブート) でメンテナンスが可能になるし、 普段 GNU/Linux OS 起動用として使ってる initramfs が、 そのまま非常用のメンテナンス環境になるため、 陳腐化する心配がない。
実は「突然死したハードディスクを復旧させる『お手軽パック』」は、 initramfs そのものだったりする。 しかも「復旧」用として作った initramfs というわけではなく、 私が普段 GNU/Linux OS を ブートするときに使っている initramfs と 全く同じものである (だからこそ ハードディスクの突然死問題 が勃発した直後にリリースできた)。

というわけで、 いいことづくめの initramfs シェル環境 (initramfs shell environment) なのだが、 「復旧お手軽パック」実行例 にもあるように、 init(8) 以前の段階で /bin/sh を実行すると

/bin/sh: can't access tty; job control turned off
#

と表示してジョブ制御がオフになってしまう。 つまりこのシェル環境では、 プログラムを実行中に control-C (^C) を押しても止める (正確にいうと SIGINT シグナルを送る) ことができない。

ジョブ制御 (^C などでシグナルを送ること) ができない状態に陥って 初めて沸き起こる制御端末 (controlling tty) に対する感謝の念なのであるが、 initramfs が役目を終えて init(8) が起動して (GNU/Linux OS がブートして) しまうと、 喉元過ぎればなんとやらで 「can't access tty」をなんとかしようという意欲は雲散霧消し、 そのままになっていた。

制御端末になれない initramfs シェル環境に対して何十回目かの悪態をついた後、 ようやく対策を立てるべく原因を調べてみることにした。

Linuxカーネル（ドライバ）のソースを読んでみたところ、 以下の端末デバイスは制御端末に成れないのです。 興味がある人は、ソース、 drivers/char/tty_io.cのtty_open()を見てみてください。

* /dev/console -- カーネルの起動時の端末。
* /dev/tty0 -- tty1～の「Linux Virtual Terminal」のうち、現在表示している物を示す。
* /dev/tty -- 現在使っている端末を示す。
* PTYのマスター側

Linux:制御端末 から引用

initramfs シェル環境で使っている端末は /dev/console だから制御端末になれない。 だから BusyBox には /dev/console という仮想的な端末ではなく、 本物のデバイスを探すための cttyhack というプログラムが付属している。 /bin/sh を実行する代わりに cttyhack /bin/sh を実行すれば ジョブ制御ができると BusyBox のマニュアルには書いてある。

...という解説は上に引用したページをはじめ、 WWW 上のあちらこちらのページで見かけるし、 私としても当然そんなことは先刻承知で、

/bin/sh: can't access tty; job control turned off
# tty
/dev/console
# cttyhack sh
sh: can't access tty; job control turned off
# tty
/dev/tty1
#

などと、確かに cttyhack の働きにより /dev/console ではなく /dev/tty1 を使うようになったものの、 相変わらず「can't access tty」エラーが出ているので困っているわけである。 cttyhack を使っているのにジョブ制御できないわけで、 cttyhack-- と思っていた。

前置きが長くなったが、ここからが本題である。

Last night, I finally succeeded in vanquishing the dread "can't access tty; job control turned off" message. As it turns out, there are several discrete steps involved in the creation of a controlling terminal, and they're all seemingly mandatory:

Turning on job control から引用

「昨晩ついに、 恐怖の "can't access tty; job control turned off" メッセージを抑えつけた!」 という書き出しに、 いやがおうにも期待が高まる。 この、TTY を制御端末にするための必須条件とやらは、 今まで日本語での記述を見たことがないので、 訳してみる:

1. session owner かつ process group leader でなければならない。 つまり前もって setsid(2) を呼び出しておく必要がある (もし既に別の制御端末を持っていたら、先に捨てる)。
2. /dev/console などカーネルが提供する仮想的な端末ではなく、 /dev/tty1 など「本物の」TTY デバイスでなければならない。 /dev/console が制御端末になれないのは、 Linux カーネル ML での議論 によれば、init を CTRL-ALT-DEL に応答させる方法に関する歴史的理由による。 もし /dev/console が制御端末だったら、 CTRL-C が効いてブートスクリプトを止めることが可能になってしまう。
3. CTRL-C, CTRL-Z その他ものもろのキーが入力できる TTY でなければならない。
4. TIOCSCTTY ioctl を行なうことによって、 標準入力の TTY を制御端末にすることができる。

つまり cttyhack が解決できるのは上記条件のうち 2番目の条件だけで、 1番目の条件は満たしていない。 そこで、cttyhack を呼ぶ前に setsid してみる:

# setsid cttyhack sh
# ping 127.0.0.1
PING 127.0.0.1 (127.0.0.1): 56 data bytes
64 bytes from 127.0.0.1: seq=0 ttl=64 time=0.077 ms
^C
--- 127.0.0.1 ping statistics ---
1 packets transmitted, 1 packets received, 0% packet loss
round-trip min/avg/max = 0.077/0.077/0.077 ms
#

お～ ついにあの忌まわしい「can't access tty; job control turned off」 エラーが表示されなくなり、 ^C でプログラムの実行を止められるようになった。

結局、鍵は setsid にあったわけで、 「setsid cttyhack」をキーに検索してみると、 同様の話が他にも見つかった:

setsid cttyhack ash
This makes the ash error about job control go away,
and "echo Hi > /dev/tty" now works.

setsid cttyhack ash から引用

じゃ、なんで cttyhack は自前で setsid しないかというと、 cttyhack は init(8) から呼び出されることを前提としているからのようだ:

On Fri, Dec 07, 2007 at 01:17:57PM -0800, Lombard, David N wrote:
> Hmmm. cttyhack doesn't do:
>
> setsid()
> ioctl(0,TIOCSCTTY,1)

Did you set CONFIG_FEATURE_INIT_SCTTY? There's conditionally compiled code in init to do the above, see init/init.c

CTRL-C - Make the hurting stop から引用

init(8) 起動前だからこそ、 initramfs シェル環境は有用であると思うのだが、 そのような initramfs の使い方は、 まだ一般的にはなっていないのだろう。

現在、ＩＰｖ６映像視聴等機能は「フレッツ・ドットネット」にて 提供しておりますが、 平成２０年３月３日（月）以降は、 ブロードバンド映像サービスのみ をご利用の場合は、 「フレッツ・ドットネット」のご契約が不要になります。 これにより解約を希望されるお客さまにつきましては、 平成２０年３月３日（月） より※３受付を開始いたします。 　なお、ブロードバンド映像サービス以外で、 「FdNネーム」「FdNディスク」「FdNディスクビューセレクト」「FdNナンバー」等 「フレッツ・ドットネット」サービス※４をご利用の際には、 引き続き「フレッツ・ドットネット」のご契約が必要となりますのでご注意ください。

私は IPv6 機能のためだけに「フレッツ・ドットネット」を契約していて、 「FdNネーム」「FdNディスク」「FdNディスクビューセレクト」「FdNナンバー」等の サービスを利用したことはない (「ブロードバンド映像サービス」も利用していない) ので、 フレッツ・スクウェアトップから、 サービス申込受付を選んで、「フレッツ・ドットネット」を解約した。

ところが！

フレッツ網側の v6 ルータが ping に反応しなくなった。

senri % ping6 -n router.flets.gcd.org
PING router.flets.gcd.org(2001:c90:XXXX:XXXX:2d0:2bff:fe30:b91a) 56 data bytes
From 2001:c90:XXXX:XXXX:2d0:2bff:fe30:b91a icmp_seq=1 Destination unreachable: Administratively prohibited
From 2001:c90:XXXX:XXXX:2d0:2bff:fe30:b91a icmp_seq=2 Destination unreachable: Administratively prohibited

--- router.flets.gcd.org ping statistics ---
2 packets transmitted, 0 received, +2 errors, 100% packet loss, time 1000ms

ちなみに、 この v6 ルータからの router advertisement は正常に流れてきている:

senri # tcpdump -i eth1 -vvv ip6
tcpdump: listening on eth1, link-type EN10MB (Ethernet), capture size 96 bytes
	...
13:02:02.904899 fe80::2d0:2bff:fe30:b91a > ff02::1: icmp6: router advertisement(chlim=64, pref=medium, router_ltime=1800, reachable_time=0, retrans_time=0)(src lladdr: 00:d0:2b:30:b9:1a)(mtu: mtu=1500)[ndp opt] [class 0xe0] (len 64, hlim 255)

v6 ルータ越えの通信が全て禁止されてしまったらしく、 フレッツ網に接続している他サイトとの IPv6 通信も同様に禁止されて (Administratively prohibited) しまった。 例外は、フレッツ・スクウェアv6 へのアクセス:

senri % ping6 -n flets-v6.jp
PING flets-v6.jp(2001:c90:ff:1::1) 56 data bytes
64 bytes from 2001:c90:ff:1::1: icmp_seq=1 ttl=52 time=5.05 ms
64 bytes from 2001:c90:ff:1::1: icmp_seq=2 ttl=52 time=4.55 ms

--- flets-v6.jp ping statistics ---
2 packets transmitted, 2 received, 0% packet loss, time 1001ms
rtt min/avg/max/mdev = 4.554/4.803/5.053/0.258 ms

おそらく「ブロードバンド映像サービス」を提供するサーバへの IPv6 通信も 許可されているのだろう。 つまり、 「ＢフレッツにＩＰｖ６映像視聴等機能を標準装備」 という NTT東日本の発表のココロは、 IPv6 映像サービスへの IPv6 通信＊のみ＊許可するということであって、 それ以外の IPv6 通信は対象外ということのようだ。

「フレッツ・ドットネット」サービスの概要には、 「フレッツ・ドットネットサービス機能一覧」として、

・FdNネームが1つ利用できます。
・FdNディスク(100MB)で、ファイル共有が利用できます。
・FdNディスク(100MB)には、最大10のグループメンバーを登録できます。
※NTT東日本が無料で提供する専用ソフトウェア「FLET'S.Netメッセンジャーにより、 ファイル転送やビデオチャットが利用できます。

が列挙されているのみであって、 IPv6 通信の許可/不許可について言及していないのは、 とてもミスリーディングな記述だと思う。

慌てて再度フレッツ・ドットネット契約を (フレッツ・スクウェアで) 申込むと、 10分ほどで再び IPv6 通信ができるようになった:

senri % ping6 -n router.flets.gcd.org
PING router.flets.gcd.org(2001:c90:XXXX:XXXX:2d0:2bff:fe30:b91a) 56 data bytes
64 bytes from 2001:c90:XXXX:XXXX:2d0:2bff:fe30:b91a: icmp_seq=1 ttl=64 time=3.11 ms
64 bytes from 2001:c90:XXXX:XXXX:2d0:2bff:fe30:b91a: icmp_seq=2 ttl=64 time=0.920 ms

--- router.flets.gcd.org ping statistics ---
2 packets transmitted, 2 received, 0% packet loss, time 1001ms
rtt min/avg/max/mdev = 0.920/2.019/3.118/1.099 ms

フレッツ網を経由した IPv6 通信を利用しているかたは、 たとえフレッツ・ドットネットサービスを利用していなくても、 フレッツ・ドットネットを解約すべきではないので、 ご注意のほどを！