Nano domain - diary

← 戻る

2004/8/1 （日）

glibc 2.3.3

動的リンクシンボルが勝手に消えたり移動したりするの，いいかげんやめてほしいよね……。

まぁ，しょせん GNU の連中にそんな品質管理を要求する方が無理なんだろうけど。

akane:~> w3m
w3m: relocation error: w3m: symbol __libc_stack_end, version GLIBC_PRIVATE not 
defined in file ld-linux.so.2 with link time reference

しかし，意外に NPTL と Linuxthreads の互換性は高いようだ。

Apache 2.0.50 や JDK 1.4.2 は，リコンパイルなしにそのまま動作している。

/lib/libpthread-0.10.so
/lib/libpthread-2.3.3.so*
/lib/libpthread.so -> libpthread.so.0*
/lib/libpthread.so.0 -> libpthread-2.3.3.so*

NPTL つきで glibc 2.3.3 をコンパイル・インストールすると上のようなファイル構成になる。 glibc 2.3.2+linuxthreads でコンパイルした Apache などは

        libpthread.so.0 => //lib/libpthread.so.0 (0x402c4000)

に dynamic link されているが，NPTL の libpthread-2.3.3.so で正常に動いているようだ。

スレッドつきでコンパイルした named（bind）や，自作のプログラムなども正常に動作しているので，互換性はそこそこ期待してもよさそうだ。

2004/8/2 （月）

2004/8/3 （火）

samba 3.0.5

glibc 2.3.3 を入れたのは NPTL を使いたいからではなくて，samba 3 系列を使うため。

2.2 系列が今年の10月で（セキュリティ修正を含め）リリースされなくなるということなので，セキュリティホールの出た 2.2.9 から，この際 samba 3.0 系列に移行しようと思ったわけ。

samba 3.0 系列を実用的に使う手段としては，2.3.2 にパッチを当てるとか libiconv を入れるといった方法もあるのだが，

2.3.2 はなぜか akane では make install がうまく動かない
libiconv を入れると後々ほかのアプリケーションで configure に悪影響を与えるような気がする

ということで，正攻法で 2.3.3 を入れることにした。といっても，cvs 版しかないんだよねぇ。

正式版 glibc は2003年3月の 2.3.2 のまま止まっている。最近あちこちの Linux ディストリビュータからリリースされている glibc-2.3.3 は，cvs から持ってこられたもの（2003年12月くらいがベース？）。

Linux: so what's happening? というページを見つけたのだが，どうも glibc 2.3.3 は "released" になっていて，2.3.4 と名乗るシンボルも含まれるようになっているのに，全く正式版 2.3.3 がリリースされる気配はないらしい。GNU の glibc のページも，2.3.2 が正式版と書いてあるままになっている。

glibc-2.3.3 からは cvs が正式版になったという本当か嘘かわからないようなことを書いているページもあって，いったいどうなっているのかさっぱり不明。これだから（ｒｙ

だいたい，実質的に Linux でのみ使われているライブラリで（Hurd？それは OS 自体が実質的に使われていないよね？）スレッドライブラリなんていう基幹部分を入れ替えるということになったら，スレッドライブラリのマージは 2.4 系列にしつつ，2.3 を維持しようとか考えるのが妥当なリリース管理なんじゃないだろうか。linuxthreads の add-on ディレクトリは残されてはいるけどさ。

で，samba 3.0.5 を make check すると，まともに通過しないんだよねぇ。しかもロケールが絡んでそうないやな FAIL が……。

python stf/standardcheck.py; \
if test -n ""; then \
        python stf/pythoncheck.py; \
fi
StrCaseCmp                     OK
strstr_m                       FAIL
-----------------------------------------------------------------
Traceback (most recent call last):
  File "stf/comfychair.py", line 325, in runtests
  File "stf/strings.py", line 138, in runtest
  File "stf/strings.py", line 100, in run_strstr
  File "stf/comfychair.py", line 194, in runcmd
  File "stf/comfychair.py", line 245, in runcmd_unchecked
AssertionError: 't_strstr "hello" "goodbye"' terminated with signal 11
test_log:
Run command: t_strstr "hello" "hello"
Wait status: 0x0 (exit code 0, signal 0)
stdout:
hello

stderr:

-----------------------------------------------------------------
PushUCS2_Tests                 OK
NoArgs                         OK
OneArg                         OK
SmbdDest                       OK
NmbdDest                       NOTRUN, not implemented
WinbinddDest                   NOTRUN, not implemented
PidDest                        OK
SelfDest                       OK
BadDest                        OK
BadCmd                         OK
Debug                          OK
ForceElection                  OK
SamSync                        OK
SamRepl                        OK
DmallocMark                    OK
DmallocChanged                 OK
Shutdown                       OK
DrvUpgrade                     OK
CloseShare                     OK
Ping                           OK
Debuglevel                     OK
PrintNotify                    OK
Profile                        OK
ProfileLevel                   OK
TimeoutArg                     OK
ConfigFileArg                  OK
BogusArg                       OK
snprintf_Test                  OK

