Dr.Web アンチウィルス

これまで、Dr.Webというアンチウィルスソフトをメールサーバーに入れていました。ユーザーIDが10番台というので相当に昔からのユーザーだったりします。

職場のサーバーはFreeBSD + Postfixで動いていますが、はっきり言ってFreeBSD向けの有料ソフトを売っているようなところは普通にはなかったりしますが、ウィルスはいろいろと問題が生じるとイヤなので有料ソフトがあるというだけでうれしくてずっと使ってきました。

最初にインストールしたバージョンはVer.4.44で、その後、ウィルスのデータベースエンジンがVer.5.xにupgradeしました。サーバーから落してくるウィルスデータにVer.4.44は対応できなくなったために新しいエンジンに入れ替えなくてはならない、ということだったために入れ替えました。

このときは、Dr.Web Japanという会社がサポートしてくれていたのでたいへんわかりやすいマニュアルがあってその通りにやればちゃんとできました。

その後、Ver.4.44のサポートはもう2013年の何月限りまで、とかいうアナウンスがあって、Ver. 6.0.xにアップデートしないとダメ、ということになったのですがその頃に、日本での代理店がDr.Web Pacificというところに変わりました。Dr.Webはロシア製のソフトですが、日本で商売になるということで、そのロシアの製造元がアジアに直接乗り込んできた、ということのようで、予想通り、Dr.Web Pacificに変わってからのサポートは極端に悪くなっていました。

いずれにしても、ライセンスの更新にあわせてVer.6.0.xにアップデートしようということでアップデートをしてみましたが、ものの見事に動かなくなりました。やっていることは、届いたメールをpostfixに渡す前に(本当はキューに入ってからだけど) Dr.webが横取りしてウィルスチェックをしてからpostfixに戻してメールをスプールにおく、という作業をやっているだけです。maillogを見ると、Dr.Webに渡す時に127.0.0.1:xxxxというポートを使っているのですが、そのポートでconnection refusedと言われています。設定ファイルのmaild.confで指定しているポート番号は一致しているので問題はなさそうなのですが、なんかわけがわかりません。

このときは、Ver4.44がインストールされたままの状態で無理矢理Ver.6.0.xをインストールしたのでそれがダメだったのかと思って、/usr/local/drwebと/usr/local/etc/drwebという2つのディレクトリを名前を変えて残しておき、クリーンインストールを試みました。本当は、/var/drwebというディレクトリもあったのですが、バックアップを忘れてました。あぁ...

これで、まぁ、なんとかなるだろう、と期待したのですが、drwebdを起動しようとすると、/var/drweb/lib/drweb32.dllがないよ、と言ってエラーになって起動しません。さっきは動いてたじゃん、と言いたい気分をグッと抑えて、該当するディレクトリをみてみると確かにそんなファイルはありません。そもそもFreeBSDってシェアードライブラリはsoっていう拡張子じゃなかったっけ、というか、windowsみたいなdynamic link libraryってあるんだっけ、とかその拡張子ってdllだったのかなぁ、などとあれこれ素朴な疑問が涌いてきてもうすっかりイヤになってしまいました。

Ver.4.44に上書きインストールなら起動して(ちゃんと動作していたわけじゃないような気がするけど)、Ver.6.0.xをクリーンインストールすると起動もしない、ってのはどういうことなんだろう。

マニュアルにはVer.4.44の設定ファイルをVer.6.0.xの設定ファイルに変換するスクリプトが/usr/local/drweb/maild/script/にある、と書いてあるのですが、残念ながらマニュアルに書いてあるようなperlのスクリプトはどこにもありません。一応、findコマンドで検索したけどやっぱりありません。マニュアルと実際のソフトがあってなくて、それが設定ファイルからみだったりするとかなり気分は萎えてしまいます。うーむ。どうなってるんだ。

どうせ、FreeBSDユーザーなんてほとんどいないのでインストーラのバグ取りなんてまともにやってないんだろう、と思いつつ、とりあえず、Dr.Webなしでpostfixが動くようにしないと明日からの生活に困るので、さっさと/usr/local/etc/postfix/{main,master}.cfからDr.Webが書き込んだであろう文字を消してしまいます。これで、postfixを再起動してキューにたまったメールをpostqueue -fでフラッシュをしようとしたのですが、なぜかフラッシュできません。maillogを見るとmail transport unavailableというエラーが出ています。

