I know who Iam.
F-Secureのlinuxゲートウエイ用にBTOパソコンを調達したが、そいつが、DG45IDとHDP725050GLA360という組み合わせ。
BIOSで設定できるRAIDにハマり、AHCI+ソフトウエアRAIDもダメ。
最近、自作系は全くやってないので、情報を持ってなかったが、検索してびっくり。
intel ICH*R+HDP725050GLA360って、去年から、トラブルに上がりまくりの組み合わせじゃん。 orz
しょうがないので、IDEモードにして、ソフトウエアRAIDで冗長性を確保する事にした。
4GBメモリ搭載なので、/var/tmpをRAMDISKにすれば、それ程、動作も遅くないだろう。
朝、会社へ行ったら、社内の顧客管理用メールサーバで昨晩からメールが取得できてないとか。
ログ見たら、fetchmail というメール取得プログラムで SIGPIPE のエラーが出ていた。
問題のメールはSPAMメールのようだったので、取得元のメールサーバにThunderbirdのIMAPで接続して、メール削除してフォルダの「最適化」をやり、これでメールが削除できているはずなのだが、反応が鈍い。
Thunderbirdが応答しないので、しょうがないから、fetchmail を再度実行するも、亡霊のごとく、ログにはそのSPAMメールのFrom行が出てくる。
telnet で取得元の port 110 叩いて、POP3プロトコル手打ち。
RETR 1ってやると削除されてねえし orz
ThunderbirdでIMAPのexpungeが完全に実施されていなかったようだ。
で、DELE 1ってやったら再び応答しなくなる。
メールで顧客情報管理なんかやってるから、やたらとクソ重くてやってらんね。
で、そのメールを手動でフォルダに移動させて工程管理だから、紙を回してるのとやってる事は変わらないし、情報化とは程遠い。そもそも基幹システムがしっかりしてたら、客のメール回すなんて馬鹿げた事はやらなくても済む話。
ああ、イカン。トラブル対応でゲンナリして愚痴っぽくなってしまったな。
で、メール取得元サーバにログインして、ハングってるpop3dをkillして、一応、telnetのPOP3プロトコル手打ちで、メールが消えてるのを確認して、fetchmailを実行したら復旧した。
問題のメールは消してしまったが、転送設定で他のアカウントにもコピーが残るように冗長化されてるので、そのアカウントから発掘してソースをじっくり眺めてみた。
multipartのクソSPAMだが、そのpartの一部に、行頭がピリオドで始まっていた。
SMTPのDATAのお約束として、行頭ピリオド＋改行でデータ終了の意味となり、fetchmailはそれを取得する際に、それでメールは終わりと判断するので、取得失敗となるようだ。
しょうがないので、Cyurus IMAPdで、DB更新時に root のDBファイル作って書けなくなるのを復旧するログ監視プログラムにfetchmailエラー時にimapsyncで受信トレイをコピーしてコピー元削除するコマンドを組み込んだ。
fetchmailと違って、配送では無いので、メールの振り分けができないが、pop3詰まりになって、メール取得がストップするよりはいいだろう。
わしは新入社員の部門説明の時に「日々、無為に過ごしてはいけない」と言った。
日々、何も考えずに過ごしていたのでは、非常に薄っぺらい人間になってしまう。もう遅いかもしれんが（笑）。
今のままでは、温くて腕が段々落ちてきそうなので、自己啓発としてJavaを習得してみようと思う。ネットワーク技術＋データベース技術＋クロスプラットフォームの技術を磨いておけば、暫く食うには困らなそうだし 🙂
「恒産無くして恒心無し」には成るまいぞ。
あるプロジェクトで、ハード担当が全くハード選定をやらないので、わしはPCとlinuxを使って、ソフト実験環境を作ってしまっているのだが、時折、「こんなんできました」みたいなメールを送っている。
それについて、ハード担当が、メールで返事を返して来て、「ネットワークについてはよく分からないから教えて欲しい」などと言ってきた。
しかし、具体的に何が分からないのかも書いておらず、そもそも何が分からないのかすらさっぱり分からない。
わしのやってる事は、socketオープンして、サーバのapacheにコネクション張って、
GET /test.php?param=1234
みたいな文字列を送出して、apacheが応答して来た文字列をsscanf()で読み取ってるだけだ。
一言で言えば、「HTTPで通信しています」で終了。
別に秘密の独自プロトコルを使ってる訳でもないし、HTTPの仕様なんて全世界に公開されてるし、解説してある文献も腐るほどある。
そもそもこういうソフトウエアのアプリケーションレヴェルの話は、プロジェクト的には、ソフト担当のわしが握る事になるから、ハード担当が気にしたってしょうがない話だが、知りたがる理由がそもそも不明だ。
下衆の勘繰りで考えると、このネタを別の案件で使いたいのか？と思ったりするのだが、さすがにこの辺の話は、「スクリプトをパクって自分のホームページに組み込んだら、よく分からないけど何とかなった」というレヴェルの話じゃない。
強いて解決法を挙げると、
プログラミング言語Cとか、Linuxの本とか、マスタリングTCP/IPとか、そういう本を全部読んで理解した上で質問して来てくれという感じ。
もっとも、これだけの本を読んで理解できているなら、「HTTPで通信しています」で分かるはずだから、質問すらして来ないだろうけど。
あと、こういう事も書いてあった。
「また、自分のWEBサーバー上でデータベースMYSQL等の操作も、実験していますが、良く理解できていません」
知らんがな（´・ω・｀）
試用期間終了後も見直し無しだとよ
上司は、ボーナスで考慮して貰えるように働きかけるとか言ってたが、どうせ空手形だし、ボーナスと基本給じゃ全然違うし、職安の求人広告の最低賃金より安く買い叩かれた事は、一生忘れないよ 🙂
社内メールサーバに障害が起こっていたが、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
とかやると、落っことしたメールを再配送できる。
監視ツールでは、この再配送までを自動でやるようにしてはいるが、実際に障害が起こらないとうまく動くかは分からないんだなこれが（笑）
新入社員に部門紹介という事で狩り出された。
3/21に発足した部門で、 実働2週間ちょっとの実績ゼロの部門で一体何を語れというのやら…。
まあ、適当に握っておいたが、部門には２名しか居なくて、おまけに肩書きのある人が公式には存在しないという謎の組織だ。
組織というのは、責任者を立てて、そこへ権限委譲して、その上位の者は責任者を管理してピラミッド構造のヒエラルキーを構築するってのがセオリーだが、 責任者が明確になっておらず、指揮系統が明確ではないというのは、非常にやり辛い。
例えば、別部門から仕事の依頼などがあれば、常識で言えば、わしのような下っ端は「私の一存では決められませんので、上長の許可を得てください」と言うのが鉄則だ。
どこぞの新入社員教育だったかで、「たとえ社長が業務を命令したとしても、所属上長の許可無く仕事を受けてはいけません。必ず『上長を通してください』と言うようにしましょう。」と習った。
所謂、「頭越し」をしてはいけないという事だが、これは、通常、部門責任者が部下の業務遂行進捗管理をやっているから、部門責任者の知らぬ所で、部下が勝手に仕事を受けて、予定していた業務が計画通りに進まない等という事態が起こらないように、この鉄則は存在する。
しかし、今は「わしの上長は誰？」みたいな感じで、非常に落ち着かない状態だ。
それよりも、今月の20日で入社6ヶ月になるが、まだ仮採用の身分なのがなんだかなあって感じだな。
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を使うというのなら、何通も同じメールを相手に送信するという馬鹿げた現象が無くなる気がするが、どうせ、この一言を言ったところで、誰もやらないだろうし、やるとなると全てわしがやらされるハメになるから言わない(^^: