CGI の内部構造については を参照して下さい。 デフォルトの &fml8; では、 apache で suexec を使う ことを前提としています。 つまり http://mail.example.org/~fml/cgi-bin/fml/DOMAIN/admin/config.cgi http://mail.example.org/~fml/cgi-bin/fml/DOMAIN/ml-admin/ML/config.cgi といった URL を使う前提です。 ＭＬごとの管理用 CGI、 ドメイン全体を管理する CGI 一般ユーザ向けの subscribe/unsubscribe リクエストを申請してもらう CGI ( 2008/09/09 以降) の３種類が用意されています。 管理用 CGI インターフェイスでは、 ユーザの追加、削除、メンバーリストやログの閲覧などが可能ですが、 いまのところ CGI からの設定変更インターフェイス (設定ファイル config.cf の編集機能) が中途半端です。 「CGI から操作可能」なコマンドは、すべて CUI と同じ効果を持ちます。 たとえば、ＭＬの作成や削除もコマンドラインと全く同一ですので、 CGI 用の特別な作業は不要です。 makefml newml ML (fml ML newml)を実行すると、 ~fml/public_html/ 以下に CGI スクリプトが作成されます。 つねに CGI スクリプトは作成されます。 一方、 apache のデフォルト設定では ~fml/ 以下は見えません。 この(制限された)意味において 「&fml8; デフォルトでは CGI が無効」 と言っています。 この CGI は前述のように３種類あります。 管理用の二種類には 「ドメイン全体を管理する CGI」 と、 「それぞれのＭＬを管理するＭＬ専用の CGI」 があり、 それぞれ、次のパスに作成されます。 そのドメイン全体の管理者用 (そのドメインすべてのＭＬを管理可能) ~fml/public_html/cgi-bin/fml/ドメイン/admin/config.cgi ＭＬごとの管理者用 (そのＭＬのみを管理可能) ~fml/public_html/cgi-bin/fml/ドメイン/ml-admin/ＭＬ名/config.cgi 一方、一般ユーザ向けの CGI (ＭＬの入会・退会申請メニュー用)は、 WWW サーバの設定でフィルタが書きやすいように、 わざと異なるパスに作成しています。 ~fml/public_html/cgi-bin/anonymous/ドメイン/ＭＬ名/submit.cgi 必要に応じ、WWW サーバの設定で 「 ~fml/public_html/cgi-bin/fml/ 」 と 「 ~fml/public_html/cgi-bin/anonymous/ 」 で異なるアクセス制御を行なって下さい。 たとえば、elena@fml.org ＭＬを作成すると次の３つが作成されます。 ○ fml.org の全ＭＬを管理する CGI スクリプト http://lists.fml.org/~fml/cgi-bin/fml/ドメイン/admin/config.cgi 例 http://lists.fml.org/~fml/cgi-bin/fml/fml.org/admin/config.cgi ○ elena@fml.org ML だけを管理する CGI スクリプト http://lists.fml.org/~fml/cgi-bin/fml/ドメイン/ml-admin/ＭＬ名/config.cgi 例 http://lists.fml.org/~fml/cgi-bin/fml/fml.org/ml-admin/elena/config.cgi ○ elena@fml.org ＭＬへの入会・退会用申請 CGI スクリプト http://lists.fml.org/~fml/cgi-bin/anonymous/ドメイン/submit.cgi 例 http://lists.fml.org/~fml/cgi-bin/anonymous/fml.org/elena/submit.cgi WWW サーバの認証システムに、おんぶにだっこです。 それはいいとしても、もう少し、 &fml8; での WWW サーバ設定支援ツールがあるべきでしょうね。 デフォルトでは、 とりあえず潰してあります(認証エラーになる)ので、 適切に変更して下さい。 デフォルトでは、 CGI のアクセスを拒否するようにドメイン単位で .htaccess が作られます。 http://lists.fml.org/~fml/cgi-bin/fml/ドメイン/.htaccess 例 http://lists.fml.org/~fml/cgi-bin/fml/fml.org/.htaccess デフォルトの .htaccess は次のような無意味:)なものになっていて、 アクセスできません(エラーになります)。 さらに、デフォルトの apache では ~fml/ へのアクセスは出来ないはずなので、 apache の設定も別途必要です。 一応、デフォルトでは、この二段構えの拒否体制になっています。 AuthName ByPassword AuthType Basic require valid-user この .htaccess を適切なものに書き換え、 apache の設定で suexec を有効にして下さい。 例 AuthName ByPassword AuthType Basic AuthUserConfig "/usr/local/etc/fml/ドメイン/htpasswd" require valid-user (当たり前ですが)この .htaccess ファイルを消すと、 誰でもアクセスできるようになります。 デバッグする場合は便利ですが、そういう裏技は使わないようにしましょう;-) また、そういう「デバッグだけだから、ちょっとだけ…」という時にかぎって、 そのまま再設定し忘れたりするものなので、 そういう流儀に慣れないようにしてください。 きちんと .htaccess を設定しましょう。 この CGI は、あるドメイン全体を操作できる権限を与えています。 「ＭＬを管理する権限を与えても良いけれど、 でも Unix のコマンドラインを使うのがちょっとつらい」 という人を想定したものです。 よって、ＭＬの作成などができるわけですが、 makefml のすべての機能が使えるわけでもありません。 CGI の画面を見るとわかる通り、 CGI で可能な項目は makefml の部分集合となっています。 利用可能なコマンドは最初の画面にヘルプとして表示されているものだけです。 例: CGI トップ画面 @home.fml.org CGI for configuration fml admin menu fml CGI interface for @home.fml.org ML's mailing list: [elena] 左のナビゲーションバーから、ＭＬ(mailing list)とコマ command: ンド(command)を選択し、 submit ボタンを押して下さい [subscribe ] 。 [submit][reset] subscribe アドレスの追加 unsubscribe アドレスの削除 addadmin リモート管理者アドレスの追加 byeadmin リモート管理者アドレスの削除 options Language: list アドレスリストを見る [Japanese] [change] log ログを見る newml ＭＬの作成 rmml ＭＬの削除 なお、画面の左下もしくは右にヘルプメッセージが表示されるので 操作の際には、それを参考にして下さい。 もちろんコマンドごとにメッセージは異なります:) 左の画面のコマンドで newml を選択し、 submit ボタンを押して下さい。 ML 名を選択する必要はありません:) 中央に、ＭＬ名の入力をうながす画面が現れるので、 作成するＭＬ名を入力し、中央の submit ボタンを押して下さい。 左の画面のコマンドで ML 名と subscribe を選択し、 submit ボタンを押して下さい。 中央に、アドレスの入力をうながす画面が現れるので、 登録したいアドレスを入力し、 中央の submit ボタンを押して下さい。 config.cgi では TABLE と SELECT が基本です。 もう少し、昔風の画面にしたいなら、menu.cgi のほうを使ってみて下さい。 そのドメインのＭＬ全部の管理者用 ~fml/public_html/fml/ドメイン/admin/menu.cgi ＭＬごとの管理者用 ~fml/public_html/fml/ドメイン/ml-admin/menu.cgi TODO: cookie で設定を覚えておくようにしようと考えています。 &fml8; を使ったＭＬへの入会/退会(subscribe/unsubscribe)は、 もともと メールベースのシステム です。 このコマンドメールによる入会/退会(subscribe/unsubscribe) の最初のフェイズだけは CGI でも出来るようにしました。 CGI だけで入会/退会が出来るとセキュリティ面でもよろしくないので、 (1) 最初だけは CGI から申請、 (2) メールで confirmation を送る、 (3) メールで confirmation が返ってきたら OK としています (もちろん、これ以上 HTTP をつかった高度なものにする予定もありません)。 何のことはない、 最初のところが 「subscribe というメールを出して下さい」 から 「この CGI でメールアドレスを入力して下さい」 に変わっただけですね？ なお、 この CGI には、SPAM よけの”おまじない”として、 メールアドレスを魔法の文字列の２つをセットで入力してもらうようにしてあります。 「ゆがんだ文字列を認識できるのは機械ではなく人間に違いない」 (image verification)です。 ま、気休めですけどね。 どうせ、このあとメールによる confirmation もあるので、 このおまじないの精度は気にしないでください。 しょせん CGI など、 メールによる confirmation システムの wrapper にすぎないという位置付けです。 CGI 単体では動作させません。 そのため、一般ユーザ用の CGI は、 すべてのこの image verification で申請を出してもらうようにして、 パスワード認証などといった面倒なシステムは廃しています。 ユーザにパスワードを入れさせるＭＬシステムもありますが、 私はパスワードを覚えていたためしがありません。 あんな仕様は危ないだけです。 一般ユーザがＭＬ関連の操作をすることは数カ月から数年に一回しかありません。 だから、パスワードを設定しても次回まで覚えていることがないのです。 また、そういったシステムでは、パスワードを忘れた場合に再送を依頼すると、 メールで平文パスワードが送られてきたりする始末です。 分かりにくいパスワードといえど、 たいてい個人情報を元にした連想だったりします。 パスワードが平文でやりとりされるのは単体で危険といえるばかりでなく、 それ以外のシステムへの危険性を増します。 毎日つかうようなシステム もちろんパスワード認証システムは、 定期的に変えるよう強制もされることが望ましい。 でないかぎり、パスワード認証法はセキュリティホールを作るだけです。