プログラミングができないSE

ITproのこんなニュース。

■【IT Service Forum 2007】プログラミング軽視が使えないシステムを生む
http://itpro.nikkeibp.co.jp/article/NEWS/20071127/288167/

開発できないSEどころか、問題解決ができない、つまり、直面する問題の何が原因でどう解決する/できるかがわからない、あるいは時間が掛かりすぎる人が多いのは事実だと思う。

寺嶋氏の提唱が必ずしもよいかどうかは不明だが、プログラムが書けないSEなんてのは、料理の作れない料理長と変わらないと思う。必ずしも全員が料理長の能力を持っている必要はないと思うが(そんなチーム構成は冗長度も構成維持費も高すぎる)、普通のコックはうまい料理と料理に対する熱意、創作意欲、発想力があってしかるべきだし、料理や味のトラブルについても洞察力を発揮できてしかるべきだと思っている。

bindに埋め込まれたroot servers

L-root serverのIPv4アドレス変更の話題の中で、[DNSOPS dnsops 320]の話が出た。
それへのreplyとして[DNSOPS dnsops 321]があがったので、ようやく時間を見つけてbindのソースを簡単に追ってみた。

[DNSOPS dnsops 321]で言われてるlib/dns/rootns.cに、以下の文字列が指定されている(ML本文を読み返さずgrepして調べてしまった)。ちなみにこれ、bind-9.4.2のsource treeね。

static char root_ns[] =
:
:
“L.ROOT-SERVERS.NET. 3600000 IN A 199.7.83.42n”

このroot_nsを参照しているのは何かというと、lib/dns/rootns.c中のdns_rootns_create()内である。ここでisc_buffer_init()の呼び出し時の引数として渡している。

isc_buffer_init(&source, root_ns, len);

このようにして、root NSを生成しているのだが、じゃあdns_rootns_create()を呼び出して生成をしようとしている人は一体誰なのか。
bin/named/server.c中のconfigure_hints()関数が呼び出していた。

result = dns_rootns_create(view->mctx, view->rdclass, filename, &db);

名前からも想像してしまうが、hintsファイルつまりnamed.root(named.confで指定可能だからファイル名は違う場合もある)をroot NSとしてzone DBを構築しようとしているわけだ。dns_rootns_create()の第1引数のview->mctxは、指定view(namedではviewという概念がある)のメモリコンテクストだと想像する(想像ね)。namedが管理するviewごとのzone情報は、メモリに蓄積されているわけだから(nsupateが入ると、ときどき.jnlファイルを更新したりzoneファイルに反映したりする)、named.conf中で指定された

zone “.” {
type hint;
file “named.root”;
};

というような設定を含むviewにroot NSの設定ファイルの中身を反映させるというわけだ、と思う。
ところでconfigure_hints()ファイルはどこで呼ばれているかというと、bin/named/server.cファイル中で呼び出しを行っている。

result = configure_hints(view, hintsfile);

指定されたviewにヒントファイル(このファイル名は、そのままdns_rootns_create()の第3引数に引き継がれる)のデータを突っ込むのだが、じゃあroot_nsは一体いつのタイミングで使われるわけ?ってのが、同じくbin/named/server.cファイル中の、おそらく以下の部分。

