Provided by:
manpages-ja_0.5.0.0.20080615-1_all 
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
つの規則が書かれます。コメントは '#' で始まり、その行の最後まで続-
ます。空白文字は無視されますが、隣り合う トークンを区切る場合は除-
ます。空行は無視されます。
それぞれの規則は以下の要素からなります:
+o 規則が _permit) 規則、 _authenticate) 規則、 _deny)
規則のいずれであるかを示すフラグ。このフラグは 1
つの文字で表されます: '+' は許可規則、 '*' は認証規則、 '-'
は拒否規則を表します。
+o クライアントの IP
アドレスと比較され、そのクライアントに規則を適用する
かどうかが決めるための IP アドレス。これは数値の IP アドレスでも
ホスト名でも欺劼任ます。数値のアドレスは、ドットで区切った 1 個から 4
個のオクテットで表します。指定したオクテットが 4 個より少ない場合は、
後ろのオクテットが 0 であるとして扱われます。
ホスト名は読み込まれる時に数値アドレスに変換されます。
ホストが複数個のアドレスを持っている場合、それぞれのアドレスに対する
規則が個別に追加されます。これは望み通りの動作をするかもしれませんし、
そうでないかもしれません。
ホスト名は注意して使うべい任后２魴茲忙間がかかる名前があると、
サーバの動作が著しく遅くなるからです。
+o アドレスを比較する前に規則とクライアントの IP アドレスとの AND を取る
ための matching マスク。このマスクは、 マスクの上位ビットにある 1
の個数を '/' の後に書いて指定します。例えば、 '/24' は 0xffffff00
というマスクを示します。 matching
マスクは省略してもかまいません。省略した場合のデフォルト値は '/32'
です。
+o 規則にマッチしたクライアントを数える方法(後述)を決める counting
マスク。 指定方法は matching マスクと同じです。 counting
マスクは省略してもかまいません。省略した場合はデフォルト値として、
matching マスクと同じ値を持ちます。
+o 同時にマッチでい襯ライアントの最大数を指定する limit 値。これは 10
進の整数で指定し、前の要素と区別するために空白を前に 置い泙后 limit
は省略してもかまいません。省略した場合のデフォルト値は、 _
規則については 0 であり、 _matching マスクとの AND
を取っておい泙后
アドレスがマッチしなければ、この規則は無視されます。
2. 現在接続している他の全てのクライアントの IP アドレスと
接続しようとしているクライアントの IP アドレスを比較します。
比較の前には各アドレスと counting マスクとの AND を取ってお-
ます。マッチしているクライアントの数
(接続しようとしているクライアントは数えません)が limit
より小さければ規則は __
します。
3. 規則が _
規則であり、かつ成功であれば、クライアントの接続が許可され、残りの規則
は無視されます。
4. 規則が _
規則であり、かつ成功であれば、サーバはクライアントが何者であるかを確認
しようとします。確認には challenge-response
プロトコルを用います(後述の __
規則であり、かつ失敗であれば、クライアントはアクセスを拒否され、残りの
規則は無視されます。
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
がどちらも存在する場合の動作は以下の通りです:
+o _+o _
規則が成功すると認証が実行されます。アクセスの可否は認証の結果によって
決まります。 cvsupd.access
ファイルの最後に来るケースは、これに含まれます。
+o _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
と見なされ、特別な扱いを受けます。