(since '05.04.25)
この日記は不定期に更新されます。なんにせよ、大したことは書かれないはずですが。
取扱上の注意
・ 引数として与えた interface に関連づけられている inet6 な経路 の中から unicast な link-local address を含むものだけを引っ張り出す program を作ってみた。といっても、今度も netstat(8) から必要な 部分を取り出した*1だけだが (^^;。
・ で、これは動いたのだが、KVM をガシガシ読み出しているので、当然のように kernel への依存度が極めて高い。こんな program は保守したくないし、そも そも link の確認は周期的に（それなりに高い頻度で）行なわなければならな いのに対し、実際に cable が抜き差しされる頻度は非常に低い。つまり、そ のときに一時的にちょっとした負荷がかかるくらいでは誰も驚かない。という わけで、とりあえず netstat(8) の出力から実際に実行すべき command 列を生成する script を書いてみた。
・ Interface が down した時に消えて欲しい経路は、
という条件になる。ここで table を眺めてみると、4 番目の経路は gateway が必ず unicast link-local address になるし、destination が unicast link-local address である場合の gateway は MAC address（つまりは link） しかない。だから、3 番目と 4 番目の条件は「Destination か gateway が unicast link-local address である」という条件に集約できる。 問題になるのは対象となる link-local address が「unicast でなければならない」という点だが、netstat の出力では /128（＝ host address）以外のものには全て「/nn」という形で prefix length が付加されており、また network address が含まれる経路に は上記の全てを満たすものはない*2ので、「/」が現われる行は除外 してしまって構わないことになる*3。
・ こうなってくると、だいぶん話は単純になる。まずはここまでの条件を満たす command 列を作ってみる。
/usr/bin/netstat -ranf inet6 | /usr/bin/awk '/dc0$/{ print $1,$2; }' | /usr/bin/grep '\<fe80' | grep -v '/' | sed -e 's:^:/sbin/route delete -inet6 :'
これで、例えば
/sbin/route delete -inet6 default fe80::240:c7ff:fexx:xxb2%dc0 /sbin/route delete -inet6 fe80::240:c7ff:fexx:xxb2%dc0 0:40:c7:xx:xx:b2 /sbin/route delete -inet6 fe80::290:96ff:fexx:xxfe%dc0 0:90:96:xx:xx:fe
のような出力を得ることができる。実際に command を実行する場合は MAC address の代わりに「-link」と書かなければならないので、さらに これを書き換えることを考える。当初は「5 個 の `:' で区切られ た 16 進文字（列）からなる単語」という条件で match させようと思ったの だが、どうも FreeBSD の sed は「`%'」を単語の境界と見做してし まうらしく、今一つ。で、ちょっと見方を変えてみると、「左側に空白があり、 右側には行末がある、16 進文字と `:' からなる文字列」という条 件で match することが判る。というわけで、最終的な command が、これ↓。
/usr/bin/netstat -ranf inet6 | /usr/bin/awk '/dc0$/{ print $1,$2; }' | /usr/bin/grep '\<fe80' | /usr/bin/grep -v '/' | /usr/bin/sed -E -e 's:^:/sbin/route delete -inet6 :' -e 's/ [0-9a-f:]+$/ -link/'
実行すると、こういう↓結果が得られる。
/sbin/route delete -inet6 default fe80::240:c7ff:fexx:xxb2%dc0 /sbin/route delete -inet6 fe80::240:c7ff:fexx:xxb2%dc0 -link /sbin/route delete -inet6 fe80::290:96ff:fexx:xxfe%dc0 -link
この command 列を実行すると、ちゃんと希望の動作をしてくれる。というわ けで、この出力を eval するなり、file にはいて実行するなりすればいい。
*1: 今まで全く意識していなかったのだが、netstat(8) って、/usr/bin/ にあったのね。考えてみれば、いくら section 8 とはいえ、route(8) や ifconfig(8) と違って、必ずしも（boot 時に）使えなきゃ困る もんでもないもんなぁ。
*2: Address が link-local でないか、もしくは別の interface（普通は lo0）に関連づけられている。
*3: Unicast address には prefixlen が表示されないことを利用している。
・ 実に久々に mail を読んで殺意を覚えたぞ。
・ まあ、書いてることが支離滅裂だし、（以下自粛）なヤツは放っておくに限る。
・ それにしても、「第三者の不利をして援護射撃をしている」というのがばれて いないと、本人は本当に思ってるのかね。Mail header を見れば一目瞭然だし、 私の mail の from と signature に書いてある address が違うということに 過剰反応している*4あたり、「語るに落ちた」というところ。
・ ‥‥と思っていたら、何人もの人からツッコミが入って、静かになった。これ でまたしばらくは出てこないだろう。
*4: 実は、普段は signature には両方とも書いてあるんだが、ふと思いついて from に使っている address を削ってみた。そもそも私はどこに行っても私で しかないので（pen name や nickname などはいろいろ面倒くさいので使った ことがない）、「本名を隠す」も何もないのだが、自分がそういうことをして いると廻りもそうだと思ってしまうんだろう。
・ 赤坂さんから mail をいただいた。ありがとうございます m(__)m。 こういう情報は、本当にありがたい。
「hosts_ctl() は tcp_wrappers に含まれている関数なの で、
APPENDDEF(`confENVDEF', `-DTCPWRAPPERS') APPENDDEF(`conf_sendmail_LIBS', `-lwrap')
あたりを devtools/Site/site.config.m4 あたりに書けばよいのでは」ということだったので、compile 時の log を調べてみた。 ところが、mail/sendmail/files/site.config.m4 には
APPENDDEF(`conf_sendmail_ENVDEF', `-DTCPWRAPPERS') APPENDDEF(`conf_sendmail_LIBS', `-lwrap')"
が含まれているし、link に失敗した際の command line にも
cc -o sendmail -L/usr/local/lib main.o alias.o arpadate.o bf.o collect.o conf.o control.o convtime.o daemon.o deliver.o domain.o envelope.o err.o headers.o macro.o map.o mci.o milter.o mime.o parseaddr.o queue.o readcf.o recipient.o savemail.o sasl.o sfsasl.o shmticklib.o sm_resolve.o srvrsmtp.o stab.o stats.o sysexits.o timers.o tls.o trace.o udb.o usersmtp.o util.o version.o -lwrap -lssl -lcrypto -lldap -llber /export2/src/ports/mail/sendmail-ldap/work/sendmail-8.12.3/obj.FreeBSD.4.4-RELEASE.i386/libsmutil/libsmutil.a /export2/src/ports/mail/sendmail-ldap/work/sendmail-8.12.3/obj.FreeBSD.4.4-RELEASE.i386/libsm/libsm.a -ldb -lutil
というように -lwrap が含まれている。
・ そこで、mail/sendmail/files/site.config.m4.* を check してみ ると、LDAP support を含めるかどうかによる差異の中に、
APPENDDEF(`confLIBDIRS', `-L%%LOCALBASE%%/lib')
が追加される、というものがあった（mail/sendmail/files/site.config.m4.ldap）。
・ 「もしかして -L が 1 つでも指定されると cc は標準の library path を忘れてしまうのでは？」と思い、mail/sendmail/files/site.config.m4 に
APPENDDEF(`confLIBDIRS', `-L/usr/lib')
を追加してみたら‥‥通った (__;。情報をいただかなければ、こう とんとんとは進まなかった。大感謝です m(__)m。
・ Compile していたのは 4.4-RELEASE なのだが、-current では大丈夫なのか、 追試の必要がある*5な。どちらにしても、含まれていて困る内容ではないので、 send-pr しておいたほうがいいのかも。‥‥英語でどう説明するかが問題だ‥‥ (-.-;;。
*5: System に標準で含まれている gcc の version が違うので、このあたりの振 舞いが異なっている可能性がある。
・ ‥‥まだ懲りずに投稿してきている。勝手に暴れている分には放っておけばい いのだが、間違った情報がばら蒔かれる（そして、それは一種の knowledge DB として ML search site に蓄積される）のは、非常に迷惑だ。どうしたも のか。
・ こういうことが相次ぐと、blacklist DB が欲しくなるな。
・ Apache や PHP を入れ替えてから、PostgreSQL の DB をうまく検索できない という現象が出ていたが、実は以前に PostgreSQL の major version を上げ た際に、旧い binary と新しい binary が混在してしまっていた、というのが 諸悪の根源であった。実にくだらない。
・ というわけで、旧い binary はさようなら。
・ そんなこんなで、無事に参照できるようになった。ところが、漢字を含む文字 列を検索させると、正しく結果が返ってこない。
・ Browser で文字列を表示させると、正しいように見える。しかし、実際に query を投入すると、
Warning: pg_query() query failed: ERROR: Invalid regular expression: parentheses ( ) not balanced in ほげほげ on line どこか
といわれてしまう。
・ PHP4 の内部 encoding は、/usr/local/etc/php.ini では EUC-JP に設定している。また、PostgreSQL 側でも、data は EUC-JP で作成している。なので、form から入力された文字列が内 部 encoding へ正しく変換されているとするならば、このような現象は出る筈 がない。なにより、「Invalid regular expression: parentheses ( ) not balanced」などと言われているのが、いかにも胡散臭い*6。そこで、POST された文字列を単純に
$_POST["ほげほげ"]
と受け取っていたのを
mb_convert_encoding($_POST["ほげほげ"], "EUC-JP", "auto")
と書き換えたところ、正しく検索されるようになった。もしかして、/usr/local/etc/php.ini で
mbstring.internal_encoding = EUC-JP mbstring.http_input = auto mbstring.http_output = ISO-2022-JP
としているのが問題？ mbstring.http_input をpass にすると無変換になると いうことなので、これが auto に設定されていると、「入力の encoding を自動検出して、内部 encoding に自動変換する」という動作にな ると思っていたのだが。しかし、mb_convert_encoding は、第 3 引数を省略すると変換前の文字列が内部 encoding であると仮定するという仕様になっていて、実際に
mb_convert_encoding($_POST["ほげほげ"], "EUC-JP")
のように記述するとどうも encoding の変換が発生しないようなので*7、もしか すると入力変換がらみの設定か code に問題があるのかも。でも、出力側の変 換は
output_handler = mb_output_handler
のように method を override してやらないと機能しないのに対し、入力側に ついては「mbstring.http_input を設定する以外の方法は（したく ても）ない」と manual に明記されているので、他に何か設定しなきゃならないことがあるとも思えないんだけど‥‥。
*6: もし ISO 2022 JP で encoding されているとすると、shift in/out の code に「(」が入る。
*7: つまり、PHP はおそらく「既に内部 encoding に変換されている」と思ってい るのだろう。
・ さて、無事に compile も終わったので、install と実験を。
・ Port から mail install すると、/usr/local/etc/rc.d/sendmail.sh.sample と /usr/local/etc/rc.d/sm-client.sh.sample が install される が、今回は sendmail の全機能を使用するので、 sendmail.sh.sample の方を使用する。
・ まずは、server を reboot した際に標準の sendmail が動かないようにするため、/etc/rc.conf に
sendmail_enable="NO"
を追加*8。
・ 次に、sendmail.cf の再生成。
・ 実は、8.11.* からの移行の場合、特に .cf を変更しなくても大抵の場合正常に動作する。しかし、うちの 環境の場合、そのままでは mail header に
X-Authentication-Warning: <host 名>: Host <relay host 名> [<relay host の address>] claimed to be <逆引きした host 名>
のような行が挿入されてうるさいので、とりあえず .mc の
define(`confPRIVACY_FLAGS', `authwarnings,noexpn,novrfy')dnl
を
define(`confPRIVACY_FLAGS', `noexpn,novrfy')dnl
に書き換えて対処。本当はこれだとその他の X-Authentication-Warning: も抑止されてしまうのであまりよろし くないのだが、根本的対策を取ってからまた warning を有効にすることにす る。
・ さらに、一部の flag の設定の仕方が変わっているようなので、それを修正。 実際に動かしてみると判るが、
FEATURE(access_db, `hash -o /etc/mail/access')dnl
の行が含まれている場合、「-T<TMPF> が指定されてねーぞ こら」と warning が出る。そこで、これを
FEATURE(access_db, `hash -T/etc/mail/access')dnl
と書き換える。
・ さて、ここからが本命。LDAP routing 用の設定を書き加える。といっても、
define(`confLDAP_DEFAULT_SPEC', `-h <LDAP server の host 名> -b "<LDAP DB tree を参照する際の DN>"') LDAPROUTE_DOMAIN(`<LDAP routing の対象になる domain 名を空白で区切って羅列>') FEATURE(`ldap_routing')
を MAILER(... の行より前に追加するだけ。
・ いよいよ、sendmail を切り換える。まずは現在走っている sendmail を kill。さらに
# /usr/local/etc/rc.d/sendmail.sh start
として、新しい sendmail を起動する。こんだけ*9。確かめてみると‥‥をを、 ちゃんと DB 通りに配信されている:-D。
・ LDAP routing を利用する際、FEATURE(`ldap_routing') の第 3 引数に「passthru」以外の単語を指定すると、「LDAPROUTE_DOMAIN() に指定された domain 宛の mail で、<mailHost> map も <mailRountingAddress> map も 持たない address 宛てのものは、その 時点で unknown user 扱いとして bounce する」という動作になる。今回はそ れを望まない*10ため、何も設定していない*11。で、実験してみると、確かに
という動作になっている。よしよし。
・ さらに、ちょっとした実験。もしも同じ address が LDAP DB と virtusertable の両方にあった場合、どちらが優先されるか。試し てみると、LDAP 側の設定が優先になった。.mc では FEATURE(virtusertable, ...) の方が先に記述してあるので、どう やら記述の順番に関係なく LDAP routing の方が優先されるらしい。virtusertable から徐々に LDAP routing へ移行しようと思っている立場としては、実に都合がいい。
・ これで sendmail 関連の作業は全て終わった‥‥と思いきや、意外な落とし穴 が。実は私の site ではとある web site の page の更新を watch する script が定期的に動いており、これが page の書き換えを検出すると mail で知らせてくるようになっている。で、この mail の送信には /usr/bin/Mail を使用しているのだが、この command を動かすと
Jun 2 07:21:15 ほげほげ sendmail[5193]: NOQUEUE: SYSERR(fml): /etc/mail/sendmail.cf: line 182: readcf: map ldapmh: class ldap not available Jun 2 07:21:15 ほげほげ sendmail[5193]: NOQUEUE: SYSERR(fml): /etc/mail/sendmail.cf: line 184: readcf: map ldapmra: class ldap not available Jun 2 07:21:15 ほげほげ sendmail[5193]: NOQUEUE: SYSERR(fml): Warning: .cf version level (10) exceeds sendmail version 8.11.6 functionality (9)
という message が maillog に出力されて、mail が配送されない。Message の内容からして、どうも旧い sendmail が起動されているような感じなので、 /usr/sbin/sendmail を /usr/local/sbin/sendmail への symbolic link にしてみたところ、この障害は出なくなった。よかったよかっ た(^^;。
・ というわけで、これにて LDAP routing の設定は終了 (^^)/。 それにしても、今回の設定をするために改めて Sendmail 8.12.3 附属の cf/README を読んでみたのだが、 8.11.6 の頃に比べて、ずいぶん と LDAP 関連の機能強化がされてるのね。もはや map 名に「LDAP」 と書けるようになってるとは。まあ、今までの virtusertable のような hash DB には、「maintenance の容易さ」という他には代えがたい 利点があるので、多分 aliases を LDAP DB で置き換えようとは思わないだろ うし、hash 型の virtusertable も（用途によって）併用していく ことになるだろう。でも、ML 用の aliases なんかは LDAP DB 化してしまってもいいだろうな。そう頻繁にはいじらないし、何といっても、/etc/mail/aliases が膨らんで、見辛い (-.-;。
*8: /var/db/pkg/sendmail-ldap-8.12.3_1/+DISPLAY に指示されている sendmail_flags="-L sm-msp-queue -Ac -q1m" は別の用途のものなので、追加してはならない。特に「-Ac（＝ 全ての配送に submit.cf を使用する）」は。
*9: 今回は予め sendmail が想定している通りの schema を使って DB を作ってお いたので話が簡単なのだが、そうでない場合は FEATURE(`ldap_routing') の引数の mailHost map と mailRoutingAddress map を適切に再定義する必要 がある。Sendmail が想定している inetLocalMailRecipient objectClass については、OpenLDAP に附属の misc.schema を参照のこと。
*10: 一部の address は既に virtusertable で管理しているし、どこに も転送せずに local へ mail を drop したい address もある。
*11: Default は passthru。
・ 結局、いろいろやってたら、寝る timing を逸したまま夜になってしまった (__;。いくらなんでも時間が時間なので、日記の日付は変えておく。
・ ふと、Jetway の 830CF を使った machine を WOL で起動できないかな、と思っ たのが、眠れなくなってしまった理由。
・ 結局、とあるところからもらってきた code をごりごりと書き換えた*1のに、動 かない。仕方がないので、Windows 用に公開されているほかの software で試 してみたけど、反応なし。
・ 幸い PCI slot は余ってるから、WOL に対応した NIC でもさして試してみる かな。fxp あたりもかなり安いし。
*1: 一発では compile が通らなかったので、code を整理している間に、結構全面 的に書き換えてしまった。Code 量自体は数十行程度のものなので。しかし、 このように元になる source があると、protocol を調べたりといった作業が 要らなくなるので、取っ掛かりには非常に助かります m(__)m。
・ 寿司。うまい。いつもながら、この味と volume でこの値段は反則だと思う (^^;。
・ 動き出した :-D。
・ Code 自体はかなり adhoc なので、あまり人様には見せたくない状態なのだが、 とりあえず最低限の要求動作はしている。これで note PC に built-in され ている NIC も PC Card NIC のような感覚で使うことができる。
・ まずは泥縄式に coding してある部分に手を入れなければ。さらに、check 自 体は複数の I/F に対して行なえるようになっているのに、up/down の状態を 1 組しか保持していないので、それを拡張する。Error message も現状では stderr に吐いてしまっているので、syslog に出さないと。
・ まあ、ここまで動けばあとは趣味の問題なので、気長に*1。
・ Program の名前も問題だ。暫定的に付けている名前は、とても人には言えない ようなダサさなので‥‥ (__;。
*1: ここまでの実装でも実使用には困らない程度のものなので、満足してしまって 作業が進まない可能性もある‥‥。
・ 昨日は直前で方向転換してしまったので、今日こそ、と上野でしゃぶしゃぶ。 参加者は総勢 4 名。店も空いており、まったりと。
・ ‥‥なんか、肉がいいんですけど。またも霜降度上昇中*2。
・ 今日は「もう食べられない」といいつつ猿丸さんさんが気絶食い。
・ 食後は例によって 1st Kitchen へ。今日は早々に解散。
*2: 念のために書いとくけど、「私の腹の」ではない。
・ 食後にちょっとだけ話が出たので、例の tool の code をいじる。
・ NetBSD でも動けばなぁ、と思ったので、CVS interface から -current の source を。‥‥機能ごとに徹底的に関数を分割してある。少なくとも、ifconfig.c に関しては FreeBSD のものよりずっと読みやすい。
・ NIC に割り当てられている IP address の取得方法は違っていた*3が、とりあえ ず link の up/down を検出する方法は一緒だったので、address の調査と、 実行時にそれを実際の command argument に突っ込む部分だけど条件 compile で切離せるようにし、test。‥‥FreeBSD では、どちらも期待通り動いている。
・ 子 process の呼び出し方法も、条件 compile で切り換えられるようにした。 最初は execv() で書いてあったのだが、/etc/pccard_conf をそのまま流用しようとすると、各 command に絶対 path が書かれていない ためか、それではうまく動かなかった*4。仕方がないので、execvp() に変更したのだが、「そもそも pccardd はどんな code で呼んでる の？」と思って source を見てみたら‥‥
‥‥ execvp() と system() を切り換えられるようにしてお いた。Default は前者。
・ ついでなので、2 つ以上の interface の状態を正しく管理できるように変更 したり、code を（ほんの少しだけ）整理したり、起動時に引数に渡した file に PID を書き出すようにしたり、SIGHUP で configuration file を読み直す ようにしたり。何となくそれっぽい形になってきたような気がする（← あくまで「気がする」だけ）。
・ で、NetBSD の ifconfig が address を取得するのに使っている getifaddrs()。FreeBSD にはないのかな‥‥と何気なく man を引いてみたら、‥‥なんだよ、あるじゃん T_T。これを使えばずっと処理が楽だし*5、そもそも内部構造に依存 しない*6から、maintenance も楽じゃん。NetBSD でもそのまま動きそうだし。 今の code はMIB の処理を shape up するのに結構時間喰ったのに‥‥。
・ まあとにもかくにも、人柱になってくれそうな人が要求しているのは「link の up/down の検出」なので、現状の code のありかを mail で送っておいて みたりして。感想をもらえると嬉しいなぁ。ついでに、かっこいい command 名も (^^;。
・ あとは、daemon として動作しているときに message 類を syslog に出すよう にするとか、interface の address 取得方法を書き換えるくらいかな。とり あえずの TODO は。後者をいじれば、NetBSD でもそのまま動くでしょう、多分。
*3: NetBSD の ifconfig は、interface が持つ IP address を getifaddrs() という関数で取得している。ちなみに、FreeBSD では MIB から構造体を読み出している。
*4: 今試してみたら、execv() でもちゃんと動いた。当たり前だよな。 きっとどこかに虫がいたんだろう (-.-;。
*5: MIB から得られる構造体は領域を圧縮してあるので、一旦展開（しかも、実際 に必要なものだけではなく、端から順番に）してやらないと、事実上情報を取 り出せない。一方、getifaddrs() のほうは、sockaddr 構造体を member に持つ ifaddrs 構造体の線形 list で帰ってくる。
*6: 逆に言えば、kernel の MIB を隠蔽するために作られたんだろうな、この関数 は。BSD/OS で導入されたものらしいし。
・ getifaddrs() を使って全面的に書き換えた。だいぶん code が小さ くなって、見通しも良くなった。NetBSD にも共通に存在する関数を使ってい るので、どちらでも動くんじゃないだろうか。
・ ふと不安になって、NetBSD の sys/socket.h を見てみたら、struct sockaddr_storage もちゃんとある*1。良かった。
・ あとは、messages を syslog に吐けるようにすれば、一段落かな。
*1: すべての size の sockaddr_〜 を格納できる（size を持つ）こと が保証されている構造体。ほかの sockaddr_〜 に cast して使うことができる構造体への pointer は struct sockaddr * と定義されていることが多いが、struct sockaddr 自体は struct sockaddr_in6 よりも小さいので、実際に data を格納する memory を確保する場合に struct sockaddr を使うと、えらい目にあう。
・ ‥‥と、ここまで書いたところで、前川さんから重要な mail をいただいた。ありがとうございます m(__)m。
・ 「NetBSD の ifwatchd(8) なんかが参考になるのでは」ということ なので、早速 man page を見てみると‥‥もしかして、私は車輪の再発明をし たのでせうか。あとで source の方も読んでみないと‥‥ (__;。
・ この ifwatchd(8)、man page によると NetBSD 1.6 から登場したら しい。最近ですな。ううむ。
・ Source を読んでみた。Routing table から address の変化を読み取り、その 変化に対応して command line で指定した script を呼び出すものらしい。 主に PPP との併用を意図している感じ。FreeBSD の ppp(8) における /etc/ppp/ppp.linkup や /etc/ppp/ppp.linkup の呼び出し機構に相当するもの？ 物理的な I/F の link up/down を検出で きるのかどうかは、NetBSD の if_is_connected() の source を読 んでみないと判らない*2。
・ ふーむ、FreeBSD では MIB から sysctl(3) 経由で読み出す情報を、 NetBSD では socket(3) で読み出すのか。読み出される情報はど ちらも同じ形式っぽい（struct if_msghdr）。やっぱり、実装の仕 方もまちまちだなぁ。
・ こうしていろいろな source を読みつつ、それをいじったりしていると、本当に勉強になる。
*2: 少なくとも、この関数は FreeBSD にはなかった。
・ if_is_connected()。 下の方の関数本体の code は見ていたから、とりあえずこれは今回の目的とは関係ないらしい*3ことが判ってい たんだけど、関数全体が macro で囲まれていたので、「SPPP_IF_SUPPORT が 定義されていないときに system 標準の関数を override するのだろう」と早 とちりしていた (__;。指摘されて 見直してみると、source の先頭付近で
#ifdef SPPP_IF_SUPPORT static int if_is_connected(const char * ifname); #else #define if_is_connected(X) 1 #endif
としてあった。むぅ‥‥。
*3: NetBSD の PPP 層に依存しているのだろう、ということ。
・ 確かに、chattering canceler のような動作はあったほうがいいかも*4。TODO にいれておこう (^^;。
・ 「Down 時には（link が down した後に何かやっても）大抵 手遅れ」というのは、まあそうなんだけど、それを言うと PC Card な NIC も同じなんだよね (__;。むしろ、あっちは I/F device ごと消滅し てしまうので、なおたちが悪い。
・ でも、あれだな。そういう（down）処理を明示的に行なわせる手段はあるとい いね。Signal で通知するとか。別に「別途 script を作っておいて、それを 手動で実行させる」のでも構わない*5けど、とりあえず（実際に down した場合に）落ち穂拾いを期待できるし、1 つの resource に対する管理は一元化されているほうがいいと思うし。
・ で、結局、大抵の人は resume 時の event handler で network の再初期化を 記述しているらしい。私の場合、s30 の動作が極めて不安定なこともあって、
という特殊事情があるからかもしれないけど。
・ でも、「Windows で当たり前のようにできていることが BSD 系 OS でできない」ってのは、なんか釈然としないんだよね‥‥（Network がらみでは特に）。
・ 「Down したあとでは既に手遅れ」というのは、多分 NFS 廻りのことをさしているんだろうとは思ってました (^^;。もしかしたら、こないだ話してたときに話題に出てたっけかな？ そのあたりは、極力（cable を抜くまえに）明示的に処理するしかないよね‥‥。
・ Client のせいばかりでなく、「server や経路が落ちてる」なんて時もあるの で、unmount を強制的に行なえるとありがたいのは同感。NFS type に対する umount -f ってのがどの程度強制力があるのか、（幸いにして）試したことはないけど。
・ で、*6。Windows 自身が使っている network protocol って、adhoc*7 なものが多いような気がす るので、そのおかげで何とかなってるんじゃないかと思う。
*4: もちろん、connector 部分での chattering cancel 自体は PHY に対策回路が入って いると思うけど、ここで問題になっているのは、もう少し time span の長い （どちらかといえばより論理的な）現象。
*5: もちろん、必要な command を手動で動かしてもいい。
*6: ていうか、up 時の処理も、少なくとも XP に同梱されている IPv6 stack に ついては全くなってない。
*7: この場合、「必要になる度に session を確立する」という意味で言っている。 （誤解を恐れずに言えば）HTTP のように。実装が adhoc であるかどうかは、言及するだけの skill を持ってないので以下略。
・ 19 時少し過ぎ、早紀さんを駅で出迎える。
・ 徒歩で家へ。マンションの下まで来たところで、すぐ脇に止まっている車の中 と、何軒か先の民家から、すごい歓声が（しかも同時に）聞こえてくる。← わかりやすい (^^;。
・ しばらく家の中でもぞもぞ。ある意味、体の柔軟性を試しているようでもあり。 その後、駅前のファミレスで食事をして、駅で解散。
・ Chattering cancel と、syslog 出力 を追加。これで、現状での TODO は、「特定の signal を 受信したときに、監視中の interface に対する down 処理を強制的に行なう」 という機能の追加のみ*1。問題は、「複数の interface を監視していて、かつ 上がっている interface も複数ある場合、down させる interface を選べる 必要があるか*2」「このような用途にはどのような signal を利用するのが一般 的か*3」ということ。
・ で、結局のところ、どうしてこういうものが欲しくなるかというと、「普段は電源を 入れたまま放置してあって、必要になると（suspend なしで）cable をおもむ ろに繋ぐから」という理由のほかに、「desk を離れる場合は（これまた suspend させずに）cable を抜いて無線 LAN card をさしたりする」という使い方をしてたりするから、だったりする。
・ そもそも、FreeBSD の場合、/etc/rc.conf が network_interfaces="auto" で*4、内蔵 NIC を DHCP で使う設定に していると、network の初期化時に dhclient(8) を実行し、それが timeout を起こすまで boot sequence が停止するのがじゃまくさい、という のも大きな理由。
*1: もっとも、実際に syslog に吐かせてみると、「どのような場合にどの level で出力するか」も設定可能であるほうがいいように感じたので、それも追加す るかも。（Facility は現時点でも設定可能。）
*2: 複数の対象に対して任意に操作をするなら、signal を使わず socket 経由で request を受信するようにしたほうがいいだろうな‥‥。
*3: SIGUSR1 あたりかしら。何かでこの signal を使ってたよーな。
*4: /etc/default/rc.conf で定義されている default 値がこれ。 この場合、ifconfig -l が返す（全ての）interfaces が対象となる。
・ 夕方、銀行と医者に行き、その後アキバで買い物。
・ 最後の店を出ると、どうもあやしい風が吹き始めている。とりあえず、馴染み の店に退避。
・ 案の定、雷鳴とともに、激しい雨が。しばらく雨宿りし、その後店員とともに 上野へ。立ち寄ったついでに、Intel EtherExpress PRO/100 S を仕入れる。 店頭表示価格は ￥3,980-.
・ 燔楽は今日も割と空いている。というか、街全体に人出が少ない。昨日はもっ と酷かったらしい。理由は此の上無いほどはっきりしてるんだけど。
・ なんだかいろいろと盛り上がりながら喰いまくる。なぜか法律談義。ふと気付 くと、隣の table でビミョーな話が繰り広げられている。あまりにビミョー 過ぎて、とてもここには書けない‥‥*5。
*5: 「業界話」とだけ書いておこう。どの業界かは、位置的にアキ（以下検閲削除）
・ TODO だった「特定の signal を 受信したときに、監視中の interface に対する down 処理を強制的に行なう」 という機能と、「どのような場合にどの level で syslog に出力するか」を 設定できる機能を、追加。
・ 前者に関しては、暫定的に「監視中の interface のうち、引数で指定された順に最初と次のものに対して、それぞれ SIGUSR1 と SIGUSR2 を受け取ると強制的に down 処理をさせる」というようにした。例えば、引数に「fxp0 dc0 dc1」と指定されていた場合、SIGUSR1 で fxp0 を、SIGUSR2 で dc0 を down させることができる。3 つ目以降の interface については、現在のところこのような処理をする方法はない。 Signal によって強制的に down させられた interface は、実際に一度 down を検出するまで、その状態を保持する*1。
・ これで一通り実装がすんだことになる。簡単な document を書いて公開するか な。でも、名前をどうしよう。「ifwatchd」のような、それっぽい 名前ってないかなぁ。私は naming sence がないので‥‥ (__;。
*1: Cable を抜くまえに signal によって down させたあと、気が変わって up させたくなったときは、一旦 cable を抜き差しすることになる。
・ 昨日の日記を更新する際、間違って一昨日の分を上書きしてしまっていたことに気 付く (__;。Backup は既に消してしまっていたので、draft folder から中間 file を見つけ出して何とか復旧。もしかすると内容が若干違ってし まっているかも‥‥。
・ 生まれて初めて沖縄に行くことになった。Air を手配するのも（自前では）初 めてなので*2、まつしたさんやうめさんに助言をいただいて、free plan の tour を利用することに。
・ おおよその方針。まず、目標は 22 日に行なわれるうめさんの講演会を聴くこ と。講演は正午過ぎに開始、終了時刻は決まっていない。いずれにしても懇親 会があるはずなので、当日夜は宿泊が必須。また、空路を利用するので、時刻 通りに着くことを期待してはいけない。正午ごろ那覇空港に着いていれば問題 はないらしいのだが、保険のために前泊することにする。つまり、target は 21 日出発・23 日帰着の 2 泊 3 日。
・ いつもお世話になっている JTB 浅草橋支店へ。「できるだけ安く沖縄に行き たいんですけど」というと、エース「出張応援価」を勧められた。Business hotel が中心の plan との由。沖縄の場合、対象になる hotel が 4 つ掲載さ れている。おおよその位置が書かれた地図と、主な設備の icon が掲載されて いるが、詳細が分からないので、まずそれぞれの宿の評価を検索してもらう*3。
・ 検索してもらっている間に、pamphlet を眺める。見ていたのは「2002 年 4 月〜 9 月発」が対象のものだが、「沖縄共通出発日カレンダー」として、こ んな↓表が（6/22 前後のみ抜粋）。
|
で、各 hotel の項には、こんな表↓が（実際に利用することになった「沖縄 ワシントンホテル」の場合）。
|
||||||||||||||||||||||||||||||||||||||||||||
この表を見比べると、あることに気付く。金曜である 21 日発の料金は「D」、 その前日の 20 日発だと「B」。つまり 2 rank も違う。で、基本プラン（1 泊）に追加される一延泊ごとの「エース宿泊プラン」の料金は、出発日や宿泊日に関わらず一定。ということは。
（五）「あのー。これって、21 日に行くより、もう一泊増やしてでも 20 日に行ったほうが、安くなる*4ってことですよね？」
（窓）「え？ ‥‥あー、そーなりますねぇー。ほんとだ‥‥」
‥‥20 日発に、大決定。（爆）
・ ちなみに、（少なくとも沖縄に限って言えば）どの hotel を利用した場合で も（単価こそ違えど）この関係が成立している。Hotel によっては、実に 2 千円近く安くなる場合すらある*5。ちなみに、出発をさらに 19 日まで早める と、その 19 日の分は「差額の 4,300 円で 1 泊できる」ということになる。 さすがに今回はやめておいたけど (^^;。
・ で、宿の評判を聞いたところ、「A が一番評判はいいですね。B はもうひとつ という感じです。C と D は、完全に business hotel ですね」。料金は D が 一番高く、B と C が同額で一番安い。A は B・C より基本が 2,000 円、一延 泊あたりで 500 円高い。まつしたさんから「宿は市街中心部に近いほうがい い」と聞いていたのだが、そういう面で見ると、C が一番便利ではある。しか し、A もそんなに不便ではない。というわけで、A の「沖縄ワシントンホテル」 にした。空室を照会してもらうと、空いているとのこと。決まり。
・ あとは、往復の便だ。思いがけずゆっくり観光できる日が 1 日できたので、 行きと帰りはあまり無理のない時間で組むことにする。片道あたり 1,000 円 割引になる「得々フライト」*6を優先して調べてもらうと、行きは 1030 頃発と 1230 頃発、帰りは 0820 頃発と 1230 頃発、1430 頃発が空いているという。 利用する hotel は tour の特例として C.I/C.O ともに 1200 時（通常はそれ ぞれ 1400/1000 時）になることもあって、行きは 1030 頃発、帰りは 1240 頃発の便にした。これなら、行きは C.I. 開始直後に那覇に着くので、hotel に直行して観光するなり休むなりできるし、帰りは C.O. 限界ぎりぎりまで hotel にいた上で空港に直行できる。帰りが早いのは何となく勿体ないような 気もしなくはないのだが、その分は 1 泊増やしてさらに割り引いてもらった 一日で元を取るってことで (^^;。
・ さすがに、今回の手配は早く済んだ。全部引っくるめて 30 分くらい。窓口自 体が空いてたし、そもそもヘンな切符を頼んで端末と格闘させなかったし（爆）。
*2: 航空機そのものが、物心つかないころ親に連れられて乗った後、今から約 10 年前に当時勤めていた会社の社員旅行（初年が Saipan、次の年が Hawaii）で 利用しただけ。
*3: AGT には、自社で宿泊を手配した客に対してアンケート用紙を渡し、その評価 を feedback して DB 化、店頭でそれを検索できるようになっているところが ある。JTB もそう。
*4: 21 日発の基本 plan が 43,800 円、20 日発だと 34,800 円。差額は 9,000 円。そこに一延泊分の 8,300 円を足しても、まだ 700 円安くなる。
*5: 戻って来てからしげしげと眺めてみると、1 日ずれるだけで 2 rank も料金が変わるのは、掲載されている 4〜9 月の期間内では、実に 6/20〜21 しかなかった。なんていいときにあたったんだろう (^^;。
*6: 今回利用した tour の場合、料金別に「基本フライト」「指定フライト」「得々 フライト」の 3 種類がある。「基本フライト」は基本料金がそのまま適用さ れる便で、沖縄便の場合、那覇行が初便から 1100 頃発まで（ただし 0830〜0930 を除く）、羽田行が 1530 頃発と、1900 頃発から終便まで。「指 定フライト」は片道利用あたり 2,000 円割増になる便で、那覇行が 0830頃〜0930 頃発、羽田行が 1430 頃発〜 1800 頃発まで。「得々フライト」 は逆に片道利用あたり 1,000 円割引になる便で、那覇行が 1030 頃発から終 便まで、羽田行が初便から 1430 頃発まで。ただ、航空会社毎に設定基準に違 いが若干あるらしく、例えば那覇行の場合、「得々」対象の ANA85 便は「基本」 JAL903 便よりも早く出るし、羽田行の場合も「基本」JAS554 便は他社の「指 定」時間帯の真っ只中に出る。特に同じ 1430 に那覇を出る 2 つの便は、JAL904 便が「得々」対象であるのに対し、ANA86 便は「指定」対象で、どちらを選ぶ かによって 3,000 も代金が変わってしまう。
・ 医者に寄り、その足でアキバへ。s30 の memory の調子が悪いということで、 昨日 memory check 用の FD をもらったんだが、これがうまく動かなかったた め、またぞろ馴染みの店へ。
・ Master の FD で試したのだが、若干状況は改善するものの、やはり途中で止 まってしまう。状況から見て、そもそも「memory がどうのこうの」以前の問 題のような気がする。というわけで、別の test program を動かしてみる。 ‥‥動いた (-.-;。
・ Machine 全般にわたる stress test を実行する。散々時間をかけた挙げ句、 ある特定の負荷 test を実行すると、増設した 128MB の領域の下位 8-bit で error が検出された。‥‥うがー！
・ 試しに、店側で確保してある「check 用の module」を載せて test してみる。 ‥‥問題ない。てことで、memory の異常と断定‥‥。
・ 不良の DIMM は、後日箱とともに持ち込んで返品することに。で、代わるもの がなかったので、今日は（というか当分）増設 RAM はお預け。標準搭載の 128MB でしのぐことになった。
・ それより大きな問題がある。度重なる突然の reboot の繰り返しで、ついに一 部の files が破損したらしく、X が動かなくなってしまった。‥‥いっそ、OS ごともう一度入れ直そうかしら‥‥。File system 自体も怪しげだし。
・ 本当は別の店舗の店員に誘われていたんだが、なんだかんだやっているうちに 22 時に。一応電話をかけてみたが波が届かなくて捕まらなかったので、御徒 町の120 円均一のわりにそこそこいいネタを喰わせる回転寿司「大江戸」へ。16 皿喰って帰る。 鯖がうまい*7。
*7: 酢でしめてあるんだが、比較的生に近く、脂も乗っていて、よくありがちな 「パサパサ」感が全くない。
・ 夕方、塩兄ちゃんから「燔楽いきます。来てください。（義務）」という mail が来たので、挑戦を受ける*1。
・ アキバで待ち合わせて、店へ向かう。中央通りにどとーの行列ができているの を見て、改めて今日が金曜であることを認識したり（やな認識の仕方だ‥‥ (__;）。
・ 店の前に着いたところで、ちょうど来た新井さんと合流。まずは 3 人で start。
・ ほどなくして、はかま大すきーセソセイ到着。あと二人がなかなか来ないので、電話をかけ てみたり。
・ そろそろやばいぞ‥‥という時間になって、ようやくかけーんとなあくさんが 到着。同時に鍋が増備される。6 人（2 発）体制でラストラン。
・ うまかった :-D。
・ 帰り道。大盛り上がり。新規 project 緊急発車。
*1: いや、実はてぐすね引いて待っていたんだが (^^;。
・ 「『黄色い電車』を『総武線』と呼ぶ」ことになれている人が地方から出てき た人（もしくは新宿駅をあまり利用しない人）に乗り換えを説明すると、新宿 で「『総武線』ってどこから乗ればいいんですかぁぁぁ T_T」という悲劇を産み出すという罠*2。
・ で、呼び方なんだけど、千葉以東や三鷹以西（および東京〜御茶ノ水間）をわざわざ「〜快速線」と呼ぶ例はあまり 聞いたことがない*3。普通は並走している緩行線と区別するために「快速線」 という言葉をつけるから。これだって、正確に言えば「急行線」なんだけど。
・ それでもって、中央緩行線と総武緩行線を直通する列車について、現在、旅客案内上は 「中央・総武各駅停車」という表現に統一されつつある模様。
・ しかし、いまだに納得いかないのは、この区間を走る列車の表示内容。ここに 投入されている 209 系や E231 系は側面の LED 表示器へ線区名と行先を交互 に表示するんだが、日中の直通時間帯はいいとして、早朝や深夜の線内運転時 （御茶ノ水から東側しか運転しない）にも「中央・総武各駅」と表示してるん だよね。むしろ「総武線」または「各駅停車」と表示したほうが、直通運転で はないことが明示的に判って、案内上親切ではないかと思うんだが‥‥。
・ 総武本線の起点については、東京乗り入れと同時に東京駅に移されてます。で、同時に御茶 ノ水〜錦糸町間は支線ということになったんだけど、この支線の起点は 御茶ノ水側にあります（2・3 番線の間の地上に 0 キロポストが立っている）。 普通は本線との分岐駅が起点になるんだけど、これはかつての本線の起点が御茶ノ水にあったという歴史的経緯によるもの。
・ ちなみに、根岸線が「京浜東北線」とはわざわざ別に（「京浜東北・根岸線」 というように）呼ばれることがあるのは、当該区間に横浜線も乗り入れて いるという事情があるためではないかと。他に、「京浜東北線」と 「中央・総武各駅停車」の大きな違いとして、
なんてのがあるかな。
・ まあ、実際のところ、「中央・総武各駅停車」を中央線側で「総武線」、総武 線側で「中央線」と通称したり、同じように根岸線内で直通先によって「京浜 東北線（電車）」「横浜線（電車）」と呼びわけていたりするのは、（地元では） ごく普通に行なわれていると思うけど、いずれも原則として地元だけで通じる 表現（少なくとも、JR 側が旅客案内上正式に用いることはない）ではないかな。
*2: 新宿で乗り換えて学校や会社に通っていた頃、困り果てた（または泣きそうな）顔をした人に何度となくこう訊かれた。
*3: 緩行線が並走している区間と同時に取り扱う場合は別。境界駅でわざわざ区切 る必要もないので。
*4: 事故発生時などに、横浜線が東神奈川以南への直通を中止することはあるけど。 これは「埼京線」と「川越線」（境界駅は大宮）なんかでもそう。
・ 作った。
・ IANA に申請していた LDAP scheme 用の private enterprise number が発行された。これで schema 作り放題（← なんか違う）
・ とある ML で人柱を募集したばかりだというのに、早速不具合発見。 しばらく走らせていると、「有効な interface がなくなった」として daemon が終了してしまう。原因は、if_nametoindex(3) がなぜか失敗すること。何で？ T_T。
・ この関数を呼んでいるのは、今となっては過去の名残でしかないので、削除し て様子を見ることに。
・ よく見ると、if_nametoindex(3) が失敗して daemon が死んだあとっ て、それまで動いていた dhclient(8) も止まっている。どっちが先？ てゆーか、何が原因なんだ‥‥。
・ 医者に行ったあと、Cafe Latino でカレーを喰おうと思い、店の前に自転車を 停めていると、ちょうど出かけようとした店主から「今日休みです。すみませ ん」と声をかけられる。さすが「不定休」の店だ‥‥ T_T。
・ 14 時過ぎに宅急便が届くので、あまり遠出はできない。で、開拓がてら、近 場の焼肉屋*1に。肉質は割と悪くないし、lunch time は coffee が free で飲 める（しかも、そこそこうまい）のはいいんだが、箸袋にタレ以外の何かが滲 みて汚れた割りばしを出してきたり、ごはんの中に髪の毛が入っていたりで、 ぐんにょり。もう行かない。
*1: 台東区側。
・ 帰ってくると、ちょうど宅急便の車が。危ないところで無事に荷物を受け取る。
・ 不在票に「品名: カタログ」と書いてあったので、「どうせヤマトを使うなら、 『クロネコメール便』にしてくれれば、手間がかからなくていいのに」と思っ ていたら、中身は会員証だった。なるほど (^^;。
・ 今日と明日は鳥越祭。一部交通規制が行なわれるので、付近の蔵前橋通りや 江戸通り、新堀通り、国際通りの通行は避けませう。
・ 東京駅の構内案内図はここから見られます*2が、 総武線 のホームは「総武地下ホーム」として独立した存在になっていま す。旅客案内上も「総武地下ホーム n 番線」となります。京葉線も 同様に、「京葉地下ホーム」。おそらく、地上にあるほかのホームと連続した 位置にないため、呼び方を分けて混乱を避けようとしたのでしょう*3。
*2: ただし、うちの環境では、HTML 版は MIME の属性がおかしいらしくて見られませんでし た。筑波での合宿の前には見られたのに‥‥。
*3: どのくらい広く周知徹底されているかは疑問だけど、大抵の人は「（地下の） 総武線（乗り場 or ホーム）」「（地下の）横須賀線（乗り場 or ホーム）」「京葉線（乗り場 or ホーム）」と呼んでいるようなので、あまり 混乱はしていない様子。逆に、（着発番が列車によってころころ変わるせいか） 総武線ホームを単に「n 番線」と呼んでいる人は見たことがありま せん。ていうか、大抵の人は番線まで言わないような。よほどよく利用する人 でない限り、escalator の上の表示器を見ないと、次に何番線から発車するか 判らないから。
・ 肉部で番外編の寿司。途中アキバで s30 の増設 memory を交換しなければな らないので、時間に余裕を持たせて 1630 発。
・ ところが、某馴染みの店では、そこの主が現在入院中のため、意外に時間を喰っ てしまった。結局、アキバ場面で予定よリ 30 分の延発。武蔵小杉には 13 分の延着。
・ 遅れて店に到着。あとは喰いまくる。うまいー
・ 店を出たあと、川崎基地で映画観賞会を行なう集団と分離し、駅のロータリー に面したバーガーショップでお茶。ちょっとした騒動があったりなかったり。 s30 よわよわ。塩兄ちゃんに某つーるを compile してもらって、header file を 1 つ追加するだけでどうやら NetBSD でも使えそうなことを確認 (^^;。ついでに要望をもらう。有難し m(__)m。
・ 猿丸さんから「port にはいつなるんですか？」と訊かれるが、いまのと ころ「suspend/resume で困ってない」という声しか聞こえてきてないので‥‥いつでせう (^^;。
・ 帰り道の頭の中は「脳内妄想座談会『わかいつばさ（仮）〜 '00 年代の BSD シーンについて考える』」がぐるぐる。
・ 行き帰りその他の時間を使って、packages を全部最初から入れ直し。しかし、 GNOME が起動しない。いよいよ OS ごと入れ直しか‥‥ (__;。
・ とりあえず、これまで使っていた拡張 memory module を抜いてしまったので、 以前よりは安定している。さらに、packages を入れ直していて、裏で X server が動いている*4と明らかに不安定になることが判った*5。でも、やっ ぱりどとーのように pkg_add(8) を書けていると、突然 panic する。
*4: 単に xdm の login 画面が出ているだけでも。
*5: 突然 key 入力が効かなくなったりする。以前から、X を使っていると、突然 画面が black out し、仮想端末の切り換えも機能しなくなる、という現象が 出ていた。おそらく、X server が console を掴んだままどこかで lock して しまっているのだろう。
・ うめさんから mail をいただいた m(__)m。if_getnametoindex(3) と getifaddrs(3) には虫がいるらしい。Patch をもらったので、試してみないと。
・ で、塩兄ちゃんから出してもらった要望に関して。例えば無線 LAN card がさしてあって、その I/F に対して監視をさせたい場合、現在の code では状態の取得時に error になったものは監視 list から外してしまうため、card を抜いた時点で監視の続行が不可能になる。これを避けるためには例え error になっても監視 list を変更しないようにすればいいが、その場合は指定された I/F 名が存在しないとき、それが「単に今存在しないだけ」なのか、「入力間違い」 なのかの区別がつかない。これは「list から削るかどうかを選択可能にする」 ということでとりあえず対応できるけど、ifconfig(8) のように「driver が存在するかどうか（または load できるかどうか）を調べる」ほうが、最終 的にはいいのかもしれない。
・ そもそも、「ifconfig(8) が driver を load する可能性があるとい うことは、つーる側でも load できなければいけないのでは」とは、思ってい たりするわけで。なぜかといえば、このつーるは ifconfig(8) を呼び出すきっかけとして使われる可能性があるわけで、その場合 「ifconfig(8) 側だけで KLD が load 可能」ということになると、 鶏と卵の関係になり得るから*6。まあ、これはとりあえず後回し。
・ ほかに、「tun(4) は監視対象たり得るか？」という話があったが、 もし PPP での利用を前提としているのであれば、普通は PPP の中で処理が完 結してしまうと思われるので、あまり意味はないかもしれない。ただ、daemon の起動や終了などに利用できる可能性はあるかも*7。
*6: まあ、「予め kldload(8) しておけばいいじゃん」と言ってしまえば、それまでなんだけど (^^;。
*7: これも /etc/ppp/ppp.linkup などで処理できるのだが、「記述を一ヶ所に集められたほうがいい」という意見が。
・ 昨日は早々に寝てしまったので、7 時には目が覚めてしまった。
・ うめさんから mail をいただいた m(__)m。Pccardd(8) による handling の場合、そもそも事前に driver が load されていないと、 attach できないらしい。Pccardd(8) の source をざっと見たが、実際 kldload(2) している code は見当たらなかった。なるほど。
・ ときに、ifconfig(8) の source を見比べると、FreeBSD では「ある名前の driver が実在するかどうか」を kldnext(2) と kldfirstmod(2)/modstat(2)/modnext(2) の組み合わせで scan できるのだが、NetBSD ではどうなんだろう。NetBSD の ifconfig(8) では「socket から情報が取得できなければ、それで終 わり」という処理になっているんだけど、昨日塩兄ちゃんに試してもらってい たときの記憶を思い返すと、「driver が存在していてかつ device が存在し ないときは、socket から ifmediareq を取得することはできるが、 ifm_status & IFM_AVALID == 0 になる」ということでいいのかし らん。
・ とりあえず README を書いた。そのついでに、ちょっと気になったところも手 直し。Driver の実在 check はまだ組み込んでいないが、公開してしまおう。どれだけ欲しい人がいるかは判らないけど。
・ Document に動作環境を書くのを忘れてた。README だけ差し替え。 塩兄ちゃんに試してもらった NetBSD と 猿丸さんに試してもらった FreeBSD-stable の version は何だったっけかな‥‥。
・ 思うところあって、一旦公開を中止。持って行った方は、当分再配布しないで ください。
・ 公開再開。README のみ若干変更。猿丸さんの環境は FreeBSD 4.6-RC とのこと m(__)m。
・ 一応書いとこう。今までに動作している（らしい）環境は、
です。
・ あかりちゃんと 2 人で上野燔楽。
・ なんか、街に人がいないんですけど‥‥店もがらがらだし。奥の部屋で 2 人きり（ハァハァ）
・ 一番な台所へ移動。うひー、客が 3 組しかいねーよ。しかも、こちらが帰る ころには、もはやほかには 1 人しか残ってないし。
・ 店を出ると、そこここであやしい歓声が。早速暴れた馬鹿がいるらしく、警官 が 3 人ほど急ぎ足で松坂屋方面へ。我々は上野駅へ。それにしても、人通り が少なすぎ。いつもなら 2 時か 3 時頃のノリですぞ。
・ 駅で別れて帰宅。途中、とってもわかりやすい服装をした何組かの集団とすれ 違う。
・ 「帰らぬ遺品」*1。被害者宅から家宅捜索によって押収され、捜査が終 結したにも関わらずいっこうに戻って来ない、ストーカー殺人 被害者の遺品。そして、遺族が国家賠償請求を起こしたとき、その遺品がおも いもよらぬ形で遺族に突きつけられて‥‥。
・ 殺人事件発生直後の記者会見。何が楽しいのか、警察側の担当者は何かという と笑っているか、さもなければ、むくれているか。そして、のちの国家賠償請求裁判 で、警察側が自らに非のないことを立証するために提出した証拠物件は、警察 に都合の悪い部分を削除し、解釈をねじ曲げた、被害者の遺品だったという。
・ これが真実であるならば、現場で真剣に職務を果たしている警察官たちには申し訳ないが、埼玉県警察本部は腐りきっている。謝罪会見や関係者の処分を経ても全く体質が変わっていないということは、彼の地で警察を頼るのは自殺行為であるということか。
・ それにしても、事件直後の被害者宅の取材状況を見て改めて思う。よく「日 本では、生き残った犯罪者の人権のみが close up され、殺された被害者の人 権はあまりにも考慮されない」と言われるが、その状況を作り出す急先鋒にい るのは、取りも直さずマスコミ（特にゴシップ誌や「ワイドショー」）ではな いのか。「個人情報保護法案*2」に反対声明を出すのも結構だが、その前に 「ワイドショー」の類を全廃してみてはいかがか。おそらく、現状の 「個人情報保護法案」を成立させようと主張される根拠のかなりの部分が正当 性を失うのではないか。
・ とりあえず、被害者（または遺族）の承諾を得ない（被害者側に対する）実名 報道はもういい加減にやめて欲しい*3。「被害者の人物像を明らかにすることに よって同情心を集める」ことで「加害者を糾弾する正義の味方」にでもなって いるつもりなのだろうが、言ってしまえば「お涙ちょうだいの視聴率稼ぎ」な わけで、興味本位の報道を助長する方向に作用しているとしか思えない。
*2: 正式名称は「個人情報の保護に関する法律案」と言うらしい。最近の法案にし ては極めて短い名称なのでは‥‥。
*3: 第一報（またはその類）については、関係者への伝達という側面もあるので一 概に否定できないが、少なくとも追跡取材において実名でいつまでも傷口に塩 を塗り込める必然性があるとはどうしても思えない。この「桶川ストーカー殺 人事件」以外にも、「神戸連続児童殺傷事件」や文京区の「お受験殺人事件」、 「池田小学校児童殺傷事件」などで、被害者の名前を出して「○○で△□君 （ちゃん）が殺害された事件で‥‥」などと報道されているのを見るにつけて そう思う。
・ 昨日は 27 時頃寝たのだが、またもや 7 時には目が覚めてしまった。あとで 眠くなりそう‥‥。
・ 松下電器の site から製品情報検索 を利用しようとしたら、Plug-in がなくて検索できなかった。ただ接続 cable の情報が欲しかっただけなのに‥‥。なぜわざわざ plug-in を使わにゃなら ん？ (-.-;
・ 最近、意味もなく見た目に凝る site が多くて困る。変なところに凝らなくて いいから、高価な標準 DV tape を「ぶちっ」と引きちぎらないような安定した DV deck を作ってくれ‥‥ ＞松下電器
・ BS Digital 放送のみ対応の tuner でも、version up によって対応できるもの（TU-BHD200）があるらしい。が、うちの tuner はもう一つ前の model（TU-BHD100）だった。むぅ。
・ うめさんが講演をする沖縄大で の講演会。参加の問い合わせを mail でしていたのだが、返事が来た。 「事前登録は特にしていないので、直接会場の受け付けにおいで下さい」との こと。うーん、web 上にそうはっきり書いておいて欲しかったりして (^^;。
・ 今日こそはと、Cafe Latino で「ポークロースカツカレー」（lunch time なので、プチサラダと飲み物がついてくる）を。せんえん。飲み物はラッシーで。うまし。
・ 何時もより早めに行ったら、妙に混んでいて、2 時間もかかってしまった。 うにゅう。
・ 入金日なので銀行へ行ったら、国税還付金が入っていた。しかも 1 週間前に。 このところ記帳していなかったので、全然気付かなかった。なぜ通知書が来な いんだ‥‥。
・ 接近中。直撃の恐れ大？
・ README 内の表現を一部改めました。その他は変わっていないので、tar ball の名前はそのまま。
・ やっぱり眠くなってきた。がしかし、腹も何となく減ってきた。どうしよう。
・ 眺めてみた。講演会の会場は沖縄大学なのだが、その沖縄大学を通過する唯一 の路線 bus が、ちょうど宿泊予定の hotel のごく近くを通っているらしい。 素晴らしい。
・ 着いた日とその翌日はどうするかな。やっぱり定期観光 bus かな。ちょうど air 便が着く少し後に那覇空港を経由する路線があるな。南部の戦跡を一巡り するもの。何はともあれ、戦跡へは行っておきたいのだが、距離が近いために 所要時間が短く、2 日目に行くには中途半端。初日にそちらへ行ければ、2 日目は中〜北部中心の丸 1 日かかる路線に乗れる。Air が定時運行*1であるこ とを祈りつつ予約するか？
*1: 航空便の場合、±15 分までの変動は「定時」と見做される。ちなみに、到着 予定時刻と bus の通過予定時刻との差は 25 分。
メールはこちらへ...[五反田 秋彦 as （五）/ Akihiko GOTANDA (a-gota_AT_agt.ne.jp)]
この日記は、GNSを使用して作成されています。作製者の GORRY さんに感謝 m(__)m。