ただのにっき

■ procmail

IMAPを使っているのをいいことに(あんまし関係ないか)、メールはNetscapeに振り分けさせたあと、ほったらかし。さすがにメールボックスを開くのに時間がかかるようになったなー、と思ったら、多いもので3000〜4000通もたまっている。Maildir形式で保存しているので、この量になるとlsすらできなくなる(笑)。やばいって。やっぱ、日常的に使うメールボックスと、アーカイブ用のディレクトリを一緒にするのは無理があったということで、これをきちんとわけることに。

多いのはもっぱらメーリングリストのファイルなので、100通づつにわけることにしよう。通し番号の100番台を境目にしてディレクトリを掘り、1メール1ファイルで整理する。これはいずれNamazuで検索できるようにするため。問題はメールを「どうやって」入手して、「どのように」振り分けるか。

まず入手先は、受信と同時、というのが一番楽だろう。~/.qmailにはフィルタを書けるから、Maildirに入れるのと同時に、何らかの振り分け用プログラムに渡せばいい。ではそのプログラムだが。通し番号で分ける前に、メーリングリストの種別で分けなければならない。通し番号単位の振り分けはRubyで自作するとして、パターンによる振り分けはprocmail様にお任せするのがスジだよね。というわけで、メールの振り分け先を~/var/mailにするとして、~/var/mail/.procmailrcを作る。~/.qmailはこんな感じ:

./Maildir/
|procmail ./var/mail/.procmailrc

■ ~/.procmailrcにしなかったのは、もっと賢いメーラーが手に入ったら、アーカイブ以外のメールもprocmailで振り分け用と考えているためである。まぁ、同じ用途なんだから、共通になるかも知れないけど、それは先の話。

■ qmail的にはprelineを通すのがスジらしいけど、別になくてもいい。あとは、標準入力から受けとった1通のメールを、Subjectの通し番号を元に適切なディレクトリに書き込むスクリプトを書くだけ。まぁ、簡単なプログラムなのでここには載せないが、仮にdispatchという名前にすると、.procmailrcはこんな感じ(例:Kondara-users.jaメーリングリスト):

:
0
* ^Subject: +\[Kondara-users.ja:[0-9]+\]
| dispatch Kondara-users.ja

■ これでメールを受信すると自動的に、保存されるようになるので、Maildirの方は好きなタイミングで削除しちゃっていいことになる。……あ、いままで溜まったメールも保存しておかなきゃ。lsできないってことは、findの出番かな。現在INBOX/Software/Kondaraという階層にメールを振り分けている場合、実際のディレクトリは~/Maildir/.Software.Kondara/curになるので:

export MAILDIR=$HOME/var/mail
find ~/Maildir/.Software.kondara/cur | xargs -l dispatch Kondara-users.ja

■ となる。これで既存のメールも、新規のメールも自動的にアーカイブされることになった。あとはNamazuを突っ込むだけやな。ひひひ。

■ mph

slocateとか、けっこう使ってるツールがerattaに上がっている。いちいちパッケージをftpしてきてもいいんだけど、そろそろmphで自動upgradeに挑戦してもいい頃。自宅のマシンはいいとしても、職場のマシンは誰にクラックされるかわかったもんじゃないし。それに職場にはKondaraのmirrorサイトがある。これを利用しない手はない。

mph自体は自動的にインストールされているので、まず、/etc/mph.confを自分の環境に合わせて書き換える。デフォルトではスナップショットを持ってくるという実にKondaraらしいというか、恐ろしい設定になっているので、ここは以前、ぱぱんださんの日記で読んだのを参考にして、Kondara1.1/eratta以下だけを対象にするようにしよう。こんな感じ:

