dovecotのantispamプラグインで迷惑メールフィルタの学習をコントロールする
先日のトラブルでIMAP環境の組み直しになった。それ自体はたいした話ではない。パッケージをいれてデータを戻すだけ。
悩ましいのは迷惑メールの処理。MUAでの判定でも十分ではあるのだが、複数のマシンで読み書きするのでちょっとめんどくさい。トラブル以前は自作ツールをぐるぐるまわしてbsfilterで処理していたのだが、再び自作ツールをぐるぐるまわす気にはなれない。かといってまともにdaemon化するなどさらにいじる元気もない。sieveでなんとかできないものかと思ったけども、やはり振り分けくらいにしか使えないようで、この手の目的には向かない。
antispamプラグイン
そういえばdovecotにプラグインがあったのだったっけ。探してみたらそれらしいプラグインが見付かった。dovecot antispamという。
これ自体で迷惑メールの判定を行うものではなく、外部の迷惑メールフィルタの学習をコントロールするためのものだ。特定のフォルダを使って迷惑メールフィルタの学習をコントロールしようとする。つまり、MUAからのフォルダ操作で学習させることができる。自作スクリプトでやっていたのと考え方は同じ。debパッケージもあるようだ――がdebは使えなかった。
dovecot本体とプラグインとのバージョン整合性が行われていて、dovecot-antispam.debは古いdovecotでbuildされている。それがバレてはねられる。うーん、と、ちょっと迷ったが、rebuildして試してみることにした。
HDDがとんだのでケースを買った
HDDがとんだ。そのためPCケースを新調した。
19日の月曜日の午前中。どうもThunderbirdがおかしな動きをする。最初はそんなだった。わりとおかしな動きをするし。でも、ふとログを見るとエラーが出ていた。少し油断していた。本格的にまずいなと思ったときには手の届かないところにいってしまっていた。
とはいえ、日次のバックアップが早朝にとれているのは確認していた。復旧作業に時間はかかるが、それほどひどいことにはならないだろうとこの時は考えた。この日、他にやらねばならないこともあったので復旧作業は翌日から進めることに決めた。
外出からの帰り道、この際だからとHDS722020ALA330(2TB)を二本購入した。今回とんでしまったのは/homeにmountしていたHDD。システム部分は生きていたので、新しいHDDを接続した上で普通にbootさせる。fdiskでパーティションを切り、mkfsをかける。バックアップからのレストアを開始した。
ところで月曜日のうちにいくつかのことをやっていて、その中で、どうもCPUやHDDの温度が高いらしいということに気付いた。CPUは45度前後、HDDは50度前後である。エアコンをかけた状態でこうであるから、エアコンをかけないときにはより高いのだろう。正直に言えば、このPCの状態はあまり気にかけていなかった。日常的に使っているので壊れるときには目の前で壊れるからだ。
だが、この状況でさらなる不幸が起きでもしたらさすがにかなわないので、HDDにサーキュレータで直接風をあてて冷やしてみることにした。そうしようとしたところ、つまりPCケースを開けたところ、一分とたたないうちにCPUの温度が下がったのである。HDDのほうはケースをあけただけではどうにもならず、ケース外でサーキュレータのまん前に置いて冷やしながらの作業となった。
こんなことがあったため、実はHDDとともにケースにつけるファンを買ってきていた。排熱がうまくないようなので、ひとたび熱がたまり始めると、どうにもならなくなってしまうのではないかと想像できる。そこで、まだ取り付けられるところにファンを、という試みだった。結果を言ってしまうと期待したような効果は得られなかった。6〜7年、もしかするともっと古いケースである。HDDがまったりまわっていたころのものであろう。みっちりと詰めるようにHDDを配置する構造では、ちょっとやそっとの風量ではたちうちできないようだ。これはいけない。
50度を越えてはいけない。半ズボンの人に風通しのよいケースをいくつか教えてもらい、その中から購入しやすそうなNINE HUNDRED TWOを発注した。待つことしばし――まあ、丸一日ほどしてケースが届いた。さっそくサーキュレータから離れられないHDDたちをはじめ、パーツたちを移動させていく。
率直に言って、青いLEDはどうかと思うが、たしかに風通しの良さそうなケースである。大きなファンが標準で四つついていて、それぞれにスピードを変えられる。ゆっくり回せばあまり音がしなくてよい。最近のケースは電源をケース下部に置けるようになっているんだなあ、というところから知らなかったくらいに久しぶりのことで取り扱いにしばし迷うこともあったが、特別に扱いにくいこともなかった。
かんじんの温度だが、このケースにしたところ室温+5度くらいのところで落ち着くようになった。なんともケースでこんなに違うものかといまさらながらに驚いたが、まずはほっと一息つくことができた。(この作業の間にケースとは関係ないHDDまわりでちょっとオモシロイことがあったのだがまた後で。)
|
|
Capistranoで指定したユーザ権限によりファイルを作成する
Capistranoを使ってファイルをアップロードするにはputやuploadを使う。ただ、指定したユーザの権限でファイルをアップロードしたいというときにしばしばなやむことになる(……よね?)。
たとえば、特定のユーザでしかアクセスできないディレクトリにファイルを置きたいといったケース。ログインユーザでいったんファイルをどこかにput/uploadして、そのファイルをsudoでchownしてmvすることになる。
まあ、通常はそれで十分なのだけど、こんなふうに書けなくもなさそうだ。
content = "abc\ndef"
sudo "dd of=/path/to/file bs=1 count=#{content.size} 2>/dev/null",
:data => content + "\n",
:as => "user-name"
ただし、この方法ではモードの指定ができないからchmodは別に行う必要がある。
停電
昨日、停電があった。
横浜に来てからは初めてのこと。それよりも前から考えてもずいぶん長い間経験していなかったような気がする。
何が起きたのかわからない
うちのあたりは30分ほどで復旧したが、地域によっては三時間以上続いたらしい。電気が止まってすぐにブレーカーを見た。落ちているレバーはなく、これはマンション全体だろうかと考えた。ほどなくサイレンをならしたパトカーが走り出し、停電らしいと考え始めた。外に出るとエレベーターが止まっていた。
その間二〜三分ほど。長くても五分くらいのもの。復旧する様子がないため、情報を求めてtwitterにアクセスしてみたところ、横浜の一部分、それなりの範囲で停電が起きていることを伝え聞いた。mixiなどにアクセスするのは思いつかなかったが、後で見てみても特別には話題になっていないようだった。大きな話題になるほどにはエリアが広くなかったためだろう。
右往左往
ともあれ、このままではUPSの電力がもたなくなるのでマシンを落とすことにした。ディスプレイ一体型のiMacは特に問題なくシャットダウンできた。が、ディスプレイを別にしているマシンは、ディスプレイの電源をとっていなかったために操作できず。やはりあわてていたようで、iMacを落とすのは、他のマシンを落とした後でなければならなかったのに順番を間違えてしまった。かといって再起動するわけにもいかず。
急いで家人が使っているノートPCを開き、そのマシンからアクセスして…… と、今度は無線が落ちている。やはり電源をとっていなかった。HUBの電源をとっているのを考えてみるに、やはりiMacをまっ先に落としたのが間違いである。もっともイーサケーブルの用意はあったので、有線でつないでマシンを落としていった。さいわいUPSが切れることはなかった。
次にHDDレコーダの処理をした。こちらもUPSがあるのだが、ちょうど動いていないタイミングであったために問題はない。が、このままでは録画が始まってしまう、かもしれない。主電源の落とし方がわからなくて――瞬間的に考えこみそうになったが、なんのことはないコンセントを抜けばよいだけのことだった。今回はたまたま録画中ではなかったが、録画中に停電が起きる可能性を考えると、その動作状態からの電源の落とし方はどこかにメモしておいたほうがよさそうだ。
こう書いてみると痛い順番間違えをしたとはいえ淡々と処理したような感じだが、実際には部屋のあちこちをかなり無駄に行ったり来たりしていた。
復旧作業
停電から復旧後、ハード的にもデータ的にも問題は起きなかったことを確認できた。だが、面倒がないわけではなかった。
普段使いのマシンで、ログインでき、Xは起動するもののなぜかすぐにホワイトアウトする現象が起きた。一部のめったに使わないパスワードがこの中にあり、X上でなければ確認できない状態だった。そのパスワードが必要な可能性があって、これは困った。他のユーザでログインすれば現象が起きないことを確認でき、そこから必要なパスワードを取り出した。後で見たところcompizの動作がおかしくなってしまっていたのがホワイトアウトの原因だった。
さらに、サーバとして使っているマシンがいつまでたっても上がってこない。fsckがかかるからそれなりの時間はかかるだろうと思ってはいたものの、それを考えにいれても異常といえるくらい応答がない。困ったことにディスプレイをつないでおらず、そしてケーブルがない。使っていないCPU切り替え機が目に入ったのでつないだが、こわれているようで何もうつらない。廃棄予定のディスプレイのケーブルが部屋のすみにあるのを見付け、これを使ってようやく状態を確認できた。単にキーボードを認識できていないだけであったようで、PS2のゲタをはかせてUSBキーボードをつないだらやがて起動してきた。
長い間、落としていないマシンばかり。一方で、手元にあるマシンだからとアップグレードを適当にかけていたためこんなことになる。毎度わかってはいるものの、事を終えるとまた繰り返してしまうのだった。
明日はじめるCapistrano
Railsのdeployに使われることで知られるようになったCapistrano。でもその実態はRailsにとらわれているわけではありません。Capistranoは何かというと、こう言えます。SSHを使って多数のホストに同時並列に接続して、実行させたいコマンドを一斉に送信、実行結果を受け取って問題なければ次のコマンドを、というのを行うためのフレームワークです。
Capistranoを使い始めるのは簡単です。受け側に必要なものがあまりなく、一般的なUNIX系環境であればすでに準備が整っている状態です。Capistranoを実行するホストにはRuby環境が必要ですが、それ以上のものは基本的には必要ありません。コンパイラも不要ですし、ちょっと試してみるだけならインストールしてなくても大丈夫。
iptablesのstringモジュールでバイト列にマッチさせる
特定の内容の通信だけを遮断したくなり、きっとiptablesに何かあるだろうと調べたらstringモジュールがあった。iptables 1.4.6のmanpageから引用する。
string
This modules matches a given string by using some pattern matching
strategy. It requires a linux kernel >= 2.6.14.
--algo {bm|kmp}
Select the pattern matching strategy. (bm = Boyer-Moore, kmp =
Knuth-Pratt-Morris)
--from offset
Set the offset from which it starts looking for any matching. If
not passed, default is 0.
--to offset
Set the offset from which it starts looking for any matching. If
not passed, default is the packet size.
[!] --string pattern
Matches the given pattern.
[!] --hex-string pattern
Matches the given pattern in hex notation.
遮断の条件に指定したい内容が非ASCIIのバイト列だったので--hex-stringを指定した。--hex-string 'e7a781e381aee5908de5898de381af...'のように。ところがうまくいかず、ありそうな書式をいくつか試しても変わりがない。ふと、試しに、文字列をそのまま(16進数表記にせずに)指定したところ、当初の意図の通りにマッチした。
どうやら何かの書式があるらしいと、iptablesのコードにあたったところ、以下のルールに従ってバイト列に変換されることがわかった。
- 「|」にはさまれた部分はバイト列の16進数表記として処理される
- それ以外の部分にある文字はその文字自身を表す
- ただし「\」により続く文字の特別な意味をキャンセルできる(「\|」や「\\」)
先の例については--hex-string '|e7a781e381aee5908de5898de381af...|'とするのが正しいやり方となる。また、--hex-string 'a|62|c'は「abc」にマッチし、--string abcや--hex-string abcを指定したのと同じ結果となる。指定できるバイト列の長さ(変換後の長さ)は128バイトまでのようだ。
--fromや--toの指定を加えると、マッチ対象とする範囲を指定できる。--from 20ならTCPヘッダ(など)以降(〜65535バイト目まで)が対象となり、特に指定しなければIPパケットの先頭から65535バイト目までが対象範囲となる。
Passengerで本当にあった○○な話
Passengerを使っていて実際にやってしまったダメーな思い出話。(けっこう前のことなので今の状況とは少し違うかも。)
間違ったキャッシュが返る
この日記にはtDiaryからTypoに移行したという経緯がある。移行のためのあれやこれの手間はかかったものの、一通りの作業を終えるとおとなしく動作していた。
ところが、ある時、ブラウザからのアクセスにatomデータを返していることに気付いた。動作を追ってみると、どうも何かの加減で間違ったキャッシュファイルがレスポンスに使われているように見える。そこで、とりあえずの回避策として、生成されていたatomキャッシュを削除した。するときちんとhtmlデータが返されるようになり、新たにhtmlのキャッシュファイルが生成されていることを確認できた。
気になって調べてみると、atomキャッシュだけが生成されているページが他にもいくつかある。先にatomへのアクセスがあれば当然このようになるわけなので、それ自体は問題ないはず。だが、これがあるとhtmlで返すべきところが返らなくなってしまうようだ。
ある期間この現象は困った謎のままであった。まったく見られなくなるわけでもなく、ともかくは動いているということもあって、場当たり的な対処を繰り返して過ごしてきた。
ここでTypoが作るキャッシュを考えてみる。Typoは生成するレスポンスによってhtml、atom、rssなどのキャッシュをファイルとしてpublic以下に作る。これらのファイルは、Passengerの通常通りの動作としてTypoが関与することなくレスポンスに使われる。したがって、問題のhtmlリクエストに対してatomデータを返している容疑者はTypoではなくPassengerかApache HTTPサーバである。ということに、かなり時間をかけた上で気付いた。
もう少し正確に言うと、ようやくそこに目を向けることができた、という感じかもしれない。となれば、まっ先に疑うべきであった点が一つ。MultiViewsだ。
ところで、前述の通り、この日記はtDiaryからTypoに移行した。tDiaryのときの設定は以下のようなものだった。
Alias /diary /path/to/diary <directory /path/to/diary> # tDiary Options -MultiViews </directory>
これをTypo+Passengerにかえた際に、/path/to/document_rootから/path/to/diary/publicへのシンボリックリンクを作成した上で、次のように変更した。(実際にはtDiary→Typo+FCGI→Typo+Passengerと設定を変えてきているため、その跡が少し残っている。)
#Alias /diary /path/to/diary/public <directory /path/to/diary/public> # Typo Options -MultiViews </directory>
気持ちの上ではMultiViewsはオフのままにしたつもり。だが、もちろん、そんなことはなく、/path/to/document_rootで有効になっているMultiViewsは/path/to/document_root/diaryでも有効になる。そしてTypoが作り出すURLには拡張子がついていない。ブラウザからのアクセスは/diary/fooに対するものとなる。この時htmlキャッシュがなくて、atomキャッシュやrssキャッシュがあれば。そう、MultiViewsの機能により(もちろん設定にもよるが)htmlではなくそれらのデータがレスポンスとして送信されてしまうのであった。
Passengerじゃない!
FastCGIで動作させていたあるRailsアプリケーションをPassengerで動かすことにした。ところが、なかなか作業がはかどらない。移行をしているせいもあって、いろいろやってみたあげく、変わらずFastCGIで動いてしまうというのを何度か繰り返していた。
と、ここで、FastCGIを動かなくしてしまえばよいではないかと思い付いた。そもそもPassengerに移行した後はFastCGIを使わないのであるから、これはどちらにしても良いことである。
さっそくそのようにしてみたところFastCGIで動作することはなくなった。
よかった、よかった。別の作業に取りかかろう。……あれ? なんだか重い? アプリケーションは動いてはいる。エラーも出ていないし、返ってくるデータにも問題はない。だけど、あれ? レスポンスがものすごく悪い?
FastCGIのプロセスがなくなったことで安心してしまったが、そういえばPassengerのプロセスは動いていただろうか。
あわてて見直してみると、Passenger配下にあるはずのインスタンスがない。では、どうやって動いているのだと追ってみれば、なんとも困ったことにアプリケーションはCGIで動いていたのだった。
Snow Leopardが遅くなる 1
Snow Leopardにしてから、なのではないか思うのだけど、よくわからない現象が起きるようになった。(実際にはそれ以前から起きていて気付いていなかっただけ、ということも無いとは言い切れないが。)
ある時、突然動作が遅くなる。重くなるのではなくて、遅くなる。CPUは使っていない(idleが70%以上など)。I/Oもたいしたことはない(ほぼアクセスしていない)。メモリにも空きがある(20%くらいはfree)。こういう状況でちょっとしたコマンドが終了するのに1秒以上かかるようになる。
たとえば「ruby -e0」を実行すると、通常ならキャッシュに乗っていない状態でも0.285秒。キャッシュに乗っていれば0.018秒で終了する(今やってみた)。これが現象発生時には1秒かかる。特に「ruby」に限定されるわけではなく、iPhotoとかXMindとか、GUIのツールでもものすごく反応がにぶくなる。
何がきっかけになってこの状態になるのか分からない。が、リブートすると元に戻ることは分かった。最初は熱か何かが原因なのかもしれないとも思ったけども、そういうものでもないようだ。ついでに言うと、上の「ruby -e0」の例はmacportsでいれた「ruby」(/opt/local/bin/ruby)を使った場合のことで、とっても不思議なのだけどもOSについてくる/usr/bin/rubyについてはこの現象を確認できない。まあ、少なくとも「/usr/bin/ruby -e0」については遅くなったところを見ていない。いったいなんなんだろう。
試しにOSの再インストールをしてみたのだけども…… たまたまなのかなんなのか、現象発生時(やっぱり発生してしまった)に「ruby -e0」を実行してみると終了までに1.5秒かかるようになってしまっていたという……。その後、まだ起きていないので本当にたまたまだったのかどうかは確認できていない。
ハードウェアトラブルでPC新調
昨日の朝方、気が付いたらPCが止まっていた。
自宅のサーバ用として使っているPCで、それが止まると何もできないというほどのことはないが、長引くとわりと困る。原因ははっきりしないのだけども、電源かマザーボードなのかなと思える(まともに電源が入らなくなった)。予備の電源などはなく、切り分けるにも道具が足りない。手さぐりでのトライ&エラーを繰り返すのもためらわれるので思いきって中身を入れ換えることにした。
前回、このPCの構成を変えたのは2006年のことだったようなので、三年ばかりたったことになる。今回も、まわりの人々にアドバイスをもらいながら構成をおおまかに決め、あとは店頭でと、ショップに走った。
- ASUS P5Q-E
- Intel Q9550
- バルク メモリ8GB
- Owltech SS-600HM
- 適当なビデオカード
小雨の中、けっこうな重さと大きさになった紙袋をひぃはぁいいながら持ち、この時節に似合わない汗を大量にかきながら帰った。
時間をおいてもいられないのですぐに換装作業に入り、毎度のことながらドキドキしながらCPUファンの取り付けをしたり、HDDのデバイス名が変わっているのに対応したり、fsckが延々続くのを待ったり、といったお決まりの作業をした。
以前よりはずいぶんと良い環境になったので、本格的に何か動かそうかな。
