かけまわる子犬。

前回書いた続編と言うか・・。

一応、apache を Proxy として利用できるようになり、コメントで hagyさん から、mod_mem_disk と mod_mem_cache の両方を書いたときの動作確認してよー。って言われたので、そのテストをしようと思った矢先・・。

テスト環境では、キャッシュしようと思っていたデータがベーシック認証の中にあったのでありました。つまり、キャッシュしてはいけないデータなので apache Proxy はデータをキャッシュしてくれないんですね・・。

フリーソフトウェアのほとんどの Proxy サーバはベーシック認証やダイジェスト認証の中にあるコンテンツについて、セキュリティの観点によりキャッシュサーバでは絶対にキャッシュしない。と言うポリシーのもとで作成されているみたいです。apache の場合、ドキュメントにちゃんと書いてあります。

http://httpd.apache.org/docs/2.2/ja/mod/mod_cache.html#cacheignorecachecontrol

NetApp 社の NetCache もしかりですが、設定が用意されているみたいで on no-cache とか on uncond-cache がそれにあたります(当然、設定 GUI からもできるとは思いますが;-)。

さてと。どーすんべなぁ。とか思って、一応 apache のソースを眺めたらわりと簡単にソース修正できそうだったので変更してしまいました。以下はそのパッチです。

--- modules/cache/mod_cache.c.ORG       2009-05-02 10:40:03.000000000 +0900
+++ modules/cache/mod_cache.c   2009-05-02 10:39:25.000000000 +0900
@@ -95,9 +95,12 @@
     /* First things first - does the request allow us to return
      * cached information at all? If not, just decline the request.
      */
