Provided by: manpages-ja_0.5.0.0.20221215+dfsg-1_all 
名称
cvsupd — ネットワーク上で CVS レポジトリを配布するためのサーバ
書式
[-ev] [-A addr] [-b base] [-c collPath] [-C maxClients] [-l log] [-p port] [-P range] [-s scanDir] [-Z
comprLevel]
解説
はネットワーク配布のためのパッケージである CVSup のサーバプログラムです。 サーバと組み合わせて動作するク
ライアントプログラム に関しては cvsup(1) を参照してください。
通常使用時には に ‘-C maxClients’ オプションを指定して実行しなければなりません。 はバッググラウンドデーモ
ンとして実行され、 リモートクライアントからの接続要求に対応します。それぞれの接続について は子プロセスを
fork し、クライアントが要求したファイルを送ります。
以下のオプションがサポートされています:
-A addr サーバが接続を受け付ける(accept)するローカルのアドレス(IP アドレス またはホスト名)を指定しま
す。このオプションは複数個の IP アドレスを持つ ホストで役立つでしょう。
-b base base を設定ファイルの起点ディレクトリとして使います。 デフォルト値は /usr/local/etc/cvsup で
す。
-c collPath
提供されるコレクションに関する情報を得るために、指定されたディレクトリを 検索します。
collPath は 1 つのディレクトリ、もしくはコロンで区切った複数のディレクトリを 含みます。 絶対
パスで指定されていない場合は、起点ディレクトリからの相対パスと解釈 されます。 デフォルトの検
索パスは ‘sup’ です。
-C maxClients
同時に接続できるクライアントの数を maxClients に制限します。 指定した最大数を超えた場合、クラ
イアントはサービスを丁寧に 断わられます。
このオプションが指定されていない場合、 はフォアグラウンドで動作して 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 パワーが大幅に消費される割には ファイルサイズはほとんど改善されませ
ん。
ファイルコレクションレポジトリを準備する
がクライアントに提供するファイルコレクションは、様々な設定ファイルで記述 します。 設定ファイルは
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 キーワードは、こういった階層的な配置において、そのコレクションの 親
コレクションを指定します。
このキーワードは省略してもかまいません。省略された場合には、 は現在のコレクションと利用可能な
他のコレクションの間に 何の関連もないとみなします。
super キーワードから得た情報は、サーバがミラーサイトとして動作している時に、 適切な scan ファ
イルを見つけるために使われます。 “CVSup を使ったミラーサイトの運用” をご覧ください。
nocheckrcs 更新される RCS ファイル群について、MD5 チェックサムの比較を行いません。 RCS ファイルにおける
チェックサムの不一致は意味を持ちません。なぜなら、 ある論理的な意味を持った RCS ファイルに
は、テキストとしての表現はたく さんあるからです。
norcs RCS ファイルを特別扱いしません。RCS ファイルを他のファイルと同様に扱い ます。
norsync rsync アルゴリズムを使わないようにします。 注意: このキーワードを releases ファイルで使うのは
古いやり方です。これを使わないでリストファイル内で norsync または rnorsync を使ってくださ
い(後述)。
認識できないキーワードは受け付けられますが、無視されます。 これは sup(1) パッケージとの後方互換性のためで
す。 が提供するリリースが 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 アルゴリズムが使われま
せん。この指定はログファイルで役立ちます。 というのも、 の “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 経由で他のサイト
にファイルを再配布するサーバのことです。ミラーサイトは、 大きなプロジェクトで負荷を複数のサーバに分散する
ためによく使われます。 配布されるファイルは元々はマスターサイトに置かれます。各ミラーサイトは マスターサ
イトを基にして、自分が持っているコピーを定期的に更新します。 次に、クライアントはミラーサイトのどれかから
更新分のファイルを取得しま す。
には、ミラーサイトの効率を劇的に向上させるための特殊な動作モードがあり ます。このモードはコマンドラインで
-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 ファイルを使います。 (詳しくは “ファイルコレクション
レポジトリを準備する” で説明されている super キーワードの説明を参照してください。) 適切な scan ファイルが
なければ、 は最終的にファイルツリーを全て調べます。
アクセス制御
デフォルトの動作ではサーバへのアクセスは制限されていませんが、接続する クライアントの 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 というファイルが存在すると、サーバは全ての新規接続要求を
受け入れなくな ります。 すでに接続されているクライアントは最後まで実行されますが、新しい接続は一 切受け付
けなくなります。 この仕組みは不便で非力なため、おそらく将来のリリースでは変更されるでしょ う。
セキュリティ
は、コマンドラインで指定するログファイルを除いて、新しいファイルの作成 やファイルへの書き込みは行いませ
ん。 が動作していることによってシステムにダメージを与える可能性はほとんどあり ません。 それよりも可能性の
高いセキュリティ上の危険として、 が騙されて公開すべきでないファイルを送り出してしまうことがあります。 で
はこのようなことがないように細心の注意を払っています。 それでもやはり、最大の防御は を ‘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 と見なされ、特別な扱いを受けます。
FreeBSD August 31, 1999 CVSUPD(8)