プログラミングと開発環境
2008年07月03日「故障した HDD WD10EACS を RMA (Return Merchandise Authorization, 返却承認) 手続きで交換してみた」で書いたように、 RMA 手続きを行なった上で Western Digital へ故障したハードディスク ドライブ (以下 HDD と略記) を送ったら、 激しく文字化けしたメールが送られてきた。
あとは HDD が送られてくるのを のんびり待つだけと思っていたら、 わずか一日後 6/26 18:44 に Western Digital からメールが来た。 しかし文字化けがひどくて読めない。 最初は何語で書いてあるかすら判然としなかったのだが、 どうやら Shift JIS で書かれた文面を quoted-printable エンコードする際に なにか問題があったようだ。 例えば 0x82 が「,」に、0x95 が「.」に置き換わってしまっている。 置換が規則的でないので、 暗号解読よろしく一文字一文字置き換え規則を推測していくしかない。
文面を再現するのに時間がかかりそうだなぁ〜と思っている間に、 交換品の HDD が届いてしまったので、 「暗号」解読するモチベーションを失ってしまっていたのだが、
Posted by 通りすがり 2008年07月02日 00:36
結局、メールにはなんて書いてあったのでしょうか？同ページ コメント欄 から引用
というコメントを頂いてしまったので、 暗号解読してみることにした。
以下、Western Digital からの文字化けメールを全文引用 (一部伏字) する:
From: "Western Digital RMA" <noreply@wdc.com>
To: <sengoku@gcd.org>
Date: Thu, 26 Jun 2008 02:44:25 -0700
MIME-Version: 1.0
Content-Type: text/plain;
charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
X-Mailer: Microsoft CDO for Windows 2000
Content-Class: urn:content-classes:message
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1896
X-OriginalArrivalTime: 26 Jun 2008 09:44:25.0728 (UTC) FILETIME=[3861F800:01C8D771]
HIROAKI SENGOKU -l,=D6=81A
^=C8?=BA,=C9.\Z=A6,=B3,=EA,=BD RMA =
,=CCfXfe=81[f^fX,=F0Sm"F,=B5,=C4,=AD,=BE,=B3,=A2=81B RMA
,=C9S=D6,=B7,=E9,=A8-=E2,=A2=8D?,=ED,=B9,=CD,=B1,=CCf=81=81[f<,=C9.=D4=90=
M,=B5,=C4,=AD,=BE,=B3,=A2=81B
=8F=EE.=F1,=AA=90=B3,=B5,=A2=8F=EA=8D?=81A,=B1,=CC"dZqf=81=81[f<,=C9,=CD.=
=D4=90M,=B5,=C8,=A2,=C5,=AD,=BE,=B3,=A2=81B
RMA "=D4=8D?=81F 8083XXXX
--------------------------------------------------------------
O=F0S=B7fhf?fCfu,=F0 5=81`7 ?c<=C6"=FA'?,=C9"=AD'-,=B5,=DC,=B7=81B
^=C8?=BA,=CCfhf?fCfu,=F0 Western Digital =
,=CDZ=F3-=CC,=B5,=DC,=B5,=BD=81F
fVfSfAf<"=D4=8D? =90=BB.i"=D4=8D? =
Z=F3-=CC"=FA=81iGMT=81j
------------ --------------- -------------
WCASJxxxxxxx WD10EACS-00ZJB0 6/25/2008
--------------------------------------------------------------
^=C8?=BA,=C9.\Z=A6,=B3,=EA,=BD RMA =
"=AD'-=8F=F3<=B5,=F0Sm"F,=B5,=C4,=AD,=BE,=B3,=A2=81B
-A'-<=C6Z=D2,=CCfVfXfef?,=CC=8DX=90V,=C91?c<=C6"=FA,=AA,=A9,=A9,=E8=81A,=BB=
,=CCO=E3"=AD'-'=C7=90=D5"=D4=8D?,=AA-LO=F8,=C9,=C8,=E8,=DC,=B7,=CC,=C5=81=
A,=B2-=B9=8F=B3,=AD,=BE,=B3,=A2=81B
O=F0S=B7fhf?fCfu,=CC'-.t=90=E6=81F
HIROAKI SENGOKU
XXXXXXXXXXXXXXXXXXXXXXXXX TAKATSU
KAWASAKI, Japan 213-XXXX
JAPAN
"z'-<=C6Z=D2=81F Fedex
"z'-'=C7=90=D5"=D4=8D?=81F XXXXXXXXXXXX
fVfSfAf<"=D4=8D? =90=BB.i"=D4=8D? =
"=AD'-"=FA=81iGMT=81j
------------ --------------- -------------
WCASJXXXXXXX WD10EACS-32ZJB0 6/26/2008
--------------------------------------------------------------
S=D6~AfSf"fN=81F
RMAZ=E8=8F?ZwZ=A6=8F=EE.=F1,=CC?{--/^=F3=8D=FC
- =
http://websupport.wdc.com/rd.asp?t=3D102&l=3Djp&p=3Dm&r=3D8083XXXX&f=3De
"=AD'-,=C6=8D=AB.=EF,=CC=8F=EE.=F1
- http://websupport.wdc.com/rd.asp?t=3D103&l=3Djp&p=3Drp
RMAfXfe=81[f^fX,=CC?{--
- =
http://websupport.wdc.com/rd.asp?t=3D104&l=3Djp&p=3Dv&r=3D8083XXXX&z=3D21=
3-XXXX
Western Digital fTf|=81[fgfz=81[f?fy=81[fW
- http://websupport.wdc.com/rd.asp?t=3D105&l=3Djp&p=3Dh
^=C8=8F=E3=81A
WD RMA f`=81[f?
http://websupport.wdc.com/rd.asp?t=3D105&l=3Djp&p=3Dh
ヘッダに「quoted-printable」と書いてあるとおり、 quoted-printable エンコーディングを行なったのだろうが、 のっけから「^=C8?=BA,=C9.\Z=A6,=B3,=EA,=BD」となっていて、 一体何語なんだ？と思わせる始まり方である。
ちなみに quoted-printable というのは 8bit データを、 「印字可能 (printable)」つまり 7bit の英数字・記号だけで表現するための方法 (エンコーディング) で、 印字可能でない 8bit データは 16進数で表わして前に「=」をつける (「=」自身は「=3D」で表現する)。 例えば「^=C8?=BA,=C9.\Z=A6,=B3,=EA,=BD」は、 16進数で書くと 「5E C8 3F BA 2C C9 2E 5C 5A A6 2C B3 2C EA 2C BD」 という 8bit データ列を意味する。
腕に覚えのあるかたは、解答を見ずに解読を試みてはいかがだろうか？
続きを読む 2008年05月12日64bit Linux (x86_64 別名 amd64) は、 CONFIG_IA32_EMULATION を有効にしておくことにより、 32bit プログラム (i386 別名 ia32) を走らせることができる。 したがって 64bit へ移行する際は、 全プログラムを一度に 64bit 化する必要はなく、 まずカーネルだけ 64bit 化しておいて、 各プログラムは (バージョンアップの機会などに) 徐々に 64bit 化していけばよい。 ただし 32bit プログラムがカーネルの機能を呼び出す場合は、 各機能それぞれが 32bit プログラムからの呼び出しに対応していることが前提となる。
32bit プログラムからの呼び出しに対応するといっても、 基本的には引数の型を変換するだけである。 x86_64 の整数データモデルは LP64、 つまり long int 型とポインタ型が 64bit で (引数の型として多用される) int型は 32bit のままなので、 変換が不要なケースも多い。
例えば ioctl システムコールはファイル・ディスクリプタ (file descriptor, 以下 fd と略記) ごとに カーネルが実行すべき機能は変わってくるわけで、 その実装は各デバイス・ドライバに委ねられることが多い。 したがって 32bit プログラムからの ioctl 呼び出しに応えられるか否かは、 各ドライバが 32bit 対応しているか否かに依存する。 不幸にしてドライバが対応していない場合は、
ioctl32(tv:11028): Unknown cmd fd(5) cmd(40045613){t:'V';sz:4} arg(081ec8b4) on /dev/video0
などといったカーネル・メッセージ (dmesg) が出力される。 このメッセージは、 カーネル・ソース中 fs/compat_ioctl.c の compat_ioctl_error が出力している:
static void compat_ioctl_error(struct file *filp, unsigned int fd,
unsigned int cmd, unsigned long arg)
{
...
compat_printk("ioctl32(%s:%d): Unknown cmd fd(%d) "
"cmd(%08x){t:%s;sz:%u} arg(%08x) on %s\n",
current->comm, current->pid,
(int)fd, (unsigned int)cmd, buf,
(cmd >> _IOC_SIZESHIFT) & _IOC_SIZEMASK,
(unsigned int)arg, fn);
...
}
fs/compat_ioctl.c は 32bit 版 ioctl システムコールを実装していて、 32bit プログラムが ioctl システムコールを呼び出すと、 この中の compat_sys_ioctl ルーチンが呼ばれる:
asmlinkage long compat_sys_ioctl(unsigned int fd, unsigned int cmd,
unsigned long arg)
{
...
if (filp->f_op && filp->f_op->compat_ioctl) {
error = filp->f_op->compat_ioctl(filp, cmd, arg);
if (error != -ENOIOCTLCMD)
goto out_fput;
}
...
compat_ioctl_error(filp, fd, cmd, arg);
...
out_fput:
fput_light(filp, fput_needed);
out:
return error;
}
つまりドライバ側で file 構造体の compat_ioctl 関数ポインタ (filp->f_op->compat_ioctl) が定義されていればそれが呼ばれ、 未定義ならば上記のような「Unknown cmd」エラーが出力される。
ちなみにこのエラーメッセージの「tv:11028」は、 ioctl を呼び出した 32bit プロセスの名前 (コマンド名) とプロセスID であり、 fd(5), cmd(40045613), arg(081ec8b4) は、 それぞれ ioctl システムコールの第一 (つまり fd 番号)、 第二 (ioctl リクエスト番号)、第三引数 (ioctl リクエストの引数) であり、 最後の on /dev/video0 は (第一引数の) fd 番号に対応するファイルのパス名である。
そして、この tv コマンドは 「ビデオキャプチャ・カード GV-MVP/RX2W を使って Linux 2.6.24.4 でテレビ録画」で紹介した perl スクリプト であり、 その名称から推測できるとおりテレビ録画を行なうためのスクリプトである。
このスクリプトでは Video::ivtv モジュールを利用していて、 このモジュールが /dev/video0 つまり TV キャプチャ・デバイスに対して、 ioctl システムコールを呼び出している。 上記エラーはスクリプト中 $IvTV->stopEncoding($TunerFD); を実行したときに発生した。
その名称から推測できる通り、 stopEncoding メソッドはキャプチャ・デバイスに対して エンコーディングの停止を指示するためのもので、 内部で ioctl(fd, VIDIOC_STREAMOFF) などと ioctl 呼び出しを行なっている。 VIDIOC_STREAMOFF は videodev2.h にて、
#define VIDIOC_STREAMOFF _IOW ('V', 19, int)
と定義されていて、このマクロを展開すると 40045613 (16進) となり、 上記カーネル・メッセージ「cmd(40045613)」と一致する。
というわけで、(少なくとも Linux 2.6.24.7 に含まれる) ivtv ドライバは、 残念ながら 32bit 対応していないことが分かった。 もちろん x86_64 なカーネルではなく、 i386 カーネルを使えば 32bit プログラムから ivtv ドライバを使うことができるが、 x86_64 なカーネルでは、32bit プログラムからの ioctl システムコールを 64bit カーネルが受付けられる形に変換できないということだ。
とはいうものの、 32bit だろうが 64bit だろうが ioctl のインタフェースに大した変わりはないはずだ。 どうして ivtv ドライバは 32bit 呼び出しをサポートしていないのだろう？ と 思いながらドライバのソースを眺めていると... drivers/media/video/compat_ioctl32.c を見つけた。 名前からしていかにも 32bit 版 ioctl のように見える。
compat_ioctl32.c の中の v4l_compat_ioctl32 ルーチンは、 32bit な ioctl 呼び出しを受付けて 引数を 64bit へ変換し (といっても int 型はどちらも 32bit だが)、 本来の (64bit な) ioctl を呼び出し直す仕組みになっている。 なぜ ivtv ドライバは、このルーチンを利用していないのだろうか。
static int do_video_ioctl(struct file *file, unsigned int cmd, unsigned long arg)
{
...
/* First, convert the command. */
switch(cmd) {
...
case VIDIOC_STREAMOFF32: realcmd = cmd = VIDIOC_STREAMOFF; break;
};
switch(cmd) {
...
case VIDIOC_STREAMOFF:
err = get_user(karg.vx, (u32 __user *)up);
compatible_arg = 1;
break;
...
};
if(err)
goto out;
if(compatible_arg)
err = native_ioctl(file, realcmd, (unsigned long)up);
else {
mm_segment_t old_fs = get_fs();
set_fs(KERNEL_DS);
err = native_ioctl(file, realcmd, (unsigned long) &karg);
set_fs(old_fs);
}
...
return err;
}
long v4l_compat_ioctl32(struct file *file, unsigned int cmd, unsigned long arg)
{
...
ret = do_video_ioctl(file, cmd, arg);
break;
...
return ret;
}
ざっと見た感じ、 ivtv ドライバからこの v4l_compat_ioctl32 ルーチンを呼んでも 特に問題は無いように思われる。
そこで、ivtv ドライバの file 構造体 (の中の file_operations 構造体) の compat_ioctl 関数ポインタに、 v4l_compat_ioctl32 を設定してみた。
--- linux-2.6.24.5.org/drivers/media/video/ivtv/ivtv-streams.c 2008-01-25 07:58:37.000000000 +0900
+++ linux-2.6.24.5/drivers/media/video/ivtv/ivtv-streams.c 2008-05-04 09:10:07.581416212 +0900
@@ -49,6 +49,7 @@
.write = ivtv_v4l2_write,
.open = ivtv_v4l2_open,
.ioctl = ivtv_v4l2_ioctl,
+ .compat_ioctl = v4l_compat_ioctl32,
.release = ivtv_v4l2_close,
.poll = ivtv_v4l2_enc_poll,
};
@@ -59,6 +60,7 @@
.write = ivtv_v4l2_write,
.open = ivtv_v4l2_open,
.ioctl = ivtv_v4l2_ioctl,
+ .compat_ioctl = v4l_compat_ioctl32,
.release = ivtv_v4l2_close,
.poll = ivtv_v4l2_dec_poll,
};
このパッチをあてることにより、 x86_64 なカーネル上で i386 な Video::ivtv モジュールを使って、 ビデオキャプチャ・カード GV-MVP/RX2W を コントロールすることができるようになった。 一週間ほど使ってみた (多数の TV 番組を予約録画した) が、 今のところ問題は起きていない。
2007年12月25日「10行でできる高精度ハードウェア自動認識」にコメントを頂いた:
最近の modprobe は、 自分で勝手に modules.alias を探してくれるようになっているようです。 この機能を使うと、 より簡単かつ高速に自動認識が可能になります。
そうだったのか... orz
いままで、 modules.alias から modporbe すべきモジュールを検索するために、 以下のような感じで sh スクリプト (/tmp/dev2mod) を生成し、 それを読み込んで (. $tmp) いたのだが、
tmp=/tmp/dev2mod
echo 'dev2mod(){ while read dev; do case $dev in' > $tmp
sort -r /lib/modules/`uname -r`/modules.alias \
| sed -n 's/^alias *\([^ ]*\) *\(.*\)/\1)modprobe \2;;/p' >> $tmp
echo 'esac; done; }' >> $tmp
. $tmp
rm $tmp
cat /sys/bus/*/devices/*/modalias | dev2mod
modprobe が自分で modules.alias を探してくれるとなると、 sh スクリプトを動的生成する必要が無くなってしまい、 上記コードは次のように書けてしまう:
dev2mod(){ while read dev; do modprobe $dev; done }
cat /sys/bus/*/devices/*/modalias | dev2mod
わずかに 2行 (^^;)
/sys/bus/*/devices/*/modalias の内容を手当たり次第 modprobe するので、 modprobe が「failed to load module」というエラー・メッセージを出してしまうが、 特に問題は無さげである。
PCMCIA や USB につないだデバイスも、 以下のように dev2mod を二度呼び出すだけで、 自動認識してしまう。
dev2mod(){ while read dev; do modprobe $dev; done }
cat /sys/bus/*/devices/*/modalias | dev2mod
modprobe pcmcia
cat /sys/bus/*/devices/*/modalias | dev2mod
う〜んすごい。
2007年11月22日次のようなプログラム test.c について考える:
#include <stdio.h>
#include <stdlib.h>
#include <sys/types.h>
#include <string.h>
struct test {
int32_t len;
int8_t buf[16];
};
int main(int argc, char *argv[]) {
struct test *p = malloc(sizeof(struct test));
int8_t buf[16];
p->len = sizeof(p->buf);
bzero(p->buf, p->len);
printf("0x%lX-0x%lX => 0x%lX\n",
(long)p->buf, (long)p->buf+p->len-1, (long)buf);
bcopy(p->buf, buf, p->len);
free(p);
return 0;
}
malloc(3) で確保した領域のうち、 16 byte を bcopy(3) でコピーするだけの極めて単純なプログラムであり、 特に問題はないように見える。
ところが memory debugging tool Valgrind を使って検証してみると、 x86_64 Linux だと次のようなエラーが出てしまう。
sag16:/home/sengoku/tmp % cc -O -Wall test.c sag16:/home/sengoku/tmp % valgrind ./a.out ==19008== Memcheck, a memory error detector. ==19008== Copyright (C) 2002-2006, and GNU GPL'd, by Julian Seward et al. ==19008== Using LibVEX rev 1658, a library for dynamic binary translation. ==19008== Copyright (C) 2004-2006, and GNU GPL'd, by OpenWorks LLP. ==19008== Using valgrind-3.2.1-Debian, a dynamic binary instrumentation framework. ==19008== Copyright (C) 2000-2006, and GNU GPL'd, by Julian Seward et al. ==19008== For more details, rerun with: -v ==19008== 0x4D5C034-0x4D5C043 => 0x7FF000750 ==19008== Invalid read of size 8 ==19008== at 0x4B9326B: (within /lib/libc-2.3.6.so) ==19008== by 0x4B92C06: bcopy (in /lib/libc-2.3.6.so) ==19008== by 0x4005BD: main (in /home/sengoku/tmp/a.out) ==19008== Address 0x4D5C040 is 16 bytes inside a block of size 20 alloc'd ==19008== at 0x4A1B858: malloc (vg_replace_malloc.c:149) ==19008== by 0x400574: main (in /home/sengoku/tmp/a.out) ==19008== ==19008== ERROR SUMMARY: 1 errors from 1 contexts (suppressed: 8 from 1) ==19008== malloc/free: in use at exit: 0 bytes in 0 blocks. ==19008== malloc/free: 1 allocs, 1 frees, 20 bytes allocated. ==19008== For counts of detected errors, rerun with: -v ==19008== All heap blocks were freed -- no leaks are possible.
「Invalid read of size 8」、 すなわちアクセスすべきではないメモリを、 64bit (8 byte) 読み込み命令で読んだというエラー。
test.c で読み込みを行なう可能性があるところと言えば、 「bcopy(p->buf, buf, p->len);」の部分だけであり、 その範囲は printf で表示しているように、 0x4D5C034 番地から 0x4D5C043 番地までの 16 byte である。
ところが、Valgrind 曰く:
Address 0x4D5C040 is 16 bytes inside a block of size 20 alloc'd
ちょっと英語の意味が取りにくい (私の英語力が低いだけ? ^^;) が、 つまり「malloc で確保した 20 byte の領域のうち、 先頭から数えて 16 byte 目 (先頭は 0 byte 目と数える) が 0x4D5C040 番地であり、 この番地に対してメモリ読み込みが行なわれた」 という意味である (「16 byte 目」なら 「16 bytes」でなくて「16th byte」のような...?)。
すなわち、 「20 byte の領域のうち 16 byte 目」というのは残り 4 byte であり、 あと 4 byte コピーすればいいのにもかかわらず、 64bit 読み込み命令を使って 8 byte いっぺんに読んでしまっているから、 malloc で確保した領域の外をアクセスしてしまう、というわけ。
結果として 4 byte 無駄に読んでしまっている (実はコピー開始位置も 4 byte 前から行なうので、計 8 byte 余計に読み込んでいる) わけだが、 CPU にとって一番高速にコピーできる単位が (64bit 境界に合わせた) 64bit 読み書きだから、 bcopy の実装がこのようになっているのだろう。
より正確に言えば、 bcopy は 16 byte 以上のコピーを行なう場合は コピー開始位置手前の 64bit 境界 (alignment) の番地から 64bit ずつコピーし、 16 byte 未満の場合は byte 単位でコピーする。 test.c では、 コピー開始位置 p->buf が (直前のメンバが int32_t なので) 64bit 境界に一致しておらず、 しかもコピーする byte 数 p->len が 16 byte (= 64bit の倍数) なので、 16 byte 以上のコピーかつコピー終了位置も 64bit 境界に一致していない、 というのがミソである。
したがって 32bit な x86 Linux の場合であれば 32bit 単位でコピーを行なうので、 test.c ではこのようなエラーは起きない。 もちろん、64bit な x86_64 Linux で Valgrind がエラーを出すからといって、 bcopy の x86_64 における実装に問題がある、というわけではない。 Valgrind は、 あくまでバグの「可能性」を指摘するだけであって、 malloc で確保した領域の外へのアクセスでも、 それが意図的なものであれば (メモリ保護違反などでない限り) 何の問題もない。
分かってみれば単純な話なのであるが、 Valgrind のメッセージ「16 bytes inside a block」の意味が把握できなかった私は、 glibc の bcopy のソースを読んで 64bit 単位でコピーを行なっていることを知り、 4 byte の領域外読み込みが行なわれることを理解して初めて、 Valgrind のメッセージの意味が分かったという、 本末転倒な体験をした (^^;)。
ちなみに、 もちろん最初から上記のようなテストプログラムを Valgrind で チェックしようと思ったわけではなく、 「struct test」構造体は実際には次のような SockAddr 構造体であり、 saDup 関数にて malloc した SockAddr 構造体を doconnect 関数で bcopy する処理になっていて、 元ネタは拙作 stone である。
typedef struct {
socklen_t len;
struct sockaddr addr;
} SockAddr;
#define SockAddrBaseSize ((int)&((SockAddr*)NULL)->addr)
...
SockAddr *saDup(struct sockaddr *sa, socklen_t salen) {
SockAddr *ret = malloc(SockAddrBaseSize + salen);
...
int doconnect(Pair *p1, struct sockaddr *sa, socklen_t salen) {
struct sockaddr_storage ss;
struct sockaddr *dst = (struct sockaddr*)&ss; /* destination */
...
bcopy(sa, dst, salen);
...
stone ML にて、 Valgrind で検証したらエラーが出た、という報告を頂いて (_O_) 以上のような調査を行なった次第。 bcopy に与えた引数に問題はなく、 どうしてこれが 「Invalid read of size 8」 エラーを引き起こすのか謎だった。 結果的には stone には問題はなく、 修正の必要もないことが判明したわけであるが、 今まで使っていなかった Valgrind を使ってみるいいきっかけになった。 実を言うと 64bit Linux を (プログラミングのレベルで) 使ったのも、 今回が初めてだったりする (^^;)。
2007年09月29日これまでLinuxのハードウェア自動認識と言えば、 /sys/bus/pci/devices 以下と、 /lib/modules/`uname -r`/modules.pcimap を照らし合わせて 解析していくのが定石でした。 USBにも対応しようとすると、もう一つ大変です。
しかしこれからの常識は、 /sys/bus/*/devices/*/modalias と
/lib/modules/`uname -r`/modules.alias です。古橋貞之の日記「20行できる高精度ハードウェア自動認識」から引用
すばらしい。 確かに modules.alias を使う方が、 簡単かつ確実に必要なモジュールを読み込むことができそう。 さっそくこの方法を使って initramfs の init スクリプトを書き直してみた。
tmp=/tmp/dev2mod
echo 'dev2mod(){ while read dev; do case $dev in' > $tmp
sort -r /lib/modules/`uname -r`/modules.alias \
| sed -n 's/^alias *\([^ ]*\) *\(.*\)/\1)modprobe \2;;/p' >> $tmp
echo 'esac; done; }' >> $tmp
. $tmp
rm $tmp
cat /sys/bus/*/devices/*/modalias | dev2mod
わずかに 8行 (^^)
(9/30追記: modules.alias を逆順ソートしておく必要があることが判明、sort -r を追加)。
シェルスクリプト版はRuby版と比べて40倍くらい遅いので注意。同ページ(古橋貞之の日記)から続けて引用
sh スクリプトの名誉のために言っておくと、 私が書いた上記 sh スクリプトだと、 古橋さんの Ruby 版と比べて 4倍くらいの遅さで済んでいる。
% time ./dev2mod ide_cd intel_agp intelfb uhci_hcd ...(中略)... libusual usbcore 0.252u 0.012s 0:00.77 33.7% 0+0k 0+0io 0pf+0w % time ./detect_kmod.rb ["ivtv", "snd_intel8x0", "intelfb", "libusual", "ftdi_sio", "usbhid", "uhci_hcd", "ehci_hcd", "usbcore", "via_velocity", "eepro100", "e100", "3c59x", "psmouse", "ide_cd", "i2c_i801", "hw_random", "intel_agp"] 0.072u 0.008s 0:00.18 38.8% 0+0k 0+0io 0pf+0w
ちなみに古橋さんのスクリプトは、
modules.alias の各行それぞれに対し、
マッチするデバイスが /sys/bus/*/devices/*/modalias に存在すれば、
そのモジュールを読み込む処理になっている。
しかしながら、これだと一つのデバイスに対し、
複数のモジュールが読み込まれてしまうことになるのではないだろうか？
古橋さんが同日追記されているように、 複数のモジュールが読み込まれること自体は簡単に修正可能で、 むしろモジュールの読み込み順が modules.alias に載っている順になることのほうが問題。 この問題点を解決するため、 /sys/bus/*/devices/*/modalias の各行それぞれに対し、 マッチするモジュールを modules.alias から見つける修正版が追記された。 さすが古橋さん、すばやい。9/30追記
例えば古橋さんのスクリプトだと、 私の手元のマシンでは e100 と eepro100 の両方のモジュールが読み込まれてしまう。 つまり、
% cat /sys/bus/pci/devices/0000:01:08.0/modalias pci:v00008086d00001050sv0000107Bsd00004043bc02sc00i00
が、modules.alias の次の二つの行にマッチするため、 このようなことが起こる。
alias pci:v00008086d00001050sv*sd*bc*sc*i* eepro100 alias pci:v00008086d00001050sv*sd*bc02sc00i* e100
modules.alias を検索する際は、 マッチする行が見つかった時点で以降の行はスキップしないと、 この例のように複数のモジュール読み込みが起きる恐れがある。 マッチした以降の行を読み飛ばすには、 私が書いた上記 sh スクリプトのように、 /sys/bus/*/devices/*/modalias の各行それぞれに対し、 マッチするモジュールを一つだけ modules.alias から見つけて読み込む処理のほうが、 簡単に書けるのではないかと思うがどうだろうか。
とはいえ、実際の NIC は Intel Pro 10/100 だったりする (^^;) ので、 読み込むべきモジュールは e100 であるような気もする。 もし e100 が正しいモジュールであるのなら、 modules.alias における eepro100 のパターンが適切ではないということになるのかも。9/30追記「*」を多く含むパターンは「後で」マッチさせたほうが、 より適切なモジュールを選択できると考えられるため、 modules.alias を逆順ソートしておくことにした。 これにより、eepro100 ではなく、e100 を読み込むようになった。9/30さらに追記
参考までに initramfs の /init スクリプト全体を添付しておく:
続きを読む 2007年09月28日要約すれば、 「chrootなんて簡単に抜けられるからセキュリティ目的で使っても意味ないよ。」 ってことね。そうだったのか。「 セキュリティ目的のchrootは意味がない」から引用
そうだったのか orz
Note that this call does not change the current working directory, so that `.' can be outside the tree rooted at `/'. In particular, the super-user can escape from a `chroot jail' by doing `mkdir foo; chroot foo; cd ..'.chroot(2) から引用
chroot するときは、そのディレクトリへ chdir しておくのが常識と 思っていたので気づいていなかった。 つまり、 故意にカレントディレクトリを chroot 外へもっていけば、 chroot されたディレクトリから抜け出せてしまう、ということ。
より正確に言えば、 chroot されたディレクトリの中で、 さらに chroot すれば、 その「親」chroot ディレクトリを抜け出せてしまう。 chroot がネストしないことを利用したテクニック、ということか。 逆に言えば、 chroot(2) 実行時にカレントディレクトリを chroot ディレクトリ下へ 強制的に移動させるか、 あるいは chroot がネストするようにすれば回避可能？
mkdir foo; chroot foo; cd ..
確かに本質はこの短いコードで言い尽くされているが、 こーいうのを見ると実地に試さずにはおれないので、コードを書いてみた。
#include <stdio.h>
#include <sys/types.h>
#include <unistd.h>
#include <sys/stat.h>
#include <errno.h>
#define BUFMAX 256
int main(int argc, char *argv[]) {
char buf[BUFMAX+1];
sprintf(buf, "escape.%d", getpid());
if (chdir("/") < 0) {
printf("Can't chdir \"/\" errno=%d\n", errno);
return 1;
}
if (mkdir(buf, 0755) < 0) {
printf("Can't mkdir \"%s\" errno=%d\n", buf, errno);
return 1;
}
if (chroot(buf) < 0) {
printf("Can't chroot \"%s\" errno=%d\n", buf, errno);
return 1;
}
if (rmdir(buf) < 0) {
printf("Can't rmdir \"%s\" errno=%d\n", buf, errno);
return 1;
}
if (!getcwd(buf, BUFMAX)) {
printf("Can't getcwd errno=%d\n", errno);
return 1;
}
printf("Now escaping from chrooted %s\n", buf);
do {
if (chdir("..") < 0) {
printf("Can't chdir \"..\" cwd=%s errno=%d\n", buf, errno);
return 1;
}
if (!getcwd(buf, BUFMAX)) {
printf("Can't getcwd errno=%d\n", errno);
return 1;
}
} while (buf[1] != '\0' && buf[0] == '/');
if (chroot(".") < 0) {
printf("Can't chroot \".\" errno=%d\n", errno);
return 1;
}
argv++;
execv(argv[0], argv);
printf("Can't exec %s err=%d\n", argv[0], errno);
return 0;
}
chdir / して、mkdir foo して、chroot foo して (rmdir foo して)、 その後に chdir .. でディレクトリ階層を上がれば抜け出せる。 言葉で書けば簡単だが、実際のコードを書こうとすると、 もう少し考えるべきことがあった。
すなわち、 抜け出した後、プログラムを終了してしまっては元の木阿弥であるので、 /bin/sh などを exec すべきであるし、 「本物」の / 下の /bin/sh をちゃんと実行するには、 「本物」の / へ chroot しなおす必要もある。 ここで注意すべきなのは、 「/」ディレクトリは元の chrooted なディレクトリのままという点だろう。 つまり chroot / してしまうと、 元の chrooted なディレクトリへ chroot してしまう (つまり何も変わらない)。
だから「/」を使わずに、 「chdir ..」で一段ずつディレクトリ階層を上っていって 「本物」の / にたどり着かねばならない。 上記コード中の while ループが「一段ずつ上っていく」処理である。 「本物」の / にたどりついたら chroot . する (くどいようだがここで chroot / してはいけない)。
試しに脱出してみる:
ikeda:/ # chroot /tmp/chroot /bin/sh # ls -laR / /: drwxr-xr-x 3 0 0 29 Sep 28 17:05 . drwxr-xr-x 3 0 0 29 Sep 28 17:05 .. drwxr-xr-x 2 0 0 38 Sep 28 16:21 bin -rwxr-xr-x 1 0 0 2111689 Sep 28 17:02 escape /bin: drwxr-xr-x 2 0 0 38 Sep 28 16:21 . drwxr-xr-x 3 0 0 29 Sep 28 17:05 .. -rwxr-xr-x 1 0 0 1392832 Sep 1 11:24 busybox lrwxrwxrwx 1 0 0 7 Sep 28 16:21 ls -> busybox lrwxrwxrwx 1 0 0 7 Sep 28 16:21 sh -> busybox # ./escape /bin/sh Now escaping from chrooted /tmp/chroot sh-3.00# ls -la /tmp/chroot total 2068 drwxr-xr-x 3 root root 29 Sep 28 17:05 . drwxrwxrwt 8 root root 4096 Sep 28 17:05 .. drwxr-xr-x 2 root root 38 Sep 28 16:21 bin -rwxr-xr-x 1 root root 2111689 Sep 28 17:02 escape sh-3.00#
2007年09月27日Linux 2.6.22 以前は、 シンボリックリンク (symbolic link) のタイムスタンプ (time stamp) を 変更することが出来なかった。 Linux (に限らず unix のほとんど全て) では、 シンボリックリンクも普通のファイルと同様、 アクセス日時と更新日時のタイムスタンプを保持している。 BSD な unix などでは、 lutimes システムコールを使ってシンボリックリンクのタイムスタンプを変更できる。
ところが、Linux には lutimes システムコールが存在しない。 したがってシンボリックリンクのタイムスタンプは、 そのシンボリックリンクを作成した時刻のままである。 tar などでアーカイブからリストアする場合や、 rsync などでディレクトリをコピーする場合などでも、 シンボリックリンクだけは元のタイムスタンプが復元されず、 復元した時刻のシンボリックリンクが作成されるので、 不便なことこのうえない。
Linux 2.6.22 になって、 utimensat システムコールが新設された。
Ulrich Drepper (glibc のメンテナ) は、 futimesat インターフェイスでは機能が足りていないということを理由に、 utimensat システムコールを提案しました。
futimesat は、inode のアクセス・変更時間を設定するためのシステムコールです。 struct timeval をパラメータとして受け取るため、 マイクロ秒単位で設定します。 一方、inode の各種情報を取得する stat というシステムコールでは、 ナノ秒単位で取得できるようになっています。 つまり、そもそも設定できない精度で情報を取得できるような仕組みに なっているわけです。
この問題を解決するために、 パラメータとして struct timespec (ナノ秒単位) を利用できる utimensat というシステムコールを用意することになりました。 このシステムコールは Linux カーネル 2.6.22-rc1 でマージされました。
この記事では、 ナノ秒単位で設定できることばかり強調しているが (私の感覚だとマイクロ秒がナノ秒になっても、あまり嬉しくない ;-)、 utimensat で機能拡張されたのはそれだけではない。
int utimensat(unsigned int dfd, char *filename, struct timespec *t, int flags);
引数が「struct timespec」になってナノ秒単位で設定できるようになったわけだが、 「utimensat」という名称から推測される通り、 他の *at (末尾に「at」がつく) システムコールと同様、 引数として与えたパス名 (char *filename) の扱いを指定できる。 /usr/include/fcntl.h には次のように書いてある。
#ifdef __USE_ATFILE # define AT_FDCWD -100 /* Special value used to indicate the *at functions should use the current working directory. */ # define AT_SYMLINK_NOFOLLOW 0x100 /* Do not follow symbolic links. */ # define AT_REMOVEDIR 0x200 /* Remove directory instead of unlinking file. */ # define AT_SYMLINK_FOLLOW 0x400 /* Follow symbolic links. */ # define AT_EACCESS 0x200 /* Test access permitted for effective IDs, not real IDs. */ #endif
utimensat の第四引数 int flags に「AT_SYMLINK_NOFOLLOW」を与えれば、 シンボリックリンクを「たどらず」に、 シンボリックリンクそのものに対して、 タイムスタンプの変更を行なうことができそうである (ちなみに futimesat は第三引数までしかなく int flags を指定できない)。
さっそく実験してみる:
int utimensat(int dfd, char *filename,
struct timespec *utimes, int flags) {
register unsigned int ret;
asm volatile (
"movl %1, %%eax\n\t"
"call *%%gs:%P2\n\t"
: "=a" (ret)
: "i" (320), "i" (16),
"b" (dfd), "c" (filename), "d" (utimes), "S" (flags)
: "memory", "cc");
return (long)ret;
}
手元の Linux マシンの glibc では、 utimensat を呼び出せるようにはなっていなかったので、 glibc のソースを参考にしながら utimensat システムコールを呼び出す関数を書いてみた。 コード中「320」などとハードコーディング (^^;) している数値は、 linux/include/asm-i386/unistd.h 中の、
#define __NR_utimensat 320
を意味している。 これで utimensat システムコールをユーザ空間から呼び出せるようになった。 もちろん、utimensat をサポートしている glibc であれば、 このような関数をデッチあげるまでもなく、 そのまま普通に utimensat を呼び出せばよい。
さっそく使ってみる:
#include <stdio.h>
#include <stdlib.h>
#define __USE_ATFILE
#include <fcntl.h>
#undef __USE_MISC
#include <sys/stat.h>
int main(int argc, char *argv[]) {
int i;
for (i=1; i < argc; i++) {
struct stat lst, st;
if (lstat(argv[i], &lst)) {
printf("Can't find: %s\nUsage: %s <file>...\n", argv[i], argv[0]);
exit(1);
}
if (S_ISLNK(lst.st_mode) && !stat(argv[i], &st)) {
struct timespec ts[2];
ts[0].tv_sec = st.st_atime;
ts[0].tv_nsec = st.st_atimensec;
ts[1].tv_sec = st.st_mtime;
ts[1].tv_nsec = st.st_mtimensec;
if (utimensat(AT_FDCWD, argv[i], ts, AT_SYMLINK_NOFOLLOW) < 0) {
printf("Failed to utimensat %s %ld.%09ld\n",
argv[i], ts[1].tv_sec, ts[1].tv_nsec);
}
}
}
return 0;
}
シンボリックリンクのタイムスタンプを、
シンボリックリンク先のファイル (or ディレクトリ、その他) のタイムスタンプと
一致させるプログラムである。
上記ソースプログラム (utimensat 関数と main 関数) を
ltouch.c という名前で保存し、
「gcc -o ltouch ltouch.c」などとコンパイルした後、
「ltouch シンボリックリンクのパス名」などと実行する。
senri # ls -lt /usr/i486-linuxaout/lib/ total 20000 lrwxrwxrwx 1 root root 16 Dec 22 2005 libPEX5.so.1 -> libPEX5.so.1.1.0* lrwxrwxrwx 1 root root 14 Dec 22 2005 libPEX5.so.6 -> libPEX5.so.6.0* lrwxrwxrwx 1 root root 15 Dec 22 2005 libX11.so.3 -> libX11.so.3.1.0* lrwxrwxrwx 1 root root 13 Dec 22 2005 libX11.so.6 -> libX11.so.6.0* lrwxrwxrwx 1 root root 13 Dec 22 2005 libXIE.so.6 -> libXIE.so.6.0* lrwxrwxrwx 1 root root 15 Dec 22 2005 libXaw.so.3 -> libXaw.so.3.1.0* lrwxrwxrwx 1 root root 13 Dec 22 2005 libXaw.so.6 -> libXaw.so.6.0* lrwxrwxrwx 1 root root 15 Dec 22 2005 libXpm.so.3 -> libXpm.so.3.3.0* lrwxrwxrwx 1 root root 13 Dec 22 2005 libXpm.so.4 -> libXpm.so.4.3* lrwxrwxrwx 1 root root 14 Dec 22 2005 libXt.so.3 -> libXt.so.3.1.0* lrwxrwxrwx 1 root root 12 Dec 22 2005 libXt.so.6 -> libXt.so.6.0* lrwxrwxrwx 1 root root 18 Dec 22 2005 libcurses.so.0 -> libcurses.so.0.1.2* lrwxrwxrwx 1 root root 15 Dec 22 2005 libdb.so.1 -> libdb.so.1.85.1* lrwxrwxrwx 1 root root 10 Dec 22 2005 libdbm.sa -> libgdbm.sa lrwxrwxrwx 1 root root 16 Dec 22 2005 libdosemu -> libdosemu-0.60.1 lrwxrwxrwx 1 root root 14 Dec 22 2005 libe2fs.so.1 -> libe2fs.so.1.0* lrwxrwxrwx 1 root root 13 Dec 22 2005 libe2p.so.1 -> libe2p.so.1.0* lrwxrwxrwx 1 root root 12 Dec 22 2005 libet.so.1 -> libet.so.1.0* lrwxrwxrwx 1 root root 12 Dec 22 2005 libgr.so.1 -> libgr.so.1.3* lrwxrwxrwx 1 root root 12 Dec 22 2005 libss.so.1 -> libss.so.1.0* lrwxrwxrwx 1 root root 14 Dec 22 2005 libtcl.so.3 -> libtcl.so.3.1j* lrwxrwxrwx 1 root root 13 Dec 22 2005 libtk.so.3 -> libtk.so.3.1j* lrwxrwxrwx 1 root root 16 Dec 22 2005 libvga.so.1 -> libvga.so.1.0.11* ...(後略)...
古いディレクトリだと、 このように同じタイムスタンプのシンボリックリンクばかり並んでしまって、 見にくいことこの上ない (おそらく 2005年12月22日に、ハードディスクを入れ替えたのだろう) のであるが、 「ltouch *」を実行すると、
senri # ltouch /usr/i486-linuxaout/lib/* senri # ls -lt /usr/i486-linuxaout/lib/ total 20000 lrwxrwxrwx 1 root root 14 Sep 11 1995 libPEX5.so.6 -> libPEX5.so.6.0* -r-xr-xr-x 1 root root 234500 Sep 11 1995 libPEX5.so.6.0* lrwxrwxrwx 1 root root 13 Sep 11 1995 libXIE.so.6 -> libXIE.so.6.0* -r-xr-xr-x 1 root root 58372 Sep 11 1995 libXIE.so.6.0* lrwxrwxrwx 1 root root 13 Sep 11 1995 libXaw.so.6 -> libXaw.so.6.0* -r-xr-xr-x 1 root root 209924 Sep 11 1995 libXaw.so.6.0* lrwxrwxrwx 1 root root 12 Sep 11 1995 libXt.so.6 -> libXt.so.6.0* -r-xr-xr-x 1 root root 320516 Sep 11 1995 libXt.so.6.0* lrwxrwxrwx 1 root root 13 Sep 11 1995 libX11.so.6 -> libX11.so.6.0* -r-xr-xr-x 1 root root 529412 Sep 11 1995 libX11.so.6.0* lrwxrwxrwx 1 root root 16 Jul 29 1995 libdosemu -> libdosemu-0.60.1 -rw-r--r-- 1 root root 630973 Jul 29 1995 libdosemu-0.60.1 -rw-r--r-- 1 root root 28912 Mar 19 1995 libdes.a lrwxrwxrwx 1 root root 14 Feb 28 1995 libe2fs.so.1 -> libe2fs.so.1.0* -rwxr-xr-x 1 root root 84035 Feb 28 1995 libe2fs.so.1.0* lrwxrwxrwx 1 root root 13 Feb 28 1995 libe2p.so.1 -> libe2p.so.1.0* -rwxr-xr-x 1 root root 51633 Feb 28 1995 libe2p.so.1.0* lrwxrwxrwx 1 root root 12 Feb 28 1995 libet.so.1 -> libet.so.1.0* -rwxr-xr-x 1 root root 56437 Feb 28 1995 libet.so.1.0* lrwxrwxrwx 1 root root 12 Feb 28 1995 libss.so.1 -> libss.so.1.0* -rwxr-xr-x 1 root root 63306 Feb 28 1995 libss.so.1.0* lrwxrwxrwx 1 root root 18 Feb 19 1995 libcurses.so.0 -> libcurses.so.0.1.2* -rwxr-xr-x 1 root root 49152 Feb 19 1995 libcurses.so.0.1.2* ...(後略)...
このように、 シンボリックリンクとリンク先ファイルが同じタイムスタンプになるので、 「ls -lt」などと更新日時でソートすれば、 リンクとリンク先が隣り合わせになって見やすくなる。
2007年09月18日ディスクレス (diskless) サーバを多数運用しようとしたときネックとなるのが、 NAS (Network Attached Storage) サーバの性能。 多数のディスクレスサーバを賄え、かつ高信頼な NAS サーバとなると、 どうしても高価なものになりがちであり、 NAS サーバ本体の価格もさることながら、 ディスクが壊れたときの交換体制などの保守運用費用も高くつく。
それでも、多数のハードディスク内蔵サーバ (つまり一般的なサーバ) を 運用して各サーバのディスクを日々交換し続ける (運用台数が多くなると、 毎週のようにどこかのディスクが壊れると言っても過言ではない) よりは、 ディスクを一ヶ所の NAS にまとめたほうがまだ安い、 というわけで NAS/SAN へのシフトは今後も進むだろう。 そもそも CPU やメモリなどとハードディスクとでは、 故障率のケタが違うのだから、 両者の台数を同じように増やせば破綻するのは当たり前。 要は、滅多に故障しないものは増やしてもいいが、 普通に故障するものは増やしてはいけない。 サーバの部品で故障する確率が桁違いに高いのはハードディスクだから、 大規模負荷分散環境においてディスクレス化は論理的必然だろう。
ハードディスクの故障率が高いのは可動部品が多いから、 というわけでハードディスクをフラッシュメモリで 置き換えようとする傾向もあるようだ。 確かに高価な NAS サーバを導入するよりは、 各サーバにフラッシュメモリを搭載する方が安上がりである可能性もある (比較的低容量であれば)。 しかしながら、 以下に述べるように NAS サーバを普通の PC サーバで実現できてしまえば、 ディスクレス化のほうが安いのは当たり前である。 サーバの台数が多くなればなるほど、 各サーバにディスク/フラッシュメモリを必要としない ディスクレス方式の方が有利になる。
とはいえ、 PC サーバの価格に慣れてしまうと、 超高価な専用サーバの世界にはもう戻れない。 そこで、 どうすればサーバ群のディスクレス化を、 低コストで行なうことができるか考えてみる。 そもそもなぜ NAS サーバが高価かと言えば、 高パフォーマンス性と高信頼性を兼ね備えようとするから。 多数のディスクレスサーバにストレージサービスを提供するのだから 高パフォーマンス性は譲れない。 となると犠牲にしてよいのは高信頼性ということになる。
信頼できなくてもよい、 つまり時々ディスクが壊れて、 書込んだはずのデータが失われても良いなら、 そこそこ高性能な PC サーバで用が足りてしまうだろう。 壊れた場合に備えて冗長化しておけば、 高信頼ではないものの、無停止性は達成できる。 もちろんマスターサーバが壊れてスレーブサーバに切り替われば、 マスターサーバにしか書込めなかったデータは失われる。
そんな NAS サーバは使えない、と言われてしまいそうであるが (^^;)、 ディスクに書込むデータで消えては困るデータとは何だろうか？ 例えば Web サーバなどでは、 永続化が必要なデータは DB サーバへ書込むのが普通で、 それ以外のデータは消えては困るとは必ずしも言えないのではないか？ というか消えては困るデータは DB サーバへ書けばいいのである。
さらに考えを一歩進めて、 ディスクに書込むデータは消えてもよい、 と割りきってしまうことができれば、 NAS サーバにデータを書く必要性すらなくなってしまう。 つまり NAS サーバのディスクを読み込み専用 (Read Only 以下 RO と略記) でマウントし、 書き込みはローカルな読み書き可能な (Read Write 以下 RW と略記) RAM ディスクに対して行なう。 NAS サーバは RO だから 内容が同じ NAS サーバを複数台用意して負荷分散させれば、 高パフォーマンスと故障時のフェールオーバを同時に達成できてしまう。 NAS サーバのクラスタリングが難しいのはデータを書込もうとするからであって、 書込む必要がなければ話は一気に単純になる。
もちろん全く何も書込めない NAS サーバというのはナンセンスだろう。 ここで「書く必要がない」と言っているのは、 アプリケーション実行中にアプリケーションの動作に同期して (つまり動作結果を) 「書く」必要性である。 アプリケーションとは非同期な書込み、 例えば何らかのコンテンツを配信する Web サーバを考えたとき、 あらかじめ大量の「コンテンツ」を NAS サーバへ事前に保存しておく場合や、 あるいは「コンテンツ」を定期的に更新する場合は、 (アプリケーションの動作結果とは無関係な書き込みなので) Web アプリケーションが NAS へ書込む必要はない。
むしろ、 大量の「コンテンツ」を NAS サーバに集中することは、 コンテンツ更新が素早く行なえるというメリットとなる。 多数の Web サーバそれぞれにハードディスクを内蔵して 同じコンテンツをコピーしていては、 コンテンツの更新頻度が上がってくると 全 Web サーバの内容を同期させるのが難しくなってくるからだ。
ここで重要なのは、 上記「RO NAS サーバ + RW ローカル RAM ディスク」が、 ディスクレスサーバ上で動くソフトウェア (例えば Web アプリケーションやミドルウェア) から見ると、 普通の RW ローカルディスク (つまり普通に書込み可能なハードディスク) に見えなければならないという点である。 もしソフトウェア側で特別な対応が必要だと、 ソフトウェアの改修コストがかかってしまう。 ハードウェアのコストを下げようとして ソフトウェアのコストが上がってしまっては本末転倒である。 ディスク上のデータが RO な NAS サーバから読み込まれたものであり、 ディスクへ書込んだデータが、実は RAM ディスクに書込んだだけで、 再起動によって消えてしまうものであったとしても、 ソフトウェアから見れば、 普通の RW ハードディスクディスクのように 振る舞わなければならないのである。
このように、
複数のディスク (RO NAS と RW RAM ディスク) を重ねて
一つのディスクとして見せる仕掛けを、
重ね合わせ可能な統合ファイルシステム (Stackable Unification File System)
と呼ぶ。
Linux 2.6.20 以降の場合、
二種類の統合ファイルシステムが利用可能である。
後発の Aufs (Another Unionfs) を利用して、
ディスクレスサーバを作ってみた。
(あいかわらず) 前フリが長いが (^^;)、ここからが本題である。
2007年09月04日linux をブートさせる際、 さまざまな PC に対応させようとすると、 多くのデバイスドライバをカーネルに組み込んでおかねばならない。 つまりルートファイルシステム (root file system, 以下 rootfs と略記) をマウントするまでは、 その rootfs 上にインストールしたモジュール群 (/lib/modules/ の下に置いた *.ko ファイル群) を読めないからだ。 rootfs さえマウントできてしまえば、 あとはいくらでもモジュールを必要に応じて読み込むことができるようになる。 だから、さまざまなハードウェアへの対応といっても、 重要なのは rootfs をマウントするまで、である。
しかしながら、 rootfs をマウントするまでの辛抱といっても、 rootfs をマウントするにはハードディスクを認識しなければならないし、 それには ATA ドライバやら SCSI ドライバやら、 果ては AHCI ドライバなどが、 ハードウェアに応じて必要になる。
個人で管理する PC の全てのハードウェアに対応させるだけなら、 全てのドライバをあらかじめカーネルに読み込んでおくのもアリだろう。 しかし汎用的なディストリビューションなど、 (カーネル再構築を行なわずに) 多くのハードウェアに対応する必要がある場合は、 必要になるかも知れない全てのドライバを、 あらかじめカーネルに読み込んでおくなどということは非現実的である。
ちなみに私は、1993年頃から linux を使っているが、 いまだに当時インストールした slackware を使用し続けている。 もちろん kernel や libc をはじめとして、 ほぼ全てのソフトウェアをアップデートしてしまっているし、 しかも起動スクリプトをはじめとして、 あらゆる設定を好き勝手に書き換えてしまっているので、 インストールしてから 10年以上たった今となっては、 元の slackware の痕跡は全くといっていいほど残っていない。 もはや、私独自のディストリビューションと呼んでしまっても差し支えないだろう。 私が個人的に管理しているマシンには、 全てこの「my distribution」をインストールしている。 そんなわけで、私は「普通の」ディストリビューションを使ったことがない。 initrd がディストリビューションの「常識」となってからも、 私は initrd は使わずに、 自分が管理する PC のハードウェアに合わせてカーネルを再構築して使ってきた。
そこで linux では、 initrd (Initial RAM Disk) という仕掛けが使われてきた。 すなわちハードディスクを rootfs としてマウントする前に、 一時的にマウントする「ミニ」ルート (mini root) である。 このミニルートには、 ハードディスク (あるいは 1CD Linux の場合であれば CD だし、 ネットワークブートする場合であれば NFS サーバ) を rootfs としてマウントするのに必要となる可能性がある モジュール群一式を置いておき、 ハードウェアに応じて必要なモジュールをミニルートから読む。 そして、ハードディスクをマウントして、 / (ルート) をミニルートからハードディスクへ切り替える。
ただ、この initrd は少々扱いが面倒くさい。 initrd は RAM ディスクという「本物の」ブロックデバイスなので、 「本物の」ファイルシステム (例えば ext2) で mkfs しなければならない。 initrd にモジュールを追加しようとすれば、 initrd イメージを (losetup コマンドを使って) ループバックデバイス経由でマウントして内容を書き換えなければならないし、 たくさんのモジュールを追加した結果、 もしファイルシステムが一杯にでもなったりしたら、 initrd イメージのサイズを大きくして mkfs からやり直しである。
メンドクサイだけでなく、 RAM ディスク自体が非効率なものであるようで、 ファイルからブロックデバイスを作る方法としては、 すでに「semi-obsolete」とまで言われてしまっているようである:
Another reason ramdisks are semi-obsolete is that the introduction of loopback devices offered a more flexible and convenient way to create synthetic block devices, now from files instead of from chunks of memory. See losetup (8) for details.linux/Documentation/filesystems/ramfs-rootfs-initramfs.txt から引用
というわけで、initrd に代わる仕掛けとして、 linux kernel 2.6 からは initramfs と呼ばれる仕掛けが導入された。 すなわち RAM ディスクというブロックデバイスを用いるのではなく、 RAM 上に直接ファイルシステムを作る ramfs を用いた「ミニルート」である。 私自身は今まで initrd を使っていなかったのであるが、 cpio アーカイブを作るだけでいいというのは、 とても手軽であるように思えたし、 カーネルにどんどんドライバを組み込んで肥大化させるよりは、 initramfs を使う方がヨサゲである (もちろん、どんどんドライバを組み込めば、 initramfs が肥大化するのだが、 カーネルが肥大化するデメリットとは比較にならない) ように感じてきたので、 宗旨替えすることにした。
| initrd | initramfs | |
|---|---|---|
| イメージ | ファイルシステム (ext2など + gzip) | アーカイブ (cpio + gzip) |
| 実装 | ブロックデバイス (RAM ディスク) | ファイルシステム |
| 実行 | /linuxrc | /init |
| rootfs マウント |
適当なディレクトリへマウントして pivot_root |
/ へマウント (switch_root) |
| init 起動 | /linuxrc 終了後、カーネルが起動 | /init が exec /sbin/init する |
ブートパラメータとして「initrd=」を与えると、 ブートローダがイメージをメモリ上に読み込んでカーネルに渡す。 するとカーネルはそのイメージがファイルシステムなのか、 cpio アーカイブなのか調べる。 もしファイルの magic number が cpio であれば、 ramfs としてマウントする。 そして /init が実行可能ならば、 initramfs として扱い、 /init を起動する。
以上の条件が一つでも成立しない場合、
すなわち cpio アーカイブでない場合や、
/init が実行できない (/init が存在しない) 場合は、
initrd 扱いになるので注意が必要である。
すなわち RAM ディスクとしてマウントしようとするので、
カーネルに RAM ディスクドライバが組み込まれていなかったり、
「root=/dev/ram0」カーネルパラメータを指定していなかったりすると、
kernel panic を起こす。
実は、initramfs として起動できるようになるまで、 かなりハマってしまった。 まず、cpio アーカイブを作るところで、いきなりハマった。
(cd /usr/src/initramfs/; find . | cpio -o -H newc ) | gzip > initrd.gz
などとしてアーカイブを作ればいいだけの話なのであるが、 このコマンドラインを /bin/csh 上で実行したために、 アーカイブの先頭にゴミが入ってしまった。 つまり、
senri:/ % (cd /usr/src/initramfs/; find . | cpio -o -H newc ) | cpio -tv | head cpio: Malformed number 0000000. cpio: Malformed number 000000. cpio: Malformed number 00000. cpio: Malformed number 0000. cpio: Malformed number 000. cpio: Malformed number 00. cpio: Malformed number 0. cpio: Malformed number . cpio: warning: skipped 56 bytes of junk drwxr-xr-x 13 root root 0 Aug 27 17:56 . drwxr-sr-x 2 root root 0 Aug 25 10:00 bin -rwxr-xr-x 1 root root 1392832 Aug 25 18:36 bin/busybox lrwxrwxrwx 1 root root 7 Aug 25 10:09 bin/addgroup -> busybox lrwxrwxrwx 1 root root 7 Aug 25 10:09 bin/adduser -> busybox lrwxrwxrwx 1 root root 7 Aug 25 10:09 bin/ash -> busybox lrwxrwxrwx 1 root root 7 Aug 25 10:09 bin/cat -> busybox lrwxrwxrwx 1 root root 7 Aug 25 10:09 bin/catv -> busybox lrwxrwxrwx 1 root root 7 Aug 25 10:09 bin/chattr -> busybox lrwxrwxrwx 1 root root 7 Aug 25 10:09 bin/chgrp -> busybox
何が起きているかお分かりだろうか？ お恥ずかしながら、アーカイブにゴミが混入していると気づくまで、 何度も kernel を panic させてしまった。 シェルのカスタマイズをやりすぎるとロクなことにならない、 という典型例なのかも (^^;)。
senri:/ % (cd /usr/src/initramfs/; echo test) | od -t a
0000000 esc E m A c S c d sp / u s r / s r
0000020 c / i n i t r a m f s nl esc E m A
0000040 c S c d sp / u s r / s r c / i n
0000060 i t r a m f s nl t e s t nl
0000075
senri:/ % alias cd
set back="$cwd";chdir !*;if(!* =~ "..")set cwd="$back:h";chdir "$cwd";setProm
senri:/ % alias setProm
set prompt="${HOST}:${cwd} $prompt_tail_char "
この alias 設定は、 もうかれこれ 10年以上使い続けてきた設定。 こんな形で悪さをするとは... orz
ようやくマトモなアーカイブを作れたと思ったら、 今度は以下のような Kernel panic が起きた:
Unpacking initramfs... done Freeing initrd memory: 1412k freed ...(中略)... No filesystem could mount root, tried: Kernel panic - not syncing: VFS: Unable to mount root fs on unknown-block(8,1)
「Unpacking initramfs... done」と出ているのだから、 cpio アーカイブはちゃんと展開できて ramfs としてマウントできているはず。 なぜに「Unable to mount root fs」なのか、 と思っていたのだが、 これは initramfs に「/init」が無いためだった (エラーメッセージが不親切杉！)。 initrd みたいなものだろうと思って、 起動スクリプトを「/linuxrc」というファイル名で作っていたのが敗因。
「/init」がないと initrd 扱いになってしまい、 RAM ディスクを mount しようとしていたが、 RAM ディスクドライバが組み込まれていなかったのでマウントできない、 というのが、このエラーメッセージの主旨だったようだ (素直に /init が見つからない、って言ってくれればいいのに...)。 「/linuxrc」を「/init」へファイル名変更してみると、 あっさり initramfs 上での起動に成功した。
% ls -lt /boot/*-2.6.20.* -rw-r--r-- 1 root root 1643881 Sep 3 07:55 /boot/initz-2.6.20.18 -rw-r--r-- 1 root root 1193392 Sep 1 23:10 /boot/linuz-2.6.20.18 -rw-r--r-- 1 root root 2017936 May 12 19:31 /boot/linuz-2.6.20.11
2.6.20.11 を make したときは、 rootfs のマウントに必要なドライバを全てカーネルに詰め込んでいたのに対し、 2.6.20.18 では、 マウントに必要なドライバは極力 initramfs に入れた。 これにより linuz 単体のサイズは半分近くに減っている。 linuz (カーネル) + initz (initramfs) の合計サイズは 2.6.20.11 に比べ増えてしまっているが、 これは busybox だけで 1.3MB ほどあるため。 とはいえ、 initramfs 内では busybox よりも lib/modules 以下のサイズの方が倍ほど大きいので、 非効率というほどでもない。
senri:/usr/src/initramfs % ls -l bin/busybox -rwxr-xr-x 1 root root 1392832 Sep 1 11:24 bin/busybox senri:/usr/src/initramfs % du --max-depth=2 --byte 1397502 ./bin 4740 ./sbin 6204 ./usr/bin 4334 ./usr/sbin 8226 ./usr/share 22860 ./usr 4096 ./dev/pts 4096 ./dev/shm 12338 ./dev 4108 ./etc 4096 ./mnt 2422679 ./lib/modules 2426775 ./lib 4096 ./proc 4096 ./tmp 4096 ./var 4096 ./sys 3895272 .
じゃ、いよいよハードウェアの自動認識をして、 適切なモジュールのみを組み込むようにしてみようかと思って、 いろいろ探してみたのだが、 どうしたことか適当なスクリプトが見当たらない。 1CD Linux の /linuxrc をいろいろ読んでみたのだが、 いまいちパッとするものがない。 デバイスの ID などがゴリゴリ書いてあるものが大半で、 どれもアドホックすぎるように思えたのである。
かといって、ハードウェアの認識を udev などに行なわせる、 というのは牛刀過ぎるように思えた。 なんたって init を起動する前のブートストラップなのである。 目的は rootfs をマウントするだけなのであるから、 あまりに汎用的な仕掛けは、いかがなものかと思うのである。
というわけで、 busybox だけでハードウェアの自動認識 & モジュール読み込みを実現することを 目標にしてみた。 前フリが長くなった (長すぎ!) が、ようやくここからが本題である。
続きを読む 2007年08月16日自前のブラックリストを用いて迷惑メール (spam, UBE) を排除する方法について、 「迷惑メール送信者とのイタチごっこを終わらせるために (1)」で説明した。 メールの送信元 IP アドレスが DNS で逆引きできない場合に、 その IP アドレスがブラックリストに載っているか否かを調べ、 もし載っているならその IP アドレスを 「ダイアルアップ IP アドレス」に準じる扱いにする、 という方法である。
迷惑メールを送ってきた実績 (?) がある IP アドレスブロックであれば、 ためらうこと無くブラックリストに入れてしまえるのであるが、 初めてメールを送ってきた IP アドレスブロックを、 逆引きできないという理由だけでダイアルアップ IP アドレス扱いするのは、 少々乱暴だろう。 そこで、 接続元 IP アドレスが属する国のコードをメールヘッダに挿入する仕掛けを MTA (Message Transfer Agent, メールサーバ) に作り込んでみた。例えば、
Received: from unknown (HELO unknown.interbgc.com) (89.215.246.95) by senri.gcd.org with SMTP; 15 Aug 2007 20:46:15 +0000 X-Country: BG 89.215.246.95 Received-SPF: pass (senri.gcd.org: SPF record at thelobstershoppe.com designates 89.215.246.95 as permitted sender) Message-ID: <34f301c7df7d$2e65ece5$5ff6d759@unknown.interbgc.com>
といった感じで、「X-Country: 」フィールドが挿入される。 「89.215.246.95」がこのメールを送ってきたマシンの IP アドレスであり、 その前の「BG」が、 この IP アドレスが属する国 (この例ではブルガリア) の ISO 3166 コード である。
ブルガリアに知り合いがおらず、 かつこのメールがメーリングリスト宛でなく個人アドレス宛であるならば、 MUA (Message User Agent, メーラー) の設定で、 このメールを迷惑メールとして排除することが可能だろう。 あるいは逆に、 「X-Country: JP」である場合は、 迷惑メール判定の結果にかかわらず排除しないという設定にして、 必要なメールを誤って排除するのを防止することもできるだろう (日本語の迷惑メールも、大半は海外の IP アドレスから送信されている)。
IP アドレスから国コード (ISO 3166 コード) を調べるサービスはいろいろあるが、 メールを受信するたびに外部のサイトへ通信するのはあまり感心しない。 ネットワークないし外部のサイトの状況の影響を受けてしまうし、 あるいは逆に大量のメールを一時に受信したときなど、 そのサイトに迷惑をかけてしまう恐れもある。 集中して問合わせを行なってしまった、などの理由で濫用と判断され、 サービスの提供が受けられなくなってしまう可能性もある。
したがって、IP アドレスから国コードを検索するためのデータベースを 自前で持つことが望ましい。 例えば CPAN には、 IP アドレスから国コードを検索するモジュール 「IP::Countryが 登録されている。 このモジュールをインストールすると、 「/usr/lib/perl5/site_perl/5.8.8/IP/Country/Fast」ディレクトリに、 「ip.gif」と「cc.gif」というファイルがインストールされる。
% ls -l /usr/lib/perl5/site_perl/5.8.8/IP/Country/Fast total 256 -r--r--r-- 1 perl perl 681 Feb 2 2007 cc.gif -r--r--r-- 1 perl perl 252766 Feb 2 2007 ip.gif
「ip.gif」が、IP アドレスから国番号を検索するためのデータベースであり、 「cc.gif」が、国番号から国コード (ISO 3166 コード) への変換テーブルである。
メールを受信するたびにメールサーバで perl スクリプトを実行するのは、 メールサーバの負荷などの観点からあまり望ましくない (私のサイトではメールサーバを chroot 環境で動かしていて、 その chroot 環境には perl をインストールしていない、 というセキュリティ上の理由もある) ので、 IP::Country::Fast の perl スクリプトを C 言語で書き直してみた。 ほとんど perl スクリプトをそのまま C に置き換えただけなので、 説明は不要だろう。 inet_ntocc 関数に限ると、 C 版のほうが perl 版より簡潔に書けてしまっている点が興味深い。 コメントは、IP/Country/Fast.pm スクリプトのコメントをそのまま入れてある。
#include <stdio.h>
#include <stdlib.h>
#include <errno.h>
#include <sys/types.h>
#include <sys/stat.h>
#include <fcntl.h>
#include <unistd.h>
#include <sys/mman.h>
#include <sys/socket.h>
#include <netinet/in.h>
#include <arpa/inet.h>
#include <string.h>
#ifndef DBDIR
#define DBDIR "/usr/lib/perl5/site_perl/5.8.8/IP/Country/Fast"
#endif
#define CC_MAX 256 /* # of countries */
int inet_ntocc(u_char *ip_db, u_long inet_n) {
/*
FORMATTING OF EACH NODE IN $ip_db
bit0 - true if this is a country code, false if this
is a jump to the next node
country codes:
bit1 - true if the country code is stored in bits 2-7
of this byte, false if the country code is
stored in bits 0-7 of the next byte
bits 2-7 or bits 0-7 of next byte contain country code
jumps:
bytes 0-3 jump distance (only first byte used if
distance < 64)
*/
u_long mask = (1 << 31);
const u_long bit0 = 0x80;
const u_long bit1 = 0x40;
int pos = 4;
u_char byte_zero = ip_db[pos];
/* loop through bits of IP address */
while (mask) {
if (inet_n & mask) {
/* bit[$i] is set [binary one]
- jump to next node
(start of child[1] node) */
if (byte_zero & bit1) {
pos = pos + 1 + (byte_zero ^ bit1);
} else {
pos = pos + 3 + ((ip_db[pos] << 8 | ip_db[pos+1]) << 8
| ip_db[pos+2]);
}
} else {
if (byte_zero & bit1) {
pos = pos + 1;
} else {
pos = pos + 3;
}
}
/*
all terminal nodes of the tree start with zeroth bit
set to zero. the first bit can then be used to indicate
whether we're using the first or second byte to store the
country code */
byte_zero = ip_db[pos];
if (byte_zero & bit0) {
if (byte_zero & bit1) {
/* unpopular country code - stored in second byte */
return ip_db[pos+1];
} else {
/* popular country code - stored in bits 2-7
(we already know that bit 1 is not set, so
just need to unset bit 1) */
return byte_zero ^ bit0;
}
}
mask = (mask >> 1);
}
return -1;
}
u_char *getdb(char *file, int *fdp, int *lenp) {
char path[PATH_MAX+1];
int fd;
struct stat st;
int length;
u_char *db;
snprintf(path, PATH_MAX, "%s/%s", DBDIR, file);
path[PATH_MAX] = '\0';
fd = open(path, O_RDONLY);
if (fd < 0) {
fprintf(stderr, "Can't open: %s err=%d\n", path, errno);
exit(1);
}
if (fdp) *fdp = fd;
if (fstat(fd, &st) < 0) {
fprintf(stderr, "Can't stat: %s fd=%d err=%d\n", path, fd, errno);
exit(1);
}
length = st.st_size;
if (lenp) *lenp = length;
db = (u_char*)mmap((void*)0, length, PROT_READ, MAP_SHARED, fd, 0);
if (db == MAP_FAILED) {
fprintf(stderr, "Can't map: %s fd=%d len=%d err=%d\n",
path, fd, length, errno);
exit(1);
}
return db;
}
int main(int argc, char *argv[]) {
int i;
u_char *ip_db = getdb("ip.gif", NULL, NULL);
const char *_cc =
"USDEGBNL--FREUBEITESCACHRUSEAUAT"
"PLCZIEFIJPDKNOUAZANGILROGRCNPTHU"
"INTRIQSGHKCYIRLTNZKRLUBGAEARBRSI"
"IDCLSKTWSAMYTHYUMXLVCOPHLBPKKZGH"
"EETZKWKERSBDHRDZEGVECMPEECLIPRGE"
"ISMEAPBYMGMDAOCIMTSOPAZWVNBANEBH"
"PSJOCDMZAZMAUZDOBJAMUGSLCGGNZMMU"
"TJMCANMWJMGIMKCRBMLRBOUYGTBWLKGP"
"ALGAMQKGTTNASVLYMNMRAFNPSNKHBBQA"
"CUGLBNOMMOPYSYPGNISMMLSCDJSZLSBF"
"CFGUNCVGHNFJPFTDLAYEFOBISDGQRWKY"
"**BSSRADGMCVGDKNETERRETNTMTGYTMV"
"VIHTKMSTGWAGVABZBTNRTOFKKIVUMPWS"
"MMAWSBJEGFAIAQIOGYNFLCPWCKDMAXFM"
"TVNUAS--------------------------"
"--------------------------------";
#ifdef CHECKCC
int cc_fd;
int cc_len;
int cc_num;
u_char *cc_db = getdb("cc.gif", &cc_fd, &cc_len);
char cc[CC_MAX * 2 + 1];
cc_num = cc_len / 3;
if (cc_num < 0 || CC_MAX <= cc_num) {
fprintf(stderr, "Can't happen: irregular CC DB cc_num=%d\n", cc_num);
exit(1);
}
for (i=0; i < CC_MAX; i++) {
cc[i*2] = '-';
cc[i*2+1] = '-';
}
cc[i*2] = '\0';
for (i=0; i < cc_num; i++) {
u_char c = cc_db[i*3];
cc[c*2] = cc_db[i*3+1];
cc[c*2+1] = cc_db[i*3+2];
}
munmap(cc_db, cc_len);
close(cc_fd);
if (strcmp(cc, _cc) != 0) {
for (i=0; i < CC_MAX; i+=16) {
int j;
printf("\"");
for (j=0; j < 16; j++) {
printf("%c%c", cc[(i+j)*2], cc[(i+j)*2+1]);
}
printf("\"\n");
}
}
#else
const char *cc = _cc;
#endif
for (i=1; i < argc; i++) {
u_long in = ntohl(inet_addr(argv[i]));
int c = inet_ntocc(ip_db, in);
if (c < 0) {
printf("UNKNOWN %s\n", argv[i]);
} else {
printf("%c%c %s\n", cc[c*2], cc[c*2+1], argv[i]);
}
}
return 0;
}
国コードへの変換テーブル「cc.gif」は、 変更頻度もさほど高くないだろうと思われたので、 プログラム中に固定文字列として定義している。 コンパイル時に「-DCHECKCC」を指定することにより、 cc.gif と内蔵の変換テーブルが一致するかチェックできる。
あとは、このコードを MTA に組み込むだけ。 私のサイトでは qmail を 使っているので、 qmail-smtpd.c にこのコードを組み込んだ。
2006年10月06日久しぶりに sed の話題を見かけたので、 思わずトラックバックしてみます。
「アキバ系!文京区本郷四畳半社長」曰く
最近はSEDとかみんな使わないのかなあ 便利なのに
...
Rubyスクリプトさえ書きたくないときにはSedです。
Sedの過激な使い方については 往年の名著「MS-DOSを256倍使うための本 vol.2」が めっぽう面白い
これこそハックだよなあ
手前ミソながら、sed の過激な使い方にかけては、 SED 教室 も そこそこいい線行っているんじゃないかと自負しておりますが、 いかがでしょうか？
例えば、 SED 教室 第十一回 「正規表現、再論」 で紹介している、 sed で「uniq -c」コマンドを実現するスクリプト:
x
1s/.*/ /
H
y/ 0123456789/11234567890/
G
s/.*\([^0]0*\)\n.*\n\(.*\)[^9]9*$/\2\1/
x
s/\n.*//
$!N
/^\(.*\)\n\1$/!{
x
G
s/\n/ /
P
s/.*/ /
x
}
D
なんてのは、ぱっと見では何をやってるんだか、 まるで分からないこと請け合い ;-)
2006年09月27日GNU screen の バグ報告を行なう ついでに screen-devel ML に参加したら、 次のようなメールが ML に流れてきた:
There is a much simpler solution
http://www.2701.org/archive/200406150000.html
The key is that SSH_AGENT need not point to a socket, it can point to a symbolic link to a socket.
なるほど〜
ssh-agent と通信するための UNIX ドメイン ソケット を指す (パス名固定の) シンボリック リンクを作るようにしておけば、 環境変数 SSH_AUTH_SOCK には、そのシンボリック リンクのパス名を 設定しておけば済むので screen の中で ssh を使うとき便利、 というわけである。 つまり、
senri:/home/sengoku % ssh asao Last login: Sun Sep 10 08:24:20 2006 from senri.flets.gcd.org Linux 2.6.16.28. asao:/home/sengoku % echo $SSH_AUTH_SOCK /tmp/ssh-chKJY25976/agent.25976 asao:/home/sengoku % screen -r
senri で ssh-agent を走らせておいて、 asao へ ssh でログインするさいに、 ForwardAgent を有効にしておくと、 上の実行例のように、SSH_AUTH_SOCK に UNIX ドメイン ソケットの パス名が設定され、このソケットを介して senri の ssh-agent と通信ができる。
ところが、前回のログイン時に使っていた screen を reattach すると、 screen の中では、SSH_AUTH_SOCK の値は、 前回のログイン時のパス名のままである:
asao:/home/sengoku % echo $SSH_AUTH_SOCK /tmp/ssh-ptnuvb3346/agent.3346
ForwardAgent はログアウトと共に終了するので、 screen の中の SSH_AUTH_SOCK の値は、 ログインするごとに設定し直す必要がある。 これはとてもメンドクサイ。
ログインし直すたびに SSH_AUTH_SOCK の値が変化するから、 このような問題が起きるわけで、 SSH_AUTH_SOCK の値が常に同じなら、 reattach した screen の中でも同じ SSH_AUTH_SOCK の値を使い続けることができる。
すなわち、 SSH_AUTH_SOCK が直接 UNIX ドメイン ソケットを指し示すのではなく、 UNIX ドメイン ソケットを指し示すシンボリック リンクを作成しておいて、 SSH_AUTH_SOCK にはこのシンボリック リンクのパス名を設定しておけばよい。
さっそく ~/.cshrc に次の行を追加した:
set agent = "$HOME/tmp/ssh-agent-$USER" if ($?SSH_AUTH_SOCK) then if (! -S $SSH_AUTH_SOCK) unsetenv SSH_AUTH_SOCK endif if ($?SSH_AUTH_SOCK) then if ($SSH_AUTH_SOCK =~ /tmp/*/agent.[0-9]*) then ln -snf "$SSH_AUTH_SOCK" $agent && setenv SSH_AUTH_SOCK $agent endif else if (-S $agent) then setenv SSH_AUTH_SOCK $agent else echo "no ssh-agent" endif unset agent
私は、かれこれ 20年近く csh をログイン シェルとして使い続けてきているので、 ~/.cshrc なのだが、今となっては (極めて?) 少数派だろう。 bash など、sh 系をログイン シェルとして使っている場合は、 ~/.profile などに
agent="$HOME/tmp/ssh-agent-$USER" if [ -S "$SSH_AUTH_SOCK" ]; then case $SSH_AUTH_SOCK in /tmp/*/agent.[0-9]*) ln -snf "$SSH_AUTH_SOCK" $agent && export SSH_AUTH_SOCK=$agent esac elif [ -S $agent ]; then export SSH_AUTH_SOCK=$agent else echo "no ssh-agent" fi
などと書いておけばよいだろう。
2006年08月28日
GNU screen の
最新バージョンである 4.0.2 において、
SJIS な端末で screen を走らせて screen のウィンドウで eucJP を使おうとすると、
1 バイト文字の前に 0x8E が挿入されてしまう。
つまり、
screen のコマンド「encoding eucJP SJIS」
(kanji euc sjis) を実行した場合とか、
あるいは「KJ=SJIS」を指定した端末で「defencoding eucJP」
(defkanji euc) を指定した
screen を使うといった場合である。
なぜだろうと思い、ソースを確認すると、encoding.c の 1154 行目あたりが 次のようになっている:
if ((0x81 <= c && c <= 0x9f) || (0xe0 <= c && c <= 0xef))
{
*statep = c;
return -1;
}
return c | (KANA << 16);
え？ これってもしかして 2 バイト文字 (全角文字) 以外は 全て 1 バイトカナ (半角カナ) 扱いにしてしまっている？
screen 4.0.2 は、2004年1月27日に公開されていて (私の知る限り) これが最新版だと思うのだが、 このような単純なバグが 2年以上にわたって放置されているとは信じられないので、 すでにパッチが出回っていて、 開発元にも連絡が行っているのではないかと思う。 ご存じの方はご指摘頂ければ幸いである。 しばらく様子をみて、ご指摘が無いようであれば、 念のため開発元にパッチを送ってみる予定。
言うまでもなく、0x80 未満 (最上位ビットが 0) の文字は、 「KANA」扱いしてはいけないので、 上記コードは以下のようであるべきだ:
if ((0x81 <= c && c <= 0x9f) || (0xe0 <= c && c <= 0xef))
{
*statep = c;
return -1;
}
if (!(c & 0x80)) return c;
return c | (KANA << 16);
このような修正を加えることにより、例えば ~/.screenrc で
defkanji euc terminfo xterm KJ=sjis terminfo kterm KJ=euc terminfo vt100 AB=\E[4%p1%dm:AF=\E[3%p1%dm:KJ=euc
などと設定して、term=xterm な端末 (term は xterm であるが「シフトJIS」な漢字を表示できる) を使うような場合でも、 漢字を正しく表示できるようになった。
Linux の多くは EUC を標準的な漢字コードとして使っているはずで、 その一方で Windows は SJIS が標準的な漢字コードだったはず (最近は UTF8 の方が多い？) なので、 このような SJIS な端末で EUC な screen を使うケースは 決してレアケースではないと思うのだが、 なぜこのようなバグが放置されていたのかとても不思議である (ちなみに私は Windows 上の TeraTerm を EUC の設定で使っていたため、 このバグに今まで気づかなかった)。
このバグは、端末の漢字コードが SJIS で、かつ
screen のウィンドウの漢字コードが SJIS 以外の場合
(つまりコード変換が行なわれる場合) に発現する。
全ての 1 バイトコード (0x00 〜 0x1F のコントロールコードさえも!) の
前に「0x8E」をつけてくれるので、
screen の detach すらできなくなるという凶悪なものである。
念のため screen 4.0.2 に対する patch の形で修正点を示しておく:
--- encoding.c.org Mon Sep 8 23:25:23 2003
+++ encoding.c Mon Aug 28 18:11:57 2006
@@ -1151,6 +1151,7 @@
*statep = c;
return -1;
}
+ if (!(c & 0x80)) return c;
return c | (KANA << 16);
}
t = c;
2006年05月10日拙作 時刻表ビューア を、 Fossil/ABACUSのPalmOSが搭載された腕時計 WristPDA(腕パーム) に 移植して頂いた。
私は、時刻表ビューアのバージョンアップは 2000年8月を最後に行っていない。 その後、Linux Zaurus SL-C700 を使うようになってからは、 Palm 自体を使わなくなってしまっていたので、 時刻表ビューアを見ることさえなくなってしまっていた。
作者自身が忘れていたソフトウェアを、 新しい機種に移植して利用していただけたというのは 大変嬉しいことであり、 オープンソース化しておいて 本当によかったと思う。
2006年04月22日開発環境の進化が、 プログラマのプログラミング能力を退化させていると思う。 私は、いわゆる統合開発環境というものを使ったことがなく、 いつでも emacs を愛用している。 しかも画面サイズは 20年来 80桁x24行のままである。
プログラミングは、メモを書きながら設計したあと、一気に書く。 設計さえきちんとできていれば、途中で手が止まることはあまりない。 食事も忘れて何時間も没頭することがよくある。 そして書き終えてたらコンパイル。 タイプミスとか変数宣言し忘れとかで出たコンパイルエラーを ひとつずつ修正。
で、コンパイルに成功したら実行させる。多くの場合、これで動く。 一通り動作確認して、期待しない動作をするところがあっても、 ほとんどの場合ソースを参照するまでもなく原因に思い当たる。 たいていの場合、デバッガを使うまでもなく、 ソースを見直すだけでどう修正すべきかも分かる。
という話をすると、奇異な目で見られてしまう。(^^;)
目視だけでデバッグと題するページで、
私と同じような感覚の人を見つけて安心した。
たいていの人は、デバッガでステップ実行させて、 実行中の変数を参照したり、 値を変えてみたりしてプログラムを修正するのだという。 たしかに頭の中でプログラムの動作を追うより、 デバッガを使って実際に動かしてみるほうが楽かもしれないが、 それでプログラミングスキルが伸びるのだろうか？
まるで、将棋を指すとき対戦用の盤面とは別に、 相手の指し手の可能性を検討する盤面を脇に置いて、 次の一手を検討しているようなものではないか。 そんなことをしていたら、 次の一手を考えるのに膨大な時間がかかってしまうし、 頭が鍛えられないので上達も難しいだろう。
プログラミングも同じ事。 頭の中に仮想的にデバッガを構築して、 無意識の思考でプログラムを実行させることができなければ、 いつになってもプログラムを見通す洞察力は身につかないだろう。
