I know who Iam.
~/.mozilla と ~/.mozilla-thunderbird のディレクトリをRAMDISK化。
これも、再起動、または、シャットダウン時に書き戻す。FirefoxのWebページ閲覧時に、USB MemoryのLEDがチカチカしていたのが無くなった。
今の所、書き戻しているのは、
/var/log
/var/cache
~/.mozilla*
で、rsync -a –delete …でやっているのだが、実は、昨日、/var/caheの書き戻しに失敗し、全部消えてログイン出来なくなった（笑）
/var/cache をRAMDISK化するのは、インストールしたパッケージを残す設定にしていたりすると、非常に大量の容量を必要とするから、実メモリが少ないマシンは要注意。
/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 ベースで動かすと、古いマシンでも充分快適に動くな。
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/logdo_stop
;;
/var/log はシャットダウンや再起動時にrsyncで書き戻す。
/tmpはそのまま揮発していただく。
最初、mount –move でやろうとしたが、umount時にRAMディスクが消えて無くなるので、書き戻せず、–bindでマウントした。
結構いい感じだが、やはり/homeの細々とした書き込みのせいで、時折、重たくなる事もある。 今のマシンはメモリ768MBしか無いから、これはさすがにRAMディスクに持っていくのはヤバい。
LinuxのRAMディスクの/dev/shmはデフォルトで、最大実メモリの半分までのサイズを持ち、実メモリの使用が増えると縮んでくれる優れもの。
実メモリの使用が増えて、RAMディスクの実使用サイズを脅かすようになるまで、稼動させた事は無いが、こういうクリティカルなケースになったら、RAMディスクのマウントが外れるのかな？
社内メールサーバに障害が起こっていたが、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
しかし、マイクロソフトのもたらす後戻り工数って、全世界規模だとどれくらいの損害額なんだろうなあ。
ファイルアップロードスクリプトが正常に動いているか、時折、ログを観察しているのだが、以前、ファイルの二重送信が原因と思っていたログパターンがまた現れた。
以前は、そのログを見て、送信ボタンの二度押しでの二重送信はJavaScriptで封じたのだが、また起こったという事は別の要因がある。
サーバログを見ると、400 BadRequestになっていた。
うーむ…、cookie関係か?二重送信っぽいので、ブラウザ2つ開いて、それぞれで送信したらどうなるんだろ？と、試験してみるとアウト！
そう言えば、セッション名は特段設定してないので、2つのブラウザで送信したら、片方が完了した時点でセッション変数は全滅するな（笑）。
という事で、セッション名を設定する事で、ブラウザ何個開いて送信しようが大丈夫になった。しかし、cookieファイルが増大していく…
cookieファイルを期限切れで破棄にするには、「アップロードが成功しました」と表示するスクリプトのヘッダ部分で、Set-Cookieを設定してブラウザに食わせてやらねばならない。
しかし、元々のあったものが、cookieの明示的な削除をして無くて、複数セッション利用時の事も全く考慮されておらず、セッション破棄の前に、色々とHTMLを表示してしまっている。
その為、いざ、cookieファイルを消そうとすると、パラメータの渡し方からロジックを洗い直さなければならず、構造からやり直しという事になる(–;
しかし、昔のわしなら、お客様の使用法を想定して、ブラウザを複数開いてファイル送信なんて事は事前に思いついたのだが、問題が起こるまで分からんというのは退化してきたのかのう。
まあ、言い訳をさせて貰うと、すでに運用されているスクリプトで、そういう事態が今まで問題に成らなかった訳が無いという思い込みがあったな。
Exchange+Outlookで、他人がメール送信に失敗した時に、わしのマシンを踏み台にしようとする件だが、メールゴミ箱を作った。
ArGo Softwareのフリーのメールサーバで、こいつのリレーをONにしつつ、ウィルスバスターのパーソナルファイヤウォールで、ポート25の送信を禁止しておく。そうするとOutlookがわしのマシンを踏み台送信に使おうとしても、ローカルのメールサーバに投げて、そこでbounce mailでドロップされて終了。
これでお客様に何通も同じメールを送りつける内の一通は減らす事ができた訳だが、他にも同じ対策をするか微妙だな。何せ、今までLinuxのサーバにメールを投げていた時は全く何の問題も無かった訳だし、Exchange+Outlookだけが「送信したメールが届かない」等の不具合がある。
全て踏み台送信対策をした場合、送信メールが届かないという事例が多発するだろう。 Exchange+Outlookってつくづくどうしようも無いクソだなあ。早く捨てたいのう…。
踏み台送信に使われているであろうと思っていたRemoteProcefureCallについて余りよく調べられていないのだが、踏み台送信にはUDPだけでも無いようだ。OutlookはExchangeアカウントを設定すると、Exchangeの送信トレイを使うように強制されてしまうが、その送信トレイが関係している気がするな。
まあ、こんなMicrosoftのしょうもない製品に時間を取られるのもバカバカしいから、詳しい検証はしていないが、アカウント共有で複数人が同じ送信トレイを使うのは、プログラマの勘で止めておいた方が良い気がするな。
Exchangeで各自にアカウントを作り、public folderを使うというのなら、何通も同じメールを相手に送信するという馬鹿げた現象が無くなる気がするが、どうせ、この一言を言ったところで、誰もやらないだろうし、やるとなると全てわしがやらされるハメになるから言わない(^^:
今更だが、ブラウザのテストに使用。
ファイル送信時にプログレスバーを表示するPHPスクリプトのテストを行った
ファイル送信でサイズオーバー検出にJavaScriptの非同期通信部を利用しているのだが、応答が帰ってくるのに5分以上もかかる。
safariも含む他のブラウザだと、すぐに応答が返ってきて、送信ファイルサイズオーバーを警告できるのだが、Chromeはこの非同期通信で送信ファイル情報がなかなか得られない。
数メガのファイルでも、大抵、最初の数秒間は情報が取得できずエラーとなる。
JavaScriptのエンジンは速いのかもしれないが、htmlエンジンはsafariをベースとしているので、それとの組み合わせで、うまくいってない部分があるみたいな気がする。
元々、safari自体が、PHPのAPCと相性があまりよろしくなく、ブラウザの戻るボタンで戻って、ファイル送信すると、APCの情報が一切取れないというのがあり、Chromeはそれに更に輪をかけて相性がよろしくない。
詳しく検証はしていないが、APCは、動作がフォームの値の順番に依存するので、ブラウザが順番が変えたりすると、期待した動作にならない事があるので、それが原因か？と思ったりする。
しかし、昔と違って、今時のブラウザはどれも長いJavaScript書いても落ち難くなったなあ。
会社で急にDNSが引けなくなるという現象が出た。
とりあえず、ネットワークアダプタの「修復」ボタンを押すと治るのだが、暫くするとまたDNSが引けなくなる。
ルータのDNS機能が悪いのか原因が良く分からない。
Wiresharkを入れてパケットダンプして眺めていると、ルータを差し置いて「俺がルータだ。俺がDNSだ」と喚いているヤツを発見。
で、結局、そのマシンでインターネット接続共有がONになっていたせいだった。
Windowsでインターネット接続共有をONにすると、パソコンがルータのようになるのは知っていたが、DHCPdまでやらかしてくれるとは思って無かった。
確かに家庭内で分かっててやるなら問題無いが、そういうマシンを企業のLANに繋がれてしまうと、配下のマシンを増やそうとしやがるから鬱陶しい。
しかし、今時、パソコンでpppoeで接続してる環境なんてあるのかねえ？
大抵はブロードバンドルータだから、こんな機能は要らないと思うのだが…。
例によって、何でMicrosoftはこういう問題の多い実装をやらかすのか、理解に苦しむ。基本姿勢が「人に迷惑をかけても使ってる人は便利だからいいじゃん」とかいう感じで実装してやがるから、大層ムカつくのでございます。
しかし、こういうMicrosoftの下種な実装で余計なトラブルを増やしてくれるおかげで、わしの様な者が職にあぶれずに済むんだけどね:-)
メール送信に失敗すると、他人のマシンを踏み台にして勝手にメール送信をやってくれるMS-Exchange ServerとOutlookだが、今日も誰かがメール送信に失敗したのか、わしのマシンを踏み台送信に使おうとしやがる。
昨日から、ウィルスバスター2009のパーソナルファイアウォールで、OutlookのTCP Port25とPort465を塞いで、Exchange Serverに踏み台送信されるのを防御しているが、いつまで経っても警告が出まくりで止まらない。
問題は、何のメールを送信しようとしているのか分からない事だ。送信トレイにもメールは無いのに、Outlookは何度も何度も誰かのメールをわしのアカウントを使って送信しようとする。
明日はUDPを全て通信不能にしてやるか。RemoteProcedureCallを封じてやれば、送信が止まるとは思うが、これでわしのマシンでのメール送信が止まったら、Exchangeが指令を出しているという事になるな。