この文章は、2002年春に渡邊克宏が SML の管理者を退く際、 次の管理者への引き継ぎと申し送りのために書いた文書です。 2004年9月にSML の管理主体の移行の話が出たので、利便を考えて公開します。 ただし、一部公開に差し支えある部分や typo は編集しました。
主にPythonを使って書かれた Mailmanというメーリングリスト管理プログラムを用いている。 バージョンは2.0.10を 日本語化した 2.0.10+J2というものである。
Webを通じた操作インタフェースはMailmanの大きなウリなのだが、 これは一般には公開せずにSRA内でのみ用いる。 なぜなら、コードを見て受けた感じとして、 まだこなれてなかったり洗練されてないところが残っており、 どこかにセキュリティホールが残っているというのはありそうな話だから。
やっぱりみつかって、2.0.11で修正された。 でもきっとまだ残ってる。
このため、Webインタフェースに関する説明などを削除してある。 sranhmにおいて、 通常のmailmanが/home/mailmanにインストールされているのに対し、 この制限されたMailmanは/home/mailman-nowwwにインストールしてある。 誤って/home/mailman の方をいじらないよう注意すること。
2.0.10+J2のソースはsranhm:/home/src/tgz/mailman-2.0.10+J2.20020418.tar.gzである。 パッチは、sranhm:/home/src/tgz/maiman-nowww-patch*である。 (複数ある場合は多分番号がふられているだろう。) このパッチは渡邊克宏によるものだが、もし需要があれば、 自由(FREE)なライセンスを適当に選んで配布してよい。
UNIX上でのmailmanの管理作業は、mailmanというユーザの権限で行なうこと。
通常の管理作業のほとんどはWebインターフェイスを通して行なうことができる。 日々作業が必要な仕事としては、 保留中の管理要求を処理する ページを見に行き、
これはおそらく Bcc: にsml@sra.co.jpを指定して投稿したか、 sendmailのようなユーザが使わない低レベルの機構を用いて 送られてきたのであろう。
などに対して、配送を承認するか破棄するかを選択することである。 なお、2002年5月末までの時点で、 登録されていないアドレスからの適正な投稿は1件だけで、ほとんどはSPAMであった。
(略)
netscapeを使って管理していると、時々パスワード設定が壊れる (mailmanのバグだと渡邊は思っている) 。 管理者としてmailmanのWebインタフェースにログインできなくなったら、
% /home/mailman-nowww/bin/pass_list sml 新しいパスワード
を試してみること。
mailmanに渡邊がいくつかのコマンドを追加した。 /home/mailman-nowww/binに置いてある。 これらは渡邊のパッチにも含まれている。
公開用アーカイブは、 mailmanによって /home/mailman-nowww/archives/private/sml/に (あらたな投稿が届くたびに)incrementalに生成される。 ただし、mailman移行以前の記事をこれに併合しておく必要がある。
SMLの過去の投稿記事は、 可能なかぎり/home/mailman-nowww/archives/private/sml.mbox/以下に 集めてある。 以下の4種類が存在する。
隠れた問題： UNIX From 行(ヘッダに先立ってコロン抜きの From で始まる行)が GMT でなく JST として記録されている。
これらから 公開用アーカイブ/home/mailman-nowww/archives/private/sml/ を再構成するには、 /home/mailman-nowww/lists/sml/bin/restore_archive というスクリプトを動かせばよい。 (3.2節参照)
投稿された記事や過去の記事・ Mailmanが管理するアーカイブ・ 公開用アーカイブ などの間のデータの依存関係(Data Flow Diagram)を以下に示す。
公開用アーカイブは月ごとに区切られているが、 これはJSTでなくGMTを基準に区切られる。 すなわち、4月1日午前8時59分に投稿された記事は、3月分に含まれることになる。 これは修正しない方がよい。 なぜなら、 .../20xx-March/00yyyy.htmlというURLで示されていた記事が、 修正した後で公開アーカイブを再構成すると .../200x-April/yyyy.htmlのような場所に移ってしまうから。 極力記事の URL は変わらないように保持したほうがよい。
sranhmでNamazuのindex(キーワードのリスト)を /home/apache/Public/ML/sml/namazuに作るが、 実際に検索のCGIが動くのはosb.sra.co.jpである。 sranhm:/home/apache/Public以下は、 cronで自動的にosb:/home/apache/htdocsにコピーされるしかけになっている
Namazuのindexは、cronから/home/mailman-nowww/lists/sml/bin/prepare_namazuを起動することによって構築する。
検索結果の表示のサマリー部分にゴミではない有用な情報を表示するために、 NAMAZUによる検索機能の追加のページを参考に、 /usr/share/namazu/filter/pipermail.plにpipermail用Namazuフィルターを置いてある。
osb.sra.co.jpで動く検索 CGI(namazu.cgi)は、 sranhm:/home/apache/Public/ML/sml/cgi-bin/ に置いてある。 このディレクトリは定期的に sranhm から osb へとコピーされることになっている (sranhm:/home/apache/Publicの下にあるから) ので、 あらかじめ osb の環境(2002年7月の時点ではFreeBSD)用のnamazu.cgiを コピーしてきて置いておかねばならない。
namazu.cgiは、 同じディレクトリに .namazurcを参照して動くが、 その内容は当然(実際に動作する環境である)osb.sra.co.jpにおける記述で なければならない。 osb.sra.co.jp の構成が変わるなどして namazu.cgiを指すURLが変更になる場合、
が正しいかどうか見直すこと。
以下のURLの文書を適切に保守すること。
これらのファイルは RCS で版管理されている。 実際に操作する際には、 sranhm:/mnt/nfs/www/public/sra/product/VisualSmalltalk/SML/ や srasva 等に mount されているものをいじるのが楽。
上記のディレクトリにある 1-1000,1001-2000などのディレクトリは、aoki さんが私的に管理しているもので、SMLの公式のものではない。 また、 archives は Mailman によって自動的に生成された公開アーカイブ(のコピー)であり、 sml.mbox は sml に投稿された記事をそのまま蓄積したアーカイブ(のコピー)である。 (1.2節参照)
このメーリングリストの管理人は、議長ではなく、 アドレスのリストを持っていて配送係を引き受けているだけの技術的な下僕である。 政治的な決定を求められたり、調停などの要求があっても、 無視あるいは断ってよい。
「管理人」という目立つ立場から議論やpolicy設定に関わってしまい、 議論を泥沼化させたりいわれのない攻撃を受けてしまう、 というのは時々見られる管理人特有の現象である。 渡邊克宏はどのメーリングリストにおいてもこれから逃げている。
運用に関しては、以下のようなポリシーが陰に陽に存在する。
不適切な投稿があっても、 それと気がついたときには(多分)既に各人への配送が済んでしまっており、 後から取り消すことは不可能である。 しかし、後々まで残るアーカイブから削除することはできるであろう。 アーカイブからの削除の核となるのは、 sml.mboxファイルを編集し、 それをWeb上の公開アーカイブに反映する作業である。 これを安全確実に行なうは、以下のような手順を踏むとよい。
削除する行為が運用policyに合っているか考えてみる。 管理人はアーカイブを技術面で保守しているだけであり、 持ち主なわけではない。 アーカイブの持ち主は、SML のメンバー集団である。 勝手な判断でアーカイブをいじると禍根を残すことがありえる。
まず、作業中に新たな記事が到着してもいいように、 メーリングリストを lock する。
% su mailman
$ cd /home/mailman-nowww
$ python -i bin/withlist -l sml
Loading list: sml (locked)
>>> ^Z (Ctrl-Z を打ち、lock を抱えたまま python を suspend させる。)
[1]+ Stopped python -i bin/withlist -l sml
$ ls locks (lock ファイルができていることを確認。)
sml.lock sml.lock.sranhm.sra.co.jp.15887
(ちなみに 15887 は lock を保持しているプロセスの番号)
$ (そしてこのシェルは sml.mbox の編集が終わるまで終了させないようにする。)
しかる後に、 /home/mailman-nowww/archives/private/sml.mbox/sml.mbox をeditor等で編集する。 単純に該当記事を削除するのではなく、 [SML 5660] のように、 削除にいたる経緯の記述で置き換えるべきである。 また、問題となった記事も、 sml-hidden.mbox等に隠して残しておくと保身に役立つかもしれない。
編集が終わったら、メーリングリストを unlock するのを忘れないこと。
$ whoami
mailman
$ jobs (lock を抱えたまま suspend している python の job No. を調べる。)
[1]+ Stopped python -i bin/withlist -l sml
$ fg %1 (lock を抱えている process を起こす。)
python -i bin/withlist -l sml
^D (Ctrl-D を打ち、lock の解放と共に python を終了させる。)
Unlocking (but not saving) list: sml
Finalizing
$ ls /home/mailman-nowww/locks (lock ファイルがなくなったのを確認。)
$
sml.mboxなどを書き換えたならば、 その変更はWeb上の公開アーカイブにも反映させる必要がある。 これには 3.2節に述べる正式な方法をとってもよいのだが、 それにはとても時間がかかる(2時間)し、 再構成中に新たな記事が到着してやりなおしが必要になることもありえる。 変更した記事に該当する html ファイルを直接いじったほうが早いし、 (全体を作り直すのではなく１つの記事だけに影響範囲を限定できるという意味で) 安全でもあろう。 ファイル名は記事の通し番号と直接対応づいているはずなので、 変更すべきファイルを /home/mailman-nowww/archives/private/sml/ の中から見つけるのは容易にちがいない。 一貫性を確実に保つために、打ち直しは避け、 機械的な方法(cut and pasteあるいはfileを介した方法)に頼るのが望ましい。
公開アーカイブは /home/mailman-nowww/archives/private/sml/に構成されているが、 これをいじったり再構成しても、それは sranhm 内からしか参照できない。 社外向け Web server のしかるべき場所に置かれて公開されるのは、 何もしなければ 翌朝("crontab -u mailman -l" を参照)まで待たねばならない。 再構成したものをすぐ世の中に公開し、結果を確認するためには、
% su mailman
$ /home/mailman-nowww/lists/sml/bin/publish_archive
のように、 コピーをするコマンドpublish_archiveを動かせばよい。
1.2.1節で述べたように、 過去に投稿された記事は、その由来に応じてディレクトリを別けて保存してある。 これらから公開用アーカイブを再構成するには、 /home/mailman-nowww/lists/sml/bin/restore_archive というコマンドを動かせばよい。 ただし、あらかじめ
% su mailman
$ rm -rf /home/mailman-nowww/archives/private/sml/*
などとして、生成される公開アーカイブのディレクトリを空にしておかねばならない。 (再構成が可能なのだから、バックアップを取る必要はないと渡邊は信じている。 しかしresotore_archiveをのぞき見た人が、 もし再構成が失敗したらどうなっちゃうの？と心配するのは自由だろう。)
なお、再構成中に新たなメールが届くと、順番が狂うなどの混乱が起きる。 これを避けるためには lock をかけたり 一時的に記事の受け入れを停止することが考えられる。 しかし、 公開アーカイブの再構成にはかなり長い時間(sranhmで2時間)がかかるので、 メーリングリストを長時間停止することになり何かと好ましくない。 通常は急いで再構成をする必要はないと思われるので、 再構成をとりあえず始めてみて、不幸にも途中に投稿がはさまった場合には 最初からやりなおすというのが現実的と思われる。
メーリングリストを lock した状態でアーカイブ作成コマンドコマンド (/home/mailman-nowww/bin/arch: これ自体も当然 lock をかけようとするはず) が dead lock に陥らずに動くのかどうか、 さらには arch を使っている restore_archive が動くのかどうかは、 試したことがないのでわかりません。