Index: head/ja_JP.eucJP/books/handbook/cutting-edge/chapter.xml =================================================================== --- head/ja_JP.eucJP/books/handbook/cutting-edge/chapter.xml (revision 50680) +++ head/ja_JP.eucJP/books/handbook/cutting-edge/chapter.xml (revision 50681) @@ -1,2350 +1,1696 @@ &os; のアップデートとアップグレード Jim Mock 再構成、再編成および改訂: Jordan Hubbard 原作: Poul-Henning Kamp John Polstra Nik Clayton この章では あるリリースから次のリリースまでの期間にも、 &os; の開発は休みなく続けられています。 最新の開発ツリーと同期することを好む人がいれば、 公式のリリース版を好んで使う方もいるでしょう。 しかしながら、公式のリリースといえども、 セキュリティや他の重要な修正のため、時にはアップデートを行う必要があります。 使用しているバージョンに関わらず、&os; は、 手元のシステムを最新の開発ツリーと同期するために必要なツールをすべて用意しています。 そして、これらのツールを使って、 &os; のバージョンをアップグレードできます。 この章では、開発ブランチを追いかける方法、および、&os; システムをアップデートする基本的なツールについて解説します。 この章を読んで分かるのは: freebsd-update もしくは Subversion を使った &os; システムの更新方法 インストールされているシステムと、変更が行われていない状態との比較方法。 Subversion またはドキュメント用の ports を使って、 インストールされているドキュメントを最新版にアップデートする方法。 2 つの開発ブランチ、&os.stable; と &os.current; の違い ベースシステム全体を再構築しインストールする方法 この章を読む前に、以下の準備をしましょう。 ネットワーク接続の適切な設定 () サードパーティ製のソフトウェアのインストール方法の習得 () この章を通じて、 &os; のソースコードをダウンロードしたりアップデートするのに svn が用いられます。 このコマンドを使うためには、devel/subversion port または package をインストールしておく必要があります。 &os; Update Tom Rhodes 寄稿: Colin Percival ベースとなったノートの提供: Updating and Upgrading freebsd-update updating-upgrading システム管理における重要な側面として、 すみやかにセキュリティパッチを適用し、 オペレーティングシステムを新しいリリースにアップグレードすることがあげられます。 &os; には、これらの処理を行うために freebsd-update と呼ばれるユーティリティが用意されています。 このユーティリティを用いると、&os; のセキュリティおよび eratta アップデートをバイナリによって行うことができます。 手動でパッチもしくは新しいカーネルをコンパイルし、 インストールする必要はありません。 バイナリアップデートは、 セキュリティチームがサポートしているすべてのアーキテクチャとリリースで利用できます。 http://www.FreeBSD.org/ja/security/ には、 サポートが行われているリリースや保守終了予定日の一覧があります。 このユーティリティは、マイナーリリースであったり、 他のリリースブランチへのアップグレードにも対応しています。 新しいリリースにアップデートする前に、 アップデートしようとしているリリースのアナウンスに目を通し、 重要な情報がないかどうかを確認してください。 リリースのアナウンスは http://www.FreeBSD.org/ja/releases/ で確認できます。 もし crontab の中に &man.freebsd-update.8; の機能が含まれていたら、 オペレーティングシステムのアップグレード作業を終えるまでは無効にしてください。 この節では、freebsd-update で使われる設定ファイルの説明、 セキュリティパッチの適応方法のデモンストレーション、 オペレーティングシステムをアップグレードする際に考慮すべきことについて説明します。 設定ファイル freebsd-update のデフォルトの設定ファイルは、 そのままでも用いることができます。 /etc/freebsd-update.conf の設定をデフォルトからきめ細かく調整して、 アップデートプロセスを制御するユーザもいます。 このファイルのコメントにおいて利用可能なオプションが説明されていますが、 以下の項目については補足が必要でしょう。 # Components of the base system which should be kept updated. Components world kernel このパラメータは、&os; のどの部分を最新に維持するかを設定します。 デフォルトでは、ベースシステム全体、 そしてカーネルをアップデートします。 src/basesrc/sys のように、個々の項目を指定することもできます。 この部分についてはデフォルトのままにしておき、 アップデートする項目をユーザがリストに加える形にするのがベストでしょう。 ソースコードとバイナリが同期していないと、 長い年月の間に悲惨な結果がもたらされる可能性があります。 # Paths which start with anything matching an entry in an IgnorePaths # statement will be ignored. IgnorePaths /boot/kernel/linker.hints /bin/sbin 等の特定のディレクトリをアップデートで変更しないように、 これらのパスを追加してください。 このオプションは、ローカルの変更点を freebsd-update が上書きすることを防ぐ目的にも利用できます。 # Paths which start with anything matching an entry in an UpdateIfUnmodified # statement will only be updated if the contents of the file have not been # modified by the user (unless changes are merged; see below). UpdateIfUnmodified /etc/ /var/ /root/ /.cshrc /.profile このオプションは、指定したディレクトリにある設定ファイルを、 ローカルで変更されていない場合のみアップデートします。 ユーザがこれらのファイルを変更していると、 これらのファイルの自動アップデートは妨げられます。 他に、KeepModifiedMetadata という別のオプションが存在します。 このオプションは、freebsd-update がマージ中に変更点を保存するようにします。 # When upgrading to a new &os; release, files which match MergeChanges # will have any local changes merged into the version from the new release. MergeChanges /etc/ /var/named/etc/ /boot/device.hints freebsd-update がマージすべきファイルが存在するディレクトリの一覧です。 ファイルのマージのプロセスは、 &man.mergemaster.8; と同様 &man.diff.1; パッチの連続ですが、 選択肢は少なく、マージを承認するか、エディタを起動するか、 freebsd-update を中断するかどうかを選んでください。 もし、心配な点があれば、 /etc をバックアップしてからマージを承認してください。 mergemaster の詳細な情報については、 - で確認してください。 + &man.mergemaster.8; で確認してください。 # Directory in which to store downloaded updates and temporary # files used by &os; Update. # WorkDir /var/db/freebsd-update ここではすべてのパッチや一次ファイルを置くディレクトリを指定しています。 バージョンをアップグレードするのであれば、 この場所には少なくともギガバイトの空き容量が必要です。 # When upgrading between releases, should the list of Components be # read strictly (StrictComponents yes) or merely as a list of components # which *might* be installed of which &os; Update should figure out # which actually are installed and upgrade those (StrictComponents no)? # StrictComponents no このオプションを yes に設定すると、 freebsd-updateComponents のリストが完全に正しいと判断し、 このリスト以外の変更点については取り扱いません。 freebsd-update は、効率的に Components リストに属するファイルをアップデートします。 セキュリティパッチの適用 &os; のセキュリティパッチを適用する過程は簡単になりました。 管理者は freebsd-update を使うことで、 システムを完全にパッチがあたった状態に保つ事ができます。 &os; セキュリティ勧告の詳細については、 &os; セキュリティ勧告 の節で説明されています。 以下のコマンドを実行すると、&os; のセキュリティパッチがダウンロードされ、インストールされます。 最初のコマンドは、未対応のパッチがあるかどうかを調べます。 もし未対応のパッチがある場合には、 パッチが当てられた際に変更されるファイルのリストが作成されます。 2 番目のコマンドはパッチを適用します。 &prompt.root; freebsd-update fetch &prompt.root; freebsd-update install アップデートによってカーネルにパッチが当たった場合には、 パッチが当たったカーネルで起動するように、 システムを再起動する必要があります。 もし、実行中のバイナリにパッチが当てられた場合には、 パッチの当てられたバージョンのバイナリが使われるように、 影響のあるアプリケーションを再起動する必要があります。 毎日一度アップデートがないかどうかを自動的に確認するように設定するには、 以下のエントリを /etc/crobntab に追加してください。 @daily root freebsd-update cron パッチが存在すると、 自動的にダウンロードされますが、適用はされません。 root宛てにメールで、 ダウンロードされたパッチを確認し、 freebsd-update install とともに手動でインストールする必要のあることが通知されます。 うまく行かなかった場合には、freebsd-update を以下のように実行すると、最後の変更までロールバックできます。 &prompt.root; freebsd-update rollback Uninstalling updates... done. カーネルまたはカーネルモジュールがアップデートされた場合には、 完了後にもう一度システムを再起動して、 影響のあったバイナリを再起動してください。 freebsd-update ユーティリティが自動的にアップデートするカーネルは GENERIC のみです。 カスタムカーネルがインストールされている場合には、 freebsd-update がインストールした後、 カーネルを再構築し、もう一度インストールする必要があります。 しかしながら、GENERIC カーネルが /boot/GENERIC に存在する場合には、 現在のシステムで実行されているカーネルでなくとも、 freebsd-update によりアップデートされます。 GENERIC カーネルを、 常に /boot/GENERIC に置いておいてください。 さまざまな問題を解決する際や、 バージョンをアップグレードする際に助けとなります。 GENERIC カーネルを用意する方法については、 を参照してください。 /etc/freebsd-update.conf のデフォルトの設定を変更しない限り、 freebsd-update は、 他の更新と共にカーネルソースをアップデートします。 新しいカスタムカーネルの再構築と再インストールは、 通常通り行うことができます。 freebsd-update は、 常にカーネルをアップデートするとは限りません。 freebsd-update install によってカーネルソースが変更されなかった場合には、 カスタムカーネルを再構築する必要はありません。 しかしながら freebsd-update は、 /usr/src/sys/conf/newvers.sh を常にアップデートします。 これは、現在のシステムのパッチレベルを uname -r-p で表示する時にこのファイルが参照されます。 そのため、何も変更されていない場合でも、 カスタムカーネルを再構築することにより、 uname がシステムの正確なパッチレベルを報告するようになります。 各システムにインストールされているアップデートをすばやく把握できるようになるので、 特に複数のシステムを管理するときに助けとなります。 メジャーおよびマイナーバージョンのアップグレードを行う &os; のマイナーバージョン間のアップグレード、 たとえば、&os; 9.0 から &os; 9.1 へのアップグレードは、 マイナーバージョン アップグレードと呼ばれます。 メジャーバージョン アップグレードは、 &os; 9.X から &os; 10.X へのアップグレードといった、 &os; のメジャーバージョンが変わるようなアップグレードのことです。 どちらのアップグレードもリリース番号のターゲットを指定する事で、 freebsd-update によって行う事ができます。 カスタムカーネルを使っているシステムでは、 アップグレードを行う前に GENERIC カーネルが、 /boot/GENERIC に置かれている事を確認してください。 GENERIC カーネルを用意する方法については、 を参照してください。 以下のコマンドを実行すると、&os; 9.0 のシステムを &os; 9.1 にアップグレードします。 &prompt.root; freebsd-update -r 9.1-RELEASE upgrade コマンドを実行すると、freebsd-update は設定ファイルと現在のシステムを評価し、 アップデートするために必要な情報を収集します。 画面には、どのコンポーネントが認識され、 どのコンポーネントが認識されていないといったリストが表示されます。 たとえば以下のように表示されます。 Looking up update.FreeBSD.org mirrors... 1 mirrors found. Fetching metadata signature for 9.0-RELEASE from update1.FreeBSD.org... done. Fetching metadata index... done. Inspecting system... done. The following components of FreeBSD seem to be installed: kernel/smp src/base src/bin src/contrib src/crypto src/etc src/games src/gnu src/include src/krb5 src/lib src/libexec src/release src/rescue src/sbin src/secure src/share src/sys src/tools src/ubin src/usbin world/base world/info world/lib32 world/manpages The following components of FreeBSD do not seem to be installed: kernel/generic world/catpages world/dict world/doc world/games world/proflibs Does this look reasonable (y/n)? y ここで、freebsd-update はアップグレードに必要なすべてのファイルをダウンロードします。 何をインストールし、どのように進むかといった質問をされることもあります。 カスタムカーネルを使っていると、 上記のステップで以下のような警告が表示されます。 WARNING: This system is running a "MYKERNEL" kernel, which is not a kernel configuration distributed as part of FreeBSD 9.0-RELEASE. This kernel will not be updated: you MUST update the kernel manually before running "/usr/sbin/freebsd-update install" この時点ではこの警告を無視してもかまいません。 アップデートされた GENERIC カーネルは、 アップグレードプロセスの途中で利用されます。 すべてのパッチがローカルシステムへダウンロードされたら、 次にパッチが適用されます。 このプロセスには時間がかかります。 この時間はコンピュータの性能とワークロードに依存します。 その後、設定ファイルがマージされます。 このプロセスでは、ユーザはファイルをマージするか、 画面上にエディタを立ち上げて手動でマージするかを尋ねられます。 プロセスが進むごとに、成功したマージのすべての結果の情報がユーザに示されます。 マージに失敗したり、無視した場合には、プロセスが中断します。 ユーザによっては /etc のバックアップを取り、 master.passwdgroup のような重要なファイルを後で手動でマージする方もいます。 すべてのパッチは別のディレクトリでマージされており、 まだ、システムには反映されていません。 すべてのパッチが正しく適用され、 すべての設定ファイルがマージされてプロセスがスムーズに進んだら、 ユーザは以下のコマンドを用いて、 変更点をディスクに反映してください。 &prompt.root; freebsd-update install パッチは最初にカーネルとカーネルモジュールに対して当てられます。 システムがカスタムカーネルを実行している場合には、 &man.nextboot.8; を使って次回の再起動時のカーネルを、 アップデートされた /boot/GENERIC に設定してください。 &prompt.root; nextboot -k GENERIC GENERIC カーネルで再起動する前に、 カーネルにシステムが適切に起動するために必要なすべてのドライバが含まれていること、 もしアップデートしているコンピュータがリモートでアクセスしているのであれば、 ネットワーク接続に必要なすべてのドライバも含まれていることを確認してください。 特に、これまで実行しているカスタムカーネルが、 カーネルモジュールとして提供されているビルドインの機能を含んでいるのであれば、 これらのモジュールを一時的に /boot/loader.conf の機能を用いて、 GENERIC に読み込んでください。 アップグレードプロセスが終わるまでは、 重要ではないサービスを無効にするとともに、 必要のないディスクやネットワークのマウントなども避けることが推奨されています。 アップデートされたカーネルでコンピュータを再起動してください。 &prompt.root; shutdown -r now システムがオンラインに戻ったら、以下のコマンドを使って freebsd-update を再び実行してください。 アップデートプロセスの状態は保存されているので、 freebsd-update を実行すると、 最初からではなく、次のステップに進み、 古い共有ライブラリとオブジェクトファイルを削除します。 &prompt.root; freebsd-update install 使用しているライブラリのバージョン番号の付けられ方によって、 3 つのインストールフェーズが 2 つになる場合もあります。 アップグレードはこれで終了です。 もしメジャーアップグレードを行った場合には、 で説明されているようにすべての ports および package を再構築してください。 &os; 9.X 以降のシステムにおけるカスタムカーネル freebsd-update を使う前に、 GENERIC カーネルが /boot/GENERIC に置かれていることを確認してください。 ただ一度だけカスタムカーネルを構築したのであれば、 /boot/kernel.oldGENERIC カーネルそのものです。 このディレクトリの名前を /boot/kernel へと変更してください。 もし、2 回以上カスタムカーネルを構築した後であったり、 カスタムカーネルを構築した回数がわからなければ、 現在のオペレーティングシステムのバージョンの GENERIC カーネルを入手してください。 コンピュータへの物理的なアクセスが可能であれば、 インストールメディアから GENERIC カーネルをインストールできます。 &prompt.root; mount /cdrom &prompt.root; cd /cdrom/usr/freebsd-dist &prompt.root; tar -C/ -xvf kernel.txz boot/kernel/kernel 別な方法としては、 GENERIC カーネルをソースから再構築して、 インストールしてください。 &prompt.root; cd /usr/src &prompt.root; make kernel __MAKE_CONF=/dev/null SRCCONF=/dev/null freebsd-update がこのカーネルを GENERIC カーネルとして認識するために、 GENERIC コンフィグレーションファイルは、 とにかく変更してはいけません。 また、特別なオプションを指定しないで構築してください。 freebsd-update は、 /boot/GENERIC が存在する事だけを必要とするので、 GENERIC カーネルで再起動する必要はありません。 メジャーバージョンアップグレード後の package のアップグレード 一般的に、マイナーバージョンアップグレードの後では、 インストールされているアプリケーションは、問題なく動作するでしょう。 メジャーバージョンが異なるとアプリケーションバイナリーインタフェース (ABI) が異なるため、 サードパーティ製のアプリケーションの多くは動作しなくなるでしょう。 メジャーバージョンアップグレード後には、 インストールされているすべての packages, ports をアップグレードする必要があります。 package は、pkg upgrade を使ってアップグレードできます。 インストールされている ports をアップグレードする場合には、 ports-mgmt/portmaster といったユーティリティを使ってください。 すべての package の強制的なアップグレードでは、 バージョン番号が上がらない package に対しても、 リポジトリから最新のバージョンで、インストールされている package を置き換えます。 &os; のメージャーバージョンが変わるようなアップグレードでは、 ABI のバージョンも変わるため、 このようなアップグレードが必要になります。 強制的なアップグレードを行うには、以下のように実行してください。 &prompt.root; pkg-static upgrade -f インストールされているすべてのアプリケーションを再構築するには、 以下のコマンドを実行してください。 &prompt.root; portmaster -af このコマンドを実行すると、 設定を変更するオプションを持つアプリケーションは、 設定変更のスクリーンを表示し、 ユーザからの指示待ちの状態で停止します。 この振る舞いをやめ、デフォルトのオプションを使用するには、 上記のコマンドに を含めてください。 ソフトウェアのアップグレードが終わったら、最後にもう一度 freebsd-update を実行して、 すべてのアップグレードプロセスのやり残し作業を行い、 アップグレードのプロセスを完了してください。 &prompt.root; freebsd-update install GENERIC カーネルを一時的に読み込んでいたのであれば、 に書かれている手順に従って、 新しいカスタムを構築し、インストールしてください。 コンピュータを再起動し、新しい &os; を立ち上げてください。 これでアップグレードのプロセスは完了です。 システムの状態の比較 freebsd-update を用いて、 インストールされている &os; の状態と、 正しく動作することが分かっている状態とを比較できます。 このコマンドは、現在のシステムのユーティリティ、ライブラリ、 設定ファイルを評価するので、 組み込みの侵入検知システム (IDS) として使うことができます。 このコマンドは、security/snort のような本当の IDS の置き換えになるものではありません。 freebsd-update はデータをディスクに保存するので、 不正な変更が行われる可能性があります。 kern.securelevel と、 freebsd-update のデータを使用しないときに、 読み取りのみの許可属性に設定されているファイルシステムに置くことで、 不正な変更の可能性を低くできますが、 よりよい解決方法は、 DVD または安全に保存されている外部 USB ディスクのような安全なディスクとシステムを比較することです。 組み込まれているユーティリティを用いた、別の方法による IDS 機能については、 &os; バイナリによる検出 の節をご覧ください。 比較を行うには、 結果の出力先のファイル名を指定してください。 &prompt.root; freebsd-update IDS >> outfile.ids システムは検査され、リリースファイルの SHA256 ハッシュ値と現在インストールされているファイルのハッシュ値がファイルの一覧と共に、 指定した出力先のファイルに送られます。 これらの行は極めて長いのですが、出力形式は簡単にすぐに解析できます。 たとえば、これらのリリースで異なっているすべてのファイルを知りたいのであれば、 以下のコマンドを実行してください。 &prompt.root; cat outfile.ids | awk '{ print $1 }' | more /etc/master.passwd /etc/motd /etc/passwd /etc/pf.conf 上の表示例では出力は切り捨てられており、 実際にはもっと多くのファイルが存在します。 これらのファイルには、運用中に変更されるファイルがあります。 たとえば、/etc/passwd はユーザがシステムに追加されると変更されます。 また、カーネルモジュールは、 freebsd-update によりアップデートされるため、変更されます。 このような特別なファイルやディレクトリを除外するには、 それらを /etc/freebsd-update.confIDSIgnorePaths オプションに追加してください。 ドキュメントのアップデート Updating and Upgrading Documentation Updating and Upgrading ドキュメントは、&os; オペレーティングシステムの必須要素です。 &os; ドキュメントの最新バージョンは、&os; ウェブサイト (http://www.freebsd.org/doc/) から入手できますが、 &os; ウェブサイト、ハンドブック、FAQ および文書の最新版をローカルに用意しておくと便利です。 この章では、ソースまたは Ports Collection を使って、 ローカルの &os; ドキュメントを最新に保つ方法を説明します。 ドキュメントを編集したり、 ドキュメントの誤りを報告する方法については、 新しい貢献者のための &os; ドキュメンテーションプロジェクト入門 (http://www.freebsd.org/doc/en_US.ISO8859-1/books/fdp-primer/) をご覧ください。 ソースから &os; ドキュメントをインストールする ソースから &os; ドキュメントを構築するのに必要なツールは、 &os; のベースシステムには含まれていません。 svn などの必要なツールは、 &os; ドキュメンテーションプロジェクトが開発している textproc/docproj package または port からインストールできます。 インストールしたら、svn を使って、ドキュメントのソースをダウンロードしてください。 &prompt.root; svn checkout https://svn.FreeBSD.org/doc/head /usr/doc 最初にドキュメントのソースをダウンロードするには少し時間がかかります。 ダウンロードが終わるまでお待ちください。 ダウンロードしたドキュメントのソースをアップデートするには、 以下のコマンドを実行してください。 &prompt.root; svn update /usr/doc 最新のドキュメントのソースのスナップショットを /usr/doc に用意できたら、 インストールされているドキュメントをアップデートする準備はすべて整いました。 利用可能なすべての言語のドキュメントをアップデートするには、 以下のように入力してください。 &prompt.root; cd /usr/doc &prompt.root; make install clean もし、ある特定の言語のみをアップデートしたいのであれば、 /usr/doc の下にある各言語のサブディレクトリで make を実行してください。 &prompt.root; cd /usr/doc/en_US.ISO8859-1 &prompt.root; make install clean ドキュメントをアップデートする別の方法は、 /usr/doc または各言語のサブディレクトリで以下のコマンドを実行してください。 &prompt.root; make update FORMATS を設定して、 以下のようにインストールする出力形式を指定できます。 &prompt.root; cd /usr/doc &prompt.root; make FORMATS='html html-split' install clean ドキュメンテーションの一部のアップデートを簡単にするオプションや、 特定の翻訳のビルドを行うためのオプションが用意されています。 これらのオプションは、システム全般のオプションである /etc/make.conf や、make に与えるコマンドラインオプションで設定できます。 オプションには以下のようなものがあります。 DOC_LANG ビルドおよびインストールの言語およびエンコーディングの一覧。 たとえば、英語のドキュメントを指定するには en_US.ISO8859-1 を設定します。 FORMATS ビルドを行うフォーマット、または出力フォーマットの一覧。 現在は html, html-split, txt, ps そして pdf に対応しています。 DOCDIR ドキュメントをインストールする場所。デフォルトは /usr/share/doc です。 &os; のシステム全般のオプションに関連するもっと多くの make 変数については、 &man.make.conf.5; をご覧ください。 ports を用いたドキュメンテーションのアップデート Marc Fonvieille ベースとなった作業: Updating and Upgrading documentation package Updating and Upgrading これまでのセクションでは、ソースコードを用いた &os; ドキュメントのアップデート方法について説明してきました。 この節では、インストールされている &os; のドキュメントをアップデートするもう一つの方法である、 Ports Collection を用いた方法について説明し、 以下について説明します。 構築済のドキュメントの packages をインストールする方法。 ローカルでの構築作業やドキュメンテーションツールチェインをインストールする必要はありません。 ports フレームワークを使ったドキュメントのソースの構築方法。 チェックアウトおよび構築作業が簡単になります。 &os; のドキュメントをアップデートするこれらの方法は、 &a.doceng; が毎月アップデートしている ドキュメンテーション ports および packages によりサポートされています。 これらの ports は、&os; Ports Collection の docs カテゴリ (http://www.freshports.org/docs/) にまとめられています。 ドキュメンテーション ports の構成は以下の通りです。 misc/freebsd-doc-en package または portは、 すべての英語文書をインストールします。 misc/freebsd-doc-all メタ package もしくは port は、 すべての利用可能な言語のすべてのドキュメントを構築します。 各言語のために package または port が用意されています。たとえば、 misc/freebsd-doc-hu はハンガリー語のドキュメンテーション port です。 バイナリ package を使うと、 インストールする言語に用意されているすべての形式の &os; ドキュメントがインストールされます。 たとえば、以下のコマンドを実行すると、 ハンガリー語のドキュメントの最新 package がインストールされます。 &prompt.root; pkg install hu-freebsd-doc ドキュメントの package は、対応する port 名とは異なり、 lang-freebsd-doc の形式で名前がつけられています。 ここで、lang は言語コードの短縮形です。 ハンガリー語の場合は hu、簡体字の場合には zh_cn です。 ドキュメントのフォーマットを指定する場合には、package ではなく port から構築してください。たとえば、 英語のドキュメントを構築してインストールするには以下のようにして下さい。 &prompt.root; cd /usr/ports/misc/freebsd-doc-en &prompt.root; make install clean この port には、 構築およびインストールするフォーマットを設定するメニューがあります。 デフォルトでは、http://www.FreeBSD.org と同じ形式である分割版の HTML 形式、 PDF が選択されています。 以下のように、ドキュメンテーション ports を構築する際の make オプションが用意されています。 WITH_HTML HTML 形式を構築します。 各ドキュメントに対し、単一版の HTML ファイルが構築されます。 整形されたドキュメントは、 article.htmlbook.html といった名前でインストールされます。 WITH_PDF 整形されたドキュメントは、 article.pdfbook.pdf といった名前でインストールされます。 DOCBASE ドキュメントのインストール先を設定します。 デフォルトのインストール先は /usr/local/share/doc/freebsd です。 以下は、上記の変数を用いてハンガリー語のドキュメントを PDF 形式でインストールする方法です。 - &prompt.root; cd /usr/ports/misc/freebsd-doc-hu -&prompt.root; make -DWITH_PDF DOCBASE=share/doc/freebsd/hu install clean + &prompt.root; cd /usr/ports/misc/freebsd-doc-hu +&prompt.root; make -DWITH_PDF DOCBASE=share/doc/freebsd/hu install clean に書かれている手順を使って、 ドキュメンテーション package または port をアップデートできます。 たとえば、以下のコマンドを実行すると、 ports-mgmt/portupgrade から、package だけを使ってインストールされているハンガリー語のドキュメントをアップデートします。 &prompt.root; portmaster -PP hu-freebsd-doc 開発ブランチを追いかける -CURRENT -STABLE &os; には二つの開発ブランチがあります。 それは &os.current; と &os.stable; です。 この節ではそれぞれのブランチと対象としている読者についての説明と、 どのようにしてシステムの対応するブランチを最新の状態に保つかについて説明します。 訳: &a.hanai;、1996 年 11 月 6 日 &os.current; を使う &os.current; とは &os; の開発の 最前線 なので、 &os.current; のユーザは高い技術力を持つことが要求されます。 そこまでの技術力を持っていないが、 開発ブランチを追いかけたいと考えているユーザは、 かわりに &os.stable; を追いかけると良いでしょう。 &os.current; は &os; の最新のソースコードであり、 中には現在開発途上のソフトウェア、 実験的な変更、あるいは過渡的な機能などが含まれています。 また、この中に入っている機能がすべて、 次の公式リリースに入るとは限りません。&os.current; をソースからほぼ毎日コンパイルしている人はたくさんいますが、 短い期間ではコンパイルさえできない状態になっている時期もあります。 これらの問題は可能な限り迅速に解決されますが、 &os.current; が不幸をもたらすか、 それとも新しい機能をもたらすかは、 まさにソースコードを同期した瞬間によるのです! &os.current; は、 次の 3 つの重要なグループを対象としています。 ソースツリーのある部分に関して活発に作業している &os; コミュニティのメンバ。 活発にテストしている &os; コミュニティのメンバ。 彼らは、種々の問題を解決するのに時間を惜しまない人々であり、 さまざまな変更に関する提案や &os; の大まかな方向付けを行ないたいと思っている人々でもあり、 パッチも提出します。 さまざまな事に目を向け、 参考のために最新のソースを使いたいと思っていたり、 時々コメントやコードを寄稿したいと考えているユーザ。 &os.current; は、次のリリースの前に、 最も早く新しい機能を入手する手段として、 期待してはいけません。 リリース前の機能は十分にテストされていないため、 バグを含んでいる可能性が大いにあるためです。 また、バグを修正するための素早い方法でもありません。 いかなるコミットは、元からあるバグを修正するのと同じく、 新しいバグを生み出すおそれがあります。 &os.current; には 公式のサポート はありません。 -CURRENT using &os.current; を追いかけるには &a.current.name; と &a.svn-src-head.name; -CURRENT 使用 メーリングリストに加わってください。 さまざまな人がシステムの現在の状態について述べているコメントを見たり、 &os.current; の現在の状態に関する重要な情報を見逃さないために、 必須の ことです。 &a.svn-src-head.name; メーリングリストでは、 それぞれの変更についての commit ログが記録されています。 また、それに関して起こり得る副作用の情報を得ることができますので、 参加する価値のあるメーリングリストです。 これらのメーリングリストに入るには、 &a.mailman.lists.link; をたどって参加したいメーリングリストをクリックし、 手順の説明にしたがってください。 &os.current; だけでなく、 ソースツリー全体の変更点を追いかけるのであれば、 &a.svn-src-all.name; メーリングリストを購読してください。 &os.current; のソースを同期してください。 特に svn を使って の一覧にある Subversion ミラーサイトのひとつの head ブランチから -CURRENT コードをチェックアウトしてください。 リポジトリのサイズが大きいため、興味のある部分や、 パッチを当てる部分のソースのみを同期するユーザもいます。 しかしながら、 ソースからオペレーティングシステムをコンパイルしようと思っているユーザは、 一部分だけではなく、&os.current; の すべて をダウンロードする必要があります。 &os.current; をコンパイル -CURRENT コンパイル する前に /usr/src/Makefile を注意深く読み、 に書かれている手順に従ってください。 &a.current; と /usr/src/UPDATING を読めば、 次のリリースへ向けて移ってゆくに当たって、 ときどき必要となる既存システムからの新システムの構築手順についての最新情報が得られるでしょう。 アクティブになってください! &os.current; のユーザには、 拡張やバグ潰しに関して提案することが勧められています。 コードを伴う提案はいつでも歓迎されます! - - - &os.stable; を使う - - 訳: &a.jp.iwasaki; - - &os.stable; - とは定期的に公開されるリリースを作成するための開発ブランチです。 - このブランチに加えられる変更は &os.current; よりゆっくりで、 - 原則として、事前に &os.current; で試験ずみであるという特徴があります。 - ただそうであっても、 - これは開発用ブランチの一つであり、ある時点における &os.stable; - のソースがどんな場合にも使えるものであるとは限りません。 - このブランチはもう一つの開発の流れというだけであって、 - エンドユーザ向けのものではありません。 - もし試験をする資源的な余裕がない場合は、代わりに最新の - &os; リリースを使ってください。 - - &os; の開発プロセスに興味があったり、 - それに対する貢献を考えていて、特にそれが次回の - &os; のリリースに関係するものであるなら - &os.stable; を追うことを考えると良いでしょう。 - - &os.stable; ブランチはいつもコンパイルができ、 - 安定に動作すべきですが、 - それが保証されているというわけではありません。 - &os.stable; のユーザは &os.current; よりも多いため、&os.current; - で発見されなかったバグが &os.stable; で発見され、 - ときどきそれが問題となることがあるのは避けることができません。 - このような理由から、盲目的に &os.stable; - を追いかけるべきではありません。 - 特に、開発環境もしくはテスト環境でコードを十分に試験せずに、 - プロダクション品質が要求されるサーバを &os.stable; - にアップグレードしてはいけません - - &os.stable; を追いかけるには - - - -STABLE - 利用する - - - - - &os.stable; の構築に関連する事柄や、 - その他の注意すべき点 に関する情報を得るために、 - &a.stable.name; メーリングリストに加わってください。 - また開発者は議論の余地がある修正や変更を考えている場合に、 - このメーリングリストで公表し、 - 提案された変更に関して問題が生じるかどうかを返答する機会をユーザに与えます。 - - 追いかけているブランチに関連する - svn メーリングリストに参加してください。 - たとえば、9-STABLE ブランチを追いかけているユーザは - &a.svn-src-stable-9.name; メーリングリストに参加してください。 - このリストでは、変更がなされるごとに作成される commit log - やそれに伴う起こりうる副作用についての情報が記録されています。 - - これらのメーリングリストに入るには、&a.mailman.lists.link; - をたどって参加したいメーリングリストをクリックし、 - 手順の説明にしたがってください。 - ソースツリー全体の変更点を追いかけるには、 - &a.svn-src-all.name; メーリングリストを購読してください。 - - - - 新しい &os.stable; システムをインストールするには、 - ミラーサイト から最近の - &os.stable; リリースをインストールするか、 - 毎月公開されている &os.stable; - からビルドされたスナップショットを使ってください。 - スナップショットの詳細については、www.freebsd.org/ja/snapshots - をご覧ください。 - - 既に &os; が動いているシステムを - &os.stable; にアップグレードするには、 - svn - - Subversion - を使って、 - 希望する開発ブランチのソースをチェックアウしてください。 - stable/9 といったブランチ名は、 - www.freebsd.org/releng - で説明されています。 - - - - &os.stable; をコンパイルしたり &os.stable; へとアップグレード - - -STABLE - 構築、コンパイル - する前に、 - /usr/src/Makefile を注意深く読み、 - - に書かれている手順に従ってください。 - &a.stable; と /usr/src/UPDATING を読んで、 - 次のリリースへ向けて移ってゆくに当たって、 - ときどき必要となる既存システムからの新システムの構築手順についての最新情報を得てください。 - - - - - ソースの同期 - - 訳: &a.jp.iwasaki;、1997 年 9 月 13 日 - - &os; のソースの最新を追いかける方法は色々あります。 - この節では、基本的なサービスである - Subversion - について説明します。 - - - ソースツリーの一部を最新のものに更新することは可能です。 - ただし、サポートされているアップデート手順は、 - ソースツリー全体を最新のものに更新し、 - /bin, /sbin - といったユーザ空間で動作するもの、 - およびカーネルソースを再構築することのみです。 - ソースツリーの一部だけであったり、カーネルだけ、 - もしくはユーザランドのプログラムだけを更新した場合は、 - 問題が生じることがよくあります。 - この時に発生する問題はコンパイル時のエラーからカーネルパニック、 - データの破壊とさまざまです。 - - - - Subversion - - - Subversion - は pull 同期モデルを採用しています。 - ユーザ (または cron スクリプト) が - svn プログラムを起動し、 - ローカルにあるソースを最新状態にします。 - 更新情報はその時点の最新のものであり、 - いつダウンロードするかはユーザがコントロールするので、 - Subversion - はローカルのソースツリーをアップデートする好ましい方法です。 - 特定のファイルやディレクトリに限定して更新することも簡単にできます。 - 更新情報はサーバによって素早く生成されます。 - Subversion によるソースの同期方法については、 - で説明されています。 - - Subversion であれば、 - うっかりローカルのアーカイブの一部を消してしまっても、 - 壊れた部分を検出して再構築してくれます。 - - - world の再構築 + ソースを用いた &os; のアップデート - - world の再構築 - - &os.stable;、&os.current; などの - &os; のどれか特定のバージョンについて、 - ローカルのソースツリーを同期させたら、 - そのソースツリーを使ってシステムを再構築できます。 - このプロセスは world の再構築と呼ばれます。 + ソースをコンパイルして&os; をアップデートする方法は、 + バイナリを用いたアップデートに比べ、いくつもの利点があります。 + 特定のハードウェアをうまく利用するためのオプションを設定してコードを構築できます。 + ベースシステムの特定の箇所の設定をデフォルトの設定から変更したり、 + 必要がない部分を完全に削除して構築することもできます。 + システムを構築することによるアップデートは、 + バイナリアップデートをインストールするだけのアップデートに比べ時間がかかりますが、 + 利用環境に合わせた &os; + を作成するような完全なカスタマイズが可能です。 - world を再構築するに、 - 以下を行ってください。 + + クィックスタート - - world の構築<emphasis>前</emphasis>に行う作業 + 以下は、&os; のアップデートをソースを構築することにより行う典型的な方法のクイックリファレンスです。 + その後の節では、このプロセスについてより詳細に説明します。 - - 重要なデータを他のシステムやリムーバブルメディアにバックアップし、 - きちんとバックアップが作成されていることを確認したら、 - 起動可能なインストールメディアを用意してください。 - システムを再構築する前に、 - バックアップを作成することの重要性は、 - いくら強調してもし過ぎると言うことはありません。 - システム全体の再構築は難しい作業ではありませんが、 - どんなに注意していたとしても、 - ソースツリーそのものに手違いがあった時には、 - システムが起動しなくなってしまう状態になることがあるのです。 - 多分、それを使うことはないと思いますが、 - あとで後悔することのないよう、念のため用意しておきましょう! - - - - メーリングリスト - 追いかけているブランチに応じて、 - &a.stable.name; もしくは &a.current.name; - の最近のエントリを調べて、 - 既知の問題や影響を受けるシステムを確認してください。 - 既知の問題が同期しているバージョンのコードに影響する場合は、 - その問題が解決されたことを報告する - 問題解決 (all clear) - のアナウンスが投稿されるまで待ってから、ソースを同期して、 - ローカルのソースに必要な修正を入れてください。 - - - - /usr/src/UPDATING を読み、 - 同期しているソースのバージョンで必要となるステップがないかどうかを調べて下さい。 - このファイルには潜在的な問題や特定のコマンドを実行する順番などの重要な情報が含まれています。 - 大きなアップグレードでは、world - をインストールする前に特定のファイルの名前を変更したり、 - 削除するといった、特別なステップが追加で必要となることがあります。 - ファイルの最後には、 - 現在推奨されているアップグレードの手順が詳しく正確に説明されています。 - もし、UPDATING に書かれている手順が、 - この節に書かれているものと矛盾していたら、 - UPDATING の手順を採用してください。 - - - - - <command>make world</command> は使わないこと - - 古いドキュメントの中には、 - make world を使うことを薦めているものがあります。 - これは、重要な手順をいくつか抜かしてしまうので、 - エキスパートでなければ使うべきではありません。 - ほぼあらゆる場合において、make world - を実行するのは間違っており、 - ここで説明されている手順を用いるべきです。 - - - - システム更新の概要 - - world の構築では、 - に書かれている手順で入手したソースを用いて、 - 古い &os; のバージョンをアップデートします。 - - &os; では、world は、 - カーネル、コアシステムのバイナリ、 - ライブラリ、プログラミングファイル、組み込みのコンパイラを意味します。 - これらのコンポーネントの構築およびインストールの順番は重要です。 - - 例えば、古いコンパイラは、 - バグを含み、新しいカーネルをコンパイルできない可能性があります。 - そのため、 - 新しいカーネルは新しいコンパイラを使って構築しなければならず、 - 新しいコンパイラの構築が必要となります。 - ただし、必ずしも、 - 新しいコンパイラがインストールされている必要はありません。 - - 新しい world は、 - 新しいカーネルの機能に依存している可能性があるので、 - 新しい world をインストールする前に、 - 新しいカーネルがインストールされている必要があります。 - 古い world は、新しいカーネルでは正しく動かないかも知れません。 - そのため、新しいカーネルをインストールしたら、 - 直ちに新しい world をインストールしてください。 - - 設定の中には、新しい world - をインストールする前に変更すべきものがありますが、 - 古い world を壊す可能性があります。 - そのため、設定のアップデートは 2 つの手順で行われます。 - 多くの場合、アップデートのプロセスは、ファイルを置き換えたり、 - 追加のみを行い、古いファイルを削除しません。 - このことが問題を引き起こす可能性があるため、 - /usr/src/UPDATING には、 - 手動で削除すべきファイルをどのステップで削除すべきかが書かれています。 - - これらを配慮した結果、以下で説明するアップグレードの推奨手順が作られました。 - - - make を実行したときの出力は、 - ファイルに保存すると良いでしょう。 - 何か障害が発生した場合には、エラーメッセージのコピーを - &os; メーリングリストに投稿してください。 - - ファイルに保存する最も簡単な方法は、 - 引数として出力の保存先のファイル名を指定して - script コマンドを使うことです。 - /tmp は、 - 再起動をすると削除されてしまう可能性があるので、 - このディレクトリには出力を保存しないようにしてください。 - 出力の保存には /var/tmp が適しています。 - 次のコマンドを world の構築の直前に実行し、再構築が終了したら - exit と入力してください。 - - &prompt.root; script /var/tmp/mw.out -Script started, output file is /var/tmp/mw.out - - - world の構築プロセスの概要 - - world の構築プロセスで用いられるコマンドは、 - ここで示されている順番で実行してください。 - この節では各コマンドの機能についてまとめます。 - - システム上で world の構築が一度でも行われていると、 - 前回の構築の際のコピーが - /usr/obj - に存在するはずです。 - このディレクトリが存在しているのであれば、 - このディレクトリを削除することで - make buildworld の行程にかかる時間を短縮し、 - 依存問題に悩まされるようなトラブルを回避できます。 + アップデートおよびビルド - &prompt.root; chflags -R noschg /usr/obj/* -&prompt.root; rm -rf /usr/obj - + &prompt.root; svn update /usr/src +check /usr/src/UPDATING +&prompt.root; cd /usr/src +&prompt.root; make -j4 buildworld +&prompt.root; make -j4 kernel +&prompt.root; shutdown -r now +&prompt.root; cd /usr/src +&prompt.root; make installworld +&prompt.root; mergemaster -Ui +&prompt.root; shutdown -r now - - 新しいコンパイラと関連ツールを最初にコンパイルし、 - その後、新しいコンパイラで、 - 新しい world の残りの部分をコンパイルします。 - コンパイルされたものは、 - /usr/obj に格納されます。 + + + 最新版のソースを入手してください。 + ソースの入手およびアップデートに関する情報については + + をご覧ください。 + - &prompt.root; cd /usr/src -&prompt.root; make buildworld - + + ソースの構築の前後で必要となる手動の作業について、 + /usr/src/UPDATING + を確認してください。 + - - コンパイラとカーネルのミスマッチを防ぐため、 - /usr/obj - にある新しいコンパイラを用いて新しいカーネルを構築します。 - 再構築は、ある種のメモリ構造体が変更されたような場合には必須で、 - pstop - のようなプログラムは、 - カーネルとソースコードのバージョンが一致しないと正常に動作しないことがあります。 + + ソースが置かれているディレクトリに移動してください。 + - &prompt.root; make buildkernel - + + world (カーネルを除くすべて) + をコンパイルしてください。 + - - 新しくアップデートされたカーネルで起動できるように、 - 新しいカーネルとカーネルモジュールをディスク上に配置します。 - kern.securelevel を 1 より大きくしていて、 - かつ カーネルのバイナリファイルに - noschg のようなフラグを設定している場合は、 - まず、シングルユーザモードに移行してください。 - それ以外の場合は、 - マルチユーザモードでこれらのコマンドを問題なく動かせるはずです。 - kern.securelevel の詳細については - &man.init.8;、ファイルに対するさまざまなフラグの詳細については - &man.chflags.1; をご覧ください。 + + カーネルをコンパイルしてインストールしてください。 + ここに書かれているコマンドは、make buildkernel + installkernel + と同じです。 + - &prompt.root; make installkernel - + + 新しいカーネルを使うため、 + システムを再起動してください。 + - - すでに実行されているソフトウェアをアップデートする際の問題を最小限にするため、シングルユーザモードに移行してください。 - シングルユーザモードに移行することにより、 - 新しいカーネル上で古い world - が実行される際の問題を最小限にします。 + + ソースが置かれているディレクトリに移動してください。 + - &prompt.root; shutdown now + + world をインストールしてください。 + - シングルユーザモードに移行したら、UFS - でフォーマットされているシステムでは、 - 以下のコマンドを実行してください。 + + /etc/ + に置かれている設定ファイルをアップデートしたりマージしてください。 + - &prompt.root; mount -u / -&prompt.root; mount -a -t ufs -&prompt.root; swapon -a - - もしシステムが ZFS でフォーマットされている場合には、 - 以下の 2 つのコマンドを実行してください。 - この例では、zpool の名前は zroot - であると仮定しています。 - - &prompt.root; zfs set readonly=off zroot -&prompt.root; zfs mount -a + + 新しく構築された world およびカーネルを利用するため、 + システムを再起動してください。 + + - - - オプション: もし、デフォルトの US English - 以外のキーボードマップが必要であれば、 - &man.kbdmap.1; で変更してください。 - - &prompt.root; kbdmap - - - - その後、どちらのファイルシステムでも、 - CMOS クロックが地域時間に設定されていて - GMT ではない場合 - (&man.date.1; が正しい時間と地域を表示しないなら当てはまります) - には、次のコマンドを実行してください。 - - &prompt.root; adjkerntz -i - - - - システムの再構築では、 - /etc, - /var や - /usr - といったディレクトリに新規に導入されたファイルや、 - 変更された設定ファイルに対する更新は行なわれません。 - 次に、新しい world - に対する /etc - の最初の設定ファイルのアップデートを行います。 - 以下のコマンドは - installworld - を成功するために本質的なファイルのみを比較します。 - たとえば、 - このステップでは、最後のアップデート後に &os; に追加された、 - 新しいグループや新しいシステムアカウント、 - もしくはスタートアップスクリプトがシステムに追加されることがあります。 - 次のコマンドに関する詳細な情報については、 - を参照してください。 - - &prompt.root; mergemaster -iF - - - - /usr/obj - にある新しい world - およびシステムのバイナリをインストールします。 - - &prompt.root; cd /usr/src -&prompt.root; make installworld - - - - 残りの設定ファイルをアップデートします。 - - &prompt.root; mergemaster -p - - - - 使われなくなったファイルを削除します。 - もし使われなくなったファイルがディスクに残っていると、 - 問題が起きる可能性があるので重要な作業です。 - - &prompt.root; make delete-old - - - - 再起動を行い、新しいカーネル、 - world そして設定ファイルをロードします。 - - &prompt.root; reboot - - - - 古いライブラリを削除する前に、 - - に書かれている手順にしたがって、 - すべての ports を再構築する必要があります。 - 再構築が終わったら、新しいライブラリと競合することを避けるため、 - 使われなくなったライブラリを削除します。 - この過程に関する詳細は、 - を参照して下さい。 - - &prompt.root; make delete-old-libs - - - シングルユーザモード - - もしシステムがダウンタイムを持つことができるのであれば、 - システムのコンパイルをマルチユーザモードでおこない、 - インストールのためにシングルユーザモードに移行するという方法ではなく、 - コンパイルをシングルユーザモードで行うことを考えてください。 - システムの再インストールでは、たくさんの重要なシステムファイル、 - すべての標準的なシステムバイナリ、ライブラリ、 - インクルードファイルが変更されるので、 - 実際に動作しているシステムにおいて、 - 特にアクティブなユーザは、トラブルに見舞われる可能性があります。 - - 設定ファイル + + ソースを用いたアップデートのための準備 - - make.conf - - - world - の構築プロセスでは、いくつかの設定ファイルが使われます。 - - /usr/src に置かれている - Makefile には、 - &os; を構成するプログラムの構築方法や、 - どういう順番でそれらを構築すべきかといった指示が記述されています。 - - make で利用可能なオプションの説明は、 - &man.make.conf.5; で説明されています。また、 - /usr/share/examples/etc/make.conf には、 - 良く使われる例が書かれています。 - これらの設定を /etc/make.conf に追加すると、 - make の実行やプログラムの構築方法を設定できます。 - これらのオプションは、 - make が使われる際には常に有効となるため、 - Ports Collection でのアプリケーションのコンパイル時、 - ユーザが書いた C プログラムや &os; - オペレーティングシステムを構築する際にも影響を及ぼします。 - ある設定を変更したことにより、影響が広い範囲におよび、 - 驚くべき結果をもたらす可能性があります。 - 両方のファイルに書かれているコメントを読むことと、 - デフォルトの設定は、パフォーマンスと安全性の観点から選ばれていることを覚えておいてください。 - - - src.conf - - - /etc/src.conf は、 - ソースコードを用いたオペレーティングシステムの構築をコントロールします。 - /etc/make.conf とは異なり、 - /etc/src.conf に書かれた設定は、 - &os; オペレーティングシステムそのものを構築するときにのみ影響します。 - このファイルで設定可能な多くのオプションについては、 - &man.src.conf.5; に記述されています。 - 一見したところ無効にされている、 - 使われていないカーネルモジュールやビルドオプションに注意してください。 - ときどき予期しなかったり、わずかな影響を与えることがあります。 + /usr/src/UPDATING を読んでください。 + このファイルには、 + アップデートの前後で必要となる手動の作業について書かれています。 - - 変数とターゲット + + ソースコードのアップデート - make の使用における一般的な書式は、 - 次のとおりです。 + &os; のソースコードは + /usr/src/ に置かれています。 + このソースコードのアップデートには、 + Subversion + バージョン管理システムを利用する方法が推奨されています。まず、 + ソースコードがバージョン管理下にあることを確認してください。 - &prompt.root; make -x -DVARIABLE target + &prompt.root; svn info /usr/src +Path: /usr/src +Working Copy Root Path: /usr/src +... - この例では、 が - make に渡されるオプションになります。 - 利用可能なオプションについては、&man.make.1; - を参照してください。 + この結果は、/usr/src/ + がバージョン管理下にあり、&man.svn.1; + を使ってアップデートできることを示しています。 - 変数を渡すには、変数の名前を - - のように指定してください。 - この変数は Makefile の動作をコントロールします。 - 変数の指定は、/etc/make.conf で設定するか、 - make の実行時に指定するかのどちらかで行います。 - たとえば、以下の変数は、プロファイル版のライブラリを構築しないことを指定します。 + &prompt.root; svn update /usr/src - &prompt.root; make -DNO_PROFILE target + このディレクトリをアップデートしていない期間が長いと、 + アップデートのプロセスには時間がかかります。 + このプロセスが終わると、ソースコードは最新となり、 + 次節以降で説明する構築のプロセスを実行できます。 - これは、/etc/make.conf - の中で以下のように設定することに対応します。 + + ソースコードの入手 - NO_PROFILE= true # Avoid compiling profiled libraries + '/usr/src' is not a working copy + という出力が出た場合には、 + ファイルがなかったり、別な方法によりインストールされているので、 + 新しくソースコードをチェックアウトする必要があります。 - target は、make に - どのように動作するのかを指示するためのものです。 - Makefile は利用可能なターゲットを定義しています。 - ターゲットには、 - システムの再構築に必要な段階を、 - 多くのさらに細かい段階に分割するため、 - 構築の過程で利用されるものがあります。 + + &os; のバージョンおよびリポジトリパス - 選択肢が分けられていることは、二つの理由から有用です。 - まず第一に、構築作業は稼働中のシステムにまったく影響を与えません。 - そのため、マルチユーザモードで稼働中のシステムでも、安全に - buildworld を実行できます。 - ただし、installworld は - シングルユーザモードで行なうことをおすすめします。 + + + + uname -r の出力 + リポジトリパス + 説明 + + - 第二に、NFS マウントを利用することで、 で説明されているように、 - ネットワーク上の複数のマシンをアップグレードすることが可能な点があげられます。 + + + X.Y-RELEASE + base/releng/X.Y + このリリースバージョンに対する重大なセキュルティへの対応およびバグの修正パッチのみが適用されています。 + このブランチは、ほとんどのユーザに推奨されます。 + - make に - をつけると、 - 同時に複数のプロセスを生成できます。 - 構築過程の大部分では CPU 性能の限界より - I/O 性能の限界の方が問題となるため、 - シングル CPU とマルチ CPU - マシンの両方に効果があります。 + + X.Y-STABLE + base/stable/X + + リリースバージョンに対し、 + そのブランチにおけるすべての開発の成果が反映されたものです。 + STABLE は、 + Applications Binary Interface + (ABI) + が変更されないことを意味しており、 + このブランチの以前のバージョンでコンパイルされたソフトウェアは、 + このバージョンでも実行できることを意味しています。 + たとえば、&os; 10.1 + で実行するようにコンパイルされたソフトウェアは、 + &os; 10-STABLE においても実行できます。 - 普通のシングル CPU マシンで以下のコマンド - を実行すると、最大 4 個までのプロセスを同時に実行します。 - メーリングリストに投稿された経験的な報告によると、 - 4 個という指定が最も良いパフォーマンスを示すようです。 + STABLE ブランチは、 + 時期によってはユーザに影響するようなバグや非互換性を持つことがあります。 + これらは通常すぐに修正されます。 + + - &prompt.root; make -j4 buildworld + + X-CURRENT + base/head/ + リリースが行われていない最新の &os; + の開発バージョンです。 + CURRENT ブランチは大きなバグや非互換があることもあるので、 + 高度な知識を持ったユーザのみ使用が推奨されます。 + + + +
- マルチ CPU マシンでは、 - 6 から 10 の間の値を設定し、 - 速度がどれくらい向上するか確認してみてください。 + &man.uname.1; を使って &os; + のバージョンを確認してください。 - - world の再構築 - 時間 - + &prompt.root; uname -r +10.3-RELEASE - - make buildworld - に変数を指定した場合は、同じ指定を - make installworld にも指定しなければなりません。 - ただし installworld - では、 を - 絶対に使ってはいけません + + から分かるように、10.3-RELEASE + のアップデートのためのソースコードのパスは、 + base/releng/10.3 です。 + このパスは、ソースコードをチェックアウトする時に使います。 - たとえば、以下のコマンドを実行したなら、 + &prompt.root; mv /usr/src /usr/src.bak +&prompt.root; svn checkout https://svn.freebsd.org/base/releng/10.3 /usr/src - &prompt.root; make -DNO_PROFILE buildworld + + + この古いディレクトリを、 + 邪魔にならないように移動してください。 + このディレクトリ以下に対して変更を行ってなければ、 + 削除しても構わないでしょう。 + - 以下のようにしてインストールしなければなりません。 - - &prompt.root; make -DNO_PROFILE installworld - - もしそうしなかった場合、2 番目のコマンドは、 - make buildworld - の段階で構築されていないプロファイル版ライブラリをインストールしようとしてしまうでしょう。 + + リポジトリの URL に + + に記載されているパスを追加します。 + 3 番目のパラメータには、 + ローカルシステム上でソースコードが置かれるディレクトリを指定します。 + +
- - - 設定ファイルの同期 + + ソースからの構築 - - - - Tom - Rhodes - - 寄稿: - - - - - - - mergemaster - - + まず最初に world + (カーネルを除くオペレーティングシステムのすべて) をコンパイルします。 + このステップを最初に実行するのは、 + カーネルの構築を最新のツールを使って行うようにするためです。 + このステップが終わったら、カーネルそのものを構築します。 - &os; の &man.mergemaster.8; Bourne シェルスクリプトは、 - /etc にある設定ファイルと、 - /usr/src/etc - にある設定ファイルの違いを確認するためのものです。 - システムの設定ファイルをソースツリーにある設定ファイルにアップデートするには、 - この方法が推奨されています。 + &prompt.root; cd /usr/src +&prompt.root; make buildworld +&prompt.root; make buildkernel - mergemaster を使う前に、 - 既存の /etc - をどこか安全な場所にコピーしておきましょう。 - 再帰的なコピーを行なう と、 - ファイルの更新時間や所有者などを保存する - と共に実行してください。 + コンパイルされたコードは + /usr/obj に書き出されます。 - &prompt.root; cp -Rp /etc /etc.old + これは基本のステップです。 + 構築をコントロールする追加のオプションについては、 + 以下で説明します。 - mergemaster を実行すると、 - / を起点とした一時的なルート環境を構築し、 - さまざまなシステム設定ファイルを - (訳注: デフォルトでは /var/tmp/temproot に) - 置いていきます。 - これらのファイルは現在システムにインストールされているファイルと比較されます。 - 異なるファイルは &man.diff.1; 形式で示され、 - の記号は追加または変更された行を表し、 - は完全に削除されたか新しく置き換えられた行を表します。 - ファイルの違いの表示方法についてのより詳しい情報は、 - &man.diff.1; を参照してください。 + + クリーンビルドの実行 - 次に mergemaster - は違いのあるファイルをそれぞれ示し、 - 選択可能なオプションを表示します。 - ここでは、一時ファイルと呼ばれる新しいファイルを削除するか、 - 一時ファイルをそのままインストールするか、 - 一時ファイルと現在インストールされているファイルを統合するか、 - もしくは結果をもう一度見るか、 - といったオプションから選択できます。 + &os; ビルドシステムのいくつかのバージョンは、 + オブジェクトが一時的に置かれるディレクトリ + /usr/obj + に前回のコンパイルされたコードを残します。 + これにより、変更されていないコードを再コンパイルせずにすむので、 + その後の構築時間を短縮できます。 + すべてを再構築するには、構築を開始する前に、 + cleanworld を実行してください。 - 一時ファイルの削除を選ぶと、mergemaster - は現在のファイルを変更しないで新しいバージョンを削除します。 - この選択は、お勧めできません。 - mergemaster - のプロンプトで ? とタイプすれば、 - いつでもヘルプが見られます。 - ファイルのスキップを選ぶと、他のすべてのファイルを終えたあと、 - もう一度そのファイルが提示されます。 + &prompt.root; make cleanworld + - 一時ファイルをそのままインストールすることを選ぶと、 - 現在のファイルを新しいファイルで置き換えます。 - ほとんどの手を加えていないファイルは、 - これが一番よい選択です。 + + ジョブの数の設定 - ファイルの統合を選んだ場合、 - テキストエディタが起動され、両方のファイルの中身が提示されます。 - 画面上に並ぶ両方のファイルを見て新しいファイルを作成するために両方から必要な部分を選択し、 - 2 つのファイルを統合することができます。 - 並んでいるファイルを比較するとき、 - l で左側の中身を選択し、 - r で右側の中身を選択します。 - 最終出力は左右両方の部分でできたファイルになるでしょう。 - このファイルをインストールすることができます。 - たいてい、このオプションはユーザが設定を変更したファイルに使われます。 + マルチコアプロセッサを搭載するシステムでは、 + 構築のためのジョブの数を増やすことで、 + 構築にかかる時間を短縮できます。 + sysctl hw.ncpu を使って、 + コアの数を確認してください。 + ジョブの数がどのように構築の速さに影響するかを確実に知るには、 + プロセッサにより異なりますし、&os; + のバージョンにより使用されるビルドシステムも変わるため、 + 実際に試してみるしか方法はありません。 + 試してみる最初のジョブの数の候補としては、 + コアの数の半分から倍の数の間で検討してみてください。 + ジョブの数は、 を使って指定します。 - 結果をもう一度見る、を選択すると、 - ファイルの相異点をもう一度見ることができます。 + + 構築のジョブの数を増やす - mergemaster - がシステムファイルの比較を終えたあと、 - 他のオプションについてのプロンプトが表示されます。 - たとえば、 - パスワードファイルを再構築するかどうかを尋ねることがあります。 - 最後に残った一時ファイルを削除するかどうかを尋ねて終了します。 + 以下は 4 つのジョブで world とカーネルを構築する例です。 - + &prompt.root; make buildkernel KERNCONF=STORAGESERVER + - - - 使われなくなったファイル、ライブラリの削除 + + コンパイルされたコードのインストール - - - - Anton - Shterenlikht - - ベースとなったノートの提供: - - - + buildworld および + buildkernel が完了したら、 + 新しいカーネルと world をインストールしてください。 - - Deleting obsolete files and directories - - - &os; の開発サイクルにおいて、 - ファイルやシステムの一部が使われなくなることがあります。 - それらの機能が別の場所で実装されたり、 - ライブラリのバージョン番号が変わったり、 - システムから完全に削除されることがあるためです。 - システムのアップデート時に削除が必要になるのは、 - 古いファイル、ライブラリそしてディレクトリです。 - これらのファイルを削除することで、 - 記憶媒体やバックアップ媒体において不必要な容量を占めている古いファイルが、 - システム上に散乱することがなくなります。 - また、古いライブラリのセキュリティや安定性に問題があると、 - ライブラリを新しくしてシステムを安定な状態にし、 - 古いライブラリによりシステムがクラッシュすることを防がなければなりません。 - 使われなくなったファイル、ディレクトリ、ライブラリは - /usr/src/ObsoleteFiles.inc - にまとめられています。以下の手順により、 - アップグレードの過程でこれらのファイルを削除できます。 - - - make installworld - と、その後の mergemaster が無事に終わったら、 - 使われなくなったファイルやライブラリを確認してください。 - &prompt.root; cd /usr/src -&prompt.root; make check-old +&prompt.root; make installkernel +&prompt.root; shutdown -r now +&prompt.root; cd /usr/src +&prompt.root; make installworld +&prompt.root; shutdown -r now - 見つかった古いファイルは、以下のコマンドで削除できます。 + カスタムカーネルを構築した場合は、 + 新しいカスタムカーネルを KERNCONF + に設定して実行してください。 - &prompt.root; make delete-old - - 使われなくなったファイルを削除する際、 - ファイルごとに確認が求められます。 - 確認を省略し、自動的にファイルを削除するには、 - 以下のように BATCH_DELETE_OLD_FILES - を設定してください。 - - &prompt.root; make -DBATCH_DELETE_OLD_FILES delete-old - - yes - をコマンドへパイプでつなげても省略できます。 - - &prompt.root; yes|make delete-old - - - Warning - - 使われなくなったファイルを削除すると、 - 削除したファイルに依存していたアプリケーションは動かなくなってしまいます。 - 特に、古いライブラリを削除する場合に起こり得ます。 - 通常、make delete-old-libs - を実行する前に、 - これらの古いライブラリを使っているプログラム、ports、 - ライブラリを再構築する必要があります。 - - - 共有ライブラリの依存をチェックするユーティリティとして、 - sysutils/libchk や - sysutils/bsdadminscripts - が用意されています。 - - 使われなくなった共有ライブラリは、 - 新しいライブラリと競合し、 - 以下のようなメッセージを表示することがあります。 - - /usr/bin/ld: warning: libz.so.4, needed by /usr/local/lib/libtiff.so, may conflict with libz.so.5 -/usr/bin/ld: warning: librpcsvc.so.4, needed by /usr/local/lib/libXext.so, may conflict with librpcsvc.so.5 - - この問題を解決するには、 - ライブラリがどの port によってインストールされたかを調べて下さい。 - - &prompt.root; pkg which /usr/local/lib/libtiff.so - /usr/local/lib/libtiff.so was installed by package tiff-3.9.4 -&prompt.root; pkg which /usr/local/lib/libXext.so - /usr/local/lib/libXext.so was installed by package libXext-1.1.1,1 - - 見つかった port をアンインストールし、 - 再構築、再インストールしてください。 - この過程は ports-mgmt/portmaster - で自動化できます。 - すべての ports が再構築され、 - 古いライブラリがどこにも使われていないことを確認したら、 - 以下のコマンドで古いライブラリを削除してください。 - - &prompt.root; make delete-old-libs - - もしちょっとした問題があった場合でも、 - システムの一部を再構築するのは簡単です。 - たとえば、アップグレードや /etc - のマージの途中で誤って - /etc/magic を削除してしまい、 - その結果 file - が動作しなくなってしまったような場合には、 - 次のコマンドを実行して修復してください。 - - &prompt.root; cd /usr/src/usr.bin/file -&prompt.root; make all install + &prompt.root; cd /usr/src +&prompt.root; make installkernel KERNCONF=STORAGESERVER +&prompt.root; shutdown -r now +&prompt.root; cd /usr/src +&prompt.root; make installworld +&prompt.root; shutdown -r now - - よくある質問 + + アップデートの完了 - - - 変更が行なわれたら、 - その度にシステムの再構築が必要になるのでしょうか? + アップデートの完了までに、いくつかの最終作業が残されています。 + デフォルトから変更した設定ファイルを新しいバージョンのファイルにマージし、 + 古くなったライブラリを見つけて削除した後に、 + システムを再起動します。 - - それは変更の内容によります。 - たとえば、svn を実行したとき、 - 次にあげるようなファイルが更新されていたとします。 + + &man.mergemaster.8; を用いた設定ファイルのマージ - src/games/factor/factor.c -src/games/fortune/fortune/fortune.c -src/usr.sbin/bsdinstall/distextract/distextract.c -src/usr.sbin/bsdinstall/partedit/diskeditor.c -src/share/man/man7/intro.7 + &man.mergemaster.8; を用いることで、 + システムの設定ファイルに行われている変更を、 + 簡単にこれらのファイルの新しいバージョンにマージできます。 - このときには、改めてシステム全体を再構築する必要はないでしょう。 - そのかわり、適切なサブディレクトリに移って - make all install を行ってください。 - しかし、たとえば src/lib/libc/stdlib - のような大きな変更が行なわれた場合には、 - システム全体の完全な再構築が強く推奨されます。 + オプションを使って + &man.mergemaster.8; を実行すると、 + ユーザが手を加えていないファイルのアップデートおよび新しく追加されたファイルのインストールを自動的に行います。 - 2 週間ごとにシステムを再構築して、 - その 2 週間分の変更を取り込むユーザもいますし、 - 変更のあった部分だけ再構築し、 - すべての依存関係を確かめたいと考えるユーザもいます。 - それらはどのくらいの頻度でアップグレードしたいか、 - そして &os.stable; か &os.current; - のどちらを追いかけているのかにもよります。 - - + &prompt.root; mergemaster -Ui - - どうして - signal 11 - signal 11 - - (もしくは他のシグナル番号) - のエラーがたくさん出てコンパイルが失敗するのでしょうか? + ファイルのマージを手動で行う必要がある時は、 + ファイルの中で残す箇所の選択を対話的におこなうようなインタフェースが表示さます。 + 詳細については、&man.mergemaster.8; をご覧ください。 + - - これは通常、ハードウェアに問題があることを示しています。 - world の再構築は、 - ハードウェア (特にメモリ) - に対する負荷耐久試験を行なうための有効な手段です。 - 本当にこの問題によるものかどうかは、 - make - をもう一度実行し、異なる段階で異常終了が発生するか、 - ということから確認できます。 + + 使われなくなったファイルやライブラリの確認 - このエラーに対応するには、RAM を始めとして、 - マシンの部品をメモリから交換して、 - どの部分が悪いのかを調べてみてください。 - - + アップデート後に、 + 使われなくなったファイルやディレクトリが残ることがあります。 + これらのファイルは、 - - 終了したら /usr/obj - を削除してもかまいませんか? + &prompt.root; make check-old - - このディレクトリには、 - コンパイルの段階で生成された - すべてのオブジェクトファイルが含まれています。 - 通常 make buildworld の最初の段階では、 - このディレクトリを削除して新しくつくり直すようになっています。 - 構築終了後も /usr/obj - を保存しておいても、あまり意味はありません。 - 削除すれば、だいたい 2GB - のディスクスペースを解放することができます。 - - + で確認でき、以下のようにして削除できます。 - - 構築を中断した場合、 - その構築を途中から再開することはできますか? + &prompt.root; make delete-old - - それは、問題が起こるまでに、 - どれだけの作業を終えているかによります。 - 一般的に make buildworld は、 - 基本的なツールや、 - システムライブラリの新しいコピーを作成します。 - その後、これらのツールやライブラリがインストールされてから、 - 自分自身の再構築に使われ、もう一度、インストールされます。 - システムの残りの部分がその新しいシステムファイルを用いて作り直されます。 + 同様に使われなくなったライブラリが残ることもあります。 + これらのライブラリは、 - 再構築の最終段階では、 - まったく安全に以下のコマンドを実行することができます。 - これは、前回の make buildworld - の作業をやり直しません。 + &prompt.root; make check-old-libs - &prompt.root; cd /usr/src -&prompt.root; make -DNO_CLEAN all + で確認でき、以下のようにして削除できます。 - 次のメッセージ + &prompt.root; make delete-old-libs - -------------------------------------------------------------- -Building everything.. --------------------------------------------------------------- + これらの古いライブラリを利用しているプログラムは、 + ライブラリが削除されると動かなくなります。 + これらのプログラムは、古いライブラリを削除した後に、 + 再構築もしくは置き換える必要があります。 - make buildworld の出力にある場合には、 - 上のようにしてもほとんど悪影響が現れることはありません。 + + 古いファイルとディレクトリのすべてを削除しても問題ないことを確認したら、 + コマンドに BATCH_DELETE_OLD_FILES + を設定することで、各ファイルを削除する際に + y および Enter + を押さなくても済むようにできます。以下はその例です。 - もしこのメッセージがない場合には、 - 安全を確保し、後悔するようなことがないよう、 - システムの再構築を最初からやり直しましょう。 - - + &prompt.root; make BATCH_DELETE_OLD_FILES=yes delete-old-libs + + - - make world を高速化できますか? + + アップデート後の再起動 - - いくつかの方法で build world のプロセスを高速化できます。 - たとえば、全体のプロセスは、 - シングルユーザモードで動かすことで高速になります。 - しかしながら、この方法では、プロセスが完了するまで、 - ユーザがシステムにアクセスすることはできません。 + コンピュータを再起動して、すべての変更を反映させることが、 + アップデートの最後におこなう作業です。 - ファイルシステムを注意深く設計したり、 - ZFS データセットを使うことでも変わります。 - /usr/src と - /usr/obj - を、異なるディスク上の別のファイルシステムに置くことを検討してください。 - また可能ならば、 - 異なるディスクコントローラに接続された異なるディスクにファイルシステムを置いてください。 - /usr/src - をマウントする時には、 - 最後にアクセスされた時刻の書き込みを抑制するように、 - - オプションを付けてマウントしてください。 - もし、/usr/src が、 - 独立したファイルシステムではないときには、 - オプションで、/usr - を再マウントしてください。 - - /usr/obj - のあるファイルシステムを、 - オプションをつけてマウントもしくは再マウントしてください。 - これによって、ディスクへの書き込みが非同期になります。 - つまり、書き込み命令はすぐに完了するのに対し、 - 実際にデータがディスクに書き込まれるのは、その数秒後になります。 - これによって、書き込み処理の一括化が可能になるため、 - 劇的なパフォーマンスの向上が期待できます。 - - - - - - このオプションを指定すると、ファイルシステムは - 壊れやすくなってしまうことに注意してください。 - このオプションを付けていて、突然電源が落ちた場合には、 - 再起動後にファイルシステムが復旧不能になる可能性が - 非常に高くなります。 - - もし、/usr/obj - が、ファイルシステムにある唯一のディレクトリであれば、 - これは問題になりません。 - しかし、同じファイルシステムに、 - 他の貴重なデータを置いているときには、 - このオプションを有効にする前に、 - バックアップをきちんと取っておきましょう。 - - - /etc/make.conf に - NO_PROFILE=true をセットして、 - プロファイル版の作成を無効化してください。 - - &man.make.1; に - - を指定して、複数のプロセスを並列に実行させてください。 - これは、単一のプロセッサでも複数のプロセッサでも、 - 同様に恩恵を得ることができます。 - - - - - なにか悪いことがあったらどうすればいいですか? - - - まず、自分の環境に前のビルドの余計なゴミが残っていないことをはっきりと確認してください。 - - &prompt.root; chflags -R noschg /usr/obj/usr -&prompt.root; rm -rf /usr/obj/usr -&prompt.root; cd /usr/src -&prompt.root; make cleandir -&prompt.root; make cleandir - - ええ、make cleandir - は本当に 2 回実行するのです。 - - そして、make buildworld を行い、 - 全プロセスを最初からやり直してください。 - - まだ問題があれば、エラーと uname -a - の出力を &a.questions; に送ってください。 - 設定についてさらに質問されても答えられるよう用意してください! - - - + &prompt.root; shutdown -r now +
複数のマシンで追いかける Mike Meyer 寄稿: NFS 複数のマシンにインストール 複数のコンピュータで同じソースツリーを追いかけていて、 全部のマシンにソースをダウンロードして全部を再構築するのは、 ディスクスペース、ネットワーク帯域、 そして CPU サイクルの無駄使いです。 解決策は 1 つのマシンに仕事のほとんどをさせ、 残りのマシンは NFS 経由でそれをマウントする、というものです。 このセクションではそのやり方を概観します。 NFS の使い方の詳細については、 をご覧下さい。 まず初めに、同じバイナリで動かそうとするマシンたちを決めます。 このマシンたちのことをビルドセットと呼びます。 それぞれのマシンはカスタムカーネルを持っているかもしれませんが、 同じユーザランドバイナリを動かそうというのです。 このビルドセットから、 ビルドマシンとなるマシンを 1 台選びます。 ベースシステムとカーネルを構築するのはこのマシンになります。 理想的には、このマシンは make buildworldmake buildkernel を実行するのに十分な CPU を持った速いマシンであるべきです。 テストマシン となるべきマシンも選んでください。 更新されたソフトウェアを使う前にそのマシンでテストするのです。 テストマシンはかなり長い時間落ちていても だいじょうぶなマシンであったほうがいいでしょう。 ビルドマシンでもかまいませんが、 ビルドマシンである必要はありません。 このビルドセットのマシンはすべて /usr/obj/usr/src をビルドマシンから FTP 経由でマウントする必要があります。 ビルドセット自体が複数ある場合は、 /usr/src はひとつのビルドマシン上にあるべきです。 他のマシンからはそれを NFS マウントするようにしましょう。 ビルドセットのすべてのマシン上の /etc/make.conf/etc/src.conf がビルドマシンと一致していることを確認してください。つまり、 ビルドマシンはビルドセットのどのマシンもインストールしようとしている ベースシステムを全部ビルドしなければならないということです。 また、各ビルドマシンは /etc/make.conf にそれぞれのビルドマシンのカーネル名を KERNCONF で指定し、 ビルドマシンは自分自身のカーネルから順に全部のカーネル名を KERNCONF にリストアップしてください。 ビルドマシンは各マシンのカーネル設定ファイルを /usr/src/sys/arch/conf に持っていなければなりません。 ビルドマシンにて、 に書いてあるようにカーネルとベースシステムを構築してください。 でも、まだビルドマシンにはインストールしないでください。 そのかわり、 ビルドしたカーネルをテストマシンにインストールしてください。 FTP 経由で /usr/src および /usr/obj をテストマシンにマウントしてください。 その後、shutdown now を実行してシングルユーザモードに移行し、 新しいカーネルとベースシステムをインストールし、 いつもするように mergemaster を実行してください。 終わったら、再起動して通常のマルチユーザ動作に戻します。 テストマシンにあるものすべてがちゃんと動いている確信が得られたら、 同じ手順でビルドセットの他のマシンにも新しいソフトウェアをインストールします。 ports ツリーにも同じ方法が使えます。 最初のステップは、 ビルドセットのすべてのマシンが NFS 経由で /usr/ports をマウントすることです。 そして、distfiles を共有するように /etc/make.conf を設定します。 NFS マウントによってマップされる root ユーザが何であれ、DISTDIR はそのユーザが書き込める共通の共有ディレクトリに設定する必要があります。 ports をローカルでビルドする場合には、 各マシンは WRKDIRPREFIX を自分のマシンのビルドディレクトリに設定しなければなりません。 また、ビルドシステムが packages をビルドしてビルドセットのコンピュータに配布するのであれば、 DISTDIR と同じようにビルドシステム上の PACKAGES ディレクトリも設定してください。