名称

cvsupd — ネットワーク上で CVS レポジトリを配布するためのサーバ

書式

cvsupd [-ev] [-A addr] [-b base] [-c collPath] [-C maxClients] [-l log] [-p port] [-P range] [-s scanDir] [-Z comprLevel]

解説

cvsupd はネットワーク配布のためのパッケージである CVSup のサーバプログラムです。 サーバと組み合わせて動作するクライアントプログラム に関しては cvsup(1) を参照してください。

通常使用時には cvsupd に ‘-C maxClients’ オプションを指定して実行しなければなりません。 cvsupd はバッググラウンドデーモンとして実行され、 リモートクライアントからの接続要求に対応します。それぞれの接続について cvsupd は子プロセスを fork し、クライアントが要求したファイルを送ります。

以下のオプションがサポートされています:

-A addr

サーバが接続を受け付ける(accept)するローカルのアドレス(IP アドレス またはホスト名)を指定します。このオプションは複数個の IP アドレスを持つ ホストで役立つでしょう。

-b base

base を設定ファイルの起点ディレクトリとして使います。 デフォルト値は /usr/local/etc/cvsup です。

-c collPath

提供されるコレクションに関する情報を得るために、指定されたディレクトリを 検索します。 collPath は 1 つのディレクトリ、もしくはコロンで区切った複数のディレクトリを 含みます。 絶対パスで指定されていない場合は、起点ディレクトリからの相対パスと解釈 されます。 デフォルトの検索パスは ‘sup’ です。

-C maxClients

同時に接続できるクライアントの数を maxClients に制限します。 指定した最大数を超えた場合、クライアントはサービスを丁寧に 断わられます。

このオプションが指定されていない場合、 cvsupd はフォアグラウンドで動作して 1 クライアントに対してのみサービスを行い、 それが終わると終了します。

-e

デーモンモードで動作している場合に、標準出力と標準エラー出力への メッセージのリダイレクトを抑制し、syslog を用いてログを記録します。 このオプションを設定しない場合、標準出力と標準エラー出力は /dev/null にリダイレクトされます。 このオプションは、サーバのクラッシュのような滅多にないパニックの際の メッセージを押さえるのに役立ちます。 こういったメッセージはデバッグに非常に有用ですが、それらを syslog に送 るための確実な方法がないためです。 このオプションのお勧めの使い方は次のようなものです:

cvsupd -e ... >>/var/tmp/cvsupd.out 2>&1

ただし、このコマンドラインでは sh(1) の表記を使っています。

-l log

ログメッセージを log に書き出します。 log が @facility (例 ‘@local0’) のような形式で指定された場合、ロギングは指定された facility を使い syslog 経由で行われます。 そうでない場合、 log はログファイルの名前として扱われます。 そのファイルがすでに存在している場合には、新しいメッセージはファイルの最 後に追加されます。

サービスを受ける各クライアントについて、少なくとも 2 つのメッセージが 記録されます。最初のメッセージはユーザ名とホスト名でクライアントを 識別します。最後のメッセージは更新の成功・失敗と、合計のネットワーク I/O の量をキロバイト単位(1K = 1024)で報告します。エラーやその他の知らせる べき状態を知らせるために、この 2 つ以外のメッセージが送られることがあ ります。

-p port

サーバが接続を待ち受ける(listen する) TCP ポートを指定します。 デフォルト値は 5999 です。 パッシブモードでない場合には、サーバからクライアントに向かって張る 2 番目の接続(データ接続と呼ばれます)のために、サーバはこれより 1 つ小さ い番号のポートも使います。

-P range

パッシブモードの時にデータ接続に使うサーバ側の TCP ポートの範囲を指定 します。 範囲 は単一の整数もしくは ‘lo-hi’ の範囲のどちらかの形で指定できます。

-s scanDir

ミラーモードを有効にし、scan ファイルがあるディレクトリを指定します。 scanDir が絶対パスで指定されていなければ、これは起点ディレクトリからの相対パス と解釈されます。後述の CVSup を使ったミラーサイトの運用 をご覧ください。

-v

バージョン番号を表示して終了します。クライアントには何も提供しません。

-Z comprLevel

