jdresolve が逆引きを失敗する

ファイヤーウォールのログや、Webページへのアクセスログを解析するために、jdresolve というユーティリティーを使用中です。

このユーティリティーは、ログファイル中のIPアドレスを一括 逆引きしてホスト名に直してくれるので、ログ解析ソフトを使う前の前処理に重宝しています。Apache ログだけなら apache をインストールすると一緒に入る logresolve コマンドを使えばいいのですが、行の先頭がIPアドレスで始まるログファイルにしか使えず、ファイヤーウォールログなど一行に複数のIPアドレスが存在するケースなど、Apache ログ以外に使うためには、ログファイルの前処理が必要になり、jdresolve コマンドには重宝しています。

例えば次のような、アクセスログがあって、これを jdresolve で処理すると、

116.58.172.107 - - [01/Nov/2012:00:00:04 +0900]
116.58.172.107 - - [01/Nov/2012:00:00:09 +0900] 
66.249.73.3 - - [01/Nov/2012:00:00:10 +0900] 
173.199.115.171 - - [01/Nov/2012:00:00:17 +0900] 
173.199.116.179 - - [01/Nov/2012:00:10:47 +0900]

IPアドレス部分をアクセスポイント名(ホスト名)に置き換えてくれます。

tokyo.lifewithunix.jp - - [01/Nov/2012:00:00:04 +0900]
tokyo.lifewithunix.jp - - [01/Nov/2012:00:00:09 +0900] 
crawl-66-249-73-3.googlebot.com - - [01/Nov/2012:00:00:10 +0900] 
173.199.115.171.choopa.net - - [01/Nov/2012:00:00:17 +0900] 
173.199.116.179.choopa.net - - [01/Nov/2012:00:10:47 +0900]

それが、本日名前解決処理したファイルに目を通してみたら、こんな事になっていました。

Net::DNS::DomainName1035=HASH(0x834670c) - - [01/Nov/2012:00:00:04 +0900]
Net::DNS::DomainName1035=HASH(0x834670c) - - [01/Nov/2012:00:00:09 +0900]
Net::DNS::DomainName1035=HASH(0x8351240) - - [01/Nov/2012:00:00:10 +0900]
Net::DNS::DomainName1035=HASH(0x834e54c) - - [01/Nov/2012:00:00:17 +0900]
Net::DNS::DomainName1035=HASH(0x835c4d4) - - [01/Nov/2012:00:10:47 +0900]

名前解決すべきフィールドに「Net::DNS::DomainName1035=HASH(0x834670c)」というPerlモジュール名とHASH(16進数)と表示されているので、名前解決に失敗しているんでしょうが、その理由は何だろう?

まず、自分のDNSが問題なのかと、nslookup を使ってみましたが問題なし。メールもWebサービスも正常に動いているから当然の結果でしょう。

では、私のサーバーが異常なの?と思って、私が管理している別のサーバーの jdresolve を試してみたら、なんと同じ症状が発生。

?????

こうなると、jdresolveかjdresolveが依存しているらしいNet::DNSソフトウェア側の問題なの?と考えるしかありません。

jdresolve の依存関係をチェックしてみたところ、Perlそのものとダイジェスト関数発生ライブラリは現象と関係なさそうですので、犯人は p5-Net-DNS-0.71 である可能性が高そうです。

> pkg_info -r -R jdresolve-0.6.1_1
Information for jdresolve-0.6.1_1:
Depends on:
Dependency: perl-5.12.4_4
Dependency: p5-Digest-HMAC-1.03
Dependency: p5-Net-DNS-0.71

幸いなことに、しばらく電源を落としていて ports ディレクトリがしばらくアップデートされていないFreeBSDサーバーがあることを思い出した。p5-Net-DNS のバージョンをチェックしてみると、0.68 とちょっと古い。このホストで jdresolve を試してみたところ結果は以下のとおり。

tokyo.lifewithunix.jp - - [01/Nov/2012:00:00:04 +0900]
tokyo.lifewithunix.jp - - [01/Nov/2012:00:00:09 +0900]
crawl-66-249-73-3.googlebot.com - - [01/Nov/2012:00:00:10 +0900]
173.199.115.171.choopa.net - - [01/Nov/2012:00:00:17 +0900]
173.199.116.179.choopa.net - - [01/Nov/2012:00:10:47 +0900]
 Total Lines: 5
 Total Time : 00:00:00 (0.00 lines/s)
 Total Hosts: 4
 Resolved Hosts: 4 (100.00%)
Unresolved Hosts: 0 (0.00%)
Average DNS time: 0.0000s per request
 Max DNS time: 0s (consider this value for your timeout)

逆引き成功です。

p5-Net-DNS をダウングレード出来れば、問題は解決しそうです。問題はどうやってダウングレードするか?ということで、今は、ports を使ってアプリケーションを管理しているため、問題のファイルを手作業で置き換えてしまい、pkg管理リストとオブジェクトが異なっているという状況を作りたくありません。今までやったことはありませんでしたが、p5-Net-DNS-0.68 がインストールされているサーバーで p5-Net-DNS のtarball を作って、p5-Net-DNS-0.71 のサーバーにコピーし、pkgツールを使って置き換えるのが良さそうだと考えました。

/usr/ports/Mk/bsd.ports.mk を読むと、make package というコマンドがあるので、/usr/ports/dns/p5-Net-DNS にてこのコマンドを発行すれば良さそうだ。そして実行したら、一瞬で完了。
しかし、パッケージはどこに出来たんだ?
初めて使うコマンドのため、デフォルトの生成場所はコマンド発行場所かと思ったら違うみたいです。

いろいろ探し回って、/usr/ports/packages の下に出来る事を発見しました。All の下に、p5-Net-DNS-0.68.tbz を発見。これをftpで不具合のあるサーバーにコピーし、「pkg_delete -f p5-Net-DNS-0.71」でNet::DNS を抜いたところまでは良かったのですが、pkg_add で p5-Net-DNS-0.68.tbz を入れようとしたら、p5-Net-DNS-0.68.tbz を生成したサーバーの perl バージョンは5.10 で、インストールされる側のperlは5.12であるため入らない!

仕方がないので、パッケージを作ったサーバーの perl 5.10 を 5.12 にアップデートすることにしました。(1時間くらい掛かってしまった。)

# portmaster -o lang/perl5.12 lang/perl5.10
# portmaster p5-

このあと、/usr/ports/dns/p5-Net-DNS にて、make deinstall, make reinsntall, make package を行い、再度 p5-Net-DNS-0.68.tbz を生成した後、ftpでコピー。本番サーバーにて、pkg_add p5-Net-DNS-0.68.tbz を発行してインストールしました。

jdresolve を実行してみたら、

tokyo.lifewithunix.jp - - [01/Nov/2012:00:00:04 +0900]
tokyo.lifewithunix.jp - - [01/Nov/2012:00:00:09 +0900]
crawl-66-249-73-3.googlebot.com - - [01/Nov/2012:00:00:10 +0900]
173.199.115.171.choopa.net - - [01/Nov/2012:00:00:17 +0900]
173.199.116.179.choopa.net - - [01/Nov/2012:00:10:47 +0900]

ということで、問題解決。

しばらくはパッケージ管理に、portupgrade -a なんて入力してしまわないように注意しなくちゃいけません。

コメントを残す