<!--
   $FML: chapter.sgml,v 1.7 2008/08/15 02:41:15 fukachan Exp $
-->


<chapter id="virtualdomain">
	<title>
	バーチャルドメインの取り扱いについて
	</title>

<para>
余談:
現在の第五世代 fml.org サーバ群のＭＬは、
すべてバーチャルドメインとして運用しています。
この方式が統一が取れていて美しいです。
はじめは一つでも、だんだんドメインが増えていくのはよくあることで、
それを考えると、
はじめからバーチャルドメインで統一しておくと扱いやすいと思います。
</para>

<caution>

<para>
2003/11: バーチャルドメインの取り扱い方を拡張しました。
</para>

<para>
/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 の関係みたいな感じ)。
</para>

<para>
また、makefml および fml コマンドには
ml_home_prefix_maps を操作する newdomain と rmdomain コマンドが
創設されました。
</para>

</caution>


<sect1 id="virtualdomain.fml8.motif">
	<title>
	バーチャルドメインのデザインモティーフ
	</title>

<para>
「
&fml8; 全体でドメインを統一的に扱えるようにしたい。
また、できるだけ &fml4; の素直な拡張であってほしい。
さらに、引越しなどが出来るだけ楽であると嬉しい。
」
これがバーチャルドメインを設計する上での主要な条件でした。
</para>

<para>
まずＭＬ名には「ユーザ＠ドメイン」形式の文字列
<footnote>
<para>
＠ドメインがない場合は、デフォルトドメインと解釈します。
素直ですよね？
</para>
</footnote>
を使うことにします。
これでデフォルトのドメインかバーチャルドメインかを &fml8; が解釈するこ
とが可能です。
</para>

<para>
ＭＬ名以外は従来のコマンド体系そのままです。
</para>

<para>
新ドメインのＭＬを作る際の最初の一回だけは「ドメインとパス」のあいだの設定を
仕込まないといけないので、MTA への追加設定が必要になりますが、
それ以外はデフォルトドメインの場合と同様に操作可能です。
</para>

<para>
素直な拡張になっていると思うのですが、どうでしょうか？
</para>

<!--
<para>
また、
引越しやディレクトリ名の変更を楽に行なうコマンドを用意する予定です。
</para>
-->

</sect1>


<sect1 id="virtualdomain.fml8.overview">
	<title>
	概要: &fml8; におけるバーチャルドメインの取り扱い
	</title>

<para>
新たに、あるドメインを使いはじめる時、
最初に newdomain コマンドを実行して下さい。
このコマンドは
<link linkend="install.virtual">
ml_home_prefix_maps 
</link>
(正確には primary_ml_home_prefix_map)を適宜、編集してくれます。
</para>

<para>
この後は &fml4; と同様に makefml (or fml) コマンドを使ってください。
ただし、makefml (or fml)コマンドを使う際には、
ＭＬ名を「ユーザ＠ドメイン」形式で指定するところが異なります。
注意して下さい。
</para>

<para>
なお、デフォルトのドメインの場合には＠ドメインが省略可能です。
つまり、この場合に限り &fml4; と同じ形式に戻るというわけです。
</para>

<para>
たとえば、コマンドの操作はＭＬではなく、ＭＬ＠ドメイン名を使うことにな
ります。つまりコマンドの使い方は
<screen>
makefml newml	ML@virtualdomain
makefml add	ML@virtualdomain	address
makefml bye	ML@virtualdomain	address
</screen>
などといったぐあいになります。
</para>

<para>
なお、CGI での操作ではドメイン名の指定が不要です。これは、config.cgi 
生成時にドメイン名をスクリプト中に埋め込んでいるためです。画面にもドメ
イン名が出ているはずですし、そもそも URL にドメイン名が入っている
<screen>
http://lists/~fml/cgi-bin/fml/$domain/admin/config.cgi
</screen>
ので、どのドメインの操作をしているのかはわかっているはずです。
</para>

<warning>
<para>
なお、CGI の URL にドメイン名が入っているのは、操作する人にとって分か
りやすいようにという配慮であって、CGI が URL を元に自分の操作対象ドメ
イン名を決めているわけではありません(それは危険です)。
</para>

<para>
ＭＬ名やドメイン名は newml 時に作成される .cgi スクリプトにハードコー
ディングされています。
URL のドメインや環境変数を CGI スクリプトは無視します。
ハードコーディングされた設定だけを見ます。
</para>