最近は check 用のスクリプトを Python で書いたりするんだねぇ。

3.0.5 がかような感じで make check 通過しないので，2.2.10-ja を入れてしのいでいるわけだが……。その 2.2.10-ja も β版ということなのかもしれないが，samba.gr.jp には samba 2.2.9 のセキュリティホール情報までは載っているものの，2.2.10-ja がこっそり出ていることは全く載っていない。

ちゃんと管理してほしい……。

2004/8/4 （水）

glibc 2.3.3

glibc-2.3.3 の正式版が出ないとかいっていたら，8/3 付けで出たようだ……。

tomcat

この日記の各月ごとのページに，月一覧へのリンクがない理由：

それは，SERE0/1/2 ごとに分岐するような JSP コードを先頭に入れるのが美しくないから。

まぁ，しかし確かに言われてみるとあった方がいいかもしれないので，include を使って入れてみることにした。

「かもしれない」理由：

月一覧から見に来た人は，ブラウザの機能で戻れるから問題ない。
というか各月を順に見るような場合，ブラウザの戻るを使うのが普通だと思うんだが……。
サーチエンジンから飛んできた人は，一般的に他の月の日記には興味ないと思われる。
そのような場合でも，URLを編集して pdiary/ で終わるようにした場合，一覧へのリンクが（一応）出る。

2004/8/5 （木）

2004/8/6 （金）

Postfix 2.1.4 + starttls

Becky! がいつのまにか POP3S + SMTPS に対応していることに気づく。こっそりスプラッシュ画面も変わってるし。

SCHANNEL API でがんばって SSL 対応した作者は偉いと思うけど，遅すぎた感がありまくり。 SCHANNEL API で実装するのが面倒なのは経験済みなのでよく知っているけど……。

なにはともあれ，めでたいので akane の Postfix も STARTTLS に対応させてみた。

STARTTLS への対応自体は難しくない。ただ，非公式のパッチが必要。作業内容は Postfix で TLS というページに詳しいが，パッチのパッケージに同梱されているドキュメントを読んでも問題ないだろう。

上のページは SSL で待機する daemon （smtps）も起動しているので，そのへんをごっそり削れば STARTTLS のみになる。

Postfix 周りで検索していて見つけたこれの 2.5 だけど……。主張はよくわかるんだけど……。

パスワード総当たり攻撃を受けるというのは明示的に攻撃対象にされてるということで，通常はどうしようもないんじゃないだろうか。パスワードの強度を上げたところで DoS アタックなのは防ぎようがないし。

SMTP Auth をどうにかしても，POP3 や IMAP のサーバが立ってたら終わりなんだし。

*-MD5 にしたところで，パスワードの強度は変わらないだろうしなぁ（8文字より長いパスワードが使える，ということなら PLAIN でも別パスワードファイルを作ればできるだろうし）。

2004/8/7 （土）

2004/8/8 （日）

よくわかる←→

午前2時過ぎ現在。

こちらは独自路線。

RAID1 Verify error

そろそろやばそう……。

3w-xxxx: scsi0: AEN: INFO: Verify started: Unit #0.
3w-xxxx: scsi0: AEN: ERROR: Verify failed: Port #0.
3w-xxxx: scsi0: AEN: INFO: Initialization started: Unit #0.

詳細はというと，

Aug  8 03:00:07 akane 3w-xxxx[4615]: INFORMATION: Verify started on unit 0 on c
ontroller ID:0. (0x29)
Aug  8 03:12:40 akane 3w-xxxx[25263]: ERROR: Verify failed on unit 0 on control
ler ID:0. due to parity mismatch.  Check drives for media errors. (0x2a)

交換用の HDD をキャプチャテンポラリから解放して，入れ替えるべきだなぁ……。

5月だかにも Verify Error 出ていた気がするし。しかし，損傷が発生しているのはどちらのボリュームなんだろうか。Verify Error だけではなんともいえないのだが……。

今年の夏は HDD が3台損傷したというのか？もはや，このくそ暑い夏にエアコン使わない家族が悪いとしかいいようがない。

krfilter

英語版作ってみた（ぉ

年々英語力が低下してるのを実感する……。

2004/8/11 （水）

ウマオイ

そろそろ秋か。

2004/8/13 （金）

今日はとてもいいことがありました（非公開）

京都巡回

