現在のmはPowerMacG4 (PCI Graphics) 400MHz 512MBRAM という前時代的遺物で動いているのだ。
HD２を２台内臓させ、毎日１回ミラーしている。起動HDがこけたらミラー先のHDから起動させれば最大２４時間前のデータを失うが、こけたのが判明してmの傍に立ったら２０分以内に回復できる。こけたのが判明してからmの傍にたどり着く時間は管理者がどこにいるかで変化する。
影武者として全く同一スペックのtamaを用意してあり、mike本体がこけたらmのHDをtamaに移動させれば１時間以内に回復できる。t を影武者としてそのままなにもせずに置いておくのは意味がないからtはproxyサーバとしてうごかしている。
これが今現在のシステムである。
PowerMacG5  2GHz 512MBRAM を２台手に入れた。したがって今まで同様の運用ができる。内臓HDが１ヶしかないから最低同じ容量のHDが２つ必要だ。
問題は現在のファイルをどうやって移動するかだ。現在のHDはATTなのでそのままつかえない。
使っているのは２０GBもない。新しく手に入れたG５の内臓のHDに現在のシステムをそのままコピーして、起動できたらうれしいな。G５のデスクトップはFirewireで外付けHDとして動作するのだろう。そうだとしたら最も簡単だ。
そうでないと、どのファイルを移行していいのかわからん。再構築しないといけないかもしれない。大変な作業になる。
取りあえずはtをコピーして．．．
できたできた。
新しいG５のHDをOSXサーバインストールディスクで起動し、rootパスワードを変更してから、ディスクユーティリティで初期化し、firewire taraget disk として起動し（t キーを押しながら起動する）、firewire でtに接続し外付けHDとして認識させ、SilverKeeper で丸ごとコピーし、再起動させた。再起動は無事できて、ip address などもtのままコピーされたことを確認した。
したがって、この方法で　移行できるようだ。mike のネットを切って、新しいメールが着信しないようにして、コピーを開始し、入れ替えてネットに接続すればいい。コピーにかかる時間だけ、mは落ちることになる。３時間くらいかな。このへんがFreeBSD（UNIX）のいいところだ。機種を選ばない。Windows だとこうはいかないだろう。
というわけで、SATA 500 GB HD ４台（m と tに２台ずつ）注文。RAMも２GBにするように注文。合計７万円。

m からumin.ac.jp に送信されるメールは届かない。umin.ac.jp はspam メールを防ぐためにenvelope のfrom 欄のドメインを読み、大学中央 のsmtpサーバにそんなドメインがあるか？と尋ねるのだ。で大学のsmtpサーバはそんなドメインはないと答える。当然だ。登録していないからね。m はk に信用されているので、kがリレーしてくれる。それだけでいいはずである。umin.ac.jp がfrom なんかを読んで処理するからいけない。from 欄なんか自由に書き換えられるのでspamメール対策になんかならないぞ。
umin.ac.jp だけだから対策をどうするかは迷っている。大学に届ければそれでいいけどね。別にこそこそ運用しているわけではないからね。
医学のネットワーク内でもk以外にもうひとつサーバがあると、トラブルの原因を探るのに便利だからね。

メーリングリストが遅い。前からわかっていたが、いよいよどうしようもないので、調べたら、どうもメーリングリストでは転送毎にウイルス・チェックしているみたい。だからリスト登録者が多いとやたら時間がかる。１通３０秒くらいかかる。そのときmが何かサービスしているともっとかかる。循環グループでは登録者が１００名を越えるので１時間もかかることがあった。Spamメールのチェックには時間はさほどかからない。
メール・ウイルス・チェックを止めた。これでmで消費する時間はかなり小さくなった。
X棟からメーリングリストに投稿すると、４０弱登録者数のメーリングリストでは、m で消費する時間はこれまで２−４分位、さらにkaをsmtpサーバに指定しているとkaで３０秒も消費するので、すぐに配信されず、失敗だと思って再投稿する奴がいる。
これでmで消費する時間は十数秒以内なのでX棟から投稿すると１分以内に配信されるであろう。
これまでmでひっかかったウイルスは数通なので、ユーザにちゃんとアンチウイルスソフトがあれば、いいでしょ。 危険（安全）ー便利（不便）　とはつねにせめぎ合いなのです。

１１月２７日の打率。８０００件以上登録したのに打率は当初からかわらん。何故だ。

２７日朝７時から、迷惑メールのデータベース更新をやめてみる。データベースはこれで自分が作ったものだけになる。ひょっとして、これまで蓄積したspam mail はデータベースをどっかのサイトに更新に行く度にちゃらになってしまったのではないだろうか？

