Provided by: manpages-ja_0.5.0.0.20140515+dfsg-2_all ![bug](/img/bug.png)
![bug](/img/bug.png)
名称
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 と見なされ、特別な扱いを受けます。