$DIRS = [
  'ftp://ftp.hogehoge.co.jp/Linux/kondara/Kondara-1.1/errata/bugfixes/i586',
  'ftp://ftp.hogehohe.co.jp/Linux/kondara/Kondara-1.1/errata/bugfixes/noarch',
  'ftp://ftp.hogehoge.co.jp/Linux/kondara/Kondara-1.1/errata/security/i586',
  'ftp://ftp.hogehoge.co.jp/Linux/kondara/Kondara-1.1/errata/security/noarch',
  'ftp://ftp.hogehoge.co.jp/Linux/kondara/Kondara-1.1/errata/updates/i586',
  'ftp://ftp.hogehoge.co.jp/Linux/kondara/Kondara-1.1/errata/updates/noarch'
]

■ 上の方にある、ftpのパスワードを、自分のメールアドレスに変えるのも忘れずに。続いて、データーベースを更新:

$ sudo mph-get update

■ ……と思ったらmph-get(その実体はRubyスクリプト)自体がコケる。正規表現のparseエラーだ。Ruby 1.4.5の非互換だな、これ。こないだ自作のスクリプトもこれにやられた。ちょこちょこと直して再実行。これでそれぞれのディレクトリに関する*.mphファイルを取得してくるので、その内容に基づいてアップグレードできるようになる。さて、アップグレードしてみよう。

$ sudo mph-get upgrade

■ アップグレード対象になっているパッケージの一覧がずらずらと表示され、そのファイルサイズ(初めてなので30MBほど。とても自宅でやりたい作業ではないね)が出て、更新するかどうか聞いてくる。「y」と答えるとftpからrpmファイルをGETしてくる……はずなんだけど、よくわからない理由でGETできんとかぬかしてくる。をいっ。

なんとなくftpのライブラリがくさい。現在のRubyはnet/ftpを使うことを推奨してるけど、このmph-getは古いftplibを使っている。そこで、スナップショットから最新のmph-0.9.6-17を持ってきてインストール……と、またreadlineが依存してるとか言われたので、src.rpmの方を再GETして--rebuildしてから再インストール。手慣れてきたな(笑)。

新しい/etc/mph.confを編集して($DIRが$asDIRに変わってたりするので注意)、再度update、upgradeを行う。こんどはいけてる。全ファイルの取得が終わると、rpm -Uvhがかかるのだ……が(こればっか)、なんとRubyのupgradeに失敗していると出た。あんた、今入ってるのは最新の1.4.5なのに、なんで1.4.4を入れようとするの。しかもruby-ebが依存してるからダメとか言うし。たぶん、mphファイルに書かれている方が優先されちゃうんだな。

■ 仕方がないので、ruby-ebをいったんアンインストールしてから、再度upgradeを実行。さっきダウンロードしたファイルはキャッシュされているので、すぐにrpmが動いて、こんどは成功。でもRubyが1.4.4に戻っちゃったので、改めてこないだ作ったRuby 1.4.5と、RubyEBを入れ直す。その前に、eb.soが入る/usr/lib/ruby/1.4/i586-linux-gnuというディレクトリを削除して、i586-linuxを指すシンボリックリンクに変えておく。これで素直に入るようになった。泥縄だけど(笑)。

でもこれだけだと、次回のupgradeでまた同じことが起きるような……。仕方がない、当面の処置としてeratta/updates/i586(Rubyが入っているディレクトリ)だけ、更新対象からはずしておこう。ローカルに自作のパッケージを入れたディレクトリを作ってmphファイルを生成しておけば、それを見に行くようにできる気もするけど、いかんせん、mphファイルの書き方がわからない(笑)。ま、これはいずれ。

■ Kondara 1.2

そういえば、Kondara自体の最新版もShizuka(1.1)からAyaka(1.2)になってるんだよなぁ。まぁ、特に不都合はないからしばらく1.2にする必要はないんだけど。つーか、ダイヤルアップユーザとしては、箱になるまで入手できないんだけどな(会社でCD-Rに焼くという手はあるけど、これは最後の手段)。そもそも、OSなんてものは年に何回もバージョンアップするものではない。次はKernelが2.4になるタイミングでしょう。

■ ディスク増設