学情からの連絡で、本日朝９時３０分頃、学内のあるサーバがDDoS*1と思われる攻撃を受け１０分間学外と通信できない状態になったそうな。学外から学内サーバがDoS攻撃を受けると、学情のところでトラフィックが増えるからだな。先月末のkiban が落ちたのは少なくとも学外からのDoS攻撃ではないようだ。
*1:DDoS攻撃（Distributed Denial of Service attack）：セキュリティの甘い多数(分散；distributed）のパソコンを踏み台にして、特定のサーバ対して正常な要求を同時に行うことでサーバのリソース（メモリ）を食いつぶし、サーバを落とす攻撃。 サーバに対する正当な要求と区別しにくいため防御がむずかしい。

１０月２６日から１１月１日にかけてのkの不調の理由：
DNS（Domain Name Ssystem）サービス*1がどうやら過負荷だったようだ。何故、過負荷だったかの理由はわからない。
のDNSサービスは医学外部からの問い合わせ、医学内からの問い合わせに応答する。さらにサーバ自体の内部でメール等を処理するための問い合わせにも答える。これまで過負荷で落ちた事がなかったから何故このときだけ過負荷になったのかはわからない。医学外部からDoS攻撃*2があったのかもしれないが、証拠もないのでわからない。Yahoo とか官庁のサーバが攻撃を受け、ダウンしたた事はあるけど、kのような中規模サーバにこのような攻撃をするとしたら、管理者に個人的な恨みのある学内者か．．．
というわけで現在はDNSサービスを別のサーバとで分散処理して賄っている。これで将来とも問題ないかどうかはわからない。
*1 DNS:ネットワーク機器の通信はIPアドレスを使って送信者、受信者を決めて行われる。しかしながら、IPアドレスは数字の羅列であり、ネットワーク環境が異なれば変わってしまうし、ユーザは覚えきれない。そこでこれに代るDomain Name System が考案され、現在はこれがどのようなネットワークでも使われている。このサービスはkというサーバのドメン名を123.123.123.123 というIPアドレスに変換し通信を可能にするものである。逆にIPアドレスからドメイン名を教えることも行う。このシステムあるいはサービスが止まるとネットワーク通信ができなくなる。
*2DoS攻撃（Denial of Service Attack）サーバの本来の業務に過負荷を与えてサーバの機能障害を生じさせるような攻撃。大量のサービスの要求を同時に行うためには多くのパソコンが必要である。そうでないとサービスをする側は、特定の機器からの要求を受けないように防御できるからである。そのため、攻撃者は、セキュリティの甘いサーバや多数の個人のパソコンにウイルスソフトをインストールさせ（踏み台にする）、特定のサーバに日時を決めて一斉にアクセスさせる。ウイルスに感染した個人のパソコンは送信量が少ししかないので、ユーザは気がつかない。サーバ側からみると、さまざまなパソコンあるいはサーバがアクセスしてきたように見え、その要求は正当なものと区別がつかないから処理せざるを得なく、サーバの資源（メモリ）を食いつぶしてサーバがダウンしてしまう。

２７日土曜日夜８時頃、自宅で一杯飲んでいると、大学の某教授から電話で医学のサーバがこけたと言ってきた。で、自宅から確認すると、kiban がこけていた。mikeちゃんは問題ない。kiban の再起動が必要だ。
土曜日の夜も働いている某教授も偉いというかworkaholicだけど、困っているのはわかるけど、どうしようもない。こっちはもう出来上がっちゃっているからな。技術責任者はバングラディッシュとかに出張で、メールも届かないとこにいるみたいだし．．．
というわけで、日曜早朝５時半に大学に来て、kiban再起動。動いている。どうもkiban が先日の停電以来不安定だ。

これまで　ため息ばかりブログにきたspam comments は２１０ヶ。そのうち１８６ヶは１０月に来ている。すべてAkismet でブロックされているけど、なんでだ。どっかに登録されちゃったんだな。

このサーバちゃんのspam 除去率を久々にアップします。

９月末に何故か打率が落ち、１０初旬に回復しました。昨日の打率は.600 で、管理者が使っているThunderbirdと重ね合わすと打率.889 となりGmail にははるかに及びませんがいいところに行きます。

一昨日の日曜日朝（２１日）にはじまったネットワーク障害の原因は、まだ中央からレポートがないのでわからない。大学が回復したあと、部局は延々と回復しなかった。
結局、部局の場合は基幹ネットから部局のサブネットの間の光ケーブル接続に問題があったためである。光ケーブルは１本が１Gbpsで、これを２本使って帯域を２Gbpsとして運用している。つまり負荷分散で見かけ上のスピードを上げているのだ。この分散装置の動作不良で、同じネットワークにある m, e などのサーバは問題がなく、k だけがおかしいという症状になったのだ。何故かはわからん。Proxy server である t ちゃんは k のDNSに依存しているので t も動かないということになったのだ。
一部から、部局のネットワークは障害が多すぎるとのクレームがあった。そうだろうか？
現在のシステムになった平成１６年１月から、予告のあったネットワーク器機交換や点検のための停電などの場合を除いたネット全体が事故で落ちたケースを拾ってみた。研究室内とかセグメント内で終止しているローカルな事故は含まない。 メール送受信以外の、一部のWebページが見えないなどのサービスの一部が出来なかった場合も除く。
平成１６年１１月８日早朝　２時間　全学基幹器機の障害
平成１６年１１月１ ０日昼頃　３０分　全学基幹器機の障害
平成１７年１月２４日朝　 ３時間　全学基幹器機動作不良
平成１７年１月２８日昼　不明　部局外の末端器機の故障・ウイルス？　接続しにくくなった
平成１７年５月２日深夜から早朝　９時間　全学基幹器機の故障
平成１７年９月 １日朝　１時間　局部DHCPサーバ電源故障
平成１７年１０月１６日　不明　電源定期点検後、全学基幹器機一部不調
平成１８年 ５月１６-１７日　断続　局部DHCPサーバ不調
平成１８年１０月１６日夕方　２０分　全学基幹器機故障
平成１９年１月１５日―１６日　断続　局部DHCPサーバ故障
平成１９年８月２０日　３０分　全学過負荷による停電事故
平成１９年１０月２１日―２２日　全学基幹器機故障
こうやって見ると、局部情報基盤室管理下の器機が原因なのは年１回あるな。DHCPサーバが原因だ。担当者がDHCPがいやだというのもわかるな。
この他に、予告があるものの、ネットワーク器機の交換・リセットとかが、部局、全学基幹部、SINETで短時間だけどあることと、研究室内あるいは特定のセグメント内だけのトラブルとかがあるので、どれをとってもユーザはネットが使えないことに変わりがないから、部局はネットが安定していないとかいうことになるんだろうな。