どうもこれはキューに入ったときにDr.Webのフィルタに接続することになっていたので、キューをフラッシュしろ、と言っても最初にキューに入ったときと同じようにDr.Webに接続しようとするためにエラーになるようです。それで、その接続先の情報を取り除いてやらなければならないということらしいです。

ここにそういうことが書いてあったのでさっそく真似をしてみます。

postsuper -r ALL

というコマンドを叩くと、直ちに

postsuper: Requeued: 24 messages

というメッセージが出てきてキューにたまったメールを再度キューに入れ直してくれます。当然、キューに入ったらそのまま送信できてしまうので送信も一瞬で完了してしまっています。これで、postqueue -p (またはmailq)とやってもMail queue is emptyとなってめでたしめでたしです。

まぁ、めでたいというかなんというか、ようやく普通の状態になっただけで、本質は解決されてないんですが...。兎に角、Dr.Webはアンインストールしておくことにしようと思って、マニュアルにあるremove.shというのを動かそうとしたのですが、そんなファイルはありません、って言われてしまいました。いや、マニュアルに書いてあるんだけど...もう、勘弁してくれぇ、という気分です。

なんか便利そうなインストールスクリプトがついてきたのはいいのですが、できが悪いと手の施しようがありません。Ver.4.44の時代はあれこれ手作業があって面倒でしたが、ちゃんとしたマニュアルがあってそのとおりにやればちゃんとできたのでこういうしょーもないワナにはあまりはまりませんでした。便利になってるんだか不便になってるんだかわかりません。

でもって、データのアップデートのためにupdate.plというスクリプトが動くのですが、これは今まではcrontabでdrwebユーザとして動かしていました。で、そのcrontabをコメントアウトして無効化してもなぜか動いていてupdate.plがない、とかごちゃごちゃエラーをメールで送ってきます。よく調べてみると、/etc/crontabに勝手にupdate.plを動かすように書いています。マニュアルにはupdate.plをcrontab -u drweb -eで登録せよ、と書いてあるのにぃ...。

マニュアルとやってることが全然違うのでせめてuninstallができれば、と思うのですが、アンインストーラはみつからないし、なんか、いかにもロシアンクオリティな感じです(って、どんなクオリティやねん...)。

それにしても困ったことになりました。Dr.Web Pacificのサポートに連絡をすりゃいいのでしょうけれど、なんかやる気が出ないというか、ログを整理して症状を説明するのがめんどうだしなぁ。

MBR損傷

コンセントがうっかり引っこ抜けてサーバーの電源が突然落ちてしまいました。再起動するとたいていの場合は、まぁ、fsckはかかりますがどうにかなるものなんですが、今回は運悪くどうにもならない状況になってしまいました。

直後の再起動はそれらしく動いていたのですが、なぜか、bootローダーのところで固まってしまって起動せず、電源を落として再度起動をかけたら今度はブート可能なメディアがないよ、というBIOSのメッセージがでて起動しなくなりました。

古い機械なので(といっても、VIA C1だったM/Bは壊れてしまったので今はintelのdual core Atomが乗っかっているM/B)、HDDがVIAのM/Bとともに半死になったものを無理やり復旧して使い続けているというものです。一応、PATAのハードウェアRAID 1でミラーリングをしているのですが、どうも、起動に失敗するようになった壊れたHDDのMBRを正しくミラーして2つのHDDのいずれも起動できなくなってしまったようです。確かに、ハードウェアRAIDの機能としては正しいけれど、論理的には正しくないよなぁ、と思いつつ、放っておくわけにもいかないので復旧を試みました。

HDDは今はなきMaxtorの160GBでATA133接続のものです。懐かしい。もう、ジャンク屋に行ってもこんな中途半端なディスクは見つかりません。

とりあえず、HDDをRAID装置から外して1台ずつ起動するか確かめますが、READ I/O errorで起動できません。HDDとしては認識しているのでコントローラの類は死んでいないようです。別のFreeBSDに壊れたらしいHDDをつなぐと起動時にad2を見に行って、LBA=0でI/Oエラーというメッセージを返してきます。これはどう考えてもMBRが壊れたということのようです。逆に、パーティションテーブルを復旧させればちゃんと起動できるディスクになるはずです。

