【USBメモリUbuntu9.04】更に危険な設定へ

/etc/sysctl.conf へ
vm.dirty_writeback_centisecs = 360000

を追加。遅延書き込み1時間  😀

/etc/init.d/mountall.sh/etc/init.d/umoutfs を変更。

/etc/fstab で手を入れたのは次の通り

UUID=0c3d26d3-43e3-4291-b618-18c9a3659ccf /               ext3    noatime,errors=remount-ro 0       1
/dev/shm        /ramdisk        tmpfs   defaults                0       0
/dev/shm        /tmp            tmpfs   defaults                0       0

root file system の relatime を noatime にして、アクセスタイムのディスク書き込みをしないようにしている。

そして、/tmp をスクリプトで設定するんじゃなくてfstabでやるようにした。

/ramdisk はUSBメモリに書き戻すデータの置き場所にしようかと考えているが、遅延書き込み周期を長く取ったので、要らないかな?

ユーザのホームディレクトリに作られるアプリケーションの設定ファイルの書き込みが困ったもので、現状だと、ログイン時にRAMDISKに移動させてシンボリックリンク貼りまくりという愚策しか思い付かん。

なので、今のところは個別アプリで、ディスクアクセスの多そうなものの設定を弄って、遅くて書く度に寿命が縮まるUSBメモリへの書き込みをできるだけ回避している。

Tunderbird は、IMAPのアカウントで使っているが、そんなに沢山のメールを貯めていないから、サーバ設定の「メッセージの保存先」を /tmp/noizumi に設定。

IMAPの場合、「メッセージの保存先」にサマリーを生成するだけなので、揮発しても次にマシン再起動した際に若干時間が掛かる程度なので、特に問題は無い。

ROM RAM ベースで動かすと、古いマシンでも充分快適に動くな。

Ubuntu 9.04 on USB Memory

RUF2-P8G-BKにUbuntuを入れようと試みるが、USB起動ディスクで作ると、サイズは700MB程度とコンパクトで良いのだが、ISOイメージを入れてくれるのとRead Only Mountなので、アップデートとかできない。

普通にインストールしたが、このままでは、書き込みが多いlogとかtmpとかのディレクトリのせいで、Flash ROMがすぐ死んでしまいそう。

そこで、RAMディスクに頻繁に書き込みのあるディレクトリを割り当て、Flash ROMの急速な劣化をさける対策をした。

rootファイルシステムは、noatimeオプションでマウント。
/etc/init.d/mountall.sh

case “$1″ in
start|””)
do_start
mkdir -p /mnt/tmp
mkdir -p /mnt/log
mount -t tmpfs /dev/shm /mnt/tmp
mount -t tmpfs /dev/shm /mnt/log

/usr/bin/rsync -a /var/log /mnt

mount –bind /mnt/tmp /tmp
mount –bind /mnt/log /var/log
chmod -R 1777 /tmp
;;

/etc/init.d/mountall.sh

stop)
umount -l /tmp
umount -l /var/log
/usr/bin/rsync -a –delete /mnt/log/ /var/log

do_stop
;;

/var/log はシャットダウンや再起動時にrsyncで書き戻す。
/tmpはそのまま揮発していただく。

最初、mount –move でやろうとしたが、umount時にRAMディスクが消えて無くなるので、書き戻せず、–bindでマウントした。

結構いい感じだが、やはり/homeの細々とした書き込みのせいで、時折、重たくなる事もある。 今のマシンはメモリ768MBしか無いから、これはさすがにRAMディスクに持っていくのはヤバい。

LinuxのRAMディスクの/dev/shmはデフォルトで、最大実メモリの半分までのサイズを持ち、実メモリの使用が増えると縮んでくれる優れもの。

実メモリの使用が増えて、RAMディスクの実使用サイズを脅かすようになるまで、稼動させた事は無いが、こういうクリティカルなケースになったら、RAMディスクのマウントが外れるのかな?

Cyrus IMAPd監視ツール

社内メールサーバに障害が起こっていたが、Cyrus IMAPdのDBのログのownerがrootになっていて書けないという原因だった。

