そして、varnish 1.1.1 が出た。
_ Web 屋さんの世界ではコードとデザインの分離をするためにテンプレートライブラリを使われることが多いけど、これが便利なのは HTML の出力だけじゃないよね。
_ わしは各種設定ファイルを自動生成するスクリプトで使うことが多い。もっとも、わしがスクリプトを書くといったらとーぜん sh であって perl やなんかじゃないし、わざわざそれ用のツールをインストールしなきゃいかんのはアホくさいので、どこでも標準でインストールされてる m4 なわけだが。
_ でも、古くからある基本的なツールのわりには、m4 を使える人って少ないんだよね。sendmail をいじってる人でも .mc をいじるのに必要最低限のことを知ってる程度、sendmail をさわらなければほんの少しでも知ってる方がめずらしい。
_ ここのところテンプレートから設定ファイルを生成するスクリプトというのを書く機会が多いので m4 をよく使ってるんだけど、困るのは使える人がまわりにほかにいないこと。いや、わしだってそんなに詳しいわけじゃないけどさ、定型処理をやらせるぐらいならなんとかなる。でもその程度のことしかしていなくても、このスクリプトはわし以外の人にはメンテ不能なわけで。ほかの人でもメンテできるようにということを考えると、m4 の使用は控えた方がいいのかなー、という気がするんだよね。保守性を上げるために m4 を使ってるのに、使うと保守できなくなるという矛盾。どうしたもんだか。
_ というわけで、不当に評価が低い m4 を見直してもらうべく、m4 の便利さを実感できるサンプルを。
_ こんなのを httpd.conf に書いておく（.htaccess 不可）。
んで、.htaccess で m4 に食わせる設定を追加。LoadModule ext_filter_module /path/to/mod_ext_filter.so ExtFilterDefine m4 mode=output cmd=/usr/bin/m4呼ばれる hoge.html はこんな感じの m4 スクリプト。<Files hoge.html> SetOutputFilter m4 </Files>さらに、こんな header.m4 を用意しておく。divert(-1) define(`_TITLE_', `ほげほげ') divert`'dnl include(`/path/to/header.m4')dnl <body> <h1>_TITLE_</h1> ...<html> <head> <title>_TITLE_</title> ... </head>_ これで hoge.html にブラウザからアクセスすると、マクロが展開されて以下のような出力が得られる。SSI よりもずっと高機能で、CGI やなんかでテンプレートライブラリを使うよりもずっとお手軽だよね。
……はず。いや、ごめん、思いつきで書いただけで試してないから、ほんとにこれで動くかどうかわからん。間違ってないとは思うけど。<html> <head> <title>ほげほげ</title> ... </head> <body> <h1>ほげほげ</h1> ...
_ 昼飯を食いに外に出たら、暑いというよりむしろ痛かったんですが。
_ 夜になってからはだいぶ涼しくなってありがたい。
BINDをRDBMSに対応させるパッチも存在します。9.4 からはパッチじゃなくて本体に取り込まれてますね。_ どこだったか忘れたけど、つい最近 MySQL 上にゾーンを置く MyDNSってものの紹介記事も見たし。まあ、そうだよなぁ。テキストファイルより RDBMS にあった方が管理は楽だろうなぁ。WebUI を用意してやれば、わしらがやらなくてもオペレーターのおねぇさんにぽちっとなしてもらうこともできるし。前にいた会社では「今年こそやろう」と毎年いいながら時間が取れずに実現できなかった課題だったし。
_ ただ、DNS と RDBMS が一体化している必要があるのか、と思う。DNS はれっきとしたディレクトリサービスの一種なんだから、その手の情報の扱いに手慣れている RDBMS や LDAP に任せるのはむしろ正しい選択なんだろうけど、多くてもせいぜい数十ゾーン数千レコードだろうし、たったそれっぽっちのデータを扱うのに RDBMS を持ち出すのはおおげさな気がする。
_ それを越えて RDBMS で情報を管理したくなるほどたくさんのゾーンやレコードをかかえてるところだと、ピークでは数百〜数千 qps ぐらいの問い合わせを受けてるんじゃないかと思うんだけど、そのたびごとに DB に select 文を投げるってのもどうよ。最近はマシンの性能も上がってるからこの程度は屁でもないだろうけど、DNS って狂ったように異常な連続クエリーを投げてくるクライアントがたまーにいるから、そういうときのためにある程度大き目の余裕を確保しておきたい。が、 BIND DLZ のパフォーマンステストの結果を見るととてもじゃないけどこれは……。PowerDNS や MyDNS はどうなんだろうね。
_ けっきょくのところ、DB に insert なり update なりしたら、従来のテキスト形式のゾーンファイルを生成しなおして rndc reload するようなトリガを仕込めれば、一体化している必要ってのはそれほどないんだよね。もちろん構成が複雑化するとかめんどくさい点もあるけど。
_ あるいは、NS に登録するのは RDBMS ではない従来の DNS で実はスレーブサーバであり、マスターの RDBMS な DNS は外から見えないところいて通常の問い合わせは受けず、更新があったときに外にいるスレーブと NOTIFY/AXFR のやりとりをするだけ、という構成かなぁ。これならばしょぼいマシンでも負荷はほとんど気にしなくていいし。
_ この前ため息をついた連載記事の第2回。 ディレクトリ非表示の意味をもう一度見つめ直す。なんだかなー。いちばん大事な点をほったらかして、二の次、三の次のことをことさら重要そうに取り上げるところは前回と同じ。この記事を書いてる人、もしかしてわざとやってないか？
_ index.html を置かなかったためにそのディレクトリ内にあるファイルの一覧が丸見えになって個人情報やら何やらが流出した、という事件はたしかによく起きている。が、それは Options +Indexes が悪いのか？ そうじゃないだろ。外部からアクセスされてはいけないものが外部からアクセスできるところに置いてあった。いちばんマズいのはそのことであって、ファイルの一覧が見えるかどうかなんてそれに比べたら些細なことだよ。
_ 3年ぐらい前かな、広く配布されているショッピングカート用 CGI で、購入者の情報が外から見えるところに置く設定がデフォルトだったために、その CGI を使っているあちこちのサイトで情報が流出したことがあった。ほぼ同じころ、悲惨なことに出会い系サイトでも、登録者名簿が外から見えるところにあった腐れシステムを使っている多数のサイトから同時多発的に名簿が流出したことがあった。こいつら、index.html がなかったから漏れたわけじゃないよ。そこにファイルが置いてあるから漏れたんだよ。そこにファイルがあるとわかっているのであれば、Options -Indexes なんて何の意味もないんだよ。
_ 他人から見られては困るものは他人から見えないところにおく、ないしは認証をかける。これがもっとも基本的でいちばん最初にくるべきことでしょ。ディレクトリインデックスを制限する、というのはその基本が守られなかった場合でも被害の広がりを最小限に留めるためのものであって、こんなのはセキュリティでもなんでもない。万が一のうっかりミスでも被害をひろげない、という意味では意義がゼロだとは言わないけど、いちばん根本的なことをないがしろにしてまで取り上げることじゃないよ。
_ ちょうど ウノウでも似た内容のネタが上がってるけど、共通してるのは、根本はそのまま残っているのに表面だけ隠してセキュリティを確保した「つもり」になっていること。隠さなきゃならないものなら上っ面だけじゃなくて中身を隠せ。それをちゃんと隠せたのならば、残ったものは隠さなくたってなんの問題もないはずだ。
_ 今さらだが、ついに BIND8 がしゅーりょーするというアナウンスが。
こんなメールが流れたけど、Subject の2008年は間違いで、もちろん2007年が正解なので念の為。From: ISC Customer Support <sue_graves@isc.org> To: bind-announce@isc.org Date: Mon, 27 Aug 2007 13:55:05 -0700 Subject: BIND 8 is EOL as of 27 August 2008_ で、もし今まで BIND8 を使っていて乗り換え先を探している人がいても、djbdns だけは選んじゃいけません。djbdns を使ったことはほんどないのでここの実装がおかしいと具体的に指摘できるわけじゃないけど、djbdns がよろしくないのはそういうところとは別の次元なので。
_ よーするに qmail と同じで、メンテされてないんだよ。今後もし穴が見つかったとしても、djb 自身の手による修正は期待しづらい。有志によるパッチを期待するしかないが、オリジナルから改変したものを配布できないライセンスなのがさらにやっかい。BIND9 を出した後も何年も 8 をメンテし続けて、EoL のときもちゃんとアナウンスする ISC はエラいよね。
_ っていうか、メンテされてないことによる弊害って、「今後もしも」ではなく現実に有害な問題をすでに起こしてる。5年ぐらい前に b.root-servers.net と j.root-servers.net の IP アドレスが変更されたのに、djbdns の配布物に含まれているルートサーバの一覧はいまだに変更前のまま。もちろん自分で修正してやればいいんだけど、それをしないで配布されたそのままの状態の dnscache はすでに廃止されたはずの IP アドレスに今もクエリーを投げ続けている。これが害悪じゃなくて何だ。
_ あとね、tinydns。慣れの問題かもしれないけどさ、あのゾーンファイルは読めません。プログラムが読み書きするには便利な形式かもしれないけど、人間にとって読み書きがめんどうなものは、バグではなくヒューマンエラーによって意図しないレコードができてしまう危険性というのも頭の隅においておいた方がいいと思う。
_ そういうわけで、すでに djbdns を十分使いこなしているところに捨てろとまでは言わないけど、新規に DNS サーバを作ることを考えているのであれば djbdns（と、もちろん BIND8）は選択肢からはずしておいた方がいい。今使っているサイトも、root/servers/@ が正しい内容かどうかいちおうチェックしておけ。