spam-その39

スパムメールの率とm の除去率(件名に***JUNK MAIL*** が付加されたもの)は以下のグラフです。横軸は計測順で、平日は1日に1回、週末は土日のメールを1回としています。平日に必ずカウントしているわけではないので、正確ではありません。

20070928l.gif

これをみてもわかるように9月6日頃から、なぜか除去率が下がり(4〜5割くらい)、昨日は7割5分の成績でした。理由はわかりません。通算打率は6割位です。あまり当初から改善されていません。spamメールを学習させているんですけどね。:cry:

停電ー対処できたか?

9月1日(土)午前5時−9時まで、8月20日のトランスがぶっとんだための全学停電の修理のため、停電である。朝5時だぜ!!:evil:

ファイルサーバであるbは前日に落とし、月曜日に起動しても問題ない。使うのが生理の人間だけだからな。分散サテライトも前日に落として月曜日起動で問題ないでしょ。利用者は学群学生だし、まだ夏休みだし。これらは担当者が対応するからいいでしょ。

k, m, t , QR はリモートで午前5時直前にシャットダウンすればいいが、セキュリティドアのサーバは、当然ながらインターネットに接続していないのでリモートで落とすことはできない。しかし、このサーバのUPSは1時間以上持つのがわかっているから、朝5時前に起きて、サーバをリモートでシャットダウンして、一眠りして、朝6時ころ大学に出てきてセキュリティドアのサーバを落として、UPS の電源をきって... また9時頃、大学に出てきて、UPSの起動とサーバの起動をすればいい...なんて甘い考えがいけなかった。

目がさめたのが朝6時直前。やば!! この時点では全学停電だからリモートでシャットダウンできない。

大学にきたのが6時10分。

m はUPS で動いていたが、t のUPSはもたなかった。バッテリーがそろそろアウトだからな。k とQR は,別の管理者がやることになっていいたから落ちていたんだろう。 確認する暇もない。

あわてて、セキュリティドアのサーバをシャットダウン。m をシャットダウン 。セキュリティドアのサーバとm, t, QR, b のUPSを落とす。

tだけが、異常修了だったわけで、HD がこけていないことを祈るだけ。でも はproxy の機能だけだから、こけちゃっても再構築は簡単だし、その間、生理グループのネットへの接続は可能だからなんとかなるだろ。

いったん自宅へ。コンビニに寄って朝食を買って、自宅で朝飯食べて、9時に再度大学に来て、全てのUPSを起動。セキュリティドアのサーバを起動。t, m, QR, bを起動。k の担当者はさらに遅れて登場。k 起動。

問題のtama は起動しただけではproxy が動いてくれなかったので、実験室から リモートで再起動。動いた。いがった。:wink:

セキュリティドアのサーバがドア開閉情報を記録しているのを確認した。9時頃沢山の大学院学生が来ている。停電時、医学の建物内では、冷凍庫のアラームがあちこち鳴っていた。 冷凍庫がちゃんと動いていることを確認しないとヤバい研究室が一杯あるからね。下っ端が来る事になっていたんだろう。

m, t, k がちゃんと動作している事を確認。 QRの確認は月曜日だな。利用者だけどID, パスワード忘れたし、利用できる環境にないし。で、月曜日朝、動作確認した。

めでたし、めでたし。が、....月曜日の朝、動いていないセグメントがあった。ユーザからのクレームだ。て、クレームがないとわからん。いちいちすべてのセグメントが動作しているかを確認できない。

原因はセグメントを仕切っているスイッチが起動時に設定をちゃんと読まなかったらしい。2度再起動して問題解決。:smile:

このスイッチは学情が管理している。これはまずいかも。迅速な対応ができなくなるかもしれない。ただのスイッチングハブで一時的に置換すればいいのだろうか。管理者なのに実務管理者に任せているので、いまいち理解していない、まずいな。 :sad: