サーバーいろいろいじりました

結局,RAIDはLevel 1(以下”RAID 1″)に戻しました.最大の理由は,GCCやGLibcといった,根幹に関わるソフトのupgradeをしたかったからです.RAID 1にしておけば,GLibcのupgradeをする前に,片方のarrayを外してブートさせて,片肺飛行にして,その状態でupgradeをして,もし不具合が生じたら,外しておいた方のarrayからbootさせれば元に戻せます.これ以上の簡単なsnapshotはありません.

HDD/SSDに余分があれば,外したHDD/SSDをPCから物理的に外して保存し,代わりのHDD/SSDをRAID 1アレーにすればよいです.また次の大手術の時に交換させれば良いです.

で,GCCを5.2に,GLibcは2.22にしました.世の中では,GCCは既に6.1に,GLibcも2.23となっているようですが,Slackware Currentでは,ここまでのようです.

たしか,このGLibcにすれば,FileZillaのインストール条件となるなんかのライブラリーをbuildできたと思います

こんな調子で,しばらく使いつづけようかと思います.

あと,KDE 5を何とかインストールできないかなぁと考えています.

この件は,全くの勘違い.

Kernel 4.2〜4.6の遅さは異常

たぶん,KernelのMLみてればわかるんでしょうけど^^;

4.2で,SSDのサポートが大幅に見直されて,TRIMが危険なドライブをブラックリスト化したというのは知っていますが,ブラックリストに入ってないと思われるSSDについても,4.1.xまでと比べて,ファイルの書き込み速度が異常に遅いです.

ここのところ,RAIDの組み替えや,バックアップ方法を模索していて,rsyncやcpioを頻繁に使い,数百GB規模のファイルのコピーをしています.どうも,お行儀よくIOライブラリを経由して書き込む,のが特別遅いようです.

例えば,新しく組み替えたRAIDのドライブに古いドライブから300GBほどのファイルのコピーを実施すると,4.1.xまでは30分程度で済むのですが,4.2〜4.6では,2日くらいかかります.

4.6に期待したのですがたいして速くなりませんでした.

解らないのは,1TBのSSDをアレーとしたRAIDの再構築(つまり,冗長ディスクに1TB全部書き込む)のは,従前どおり70分くらいで済みます.

GLibcを更新しないといけないとかなのかなぁ.かつて経験したことがありませんが,今回に限っては,Kernelだけ新しくしてもだめ,ということなのでしょうか.

しょうがないので,当分4.1.xにとどまります.さいわい,4.1.xはLongtermとなっています.

いや,分かんないだろう^^;
書き込み先が,SSDの場合.

mdstatをLogWatchで

Software RAIDに限らず,RAIDを動かしていて一番かんじんなのは,冗長diskが故障して,冗長性がなくなったことを遅滞なく知る,ということですね.そのためには,1日1回

cat /proc/mdstat

をすれば普通は十分でしょう.

LogWatchを動かしている人は,そのレポートの中に,/proc/mdstatの内容をそのまま取り込んでくれれば楽だと思うでしょう.

ということでやってみました.結果的にはすごく簡単なことなんですが,ネット検索では,なかなかズバリというものが見つかりませんでしたので,たまには社会奉仕と言うことで,過不足なく公開します.

まず,LogWatchが動いていることが前提です.

で,設定ファイルを作るんですが,LogWatchのドキュメント類をザッと読めばわかりますが,/usr/share/logwatch以下に新規に書いたり,書き直すのは,推奨されていません./etc/logwatchに書きます.

読み込むログはありませんので, /etc/logwatch/conf/services/mdstat.conf は,

Title = "mdstat"
LogFile = NONE

となります.そして, /etc/logwatch/scripts/services/mdstat は,

#!/bin/bash
cat /proc/mdstat

となります.このファイルは,実行可能にしておきます.

これで,あとは,次にLogWatchのレポートが来るのを待つだけです.

古いメールの回復

条件がいろいろ違う

