doc/ja_JP.eucJP/books/handbook/cutting-edge/chapter.xml
2015-01-31 06:50:10 +00:00

2437 lines
94 KiB
XML
Raw Blame History

This file contains invisible Unicode characters

This file contains invisible Unicode characters that are indistinguishable to humans but may be processed differently by a computer. If you think that this is intentional, you can safely ignore this warning. Use the Escape button to reveal them.

<?xml version="1.0" encoding="euc-jp"?>
<!--
The FreeBSD Documentation Project
The FreeBSD Japanese Documentation Project
Original revision: r46231
$FreeBSD$
-->
<chapter xmlns="http://docbook.org/ns/docbook"
xmlns:xlink="http://www.w3.org/1999/xlink" version="5.0"
xml:id="updating-upgrading">
<info>
<title>&os; のアップデートとアップグレード</title>
<authorgroup>
<author>
<personname>
<firstname>Jim</firstname>
<surname>Mock</surname>
</personname>
<contrib>再構成、再編成および改訂: </contrib>
</author>
<!-- Mar 2000 -->
</authorgroup>
<authorgroup>
<author>
<personname>
<firstname>Jordan</firstname>
<surname>Hubbard</surname>
</personname>
<contrib>原作: </contrib>
</author>
<author>
<personname>
<firstname>Poul-Henning</firstname>
<surname>Kamp</surname>
</personname>
</author>
<author>
<personname>
<firstname>John</firstname>
<surname>Polstra</surname>
</personname>
</author>
<author>
<personname>
<firstname>Nik</firstname>
<surname>Clayton</surname>
</personname>
</author>
</authorgroup>
</info>
<sect1 xml:id="updating-upgrading-synopsis">
<title>この章では</title>
<para>あるリリースから次のリリースまでの期間にも、
&os; の開発は休みなく続けられています。
最新の開発ツリーと同期することを好む人もいますし、
公式のリリース版を好んで使う方もいます。
しかしながら、公式のリリースといえども、
セキュリティや他の重要な修正のため、時にはアップデートを行う必要があります。
使用しているバージョンに関わらず、&os; は、
手元のシステムを最新の開発ツリーと同期するために必要なツールをすべて用意しています。
そして、これらのツールは、&os; のバージョンをアップグレードするために使えます。
この章では、開発ブランチを追いかける方法、および、&os;
システムをアップデートする基本的なツールについて解説しています。</para>
<para>この章を読んで分かるのは:</para>
<itemizedlist>
<listitem>
<para><application>freebsd-update</application>,
<application>Subversion</application> もしくは
<application>CTM</application>
を使った &os; システムの更新方法</para>
</listitem>
<listitem>
<para>インストールされているシステムと、変更が行われていない状態との比較方法。</para>
</listitem>
<listitem>
<para><application>Subversion</application>
またはドキュメント用の ports<!-- and
<application>Docsnap</application>--> を使って、
インストールされているドキュメントを最新のものにアップデートする方法。</para>
</listitem>
<listitem>
<para>2 つの開発ブランチ、&os.stable;&os.current; の違い</para>
</listitem>
<listitem>
<para>ベースシステム全体を再構築しインストールする方法</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>svn</command> が用いられます。
このコマンドを使うためには、<package>devel/subversion</package> port または package
をインストールしておく必要があります。</para>
</note>
</sect1>
<sect1 xml:id="updating-upgrading-freebsdupdate">
<info>
<title>&os; Update</title>
<authorgroup>
<author>
<personname>
<firstname>Tom</firstname>
<surname>Rhodes</surname>
</personname>
<contrib>寄稿: </contrib>
</author>
</authorgroup>
<authorgroup>
<author>
<personname>
<firstname>Colin</firstname>
<surname>Percival</surname>
</personname>
<contrib>ベースとなったノートの提供: </contrib>
</author>
</authorgroup>
</info>
<indexterm>
<primary>Updating and Upgrading</primary>
</indexterm>
<indexterm>
<primary>freebsd-update</primary>
<see>updating-upgrading</see>
</indexterm>
<para>システム管理における重要な側面に、
すみやかにセキュリティパッチを適用し、
オペレーティングシステムを新しいリリースにアップグレードすることがあります。
&os; には、これらの処理を行うために <command>freebsd-update</command>
と呼ばれるユーティリティが用意されています。</para>
<para>このユーティリティを用いると、&os; のセキュリティおよび
eratta アップデートをバイナリによって行うことができます。
手動でパッチもしくは新しいカーネルをコンパイルし、
インストールする必要はありません。
バイナリアップデートは、
セキュリティチームがサポートしているすべてのアーキテクチャとリリースで利用できます。
<uri xlink:href="http://www.FreeBSD.org/ja/security/">http://www.FreeBSD.org/ja/security/</uri> には、
サポートが行われているリリースや保守終了予定日の一覧があります。</para>
<para>このユーティリティは、マイナーリリースであったり、
他のリリースブランチへのアップグレードにも対応しています。
新しいリリースにアップデートする前に、
アップデートしようとしているリリースのアナウンスに目を通し、
重要な情報がないかどうかを確認してください。
リリースのアナウンスは <uri
xlink:href="http://www.FreeBSD.org/ja/releases/">http://www.FreeBSD.org/ja/releases/</uri>
で確認できます。</para>
<note>
<para>もし <command>crontab</command> の中に
&man.freebsd-update.8; の機能が含まれていたら、
オペレーティングシステムのアップグレード作業を終えるまでは無効にしてください。</para>
</note>
<para>この節では、<command>freebsd-update</command>
で使われる設定ファイルの説明、
セキュリティパッチの適応方法のデモンストレーション、
オペレーティングシステムをアップグレードする際に考慮すべきことについて説明します。</para>
<sect2 xml:id="freebsdupdate-config-file">
<title>設定ファイル</title>
<para><command>freebsd-update</command> のデフォルトの設定ファイルは、
そのままでも用いることができます。
<filename>/etc/freebsd-update.conf</filename>
の設定をデフォルトからきめ細かく調整して、
アップデートプロセスを制御するユーザもいます。
このファイルのコメントにおいて利用可能なオプションが説明されていますが、
以下の項目については補足が必要でしょう。</para>
<programlisting># Components of the base system which should be kept updated.
Components world kernel</programlisting>
<para>このパラメータは、&os; のどの部分を最新に維持するかを設定します。
デフォルトでは、ベースシステム全体、
そしてカーネルをアップデートします。
<literal>src/base</literal><literal>src/sys</literal>
のように、個々の項目を指定することもできます。
この部分についてはデフォルトのままにしておき、
アップデートする項目をユーザがリストに加える形にするのがベストでしょう。
ソースコードとバイナリが同期していないと、
長い年月の間に悲惨な結果がもたらされる可能性があります。</para>
<programlisting># Paths which start with anything matching an entry in an IgnorePaths
# statement will be ignored.
IgnorePaths /boot/kernel/linker.hints</programlisting>
<para><filename>/bin</filename><filename>/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/ /boot/device.hints</programlisting>
<para><command>freebsd-update</command>
がマージすべきファイルが存在するディレクトリの一覧です。
ファイルのマージのプロセスは、
&man.mergemaster.8; と同様 &man.diff.1; パッチの連続ですが、
選択肢は少なく、マージを承認するか、エディタを起動するか、
<command>freebsd-update</command>
を中断するかどうかを選んでください。
もし、心配な点があれば、
<filename>/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 xml:id="freebsdupdate-security-patches">
<title>セキュリティパッチの適用</title>
<para>&os; のセキュリティパッチを適用する過程は簡単になり、
管理者は <command>freebsd-update</command> を使って、
システムを完全にパッチがあたった状態に保つ事ができるようになりました。
&os; セキュリティ勧告の詳細については、
<link xlink:href="&url.books.handbook.en;/security-advisories.html">&os; セキュリティ勧告</link>
<!-- <xref linkend="security-advisories"/> -->
の節で説明されています。</para>
<para>以下のコマンドを実行すると、&os;
のセキュリティパッチがダウンロードされ、インストールされます。
最初のコマンドは、未対応のパッチがあるかどうかを調べます。
もし未対応のパッチがある場合には、
パッチが当てられた際に変更されるファイルのリストが作成されます。
2 番目のコマンドはパッチを適用します。</para>
<screen>&prompt.root; <userinput>freebsd-update fetch</userinput>
&prompt.root; <userinput>freebsd-update install</userinput></screen>
<para>アップデートによってカーネルにパッチが当たった場合には、
パッチが当たったカーネルで起動するように、
システムを再起動する必要があります。
もし、実行中のバイナリにパッチが当てられた場合には、
パッチの当てられたバージョンのバイナリが使われるように、
影響のあるアプリケーションを再起動する必要があります。</para>
<para>毎日一度アップデートがないかどうかを自動的に確認するように設定するには、
以下のエントリを <filename>/etc/crobntab</filename>
に追加してください。</para>
<programlisting>@daily root freebsd-update cron</programlisting>
<para>パッチが存在すると、
自動的にダウンロードされますが、適用はされません。
<systemitem class="username">root</systemitem>宛てにメールで、
ダウンロードされたパッチを確認し、
<command>freebsd-update install</command>
とともに手動でインストールする必要のあることが通知されます。</para>
<para>うまく行かなかった場合には、<command>freebsd-update</command>
を以下のように実行すると、最後の変更までロールバックできます。</para>
<screen>&prompt.root; <userinput>freebsd-update rollback</userinput>
Uninstalling updates... done.</screen>
<para>カーネルまたはカーネルモジュールがアップデートされた場合には、
完了後にもう一度システムを再起動して、
影響のあったバイナリを再起動してください。</para>
<para><command>freebsd-update</command>
ユーティリティが自動的にアップデートするカーネルは
<filename>GENERIC</filename> のみです。
カスタムカーネルがインストールされている場合には、
<command>freebsd-update</command> がインストールした後、
カーネルを再構築し、もう一度インストールする必要があります。
しかしながら、<filename>GENERIC</filename> カーネルが
<filename>/boot/GENERIC</filename> に存在する場合には、
現在のシステムで実行されているカーネルでなくとも、
<command>freebsd-update</command>
によりアップデートされます。</para>
<note>
<para><filename>GENERIC</filename> カーネルを、
常に <filename>/boot/GENERIC</filename> に置いておいてください。
さまざまな問題を解決する際や、
バージョンをアップグレードする際に助けとなります。
<filename>GENERIC</filename> カーネルを用意する方法については、
<xref
linkend="freebsd-update-custom-kernel-9x"/> または <xref
linkend="freebsd-update-custom-kernel-8x"/>
を参照してください。</para>
</note>
<para><filename>/etc/freebsd-update.conf</filename>
のデフォルトの設定を変更しない限り、
<command>freebsd-update</command> は、
他の更新と共にカーネルソースをアップデートします。
新しいカスタムカーネルの再構築と再インストールは、
通常通り行うことができます。</para>
<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>
で表示する時にこのファイルが参照されます。
そのため、何も変更されていない場合でも、
カスタムカーネルを再構築することにより、
<command>uname</command> がシステムの正確なパッチレベルを報告するようになります。
各システムにインストールされているアップデートをすばやく把握できるようになるので、
特に複数のシステムを管理するときに助けとなります。</para>
</sect2>
<sect2 xml:id="freebsdupdate-upgrade">
<title>メジャーおよびマイナーバージョンのアップグレードを行う</title>
<para>&os; のマイナーバージョン間のアップグレード、
たとえば、&os;&nbsp;9.0 から &os;&nbsp;9.1 へのアップグレードは、
<emphasis>マイナーバージョン</emphasis> アップグレードと呼ばれます。
<emphasis>メジャーバージョン</emphasis> アップグレードは、
&os;&nbsp;9.X から &os;&nbsp;10.X へのアップグレードといった、
&os; のメジャーバージョンが変わるようなアップグレードのことです。
どちらのアップグレードもリリース番号のターゲットを指定する事で、
<command>freebsd-update</command> によって行う事ができます。</para>
<note>
<para>カスタムカーネルを使っているシステムでは、
アップグレードを行う前に
<filename>GENERIC</filename> カーネルが、
<filename>/boot/GENERIC</filename>
に置かれている事を確認してください。
<filename>GENERIC</filename> カーネルを用意する方法については、
<xref
linkend="freebsd-update-custom-kernel-9x"/> または <xref
linkend="freebsd-update-custom-kernel-8x"/>
を参照してください。</para>
</note>
<para>以下のコマンドを実行すると、&os;&nbsp;9.0
のシステムを &os;&nbsp;9.1 にアップグレードします。</para>
<screen>&prompt.root; <userinput>freebsd-update -r 9.1-RELEASE upgrade</userinput></screen>
<para>コマンドを実行すると、<command>freebsd-update</command>
は設定ファイルと現在のシステムを評価し、
アップデートするために必要な情報を収集します。
画面には、どのコンポーネントが認識され、
どのコンポーネントが認識されていないといったリストが表示されます。
たとえば以下のように表示されます。</para>
<screen>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)? <userinput>y</userinput></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 9.0-RELEASE.
This kernel will not be updated: you MUST update the kernel manually
before running "/usr/sbin/freebsd-update install"</screen>
<para>この時点ではこの警告を無視してもかまいません。
アップデートされた <filename>GENERIC</filename> カーネルは、
アップグレードプロセスの途中で利用されます。</para>
<para>すべてのパッチがローカルシステムへダウンロードされたら、
次にパッチが適用されます。
このプロセスには時間がかかります。
この時間はコンピュータの性能とワークロードに依存します。
その後、設定ファイルがマージされます。
このプロセスでは、ユーザはファイルをマージするか、
画面上にエディタを立ち上げて手動でマージするかを尋ねられます。
プロセスが進むごとに、成功したマージのすべての結果の情報がユーザに示されます。
マージに失敗したり、無視した場合には、プロセスが中断します。
ユーザによっては <filename>/etc</filename>
のバックアップを取り、
<filename>master.passwd</filename><filename>group</filename>
のような重要なファイルを後で手動でマージする方もいます。</para>
<note>
<para>すべてのパッチは別のディレクトリでマージされており、
まだ、システムには反映されていません。
すべてのパッチが正しく適用され、
すべての設定ファイルがマージされてプロセスがスムーズに進んだら、
ユーザは以下のコマンドを用いて、
変更点をディスクに反映してください。</para>
<screen>&prompt.root; <userinput>freebsd-update install</userinput></screen>
</note>
<para>パッチは最初にカーネルとカーネルモジュールに対して当てられます。
システムがカスタムカーネルを実行している場合には、
&man.nextboot.8; を使って次回の再起動時のカーネルを、
アップデートされた <filename>/boot/GENERIC</filename>
に設定してください。</para>
<screen>&prompt.root; <userinput>nextboot -k GENERIC</userinput></screen>
<warning>
<para><filename>GENERIC</filename> カーネルで再起動する前に、
カーネルにシステムが適切に起動するために必要なすべてのドライバが含まれていること、
もしアップデートしているコンピュータがリモートでアクセスしているのであれば、
ネットワーク接続に必要なすべてのドライバも含まれていることを確認してください。
特に、これまで実行しているカスタムカーネルが、
カーネルモジュールとして提供されているビルドインの機能を含んでいるのであれば、
これらのモジュールを一時的に <filename>/boot/loader.conf</filename>
の機能を用いて、
<filename>GENERIC</filename> に読み込んでください。
アップグレードプロセスが終わるまでは、
重要ではないサービスを無効にするとともに、
必要のないディスクやネットワークのマウントなども避けることが推奨されています。</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>アップグレードはこれで終了です。
もしメジャーアップグレードを行った場合には、
<xref linkend="freebsdupdate-portsrebuild"/>
で説明されているようにすべての ports および package
を再構築してください。</para>
<sect3 xml:id="freebsd-update-custom-kernel-9x">
<title>&os;&nbsp;9.X 以降のシステムにおけるカスタムカーネル</title>
<para><command>freebsd-update</command> を使う前に、
<filename>GENERIC</filename> カーネルが
<filename>/boot/GENERIC</filename>
に置かれていることを確認してください。
ただ一度だけカスタムカーネルを構築したのであれば、
<filename>/boot/kernel.old</filename>
<filename>GENERIC</filename> カーネルそのものです。
このディレクトリの名前を
<filename>/boot/kernel</filename>
へと変更してください。</para>
<para>もし、2 回以上カスタムカーネルを構築した後であったり、
カスタムカーネルを構築した回数がわからなければ、
現在のオペレーティングシステムのバージョンの
<filename>GENERIC</filename> カーネルを入手してください。
コンピュータへの物理的なアクセスが可能であれば、
インストールメディアから <filename>GENERIC</filename>
カーネルをインストールできます。</para>
<screen>&prompt.root; <userinput>mount /cdrom</userinput>
&prompt.root; <userinput>cd /cdrom/usr/freebsd-dist</userinput>
&prompt.root; <userinput>tar -C/ -xvf kernel.txz boot/kernel/kernel</userinput></screen>
<para>別な方法としては、
<filename>GENERIC</filename> カーネルをソースから再構築して、
インストールしてください。</para>
<screen>&prompt.root; <userinput>cd /usr/src</userinput>
&prompt.root; <userinput>make kernel __MAKE_CONF=/dev/null SRCCONF=/dev/null</userinput></screen>
<para><command>freebsd-update</command> がこのカーネルを
<filename>GENERIC</filename> カーネルとして認識するために、
<filename>GENERIC</filename> コンフィグレーションファイルは、
とにかく変更してはいけません。
また、特別なオプションを指定しないで構築してください。</para>
<para><command>freebsd-update</command> は、
<filename>/boot/GENERIC</filename>
が存在する事だけを必要とするので、
<filename>GENERIC</filename>
カーネルで再起動する必要はありません。</para>
</sect3>
<sect3 xml:id="freebsd-update-custom-kernel-8x">
<title>&os;&nbsp;8.X におけるカスタムカーネル</title>
<para>&os;&nbsp;8.X システムでは、<filename>GENERIC</filename>
カーネルを入手する方法や構築の方法が少し異なります。</para>
<para>コンピュータへの物理的なアクセスが可能であれば、
以下のコマンドを実行することで、
インストールメディアから <filename>GENERIC</filename>
カーネルをインストールできます。</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>
をリリース番号に置き換えてください。
<filename>GENERIC</filename> カーネルは、
デフォルトで <filename>/boot/GENERIC</filename>
にインストールされます。</para>
<para>または、<filename>GENERIC</filename>
カーネルをソースから再構築してください。</para>
<screen>&prompt.root; <userinput>cd /usr/src</userinput>
&prompt.root; <userinput>env DESTDIR=/boot/GENERIC make kernel __MAKE_CONF=/dev/null SRCCONF=/dev/null</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> が、このカーネルを
<filename>GENERIC</filename> カーネルとして扱うように、
<filename>GENERIC</filename> コンフィグレーションファイルは、
とにかく変更してはいけません。
また、特別なオプションを指定しないで構築してください。</para>
<para><filename>GENERIC</filename>
カーネルで再起動する必要はありません。</para>
</sect3>
<sect3 xml:id="freebsdupdate-portsrebuild">
<title>メジャーバージョンアップグレード後の
package のアップグレード</title>
<para>一般的に、マイナーバージョンアップグレードの後では、
インストールされているアプリケーションは、問題なく動作するでしょう。
メジャーバージョンが異なるとアプリケーションバイナリーインタフェース
(<acronym>ABI</acronym>) が異なるため、
サードパーティ製のアプリケーションの多くは動作しなくなるでしょう。
メジャーバージョンアップグレード後には、
インストールされているすべての packages, ports
をアップグレードする必要があります。
package は、<command>pkg upgrade</command>
を使ってアップグレードできます。
インストールされている ports をアップグレードする場合には、
<package>ports-mgmt/portmaster</package>
といったユーティリティを使ってください。</para>
<para>すべての package の強制的なアップグレードでは、
バージョン番号が上がらない package に対しても、
リポジトリから最新のバージョンで、インストールされている
package を置き換えます。
&os; のメージャーバージョンが変わるようなアップグレードでは、
ABI のバージョンも変わるため、
このようなアップグレードが必要になります。
強制的なアップグレードを行うには、以下のように実行してください。</para>
<screen>&prompt.root; <userinput>pkg-static upgrade -f</userinput></screen>
<para>インストールされているすべてのアプリケーションを再構築するには、
以下のコマンドを実行してください。</para>
<screen>&prompt.root; <userinput>portmaster -af</userinput></screen>
<para>このコマンドを実行すると、
設定を変更するオプションを持つアプリケーションは、
設定変更のスクリーンを表示し、
ユーザからの指示待ちの状態で停止します。
この振る舞いをやめ、デフォルトのオプションを使用するには、
上記のコマンドに <option>-G</option> を含めてください。</para>
<para>ソフトウェアのアップグレードが終わったら、最後にもう一度
<command>freebsd-update</command>
を実行して、
すべてのアップグレードプロセスのやり残し作業を行い、
アップグレードのプロセスを完了してください。</para>
<screen>&prompt.root; <userinput>freebsd-update install</userinput></screen>
<para><filename>GENERIC</filename>
カーネルを一時的に読み込んでいたのであれば、<xref
linkend="kernelconfig"/> に書かれている手順に従って、
新しいカスタムを構築し、インストールしてください。</para>
<para>コンピュータを再起動し、新しい &os; を立ち上げてください。
これでアップグレードのプロセスは完了です。</para>
</sect3>
</sect2>
<sect2 xml:id="freebsdupdate-system-comparison">
<title>システムの状態の比較</title>
<para><command>freebsd-update</command> を用いて、
インストールされている &os; の状態と、
正しく動作することが分かっている状態とを比較できます。
このコマンドは、現在のシステムのユーティリティ、ライブラリ、
設定ファイルを評価するので、
組み込みの侵入検知システム (<acronym>IDS</acronym>)
として使うことができます。</para>
<warning>
<para>このコマンドは、<package>security/snort</package>
のような本当の <acronym>IDS</acronym>
の置き換えになるものではありません。
<command>freebsd-update</command> はデータをディスクに保存するので、
不正な変更が行われる可能性があります。
<varname>kern.securelevel</varname> と、
<command>freebsd-update</command> のデータを使用しないときに、
読み取りのみの許可属性に設定されているファイルシステムに置くことで、
不正な変更の可能性を低くできますが、
よりよい解決方法は、
<acronym>DVD</acronym>
または安全に保存されている外部 <acronym>USB</acronym>
ディスクのような安全なディスクとシステムを比較することです。
組み込まれているユーティリティを用いた、別の方法による
<acronym>IDS</acronym> 機能については、
<link xlink:href="&url.books.handbook.en;/security-intro.html#security-ids">&os; バイナリによる検出</link>
<!-- <xref linkend="security-ids"/> -->
の節をご覧ください。</para>
</warning>
<para>比較を行うには、
結果の出力先のファイル名を指定してください。</para>
<screen>&prompt.root; <userinput>freebsd-update IDS &gt;&gt; outfile.ids</userinput></screen>
<para>システムは検査され、リリースファイルの <acronym>SHA256</acronym>
ハッシュ値と現在インストールされているファイルのハッシュ値がファイルの一覧と共に、
指定した出力先のファイルに送られます。</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>
</sect2>
</sect1>
<sect1 xml:id="updating-upgrading-documentation">
<title>ドキュメントのアップデート</title>
<indexterm><primary>Updating and Upgrading</primary></indexterm>
<indexterm>
<primary>Documentation</primary>
<see>Updating and Upgrading</see>
</indexterm>
<para>ドキュメントは、&os; オペレーティングシステムの必須要素です。
&os; ドキュメントの最新バージョンは、&os; ウェブサイト (<link
xlink:href="&url.base;/doc/">http://www.freebsd.org/doc/</link>)
から入手できますが、
&os; ウェブサイト、ハンドブック、<acronym>FAQ</acronym>
および文書の最新版をローカルに用意しておくと便利です。</para>
<para>この章では、ソースまたは Ports Collection を使って、
ローカルの &os; ドキュメントを最新に保つ方法を説明します。</para>
<para>ドキュメントを編集したり、
ドキュメントの誤りを報告する方法については、
新しい貢献者のための &os; ドキュメンテーションプロジェクト入門 (<link
xlink:href="&url.books.fdp-primer.en;">http://www.freebsd.org/doc/en_US.ISO8859-1/books/fdp-primer/</link>)
をご覧ください。</para>
<sect2 xml:id="updating-installed-documentation">
<title>ソースから &os; ドキュメントをインストールする</title>
<para>ソースから &os; ドキュメントを構築するのに必要なツールは、
&os; のベースシステムには含まれてはいません。
<application>svn</application> などの必要なツールは、
&os; ドキュメンテーションプロジェクトが開発している
<package>textproc/docproj</package> package または port
からインストールできます。</para>
<para>インストールしたら、<application>svn</application>
を使って、ドキュメントのソースをダウンロードしてください。
以下の例で、
<replaceable>https://svn0.us-west.FreeBSD.org</replaceable>
<xref linkend="svn-mirrors"/>
の中からもっとも近いミラーのアドレスに変更してください。</para>
<screen>&prompt.root; <userinput>svn checkout <replaceable>https://svn0.us-west.FreeBSD.org</replaceable>/doc/head /usr/doc</userinput></screen>
<para>最初にドキュメントのソースをダウンロードするには少し時間がかかります。
ダウンロードが終わるまでお待ちください。</para>
<para>ダウンロードしたドキュメントのソースをアップデートするには、
以下のコマンドを実行してください。</para>
<screen>&prompt.root; <userinput>svn update /usr/doc</userinput></screen>
<para>最新のドキュメントのソースのスナップショットを
<filename>/usr/doc</filename> に用意できたら、
インストールされているドキュメントをアップデートする準備はすべて整いました。</para>
<para>利用可能なすべての言語のドキュメントをアップデートするには、
以下のように入力してください。</para>
<screen>&prompt.root; <userinput>cd /usr/doc</userinput>
&prompt.root; <userinput>make install clean</userinput></screen>
<para>もし、ある特定の言語のみをアップデートしたいのであれば、
<filename>/usr/doc</filename>
の下にある各言語のサブディレクトリで <command>make</command>
を実行してください。</para>
<screen>&prompt.root; <userinput>cd /usr/doc/en_US.ISO8859-1</userinput>
&prompt.root; <userinput>make install clean</userinput></screen>
<para>ドキュメントをアップデートする別の方法は、
<filename>/usr/doc</filename>
または各言語のサブディレクトリで以下のコマンドを実行してください。</para>
<screen>&prompt.root; <userinput>make update</userinput></screen>
<para><varname>FORMATS</varname> を設定して、
以下のようにインストールする出力形式を指定できます。</para>
<screen>&prompt.root; <userinput>cd /usr/doc</userinput>
&prompt.root; <userinput>make FORMATS='html html-split' install clean</userinput></screen>
<para>ドキュメンテーションの一部のアップデートを簡単にするオプションや、
特定の翻訳のビルドを行うためのオプションが用意されています。
これらのオプションは、システム全般のオプションである
<filename>/etc/make.conf</filename> や、<command>make</command>
に与えるコマンドラインオプションで設定できます。</para>
<para>オプションには以下のようなものがあります。</para>
<variablelist>
<varlistentry>
<term><varname>DOC_LANG</varname></term>
<listitem>
<para>ビルドおよびインストールの言語およびエンコーディングの一覧。
たとえば、英語のドキュメントを指定するには
<literal>en_US.ISO8859-1</literal> を設定します。</para>
</listitem>
</varlistentry>
<varlistentry>
<term><varname>FORMATS</varname></term>
<listitem>
<para>ビルドを行うフォーマット、または出力フォーマットの一覧。
現在は <literal>html</literal>,
<literal>html-split</literal>, <literal>txt</literal>,
<literal>ps</literal> そして <literal>pdf</literal>
に対応しています。</para>
</listitem>
</varlistentry>
<varlistentry>
<term><varname>DOCDIR</varname></term>
<listitem>
<para>ドキュメントをインストールする場所。デフォルトは
<filename>/usr/share/doc</filename> です。</para>
</listitem>
</varlistentry>
</variablelist>
<para>&os; のシステム全般のオプションに関連するもっと多くの
<command>make</command> 変数については、
&man.make.conf.5; をご覧ください。</para>
</sect2>
<sect2 xml:id="doc-ports-install-package">
<info>
<title>ports を用いたドキュメンテーションのアップデート</title>
<authorgroup>
<author>
<personname>
<firstname>Marc</firstname>
<surname>Fonvieille</surname>
</personname>
<contrib>ベースとなった作業:</contrib>
</author>
</authorgroup>
</info>
<indexterm>
<primary>Updating and Upgrading</primary>
</indexterm>
<indexterm>
<primary>documentation package</primary>
<see>Updating and Upgrading</see>
</indexterm>
<para>これまでのセクションでは、ソースコードを用いた &os;
ドキュメントのアップデート方法について説明してきました。
この節では、インストールされている
&os; のドキュメントをアップデートするもう一つの方法である、
Ports Collection を用いた方法について説明し、
以下について説明します。</para>
<itemizedlist>
<listitem>
<para>構築済のドキュメントの packages をインストールする方法。
ローカルでの構築作業やドキュメンテーションツールチェインをインストールする必要はありません。</para>
</listitem>
<listitem>
<para>ports フレームワークを使ったドキュメントのソースの構築方法。
チェックアウトおよび構築作業が簡単になります。</para>
</listitem>
</itemizedlist>
<para>&os; のドキュメントをアップデートするこれらの方法は、
&a.doceng; が毎月アップデートしている
ドキュメンテーション ports および packages
によりサポートされています。
これらの ports は、&os; Ports&nbsp;Collection の
docs カテゴリ (<link
xlink:href="http://www.freshports.org/docs/">http://www.freshports.org/docs/</link>)
にまとめられています。</para>
<para>ドキュメンテーション ports の構成は以下の通りです。</para>
<itemizedlist>
<listitem>
<para><package>misc/freebsd-doc-en</package> package または portは、
すべての英語文書をインストールします。</para>
</listitem>
<listitem>
<para><package>misc/freebsd-doc-all</package> メタ package
もしくは port は、
すべての利用可能な言語のすべてのドキュメントを構築します。</para>
</listitem>
<listitem>
<para>各言語のために package または port
が用意されています。たとえば、
<package>misc/freebsd-doc-hu</package>
はハンガリー語のドキュメンテーション port です。</para>
</listitem>
</itemizedlist>
<para>バイナリ package を使うと、
インストールする言語に用意されているすべての形式の
&os; ドキュメントがインストールされます。
たとえば、以下のコマンドを実行すると、
ハンガリー語のドキュメントの最新 package
がインストールされます。</para>
<screen>&prompt.root; <userinput>pkg install hu-freebsd-doc</userinput></screen>
<note>
<para>ドキュメントの package は、対応する port 名とは異なり、
<literal><replaceable>lang</replaceable>-freebsd-doc</literal>
の形式で名前がつけられています。
ここで、<replaceable>lang</replaceable> は言語コードの短縮形です。
ハンガリー語の場合は <literal>hu</literal>、簡体字の場合には
<literal>zh_cn</literal> です。</para>
</note>
<para>ドキュメントのフォーマットを指定する場合には、package ではなく
port から構築をしてください。たとえば、
英語のドキュメントを構築してインストールするには以下のようにして下さい。</para>
<screen>&prompt.root; <userinput>cd /usr/ports/misc/freebsd-doc-en</userinput>
&prompt.root; <userinput>make install clean</userinput></screen>
<para>この port には、
構築およびインストールするフォーマットを設定するメニューがあります。
デフォルトでは、<uri
xlink:href="http://www.FreeBSD.org">http://www.FreeBSD.org</uri>
と同じ形式である分割版の <acronym>HTML</acronym> 形式、
<acronym>PDF</acronym> が選択されています。</para>
<para>以下のように、ドキュメンテーション ports を構築する際の
<command>make</command> オプションが用意されています。</para>
<variablelist>
<varlistentry>
<term><varname>WITH_HTML</varname></term>
<listitem>
<para>HTML 形式を構築します。
各ドキュメントに対し、単一版の HTML ファイルが構築されます。
整形されたドキュメントは、
<filename>article.html</filename>
<filename>book.html</filename>
といった名前でインストールされます。</para>
</listitem>
</varlistentry>
<varlistentry>
<term><varname>WITH_PDF</varname></term>
<listitem>
<para>整形されたドキュメントは、
<filename>article.pdf</filename>
<filename>book.pdf</filename>
といった名前でインストールされます。</para>
</listitem>
</varlistentry>
<varlistentry>
<term><varname>DOCBASE</varname></term>
<listitem>
<para>ドキュメントのインストール先を設定します。
デフォルトのインストール先は
<filename>/usr/local/share/doc/freebsd</filename>
です。</para>
</listitem>
</varlistentry>
</variablelist>
<para>以下は、上記の変数を用いてハンガリー語のドキュメントを
<acronym>PDF</acronym> 形式でインストールする方法です。</para>
<screen>&prompt.root; cd /usr/ports/misc/freebsd-doc-hu
&prompt.root; make -DWITH_PDF DOCBASE=share/doc/freebsd/hu install clean</screen>
<para><xref linkend="ports"/> に書かれている手順を使って、
ドキュメンテーション package または port
をアップデートできます。
たとえば、以下のコマンドを実行すると、
<package>ports-mgmt/portupgrade</package>
から、package
だけを使ってインストールされているハンガリー語のドキュメントをアップデートします。</para>
<screen>&prompt.root; <userinput>portmaster -PP hu-freebsd-doc</userinput></screen>
</sect2>
</sect1>
<sect1 xml:id="current-stable">
<title>開発ブランチを追いかける</title>
<indexterm><primary>-CURRENT</primary></indexterm>
<indexterm><primary>-STABLE</primary></indexterm>
<para>&os; には二つの開発ブランチがあります。
それは &os.current;&os.stable; です。</para>
<para>この節ではそれぞれのブランチと対象としている読者についての説明と、
どのようにしてシステムの対応するブランチを最新の状態に保つかについて説明します。</para>
<para><emphasis>訳: &a.hanai;、1996 年 11 月 6 日</emphasis></para>
<sect2 xml:id="current">
<title>&os.current; を使う</title>
<para>&os.current; とは &os; の開発の <quote>最前線</quote> なので、
&os.current; のユーザは高い技術力を持つことが要求されます。
そこまでの技術力を持っていないが、
開発ブランチを追いかけたいと考えているユーザは、
かわりに &os.stable; を追いかけると良いでしょう。</para>
<para>&os.current;&os; の最新のソースコードであり、
中には現在開発途上のソフトウェア、
実験的な変更、あるいは過渡的な機能などが含まれています。
また、この中に入っている機能がすべて、
次の公式リリースに入るとは限りません。&os.current;
をソースからほぼ毎日コンパイルしている人はたくさんいますが、
短い期間ではコンパイルさえできない状態になっている時期もあります。
これらの問題は可能な限り迅速に解決されますが、
&os.current; が不幸をもたらすか、
それとも新しい機能をもたらすかは、
まさにソースコードを同期した瞬間によるのです!</para>
<para>&os.current; は、
次の 3 つの重要なグループを対象としています。</para>
<orderedlist>
<listitem>
<para>ソースツリーのある部分に関して活発に作業している
&os; コミュニティのメンバ。</para>
</listitem>
<listitem>
<para>活発にテストしている &os; コミュニティのメンバ。
彼らは、種々の問題を解決するのに時間を惜しまない人々であり、
さまざまな変更に関する提案や
&os; の大まかな方向付けを行ないたいと思っている人々でもあり、
パッチも提出します。</para>
</listitem>
<listitem>
<para>さまざまな事に目を向け、
参考のために最新のソースを使いたいと思っていたり、
時々コメントやコードを寄稿したいと考えているユーザ。</para>
</listitem>
</orderedlist>
<para>&os.current; は、次のリリースの前に、
最も早く新しい機能を入手する手段として、
期待しては<emphasis>いけません</emphasis>
リリース前の機能は十分にテストされていないため、
バグを含んでいる可能性が大いにあるためです。
また、バグを修正するための素早い方法でもありません。
いかなるコミットは、元からあるバグを修正するのと同じく、
新しいバグを生み出すおそれがあります。
&os.current; には <quote>公式のサポート</quote> はありません。</para>
<indexterm>
<primary>-CURRENT</primary>
<secondary>using</secondary>
</indexterm>
<para>&os.current; を追いかけるには</para>
<orderedlist>
<listitem>
<para>&a.current.name;&a.svn-src-head.name;
<indexterm>
<primary>-CURRENT</primary>
<secondary>使用</secondary>
</indexterm>
メーリングリストに加わってください。
さまざまな人がシステムの現在の状態について述べているコメントを見たり、
&os.current; の現在の状態に関する重要な情報を見逃さないために、
<emphasis>必須の</emphasis> ことです。</para>
<para>&a.svn-src-head.name; メーリングリストでは、
それぞれの変更についての commit ログが記録されています。
また、それに関して起こり得る副作用の情報を得ることができますので、
参加する価値のあるメーリングリストです。</para>
<para>これらのメーリングリストに入るには、
&a.mailman.lists.link;
をたどって参加したいメーリングリストをクリックし、
手順の説明にしたがってください。
&os.current; だけでなく、
ソースツリー全体の変更点を追いかけるのであれば、
&a.svn-src-all.name; メーリングリストを購読してください。</para>
</listitem>
<listitem>
<para>&os.current; のソースを同期してください。
特に <link linkend="svn">svn</link> を使って
<xref linkend="svn-mirrors"/> の一覧にある
Subversion ミラーサイトのひとつの
<literal>head</literal> ブランチから
-CURRENT コードをチェックアウトしてください。</para>
</listitem>
<listitem>
<para>インターネットの接続がとても遅かったり、
制限がある場合には、
<xref linkend="ctm"/> で説明されている CTM
を利用すると良いでしょう。
ただし、<application>svn</application>
ほどには信頼はできないので、
<application>svn</application>
を利用されることを推奨します。</para>
</listitem>
<listitem>
<para>リポジトリのサイズが大きいため、興味のある部分や、
パッチを当てる部分のソースのみを同期するユーザもいます。
しかしながら、
ソースからオペレーティングシステムをコンパイルしようと思っているユーザは、
一部分だけではなく、&os.current;<emphasis>すべて</emphasis>
をダウンロードする必要があります。</para>
<para>&os.current; をコンパイル
<indexterm>
<primary>-CURRENT</primary>
<secondary>コンパイル</secondary>
</indexterm> する前に
<filename>/usr/src/Makefile</filename> を注意深く読み、
<xref linkend="makeworld"/>
に書かれている手順に従ってください。
&a.current;<filename>/usr/src/UPDATING</filename> を読めば、
次のリリースへ向けて移ってゆくに当たって、
ときどき必要となる既存システムからの新システムの構築手順についての最新情報が得られるでしょう。</para>
</listitem>
<listitem>
<para>アクティブになってください!
&os.current; のユーザには、
拡張やバグ潰しに関して提案することが勧められています。
コードを伴う提案はいつでも歓迎されます!</para>
</listitem>
</orderedlist>
</sect2>
<sect2 xml:id="stable">
<title>&os.stable; を使う</title>
<para><emphasis>訳: &a.jp.iwasaki;</emphasis></para>
<para>&os.stable;
とは定期的に公開されるリリースを作成するための開発ブランチです。
このブランチに加えられる変更は &os.current; よりゆっくりで、
原則として、事前に &os.current; で試験ずみであるという特徴があります。
ただ<emphasis>そうであっても</emphasis>
これは開発用ブランチの一つであり、ある時点における &os.stable;
のソースがどんな場合にも使えるものであるとは限りません。
このブランチはもう一つの開発の流れというだけであって、
エンドユーザ向けのものではありません。
もし試験をする資源的な余裕がない場合は、代わりに最新の
&os; リリースを使ってください。</para>
<para>&os; の開発プロセスに興味があったり、
それに対する貢献を考えていて、特にそれが次回の
&os; のリリースに関係するものであるなら
&os.stable; を追うことを考えると良いでしょう。</para>
<para>&os.stable; ブランチはいつもコンパイルができ、
安定に動作すべきですが、
それが保証されているというわけではありません。
&os.stable; のユーザは &os.current; よりも多いため、&os.current;
で発見されなかったバグが &os.stable; で発見され、
ときどきそれが問題となることがあるのは避けることができません。
このような理由から、盲目的に &os.stable;
を追いかけるべきではありません。
特に、開発環境もしくはテスト環境でコードを十分に試験せずに、
プロダクション品質が要求されるサーバを &os.stable;
にアップグレードしては<emphasis>いけません</emphasis></para>
<para>&os.stable; を追いかけるには</para>
<indexterm>
<primary>-STABLE</primary>
<secondary>利用する</secondary>
</indexterm>
<orderedlist>
<listitem>
<para>&os.stable; の構築に関連する事柄や、
その他の注意すべき点 に関する情報を得るために、
&a.stable.name; メーリングリストに加わってください。
また開発者は議論の余地がある修正や変更を考えている場合に、
このメーリングリストで公表し、
提案された変更に関して問題が生じるかどうかを返答する機会をユーザに与えます。</para>
<para>追いかけているブランチに関連する
<application>svn</application> メーリングリストに参加してください。
たとえば、9-STABLE ブランチを追いかけているユーザは
&a.svn-src-stable-9.name; メーリングリストに参加してください。
このリストでは、変更がなされるごとに作成される commit log
やそれに伴う起こりうる副作用についての情報が記録されています。</para>
<para>これらのメーリングリストに入るには、&a.mailman.lists.link;
をたどって参加したいメーリングリストをクリックし、
手順の説明にしたがってください。
ソースツリー全体の変更点を追いかけるには、
&a.svn-src-all.name; メーリングリストを購読してください。</para>
</listitem>
<listitem>
<para>新しい &os.stable; システムをインストールするには、
<link linkend="mirrors">ミラーサイト</link> から最近の
&os.stable; リリースをインストールするか、
毎月公開されている &os.stable;
からビルドされたスナップショットを使ってください。
スナップショットの詳細については、<link
xlink:href="&url.base;/ja/snapshots/">www.freebsd.org/ja/snapshots</link>
をご覧ください。</para>
<para>既に &os; が動いているシステムを
&os.stable; にアップグレードするには、
<link linkend="svn">svn</link>
<indexterm>
<primary>Subversion</primary>
</indexterm> を使って、
希望する開発ブランチのソースをチェックアウしてください。
<literal>stable/9</literal> といったブランチ名は、
<link xlink:href="&url.base;/releng/">www.freebsd.org/releng</link>
で説明されています。
インターネットへの接続に信頼できる回線を利用できないのであれば、
CTM (<xref linkend="ctm"/>) を使ってください。</para>
</listitem>
<listitem>
<para>&os.stable; をコンパイルしたり &os.stable; へとアップグレード
<indexterm>
<primary>-STABLE</primary>
<secondary>構築、コンパイル</secondary>
</indexterm> する前に、
<filename>/usr/src/Makefile</filename> を注意深く読み、
<xref linkend="makeworld"/>
に書かれている手順に従ってください。
&a.stable;<filename>/usr/src/UPDATING</filename> を読んで、
次のリリースへ向けて移ってゆくに当たって、
ときどき必要となる既存システムからの新システムの構築手順についての最新情報を得てください。</para>
</listitem>
</orderedlist>
</sect2>
</sect1>
<sect1 xml:id="synching">
<title>ソースの同期</title>
<para><emphasis>訳: &a.jp.iwasaki;、1997 年 9 月 13 日</emphasis></para>
<para>&os; のソースの最新を追いかける方法は色々あります。
この節では、基本的なサービスである
<application>Subversion</application> および
<application>CTM</application> について説明します。</para>
<warning>
<para>ソースツリーの一部を最新のものに更新することは可能です。
ただし、サポートされているアップデート手順は、
ソースツリー全体を最新のものに更新し、
<filename>/bin</filename>, <filename>/sbin</filename>
といったユーザ空間で動作するもの、
およびカーネルソースを再構築することのみです。
ソースツリーの一部だけであったり、カーネルだけ、
もしくはユーザランドのプログラムだけを更新した場合は、
問題が生じることがよくあります。
この時に発生する問題はコンパイル時のエラーからカーネルパニック、
データの破壊とさまざまです。</para>
</warning>
<indexterm>
<primary>Subversion</primary>
</indexterm>
<para><application>Subversion</application>
<emphasis>pull</emphasis> 同期モデルを採用しています。
ユーザ (または <command>cron</command> スクリプト) が
<command>svn</command> プログラムを起動し、
ローカルにあるソースを最新状態にします。
更新情報はその時点の最新のものであり、
いつダウンロードするかはユーザがコントロールするので、
<application>Subversion</application>
はローカルのソースツリーをアップデートする好ましい方法です。
特定のファイルやディレクトリに限定して更新することも簡単にできます。
更新情報はサーバによって素早く生成されます。
<application>Subversion</application> によるソースの同期方法については、
<xref linkend="svn"/> で説明されています。</para>
<indexterm>
<primary><application>CTM</application></primary>
</indexterm>
<para>一方、<application>CTM</application>
はあなたが持っているソースとマスタアーカイブ上に
あるそれとの対話的な比較をおこないませんし、
あるいは向こう側から変更点を pull したりもしません。
そのかわりに、前回の実行時からの変更を認識するスクリプトが
マスタ CTM マシン上で一日に数回実行され、
すべての変更を compress して通し番号を振り、
さらに電子メールで、印字可能な <acronym>ASCII</acronym>
キャラクタのみで転送できるようにエンコードします。
ダウンロードした後は、
これらの <quote>デルタ</quote> は、
自動的にデコード、検査してユーザのソースのコピーに変更を適用する
<command>ctm.rmail</command> によって処理可能です。
この処理は <application>Subversion</application>
よりずっと効率的であり、<emphasis>pull</emphasis> モデルというよりむしろ
<emphasis>push</emphasis> モデルであるため、
サーバ資源の負荷は軽くなります。
<application>CTM</application> を用いたソースの同期方法については、
<xref linkend="ctm"/> をご覧ください。</para>
<para><application>Subversion</application> であれば、
うっかりローカルのアーカイブの一部を消してしまっても、
壊れた部分を検出して再構築してくれます。
<application>CTM</application> はこれをやってくれません。
もしソースツリーの一部を消してしまい、
そしてバックアップを取っていないのであれば、最新の
<firstterm>ベースデルタ</firstterm> を用いて、一からやり直し、
<application>CTM</application>
を使ってすべてを再構築しなければなりません。</para>
</sect1>
<sect1 xml:id="makeworld">
<title>world の再構築</title>
<indexterm>
<primary><quote>world</quote> の再構築</primary>
</indexterm>
<para>&os.stable;&os.current; などの
&os; のどれか特定のバージョンについて、
ローカルのソースツリーを同期させたら、
そのソースツリーを使ってシステムを再構築できます。
このプロセスは world の再構築と呼ばれます。</para>
<para>world を再構築する<emphasis></emphasis>に、
以下を行ってください。</para>
<procedure>
<title>world の構築<emphasis></emphasis>に行う作業</title>
<step>
<para>重要なデータを他のシステムやリムーバブルメディアにバックアップし、
きちんとバックアップが作成されていることを確認したら、
起動可能なインストールメディアを用意してください。
システムを再構築する<emphasis>前に</emphasis>
バックアップを作成することの重要性は、
いくら強調してもし過ぎると言うことはありません。
システム全体の再構築は難しい作業ではありませんが、
どんなに注意していたとしても、<!-- hrs:2000/01/12 inevitably -->
ソースツリーそのものに手違いがあった時には、
システムが起動しなくなってしまう状態になることがあるのです。
多分、それを使うことはないと思いますが、
あとで後悔することのないよう、念のため用意しておきましょう!</para>
</step>
<step>
<indexterm><primary>メーリングリスト</primary></indexterm>
<para>追いかけているブランチに応じて、
&a.stable.name; もしくは &a.current.name;
の最近のエントリを調べて、
既知の問題や影響を受けるシステムを確認してください。
既知の問題が同期しているバージョンのコードに影響する場合は、
その問題が解決されたことを報告する
<quote>問題解決 (all clear)</quote>
のアナウンスが投稿されるまで待ってから、ソースを同期して、
ローカルのソースに必要な修正を入れてください。</para>
</step>
<step>
<para><filename>/usr/src/UPDATING</filename> を読み、
同期しているソースのバージョンで必要となるステップがないかどうかを調べて下さい。
このファイルには潜在的な問題や特定のコマンドを実行する順などの重要な情報が含まれています。
大きなアップグレードでは、world
をインストールする前に特定のファイルの名前を変更したり、
削除するといった、特別なステップが追加で必要となることがあります。
ファイルの最後には、
現在推奨されているアップグレードの手順が詳しく正確に説明されています。
もし、<filename>UPDATING</filename> に書かれている手順が、
この節に書かれているものと矛盾していたら、
<filename>UPDATING</filename> の手順を採用してください。</para>
</step>
</procedure>
<warning>
<title><command>make world</command> は使わないこと</title>
<para>古いドキュメントの中には、
<command>make world</command> を使うことを薦めているものがあります。
これは、重要な手順をいくつか抜かしてしまうので、
エキスパートでなければ使うべきではありません。
ほぼあらゆる場合において、<command>make world</command>
を実行するのは間違っており、
ここで説明されている手順を用いるべきです。</para>
</warning>
<sect2 xml:id="canonical-build">
<title>システム更新の概要</title>
<para>world の構築では、<xref linkend="synching"/>
に書かれている手順で入手したソースを用いて、
古い &os; のバージョンをアップデートしてください。</para>
<para>&os; では、<quote>world</quote> は、
カーネル、コアシステムのバイナリ、
ライブラリ、プログラミングファイル、組み込みのコンパイラを意味します。
これらのコンポーネントの構築およびインストールの順番は重要です。</para>
<para>例えば、古いコンパイラは、
バグを含み、新しいカーネルをコンパイルできない可能性があります。
そのため、新しいカーネルは新しいコンパイラで構築しなければならないので、
新しいコンパイラの構築が必要となりますが、
必ずしも、
新しいコンパイラがインストールされている必要はありません。</para>
<para>新しい world は、
新しいカーネルの機能に依存している可能性があるので、
新しい world をインストールする前に、
新しいカーネルがインストールされていなければなりません。
古い world は、新しいカーネルでは正しく動かないかも知れません。
そのため、新しいカーネルをインストールしたら、
直ちに新しい world をインストールしてください。</para>
<para>設定の中には、新しい world
をインストールする前に変更すべきものがありますが、
古い world を壊す可能性があります。
そのため、設定のアップデートは 2 つの手順で行われます。
多くの場合、アップデートのプロセスは、ファイルを置き換えたり、
追加のみを行い、古いファイルを削除しません。
このことが問題を引き起こす可能性があるため、
<filename>/usr/src/UPDATING</filename> には、
手動で削除すべきファイルをどのステップで削除すべきかが書かれています。</para>
<para>これらを配慮し、アップグレードの推奨手順が作られました。</para>
<note>
<para><command>make</command> を実行したときの出力は、
ファイルに保存すると良いでしょう。
何か障害が発生した場合には、エラーメッセージのコピーを
&os; メーリングリストに投稿してください。</para>
<para>ファイルに保存する最も簡単な方法は、
引数として出力の保存先のファイル名を指定して
<command>script</command> コマンドを使うことです。
<filename>/tmp</filename> に出力を保存しないようにしてください。
このディレクトリは、次の再起動で削除されてしまう可能性があります。
出力の保存には、<filename>/var/tmp</filename> が適しています。
次のコマンドを world の構築の直前に行ない、再構築が終了したら
<userinput>exit</userinput> と入力してください。</para>
<screen>&prompt.root; <userinput>script <replaceable>/var/tmp/mw.out</replaceable></userinput>
Script started, output file is /var/tmp/mw.out</screen>
</note>
<procedure>
<title>world の構築プロセスの概要</title>
<para>world の構築プロセスで用いられるコマンドは、
ここで示されている順番で実行してください。
この節では各コマンドの機能についてまとめます。</para>
<step>
<para>システム上で world の構築が一度でも行われたのであれば、
前回の構築の際のコピーが
<filename class="directory">/usr/obj</filename>
に存在するはずです。
このディレクトリが存在しているのであれば、
このディレクトリを削除することで
<command>make buildworld</command> の行程にかかる時間を短縮し、
依存問題に悩まされるようなトラブルを回避できます。</para>
<screen>&prompt.root; <userinput>chflags -R noschg /usr/obj/*</userinput>
&prompt.root; <userinput>rm -rf /usr/obj</userinput></screen>
</step>
<step>
<para>新しいコンパイラと関連ツールを最初にコンパイルし、
その後、新しいコンパイラで、
新しい world の残りの部分をコンパイルします。
コンパイルされたものは、
<filename class="directory">/usr/obj</filename>
に格納されます。</para>
<screen>&prompt.root; <userinput>cd /usr/src</userinput>
&prompt.root; <userinput>make buildworld</userinput></screen>
</step>
<step>
<para>コンパイラとカーネルのミスマッチを防ぐため、
<filename class="directory">/usr/obj</filename>
にある新しいコンパイラを用いて新しいカーネルを構築します。
再構築は、ある種のメモリ構造体が変更されたような場合には必須で、
<command>ps</command><command>top</command>
のようなプログラムは、
カーネルとソースコードのバージョンが一致しないと正常に動作しないでしょう。</para>
<screen>&prompt.root; <userinput>make buildkernel</userinput></screen>
</step>
<step>
<para>新しくアップデートされたカーネルで起動できるように、
新しいカーネルとカーネルモジュールをディスク上に配置します。
<varname>kern.securelevel</varname> を 1 より大きくしていて、
<emphasis>かつ</emphasis> カーネルのバイナリファイルに
<literal>noschg</literal> のようなフラグを設定している場合は、
まず、シングルユーザモードに移行してください。
それ以外の場合は、
マルチユーザモードでこれらのコマンドを問題なく動かせるはずです。
<varname>kern.securelevel</varname> について詳しくは
&man.init.8; を、ファイルに対するさまざまなフラグについて詳しくは
&man.chflags.1; をご覧ください。</para>
<screen>&prompt.root; <userinput>make installkernel</userinput></screen>
</step>
<step>
<para>すでに実行されているソフトウェアをアップデートする際の問題を最小限にするため、シングルユーザモードに移行します。
また、新しいカーネル上で古い world
が実行される際の問題も最小限にします。</para>
<screen>&prompt.root; <userinput>shutdown now</userinput></screen>
<para>シングルユーザモードに移行したら、UFS
でフォーマットされているシステムでは、
以下のコマンドを実行してください。</para>
<screen>&prompt.root; <userinput>mount -u /</userinput>
&prompt.root; <userinput>mount -a -t ufs</userinput>
&prompt.root; <userinput>swapon -a</userinput></screen>
<para>もしシステムが ZFS でフォーマットされている場合には、
以下の 2 つのコマンドを実行してください。
この例では、zpool の名前は <literal>zroot</literal>
であると仮定します。</para>
<screen>&prompt.root; <userinput>zfs set readonly=off zroot</userinput>
&prompt.root; <userinput>zfs mount -a</userinput></screen>
</step>
<step>
<para>オプション: もし、デフォルトの US English
以外のキーボードマップが必要であれば、
&man.kbdmap.1; で変更してください。</para>
<screen>&prompt.root; <userinput>kbdmap</userinput></screen>
</step>
<step>
<para>その後、どちらのファイルシステムでも、
<acronym>CMOS</acronym> クロックが地域時間に設定されていて
GMT ではない場合
(&man.date.1; が正しい時間と地域を表示しないなら当てはまります)
には、次のコマンドを実行してください。</para>
<screen>&prompt.root; <userinput>adjkerntz -i</userinput></screen>
</step>
<step>
<para>システムの再構築では、
<filename>/etc</filename>,
<filename>/var</filename>
<filename>/usr</filename>
といったディレクトリに新規に導入されたファイルや、
変更された設定ファイルに対する更新は行なわれません。
次に、新しい world
に対する <filename class="directory">/etc</filename>
の最初の設定ファイルのアップデートを行います。
以下のコマンドは
<buildtarget>installworld</buildtarget>
に成功するために本質的なファイルのみを比較します。
たとえば、
このステップでは、最後のアップデート後に &os; に追加された、
新しいグループや新しいシステムアカウント、
もしくはスタートアップスクリプトがシステムに追加されることがあります。
次のコマンドに関する詳細な情報については、
<xref linkend="mergemaster"/> を参照してください。</para>
<screen>&prompt.root; <userinput>mergemaster -iF</userinput></screen>
</step>
<step>
<para><filename class="directory">/usr/obj</filename>
にある新しい world
  およびシステムのバイナリをインストールします。</para>
<screen>&prompt.root; <userinput>cd /usr/src</userinput>
&prompt.root; <userinput>make installworld</userinput></screen>
</step>
<step>
<para>残りの設定ファイルをアップデートします。</para>
<screen>&prompt.root; <userinput>mergemaster -p</userinput></screen>
</step>
<step>
<para>使われなくなったファイルを削除します。
もし使われなくなったファイルがディスクに残っていると、
問題が起きる可能性があるため重要な作業です。</para>
<screen>&prompt.root; <userinput>make delete-old</userinput></screen>
</step>
<step>
<para>再起動を行い、新しいカーネル、
world そして設定ファイルをロードします。</para>
<screen>&prompt.root; <userinput>reboot</userinput></screen>
</step>
<step>
<para>古いライブラリを削除する前に、
<xref linkend="ports-upgrading"/>
に書かれている手順にしたがって、
すべての ports を再構築する必要があります。
再構築が終わったら、新しいライブラリと競合することを避けるため、
使われなくなったライブラリを削除します。
この過程に関する詳細については、<xref linkend="make-delete-old"/>
を参照して下さい。</para>
<screen>&prompt.root; <userinput>make delete-old-libs</userinput></screen>
</step>
</procedure>
<indexterm><primary>シングルユーザモード</primary></indexterm>
<para>もしシステムがダウンタイムを持つことができるのであれば、
システムのコンパイルをマルチユーザモードでおこない、
インストールのためにシングルユーザモードに移行するという方法ではなく、
コンパイルをシングルユーザモードで行うことを考えてください。
システムの再インストールでは、たくさんの重要なシステムファイル、
すべての標準的なシステムバイナリ、ライブラリ、
インクルードファイルが変更されるので、
実際に動作しているシステムにおいて、
特にアクティブなユーザは、トラブルに見舞われる可能性があります。</para>
</sect2>
<sect2 xml:id="src-updating">
<title>設定ファイル</title>
<indexterm>
<primary><filename>make.conf</filename></primary>
</indexterm>
<para>world
の構築プロセスでは、いくつかの設定ファイルが使われます。</para>
<para><filename>/usr/src</filename> に置かれている、
<filename>Makefile</filename> には、
&os; を構成するプログラムの構築方法や、
どういう順番でそれらを構築すべきかといった指示が記述されています。</para>
<para><command>make</command> で利用可能なオプションの説明は
&man.make.conf.5; や、共通の例が
<filename>/usr/share/examples/etc/make.conf</filename> にあります。
これらの設定を <filename>/etc/make.conf</filename> に追加すると、
<command>make</command> の実行やプログラムの構築方法を設定できます。
これらのオプションは、
<command>make</command> が使われる際には常に有効となるため、
Ports Collection からアプリケーションをコンパイルする時、
ユーザが書いた C プログラムや &os;
オペレーティングシステムを構築する際に影響を及ぼします。
ある設定を変更したことにより、影響が広い範囲におよび、
驚くべき結果をもたらす可能性があります。
両方のファイルに書かれているコメントを読むことと、
デフォルトの設定は、パフォーマンスと安全性の観点から選ばれていることを覚えておいてください。</para>
<indexterm>
<primary><filename>src.conf</filename></primary>
</indexterm>
<para><filename>/etc/src.conf</filename> は、
ソースコードを用いたオペレーティングシステムの構築をコントロールします。
<filename>/etc/make.conf</filename> とは異なり、
<filename>/etc/src.conf</filename> に書かれた設定は、
&os; オペレーティングシステムそのものを構築するときにのみ影響します。
このファイルで設定可能な多くのオプションについては、
&man.src.conf.5; に記述されています。
一見したところ無効にされている、
使われていないカーネルモジュールやビルドオプションに注意してください。
ときどき予期しなかったり、わずかな影響を与えることがあります。</para>
</sect2>
<sect2 xml:id="make-buildworld">
<title>変数とターゲット</title>
<para><command>make</command> の使用における一般的な書式は、
次のとおりです。</para>
<screen>&prompt.root; <userinput>make -<replaceable>x</replaceable> -D<replaceable>VARIABLE</replaceable> <replaceable>target</replaceable></userinput></screen>
<para>この例では、<option>-<replaceable>x</replaceable></option>
<command>make</command> に渡されるオプションになります。
どのようなオプションが利用できるかについては、&man.make.1;
を参照してください。</para>
<para>変数を渡すには、変数の名前を
<option>-D<replaceable>VARIABLE</replaceable></option>
のように指定してください。
この変数は <filename>Makefile</filename> の動作をコントロールします。
変数の指定は、<filename>/etc/make.conf</filename> で設定するか、
<command>make</command> の実行時に指定するかのどちらかで行います。
たとえば、以下の変数は、プロファイル版のライブラリを構築しないことを指定します。</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><replaceable>target</replaceable> は、<command>make</command>
どのように動作するのかを指示するためのものです。
<filename>Makefile</filename> は利用可能なターゲットを定義しています。
ターゲットには、
システムの再構築に必要な段階を、
多くのさらに細かい段階に分割するため、
構築の過程で利用されるものがあります。</para>
<para>選択肢が分けられていることは、二つの理由から有用です。
まず第一に、構築作業は稼働中のシステムにまったく影響を与えません。
そのため、マルチユーザモードで稼働中のシステムでも、安全に
<buildtarget>buildworld</buildtarget> を実行できます。
ただし、<buildtarget>installworld</buildtarget>
シングルユーザモードで行なうことをおすすめします。</para>
<para>第二に、<acronym>NFS</acronym> マウントを利用することで、<xref
linkend="small-lan"/> で説明されているように、
ネットワーク上の複数のマシンをアップグレードすることが可能な点があげられます。</para>
<para><command>make</command>
<option>-j</option> をつけると、
同時に複数のプロセスを生成できます。
構築過程の大部分では <acronym>CPU</acronym> 性能の限界より
<acronym>I/O</acronym> 性能の限界の方が問題となるため、
シングル <acronym>CPU</acronym> とマルチ <acronym>CPU</acronym>
マシンの両方に効果があります。</para>
<para>普通のシングル <acronym>CPU</acronym> マシンで以下のコマンド
を実行すると、最大 4 個までのプロセスを同時に実行します。
メーリングリストに投稿された経験的な報告によると、
4 個という指定が最も良いパフォーマンスを示すようです。</para>
<screen>&prompt.root; <userinput>make -j4 buildworld</userinput></screen>
<para>マルチ <acronym>CPU</acronym> マシンでは、
<literal>6</literal> から <literal>10</literal> の間の値を設定し、
速度がどれくらい向上するか確認してみてください。</para>
<indexterm>
<primary><quote>world</quote> の再構築</primary>
<secondary>時間</secondary>
</indexterm>
<note>
<para><command>make buildworld</command>
に変数を指定した場合は、同じ指定を
<command>make installworld</command> にも指定しなければなりません。
ただし <buildtarget>installworld</buildtarget>
では、<option>-j</option>
<emphasis>絶対に使ってはいけません</emphasis></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>もしそうしなかった場合、2 番目のコマンドは、
<command>make buildworld</command>
の段階で構築されていないプロファイル版ライブラリをインストールしようとしてしまうでしょう。</para>
</note>
</sect2>
<sect2 xml:id="mergemaster">
<info>
<title>設定ファイルの同期</title>
<authorgroup>
<author>
<personname>
<firstname>Tom</firstname>
<surname>Rhodes</surname>
</personname>
<contrib>寄稿: </contrib>
</author>
</authorgroup>
</info>
<indexterm>
<primary>
<command>mergemaster</command>
</primary>
</indexterm>
<para>&os;&man.mergemaster.8; Bourne シェルスクリプトは、
<filename>/etc</filename> にある設定ファイルと、
<filename>/usr/src/etc</filename>
にある設定ファイルの違いを確認するためのものです。
これを使うのが、
ソースツリーにある設定ファイルにシステムの設定ファイルを
更新するために推奨される方法です。</para>
<para><command>mergemaster</command> を使う前に、
既存の <filename>/etc</filename>
をどこか安全な場所にコピーしておきましょう。
再帰的なコピーを行なう <option>-R</option> と、
ファイルの更新時間や所有者などを保存する
<option>-p</option> と共に実行してください。</para>
<screen>&prompt.root; <userinput>cp -Rp /etc /etc.old</userinput></screen>
<para><command>mergemaster</command> を実行すると、
<filename>/</filename> を起点とした一時的なルート環境を構築し、
さまざまなシステム設定ファイルを
(訳注: デフォルトでは <filename>/var/tmp/temproot</filename> に)
置いていきます。
これらのファイルは現在システムにインストールされているファイルと比較されます。
異なるファイルは &man.diff.1; 形式で示され、
<option>+</option> の記号は追加または変更された行を表し、
<option>-</option> は完全に削除されたか新しく置き換えられた行を表します。
ファイルの違いの表示方法についてのより詳しい情報は、
&man.diff.1; を参照してください。</para>
<para>次に &man.mergemaster.8; は違いのあるファイルをそれぞれ示し、
選択可能なオプションを表示します。
ここでは、新しいファイルを削除するか、
一時ファイルをそのままインストールするか、
一時ファイルと現在インストールされているファイルを統合するか、
もしくは結果をもう一度見るかを選択できます。</para>
<para>一時ファイルの削除を選ぶと、<command>mergemaster</command>
に現在のファイルを変更しないで新しいバージョンを削除せよと伝えます。
この選択は、お勧めできません。
<command>mergemaster</command>
のプロンプトで <keycap>?</keycap> とタイプすれば、
いつでもヘルプが見られます。
ファイルのスキップを選ぶと、他のすべてのファイルを終えたあと、
もう一度そのファイルが提示されます。</para>
<para>一時ファイルをそのままインストールすることを選ぶと、
現在のファイルを新しいファイルで置き換えます。
ほとんどの手を加えていないファイルは、
これが一番よい選択です。</para>
<para>ファイルの統合を選んだ場合、
テキストエディタが起動され、両方のファイルの中身が提示されます。
画面上に並ぶ両方のファイルを見て新しいファイルを作成するために両方から必要な部分を選択し、
2 つのファイルを統合することができます。
並んでいるファイルを比較するとき、
<keycap>l</keycap> で左側の中身を選択し、
<keycap>r</keycap> で右側の中身を選択します。
最終出力は左右両方の部分でできたファイルになるでしょう。
このファイルをインストールすることができます。
たいてい、このオプションはユーザが設定を変更したファイルに使われます。</para>
<para>結果をもう一度見る、を選択すると、
ファイルの相異点をもう一度見ることができます。</para>
<para><command>mergemaster</command>
がシステムファイルの比較を終えたあと、
他のオプションについてもプロンプトが表示されます。
たとえば、
パスワードファイルを再構築するかどうかを尋ねることがあります。
最後に残った一時ファイルを削除するかどうかを尋ねて終了します。</para>
<!--
Probably not needed as changes should be minimal and mergemaster does
a good job of merging.
<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> や
他のディレクトリを更新したくなったときは、ターゲット
ディレクトリに、そのときの日付に基づく名前をつけてください。</para>
<screen>&prompt.root; <userinput>mkdir /var/tmp/root-20130214</userinput>
&prompt.root; <userinput>cd /usr/src/etc</userinput>
&prompt.root; <userinput>make DESTDIR=/var/tmp/root-20130214 \
distrib-dirs distribution</userinput></screen>
</step>
<step>
<para>上に説明されているように、
このディレクトリから変更点をマージします。
その作業が終了しても、
<filename>/var/tmp/root-20130214</filename>
を削除しては<emphasis>いけません</emphasis>。</para>
</step>
<step>
<para>最新版のソースをダウンロードして再構築したら、
ステップ 1 にしたがってください。今度は、
新しい日付を反映したディレクトリを作成してください。
この例では、<filename>/var/tmp/root-20130221</filename>
という新しいディレクトリをつくります。</para>
</step>
<step>
<para>&man.diff.1; を使用し、
二つのディレクトリを比較する再帰的 diff を作成することで、
一週間の間に行なわれたソースへの変更による相違点を調べます。
</para>
<screen>&prompt.root; <userinput>cd /var/tmp</userinput>
&prompt.root; <userinput>diff -r root-20130214 root-20130221</userinput></screen>
<para>これによって報告される相違点は、大抵の場合、
<filename>/var/tmp/root-20130221/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-20130214</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>
-->
</sect2>
<sect2 xml:id="make-delete-old">
<info>
<title>使われなくなったファイル、ライブラリの削除</title>
<authorgroup>
<author>
<personname>
<firstname>Anton</firstname>
<surname>Shterenlikht</surname>
</personname>
<contrib>ベースとなったノートの提供: </contrib>
</author>
</authorgroup>
</info>
<indexterm>
<primary>Deleting obsolete files and directories</primary>
</indexterm>
<para>&os; の開発サイクルにおいて、
ファイルやシステムの一部が使われなくなることがあります。
それらの機能が別の場所で実装されたり、
ライブラリのバージョン番号が変わったり、
システムから完全に削除されることがあるためです。
システムのアップデート時に削除が必要になるのは、
古いファイル、ライブラリそしてディレクトリです。
これらのファイルを削除することで、
記憶媒体やバックアップ媒体において不必要な容量を占めている古いファイルが、
システム上に散乱することがなくなります。
また、古いライブラリのセキュリティや安定性に問題があると、
ライブラリを新しくしてシステムを安定な状態にし、
古いライブラリによりシステムがクラッシュすることを防がなければなりません。
使われなくなったファイル、ディレクトリ、ライブラリは
<filename>/usr/src/ObsoleteFiles.inc</filename>
にまとめられています。以下の手順により、
アップグレードの過程でこれらのファイルを削除できます。</para>
<para>
<command>make installworld</command>
と、その後の <command>mergemaster</command> が無事に終わったら、
使われなくなったファイルやライブラリを確認してください。</para>
<screen>&prompt.root; <userinput>cd /usr/src</userinput>
&prompt.root; <userinput>make check-old</userinput></screen>
<para>見つかった古いファイルは、以下のコマンドで削除できます。</para>
<screen>&prompt.root; <userinput>make delete-old</userinput></screen>
<para>使われなくなったファイルを削除する際、
ファイルごとに確認が求められます。
確認を省略し、自動的にファイルを削除するには、
以下のように <varname>BATCH_DELETE_OLD_FILES</varname>
を設定してください。</para>
<screen>&prompt.root; <userinput>make -DBATCH_DELETE_OLD_FILES delete-old</userinput></screen>
<para><command>yes</command>
をコマンドへパイプでつなげても省略できます。</para>
<screen>&prompt.root; <userinput>yes|make delete-old</userinput></screen>
<warning>
<title>Warning</title>
<para>使われなくなったファイルを削除すると、
削除したファイルに依存していたアプリケーションは壊れてしまいます。
特に、古いライブラリを削除する場合に起こり得ます。
通常、<command>make
delete-old-libs</command>
を実行する前に、
これらの古いライブラリを使っているプログラム、ports、
ライブラリを再構築する必要があります。</para>
</warning>
<para>共有ライブラリをチェックするユーティリティとして、
<package>sysutils/libchk</package>
<package>sysutils/bsdadminscripts</package>
を利用できます。</para>
<para>使われなくなった共有ライブラリは、
新しいライブラリと競合し、以下のようなメッセージを表示することがあります。</para>
<screen>/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</screen>
<para>この問題を解決するには、
まずライブラリがどの port によってインストールされたかを調べて下さい。</para>
<screen>&prompt.root; <userinput>pkg which /usr/local/lib/libtiff.so</userinput>
/usr/local/lib/libtiff.so was installed by package tiff-3.9.4
&prompt.root; <userinput>pkg which /usr/local/lib/libXext.so</userinput>
/usr/local/lib/libXext.so was installed by package libXext-1.1.1,1</screen>
<para>見つかった port をアンインストールし、
再構築、再インストールしてください。
この過程は <package>ports-mgmt/portmaster</package>
で自動化できます。
すべての ports が再構築され、
古いライブラリがどこにも使われていないことを確認したら、
以下のコマンドで古いライブラリを削除してください。</para>
<screen>&prompt.root; <userinput>make delete-old-libs</userinput></screen>
<para>もしちょっとした問題があった場合でも、
システムの一部を再構築するのは簡単です。
たとえば、アップグレードや <filename>/etc</filename>
のマージの途中で誤って
<filename>/etc/magic</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 xml:id="updating-questions">
<title>よくある質問</title>
<variablelist>
<varlistentry>
<term>変更が行なわれたら、
その度にシステムの再構築が必要になるのでしょうか?</term>
<listitem>
<para>それは変更の内容によります。
たとえば、<application>svn</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 週間分の変更を取り込むユーザもいますし、
変更のあった部分だけ再構築し、
すべての依存関係を確かめたいと考えるユーザもいます。
それらはどのくらいの頻度でアップグレードしたいか、
そして &os.stable;&os.current;
のどちらを追いかけているのかにもよります。</para>
</listitem>
</varlistentry>
<varlistentry>
<term>どうして
signal 11<indexterm>
<primary>signal 11</primary>
</indexterm>
(もしくは他のシグナル番号) のエラーがたくさん出て
コンパイルが失敗するのでしょうか?</term>
<listitem>
<para>これは通常、ハードウェアに問題があることを示しています。
world の再構築は、
ハードウェア (特にメモリ)
に対する負荷耐久試験を行なうための有効な手段です。
本当にこの問題によるものかどうかは、
<application>make</application>
をもう一度実行し、異なる段階で異常終了が発生するか、
ということから確認できます。</para>
<para>このエラーに対応するには、RAM を始めとして、
マシンの部品をメモリから交換して、
どの部分が悪いのかを調べてみてください。</para>
</listitem>
</varlistentry>
<varlistentry>
<term>終了したら <filename class="directory">/usr/obj</filename>
を削除してもかまいませんか?</term>
<listitem>
<para>このディレクトリには、
コンパイルの段階で生成された
すべてのオブジェクトファイルが含まれています。
通常 <command>make buildworld</command> の最初の段階では、
このディレクトリを削除して新しくつくり直すようになっています。
構築終了後も <filename>/usr/obj</filename>
を保存しておいても、あまり意味はありません。
削除すれば、だいたい 2GB
のディスクスペースを解放することができます。</para>
</listitem>
</varlistentry>
<varlistentry>
<term>構築を中断した場合、
その構築を途中から再開することはできますか?</term>
<listitem>
<para>それは、問題が起こるまでに、
どれだけの作業を終えているかによります。
一般的に <command>make buildworld</command> は、
基本的なツールや、
システムライブラリの新しいコピーを作成します。
その後、これらのツールやライブラリがインストールされてから、
自分自身の再構築に使われ、もう一度、インストールされます。
システムの残りの部分がその新しいシステムファイルを用いて作り直されます。</para>
<para>再構築の最終段階では、
まったく安全に以下のコマンドを実行することができます。
これは、前回の <command>make buildworld</command>
の作業をやり直しません。</para>
<screen>&prompt.root; <userinput>cd /usr/src</userinput>
&prompt.root; <userinput>make -DNO_CLEAN all</userinput></screen>
<para>次のメッセージ</para>
<screen>--------------------------------------------------------------
Building everything..
--------------------------------------------------------------</screen>
<para><command>make buildworld</command> の出力にある場合には、
上のようにしてもほとんど悪影響が現れることはありません。</para>
<para>もしこのメッセージがない場合には、
安全を確保し、後悔するようなことがないよう、
システムの再構築を最初からやり直しましょう。</para>
</listitem>
</varlistentry>
<varlistentry>
<term>make world を高速化できますか?</term>
<listitem>
<para>いくつかの方法で build world のプロセスを高速化できます。
たとえば、全体のプロセスは、
シングルユーザモードで動かすことで高速になります。
しかしながら、この方法では、プロセスが完了するまで、
ユーザがシステムにアクセスすることはできません。</para>
<para>ファイルシステムを注意深く設計したり、
ZFS データセットを使うことでも変わります。
<filename class="directory">/usr/src</filename>
<filename class="directory">/usr/obj</filename>
を、異なるディスク上の別のファイルシステムに置くことを検討してください。
また可能ならば、
異なるディスクコントローラに接続された異なるディスクにファイルシステムを置いてください。
<filename class="directory">/usr/src</filename>
をマウントする時には、
最後にアクセスされた時刻の書き込みを抑制するように、
<option>noatime</option>
オプションを付けてマウントしてください。
もし、<filename
class="directory">/usr/src</filename> が、
独立したファイルシステムではないときには、
<option>noatime</option> オプションで、<filename
class="directory">/usr</filename>
を再マウントしてください。</para>
<para><filename class="directory">/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>&gt;/usr/obj</filename>
が、ファイルシステムにある唯一のディレクトリであれば、
これは問題になりません。
しかし、同じファイルシステムに、
他の貴重なデータを置いているときには、
このオプションを有効にする前に、
バックアップをきちんと取っておきましょう。</para>
</warning>
<para><filename>/etc/make.conf</filename>
<quote>NO_PROFILE=true</quote> をセットして、
プロファイル版の作成を無効化してください。</para>
<para>&man.make.1;
<option>-j<replaceable>n</replaceable></option>
を指定して、複数のプロセスを並列に実行させてください。
これは、単一のプロセッサでも複数のプロセッサでも、
同様に恩恵を得ることができます。</para>
</listitem>
</varlistentry>
<varlistentry>
<term>なにか悪いことがあったらどうすればいいですか?</term>
<listitem>
<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>
</listitem>
</varlistentry>
</variablelist>
</sect2>
</sect1>
<sect1 xml:id="small-lan">
<info>
<title>複数のマシンで追いかける</title>
<authorgroup>
<author>
<personname>
<firstname>Mike</firstname>
<surname>Meyer</surname>
</personname>
<contrib>寄稿: </contrib>
</author>
</authorgroup>
</info>
<indexterm>
<primary>NFS</primary>
<secondary>複数のマシンにインストール</secondary>
</indexterm>
<para>複数のコンピュータで同じソースツリーを追いかけていて、
全部のマシンにソースをダウンロードして全部を再構築するのは、
ディスクスペース、ネットワーク帯域、
そして <acronym>CPU</acronym> サイクルの無駄使いです。
解決策は 1 つのマシンに仕事のほとんどをさせ、
残りのマシンは <acronym>NFS</acronym>
経由でそれをマウントする、というものです。
このセクションではそのやり方を概観します。
<acronym>NFS</acronym> の使い方の詳細については、<xref
linkend="network-nfs"/> をご覧下さい。</para>
<para>まず初めに、同じバイナリで動かそうとするマシンたちを決めます。
このマシンたちのことを<firstterm>ビルドセット</firstterm>と呼びます。
それぞれのマシンはカスタムカーネルを持っているかもしれませんが、
同じユーザランドバイナリを動かそうというのです。
このビルドセットから、
<firstterm>ビルドマシン</firstterm>となるマシンを 1 台選びます。
ベースシステムとカーネルを構築するのはこのマシンになります。
理想的には、このマシンは <command>make buildworld</command>
<command>make buildkernel</command>
を実行するのに十分な <acronym>CPU</acronym>
を持った速いマシンであるべきです。</para>
<para><firstterm>テストマシン</firstterm>
となるべきマシンも選んでください。
更新されたソフトウェアを使う前にそのマシンでテストするのです。
テストマシンはかなり長い時間落ちていても
だいじょうぶなマシン<emphasis>であったほうがいいでしょう</emphasis>
ビルドマシンでもかまいませんが、
ビルドマシンである必要はありません。</para>
<para>このビルドセットのマシンはすべて
<filename>/usr/obj</filename>
<filename>/usr/src</filename>
をビルドマシンから <acronym>FTP</acronym>
経由でマウントする必要があります。
ビルドセット自体が複数ある場合は、
<filename>/usr/src</filename>
はひとつのビルドマシン上にあるべきです。
他のマシンからはそれを <acronym>NFS</acronym>
マウントするようにしましょう。</para>
<para>ビルドセットのすべてのマシン上の
<filename>/etc/make.conf</filename>
<filename>/etc/src.conf</filename>
がビルドマシンと一致していることを確認してください。つまり、
ビルドマシンはビルドセットのどのマシンもインストールしようとしている
ベースシステムを全部ビルドしなければならないということです。
また、各ビルドマシンは <filename>/etc/make.conf</filename>
にそれぞれのビルドマシンのカーネル名を
<varname>KERNCONF</varname> で指定し、
ビルドマシンは自分自身のカーネルから順に全部のカーネル名を
<varname>KERNCONF</varname> にリストアップしてください。
ビルドマシンは各マシンのカーネル設定ファイルを <filename
class="directory">/usr/src/sys/<replaceable>arch</replaceable>/conf</filename>
に持っていなければなりません。</para>
<para>ビルドマシンにて、
<xref linkend="makeworld"/>
に書いてあるようにカーネルとベースシステムを構築してください。
でも、まだビルドマシンにはインストールしないでください。
そのかわり、
ビルドしたカーネルをテストマシンにインストールしてください。
<acronym>FTP</acronym> 経由で
<filename>/usr/src</filename> および <filename>/usr/obj</filename>
をテストマシンにマウントしてください。
その後、<command>shutdown now</command>
を実行してシングルユーザモードに移行し、
新しいカーネルとベースシステムをインストールし、
いつもするように
<command>mergemaster</command> を実行してください。
終わったら、再起動して通常のマルチユーザ動作に戻します。</para>
<para>テストマシンにあるものすべてがちゃんと動いている確信が得られたら、
同じ手順でビルドセットの他のマシンにも新しいソフトウェアをインストールします。</para>
<para>ports ツリーにも同じ方法が使えます。
最初のステップは、
ビルドセットのすべてのマシンが <acronym>NFS</acronym> 経由で
<filename>/usr/ports</filename> をマウントすることです。
そして、distfiles を共有するように
<filename>/etc/make.conf</filename> を設定します。
<acronym>NFS</acronym> マウントによってマップされる
<systemitem class="username">root</systemitem>
ユーザが何であれ、<varname>DISTDIR</varname>
はそのユーザが書き込める共通の共有ディレクトリに設定する必要があります。
ports をローカルでビルドする場合には、
各マシンは <varname>WRKDIRPREFIX</varname>
を自分のマシンのビルドディレクトリに設定しなければなりません。
また、ビルドシステムが packages
をビルドしてビルドセットのコンピュータに配布するのであれば、
<varname>DISTDIR</varname> と同じようにビルドシステム上の
<varname>PACKAGES</varname>
ディレクトリも設定してください。</para>
</sect1>
</chapter>