圧縮レベルを comprLevel に設定します。 圧縮レベルは 0 から 9 の間で指定します。 レベル 0 では圧縮は行われず、9 で圧縮率が最大となります。 デフォルトの圧縮レベルは 1 です。 これよりも高い圧縮レベルを使っても、CPU パワーが大幅に消費される割には ファイルサイズはほとんど改善されません。

ファイルコレクションレポジトリを準備する

cvsupd がクライアントに提供するファイルコレクションは、様々な設定ファイルで記述 します。 設定ファイルは base/colldir ディレクトリ下に置きます。ここで base は -b base コマンドラインオプションで指定されたもの、もしくはデフォルト値の /usr/local/etc/cvsup です。 collDir は -c オプションで指定されたディレクトリのいずれか、もしくはデフォルト値の ‘sup’ です。

各コレクションの設定ファイルは、 base/collDir 下に作ったコレクション名と同名のサブディレクトリに個別に置かれます。 例えば ‘src-base’ コレクションの設定ファイルは base/collDir/src-base に置かれます。 コレクションのサブディレクトリ中には、 releases ファイルとリストファイルが置かれます。 releases ファイルはリリースごとに一行の記述を含みます。 各行の最初の語はリリース名です。例えば ‘cvs’ となります。 その後には、順不同で以下のようなフレーズが続きます:

list=file

リストファイルの名前を、コレクションのサブディレクトリに対する相対パス で指定します。リストファイルについては後ほど説明します。

prefix=directory

コレクションを構成するファイルのある場所を指定します。 もし directory が絶対パスでなければ、起点ディレクトリ base からの相対パスと見なされます。 prefix が指定されていない場合のデフォルト値は base です。

keywordprefix=directory

“仮想プレフィックス” を指定します。これは RCS のキーワードである ‘$Header$’ と ‘$Source$’ を絶対パスに展開するためにのみ用いられます。 普通は、 direcotry はマスターの CVS レポジトリを持っているマシンにおける、その CVS レポジトリの絶対パスです。 keywordprefix を用いると、 CVSup は必ず、 実際のレポジトリの位置によらず全てのマシン上で RCS キーワードを同一の形に展開します。

super=collection

現在のコレクションの直接のスーパーコレクションを指定します。 配布物が大きな場合には、コレクションに階層を持たせてまとめることがよく あります。最も上の階層は、配布されている全てのファイルを含む コレクションです。次の階層はいくつかのサブコレクションからなり、それぞ れは全体のファイルの部分集合となります。 各サブコレクションは自分の下にサブコレクションを持てますし、それ以降も 同様です。 super キーワードは、こういった階層的な配置において、そのコレクションの 親コレクションを指定します。

このキーワードは省略してもかまいません。省略された場合には、 cvsupd は現在のコレクションと利用可能な他のコレクションの間に 何の関連もないとみなします。

super キーワードから得た情報は、サーバがミラーサイトとして動作している時に、 適切な scan ファイルを見つけるために使われます。 CVSup を使ったミラーサイトの運用 をご覧ください。

nocheckrcs

更新される RCS ファイル群について、MD5 チェックサムの比較を行いません。 RCS ファイルにおけるチェックサムの不一致は意味を持ちません。なぜなら、 ある論理的な意味を持った RCS ファイルには、テキストとしての表現はたく さんあるからです。

norcs

RCS ファイルを特別扱いしません。RCS ファイルを他のファイルと同様に扱い ます。

norsync

rsync アルゴリズムを使わないようにします。 注意: このキーワードを releases ファイルで使うのは古いやり方です。これを使わないでリストファイル内で norsync または rnorsync を使ってください(後述)。

認識できないキーワードは受け付けられますが、無視されます。 これは sup(1) パッケージとの後方互換性のためです。 cvsupd が提供するリリースが 1 つだけであっても、 releases ファイルは必要であることを覚えておいてください。

リストファイルは、クライアントのコレクションのバージョンを更新する方法 を詳しく指定します。 各行には 1 つだけコマンドが書かれます。空行と ‘#’ から始まる行は無視されます。 指定される全てのファイル名は releases 内で指定されている prefix ディレクトリからの相対パスとして扱われます。