発掘した場所,元の時代などによっていろいろメールファイルの形態(ヘッダーに含まれる情報や型式,文字コード等)が違いますので,なかなか一筋縄ではいきません.

一応,昔の発掘したメールファイルの回復方法を書いときます.最終的には手作業で,メールヘッダー部分を修正する必要があることが多いです.

取り出して一通ずつ切り分ける

まず,何とかして取り出して,一通ずつに切り分けます.どこからもってくるかによって全部つながっていたり,個別に分かれていたりしますね

メールが数百とかある場合は,Perlスクリプトなどで処理するのが現実的ですね.

文字コードをUTF-8に整える

文字コード変換が必要な場合,扱うOSでネイティブな文字コードに変換してしまうのが楽です.わたしの場合は,MacとLinux + KDEが主なので,迷わずUTF-8です.

nkfを使うか,Kateなどの高機能エディターでUTF-8にします.数が多い場合は,bashでnkfを連続で回すのが良いでしょうね.

ヘッダーを整える

文字コードを変換した場合,ヘッダーの当該部分を,

Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: 8bit

にします.数が多ければsedを使うのがよいでしょう.

なお,比較的新しいメールについては,ヘッダー内のタイトル(Subject)はMIME化されていて,また,本文の文字コードと,ヘッダーの上記部分の整合性もいいので,文字コード変更(とそれに伴うヘッダー修正)は行わない方が良いです.

ヘッダーの修正

文字コード以外のヘッダーの修正が必要なことが多いです.

一番引っかかる(IMAPクライアントのヘッダー解析でエラーになってしまう)のが,

>From だれそれ

というヘッダーです.これは,ざっくり削除しました.

sed -i '/^>From /d' *

(Mac OS X付属のsedは,GNU sedではないようで,上記の方法はNGです.)

ただし,手持ちの古いファイルの一部は,このヘッダーのみに日時が含まれている(「だれそれ」の後に付いている)ので,これをDate:行に書き換える必要がありました.

できたファイルをThunderbirdで読み込む

できたファイルの拡張子は,”eml”にします.

IMAPのサーバーでも良いし,ローカルでも良いので空のフォルダーを,Thunderbirdで作ります.そこへ(Thunderbirdへ),整えたemlファイルをdrag & dropします.

確認して必要ならば修正

読み込んだメールの日時やタイトル,本文を確認して,うまくいってなければ個別に文字コードやヘッダーを修正して再度読み込ませます.

Thunderbirdが依然としてエラーを出すヘッダーのあるemlについては,emlをuploadした直後に,downloadに失敗します(uploadはノーチェックのようです)ので,小分けにして読み込ませるのが良いようです.

制限

このようにして,Thunderbirdでは,エラーなく復活できたメールを正常に相手,日時,タイトルなどをリスト表示できて,本文の表示もできます.

いっぽうで,このようにThunderbirdからIMAPサーバーにuploadしたメールについて,Mac OS Xの”Mail”や,iPhoneなどのiOSの「メール」でアクセスすると,リストには日時が正常に表示されず,Thunderbirdでemlをuploadした日時が表示されるものがあります.また,リストには「本文がありません」と表示されるものもあります.

この,Mac OS Xと,iOSのMailでのリスト表示の不具合はなんとも不可思議で,同じように処理したつもりでも,リストに日時が正常に表示されるものと,uploadの日時になってしまうものがあります.両者のヘッダーを穴の開くほど眺めましたが,違いが分かりませんでした.

内容表示は正常なのでよしとします.時間順が重要な場合は,Thunderbirdで読むことにします.

効能^^;

この方法でかなり多くのメールを復活させました.2000年前後が主ですが,1994年頃のものもあります.

この人とは,この頃こういう交流をしていたのだ,などと懐古しています^^;

亡くなった先輩とのメールなど読み返すと,いろいろ思うところがあります.仲の良い先輩で,ある意味友だち付き合いしていました.あんまり失礼な書きぶりがなくてほっとしています.

Eudoraのメールファイル,UW-IMAPサーバーのユーザーディレクトリー内のファイルは,一続きでした.