if (dns_name_equal(origin, dns_rootname)) {
const char *hintsfile = cfg_obj_asstring(fileobj);

result = configure_hints(view, hintsfile);
if (result != ISC_R_SUCCESS) {
isc_log_write(ns_g_lctx, NS_LOGCATEGORY_GENERAL,
NS_LOGMODULE_SERVER,
ISC_LOG_ERROR,
“could not configure root hints ”
“from ‘%s’: %s”, hintsfile,
isc_result_totext(result));
goto cleanup;
}

dns_rootnameは上手に追えてないのですが、static dns_name_t rootをそのまま参照しているだけのポインタだと思われる(それ以外で、どこかで代入されている形跡はgrepできんかった)。
originはこれまた上手に追えていません。上記コードが置かれたconfigure_zone()内の初めの方で、以下のように代入したまま変更のない値を使っている模様。

origin = dns_fixedname_name(&fixorigin);

fixoriginっていうのは、configure_zone()の第2引数zconfigを元にメンバ変数を生成している。zconfigは、さらに呼び出し元であるconfigure_view()の中を見る限りでは、named.conf中の現時点でのviewステートメント中にあるzoneステートメントを指しているんじゃないかしらと仮定。その中でさらにhintを見付け、file指定子を探し、dns_name_equal()に至っている。
dns_name_equalで、両者構造体中のメンバ変数ndataを(attributesメンバ変数なども参照して厳密に)比較しているので、DNS的rootの基準であるdns_rootnameと比較することで「zone “.” { … };」を検出、そうであればconfigure_hints()を呼ぶことにしている、と想像する。

configure_hints()で呼び出されると、さきほど辿ってきた関数群をどんどん進み、最初に出てきたlib/dns/rootns.c中のdns_rootns_create()の中にある、この部分に突き進む。

if (filename != NULL) {
/*
* Load the hints from the specified filename.
*/
result = dns_master_loadfile(filename, &db->origin,
&db->origin, db->rdclass,
DNS_MASTER_HINT,
&callbacks, db->mctx);
} else if (rdclass == dns_rdataclass_in) {
/*
* Default to using the Internet root servers.
*/
result = dns_master_loadbuffer(&source, &db->origin,
&db->origin, db->rdclass,
DNS_MASTER_HINT,
&callbacks, db->mctx);

filenameはnamed.conf中で指定しているヒントファイルだが、これがNULLでなければ、このファイルからroot NSを読み込んでzone DBに突っ込んでいる。
root_nsが使われるのは、else ifの条件にひっかかった場合だ。最初の「isc_buffer_init(&source, root_ns, len);」のとおり、sourceがデフォルトのroot NSのデータを示すオブジェクトとして指定されているので(たぶんね)、dns_master_loadbuffer()でデフォルトのroot serversが突っ込まれることになる。

だから、named.conf中でnamed.root(ヒントファイル)の指定がない場合にはroot_ns[]つまり内蔵されたroot serversデータが使用される。したがって、L-root serverのIPv4が変更される前のbindを使っていて、かつヒントファイルの指定がない場合のみ、L-root serversが古いまま参照され続けてしまうということになる。

あ〜、疲れた…。
てか、これであってるのかしら?(保証なし)

BIND-9.4.2リリース

昨日かおとついに、ISCフォーラム会員限定リリースされていたみたいですが、ようやくbind-9.4.2が一般公開されたみたいです。bind-9.4.2rc2から特に変更はない模様。bind-9.4.1からのバグ修正が含まれるのと、例によってLIBINTERFACEで指定される値の間違い(?)があるので、bind-9.4.2rc1の人はrebuildしなければならない問題がある模様。

■BIND 9.4.2
http://www.isc.org/index.pl?/sw/bind/view/?release=9.4.2

JPCERT/CC REPORT 2007-11-28

JPCERT/CCからの定期レポート。

Lhaplusがらみのバッファオーバーフローがメジャーどころですかね。

■11/18(日)〜11/24(土) のセキュリティ関連情報
http://www.jpcert.or.jp/wr/2007/wr074601.html

そういえばこれに掲載されていませんが、Firefoxで.jarファイル取扱いがらみのセキュリティホールがでていますね。
それ以外にも、window.locationでのreferer偽装問題なんてのもあるみたい。

■Firefox 2.0.0.10 リリースノート
http://www.mozilla-japan.org/products/firefox/2.0.0.10/releasenotes/

Captcha!プラグインの日本語化

っていうか、単に日本語に翻訳するだけなんですが。
それほど難しくなかったので翻訳してみようと思ったのですが、埋め込み型なので日本語文をそのままcaptcha.phpに埋め込んで行く作業に。
で、UTF-8にnkfで変換して試してみるのですが、nkfがよくないのか(不明)、日本語文字列のある部分でPHPのエラーで止まってしまう。「)がないよ」的メッセージだったと思うが、これってやっぱ文字コードで問題起きてるよね。

文字コードのことを詳しく理解していないんだけれど、wordpressがUTF-8を使っている以上はUTF-8で埋め込まないといかんと思うのだが、どうしてもここでダメになってしまう。

困った。
っていうかgettextで書いておくれよぉ。

試作を一応晒しておくが、まず役に立たないよね。
http://mbuf.que.jp/blog/UltraH/files/captcha.php-ja