というふうにだいたいの復旧の方向にあたりをつけていろいろツールを探してみるとTestDiskというとてもありがたいフリーソフトがあって、コンソールで動くのでたいていのOSでコンパイルできてしまうという便利なものがありました。使い方は日本語で説明されたありがたいサイトがあるので適当に参考にします。

「TestDisk」の使い方

基本的にはここからもらってきて./configure && make一発です。コンパイルできたら、srcディレクトリに実行ファイルができているので、そのディレクトリに移動して./testdiskとやれば起動できます。

あとは、対象とするディスクを選び、Analyseからquick searchで適当にパーティションを調べてもらう、という手順です。

ここではまったのはFreeBSDはFATでいうところのパーティションはスライスと言っていて、スライスのなかで分けているBSDパーティションをパーティションと呼んでいるので混乱する点です。TestDiskはスライスを見つけてくれますが、BSDパーティションは見つけてくれません。つまり、ad0s1, ad0s2, ad0s3というのは見つけられるけど、ad0s1a, ad0s1b, ad0s1e, ad0s1fというようなBSDパーティションは見つけられない、ということです。deeper searchをするとなんとなくそれらしいものを見つけてくれるようではあるのですが、正しいのかどうかよくわかりません。

いずれにしても、MBRが壊れたという今回の状況ではスライスを復旧すればよいはずです。BSDパーティションの情報は各スライスの頭に書き込まれているはずで、それが壊れていなければスライスを復旧した時点で全部復旧するはずです。

quick searchするとそれらしいスライスを見つけてくれます。ところがディスクに書き込まれているラベルはシリンダー/ヘッド/セクター(CHS)の値が317632/16/63となっていて512byte/sectorです。これでパーティション(スライス)の切れ目をTestDiskが探すとヘッドの数が少なくてスライスががオーバラップしている、といって書き込みができません。

analyse (どうでもいいけど自分はいつもanalyzeって書くので綴りが気になる...)するときにヘッドの数が16になってるけど255だと思うよ、というメッセージがでて、もし、オーバラップで書き込みができないようなときはgeometryでヘッドの数を255にしてみてね、と言われます。FreeBSDのfdiskはオーバラップをものともせずにヘッドの数を16でスライスに切っちゃってるようですが、TestDiskはそれを潔しとしないようです。

というわけでしょうがないのでヘッドを255に直してからスライスを書き込みます。ついでに最初のスライスをアクティブに設定しておいてブートローダを使わないで起動するようにしてしまいました。どうせサーバーでFreeBSDしか入れていないので特に不便はありません。

TestDiskでパーティション情報をMBRに書き込むと途端にOSのほうでパーティションを認識して/dev/ad2s***というデバイスファイルが出現します。これでマウントできます。ただし、認識したときにdisklabelにはヘッドが16って書いてあるのにヘッドが255もあるじゃん、という不満は言ってきます。とりあえず動いているようなので軽くスルーしてしまいます。

これで、いざマウントしようと思ったらディスクがクリーンじゃないからfsckしろよ、と言われます。

しょうがないので、fsck /dev/ad2s1aという具合でコマンドをたたくのですが、ファイルシステムがわかんない、と言われて終わってしまいます。いつのころからかfsckはファイルシステムを明示的にオプションで指定してやらないといけないようになったようで、

fsck -t ufs /dev/ad2s1a

というようにやらないといけないみたいです。

これで無事マウントできるし、実際にこのHDDからも起動ができるようになりました。

ちなみに、ミラーリングしていた2台のHDDのうち1台はかなり古くてガタが来ているよな、と思っていたのですが、案の定、不良セクターが山のように発生して危険な状態でした。しょうがないので、このディスクはバックアップとして残しておき、そこらへんに転がっていた同じMaxtorの160GBのディスクをfsckして不良セクタがないことを確認したうえでミラー用に投入しました。

というわけで、やり方がわかれば優秀なツールのおかげであっけなく解決ですが、やっぱり問題の切り分けが一番面倒でした。さすがに最近このサーバーは事故が多いのでデータを退避させて新しいシステムに移行しないとまずいなぁ、と思います。

でも、のど元過ぎればなんとやら、で普通に動き出すとまた後回しになっちゃうんですよね。弱すぎ。