/etc/init.d/cyrus-imapd stop
chown cyrus.imap /var/lib/imap/db/*
/etc/init.d/cyrus-imapd start

とやって、 再びstartさせたら治ったが、ログを見る限りでは、DBのログローテーションタイミングで、ctl_cyrusdbが新たに作成したログへの書き込みに失敗しているという感じ。

Web検索すると、Macの事例がちょこっと読めたりするのだが、英語のメーリングリストまで当たってみても、具体的にどういう対策を採れば解決するのかという情報は皆無で、バージョンは今2.2.12だが、2.3.xに上げたとしても直る保証がない。

何しろ、DBのログローテーションのタイミングで起こるので、よっぽど大量のメールを処理してても滅多に起こるものでもない。しかし、休日に呼び出されるのも嫌なので、ログを監視して自動復旧するツールを作った。

昔、perlでpppのログ監視して、pppが切断されたら再upとか、PCMCIAのAirH”カードを再初期化するツールを作っていたので、その応用で、maillogを監視し、ctl_cyrusdb\[\d+\]:.*DBERROR.*Permission denied ってのに反応するようにした。

Cyrus のdeliverはIMAPdでスプールできないと/var/spool/mailに落としてくれるので、

formail -d -s sendmail hoge</var/spool/mail/hoge

とかやると、落っことしたメールを再配送できる。

監視ツールでは、この再配送までを自動でやるようにしてはいるが、実際に障害が起こらないとうまく動くかは分からないんだなこれが(笑)

ツール作り

Cyrus IMAPdと腐れExchange Serverのメールをバックアップアカウントへ合成コピーした時に、腐れExchange Serverのメールがダブるので、それを消すツールを作った。

こういうちょいとしたツール作りは楽しい:-)

まあ、普通のまともなメールサーバーなら、Message IDが同じだとメールの同一性は保証されていて、Cyrus IMAPdへスプールしてもインテリジェントにduplicate markを付けて、冗長な同じメールは実データとして格納しないはずだ。

しかし、腐れExchange ServerとOutlookは意味の無いReceivedヘッダをわざわざ追加し、winmail.datとかいう何の役にも立たないゴミを付加してくれるので、さすがのCyrus IMAPdも別のメールとしか見てくれないようだ。

「簡単」と素人を騙して売りつけ、実は制御不能の腐れExchange Serverなんぞ相手にしていなければ、作る必要の無いツールな訳だが、まあ、問題解決のプロセスを考えるのが面白いからよかろう。

で、最初、PHPで組んだ時に、UIDがキーの連想配列にMessage IDを格納して、array_unique()という簡単な処理で、ダブってないMessage IDのリストが作れ、array_diffで、削除すべきメールのリストがすぐ作れた。

だが、盲点は、消されるのはダブっているメールの一方であって、必ずしも腐れExchange Serverのゴミメールじゃないという事だ。

そこで、imap_fetch_overview()で取得したサイズも配列に格納し、array_multisort()で、UID、Message ID、Sizeのそれぞれの配列をソートする。

すると、リストで、ダブっているMessage IDのトップは必ずサイズの小さいものとなり、array_unique()で生き残るのは一番最初に見つかったものなので、サイズの大きいメールが駆逐されるというアルゴリズムにした。

これで完璧だ:-D

しかし、マイクロソフトのもたらす後戻り工数って、全世界規模だとどれくらいの損害額なんだろうなあ。

Progress bar 実装

PHPでファイルアップロード時に進捗を表示するProgress barの実装をやってたりする。

PHP5のAPC(Alternative PHP Cache)で、ファイル送信時の情報取得が使えるようになったのだが、サーバがPHP4のシステムで動いているので、PHP5に置き換えられない。

PHP4とPHP5の同居が必要なのと、Apacheでモジュールを組み込むにしても、mod_phpは4と5を同時に組み込む事ができないので、それぞれを組み込んだApacheを動かす必要がある。

通常動かしているApacheとは別にもう1個別portで動かして、特定のURL以下をreverse proxyで置き換えなんてトリッキーなやり方で動作環境は確保した。

で、Progress barのソースサンプルを入手して実装しようとしたのだが、非常に難解な組み方をしていて、「何かあるな」という感じはしていたのだが、別に気にせず、原理を理解して、Ajaxのprototype.jsを使ってコードを書いた。

しかし、safariでテストした時、全然動かない。
非同期通信で呼ばれるPHPスクリプトのアクセスログが発生せず、Progress barを表示するページで、formにAjax.requestの処理の入った関数が呼ばれているかを吐き出すようにしてみると、ちゃんと呼ばれている。

しかし、Ajax.requestの行だけ、全く無視された状態になっていた。サンプルだと動く。サンプルは、ページ遷移しないか、一部が遷移するようになっていて、非同期通信でAPCの情報を取得しているのは、遷移しない部分…。

ここで、サンプルがなぜ難解な方法で組まれているのか全てを理解した。
APCの情報を取るのに、一部のブラウザではページ遷移が起こる場合、Ajax.requestなどの非同期通信のjavascriptコードが一切動かなくなるのだ。

根本的に構造の見直しが必要で、ほとんど一から作り直し(笑)

まあ、なんとかでっち上げつつあるが、今はIE6で後方互換モードでないと表示しないとかしょうもないブラウザのバグの対処に当たっている。

暫く、SI業から遠ざかっていたから動向を良く知らなかったが、Microsoftは相変わらず、世間に迷惑をかける実装を続けていたのか。実にMicrosoftらしいと感心する事しきり(笑)。

PHP

IMAPのメールサーバをimapsyncというツールで複製を取っているが、フォルダに関しては、コピー元のフォルダが基準となり、コピー先に無ければ作成して中身をコピーという動作になっている。

コピー元のフォルダが削除されたらどうなるか?と言えば、コピー先のフォルダはそのまんま。つまり、長期間複製を取っていると、コピー元で削除されたフォルダが、コピー先でどんどん増えていくという困った状態になる。

IMAPのサーバの機能としては、メールだけは「何日以上古いものは消す」という事はできるが、フォルダは消せない。

空のフォルダが溜まって来るのを何とかしないといけないので、ツールを作る事にした。

socket openとか低レベルな関数組み合わせてゴリゴリ作らなきゃいけないのかと思ったが、PHPにはIMAP Clientなる便利な関数群があった。

フォルダツリーを辿って、子フォルダが無く、メールも入ってないフォルダを削除するってのを再帰処理で組んだが、socketとかバッファとか、文字列処理とか考えなくていいからすげー楽だ。

いい世の中になったものよのう。

Cyrus IMAPd

業務でCyrus IMAPdなんかと戯れている。

社内の業務で使っているExchange Serverが、お客さんのメールをバシバシBadMailに落とし、届かないという由々しき事態となっているので、捨てようという話で(笑)、代替環境を試験している。

しかし、pop3コネクタかExchange Serverの挙動は非常におかしい。

MIMEエンコードしてあるメールアドレスの名前部分をデコードしてから、メールアドレスとして正しいかを評価し、RFC違反だとしてBadMailフォルダに叩き落してくれる。しかも、それがpostmasterには通知されない。

喩えば、「(株)会社名<hoge@fuga.co.jp>」みたいなので、()内はメールアドレスではコメント扱いだが、( だけが削除されて、複数の変なアドレスに変換される。

これは、Outlookも変な仕様を継承していて、宛先などの行頭に ( が入っていると勝手に削除する。

()を全角にすり替えてやると通るのだろうが、そもそもSMTPでRFC違反にならないように、わざわざMIMEエンコードしているものを、なんでデコードした上に正しくないアドレスを創作して、評価するんだ?

「ユーザーは馬鹿だから、かしこいマイクロソフトが正しいRFCに準拠したアドレスに修正して、メールが不達になる最悪の事態を防ぎます」とでも言いたそうだな。

実際は、その蛇足のせいで、届いて当たり前のメールが届かなくなっているんだが、一体何を考えとるんだ?

MIMEデコードしているのは、恐らく、サーバーサイドのメールの振り分けの為だろうが、MIMEデコード前にメールアドレスが正しいのかをチェックして、それからMIMEデコードだろう。何でこんなクソな実装ができるのか理解に苦しむ…。

Cyrus IMAPdはさすがに軽くてパフォーマンスは良い感じ。しかし、sendmail、procmailと連携させるのに色々と調べないといけなかった。

古いドキュメントを見ると、色々と設定しなくてはいけないのだが、新しいsendmailになると、cyrus imapdとの連携が出来るようになっていて、sendmail.mcに2行書いて終わりとか簡単になっている。

procmailと連携させる場合だと、sendmail.mcはいじる必要が無く、/etc/procmailrcを作成すれば良いのだが、cyrus imapにメールを渡す時にヘッダ部にFrom: 以外のFromがあるとダメなので、formailで削除しておくとか、殆ど検索しても出てこないようなマイナーな設定をやらないといけないから苦労した。

余りコードをゴリゴリ書くような事は無く、殆ど設定弄って環境構築するシステムインテグレーションだから、楽でいいなあ。