Provided by: manpages-ja_0.5.0.0.20140515+dfsg-2_all 
名称
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 アドレスにもマッチする 認証 規則が暗黙的に置かれています。した
がって、アクセスが許可も拒否もされず に処理が終わった場合は、アクセスは認証機構によって制御
されます。
規則の一般的な使用方法の例を以下に示します。
-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 アドレ
スが使われます(例: ‘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 つのキーワードが書かれます。 ‘#’ から行
末まではコメントと見なされます。 また空白行は無視されます。 歴史的な経緯のために文法は変てこ
です。
キーワードの別名を定義するには、次の形式の行を使います :
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 キーワード設定ファイル。
関連項目
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 と見なされ、特別な扱いを受けます。