京都駅前地下街。

予算がかかったのは理解する。だがしかし，でかでかとプレートを出すようなことなのか……？

京阿月（ポルタ店）のかき氷は相変わらずおいしい。

京しぐれ（780円，かき氷+抹茶シロップ+練乳+抹茶アイスクリーム）と抹茶金時（680円，かき氷+抹茶シロップ）で 100円の差がいまいち感じられないのが謎だが……。

東本願寺では，本堂全改修工事のため，いまなら1万円で瓦にあなたの名前が入ります。

JR-ISETAN で弁当を買って東京へ帰還。

2004/8/14 （土）

ICOCA

Suica 定期券を ICOCA エリアで使ってきた結果。

新大阪駅でチャージ，新大阪 - 吹田，吹田 - 京都が全て「未登録駅」になっているのは，PaSoRi に付属してるビューワが非対応なだけだと思うが……。

2004/8/21 （土）

SPF（Sender Policy Framework）

Microsoft の Caller ID と，SPF を統合した形で Sender ID が IETF で審議され始めた，と Microsoft がアナウンスしたのは記憶に新しいところだが，SPF についての日本語ドキュメントが google で引っかからないので少し調べてみた。以下の説明は主に SPF のサイトを参考にしている。

まず，SPF と Caller ID の統合について。IETF でどうなっているか調べたわけではないが，おおよそこういう感じらしい。

Sender ID といっても，普及しているのは SPF である（既に 20000 ドメイン以上が対応しているらしい）。
SPF は（SIP のように）プレインテキストベースで，MS のは XML ベース。
誰も XML をわざわざ parse したくないから，MS の提案仕様なんか見向きもしていない。

MS が hotmail に搭載しているのは Caller ID なのかもしれないが，一般に普及しているのは SPF である。

次に，各種 MTA のサポート状況について。

Sendmail 社は既にサポートを表明。フリー版でもなんかがんばるとできる模様。
Postfix 用の SPF パッチはここにある模様。
qmail とかにもパッチはある模様。
Microsoft は，次世代の Exchange Server でサポートする模様。

つまり，MTA 側ではサポートがおおよそ整っていることになる。

次に，DNS サーバのサポート状況について。

現行の bind9 では SPF レコードを付けることが可能。

従って，DNS 側も問題なし（Microsoft の DNS サーバでも，きっとサポートされるんだろう（？））。

SPF の仕組みについて。

あるドメイン（example.com とする）について，こんな感じの DNS 定義があったとする。

example.com.    IN      TXT     "v=spf1 mx"

v=spf1 は SPF のバージョン番号，mx は "example.com" の MX レコードで示されるアドレス（SMTP 受信サーバのアドレス）を公式なメール送出ホストとすることを表す。

従って，DNS に

@               IN      MX      10     ns.example.com.
ns                      A       1.2.3.4

と記述されていた場合，『@example.com のメールアドレスをエンベロープFromに持つメールは，IPv4 アドレス 1.2.3.4 からしか送出されることはない』という表明になる。

（念のために書いておくと，「エンベロープFrom」とは，SMTP プロトコルで MAIL FROM コマンドで指定する From アドレスのこと。いわゆる「メールヘッダ」中の From: 行のことではない。同様に，SMTP プロトコルの RCPT TO コマンドで指定する To アドレスのことを「エンベロープTo」という。）

では，エンベロープFrom が hogehoge@example.com のメールを受信した MTA は，SPF レコードをどのように活用して spam 判定をするのだろうか？

IP アドレス 2.3.4.5 から SMTP 接続があり，エンベロープFrom は hogehoge@example.com だった。
example.com の SPF レコードを見る。
example.com の SPF レコードには，@example.com のメールアドレスのメールは，IP アドレス 1.2.3.4 からしか送られてこないと書かれている。
IP アドレス 2.3.4.5 から @example.com のメールが送られてくるはずがない。
従って，いま送られてきているメールはアドレス詐称メールであり，spam か何かであろう。
エラーを返し，受信を拒否する。

ここでいくつかの罠が考えられる。

spam 業者が独自ドメインを取って，そのドメインに SPF レコードを設定し，そのドメインのエンベロープFromで spam を送った場合。
ある人は hogehoge@example.com をメインのアドレスとして使用しており，メールを送るときはどこのネットワークにいても使っている（モバイル運用中にプロバイダの SMTP サーバを使っているなど），といった場合。
メールを転送している場合。

まず，spam 業者が独自ドメインを取って SPF レコードを spam 送信マシンの IP アドレスに設定した場合。

ドメインを取らなければならない。ドメインは無料ではない。
ドメインが固定されているので，spam 業者のドメインを From を持つメールを排除すれば良い（ドメインをはじくシステムが RBL のような形で整備される必要はある）。

