[PREVIOUS CHAPTER]
[NEXT CHAPTER]
2 fml の機能についての概要
注意: インストールやMLの作成の仕方についての詳細は INSTALL.jp という
ファイルを読んで下さい。
2.1 Directory 構造
基本的に directory は2箇所からなります。インストール時に makefml で指
定できます。インストール方法の詳細はINSTALLというファイルを参照。
1 $EXEC_DIR (と makefml でいっている)
実行ファイルとライブラリ群 (e.g. /usr/local/fml)
2 $ML_DIR (e.g. /var/spool/ml)
各ML群が /var/spool/ml/ に作られる
/var/spool/ml/elena/ (elena ML)
/var/spool/ml/mirei/ (mirei ML)
/var/spool/ml/Freekick/ (Freekick ML)
/var/spool/ml/sakura/ (sakura ML)
/var/spool/ml/tomoyo/ (tomoyo ML)
/var/spool/ml/kerochan/ (kerochan ML)
...
elena ML 関係の全てのファイルは /var/spool/ml/elena/ 以下に作られます。
設定ファイル(config.ph)や記事のスプールも同様です。複数のMLを作成す
ると /var/spool/ml/ 以下に並びます。
2.2 インストーラ
対話的処理をする makefml という簡単なインターフェイス(CUI)がついてきま
す。これがインストールやMLの作成簡単な設定の変更を可能にしています。
詳しくは INSTALL.jp を参照
初心者には最初は何をどういじってインストールするのかは良くわからないも
のです。とりあえず簡単なものはこれでできるはずです。詳細については
INSTALL.jp というファイルを見て下さい。
『ある動作をするか?否か?』については config.ph という設定ファイルで
操作することができます。アーカイブやスプール、help ファイルの場所 や
『tar ish lha のような system のコマンド』のようなものもすべて hard
coding ではなく user が外部から制御できる変数として定義されています。
変数リストについて興味があれば cf/MANIFEST を見るとわかります。
2.3 ドキュメントについて
PLAIN TEXT 版はパッケージ中の doc/ にあらかじめ用意されています。README
や INSTALLマニュアル の HTML 版も ぱっけーじ/doc/html/ の下に用意され
ています。
ドキュメントの最新版は
http://www.fml.org/fml/
にあります。
2.4 一般ユーザー権限ということ
特別なユーザー 例えば daemon 等で動かすのはセキュリティ上好ましくあり
ません。よって一般ユーザー、できればML用の特別なユーザーを用意し、そ
のユーザの権限でFMLを動かすのが望まれます。通常FMLプロセスのオーナー
(ユーザー)は makefml で作られる include というファイルの所有者です。
また FML は実装上 Trusted User 等を気にする必要はないので daemon で動
かす必要もありません。
少しメカニズムの話をするとMTA (e.g. sendmail) はユーザー権限で動かすた
めに setuid() を行ない、そのユーザーとして fml.pl を起動します。POSIX
準拠 OSは setuid() をちゃんと行なえる user は root に限られます。これ
はこれで正しい選択だし、ターゲットの 4.4BSD もそういう実装をとっていま
す。そのためMTAから setuid() をしてfml.plを動かすプログラムを走らせた
りはせずにその辺はMTAにまかせています。
sendmail 等がうまく setuid() を実行できない場合 4.3 BSD では fml.c を
compile して使えば良いでしょう。makefml でインストールしていれば
makefml が作った Makefile を使うと
(shell prompt)% make fml
で fml および fml-ctl という実行ファイルが生成され、setuid されます。
fml は投稿用アドレス、fml-ctl はコマンド用アドレスに使います。
4.3BSD では一般ユーザーに setuid() されたこの状態で setuid() が実行で
きます。POSIX 準拠等OSでは *非常に危ないですが* この fml を root 権
限に setuid しなければなりません。fml, fml-ctl をどこにおいて使うべき
か?について自信がない場合あなたのサイトもしくはそのマシンの管理者によ
く相談して下さい。
2.5 ライブラリ・モジュールとダイナミック・ローディング
モジュールにすることにより
マスターコードの保守
自分だけのモジュールを独立に保守
することが容易になります。モジュールはすべて lib"module-name".pl とい
うファイル名です。
もともとは SMTP部分の独立保守と 常時使うわけではないコマンド部分を切り
離すことを目的としたモジュール化でしたが、現在では必要に応じてダイナミッ
クローディングされる様々なライブラリが提供されています。ファイルは一杯
ありますが常に使われるのはそのうちの2、3個くらいです。後は週に一度とか
明示的に設定がされた場合のみにしか使われないようなものです。
モジュールはインターフェイス仕様さえ不変なら独立に保守できます。
contribution され独立に保守されているコードも同様にライブラリに入って
います。例えば libtraffic.pl は
libfml.pl の関数呼びだしインターフェイスに合わせれば、後は
すべて user defined で作れる
というよい例です。
#ぼくは中身についてタッチしていません。fml master code tree とは独立
#に保守されています(感謝)
FML はこのライブラリ群が本体で、その動きを設定ファイル(config.ph)でカ
スタマイズするようになっています。そのためライブラリ・モジュールは一箇
所にまとめておくと『ひとつのfmlで複数のMLを扱うように拡張』等も容易
になり、また version up も楽です。makefml でインストールする場合はそう
いう形態になります。
例:
ライブラリは /usr/local/fml の下に全部入れる
ML群は /var/spool/ml/each-ml/
(e.g. /var/spool/ml/each-ml/config.ph )
MLを配送ではなく特定の目的のサーバのみを dynamic loading して
『特定の目的のサーバ』にすることも簡単にできます。
#config.ph で特定のファイル名を $LOAD_LIBRARY に設定する
これにより、
コマンド 専用サーバ
ftp 用サーバ
ftpmail 専用サーバ
メールで request をうけてURLの中身を返すサーバ
等の専用サーバに設定することもできます。
2.6 設定ファイル (config.ph)
できるだけソースコードを直接いじらなくてもたくさんの制御変数とフックで
カスタマイズできるようになっています。カスタマイズ可能な変数は
config.ph 中に簡単な説明とともに書いてあるのでこれを変更することで行な
います。基本的なものについては makefml で変更ができます。
2.7 アクセス制御と自動登録
../how_to_subscribe 4.0
前述のとおりデフォールトは来たメールの From: を見てメンバーチェックを
します。FML 2.1 以降では投稿とコマンドそれぞれについて以下の
・誰からの投稿を許すか?
だれでもOK anyone
登録されているメンバーだけ members_only
モデレーターだけ moderator (../how_to_subscribe 5.0)
・もし、登録されているメンバー以外から来た場合にはどうするか?
許否 reject
自動登録 auto_regist
無視(管理者へ報告だけする) ignore
を設定できます。デフォールトはいずれも
メンバーのみ(members_only) 投稿/コマンドの使用 が可能
もしメンバー以外から来たら許否(reject)
です。自動登録は"投稿がメンバーだけ"(members_only)の場合に
もしメンバー以外から来たら自動登録 → auto_regist へ変更
することで行ないます。自動登録のタイプは4種類あります。
2.8 ファイル操作: 取り寄せとまとめ送り
5.0../digest 2.0
get, mget, matome 等のコマンドにはオプションで tar.gz で固めてとか
MIME/Multipart 形で記事をまとめて送り返して欲しい等の変更ができます。
mget と まとめおくりでの User interface は次のようなものが取り揃えられ
ています。mget コマンド毎に指定を変えることができます。
PLAIN TEST
UNIX FROM
RFC934
RFC1153
MIME/Multipart
COMPRESSED FILE
gzip UNIX FROM file
tar + gzip
uuencode
(日本使用)
Lha + Ish (自動SJIS変換可)
Lha + uuencode (自動SJIS変換可)
mget で取り寄せられるのはデフォールトは $SPOOL_DIR (default "spool")
ですが対象は標準のMLの記事スプール以外にも @ARCHIVE_DIR に指定するこ
とで増やすことができます。
ファイル操作の応用編としてユーザーが put も get できるように拡張された
コマンドも実装しています(library コマンド)。ただしデフォールトでは、
put するファイル名はセキュリティ上選べません。ファイル名を明示的に指定
する場合は安全のため管理者が変更するべきです。
../command 5.1
2.9 MIME や base64 等の処理
../html_convert 1.0
メール本文は基本的に素通しです。Subject のMIMEは decode してサマリーを
作ります(2.2ではデフォールト)。またHTMLでは base64 の画像等の変換処理
を下請けのプログラムに渡して行ないます。つまりメール中の gif ファイル
を変換してメールの記事の html を生成します。
2.10 リモートでMLを管理すること
../remote_control 4.0
../encryption 4.0
デフォールトではできません。設定ファイルで
$REMOTE_ADMINISTRATION = 1;
を設定するとできるようになります(makefmlでも設定できます)。
管理者として登録された人に対し
From: 行での認証
管理者一人ごとのパスワード (秘密鍵暗合)
PGPベースでの認証 (公開鍵暗合)
../encryption 4.0
の組合せで認証をします。デフォールトは
From: 行での認証
管理者一人ごとのパスワード (秘密鍵暗合)
です。どうせやるなら PGPベースが推奨です:)
FML 1.0 で『管理者が本当に操作しているかどうか?という点に関して保証で
きない』という理由ではずしたリモート管理(アドミンコマンド)を再実装し、
サポートします。保証できないという意味は From: での認証は簡単に偽造で
きるからです。
多くの場合MLではリモート操作はパスワードで認証しています。しかしなが
ら、メールの中では平文パスワードを書く必要がありますし、ひとりの管理者
のパスワードは毎回同じで使い捨てではありません(時系列に沿って)。よって、
間違ってメールが読まれた場合を考えると危険なわけです。
PGPベースではこの心配はありません(もちろんあるメール全体を読まれていれ
ばそのメールと全く同じ内容を実行だけは可能なはずですが)。
FMLのリモート管理モードではパスワードは各管理者ごとに設定できます。
PGPの場合は管理者一人一人の public key を入れることになります。
管理者全体で一つの共通パスワードというようなださい実装はしません。これ
は普通の UNIX の パスワードシステム のミニチュア版です。サーバ側では
$DIR/etc/passwd に 管理者ごとにパスワードを保存しています。 保証の度合
が上がったわけではありませんが、パスワードは crypt し保存しています。
一応かつての UNIX 程度の保証はされます。パスワードの保存を MD5 にする
こともできます。PGPではMLごとに $DIR/etc/pgp/ 以下に keyringを作りMLご
とに別のPGPPATHを用います。
../encryption 4.0
2.11 .forward
../utility_programs 4.0
通常 include ファイルを設定するのは /etc/aliases ですが .forward は本
質的に同じものです。もっとも .forward の場合ユーザー名以外のものを使う
ことはできないわけですが。だから include は .forward に設定すれば同じ
です。詳細は ../utility_programs 4.0
2.12 Listserv/Majordomo
../utility_programs 3.0
Listserv 互換用インターフェイス libexec/fmlserv.pl
fmlserv.pl を呼ぶようにした場合 コマンドは
コマンド ML名前 オプション
になります。ようは Listserv 形式のしんたっくすで fml のコマンドを使え
るようにしたインターフェイスです。
listserv: fmlserv
majordomo: fmlserv
fmlserv: :include:/var/spool/ml/include/fmlserv
のようにしても大丈夫です。
2.13 MTAとの通信 (e.g. sendmail)
FMLは sendmail 等の SMTP配信エージェントと自力で通信します。
$Envelope{'mci:mailer'} = 'ipc'; (default)
の場合 $HOST で指定されているマシンにSMTP でコネクションを張り配送をま
かせます。$HOSTのデフォールトは自分のマシンで、つまり自分のマシンで走っ
ているMTAと通信します。
$Envelope{'mci:mailer'} = 'prog';
の場合 $SENDMAIL という変数のプログラムを起動してそれに配送をさせるこ
ともできます。
SMTP を理解してくれるなら sendmail である必要もないし配送用に使える
SMTPサーバ があれば動きます。それは必ずしも自分のマシンで sendmail が
走っている必要はありません。各サイトで走っているSMTPを理解してくれる配
送プログラムがあればよいです。sendmail が走っているマシンが一つもなけ
れば sendmail を起動するように 'prog' を指定すればよいです。
2.14 MTAがメールを受けとれないマシンの時
../utility_programs 5.0
逆にどうやってメールを受けとるかという問題があります。通常 SMTP を理解
する受けとるサーバが走っていて、メールを受けとり fml.pl へ渡します。例
えば一定時間間隔で POP をかけてMLを動かし、配送はサイトの SMTP サー
バにやらせることでMLを実行するこは可能です。
2.15 セキュリティ
MLのトラフィックをモニターして一気にメールが送られてきたらメール爆弾
と判定してrejectするとかヘッダやメール本文の特定のパターンをフィルタリ
ングする機能もあります。詳しくは 9.0
2.16 その他の機能
ロックは flock によるロック処理をデフォールトにしています。が flock()
が動かない場合 UNIX V7 以来の link() によるロックを使います。
リレーサーバを設定できます。例えば、関東方面、関西方面にこねがあって、
マシンが調達できる場合、関東方面のメールを一回そのマシンに送ることで関
東方面へおくるメールを一つのメールでいっきにおくって、配送はそのリレー
先にまかすことで、配送を高速化できます。
注意: 現代のMTAでは対SPAM設定が普通ですからやるのであればちゃんと折衝
しましょう。
プロバイダ等でDISKに制限があったりする場合は、古い記事は消したいとおも
いますがそのための自動圧縮や Expire の機能をサポートします。
newsyslog(8) 的機能をサポートしています。古いログは自動的に
members -> var/log/members.0
のように変換し保存するようにしています。デフォールトでは members ファ
イルや まとめおくりのログに対して newsyslog を実行しています。
#参照: % man newsyslog
一つのマシン上にある ML間のクロスポスト の場合、
複数のMLに入っている人には一通しか送らないようにします。
#サイトにまたがる場合はデータのシンクロが必要なため実験段階です
おまけ機能として、スタートレックの宇宙歴をサポート(笑)します。
contrib/Utilities に宇宙歴をつけるmh, mh-e user interface つき:-)です。
../header_rewrite 3.14../utility_programs 6.26
[PREVIOUS CHAPTER]
[NEXT CHAPTER]