<para>
CGI 実行時に、ユーザが HTTP 経由で操作対象を変更することは出来ません
(させません)。
</para>

</warning>

</sect1>


<sect1 id="virtualdomain.movement">
	<title>
	ケーススタディ: FML.ORG サーバ間引越の例
	</title>

<para>
FML.ORG で第四世代から第五世代サーバへ引越しをした時の記録を参考資料と
してまとめておきます。
</para>

<para>
結論から言えば、&fml4; → &fml8; コンバータは使いませんでした。
すべてをコピーして MTA 用の設定を生成しました
(include の類は強制上書きしました)。
</para>

<para>
(1) 新サーバを用意します。
ホスト名は今まで使ったことのない新しいものをつけました。
この段階では、
新サーバではインターネットからのメールを受け付けないようにして下さい。
</para>

<para>
(2) Postfix は localhost と新ホスト名だけを mydestination として受けと
るように設定します。かつて使ったことのあるドメインすべてをバーチャルド
メインとして処理するためです。
</para>

<para>
(3) 旧サーバの Postfix を停止し、新たにメールを受け付けないように設定
しておいてください。
</para>

<para>
そしてキューをフラッシュしつくします。残っているキューを調べＭＬ宛のも
のがないことを確認します(mailq と postcat、削除するなら postsuper も使
う)。ps で走っているプロセスがないか？も確認して下さい。
</para>

<para>
旧サーバで処理されるべきメール(fml へ入力する方向のメール)がすべてなく
なった、つまりＭＬの更新がいっさいなくなったことに自信ができたら次のス
テップへ進みます。
</para>

<para>
(4) 旧サーバから新サーバへＭＬ全体(/var/spool/ml 相当)をコピーします。
時間をかけないために、もちろん事前にコピーがしてあり、最後の差分だけを 
コピーするということです(たとえば rsync を使って行なってください)。
</para>

<para>
(5) ＭＬのパスを再配置します。
<screen>
ベースディレクトリ/ドメイン名/ＭＬ名
</screen>
として、ドメイン名がはっきり分かるようにしました。
</para>

<para>
(6) ドメインごとにＭＬの設定を再生成します。
<screen>
% su root
# makefml newdomain ドメイン名 ベースディレクトリ/ドメイン名
# suspend
% makefml --force newml ＭＬ名１
% makefml --force newml ＭＬ名２
   ... 必要なもの全部 ...
</screen>
config.cf include ファイル群、ＭＴＡ用の設定ファイルが生成されます。
デフォルト値と異なる設定のＭＬは config.cf を編集してください。
</para>

<para>
(7) ドメインごとに Postfix の alias_maps と virtual_maps へ設定を追加
し、動作確認をします。
</para>

<para>
(8) ドメインの数だけ (6)(7) を繰り返します。
</para>

<para>
(9) ローカルでテストをして問題がないようなら、
新サーバでインターネットからのメールを受け付けるようにします
(/etc/postfix/main.cf の inet_interfaces か /etc/postfix/master.cf を
編集し、念のため postfix reload ではなく postfix stop して postfix start)。
</para>

<para>
これで終りです。奇麗になりましたね。
</para>

<para>
なお、WWW アーカイブの作りなおしとか必要なら、さらに作業が続きます。
本ドキュメントの該当する記述を参照して下さい。
</para>

</sect1>


<!--
<para>
ドメインの変更は考えなくても良いか？
ドメインの変更なんてそんなにあるか？
変更するならＭＬも作りなおすような気がする（嘘？）。
いずれにせよ、ドメインの移行はいっぱい直すところが
あるので、そんなに簡単じゃない。
</para>

<para>
ホストを新しくするか？
うむ、これは割とありそうだ。
</para>

<para>
解決しないといけない問題はディレクトリのパスが変わること。
/usr/local/etc/fml/ の変更だけで解決できないか？

いや、include ファイルがこんな風になっているが、
<screen>
"| /some/where/libexec/distribute elena@fml.org"
</screen>
書式変更が必要ではないのか？
</para>

<para>
4.0 から 8.0 へは？ mergeml コマンドがある。
</para>

<para>
一応、fml.pl は互換性のため fml.pl $DIR も可で、
libexec/distribute libexec/command など新しいコマンドは
ＭＬ名を引数にとるということにしてある。
</para>

-->


</chapter>