新規にドメインを取得し続ければ排除されずに済むが，現在ほどお手軽に spam を送ることはできなくなると思われる。

次に，example.com の公式メールサーバでない IP アドレスから，@example.com のメールアドレスでメールを送信するような場合について。

これは，example.com の DNS に SPF レコードが記述されているために起きる問題で，example.com の MTA サーバが SPF を利用する場合はもちろん問題にならない。症状としては，『自分の送ったメールが SPF 対応の MTA を利用している相手に届かない（蹴られる）』といったことが起きる。

『そういうことはするな』以外にどうしようもない。以下のように対処する。

example.com の SMTP サーバを SMTP auth 対応にして（open relay にしてはいけない），出先からは SMTP auth を利用して example.com のメールサーバを利用する。

自ドメイン（example.com）ドメインを利用しているユーザについて，必ずドメインの公式 SMTP サーバからメールを送出するように周知徹底する必要がある。

最後に，メール転送について。

現行の SMTP では，SPF が導入されるとメール転送はできない。

例えば，

hogehoge@example.com を From にして，example.com のメールサーバから taretare@example.org 宛にメールを送った。
example.org のメールサーバは，正統な example.com からのメールだったので受信。
taretare@example.org の人は，gyagya@example.jp 宛に転送設定していた。
example.org のメールサーバは，example.jp のメールサーバに転送のため接続。
example.org のメールサーバは，もちろん example.com の SPF レコードには載っていない。
example.jp のメールサーバは，From が hogehoge@example.com であるにも関わらず接続元が example.com のメールサーバでないため，メールの受信を拒否。
メールの転送は失敗する。

といったことが起きてしまう。

この問題を回避するには，SRS という方式を転送時に使う必要がある。

hogehoge@example.com を From にして，example.com のメールサーバから taretare@example.org 宛にメールを送った。
example.org のメールサーバは，正統な example.com からのメールだったので受信。
taretare@example.org の人は，gyagya@example.jp 宛に転送設定していた。
example.org のメールサーバは，example.jp のメールサーバに転送のため接続。
example.org のメールサーバは，当該メールの From を taretare@example.org に書き換えて転送する。
example.jp のメールサーバは，正統な example.org からのメールだったので受信。

現行の MTA は，メール転送時にエンベロープFrom を書き換えず，オリジナルのまま転送する。そうではなく，転送する人の転送するサーバでのメールアドレス（== オリジナルのエンベロープTo）に書き換えればいいという単純な話である。実装も楽勝と思われる。

単純な話ではあるが，SRS でない MTA がほとんどであるうちは SPF が実用にならないということを意味する。主要 MTA に SRS が取り込まれてデフォルトで on になり，普及が完了するまでにどれくらいの時間がかかるだろうか……。

2004/8/22 （日）

あえて書かない（非公開）

Sonybank

Sonybank の口座を放置していたら，ポスペ4匹のやるきが全くなくなっていた。

2004/8/25 （水）

ICOCA

14日に載せた SFCard Viewer の結果だが，SFCard Viewer2 だと表示できることがわかった。

ばっちりですね。

2004/8/28 （土）

ImageConverter

オプションを調べていて，ImageConverter.exe 中にこんな文字列を見つけたのだが……。

GIF_LIBRARY	IBMPC  Version 4.0, 	Gershon Elber,	Jul 25 2000,   15:57:49
(C) Copyright 1989 Gershon Elber, Non commercial use only.

SONY，大丈夫か？

exe ファイルを読むのはリバースエンジニアリング禁止条項に引っかかるから見つかるはずがない，とでもいうことだろうか。

テキストエディタで読むのはRE禁止条項に引っかかったりはしないよね？

あとわかるところでは，

libpng:

 libpng version 1.0.3 - January 14, 1999
   Copyright (c) 1995, 1996 Guy Eric Schalnat, Group 42, Inc.
   Copyright (c) 1996, 1997 Andreas Dilger
   Copyright (c) 1998, 1999, Glenn Randers-Pehrson

zlib？

deflate 1.1.4 Copyright 1995-2002 Jean-loup Gailly

zlib？

inflate 1.1.4 Copyright 1995-2002 Mark Adler

Independent JPEG Group の Release 6b:

27-Mar-1998Copyright (C) 1998, Thomas G. Lane

TIFF ライブラリ？

SGILog

.prc ファイル（画像？）を読むための libprc というものも入っているようだが，SONY 製かもしれない。

ヘルプファイルには，libtiff と libpng，zlib のコピーライト表示はあった。

SONY は自社でまともなメディアアクセスライブラリを開発してないのか？