余談: 現在の第五世代 fml.org サーバ群のＭＬは、 すべてバーチャルドメインとして運用しています。 この方式が統一が取れていて美しいです。 はじめは一つでも、だんだんドメインが増えていくのはよくあることで、 それを考えると、 はじめからバーチャルドメインで統一しておくと扱いやすいと思います。 2003/11: バーチャルドメインの取り扱い方を拡張しました。 /usr/local/fml/etc/main.cf における virtual_maps は obsolete となりま した。今後は virtual_maps の代わりに ml_home_prefix_maps を使うことに なります。しかしながら、互換性のため virtual_maps も引続き有効です( なんのことはない、互換性のため、 ml_home_prefix_maps の定義に virtual_maps も含めているというだけのことです。 Postfix の virtual_maps と virtual_alias_maps の関係みたいな感じ)。 また、makefml および fml コマンドには ml_home_prefix_maps を操作する newdomain と rmdomain コマンドが 創設されました。 「 &fml8; 全体でドメインを統一的に扱えるようにしたい。 また、できるだけ &fml4; の素直な拡張であってほしい。 さらに、引越しなどが出来るだけ楽であると嬉しい。 」 これがバーチャルドメインを設計する上での主要な条件でした。 まずＭＬ名には「ユーザ＠ドメイン」形式の文字列 ＠ドメインがない場合は、デフォルトドメインと解釈します。 素直ですよね？ を使うことにします。 これでデフォルトのドメインかバーチャルドメインかを &fml8; が解釈するこ とが可能です。 ＭＬ名以外は従来のコマンド体系そのままです。 新ドメインのＭＬを作る際の最初の一回だけは「ドメインとパス」のあいだの設定を 仕込まないといけないので、MTA への追加設定が必要になりますが、 それ以外はデフォルトドメインの場合と同様に操作可能です。 素直な拡張になっていると思うのですが、どうでしょうか？ 新たに、あるドメインを使いはじめる時、 最初に newdomain コマンドを実行して下さい。 このコマンドは ml_home_prefix_maps (正確には primary_ml_home_prefix_map)を適宜、編集してくれます。 この後は &fml4; と同様に makefml (or fml) コマンドを使ってください。 ただし、makefml (or fml)コマンドを使う際には、 ＭＬ名を「ユーザ＠ドメイン」形式で指定するところが異なります。 注意して下さい。 なお、デフォルトのドメインの場合には＠ドメインが省略可能です。 つまり、この場合に限り &fml4; と同じ形式に戻るというわけです。 たとえば、コマンドの操作はＭＬではなく、ＭＬ＠ドメイン名を使うことにな ります。つまりコマンドの使い方は makefml newml ML@virtualdomain makefml add ML@virtualdomain address makefml bye ML@virtualdomain address などといったぐあいになります。 なお、CGI での操作ではドメイン名の指定が不要です。これは、config.cgi 生成時にドメイン名をスクリプト中に埋め込んでいるためです。画面にもドメ イン名が出ているはずですし、そもそも URL にドメイン名が入っている http://lists/~fml/cgi-bin/fml/$domain/admin/config.cgi ので、どのドメインの操作をしているのかはわかっているはずです。 なお、CGI の URL にドメイン名が入っているのは、操作する人にとって分か りやすいようにという配慮であって、CGI が URL を元に自分の操作対象ドメ イン名を決めているわけではありません(それは危険です)。 ＭＬ名やドメイン名は newml 時に作成される .cgi スクリプトにハードコー ディングされています。 URL のドメインや環境変数を CGI スクリプトは無視します。 ハードコーディングされた設定だけを見ます。 CGI 実行時に、ユーザが HTTP 経由で操作対象を変更することは出来ません (させません)。 FML.ORG で第四世代から第五世代サーバへ引越しをした時の記録を参考資料と してまとめておきます。 結論から言えば、&fml4; → &fml8; コンバータは使いませんでした。 すべてをコピーして MTA 用の設定を生成しました (include の類は強制上書きしました)。 (1) 新サーバを用意します。 ホスト名は今まで使ったことのない新しいものをつけました。 この段階では、 新サーバではインターネットからのメールを受け付けないようにして下さい。 (2) Postfix は localhost と新ホスト名だけを mydestination として受けと るように設定します。かつて使ったことのあるドメインすべてをバーチャルド メインとして処理するためです。 (3) 旧サーバの Postfix を停止し、新たにメールを受け付けないように設定 しておいてください。 そしてキューをフラッシュしつくします。残っているキューを調べＭＬ宛のも のがないことを確認します(mailq と postcat、削除するなら postsuper も使 う)。ps で走っているプロセスがないか？も確認して下さい。 旧サーバで処理されるべきメール(fml へ入力する方向のメール)がすべてなく なった、つまりＭＬの更新がいっさいなくなったことに自信ができたら次のス テップへ進みます。 (4) 旧サーバから新サーバへＭＬ全体(/var/spool/ml 相当)をコピーします。 時間をかけないために、もちろん事前にコピーがしてあり、最後の差分だけを コピーするということです(たとえば rsync を使って行なってください)。 (5) ＭＬのパスを再配置します。 ベースディレクトリ/ドメイン名/ＭＬ名 として、ドメイン名がはっきり分かるようにしました。 (6) ドメインごとにＭＬの設定を再生成します。 % su root # makefml newdomain ドメイン名 ベースディレクトリ/ドメイン名 # suspend % makefml --force newml ＭＬ名１ % makefml --force newml ＭＬ名２ ... 必要なもの全部 ... config.cf include ファイル群、ＭＴＡ用の設定ファイルが生成されます。 デフォルト値と異なる設定のＭＬは config.cf を編集してください。 (7) ドメインごとに Postfix の alias_maps と virtual_maps へ設定を追加 し、動作確認をします。 (8) ドメインの数だけ (6)(7) を繰り返します。 (9) ローカルでテストをして問題がないようなら、 新サーバでインターネットからのメールを受け付けるようにします (/etc/postfix/main.cf の inet_interfaces か /etc/postfix/master.cf を 編集し、念のため postfix reload ではなく postfix stop して postfix start)。 これで終りです。奇麗になりましたね。 なお、WWW アーカイブの作りなおしとか必要なら、さらに作業が続きます。 本ドキュメントの該当する記述を参照して下さい。