[PREVIOUS CHAPTER]
[NEXT CHAPTER]
8 FML 設定ファイルのフォーマットと構造
fml の設定ファイル、メンバーリストは基本的に shell like な構造で記述さ
れていると期待されています。つまり基本的に # ではじまる行はコメント、
空行は飛ばす等の挙動を各ルーチンはしています。
以下では各設定ファイルのフォーマットについて言及します。
8.1 members ファイルのフォーマットと構造
生のファイルのフォーマットは後述のようなものです。コマンドの挙動は 2.2
以前と以後でちょっと違います。2.2 以降のmembersコマンドでは一般ユーザ
には下のようなフォーマットは見えません。すでにいなくなったメンバーの情
報をだすべきではないからです。admin members では後述する生のフォーマッ
トが見えてしまいます。一応知っておいて下さい。
$MEMBER_LIST (default members) で定義されるファイルは
#.FML
…fml が自動的につけるコメント…
#.endFML
アドレス1
アドレス2
# アドレス3
##BYE アドレス4
アドレス5
のような形をしています。歴史的理由により現在では
# の後空白 でコメントアウトされていてもメンバーチェックの対象になる
## ではじまるところはコメント
となっています。よって上の例では ##BYE の行は無視されますが、それ以外
の アドレス1 〜 アドレス5 (4を除いて) すべてがメンバーチェックの際には
対象となります。
[歴史]
この動作は 1.2 release version の直後、自動登録を拡張する際に導入され
ました。またこの導入のため # off と # skip はどう違う?という疑問がそ
の後生まれることになりました。
なおメンバーファイルとしては各行のアドレスより後ろの部分は
何にも使われていませんので、勝手に使って構いません。
しかしながら、自動登録の場合は $MEMBER_LIST と $ACTIVE_LIST は同じもの
($MEMBER_LIST)が使われます。よってそのフォーマットは $ACTIVE_LIST 形
式であると仮定する必要があります。
8.2 actives ファイルのフォーマットと構造
$ACTIVE_LIST (default actives) で定義されるファイルは $MEMBER_LIST と
同様の構造を持ちます。
しかし actives ファイルは拡張された表現として各アドレスのオプションを
行の残りの部分に持つことができます。
アドレス オプション # コメント
注意:なお、それぞれの↑ブロックの間には必ず一つ以上の SPACE
か TAB があると仮定しています。
よって勝手に何かを書いた場合オプションとみなされます。付加情報は # コ
メント として行の最後にでも書いて下さい。この辺は shell と同じです。
オプションは V1 と V2 フォーマットがあります。
V1 フォーマットは
数字(フォーマット) まとめおくりの指定
数字以外 リレーサーバ
V2 フォーマットでは将来の拡張のため
m=まとめ送り指定
r=リレーサーバ
s=1(skip を意味する)
のように alphabet=option-value の形で定義されています。現在のところこ
れ以外のキーワードは将来のために予約されています。
現在のルーチンは V2 のみを理解します。よって V1 -> V2 に変換する必要が
あります。この変換は
libfml.pl で ChangeMemberList が呼ばれた時
つまりメンバーリスト等へのなんらかの変更を行なう時に自動的に行なわれま
す。
8.3 actives と members の違い
フォーマット的には上述の通りです。後は自動登録の章で述べられている通り
members はメンバーであるか否か?の認証、 actives は配送リストです。
自動登録では members 一つを認証と配送リスト両方に使っています。そのた
め表現の拡張が必要だったわけです。
8.4 複数のメンバーリスト、複数の配送リスト
@ACTIVE_LIST 複数の配送リスト
@MEMBER_LIST 複数のメンバーリスト
を定義できます。地方ごととか組織ごとにリストを管理するのに便利かも知れ
ません。
@ACTIVE_LIST plural member lists
@MEMBER_LIST plural delivery lists
デフォールトでは @ACTIVE_LIST は $ACTIVE_LIST と同じになります。
@MEMBER_LIST は members と members-admin です。
歴史: 最初に管理者を設定して後はリモートですべてをおこなうという目的の
ために拡張されました。
***
actives members のバックアップについて => ../daily 6.2
8.5 msendrc ファイルのフォーマットと構造
msendrc は $MSEND_RC で定められる場所におかれます。そのフォーマットは
アドレス 次回に送る最初の記事番号
です。msednrc は msend.pl が制御するログファイルです。msend.pl は
$ACTIVE_LIST を見て、
・あるアドレスがまとめ送りになった
そのアドレスのエントリを msendrc 内に新しく作る
・あるアドレスがまとめ送りで”なくなった”
そのアドレスのエントリを消去
・まとめおくりを配送した
次回に送る最初の記事番号を msendrc に記録する
ということを msendrc に対して行ないます。msend.pl 以外のプログラムが
msendrc をいじることはありません。
8.6 パスワードファイルのフォーマットと構造
../utility_programs 6.17../remote_control 4.0
リモート管理の時の認証で用いるパスワードを保存しているファイルは
$PASSWD_FILE でデフォールトでは $DIR/etc/passwd です。フォーマットは
../remote_control 4.0
アドレス cryptされたパスワード
です。つまり UNIX 伝統のパスワードファイル形式の先頭の2つが空白で区切
られたものです。#crypt(3) についてはマニュアル参照
$REMOTE_ADMINISTRATION_AUTH_TYPE = "md5";
../remote_control 4.6
と設定されている時は fml.pl の crypt 関数は crypt(3) ではなく MD5 の値
を返すようになります。これは MD5.pm を用いた実装なので perl 5 であるこ
とと MD5-1.7.tar.gz のインストールが必要です。MD5.pm のソースは fml の
directory に一緒に置いてあります。
admin コマンドには initpass というパスワード初期化コマンドがあります。
あるアドレスをこのファイルへ登録する時などは makefml passwd を使うと良
いでしょう。makefml の使い方については INSTALL ファイルを参照。
8.7 FMLインストール後の maintenance と version up に関して
install は makefml install を使います。version up も同様にして下さい。
というのはインストールするOSなどに依存することがあるので、makefml
install を使うべきだからです。なにをやっているか知っている人は別に cp
でも構いません:)
version up の仕方は、例えば次のようになるでしょう。
% cd /var/tmp
% tar zxvf fml-current.tar.gz
% cd fml-version番号他の名前
% make install
以下では例として
/usr/local/fml に executable
/var/spool/ml/elena に elena ML
ということにしましょう。
makefml install はいつでも /usr/local/fml に executable やライブラリを
入れるだけです。version up の際に違うことは既にあるML群に対してロッ
クをしてからインストール作業を行なうことだけです。/var/spool/ml/elena
の下つまり config.ph 等は変更を受けません。
fml.pl を筆頭に lib*pl 群は overwrite されますから自分でいじってしまっ
ている場合は一旦バックアップを取っておくことが必要です。
メインテナンスを楽にするにはコマンドのパスやML全体共通の設定はファイ
ルに全部書いておくべきだし、可能な限りHOOKなどにするべきです。例えば
$HOME/libexec/fml/sitedef.ph
で行ない各MLごとの設定は
$HOME/w/spool/fml-support/config.ph
で制御するなどの運用ポリシーを立てておくことも大事です。
[PREVIOUS CHAPTER]
[NEXT CHAPTER]