先々週、PCがウイルスまみれでなんとかしてくれとの話がきた。
PCの調子が悪い→業者を呼んだ→ウイルススキャンを実施したら４００以上ヒットした。→再度アンチウイルスソフトを使ったが全く減らない→業者が基盤室に泣き込んできた。
というわけである。基盤室でもインストールされているノートン・アンチウイルス・エンドポイントを使ったが同じ結果だ。
ということで、基盤室職員はこれ以上関わりたくなく、リストアしなさいとのご宣託。
それでは、ユーザが困る。リストアできないからである。
ということで、データのバックアップを取り、リストアすることを試みた。
なんと、データのコピーもできない。特にWindows とかのシステム関連フォルダにあるファイルのコピーがうまく行かない。書き換えられちゃってるからだろうな。コピーを実施すると、コピーできているようだが、最後の確認作業がなかなか終了できず、コイピー先にファイルが見えない。しょうがないから、デスクトップとマイドキュメント、Thunderbirdのファイルだけ外付けHDにコピー。これはできたようで、このHDを別のスタンドアローンのPCでスキャンしたがウイルスは発見できない。
ここで、工場出荷時にリストアをした。そんでWindwsのアップデートを繰り返し、アンチウイルスソフトをインストールし、Thunderbirdをダウンロードし、外付けのHDからデスクトップとマイドキュメントとThunderbirdのファイルを入れ替え、MSOfficeをインストールしておしまい。ここまでで、丸一日。アンチウイルスソフトを毎日、昼休みに動かすように設定しておいた。
再度、アンチウイルスソフトでスキャンしてウイルスがいないことを確認するように伝えたけど、大丈夫かな。
４００ヶもウイルスがいると、ファイルのコピーすらままならなくなる。検出を試みても削除、隔離ができない。すごいもんだ。
[後日談；１２月１２日]
このあと基盤室職員が面倒を見ようとしたら、また問題が生じたらしい。保存してまたもとに戻したThunderbird のメールには、ウイルスいっぱいのメールがあったらしい。これらのメールを開かなかったからよかったけど、どうやらウイルスメールを抱えたままだったようだ。IMAPを使っていたので、Mac のほうでアクセスし、迷惑メールを削除し、サーバからも除いておいて、Windows の方のThuderbirdを捨てて、再度起動して新しくし、アドレス帳等のみを保存してあった外付けHDからコピーし、サーバにたまっているメールをダウンロードしたとのことだ。ふむ。IMAPを使っているとこのような時はいい。大昔のメールも再度落とせる。なんと５万通くらいあって、そのうち３千通未満がまともなメールで、あとはすべて迷惑メールだったとのことだ。なんてことだ、迷惑メールを削除していないとは。信じられない。
Carbon Copy Cloner (CCC) のメール通知機能の日付が1970.1.1 になってしまう問題と、日本語のシステムではメールアドレスの日本語の部分のエンコードに問題があって、SMTPサーバが受付を拒否してしまうという問題は解決した。
Carbon Copy Cloner の Notification、とCarbon Copy Cloner の Notificationその２
日本語の部分のエンコードをうまく処理できなかったことに問題があったようだ。作者のDisucussionのページに投稿して、作者とやり取りして解決した。解決したバージョンは3.4.4-b2(489)でdiscussion のページの下の方にある。
１１月２１日に問題を投げかけ、解決したのは今日なので１２日かかったわけだ。一日おきくらいのやり取りだ。作者のMike （なんとこのサーバと同じ名前！！）との間には時差がある（多分、どこに住んでいるか知らん）し、お互いこの問題にかかりきりじゃないからね。こちらのテスト機は平日しか使えないからね（リモートでアクセスしテストすることもできるけどね）。作者は英語システムだから問題に気がつかなかったんだろう。日本語のエンコードの問題で、作者の環境とちがうからね。
というわけでdonation １５ドルしちゃった。早い応答が気に入ったからだ。円高だからもっと寄付してもよかったけどね。
このサーバもそうだが、デスクトップのMacintosh はすべてCarbon Copy Cloner (CCC) でもバックアップを別HDに取っている。
バージョン３あたりから、バックアップ終了時とかエラーがあったときメールで通知する機能が加わった。そこで設定したが、受け取ったメールの日付が
Date: ?, 11 11? 2011 02:06:01 +0900
となって、受け取るメールソフトでは文字化けのため、 (19)70年1月1日午前9時 と表示されてしまう。
Date: Thu, 11 Nov 2011 02:06:01 +0900
となるべきなのだ。
あっちの大学の普段使っているMac OSX10.6、 CCCのバージョンは3.4.3 ではスケジュールされたバックアップのレポートの日付に問題ないが、テストメールを出すと、文字化けで日付が正しく表示されない。
自宅サーバはスケジュールの結果のレポートの日付がだめだ。帰宅したらバージョンを確認してみよう。
ま、メールをフォルダに分類しているからいいか。
解決した。（１２月２日）
先日こけたと思われるRTX3000をラックから引き出し、本当にこけたのかをチェックしてみようと思う。
MacAirしか手元にないのでUSB-RS232C変換アダプタとして、これは手元にあったやつで、SANWA USB-CVRS9 を使うことにする。
Mac用のドライバがないのでuc232a_v2.1mac.zipをATENからダウンロードしインストールした。ターミナルを起動し、
$ ls /dev/tty.*
としたら、
/dev/tty.Bluetooth-Modem /dev/tty.Bluetooth-PDA-Sync /dev/tty.UC-232AC
と返ってきて変換機は認識されているのがわかる。しかし、
$ screen /dev/tty.UC-232AC
とやってもなんの反応もない。
RS232Cケーブルがクロスでないといけないのではと、思いクロスケーブルを探し出し再度挑戦してもなんもいってこない。
む、とおもいきやリターンキーを押したら
Password:
と聞いてきた。やはりRC232Cケーブルは、この変換機を使ってもクロスでないとだめなようだ。そりゃそうだろな。
screenを終了するには、Ctrlキーを押しながらAを押して、そのままCtrlキーを離さずに¥を押す。
＞プロンプトのあとにpingで設定してあったルータの上流のip address を入力して送ったら、ちゃんと応答している。ホントにこけたんだろうか？
１０月の第３週末は大学の電源の定期点検のため停電だ。毎年、苦労する。なんだか毎回うまくすべてが再起動できないんだよね。
今年は、サーバ本体を学情に移動し、この電源は学情の方で管理されるから問題はないはず…..ま、毎年問題ないはず、が問題が生じるんだよね。
今回は、サーバ本体が学情にあるから、こちらで面倒をみるのはローカルな設備だけ。サーバ本体は電源が維持されるし、基幹のネットワークも維持されるはず。したがってVLANを作っている都合上、電算機室のスイッチの電源さえ確保できるのだったら、学外からメールの送受信はできるはず。ということで、土曜日の朝の停電時に仮説電源から電源をひっぱってきて、電算機室のスイッチに電源を供給した。学外からアクセスしてメールの送受信できた。夕方５時過ぎに電源が回復するので、回復したらスイッチの電源を本来の電源にもどした。土曜日、夜医学内からネットワークが利用可能になった。日曜日、朝、再び停電になるので、また仮設電源から電源を供給した。で、夕方５時過ぎ、電源が回復したとき、本来の電源に戻した。これで、土曜日と日曜日の日中は学外からのみアクセス可能、土曜の夜から日曜の朝は通常通り医学内から利用可能、日曜日午後５時過ぎから、通常通り利用可能となった。日曜日、夕方、電源を本来の供給源に接続し、mikeのネットワークが問題ないことを確認して帰宅。医学内のネットワークはチェックしなかった。問題ないだろということだからな。あとから、考えると、かりにこのときチェックしても問題は発見されなかった。
月曜日、朝、きて、mikeの配下のネットワークが動くので、のんびりと、あっちの大学の実習書をつくっていたら、基盤室職員がきて、ネットがつながらないという。うぅぅぅぅ。
調べたら、学情が設置したスイッチがいまいち動作確認がとれていないとのこと。そのせいかも…..学情の職員がきて、設定を直して、スイッチ類は問題なくなった。しかし、医学内からネットに接続できない状況は変わらない。ip address が取得できないのだ。
というわけApresiaがこけたか、ルータ(RTX3000）がこけたかだ。ある利用者から、日曜日の朝４時半まで利用できていたとの連絡があった。したがって、停電からの回復操作は正常に行われ、ネットは動いていたことになる。朝４時半から７時半までの３時間になにかが起こったことになる。
ここから先は、わからないので、本年度から委託した業者の出番だ。来てもらって調べたが、なかなか原因がわからない。ping を送るのだが、その返信時間が一定でない。どっかのサブネットが過大なパケットを送り出している可能性がある。昔、電源が回復したとき、サージでパソコンのNICが壊れ、めちゃくちゃなパケットを出し続けたことがあって、これがトラブルの原因だったことがあった。
というわけで、末端のネットワーク機器またはパソコンがめちゃくちゃにパケットを飛ばしているのではないかと疑った。サブネットのケーブルを抜き差ししたが、状況が変わるようで変わらない。ルータApresiaのスイッチを再起動するとほんの数分間だけ問題なくなる。しかし、数分経つと機能しなくなる。ウイルス感染したPCはネットが遮断されると動作をやめ、しばらくおとなしいが、ネットの接続が確認されると、パケットを出すやつがいる。古いタイプのウイルスね。今のは、ユーザがわからないようにパケットをだすのだ。だから末端のPCまたはネットワーク機器がおかしいのではと疑ったのが敗因だった。時間ばかりかかり、どのサブネットが接続すると、ネットが落ちるのか、わからない。
業者の人がようやく、ルータにコマンドを送るとルータがフリーズすることを発見。ルータ予備機に交換。しかし改善されない。予備機のアップデートができてなかった。アップデートしようやく解決。
ルータがこけたのだ。ルータがこけた原因は不明。停電は直接の原因ではなさそうだ。電源をもとに戻して８時間以上正常に動作したから。しかし、負荷が少なかったので動作していたのかもしれない。
というわけで、こけたルータは廃棄にし、予備機で運用。新しいルータを購入することとした。
あー、くたびれた。午後２時半までかかった。
追記
翌日、寝過ごした。あっちの大学へ行くのが遅くなった。くたびれていたからな。
au とか docomo が許していた／いるメアドで「@の前の文字列にドットが連続してあってはいけない、@の直前にドットがあってはならない」（SHOULD NOT）というRFC規則に引っかかるメアドを許している件である。auもdocomoも新規に作るメアドではRFCに準拠したものでないと許可しないようになったが、以前に作成したメアドはそのまま使っていいことになっている。
多くのパソコンで使うメールソフトはRFC規則に沿っていないメアドをはじくようになっているので、途中のSMTPサーバや最終的に受信するauとかdocomo のサーバが受け付けていても、メールを送ることができない。メールソフトはアドレスの入力間違いとしてはじいてしまうのだ。
しかし、RFC2821の2.3.10 では@前の文字列であるloca-part の意味の解釈および割り当ては、そのアドレスのドメイン部で指定されているホストによってのみ行われなければならない(MUST)。とあるのでau とかdocomoの勝手であってなんら問題はないはずである。
RFCのどこに、上記のような規則が書いてあるのか、調べてみるが、よくわからない。
結論からいうとメールアドレスの書式というページに書いてあることのようだ。
このページの最後に個人的な雑感というのがあって、この感想に賛成だ。RFCの文書のどこにこのような規則があるのかよくわからない。
メールソフトで、この規則にのっとっていないメアドを ” ” でくくって送ると届くはず。” ”内は文字列として文法上の記号等があっても無視できるからである。
事実、Thunderbird でこのようなメアドから来たメールのヘッダーを見ると、
From: “xxxxxx..yyyyy”@ezweb.ne.jp とFrom欄を解釈し、 ” ” でくくっていて、単純に返信すると
To: xxxxxx..yyyyy@ezweb.ne.jp
に送信している。問題なく送受信できている。Outlook なんかはだめなようだ。
mailman もだめなようで、このようなメアドを登録すると、さきに書いたように届かない。
mailman では登録すらできない。” “でくくると登録ができるが、どうやらとどかないようだ。送信エラーもこない。送られたのだがau とか docomo が捨てちゃうのだろうか？届かないと学生は言うがとどいているのかもしれない。もし捨てちゃうようだったらauやdocomoはものすごくたちが悪いことになる。
パソコンからThunderbirdで
“xxxxxx..yyyyy”@ezweb.ne.jp あるいは
xxxxxx..yyyyy@ezweb.ne.jp で送付すると届く。ということはauは” “をちゃんと解釈してくれているようだ。
しかしmailmanからだと
“xxxxxx..yyyyy”@ezweb.ne.jp は登録できるが、届かない。
xxxxxx..yyyyy@ezweb.ne.jp は登録ができない。
mailmanの設定かな？ ちがったPostfix のせいだ。ためしたのはハイフンで始まるメアドだったからだ。
http://www.postfix-jp.info/trans-2.3/jhtml/postconf.5.html#allow_min_user によると；
allow_min_user (デフォルト: no)
受信者アドレスが最初の文字として `-‘ を持つことを許可します。コマンドラインでEメールアドレスを渡すソフトウェアでの事故を避けるため、デフォルトではこれを認めません。そのようなソフトウェアは悪意のあるアドレスと正しいコマンドラインオプションを区別できないでしょう。これは “–” オプションターミネータをコマンドラインに入れることで防げますが、一貫して全体に強制するのは困難です。
で、デフォルトの設定だからだ。
mike (MacOSX)の場合、しかしながら
/etc/postfix/main.cf にallow_min_user の記述がない。
au とか docomo は携帯メールアドレスのユーザ名の文字列に . (period/ドット）を連続してもいいとか、＠の前につけてもいいとかにしてあった。最近は禁じているようだが。
しかし、以前からのユーザのユーザ名がRFCの規則に接触していてもそのまま許している。こういうアカウントに対してはメールが送付できない。
管理者が担当している卒研の学生への連絡を行うため、メーリングリストを立ち上げた。学生にメールアドレスをよこせといったら、まず送ってきたアドレスはすべて携帯のメアド。一括して登録してしまった。
メールを送ってから、特定の学生にとどかないことが判明した。そのメアドを見たら . が２つ連続している。使えないのだからメーリングリストから削除しようと思って、mailman の管理画面から削除しようとしたが、削除できない。
この退会のチェックボックスをチェックして変更を送信しても消去されないのだ。何故かはわからん。メールでリストの一覧を取得しても残っている。ちゃんとしたアドレスの場合、このチェックボックスで削除できる。
あまりつかわないのだが、リストに登録しているメアドを得るのは；
[メーリングリスト名]-request@example.com 宛に、本文に who [管理パスワード] だけ記入して（署名欄は削除して）送付すればいい
リストに登録してあるメールアドレスとメモ欄に記入した情報が書いたメールが返ってくる。ここに記載されたままなのだ。
悩んでいたのだ。
まとめて退会 というのがあるのに気がついた。まとめなくても１つだけでもできるかな？とおもって退会メアドのリストに１行だけ、該当アドレスを記入して、変更を送信したら消えてくれた。へんなの。
しかし、au とか docomo は規則に従わないメアドは使えないようにしてくれよな。携帯のメールを使うのは若者で、めちゃめちゃなアドレスを使うんだから。happyponpon とかchunkなんちゃら、fight_the_future とか pride_before_crushとかかふざけた名前が多いからな。
医学のサーバのWebメールであるsquirrel mail で、届いたメールに対して転送あるいは返信を選択すると引用部分が文字化けする。
SquirrelMail バージョン 1.4.21だ。どうやら文字コードが明示されていないときに生じ易い。つまりサーバからのレポートとかで生じ易いようだが、一般のメールでも起こるらしい。しつけの悪いメールソフトからなのだろうか。
例えばNASのレポートのような場合だ。
############
バックアップログ報告
バックアップタスク1を開始しました。
[TeraStation PRO情報]
TeraStation PRO名称: T-STATION21 (TS-HTGL/R5)
時刻: 2011/08/25 03:00:02
設定画面: http://192.168.100.5/
############
というメールに返信しようとすると
############
> ????????????????????
> ??????????????????1????????????????
> ????????????????: ????????
> [TeraStation PRO????]
> TeraStation PRO????: T-STATION21 (TS-HTGL/R5)
> ????: 2011/08/25 03:01:15
> ????????: http://192.168.100.5/
############
となるわけだ。
squirrelmailの設定オプションに
$lossy_encoding = true;
があって、マニュアルによると
SquirrelMail supports the $lossy_encoding option since 1.4.4 and 1.5.1,
which allows charset conversions when the output charset does not
support all symbols used in the original email charset.
とあり、これを読む限りはtrueにした方がよさそうに見えるのが、ど
うも日本語文字コード間の変換と相性が悪いようで、こちらを”false”にすると文字化けが解消する。
と、本年度から委託した業者から連絡があった。
mike (MacOSXServer)の場合
/etc/squirrelmail/config に
config.php があってこの２８行目に
$lossy_encoding = false;
となっている。デフォルトでfalseになっていた。なぜkibanではtrue になっていたのかはわからない。
It's alright, I say It's OK. Listen to what I say.
保存した場所からsignatureswitch1_6_9.xpiファイルを選択し開くをクリックする。
この図はWindowsの場合だが、MacOSXでも同様のウインドウが出てくるので、今すぐインストール をクリックする。
以下、基本的な設定はWin もMac も同じなので、図はWin の場合だけを示す。オプションの特定の宛先に適用するのはmacではできないのかもしれない。
新規 ボタンをクリックする。
