Index: head/ja_JP.eucJP/books/handbook/mirrors/chapter.xml =================================================================== --- head/ja_JP.eucJP/books/handbook/mirrors/chapter.xml (revision 42481) +++ head/ja_JP.eucJP/books/handbook/mirrors/chapter.xml (revision 42482) @@ -1,2668 +1,2669 @@ &os; の入手方法 CDROM/DVD 出版社 CD/DVD セット &os; の CD/DVD セットは以下のオンライン業者から入手できます。
&os; Mall, Inc. 2420 Sand Creek Rd C-1 #347 Brentwood, CA 94513 USA 電話: +1 925 240-6652 Fax: +1 925 674-0821 Email: info@freebsdmall.com WWW:
Dr. Hinner EDV Kochelseestr. 11 D-81371 München Germany 電話: (0177) 428 419 0 WWW:
Linux Distro UK 42 Wharfedale Road Margate CT9 2TB United Kingdom WWW:
The Linux Emporium The Techno Centre, Puma Way Parkside CV1 2TT United Kingdom 電話: +44 (0)247 615 8121 Fax: +44 1491 837016 WWW:
LinuxCenter.Ru Galernaya Street, 55 Saint-Petersburg 190000 Russia 電話: +7-812-3125208 Email: info@linuxcenter.ru WWW:
FTP サイト &os; の公式な情報は anonymous FTP によって世界中のミラーサイトより入手できます。 サイトは接続が良く、大規模な接続を受け付けていますが、 よりネットワーク的に近い ミラーサイトを探した方が良いでしょう (特にミラーサイトのようなものを構築しようとした場合はこれに該当します)。 さらに、&os; は以下のミラーサイトから anonymous FTP によって入手できます。もし &os; を anonymous FTP によって手にいれる場合は、 近くのサイトを利用するようにしてください。 一次ミラーサイト としてあげられているサイトには、 &os; の各アーキテクチャで利用可能なすべてのバージョンのアーカイブ一式が用意されています。 あなたが住んでいる国や地域には、 より高速にダウンロードできるサイトがおそらくあるでしょう。 各国のミラーサイトには、 人気のあるアーキテクチャの最新のバージョンが置いてありますが、 &os; のアーカイブ全体はもしかするとないかもしれません。 すべてのサイトは anonymous FTP によるアクセスを提供していますが、 別の方法によるアクセスを提供しているサイトもあります。 各サイトで提供しているアクセス方法は、 ホスト名に続く括弧の中に記載されています。 &chap.mirrors.ftp.index.inc; &chap.mirrors.lastmod.inc; &chap.mirrors.ftp.inc; Anonymous CVS (非推奨) Warning CVS は、プロジェクトにおいて使用されなくなったため、 非推奨になりました。かわりに Subversion を使ってください。 CTM を使う CTM 訳: &a.hanai;、1997 年 9 月 13 日 CTM はリモートのディレクトリツリーを中央のツリーに同期させるための 手段です。 これは &os; のソースツリーの配布を行なうために開発されまし たが、時が経つにつれて別の目的にも有用であることがわかるかも しれません。 デルタを作り出す処理に関するドキュメントは現在ほとんど ありません。従って、もしあなたがCTM を他のことに使いたいなら &a.ctm-users.name; メーリングリストにさらなる情報を問い合わせてください。 なぜ <application>CTM</application> を使うの? CTM を使うことにより &os; ソースツリーのローカルコピーを手にいれることができます。 ソースツリーが使えることの魅力は数多くあります。完全な cvs ツリーを追いかけるにしても、ひとつのブランチを追いかける にしても CTM は必要な情報を与えてくれます。 もしあなたが &os; のアクティブな開発者であるにもかかわらず お粗末な TCP/IP 接続しか持っていなかったり、または TCP/IP 接続が 行なえないとしたら、あるいは単に変更が自動的に送られてきて ほしいというのであれば CTM はそんなあなたのために 作られたのです。 アクティブなブランチでは 1 日に最大三つまでのデルタを受け取る必要があります。 これが自動的に e-mail で送られてくるという方法を ぜひ検討してみてください。 デルタのサイズは常にできるだけ小さく保たれています。 大抵の場合 5KB よりも小さく、 たまに (10 回に 1 回程度) 10-50KB になり、 ときおり 100KB かもっと大きくなるでしょう。 開発ソースから直接に得られたものを使うことについては、 あらかじめパッケージにされたリリースとは違い、 いろいろと注意することが あります。これは特に current のソースを選んでいるときは重要です。 最新の &os; を追いかけるを読むことをお勧めします。 <application>CTM</application>を使うには何が必要? 二つのものが必要でしょう: CTM プログラムとそれに与える (current レベルを得るための) 最初のデルタです。 CTM プログラムはバージョン 2.0 のリリース以来 &os; の一部になりました。 もしソースのコピーを持っているなら /usr/src/usr.sbin/ctmにあります。 から入手できます。CTM に与える デルタ は二つの方法、FTP または e-mail、 で得ること ができます。 もしインターネットに FTP アクセスできるなら、 次の FTP サイト: または、そのミラーサイトが CTM へのアクセスをサポートします。 適切なディレクトリに FTP して README ファイルを入手し、そこからスタートしてください。 e-mail によってデルタを得たいという場合は: CTM 配布メーリングリストのいずれかに参加してください。 &a.ctm-src-cur.name; は完全な Subversion ツリー、 &a.ctm-src-cur.name; は開発先端ブランチに対応しています。&a.ctm-src-9.name; は 9.X リリースのブランチに対応したものです (もし参加方法が分からない場合は、メーリングリスト名をクリックするか、 &a.mailman.lists.link; に行って参加したいメーリングリストをクリックしてください。 このページには、参加手順が詳しく書かれています)。 メールで CTM による更新ファイルを受け取り始めると、中身を取り出して使用 するために ctm_rmail プログラムを使うかもしれません。それを完全 に自動で行ないたいなら、/etc/aliases から ctm_rmailプロ グラムを直接使うこともできます。 さらに詳しいことは ctm_rmail manページを御覧ください。 どの方法を使って CTM デルタを入手していたとしても、 &a.ctm-announce.name; メーリングリストには参加しておくといいでしょう。 このメーリングリストは将来的には CTM システムの操作に関する アナウンスがポストされる唯一の場になるでしょう。 メーリングリストに参加するには、上のメーリングリスト名をクリックして、 参加手順に従ってください。 はじめて <application>CTM</application> を使い始める CTM デルタを使い始めるためには、これは以降作られる全ての デルタの出発点を手にいれる必要があります。 最初にあなたが何をすでに持っているかをはっきりさせましょう。 すべての人は 空 のディレクトリから始めなければなりません。 ツリーをサポートしてるあなたの CTM を稼働するためには 指定した 空 のデルタを使う必要があります。いくつかの分岐点 では、あなたの都合により CD 内に分配されている スタータ デルタを使用できるようになっています。しかしながら、これは 頻繁に行われることではありません。 適切な出発点が決まれば、その出発点を CTM が 維持するツリーへ変換するための スタータ 初期デルタを使う必要が あります。 移行デルタは番号の後ろに X をつけたものがそうです (たとえば src-cur.3210XEmpty.gz)。 X の後ろは最初の開始ポイントに対応します。 Empty は 空のディレクトリです。 ルールとして Empty からの移行デルタは 100 デルタごとに 作られます。ちなみに、 これらは非常に大きくなります! XEmptyのデルタは 70 から 80MB の gzip で圧縮されたデータというのが普通です。 一度スタートするためのベースデルタを得ると、 それに続く多数のすべてのデルタも必要になるでしょう。 <application>CTM</application> を日常で使う デルタを適用するためには、単に &prompt.root; cd /where/ever/you/want/the/stuff &prompt.root; ctm -v -v /where/you/store/your/deltas/src-xxx.* とします。 CTM はどれが gzip されているか理解します。 従って最初に gunzip しておく必要はありません。 ディスクの節約にもなります。 全体の処理に関して確信するまでは CTM は (ソース) ツリーに対して 何もしません。また、デルタを確かめるためには フラグを使うことができます。 このフラグがあると CTM はツリーに対して実際には何も行ないません。 単にデルタの完全性を確認し、 現在のツリーに問題なく使用できるかを確認 するだけです。 CTM には他にもオプションがあります。詳細に関しては マニュアルページを参照するかソースを見てください。 以上でやることは本当に全部です。 新しいデルタを入手した時には、 ソースを最新のものにするためにそれを CTMに通すだけです。 もしデルタを再ダウンロードするのが 骨の折れる作業であれば、デルタを消さないでおいてください。 なにかおかしなことが起こった場合には置いておけば良かった と思うかもしれません。 もしフロッピーディスクしか持っていない状況 であってもコピーを取るのに fdwrite を使うことを考えてください。 ローカルの変更を保存する 開発者としてはソースツリー中のファイルを 使って実験したり変更したく なるものです。 CTM はローカルの変更を制限つきでサポートします: ファイル foo の存在をチェックする前に、 foo.ctm を参照しにいきます。 このファイルが存在する場合、CTM は foo の代りにこれを処理します。 この動作はローカルの変更を保持する簡単な手段を 提供します: 単に変更したいファイルを拡張子 .ctm 付きのファイル名で コピーするだけです。あとは自由にコードをハックでき、 .ctm ファイルの方は CTM が最新状態に保ってくれます。 <application>CTM</application> のその他の面白いオプション 更新で変更されるファイルを正確に知る CTM のソースリポジトリに対する変更のリストを オプションを使って決定することができます。 これは、変更のログを保存したい、 変更されたファイルをなんらかの方法で 前・後処理したい、 または単にこだわりたい場合には、 役に立つでしょう。 更新前にバックアップを取る CTM の更新によって変更されるファイルすべてのバックアップを 取りたくなることがあります。 オプションを指定すると CTM は デルタで変更されるファイルすべてを backup-file としてバックアップするようになります。 更新で変更されるファイルを制限する CTM の更新の範囲を制限したり一連のデルタのから ほんの数ファイルを抽出したくなることがあります。 と オプションを用い正規表現を指定することで、 CTM が処理するファイルのリストを制御することが できます。 例えば、lib/libc/Makefile の最新のコピーを保存してある CTM デルタのコレクションから抽出するには、 以下のコマンドを実行します。 &prompt.root; cd /where/ever/you/want/to/extract/it/ &prompt.root; ctm -e '^lib/libc/Makefile' ~ctm/src-xxx.* CTM デルタで指定されたファイルごとに、 そして オプションがコマンドラインで指定された順序で適用されます。 すべての そして オプションが適用された後に更新対象と選択された場合に限り、 CTM はそのファイルを処理します。 <application>CTM</application>の将来計画 重要なもの なんらかの CTM システムへの認証機構を用い、不正な CTM の更新の検出を可能とする。 CTM へのオプションを整理する。さもないと混乱し、 直観に反したものになります。 その他 ports コレクションに対するデルタもあるのですが、 これに興味を持っている人はまだ少ないようです。 CTM サイト CTM/&os; は以下のミラーサイトから anonymous FTP によって入手できます。 もし CTM を anonymous FTP によって手にいれる場合は、 近くのサイトを利用するようにしてください。 何か問題がある場合は、&a.ctm-users.name; メーリングリストに相談してください。 カリフォルニア、サンフランシスコ近辺、 公式なソース 南アフリカ、ctm、sup、 CVSupなどの古い差分ファイルのバックアップサーバ 台湾/中華民国 近くにミラーサイトがない場合やミラーが不完全な場合は、 alltheweb のような検索エンジンを使ってみてください。 <application>Subversion</application> を使う Subversion はじめに 2012 年 7 月から、&os; はすべてのソースコード、ドキュメント、Ports Collection を管理するメインのバージョン管理システムに Subversion (svn) を使っています。 一般的には Subversion は開発者向けのツールです。 大部分のユーザは、&os; のベースシステムのアップデートに FreeBSD Update、 Ports Collection のアップデートには Portsnap を使うべきでしょう。 Subversion では、リポジトリの指定に protocol://hostname/path 形式の URL を用います。 以下に記載されているように、 ミラーサイトは異なる複数のプロトコルに対応しています。 アクセスする FreeBSD のリポジトリは、パス (path) の最初で指定します。 リポジトリは 3 つあります。 base は &os; ベースシステムのソースコード、 ports は Ports Collection、 そして doc はドキュメントのリポジトリです。 たとえば、 svn://svn0.us-east.FreeBSD.org/ports/head/ という URL は、svn プロトコルによる svn0.us-east.FreeBSD.org ミラー上の ports リポジトリのメインブランチを示しています。 インストール リポジトリの中身をチェックアウトできるよう、事前に Subversion をインストールしておく必要があります。 もし、すでに ports ツリーが用意してあれば、 以下のようにして Subversion をインストールできます。 &prompt.root; cd /usr/ports/devel/subversion &prompt.root; make install clean もし ports ツリーを利用できなければ、package から Subversion をインストールできます。 &prompt.root; pkg_add -r subversion もし、packages の管理に pkgng を使っているのであれば、かわりに以下のようにして Subversion をインストールできます。 &prompt.root; pkg install devel/subversion <application>Subversion</application> の実行 svn コマンドを使って、 必要なリポジトリのソースコードを以下のようにしてダウンロードします。 このディレクトリにあるファイルを ローカル作業コピー と呼びます。 すでにローカルディレクトリが存在していても、 それが svn によって生成されたディレクトリでなければ、 チェックアウトする前に名前を変更するか、削除してください。 svn 以外の方法で用意されたディレクトリでチェックアウトすると、 すでに存在するファイルと、 リポジトリから持ってきたファイルとの間で衝突が起きてしまいます。 以下のように入力して、リポジトリからチェックアウトしてください。 &prompt.root; svn checkout svn-mirror/repository/branch lwcdir ここで、repository, branch および root は以下のとおりです。 svn-mirror は、 Subversion ミラーサイト のひとつの URL です。 repository には、 プロジェクトのリポジトリ、すなわち base, ports, または doc のどれかひとつを指定します。 branch は、使うリポジトリによります。 ports および doc では、ほとんどの変更が head ブランチで行われます。 base リポジトリでは、head ブランチで -CURRENT の最新バージョンを管理しています。 -STABLE ブランチの最新バージョンは、8.x は stable/8、 9.x は stable/9 で管理しています。 lwcdir は、 指定したブランチの中身が置かれるターゲットのディレクトリです。 通常 ports は /usr/ports、 base は /usr/src、 そして doc では /usr/doc と指定します。 以下の例では、Ports Collection を western US リポジトリから HTTPS プロトコルを使って、チェックアウトします。 そしてそれらは、 /usr/ports のローカル作業コピーに置かれます。 もし /usr/ports がすでに存在して、 それが svn によって生成されたものでなければ、 チェックアウトする前に、名前を変更するか削除してください。 &prompt.root; svn checkout https://svn0.us-west.FreeBSD.org/ports/head /usr/ports 初めてチェックアウトする際には、 リモートリポジトリのすべてのブランチをダウンロードするので時間がかかります。 どうぞ我慢してください。 初めてのチェックアウト後は、 以下を実行することでローカル作業コピーをアップデートできます。 &prompt.root; svn update lwcdir この例で作成された /usr/ports をアップデートするには、 以下のようにしてください。 &prompt.root; svn update /usr/ports アップデートはチェックアウトにくらべ、 変更点のあるファイルのみが転送されるので高速です。 チェックアウト後、ローカル作業コピーをアップデートするもうひとつの方法は、 /usr/ports, /usr/src または /usr/doc ディレクトリの Makefile で提供されています。 SVN_UPDATE を設定して update ターゲットを使ってください。 たとえば、/usr/src をアップデートするには、以下のようにしてください。 &prompt.root; cd /usr/src &prompt.root; make update SVN_UPDATE=yes より詳しい情報 Subversion の利用に関する他の情報は、Version Control with Subversion や Subversion Documentation といった Subversion Book をご覧ください。 <application>Subversion</application> ミラーサイト Subversion Repository ミラーサイト すべてのミラーはすべてのリポジトリを持っています。 &os; Subversion サーバのマスタである svn.FreeBSD.org は、 公には読み出し専用でアクセスできますが、 将来的には変更される予定ですので、 オフィシャルミラーを使うことが推奨されます。 ブラウザを用いて &os; の Subversion リポジトリを参照するには、http://svnweb.FreeBSD.org/ を利用してください。 &os; の svn ミラーネットワークは、 まだ初期の段階にあるので、今後変更されることがあります。 以下のミラー一覧を不変なものとは考えないでください。 特に、サーバの SSL 証明書は、いずれかの時点で変更になるでしょう。 名前 プロトコル 位置 SSL フィンガープリント svn0.us-west.FreeBSD.org svn, http, https USA, カリフォルニア SHA1 - 79:35:8F:CA:6D:34:D9:30:44:D1:00:AF:33:4D:E6:11:44:4D:15:EC + 1C:BD:85:95:11:9F:EB:75:A5:4B:C8:A3:FE:08:E4:02:73:06:1E:61 svn0.us-east.FreeBSD.org svn, http, https, rsync USA, ニュージャージ SHA1 - 06:D1:23:DE:5E:7A:F7:2B:7A:7E:74:95:5F:54:8D:5C:B0:D6:2E:8F + 1C:BD:85:95:11:9F:EB:75:A5:4B:C8:A3:FE:08:E4:02:73:06:1E:61 svn0.eu.FreeBSD.org svn, http, https, rsync Europe, UK SHA1 39:B0:53:35:CE:60:C7:BB:00:54:96:96:71:10:94:BB:CE:1C:07:A7 HTTPS は推奨されているプロトコルです。 他のコンピュータが &os; ミラーを装う (一般的には マン・イン・ザ・ミドル 攻撃として知られています) ことや、 もしくは、エンドユーザに対し好ましくない内容を送りつけようということに対し保護を行います。 HTTPS ミラーへの最初の接続の際には、 サーバの フィンガープリント の確認を求められます。 Error validating server certificate for 'https://svn0.us-west.freebsd.org:443': - The certificate is not issued by a trusted authority. Use the fingerprint to validate the certificate manually! + - The certificate hostname does not match. Certificate information: - Hostname: svnmir.ysv.FreeBSD.org - - Valid: from Fri, 24 Aug 2012 22:04:04 GMT until Sat, 24 Aug 2013 22:04:04 GMT - - Issuer: clusteradm, FreeBSD.org, CA, US - - Fingerprint: 79:35:8f:ca:6d:34:d9:30:44:d1:00:af:33:4d:e6:11:44:4d:15:ec + - Valid: from Jul 29 22:01:21 2013 GMT until Dec 13 22:01:21 2040 GMT + - Issuer: clusteradm, FreeBSD.org, (null), CA, US (clusteradm@FreeBSD.org) + - Fingerprint: 1C:BD:85:95:11:9F:EB:75:A5:4B:C8:A3:FE:08:E4:02:73:06:1E:61 (R)eject, accept (t)emporarily or accept (p)ermanently? フィンガープリントを上の表の一覧のものと照合してください。 フィンガープリントが一致したら、 サーバのセキュリティ証明書を一時的 (permanently) もしくは恒久的 (temporarily) に受け入れてください。 一時的な認証であれば、サーバとの一回のセッションで有効期限が切れるため、 次回の接続時にはもう一度検証が行われます。 恒常的な認証を選んだ場合には、認証のための証明書が ~/.subversion/auth/ に保存され、 有効期限が切れるまでは、フィンガープリントの確認は求められません。 ファイアウォールまたは他の問題のため、HTTPS を使えなければ、転送速度がより少し早い SVN を使ってください。 両方を使えない場合には、 HTTP を使ってください。 CVSup を使う (非推奨) 訳: &a.jp.iwasaki;、1997 年 2 月 27 日 紹介 cvsup は、 プロジェクトにおいて使用されなくなったため、 非推奨になりました。 かわりに Subversion を使ってください。 CVSup は、 リモートのサーバホストにあるマスタ CVS リポジトリから ソースツリーを配布し更新するための ソフトウェアパッケージです。&os; のソースは、 カリフォルニアにある中心的な開発マシンの CVS リポジトリの 中でメンテナンスしています。CVSup を使用することで、&os; ユーザは 簡単に自分のソースツリーを最新の状態に しておくことができます。 CVSup は pull モデルとよばれる更新のモデルを採用しています。pull モデルでは、 各クライアントが更新したい場合に更新したい時点で、 サーバに更新の問い合わせをおこないます。 サーバはクライアントからの 更新の要求を受け身の状態で待ちます。したがって、 すべての更新はクライアント主導でおこなわれます。 サーバは頼まれもしない更新情報を送るようなことはしません。 ユーザは CVSup クライアントを手動で実行して更新をおこなうか、 cron ジョブを設定して定期的に自動実行する必要があります。 用語 CVSup のように大文字で表記しているものは、ソフトウェアパッケージ 全体を指します。主な構成物は、 各ユーザマシンで実行するクライアントである cvsup、&os; の各ミラーサイトで実行するサーバ cvsupd です。 csup ユーティリティは CVSup ソフトウェアを C 言語で書き直したものです。 処理速度が速く、また、Modula-3 言語を使わないため、 Modula-3 をインストールする必要がありません。 さらに、ベースシステムに含まれているので、 すぐに使うことができます。 csup を使う場合は、 CVSup のインストールを省略し、 以下の文章中の CVSup を csup に置きかえて読んでください。 インストール CVSup をインストールする最も簡単な方法は、&os; Ports コレクションのパッケージ からコンパイル済みの net/cvsup パッケージをインストールすることです。 もしくは、net/cvsup でも構いません。 ただし、net/cvsup は Modula-3 システムに依存していて、構築にかかる時間、 ディスクスペースは比較的大きくなります。 たとえばサーバのような &xorg; がインストールされていない計算機で CVSup を使おうとしているのであれば、必ず CVSup GUI が含まれていない net/cvsup-without-gui を使ってください。 CVSup のコンフィグレーション CVSup の動作は、supfile と呼ばれるコンフィグレーションファイルで制御します。 supfile のサンプルは、ディレクトリ /usr/share/examples/cvsup/ の下にあります。 supfile には以下の CVSup に関する質問への答えを記述します: どのファイルを受け取りたいのか? どのバージョンのものが欲しいのか? どこから入手したいのか? 自分のマシンのどこに置きたいのか? どこに status ファイルを置きたいのか? 次のセクションで、これらの質問に順番に答えながら典型的な supfile を組み立てていきます。最初に supfile の全体構造を説明します。 supfile はテキストファイルです。 コメントは # から行末までです。 空行とコメントだけの行は無視します。 残りの各行には、 ユーザが受け取りたいファイル群について記述します。 行の始めは、 サーバ側で定義した論理的なファイルのグループである コレクション の名称です。 コレクションの名称を指定して、欲しいファイル群を サーバに伝えます。コレクション名の後には、 ホワイトスペースで区切られた 0 個以上のフィールドが続きます。 これらのフィールドが上記の質問に対する答えになります。 フィールドには 2 種類あります: flag フィールドと value フィールドです。flag フィールドは delete や compress のような 単独のキーワードから成ります。また、value フィールドもキーワードで始まりますが、 キーワードの後にはホワイトスペースは入らず、 = と二つめの単語が続きます。例えば、 release=cvs は value フィールドです。 通常、supfile には受け取りたいコレクションを一つ以上指定します。 supfile を組み立てる一つの方法として、 コレクション毎にすべての関係の あるフィールドを明示的に指定する方法があります。しかし、 これでは supfile のすべてのコレクションに対して ほとんどのフィールドが同じになるため、 行が非常に長くなってしまい不便になります。 これらの問題を避けるため、CVSup ではデフォルトを指定することのできる メカニズムが提供されています。特殊な擬似コレクション名 *default で始まる行は、 supfile 中の後続の コレクションに対して使用する flag フィールドと value フィールドのデフォルトを設定するために利用できます。 個々のコレクションで固有の値を指定すると、 デフォルト値を無効にできます。また 行を追加すると、supfile の途中からデフォルト値の変更や追加が可能になります。 これまでの予備知識を基に、 &os;-CURRENT のメインのソースツリーを受け取って更新するための supfile を組み立ててみましょう。 どのファイルを受け取りたいのか? CVSup を通して入手できるファイルは コレクション と呼ばれる名前の付けられたグループにまとめられています。 利用可能なコレクションについては 後の節の中で説明しています。 ここでは、&os; システムのメインのソースツリー全体 を受け取るための設定例を紹介します。 すべてを含む src-all という単一の大きなコレクションがあります。 supfile を組み立てる最初のステップとして、 これらのコレクションを一行に一つずつ記述します (この場合は一行だけです)。 src-all どのバージョンのものが欲しいのか? CVSup を使用すると、 かつて存在していたことのある、事実上どのバージョンの ソースでも受け取ることができます。これは cvsupd サーバがすべてのバージョンを含む CVS リポジトリに基づいて動作することにより、 実現されています。 tag= および の value フィールドを使用して、 欲しいバージョンの 一つを指定します。 tag= のフィールドの指定は正確に行うように十分注意 してください。いくつかのタグは特定のコレクションに 対してのみ有効です。 タグの綴りが違っていたり不適切なタグを指定すると、 CVSup はユーザが消し たくないファイルまで削除してしまいます。特に ports-* のコレクション に対しては tag=. だけ を指定するようにしてください。 tag= フィールドはリポジトリ中のシンボリックタグを指定します。 tag には revision tag と branch tag の二種類があります。 revision tag は特定のリビジョンを指します。これは、 毎日同じ状態に保つことになります。一方 branch tag は、 ある時点での開発分流の最新のリビジョンを指します。 branch tag は特定のリビジョンを指定している訳ではないので、 今日と明日では 異なるリビジョンを参照することになるかもしれません。 にはユーザが興味を持つであろうリビジョンタグの一覧が載せられています。 CVSup の設定ファイル中でタグを指定する時は、 tag= に続けて書きます (RELENG_8 は tag=RELENG_8 になります)。 tag=. だけが Ports Collection には 適切であることに注意してください。 tag 名を示した通りにタイプされているか十分注意してく ださい。CVSup は tag 名が正しいかどうかを見分けることはできません。tag が間違っていた場合、 たまたまファイルがまったく存在しない正しい tag が 指定されたものとしてCVSup は動作します。その場合は、現在あるソースが削 除されるでしょう。 branch tag を指定した際には、 通常はその開発分流の最新バージョンの ファイルを受け取ります。 いくらか前のバージョンを受け取りたい場合は、 の value フィールドを使って日付を指定することで、 これを実現することが できます。&man.cvsup.1; のマニュアルページで、 その方法を説明しています。 例として、&os;-CURRENT を受け取りたいとします。 次の行を supfile の始めに追加します: *default tag=. tag= フィールドも date= フィールドも指定しなかった場合に 動き出す重要な特殊なケースがあります。そのケースでは、 特定のバージョンの ファイルを受け取るのではなく、 サーバの CVS リポジトリから実際の RCS ファイルを直接受け取ります。 一般的に開発者はこの処理のモードが好きなようです。 彼らのシステム上にリポジトリそのものの コピーを維持することで、 リビジョン履歴を閲覧し過去のバージョンの ファイルを検査できるようになります。しかし、 これには大きなディスクスペースが必要になります。 どこから入手したいのか? 更新情報をどこから入手するかを cvsup に伝えるために host= フィールドを使用します。 CVSup ミラーサイト のどこからでも入手できますが、 ネット上での最寄りのサイトを選ぶべきでしょう。 この例では、仮想上の &os; 配布サイト cvsup99.FreeBSD.org を使用します: *default host=cvsup99.FreeBSD.org CVSup を実行する前にホスト名を 実在のものに変更する必要があります。どのように cvsup を実行しても、この設定は を 使用してコマンドラインで変更することができます。 自分のマシンのどこに置きたいのか? prefix= フィールドは、 cvsup に受け取ったファイルをどこに置くかを伝えます。 この例では、ソースファイルを直接メインのソースツリー /usr/src に置きます。 src ディレクトリはすでにファイルを受け取るために 選択したコレクションで暗黙に指定しているので、 これは正しい仕様となります: *default prefix=/usr どこに status ファイルを置きたいのか? CVSup クライアントは base ディレクトリと呼ばれる場所に、ある status ファイルを維持しています。 すでに受け取った更新情報を追従し続けることで、 これらのファイルは CVSup がより効果的に動作することを支援します。標準の base ディレクトリ /var/db を使用します: *default base=/var/db base ディレクトリが存在しない場合は作成しておきましょう。base ディレクトリが存在しない場合、cvsup クライアントは実行を拒否します。 その他もろもろの supfile の設定: 通常 supfile に入れておくべき行がもう一つあります: *default release=cvs delete use-rel-suffix compress release=cvs は、サーバがメインの &os; CVS リポジトリから その情報を取得するように指示します。 ほとんどの場合はこのようにしておきますが、 ここでの説明の範疇をこえるような 状況では他の指定をすることも可能です。 delete は CVSup にファイルを削除することを許可します。 CVSup が ソースツリーを完全に最新の状態に 保てるようにするためには、これは常に 指定しておくべきでしょう。 CVSup は、 これらの責任範囲のファイルだけを慎重に削除します。 たまたま存在する他の余分なファイルについては、 まったく手をつけずに残しておきます。 use-rel-suffix は、…神秘的なものです。これについて本当に知りたい人は、 &man.cvsup.1; のマニュアルページをご覧ください。 でなければ、何も考えずに指定してみてください。 compress は通信チャネルで gzip 形式の圧縮の使用を有効にします。 ご使用のネットワーク接続が T1 speed 以上である場合、 この圧縮を使用しない方がよいかもしれません。 そうでない場合は十分に役に立ちます。 supfile の例のまとめ: 以下は supfile の例の全体です: *default tag=. *default host=cvsup99.FreeBSD.org *default prefix=/usr *default base=/var/db *default release=cvs delete use-rel-suffix compress src-all <filename>refuse</filename> ファイル 既に述べたように、CVSup は取り寄せ法 (pull method)を用いるのですが、 これは基本的に次のようなことを意味します。 まずあなたが CVSup サーバに接続します。 するとサーバは あなたがダウンロードできるのはこれこれです と言います。 それに対し、あなたが使っているクライアントは わかりました。 では、これとこれとこれをもらいます と答えます。 デフォルトの設定の CVSup クライアントは、 設定ファイルで選んだコレクションとタグに適合するすべてのファイルを取得します。 ツリーの一部をダウンロードするには、 refuse ファイルを使ってください。 refuse ファイルは CVSup に対し、 コレクションに含まれる一部のファイルを取得することを伝えます。 言い換えれば、それはクライアントに対し、 サーバから来る一部のファイルを拒否するよう指定するということです。 refuse ファイルは base/sup/ にあります (もしファイルがない場合には作成してください)。 base は supfile 内で定義されています。 私達は base に /var/db を定義しています。つまり、 refuse ファイルのデフォルトは /var/db/sup/refuse ということになります。 refuse ファイルの書式は、単にダウンロードしたくないファイルや ディレクトリの名前が書いてあるだけの非常にシンプルなものです。 たとえば、以下のような refuse ファイルが考えられます。 bin/ usr.bin/ まったく必要としないファイルをダウンロードする必要がなくなり、 インターネット接続の回線が遅かったり従量制で課金されている人は時間を節約できるようになります。 refuse ファイルの詳細や CVSup が持つその他の便利な機能に関しては マニュアルページを参照してください。 <application>CVSup</application> の実行 さて、更新の準備ができました。 これを実行するコマンドラインは実に簡単です: &prompt.root; cvsup supfile もちろん、ここでの supfile は作成したばかりの supfile のファイル名です。X11 環境で実行するものと仮定して、cvsup は 通常の操作に必要なボタンを持つ GUI ウィンドウを表示します。 go ボタンを押して、 実行を監視してください。 この例では実際の /usr/src ツリーを更新しているので、cvsup にファイルを更新するのに必要なパーミッションを与えるために、 ユーザ root で実行する必要があります。 コンフィグレーションファイルを作ったばかりで、 しかも以前にこのプログラムを実行したことがないので、 神経質になるのは無理もない話だと思います。 大切なファイルに触らずに試しに実行する簡単な方法があります。 どこか適当な場所に空のディレクトリを作成して、 コマンドラインの引数で指定するだけです: &prompt.root; mkdir /var/tmp/dest &prompt.root; cvsup supfile /var/tmp/dest 指定したディレクトリは、すべての更新されるファイルの 更新先ディレクトリとして使用します。 CVSup は /usr/src の下のファイルを検査しますが、 変更や削除はまったくおこないません。かわりに /var/tmp/dest/usr/src に更新されたすべてのファイルが置かれるようになります。 この方法で実行した場合は、CVSup は base ディレクトリの status ファイルを更新せずにそのままにします。 これらのファイルの新しいバージョンは指定されたディレクトリ に書き込まれます。/usr/src の読み取り許可がある限り、このような試し実行のためにユーザ root になる必要はありません。 X11 を利用していないとか単に GUI が気に入らない場合は、 cvsup 起動時にコマンドラインに 二つほどオプションを追加する必要があります: &prompt.root; cvsup -g -L 2 supfile オプションは CVSup に GUI を使用しないように伝えます。X11 を利用していない場合には自動的に指定されますが、 そうでない場合は明示的に指定します。 オプションは cvsup にファイル更新中の詳細情報をプリントアウト するように伝えます。冗長性には から までの三つのレベルがあります。 デフォルトは 0 であり、エラーメッセージ以外はまったく出力 しません。 たくさんの他のオプション変数があります。 それらの簡単な一覧は cvsup -H で表示されます。 より詳しい説明はマニュアルページをご覧ください。 動作している更新の方法に満足したら、&man.cron.8; を使って CVSup を定期的に 実行させる準備をすることができます。cron から起動する際には、 明示的に CVSup が GUI を使わないようにする必要があります。 <application>CVSup</application> ファイルコレクション CVSup 経由で入手できるファイルコレクションは 階層的に組織化されています。 いくつか大きなコレクションがあり、 それらは小さなサブコレクションに 分割されています。 大きなコレクションは、そのサブコレクション毎に 受信することと同じことになります。 下の一覧ではコレクション間の階層関係を 字下げして表現します。 最も一般的に使用するコレクションは src-all です。 cvs-all release=cvs メインの &os; CVS リポジトリであり、 暗号のコードを含んでいます。 distrib release=cvs &os; の配布とミラーに関連するファイルです。 projects-all release=cvs &os; プロジェクトのリポジトリのソース。 src-all release=cvs メインの &os; ソース群であり、 暗号のコードを含んでいます。 src-base release=cvs /usr/src のトップにあるその他のファイル。 src-bin release=cvs シングルユーザモードで必要な ユーザユーティリティ (/usr/src/bin)。 src-cddl release=cvs CDDL ライセンスのユーティリティおよびライブラリ (/usr/src/cddl)。 src-contrib release=cvs &os; プロジェクト外部からの ユーティリティおよびライブラリ、 比較的無修正 (/usr/src/contrib)。 src-crypto release=cvs &os; プロジェクトの外部で開発された暗号ユーティリティとライブラリで、 ほとんどそのままの形で使われます (/usr/src/crypto)。 src-eBones release=cvs Kerberos と DES (/usr/src/eBones) のこと。 現在の &os; リリースでは使われていません。 src-etc release=cvs システムコンフィグレーションファイル (/usr/src/etc)。 src-games release=cvs ゲーム (/usr/src/games)。 src-gnu release=cvs GNU Public License 下にあるユーティリティ (/usr/src/gnu)。 src-include release=cvs ヘッダファイル (/usr/src/include)。 src-kerberos5 release=cvs Kerberos5 セキュリティパッケージ (/usr/src/kerberos5)。 src-kerberosIV release=cvs KerberosIV セキュリティパッケージ (/usr/src/kerberosIV)。 src-lib release=cvs ライブラリ (/usr/src/lib)。 src-libexec release=cvs システムプログラムであり、 通常は他のプログラムから実行される (/usr/src/libexec)。 src-release release=cvs &os; の release を構築するために必要なファイル (/usr/src/release)。 src-rescue release=cvs システム復旧のためのスタティックリンクされている緊急用プログラム。 &man.rescue.8; をご覧ください (/usr/src/rescue)。 src-sbin release=cvs シングルユーザモード用の システムユーティリティ (/usr/src/sbin)。 src-secure release=cvs 暗号化ライブラリとコマンド (/usr/src/secure)。 src-share release=cvs 多様なシステム間で共有可能なファイル (/usr/src/share)。 src-sys release=cvs カーネル (/usr/src/sys)。 src-sys-crypto release=cvs カーネル用の暗号コード (/usr/src/sys/crypto)。 src-tools release=cvs &os; の保守用の色々なツール (/usr/src/tools)。 src-usrbin release=cvs ユーザユーティリティ (/usr/src/usr.bin)。 src-usrsbin release=cvs システムユーティリティ (/usr/src/usr.sbin)。 www release=cvs &os; WWW サイトのソースです。 distrib release=self CVSup サーバ自身のコンフィグレーションファイルです。CVSup ミラーサイトが使用します。 gnats release=current GNATS バグトラッキングデータベースです。 mail-archive release=current &os; 関連メーリングリストのアーカイブ。 詳細について CVSup の FAQ や CVSup に関するその他の情報については The CVSup Home Page をご覧ください。 CVSup のほとんどの &os; 関連の議論は &a.hackers; でおこなわれています。 ソフトウェアの新しいバージョンは &a.announce; で アナウンスされます。 CVSup に関する質問やバグ報告については CVSup FAQ をご覧ください。 CVSup サイト &os; の CVSup サーバは以下のサイトで稼働しています。 &chap.mirrors.cvsup.index.inc; &chap.mirrors.lastmod.inc; &chap.mirrors.cvsup.inc; CVS タグ CVS は、プロジェクトにおいて使用されなくなったため、 非推奨になりました。 かわりに Subversion を使ってください。 cvs や CVSup を使用してソースを入手したり同期させたりするとき、 リビジョンタグを指定しなければなりません。 リビジョンタグは、特定の &os; 開発ブランチか、 もしくはある時刻に対応しています。前者を ブランチタグ、 後者を リリースタグ と呼びます。 ブランチタグ ここにある HEAD (常に有効なタグ) 以外のすべてのタグは、src/ のみに有効です。 ports/、doc/、 www/ ツリーは、ブランチに分けられていません。 HEAD 主要部をなす流れ、すなわち &os;-CURRENT のための名前です。また、 どのリビジョンも指定されなかったときにはこれになります。 CVSup では、 このタグは . で表されます (句読点ではありません。. 文字そのものです)。 CVS ではこれがリビジョンタグが指定されなかった時のデフォルトです。 STABLE な計算機上に CURRENT のソースをチェクアウトしたりアップデートするのは、 思うところがあってやっているのというのでなければ、 よい考えとはいえません。 RELENG_9 &os;-9.X の開発のための流れです。 &os; 9-STABLE としても知られています。 RELENG_9_1 &os;-9.1 用のリリースブランチ。セキュリティ勧告や、 その他の深刻なセキュリティ上の修正があった場合にのみ使われます。 RELENG_9_0 &os;-9.0 用のリリースブランチ。セキュリティ勧告や その他の深刻なセキュリティ上の修正があった場合にのみ使われます。 RELENG_8 &os;-8.X の開発のための流れです。 &os; 8-STABLE としても知られています。 RELENG_8_3 &os;-8.3 用のリリースブランチ。セキュリティ勧告や、 その他の深刻なセキュリティ上の修正があった場合にのみ使われます。 RELENG_8_2 &os;-8.2 用のリリースブランチ。セキュリティ勧告や その他の深刻なセキュリティ上の修正があった場合にのみ使われます。 RELENG_8_1 &os;-8.1 用のリリースブランチ。セキュリティ勧告や その他の深刻なセキュリティ上の修正があった場合にのみ使われます。 RELENG_8_0 &os;-8.0 用のリリースブランチ。セキュリティ勧告や その他の深刻なセキュリティ上の修正があった場合にのみ使われます。 RELENG_7 &os;-7.X の開発のための流れです。 &os; 7-STABLE としても知られています。 RELENG_7_4 &os;-7.4 用のリリースブランチ。セキュリティ勧告や その他の深刻なセキュリティ上の修正があった場合にのみ使われます。 RELENG_7_3 &os;-7.3 用のリリースブランチ。セキュリティ勧告や その他の深刻なセキュリティ上の修正があった場合にのみ使われます。 RELENG_7_2 &os;-7.2 用のリリースブランチ。セキュリティ勧告や その他の深刻なセキュリティ上の修正があった場合にのみ使われます。 RELENG_7_1 &os;-7.1 用のリリースブランチ。セキュリティ勧告や その他の深刻なセキュリティ上の修正があった場合にのみ使われます。 RELENG_7_0 &os;-7.0 用のリリースブランチ。セキュリティ勧告や その他の深刻なセキュリティ上の修正があった場合にのみ使われます。 RELENG_6 &os;-6.X の開発のための流れです。 &os; 6-STABLE としても知られています。 RELENG_6_4 &os;-6.4 用のリリースブランチ。セキュリティ勧告や その他の深刻なセキュリティ上の修正があった場合にのみ使われます。 RELENG_6_3 &os;-6.3 用のリリースブランチ。セキュリティ勧告や その他の深刻なセキュリティ上の修正があった場合にのみ使われます。 RELENG_6_2 &os;-6.2 用のリリースブランチ。セキュリティ勧告や その他の深刻なセキュリティ上の修正があった場合にのみ使われます。 RELENG_6_1 &os;-6.1 用のリリースブランチ。セキュリティ勧告や その他の深刻なセキュリティ上の修正があった場合にのみ使われます。 RELENG_6_0 &os;-6.0 用のリリースブランチ。セキュリティ勧告や その他の深刻なセキュリティ上の修正があった場合にのみ使われます。 RELENG_5 &os;-5.X の開発のための流れです。 &os; 5-STABLE としても知られています。 RELENG_5_5 &os;-5.5 用のリリースブランチ。セキュリティ勧告や その他の深刻なセキュリティ上の修正があった場合にのみ使われます。 RELENG_5_4 &os;-5.4 用のリリースブランチ。セキュリティ勧告や その他の深刻なセキュリティ上の修正があった場合にのみ使われます。 RELENG_5_3 &os;-5.3 用のリリースブランチ。セキュリティ勧告や その他の深刻なセキュリティ上の修正があった場合にのみ使われます。 RELENG_5_2 &os;-5.2 および &os;-5.2.1 用のリリースブランチ。セキュリティ勧告や その他の深刻なセキュリティ上の修正があった場合にのみ使われます。 RELENG_5_1 &os;-5.1 用のリリースブランチ。セキュリティ勧告や その他の深刻なセキュリティ上の修正があった場合にのみ使われます。 RELENG_5_0 &os;-5.0 用のリリースブランチ。セキュリティ勧告や その他の重要なセキュリティ上の修正があった場合にのみ使われます。 RELENG_4 &os;-4.X の開発のための流れです。 &os; 4-STABLE としても知られています。 RELENG_4_11 &os;-4.11 用のリリースブランチ。セキュリティ勧告や その他の重要なセキュリティ上の修正があった場合にのみ使われます。 RELENG_4_10 &os;-4.10 用のリリースブランチ。セキュリティ勧告や その他の重要なセキュリティ上の修正があった場合にのみ使われます。 RELENG_4_9 &os;-4.9 用のリリースブランチ。セキュリティ勧告や その他の重要なセキュリティ上の修正があった場合にのみ使われます。 RELENG_4_8 &os;-4.8 用のリリースブランチ。セキュリティ勧告や その他の重要なセキュリティ上の修正があった場合にのみ使われます。 RELENG_4_7 &os;-4.7 用のリリースブランチ。セキュリティ勧告や その他の重要なセキュリティ上の修正があった場合にのみ使われます。 RELENG_4_6 &os;-4.6 および &os;-4.6.2 用のリリースブランチ。セキュリティ勧告や その他の重要なセキュリティ上の修正があった場合にのみ使われます。 RELENG_4_5 &os;-4.5 用のリリースブランチ。セキュリティ勧告や その他の重要なセキュリティ上の修正があった場合にのみ使われます。 RELENG_4_4 &os;-4.4 用のリリースブランチ。セキュリティ勧告や その他の重要なセキュリティ上の修正があった場合にのみ使われます。 RELENG_4_3 &os;-4.3 用のリリースブランチ。セキュリティ勧告や その他の重要なセキュリティ上の修正があった場合にのみ使われます。 RELENG_3 &os;-3.X の開発のための流れです。 3.X-STABLE としても知られています。 RELENG_2_2 &os;-2.2.X の開発のための流れです。2.2-STABLE としても知られています。このブランチは大部分が すたれています。 リリースタグ これらのタグは、各バージョンの &os; がリリースされた時点に対応しています。 リリースエンジニアリング工程は、 Release Engineering Information と Release Process に詳細にまとめられています。 src ツリーでは、 RELENG_ で始まる名前のタグが使われています。 ports ツリーおよび doc ツリーでは、 RELEASE で始まる名前のタグが使われています。 なお、www ツリーは、 リリースに際して特別なタグが付与されることはありません。 RELENG_9_1_0_RELEASE &os; 9.1 RELENG_9_0_0_RELEASE &os; 9.0 RELENG_8_3_0_RELEASE &os; 8.3 RELENG_8_2_0_RELEASE &os; 8.2 RELENG_8_1_0_RELEASE &os; 8.1 RELENG_8_0_0_RELEASE &os; 8.0 RELENG_7_4_0_RELEASE &os; 7.4 RELENG_7_3_0_RELEASE &os; 7.3 RELENG_7_2_0_RELEASE &os; 7.2 RELENG_7_1_0_RELEASE &os; 7.1 RELENG_7_0_0_RELEASE &os; 7.0 RELENG_6_4_0_RELEASE &os; 6.4 RELENG_6_3_0_RELEASE &os; 6.3 RELENG_6_2_0_RELEASE &os; 6.2 RELENG_6_1_0_RELEASE &os; 6.1 RELENG_6_0_0_RELEASE &os; 6.0 RELENG_5_5_0_RELEASE &os; 5.5 RELENG_5_4_0_RELEASE &os; 5.4 RELENG_4_11_0_RELEASE &os; 4.11 RELENG_5_3_0_RELEASE &os; 5.3 RELENG_4_10_0_RELEASE &os; 4.10 RELENG_5_2_1_RELEASE &os; 5.2.1 RELENG_5_2_0_RELEASE &os; 5.2 RELENG_4_9_0_RELEASE &os; 4.9 RELENG_5_1_0_RELEASE &os; 5.1 RELENG_4_8_0_RELEASE &os; 4.8 RELENG_5_0_0_RELEASE &os; 5.0 RELENG_4_7_0_RELEASE &os; 4.7 RELENG_4_6_2_RELEASE &os; 4.6.2 RELENG_4_6_1_RELEASE &os; 4.6.1 RELENG_4_6_0_RELEASE &os; 4.6 RELENG_4_5_0_RELEASE &os; 4.5 RELENG_4_4_0_RELEASE &os; 4.4 RELENG_4_3_0_RELEASE &os; 4.3 RELENG_4_2_0_RELEASE &os; 4.2 RELENG_4_1_1_RELEASE &os; 4.1.1 RELENG_4_1_0_RELEASE &os; 4.1 RELENG_4_0_0_RELEASE &os; 4.0 RELENG_3_5_0_RELEASE &os;-3.5 RELENG_3_4_0_RELEASE &os;-3.4 RELENG_3_3_0_RELEASE &os;-3.3 RELENG_3_2_0_RELEASE &os;-3.2 RELENG_3_1_0_RELEASE &os;-3.1 RELENG_3_0_0_RELEASE &os;-3.0 RELENG_2_2_8_RELEASE &os;-2.2.8 RELENG_2_2_7_RELEASE &os;-2.2.7 RELENG_2_2_6_RELEASE &os;-2.2.6 RELENG_2_2_5_RELEASE &os;-2.2.5 RELENG_2_2_2_RELEASE &os;-2.2.2 RELENG_2_2_1_RELEASE &os;-2.2.1 RELENG_2_2_0_RELEASE &os;-2.2.0 <application>rsync</application> ミラーサイト 次のサイトは、&os; を rsync プロトコルで提供しています。 rsync ユーティリティは &man.rcp.1; コマンドとほぼ同じ機能を実現するもので、 こちらの方が豊富なオプションを備え、送り側と受け側の差分だけを 転送するという rsync リモート更新プロトコルを使用するという点が異なります。 rsync を使うと、ネットワーク経由での同期を非常に高速に行なうことが可能です。 特に、&os; FTP サーバや CVS リポジトリのミラーサイトを作成する時に便利でしょう。 rsync は、多くのオペレーティングシステムで 利用することができます。&os; 版は、 net/rsync の port か、package を使ってください。 チェコ共和国 rsync://ftp.cz.FreeBSD.org/ 提供しているコレクション: ftp: &os; FTP サーバの部分ミラー &os;: &os; FTP サーバの全体ミラー オランダ rsync://ftp.nl.FreeBSD.org/ 提供しているコレクション: &os;: &os; FTP サーバの全体ミラー ロシア rsync://ftp.mtu.ru/ 提供しているコレクション: &os;: &os; FTP サーバの全体ミラー &os;-gnats: GNATS バグトラッキングデータベース &os;-Archive: &os; アーカイブ FTP サーバのミラー スウェーデン rsync://ftp4.se.freebsd.org/ 提供しているコレクション: &os;: &os; FTP サーバの全体ミラー 台湾 rsync://ftp.tw.FreeBSD.org/ rsync://ftp2.tw.FreeBSD.org/ rsync://ftp6.tw.FreeBSD.org/ 提供しているコレクション: &os;: &os; FTP サーバの全体ミラー イギリス rsync://rsync.mirrorservice.org/ 提供しているコレクション: ftp.freebsd.org: &os; FTP サーバの全体ミラー アメリカ合衆国 rsync://ftp-master.FreeBSD.org/ このサーバは、&os; の一次ミラーサイトとしてのみ使われています。 提供しているコレクション: &os;: &os; FTP サーバのマスタアーカイブ acl: The &os; マスタ ACL リスト rsync://ftp13.FreeBSD.org/ 提供しているコレクション: &os;: &os; FTP サーバの全体ミラー