+
+    /* Authorization pass.
     if (auth) {
         return DECLINED;
     }
+    */

     /*
      * Try to serve this request from the cache.

ふぅ。これでキャッシュ用 Proxy サーバはなんとかでき上がりました。では続いて懸案であった、mod_mem_disk と mod_mem_cache の両方を書いたときの動作確認をしたいと思います。

が・・。どう言うわけか mod_mem_cache の設定を書いていると httpd が Segmentation fault(11) してしまいます(今回は prefork で make したので一個のプロセスが Segmentation fault を起こすのみで、全ての httpd は死んではいないため port:80 では LISTEN が可能状態です)。一番最初、キャッシュしていない状態でアクセスがあった場合はマスターサーバから、仮に「A」と言うコンテンツを取ってきてキャッシュして、そしてクライアントに返します。

次に別のクライアントがコンテンツ「A」を取りに来たとき、httpd がこの時に Segmentation fault(11) で落ちてしまう。と言う状態に陥ったのでありました。なので、コンテンツは DISK 上(もしくはメモリ上)に溜まるけど、利用されることは無い。と言う感じですね。

＃ちなみに mod_mem_cache で溜まったキャッシュの情報ってどうやって確認するのだろう・・。メモリ利用量のみで判断するのかなぁ？

mod_mem_cache を削除して mod_mem_disk の設定のみを書いたときは正しくキャッシュできて、 Segmentation fault(11) もせず、キャッシュされたデータも再利用できることを確認しました。なので運用的にはキャッシュデータは DISK のみに保存する。と言う方向で行きたいと思います。

ごめんねー。hagyさん。

それにしても、色々詳しく調べるまで、ベーシック認証配下のコンテンツはキャッシュしない。と言うのを知らなかったなぁ。まぁ、考えてみれば当たり前だよなー。認証の奥にある情報が実は Proxy キャッシュサーバの中に残っていた。なんてのは怖いことだもんなぁ。

前回は、mrtg が実質的に IPv6 に対応していないねぇ。って所で話が終わったのですが、そこから進展がちょっとあったので書いてみたいと思います。

net-snmp に対して IPv6 で接続したい人は前の記事を先に読んで 、その後でこの記事を読んでください。

さてと。物語りは前回からの続きなのですが、mrtg の config ファイルを記述した時、 Target に IPv6 を記述した場合 ifIndex でしかトラフィック情報が取得できない。と言う所で終わりました。

確かに、何度試してもダメだったので、debug オプションを有効にしてログを見つつソースコードなどを眺めていたら問題点を発見しました。最近の ports-current から mrtg をインストールするとmrtg-2.16.2,1 がインストールされるのですが、その時に /usr/local/lib/perl5/site_perl/5.8.9/Net_SNMP_util.pm も併せてインストールされます。こいつの中で Net::SNMP を呼んでいる時に -domain で udp/IPv4 しかセットしていないみたいなので udp/IPv6 をセットするようにしたら IPv6 でも一応動くようになりました。

修正分のパッチはこの辺りに置いておきます。

このパッチを適用することにより、FQDN で問い合わせした時は ifDescr でも値が取れる事を確認できました。以下におさらいしてみることにしましょう。

・IPv6 で SNMP が取得できるもの

Target[dir_re1]: 2:public@taro6.running-dog.net:
Target[dir_re1]: \re1:public@taro6.running-dog.net:
Target[dir_re1]: 2:public@[2001:200:161:14cc::1:1]:161:

taro6.running-dog.net は DNS に IPv6 のみのアドレスが登録されています。

この設定では IPv6 では ifIndex と ifDescr でトラフィック量を取得することができました。

・取得できないもの

MAC アドレス指定(FQDN・IPv6 共に)
ifDescr 指定での IPv6 アドレスを記述した場合

とまぁ、こんな感じで ifDescr で取得できるようになったのでヨシとしておきましょう。それにしても DNS は必須になってしまうのですが・・。

後、net-snmp って --enable-ipv6 で make しても snmpwalk は IPv6 に対応していないのねぇ。DNS に IPv6 のみ登録してある FQDN を指定しても「そんなアドレス知らん。」とか言われます。/etc/hosts に書いてもダメ。snmpd が IPv6 に対応しているだけにもったいないことです・・。

さてと。ここまでは net-snmp と mrtg のお話で、前回の続きの完結編。と言う感じになります。

続きまして rrdtool に行ってみましょうか。ports 的には ports/databases/rrdtool になりますが、これをインストールすると RRDs と言う perl のモジュールをインストールしてくれて RRDs::graph と言うモジュールを使うと MRTG グラフを表示してくれます。グラフを作成する際のオプションとして IPv6 アドレスが存在した場合にどうなるのか？

正解ですが、":" は区切り文字に使われているので DEF: の設定に IPv6 アドレスがあるとまともに動作してくれません。

ports 的な rrdtool-1.3.5 のソースを見てみると rrdtool-1.3.5/src/rrd_graph_helper.c に以下のような記述が所々にあり、"[]" で囲むとか "\:" などしても全然対処できないと言うことが解ります。

    if (line[*eaten] == '\0' || line[*eaten] == ':') {
        dprintf("- no (or: empty) legend found\n");
        return 0;
    }

と、言うことで RRDs を使う場合には IPv6 を意識しないようにしないとまずいです。では、どんな時に IPv6 を使う必然性が出てくるのかとなるのですが、僕の場合、rrdfile と PNG ファイルの保存場所に IP アドレスを利用してる感じですね。

/data/mrtg/192.168.1.1/re1.rrd
/data/mrtg/2001:200:161:14cc::1:1/re1.rrd

でもって RRDs::graph では以下のようなコーテイングをしていたらこらアカンですわなー。

：
my $rrdfile = "/data/mrtg/2001:200:161:14cc::1:1/re1.rrd";
my $pngfile = "/data/mrtg/2001:200:161:14cc::1:1/re1.png";
push (@options
：
   ,"DEF:avein0=${rrdfile}:ds0:AVERAGE",  "CDEF:avein=avein0,8,*"
   ,"DEF:maxin0=${rrdfile}:ds0:MAX",      "CDEF:maxin=maxin0,8,*"
：
);

my @rv = RRDs::graph(
     $pngfile
    ,@optins
：
);

なので、結局 $rrdfile =~ s/:/_/g; など言う弱いことをして問題回避したのでありました。

これで、net-snmp・mrtg・rrdtools の IPv6 対応が一応終わった感じかなぁ。10Gbps 問題も回避できたし、今の所は多分これで IPv6 な世界が来ても大丈夫なような気がします。が・・。mrtg には IPv6 対応をもう少し頑張ってもらい所ではあります。

http://oss.oetiker.ch/mrtg/doc/mrtg-ipv6.en.html

こんな所読んだって Target の所がハショッて書いてありすぎで全然ダメなんだもの・・。トホホ。

くーーっ。MacOSX Leopard の /usr/sbin/snmpd は 5.4.1 使っているのに IPv6 に対応してないじゃん。 udp6:161 のオプション、そんなのねーー。とか言いやがる・・orz。これはヒサンだ・・。

つまり、どういうことかと言うと、例えば MacOSX を leopard.running-dog.net と言う FQDN で 192.168.1.30 と 2001:200:161:14cc::1:10 の二つ RR レコードを記述していた場合、mrtg.cfg の Tagrt に FQDN を記述すれば mrtg は IPv6 で問い合わせに行くことになります。

けど、MacOSX の snmpd は IPv4 にしか答えないので mrtg はエラーとなります。そして、mrtg は「IPv6 から IPv4 にフェイルオーバーしないよ。」と言う仕様なので、MacOSX への mrtg.cfg の設定における Target は FQDN ではなく、IPv4 アドレスを記述しないと正しく情報が取得できないことになります。

いやぁ・・。奥が深い・・。まず最初に監視対象機器が DNS に A と AAAA があるか確認した後、当該機器の snmpd が IPv6 に対応しているか確認してからでないと mrtg.cfg の記述が完成しないんだー・・。

と。言うこで、このネタ。ここまでにしておきましょう・・。

なんか、「さくらのレンタルサーバ」には emacs が入ってないので自力で make してインストールしてしまおう。みたいな感じです。そもそも、ssh でログインして、ちろっと html を直したい場合、vi じゃ日本語表示してくれないしきついでしょう。

一応、SAKURA のサポートにはメール投げたけど、いつ pkg_add してくれるのか解らないし・・。と、言うことで emacs-current をインストール;-)。作業内容は以下のような感じで非常に簡単です。「さくらのレンタルサーバ」を利用している方、是非試してみてください;-P。

あ、emacs-current をソースからインストールすると大体 300MByte 位必要になります。自分のディレクトリでは du -sk して空き容量を確認してくださいね。

と、言うことでインストール開始;-)。

これで ssh でログインした後にファイルを編集するすることができるようになった。めでたしめでたし。