通常使用時には に `-C ' Ar maxClients オプションを指定して実行しなければなりません。 はバッググラウンドデーモンとして実行され、 リモートクライアントからの接続要求に対応します。それぞれの接続について は子プロセスを fork し、クライアントが要求したファイルを送ります。
以下のオプションがサポートされています:
このオプションが指定されていない場合、 はフォアグラウンドで動作して 1 クライアントに対してのみサービスを行い、 それが終わると終了します。
cvsupd -e ... >>/var/tmp/cvsupd.out 2>&1ただし、このコマンドラインでは sh(1) の表記を使っています。
サービスを受ける各クライアントについて、少なくとも 2 つのメッセージが 記録されます。最初のメッセージはユーザ名とホスト名でクライアントを 識別します。最後のメッセージは更新の成功・失敗と、合計のネットワーク I/O の量をキロバイト単位(1K = 1024)で報告します。エラーやその他の知らせる べき状態を知らせるために、この 2 つ以外のメッセージが送られることがあ ります。
各コレクションの設定ファイルは、 base / collDir 下に作ったコレクション名と同名のサブディレクトリに個別に置かれます。 例えば `src-base' コレクションの設定ファイルは base / collDir /src-base に置かれます。 コレクションのサブディレクトリ中には、 releases ファイルとリストファイルが置かれます。 releases ファイルはリリースごとに一行の記述を含みます。 各行の最初の語はリリース名です。例えば `cvs' となります。 その後には、順不同で以下のようなフレーズが続きます:
このキーワードは省略してもかまいません。省略された場合には、 は現在のコレクションと利用可能な他のコレクションの間に 何の関連もないとみなします。
super キーワードから得た情報は、サーバがミラーサイトとして動作している時に、 適切な scan ファイルを見つけるために使われます。 Sx CVSup を使ったミラーサイトの運用 をご覧ください。
認識できないキーワードは受け付けられますが、無視されます。 これは sup(1) パッケージとの後方互換性のためです。 が提供するリリースが 1 つだけであっても、 releases ファイルは必要であることを覚えておいてください。
リストファイルは、クライアントのコレクションのバージョンを更新する方法 を詳しく指定します。 各行には 1 つだけコマンドが書かれます。空行と `#' から始まる行は無視されます。 指定される全てのファイル名は releases 内で指定されている prefix ディレクトリからの相対パスとして扱われます。
リストファイルのコマンドの多くは、ファイル名のパターンを引数として 受け付けます。 このパターンは sh(1) が受け付けるパターンに似ており、 `*' , `?' , `[...]' を組み合わせたワイルドカードが使えます。 omitany パターンだけは例外ですが、その他の場合には、ファイル名に含まれる スラッシュ文字は、パターン中のスラッシュ文字とだけマッチします。 例えば `*' は `.prifole' というファイル名にマッチします。
omitany に対するパターンの解釈は他のパターンと異なります。 一般のパターンでは、パス名に含まれるスラッシュ文字はパターン中の スラッシュ文字にのみマッチしますが、 omitany に与えるパターンでは、スラッシュ文字は他の文字と同じように扱われます。 したがって、 `*.c' は `.c' で終わるすべてのパス名にマッチします。例えば `foo/bar/lam.c' も含まれます。
空白文字で区切って複数のパターンを指定することができます。 それらのファイルは prefix ディレクトリからの相対パスとして解釈されます。 それぞれのパターンは、ファイルが server 上に存在する場合でも適切なファイルにマッチするように記述しなければなり ません。 例えば RCS ファイル名の `,v' サフィックスは、たとえチェックアウトモードの結果としてクライアント上にそ のサフィックスが存在しない場合でもマッチしなければなりません。 ファイル名に含まれるスラッシュ文字は、パターン中のスラッシュと正確に一 致しなければなりません。 CVS の `Attic' ディレクトリはマッチングの処理に暗黙的に含まれるで、パターン中で直接指 定してはいけません。 マッチするファイルは、それが Attic かどうかに関わらず発見されます。
execute 文がディレクトリにマッチした場合、コマンドが実行されるのは、 ディレクトリが新規に作成されたとき、またはディレクトリの属性が変更され たときです。 コマンドはディレクトリから上ったとき、つまりそのディレクトリ内の ファイルとサブディレクトリの処理が終わった後に実行されます。
複数の execute 文が 1 つのファイルにマッチした場合、全ての関係するコマンドが順に実行 されます。
セキュリティ上の理由で、クライアントは全ての execute 文を無視するかもしれません。
認識できないコマンドは受け付けられますが、無視されます。これは sup(1) との後方互換性のための動作です。
には、ミラーサイトの効率を劇的に向上させるための特殊な動作モードがあり ます。このモードはコマンドラインで -s scanDir オプションを指定すると有効になります。 -s オプションを指定しないと、 は要求された各コレクションのファイルに対してファイルツリー全体を調 べて、全てのファイルについて stat(2) システムコールを実行します。この動作は接続した全てのクライアントに対し て行われます。どのファイルがいつ変更されるか分からないからです。このよ うな調べ方をするとファイルを持っているディスクに対してシークの負荷が大 きくかかり、同時にサービスを受けられるクライアントの数が制限されること になります。
ミラーサイトの場合には、コレクション内のファイルが更新されるのは新しい バージョンを CVSup 経由で受け取る時だけであることが分かっています。 -s オプションを使うと、 はこの性質を生かして、ファイルツリーの調査を全く行わずにすみます。 そのため、サーバのディスク負荷は大幅に削減されます。ファイルツリーを調 べる代わりに、 はコレクション内のファイルに関する必要な情報を scan ファイルを読むことによって取得します。scan ファイルは、 cvsup クラアイントがミラーサイト上のファイルをマスターサイトにあるオリジナル のデータを使って更新する際に、クライアントが作成します。 CVSUP(1) では、これらのファイルは list と書かれています。どちらの呼び方でも同じファイルを指しています。 はクライアントにサービスする際は毎回、最後のマスターサイトからの更新の ときに生成された scan ファイルを見つけます。したがって、サーバは コレクション内にあるファイルに関する最新の情報を常に持っており、 ファイルツリーを調べる必要はありません。
-s オプションの後には、scan ファイルがあるディレクトリ名を指定します。こ れは普通、起点ディレクトリのサブディレクトリであり、 cvsup クライアントがリストファイルを管理している場所と一致していなければなり ません。デフォルトでは、 cvsup は起点ディレクトリのサブディレクトリである sup にこれらのファイルを置きます。これに合わせるには、 は `-s' sup で実行しなければなりません。 -c オプションによって cvsup のリストファイルの位置がデフォルト値から変更されている場合、 の scan ディレクトリも同じように変更しなければなりません。 -s オプションにはデフォルト値はありません。コマンドラインで明示的に指定し ていなければ、scan ファイルは全く使われません。
全てのコレクションに対して scan ファイルが存在する必要はありません。 はまずクライアントが要求したコレクションについて scan ファイルを探しま す。その scan ファイルが存在しなければ、 は順にスーパーコレクションの scan ファイルを探していき、最初に見つかっ た scan ファイルを使います。 (詳しくは Sx ファイルコレクションレポジトリを準備する で説明されている super キーワードの説明を参照してください。) 適切な scan ファイルがなければ、 は最終的にファイルツリーを全て調べます。
それぞれの規則は以下の要素からなります:
ホスト名は読み込まれる時に数値アドレスに変換されます。 ホストが複数個のアドレスを持っている場合、それぞれのアドレスに対する 規則が個別に追加されます。これは望み通りの動作をするかもしれませんし、 そうでないかもしれません。
ホスト名は注意して使うべきです。解決に時間がかかる名前があると、 サーバの動作が著しく遅くなるからです。
クライアントがサーバに接続した際、クライアントの IP アドレスは 規則に対して順番にチェックされていきます。 それぞれの規則は以下のように処理されます:
リストの最後には、どんな IP アドレスにもマッチする 認証 規則が暗黙的に置かれています。したがって、アクセスが許可も拒否もされず に処理が終わった場合は、アクセスは認証機構によって制御されます。
規則の一般的な使用方法の例を以下に示します。
-spam.cyberpromo.com特定のホストからのアクセスを全て拒否します。
+mirror.FreeBSD.org特定のホストからのアクセスを無制限に許可します。
-user.FreeBSD.org 1特定のホストからの同時接続を 1 つだけに制限します。
-198.211.214/24特定のクラス C アドレスのホストからのアクセスを拒否します。
-198.211.214/24 3特定のクラス C アドレスのホストからの同時アクセスを、 合計 3 つまで許可します。
-198.211.214/24/32 3特定のクラス C アドレスに含まれるホストからの同時アクセスを、 ホストごとに合計 3 つまで許可します。
上記 2 つの例の違いに注意してください。 前者の例はネットワークごとの制限を行い、後者の例はホスト単位の制限を行っ ています。両者の相違点は counting マスクです。最初の例はマスクが 24 ビットなので、指定したアドレスブロッ クに含まれる全てのホストについて共通のカウンタが作られます。後者の例は マスクが 32 ビットなので、ホストごとに別々のカウンタが作られます。
-0.0.0/0/24 1各アドレスブロック(アドレス 256 個)からの同時接続をそれぞれ 1 つだけ 許可します。
*0.0.0.0/0全てのクライアントについて、認証を行ってアクセスを許可するかどうかを決 めます。
アクセス制御ファイルを更新する際にサーバを止める必要はありません。 しかし、編集の際にはコピーを取って別の場所で編集し、それからアトミック に新しいファイルに置き換えるべきです。ファイルを更新した後にサーバに シグナルを送る必要はありません。サーバはファイルが触られたことを 検出し、再読み込みを自動的に行います。 さらに、サーバは 3 時間ごとにファイルを再読み込みします。 これは DNS の変更で解決されるホスト名が変わるかもしれないので、これに 対応するためです。
個々の規則における文法違反はログに記録され、違反している規則は無視され ます。ホスト名解決の失敗もログに記録されます。
クライアントの認証は base /cvsupd.access ファイル内の 認証 規則が成功するか、 ``規則が適用されないままファイル末尾まで来た'' 場合に呼び出されます。 cvsupd.access が存在しない場合はクライアントの認証は行われません。
base /cvsupd.passwd ファイルには認証時に使う情報が入っています。このファイルには、 サーバへのアクセスが許可されたクライアントについてのレコードが書かれて います。ファイル中では 1 行に 1 レコードが書かれます。 `#' で始まる行と、空白文字しか含まない行は無視されます。 ファイル中の別の場所では空白文字は必ず意味を持ちます。フィールドは `:' 文字で区切ります。
ファイルの最初のレコードは特別です。最初のレコードはサーバ自身を表しま す。サーバのレコードは以下の形式になります:
serverName : privateKey
ServerName はサーバのカノニカル名です(例: `CVSup.FreeBSD.ORG' )。 この名前がクライアントに送られ、クライアントはこの名前を使って適切なク ライアント名と、認証のために共有している秘密の文字列を選びます。 この名前では大文字と小文字は区別されません。
PrivateKey は `:' を除く任意の文字からなる文字列です。 サーバがランダムな challenge 文字列を生成してクライアントに送った時、 サーバは推測が困難な challenge 文字列を privateKey を使って作ります。challenge 文字列はランダムであり、まず予測できないの で、 privateKey は実はあまり重要ではありません。そうしたければ空のままでもかまいません が、文字列の前の `:' は必ず必要です。
ファイル中の残り全てのレコードは、個々のクライアントに対応します。 クライアント用のレコードは以下の形となります:
Ar clientName No : Ar sharedSecret No : class : comment
空のフィールドがある場合でも、全てのフィールドが存在しなければなりません。 ClientName はレコードが適用されるクライアントの名前です。慣習では、全ての クライアント名には e-mail アドレスが使われます(例: `BillyJoe@FreeBSD.ORG' )。 クライアント名では大文字と小文字は区別されません。
SharedSecret は、クライアントとサーバだけが知っている秘密の文字列です。 この文字列はクライアントが選んだパスワードから cvpasswd ユーティリティを使って生成されます。 クライアントは sharedSecret を知っていることを示すことにより、自分の身分をサーバに対して証明します (その逆も同じです)。 sharedSecret フィールドを `*' にすることにより、クライアントのアクセスを禁止できます。
共有している秘密の文字列がネットワーク上を流れることはありませんし、 秘密の文字列からクライアントのパスワードを調べることもできません。しか し、共有している秘密の文字列があれば、改造した cvsup を使ってクライアントのふりをすることができるかもしれません。したがって、 cvsupd.passwd 必ずファイルはサーバしか読めないように注意してください。
Class は将来使うために予約しています。空にしてください。
Comment はサーバの管理者が便利なように、クライアントに関する備考が書かれていま す。例えば、クライアントの本名や、別の連絡手段などです。
cvsupd.passwd ファイルを更新する際にサーバを止める必要はありません。 しかし、編集の際にはコピーを取って別の場所で編集し、それからアトミック に新しいファイルに置き換えるべきです。ファイルを更新した後にサーバに シグナルを送る必要はありません。
cvsupd.passwd ファイル中では、個々のレコードの文法違反はログに記録され、違反している レコードは無視されます。
標準 RCS キーワードの別名を定義し、それぞれのキーワードの解釈を選択的に 有効・無効にすることも可能です。 この設定は、 prefix /CVSROOT/options ファイルに書かれているキーワードによって、 レポジトリ全体を単位として制御されます。 1 行には 1 つのキーワードが書かれます。 `#' から行末まではコメントと見なされます。 また空白行は無視されます。 歴史的な経緯のために文法は変てこです。
キーワードの別名を定義するには、次の形式の行を使います :
tag= alias [= keyword ]例えば:
tag=FreeBSD=CVSHeaderは新しい RCS キーワード `$FreeBSD$' を定義し、これは `$CVSHeader$' と同様に展開されます。 二番目の `=' と keyword がない場合、キーワードのデフォルト値は `Id です。 '
選んだ特定のキーワード以外を全て無効にするには、次の形式の行を使います:
tagexpand=i keyword [, ... ]例えば
tagexpand=iFreeBSD,Id と書くと`$FreeBSD$' と `$Id$' 以外の全てのキーワードの展開を行わなくなります。 最初の `i' は ``include'' の意味です。
選択した特定のキーワード以外を全て有効にするためには、次の形式の行を使 います:
tagexpand=e keyword [, ... ]例えば
tagexpand=eFreeBSD,Id と書くと、`$FreeBSD$' と `$Id$' 以外の全てのキーワードの展開を行うようになります。 先頭の `e' は ``exclude'' の意味です。
CVSup は、ネットワーク上を流れるデータの暗号化には対応していません。 機密性が必要であれば、 ssh を使って接続をトンネリングしてください。
http://www.polstra.com/projects/freeware/CVSup/
`Attic' という名前のディレクトリは全て CVS Attic と見なされ、特別な扱いを受けます。