続いて、週末に買ってきたハードディスクの取り付け。MP3ファイルで手狭になってきたQuantum Fireball SE 4GBに変えて、IBM DTLA-30502 20GBにするのだ。まずはIBMをセカンダリ・スレーブに取り付けて、以前の増設の手順を見ながら領域確保〜フォーマット〜mountまで順調に進める。日記ってすばらしい(笑)。それから取り外す予定のQuantumから、全ファイルをコピー。なんか、やたらとCPUを食うような。しかも遅い。変だな。

この時点ではあまり気にせず、Quantumを外して空いたプライマリ・スレーブにIBMをつなぎ替え。/etc/fstabを適当に修正して、載せ替え完了。ふっふっふー、楽勝じゃ。

でも、さっきの遅さが気になる。いずれ/homeをこっちに移動しちゃおうと思ってるだけに、あまり遅いのは困るだろ。dmesgを見てみると、プライマリ・マスターにつないであるもう1つのQuantumには「UDMA」の文字が出ているのに、今日増設したIBMには出ていない。UltraDMA66のディスクだから? どうもハードウェアのことになるとからきしだからなぁ、おれ。

hdparmというコマンドが記憶にあったので、rootになって使ってみる。DMAは-dで見えるらしい。なるほど、Quantumは1(on)なのに、IBMの方は0(off)だ。だから遅い? いやいやしかし。-tでちょっとしたベンチマークを取ってみると、どっちのディスクも3MB/secくらいしか出ていないことが判明(爆)。こんな遅いディスクで満足してたんか、おれは(笑)。

Webを調べてみると、DMAよりも-cオプション、つまりI/Oモードを32bitにする方が効果があるみたいだ。実際、IBMの方に-d 1を指定してDMAをonにしたら、ディスクが正しく読めなくなっちまった(汗)。試しに両者を比較してみると……

# hdparm -c 0 -t /dev/hdb
 
/dev/hdb:
 setting 32-bit I/O support flag to 0
 I/O support  =  0 (default 16-bit)
 Timing buffered disk reads:  64 MB in 17.45 seconds =  3.67 MB/sec
 
# hdparm -c 1 -t /dev/hdb
 
/dev/hdb:
 setting 32-bit I/O support flag to 1
 I/O support  =  1 (32-bit)
 Timing buffered disk reads:  64 MB in 10.29 seconds =  6.22 MB/sec
 

■ おおー、およそ倍。これなら文句ないだろ。いや、もしかするともっと速くなるかも知れないけど、おれって以前からSCSI2の5MB/secで満足だった人だから。これだけ出てれば十分でないの。いやホント。不満なのはDMA転送を使えないとCPU負荷が高いことだよなぁ。どうしたもんか……。

などと考えつつ、試しにリブートしてみたら、見事に設定を忘れてくれてるし。いちおう-kオプションもつけてみたんだけど、無意味だったか。仕方がないので、/etc/rc.d/rc.localの末尾に/sbin/hdparm -c1 /dev/hda /dev/hdbというのを追加しておいた。ちょっと不満だが、ま、いいだろ。

■ Courier-IMAP

Courier-IMAP 0.35。これはtar玉だがrpm --target=i586 -taでRPMが作れる。

■ RubyEB

RubyEB(こう書くのが正式?)のRPMが、ここにあったので、src.rpmでもらってきて、--target i586で自前ビルドする(←この手法が気に入ったらしい)。なぜか/usr/lib/ruby/1.4/i586-linux-gnuなんて変なディレクトリに入れられてしまったので移動する……って、これじゃRPM化した意味がない!? あとでSPECファイルを見てみるか。

■ SGmail

SGmail 3.20。やっと持ってきてインストール。機能的にはそんなに変わってない。サポートBBSができていて驚く。それがRuBBSでさらに驚く(笑)。

■ w3m

ついで。w3mをKondaraのsnapshotから拾ってきて入れる。0.1.10。これで、RuBBSで投稿直後にreloadをかましても、エラーにならずに済むようになった。テストのためにテスト用BBSに書き込んだつもりが、間違ってRuBBSサポート掲示板に書いてしまう……アホ。