cvsupd

名称

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 アドレスは規則に対して順番にチェックされていきます。それぞれの規則は以下のように処理されます:

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

リストの最後には、どんな 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 の変更で解決されるホスト名が変わるかもしれないので、これに対応するためです。

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

認証

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

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

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

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

serverName:privateKey

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

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

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

clientName:sharedSecret:class:comment

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

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

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

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

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

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

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

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

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

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

RCS キーワードの展開

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

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

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

tag=alias[=keyword]

例えば:

tag=FreeBSD=CVSHeader

は新しい RCS キーワード ‘ $FreeBSD$ ’ を定義し、これは ‘ $CVSHeader$ ’ と同様に展開されます。二番目の ‘=’ と keyword がない場合、キーワードのデフォルト値は ‘Id’ です。

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

tagexpand=ikeyword[,...]

例えば

tagexpand=iFreeBSD,Id

と書くと ‘ $FreeBSD$ ’ と ‘ $Id$ ’ 以外の全てのキーワードの展開を行わなくなります。最初の ‘i’ は “include” の意味です。

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

tagexpand=ekeyword[,...]

例えば

tagexpand=eFreeBSD,Id

と書くと、 ‘ $FreeBSD$ ’ と ‘ $Id$ ’ 以外の全てのキーワードの展開を行うようになります。先頭の ‘e’ は “exclude” の意味です。

シャットダウン

サーバの起動よりも後に作られた 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 キーワード設定ファイル。

作者

John Polstra ⟨[email protected]⟩

バグ

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

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

August 31, 1999

FreeBSD

cvsupd

名称

書式

解説

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