<!-- -*- mode:text coding:euc-jp -*-
   $FML: chapter.onhost.sgml,v 1.18 2008/08/19 07:11:02 fukachan Exp $
-->


<chapter id="usage.onhost">
	<title>
	ＭＬサーバ上でコマンドを使うと(ＭＬ管理者に)できること
	</title>

<para>
「ＭＬサーバ上でコマンドを使う」
というのは、
「ＭＬサーバ」へ SSH (Secure Shell) でログインし、
makefml (/usr/local/bin/makefml)
コマンドもしくは
fml (/usr/local/bin/fml)
コマンドを使い、
&fml8; の設定変更をするという操作を意味しています。
</para>

<para>
makefml の基本的な使い方は &fml4; の makefml と同様です。
できるだけ &fml4; と同じ使い勝手になるように、
つまり互換性を保つように努力しています。
</para>

<para>
相違点についての詳細は
<link linkend="changes.cui">
『<xref linkend="changes.cui">』
</link>
を参照してください。
</para>


<sect1 id="usage.onhost.priviledge">
	<title>
	ホスト上でできること、その権限について
	</title>

<para>
makefml を使う操作は確認(confirmation)が不要です。
たとえば、
メンバーの登録は、コマンドを実行すると、そのまま処理が行なわれます。
これが許されるのは
makefml を実行できる時点で、
つまりそのサーバにログインできる時点で、
特権的なユーザであることが証明されているからです。
</para>

<para>
「正しくサーバが構築されている」ことが大前提です
(これは &fml8; とは直接の関係がないので説明しません)。
</para>

<para>
ＭＬサーバのホストに入ることができる(例: ssh してシェルが取れる)人は、
ＭＬにとって最強の権限を持つ人を意味します。
ファイルを直接編集することで、どんなことでもできるわけですから、無敵です。
つまり特権的な操作が可能な状態です。
</para>

<para>
しかしながら、
人間まちがいを犯すもので、ついファイルのフォーマットを間違えたりします。
</para>

<para>
そのためファイルの直接編集などはせずに、
通常は「makefml (/usr/local/bin/makefml )コマンドを使うことで
&fml8; の設定を変更してください」という運用ポリシーが推奨されています。
もちろんファイルを編集してもかまいませんが、
その場合、内部構造などをよく理解して操作してください。
</para>

<para>
なお、fml コマンドは引数の順番の異なる makefml 同等品です。
<screen>
makefml コマンド ＭＬ名 オプション
fml     ＭＬ名 コマンド オプション
</screen>
コマンドの中身/動作は同じですので、
シンタックスの好き嫌いで、どちらかを選んで使ってください。
</para>

</sect1>


<sect1 id="usage.commandpolicy">
	<title>
	コマンドを用意する基準
	</title>

<para>
&fml8; では、機能ごとに個別にコマンドを用意するようにしていますが、
どうも、このポリシーでは、やたらと多くなるだけのようです。
「できるだけ分離せずに makefml に統合するべき」でしょう。
そこで、以下のような基準に基づき用意することにしています(2003/03 記)。
<quote>
makefml に統合してある方が
admin コマンドや
CGI でも使えるようになりうるので、
再利用性が高く有益です。
</quote>
</para>


<sect2>
	<title>
	特定のＭＬに操作を施すコマンド (read/write)
	</title>

<para>
特定のＭＬに対し、
何らかのデータを見るだけでなく変更/書き込み操作をする可能性があるなら、
makefml (or fml) のコマンドとして実装します。
<screen>
makefml コマンド ＭＬ名 オプション
fml     ＭＬ名 コマンド オプション
</screen>
</para>

</sect2>


<sect2>
	<title>
	特定のＭＬのデータを見るコマンド (read only)
	</title>

<para>
特定のＭＬに対し、データ(ログや何かのサマリ)を見るだけでも、
makefml (or fml) のコマンドとして実装しましょう。
<screen>
makefml コマンド ＭＬ名 オプション
fml     ＭＬ名 コマンド オプション
</screen>
</para>

</sect2>


<sect2>
	<title>
	データを見るだけのコマンド (read only)
	</title>

<para>
特定のＭＬと関わりのないコマンドがあり得ます。
たとえば、
モジュールのドキュメントを見るとか、
OS のアカウントやエイリアス一覧を表示させる類のものです。
これは fml が頭文字につくコマンドを別途用意します。
<screen>
fmladdr	 [-n]
fmlalias [-n]
fmldoc   モジュール名
fmlconf  [-n] $ml
</screen>
(ん〜 fmlconf だけ意味が違うか…)
</para>

</sect2>


<sect2>
	<title>
	ＭＬごとの操作だが、単なるコマンドの wrapper
	</title>

<para>
PGP / GPG コマンドの操作コマンド(例: fmlpgp)が、これにあたります。
でも、いいのか、この基準は…
</para>

<para>
実は、下請けのコマンドに渡すオプションを指定する必要があるので、
オプション解析の段階で困ってしまいます。
&fml8; のオプションは解析し、
下請けのコマンドに渡すオプションは解析していはいけません。
「コマンドラインオプションなどを一切考えない特殊なモード」を作り込めば
makefml に移すことが出来ないわけではないはずですが、こまりました。
</para>

</sect2>


<sect2>
	<title>
	操作を施すコマンドだが、
	特定のＭＬとの関わりはないかも知れないタイプ (read / write ?)
	</title>

<para>
これが一番困るケースのような気がしますが、どうしても作る必要があるなら、
fml が頭文字につくコマンドを別途用意します。
</para>

<para>
例: 記事のスプールを HTML 化する。
<screen>
fmlhtmlify [-I DIR] $src_dir $dst_dir
</screen>
ちなみに
この例は
fml に限定されず、ソースが MH フォルダなどでもかまいませんよね。
ちょっと特殊例です。
</para>

</sect2>


</sect1>


<sect1 id="usage.command.line.options">
	<title>
	共通のコマンドラインオプション
	</title>

<para>
libexec/ と bin/ にあるプログラム群(.cgi は除く)
すべてに共通するコマンドラインオプションは
<screen>
--debug
--help
-c file
-o key=value
</screen>
の４つです。
-c はデフォルトではない main.cf のパスを指定する際に使います。
また、-o により変数(config.cfで指定する変数)の上書きが可能です。
-o は複数回、使っても問題ありません。
<screen>
-o key1=value1 -o key2=value2
</screen>
</para>

</sect1>


&sect.usage.makefml;
&sect.usage.fml;
&sect.usage.fmladdr;
&sect.usage.fmlalias;
&sect.usage.fmlconf;
&sect.usage.fmldoc;
&sect.usage.fmlhtmlify;


<sect1 id="usage.recipes">
	<title>
	レシピ’s
	</title>

<!-- TABLE_OF_RECIPES -->
&sect.usage.onhost.recipes;

</sect1>


</chapter>
