diff --git a/ja_JP.eucJP/books/handbook/appendix.decl b/ja_JP.eucJP/books/handbook/appendix.decl new file mode 100644 index 0000000000..b7caea1f36 --- /dev/null +++ b/ja_JP.eucJP/books/handbook/appendix.decl @@ -0,0 +1,9 @@ + + + diff --git a/ja_JP.eucJP/books/handbook/boot/chapter.sgml b/ja_JP.eucJP/books/handbook/boot/chapter.sgml index cf2275d3db..800d9eed58 100644 --- a/ja_JP.eucJP/books/handbook/boot/chapter.sgml +++ b/ja_JP.eucJP/books/handbook/boot/chapter.sgml @@ -1,569 +1,569 @@ FreeBSD の起動のプロセス 概要 FreeBSD は通常, 起動(bootstrap)を三段階に分けて行ないます. これには基本的に, 互いに順番に呼び出される三つのプログラム(二つの 起動ブロック(boot block)と ローダ(loader))が使われています. これらのプログラムはそれぞれ, その前に呼び出されるプログラムの情報に基づいて動作し, より洗練された機能を提供します. - デバイスの検出と初期化が終わると, カーネルが起動されます. + その後カーネルが起動し, デバイスの検出と初期化を行ないます. そしてカーネルの起動が終わると, 制御はユーザープロセスの &man.init.8; へ移されます. &man.init.8; はまず ディスクが利用可能であることを確かめ, ファイルシステムのマウント, ネットワークで利用するネットワークカードのセットアップ, そして通常 FreeBSD システムで初期時に起動されるすべてのプロセスの起動, といったユーザーレベルでのリソース(資源)設定を行ないます. 起動ブロック: 起動ステージ 1 および 2 起動(bootstrap)とは, コンピュータが接続されたデバイスを検出, 初期化し, 必要となるプログラムを動作させることを指します. 起動には起動の際の動作が記録された, 特殊な読み出し専用メモリチップを利用します. その動作は通常, メモリテストやデバイスの設定を行なう他のチップに制御を渡し, そして設定された内容をプログラムに提供するというものです. 標準的な個人向けコンピュータでは, - BIOS と呼ばれる起動を行なう部分と, - CMOS と呼ばれる, 設定を記録する部分によって起動が実現されています. + BIOS (起動を行なう部分) と + CMOS (設定を記録する部分) によって起動を実現しています. これらはディスクが存在すること, そしてオペレーティングシステムをロードするためのプログラムが ディスク上のどこにあるのかを認識しています. この章では上に述べたような起動の初期の過程については扱いません. 焦点を合わせるのは, ディスク上のプログラムに制御が移された後の内容についてです. 起動ブロックは(通常), ローダを見つけて実行する役割を持っています. したがって, ファイルシステム上のプログラムを見つけること, 実行できること, そしてその動作に関して最低限の設定が可能である必要があります. boot0 まず実際に最初にあるのは boot0 と呼ばれる起動ブロックです. これは マスターブートレコード(MBR; Master Boot Record) という, システムが起動時にプログラムを検索するディスク上の特殊な部分に存在します. この部分は, 単に起動可能なスライスのリストが格納されています. boot0 は非常に単純なプログラムです. これは, MBR にあるプログラムは 512 バイトの大きさでなければならないという制限があるためです. boot0 は, 下のような出力をします. boot0 のスクリーンショット F1 DOS F2 FreeBSD F3 Linux F4 ?? F5 Drive 1 Default: F2 boot1 boot1 は起動スライス(slice)の起動セクタにあります. 起動セクタは boot0 が存在し, MBR にある他のプログラムが 起動のプロセスを続けるために必要なプログラムを探す部分です. boot1 も非常に単純なプログラムです. これは boot0 同様に, 512 バイトの大きさでなければならないという制限があるためです. boot1 は boot2 を検索し, 実行するため, そのスライスの情報を保持する FreeBSD のディスクラベル(disklabel) に関する最低限の情報を持っています. boot2 boot2 はもう少し高機能です. これは FreeBSDのファイルシステム上でファイルを見つける能力を持ち, 実行するカーネルやローダを指定するための簡単なインターフェイスを提供する事ができます. ローダ(loader)はさらに高機能なもので, 使いやすく簡単な起動設定が行なえる手段を提供します. boot2 は通常それを起動します. 以前の boot2 は, カーネルを直接起動する機能しかありませんでした. boot2 のスクリーンショット - >> FreeBSD/i386 BOOT + >> FreeBSD/i386 BOOT Default: 0:wd(0,a)/kernel boot: ローダ(loader): 起動ステージ 3 ローダは三段階の起動プロセスの最終段階です. ローダは通常, ファイルシステム上の /boot/loader として存在しています. /boot/boot0, /boot/boot1, /boot/boot2 というファイルがありますが, これらは MBR, 起動セクタ, ディスクラベルの実際のコピーではありません. ローダは, よりさまざまなコマンド群をサポートした 強力なインタープリタによって提供される簡易組み込みコマンド群を利用することで, ユーザが利用しやすい設定手段となるように設計されています. ローダプログラムの処理の流れ ローダは初期化の際にコンソールとディスクの検出を行ない, どのディスクから起動しているかを調べます. そして必要な変数を設定してからインタープリタを起動し, 簡易コマンドを解釈します. ローダは次に /boot/loader.rc を読み込み, 通常, 変数の標準値を定義した /boot/defaults/loader.conf と, そのマシンにローカルな変数を定義した /boot/loader.conf を読み込みます. loader.rc はそれらの変数にもとづき, 選択されたモジュールとカーネルをロードします. ローダは最後に, 標準設定で 10 秒のキー入力待ち時間を用意し, 入力がなければカーネルを起動します. 入力があった場合, 簡易コマンド群が使えるプロンプトが表示され, ユーザは変数を調整したり, すべてのモジュールをアンロードしたり, モジュールをロードしたりすることができます. その後, 最終的な起動や再起動へ移行します. この処理に関するより技術的な説明は &man.loader.8; にあります. ローダの組み込みコマンド 簡易コマンド群は, 次のようなもので構成されています. autoboot seconds seconds で与えられた時間内に入力がなければ, カーネルの起動へと進みます. カウントダウンを表示し, 標準設定では 10 秒間です. boot -options kernelname すぐにカーネルの起動へ進みます. オプション, カーネル名が指定されている場合は, それらが使われます. boot-conf すべてのモジュールの設定を, 起動時と同じように変数にもとづいて自動的に行ないます. このコマンドは, まず unload を行なって, 変数—普通 kernel など—を変更した場合にのみ有効に働きます. help topic /boot/loader.help を読み込み, ヘルプメッセージを表示します. topic に index 指定された場合, 利用可能な topic を表示します. include filename … 指定されたファイル名のファイルを処理します. ローダはファイルを読み込み, 行単位で解釈します. エラーが発生した場合, include コマンドの実行はその時点で停止します. load type filename 指定されたファイル名のカーネル, カーネルモジュール, あるいは type に指定された種類のファイルをロードします. ファイル名以降に指定された引数はファイルへと渡されます. ls path 指定された path にあるファイルを表示します. path が指定されていなければ, ルートディレクトリを表示します. が指定されていればファイルサイズも表示されます. lsdev モジュールがロード可能なすべてのデバイスを表示します. もし が指定されていれば, より詳細な出力がされます. lsmod ロード済みのモジュールを表示します. が指定されていれば, より詳細な内容が出力されます. more filename LINES 単位でスクロールを停止しながら指定されたファイルを表示します. reboot すぐにシステムを再起動します. set variable set variable=value ローダの環境変数を設定します. unload すべてのロード済みモジュールを削除します. ローダの使用例 次にあげるのは, ローダの実践的な使用例です. 普段使っているカーネルをシングルユーザモードで起動します. boot -s 普段使っているカーネルとモジュールをアンロードし, 古い(もしくは別の)カーネルをロードします. unload load kernel.old kernel.GENERIC とすると, インストールディスクに入っていた generic カーネルを指定することができます. また, 直前にインストールされていたカーネル(たとえば, カーネルを自分で設定したり, アップグレードしたりした場合)を指定するには kernel.old とします. 普段のカーネルで使っているモジュールを 指定したカーネルでロードする場合は, 下のようにします. unload set kernel="kernel.old" boot-conf カーネルの設定スクリプト(通常, カーネル起動時に設定される内容を自動化するスクリプト)をロードします. load -t userconfig_script /boot/kernel.conf カーネル起動時の応答 カーネルがローダ(通常は) かboot2 (ローダを迂回して)によってロードされると, 起動フラグを調べます. もし起動フラグがあれば, それに応じて動作を調整します. カーネル起動フラグ 良く使われる起動フラグは次のとおりです. カーネル初期化中に, ルートファイルシステムとしてマウントするデバイスを尋ねます. CDROM から起動します. 起動時にカーネルコンフィグレーションを行なう UserConfig を実行します. シングルユーザモードで起動します. カーネル起動時により詳細な情報を表示します. 起動フラグはこの他にもあります. それらについては &man.boot.8; を参照してください. Init: プロセス制御の初期化 カーネルの起動が完了すると, init というユーザプロセスに制御が移されます. これは /sbin/init, もしくは loader の init_path 変数で指定される場所にあります. 自動再起動(automatic reboot)の動作 自動再起動では, システム上で利用できるファイルシステムの一慣性を確認します. もしそれに問題があって fsck がその不一致を修復できなければ, 管理者に直接に処置させるため init はシステムをシングルユーザモードへと移行させます. シングルユーザモード このモードには, 自動再起動の処理中か, ユーザが起動時に を指定た場合, あるいは loader で boot_single 変数を設定することによって移行します. また, マルチユーザモードから 再起動オプション() や停止(halt)オプション()なしで shutdown を呼び出すとこのモードに移行します. /etc/ttys でシステムコンソール console が insecure に設定されている場合, システムはシングルユーザモードに移行する前に root のパスワードを入力するように求めます. /etc/ttys の insecure コンソール # name getty type status comments # # This entry needed for asking password when init goes to single-user mode # If you want to be asked for password, change "secure" to "insecure" here # # 訳) このエントリは init がシングルユーザモードへ移行する際にパスワードを要 # 求させるために必要です. もし, パスワードの要求を望む場合, ここの "secure" を # "insecure" へ変更してください. # console none unknown off insecure insecure コンソールとは, あなた自身, コンソールが物理的に安全でないと考えていて, root パスワードを知る人だけがシングルユーザモードを使えるようにしたいという意味であり, コンソールを安全でない状態で使いたいという意味ではありません. そのため, 安全性を求めるならば secure でなく insecure を選んでください. マルチユーザモード init がファイルシステムが正常であると判断するか, ユーザがシングルユーザモードを終了すると, システムはマルチユーザモードへ移行し, リソースの設定を始めます. リソース設定(rc) リソース設定システムはデフォルト設定を /etc/defaults/rc.conf から, そのシステム独自の細かな設定を /etc/rc.conf から読み込みます. そして /etc/fstab に記述されるシステムファイルシステムをマウントし, ネットワークサービスの開始, さまざまなシステムデーモンの開始, そして最後に, ローカルにインストールされた package の起動スクリプトの実行へと進みます. リソース設定システムのに関する参考資料は, &man.rc.8; にあります. これはスクリプトそのものを調べることと同じくらい優れたものです. シャットダウン動作 shutdown を用いてシステムを意図的にシャットダウンした場合, init は /etc/rc.shutdown というスクリプトの実行を試みます. そして, すべてのプロセスへ終了(terminate)シグナルを送り, 続いてうまく終了できなかったプロセスへ 強制終了(kill)シグナルを送ります. diff --git a/ja_JP.eucJP/books/handbook/cutting-edge/chapter.sgml b/ja_JP.eucJP/books/handbook/cutting-edge/chapter.sgml index a439275635..e79e2bb973 100644 --- a/ja_JP.eucJP/books/handbook/cutting-edge/chapter.sgml +++ b/ja_JP.eucJP/books/handbook/cutting-edge/chapter.sgml @@ -1,2209 +1,1879 @@ 開発の最前線 - 再構成, 再編成, 一部更新: &a.jim; - March 2000. 原作: &a.jkh;, &a.phk;, &a.jdp;, &a.nik;, - およびたくさんのフィードバック. + 再構成, 再編成, 一部更新: &a.jim;, 2000 年 3 月. + + 原作: &a.jkh;, &a.phk;, &a.jdp;, &a.nik;, + およびたくさんのフィードバック. 概要 - あるリリースから次のリリースまでの期間にも, FreeBSD の開発は - 休みなく続けられています. - この開発の最前線に興味を持っている人のために, - 手元のシステムを最新の開発ツリーに同期させておくための, - とても使いやすい仕掛けが何種類も用意されています. 注意: - 開発の最前線は, 誰でもが扱えるという性質のものではありません! - もしもあなたが, 開発途中のシステムを追いかけようか, - それともリリース - バージョンのどれかを使い続けようかと迷っているのなら, - きっとこの章が参考になるでしょう. + あるリリースから次のリリースまでの期間にも, FreeBSD の開発は + 休みなく続けられています. + この開発の最前線に興味を持っている人のために, + 手元のシステムを最新の開発ツリーに同期させておくための, + とても使いやすい仕掛けが何種類も用意されています. 注意: + 開発の最前線は, 誰でもが扱えるという性質のものではありません! + もしもあなたが, 開発途中のシステムを追いかけようか, + それともリリース + バージョンのどれかを使い続けようかと迷っているのなら, + きっとこの章が参考になるでしょう. -CURRENT v.s.. -STABLE FreeBSD には二つの開発ブランチがあります. -CURRENT と -STABLE です. この章ではそれぞれについて少しだけ説明し, どのようにしてあなたの システムを対応するツリーに対して常に最新の状態にに保つかについて 記述します. まず -CURRENT を論じ, ついで -STABLE を論じます. - 訳: &a.hanai; 6 November 1996. + 訳: &a.hanai;, 1996 年 11 月 6 日. 最新のFreeBSDを追いかける これを読むならば, 心に止めておいて欲しいことがあります. -CURRENT とは FreeBSD の開発における 切断面 であり, 故にあなたが FreeBSD を使い始めたばかりなら あなたはこれがすることについて十分検討を重ねた方がいいでしょう. FreeBSD-current ってなに? FreeBSD-CURRENT とは, 文字通りに, 日々変更されている FreeBSD のソース のスナップショット以外の何ものでもありません. 中には現在開発途上のソフトウェア, 実験的な変更, あるいは過渡的な機能などが含まれています. また, この中に入っている機能がすべて次の公式リリースに 入るとはかぎりません. FreeBSD-CURRENT をソースからほとんど毎日コンパイルしている人はたくさん いますが, 時期によっては FreeBSD-CURRENT はコンパイルさえできない状態になっていることもあります. これらの問題は一般的には可能な限り素早く解決されますが, FreeBSD-CURRENT のソースが不幸をもたらすか, それとも非常に 素晴らしい機能をもたらすかというのは文字通り, ある与えられた 24 時間の間 のどの部分であなたがソースを手に入れたか, による場合もあります. 誰が FreeBSD-current を必要としてるの? FreeBSD-CURRENT は, 主に次の三つの重要なグループを対象としています. ソースツリーのある部分に関して活発に作業している FreeBSD グループのメンバー. 彼らにとっては 最新のもの にしておくのが 絶対に必要なことなのです. 活発にテストをする FreeBSD グループのメンバー. 彼らは, FreeBSD-CURRENT を 健全である ことを出来るだけ確認するために種々の問題と戦うのに 時間を費やすのを厭わない人々です. 彼らはまた, 様々な変更に関する提案や FreeBSD の大まかな方向付けを行ないたいと思っている 人々でもあります. 単に, 様々な事に目を向け, 参考のために (例えば, 動かすためではなく 読むため に) 最新のソースを使いたいと思っている FreeBSD (または他の) グループのまわりにいるメンバー. これらの人々はまた, 時々コメントやコードを寄稿してくれます. FreeBSD-CURRENT に期待しては<emphasis>いけない</emphasis>ことは? なにか新しくカッコイイモノがあると聞き, 自分の周囲では 一番にそれを持ちたいがためにリリース前のコードの断片を 追いかけること. バグを修正するための素早い方法. 我々によって 公式にサポートされている こと. 私たちは 3 つの 公式な FreeBSD-CURRENT のグループの一つに実際に属する 人々を助けるのにベストを尽くしますが, 技術的なサポートを行なうには 単に「時間が足りない」のです. これは我々が外の人を助けるの好まない, ケチで意地悪い人間だと いうことではなく (もしそうなら FreeBSD なんかやっていません), 文字通り我々は一日に 400 ものメッセージに答え かつ FreeBSD の作業をすることなど出来ない! ということなのです. もし, たくさんの質問に答えるか, それとも FreeBSD を良くする作業を続けるかという選択が与えられた場合, あなた方のほとんどは後者を支持する, と私は確信しています. FreeBSD-CURRENT を使う &a.current;と&a.cvsall;に加わって下さい. これは単に良い考えであるというだけでなく, 必須のことなのです. もし FreeBSD-current メーリングリストに入っていなければ, 様々な人がシステムの現在の状態について 述べているコメントを決して見ることはありませんし, 従って他の人が既に見つけて解決している多くの問題に戸惑っ てあきらめてしまうでしょう. さらに言うと, システムを正常に保つための 重要な情報を見逃してしまう可能性もあります. &a.cvsall; メーリングリストでは, それぞれの変更についての commit ログを見ることができますし, それに関して起こり得る副作用の情報を得ることができ, もう一つの加わるに値するメーリングリストです. これらのメーリングリストに入るには, &a.majordomo; へ subscribe freebsd-current subscribe cvs-all と書いたメールを送って下さい. オプションとして本文に help と書けば, Majordomo はあなたへ我々がサポ ートする様々なメーリングリストに参加 / 脱退する方法に関する詳しい ヘルプを送ります. ftp.FreeBSD.org からのソースの入手. 以下の3つの方法で行なうこと が出来ます. 下に述べられているCTMを用いる. 均一なレートの, 良質の TCP/IP 接続を持っていない人には, これが一番いい方法でしょう. cvsup を この supfile を用いて使用する. これは 2 番目に推薦される方法です. なぜなら, cvsup によって一度全体を入手し, 後は変更されたところだけを入手することが 出来るからです. たくさんの人が自動的にソースを最新のもに保つために cvsup を cron から起動しています. これを行なうための非常に簡単な方法は, 単に
&prompt.root; pkg_add -f \ ftp://ftp.FreeBSD.org/pub/FreeBSD/development/CVSup/cvsupit.tgz
とタイプすることです. ftp を使う. FreeBSD-current のソースツリーは常に ftp://ftp.FreeBSD.org/pub/FreeBSD/FreeBSD-current/ に 公開 されています. 我々はまた全体を compress/tar して入手できる wu-ftpd を使っています. 例えば, usr.bin/lex があったとすると, ftp> cd usr.bin ftp> get lex.tar とすることにより, ディレクトリ全体(この場合, usr.bin/lex以下全体) を tar ファイルとして入手することができます. 以上のことをまとめると, 必要に応じて迅速なアクセスをする必要があり, 接続のバンド幅が問題ではなければ cvsup か ftp を使いましょう. そうではなければ CTM を使いましょう. もしソースを, 眺めるだけでなく走らせるために入手しているのであれば, 一部だけ選ぶのではなく, current の全体を手に入れてください. なぜなら, ソースの様々な部分が他の部分の更新に依存しており, 一部のみをコンパイルしようとすると, ほぼ間違いなくトラブルを起こすからです. current をコンパイルする前に /usr/src にある Makefile をよく読んでください. アップグレードの処理の一部として, 少なくとも一回は最初に make world を行なうべきでしょう. &a.current; を読めば, 次のリリースへ向けて, 時々必要になる 他のブートストラップの方法に関して 常に最新情報を得ることが出来ます. アクティブになって下さい! もし FreeBSD-CURRENT を走らせているなら我々はそれに関するコメント, 特に拡張やバグ潰しに関する提案, を欲しています. コードを伴う提案はもっとも歓迎されるものです! FreeBSD の安定状態の持続 あなたが FreeBSD をプロダクション環境下で使っていて -CURRENT 系列からの修正の最新版を得ていることを確実にしたいなら -STABLE を使っていた方がいいでしょう. これは新しいリリースが まとめられた時 -RELEASE がこれから分岐するツリーです. たとえば, あなたが 3.4-RELEASE のコピーを持っていたとして, それは単に CD-ROM にまとめられた -STABLE 系列の snapshot に過ぎません. -RELEASE 以降に -STABLE にマージされた差分を入手するには -STABLE 系列を 追跡する必要があります. 訳: &a.jp.iwasaki;. FreeBSD-STABLE ってなに? FreeBSD-STABLE は, 次の本流のリリースを目指した新機能をあまり採り入 れない保守的な変更のための開発の支流です. 実験的またはテスト未完の変更はこの支流には取り入れられません (最新の FreeBSD を追いかける 参照). 誰が FreeBSD-STABLE を必要としているの? もしあなたが仕事で使用しているとか, なによりも FreeBSD システムの安定性を最重要視するなら, stable を追いかけることを考えるべきで しょう. stable の支流は前のリリースに関して効果的にバグフィックスされた 流れであるため, 最新のリリース ( &rel.current;-RELEASE 執筆時点) をインストールしているのであれば, 特にそうです. stable ツリーが常に完全に互換性があり安定するように努力し ていますが, たまに間違いがあることに注意してください (結局, 内容が吟味 されずに素早く送られた変更を含むソースがまだあるのです). また, current を stable へ移行する前に完璧なテストフィックスに最善を尽くしますが, 私たちのテストはすべてのケースを十分に網羅して いるとは限りません. もし何か stable で不具合があるようでしたら, 私たちにすぐに教えてください (次の節参照). FreeBSD-STABLE を使う &a.stable; へ加わってください. このメーリングリスト では, stable の構築に関連する事柄や, その他の注意すべき点 に関する情報が流れています. また開発者は議論の余地がある修正や変更を考えている場合に, このメーリングリストで公表し, 提案された変更に 関して問題が生じるかどうかを返答する機会を ユーザに与えます. また, &a.cvsall; メーリングリストでは, それぞれの変更がなされると 起こりうる副作用に関するすべての適切な情報と一緒に commit log を読むことができます. subscribe しておきたいもう一つのメーリングリストです. メーリングリストに参加するには, &a.majordomo へメッセージの本文に 次のように書いたメールを送ってください: subscribe freebsd-stable subscribe cvs-all オプションとして本文に `help' と書けば, Majordomo は私たちがサポートする様々なメーリングリストに参加 / 脱退する方法に関する詳しいヘルプを送付します. もし, あなたが新しいシステムをインストールしようとしていて それを可能な限り安定なものにしておきたいなら, 最新のブランチの snapshot を ftp://releng4.freebsd.org/pub/FreeBSD から取得し, これを一般のリリースのものと同様に インストールしてください. もし, 既に FreeBSD の以前のリリースが動いている場合で, これをソースからアップグレードしようとするならば, ftp.FreeBSD.org より簡単に これを行う事が出来ます. これには次の 3 つの方法があります. CTM 機能を使用する. 転送レートが安定している TCP/IP 接続でない場合は, この方法が適しています. cvsup を この supfile を用いて使用する. 一度コレクション全体を入手してしまえば, 前回からの変更部分だけですむので, 2 番目に推奨される方法です. 多くの人が cron から cvsup を実行し, 自動的にソースコードを最新の状態に保っています. これを簡単に扱うには次のようにタイプしてください.
&prompt.root; pkg_add -f \ ftp://ftp.FreeBSD.org/pub/FreeBSD/development/CVSup/cvsupit.tgz
 ftp を使用する. FreeBSD-STABLE 用のソースツリーは 常に次のところで公開されています: ftp://ftp.FreeBSD.org/pub/FreeBSD/FreeBSD-stable/ 私たちはまた, tar/compress でツリー全体を入手できる wu-ftpd を使用しています. 例えば : usr.bin/lex に対して: ftp> cd usr.bin ftp> get lex.tar とすることにより, ディレクトリ全体を tar ファイルとして入手することができます. 基本的には, ソースに迅速でオンデマンドなアクセスが必要で, 接続のバンド幅が問題でなければ, cvsup か ftp を使いましょう. そうで ない場合は CTM を使いましょう. stable をコンパイルする前に, /usr/src にある Makefile をよ く読んでください. 少なくとも一回はアップグレードの処理の一部として最初に make world を実行するべきでしょう. &a.stable; を読めば, 次のリリースに移行する に当たって時々必要となる既存システムからの 新システムの構築手順に ついての最新情報が得られるでしょう. あなたのソースを同期させる 訳: &a.jp.iwasaki;. 13 September 1997. インターネット接続 (または電子メール) を使用して, あなたの興味の対象によって FreeBSD プロジェクトのソースのある一部分または全体の最新を 追いかける方法は色々あります. 私たちが提供している基本的なサービスは Anonymous CVS, CVSup と CTM です: Anonymous CVS と CVSup は pull 同期モデルを採用しています. CVSup の場合, ユーザ (または cron スクリプト) が cvsup 起動し, どこかにある cvsupd サーバとやりとりしてファイルを 最新状態にします. 届けられる更新情報はその時点の最新のものであり, また必要な時にだけ取り寄せられます. 興味のある特定のファイルやディレクトリに 限定して更新することも簡単にできます. クライアント側のソースツリーの状態・ 設定ファイルの指定に従い, サーバによって更新情報が 素早く生成されます. Anonymous CVS は, このプログラムがリモートの CVS リポジトリから直接変更点を pull できるようにした &man.cvs.1; への拡張であるという点で, CVSup よりもずっと単純です. CVSup は効率の点ではるかにまさっていますが, Anonymous CVS の方が簡単に利用できます. 一方, CTM はあなたが持っているソースとマスタアーカイブ上に あるそれとの対話的な比較をおこないませんし, あるいは向こう側から変更点を pull したりもしません. そのかわりに, 前回の実行時からの変更を認識するスクリプトが マスタ CTM マシン上で一日に数回実行され, すべての変更を compress して通し番号を振り, さらに電子メールで転送できるようにエンコードします (印字可能な ASCII キャラクタのみです). 受信した後は, これらの CTM のデルタ は自動 的にデコード, 検査してユーザのソースのコピーに変更を適用する &man.ctm.rmail.1; によって処理可能となります. この処理は CVSup や Anonymous CVS よりずっと効率 的であり, pull モデルというよりむしろ push モデルで あるため, 私たちのサーバ資源の負荷は軽くなります. もちろん他のトレードオフもあります. うっかりアーカイブ の一部を消してしまっても, CVSup は壊れた部分を検出して再構築してくれます. CTM はこれをやってくれませんし, Anonymous CVS はおそらく他の何よりも深く混乱してしまうことが多いでしょう. もしソースツリーの一部を消してしまったら, (最新の CVS ベースデルタから) 一からやり直し, CTM か anoncvs を使って悪い部分を消去し, 再同期させることによって すべてを再構築しなければなりません. Anonymous CVS, CTM, CVSup についての 詳しい情報については, - 以下の節を参照してください: - - - Anonymous CVS - - 訳: &a.jp.sugimura;. 19 July 1998. - - - <anchor id="anoncvs-intro">導入 - - Anonymous CVS (もしくは, anoncvs - として知られています) は離れたところにある CVS - リポジトリと同期を取るために FreeBSD に付属している CVS - ユーティリティに含まれている機能です. 他にもありますが, - それは FreeBSD のユーザが, 特別な権限なしに FreeBSD - プロジェクトの公式な anoncvs サーバに読み取り専用で CVS - の操作をすることができるようにするためのものです. - それを使うには, 単に CVSROOT - 環境変数を設定して適切な anoncvs サーバを指定し, - cvs login を使って - パスワード anoncvs を入力して下さい. - そして次に, &man.cvs.1; コマンドを使うことで, - 手元にあるリポジトリと同じようにアクセスでるようになります. - - CVSup と - anoncvs - のサービスは本質的に同じ機能ではないか - ということも言われていますが, - ユーザが同期を取る方法を選ぶときに影響を与えるような - さまざまなトレードオフが存在します. 要約して言えば, - CVSup - はネットワーク資源の使い方においては非常に効率がよく, - またはるかに技術的に洗練されたものですが, - 相当な手間がかかります. CVSup - を使うには, - 特別なクライアントをまずインストールして設定しなくては 1bit - も取ってくることができず, またそのとき - CVSup では - collections - と呼んでいるかなり大きなかたまりだけからしか - 取ってこれません. - - それに対して anoncvs では, - CVS モジュールの名前を指定することで特定のプログラムの - (ls や grep のような) - 個々のファイルから調べることができます. もちろん, - anoncvs は CVS - リポジトリの読み取り専用の操作に対してのみ適しているので, - もしあなたが FreeBSD プロジェクトのものと共有されたなにか - ローカルなリポジトリを作ってそこでの開発を - 行おうというときには, CVSup - だけが唯一の手段となってしまいます. - - - - <anchor id="anoncvs-usage">Anonymous CVS を使う - - &man.cvs.1; を設定して Anonymous CVS - リポジトリを使うには単に CVSROOT - 環境変数を設定して FreeBSD プロジェクトの - anoncvs サーバを指定するだけのことです. - この文書を書いているときには, - 次のサーバが利用できるようになっています. - - - - USA: - :pserver:anoncvs@anoncvs.freebsd.org:/ncvs - (cvs login コマンドを使い, - プロンプトが表示されたらパスワード - anoncvs を入力してください) - - - - CVS はかつて存在した (もしくは, - 時にはこれから存在するものも :) - ほとんどどんなバージョンの FreeBSD のソースを check - out することができますが, あなたは &man.cvs.1; の - リビジョン () のオプションや FreeBSD - プロジェクトのリポジトリの中で - それをどのように指定したらいいものかということを - よく知っておく必要があります. - - タグには 2 種類あって, - リビジョンタグとブランチタグがあります. - リビジョンタグは特定の改訂版を指しており, - それはいつも同じものを意味しています. 一方ブランチタグは, - 指定されたときの指定された開発の流れにおける - 最も新しい改訂版を示しています. - ブランチタグは特定の改訂版を指していないために, - その意味はきょうと明日では違うものになっているでしょう. - - - ユーザが興味を持つと思われるブランチタグの一覧です - (ports コレクションに - 有効なタグはHEAD だけだという事を - 心に留めておいてください). - - - - HEAD - - 主要部をなす流れ, すなわち FreeBSD-CURRENT - のための名前です. また, - どのリビジョンも - 指定されなかったときにはこれになります. - - - - - RELENG_4 - - - FreeBSD-4.X の開発のための流れです. - FreeBSD-STABLE としても知られています. - - - - - RELENG_3 - - FreeBSD-3.X の開発のための流れです. - 3.X-STABLE としても知られています. - - - - - RELENG_2_2 - - FreeBSD-2.2.X の開発のための流れです. 2.2-STABLE - としても知られています. このブランチは大部分が - すたれています. - - - - - ユーザが興味を持つであろうリビジョンタグの一覧です. - これらのどれも ports コレクションには無効です. - ports コレクションは複数のリビジョンを持ちません - - - - - RELENG_4_0_0_RELEASE - - - FreeBSD 4.0 です. - - - - - RELENG_3_4_0_RELEASE - - FreeBSD-3.4 です. - - - - - RELENG_3_3_0_RELEASE - - - FreeBSD-3.3 です. - - - - - - RELENG_3_2_0_RELEASE - - - FreeBSD-3.2 です. - - - - - RELENG_3_1_0_RELEASE - - FreeBSD-3.1 です. - - - - - RELENG_3_0_0_RELEASE - - FreeBSD-3.0 です. - - - - - RELENG_2_2_8_RELEASE - - FreeBSD-2.2.8 です. - - - - - RELENG_2_2_7_RELEASE - - FreeBSD-2.2.7 です. - - - - - RELENG_2_2_6_RELEASE - - FreeBSD-2.2.6 です. - - - - - RELENG_2_2_5_RELEASE - - FreeBSD-2.2.5 です. - - - - - RELENG_2_2_2_RELEASE - - FreeBSD-2.2.2 です. - - - - - RELENG_2_2_1_RELEASE - - FreeBSD-2.2.1 です. - - - - - RELENG_2_2_0_RELEASE - - FreeBSD-2.2.0 です. - - - - - ブランチタグを指定したときには, - 普通はその開発の流れにおける - 最も新しいバージョンのファイルを受け取ることができます. - もし以前のバージョンのものが欲しいときには, 日付を - - オプションを使って指定すればよいです. - これ以上のことは &man.cvs.1; man page を見てください. - - - - 例 - - 本当はなにかする前には &man.cvs.1; - のマニュアルページの全体を - ちゃんと読んでからのほうがいいのですが, Anonymous CVS - の使い方の本質的なところを簡単に例を挙げて説明します. - - - -CURRENT (&man.ls.1;) - をちょっと確認してから消してみます. - - -&prompt.user; setenv CVSROOT :pserver:anoncvs@anoncvs.freebsd.org:/ncvs -&prompt.user; cvs login -プロンプトが表示されたら, パスワード anoncvs を入力します. -&prompt.user; cvs co ls -&prompt.user; cvs release -d ls -&prompt.user; cvs logout - - - - &man.ls.1; のバージョンを 3.X-STABLE - ブランチから調べてみます. - - -&prompt.user; setenv CVSROOT :pserver:anoncvs@anoncvs.freebsd.org:/ncvs -&prompt.user; cvs login -プロンプトが表示されたら, パスワード anoncvs を入力します. -&prompt.user; cvs co -rRELENG_3 ls -&prompt.user; cvs release -d ls -&prompt.user; cvs logout - - - - &man.ls.1; の変更点のリストを - (unified diff で) 作ってみます. - - -&prompt.user; setenv CVSROOT :pserver:anoncvs@anoncvs.freebsd.org:/ncvs -&prompt.user; cvs login -プロンプトが表示されたら, パスワード anoncvs を入力します. -&prompt.user; cvs rdiff -u -rRELENG_3_0_0_RELEASE -rRELENG_3_4_0_RELEASE ls -&prompt.user; cvs logout - - - - 他のどんなモジュールの名前が - 使われているか検索してみます. - - -&prompt.user; setenv CVSROOT :pserver:anoncvs@anoncvs.freebsd.org:/ncvs -&prompt.user; cvs login -プロンプトが表示されたら, パスワード anoncvs を入力します. -&prompt.user; more modules/modules -&prompt.user; cvs release -d modules -&prompt.user; cvs logout - - - - - 他の資料 - - 次の資料は CVS を学ぶのに役に立つでしょう. - - - - CVS チュートリアル. Cal Poly によります. - - - - Cyclic - Software, 商用として CVS を維持しています. - - - - CVSWeb - は FreeBSD Project の CVS のための web - インターフェースです. - - - - + 以下の節を参照してください. <command>make world</command> の利用 FreeBSD のどれか特定のバージョン (stable, current など) について, ローカルのソースツリーを同期させたら, そのソースツリーを使ってシステムを 再構築しなければなりません. バックアップを作成する システムを再構築する前にバックアップを 作成することの重要性は, いくら強調してもし過ぎると言うことはありません. システム全体の再構築とは (以降に書かれた手順に従っている限り)難しい作業ではありませんが, どんなに注意していたとしても, あなた自身, あるいはソースツリーで作業している他の人達に手違いがあった時には, システムが起動しなくなってしまう状態になることがあるのです. まず, バックアップがきちんと作成されていることを確認して下さい. そして, fix-it フロッピーを用意して下さい. 私は今までに, 一度もバックアップや fix-it フロッピーのお世話になったことはありませんし, これからもそうなるようなことはないと思っていますが, どういう場合であっても用意しておいて損はないでしょう. メーリングリストに参加する もともと, -STABLE と -CURRENT のコードブランチは, 開発中のものです. FreeBSD の作業に貢献してくださっている人達も人間ですから, 時にはミスをすることだってあるでしょう. そのような間違いは, 単に警告を示す見慣れない 診断メッセージをシステムが,表示するような, 全く害のないものであることもあれば, システムを起動できなくしたり, ファイルシステムを破壊してしまうような, 恐ろしい結果を招くものかも知れません. 万が一, このような問題が生じた場合, 問題の詳細と, どのようなシステムが影響を受けるかについて書かれた 注意(heads up)の記事が 適切なメーリングリストに投稿され, そして, その問題が解決されると, 問題解決(all clear)のアナウンス記事が同様に 投稿されます. -STABLE や -CURRENT ブランチを試したり, それらに 追随していくときに FreeBSD-stable@FreeBSD.ORG や FreeBSD-current@FreeBSD.ORG を読まないというのは, 自ら災難を招くことになるでしょう. 訳注: これらのメーリングリストは英語でやりとりされているため, 日本語での投稿は歓迎されません. 英語でのやりとりができない人は, FreeBSD 友の会 の運営しているメーリングリストをあたってみるのがいいでしょう. <filename>/usr/src/UPDATING</filename> を読む 何を始めるにしろ, まず最初に /usr/src/UPDATING (もしくはあなたがソースコードを どこにコピーしたにせよそれに相当するファイル) を読みましょう. このファイルにはあなたが遭遇するかも知れない問題に対する重要な情報を 含んでいたり, あなたが特定のコマンドを実行しなければならなくなった時 その順序を指示したりするはずです. UPDATING があなたが読んだ事柄と矛盾している時は UPDATING が優先します. UPDATING を読むということは, 前述の 適切なメーリングリストを購読する代わりにはなりません. 二つの要求は相補的なもので排他的なものではないのです. <filename>/etc/make.conf</filename> の確認 まず, /etc/defaults/make.conf と /etc/make.conf を調べてください. そこには 最初から標準的なものが (多くのものはコメントアウトされていますが) 含まれています. ソースからシステムを再構築するときに make が /etc/make.conf に付け加えられた設定を使用します. /etc/make.conf に追加された設定は make を実行したときに常に使われることを覚えておいてください. それらをあなたのシステムに合うように設定しておくとよいでしょう. ( FreeBSD 開発者でない) 標準的なユーザならおそらく /etc/defaults/make.conf の CFLAGS と NOPROFILE の行を追加したいでしょう. 最初の状態では, すべてがコメントアウトされています. 必要だと思う項目のコメントをはずして下さい. (開発者でない)標準的なユーザならおそらく, CFLAGS と NOPROFILE のコメントをはずすことを考えると思います. もし, 浮動小数点演算ユニット(386DX, 486DX, Pentium と, それより上のクラスのマシン)がある場合には, HAVE_FPU の行のコメントをはずすことができます. </para> <!-- hrs:2000/01/13 386DX doesn't have FPU. --> <para>この定義は, FreeBSD 2.2.2 以降で廃止されました. </para> </note> <para>他の定義 (COPTFLAGS, NOPORTDOCS など) の定義行についても, コメントを外す必要があるかどうか調べておきましょう. </para> </sect2> <sect2> <title><filename>/etc/group</filename> の更新 /etc ディレクトリには, システム起動時に実行されるスクリプトだけでなく, あなたのシステムの設定に関連する情報の大部分が 含まれています. そのディレクトリに含まれる スクリプトは, FreeBSD のバージョンによって多少異なります. また, 設定ファイルのなかには, 稼働中のシステムが日々利用している ものもあります. 実際には, /etc/group などがそれに該当します. make world のインストールの段階では, 特定のユーザ名, あるいはグループが存在していることを 要求する場面があります. システムのアップグレードを行なう際には, それらのグループが削除, あるいは変更されて存在していない可能性が 考えられますが, そういった場合, システムのアップグレードを 行なっている間に, 問題が発生する原因になります. この種の例でもっとも記憶に新しいのは, ppp サブシステムがインストールされる時, そのサブシステムが利用する 解決方法は, /usr/src/etc/group を調べ, 自分のシステムのグループ名リストと比較することです. 最新のファイルに含まれていて, あなたのファイルに含まれていない グループ名があれば, あなたのファイルにそのグループ名をコピーして下さい. 同様に, 名前が異なるにも関わらず, /etc/group と /usr/src/etc/group で同じ GID を持っているグループ名があれば, /etc/group に含まれる, 該当するすべてのグループ名を変更しておかなければなりません. もし, あなたがもっと神経質な人なら, あなたが名前を変更したり, 削除してしまったグループが所有しているファイルを, 次のようにして調べることもできます. &prompt.root; find / -group GID -print これは GID(グループ名もしくは数字で示されたグループ ID)で 指定されたグループが所有するすべてのファイルを表示します. コンパイルは, シングルユーザモードで行なった方が良いでしょう. そうすることで多少速度が向上する, というちょっとした利点が あるだけでなく, システムの再インストールは重要なシステムファイル, 標準コマンド, ライブラリ, インクルードファイルなどを操作します. 稼働中のシステムに(特に他のユーザがログインしている時に)そのような 変更を加えることは, トラブルを引き起こす原因となります. </para> <para>自信家の方は, このステップを省略しても構いません.</para> <note> <title>FreeBSD 2.2.5-RELEASE 以降の場合 以下に詳しく述べられているように, 2.2.5-RELEASE 以降, ビルド(システムの構築)とインストールの行程を分離して行なうことが可能になりました. そのため, マルチユーザモードで新しいシステムのビルドを行ない, その後, シングルユーザモードに移行してから インストールを行なうことができます. 稼働中のシステムでシングルユーザモードに移行するには, スーパユーザ(root)権限で次のコマンドを実行します. &prompt.root; あるいはシステムを再起動し, ブートプロンプトから フラグを設定することで, シングルユーザモードで システムを起動させることができます. 起動後, シェルプロンプトから 次のように実行して下さい. &prompt.root; fsck -p &prompt.root; mount -u / &prompt.root; mount -a -t ufs &prompt.root; swapon -a これはファイルシステムをチェックした後, / を読み書き可能にして再マウント, /etc/fstab に指定されている, それ以外の UFS ファイルシステムをすべてマウントしてから スワップを有効にします. <filename>/usr/obj</filename> の削除 システムが再構築される時, 構築されたものは(デフォルトで) /usr/obj 以下のディレクトリに格納され, そのディレクトリの下は /usr/src と同じ構造となります. このディレクトリをあらかじめ削除しておくことにより, make world の行程にかかる時間を短縮させ, 依存問題に悩まされるようなトラブルを回避することができます. /usr/obj 以下のファイルには, 変更不可(immutable)フラグ(詳細は &man.chflags.1; 参照)がセットされているものがあります. そのため, まず最初にそのフラグを変更しなければなりません. &prompt.root; cd /usr/obj &prompt.root; chflags -R noschg * &prompt.root; rm -rf * <title>全バージョンに共通すること まず, カレントディレクトリを /usr/src に 変更しなければなりません. 次のように実行して下さい. &prompt.root; cd /usr/src (もちろん, ソースコードが他のディレクトリにある場合には, /usr/src ではなく, ソースコードのあるディレクトリに移動して下さい). make world を行なうには, &man.make.1; コマンドを使用します. このコマンドは, Makefile というファイルから, FreeBSD を構成するプログラムの再構築方法や, どういう順番でそれらを構築すべきかといったような 指示を読み込みます. コマンドラインの一般的な書式は, 次のとおりです. &prompt.root; make この例では, が &man.make.1; に渡されるオプションになります. どのようなオプションが利用できるかについては, マニュアルページを 参照して下さい. は, Makefile に渡される変数であり, この変数は Makefile の動作をコントロールします. また, /etc/make.conf で設定される変数も 同様です. これは変数を設定するもう一つの方法として用意されています. &prompt.root; make -DNOPROFILE=true target は, プロファイル版のライブラリを構築しないことを指定する もう一つの記法で, /etc/make.conf 中の NOPROFILE= true # Avoid compiling profiled libraries の行に対応します. target は, &man.make.1; に どのように動作するのかを指示するためのものです. 各々の Makefile には, 数多くの異なる ターゲット(target) が定義されていて, 指定されたターゲットによって, 動作が決まります. Makefile に書かれているターゲットには, あなたが指定しても意味を持たないものも含まれます. これらは, システムの再構築に必要な段階を, 多くの さらに細かい段階に分割するため, 構築の過程で利用されるものです. 大抵の場合, &man.make.1; にパラメータを指定する必要はないでしょうから, コマンドラインは次のようなものになるでしょう. &prompt.root; make target 出力の保存 実行される &man.make.1; からの出力は, ファイルに保存すると良いでしょう. もし, 何か障害が発生した場合, エラーメッセージのコピーに加え, どの時点でそれが起こったのか, 完全なリストが手元に残ります. 何が悪かったのか, あなた自身がそれから理解することはできないかも 知れません. しかし, FreeBSD メーリングリストに投稿して, 誰か他の人からの助言を得るために利用することができます. ファイルに保存する最も簡単な方法は, &man.script.1; コマンドを 使い, 引数に出力を保存したいファイル名を指定することです. これを make world の直前に行ない, 再構築が終了してから exit と入力すると, 出力を保存することができます. &prompt.root; script /var/tmp/mw.out Script started, output file is /var/tmp/mw.out &prompt.root; make world … compile, compile, compile … &prompt.root; exit Script done, … 出力を保存する場合, /tmp ディレクトリの中に 保存してはいけません. このディレクトリは, 次の再起動で削除されてしまう可能性があります. 出力の保存には, (上の例のように)/var/tmpや root のホームディレクトリが適しています. FreeBSD-2.2.2 と, それ以前のバージョン /usr/src/Makefile には, システム全体を再構築しインストールを行なう world ターゲットが含まれています. それを, 次のように使って下さい. &prompt.root; make world FreeBSD-2.2.5 と, それ以降のバージョン FreeBSD-2.2.5 から(実際には, -CURRENT ブランチで最初に作成され, 2.2.2 と 2.2.5 の間の時点で -STABLE に導入されたのですが), world ターゲットは buildworld と installworld の二つに分割されました. その名前が示すように, buildworld は /usr/obj 以下に新しい完全な ディレクトリツリーを構築し, installworld は, そのツリーを 現在のマシンにインストールします. これは, 二つの理由から非常に有用です. まず第一に, 稼働中のシステムに全く影響を与えることなく, 安全にシステムの構築作業を行えることです. 構築作業は何にも依存せず独立して行なわれるため, マルチユーザモードで稼働中のシステムでも, 何一つ 悪影響を与えずに buildworld を 実行することができます. ただし, installworld は シングルユーザモードで行なうことをおすすめします. 第二に, NFS マウントを利用することで, ネットワーク上の複数のマシンをアップグレードすることが 可能な点があげられます. 例えば三台のマシン, マシン A, マシン B, マシン C をアップグレードしたい場合には, まず マシン A で make buildworld と make installworld を実行します. それから, マシン B とマシン C で /usr/src を NFS マウントし, make installworld とすることで 構築済みのシステムを各マシンにインストールすることができるのです. 一方, world ターゲットも残されていますので, FreeBSD-2.2.2 の場合として示されている方法と同じように, このターゲットを利用することもできます. make world は, make buildworld に続けて make installworld を実行します. make buildworld と make installworld のコマンドを分けて実行する場合には, それぞれ同じ引数を &man.make.1; に渡さなければなりません. 次のように実行したとすると, &prompt.root; make -DNOPROFILE=true buildworld 構築されたシステムは次のようにしてインストールする必要があります. &prompt.root; make -DNOPROFILE=true installworld そうしないと, make buildworld の段階で 構築されていない, プロファイル版ライブラリのインストールを 試みることになります. (訳注: もちろん, それには失敗するのでエラーが発生します. ) -CURRENT と, それ以降 もし, -CURRENT を追跡しているなら, make コマンドに オプションを渡すことができます. このオプションにより, make は 同時に複数のプロセスを生成するようになります. これは, 実際に複数の CPU を備えているマシンに対して 非常に有効に働きます. また, コンパイルプロセスの大部分は CPU の処理ではなく入出力の処理に費やされるため, 単一の CPU を持つマシンでも同じように有効です. 単一の CPU を持つ典型的なマシンでは, 次のように実行します. &prompt.root; make -j4 target この時 &man.make.1; は, 最大 4 個までのプロセスを同時に実行します. メーリングリストに投稿された経験的な報告によると, 4 個という指定が最も良いパフォーマンスを示すようです. もし, 複数の CPU を備えたマシンで SMP 設定が行なわれたカーネルを 利用しているなら, 6 から 10 の間の値を設定し, 速度がどれくらい 向上するか確認してみて下さい. 注意して欲しいのですが, (この原稿を書いている時点では)この機能はまだ 実験段階です. そのため, ソースツリーへ変更が加えられたときに これが正常に機能しなくなる可能性があります. もし, このオプションを用いてシステムの構築に失敗した場合には, 障害を報告する前に, もう一度オプションを付けずに試してみて下さい. システムの構築にかかる時間 すべてが順調に進んでいたとしても, 一時間半から丸一日程度の時間がかかります. 一般的に言って, 200MHz の P6(訳注: Intel PentiumPro のこと) で 32MB 以上のメモリを搭載し, 標準的な SCSI ディスクドライブを利用していた とすると, make world の完了までに およそ一時間半の時間がかかります. この構成よりも性能が低ければ, それよりもさらに時間がかかるでしょう. <filename>/etc</filename> の更新 システムの再構築は, いくつかのディレクトリ ( 特に, /etc, や /var や /usr) において, 新規に導入されたり, 変更された設定ファイルによる ファイルの更新は行なわれません. これは, あなた自身の手や目, そして適切な &man.diff.1; の使用をによって行なわなければなりません. 単にファイルを /usr/src/etc から /etc に コピーしただけでは正常に動作させることはできません. これらのファイルには, インストールという 手順を踏まなければならないものが含まれています. /usr/src/etc ディレクトリは /etc ディレクトリにそのまま置き換えられるような コピーではないからです. また, /etc にあるべきファイルのうちで /usr/src/etc にないものもあります. 一番簡単な方法は, ファイルを新しいディレクトリにインストールしてから, 以前のものと異なっている部分を調べて更新作業を行なうことです. 既存の <filename>/etc</filename> をバックアップする 理論的に考えて, このディレクトリが自動的に 処理されることはありませんが, 念には念を入れておいて 損はありません. たとえば以下のようにして, 既存の /etc ディレクトリを どこか安全な場所にコピーしておきましょう. &prompt.root; cp -Rp /etc /etc.old は再帰的なコピーを行ない, はファイルの更新時間や所有者などを保存します. また, 新しい /etc やその他のファイルを インストールするための, 仮のディレクトリを作っておく必要があります. 私はいつもこの仮のディレクトリを /var/tmp/root に置くことにしています. 同様に, 必要なサブディレクトリもこの下に置きます. &prompt.root; mkdir /var/tmp/root &prompt.root; cd /usr/src/etc &prompt.root; make DESTDIR=/var/tmp/root distrib-dirs distribution 上の例は, 必要なディレクトリ構造をつくり, ファイルをインストールします. /var/tmp/root 以下に作られる, たくさんの空のディレクトリは削除する必要があります. 一番簡単なやり方は, 次のとおりです. &prompt.root; cd /var/tmp/root &prompt.root; find -d . -type d | /usr/bin/perl -lne \ 'opendir(D,$_);@f=readdir(D);rmdir if $#f == 1;closedir(D);' これは深さ優先探索で各ディレクトリを走査し, 含まれるファイルの数が 2 個(スクリプト中の この段階の /var/tmp/root には, 本来 / 以下にあるべきファイルが すべて含まれています. 各ファイルを順に見て, 既存のファイルと異なる部分を 調べて下さい. /var/tmp/root 以下に インストールされているファイルの中には, /var/tmp/root/ と /var/tmp/root/root/ の中にある シェルスタートアップ ファイルだけですが, 他のものがあるかも知れません. (これは, あなたがこれをどの時点で読んでいるかに依存するので, もっとも簡単な方法は, 二つのファイルを比較するコマンド &man.diff.1; を使うことです. &prompt.root; diff /etc/shells /var/tmp/root/etc/shells これは, あなたの /etc/shells ファイルと 新しい /etc/shells ファイルの 異なる部分を表示します. これらを, あなたが書き換えたものに変更点をマージするか, それとも既存のファイルを新しいもので上書きするかを 判断する材料にして下さい. 新しい root ディレクトリ (<filename>/var/tmp/root</filename>) の名前に タイムスタンプを付けておくと, 異なるバージョン間の比較を楽に行なうことができます. 頻繁にシステムの再構築を行なうということは, /etc の更新もまた, 頻繁に行う必要がある ということです. これはちょっと手間のかかる作業です. この作業は, あなたが /etc にマージした, 新しく変更されたファイルの最新のセットのコピーを保存しておくことで 素早く行なうことができます. 下の手順は, それを実現するための一つの方法です. 普通に make world します. /etc や 他のディレクトリを更新したくなったときは, ターゲット ディレクトリに, そのときの日付に基づく名前をつけてください. たとえば 1998 年 2 月 14 日 だとすれば, 以下のようにします. &prompt.root; mkdir /var/tmp/root-19980214 &prompt.root; cd /usr/src/etc &prompt.root; make DESTDIR=/var/tmp/root-19980214 \ distrib-dirs distribution 上に説明されているように, このディレクトリから変更点をマージします. その作業が終了しても, /var/tmp/root-19980214 を 削除してはいけません. 最新版のソースをダウンロードして再構築したら, ステップ 1 にしたがって下さい. 今度は, /var/tmp/root-19980221 (更新作業が一週間おきだった場合) のような名前の, 新しいディレクトリをつくることになるでしょう. この段階で &man.diff.1; を使用し, 二つのディレクトリを比較する再帰的 diff を作成することで, 一週間の間に行なわれたソースへの変更による相違点を調べます. &prompt.root; cd /var/tmp &prompt.root; diff -r root-19980214 root-19980221 これによって報告される相違点は, 大抵の場合, /var/tmp/root-19980221/etc と /etc との場合に比べて 非常に少ないものになります. 相違点が少ないため, 変更点を既存の /etc ディレクトリにマージすることは, 比較的容易になります. ここまで終了したら, /var/tmp/root-* の 二つのうち, 古い方のディレクトリは削除して構いません. &prompt.root; rm -rf /var/tmp/root-19980214 この工程を, /etc へ変更点をマージする 必要があるたび, 毎回繰り返します. ディレクトリ名の生成を自動化するには, &man.date.1; を利用することができます. &prompt.root; mkdir /var/tmp/root-`date "+%Y%m%d"` <filename>/dev</filename> の更新 DEVFS もし, DEVFS を利用しているなら, この作業はおそらく必要ないでしょう. 安全のため, これはいくつかの段階に分けて行ないます. /var/tmp/root/dev/MAKEDEV を /dev にコピーします. &prompt.root; cp /var/tmp/root/dev/MAKEDEV /dev ここで, /dev のファイル一覧を記録しておきます. この一覧は, 各ファイルの許可属性, 所有者, メジャー番号, マイナー番号が 含まれている必要がありますが, タイムスタンプは含まれていてはいけません. これを行なう簡単な方法は, &man.awk.1; を使って, いくつかの情報を取り除くことです. &prompt.root; cd /dev &prompt.root; ls -l | awk '{print $1, $2, $3, $4, $5, $6, $NF}' > /var/tmp/dev.out デバイスファイルをつくり直します. &prompt.root; もう一度, ディレクトリのファイル一覧を記録します. 今回は /var/tmp/dev2.out です. この段階で, この二つのファイル一覧を調べて 作成に失敗したデバイスを探して下さい. 違いは一つもないはずなのですが, 安全のために一応チェックして下さい. &prompt.root; diff /var/tmp/dev.out /var/tmp/dev2.out 次のようなコマンドを使用し, ディスクスライスエントリを 再作成することで, ディスクスライスの矛盾を検出することができます. &prompt.root; sh MAKEDEV sd0s1 適当な組み合わせは, 環境によって異なります. <filename>/stand</filename> の更新 この段階は, 完全な更新を行なう場合にだけ必要な内容を含んでいます. 悪影響はありませんので, 省略しても構いません. 完全な更新を行なうために, /stand にあるファイルも同じように 更新したいと考えるかも知れません. これらのファイルは, /stand/sysinstall という バイナリファイルへのハードリンクです. このバイナリファイルは, 他のファイルシステム(特に /usr)が マウントされていない場合にも動作できるよう, 静的にリンクされていなければなりません. &prompt.root; cd /usr/src/release/sysinstall &prompt.root; make all install 1998 年 4 月 2 日以前のソースの場合 もし, 1998 年 4 月 2 日より古いソースコードを使っているか, Makefile のバージョンが 1.68 以降(FreeBSD-CURRENT および FreeBSD-3.X の場合), 1.48.2.21 以降(FreeBSD-2.2.X の場合)でなければ, 次のように NOSHARED=yes オプションを追加する必要があります. &prompt.root; make NOSHARED=yes all install 新しいカーネルのコンパイルとインストール 新しいシステムにおけるアドバンテージを完全に得るために, カーネルの再コンパイルをすべきです. 再コンパイルは, ある種のメモリ構造が変更された時には必須です. その場合, &man.ps.1; や &man.top.1; のようなプログラムは, カーネルとソースコードのバージョンが一致しないと 正常に動作しないでしょう. 新しい kernel をコンパイルするには, FreeBSD ハンドブックの指示にしたがってください. 過去に自分で設定したカーネルを構築している場合には, LINT コンフィグレーションファイルを注意深く調べて, 利用できる新しいオプションがあるかどうか確かめて下さい. この文書の以前の版では, カーネルの再構築の前に再起動することを推奨していました. これは以下の点で誤りです. &man.ps.1;, や &man.ifconfig.8;, &man.sysctl.8; といったコマンドが動作しなくなる恐れがあります. そうなると, マシンがネットワークに接続できなくなってしまいます. &man.mount.8; のような基本的なユーティリティが機能しなくなり, / や /usr 等を マウントできなくなってしまうかも知れません. これは, -STABLE の候補を追いかけている場合には あまり発生することはありませんが, -CURRENT を追いかけていて, 大規模なマージが行なわれている間には良く起こります. ローダブルカーネルモジュール (FreeBSD-3.X 以前は LKM と呼ばれていましたが, FreeBSD-3.X 以降は KLD と呼んでいます)は world の一部として 構築されるため, 古いカーネルがクラッシュする可能性があります. これらの理由から, どんな場合においても, 再起動する前に新しいカーネルを再構築し, インストールすることが 最も良い手順になります. 新しいカーネルは, make world (あるいは make installworld) が完了した後で 構築しなければなりません. もし, そうしない場合には (おそらく, あなたはシステムを更新する前にカーネルが構築されることを 確認したいのでしょう) 問題が起こるかも知れません. それは, カーネルソースに対して &man.config.8; コマンドが古いことが原因です. その場合には, 新しいバージョンの &man.config.8; でカーネルを構築することができます. &prompt.root; /usr/obj/usr/src/usr.sbin/config/config KERNELNAME これは, いつもうまく行くとは限りませんので, 新しいをカーネルをコンパイルする前に make world (あるいは make installworld)を完了させることが推奨されています. これで, 作業はおしまいです. すべてがあるべき正しい場所に存在することをチェックしたら, システムを再起動します. これは, 単に &man.fastboot.8; を実行するだけです. </para> <screen>&prompt.root; <userinput>fastboot</userinput></screen> </sect2> <sect2> <title>作業の完了 ここまで来れば, FreeBSD システムのアップグレードは成功です. おめでとうございます. さて, この時点で, 今までの間違った操作による小さな問題に 気付くことがあるかも知れません. たとえば, 私はかつて /etc/magic をアップグレードの途中で削除し, そのまま /etc にマージしてしまったことがあります. その結果, file コマンドは動作しなくなってしまったのです. すぐに思いついたのは, これを修復するには &prompt.root; cd /usr/src/usr.bin/file &prompt.root; だけで十分ではないか, ということでした. <qandaentry> <question> <para>変更が行なわれたら, その度にシステムの再構築が必要になるのでしょうか?</para> </question> <answer> <para> それは変更の性質によるので, なんとも言えません. 例えば, CVSup を実行したとき, 最後に実行したときから比べて 次にあげるようなファイルが更新されていたとします.</para> <screen><filename>src/games/cribbage/instr.c</filename> <filename>src/games/sail/pl_main.c</filename> <filename>src/release/sysinstall/config.c</filename> <filename>src/release/sysinstall/media.c</filename> <filename>src/share/mk/bsd.port.mk</filename></screen> <para> このときには, 改めてシステムを再構築する必要はありません. わたしなら, 適切なサブディレクトリに移って <command>make all install</command> を行うと思います. しかし, もし何らかの大きな変更が行なわれているとき, 例えば <filename>src/lib/libc/stdlib</filename> が変更されている場合には, システムを再構築するか, もしくはそのうち, 少なくとも静的にリンクされているもの(と, わたしが追加した 他のプログラムのうち, 静的にリンクされたもの)を 作り直すことでしょう. </para> <para>結局のところ, どの時点で現在のシステムをアップグレードするかは あなたが決めることです. 2 週間ごとにシステムを再構築し, その 2 週間の変更を取り込めば 幸せかもしれませんし, 変更のあった部分だけ再構築し, 依存関係を確かめたいと考えるかも知れません. <!-- hrs:2000/02/15 What's "every fortnight say"? s/say/day/? --> </para> <para> もちろん, それらはどのくらいの頻度でアップグレードしたいか, そして -STABLE か -CURRENT のどちらを追いかけているのかによります. </para> </answer> </qandaentry> <qandaentry> <question> <para>signal 12(もしくは他のシグナル番号)のエラーがたくさん出て コンパイルが失敗します. 何が起こっているんでしょうか?</para> </question> <answer> <para> これは通常, ハードウェアに問題があることを示しています. システムの再構築は, ハードウェアに対する負荷耐久試験を行なうための 有効な手段の一つで, メモリに関係する問題がよく報告されます. その大部分は, コンパイラが奇妙なシグナルを受け取り, 不可解な異常終了となることで発見されます. </para> <para> 本当にこの問題によるものかどうかは, 再構築をもう一度実行し, 異なる段階で異常終了が発生するか, ということから確認できます. </para> <para> この場合には, マシンの部品を交換して, どの部分が悪いのかを 調べてみることくらいしかできることはありません. </para> </answer> </qandaentry> <qandaentry> <question> <para>終了したら <filename>/usr/obj</filename> を削除しても かまいませんか?</para> </question> <answer> <para> それはあなたが次の機会に, システムの再構築をどう行なうつもりなのかによります. </para> <para><filename>/usr/obj</filename> には, コンパイルの段階で生成された すべてのオブジェクトファイルが含まれています. 通常 <quote/make world/ の最初の段階では, このディレクトリを削除して新しくつくり直すようになっています. その場合には, 構築終了後の <filename>/usr/obj</filename> を保存しておいても, あまり意味はありません. 削除すれば, 大きなディスクスペースを (現在はだいたい 150MB あります) 解放することができます. </para> <para> しかし, もしあなたが何を行なおうとしているのか理解しているなら, この段階を省略して <quote/make world/ を行なうことができます. こうすると, ほとんどのソースは再コンパイルされないため, 構築はかなり高速化されます. これは裏をかえせば, デリケートな依存関係の問題によって, システムの構築が奇妙な失敗に終わる可能性があるということです. FreeBSD メーリングリストではしばしば, 構築の失敗が, この段階の省略によるものだということを理解せずに 不満の声をあげる人がいます. </para> <para> もし, このような危険を承知した上でシステムの再構築を行なう場合には, 次のように変数 <makevar>NOCLEAN</makevar> を定義して構築します. </para> <screen>&prompt.root; <userinput>make -DNOCLEAN world</userinput></screen> </answer> </qandaentry> <qandaentry> <question> <para>構築を中断した場合, その構築を途中から再開することはできますか?</para> </question> <answer> <para> それは, あなたが問題に気付く前に, どれだけの作業を終えているかによって変わります. </para> <para><emphasis>一般的に</emphasis> (そしてこれは確実でしっかりした 規則ではありませんが), <quote>make world</quote> の過程では, 基本的なツール ( &man.gcc.1;, や &man.make.1; のようなもの) や, システムライブラリの新しいコピーが作成されます. その後まず, これらのツールやライブラリはインストールされてから 自分自身の再構築に使われ, もう一度, インストールされます. 全体のシステム (ここでは &man.ls.1; や &man.grep.1; といった 標準的なユーザプログラムを含みます) は, その新しいシステムファイルを用いて作り直されることになります. </para> <para> もし, 再構築が最終段階に入っていること が(記録しておいた出力を見たりすることで)わかっていたら, (全く悪影響を与えることなく)次のようにすることができます, </para> <screen><emphasis>… fix the problem …</emphasis> &prompt.root; <userinput>cd /usr/src</userinput> &prompt.root; <userinput>make -DNOCLEAN all</userinput></screen> <para> これは, 前回の <quote>make world</quote> の作業をやり直しません. </para> <para>次のメッセージ <screen>-------------------------------------------------------------- Building everything.. --------------------------------------------------------------</screen> が <quote>make world</quote> の出力にある場合には, 上のようにしてもほとんど悪影響が現れることはありません. </para> <para> もしこのメッセージがないとか, よく分からないという場合には, 安全を確保し, 後悔するようなことがないよう, システムの再構築を最初からやり直しましょう. </para> </answer> </qandaentry> <qandaentry> <question> <para>あるマシンを <emphasis/マスタ/ として, 他の多くのマシンを (NFSで) アップグレードできますか?</para> </question> <answer> <para>すべてのコンパイル作業をあるマシンで行ない, 構築されたものを他のマシンにネットワークを経由で <command>make install</command> することができるかどうかは, よく FreeBSD メーリングリストで尋ねられます. </para> <para>これはわたしが行った作業ではありませんので, 下に書かれている提案は, 他の人々から頂いたか, Makefile から推論したものです.</para> <para>取るべき適切な方法については, 利用している FreeBSD のバージョンに依存します.</para> <para> アップグレードしたマシンでは, この作業を行った後に <filename>/etc</filename> や <filename>/dev</filename> の 更新を行わなくてはなりません.</para> <para>2.1.7 とそれより古いものについて, Antonio Bemfica は 次に示すような方法を教えてくれました. </para> <screen>Date: Thu, 20 Feb 1997 14:05:01 -0400 (AST) From: Antonio Bemfica <bemfica@militzer.me.tuns.ca> To: freebsd-questions@FreeBSD.org Message-ID: <Pine.BSI.3.94.970220135725.245C-100000@militzer.me.tuns.ca> Josef Karthauser は質問しました: > どなたかネットワークを通してマシンをアップグレードするよい方法は知りませんか まず, メインとなるマシンで make world などをします. そして次のように, リモートのマシンから / や /usr をマウントします: main_machine% mount remote_machine:/ /mnt main_machine% mount remote_machine:/usr /mnt/usr そして, /mnt をインストール先に指定して 'make install' とします: main_machine% make install DESTDIR=/mnt これをネットワーク上の他のマシンについても繰り返してください. わたしの場合には, これでうまくいきました. Antonio</screen> <para>この仕組みは (わたしの知る限り) NFS サーバ上の <filename>/usr/src</filename> が書き込み可能である場合にのみ きちんと動作します. FreeBSD-2.1.7 とそれ以前では, この作業に <maketarget>install</maketarget> ターゲットを使います. </para> <para>FreeBSD-2.1.7 と FreeBSD-2.2.0 の間で <quote>reinstall</quote> ターゲットが導入されました. 上にあげた FreeBSD-2.1.7 向けの方法に加え, <quote>install</quote> の代わりに <quote>reinstall</quote> を 使うことができます. </para> <para>この方法では, NFS サーバ上の <filename>/usr/src</filename> ディレクトリへの書き込み権限は必要 <emphasis>ありません</emphasis>.</para> <para>Makefile の 1.68 から 1.107 の間のバージョンには, このターゲットに関するバグがありました. それは NFS サーバへの書き込み権限が <emphasis>必要になる</emphasis> というもので, このバグは FreeBSD-2.2.0 がリリースされる前に修正されました. この時期の -STABLE が動いている古いサーバでは, 問題になるかも知れません. </para> <para>FreeBSD-2.2.5 以降のバージョンでは, <quote>buildworld</quote> と <quote>installworld</quote> ターゲットが利用できます. これらを使ってソースツリーを一つのマシンで構築し, <filename>/usr/src</filename> と <filename>/usr/obj</filename> をリモートマシンで NFS マウントして, そこからインストールすることができます.</para> </answer> </qandaentry> <qandaentry> <question> <para>どのようにすれば make world を高速化できますか?</para> <itemizedlist> <listitem> <para>シングルユーザモードで動かしてください.</para> </listitem> <listitem> <para><filename>/usr/src</filename> と <filename>/usr/obj</filename> ディレクトリを, 異なるディスク上の別のファイルシステムに置いてください. また可能ならば, 異なるディスクコントローラに接続された ディスクを使って下さい. </para> </listitem> <listitem> <para>さらに高速化するには, これらのファイルシステムを <quote>ccd</quote> (連結ディスクドライバ) デバイスを 使って, 別々なディスク上に置いてください.</para> </listitem> <listitem> <para>プロファイル版の作成を無効化して下さい. (<filename>/etc/make.conf</filename> で <quote>NOPROFILE=true</quote> をセットします) 普通, それが必要になることはありません. </para> </listitem> <listitem> <para>また, <filename>/etc/make.conf</filename> の中の <quote>CFLAGS</quote> を, <quote>-O -pipe</quote> のように指定しましょう. <quote>-O2</quote> の最適化はさらに多くの時間を必要とし, しかも <quote>-O</quote> と <quote>-O2</quote> の 最適化には, ほtんど差はありません. <quote>-pipe</quote> を指定することで, コンパイラはテンポラリファイルの代わりにパイプを利用します. その結果, (メモリの利用は増えますが)ディスクアクセスが減ります. </para> </listitem> <listitem> <para>(もしあなたが十分に最近のバージョンの FreeBSD を使っているなら) 複数のプロセスを並列に実行させるため, make に <option>-j<n></option> オプションを指定してください. これはプロセッサが単一か複数かによらず, どちらも同様に恩恵を得ることができます.</para> </listitem> <listitem><para><filename>/usr/src</filename> のある ファイルシステムを, <quote>noatime</quote> オプションを付けてマウント(もしくは再マウント)してください. これは, そのファイルシステムにおいて, 最後にアクセスされた時刻の書き込みを抑制します. おそらく, この情報が必要になることはないでしょう.</para> <note> <para><quote>noatime</quote> が利用可能なのは, FreeBSD-2.2.0 以降です.</para> </note> <screen>&prompt.root; <userinput>mount -u -o noatime /usr/src</userinput></screen> <warning> <para>上の例は, <filename>/usr/src</filename> 自身が独立したファイルシステムで あることを想定しています. もしそうでないときには (例えば <filename>/usr</filename> の 一部である場合には), <filename>/usr/src</filename> ではなく 適切なマウントポイントを指定する必要があります. </para> </warning> </listitem> <listitem> <para><filename>/usr/obj</filename> のあるファイルシステムを, <quote>async</quote> オプションをつけてマウント (もしくは 再マウント) してください. これによって, ディスクへの書き込みが非同期になります. つまり, 書き込み命令はすぐに完了するのに対し, 実際にデータがディスクに書き込まれるのは, その数秒後になります. これによって, 書き込み処理の一括化が可能になるため, 劇的なパフォーマンスの向上が期待できます. <!-- hrs:2000/02/15 (for ja-translators) "be clusterd togather" is translated into "clusterization" --> </para> <warning> <para> このオプションを指定すると, ファイルシステムは 壊れやすくなってしまうことに注意してください. このオプションを付けていて, 突然電源が落ちた場合には, 再起動後にファイルシステムが復旧不能になる可能性が 非常に高くなります. </para> <para>もし, <filename>/usr/obj</filename> 自身が独立した ファイルシステムであるならば, これは問題になりません. しかし, 同じファイルシステムに, 他の貴重なデータを置いているときには, このオプションを有効にする前に, バックアップをきちんと取っておきましょう.</para> </warning> <screen>&prompt.root; <userinput>mount -u -o async /usr/obj</userinput></screen> <warning> <para>もし <filename>/usr/obj</filename> 自身が ファイルシステムでない場合には, 適切なマウントポイントを指すように, 上の例の名前を置き換えて下さい. </para> </warning> </listitem> </itemizedlist> </question> </qandaentry> </qandaset> </sect2> </sect1> </chapter> <!-- Local Variables: mode: sgml sgml-declaration: "../chapter.decl" sgml-indent-data: t sgml-omittag: nil sgml-always-quote-attributes: t sgml-parent-document: ("../book.sgml" "part" "chapter") End: --> diff --git a/ja_JP.eucJP/books/handbook/introduction/chapter.sgml b/ja_JP.eucJP/books/handbook/introduction/chapter.sgml index 24856c99f8..80d68ff4f9 100644 --- a/ja_JP.eucJP/books/handbook/introduction/chapter.sgml +++ b/ja_JP.eucJP/books/handbook/introduction/chapter.sgml @@ -1,807 +1,806 @@ <!-- The FreeBSD Documentation Project The FreeBSD Japanese Documentation Project Original revision: 1.30 - $FreeBSD: doc/ja_JP.eucJP/books/handbook/introduction/chapter.sgml,v 1.12 2000/07/17 09:14:37 kuriyama Exp $ + $FreeBSD: doc/ja_JP.eucJP/books/handbook/introduction/chapter.sgml,v 1.13 2000/07/18 02:51:10 kuriyama Exp $ --> <chapter id="introduction"> <title>はじめに - Restructured, reorganized, and parts rewritten by - &a.jim;, 17 January 2000. + 改訂: &a.jim;, 2000 年 1 月 17 日. - Synopsis + 概要 FreeBSD に興味を持って頂きありがとうございます! - 以下の章では FreeBSD の歴史, 目標, 開発モデルなど, + この章では FreeBSD の歴史, 目標, 開発モデルなど, FreeBSD プロジェクトに関する様々な事柄に言及しています. FreeBSD は, Intel アーキテクチャ (x86) と DEC Alpha ベースの システムのための 4.4BSD-Lite2 をベースとしたオペレーティング システムです. 他のアーキテクチャに対する移植も進行中です. FreeBSD の概要については, 次のセクション をご覧ください. FreeBSD の歴史 や, 現在のリリースについて も読むことができます. プロジェクトへの何らかの貢献 (ソースコード, ハードウェア, 資金の提供など) について興味があれば, FreeBSD への貢献 をご覧ください. FreeBSD へようこそ! もしまだここを読んでいるなら, FreeBSD がどんなものか, 何ができるのかを多少なりとも理解していると思います. もし FreeBSD について初心者なら, このまま読み続けてください. FreeBSD って何? 一般に, FreeBSD は 4.4BSD-Lite2 ベースのオペレーティング システムです. Intel アーキテクチャ (x86) ベースのコンピュータシステム上で 動作し, DEC Alpha アーキテクチャでも動作します. FreeBSD は, 以下のサイトを含む多くの Internet 上の最大クラスのサイトで利用されています: Yahoo! Hotmail Apache Be, Inc. Blue Mountain Arts Pair Networks Whistle Communications Walnut Creek CDROM などです. FreeBSD で何ができるの? FreeBSD には多くの注目すべき機能があります. 例を挙げれば以下のようになります: 優先度を動的に調節する機能を備えることで アプリケーションとユーザとの間で円滑かつ公平な コンピュータ資源共有を実現し, 特に高い負荷にも耐えることができる堅牢さを備えた プリエンプティブマルチタスキング. 多くの人々が 1 つの FreeBSD システムをさまざまな目的で同時に使うことを可能にする マルチユーザ機能. これは例えば, プリンタやテープデバイスといった システムの周辺機器が, そのシステムを利用する全てのユーザだけでなく ネットワーク経由においても自然な形で共有され, さらに重要なシステム資源の使い過ぎを防ぐために 個々の資源に対する制限がユーザ単位, グループ単位で 設定できる, というようなことを意味しています. SLIP や PPP, NFS, DHCP, NIS といった業界標準規格の サポートを含んだ 堅固な TCP/IP ネットワーキング. これによって, FreeBSD マシンが商用サーバと同じように相互に運用でき, NFS(リモートファイルアクセス)や, 電子メールサービスのような 極めて重要な機能を提供します. また, WWW や FTP, ルーティング, ファイアウォール (セキュリティ) サービスを用いてインターネットと 接続できます. アプリケーション (あるいはユーザ) がお互いに干渉できない ようにするメモリ保護機能. アプリケーションがクラッシュしても, どのような場合でも 他のアプリケーションには影響を与えません. FreeBSD は 32ビット のオペレーティングシステム(Alpha 版は 64 ビット)であり, 最初からそのようにこつこつと設計されました. 業界標準であるX Windowシステム (X11R6) は, 普通のVGAカードやモニタでグラフィカルユーザ インタフェース (GUI) を提供し, すべてのソースコードも一緒に提供されます. Linux や SCO, SVR4, BSDI, NetBSD 用に作られた多くの プログラムとのバイナリ互換性. 何千ものすぐに実行可能な アプリケーションが FreeBSD の ports や packages コレクションで利用可能です. ここに用意されているものは ネットを探し回る必要がありません インターネット上で入手可能な, 移植が容易な 何千ものアプリケーションを追加できます. FreeBSD は最も評判の よい商用の Unix システムとソースコードレベルで互換性があります. このため, ほとんどのアプリケーションは, もしあったとしてもほんの 少しの変更でコンパイルすることができます. デマンドページング 仮想メモリ とそれに 付随の VM/buffer キャッシュの設計は, 多くのメモリを要求する アプリケーションに対して効率よくメモリを 与えるようにする一方で, 他のユーザに対しても対話的な応答を維持します. 複数の CPU を搭載したマシンにおける SMP 機能のサポート(Intel 版のみ). 完全な C や C++, Fortran, Perlの 開発ツール. 進んだ研究や開発のための多くの他の言語も ports や packages コレクションで提供されています. システム全体の ソースコード が提供されているので, 要求に合わせて環境を最大限に適合させることができます. 真のオープンシステムが利用できるのですから, 所有権のある解決方法に 締めつけられ, ベンダのなすがままになる必要はありません. 膨大な量の オンラインドキュメント. もう書ききれません! FreeBSD はカリフォルニア大学バークレイ校のComputer Systems Research Group (CSRG) による4.4BSD-Lite2 リリースを基にしており, BSDシステムの開発の優れた伝統を守り続けています. CSRGによる素晴らしい活動に加えて, FreeBSDプロジェクトは何千時間もの時間を注ぎ込んで, 実際の使用の場において最大の性能と信頼性を 発揮するためにシステムのチューニングをおこなっています. 多くの大企業がPCオペレーティングシステムの分野で 実現しようと奮闘しているそのような機能や性能, 信頼性を FreeBSDは今すぐ提供できます! あなたの思いつく限りのアプリケーションは, 何でもFreeBSDで 実行できます. ソフトウェア開発から ファクトリオートメーション, 在庫制御から遠く離れた人工衛星の アンテナの方向調整まで; 商用UNIX製品でできることは, FreeBSDでも十分にできるのです! また, FreeBSDは世界中の研究センターや大学によって開発される 文字通り何千もの高品質で, たいていはほとんど無料で利用できる アプリケーションによる恩恵を得ることができます. 商用のアプリケーションも提供されており, 日々増え続けています. FreeBSDのソースコードは広く提供されているので, システムも特別なアプリケーションやプロジェクトに合わせて, いくらでもカスタマイズすることができます. これは 有名な商業ベンダから出ているほとんどのオペレーティング システムでは不可能なことです. 以下に現在FreeBSDを 使っている人々のアプリケーションの例をいくつか上げます: インターネットサービス: FreeBSDに組み込まれている 頑強なTCP/IP ネットワーキング機能は次のようなさまざまなインターネット サービスの理想的なプラットフォームになります: FTP サーバ World Wide Web サーバ(標準, もしくは安全な [SSL]) ファイアウォールと NAT (IP マスカレード) ゲートウェイ 電子メールサーバ USENET ニュースおよび電子掲示板システム さらにいろいろ... FreeBSD を利用すれば, 小規模で安価な 386 クラスの PC でも気軽に導入することができますし, 事業の成長に合わせてアップグレードした 4 つの Xeon プロセッサと RAID ストレージデバイスを 備えたシステムでも, 全くそのまま使うことができるのです. 教育: あなたは計算機科学または工学の学生ですか? オペレーティングシステムやコンピュータアーキテクチャ, ネットワーキングを学習するなら, FreeBSDを手に 経験するのが一番よい方法です. 自由に利用できるCADや数学, グラフィックデザインのパッケージもいくつもあり, コンピュータに関心を持った人が 他の人 の成果を 手に入れて利用するのにとても役に立ちます. 研究: システム全体のソースコードが利用できるため, FreeBSDはオペレーティングシステムの研究だけでなく, 計算機科学の他の部門においても優れたプラットフォームです. 自由に利用できるFreeBSDの特長は, オープンフォーラムで 議論される特別なライセンスの同意や制限について 心配することなく, 離れたグループでもアイディアや開発の共有に よる共同研究を可能にします. ネットワーキング: 新しいルータが必要? ネームサーバ (DNS) は? 内部のネットワークを人々から守る ファイアウォールは? FreeBSDはすみに眠っている使われていない386や486のPCを簡単に 洗練されたパケットフィルタリング機能を持つ高級なルータに 変えることができます. X Windowワークステーション: 自由に利用できるXFree86サーバやX Inside社から提供される 優れた商業サーバを使うことによって, 安価なX端末 としてFreeBSDを使うこともできます. X端末とは違ってFreeBSDは 多くのアプリケーションをローカルに走らせることもでき, 中心のサーバの負荷を軽減することも可能です. FreeBSDはディスクレスでもブート可能であり, 個々のワークステーションを安価で, 容易に管理することさえ 可能にします. ソフトウェア開発: 基本的なFreeBSDシステムには 有名なGNUのC/C++コンパイラやデバッガ含んだ完全な開発ツールが ついてきます. FreeBSD は CDROM または anonymous FTP によってソース, バイナリとも利用可能です. 詳しくは, FreeBSD の入手方法 を見てください. FreeBSD について 以下のセクションでは, 簡単な歴史やプロジェクトの目標, 開発モデルなど, 普段は表にでない話題を提供しています. FreeBSD 小史 原作: &a.jkh;. 訳: &a.jp.masaki;, &a.jp.hino;. 19 December 1996. FreeBSD プロジェクトは 1993年の始めに Unofficial 386BSD Patchkit の最後の 3人のまとめ役によって, 部分的に patchkit から派生する形で開始 されました. ここでの 3人のまとめ役というのは, Nate Williams と, Rod Grimes と, 私 (Jordan K. Hubbard) です. 私たちのもともとの目標は, patchkit という仕組みではもう十分に解 決できなくなってしまった 386BSD の数多くの問題を修正するための, 386BSD の暫定的なスナップショットを作成することでした. こういった経緯を経てい るので, このプロジェクトの初期の頃の名前が 386BSD 0.5 や 386BSD 暫定版 (Interim) であったということを覚えている人もいるでしょう. 386BSD は, Bill Jolitz が (訳注: バークレイ Net/2 テープを基に) 作成し たオペレーティングシステムです. 当時の 386BSD は, ほぼ一年にわたって放っ ておかれていた (訳注: 作者がバグの報告を受けても何もしなかった) という ひどい状況に苦しんでいました. 作者の代わりに問題を修正し続けていた patchkit は日を追うごとに不快なまでに膨張してしまっていました. このよ うな状況に対して, このままではいけない, 何か行動を起こさなければ, とい うことで異議を唱えるものは私たちのなかにはいませんでした. そして私たち は挑戦することを決断し, 暫定的なクリーンアップスナップショットを作 成することで Bill を手助けしようと決めたのです. しかし, この計画は唐突 に終了してしまいました. Bill Jolitz が, このプロジェクトに対する受け 入れ支持を取り下げることを突然決意し, なおかつこのプロジェクトの代わり に何をするのかを一切言明しなかったのです. たとえ Bill が支持してくれないとしても, われわれの目標には依然としてや る価値があると決心するのにさしたる時間はかかりませんでした. そこで David Greenman が考案した名称 FreeBSD を私たちのプロジェクトの名前 に採用し, 新たなスタートを切りました. この時点でのプロジェクトの初期目 標は, すでにこのシステム (訳注: 386BSD + Patchkit) を使っていた利用者 たちと相談して決められました. プロジェクトが実現に向けて軌道に乗ってき たことが明確になった時点で, 私は Walnut Creek CDROM 社に連絡してみまし た. CDROM を使って FreeBSD を配布することによって, インターネットに容 易に接続できない多くの人々が FreeBSD を簡単に入手できるようになると考 えたからです. Walnut Creek CDROM 社は FreeBSD を CD で配布するというア イデアを採用してくれたばかりか, 作業するためのマシンと高速なインターネッ ト回線を私たちのプロジェクトに提供してくれました. 当時は海のものとも山 のものともわからなかった私たちのプロジェクトに対して, Walnut Creek CDROM 社が信じられないほどの信頼を寄せてくれたおかげで, FreeBSD は短期 間のうちにここまで大きく成長したのです. CDROM による最初の配布 (そしてネットでの, ベータ版ではない最初の一般向 け配布) は FreeBSD 1.0 で, 1993年 12月に公開されました. これは カリフォ ルニア大学バークレイ校の 4.3BSD-Lite (Net/2) を基とし, 386BSD や Free Software Foundation からも多くの部分を取り入れたものです. これは 初めて公開したものとしては十分に成功しました. 続けて 1994年 5月に FreeBSD 1.1 を公開し, 非常に大きな成功を収めました. この時期, あまり予想していなかった嵐が遠くから接近してきていました. バー クレイ Net/2 テープの法的な位置づけについて, Novell 社と カリフォルニア大学バークレイ校との間の長期にわたる 法廷論争において和解が成立したの です. 和解の内容は, Net/2 のかなりの部分が権利つき (encumbered)コー ドであり, それは Novell 社の所有物である, というバークレイ校側が譲歩し たものでした. なお, Novell 社はこれらの権利を裁判が始まる少し前に AT&T 社から買収していました. 和解における譲歩の見返りにバークレイ 校が得たのは, 4.4BSD-Lite が最終的に発表された時点で, 4.4BSD-Lite は権 利つきではないと公式に宣言されること, そしてすべての既存の Net/2 の利 用者が 4.4BSD-Lite の利用へと移行することが強く奨励されること, という Novell 社からのありがたき天からの恵みでした. (訳注: 4.4BSD-Lite は その後 Novell 社のチェックを受けてから公開された.) FreeBSD も Net/2 を利 用していましたから, 1994年の 7月の終わりまでに Net/2 ベースの FreeBSD の出荷を停止するように言われました. ただし, このときの合意によって, 私 たちは締め切りまでに一回だけ最後の公開をすることを許されました. そして それは FreeBSD 1.1.5.1 となりました. それから FreeBSD プロジェクトは, まっさらでかなり不完全な 4.4BSD-Lite を基に, 文字どおり一から再度作り直すという, 難しくて大変な作業の準備を始めまし た. Lite バージョンは, 部分的には本当に軽くて, 中身がなかったので す. 起動し, 動作できるシステムを実際に作り上げるために必要となるプログ ラムコードのかなりの部分がバークレイ校 の CSRG (訳注: BSDを作っている グループ) によって (いろいろな法的要求のせいで) 削除されてしまっていた ということと, 4.4BSD の Intel アーキテクチャ対応が元々かなり不完全であっ たということがその理由です. この移行作業は結局 1994年の 11月までかかり ました. そしてその時点で FreeBSD 2.0 をネットと CDROM(12月末ごろ)を通じて公 開しました. これは, かなり粗削りなところが残っていたにもかかわらず, か なりの成功を収めました. そしてその後に, より信頼性が高く, そしてインス トールが簡単になった FreeBSD 2.0.5 が 1995年の 6月に公開されました. 私たちは 1996年の 8月に FreeBSD 2.1.5 を公開しました. この出来が非常に 良く, 特に業務で運用しているサイトや ISP での人気が高かったので, 私た ちは 2.1-STABLE 開発分流から更に公開をおこなうことにメリットがあると考 えました. それが FreeBSD 2.1.7.1 で, 2.1-STABLE 開発分流の最後を締めく くるものとして, 1997年の 2月に公開されました. 2.1-STABLE 開発分流 (RELENG_2_1_0) は現在, 保守のみをおこなう状態になっており, 今後は, セ キュリティの改善や他の何か重要なバグフィックスのみが おこなわれるでしょう. FreeBSD 2.2 の開発は, RELENG_2_2 開発ブランチとして, 開発の本流 (-CURRENT) から 1996 年 11 月に分岐し, そして 1997 年 4 月に最初のリリース(2.2.1)が行なわれました. 2.2 開発ブランチからは, さらに 97 年の夏と秋にリリースが行なわれ, 98 年 11 月に 2.2 開発ブランチの最終リリース(2.2.8)が 行なわれています. 1998 年 10 月に FreeBSD 3.0 最初の公式リリースが 行なわれ, 2.2 開発ブランチは開発の終了を迎えることになりました. 1999 年 1 月 20 日には, FreeBSD の開発ツリーが 4.0-CURRENT と 3.X-STABLE の各ブランチに再び分岐しました. 3.X-STABLE からは 3.1 が 1999 年 2 月 15 日に, 3.2 が 1999 年 5 月 15 日に, 3.3 が 1999 年 9 月 16 日にリリースされました. このブランチにおける現時点で最も新しいリリースは 3.4 で, 1999 年 12 月 20 日にリリースされています. 2000 年 3 月 13 日には 5.0-CURRENT の発生と, 4.X-STABLE ブランチの作成が行われました. これまでのところ, このブランチからの唯一のリリースは &rel.current;-RELEASE です. 長期的な開発プロジェクトは 5.0-CURRENT 開発ブランチで続けられ, 5.0 のスナップショットリリースが収録された CDROM (もちろん, ネットワーク上でも)は, 開発の進行状況に応じて 継続的に公開されています. FreeBSDプロジェクトの目的 原作: &a.jkh; 訳: &a.jp.kiroh; 24 September 1996. FreeBSD プロジェクトの目的は, いかなる用途にも使用でき, 何ら制限のない ソフトウェアを供給することです. 私たちの多くは, コード(そしてプロジェ クト)に対してかなりの投資をしてきており, これからも多少の無駄はあって も投資を続けて行くつもりです. ただ, 他の人達にも同じような負担をするよ うに主張しているわけではありません. FreeBSD に興味を持っている一人の残 らず全ての人々に, 目的を限定しないでコードを提供すること. これが, 私たちの最初のそして最大の 任務 であると信じています. そうすれば, コード は可能な限り広く使われ, 最大の恩恵をもたらすことができるでしょう. これ が, 私たちが熱烈に支持しているフリーソフトウェアの 最も基本的な目的であ ると, 私は信じています. 私たちのソースツリーに含まれるソースのうち, GNU 一般公有使用許諾(GPL)または GNU ライブラリ一般公有使用許諾(LGPL) に従っているものについては, 多少制限が課せられています. ただし, ソースコードへのアクセスの保証という, 一般の制限とはいわば逆の制限(訳注1)です. GPL ソフトウェアの商利用には, そのライセンスにある 複雑な側面が影響してくることがあります. ですから私たちは, そうすることが合理的であると判断されたときには, より制限の少ない, BSD 著作権表示を採用しているソフトウェアを 選択するようにしています. (訳注1) GPL では, 「ソースコードを実際に受け取るか, あるいは, 希望しさえすればそれを入手することが可能であること」 を求めています. FreeBSDの開発モデル 原作: &a.asami;. 18 October 1996. 訳: &a.asami;. 31 October 1996. FreeBSD の開発は非常に開かれた, 柔軟性のあるプロセスです. コントリビュータのリスト を見ていただければわかる とおり, FreeBSDは文字通り世界中の何百という人々の努力によって開発され ています. 新しい開発者はいつでも大歓迎ですので, &a.hackers; にメールを 送ってください. &a.announce; もありますので, 他のFreeBSDユーザに自分のやっ ていることを宣伝したい時にはどうぞ使ってください. あと, FreeBSD プロジェクトとその開発プロセスについて, どなたにも知って いていただきたいのは以下のようなことです. CVSリポジトリ FreeBSDのソースツリーは CVS (Concurrent Versions System) によってメンテナンスされています. CVSはソー スコード管理用のフリーソフトウェアで, FreeBSDのリリースにも含まれてい ます. FreeBSD の メインの CVS リポジトリ は米国カリフォルニア州のコンコルド市に存在 し, そこから世界中のたくさんのミラーサイトに コピーされています. CVSツ リーそのもの, そしてそのチェックアウトされたバージョンである -CURRENTと -STABLEはあな たのマシンにも簡単に取ってくることができます. これについては ソースツリーの同期 の章をご覧ください. ソースツリー管理者 ソースツリー管理者 はCVSツリーへの書き込み権限を持っている人, つまりFreeBSDのソースに変更を加えることができる人です. (CVSでリポジトリに変更を加えるには &man.cvs.1; commit というコマンドを使うので, これらの人々は英語では committers と呼ばれます.) 開発者にコードを送って見てもらうのに一番いい方法は &man.send-pr.1; コマンドを使うことです. もし, 何か問題があって send-pr が使えないならcvs-committers@FreeBSD.org にメールを送っていただいても結構です. FreeBSDコアチーム FreeBSD コアチームはFreeBSDプロジェク トが会社だとすると取締役会にあたるものです. コアチームとして一番重要 な役割は FreeBSD プロジェクトが全体としてよい方向に向かっていることを確 認することです. 責任感あふれる開発者を上記のソースツリー管理者として 招くこと, また仕事上の都合などでコアチームを やめた人たちの後任を見つけ ることもコアチームの役割です. 現在のコアチームのほとんどは最初は単な る一開発者としてプロジェクトに関わりはじめ, ずるずるといつのまにか深み にはまってしまった人です. コアチームのうち何人かは特定の 担当分野 を持っており, システムのうち一部に特に重点をおいて 面倒を見ています. 忘れてほしくないのはコアチームのほとんどは FreeBSD についてはボラ ンティアであり, FreeBSD プロジェクトからは何ら金銭的な支援を受けていな いということです. ですから, ここでの 責任 は 保証されたサポート ではありません. そういう意味で, 上記の取締役会という例えはあまりよく ないかもしれません. むしろ, FreeBSDのために人生を棒に振ってしまった人 の集まりといった方が正しいかも.... ;-) その他のコントリビュータ 最後になりますが, もっとも重要で多数をしめる開発者はフィードバック やバグフィクスをどんどん送ってくれるユーザ自身です. FreeBSDの開発に外 郭から関わっていきたいという人は &a.hackers; ( メーリングリスト情報 を見てください) に参加するといいでしょう. FreeBSD のソースツリーに入っている何かを書いた人の リスト は日に日に長くなっています. あ なたも今日, 何か送ることからはじめてみませんか? :-) もちろんFreeBSD に貢献するにはコードを書くほかにもいろいろな方法があ ります. 助けが求められている分野については, このハンドブックの 貢献の仕方 の節を見てください. ひとことで言うと, FreeBSD の開発組織はゆるやかな同心円状になっています. ともすると中央集権的に見えがちなこの組織は, FreeBSDのユーザが きちんと管理されたコードベースを 容易に追いかけられるようにデザインされ ているもので, 貢献したいという人を締め出す意図は全くありません! 私た ちの目標は安定したオペレーティングシステムと 簡単にインストールして使う ことのできる アプリケーションを提供することであ り, この方法は結構うまくはたらくのです. これからFreeBSDの開発にたずさわろうという人に, 私たちが望むことはただ 一つです: FreeBSDの成功を継続的なものにするために, 現在の開発者と同じ ような情熱を持って接してください! 現在のリリースについて FreeBSD は自由に利用でき Intel i386, i486, Pentium, Pentium Pro, Celeron, Pentium II, Pentium III (とその互換 CPU) 及び DEC Alpha アーキテクチャのコンピュータシステムで動作する, 4.4BSD-Lite2 ベースの全ソー スつきのリリースです. これはもともとカリフォルニア大学バーク レイ校 CSRGグループのソフトウェアがベースとなっており, NetBSD, OpenBSD, 386BSD, そして Free Software Foundation の ソフトウェアなどにより拡張されています. 94 年末の FreeBSD 2.0 のリリースからみると, FreeBSD は性能, 機能, 安定性の面で劇的に改善されました. もっとも大きな変化は仮想メモリシステムに おける改良で, 統合化された VM/file バッファキャッシュを用いる ことで性能を向上させながらも FreeBSD のメモリの使用量を減らすことができたことです. そのおかげで, 最低 5MB メモリという制約上でも動作するようになりました. その他の拡張としては, NIS のクライアントとサーバの完全なサポート, トランザクション TCP のサポート, ダイヤルオンデマンド PPP, 統合された DHCP のサポート, 改良された SCSI サブシステム, ISDN, ATM, FDDI, Fast Ethernet や Gigabit Ethernet(1000Mbit) アダプタへの対応, 最新の Adaptec コントローラ対応の改良や, 数百件におよぶバグの修正などがあります. 私たちはたくさんのユーザからのコメントや 提案をまじめに受け取り, 私たちが正しいと考え, かつ導入の手順が分かりやすいものを提供しようと 努力しています. この (継続的に進化する) プロセスに対するあなたの意見を 心からお待ちしています. FreeBSD では基本配布セットに加え, 移植されたソフトウェア集 として 数千の人気の高いプログラムを提供しています. 2000 年 7 月 中旬の時点で 3000 以上の ports (移植ソフトウェア) が存在します. ports には http (WWW) サーバから, ゲーム, 言語, エディタまでありとあらゆるものが含まれています. portsはオリジナル ソースに対する差分という形で表現されており, すべての portsを 集めても 50MB程度にしかなりません. こうすることで ports の更新を 容易にし, portsに必要なディスクスペースを小さくすることができます. portsをコンパイルするには, インストールしたいと思っているプログラムの ディレクトリに移動し, make install とすると, あとはすべてシステムが やってくれます. どの portsもオリジナルの配布セットを動的に CDROM または近くの FTP サーバから取ってくるので, ディスクは 構築したいと思っている portsの分だけを準備しておけば十分です. ほとんどの portsは, すでにコンパイルされた状態で package として提供されており, ソースコードからコンパイルしたくない場 合, これを使うと (pkg_add というコマンドで) 簡単にインストー ルできます. FreeBSD 2.1 以降のマシンであれば, /usr/share/doc ディレクトリにインストールの手順や FreeBSD を利用する上で有用な ドキュメントがたくさんあります. これらのローカルにインストールされたドキュメントは, HTML ブラウザを使って, 以下の URL から 参照することができます. FreeBSD ハンドブック (英文オリジナル) file:/usr/share/doc/handbook/index.html FreeBSD に関する FAQ file:/usr/share/doc/faq/index.html また, http://www.FreeBSD.org/ にはマスタ (かなり頻繁に更新されます) がありますので, こちらも参照してください. 合衆国の輸出規制のため, FreeBSD のコア配布セットには DES のコードは 含まれていません. 合衆国国内に限り, DES を使うプログラムなどが, コア配布セットに加えるパッケージとして提供されています. 誰でも使えるパッケージは, 別途, 合衆国国外で提供されています. 合衆国国外からも自由に取得可能な DES の配布セットに関する 詳細は, FreeBSD FAQ にあります. FreeBSD 上で必要とされるセキュリティがパスワードだけであり, Sun や DEC などの別のホストから暗号化されたパスワードをコピーする必要が ないのであれば, FreeBSD の MD5 ベースのセキュリティで十分です. この標準のセキュリティモデルは DES よりも適していると私たちは思って いますし, また, やっかいな輸出規制にもひっかかることはありません. あなたが合衆国国外にいるなら (あるいは国内にいても) 一度試してみて ください! diff --git a/ja_JP.eucJP/books/handbook/kerneldebug/chapter.sgml b/ja_JP.eucJP/books/handbook/kerneldebug/chapter.sgml index 15b639fe1b..79f539795e 100644 --- a/ja_JP.eucJP/books/handbook/kerneldebug/chapter.sgml +++ b/ja_JP.eucJP/books/handbook/kerneldebug/chapter.sgml @@ -1,690 +1,713 @@ カーネルデバッグ 原作 &a.paul; and &a.joerg; 訳: &a.jp.yoshiaki;. 1997 年 3 月 18 日. <command>kgdb</command> によるカーネルのクラッシュダンプのデバッグ ここではクラッシュダンプ (crash dump : 訳注 この文脈では kernel 自身 の異常によって停止した場合に出力されるイメージを指します) によるカー ネルデバッグの方法を示します. ここではダンプするための十分なスワップ (swap) の容量があるものとします. もし複数のスワップパーティションを持ち, 最初のパーティションがダンプ を保持するのに十分な大きさを持たない場合は 別のダンプデバイスを使うよ うに (config kernel 行で) カーネルのコンフィグをおこなうか, &man.dumpon.8; コマンドを使って別のデバイスを示すことができます. &man.dumpon.8; を使うもっともよい方法は変数 dumpdev を /etc/rc.conf で設定することです. 一般的には /etc/fstab で設定されているスワップデバイスが 使われるでしょう. スワップに使えないデバイスへのダンプ, 例えばテープへのダンプは現在サポートさ れていません. カーネルのコンフィグは config -g によって行ってください. FreeBSD カーネルのコンフィグレーション には FreeBSD のカーネルの設定の詳細がありますので 参照してください. &man.dumpon.8; コマンドを使ってどこへダンプするか カーネルに伝えてください (&man.swapon.8; によってそのパーティションが スワップとして設定された 後でなければならないことに注意してください). これは普通は /etc/rc.conf や /etc/rc で設定されます. あるいは 別の方法としてカーネルコンフィグレーションファイルの config 行の dump 節 で ダンプデバイスをハードコードすることができます. この方法はあまりよくは ありません. カーネルがブート時に crash する場合のクラッシュダンプを取り たい時だけ使うべきです. 以下では kgdbという用語は gdb をカーネルデバッグモードで動かしていることを意味します. gdb を オプションをつけて起動するか kgdbという名前でリン クして起動することでこのモードになります. デフォルトでは このリンク は作られていません. また, このアイデアは GNU関係者たちが彼らのツール を別の名前で呼び出した時に異なった動作をするということを 好まない, と いう点で不評です. あるいは将来この機能を廃止することになるかもしれません. + + FreeBSD 3 およびそれ以前のシステムを使っているなら, + 巨大なデバッグカーネルをそのままインストールするのではなく + strip されたデバッグ用カーネルをつくるべきでしょう. + + &prompt.root; cp kernel kernel.debug +&prompt.root; strip -g kernel + + この手順は必須ではありませんが, ぜひ行なうことをおすすめします + (FreeBSD 4 およびそれ以降では, カーネルの make + の段階で自動的にこれが行なわれます). + 自動的に, あるいは上のコマンドを手動で実行してカーネルが strip + されたら, 普通に make install + と実行し, カーネルをインストールして構いません. + + FreeBSD の古いリリース (3.1 を含まない以前のもの) は, + 標準で a.out カーネルを使っていることに注意してください. + これはシンボルテーブルが常に物理メモリ上に存在することを要求するため, + strip されていないデバッグカーネルに含まれる大きなシンボルテーブルは非常に無駄になります. + ELF カーネルを使った FreeBSD の最近のリリースでは, + そのような問題がなくなりました. + + カーネルを作った時にそのコピーを - kernel.debug という名前で作 りましょう. + kernel.debug という名前で作りましょう. また, オリジナルに対して strip -gを実行します. オリジナルを普通にインストールします. また strip していないカーネル も同様にインストールすることができますが, シンボルテーブルの参照時間 がいくつかのプログラムでは劇的に増加するでしょう. また, カーネル全体 はブート時に読み込まれ スワップアウトされないため数メガバイトの物理メ モリが無駄になります. 例えばブートプロンプトで 新しいカーネルの名前をタイプすることによって, 新しいカーネルをテストした場合で, 再びシステムを動かすのに別のカーネ ルで立ち上げることが必要な場合はブートプロンプトで フラグ を使いシングルユーザの状態にしてください. そして以下のような操作をおこな います. &prompt.root; fsck -p &prompt.root; mount -a -t ufs # /var/crash 用のファイルシステムを書き込み可能にする &prompt.root; savecore -N /kernel.panicked /var/crash &prompt.root; exit # ...マルチユーザモードへ移行 ここに示した &man.savecore.8; は (現在動いているものとは別の) カーネルのシンボル名の抽出をおこなうために使っています. 抽出はデフォルトで は現在動いているカーネルに対しておこなわれ, クラッシュダンプとカーネルシンボ ルのくい違いのためにまったく何もしません (訳注:そのためにオプション で実際にダンプをおこしたカーネルを指定します). クラッシュダンプの起きた後に /sys/compile/WHATEVERへ行き kgdbを動かします. kgdb より次のようにします. symbol-file kernel.debug exec-file /var/crash/kernel.0 core-file /var/crash/vmcore.0 こうすると, クラッシュダンプを使ってカーネルソースを他のプログラムと同様に デバッグすることができます. 次に kgdb での手順のセッションのログを示します. 長い行は読 みやすくするために改行しました. また, 参照のために行番号を入れてあり ます. ただし, これは実際の pcvtコンソールドライバの開発中の実際のエ ラーのトレースです. 1:Script started on Fri Dec 30 23:15:22 1994 2:&prompt.root; cd /sys/compile/URIAH 3:&prompt.root; kgdb kernel /var/crash/vmcore.1 4:Reading symbol data from /usr/src/sys/compile/URIAH/kernel ...done. 5:IdlePTD 1f3000 6:panic: because you said to! 7:current pcb at 1e3f70 8:Reading in symbols for ../../i386/i386/machdep.c...done. 9:(kgdb) where 10:#0 boot (arghowto=256) (../../i386/i386/machdep.c line 767) 11:#1 0xf0115159 in panic () 12:#2 0xf01955bd in diediedie () (../../i386/i386/machdep.c line 698) 13:#3 0xf010185e in db_fncall () 14:#4 0xf0101586 in db_command (-266509132, -266509516, -267381073) 15:#5 0xf0101711 in db_command_loop () 16:#6 0xf01040a0 in db_trap () 17:#7 0xf0192976 in kdb_trap (12, 0, -272630436, -266743723) 18:#8 0xf019d2eb in trap_fatal (...) 19:#9 0xf019ce60 in trap_pfault (...) 20:#10 0xf019cb2f in trap (...) 21:#11 0xf01932a1 in exception:calltrap () 22:#12 0xf0191503 in cnopen (...) 23:#13 0xf0132c34 in spec_open () 24:#14 0xf012d014 in vn_open () 25:#15 0xf012a183 in open () 26:#16 0xf019d4eb in syscall (...) 27:(kgdb) up 10 28:Reading in symbols for ../../i386/i386/trap.c...done. 29:#10 0xf019cb2f in trap (frame={tf_es = -260440048, tf_ds = 16, tf_\ 30:edi = 3072, tf_esi = -266445372, tf_ebp = -272630356, tf_isp = -27\ 31:2630396, tf_ebx = -266427884, tf_edx = 12, tf_ecx = -266427884, tf\ 32:_eax = 64772224, tf_trapno = 12, tf_err = -272695296, tf_eip = -26\ 33:6672343, tf_cs = -266469368, tf_eflags = 66066, tf_esp = 3072, tf_\ 34:ss = -266427884}) (../../i386/i386/trap.c line 283) 35:283 (void) trap_pfault(&frame, FALSE); 36:(kgdb) frame frame->tf_ebp frame->tf_eip 37:Reading in symbols for ../../i386/isa/pcvt/pcvt_drv.c...done. 38:#0 0xf01ae729 in pcopen (dev=3072, flag=3, mode=8192, p=(struct p\ 39:roc *) 0xf07c0c00) (../../i386/isa/pcvt/pcvt_drv.c line 403) 40:403 return ((*linesw[tp->t_line].l_open)(dev, tp)); 41:(kgdb) list 42:398 43:399 tp->t_state |= TS_CARR_ON; 44:400 tp->t_cflag |= CLOCAL; /* cannot be a modem (:-) */ 45:401 46:402 #if PCVT_NETBSD || (PCVT_FREEBSD >= 200) 47:403 return ((*linesw[tp->t_line].l_open)(dev, tp)); 48:404 #else 49:405 return ((*linesw[tp->t_line].l_open)(dev, tp, flag)); 50:406 #endif /* PCVT_NETBSD || (PCVT_FREEBSD >= 200) */ 51:407 } 52:(kgdb) print tp 53:Reading in symbols for ../../i386/i386/cons.c...done. 54:$1 = (struct tty *) 0x1bae 55:(kgdb) print tp->t_line 56:$2 = 1767990816 57:(kgdb) up 58:#1 0xf0191503 in cnopen (dev=0x00000000, flag=3, mode=8192, p=(st\ 59:ruct proc *) 0xf07c0c00) (../../i386/i386/cons.c line 126) 60: return ((*cdevsw[major(dev)].d_open)(dev, flag, mode, p)); 61:(kgdb) up 62:#2 0xf0132c34 in spec_open () 63:(kgdb) up 64:#3 0xf012d014 in vn_open () 65:(kgdb) up 66:#4 0xf012a183 in open () 67:(kgdb) up 68:#5 0xf019d4eb in syscall (frame={tf_es = 39, tf_ds = 39, tf_edi =\ 69: 2158592, tf_esi = 0, tf_ebp = -272638436, tf_isp = -272629788, tf\ 70:_ebx = 7086, tf_edx = 1, tf_ecx = 0, tf_eax = 5, tf_trapno = 582, \ 71:tf_err = 582, tf_eip = 75749, tf_cs = 31, tf_eflags = 582, tf_esp \ 72:= -272638456, tf_ss = 39}) (../../i386/i386/trap.c line 673) 73:673 error = (*callp->sy_call)(p, args, rval); 74:(kgdb) up 75:Initial frame selected; you cannot go up. 76:(kgdb) quit 77:&prompt.root; exit 78:exit 79: 80:Script done on Fri Dec 30 23:18:04 1994 上の出力についてのコメントをします. line 6: これは DDB (後述) からのダンプです. このため because you said to! という panicコメントがつき, ページフォルトのト ラップによって DDBに入ったことが原因の, やや長いスタックトレー スがあります. line 20: スタックトレースでのこれは trap()関数の位置で す. line 36: 新しいスタックフレームの使用を指定しています. これは現 在は必要ありません. trapの場合ではスタックフレームは正 しい場所を指していると考えられます. (私は新しいコアダンプ を持っていません. 私のカーネルは長い間 panicを起こしていま せん.) ソースコードの 403 行を見ると, tp ポインタのアク セスが失敗しているか配列のアクセスが範囲外である可能性が高 いことがわかります. line 52: 怪しいポインタですが, アクセスは正常におこなえました. line 56: ところが, 明らかにポインタはゴミを指しています. これで エラーを見つけました! (ここのコードの部分からはよくわかり ませんが, tp->t_lineはコンソールデバイスの規定 する行を参照しているので, もっと小さな整数でなければなりませ ん. ) DDD によるクラッシュダンプのデバッグ カーネルのクラッシュダンプは ddd のようなグラフィカルなデバッガで調べることもできます. 通常はコマンドラインで オプションをつけて ddd を起動します. たとえば: &prompt.root; ddd -k /var/crash/kernel.0 /var/crash/vmcore.0 クラッシュダンプを ddd のグラフィカルなインターフェースを使って 見ることができます. 突然ダンプした場合の解析 カーネルが予想もしない時にコアダンプして config -g を行ってコンパイルされていなかった場合にはどうしたら よいでしょう. すべてが失われるわけではありません. パニックを起こさないでください. もちろん, クラッシュダンプを使えるようにする必要があります. 使い方は前述の部分を見てください. カーネルのコンパイルディレクトリ (/usr/src/sys/arch/conf) で, 設定ファイルを編集します. 以下の行のコメントを外します (行が存在しなければ追加します): makeoptions DEBUG=-g #Build kernel with gdb(1) debug symbols カーネルを再構築しましょう. Makefileのタイムスタンプの変更により, 例えば trap.o などのいくつかの他のオブジェクトファイルも作り直さ れます. 少しの幸運があれば, オプションが追加されても作ら れるコードは変更されず, いくらかのデバッグシンボル以外には 問題を 起こしたコードとそっくりな新しいカーネルを手に入れることが できます. 少なくとも &man.size.1; コマンドで古い方と新しい方のサイズを比較すべ きです. これが食い違っていれば, 多分あきらめなければならないでしょう. ダンプを使って前述のように動かして調べます. デバッグシンボルは 必ずしも十分ではありません. 上の例ではスタックトレースでいくつかの関 数の行番号や引数リストが表示されないかもしれません. もしより多くのデ バッグシンボルが必要であれば,十分になるまで 適切なオブジェクトファイ ルを消して (makeして) kgdbセッションを繰り返してください. これは必ずしもうまく動くと保証はできません. しかしほとんどの場合でう まくいくでしょう. DDBを使ったオンラインカーネルデバッグ kgdb は非常に高レベルのユーザインタフェースを提 供するオフラインデバッガですが, いくつかのことはできません. (できないことの中で) 極めて重要なことはカーネルコードへのブレークポイ ントの設定とシングルステップ実行です. カーネルの低レベルデバッグが必要であれば, DDBと呼ばれる on-lineデバッ ガが使えます. ブレークポイントの設定, シングルステップのカーネルの実 行, 変数の検査と変更などができます. ただし,これはカーネルのソースファ イルにアクセスすることはできません. kgdbのようにすべてのデ バッグ情報にはアクセスできず, globalと staticのシンボルにアクセス することができるだけです. カーネルに DDB を含めるためにはコンフィグファイルに次のようなオプショ ンを加えて, options DDB 再構築をおこないます. ( FreeBSDのカーネルの設定の詳細については FreeBSD カーネルのコンフィグレーションを参照してくださ い. もしブートブロックが古いバージョンですと, デバッガのシンボルが完 全にはロードされないかもしれませんので注意してください. DDB シンボル がロードされるようにブートブロックを 最新の物にアップデートしてくださ い) DDB カーネルの実行において, DDBに入るいくつかの方法があります. 最初 の, 最も早い方法はブートプロンプトが出ている時に のブート フラグをタイプすることです. カーネルはデバッグモードで起動し, デバ イスのプローブ以前に DDBに入ります. したがって, デバイスのプローブ/初期 設定ファンクションのデバッグができます. 2つ目のシナリオはキーボードのホットキーで, 通常は Ctrl-Alt-ESCです. syscons ではホットキーは再設定することができ, 配付されているいくつかの キーマッピングでは別のキーに 再設定されていますので確認しておいてください. シリアルラインの BREAKを使って シリアルコンソールから DDBへ入ることを可 能にするオプションもあります (カーネルコンフィグレーションファイルの options BREAK_TO_DEBUGGER). これは 多くのつまらないシリ アルアダプタが, 例えばケーブルを引き抜いた時に BREAK状態を意味もなく 作り出してしまうのでデフォルトでは無効になっています. 3つ目は, DDB を使うようになっているカーネルがパニック状態になると DDB へ入るというものです. このため, 無人運転するマシンのカーネルにDDBを 入れるのは賢明ではありません. DDB のコマンドはおおまかには gdb のいくつかのコマンドと似て います. おそらく最初にブレークポイントを 設定する必要があるでしょう. b function-name b address 数値はデフォルトでは16進数で, シンボル名とはまったく異ります. 16進数で a-f の文字で始まる場合は, 先頭に 0x をつける必要があります(それ以外の数字の場合はどちらでもか まいません). function-name + 0x103のような単純な式を使うこ とができます. 割り込みされたカーネルから処理を続行するためには, c とタイプするだけです. スタックのトレースには trace とします. DDB にホットキーで入った場合は, カーネルはその (ホットキーの) 割り込み の処理を行っていますのでスタックトレースは あまり役にたたないことに注 意してください. ブレークポイントを削除したい場合は, del del address-expression とします. 最初の形式はブレークポイントにヒットしたすぐ後で使うことが でき, 現在のブレークポイントを削除します. 2番目の形式では任意のブレー クポイントを削除することができますが, 次の形式で得られるような正確な アドレスを与えることが必要です. show b カーネルをシングルステップ実行させるには s としてみてください. これは関数呼出し先までステップ実行 (step into function) するでしょう. 次のステートメントが終了するまでのDDBトレースは n によっておこなうことができます. これは gdb の next 命令とは異ります. gdbの finish命令と似ています. メモリ上のデータを調べるには (例として) 次のようにします. x/wx 0xf0133fe0,40 x/hd db_symtab_space x/bc termbuf,10 x/s stringbuf word/halfword/byte 単位でアクセスをおこない, hex (16進) /dec (10進) / char (文字) /string (文字列) で表示します. カンマの後ろの数字はオブジェク トカウントです. 次の 0x10個の要素を表示するには, 単純に x ,10 とします. 同様に次のように使うことができます. x/ia foofunc,10 foofunc の最初の 0x10個の命令語をディスアセンブルし, foofunc の先頭からのオフセットとともに表示します. メモリの内容を変更するには writeコマンドを使います. w/b termbuf 0xa 0xb 0 w/w 0xf0010030 0 0 コマンドモディファイアの (b/h/w) はデータを 書くサイズを定義し, これに続く最初の式は書き込むアドレス, 残りがこれ に続く連続するメモリアドレスに書き込まれるデータになります. 現在のレジスタ群の内容を知りたい場合は show reg とします. また, 単一のレジスタの値を表示するには, 例えば p $eax とします. また値の変更は set $eax new-value とします. DDBからカーネルの関数を呼び出す必要がある場合は, 単に call func(arg1, arg2, ...) とします. return 値が出力されます. 動いているプロセスの &man.ps.1; スタイルの概要は ps です. カーネルの失敗の原因の調査が終わったらリブートすべきです. それまでの 不具合によりカーネルのすべての部分が期待するような 動作をしているわけ ではないということを忘れないでください. 以下のうちいずれかの方法でシ ステムのシャットダウンおよびリブートを行ってください. panic カーネルをコアダンプしてリブートしますので, 後で kgdbによってコアの高 レベル解析をすることができます. このコマンドは通常, 一度 continue命令を使った後に 使うことになるでしょう. call boot(0) は動いているシステムを `clean' に shut downするよい方法です. すべて のディスクを sync()して最後にリブートします. ディスクとカー ネルのファイルシステムインタフェースが破損していない限り, ほぼ完全 に `clean'にシャットダウンするよい方法でしょう. call cpu_reset() は大惨事を防ぐための最後の手段で 「赤い大きなボタン」 を押すのとほとんど 同じです.(訳注: リセットボタンを押すのとほぼ同じであるという意味です) 短いコマンドの要約は help をタイプします. ただし, デバッグセッションのために &man.ddb.4; の マニュアルページのプリントアウトを用意しておくことを 強くお奨めします. カーネルのシングルステップ中にオンラインマニュアルを 読むことは難しい ということを覚えておいてください. リモート GDB を使ったオンラインカーネルデバッグ この機能は FreeBSD 2.2 からサポートされました. これは本当にすばらし い機能です. GDB はすでにかなり以前より リモートデバッグ をサポートしてい ます. これはシリアル回線を使い非常に単純なプロトコルで行ないます. もちろん, この方法では今までに示した方法とは違い, 2台のマシンが必 要になります. 1台はデバッグ環境のためのホストで, すべてのソースとす べてのシンボルを含んだバイナリのコピーを持っています. もう 1台は ターゲットマシンで, 同一のカーネルのコピー (ただしデバッグ情報は 取り除いてあるもの) を単に実行するためのものです. この場合, カーネルのコンフィグレーションは config -g で行な い, を含めなくてはなりません. そうして通常通りコンパイルし ます. こうして作ったバイナリファイルはデバッグ情報のために非常に大き くなります. このカーネルをターゲットマシンにコピーして strip -x でデバッグシンボルを取り除きます. そして ブートオプションを使いブートします. sio デバイスにフラグ 0x80 が設定されているターゲットマシンの シリアル回線を, デバッグホストのいずれかのシリアル回線に つないでください. それからデバッグ(訳注:ホスト)マシン上で, ターゲットとなって いるカーネルのコンパイルディレクトリで gdb を起動します: &prompt.user; gdb -k kernel GDB is free software and you are welcome to distribute copies of it under certain conditions; type "show copying" to see the conditions. There is absolutely no warranty for GDB; type "show warranty" for details. GDB 4.16 (i386-unknown-freebsd), Copyright 1996 Free Software Foundation, Inc... (kgdb) リモートデバッグセッションの初期化 (1番目のシリアルポートを使用する ことの設定) を以下のように行ないます. (kgdb) target remote /dev/cuaa0 次にターゲットマシン (デバイスのプローブ直前で DDB に入っています) で次のように入力します: Debugger("Boot flags requested debugger") Stopped at Debugger+0x35: movb $0, edata+0x51bc db> gdb DDB は次のような出力を返すでしょう. Next trap will enter GDB remote protocol mode gdbと入力するたびに リモート GDB とローカル DDB が交互に切り替わ ります. トラップをすぐに起こすために単に ``s'' (step) と入力して下 さい. そうするとホストの GDB はターゲットのカーネルの制御を行なうよ うになります. Remote debugging using /dev/cuaa0 Debugger (msg=0xf01b0383 "Boot flags requested debugger") at ../../i386/i386/db_interface.c:257 (kgdb) このセッションではソースコードへのフルアクセスや Emacs の window 上 の gud-mode (これは別の Emacs window に自動的にソースコードを表示し ます) で動かすなど, 通常の GDB セッションでできることのほとんどのこ とができます. リモート GDB は LKM のデバッグも行なうことができます. 最初に LKM を デバッグシンボルを含めた形で作ります. &prompt.root; cd /usr/src/lkm/linux &prompt.root; make clean; make COPTS=-g そしてターゲットマシン上で モジュールのこのバージョンをインストールし ます. これをロードしてから, modstat を使ってロードされている ことを確認してください: &prompt.root; linux &prompt.root; modstat Type Id Off Loadaddr Size Info Rev Module Name EXEC 0 4 f5109000 001c f510f010 1 linux_mod 示されたロードアドレスに 0x20 (a.outのヘッダはおそらくこの大きさでしょ う) を加えます. それがモジュールコードの再配置されるアドレスです. GDB の add-symbol-file コマンドを使ってデバッガにモジュールの 情報をつたえます. (kgdb) add-symbol-file /usr/src/lkm/linux/linux_mod.o 0xf5109020 add symbol table from file "/usr/src/lkm/linux/linux_mod.o" at text_addr = 0xf5109020? (y or n) y (kgdb) これで LKM のすべてのシンボルにアクセスできるようになります. コンソールドライバのデバッグ DDBを動かすためにはコンソールドライバが必要ですから, コンソールドラ イバ自身に不具合のある場合は複雑になります. シリアルコンソールを利 用する方法 (ブートブロックを変更するか Boot:プロンプトで と入力する) を思い出してください. そして標準ター ミナルを最初のシリアルポートに設定します. DDBは, もちろんシリアルコ ンソールを含むいずれの コンソールドライバの設定でも動作します. diff --git a/ja_JP.eucJP/books/handbook/mirrors/chapter.sgml b/ja_JP.eucJP/books/handbook/mirrors/chapter.sgml index 9eeedabc00..9c207b0137 100644 --- a/ja_JP.eucJP/books/handbook/mirrors/chapter.sgml +++ b/ja_JP.eucJP/books/handbook/mirrors/chapter.sgml @@ -1,3296 +1,3480 @@ FreeBSD の入手方法 CD-ROM 出版社 FreeBSD は Walnut Creek CDROM から出されている CD-ROM から入手できます:
Walnut Creek CDROM 4041 Pike Lane, Suite F Concord CA, 94520 USA Phone: +1 925 674-0783 Fax: +1 925 674-0821 Email: info@cdrom.com WWW: http://www.cdrom.com/
FTP サイト FreeBSD の公式な情報は anonymous FTP によって以下の場所から 入手できます:
ftp://ftp.FreeBSD.org/pub/FreeBSD/.
FreeBSD ミラーサイトデーターベース FreeBSD ハンドブックの “ミラーサイト一覧” よりも正確です.というのはその情報を DNS から取得するので, 静的に記述されたリストよりも信頼性が高いのです. さらに, FreeBSD は以下のミラーサイトから anonymous FTP によって 入手できます. もし FreeBSD を anonymous FTP によって手にいれる場合は, 近くのサイトを利用するようにしてください. Argentina, Australia, Brazil, Canada, China, Czech Republic, Denmark, Estonia, Finland, France, Germany, Hong Kong, Ireland, Israel, Japan, Korea, Netherlands, New Zealand, Poland, Portugal, Russia, Saudi Arabia, South Africa, Spain, Slovak Republic, Slovenia, Sweden, Taiwan, Thailand, UK, Ukraine, USA. アルゼンチン 何か問題がある場合は，このドメインの hostmaster hostmaster@ar.FreeBSD.org に連絡してください． ftp.ar.FreeBSD.org/pub/FreeBSD/ オーストラリア 何か問題がある場合は, このドメインの hostmaster hostmaster@au.FreeBSD.org に連絡してください. ftp://ftp.au.FreeBSD.org/pub/FreeBSD/ ftp://ftp2.au.FreeBSD.org/pub/FreeBSD/ ftp://ftp3.au.FreeBSD.org/pub/FreeBSD/ ftp://ftp4.au.FreeBSD.org/pub/FreeBSD/ ブラジル 何か問題がある場合は, このドメインの hostmaster hostmaster@br.FreeBSD.org に連絡してください. ftp://ftp.br.FreeBSD.org/pub/FreeBSD/ ftp://ftp2.br.FreeBSD.org/pub/FreeBSD/ ftp://ftp3.br.FreeBSD.org/pub/FreeBSD/ ftp://ftp4.br.FreeBSD.org/pub/FreeBSD/ ftp://ftp5.br.FreeBSD.org/pub/FreeBSD/ ftp://ftp6.br.FreeBSD.org/pub/FreeBSD/ ftp://ftp7.br.FreeBSD.org/pub/FreeBSD/ カナダ 何か問題がある場合は, このドメインの hostmaster hostmaster@ca.FreeBSD.org に連絡してください. ftp://ftp.ca.FreeBSD.org/pub/FreeBSD/ 中国 何か問題がある場合は, このドメインの hostmaster phj@cn.FreeBSD.org に連絡してください. ftp://ftp.cn.FreeBSD.org/pub/FreeBSD/ チェコ 何か問題がある場合は, このドメインの hostmaster hostmaster@cz.FreeBSD.org に連絡してください. ftp://ftp.cz.FreeBSD.org/pub/FreeBSD/ 連絡先: calda@dzungle.ms.mff.cuni.cz デンマーク 何か問題がある場合は，このドメインの hostmaster hostmaster@dk.FreeBSD.org に連絡してください． ftp://ftp.dk.FreeBSD.org/pub/FreeBSD/ エストニア 何か問題がある場合は, このドメインの hostmaster hostmaster@ee.FreeBSD.org に連絡してください. ftp://ftp.ee.FreeBSD.org/pub/FreeBSD/ フィンランド 何か問題がある場合は, このドメインの hostmaster hostmaster@fi.FreeBSD.org に連絡してください. ftp://ftp.fi.FreeBSD.org/pub/FreeBSD/ フランス 何か問題がある場合は, このドメインの hostmaster hostmaster@fr.FreeBSD.org に連絡してください. ftp://ftp.fr.FreeBSD.org/pub/FreeBSD/ ftp://ftp2.fr.FreeBSD.org/pub/FreeBSD/ ftp://ftp3.fr.FreeBSD.org/pub/FreeBSD/ ドイツ 何か問題がある場合は, このドメインのミラー管理者 de-bsd-hubsr@de.FreeBSD.org に連絡してください. ftp://ftp.de.FreeBSD.org/pub/FreeBSD/ ftp://ftp2.de.FreeBSD.org/pub/FreeBSD/ ftp://ftp3.de.FreeBSD.org/pub/FreeBSD/ ftp://ftp4.de.FreeBSD.org/pub/FreeBSD/ ftp://ftp5.de.FreeBSD.org/pub/FreeBSD/ ftp://ftp6.de.FreeBSD.org/pub/FreeBSD/ ftp://ftp7.de.FreeBSD.org/pub/FreeBSD/ 香港 ftp://ftp.hk.super.net/pub/FreeBSD/ 連絡先: ftp-admin@HK.Super.NET. アイルランド 何か問題がある場合は, このドメインの hostmaster hostmaster@ie.FreeBSD.org に連絡してください. ftp://ftp.ie.FreeBSD.org/pub/FreeBSD/ イスラエル 何か問題がある場合は, このドメインの hostmaster hostmaster@il.FreeBSD.org に連絡してください. ftp://ftp.il.FreeBSD.org/pub/FreeBSD/ ftp://ftp2.il.FreeBSD.org/pub/FreeBSD/ 日本 何か問題がある場合は, このドメインの hostmaster hostmaster@jp.FreeBSD.org に連絡してください. ftp://ftp.jp.FreeBSD.org/pub/FreeBSD/ ftp://ftp2.jp.FreeBSD.org/pub/FreeBSD/ ftp://ftp3.jp.FreeBSD.org/pub/FreeBSD/ ftp://ftp4.jp.FreeBSD.org/pub/FreeBSD/ ftp://ftp5.jp.FreeBSD.org/pub/FreeBSD/ ftp://ftp6.jp.FreeBSD.org/pub/FreeBSD/ 韓国 何か問題がある場合は, このドメインの hostmaster hostmaster@kr.FreeBSD.org に連絡してください. ftp://ftp.kr.FreeBSD.org/pub/FreeBSD/ ftp://ftp2.kr.FreeBSD.org/pub/FreeBSD/ ftp://ftp3.kr.FreeBSD.org/pub/FreeBSD/ ftp://ftp4.kr.FreeBSD.org/pub/FreeBSD/ ftp://ftp5.kr.FreeBSD.org/pub/FreeBSD/ ftp://ftp6.kr.FreeBSD.org/pub/FreeBSD/ オランダ 何か問題がある場合は, このドメインの hostmaster hostmaster@nl.FreeBSD.org に連絡してください. ftp://ftp.nl.FreeBSD.org/pub/FreeBSD/ ニュージーランド 何か問題がある場合は, このドメインの hostmaster hostmaster@nz.FreeBSD.org に連絡してください. ftp://ftp.nz.FreeBSD.org/pub/FreeBSD/ ポーランド 何か問題がある場合は，このドメインの hostmaster hostmaster@pl.FreeBSD.org に連絡してください． ftp://ftp.pl.FreeBSD.org/pub/FreeBSD/ ポルトガル 何か問題がある場合は, このドメインの hostmaster hostmaster@pt.FreeBSD.org に連絡してください. ftp://ftp.pt.FreeBSD.org/pub/FreeBSD/ ftp://ftp2.pt.FreeBSD.org/pub/FreeBSD/ ロシア 何か問題がある場合は, このドメインの hostmaster hostmaster@ru.FreeBSD.org に連絡してください. ftp://ftp.ru.FreeBSD.org/pub/FreeBSD/ ftp://ftp2.ru.FreeBSD.org/pub/FreeBSD/ ftp://ftp3.ru.FreeBSD.org/pub/FreeBSD/ ftp://ftp4.ru.FreeBSD.org/pub/FreeBSD/ サウジアラビア 何か問題がある場合は, ftpadmin@isu.net.sa に連絡してください. ftp://ftp.isu.net.sa/pub/mirrors/ftp.freebsd.org/ 南アフリカ 何か問題がある場合は, このドメインの hostmaster hostmaster@za.FreeBSD.org に連絡してください. ftp://ftp.za.FreeBSD.org/pub/FreeBSD/ ftp://ftp2.za.FreeBSD.org/pub/FreeBSD/ ftp://ftp3.za.FreeBSD.org/pub/FreeBSD/ スロヴァキア共和国 何か問題がある場合には, このドメインの hostmaster hostmaster@sk.FreeBSD.org に連絡してください. ftp://ftp.sk.FreeBSD.org/pub/FreeBSD/ スロベニア 何か問題がある場合には, このドメインの hostmaster hostmaster@si.FreeBSD.org に連絡してください. ftp://ftp.si.FreeBSD.org/pub/FreeBSD スペイン 何か問題がある場合は, このドメインの hostmaster hostmaster@es.FreeBSD.org に連絡してください. ftp://ftp.es.FreeBSD.org/pub/FreeBSD/ スウェーデン 何か問題がある場合は, このドメインの hostmaster hostmaster@se.FreeBSD.org に連絡してください. ftp://ftp.se.FreeBSD.org/pub/FreeBSD/ ftp://ftp2.se.FreeBSD.org/pub/FreeBSD/ ftp://ftp3.se.FreeBSD.org/pub/FreeBSD/ 台湾 何か問題がある場合は, このドメインの hostmaster hostmaster@tw.FreeBSD.org に連絡してください. ftp://ftp.tw.FreeBSD.org/pub/FreeBSD/ ftp://ftp2.tw.FreeBSD.org/pub/FreeBSD/ ftp://ftp3.tw.FreeBSD.org/pub/FreeBSD/ ftp://ftp4.tw.FreeBSD.org/pub/FreeBSD/ タイ ftp://ftp.nectec.or.th/pub/FreeBSD/ 連絡先: ftpadmin@ftp.nectec.or.th. ウクライナ ftp://ftp.ua.FreeBSD.org/pub/FreeBSD/ 連絡先: freebsd-mnt@lucky.net. イギリス 何か問題がある場合は, このドメインの hostmaster hostmaster@uk.FreeBSD.org に連絡してください. ftp://ftp.uk.FreeBSD.org/pub/FreeBSD/ ftp://ftp2.uk.FreeBSD.org/pub/FreeBSD/ ftp://ftp3.uk.FreeBSD.org/pub/FreeBSD/ ftp://ftp4.uk.FreeBSD.org/pub/FreeBSD/ ftp://ftp5.uk.FreeBSD.org/pub/FreeBSD/ アメリカ 何か問題がある場合は, このドメインの hostmaster hostmaster@FreeBSD.org に連絡してください. ftp://ftp.FreeBSD.org/pub/FreeBSD/ ftp://ftp2.FreeBSD.org/pub/FreeBSD/ ftp://ftp3.FreeBSD.org/pub/FreeBSD/ ftp://ftp4.FreeBSD.org/pub/FreeBSD/ ftp://ftp5.FreeBSD.org/pub/FreeBSD/ ftp://ftp6.FreeBSD.org/pub/FreeBSD/ + - FreeBSD (2.0C またはそれ以降) の輸出規制コード (eBones と - secure) の 最新のバージョンは以下の場所から入手できます. - もしあなたがアメリカやカナダ以外にいるのであれば, secure (DES) - と eBones (Kerberos) を - 以下の外国向けの配布サイトから手にいれてください: - - - 南アフリカ - - このドメインの Hostmaster - hostmaster@internat.FreeBSD.org . + + Anonymous CVS - - - ftp://ftp.internat.FreeBSD.org/pub/FreeBSD/ - + 訳: &a.jp.sugimura;, 1998 年 7 月 19 日. - - ftp://ftp2.internat.FreeBSD.org/pub/FreeBSD/ - - - - + + <anchor id="anoncvs-intro">導入 + + Anonymous CVS (もしくは, anoncvs + として知られています) は離れたところにある CVS + リポジトリと同期を取るために FreeBSD に付属している CVS + ユーティリティに含まれている機能です. 他にもありますが, + それは FreeBSD のユーザが, 特別な権限なしに FreeBSD + プロジェクトの公式な anoncvs サーバに読み取り専用で CVS + の操作をすることができるようにするためのものです. + それを使うには, 単に CVSROOT + 環境変数を設定して適切な anoncvs サーバを指定し, + cvs login を使って + パスワード anoncvs を入力してください. + そして次に &man.cvs.1; コマンドを使うことで, + 手元にあるリポジトリと同じようにアクセスできるようになります. + + CVSup と + anoncvs + のサービスは本質的に同じ機能ではないかということも言われていますが, + ユーザが同期を取る方法を選ぶときに影響を与える, + さまざまなトレードオフが存在します. 要約して言えば, + CVSup + はネットワーク資源の使い方においては非常に効率が良く技術的にもはるかに洗練されたものですが, + 相当な手間がかかります. CVSup + を使うには特別なクライアントをまずインストールして設定しなくては + 1 bit も取ってくることができませんし, さらにそのとき + CVSup で取ってくることができるのは, + コレクション(collection) + と呼ばれる, + かなり大きなかたまりだけです. + + それに対して anoncvs では, + CVS モジュールの名前を指定することで特定のプログラムの + (ls や grep のような) + 個々のファイルから調べることができます. もちろん, + anoncvs は CVS + リポジトリの読み取り専用の操作に対してのみ適しているので, + もしあなたが FreeBSD プロジェクトのものと共有されたなにか + ローカルなリポジトリを作ってそこでの開発を + 行おうというときには, CVSup + だけが唯一の手段となってしまいます. + + + + <anchor id="anoncvs-usage">Anonymous CVS を使う + + &man.cvs.1; を設定して Anonymous CVS + リポジトリを使うには単に CVSROOT + 環境変数を設定して FreeBSD プロジェクトの + anoncvs サーバを指定するだけのことです. + この文書を書いているときには, + 次のサーバが利用できるようになっています. + + + + USA: + :pserver:anoncvs@anoncvs.freebsd.org:/ncvs + (cvs login コマンドを使い, + プロンプトが表示されたらパスワード + anoncvs を入力してください) + + + + CVS はかつて存在した (もしくは, + 時にはこれから存在するものも :) + ほとんどどんなバージョンの FreeBSD のソースを check + out することができますが, あなたは &man.cvs.1; の + リビジョン () のオプションや FreeBSD + プロジェクトのリポジトリの中で + それをどのように指定したらいいものかということを + よく知っておく必要があります. + + タグには 2 種類あって, + リビジョンタグとブランチタグがあります. + リビジョンタグは特定の改訂版を指しており, + それはいつも同じものを意味しています. 一方ブランチタグは, + 指定されたときの指定された開発の流れにおける + 最も新しい改訂版を示しています. + ブランチタグは特定の改訂版を指していないために, + その意味はきょうと明日では違うものになっているでしょう. + + + ユーザが興味を持つと思われるブランチタグの一覧です + (Ports Collectionに有効なタグは + HEAD + だけだという事を心に留めておいてください). + + + + HEAD + + + 主要部をなす流れ, すなわち FreeBSD-CURRENT + のための名前です. また, + どのリビジョンも + 指定されなかったときにはこれになります. + + + + + RELENG_4 + + + FreeBSD-4.X の開発のための流れです. + FreeBSD-STABLE としても知られています. + + + + + RELENG_3 + + + FreeBSD-3.X の開発のための流れです. + 3.X-STABLE としても知られています. + + + + + RELENG_2_2 + + + FreeBSD-2.2.X の開発のための流れです. 2.2-STABLE + としても知られています. このブランチは大部分が + すたれています. + + + + + ユーザが興味を持つであろうリビジョンタグの一覧です. + これらはいずれも Ports Collection には無効です. + Ports Collection は複数のリビジョンを持ちません + + + + RELENG_4_0_0_RELEASE + + + FreeBSD 4.0 です. + + + + + RELENG_3_4_0_RELEASE - ブラジル - - このドメインの Hostmaster - hostmaster@br.FreeBSD.org . + + FreeBSD-3.4 です. + + + + + RELENG_3_3_0_RELEASE + + + FreeBSD-3.3 です. + + + + + RELENG_3_2_0_RELEASE + + + FreeBSD-3.2 です. + + + + + RELENG_3_1_0_RELEASE + + + FreeBSD-3.1 です. + + + + + RELENG_3_0_0_RELEASE + + + FreeBSD-3.0 です. + + - - - ftp://ftp.br.FreeBSD.org/pub/FreeBSD/ - - - - + + RELENG_2_2_8_RELEASE + + + FreeBSD-2.2.8 です. + + + + + RELENG_2_2_7_RELEASE + + + FreeBSD-2.2.7 です. + + + + + RELENG_2_2_6_RELEASE + + + FreeBSD-2.2.6 です. + + + + + RELENG_2_2_5_RELEASE + + + FreeBSD-2.2.5 です. + + + + + RELENG_2_2_2_RELEASE + + + FreeBSD-2.2.2 です. + + + + + RELENG_2_2_1_RELEASE + + + FreeBSD-2.2.1 です. + + + + + RELENG_2_2_0_RELEASE + + + FreeBSD-2.2.0 です. + + + + + ブランチタグを指定したときには, + 普通はその開発の流れにおける + 最も新しいバージョンのファイルを受け取ることができます. + もし以前のバージョンのものが欲しいときには, 日付を + + オプションを使って指定すればよいです. + これ以上のことは &man.cvs.1; man page を見てください. + + + + 例 + + 本当はなにかする前には &man.cvs.1; + のマニュアルページの全体をちゃんと読んでからのほうがいいのですが, + Anonymous CVS + の使い方の本質的なところを簡単に例を挙げて説明します. + + + -CURRENT (&man.ls.1;) + をちょっと確認してから消してみます. + + +&prompt.user; setenv CVSROOT :pserver:anoncvs@anoncvs.freebsd.org:/ncvs +&prompt.user; cvs login +プロンプトが表示されたら, パスワード anoncvs を入力します. +&prompt.user; cvs co ls +&prompt.user; cvs release -d ls +&prompt.user; cvs logout + + + + &man.ls.1; のバージョンを 3.X-STABLE + ブランチから調べてみます. + + +&prompt.user; setenv CVSROOT :pserver:anoncvs@anoncvs.freebsd.org:/ncvs +&prompt.user; cvs login +プロンプトが表示されたら, パスワード anoncvs を入力します. +&prompt.user; cvs co -rRELENG_3 ls +&prompt.user; cvs release -d ls +&prompt.user; cvs logout + + + + &man.ls.1; の変更点のリストを + (unified diff で) 作ってみます. + + +&prompt.user; setenv CVSROOT :pserver:anoncvs@anoncvs.freebsd.org:/ncvs +&prompt.user; cvs login +プロンプトが表示されたら, パスワード anoncvs を入力します. +&prompt.user; cvs rdiff -u -rRELENG_3_0_0_RELEASE -rRELENG_3_4_0_RELEASE ls +&prompt.user; cvs logout + + + + 他のどんなモジュールの名前が + 使われているか検索してみます. + + +&prompt.user; setenv CVSROOT :pserver:anoncvs@anoncvs.freebsd.org:/ncvs +&prompt.user; cvs login +プロンプトが表示されたら, パスワード anoncvs を入力します. +&prompt.user; more modules/modules +&prompt.user; cvs release -d modules +&prompt.user; cvs logout + + - フィンランド - - - - ftp://nic.funet.fi/pub/unix/FreeBSD/eurocrypt/ - 連絡先: count@nic.funet.fi. - - - - - + + 他の資料 + + 次の資料は CVS を学ぶのに役に立つでしょう. + + + + CVS チュートリアル. Cal Poly によるものです. + + + + Cyclic + Software, 商用として CVS を保守しています. + + + + CVSWeb + は FreeBSD Project の CVS のための WWW インターフェースです. + + + - + CTM を使う 訳: &a.hanai;, 1997 年 9 月 13 日. CTM はリモートのディレクトリツリーを中央のツリーに同期させるための 手段です. これはFreeBSDのソースツリーの配布を行なうために開発されまし たが, 時が経つにつれて別の目的にも有用であることがわかるかも しれません. デルタを作り出す処理に関するドキュメントは現在ほとんど ありません. 従って, もしあなたがCTM を他のことに使いたいなら &a.phk;にさらなる情報を問い合わせてください. なぜ<application>CTM</application>を使うの? CTM を使うことにより FreeBSD ソースツリーのローカルコピーを手にいれることができます. ソースツリーが使えることの魅力は数多くあります. 完全な cvs ツリーを追いかけるにしても, ひとつのブランチを追いかける にしても CTM は必要な情報を与えてくれます. もしあなたがFreeBSDのアクティブな開発者であるにもかかわらず お粗末なTCP/IP接続しか持っていなかったり, またはTCP/IP接続が 行なえないとしたら, あるいは単に変更が自動的に送られてきて ほしいというのであれば CTM はそんなあなたのために 作られたのです. アクティブなブランチでは 1 日に最大三つまでのデルタを受け取る必要があります. これが自動的に e-mail で送られてくるという方法を ぜひ検討してみてください. デルタのサイズは常にできるだけ小さく保たれています. 大抵の場合5KBよりも小さく, たまに(10回に1回程度)10-50KBになり, ときおり100KBかもっと大きくなるでしょう. 開発ソースから直接に得られたものを使うことについては, あらかじめパッケージにされたリリースとは違い, いろいろと注意することが あります. これは特に “current” のソースを選んでいるときは重要です. 最新の FreeBSD を追いかけるを読むことをお勧めします. <application>CTM</application>を使うには何が必要? 二つのものが必要でしょう: CTM プログラムとそれに与える (“current” レベルを得るための)最初のデルタです. CTM プログラムはバージョン2.0のリリース以来FreeBSDの一部にな りました. もしソースのコピーを持っているなら /usr/src/usr.sbin/CTMにあります. もしFreeBSDの2.0以前のバージョンなら, 最新のCTMのソースを直接 ftp://ftp.FreeBSD.org/pub/FreeBSD/FreeBSD-current/src/usr.sbin/ctm/ から入手できます. CTM に与える “デルタ” は二つの方法, FTPまたはe-mail, で得ること ができます. もしインターネットにFTPアクセスできるなら, 次のFTPサイト: ftp://ftp.FreeBSD.org/pub/FreeBSD/CTM/ - または, その ミラーサイト が + または, その ミラーサイト が CTM へのアクセスをサポートします. 適切なディレクトリに FTP して README ファイルを入手し, そこからスタートしてください. e-mail によってデルタを得たいという場合は: CTM 配布メーリングリストのいずれかに参加するために &a.majordomo; へ subscribe のメールを送ってください. “ctm-cvs-cur” は完全な cvs ツリー をサポートします. “ctm-src-cur” は開発先端ブランチをサポートします “ctm-src-2_2” は 2.2 リリースのブランチのサポートです. (もし majordomo を使って参加する方法を知らないのであれば, 最初に help という語を含むメッセージを送ってください. — 使い方の説明が送られてくるでしょう.) メールで CTM による更新ファイルを受け取り始めると, 中身を取り出して使用 するために ctm_rmail プログラムを使うかもしれません. それを完全 に自動で行ないたいなら, /etc/aliases から ctm_rmailプロ グラムを直接使うこともできます. さらに詳しいことはctm_rmail manページを御覧ください. CTM デルタを得るためにどの方法を使うのであっても, ctm-announce@FreeBSD.org メーリングリストに参加するべきです. このメーリングリストは将来的には CTMシステムの操作に関する アナウンスがポストされる唯一の場になるでしょう. メーリングリストに加わるためにはsubscribe ctm-announce と書いた一行だけのメールを &a.majordomo; へ送ってください. はじめて<application>CTM</application>を使い始める CTM デルタを使い始めるためには, これは以降作られる全ての デルタの出発点を手にいれる必要があります. 最初にあなたが何をすでに持っているかをはっきりさせましょう. すべての人は “空”のディレクトリから始めなければなりません. ツリーをサポートしてるあなたの CTM を稼働するためには 指定した“空” のデルタを使う必要があります. いくつかの分岐点 では, あなたの都合により CD 内に分配されている“スタータ” デルタを使用できるようになっています. しかしながら, これは 頻繁に行われることではありません. 適切な出発点が決まれば, その出発点を CTM が 維持するツリーへ変換するための “スタータ” 初期デルタを使う必要が あります. 移行デルタは番号の後ろに X をつけたものがそうです (たとえばsrc-cur.3210XEmpty.gz). X の後ろは最初の開始ポイントに対応します. Empty は 空のディレクトリです. ルールとして Empty からの移行デルタは 100 デルタごとに 作られます. ところで, これらは非常に大きいです! XEmptyのデルタは 数十MBの 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 へのオプションを整理する. さもないと混乱し, 直観に反したものになります. その他 - “DESに染まった” (例えば, - 国外への持ち出しが規制された)ソースはまったく含まれません. - 手に入るのは“国際”バージョンだけです. - もし興味のある人が多いようであれば, - 我々はsec-curシーケンスも - セットアップするつもりです. ports - コレクションに対するデルタのシーケンスもあります. しかし, - まだあまり興味は持たれていないようです. - もしこれに対するメーリング - リストが欲しい時も私に言ってください. - 我々はセットアップすることを考えます. + ports コレクションに対するデルタもあるのですが, + これに興味を持っている人はまだ少ないようです. + もしこれに対するメーリングリストが欲しい時はセットアップを行ないますので, + わたしの方まで連絡ください. CTM サイト CTM/FreeBSD は以下のミラーサイトから anonymous FTP によって入手できます. もし CTM を anonymous FTP によって手にいれる場合は, 近くのサイトを利用するようにしてください. 何か問題がある場合は, &a.phk;に連絡してください. カリフォルニア, サンフランシスコ近辺, 公式なソース ftp://ftp.FreeBSD.org/pub/FreeBSD/CTM/ ドイツ, トリエル ftp://ftp.uni-trier.de/pub/unix/systems/BSD/FreeBSD/CTM/ 南アフリカ, ctm, sup, CVSupなどの古い差分ファイルのバックアップサーバ - ftp://ftp.internat.FreeBSD.org/pub/FreeBSD/CTM/ + ftp://ftp.za.FreeBSD.org/pub/FreeBSD/CTM/ 台湾/中華民国, チャーイー(嘉義) ftp://ctm.tw.FreeBSD.org/pub/freebsd/CTM/ ftp://ctm2.tw.FreeBSD.org/pub/FreeBSD/CTM/ ftp://ctm3.tw.FreeBSD.org/pub/freebsd/CTM/ 近くにミラーサイトがない場合やミラーが不完全な場合は, http://ftpsearch.ntnu.no/ftpsearch の FTP search を試してください. FTP search はノルウェーの Trondheim にある, フリーの素晴らしい アーカイブサーバです. - + CVSup を使う 訳: &a.jp.iwasaki;, 1997 年 2 月 27 日. 紹介 CVSup は, リモートのサーバホストにあるマスタ CVS リポジトリから ソースツリーを配布し更新するための ソフトウェアパッケージです. FreeBSD のソースは, カリフォルニアにある中心的な開発マシンの CVS リポジトリの 中でメンテナンスしています. CVSup を使用することで, FreeBSD ユーザは 簡単に自分のソースツリーを最新の状態に しておくことができます. CVSup は pull モデルとよばれる更新のモデルを採用しています. pull モデルでは, 各クライアントが更新したい場合に更新したい時点で, サーバに更新の問い合わせをおこないます. サーバはクライアントからの 更新の要求を受け身の状態で待ちます. したがって, すべての更新はクライアント主導でおこなわれます. サーバは頼まれもしない更新情報を送るようなことはしません. ユーザは CVSup クライアントを手動で実行して更新をおこなうか, cron ジョブを設定して定期的に自動実行する必要があります. 用語 CVSup のように大文字で表記しているものは, ソフトウェアパッケージ 全体を指します. 主な構成物は, 各ユーザマシンで実行するクライアントである cvsup, FreeBSD の各ミラーサイトで実行するサーバ cvsupd です. FreeBSD の文書やメーリングリストを読んだ際に, sup についての言及を 見かけたかもしれません. sup は CVSup の前に存在していたもので, 同様の目的で使われていました. CVSup は sup と同じように使用されており, 実際, sup と互換性のあるコンフィグレーションファイルを使用します. CVSup の方がより高速で柔軟性もあるので, もはや sup は FreeBSD プロジェクトでは使用されていません. インストール CVSup をインストールする 最も簡単な方法は, FreeBSD ports コレクション の net/cvsup-bin をインストールすることです. もしくは, net/cvsup でも構いません. ただし, net/cvsup は Modula-3 システムに依存していて, 構築にかかる時間, メモリ, ディスクスペースは比較的大きくなります. もし, あなたに cvsup に関して全く知識がなく, 自動で設定ファイルをセットアップして, クリックするだけで転送を行なえるインターフェイスを提供してくれるような, 単一のパッケージをインストールしたいと考えているなら, cvsupit パッケージを利用して下さい. これは &man.pkg.add.1; するだけで良く, 設定は, その際にメニュー形式で行なうことができるようになっています. 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 の途中からデフォルト値の変更や追加が可能になります. これまでの予備知識を基に, FreeBSD-current のメインのソースツリーを受け取って更新するための supfile を組み立ててみましょう. どのファイルを受け取りたいのか? CVSup を通して入手できるファイルは コレクション と呼ばれる名前の付けられたグループにまとめられています. 利用可能なコレクションについては ここ で説明しています. ここでは, FreeBSD システムのメインのソースツリー全体 を受け取るための設定例を紹介します. - 輸出規制されている暗号化サポートの - コード以外のすべてを含む src-all - という単一の大きなコレクションがあります. - この例では私たちがアメリカ合衆国か - カナダにいるものと仮定します. その場合, - cvs-crypto という一つの付化的な - コレクションで暗号化コードを入手することができます. + すべてを含む src-all + という単一の大きなコレクションがあります. supfile を組み立てる最初のステップとして, - これらのコレクションを一行に一つづつ記述します: + これらのコレクションを一行に一つずつ記述します + (この場合は一行だけです). -src-all -cvs-crypto +src-all どのバージョンのものが欲しいのか? CVSup を使用すると, かつて存在していたことのある, 事実上どのバージョンの ソースでも受け取ることができます. これは cvsupd サーバがすべてのバージョンを含む CVS リポジトリに基づいて動作することにより, 実現されています. tag= および の value フィールドを使用して, 欲しいバージョンの 一つを指定します. tag= のフィールドの指定は正確に行うように十分注意 してください. いくつかのタグは特定のコレクションに 対してのみ有効です. タグの綴りが違っていたり不適切なタグを指定すると, CVSupはユーザが消し たくないファイルまで削除してしまいます. 特に ports-* のコレクション に対しては tag=. だけ を指定するようにしてください. tag= フィールドはリポジトリ中のシンボリックタグを指定します. tag には revision tag と branch tag の二種類があります. revision tag は特定のリビジョンを指します. これは, 毎日同じ状態に保つことになります. 一方 branch tag は, ある時点での開発分流の最新のリビジョンを指します. branch tag は特定のリビジョンを指定している訳ではないので, 今日と明日では 異なるリビジョンを参照することになるかもしれません. 以下はユーザが興味を持っていると思われる branch tag です. tag=. だけが ports コレクションには 適切であることに注意してください. tag=. メインの開発分流であり, FreeBSD-CURRENT として知られています. 注意: . は句読点ではありません. tag の名称です. このタグの指定は総ての コレクションに対して有効です. tag=RELENG_4 FreeBSD-4.X 用の開発分流であり, FreeBSD-STABLE として知られています. tag=RELENG_3 FreeBSD-3.X 用の開発分流です. tag=RELENG_2_2 FreeBSD-2.2.X 用の開発分流であり, 2.2-STABLE として知られています. 以下はユーザが興味を持っていると思われる revision tag です. 以下は ports コレクションには不適切であることに 再度注意してください. tag=RELENG_4_0_0_RELEASE FreeBSD-4.0. tag=RELENG_3_4_0_RELEASE FreeBSD-3.4. tag=RELENG_3_3_0_RELEASE FreeBSD-3.3. tag=RELENG_3_2_0_RELEASE FreeBSD-3.2. tag=RELENG_3_1_0_RELEASE FreeBSD-3.1. tag=RELENG_3_0_0_RELEASE FreeBSD-3.0. tag=RELENG_2_2_8_RELEASE FreeBSD-2.2.8. tag=RELENG_2_2_7_RELEASE FreeBSD-2.2.7. tag=RELENG_2_2_6_RELEASE FreeBSD-2.2.6. tag=RELENG_2_2_5_RELEASE FreeBSD-2.2.5. tag=RELENG_2_2_2_RELEASE FreeBSD-2.2.2. tag=RELENG_2_2_1_RELEASE FreeBSD-2.2.1. tag=RELENG_2_2_0_RELEASE FreeBSD-2.2.0. tag 名を示した通りにタイプされているか十分注意してく ださい. CVSup は tag 名が正しいかどうかを見分けることはできません. tag が間違っていた場合, たまたまファイルがまったく存在しない正しい tag が 指定されたものとしてCVSup は動作します. その場合は, 現在あるソースが削 除されるでしょう. branch tag を指定した際には, 通常はその開発分流の最新バージョンの ファイルを受け取ります. いくらか前のバージョンを受け取りたい場合は, の value フィールドを使って日付を指定することで, これを実現することが できます. &man.cvsup.1; のマニュアルページで, その方法を説明しています. 例として, FreeBSD-current を受け取りたいとします. 次の行を supfile の始めに追加します: *default tag=. tag= フィールドも date= フィールドも指定しなかった場合に 動き出す重要な特殊なケースがあります. そのケースでは, 特定のバージョンの ファイルを受け取るのではなく, サーバの CVS リポジトリから実際の RCS ファイルを直接受け取ります. 一般的に開発者はこの処理のモードが 好きなようです. 彼らのシステム上にリポジトリそのものの コピーを維持することで, リビジョン履歴を閲覧し過去のバージョンの ファイルを検査できるようになります. しかし, これには大きなディスクスペースが必要になります. どこから入手したいのか? 更新情報をどこから入手するかを cvsup に伝えるために host= フィールドを使用します. CVSup ミラーサイト のどこからでも入手できますが, ネット上での最寄りのサイトを選ぶべきでしょう. この例では, 仮想上の FreeBSD 配布サイト cvsup666.FreeBSD.org を使用します: *default host=cvsup666.FreeBSD.org CVSup を実行する前にホスト名を 実在のものに変更する必要があります. どのように cvsup を実行しても, この設定は を 使用してコマンドラインで変更することができます. 自分のマシンのどこに置きたいのか? prefix= フィールドは, cvsup に受け取ったファイルをどこに置くかを 伝えます. この例では, ソースファイルを直接メインのソースツリー /usr/src に置きます. src ディレクトリはすでにファイルを受け取るために 選択したコレクションで暗黙に指定しているので, これは正しい仕様となります: *default prefix=/usr どこに status ファイルを置きたいのか? cvsup クライアントは base ディレクトリと呼ばれる場所に, ある status ファイルを維持しています. すでに受け取った更新情報を追従し続けることで, これらのファイルは CVSup がより効果的に動作することを支援します. 標準の base ディレクトリ /usr/local/etc/cvsup を使用します: *default base=/usr/local/etc/cvsup supfile に指定がない場合は, この設定をデフォルトで使用しますので, 実際には上の行は必要ありません. base ディレクトリが存在しない場合は作成しておきましょう. base ディレクトリが存在しない場合, cvsup クライアントは実行を拒否します. その他もろもろの supfile の設定: 通常 supfile に入れておくべき行がもう一つあります: *default release=cvs delete use-rel-suffix compress release=cvs は, サーバがメインの FreeBSD CVS リポジトリから その情報を取得するように指示します. ほとんどの場合はこのようにしておきますが, ここでの説明の範疇をこえるような 状況では他の指定をすることも可能です. delete は CVSup にファイルを削除することを許可します. CVSup が ソースツリーを完全に最新の状態に 保てるようにするためには, これは常に 指定しておくべきでしょう. CVSup は, これらの責任範囲のファイルだけを 慎重に削除します. たまたま存在する他の余分なファイルについては, まったく手をつけずに残しておきます. use-rel-suffix は ... 神秘的なものです. これについて本当に知りたい人は, &man.cvsup.1; のマニュアルページをご覧ください. でなければ, 何も考えずに指定してみてください. compress は通信チャネルで gzip 形式の圧縮の使用を有効にします. ご使用のネットワーク接続が T1 speed 以上である場合, この圧縮を使用しない方がよいかもしれません. そうでない場合は十分に役に立ちます. supfile の例のまとめ: 以下は supfile の例の全体です: *default tag=. *default host=cvsup666.FreeBSD.org *default prefix=/usr *default base=/usr/local/etc/cvsup *default release=cvs delete use-rel-suffix compress -src-all -cvs-crypto +src-all 拒否ファイル(refuse file) 既に述べたように, CVSup は取り寄せ法(pull method)を用いるのですが, これは基本的に次のようなことを意味します. まずあなたが CVSup サーバに接続します. するとサーバは あなたがダウンロードできるのはこれこれですと言います. それに対し, あなたが使っているクライアントは わかりました. では, これとこれとこれをもらいますと答えます. デフォルトの設定の CVSup クライアントは, 設定ファイルで選んだコレクションとタグに適合する すべてのファイルを取得します. しかし, これは常にあなたの望む動作と一致するとは限りません. 特に doc や ports や www のツリーを同期させる場合などはそうでしょう. ほとんどの人は四か国語も五か国語も操れるわけではありませんから, 特定の言語のファイルのダウンロードは必要ないでしょう. Ports コレクションを CVSup で取得する場合には, 各コレクションを個別に指定することができます (たとえば, 単に ports-all とするかわりに ports-astrology, ports-biology などと書きます). 一方, doc と www のツリーは言語別のコレクションになっていません. そこであなたは CVSup のたくさんある洗練された機能の一つ, 拒否ファイル(refuse file) 機能を使う必要があります. 拒否ファイル(refuse file) は CVSup に対し, コレクションに含まれる一部のファイルを取得することを伝えます. 言い換えれば, それはクライアントに対し, サーバから来る一部のファイルを拒否するよう指定するということです. 拒否ファイルは base/sup/refuse にあります(もしファイルがない場合には作成してください). base は supfile 内で定義されています. デフォルトでは /usr/sup です. つまり, 拒否ファイルのデフォルトは /usr/sup/refuse ということになります. 拒否ファイルの書式は, 単にダウンロードしたくないファイルや ディレクトリの名前が書いてあるだけの非常にシンプルなものです. たとえば, 私は英語以外はドイツ語を少し話せるだけで, しかもドイツ語のアプリケーションの必要を感じないので 拒否ファイルは以下のように書いています. ports/chinese ports/german ports/japanese ports/korean ports/russian ports/vietnamese doc/es_ES.ISO_8859-1 doc/ja_JP.eucJP 他の言語についても同様です. 拒否ファイルの中ではリポジトリの名前が ディレクトリの先頭部分に対応することに注意してください. この実に便利な機能を使うと まったく必要としないファイルをダウンロードする必要がなくなり, インターネット接続の回線が遅かったり従量制で課金されている人は 貴重な時間を節約できるようになります. 拒否ファイルの詳細や 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-crypto, - そして ports-all です. + src-all, + ports-all です. 他のコレクションは特別な目的を持つ人達だけが使用しており, ミラーサイトはそれらのすべてを 持っていないかもしれません. cvs-all release=cvs メインの FreeBSD CVS リポジトリであり, - 輸出規制された暗号化コードは含まれていません. + 暗号のコードを含んでいます. distrib release=cvs FreeBSD の配布とミラーに関連するファイルです. doc-all release=cvs FreeBSD ハンドブックおよびその他のドキュメントの ソースです. ports-all release=cvs FreeBSD の ports コレクションです. ports-archivers release=cvs アーカイビングのツール. ports-astro release=cvs 天文学関連の ports. ports-audio release=cvs サウンドサポート. ports-base release=cvs /usr/ports のトップにあるその他のファイル. ports-benchmarks release=cvs ベンチマークプログラム. ports-biology release=cvs 植物学関連のプログラム. ports-cad release=cvs CAD ツール. ports-chinese release=cvs 中国語サポート. ports-comms release=cvs 通信ソフトウェア. ports-converters release=cvs 文字コードコンバータ. ports-databases release=cvs データベース. ports-deskutils release=cvs コンピュータが発明される前に 卓上で使われていたものたち. ports-devel release=cvs 開発ユーティリティ. ports-editors release=cvs エディタ. ports-emulators release=cvs 他の OS のエミュレータ. ports-ftp release=cvs FTP クライアントとサーバ. ports-games release=cvs ゲーム. ports-german release=cvs ドイツ語サポート. ports-graphics release=cvs グラフィックユーティリティ. ports-irc release=cvs インターネットリレーチャット(IRC)用のユーティリティ ports-japanese release=cvs 日本語サポート. ports-java release=cvs Java ユーティリティ ports-korean release=cvs 韓国語サポート. ports-lang release=cvs プログラミング言語. ports-mail release=cvs メールソフトウェア. ports-math release=cvs 数値計算ソフトウェア. ports-mbone release=cvs MBone アプリケーション. ports-misc release=cvs 色々なユーティリティ. ports-net release=cvs ネットワーキングソフトウェア. ports-news release=cvs USENET ニュースのソフトウェア. ports-palm release=cvs 3Com Palm(tm) シリーズ用ソフトウェア. ports-print release=cvs 印刷ソフトウェア. ports-russian release=cvs ロシア語サポート. ports-security release=cvs セキュリティユーティリティ. ports-shells release=cvs コマンドラインシェル. ports-sysutils release=cvs システムユーティリティ. ports-textproc release=cvs 文書処理ユーティリティ (デスクトップパブリッシングは含まない). ports-vietnamese release=cvs ベトナム語サポート. ports-www release=cvs World Wide Web 関連のソフトウェア. ports-x11 release=cvs X window システムをサポートする ports. ports-x11-clocks release=cvs X11 上で動作する時計の数々. ports-x11-fm release=cvs X11 上で動作するファイラ. ports-x11-fonts release=cvs X11 のフォントとフォントユーティリティ. ports-x11-toolkits release=cvs X11 のツールキット. ports-x11-servers 各種 X11 サーバ ports-x11-wm release=cvs X11 のウィンドウマネージャ. src-all release=cvs メインの FreeBSD ソース群であり, - 輸出規制された暗号化コードは - 含まれていません. + 暗号のコードを含んでいます. src-base release=cvs /usr/src のトップにあるその他のファイル. src-bin release=cvs シングルユーザモードで必要な ユーザユーティリティ (/usr/src/bin). src-contrib release=cvs FreeBSD プロジェクト外部からの ユーティリティおよびライブラリ, 比較的無修正 (/usr/src/contrib). + + src-crypto release=cvs + + + FreeBSD プロジェクトの外部で開発された暗号ユーティリティとライブラリ. + ほとんどそのままの形で使われます. + (/usr/src/crypto). + + + + + src-eBones release=cvs + + + Kerberos と DES + (/usr/src/eBones). + 現在の FreeBSD リリースでは使われていません. + + + 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 FreeBSD の release を構築するために必要なファイル (/usr/src/release). + + src-secure release=cvs + + + DES (/usr/src/secure). + + + src-sbin release=cvs シングルユーザモード用の システムユーティリティ (/usr/src/sbin). 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 FreeBSD の保守用の色々なツール (/usr/src/tools). src-usrbin release=cvs ユーザユーティリティ (/usr/src/usr.bin). src-usrsbin release=cvs システムユーティリティ (/usr/src/usr.sbin). www release=cvs World Wide Web のデータ用のソースです. - cvs-crypto release=cvs - - 輸出規制された暗号化コードです. - - - - src-crypto release=cvs - - - 輸出規制された FreeBSD - プロジェクト外部からのユーティリティおよび - ライブラリ, 比較的無修正 - (/usr/src/crypto). - - - - - src-eBones release=cvs - - - Kerberos および DES - (/usr/src/eBones). - FreeBSD の現在のリリースでは使われていません. - - - - - src-secure release=cvs - - - DES (/usr/src/secure). - - - - - src-sys-crypto release=cvs - - - カーネルの暗号化コード - (/usr/src/sys/crypto). - - - - - - distrib release=self CVSup サーバ自身のコンフィグレーションファイルです. CVSup ミラーサイトが使用します. gnats release=current GNATS バグトラッキングデータベースです. mail-archive release=current FreeBSD 関連メーリングリストのアーカイブ. www release=current インストールされた World Wide Web のデータです. WWW ミラーサイトが使用します. 詳細について CVSup の FAQ や CVSup に関するその他の情報については The CVSup Home Page をご覧ください. CVSup のほとんどの FreeBSD 関連の議論は &a.hackers; でおこなわれています. ソフトウェアの新しいバージョンは &a.announce; で アナウンスされます. 質問とバグ報告はプログラムの作者, cvsup-bugs@polstra.com へ 送ってください. - + CVSup サイト FreeBSD の CVSup サーバは以下のサイトで稼働しています: アルゼンチン cvsup.ar.FreeBSD.org (保守担当 msagre@cactus.fi.uba.ar) オーストラリア cvsup.au.FreeBSD.org (保守担当 dawes@xfree86.org) cvsup3.au.FreeBSD.org (保守担当 FreeBSD@admin.gil.com.au) オーストリア cvsup.at.FreeBSD.org (保守担当 postmaster@wu-wien.ac.at) ブラジル cvsup.br.FreeBSD.org (保守担当 cvsup@cvsup.br.FreeBSD.org) cvsup2.br.FreeBSD.org (保守担当 tps@ti.sk) cvsup3.br.FreeBSD.org (保守担当 camposr@matrix.com.br) カナダ cvsup.ca.FreeBSD.org (保守担当 dan@jaded.net) 中国 cvsup.cn.FreeBSD.org (保守担当 phj@cn.FreeBSD.org) チェコ cvsup.cz.FreeBSD.org (保守担当 cejkar@dcse.fee.vutbr.cz) デンマーク cvsup.dk.FreeBSD.org (保守担当 jesper@skriver.dk) エストニア cvsup.ee.FreeBSD.org (保守担当 taavi@uninet.ee) フィンランド cvsup.fi.FreeBSD.org (保守担当 count@key.sms.fi) cvsup2.fi.FreeBSD.org (保守担当 count@key.sms.fi) フランス cvsup.fr.FreeBSD.org (保守担当 hostmaster@fr.FreeBSD.org) ドイツ cvsup.de.FreeBSD.org (保守担当 wosch@FreeBSD.org) cvsup2.de.FreeBSD.org (保守担当 petzi@FreeBSD.org) cvsup3.de.FreeBSD.org (保守担当 ag@leo.org) アイスランド cvsup.is.FreeBSD.org (保守担当 adam@veda.is) 日本 cvsup.jp.FreeBSD.org (保守担当 cvsupadm@jp.FreeBSD.org) cvsup2.jp.FreeBSD.org (保守担当 max@FreeBSD.org) cvsup3.jp.FreeBSD.org (保守担当 shige@cin.nihon-u.ac.jp) cvsup4.jp.FreeBSD.org (保守担当 cvsup-admin@ftp.media.kyoto-u.ac.jp) cvsup5.jp.FreeBSD.org (保守担当 cvsup@imasy.or.jp) cvsup6.jp.FreeBSD.org (保守担当 cvsupadm@jp.FreeBSD.org) 韓国 cvsup.kr.FreeBSD.org (保守担当 cjh@kr.FreeBSD.org) cvsup2.kr.FreeBSD.org (保守担当 holywar@mail.holywar.net) オランダ cvsup.nl.FreeBSD.org (保守担当 xaa@xaa.iae.nl) cvsup2.nl.FreeBSD.org (保守担当 cvsup@nl.uu.net) ノルウェー cvsup.no.FreeBSD.org (保守担当 Per.Hove@math.ntnu.no) ポーランド cvsup.pl.FreeBSD.org (保守担当 Mariusz@kam.pl) ポルトガル cvsup.pt.FreeBSD.org (保守担当 jpedras@webvolution.net) ロシア cvsup.ru.FreeBSD.org (保守担当 ache@nagual.pp.ru) cvsup2.ru.FreeBSD.org (保守担当 dv@dv.ru) cvsup3.ru.FreeBSD.org (保守担当 fjoe@iclub.nsu.ru) スロヴァキア共和国 cvsup.sk.FreeBSD.org (保守担当 tps@tps.sk) cvsup2.sk.FreeBSD.org (保守担当 tps@tps.sk) スロベニア cvsup.si.FreeBSD.org (保守担当 blaz@si.FreeBSD.org) 南アフリカ cvsup.za.FreeBSD.org (保守担当 markm@FreeBSD.org) cvsup2.za.FreeBSD.org (保守担当 markm@FreeBSD.org) スペイン cvsup.es.FreeBSD.org (保守担当 jesusr@FreeBSD.org) スウェーデン cvsup.se.FreeBSD.org (保守担当 pantzer@ludd.luth.se) 台湾 cvsup.tw.FreeBSD.org (保守担当 jdli@freebsd.csie.nctu.edu.tw) cvsup2.tw.FreeBSD.org (保守担当 ycheng@sinica.edu.tw) cvsup3.tw.FreeBSD.org (保守担当 foxfair@FreeBSD.org) ウクライナ cvsup2.ua.FreeBSD.org (保守担当 freebsd-mnt@lucky.net) cvsup3.ua.FreeBSD.org (保守担当 ftpmaster@ukr.net), キエフ cvsup4.ua.FreeBSD.org (保守担当 phantom@cris.net) イギリス cvsup.uk.FreeBSD.org (保守担当 joe@pavilion.net) cvsup2.uk.FreeBSD.org (保守担当 brian@FreeBSD.org) cvsup3.uk.FreeBSD.org (保守担当 ftp-admin@plig.net) アメリカ cvsup1.FreeBSD.org (保守担当 skynyrd@opus.cts.cwu.edu), ワシントン州 cvsup2.FreeBSD.org (保守担当 jdp@FreeBSD.org), カリフォルニア州 cvsup3.FreeBSD.org (保守担当 wollman@FreeBSD.org), マサチューセッツ州 cvsup4.FreeBSD.org (保守担当 rgrimes@FreeBSD.org), オレゴン州 cvsup5.FreeBSD.org (保守担当 mjr@blackened.com), アリゾナ州 cvsup6.FreeBSD.org (保守担当 jdp@FreeBSD.org), フロリダ州 cvsup7.FreeBSD.org (保守担当 jdp@FreeBSD.org), ワシントン州 cvsup8.FreeBSD.org (保守担当 hostmaster@bigmirror.com), ワシントン州 - FreeBSD の輸出規制されたコード (eBones と secure) は - CVSup 経由で以下 - の国際的なリポジトリから入手できます. - アメリカ合衆国やカナダ以外に居る 場合は, - このサイトを使って輸出規制されたコードを入手してください. - - - - 南アフリカ - - - - - cvsup.internat.FreeBSD.org - (保守担当 markm@FreeBSD.org) - - - - - - - このサイトがいつアクセスしても反応が悪いときは, - 以下のミラーサイトを輸出規制されたコードの取得に - 使うことができます. - - - - デンマーク - - - - - cvsup.dk.FreeBSD.org - (保守担当 jesper@skriver.dk) - - - - - - - ドイツ - - - - - cvsup.de.FreeBSD.org - (保守担当 wosch@FreeBSD.org) - - - - cvsup3.de.FreeBSD.org - (保守担当 ag@leo.org) - - - - - - - イギリス - - - - - cvsup.uk.FreeBSD.org - (保守担当 joe@pavilion.net) - - - - cvsup2.uk.FreeBSD.org - (保守担当 brian@FreeBSD.org) - - - - cvsup3.uk.FreeBSD.org - (保守担当 ftp-admin@plig.net) - - - - - - 以下の CVSup サイトは, CTM ユーザのことを特に考慮して運用されています. 他の CVSup のミラーサイトとは異なり, これらのサイトでは CTM を使って最新の状態を保っています. つまり, もし以下の サイトから cvs-all を release=cvs で CVSup すれば, CTM の cvs-cur のデルタを使って更新するのに適した CVS のリポジトリ (必須となる .ctm_status ファイルも含まれています.) を入手することができます. これにより, これまで CVSup を使って cvs-all 全部を入手していたユーザも CTM のベースデルタを使って 最初からリポジトリを構築し直すことなく CVSup から CTM へと移行すること が可能です. この機能は, リリースタグを cvs として cvs-all ディストリビューションを入手する時のみ 利用できるものですので注意してください. 他のディストリビューションやリリースタグを 指定した場合でも指定したファイルを入手することは可能ですが, これらのファイルを CTM で更新することはできません. また, CTM の現在のバージョンではタイムスタンプを保存しないため, 以 下のサイトのファイルのタイムスタンプは 他のミラーとは異なる物となってい ますので注意が必要です. 利用するサイトを以下のサイトと他のサイトの間で 変更することはお勧めできません. ファイルの転送は問題なくできますが, 少々非能率的です. ドイツ ctm.FreeBSD.org (保守担当 blank@fox.uni-trier.de) AFS サイト FreeBSD の AFS サーバは以下のサイトで稼働しています: スウェーデン ファイルは以下の場所にあります: /afs/stacken.kth.se/ftp/pub/FreeBSD/ stacken.kth.se # Stacken Computer Club, KTH, Sweden 130.237.234.43 #hot.stacken.kth.se 130.237.237.230 #fishburger.stacken.kth.se 130.237.234.3 #milko.stacken.kth.se (保守担当 ftp@stacken.kth.se) diff --git a/ja_JP.eucJP/books/handbook/users/chapter.sgml b/ja_JP.eucJP/books/handbook/users/chapter.sgml index 34db38e0ad..21adc390f8 100644 --- a/ja_JP.eucJP/books/handbook/users/chapter.sgml +++ b/ja_JP.eucJP/books/handbook/users/chapter.sgml @@ -1,507 +1,507 @@ ユーザと基本的なアカウントの管理 概要 寄稿: &a.nbm;, 2000 年 2 月. システムへアクセスするには, かならずユーザアカウントが使われます. また, プロセスもすべてユーザによって実行されますので, ユーザとアカウントの管理は FreeBSD システムにおいて欠かすことのできない重要なものです. アカウントには大きく分けて三種類のものがあります. それは, スーパーユーザ(Superuser), システムユーザ(system users), そしてユーザアカウント(user accounts)です. スーパーユーザのアカウントは通常 root と呼ばれ, 無制限の特権を持つためにシステムの管理に用いられます. また, システムユーザはサービスの運用に用いられ, 最後のユーザアカウントは, 実際にログインしてメールを読むといった作業を行なう利用者のためのものです. スーパーユーザアカウント スーパーユーザアカウントは通常 root と呼ばれ, 初期時から設定済みです. このアカウントはシステム管理を行なうためのもので, メールのやりとり, システムの調査, プログラミングといった日常的な作業を行なうために使われるべきものではありません. その理由は, スーパーユーザが通常のユーザアカウントと異なり, 操作にまったく制限を受けないことによります. そのためスーパーユーザアカウントで操作を間違えると, システムに重大な影響を与えてしまう恐れがあるのです. ユーザアカウントでは, 仮に操作を間違えてもシステムを壊してしまうようなことは できないようになっています. したがって特権を必要としていないのであれば, できるだけいつもユーザアカウントを利用する方が望ましいと言えるでしょう. また, スーパーユーザで実行するコマンドはいつでも, 二回, 三回と何度もコマンドをチェックしてください. なぜならスペースが多かったり, 文字が欠けていたりするだけで, 取り返しのつかないデータの破壊につながる可能性があるからです. スーパーユーザになると得られる特権は, 言い換えてみれば通常のユーザアカウントの保護を受けることができない, ということも意味しています. ですから, この章を読んでからあなたが最初にすべきなのは, もし用意していないなら, 日常的に利用するための あなた自身のユーザアカウントを作成することです. これはマルチユーザモード, シングルユーザモードを問わず, 同様にあてはまります. この章のうしろの方では, アカウントの追加と通常のユーザから スーパーユーザへと移行する手順について扱います. システムアカウント システムユーザとは, DNS, メール, ウェブサーバといった各種サービスを運用するために使われるものです. これはセキュリティを確保するためのもので, サービス自体はスーパーユーザで実行される場合と同様, 制限を受けません. システムユーザの具体例として, daemon, operator, bind (DNS; Domain Name Service 用) および news といったものがあります. またシステム管理者はよく, インストールしたウェブサーバを運用するために httpd というユーザを作成しています. nobody ユーザは通常の特権を持たないシステムユーザですが, nobody を利用するサービスが増えれば増えるほど, その特権も大きくなります. ユーザアカウント ユーザアカウントは, 主に現実のユーザがシステムにアクセスする手段として用いられるものです. このアカウントは利用するユーザとシステム環境を分離します. そのため, システムや他のユーザに危害をおよぼす危険性をなくし, また, 他に影響を与えることなくユーザ自身の環境をカスタマイズすることを可能にしています. システムにアクセスするすべてのユーザは, それぞれに一人一つのユーザアカウントを持つべきです. こうすることで誰が何を行なっているかがわかりますし, 他の人の設定を壊してしまったり, 他人にメールを読まれてしまうようなことを避けることができます. それぞれのユーザは快適にシステムを利用するため, シェル, エディタ, キー設定, 言語など, 各自の環境をセットアップすることができます. アカウント情報の変更 強力で柔軟性に富むアカウント情報の変更手段として, pw があります. しかし, 新しいアカウントをつくる場合は adduser を, アカウントを削除する場合は rmuser を使うことが推奨されています. chpass を使うことで, システム管理者, 通常のユーザはパスワード, シェル, その他の個人情報を変更することができます. また, 特にパスワードを変更する場合には, 通常 passwd の方が良く使われます. adduser adduser は, 新しいユーザを登録するためのシンプルなプログラムです. このプログラムは passwd と group に新しいユーザのエントリを作成するのと同時に, ホームディレクトリを作成して /usr/share/skel からデフォルトで使用されるドットファイル(訳注: ホームディレクトリに存在する . から始まるファイルのことで, 各種設定に用いられます)をコピーします. また, 新しく作成されたユーザに対して, ウェルカムメッセージをメールで送信することも可能です. 初期設定ファイルを作成するには, adduser -s -config_create. とします オプション をつけると, デフォルトで詳細を表示しないように adduser を設定します. この後に詳細を表示させるようにしたい場合は, オプション を指定してください. . そして次に adduser のデフォルト設定を行ない, 最初のユーザアカウントを作成します. システムを日常利用する際に root を用いるのは最悪です. adduser の設定の変更 &prompt.root; adduser -v Use option ``-silent'' if you don't want to see all warnings and questions. Check /etc/shells Check /etc/master.passwd Check /etc/group Enter your default shell: csh date no sh tcsh [sh]: tcsh Your default shell is: tcsh -> /usr/local/bin/tcsh Enter your default HOME partition: [/home]: Copy dotfiles from: /usr/share/skel no [/usr/share/skel]: Send message from file: /etc/adduser.message no [/etc/adduser.message]: no Do not send message Use passwords (y/n) [y]: y Write your changes to /etc/adduser.conf? (y/n) [n]: y Ok, let's go. Don't worry about mistakes. I will give you the chance later to correct any input. Enter username [a-z0-9_-]: jru Enter full name []: J. Random User Enter shell csh date no sh tcsh [tcsh]: Enter home directory (full path) [/home/jru]: Uid [1001]: Enter login class: default []: Login group jru [jru]: Login group is ``jru''. Invite jru into other groups: guest no [no]: wheel Enter password []: Enter password again []: Name: jru Password: **** Fullname: J. Random User Uid: 1007 Gid: 1007 (jru) Class: Groups: jru wheel HOME: /home/jru Shell: /usr/local/bin/tcsh OK? (y/n) [y]: y Added user ``jru'' Copy files from /usr/share/skel to /home/jru Add another user? (y/n) [y]: n Goodbye! &prompt.root; 簡単に上の操作を説明します. まずデフォルトシェルを tcsh (packages にある追加のシェルです) に変更し, 新しいユーザにウェルカムメッセージのメールを送付しないようにしました. そしてその設定を保存し, wheel グループ(後に, これが重要な意味を持っていることがわかるでしょう)に所属する jru というアカウントを作成しています. 入力したパスワードは画面に表示されません. アスタリスク記号も表示されませんので, パスワードを二回とも間違えて入力してしまわないように注意してください. :-) これ以降はオプション引数をつけず単に adduser を起動します. デフォルト設定を変更する必要はありません. もし, adduser がデフォルト設定を変更するかどうか尋ねてきたら, adduser を終了し, オプションを使うようにしてください. rmuser rmuser は, システムからユーザを削除します. これにはユーザデータベースからの削除だけでなく, その他, そのユーザに依存する情報すべてが含まれます. rmuser は次の手順を実行します. 指定されたユーザの &man.crontab.1; エントリを削除 (存在する場合). 指定されたユーザの &man.at.1; ジョブをすべて削除. 指定されたユーザが所有するすべてのプロセスを強制終了. ローカルパスワードファイルから, 指定されたユーザのエントリを削除. 指定されたユーザのホームディレクトリを削除 (ディレクトリの所有者が指定されたユーザのものだった場合). /var/mail から, 指定されたユーザの到着メールファイルを削除. /tmp のような一時ファイル保存領域から, 指定されたユーザの所有するファイルを削除. そして最後に, /etc/group にある すべてのグループから, 指定されたユーザを削除します. 指定されたユーザと同じ名前のグループで, そのユーザが削除されると空のグループとなる場合は, そのグループ自体が削除されます. これは &man.adduser.8; によってユーザごとに作成される, ユニークなグループに対応するものです. スーパユーザアカウントの削除に rmuser を利用することはできません. スーパユーザアカウントの削除はほとんどすべての場合, 大規模なシステムの破壊を意味するからです. デフォルトでは, どういう操作を行なっているか確認できる対話モードが使われます. rmuser による対話的なアカウントの削除 &prompt.root; rmuser jru Matching password entry: jru:*:1000:1000::0:0:J. Random User:/home/jru:/usr/local/bin/tcsh Is this the entry you wish to remove? y Remove user's home directory (/home/jru)? y Updating password file, updating databases, done. Updating group file: trusted (removing group jru -- personal group is empty) done. Removing user's incoming mail file /var/mail/jru: done. Removing files belonging to jru from /tmp: done. Removing files belonging to jru from /var/tmp: done. Removing files belonging to jru from /var/tmp/vi.recover: done. &prompt.root; pw pw は, ユーザやグループの作成, 削除, 変更および表示を行なうことができ, システムユーザファイルやシステムグループファイルの編集機能を持った コマンドラインのユーティリティです. これはシェルスクリプトからの利用や, 直接コマンドを実行する際に便利に使えるように設計されたものです. 詳細はすべて &man.pw.8; に書かれています. chpass chpass は, パスワード, シェル, その他の個人情報といった, ユーザデータベース情報を変更します. システム管理者に限りスーパユーザ権限で chpass を用い, 他のユーザの情報やパスワードを変更することが可能です. ユーザ名の他にオプションを指定しないと, chpass はユーザ情報を編集するエディタを表示します. そのエディタを終了すると, chpass はユーザデータベース情報の変更を試みます. スーパユーザによる対話的な chpass #Changing user database information for jru. Login: jru Password: * Uid [#]: 1000 Gid [# or name]: 1000 Change [month day year]: Expire [month day year]: Class: Home directory: /home/jru Shell: /usr/local/bin/tcsh Full Name: J. Random User Office Location: Office Phone: Home Phone: Other information: 通常のユーザは, この情報の限られた部分のみ変更が可能です. また, 変更できるのはそのユーザ自身の情報のみです. 通常のユーザによる対話的な chpass #Changing user database information for jru. Shell: /usr/local/bin/tcsh Full Name: J. Random User Office Location: Office Phone: Home Phone: Other information: chfn, chsh はいずれも, 単に chpass へのハードリンクになっています. また, ypchpass, ypchfn および ypchsh も同様です. NIS のサポートは自動的に行なわれますので, コマンドの先頭に yp をつける必要はありません. passwd passwd は, ユーザが自分のパスワードを変更する通常の方法です. スーパユーザ権限では, 他のユーザのパスワードを変更するのに使われます. ユーザはパスワードを変更する前に, もともと設定されていたパスワードを入力しなければなりません. これはユーザがコンソールを離れた際に, 不審な人物によってパスワードが変更されることを防ぐためです. passwd &prompt.user; passwd Changing local password for jru. Old password: New password: Retype new password: passwd: updating the database... passwd: done &prompt.root; passwd jru Changing local password for jru. New password: Retype new password: passwd: updating the database... passwd: done yppasswd は, - 単に yppasswd へのハードリンクになっています. + 単に passwd へのハードリンクになっています. NIS のサポートは自動的に行なわれますので, コマンドの先頭に yp をつける必要はありません. ユーザへの制限と設定 quota がシステムで有効化されていると, システム管理者はディスク使用の上限を設定し, ユーザは自身のディスク使用量をチェックできるようになります. quota については, quota の章に書かれています. 地域化(localization)とは, それぞれ異なる言語, キャラクタセット, 日付や時間の標準などに適応させるための環境設定を, システム管理者やユーザが行なうことを指します. 地域化については, 地域化の章に書かれています.