リストファイルのコマンドの多くは、ファイル名のパターンを引数として 受け付けます。 このパターンは sh(1) が受け付けるパターンに似ており、 ‘*’, ‘’?, ‘[...]’ を組み合わせたワイルドカードが使えます。 omitany パターンだけは例外ですが、その他の場合には、ファイル名に含まれる スラッシュ文字は、パターン中のスラッシュ文字とだけマッチします。 例えば ‘*’ は ‘.prifole’ というファイル名にマッチします。

upgrade pattern ...

与えられたパターンのいずれかにマッチした、すべてのファイルとディレクトリ が更新ド対象のリストに含められます。 ディレクトリ名がマッチした場合、その中にある全てのファイルと サブディレクトリが再帰的に含まれます。

always pattern ...

このコマンドは、全ての omitany コマンドを上書きすることを除いて、 upgrade コマンドと同一です。

omitany pattern ...

与えられたパターンのいずれかにマッチした、すべてのファイルとディレクトリ は更新対象のリストから除外されます。 ディレクトリ名がマッチした場合、その中にある全てのファイルと サブディレクトリが除外されます。

omitany に対するパターンの解釈は他のパターンと異なります。 一般のパターンでは、パス名に含まれるスラッシュ文字はパターン中の スラッシュ文字にのみマッチしますが、 omitany に与えるパターンでは、スラッシュ文字は他の文字と同じように扱われます。 したがって、 ‘*.c’ は ‘.c’ で終わるすべてのパス名にマッチします。例えば ‘foo/bar/lam.c’ も含まれます。

symlink pattern ...

与えられたパターンのいずれかにマッチしたシンボリックリンクは、その シンボリックリンクが指すファイルとしてではなく、シンボリックリンクとし てアップグレードされます。 この指定がない場合、シンボリックリンクのリンク先が参照され、リンクが指 すファイルがクライアントに送られます。

rsymlink pattern ...

このコマンドは symlink に似ていますが、もしディレクトリがマッチした場合、そのディレクトリ ツリー以下のすべてのシンボリックリンクもマッチしたものとして扱われます。

norsync pattern ...

与えられたパターンのいずれかにマッチしたファイルの更新において、rsync アルゴリズムが使われません。この指定はログファイルで役立ちます。 というのも、 cvsupd の “append” 最適化の方が rsync アルゴリズムよりも効率的だからです。

rnorsync pattern ...

このコマンドは norsync に似ていますが、もしディレクトリがマッチした場合、そのディレクトリ ツリー以下の全てのファイルがマッチしたものとして扱われます。

execute command (pattern ...)

