<!--
The FreeBSD Documentation Project
The FreeBSD Japanese Documentation Project
Original revision: 1.236
$FreeBSD$
-->
<chapter id="updating-upgrading">
<chapterinfo>
<authorgroup>
<author>
<firstname>Jim</firstname>
<surname>Mock</surname>
<contrib>再構成、再編成および改訂: </contrib>
</author>
<!-- Mar 2000 -->
</authorgroup>
<authorgroup>
<author>
<firstname>Jordan</firstname>
<surname>Hubbard</surname>
<contrib>原作: </contrib>
</author>
<author>
<firstname>Poul-Henning</firstname>
<surname>Kamp</surname>
</author>
<author>
<firstname>John</firstname>
<surname>Polstra</surname>
</author>
<author>
<firstname>Nik</firstname>
<surname>Clayton</surname>
</author>
</authorgroup>
<!-- with feedback from various others -->
</chapterinfo>
<title>&os; のアップデートとアップグレード</title>
<sect1 id="updating-upgrading-synopsis">
<title>この章では</title>
<para>あるリリースから次のリリースまでの期間にも、
&os; の開発は休みなく続けられています。
最新の開発ツリーと同期することを好む人もいますし、
公式のリリース版を好んで使う方もいます。
しかしながら、公式のリリースといえども、
セキュリティや他の重要な修正のため、時にはアップデートを行う必要があります。
使用しているバージョンに関わらず、&os; は、
手元のシステムを最新の開発ツリーと同期するために必要なツールをすべて用意しています。
そして、これらのツールは、&os; のバージョンをアップグレードするためにも使えます。
もしもあなたが、開発途中のシステムを追いかけようか、
それともリリースバージョンのどれかを使い続けようかと迷っているのなら、
きっとこの章が参考になるでしょう。
手元のシステムをアップデートする基本的なツールについても解説しています。</para>
<para>この章を読んで分かるのは:</para>
<itemizedlist>
<listitem>
<para>システムと Ports Collection
のアップデートに用いるユーティリティについて</para>
</listitem>
<listitem>
<para><application>freebsd-update</application>,
<application>CVSup</application>,
<application>CVS</application> もしくは
<application>CTM</application>
を使ったシステム更新方法</para>
</listitem>
<listitem>
<para>インストールされているシステムと、変更が行われていない状態との比較方法。</para>
</listitem>
<listitem>
<para>2 つの開発ブランチ、&os.stable; と &os.current; の違い</para>
</listitem>
<listitem>
<para><command>make buildworld</command> (等)
を使ってベースシステム全体を再構築しインストールする方法</para>
</listitem>
</itemizedlist>
<para>この章を読む前に、以下の準備をしましょう。</para>
<itemizedlist>
<listitem><para>ネットワーク接続の適切な設定 (<xref
linkend="advanced-networking">)</para>
</listitem>
<listitem><para>サードパーティ製のソフトウェアのインストール方法の習得
(<xref linkend="ports">)</para></listitem>
</itemizedlist>
<note>
<para>この章を通じて、
&os; のソースコードをダウンロードしたりアップデートするのに
<command>cvsup</command> コマンドが用いられます。
このコマンドを使うには、
<filename role="package">net/cvsup-without-gui</filename>
のような port、または package
をインストールしておく必要があります。
&os; 6.2-RELEASE 以降を使っているのであれば、
代わりに &man.csup.1; を使うと良いでしょう。
このコマンドはベースシステムの中に組み込まれています。</para>
</note>
</sect1>
<sect1 id="updating-upgrading-freebsdupdate">
<sect1info>
<authorgroup>
<author>
<firstname>Tom</firstname>
<surname>Rhodes</surname>
<contrib>寄稿: </contrib>
</author>
</authorgroup>
<authorgroup>
<author>
<firstname>Colin</firstname>
<surname>Percival</surname>
<contrib>ベースとなったノートの提供: </contrib>
</author>
</authorgroup>
</sect1info>
<title>FreeBSD Update</title>
<indexterm><primary>Updating and Upgrading</primary></indexterm>
<indexterm>
<primary>freebsd-update</primary>
<see>updating-upgrading</see>
</indexterm>
<para>セキュリティパッチを適用することは、コンピュータソフトウェア、
特にオペレーティングシステムを管理する上で重要な役割を果たします。
&os; にとって長い間、このプロセスは簡単なものではありませんでした。
パッチをソースコードに当てた後、コードからバイナリを再構築し、
バイナリを再びインストールする必要がありました。</para>
<para>現在では &os; に <command>freebsd-update</command>
と呼ばれるユーティリティが追加され、状況は変わりました。
このユーティリティは 2 つの機能を持っています。
第一に、&os; ベースシステムのビルドやインストールを行うことなく、
バイナリによってセキュリティおよび eratta アップデートできます。
第二に、このユーティリティはマイナーおよびメジャーリリースのアップグレードに対応しています。</para>
<note>
<para>バイナリアップデートは、
セキュリティチームがサポートしているすべてのアーキテクチャとリリースで利用できます。
しかしながら、&os;
オペレーティングシステムのアップグレードなどいくつかの機能については、
最新の &man.freebsd-update.8; と &os; 6.3 以降を必要とします。
新しいリリースにアップデートする前に、現在のリリースのアナウンスに目を通し、
アップデートしようとしているリリースに対して重要な情報がないかどうかを確認してください。
これらのアナウンスは
<ulink url="http://www.FreeBSD.org/ja/releases/"></ulink>
で確認できます。</para>
</note>
<para>もし <command>crontab</command> の中に
<command>freebsd-update</command> の機能が含まれていたら、
以下の作業を行うまでは無効にしておいてください。</para>
<sect2>
<title>設定ファイル</title>
<para>設定ファイル <filename>/etc/freebsd-update.conf</filename>
をきめ細かく調整して、アップデートプロセスを制御するユーザもいます。
この作業は良く文書化されていますが、
以下のいくつかの項目については説明が必要でしょう。</para>
<programlisting># Components of the base system which should be kept updated.
Components src world kernel</programlisting>
<para>このパラメータは、&os; のどの部分を最新に維持するかを設定します。
デフォルトではソースコード、ベースシステム全体、そしてカーネルをアップデートします。
Components に設定できる項目は、インストール時に選択できるものと同じです。
たとえば、ここで "world/games" を追加すると、
game にパッチが当たるようになります。
"src/bin" を追加すると、<filename class="directory">src/bin</filename>
ソースコードのアップデートを許可します。</para>
<para>この部分についてはデフォルトのままにしておき、
アップデートしたい項目をユーザがリストに加える形にするのがベストでしょう。
ソースコードとバイナリが同期していないと、
悲惨な結果をもたらす可能性があります。</para>
<programlisting># Paths which start with anything matching an entry in an IgnorePaths
# statement will be ignored.
IgnorePaths</programlisting>
<para>アップデートで変更されてはいけない特定のディレクトリ、
<filename class="directory">/bin</filename> や
<filename class="directory">/sbin</filename> 等のパスを追加してください。
このオプションは、ローカルの変更点を <command>freebsd-update</command>
が上書きすることを防ぐ目的にも利用できます。</para>
<programlisting># 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</programlisting>
<para>指定したディレクトリにある設定ファイルが、
ローカルで変更されていない場合のみアップデートします。
ユーザがこれらのファイルを変更していると、
これらのファイルの自動アップデートは無効になります。
他に、<literal>KeepModifiedMetadata</literal>
という別のオプションが存在します。
このオプションは、<command>freebsd-update</command>
がマージ中に変更点を保存するようにします。</para>
<programlisting># 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/</programlisting>
<para><command>freebsd-update</command>
がマージすべきファイルが存在するディレクトリの一覧です。
ファイルのマージのプロセスは、
&man.mergemaster.8; と同様 &man.diff.1; パッチの連続です。
マージを承認するか、エディタを起動するか、
<command>freebsd-update</command>
を中断するかどうかを選んでください。
もし、心配な点があれば、
<filename class="directory">/etc</filename>
をバックアップしてからマージを承認してください。
<command>mergemaster</command> コマンドの詳細な情報については、
<xref linkend="mergemaster"> で確認してください。</para>
<programlisting># Directory in which to store downloaded updates and temporary
# files used by &os; Update.
# WorkDir /var/db/freebsd-update</programlisting>
<para>ここではすべてのパッチや一次ファイルを置くディレクトリを指定しています。
バージョンをアップグレードするのであれば、
この場所には少なくともギガバイトの空き容量が必要です。</para>
<programlisting># 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</programlisting>
<para><literal>yes</literal> に設定すると、
<command>freebsd-update</command> は
<literal>Components</literal> のリストが完全に正しいと判断し、
このリスト以外の変更点については取り扱いません。
<command>freebsd-update</command> は、効率的に
<literal>Components</literal>
リストに属するにファイルをアップデートします。</para>
</sect2>
<sect2>
<title>セキュリティパッチ</title>
<para>セキュリティパッチはリモートマシンに保存されており、
以下のコマンドを実行すると、ダウンロードしてインストールします。</para>
<screen>&prompt.root; <userinput>freebsd-update fetch</userinput>
&prompt.root; <userinput>freebsd-update install</userinput></screen>
<para>カーネルにパッチが当たった場合には、システムを再起動する必要があります。
すべてがうまく実行でき、システムにパッチが当たるようであれば、
毎晩の &man.cron.8; ジョブとして <command>freebsd-update</command>
を実行してもよいでしょう。
このタスクを実行できるようにするには、
以下のエントリを <filename>/etc/crobntab</filename> に追加してください。</para>
<programlisting>@daily root freebsd-update cron</programlisting>
<para>このエントリは、毎日一度
<command>freebsd-update</command> を実行することを意味します。
このように <option>cron</option> に記述すると、
<command>freebsd-update</command>
はアップデートが存在するときだけ確認します。
パッチが存在すると、
自動的にローカルディスクにダウンロードされますが、適用はされません。
ダウンロードされたパッチを手動でインストールすることが必要で、このことは
<username>root</username> 宛てにメールで通知されます。</para>
<para>うまく行かなかった場合には、<command>freebsd-update</command>
を以下のように実行することで最後の変更までロールバックできます。</para>
<screen>&prompt.root; <userinput>freebsd-update rollback</userinput></screen>
<para>カーネルまたはカーネルモジュールがアップデートされた場合には、
完了後にシステムを再起動してください。
この作業によって、&os; がバイナリをメモリに読み込みます。</para>
<para><command>freebsd-update</command>
ユーティリティが自動的にアップデートするカーネルは
<literal>GENERIC</literal> のみです。
カスタムカーネルを使っている場合には、<command>freebsd-update</command>
が他の部分をアップデートした後、
カーネルを再構築し、もう一度インストールする必要があります。
<literal>GENERIC</literal> カーネルが <filename
class="directory">/boot/GENERIC</filename>
に存在する場合には、
<command>freebsd-update</command> により
(現在のシステムで実行されているカーネルでなくとも)
アップデートされます。</para>
<note>
<para><literal>GENERIC</literal> カーネルを、常に <filename
class="directory">/boot/GENERIC</filename>
に置いておくことは良い考えです。
さまざまな問題を解決する際や
<xref linkend="freebsdupdate-upgrade"> に説明されているように、
<command>freebsd-update</command>
を用いたバージョンのアップグレードの際に助けとなります。</para>
</note>
<para><filename>/etc/freebsd-update.conf</filename>
のデフォルトの設定を変更しない限り、
<command>freebsd-update</command> は、
他の更新と共にカーネルソースをアップデートします。
新しいカスタムカーネルの再構築と再インストールは、
通常通り行うことができます。</para>
<note>
<para><command>freebsd-update</command> は、
常にカーネルをアップデートするとは限りません。
<command>freebsd-update install</command>
によってカーネルソースが変更されなかった場合には、
カスタムカーネルを再構築する必要はありません。
しかしながら <command>freebsd-update</command> は、
<filename>/usr/src/sys/conf/newvers.sh</filename>
ファイルを常にアップデートします。
これは、現在のシステムのパッチレベル (<command>uname -r</command> が
<literal>-p</literal> で表示する番号) を示す際に参照されるファイルです。
そのため、何も変更されていない場合でも、カスタムカーネルを再構築することにより、
&man.uname.1; がシステムの正確なパッチレベルを報告するようになります。
各システムにインストールされているアップデートをすばやく把握できるようになるので、
特に複数のシステムを管理するときに助けとなります。</para>
</note>
</sect2>
<sect2 id="freebsdupdate-upgrade">
<title>メジャーおよびマイナーアップグレード</title>
<para>このプロセスでは、古いオブジェクトファイルやライブラリが削除され、
これらに依存する多くのサードパーティ製アプリケーションに影響を与える可能性があります。
インストールされているすべての ports を削除して再インストールするか、
後で、<filename role="package">ports-mgmt/portupgrade</filename>
ユーティリティを使ってアップグレードすることが推奨されています。
試験的にビルドを行いたいと思っているユーザは、
以下のコマンドを実行してください。</para>
<screen>&prompt.root; <userinput>portupgrade -af</userinput></screen>
<para>このコマンドは、すべての ports を適切に再インストールしようとします。
<makevar>BATCH</makevar> 環境変数を
<literal>yes</literal> に設定しておくと、
アップデートプロセスの途中の質問に対し
<literal>yes</literal> と答えるようになるので、
ビルドプロセスでの手動操作を省略できます。</para>
<para>カスタムカーネルを使用している場合には、
アップグレードのプロセスは幾分複雑となります。
<literal>GENERIC</literal> カーネルが <filename
class="directory">/boot/GENERIC</filename>
に置かれている必要があります。
もし <literal>GENERIC</literal>
カーネルがシステムに存在しない場合には、
以下のどれかの方法で用意してください。</para>
<itemizedlist>
<listitem>
<para>ただ一度だけカスタムカーネルを構築したのであれば、
<filename class="directory">/boot/kernel.old</filename>
カーネルは <literal>GENERIC</literal> そのものです。
ただ単にこのディレクトリの名前を
<filename class="directory">/boot/GENERIC</filename>
へと変更してください。</para>
</listitem>
<listitem>
<para>コンピュータへの物理的なアクセスが可能であれば、
CD-ROM から <literal>GENERIC</literal>
カーネルをインストールできます。
インストールディスクを挿入して、以下のコマンドを実行してください。</para>
<screen>&prompt.root; <userinput>mount /cdrom</userinput>
&prompt.root; <userinput>cd /cdrom/<replaceable>X.Y-RELEASE</replaceable>/kernels</userinput>
&prompt.root; <userinput>./install.sh GENERIC</userinput></screen>
<para>ここで <filename
class="directory"><replaceable>X.Y-RELEASE</replaceable></filename>
を実際のリリース番号に置き換えてください。
<literal>GENERIC</literal> は、デフォルトで <filename
class="directory">/boot/GENERIC</filename>
にインストールされます。</para>
</listitem>
<listitem>
<para>上記の方法が失敗するのであれば、
<literal>GENERIC</literal> カーネルをソースから再構築して、
インストールしてください。</para>
<screen>&prompt.root; <userinput>cd /usr/src</userinput>
&prompt.root; <userinput>env DESTDIR=/boot/GENERIC make kernel</userinput>
&prompt.root; <userinput>mv /boot/GENERIC/boot/kernel/* /boot/GENERIC</userinput>
&prompt.root; <userinput>rm -rf /boot/GENERIC/boot</userinput></screen>
<para><command>freebsd-update</command> は、このカーネルを
<literal>GENERIC</literal> として扱います。
<literal>GENERIC</literal> コンフィグレーションファイルは、
とにかく変更してはいけません。
また、特別なオプションを指定しない
(<filename>/etc/make.conf</filename> が空であることが望ましい)
で構築してください。</para>
</listitem>
</itemizedlist>
<para>この時点で <literal>GENERIC</literal>
カーネルで再起動する必要はありません。</para>
<para><command>freebsd-update</command>
によるメジャー、またはマイナーバージョンのアップデートでは、
リリースバージョンをターゲットにして実行します。
たとえば、&os; 6.4 にアップデートするには以下のコマンドを実行してください。</para>
<screen>&prompt.root; <userinput>freebsd-update -r 6.4-RELEASE upgrade</userinput></screen>
<para>コマンドを実行すると、<command>freebsd-update</command>
は設定ファイルと現在のシステムを評価し、
システムをアップデートするために必要な情報を収集します。
画面には、どのコンポーネントが認識され、
どのコンポーネントが認識されていないかといったリストが表示されます。
たとえば以下のように表示されます。</para>
<screen>Looking up update.FreeBSD.org mirrors... 1 mirrors found.
Fetching metadata signature for 6.3-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</screen>
<para>ここで、<command>freebsd-update</command>
はアップグレードに必要なすべてのファイルをダウンロードします。
何をインストールし、どのように進むかといった質問をされることもあります。</para>
<para>カスタムカーネルを使っていると、
上記のステップで以下のような警告が表示されます。</para>
<screen>WARNING: This system is running a "<replaceable>MYKERNEL</replaceable>" kernel, which is not a
kernel configuration distributed as part of FreeBSD 6.3-RELEASE.
This kernel will not be updated: you MUST update the kernel manually
before running "/usr/sbin/freebsd-update install"</screen>
<para>この時点ではこの警告を無視してもかまいません。
アップデートされた <literal>GENERIC</literal> カーネルは、
アップグレードプロセスの途中で利用されます。</para>
<para>ローカルシステムへすべてのパッチがダウンロードされたら、
次にパッチが適用されます。
このプロセスにかかる時間はコンピュータの性能とワークロードに依存します。
その後、設定ファイルがマージされます。
このプロセスでは、ファイルをマージするか、
画面上にエディタを立ち上げて手動でマージするかを尋ねられます。
プロセスごとに、マージに成功した情報がユーザに示されます。
マージに失敗したり、無視した場合には、プロセスが中断します。
<filename class="directory">/etc</filename> のバックアップを取り、
<filename>master.passwd</filename> や <filename>group</filename>
のような重要なファイルを後で手動でマージするユーザもいるでしょう。</para>
<note>
<para>すべてのパッチは別のディレクトリでマージされており、
まだ、システムには反映されていません。
ユーザによる変更点のコミットは必要ありません。</para>
</note>
<para>このプロセスが終わったら、
以下のコマンドを用いて、アップグレードをディスクに反映してください。</para>
<screen>&prompt.root; <userinput>freebsd-update install</userinput></screen>
<para>パッチは最初にカーネルとカーネルモジュールに対して当てられます。
ここでコンピュータを再起動する必要があります。
システムがカスタムカーネルを実行していた場合には、
&man.nextboot.8; コマンドを使って次回の再起動時のカーネルを
(アップデートされた) <filename
class="directory">/boot/GENERIC</filename> に変更してください。</para>
<screen>&prompt.root; <userinput>nextboot -k GENERIC</userinput></screen>
<warning>
<para><literal>GENERIC</literal> カーネルで再起動する前に、
システムが適切に起動するために必要な
(もしコンピュータにリモートでアクセスしてアップデートしていたのであれば、
ネットワーク接続に必要な)
すべてのドライバが含まれていることを確認してください。
特に、これまでに実行していたカスタムカーネルが
(通常はカーネルモジュールとして提供されている)
ビルド済みの機能を含んでいるのであれば、
これらのモジュールを一時的に <filename>/boot/loader.conf</filename>
の機能を用いて、
<literal>GENERIC</literal> へと読み込んでください。
アップグレードプロセスが終わるまでは、
重要ではないサービスを無効にし、
ディスクやネットワークのマウントなどは避けてください。</para>
</warning>
<para>アップデートされたカーネルでコンピュータを再起動してください。</para>
<screen>&prompt.root; <userinput>shutdown -r now</userinput></screen>
<para>システムがオンラインに戻ったら、
<command>freebsd-update</command> を再び実行する必要があります。
アップデートプロセスの状態は保存されているので、
<command>freebsd-update</command> を実行すると、最初からではなく、
古い共有ライブラリとオブジェクトファイルを削除するプロセスから始まります。
このステージを続行するには、以下のコマンドを実行してください。</para>
<screen>&prompt.root; <userinput>freebsd-update install</userinput></screen>
<note>
<para>使用しているライブラリのバージョン番号の付けられ方によって、
3 つのインストールフェーズが 2 つになる場合もあります。</para>
</note>
<para>すべてのサードパーティ製のソフトウェアを再構築し、
再インストールする必要があります。
この作業が必要なのは、インストールされているソフトウェアが、
アップグレードの際に削除されたライブラリに依存している可能性があるためです。
<filename role="package">ports-mgmt/portupgrade</filename>
コマンドは、このプロセスを自動化します。
以下のコマンドで、このプロセスを開始します。</para>
<screen>&prompt.root; <userinput>portupgrade -f ruby</userinput>
&prompt.root; <userinput>rm /var/db/pkg/pkgdb.db</userinput>
&prompt.root; <userinput>portupgrade -f ruby18-bdb</userinput>
&prompt.root; <userinput>rm /var/db/pkg/pkgdb.db /usr/ports/INDEX-*.db</userinput>
&prompt.root; <userinput>portupgrade -af</userinput></screen>
<para>この作業の終了後、最後にもう一度
<command>freebsd-update</command>
を実行すると、アップグレードのプロセスが完了します。
以下のコマンドですべてのアップグレードプロセスのやり残し作業が行われます。</para>
<screen>&prompt.root; <userinput>freebsd-update install</userinput></screen>
<para><literal>GENERIC</literal>
カーネルを一時的に読み込んでいたのであれば、
ここで、通常の方法を用いて新しいカスタムを構築し、インストールしてください。</para>
<para>コンピュータを再起動し、新しい &os; を立ち上げてください。
これでアップグレードのプロセスは完了です。</para>
</sect2>
<sect2>
<title>システムの状態の比較</title>
<para><command>freebsd-update</command> ユーティリティを用いて、
インストールされている &os; の状態と、
正しく動作することが分かっている状態とを比較できます。
このオプションは、システムのユーティリティ、ライブラリ、
設定ファイルを評価します。
比較を行うには、以下のコマンドを実行してください。</para>
<screen>&prompt.root; <userinput>freebsd-update IDS >> outfile.ids</userinput></screen>
<warning>
<para>コマンドライン名は <acronym>IDS</acronym> ですが、
<filename role="package">security/snort</filename>
のような侵入検知システムの置き換えになるものではありません。
<command>freebsd-update</command> はデータをディスクに保存するので、
明らかに不正な変更が行われる可能性があります。
この不正な変更の可能性は、
<varname>kern.securelevel</varname> の設定と、
<command>freebsd-update</command> のデータを使用しないときに、
読み取りのみの許可属性に設定されているファイルシステムに置くことで低くすることができますが、
よりよい解決方法は、
<acronym>DVD</acronym>
または安全に保存されている外部 <acronym>USB</acronym>
ディスクのような安全なディスクとシステムを比較することです。</para>
</warning>
<para>これで、システムは検査されます。そして、
リリースファイルの &man.sha256.1;
ハッシュ値と現在インストールされているファイルの値がファイルの一覧と共に表示されます。
これが <filename>outfile.ids</filename> ファイルに出力を送る理由です。
目で比較するにはとても早くスクロールし、
コンソールバッファをいっぱいに満たしてしまいます。</para>
<para>これらの行は極めて長いのですが、出力形式は簡単にすぐに解析できます。
たとえば、これらのリリースで異なっているすべてのファイルを知りたいのであれば、
以下のコマンドを実行してください。</para>
<screen>&prompt.root; <userinput>cat outfile.ids | awk '{ print $1 }' | more</userinput>
/etc/master.passwd
/etc/motd
/etc/passwd
/etc/pf.conf</screen>
<para>上の表示例では出力は切り捨てられており、
実際にはもっと多くのファイルが存在します。
これらのファイルには、運用中に変更されるファイルがあります。
たとえば、<filename>/etc/passwd</filename>
はユーザがシステムに追加されると変更されます。
また、カーネルモジュールのようなファイルがあります。
これらは <command>freebsd-update</command>
によりアップデートされます。
このような特別なファイルやディレクトリを除外するには、
それらを <filename>/etc/freebsd-update.conf</filename> の
<literal>IDSIgnorePaths</literal> オプションに追加してください。</para>
<para>以前に議論した方法とは別に、
このシステムを入念なアップグレード方法の一部として用いることができます。</para>
</sect2>
</sect1>
<sect1 id="updating-upgrading-portsnap">
<sect1info>
<authorgroup>
<author>
<firstname>Tom</firstname>
<surname>Rhodes</surname>
<contrib>寄稿: </contrib>
</author>
</authorgroup>
<authorgroup>
<author>
<firstname>Colin</firstname>
<surname>Percival</surname>
<contrib>ベースとなったノートの提供: </contrib>
</author>
</authorgroup>
</sect1info>
<title>Portsnap: Ports Collection アップデートツール</title>
<indexterm><primary>アップデートとアップグレード</primary></indexterm>
<indexterm>
<primary>Portsnap</primary>
<see>アップデートとアップグレード</see>
</indexterm>
<para>&os; のベースシステムには、&man.portsnap.8; と呼ばれる
Ports Collection のアップデートユーティリティがあります。
実行すると、リモートサイトに接続し、セキュリティキーを検証し、
Ports Collection をダウンロードします。
セキュリティキーは、
ダウンロードしたすべてのファイルがダウンロード中に変更されていないことの検証に用いられます。
最新の Ports Collection ファイルをダウンロードするには、
以下のコマンドを実行してください。</para>
<screen>&prompt.root; <userinput>portsnap fetch</userinput>
Looking up portsnap.FreeBSD.org mirrors... 3 mirrors found.
Fetching snapshot tag from portsnap1.FreeBSD.org... done.
Fetching snapshot metadata... done.
Updating from Wed Aug 6 18:00:22 EDT 2008 to Sat Aug 30 20:24:11 EDT 2008.
Fetching 3 metadata patches.. done.
Applying metadata patches... done.
Fetching 3 metadata files... done.
Fetching 90 patches.....10....20....30....40....50....60....70....80....90. done.
Applying patches... done.
Fetching 133 new ports or files... done.</screen>
<para>この例では、&man.portsnap.8;
が現在の ports に対するパッチを見つけ、検証したことを示しています。
また、ユーティリティは以前に実行していることも示しています。
もし初めて実行したのであれば、Ports Collection のダウンロードのみが行われます。</para>
<para>&man.portsnap.8; が <command>fetch</command> に成功すると、
検証を通った Ports Collection と、
それに続くパッチがローカルシステムに存在します。
このアップデートファイルをインストールするには以下のように入力してください。</para>
<screen>&prompt.root; <userinput>portsnap extract</userinput>
/usr/ports/.cvsignore
/usr/ports/CHANGES
/usr/ports/COPYRIGHT
/usr/ports/GIDs
/usr/ports/KNOBS
/usr/ports/LEGAL
/usr/ports/MOVED
/usr/ports/Makefile
/usr/ports/Mk/bsd.apache.mk
/usr/ports/Mk/bsd.autotools.mk
/usr/ports/Mk/bsd.cmake.mk
<replaceable>...</replaceable></screen>
<para>これでアップデートプロセスは完了しました。
更新された Ports Collection を使って、
アプリケーションをインストールしたり、
アップグレードできます。</para>
<para>このプロセスを連続して行うには、以下のコマンドを実行してください。</para>
<screen>&prompt.root; <userinput>portsnap fetch update</userinput></screen>
</sect1>
<sect1 id="current-stable">
<title>開発ブランチを追いかける</title>
<indexterm><primary>-CURRENT</primary></indexterm>
<indexterm><primary>-STABLE</primary></indexterm>
<para>FreeBSD には二つの開発ブランチがあります。
それは &os.current; と &os.stable; です。
この章ではそれぞれについて簡単に説明し、
どのようにしてあなたのシステムを対応するツリーに対して、
どうやって常に最新の状態に保つかについて扱います。
まずは &os.current;、次に &os.stable; について説明します。</para>
<para><emphasis>訳: &a.hanai;、1996 年 11 月 6 日</emphasis></para>
<sect2 id="current">
<title>最新の &os; を追いかける</title>
<para>これを読む前に、
心にとめておいて欲しいことがあります。
&os.current; とは &os; の開発の <quote>最前線</quote> だということです。
&os.current; のユーザは高い技術力を持つことが要求され、
自分のシステムが抱える困難な問題を自力で解決できなければなりません。
もし &os; を使い始めたばかりなら、
これを運用することについて十分検討を重ねた方が良いでしょう。</para>
<sect3>
<title>&os.current; ってなに?</title>
<para>&os.current; は &os; の最新の、そして作業進行中のソースです。
中には現在開発途上のソフトウェア、
実験的な変更、あるいは過渡的な機能などが含まれています。
また、この中に入っている機能がすべて、
次の公式リリースに入るとは限りません。
&os.current; をソースからほぼ毎日コンパイルしている人は
たくさんいますが、
時期によってはコンパイルさえできない状態になっていることもあります。
これらの問題は可能な限り迅速に解決されますが、
&os.current; が不幸をもたらすか、
それとも非常に素晴らしい機能をもたらすかは、
まさにソースコードを手に入れた瞬間によるのです!</para>
</sect3>
<sect3>
<title>誰が &os.current; を必要としてるの?</title>
<para>&os.current; は、
次の三つの重要なグループを対象としています。</para>
<orderedlist>
<listitem>
<para>ソースツリーのある部分に関して活発に作業している
&os; コミュニティのメンバ。
彼らにとっては <quote>最新のもの</quote> にしておくのが
絶対に必要なことなのです。</para>
</listitem>
<listitem>
<para>活発にテストしている &os; コミュニティのメンバ。
彼らは、&os.current;
が <quote>健全である</quote> ことを可能な限り保証するために、
種々の問題を解決するのに時間を惜しまない人々です。
彼らはまた、様々な変更に関する提案や
&os; の大まかな方向付けを行ないたいと思っている
人々でもあり、それを実装するためのパッチを提示します。</para>
</listitem>
<listitem>
<para>単に、様々な事に目を向け、参考のために
(たとえば動かすためではなく<emphasis>読むため</emphasis>に)
最新のソースを使いたいと思っている人々。
これらの人々はまた、
時々コメントやコードを寄稿してくれます。</para>
</listitem>
</orderedlist>
</sect3>
<sect3>
<title>&os.current;
に期待しては<emphasis>いけない</emphasis>ことは?</title>
<orderedlist>
<listitem>
<para>なにか新しくカッコイイモノがあると聞き、
自分の周囲では一番にそれを持ちたいがために、
リリース前のコードの断片を追いかけること。
新しい機能を得るために一番乗りになるということは、
新しいバグに最初にぶち当たるということです。</para>
</listitem>
<listitem>
<para>バグを修正するための素早い方法。
いかなるバージョンの &os.current; であれ、
元からあるバグを修正するのと同じく、
新しいバグを生み出すおそれがあります。</para>
</listitem>
<listitem>
<para><quote>公式にサポートする</quote> こと。
わたしたちは 3 つの <quote>公式な</quote>
&os.current; のグループの一つに、
実際に属する人々を助けるのにベストを尽くしますが、
技術的なサポートを行なうには、単に「時間が足りない」のです。
これはわたしたちが外の人を助けるの好まない、
ケチで意地悪い人間だということではありません
(もしそうなら &os; なんてやっていません)。
わたしたちは一日に何百通ものメッセージに答え、
<emphasis>かつ</emphasis> &os;
の作業をすることなど出来ない!
というだけのことなのです。
もし、&os; の改良作業を続けるか、
それとも実験的なコードに関するたくさんの質問に答えるか、
という二つの選択を迫られたら、開発者は前者を選ぶでしょう。</para>
</listitem>
</orderedlist>
</sect3>
<sect3>
<title>&os.current; を使う</title>
<indexterm>
<primary>-CURRENT</primary>
<secondary>使用</secondary>
</indexterm>
<orderedlist>
<listitem>
<para>&a.current.name; と &a.svn-src-head.name; メーリングリスト
に加わってください。
これは単に良い考えであるというだけでなく、
<emphasis>必須の</emphasis>ことなのです。
もし
<emphasis>&a.current.name;</emphasis>
メーリングリストに入っていなければ、
さまざまな人がシステムの現在の状態について
述べているコメントを見ることは決してありませんし、
従って他の人が既に見つけて解決している
多くの問題に戸惑ってあきらめてしまうでしょう。
さらに言うと、システムを正常に保つための
重要な情報を見逃してしまう可能性もあります。</para>
<para>&a.svn-src-head.name; メーリングリストでは、
それぞれの変更についての
commit ログを見ることができます。
また、それに関して起こり得る副作用の情報を得ることができますので、
参加する価値のあるメーリングリストです。</para>
<para>これらの、もしくは他のメーリングリストに入るには、
&a.mailman.lists.link; をたどって参加したいメーリングリ
ストをクリックしてください。残りの手順の説明はそこにあります。
もし、ソースツリー全体の変更点を追いかけることに興味があれば、
&a.svn-src-all.name; メーリングリストを購読してください。</para>
</listitem>
<listitem>
<para>&os; <link linkend="mirrors">ミラーサイト</link> か
らのソースの入手。以下の 2 つの方法のいずれかでできます。</para>
<orderedlist>
<indexterm>
<primary><command>cvsup</command></primary>
</indexterm>
<indexterm>
<primary><command>cron</command></primary>
</indexterm>
<indexterm>
<primary>-CURRENT</primary>
<secondary><application>CVSup</application> を使った同期</secondary>
</indexterm>
<listitem>
<para><link linkend="cvsup">cvsup</link> を
<filename>/usr/share/examples/cvsup</filename> にある
<filename>standard-supfile</filename> という名称の
<filename>supfile</filename> と合わせて使ってください。
これがもっとも推奨される方法です。
なぜなら、<command>cvsup</command> によって一度全体を入手し、
後は変更されたところだけを入手することができるからです。
多くの人が <command>cvsup</command> を
<command>cron</command> から起動して、自動的にソースコー
ドを最新のものに保っています。
上に挙げた見本の <filename>supfile</filename> をカス
タマイズするとともに、あなたの環境に合わせて <link
linkend="cvsup">cvsup</link> を設定する必要があります。</para>
<note>
<para>サンプルファイルの <filename>standard-supfile</filename>
は、&os; の特定のセキュリティブランチを追いかけるためのものであり、
&os.current; 用ではありません。
このファイルの中にある次の行を</para>
<programlisting>*default release=cvs tag=RELENG_<replaceable>X</replaceable>_<replaceable>Y</replaceable></programlisting>
<para>以下に置き換えてください。</para>
<programlisting>*default release=cvs tag=.</programlisting>
<para>使用可能なタグに関する詳細な説明は、
ハンドブックの <link
linkend="cvs-tags">CVS タグ</link> の章にあります。</para>
</note>
</listitem>
<indexterm>
<primary>-CURRENT</primary>
<secondary>CTM を使った同期</secondary>
</indexterm>
<listitem>
<para><application><link linkend="ctm">CTM</link></application>を用いる。
(接続料が高額だったり、email でのアクセスしかできないような)
あまり良質でない TCP/IP 接続の場合には、<application>CTM</application>
を利用すると良いでしょう。ただし、
これには多くの手間がかかりますし、
壊れたファイルを受けとってしまう可能性もあります。
そのため、最近ではあまり使われなくなっており、
長い間使用できなくなってしまう事態が発生する可能性があります
(訳注: 保守する人が少ないためです)。
9600 bps 以上の速度で接続しているなら、
<application><link linkend="cvsup">CVSup</link></application>
を利用されることを推奨します。
</para>
</listitem>
</orderedlist>
</listitem>
<listitem>
<para>もし、ソースを眺めるだけでなく、
走らせるために入手しているのであれば、
一部だけ選ぶのではなく、&os.current;
の<emphasis>全体</emphasis>を手に入れてください。
なぜなら、ソースのさまざまな部分が他の部分の更新に依存しており、
一部のみをコンパイルしようとすると、
ほぼ間違いなくトラブルを起こすからです。</para>
<indexterm>
<primary>-CURRENT</primary>
<secondary>コンパイル</secondary>
</indexterm>
<para>&os.current; をコンパイルする前に
<filename>/usr/src</filename> にある Makefile
を良く読んでください。
アップグレードの処理の一部として、
少なくとも一回は最初に
<link linkend="makeworld">新しいカーネルをインストールし
て、world を再構築</link> すべきでしょう。&a.current; と
<filename>/usr/src/UPDATING</filename> を読めば、次のリ
リースへ向けて移ってゆくに当たって時々必要となる既存シス
テムからの新システムの構築手順についての最新情報が得られ
るでしょう。</para>
</listitem>
<listitem>
<para>アクティブになってください!
もし &os.current;
を走らせているなら、わたしたちはそれに関するコメント、
特に拡張やバグ潰しに関する提案を欲しています。
コードを伴う提案はもっとも歓迎されるものです!</para>
</listitem>
</orderedlist>
</sect3>
</sect2>
<sect2 id="stable">
<title>安定版の &os; を使う</title>
<para><emphasis>訳: &a.jp.iwasaki;</emphasis></para>
<sect3>
<title>&os.stable; ってなに?</title>
<indexterm><primary>-STABLE</primary></indexterm>
<para>&os.stable; とは定期的に公開されるリリースを作成するための開発ブランチです。
このブランチに加えられる変更は原則として、
事前に &os.current; で試験ずみであるという特徴があります。
ただ<emphasis>そうであっても</emphasis>、
これは開発用ブランチの一つであるということに注意してください。
つまり、ある時点における &os.stable; のソースが
どんな場合にも使えるものであるとは限らないということです。
このブランチはもう一つの開発の流れというだけであって、
エンドユーザ向けのものではありません。</para>
</sect3>
<sect3>
<title>誰が &os.stable; を必要としているの?</title>
<para>もしあなたが FreeBSD の開発過程に興味があるとか、
それに対する貢献を考えていて、特にそれが
次回の <quote>ポイント</quote> リリースに関係するもの
であるなら &os.stable; を追うことを考えると良いでしょう。</para>
<para>セキュリティ上の修正は &os.stable; ブランチに対して行なわれますが、
そのために &os.stable; を追う<emphasis>必要</emphasis>はありません。
すべての FreeBSD セキュリティ勧告には
影響のあるリリースで問題点を修正する方法が説明されており
<footnote><para>これは正確ではありません。
実際わたしたちは何年もの間古いリリースの FreeBSD
をサポートしてはいるのですが、
永遠にサポートし続けることはできません。
現時点での古いリリースの FreeBSD のセキュリティポリシーの全説明を知るには、
<ulink
url="&url.base;/security/">http://www.FreeBSD.org/security/</ulink>
を参照してください。</para>
</footnote>
、
セキュリティ上の理由のみから開発用ブランチ全体を追いかけることは、
同時に望ましくない変更点まで取り込んでしまう可能性があるからです。</para>
<para>わたしたちは &os.stable; ブランチがいつも安定に動作するように
努めていますが、それが保証されているというわけではありません。
また、コードは &os.stable; に加えられる前に
&os.current; で開発されるのですが、&os.stable; のユーザは
&os.current; よりも多いため、&os.current; で発見されなかった
バグが &os.stable; で発見され、時々それが問題となることがあるのは
避けることができません。</para>
<para>このような理由から、わたしたちは盲目的に &os.stable;
を追いかけることを推奨<emphasis>しません</emphasis>。
特に、最初に開発環境でコードを十分に試験せずに
プロダクション品質が要求されるサーバを &os.stable;
にアップグレードしてはいけません。</para>
<para>もしそうするための資源的な余裕がない場合は、
リリース間のバイナリアップデート機能を利用して、
最新の FreeBSD リリースを使うことを推奨します。</para>
</sect3>
<sect3>
<title>&os.stable; を使う</title>
<indexterm>
<primary>-STABLE</primary>
<secondary>利用する</secondary>
</indexterm>
<orderedlist>
<listitem>
<para>&a.stable.name; メーリングリストに加わってください。
このメーリングリストでは、
&os.stable; の構築に関連する事柄や、
その他の注意すべき点 に関する情報が流れています。
また開発者は議論の余地がある修正や変更を考えている場合に、
このメーリングリストで公表し、
提案された変更に関して問題が生じるかどうかを返答する機会をユーザに与えます。</para>
<para>追いかけているブランチに関連する <application>SVN</application>
メーリングリストに参加してください。
たとえば、7-STABLE ブランチを追いかけているのであれば、
&a.svn-src-stable-7.name; メーリングリストに参加してください。
変更がなされるごとに作成される commit log やそれに伴う
起こりうる副作用についての情報を読むことができます。</para>
<para>これらの、もしくは他のメーリングリストに入るには、
&a.mailman.lists.link; をたどって参加したいメーリングリ
ストをクリックしてください。残りの手順の説明はそこにあります。
もし、ソースツリー全体の変更点を追いかけることに興味があれば、
&a.svn-src-all.name; メーリングリストを購読してください。</para>
</listitem>
<listitem>
<para>もし、あなたが新しいシステムをインストールしようとしていて、
毎月公開されている &os.stable;
からビルドされたスナップショットをインストールしたいなら、
<ulink url="&url.base;/snapshots/">スナップショット</ulink>
web ページをご覧ください。
もしくは、<link linkend="mirrors">ミラーサイト</link>から最近の
&os.stable; リリースをインストールし、下記の説明に従って最新の
&os.stable; のソースコードに更新することもできます。</para>
<para>もし、既に &os; の以前のリリースが動いている場合で、
これをソースからアップグレードしようとするならば、
&os; <link linkend="mirrors">ミラーサイト</link> から簡
単に行えます。これには次の 2 つの方法があります。
</para>
<orderedlist>
<indexterm>
<primary><command>cvsup</command></primary>
</indexterm>
<indexterm>
<primary><command>cron</command></primary>
</indexterm>
<indexterm>
<primary>-STABLE</primary>
<secondary><application>CVSup</application> を使った同期</secondary>
</indexterm>
<listitem>
<para><link linkend="cvsup">cvsup</link> を
<filename>/usr/share/examples/cvsup</filename> にある
<filename>stable-supfile</filename> という名称の
<filename>supfile</filename> と合わせて使ってください。
これがもっとも推奨される方法です。
なぜなら、<command>cvsup</command> によって一度全体を入手し、
後は変更されたところだけを入手することができるからです。
多くの人が <command>cvsup</command> を
<command>cron</command> から起動して、自動的にソースコー
ドを最新のものに保っています。
上に挙げた見本の <filename>supfile</filename> をカス
タマイズするとともに、あなたの環境に合わせて <link
linkend="cvsup">cvsup</link> を設定する必要がありま
す。</para>
</listitem>
<indexterm>
<primary>-STABLE</primary>
<secondary>CTM を使って同期する</secondary>
</indexterm>
<listitem>
<para><application><link
linkend="ctm">CTM</link></application> 機能を使います。
インターネットへの接続に高速で安価な回線を利用できないのであれば、
この方法を検討してみましょう。</para>
</listitem>
</orderedlist>
</listitem>
<listitem>
<para>基本的には、
ソースに迅速でオンデマンドなアクセスが必要で、
接続のバンド幅が問題でなければ、<command>cvsup</command>
か <command>ftp</command> を使いましょう。そうで
ない場合は <application>CTM</application>
を使いましょう。</para>
</listitem>
<indexterm>
<primary>-STABLE</primary>
<secondary>構築、コンパイル</secondary>
</indexterm>
<listitem>
<para>&os.stable; をコンパイルする前に、
<filename>/usr/src</filename> にある Makefile をよ
く読んでください。
少なくとも一回はアップグレードの処理の一部として最初に
<link linkend="makeworld">新しいカーネルをインストールし
て、world を再構築</link> すべきでしょう。&a.stable; と
<filename>/usr/src/UPDATING</filename> を読めば、次のリ
リースへ向けて移ってゆくに当たって時々必要となる既存シス
テムからの新システムの構築手順についての最新情報が得られ
るでしょう。</para>
</listitem>
</orderedlist>
</sect3>
</sect2>
</sect1>
<sect1 id="synching">
<title>ソースの同期</title>
<para><emphasis>訳: &a.jp.iwasaki;、1997 年 9 月 13 日</emphasis></para>
<para>インターネット接続 (または電子メール) を使用して、
あなたの興味の対象によって &os;
プロジェクトのソースのある一部分または全体の最新を
追いかける方法は色々あります。
私たちが提供している基本的なサービスは <link
linkend="anoncvs">Anonymous CVS</link>、<link
linkend="cvsup">CVSup</link> と <link linkend="ctm">CTM</link>
です:</para>
<warning>
<para>ソースツリーの一部を最新のものに更新することは可能です。
ただし、サポートされているアップデート手順は、
ソースツリー全体を最新のものに更新して、
ユーザランド (<filename>/bin</filename> や <filename>/sbin</filename>
にあるような、ユーザが実行するプログラム全体のこと)
およびカーネルのソースから再構築することのみであることに注意してください。
カーネルだけ、あるいはユーザランドだけというように、
ソースツリーの一部を更新した場合は、問題が生じることがよくあります。
この時に発生する問題はコンパイル時のエラーからカーネルパニック、
データの破壊とさまざまです。</para>
</warning>
<indexterm>
<primary>CVS</primary>
<secondary>anonymous</secondary>
</indexterm>
<para><application>Anonymous CVS</application> と
<application>CVSup</application> は <emphasis>pull</emphasis>
同期モデルを採用しています。
<application>CVSup</application> の場合、ユーザ
(または <command>cron</command> スクリプト) が <command>cvsup</command>
を起動し、どこかにある <command>cvsupd</command>
サーバとやりとりしてファイルを
最新状態にします。
届けられる更新情報はその時点の最新のものであり、
また必要な時にだけ取り寄せられます。
興味のある特定のファイルやディレクトリに
限定して更新することも簡単にできます。
クライアント側のソースツリーの状態・
設定ファイルの指定に従い、サーバによって更新情報が
素早く生成されます。
<application>Anonymous CVS</application> は、
このプログラムがリモートの CVS リポジトリから直接変更点を
pull できるようにした &man.cvs.1; への拡張であるという点で、
<application>CVSup</application> よりもずっと単純です。
<application>CVSup</application>
は効率の点ではるかにまさっていますが、
<application>Anonymous CVS</application> の方が簡単に利用できます。
</para>
<indexterm>
<primary><application>CTM</application></primary>
</indexterm>
<para>一方、<application>CTM</application>
はあなたが持っているソースとマスタアーカイブ上に
あるそれとの対話的な比較をおこないませんし、
あるいは向こう側から変更点を pull したりもしません。
そのかわりに、前回の実行時からの変更を認識するスクリプトが
マスタ CTM マシン上で一日に数回実行され、
すべての変更を compress して通し番号を振り、
さらに電子メールで転送できるようにエンコードします
(印字可能な ASCII
キャラクタのみです)。受信した後は、
これらの <quote>CTM のデルタ</quote> は自動
的にデコード、検査してユーザのソースのコピーに変更を適用する
&man.ctm.rmail.1; によって処理可能となります。
この処理は <application>CVSup</application> や
<application>Anonymous CVS</application> よりずっと効率
的であり、<emphasis>pull</emphasis> モデルというよりむしろ
<emphasis>push</emphasis> モデルで
あるため、私たちのサーバ資源の負荷は軽くなります。</para>
<para>もちろん他のトレードオフもあります。うっかりアーカイブ
の一部を消してしまっても、<application>CVSup</application>
は壊れた部分を検出して再構築してくれます。
<application>CTM</application> はこれをやってくれませんし、
<application>Anonymous CVS</application>
はおそらく他の何よりも深く混乱してしまうことが多いでしょう。
もしソースツリーの一部を消してしまったら、(最新の CVS
<quote>ベースデルタ</quote> から) 一からやり直し、
<application>CTM</application> か <application>Anonymous CVS</application>
を使って悪い部分を消去し、再同期させることによって
すべてを再構築しなければなりません。</para>
</sect1>
<sect1 id="makeworld">
<title><quote>world</quote> の再構築</title>
<indexterm>
<primary><quote>world</quote> の再構築</primary>
</indexterm>
<para>&os; のどれか特定のバージョン (&os.stable;、&os.current; など)
について、ローカルのソースツリーを同期させたら、
そのソースツリーを使ってシステムを
再構築しなければなりません。</para>
<warning>
<title>バックアップの作成</title>
<para>システムを再構築する<emphasis>前に</emphasis>バックアップを
作成することの重要性は、いくら強調してもし過ぎると言うことはありません。
システム全体の再構築とは
(以降に書かれた手順に従っている限り) 難しい作業ではありませんが、
どんなに注意していたとしても、<!-- hrs:2000/01/12 inevitably -->
あなた自身、あるいはソースツリーで作業している他の人達に手違いがあった時には、
システムが起動しなくなってしまう状態になることがあるのです。
</para>
<para>まず、バックアップがきちんと作成されていることを確認して、
fixit フロッピーか起動可能な CD を用意してください。
多分、それを使うことはないと思いますが、
あとで後悔することのないよう、念のため用意しておきましょう。</para>
</warning>
<warning>
<title>メーリングリストに参加する</title>
<indexterm><primary>メーリングリスト</primary></indexterm>
<para>もともと、&os.stable; と &os.current; のコードブランチは、
<emphasis>開発中のもの</emphasis>です。
&os; の作業に貢献してくださっている人達も人間ですから、
時にはミスをすることだってあるでしょう。
</para>
<para>そのような間違いは、単に警告を示す見慣れない
診断メッセージをシステムが、表示するような、
全く害のないものであることもあれば、システムを起動できなくしたり、
ファイルシステムを破壊してしまうような、
恐ろしい結果を招くものかも知れません。
</para>
<para>万が一、このような問題が生じた場合、
問題の詳細と、どのようなシステムが影響を受けるかについて書かれた
<quote>注意 (heads up)</quote> の記事が
適切なメーリングリストに投稿され、そして、その問題が解決されると、
<quote>問題解決 (all clear)</quote> のアナウンス記事が同様に
投稿されます。
</para>
<para>&os.stable; や &os.current; ブランチに追随するために試そうとするのに、
&a.stable; や &a.current; を過去にさかのぼって読まないというのは、
自ら災難を招くことになるでしょう。</para>
<para><emphasis>訳注:</emphasis>
これらのメーリングリストは英語でやりとりされているため、
日本語での投稿は歓迎されません。英語でのやりとりができない人は、
<ulink url="http://www.jp.FreeBSD.org">FreeBSD 友の会</ulink>
の運営しているメーリングリストをあたってみるのがいいでしょう。
</para>
</warning>
<warning>
<title><command>make world</command> は使わないこと</title>
<para>古いドキュメントの多くが、この目的に
<command>make world</command> を使うことを薦めています。
これは、重要な手順をいくつか抜かしてしまうので、
何をしているかよく分かっていなければ使うべきではありません。
ほぼあらゆる場合において、<command>make world</command>
を実行するのは間違っており、
ここで説明されている手順を用いるべきです。</para>
</warning>
<sect2>
<title>システムを更新する正式な方法</title>
<para>システムを更新する前に、
<filename>/usr/src/UPDATING</filename> を確認してください。
このファイルには、用意したソースコードで buildworld
を行う前に必要な手順が書かれています。
その後、次の手順を踏んでください。</para>
<screen>&prompt.root; <userinput>cd /usr/src</userinput>
&prompt.root; <userinput>make buildworld</userinput>
&prompt.root; <userinput>make buildkernel</userinput>
&prompt.root; <userinput>make installkernel</userinput>
&prompt.root; <userinput>shutdown -r now</userinput></screen>
<note>
<para>まれに <maketarget>buildworld</maketarget>
の前に <command>mergemaster -p</command>
を余分に実行することが必要な場合があります。その場合は
<filename>UPDATING</filename> にそう書かれています。
&os; のメジャーバージョンをまたいで更新するのでなければ、
通常はこの手順を省略してもなんら問題ないでしょう。</para>
</note>
<para><maketarget>installkernel</maketarget>
が無事に終了したら、(たとえば、ローダのプロンプトから
<command>boot -s</command> を使って)
シングルユーザモードで立ち上げましょう。
それから、以下を実行してください。</para>
<screen>&prompt.root; <userinput>mount -a -t ufs</userinput>
&prompt.root; <userinput>mergemaster -p</userinput>
&prompt.root; <userinput>cd /usr/src</userinput>
&prompt.root; <userinput>make installworld</userinput>
&prompt.root; <userinput>mergemaster</userinput>
&prompt.root; <userinput>reboot</userinput></screen>
<warning>
<title>この後の説明を読んでください</title>
<para>上述の手順は、
とりあえず着手するための簡単なまとめにすぎません。
それぞれの手順をきちんと理解するために、
この後の節を読んでください。
カスタムカーネルを利用したいと考えているならなおさらです。</para>
</warning>
</sect2>
<sect2>
<title><filename>/usr/src/UPDATING</filename> を読む</title>
<para>何を始めるにしろ、まず最初に
<filename>/usr/src/UPDATING</filename> (もしくはあなたがソースコードを
どこにコピーしたにせよそれに相当するファイル) を読みましょう。
このファイルにはあなたが遭遇するかも知れない問題に対する重要な情報を
含んでいたり、あなたが特定のコマンドを実行しなければならなくなった時
その順序を指示したりするはずです。
<filename>UPDATING</filename> があなたが読んだ事柄と矛盾している時は
<filename>UPDATING</filename> が優先します。</para>
<important>
<para><filename>UPDATING</filename> を読むということは、前述の
適切なメーリングリストを購読する代わりにはなりません。
二つの要求は相補的なもので排他的なものではないのです。</para>
</important>
</sect2>
<sect2>
<title><filename>/etc/make.conf</filename> の確認</title>
<indexterm>
<primary><filename>make.conf</filename></primary>
</indexterm>
<para>まず、<filename>/usr/share/examples/etc/make.conf</filename> と
<filename>/etc/make.conf</filename> を調べてください。そこには
最初から標準的なものが (多くのものはコメントアウトされていますが)
含まれています。ソースからシステムを再構築するときに make が
<filename>/etc/make.conf</filename> に付け加えられた設定を使用します。
<filename>/etc/make.conf</filename> に追加された設定は <command>make
</command> を実行したときに常に使われることを覚えておいてください。
そのため、システムに必要な設定を書いておくと良いでしょう。</para>
<para>標準的なユーザならおそらく、
<filename>/usr/share/examples/etc/make.conf</filename> の
<makevar>CFLAGS</makevar> と <makevar>NO_PROFILE</makevar>
のコメントをはずしたくなるでしょう。</para>
<para>他の定義 (<makevar>COPTFLAGS</makevar>、
<makevar>NOPORTDOCS</makevar> など) の定義行についても、
コメントを外す必要があるかどうか調べておきましょう。
</para>
</sect2>
<sect2>
<title><filename>/etc</filename> にあるファイルの更新</title>
<para>
<filename>/etc</filename> ディレクトリには、
システム起動時に実行されるスクリプトだけでなく、
あなたのシステムの設定に関連する情報の大部分が
含まれています。そのディレクトリに含まれる
スクリプトは、FreeBSD のバージョンによって多少異なります。
</para>
<para>
また、設定ファイルのなかには、稼働中のシステムが日々利用している
ものもあります。実際には、<filename>/etc/group</filename>
などがそれに該当します。
</para>
<para>
<command>make installworld</command> によるインストールの段階では、
特定のユーザ名、あるいはグループが存在していることを
要求する場面があります。システムのアップグレードを行なう際には、
それらのユーザ名やグループが削除、あるいは変更されて存在していない可能性が
考えられますが、そういった場合、システムのアップグレードを
行なっている間に、問題が発生する原因になります。
<command>make buildworld</command> において、
それらのユーザ名やグループが存在するか確認が行われる場合もあります。
</para>
<para>この例の一つは、
<username>smmsp</username> ユーザが追加された時です。
&man.mtree.8; が
<filename>/var/spool/clientmqueue</filename>
を作成しようとする時、
そのユーザ名 (およびグループ)
が存在しないためにインストールに失敗してしまったのです。</para>
<para>解決方法は、buildworld の前に <option>-p</option>
オプションをつけて &man.mergemaster.8; を実行することです。
これを実行すると、<maketarget>buildworld</maketarget> や
<maketarget>installworld</maketarget>
が成功するために必要なファイルだけを比較します。
古いバージョンの <command>mergemaster</command>
を使っていて、<option>-p</option> がサポートされていない場合、
最初に実行するときソースツリーにある新しいバージョンのものを使ってください。</para>
<screen>&prompt.root; <userinput>cd /usr/src/usr.sbin/mergemaster</userinput>
&prompt.root; <userinput>./mergemaster.sh -p</userinput></screen>
<tip>
<para>もし、あなたがもっと神経質な人なら、あなたが名前を変更したり、
削除してしまったグループが所有しているファイルを、
次のようにして調べることもできます。
</para>
<screen>&prompt.root; <userinput>find / -group <replaceable>GID</replaceable> -print</userinput></screen>
<para>これは <replaceable>GID</replaceable> (グループ名もしくは数字で示されたグループ ID) で
指定されたグループが所有するすべてのファイルを表示します。
</para>
</tip>
</sect2>
<sect2 id="makeworld-singleuser">
<title>シングルユーザモードへの移行</title>
<indexterm><primary>シングルユーザモード</primary></indexterm>
<para>コンパイルは、シングルユーザモードで行なった方が良いでしょう。
そうすることで多少速度が向上する、というちょっとした利点が
あるだけでなく、システムの再インストールは重要なシステムファイル、
標準コマンド、ライブラリ、インクルードファイルなどを操作します。
稼働中のシステムに (特に他のユーザがそのシステムにログインしている時に)
そのような変更を加えることは、トラブルを引き起こす原因となります。
</para>
<indexterm><primary>マルチユーザモード</primary></indexterm>
<para>もう一つの方法として、マルチユーザモードでシステムを再構築して、
シングルユーザモードに移行してからそれをインストールする、
というのがあります。もしこのような方法で行ないたい場合は、
以下の手順を構築が完了するところまで飛ばしてください。
シングルユーザモードに移行するのを、
<maketarget>installkernel</maketarget> もしくは
<maketarget>installworld</maketarget> しなければならなくなるま
で後回しにできます。</para>
<para>稼働中のシステムでシングルユーザモードに移行するには、
スーパユーザ (root) 権限で次のコマンドを実行します。</para>
<screen>&prompt.root; <userinput>shutdown now</userinput></screen>
<para>あるいはシステムを再起動し、ブートプロンプトから
<quote>single user</quote> を選択すると、
シングルユーザモードでシステムを起動できます。
起動後、シェルプロンプトから次のように実行してください。</para>
<screen>&prompt.root; <userinput>fsck -p</userinput>
&prompt.root; <userinput>mount -u /</userinput>
&prompt.root; <userinput>mount -a -t ufs</userinput>
&prompt.root; <userinput>swapon -a</userinput></screen>
<para>これはファイルシステムをチェックした後、
<filename>/</filename> を読み書き可能にして再マウント、
<filename>/etc/fstab</filename> に指定されている、
それ以外の UFS ファイルシステムをすべてマウントしてから
スワップを有効にします。
</para>
<note>
<para>CMOS クロックが地域時間に設定されていて
GMT ではない場合 (&man.date.1; コマンドが正しい時間と地域
を表示しないなら当てはまります)、
次のコマンドを実行する必要があるかもしれません。</para>
<screen>&prompt.root; <userinput>adjkerntz -i</userinput></screen>
<para>こうすれば、
確実に地域時刻が正しく設定されます — これを怠ると、
あとあと問題になるかもしれません。</para>
</note>
</sect2>
<sect2>
<title><filename>/usr/obj</filename> の削除</title>
<para>システムが再構築される時、構築されたものは (デフォルトで)
<filename>/usr/obj</filename> 以下のディレクトリに格納され、
そのディレクトリの下は <filename>/usr/src</filename> と同じ構造となります。
</para>
<para>このディレクトリをあらかじめ削除しておくことにより、
<command>make buildworld</command> の行程にかかる時間を短縮させ、
依存問題に悩まされるようなトラブルを回避することができます。
</para>
<para><filename>/usr/obj</filename> 以下のファイルには、
変更不可 (immutable) フラグ (詳細は
&man.chflags.1; 参照) がセットされているものがある可能性があります。
そのため、まず最初にそのフラグを変更しなければなりません。
</para>
<screen>&prompt.root; <userinput>cd /usr/obj</userinput>
&prompt.root; <userinput>chflags -R noschg *</userinput>
&prompt.root; <userinput>rm -rf *</userinput></screen>
</sect2>
<sect2 id="updating-upgrading-compilebase">
<title>ベースシステムの再構築</title>
<sect3>
<title>出力メッセージの保存</title>
<para>実行される &man.make.1; からの出力は、ファイルに保存すると良いでしょう。
もし、何か障害が発生した場合、エラーメッセージのコピーを手元に残すことができます。
何が悪かったのか、あなた自身がそれから理解することはできないかも
知れませんが、&os; メーリングリストに投稿して、
誰か他の人からの助言を得るために利用することができます。</para>
<para>ファイルに保存する最も簡単な方法は、&man.script.1; コマンドを
使い、引数に出力を保存したいファイル名を指定することです。
これを make world の直前に行ない、再構築が終了してから
<userinput>exit</userinput> と入力すると、出力を保存することができます。</para>
<screen>&prompt.root; <userinput>script /var/tmp/mw.out</userinput>
Script started, output file is /var/tmp/mw.out
&prompt.root; <userinput>make TARGET</userinput>
<emphasis>… compile, compile, compile …</emphasis>
&prompt.root; <userinput>exit</userinput>
Script done, …</screen>
<para>出力を保存する場合、<filename>/tmp</filename> ディレクトリの中に
保存しては<emphasis>いけません</emphasis>。
このディレクトリは、次の再起動で削除されてしまう可能性があります。
出力の保存には、(上の例のように) <filename>/var/tmp</filename>や
<username>root</username> のホームディレクトリが適しています。</para>
</sect3>
<sect3 id="make-buildworld">
<title>ベースシステムの構築</title>
<para>まず、カレントディレクトリを <filename>/usr/src</filename> に
変更しなければなりません。次のように実行してください。</para>
<screen>&prompt.root; <userinput>cd /usr/src</userinput></screen>
<para>(もちろん、ソースコードが他のディレクトリにある場合には、
<filename>/usr/src</filename> ではなく、
ソースコードのあるディレクトリに移動してください)。
</para>
<indexterm><primary><command>make</command></primary></indexterm>
<para>
make world を行なうには、&man.make.1; コマンドを使用します。
このコマンドは、<filename>Makefile</filename> というファイルから、
FreeBSD を構成するプログラムの再構築方法や、
どういう順番でそれらを構築すべきかといったような
指示を読み込みます。
</para>
<para>
コマンドラインの一般的な書式は、次のとおりです。
</para>
<screen>&prompt.root; <userinput>make -<replaceable>x</replaceable> -D<replaceable>VARIABLE</replaceable> <replaceable>target</replaceable></userinput></screen>
<para>
この例では、<option>-<replaceable>x</replaceable></option> が
&man.make.1; に渡されるオプションになります。
どのようなオプションが利用できるかについては、マニュアルページを
参照してください。
</para>
<para>
<option>-D<replaceable>VARIABLE</replaceable></option> は、
<filename>Makefile</filename> に渡される変数であり、
この変数は <filename>Makefile</filename> の動作をコントロールします。
また、<filename>/etc/make.conf</filename> で設定される変数も
同様です。これは変数を設定するもう一つの方法として用意されています。
</para>
<screen>&prompt.root; <userinput>make -DNO_PROFILE <replaceable>target</replaceable></userinput></screen>
<para>
は、プロファイル版のライブラリを構築しないことを指定する
もう一つの記法で、<filename>/etc/make.conf</filename> 中の</para>
<programlisting>NO_PROFILE= true # Avoid compiling profiled libraries</programlisting>
<para>の行に対応します。</para>
<para>
<replaceable>target</replaceable> は、&man.make.1; に
どのように動作するのかを指示するためのものです。
各々の <filename>Makefile</filename> には、数多くの異なる
<quote>ターゲット (target)</quote> が定義されていて、
指定されたターゲットによって動作が決まります。
</para>
<para>
<filename>Makefile</filename> に書かれているターゲットには、
あなたが指定しても意味を持たないものも含まれます。
これらは、システムの再構築に必要な段階を、多くの
さらに細かい段階に分割するため、構築の過程で利用されるものです。
</para>
<para>
大抵の場合、&man.make.1; にパラメータを指定する必要はないでしょうから、
コマンドラインは次のようなものになるでしょう。
</para>
<screen>&prompt.root; <userinput>make <replaceable>target</replaceable></userinput></screen>
<para>ここで、<replaceable>target</replaceable>
は、多くのビルドオプションのどれかになります。
最初のターゲットはいつも <maketarget>buildworld</maketarget>
になるでしょう。</para>
<para>
その名前が示すように、<maketarget>buildworld</maketarget> は
<filename>/usr/obj</filename> 以下に新しい完全な
ディレクトリツリーを構築し、もう一つのターゲット
<maketarget>installworld</maketarget> は、そのツリーを
現在のマシンにインストールします。
</para>
<para>選択肢が分けられていることは、二つの理由から非常に有用です。
まず第一に、稼働中のシステムに全く影響を与えることなく、
安全にシステムの構築作業を行えることです。
構築作業は <quote>何にも依存せず独立して行なわれる</quote> ため、
<!-- hrs:2000/02/14: needs good phrase that means "self hosted" -->
マルチユーザモードで稼働中のシステムでも、何一つ
悪影響を与えずに <maketarget>buildworld</maketarget> を
実行することができます。
ただし、<maketarget>installworld</maketarget> は
シングルユーザモードで行なうことをおすすめします。
</para>
<para>
第二に、NFS マウントを利用することで、
ネットワーク上の複数のマシンをアップグレードすることが
可能な点があげられます。たとえば三台のマシン、
<hostid>A</hostid>, <hostid>B</hostid>, <hostid>C</hostid>
をアップグレードしたい場合には、まずマシン <hostid>A</hostid>
で <command>make buildworld</command> と
<command>make installworld</command> を実行します。
それから、マシン <hostid>B</hostid> とマシン <hostid>C</hostid>
でマシン <hostid>A</hostid> の
<filename>/usr/src</filename> と <filename>/usr/obj</filename> を
NFS マウントし、<command>make installworld</command> とすることで
構築済みのシステムを各マシンにインストールすることができるのです。
</para>
<para><maketarget>world</maketarget> ターゲットも利用可能ですが、
このターゲットの利用は推奨されていません。</para>
<para>次のコマンド</para>
<screen>&prompt.root; <userinput>make buildworld</userinput></screen>
<para>を実行してください。ここで <command>make</command> に
<option>-j</option> オプションをつけると、
同時にいくつかのプロセスを生成させることができます。
この機能はマルチ CPU マシンで特に効果を発揮します。
構築過程の大部分では CPU 性能の限界より
I/O 性能の限界の方が問題となるため、シングル CPU
マシンにも効果があります。</para>
<para>普通のシングル CPU マシンで以下のコマンド</para>
<screen>&prompt.root; <userinput>make -j4 buildworld</userinput></screen>
<para>を実行すると、&man.make.1; は最大 4 個までのプロセスを同時に実行します。
メーリングリストに投稿された経験的な報告によると、
4 個という指定が最も良いパフォーマンスを示すようです。</para>
<para>もし、複数の CPU を備えたマシンで SMP 設定が行なわれたカーネルを
利用しているなら、6 から 10 の間の値を設定し、速度がどれくらい
向上するか確認してみてください。</para>
</sect3>
<sect3>
<title>システムの構築にかかる時間</title>
<indexterm>
<primary><quote>world</quote> の再構築</primary>
<secondary>時間</secondary>
</indexterm>
<para>構築時間を決める要素はさまざまありますが、
十分新しいマシンであれば、
トリックや近道を使わずに普通に構築した場合、&os.stable;
の構築には 1, 2 時間しかかからないでしょう。
&os.current; の構築は、もう少し時間がかかります。</para>
</sect3>
</sect2>
<sect2>
<title>新しいカーネルの構築とインストール</title>
<indexterm>
<primary>カーネル (kernel)</primary>
<secondary>構築、コンパイル</secondary>
</indexterm>
<para>
新しいシステムの全機能を完全に利用できるようにするには、
カーネルの再構築をする必要があります。
再構築は、ある種のメモリ構造体が変更された時には特に必須であり、
&man.ps.1; や &man.top.1; のようなプログラムは、
カーネルとソースコードのバージョンが一致しないと正常に動作しないでしょう。</para>
<para>最も簡単で安全にカーネルの再構築を行なう方法は、
<filename>GENERIC</filename> を使ったカーネルを構築・インストールすることです。
<filename>GENERIC</filename> にはあなたが必要とするデバイスがすべて含まれていない
かも知れませんが、あなたのシステムをシングルユーザモードで
起動させるのに必要なものはすべて入っています。
これは新しいバージョンのシステムがきちんと動作するかどうか
調べる良い方法の一つです。
<filename>GENERIC</filename> で起動してから、
あなたがいつも使っているカーネルコンフィグレーションファイルを
使って新しいカーネルを構築することで、
システムが正常に動作しているかどうか確かめることができます。</para>
<para>&os; では、新しいカーネルを構築する前に <link
linkend="make-buildworld">build world</link> を行うことが重要です。
</para>
<note><para>カスタムカーネルを構築したい場合、既にコンフィグレー
ションファイルがあるならば、単に
<literal>KERNCONF=<replaceable>MYKERNEL</replaceable></literal>
を使ってください。</para>
<screen>&prompt.root; <userinput>cd /usr/src</userinput>
&prompt.root; <userinput>make buildkernel KERNCONF=<replaceable>MYKERNEL</replaceable></userinput>
&prompt.root; <userinput>make installkernel KERNCONF=<replaceable>MYKERNEL</replaceable></userinput></screen>
</note>
<para>なお、<literal>kern.securelevel</literal> を 1 より大きく
していて、<emphasis>かつ</emphasis>カーネルのバイナリファイル
に <literal>noschg</literal> のようなフラグを設定している場合
は、<maketarget>installkernel</maketarget> を行うのにシングル
ユーザモードに移行しなければなりません。それ以外の場合は、マル
チユーザモードでこれらのコマンドを問題なく動かせるはずです。
<literal>kern.securelevel</literal> について詳しくは
&man.init.8; を、ファイルの様々なフラグについて詳しくは
&man.chflags.1; をご覧ください。</para>
</sect2>
<sect2>
<title>シングルユーザモードで再起動する</title>
<indexterm><primary>single-user mode</primary></indexterm>
<para>
新しいカーネルが動作するかどうかテストするために、
シングルユーザモードで再起動するべきです。
シングルユーザモードでの起動は、
<xref linkend="makeworld-singleuser">
に書かれている手順に従ってください。</para>
</sect2>
<sect2 id="make-installworld">
<title>新しいシステムバイナリのインストール</title>
<para>十分最近のバージョンの &os; を
<command>make buildworld</command> で構築しているなら、
次にここで <maketarget>installworld</maketarget> を
使うことで新しいシステムバイナリのインストールを行ないます。</para>
<para>それには、以下のコマンドを実行してください。</para>
<screen>&prompt.root; <userinput>cd /usr/src</userinput>
&prompt.root; <userinput>make installworld</userinput></screen>
<note>
<para><command>make buildworld</command> でコマンドラインから
変数を指定した場合は、同じ指定を
<command>make installworld</command> のコマンドラインにも
指定しなければなりません。
ただし、オプションについてはその限りではありません。
たとえば <option>-j</option> は
<maketarget>installworld</maketarget> で絶対に使ってはいけません。</para>
<para>たとえば以下のように実行したなら、</para>
<screen>&prompt.root; <userinput>make -DNO_PROFILE buildworld</userinput></screen>
<para>以下のようにしてインストールしなければなりません。</para>
<screen>&prompt.root; <userinput>make -DNO_PROFILE installworld</userinput></screen>
<para>もしそうしなかった場合、
<command>make buildworld</command> の段階で構築されていない
プロファイル版ライブラリをインストールしようとしてしまうでしょう。</para>
</note>
</sect2>
<sect2>
<title><command>make installworld</command> で更新されないファイルの更新</title>
<para>
システムの再構築は、いくつかのディレクトリ (
特に、<filename>/etc</filename> や <filename>/var</filename> や
<filename>/usr</filename>) において、
新規に導入されたり、変更された設定ファイルによる
ファイルの更新は行なわれません。</para>
<para>
これらのファイルを更新するもっとも簡単な方法は、&man.mergemaster.8;
を使うことです。これは自分でやることも可能なので、そうしても
かまいません。
いずれの方法に従うにせよ、
必ず <filename>/etc</filename>
のバックアップを取って不測の事態に備えてください。
</para>
<sect3 id="mergemaster">
<sect3info>
<authorgroup>
<author>
<firstname>Tom</firstname>
<surname>Rhodes</surname>
<contrib>寄稿: </contrib>
</author>
</authorgroup>
</sect3info>
<title><command>mergemaster</command></title>
<indexterm><primary><command>mergemaster</command></primary></indexterm>
<para>&man.mergemaster.8; ユーティリティは Bourne シェルスクリプトで、
<filename>/etc</filename> にある設定ファイルとソースツリーの
<filename>/usr/src/etc</filename> にある設定ファイルの違いを確認するのを手伝ってくれます。
これを使うのが、ソースツリーにある設定ファイルにシステムの設定ファイルを
更新するために推奨される方法です。</para>
<para>始めるには、プロンプトから単に
<command>mergemaster</command> と入力して、
ファイルの比較を開始するのを見てください。
<command>mergemaster</command> は
<filename>/</filename> を起点とした一時的なルート環境を構築し、
さまざまなシステム設定ファイルを
(訳注: デフォルトでは <filename>/var/tmp/temproot</filename> に)
置いていきます。
次にこれらのファイルは現在システムにインストールされているファイルと比較されます。
この時点で、異なるファイルは &man.diff.1; 形式で示され、
<option>+</option> の記号は追加または変更された行を表し、
<option>-</option> は完全に削除されたか新しく置き換えられた行を表します。
&man.diff.1; の書式とファイルの違いの表示方法についてのより詳しい情報は、
&man.diff.1; を参照してください。</para>
<para>&man.mergemaster.8; は食い違いが起きているファイルをそれぞれ示します。
ここでは新しいファイル (一時ファイルとして参照されています) を削除するか、
一時ファイルをそのままインストールするか、
一時ファイルと現在インストールされているファイルを統合するか、
もしくは &man.diff.1; の結果をもう一度見るか選択できます。</para>
<para>一時ファイルの削除を選ぶと、&man.mergemaster.8;
に現在のファイルを変更しないで新しいバージョンを削除せよと伝えます。
この選択は、現在のファイルを変更する理由が分からないのであれば、
お勧めできません。
&man.mergemaster.8; のプロンプトで <keycap>?</keycap> とタイプすれば、
いつでもヘルプが見られます。
ファイルのスキップを選ぶと、他のすべてのファイルを終えたあと、
もう一度そのファイルが提示されます。</para>
<para>一時ファイルをそのままインストールすることを選ぶと、
現在のファイルを新しいファイルで置き換えます。
ほとんどの手を加えていないファイルは、
これが一番よい選択です。</para>
<para>ファイルの統合を選んだ場合、
テキストエディタが起動され、両方のファイルの中身が提示されます。
画面上に並ぶ両方のファイルを見て新しいファイルを作成するために両方から必要な部分を選択し、
2 つのファイルを統合することができます。
並んでいるファイルを比較するとき、
<keycap>l</keycap> キーで左側の中身を選択し、
<keycap>r</keycap> キーで右側の中身を選択します。
最終出力は左右両方の部分でできたファイルになるでしょう。
このファイルをインストールすることができます。
たいてい、このオプシュンはユーザが設定を変更したファイルに使われます。</para>
<para>&man.diff.1; の結果をもう一度見る、を選択すると、
ちょうど先ほど &man.mergemaster.8; が選択肢を表示する前と同じように、
ファイルの相異点を見ることができます。</para>
<para>&man.mergemaster.8; がシステムファイルの比較を終えたあと、
他のオプションについてもプロンプトが表示されます。
&man.mergemaster.8;
が、パスワードファイルを再構築したいかどうか尋ねることがあります。
最後に残った一時ファイルを削除するかどうかを尋ねて終了します。</para>
</sect3>
<sect3>
<title>手動での更新</title>
<para>
手動で更新することを選んだ場合、
単にファイルを
<filename>/usr/src/etc</filename> から <filename>/etc</filename> に
コピーしただけでは正常に動作させることはできません。
これらのファイルには、<quote>インストールという
手順を踏まなければならないもの</quote> が含まれています。
<filename>/usr/src/etc</filename> ディレクトリは
<filename>/etc</filename>
ディレクトリにそのまま置き換えられるような
コピーでは<emphasis>ない</emphasis>からです。
また、<filename>/etc</filename> にあるべきファイルのうちで
<filename>/usr/src/etc</filename> にないものもあります。
</para>
<para>&man.mergemaster.8; を (勧められた通り)
使っているのであれば、<link
linkend="updating-upgrading-rebooting">次の節</link>
まで飛ばしてもかまいません。</para>
<para>
手動で行う際の
一番簡単な方法は、ファイルを新しいディレクトリにインストールしてから、
以前のものと異なっている部分を調べて更新作業を行なうことです。
</para>
<warning>
<title>既存の <filename>/etc</filename> をバックアップする</title>
<para>
理論的に考えて、このディレクトリが自動的に
処理されることはありませんが、念には念を入れておいて
損はありません。たとえば以下のようにして、
既存の <filename>/etc</filename> ディレクトリを
どこか安全な場所にコピーしておきましょう。
</para>
<screen>&prompt.root; <userinput>cp -Rp /etc /etc.old</userinput></screen>
<para>
<option>-R</option> は再帰的なコピーを行ない、
<option>-p</option> はファイルの更新時間や所有者などを保存します。
</para>
</warning>
<para>
また、新しい <filename>/etc</filename> やその他のファイルを
インストールするための、仮のディレクトリを作っておく必要があります。
仮ディレクトリは <filename>/var/tmp/root</filename> に置くのが良いでしょう。
同様に、必要なサブディレクトリもこの下に置きます。</para>
<screen>&prompt.root; <userinput>mkdir /var/tmp/root</userinput>
&prompt.root; <userinput>cd /usr/src/etc</userinput>
&prompt.root; <userinput>make DESTDIR=/var/tmp/root distrib-dirs distribution</userinput></screen>
<para>
上の例は、必要なディレクトリ構造をつくり、ファイルをインストールします。
<filename>/var/tmp/root</filename> 以下に作られる、
たくさんの空のディレクトリは削除する必要があります。
一番簡単なやり方は、次のとおりです。</para>
<screen>&prompt.root; <userinput>cd /var/tmp/root</userinput>
&prompt.root; <userinput>find -d . -type d | xargs rmdir 2>/dev/null</userinput></screen>
<para>
これは空ディレクトリをすべて削除します。
(空でないディレクトリに関する警告を避けるために、
標準エラー出力は <filename>/dev/null</filename> に
リダイレクトされます)
</para>
<para>
この段階の <filename>/var/tmp/root</filename> には、
本来 <filename>/</filename> 以下にあるべきファイルが
すべて含まれています。
各ファイルを順に見て、既存のファイルと異なる部分を
調べてください。
</para>
<para>
<filename>/var/tmp/root</filename> 以下に
インストールされているファイルの中には、
<quote>.</quote> から始まっているものがあります。
これを書いている時点で、それに該当するファイルは
<filename>/var/tmp/root/</filename> と
<filename>/var/tmp/root/root/</filename> の中にある
シェルスタートアップファイルだけですが、
他にもあるかも知れません
(これは、あなたがこれをどの時点で読んでいるかに依存します)。
<command>ls -a</command> を使って確かめてください。</para>
<para>
もっとも簡単な方法は、二つのファイルを比較するコマンド
&man.diff.1; を使うことです。
</para>
<screen>&prompt.root; <userinput>diff /etc/shells /var/tmp/root/etc/shells</userinput></screen>
<para>
これは、あなたの
<filename>/etc/shells</filename> ファイルと
新しい <filename>/var/tmp/root/etc/shells</filename> ファイルの
異なる部分を表示します。
これらを、あなたが書き換えたものに変更点をマージするか、
それとも既存のファイルを新しいもので上書きするかを
判断する材料にしてください。
</para>
<tip>
<title>新しい root ディレクトリ
(<filename>/var/tmp/root</filename>) の名前に
タイムスタンプを付けておくと、
異なるバージョン間の比較を楽に行なうことができます。</title>
<para>
頻繁にシステムの再構築を行なうということは、
<filename>/etc</filename> の更新もまた、頻繁に行う必要がある
ということです。これはちょっと手間のかかる作業です。
</para>
<para>
この作業は、あなたが <filename>/etc</filename> にマージした、
新しく変更されたファイルの最新のセットのコピーを保存しておくことで
素早く行なうことができます。
下の手順は、それを実現するための一つの方法です。</para>
<procedure>
<step>
<para>
普通に make world します。<filename>/etc</filename> や
他のディレクトリを更新したくなったときは、ターゲット
ディレクトリに、そのときの日付に基づく名前をつけてください。
たとえば 1998 年 2 月 14 日 だとすれば、以下のようにします。
</para>
<screen>&prompt.root; <userinput>mkdir /var/tmp/root-19980214</userinput>
&prompt.root; <userinput>cd /usr/src/etc</userinput>
&prompt.root; <userinput>make DESTDIR=/var/tmp/root-19980214 \
distrib-dirs distribution</userinput></screen>
</step>
<step>
<para>
上に説明されているように、
このディレクトリから変更点をマージします。
</para>
<para>
その作業が終了しても、
<filename>/var/tmp/root-19980214</filename> を
削除しては<emphasis>いけません</emphasis>。</para>
</step>
<step>
<para>
最新版のソースをダウンロードして再構築したら、
ステップ 1 にしたがってください。今度は、
<filename>/var/tmp/root-19980221</filename>
(更新作業が一週間おきだった場合)
のような名前の、新しいディレクトリをつくることになるでしょう。
</para>
</step>
<step>
<para>
この段階で &man.diff.1; を使用し、
二つのディレクトリを比較する再帰的 diff を作成することで、
一週間の間に行なわれたソースへの変更による相違点を調べます。
</para>
<screen>&prompt.root; <userinput>cd /var/tmp</userinput>
&prompt.root; <userinput>diff -r root-19980214 root-19980221</userinput></screen>
<para>
これによって報告される相違点は、大抵の場合、
<filename>/var/tmp/root-19980221/etc</filename> と
<filename>/etc</filename> との場合に比べて
非常に少ないものになります。
相違点が少ないため、変更点を既存の <filename>/etc</filename>
ディレクトリにマージすることは、比較的容易になります。
</para>
</step>
<step>
<para>
ここまで終了したら、<filename>/var/tmp/root-*</filename> の
二つのうち、古い方のディレクトリは削除して構いません。
</para>
<screen>&prompt.root; <userinput>rm -rf /var/tmp/root-19980214</userinput></screen>
</step>
<step>
<para>
この工程を、<filename>/etc</filename> へ変更点をマージする
必要があるたび、毎回繰り返します。
</para>
</step>
</procedure>
<para>
ディレクトリ名の生成を自動化するには、&man.date.1;
を利用することができます。
</para>
<screen>&prompt.root; <userinput>mkdir /var/tmp/root-`date "+%Y%m%d"`</userinput></screen>
</tip>
</sect3>
</sect2>
<sect2 id="updating-upgrading-rebooting">
<title>再起動</title>
<para>
これで、作業はおしまいです。
すべてがあるべき正しい場所に存在することをチェックしたら、
システムを再起動します。これは、単に
&man.shutdown.8; を実行するだけです。
</para>
<screen>&prompt.root; <userinput>shutdown -r now</userinput></screen>
</sect2>
<sect2>
<title>作業の完了</title>
<para>
ここまで来れば、&os; システムのアップグレードは成功です。
おめでとうございます。
</para>
<para>もしちょっとした問題があった場合でも、
システムの一部を再構築するのは簡単です。
たとえば、アップグレードの途中で誤って
<filename>/etc/magic</filename> を削除して
<filename>/etc</filename> にマージしてしまい、
その結果 <command>file</command>
コマンドが動作しなくなってしまったような場合を考えてみてください。
これを修復するには、次のコマンドを実行すれば修復することができます。</para>
<screen>&prompt.root; <userinput>cd /usr/src/usr.bin/file</userinput>
&prompt.root; <userinput>make all install</userinput></screen>
</sect2>
<sect2>
<title>質問ですか?</title>
<qandaset>
<qandaentry>
<question>
<para>変更が行なわれたら、その度にシステムの再構築が必要になるのでしょうか?</para>
</question>
<answer>
<para>
それは変更の性質によるので、なんとも言えません。
たとえば、<application>CVSup</application> を実行したとき、最後に実行したときから比べて
次にあげるようなファイルが更新されていたとします。</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>
もちろん、それらはどのくらいの頻度でアップグレードしたいか、
そして &os.stable; か &os.current; のどちらを追いかけているのかによります。
</para>
</answer>
</qandaentry>
<qandaentry>
<question>
<para>signal 11 (もしくは他のシグナル番号) のエラーがたくさん出て
コンパイルが失敗します。何が起こっているんでしょうか?</para>
</question>
<indexterm><primary>signal 11</primary></indexterm>
<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> には、
コンパイルの段階で生成された
すべてのオブジェクトファイルが含まれています。
通常 <command>make buildworld</command> の最初の段階では、
このディレクトリを削除して新しくつくり直すようになっています。
その場合には、構築終了後の <filename>/usr/obj</filename>
を保存しておいても、あまり意味はありません。
削除すれば、大きなディスクスペースを
(現在はだいたい 340 MB あります) 解放することができます。</para>
<para>
しかし、もしあなたが何を行なおうとしているのか理解しているなら、
この段階を省略して <command>make buildworld</command>
を行なうことができます。
こうすると、ほとんどのソースは再コンパイルされないため、
構築はかなり高速化されます。
これは裏をかえせば、デリケートな依存関係の問題によって、
システムの構築が奇妙な失敗に終わる可能性があるということです。
&os; メーリングリストではしばしば、構築の失敗が、
この段階の省略によるものだということを理解せずに
不満の声をあげる人がいます。</para>
</answer>
</qandaentry>
<qandaentry>
<question>
<para>構築を中断した場合、その構築を途中から再開することはできますか?</para>
</question>
<answer>
<para>それは、あなたが問題に気付く前に、
どれだけの作業を終えているかによって変わります。</para>
<para><emphasis>一般的に</emphasis> (そしてこれは確実でしっかりした
規則ではありませんが)、
<command>make buildworld</command> の過程では、
基本的なツール ( &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 -DNO_CLEAN all</userinput></screen>
<para>
これは、前回の <command>make buildworld</command>
の作業をやり直しません。
</para>
<para>次のメッセージ
<screen>--------------------------------------------------------------
Building everything..
--------------------------------------------------------------</screen>
<para>が <command>make buildworld</command> の出力にある場合には、
上のようにしてもほとんど悪影響が現れることはありません。
</para>
<para>
もしこのメッセージがないとか、よく分からないという場合には、
安全を確保し、後悔するようなことがないよう、
システムの再構築を最初からやり直しましょう。</para>
</answer>
</qandaentry>
<qandaentry>
<question>
<para>どのようにすれば make world を高速化できますか?</para>
</question>
<answer>
<itemizedlist>
<listitem>
<para>シングルユーザモードで動かしてください。</para>
</listitem>
<listitem>
<para><filename>/usr/src</filename> と
<filename>/usr/obj</filename> ディレクトリを、
異なるディスク上の別のファイルシステムに置いてください。
また可能ならば、異なるディスクコントローラに接続された
ディスクを使ってください。</para>
</listitem>
<listitem>
<para>さらに高速化するには、これらのファイルシステムを
&man.ccd.4; (連結ディスクドライバ) デバイスを
使って、複数のディスク上に置いてください。</para>
</listitem>
<listitem>
<para>プロファイル版の作成を無効化してください。
(<filename>/etc/make.conf</filename> で
<quote>NO_PROFILE=true</quote> をセットします)
普通、それが必要になることはありません。</para>
</listitem>
<listitem>
<para>また、<filename>/etc/make.conf</filename> の中の
<makevar>CFLAGS</makevar> を、
<option>-O -pipe</option> のように指定しましょう。
<option>-O2</option> の最適化はさらに多くの時間を必要とし、
しかも <option>-O</option> と <option>-O2</option> の
最適化には、ほとんど差はありません。
<option>-pipe</option> を指定することで、
コンパイラはテンポラリファイルの代わりにパイプを利用します。
その結果、(メモリの利用は増えますが) ディスクアクセスが減ります。
</para>
</listitem>
<listitem>
<para>&man.make.1; に
<option>-j<replaceable>n</replaceable></option> オプ
ションを指定して、複数のプロセスを並列に実行させてく
ださい。
これはプロセッサが単一か複数かによらず、
どちらも同様に恩恵を得ることができます。</para>
</listitem>
<listitem><para><filename>/usr/src</filename> のある
ファイルシステムを、<option>noatime</option>
オプションを付けてマウント (もしくは再マウント) してください。
これは、そのファイルシステムにおいて、
最後にアクセスされた時刻の書き込みを抑制します。
おそらく、この情報が必要になることはないでしょう。</para>
<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> のあるファイルシステムを、
<option>async</option> オプションをつけてマウント (もしくは
再マウント) してください。これによって、
ディスクへの書き込みが非同期になります。
つまり、書き込み命令はすぐに完了するのに対し、
実際にデータがディスクに書き込まれるのは、その数秒後になります。
これによって、書き込み処理の一括化が可能になるため、
劇的なパフォーマンスの向上が期待できます。
<!-- 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>
</answer>
</qandaentry>
<qandaentry>
<question>
<para>なにか悪いことがあったらどうすればいいですか?</para>
</question>
<answer>
<para>自分の環境に前のビルドの余計なゴミが残っていないことをはっきりと確認してください。
とても簡単です。</para>
<screen>&prompt.root; <userinput>chflags -R noschg /usr/obj/usr</userinput>
&prompt.root; <userinput>rm -rf /usr/obj/usr</userinput>
&prompt.root; <userinput>cd /usr/src</userinput>
&prompt.root; <userinput>make cleandir</userinput>
&prompt.root; <userinput>make cleandir</userinput></screen>
<para>ええ、<command>make cleandir</command>
は本当に 2 回実行するのです。</para>
<para>そして、<command>make buildworld</command> を行い、
全プロセスを最初からやり直してください。</para>
<para>まだ問題があれば、エラーと <command>uname -a</command>
の出力を &a.questions; に送ってください。
自分の設定についてさらに質問されても答えられるよう用意してください!</para>
</answer>
</qandaentry>
</qandaset>
</sect2>
</sect1>
<sect1 id="small-lan">
<sect1info>
<authorgroup>
<author>
<firstname>Mike</firstname>
<surname>Meyer</surname>
<contrib>寄稿: </contrib>
</author>
</authorgroup>
</sect1info>
<title>複数のマシンで追いかける</title>
<indexterm>
<primary>NFS</primary>
<secondary>複数のマシンにインストール</secondary>
</indexterm>
<para>同じソースツリーを追いかけたいマシンを複数持っているなら、
全部のマシンにソースをダウンロードして全部再構築するのは資源、
つまりディスクスペース、ネットワーク帯域、そして CPU サイクルの無駄使いに思えます。
実際これは無駄で、解決策は 1 つのマシンに仕事のほとんどをさせ、
残りのマシンは NFS 経由でそれをマウントする、というものです。
このセクションではそのやり方を概観します。</para>
<sect2 id="small-lan-preliminaries">
<title>準備</title>
<para>まず初めに、同じバイナリで動かそうとするマシンたちを決めます。
このマシンたちのことを<emphasis>ビルドセット</emphasis>と呼びましょう。
それぞれのマシンはカスタムカーネルを持っているかもしれませんが、
同じユーザランドバイナリを動かそうというのです。
このビルドセットから、
<emphasis>ビルドマシン</emphasis>となるマシンを 1 台選びます。
ベースシステムとカーネルを構築するのはこのマシンになります。
理想的には、このマシンは <command>make buildworld</command>
と <command>make buildkernel</command>
を実行するのに十分な CPU を持った速いマシンであるべきです。
<emphasis>テストマシン</emphasis>となるべきマシンも選びたいでしょう。
更新されたソフトウェアを使う前にそのマシンでテストするのです。
テストマシンはかなり長い時間落ちていても
だいじょうぶなマシン<emphasis>であったほうがいいでしょう</emphasis>。
ビルドマシンでもかまいませんが、ビルドマシンである必要はありません。</para>
<para>このビルドセットのマシンはすべて
<filename>/usr/obj</filename> と
<filename>/usr/src</filename>
を同じマシンの同じ場所からマウントする必要があります。
理想的にはビルドマシンの 2 つの違うドライブ上にあるとよいのですが、
ビルドマシンに NFS マウントされていてもかまいません。
ビルドセット自体が複数ある場合は、
<filename>/usr/src</filename> はひとつのビルドマシン上にあるべきです。
他のマシンからはそれを NFS マウントするようにしましょう。</para>
<para>最後にビルドセットの全てのマシン上の
<filename>/etc/make.conf</filename> と
<filename>/etc/src.conf</filename>
がビルドマシンと一致していることを確認してください。
つまり、ビルドマシンはビルドセットのどのマシンもインストールしようとしている
ベースシステムを全部ビルドしなければならないということです。
また、各ビルドマシンは <filename>/etc/make.conf</filename>
にそれぞれのビルドマシンのカーネル名を
<makevar>KERNCONF</makevar> で指定し、
ビルドマシンは自分自身のカーネルから順に全部のカーネル名を
<makevar>KERNCONF</makevar> にリストアップしてください。
各マシンのカーネルもビルドするのであれば、
ビルドマシンは各マシンのカーネル設定ファイルを
<filename>/usr/src/sys/<replaceable>arch</replaceable>/conf</filename>
に持っていなければなりません。</para>
</sect2>
<sect2>
<title>ベースシステム</title>
<para>さて、準備は整ったので、ビルドしましょう。
<xref linkend="make-buildworld">
に書いてあるようにカーネルとベースシステムを構築してください。
でも、まだインストールしないでください。
ビルドが終わったら、テストマシンに移り、
ビルドしたばかりのカーネルをインストールしてください。
テストマシンが NFS 経由で
<filename>/usr/src</filename> と
<filename>/usr/obj</filename> をマウントしているなら、
シングルユーザで再起動したときネットワークを使えるようにしてマウントする必要があります。
もっとも簡単な方法は、
マルチユーザモードで起動して、<command>shutdown now</command>
を実行してシングルユーザモードに移行することです。
そうしたら、カーネルとベースシステムをインストールし、
いつもするように
<command>mergemaster</command> を実行できます。
終わったら、
テストマシンを再起動して通常のマルチユーザ動作に戻します。</para>
<para>テストマシンにあるものすべてがちゃんと動いている確信が得られたら、
同じ手順でビルドセットの他のマシンにも新しいソフトウェアをインストールします。</para>
</sect2>
<sect2>
<title>Ports</title>
<para>ports ツリーにも同じアイデアが使えます。
最初に重要な点は、
ビルドセットのすべてのマシンに同じマシンの
<filename>/usr/ports</filename> をマウントすることです。
そして、distfiles を共有するために、
<filename>/etc/make.conf</filename> を適切に設定します。
NFS マウントによってマップされる <username>root</username>
ユーザが何であれ、<makevar>DISTDIR</makevar>
はそのユーザが書き込める共通の共有ディレクトリに設定する必要があります。
各マシンは <makevar>WRKDIRPREFIX</makevar>
を自分のマシンのビルドディレクトリに設定しなければなりません。
最後に、パッケージをビルドして配布しようとしているなら、
<makevar>DISTDIR</makevar> と同じように
<makevar>PACKAGES</makevar> ディレクトリも設定してください。</para>
</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:
-->