pattern の 1 つにマッチするファイルの更新が成功したときに、指定された command がクライアントによって実行されます。 command は、最初の (‘’ までの全ての語からなります。 ‘%s’ という文字列はすべて、クライアントホストで更新されたファイルのパス名に 置き換えられます。 存在する ‘%%’ はすべて ‘%’ に置き換えられます。 コマンドは文字列を /bin/sh に渡すことで実行されます。

空白文字で区切って複数のパターンを指定することができます。 それらのファイルは prefix ディレクトリからの相対パスとして解釈されます。 それぞれのパターンは、ファイルが server 上に存在する場合でも適切なファイルにマッチするように記述しなければなり ません。 例えば RCS ファイル名の ‘,v’ サフィックスは、たとえチェックアウトモードの結果としてクライアント上にそ のサフィックスが存在しない場合でもマッチしなければなりません。 ファイル名に含まれるスラッシュ文字は、パターン中のスラッシュと正確に一 致しなければなりません。 CVS の ‘Attic’ ディレクトリはマッチングの処理に暗黙的に含まれるで、パターン中で直接指 定してはいけません。 マッチするファイルは、それが Attic かどうかに関わらず発見されます。

execute 文がディレクトリにマッチした場合、コマンドが実行されるのは、 ディレクトリが新規に作成されたとき、またはディレクトリの属性が変更され たときです。 コマンドはディレクトリから上ったとき、つまりそのディレクトリ内の ファイルとサブディレクトリの処理が終わった後に実行されます。

複数の execute 文が 1 つのファイルにマッチした場合、全ての関係するコマンドが順に実行 されます。

セキュリティ上の理由で、クライアントは全ての execute 文を無視するかもしれません。

認識できないコマンドは受け付けられますが、無視されます。これは sup(1) との後方互換性のための動作です。

CVSup によるミラーサイトの運営

ミラーサイトとは、 CVSup を用いてマスターのサイトからファイルの取得と更新を行い、 CVSup 経由で他のサイトにファイルを再配布するサーバのことです。ミラーサイトは、 大きなプロジェクトで負荷を複数のサーバに分散するためによく使われます。 配布されるファイルは元々はマスターサイトに置かれます。各ミラーサイトは マスターサイトを基にして、自分が持っているコピーを定期的に更新します。 次に、クライアントはミラーサイトのどれかから更新分のファイルを取得しま す。

cvsupd には、ミラーサイトの効率を劇的に向上させるための特殊な動作モードがあり ます。このモードはコマンドラインで -s scanDir オプションを指定すると有効になります。 -s オプションを指定しないと、 cvsupd は要求された各コレクションのファイルに対してファイルツリー全体を調 べて、全てのファイルについて stat(2) システムコールを実行します。この動作は接続した全てのクライアントに対し て行われます。どのファイルがいつ変更されるか分からないからです。このよ うな調べ方をするとファイルを持っているディスクに対してシークの負荷が大 きくかかり、同時にサービスを受けられるクライアントの数が制限されること になります。

ミラーサイトの場合には、コレクション内のファイルが更新されるのは新しい バージョンを CVSup 経由で受け取る時だけであることが分かっています。 -s オプションを使うと、 cvsupd はこの性質を生かして、ファイルツリーの調査を全く行わずにすみます。 そのため、サーバのディスク負荷は大幅に削減されます。ファイルツリーを調 べる代わりに、 cvsupd はコレクション内のファイルに関する必要な情報を scan ファイルを読むことによって取得します。scan ファイルは、 cvsup クラアイントがミラーサイト上のファイルをマスターサイトにあるオリジナル のデータを使って更新する際に、クライアントが作成します。 CVSUP(1) では、これらのファイルは list と書かれています。どちらの呼び方でも同じファイルを指しています。 cvsupd はクライアントにサービスする際は毎回、最後のマスターサイトからの更新の ときに生成された scan ファイルを見つけます。したがって、サーバは コレクション内にあるファイルに関する最新の情報を常に持っており、 ファイルツリーを調べる必要はありません。

-s オプションの後には、scan ファイルがあるディレクトリ名を指定します。こ れは普通、起点ディレクトリのサブディレクトリであり、 cvsup クライアントがリストファイルを管理している場所と一致していなければなり ません。デフォルトでは、 cvsup は起点ディレクトリのサブディレクトリである sup にこれらのファイルを置きます。これに合わせるには、 cvsupd は ‘-s sup’ で実行しなければなりません。 -c オプションによって cvsup のリストファイルの位置がデフォルト値から変更されている場合、 cvsupdの scan ディレクトリも同じように変更しなければなりません。 -s オプションにはデフォルト値はありません。コマンドラインで明示的に指定し ていなければ、scan ファイルは全く使われません。

全てのコレクションに対して scan ファイルが存在する必要はありません。 cvsupd はまずクライアントが要求したコレクションについて scan ファイルを探しま す。その scan ファイルが存在しなければ、 cvsupd は順にスーパーコレクションの scan ファイルを探していき、最初に見つかっ た scan ファイルを使います。 (詳しくは ファイルコレクションレポジトリを準備する で説明されている super キーワードの説明を参照してください。) 適切な scan ファイルがなければ、 cvsupd は最終的にファイルツリーを全て調べます。

アクセス制御

デフォルトの動作ではサーバへのアクセスは制限されていませんが、接続する クライアントの IP アドレスに基づくかなり柔軟な機構があります。この機構は アクセス制御ファイル base/cvsupd.access に規則を書くことによって有効になります。アクセス制御ファイルは テキストファイルであり、1 行に 1 つの規則が書かれます。コメントは ‘#’ で始まり、その行の最後まで続きます。空白文字は無視されますが、隣り合う トークンを区切る場合は除きます。空行は無視されます。

それぞれの規則は以下の要素からなります:

• 規則が 許可(permit) 規則、 認証(authenticate) 規則、 拒否(deny) 規則のいずれであるかを示すフラグ。このフラグは 1 つの文字で表されます: ‘+’ は許可規則、 ‘*’ は認証規則、 ‘-’ は拒否規則を表します。
• クライアントの IP アドレスと比較され、そのクライアントに規則を適用する かどうかが決めるための IP アドレス。これは数値の IP アドレスでも ホスト名でも記述できます。数値のアドレスは、ドットで区切った 1 個から 4 個のオクテットで表します。指定したオクテットが 4 個より少ない場合は、 後ろのオクテットが 0 であるとして扱われます。

  ホスト名は読み込まれる時に数値アドレスに変換されます。 ホストが複数個のアドレスを持っている場合、それぞれのアドレスに対する 規則が個別に追加されます。これは望み通りの動作をするかもしれませんし、 そうでないかもしれません。

  ホスト名は注意して使うべきです。解決に時間がかかる名前があると、 サーバの動作が著しく遅くなるからです。

• アドレスを比較する前に規則とクライアントの IP アドレスとの AND を取る ための matching マスク。このマスクは、 マスクの上位ビットにある 1 の個数を ‘/’ の後に書いて指定します。例えば、 ‘/24’ は 0xffffff00 というマスクを示します。 matching マスクは省略してもかまいません。省略した場合のデフォルト値は ‘/32’ です。
• 規則にマッチしたクライアントを数える方法(後述)を決める counting マスク。 指定方法は matching マスクと同じです。 counting マスクは省略してもかまいません。省略した場合はデフォルト値として、 matching マスクと同じ値を持ちます。
• 同時にマッチできるクライアントの最大数を指定する limit 値。これは 10 進の整数で指定し、前の要素と区別するために空白を前に 置きます。 limit は省略してもかまいません。省略した場合のデフォルト値は、 拒否 規則については 0 であり、 許可 規則については無制限です。

クライアントがサーバに接続した際、クライアントの IP アドレスは 規則に対して順番にチェックされていきます。 それぞれの規則は以下のように処理されます:

1. 規則の IP アドレスとクライアントの IP アドレスを比較します。 比較の前にはそれぞれのアドレスと matching マスクとの AND を取っておきます。 アドレスがマッチしなければ、この規則は無視されます。
2. 現在接続している他の全てのクライアントの IP アドレスと 接続しようとしているクライアントの IP アドレスを比較します。 比較の前には各アドレスと counting マスクとの AND を取っておきます。マッチしているクライアントの数 (接続しようとしているクライアントは数えません)が limit より小さければ規則は 成功 となります。 そうでなければ規則は 失敗 します。
3. 規則が 許可 規則であり、かつ成功であれば、クライアントの接続が許可され、残りの規則 は無視されます。
4. 規則が 認証 規則であり、かつ成功であれば、サーバはクライアントが何者であるかを確認 しようとします。確認には challenge-response プロトコルを用います(後述の 認証 の節を見てください)。 アクセスが許可されるか拒否されるかは認証の結果によって決まります。 残りの規則は無視されます。
5. 規則が 拒否 規則であり、かつ失敗であれば、クライアントはアクセスを拒否され、残りの 規則は無視されます。
6. これ以外の場合には、次の規則について処理が継続されます。

リストの最後には、どんな IP アドレスにもマッチする 認証 規則が暗黙的に置かれています。したがって、アクセスが許可も拒否もされず に処理が終わった場合は、アクセスは認証機構によって制御されます。

規則の一般的な使用方法の例を以下に示します。

上記 2 つの例の違いに注意してください。 前者の例はネットワークごとの制限を行い、後者の例はホスト単位の制限を行っ ています。両者の相違点は counting マスクです。最初の例はマスクが 24 ビットなので、指定したアドレスブロッ クに含まれる全てのホストについて共通のカウンタが作られます。後者の例は マスクが 32 ビットなので、ホストごとに別々のカウンタが作られます。

アクセス制御ファイルを更新する際にサーバを止める必要はありません。 しかし、編集の際にはコピーを取って別の場所で編集し、それからアトミック に新しいファイルに置き換えるべきです。ファイルを更新した後にサーバに シグナルを送る必要はありません。サーバはファイルが触られたことを 検出し、再読み込みを自動的に行います。 さらに、サーバは 3 時間ごとにファイルを再読み込みします。 これは DNS の変更で解決されるホスト名が変わるかもしれないので、これに 対応するためです。

個々の規則における文法違反はログに記録され、違反している規則は無視され ます。ホスト名解決の失敗もログに記録されます。

認証

CVSup はサーバへのアクセスの制御に使える認証機構を備えています。この認証機構 はパケットの盗聴攻撃や再生攻撃の影響を受けない challenge-response プロトコルを使っています。ネットワーク上ではどちらの方向にもパスワード は流れません。クライアントとサーバはどちらとも、相手が何者であるかを 独立して確認できます。

クライアントの認証は base/cvsupd.access ファイル内の 認証 規則が成功するか、 “規則が適用されないままファイル末尾まで来た” 場合に呼び出されます。 cvsupd.access が存在しない場合はクライアントの認証は行われません。

base/cvsupd.passwd ファイルには認証時に使う情報が入っています。このファイルには、 サーバへのアクセスが許可されたクライアントについてのレコードが書かれて います。ファイル中では 1 行に 1 レコードが書かれます。 ‘#’ で始まる行と、空白文字しか含まない行は無視されます。 ファイル中の別の場所では空白文字は必ず意味を持ちます。フィールドは ‘:’ 文字で区切ります。

ファイルの最初のレコードは特別です。最初のレコードはサーバ自身を表しま す。サーバのレコードは以下の形式になります:

ServerName はサーバのカノニカル名です(例: ‘CVSup.FreeBSD.ORG’ )。 この名前がクライアントに送られ、クライアントはこの名前を使って適切なク ライアント名と、認証のために共有している秘密の文字列を選びます。 この名前では大文字と小文字は区別されません。

PrivateKey は ‘:’ を除く任意の文字からなる文字列です。 サーバがランダムな challenge 文字列を生成してクライアントに送った時、 サーバは推測が困難な challenge 文字列を privateKey を使って作ります。challenge 文字列はランダムであり、まず予測できないの で、 privateKey は実はあまり重要ではありません。そうしたければ空のままでもかまいません が、文字列の前の ‘:’ は必ず必要です。

ファイル中の残り全てのレコードは、個々のクライアントに対応します。 クライアント用のレコードは以下の形となります:

clientName:sharedSecret:
class:comment

空のフィールドがある場合でも、全てのフィールドが存在しなければなりません。 ClientName はレコードが適用されるクライアントの名前です。慣習では、全ての クライアント名には e-mail アドレスが使われます(例: ‘BillyJoe@FreeBSD.ORG’ )。 クライアント名では大文字と小文字は区別されません。

SharedSecret は、クライアントとサーバだけが知っている秘密の文字列です。 この文字列はクライアントが選んだパスワードから cvpasswd ユーティリティを使って生成されます。 クライアントは sharedSecret を知っていることを示すことにより、自分の身分をサーバに対して証明します (その逆も同じです)。 sharedSecret フィールドを ‘*’ にすることにより、クライアントのアクセスを禁止できます。

共有している秘密の文字列がネットワーク上を流れることはありませんし、 秘密の文字列からクライアントのパスワードを調べることもできません。しか し、共有している秘密の文字列があれば、改造した cvsup を使ってクライアントのふりをすることができるかもしれません。したがって、 cvsupd.passwd 必ずファイルはサーバしか読めないように注意してください。

Class は将来使うために予約しています。空にしてください。

Comment はサーバの管理者が便利なように、クライアントに関する備考が書かれていま す。例えば、クライアントの本名や、別の連絡手段などです。

cvsupd.passwd ファイルを更新する際にサーバを止める必要はありません。 しかし、編集の際にはコピーを取って別の場所で編集し、それからアトミック に新しいファイルに置き換えるべきです。ファイルを更新した後にサーバに シグナルを送る必要はありません。

cvsupd.passwd ファイル中では、個々のレコードの文法違反はログに記録され、違反している レコードは無視されます。

アクセス制御と認証通信の方法

アクセス制御と認証機構の関係を以下にまとめます。重要な原則は、アクセス 制御が先に行われる点です。アクセス制御の結果によって認証が行われるかど うかが決まります。

1. cvsupd.access ファイルがなければ、全てのクライアントのアクセスが許可されます。たとえ cvsupd.passwd があっても認証は行われません。
2. cvsupd.access ファイルが存在するけれど、空である場合、全てのクライアントに対して認証 が行われます。 cvsupd.passwd が存在しなければ、誰もサーバにアクセスできません。
3. cvsupd.access が存在してファイル中に規則が書かれているけれど、 cvsupd.passwd ファイルが存在しない場合は、 認証 規則が成功するとアクセスが拒否されます。この場合でも、 許可 規則が成功したクライアントはアクセスできます。 cvsupd.access ファイルの最後まで来た場合には、アクセスは拒否されます。
4. cvsupd.access と cvsupd.passwd がどちらも存在する場合の動作は以下の通りです:
   • 許可 規則が成功すると認証無しでアクセスが許可されます。
   • 認証 規則が成功すると認証が実行されます。アクセスの可否は認証の結果によって 決まります。 cvsupd.access ファイルの最後に来るケースは、これに含まれます。
   • 拒否 規則が失敗するとアクセスは拒否されます。

RCS キーワードの展開

チェックアウトモードでは、 CVSup は co(1) で説明されているように RCS キーワードを展開します。 CVSup は標準的キーワードは全て展開し、さらに非標準のキーワードである ‘$CVSHeader$’ も展開します。 この展開は ‘$Header$’ と同様に行われますが、RCS ファイルのパス名が絶対パスではなく prefix ディレクトリからの相対パスで表記される点が異なります。 ここで prefix は CVS レポジトリのルートディレクトリです。

標準 RCS キーワードの別名を定義し、それぞれのキーワードの解釈を選択的に 有効・無効にすることも可能です。 この設定は、 prefix/CVSROOT/options ファイルに書かれているキーワードによって、 レポジトリ全体を単位として制御されます。 1 行には 1 つのキーワードが書かれます。 ‘#’ から行末まではコメントと見なされます。 また空白行は無視されます。 歴史的な経緯のために文法は変てこです。

キーワードの別名を定義するには、次の形式の行を使います :

選んだ特定のキーワード以外を全て無効にするには、次の形式の行を使います:

選択した特定のキーワード以外を全て有効にするためには、次の形式の行を使 います:

シャットダウン

サーバの起動よりも後に作られた base/cvsupd.HALT というファイルが存在すると、サーバは全ての新規接続要求を受け入れなくな ります。 すでに接続されているクライアントは最後まで実行されますが、新しい接続は一 切受け付けなくなります。 この仕組みは不便で非力なため、おそらく将来のリリースでは変更されるでしょ う。

セキュリティ

cvsupd は、コマンドラインで指定するログファイルを除いて、新しいファイルの作成 やファイルへの書き込みは行いません。 cvsupd が動作していることによってシステムにダメージを与える可能性はほとんどあり ません。 それよりも可能性の高いセキュリティ上の危険として、 cvsupd が騙されて公開すべきでないファイルを送り出してしまうことがあります。 cvsupd ではこのようなことがないように細心の注意を払っています。 それでもやはり、最大の防御は cvsupd を ‘nobody’ のような全く権限のないユーザで実行し、誰でも読めるファイルしか提供でき ないようにすることです。

CVSup は、ネットワーク上を流れるデータの暗号化には対応していません。 機密性が必要であれば、 ssh を使って接続をトンネリングしてください。

ファイル

/usr/local/etc/cvsup

デフォルトの 起点 ディレクトリ。

sup

デフォルトの collDir サブディレクトリ。

base/collDir/collection/releases

リリースファイル。

base/collDir/collection/list

リストファイル。

base/cvsupd.HALT

シャットダウンファイル。

base/cvsupd.access

アクセス制御ファイル。

base/cvsupd.passwd

認証パスワードファイル。

prefix/CVSROOT/options

RCS キーワード設定ファイル。

関連項目

co(1), cvpasswd(1), cvs(1), cvsup(1)

http://www.polstra.com/projects/freeware/CVSup/

作者

John Polstra ⟨jdp@polstra.com⟩

バグ

ファイル名の末尾が ‘,v’ になっていない RCS ファイルは認識されません。

‘Attic’ という名前のディレクトリは全て CVS Attic と見なされ、特別な扱いを受けます。