diff --git a/ja_JP.eucJP/books/handbook/cutting-edge/chapter.xml b/ja_JP.eucJP/books/handbook/cutting-edge/chapter.xml index 93577070b6..c1578156bd 100644 --- a/ja_JP.eucJP/books/handbook/cutting-edge/chapter.xml +++ b/ja_JP.eucJP/books/handbook/cutting-edge/chapter.xml @@ -1,3532 +1,3469 @@ Jim Mock 再構成、再編成および改訂: Jordan Hubbard 原作: Poul-Henning Kamp John Polstra Nik Clayton &os; のアップデートとアップグレード この章では あるリリースから次のリリースまでの期間にも、 &os; の開発は休みなく続けられています。 最新の開発ツリーと同期することを好む人もいますし、 公式のリリース版を好んで使う方もいます。 しかしながら、公式のリリースといえども、 セキュリティや他の重要な修正のため、時にはアップデートを行う必要があります。 使用しているバージョンに関わらず、&os; は、 手元のシステムを最新の開発ツリーと同期するために必要なツールをすべて用意しています。 そして、これらのツールは、&os; のバージョンをアップグレードするためにも使えます。 もしもあなたが、開発途中のシステムを追いかけようか、 それともリリースバージョンのどれかを使い続けようかと迷っているのなら、 きっとこの章が参考になるでしょう。 手元のシステムをアップデートする基本的なツールについても解説しています。 この章を読んで分かるのは: システムと Ports Collection のアップデートに用いるユーティリティについて freebsd-update, - Subversion, - CVSup, - CVS もしくは + Subversion もしくは CTM を使ったシステム更新方法 インストールされているシステムと、変更が行われていない状態との比較方法。 Subversion またはドキュメント用の ports を使って、 ドキュメントを最新のものにアップデートする方法。 2 つの開発ブランチ、&os.stable; と &os.current; の違い make buildworld (等) を使ってベースシステム全体を再構築しインストールする方法 この章を読む前に、以下の準備をしましょう。 ネットワーク接続の適切な設定 () サードパーティ製のソフトウェアのインストール方法の習得 () この章を通じて、 &os; のソースコードをダウンロードしたりアップデートするのに svn コマンドが用いられます。 このコマンドを使うには、devel/subversion port または package + role="package">devel/subversion port または package をインストールしておく必要があります。 Tom Rhodes 寄稿: Colin Percival ベースとなったノートの提供: FreeBSD Update Updating and Upgrading freebsd-update updating-upgrading セキュリティパッチを適用することは、コンピュータソフトウェア、 特にオペレーティングシステムを管理する上で重要な役割を果たします。 しかしながら、&os; においては、 このプロセスは簡単なものではありませんでした。 ソースコードにパッチを当て、コードからバイナリを再構築し、 バイナリを再びインストールする必要がありました。 現在では &os; に freebsd-update と呼ばれるユーティリティが追加され、状況は変わりました。 このユーティリティは 2 つの機能を持っています。 第一に、&os; ベースシステムのビルドやインストールを行うことなく、 バイナリによってセキュリティおよび eratta アップデートできます。 第二に、このユーティリティはマイナーおよびメジャーリリースのアップグレードに対応しています。 バイナリアップデートは、 セキュリティチームがサポートしているすべてのアーキテクチャとリリースで利用できます。 新しいリリースにアップデートする前に、現在のリリースのアナウンスに目を通し、 アップデートしようとしているリリースに対して重要な情報がないかどうかを確認してください。 これらのアナウンスは で確認できます。 もし crontab の中に freebsd-update の機能が含まれていたら、 以下の作業を行うまでは無効にしておいてください。 設定ファイル 設定ファイル /etc/freebsd-update.conf をデフォルトからきめ細かく調整して、 アップデートプロセスを制御するユーザもいます。 この作業は良く文書化されていますが、 以下のいくつかの項目については説明が必要でしょう。 # Components of the base system which should be kept updated. Components src world kernel このパラメータは、&os; のどの部分を最新に維持するかを設定します。 デフォルトではソースコード、ベースシステム全体、そしてカーネルをアップデートします。 Components に設定できる項目は、インストール時に選択できるものと同じです。 たとえば、ここで world/games を追加すると、 game にパッチが当たるようになります。 src/bin を追加すると、 src/bin ソースコードのアップデートを許可します。 この部分についてはデフォルトのままにしておき、 アップデートしたい項目をユーザがリストに加える形にするのがベストでしょう。 ソースコードとバイナリが同期していないと、 悲惨な結果をもたらす可能性があります。 # Paths which start with anything matching an entry in an IgnorePaths # statement will be ignored. IgnorePaths アップデートで変更されてはいけない特定のディレクトリ、 /bin や /sbin 等のパスを追加してください。 このオプションは、ローカルの変更点を freebsd-update が上書きすることを防ぐ目的にも利用できます。 # Paths which start with anything matching an entry in an UpdateIfUnmodified # statement will only be updated if the contents of the file have not been # modified by the user (unless changes are merged; see below). UpdateIfUnmodified /etc/ /var/ /root/ /.cshrc /.profile 指定したディレクトリにある設定ファイルを、 ローカルで変更されていない場合のみアップデートします。 ユーザがこれらのファイルを変更していると、 これらのファイルの自動アップデートは無効になります。 他に、KeepModifiedMetadata という別のオプションが存在します。 このオプションは、freebsd-update がマージ中に変更点を保存するようにします。 # When upgrading to a new &os; release, files which match MergeChanges # will have any local changes merged into the version from the new release. MergeChanges /etc/ /var/named/etc/ freebsd-update がマージすべきファイルが存在するディレクトリの一覧です。 ファイルのマージのプロセスは、 &man.mergemaster.8; と同様 &man.diff.1; パッチの連続です。 マージを承認するか、エディタを起動するか、 freebsd-update を中断するかどうかを選んでください。 もし、心配な点があれば、 /etc をバックアップしてからマージを承認してください。 mergemaster コマンドの詳細な情報については、 で確認してください。 # Directory in which to store downloaded updates and temporary # files used by &os; Update. # WorkDir /var/db/freebsd-update ここではすべてのパッチや一次ファイルを置くディレクトリを指定しています。 バージョンをアップグレードするのであれば、 この場所には少なくともギガバイトの空き容量が必要です。 # When upgrading between releases, should the list of Components be # read strictly (StrictComponents yes) or merely as a list of components # which *might* be installed of which &os; Update should figure out # which actually are installed and upgrade those (StrictComponents no)? # StrictComponents no yes に設定すると、 freebsd-update は Components のリストが完全に正しいと判断し、 このリスト以外の変更点については取り扱いません。 freebsd-update は、効率的に Components リストに属するファイルをアップデートします。 セキュリティパッチ セキュリティパッチはリモートマシンに保存されており、 以下のコマンドを実行すると、ダウンロードしてインストールします。 &prompt.root; freebsd-update fetch &prompt.root; freebsd-update install カーネルにパッチが当たった場合には、システムを再起動する必要があります。 すべてがうまく実行でき、システムにパッチが当たるようであれば、 毎晩の &man.cron.8; ジョブとして freebsd-update を実行してもよいでしょう。 このタスクを実行できるようにするには、 以下のエントリを /etc/crobntab に追加してください。 @daily root freebsd-update cron このエントリは、毎日一度 freebsd-update ユーティリティを実行することを意味します。 このように に記述すると、 freebsd-update はアップデートが存在するときだけ確認します。 パッチが存在すると、 自動的にローカルディスクにダウンロードされますが、適用はされません。 ダウンロードされたパッチを手動でインストールすることが必要で、このことは root 宛てにメールで通知されます。 うまく行かなかった場合には、freebsd-update を以下のように実行すると、最後の変更までロールバックできます。 &prompt.root; freebsd-update rollback カーネルまたはカーネルモジュールがアップデートされた場合には、 完了後にシステムを再起動してください。 この作業によって、&os; がバイナリをメモリに読み込みます。 freebsd-update ユーティリティが自動的にアップデートするカーネルは GENERIC のみです。 カスタムカーネルを使っている場合には、freebsd-update が他の部分をアップデートした後、 カーネルを再構築し、もう一度インストールする必要があります。 GENERIC カーネルが /boot/GENERIC に存在する場合には、 freebsd-update により (現在のシステムで実行されているカーネルでなくとも) アップデートされます。 GENERIC カーネルを、常に /boot/GENERIC に置いておくことは良い考えです。 さまざまな問題を解決する際や、 に説明されているように、 freebsd-update を用いてバージョンをアップグレードする際に助けとなります。 /etc/freebsd-update.conf のデフォルトの設定を変更しない限り、 freebsd-update は、 他の更新と共にカーネルソースをアップデートします。 新しいカスタムカーネルの再構築と再インストールは、 通常通り行うことができます。 freebsd-update は、 常にカーネルをアップデートするとは限りません。 freebsd-update install によってカーネルソースが変更されなかった場合には、 カスタムカーネルを再構築する必要はありません。 しかしながら freebsd-update は、 /usr/src/sys/conf/newvers.sh ファイルを常にアップデートします。 これは、現在のシステムのパッチレベル (uname -r が -p で表示する番号) を示す際に参照されるファイルです。 そのため、何も変更されていない場合でも、カスタムカーネルを再構築することにより、 &man.uname.1; がシステムの正確なパッチレベルを報告するようになります。 各システムにインストールされているアップデートをすばやく把握できるようになるので、 特に複数のシステムを管理するときに助けとなります。 メジャーおよびマイナーバージョンのアップグレード &os; のマイナーバージョン間のアップグレード、 たとえば、&os; 9.0 から &os; 9.1 へのアップグレードは、 マイナーバージョン アップグレードと呼ばれます。 通常は、マイナーバージョンのアップグレードを行った後でも、 インストールされているアプリケーションは問題なく動きます。 メジャーバージョン アップグレードは、 &os; 8.X から &os; 9.X へのアップグレードといった、 &os; のメジャーバージョンが変わるようなアップグレードのことです。 メジャーバージョンのアップグレードでは、 古いオブジェクトファイルやライブラリが削除され、 これらに依存する多くのサードパーティ製アプリケーションに影響を与える可能性があります。 インストールされているすべての ports を削除して再インストールするか、 メジャーアップグレード後、 ports-mgmt/portupgrade ユーティリティを使ってアップグレードすることが推奨されています。 インストールされているアプリケーションのブルートフォース的な再構築は、 以下のコマンドにより行うことができます。 &prompt.root; portupgrade -af このコマンドは、すべての ports を適切に再インストールしようとします。 BATCH 環境変数を yes に設定しておくと、 アップデートプロセスの途中の質問に対し yes と答えるようになるので、 ビルドプロセスでの手動操作を省略できます。 カスタムカーネルの取り扱い カスタムカーネルを使用している場合には、アップグレードのプロセスは、 幾分複雑となります。 アップグレードの手順は &os; のバージョンによって変わります。 &os; 8.X 以前のシステムにおけるカスタムカーネル GENERIC カーネルが /boot/GENERIC に置かれている必要があります。 もし GENERIC カーネルがシステムに存在しない場合には、 以下のどれかの方法で用意してください。 ただ一度だけカスタムカーネルを構築したのであれば、 - /boot/kernel.old - は GENERIC カーネルそのものです。 - ただ単にこのディレクトリの名前を - /boot/GENERIC - へと変更してください。 + /boot/kernel.old + は GENERIC カーネルそのものです。 + ただ単にこのディレクトリの名前を + /boot/GENERIC + へと変更してください。 コンピュータへの物理的なアクセスが可能であれば、 CD-ROM メディアから GENERIC カーネルをインストールできます。 インストールディスクを挿入して、以下のコマンドを実行してください。 &prompt.root; mount /cdrom &prompt.root; cd /cdrom/X.Y-RELEASE/kernels &prompt.root; ./install.sh GENERIC ここで X.Y-RELEASE を実際のリリース番号に置き換えてください。 GENERIC は、デフォルトで /boot/GENERIC + class="directory">/boot/GENERIC にインストールされます。 上記の方法がすべて失敗するのであれば、 GENERIC カーネルをソースから再構築して、 インストールしてください。 &prompt.root; cd /usr/src &prompt.root; env DESTDIR=/boot/GENERIC make kernel __MAKE_CONF=/dev/null &prompt.root; mv /boot/GENERIC/boot/kernel/* /boot/GENERIC &prompt.root; rm -rf /boot/GENERIC/boot freebsd-update は、このカーネルを GENERIC カーネルとして扱います。 GENERIC コンフィグレーションファイルは、 とにかく変更してはいけません。 また、特別なオプションを指定しないで構築してください。 この時点で GENERIC カーネルで再起動する必要はありません。 &os; 9.X 以降のシステムにおけるカスタムカーネル ただ一度だけカスタムカーネルを構築したのであれば、 - /boot/kernel.old + /boot/kernel.old は GENERIC カーネルそのものです。 ただ単にこのディレクトリの名前を /boot/kernel へと変更してください。 コンピュータへの物理的なアクセスが可能であれば、 CD-ROM メディアから GENERIC カーネルをインストールできます。 インストールディスクを挿入して、以下のコマンドを実行してください。 &prompt.root; mount /cdrom &prompt.root; cd /cdrom/usr/freebsd-dist &prompt.root; tar -C/ -xvf kernel.txz boot/kernel/kernel 上記の方法が失敗するのであれば、 GENERIC カーネルをソースから再構築して、 インストールしてください。 &prompt.root; cd /usr/src &prompt.root; make kernel __MAKE_CONF=/dev/null freebsd-update は、このカーネルを GENERIC カーネルとして扱います。 GENERIC コンフィグレーションファイルは、 とにかく変更してはいけません。 また、特別なオプションを指定しないで構築してください。 この時点で GENERIC カーネルで再起動する必要はありません。 アップグレードを行う freebsd-update によるメジャー、またはマイナーバージョンのアップデートでは、 リリースバージョンをターゲットにして実行します。 たとえば、&os; 8.1 にアップデートするには以下のコマンドを実行してください。 &prompt.root; freebsd-update -r 8.1-RELEASE upgrade コマンドを実行すると、freebsd-update は設定ファイルと現在のシステムを評価し、 システムをアップデートするために必要な情報を収集します。 画面には、どのコンポーネントが認識され、 どのコンポーネントが認識されていないかといったリストが表示されます。 たとえば以下のように表示されます。 Looking up update.FreeBSD.org mirrors... 1 mirrors found. Fetching metadata signature for 8.0-RELEASE from update1.FreeBSD.org... done. Fetching metadata index... done. Inspecting system... done. The following components of FreeBSD seem to be installed: kernel/smp src/base src/bin src/contrib src/crypto src/etc src/games src/gnu src/include src/krb5 src/lib src/libexec src/release src/rescue src/sbin src/secure src/share src/sys src/tools src/ubin src/usbin world/base world/info world/lib32 world/manpages The following components of FreeBSD do not seem to be installed: kernel/generic world/catpages world/dict world/doc world/games world/proflibs Does this look reasonable (y/n)? y ここで、freebsd-update はアップグレードに必要なすべてのファイルをダウンロードします。 何をインストールし、どのように進むかといった質問をされることもあります。 カスタムカーネルを使っていると、 上記のステップで以下のような警告が表示されます。 WARNING: This system is running a "MYKERNEL" kernel, which is not a kernel configuration distributed as part of FreeBSD 8.0-RELEASE. This kernel will not be updated: you MUST update the kernel manually before running "/usr/sbin/freebsd-update install" この時点ではこの警告を無視してもかまいません。 アップデートされた GENERIC カーネルは、 アップグレードプロセスの途中で利用されます。 すべてのパッチがローカルシステムへダウンロードされたら、 次にパッチが適用されます。 このプロセスにかかる時間はコンピュータの性能とワークロードに依存します。 その後、設定ファイルがマージされます。 このプロセスでは、ファイルをマージするか、 画面上にエディタを立ち上げて手動でマージするかを尋ねられます。 プロセスごとに、マージに成功した情報がユーザに示されます。 マージに失敗したり、無視した場合には、プロセスが中断します。 ユーザによっては /etc のバックアップを取り、 master.passwd や group のような重要なファイルを後で手動でマージする方もいます。 すべてのパッチは別のディレクトリでマージされており、 まだ、システムには反映されていません。 すべてのパッチが正しく適用され、 すべての設定ファイルがマージされてプロセスがスムーズに進んでいる時には、 ユーザによる変更点のコミットは必要ありません。 このプロセスが終わったら、 以下のコマンドを用いて、アップグレードをディスクに反映してください。 &prompt.root; freebsd-update install パッチは最初にカーネルとカーネルモジュールに対して当てられます。 ここでコンピュータを再起動する必要があります。 システムがカスタムカーネルを実行している場合には、 &man.nextboot.8; コマンドを使って次回の再起動時のカーネルを (アップデートされた) /boot/GENERIC に変更してください。 &prompt.root; nextboot -k GENERIC GENERIC カーネルで再起動する前に、 システムが適切に起動するために必要な (もしコンピュータにリモートでアクセスしてアップデートしていたのであれば、 ネットワーク接続に必要な) すべてのドライバが含まれていることを確認してください。 特に、これまでに実行していたカスタムカーネルが (通常はカーネルモジュールとして提供されている) ビルド済みの機能を含んでいるのであれば、 これらのモジュールを一時的に /boot/loader.conf の機能を用いて、 GENERIC へと読み込んでください。 アップグレードプロセスが終わるまでは、 重要ではないサービスを無効にし、 ディスクやネットワークのマウントなどは避けてください。 アップデートされたカーネルでコンピュータを再起動してください。 &prompt.root; shutdown -r now システムがオンラインに戻ったら、 freebsd-update を再び実行する必要があります。 アップデートプロセスの状態は保存されているので、 freebsd-update を実行すると、最初からではなく、 古い共有ライブラリとオブジェクトファイルを削除するプロセスから始まります。 このステージを続行するには、以下のコマンドを実行してください。 &prompt.root; freebsd-update install 使用しているライブラリのバージョン番号の付けられ方によって、 3 つのインストールフェーズが 2 つになる場合もあります。 メジャーバージョンアップグレード後の ports の再構築 メジャーバージョンアップグレードを行った後では、 すべてのサードパーティ製のソフトウェアを再構築し、 再インストールする必要があります。 この作業が必要なのは、インストールされているソフトウェアが、 アップグレードの際に削除されたライブラリに依存している可能性があるためです。 ports-mgmt/portupgrade コマンドは、このプロセスを自動化します。 以下のコマンドで、このプロセスを開始します。 &prompt.root; portupgrade -f ruby &prompt.root; rm /var/db/pkg/pkgdb.db &prompt.root; portupgrade -f ruby18-bdb &prompt.root; rm /var/db/pkg/pkgdb.db /usr/ports/INDEX-*.db &prompt.root; portupgrade -af この作業の終了後、最後にもう一度 freebsd-update を実行すると、アップグレードのプロセスが完了します。 以下のコマンドですべてのアップグレードプロセスのやり残し作業が行われます。 &prompt.root; freebsd-update install GENERIC カーネルを一時的に読み込んでいたのであれば、 ここで、通常の方法を用いて新しいカスタムを構築し、インストールしてください。 コンピュータを再起動し、新しい &os; を立ち上げてください。 これでアップグレードのプロセスは完了です。 システムの状態の比較 freebsd-update ユーティリティを用いて、 インストールされている &os; の状態と、 正しく動作することが分かっている状態とを比較できます。 このオプションは、システムのユーティリティ、ライブラリ、 設定ファイルを評価します。 比較を行うには、以下のコマンドを実行してください。 &prompt.root; freebsd-update IDS >> outfile.ids コマンドライン名は IDS ですが、 security/snort のような侵入検知システムの置き換えになるものではありません。 freebsd-update はデータをディスクに保存するので、 明らかに不正な変更が行われる可能性があります。 この不正な変更の可能性は、 kern.securelevel の設定と、 freebsd-update のデータを使用しないときに、 読み取りのみの許可属性に設定されているファイルシステムに置くことで低くすることができますが、 よりよい解決方法は、 DVD または安全に保存されている外部 USB ディスクのような安全なディスクとシステムを比較することです。 これで、システムは検査されます。そして、 リリースファイルの &man.sha256.1; ハッシュ値と現在インストールされているファイルの値がファイルの一覧と共に表示されます。 これが outfile.ids ファイルに出力する理由です。 目で比較するにはとても早くスクロールし、 コンソールバッファをいっぱいに満たしてしまいます。 これらの行は極めて長いのですが、出力形式は簡単にすぐに解析できます。 たとえば、これらのリリースで異なっているすべてのファイルを知りたいのであれば、 以下のコマンドを実行してください。 &prompt.root; cat outfile.ids | awk '{ print $1 }' | more /etc/master.passwd /etc/motd /etc/passwd /etc/pf.conf 上の表示例では出力は切り捨てられており、 実際にはもっと多くのファイルが存在します。 これらのファイルには、運用中に変更されるファイルがあります。 たとえば、/etc/passwd はユーザがシステムに追加されると変更されます。 また、カーネルモジュールのようなファイルがあります。 これらは freebsd-update によりアップデートされます。 このような特別なファイルやディレクトリを除外するには、 それらを /etc/freebsd-update.conf の IDSIgnorePaths オプションに追加してください。 以前に議論した方法とは別に、 このシステムを入念なアップグレード方法の一部として用いることができます。 Tom Rhodes 寄稿: Colin Percival ベースとなったノートの提供: Portsnap: Ports Collection アップデートツール アップデートとアップグレード Portsnap アップデートとアップグレード &os; のベースシステムには、&man.portsnap.8; と呼ばれる Ports Collection のアップデートユーティリティがあります。 実行すると、リモートサイトに接続し、セキュリティキーを検証し、 Ports Collection をダウンロードします。 セキュリティキーは、 ダウンロードしたすべてのファイルがダウンロード中に変更されていないことの検証に用いられます。 最新の Ports Collection ファイルをダウンロードするには、 以下のコマンドを実行してください。 &prompt.root; portsnap fetch Looking up portsnap.FreeBSD.org mirrors... 9 mirrors found. Fetching snapshot tag from geodns-1.portsnap.freebsd.org... done. Fetching snapshot metadata... done. Updating from Tue May 22 02:12:15 CEST 2012 to Wed May 23 16:28:31 CEST 2012. 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. この例では、&man.portsnap.8; が現在の ports に対するパッチを見つけ、検証したことを示しています。 また、ユーティリティは以前に実行していることも示しています。 もし初めて実行したのであれば、Ports Collection のダウンロードのみが行われます。 &man.portsnap.8; が fetch に成功すると、 検証を通った Ports Collection と、 それに続くパッチがローカルシステムに存在します。 はじめて portsnap を実行した時には、 extract を使って、 ダウンロードしたファイルをインストールしてください。 &prompt.root; portsnap extract /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 ... すでにインストールされている Ports Collection をアップデートするには、以下のように portsnap update コマンドを使ってください。 &prompt.root; portsnap update これでアップデートプロセスは完了しました。 更新された Ports Collection を使って、 アプリケーションをインストールしたり、 アップグレードできます。 fetch と extract または update のプロセスを連続して行うには、 以下の例のように実行してください。 &prompt.root; portsnap fetch update このコマンドにより最新の Ports Collection がダウンロードされ、 /usr/ports 以下にあるローカルの Ports Collection がアップデートされます。 ドキュメントのアップデート Updating and Upgrading Documentation Updating and Upgrading ベースシステム、Ports Collection に加え、 ドキュメントも &os; オペレーティングシステムの構成要素です。 &os; ドキュメントセットの最新バージョンは、&os; ウェブサイト から入手できますが、 ネットワーク接続が遅い、もしくはまったく接続できないユーザもいます。 幸運にも、各リリースで提供されるドキュメントをアップデートして、 最新の &os; ドキュメントセットをローカルで維持する方法が用意されています。 <application>Subversion</application> を用いたドキュメントのアップデート方法 &os; のドキュメントのソースは、 Subversion を用いて入手できます。 この節では以下について説明します。 ドキュメントツールチェインのインストール方法。 このツールは、&os; のドキュメントをソースから再構築するのに必要です。 Subversion を用いて、 ドキュメントのソースを /usr/doc 以下にダウンロードする方法。 &os; ドキュメントをソースから再構築し、 /usr/share/doc 以下にインストールする方法。 ドキュメントのビルドシステムにおいてサポートされているビルドオプションの説明。 たとえば、翻訳されたドキュメンテーションのみを構築するオプションや、 ある特定の出力フォーマットを指定するようなオプションについて説明します。 <application>Subversion</application> およびドキュメントツールチェインのインストール &os; のドキュメントをソースから再構築するには、 かなり大きなツールのコレクションが必要です。 これらのツールは多くのディスク容量を必要とし、また、 すべての &os; ユーザにとって有用というわけではないので、 &os; ベースシステムの一部ではありません。 これらのツールは、&os; のために新しいドキュメントを活発に執筆している方や、 頻繁にドキュメントをソースからアップデートする方に向けたものです。 必要なツールは、すべて Ports Collection で入手できます。textproc/docproj は、 &os; ドキュメンテーションプロジェクトにより開発されているマスター port で、 これらのツールのインストールやアップデートを容易にします。 ドキュメントの &postscript; や PDF 版が必要なければ、かわりに textproc/docproj-nojadetex をインストールすることも考えてよいでしょう。 このドキュメンテーションのツールチェインは、 teTeX と呼ばれる組版エンジンを除いたすべてをインストールします。 teTeX は大きなツールのコレクションです。 そのため、もし PDF 出力を本当に必要としなければ、 このツールをインストールしないことはとても賢明です。 textproc/docproj をインストールすると、Subversion もインストールされます。 ドキュメントのソースをアップデートする ドキュメントのソースは、 Subversion プログラムを使ってダウンロードできます。 - ダウンロードするには以下のように入力してください。 + western US ミラーから HTTPS + プロトコルを用いてダウンロードするには以下のように入力してください。 + + &prompt.root; svn checkout https://svn0.us-west.FreeBSD.org/doc/head /usr/doc - &prompt.root; svn checkout svn://svn.FreeBSD.org/doc/head /usr/doc + 利用可能な Subversion ミラーサイト + の中からもっとも近いミラーを使ってください。 最初にドキュメントのソースをダウンロードするには少し時間がかかります。 ダウンロードが終わるまでお待ちください。 ダウンロードしたドキュメントのソースをアップデートするには、 以下のコマンドを実行してください。 &prompt.root; svn update /usr/doc ソースを入手したら、/usr/doc ディレクトリの Makefile を使い、 以下のようにドキュメントをアップデートすることもできます。 &prompt.root; cd /usr/doc &prompt.root; make update ドキュメントのソースの調整可能なオプション &os; のドキュメントのアップデートとビルドシステムは、 ドキュメンテーションの一部のアップデートを簡単にするオプションや、 特定の翻訳のビルドに対応しています。 これらのオプションは、システム全般のオプションである /etc/make.conf ファイルや、&man.make.1; ユーティリティに与えるコマンドラインオプションで設定できます。 以下がこれらのオプションの一部です。 DOC_LANG ビルドおよびインストールの言語およびエンコーディングの一覧。 たとえば、英語のドキュメントのみを指定するには en_US.ISO8859-1 を設定します。 FORMATS ビルドを行うフォーマット、または出力フォーマットの一覧。 現在は html, html-split, txt, ps, pdf, そして rtf に対応しています。 DOCDIR ドキュメントをインストールする場所。デフォルトは /usr/share/doc です。 &os; のシステム全般のオプションに関連するもっと多くの make 変数については、 &man.make.conf.5; をご覧ください。 &os; ドキュメントのビルドシステムで対応しているさらなる make の変数に関しては、 新しい貢献者のための &os; ドキュメンテーションプロジェクト入門 を参照してください。 ソースから &os; ドキュメントをインストールする ドキュメントのソースの最新スナップショットを /usr/doc にダウンロードし終わったら、 インストールされているドキュメントをアップデートする準備がすべて整いました。 makefile の DOC_LANG オプションで定義されているすべての言語を完全にアップデートするには、 以下のように入力してください。 &prompt.root; cd /usr/doc &prompt.root; make install clean もし、ある特定の言語のみをアップデートしたいのであれば、 /usr/doc サブディレクトリで以下のように &man.make.1; を実行してください。 &prompt.root; cd /usr/doc/en_US.ISO8859-1 &prompt.root; make update install clean make の FORMATS 変数を設定して、 以下のようにインストールする出力形式を指定できます。 &prompt.root; cd /usr/doc &prompt.root; make FORMATS='html html-split' install clean Marc Fonvieille ベースとなった作業: ドキュメンテーション ports Updating and Upgrading documentation package Updating and Upgrading これまでのセクションでは、ソースコードを用いた &os; ドキュメントのアップデート方法について説明してきました。 しかしながら、すべてのシステムにおいて、 ソースからドキュメントをアップデートすることは難しいかも知れませんし、 できたとしても現実的ではないこともあります。 ドキュメントをソースから構築するには、 かなり大きなツールとユーティリティから構成される ドキュメンテーションツールチェイン が必要です。 また、Subversion リポジトリからソースをチェックアウトし、 チェックアウトしたソースからドキュメントを手動で構築する方法について、 それなりに熟知している必要もあります。 この節では、インストールされている &os; のドキュメントをアップデートするもう一つの方法である、 Ports Collection を用いた以下の方法について説明します。 構築済のドキュメントのスナップショットをダウンロードしてインストールする方法。 ローカルでの構築作業は必要ありません (ドキュメンテーションツールチェインをインストールする必要はありません)。 ドキュメントのソースをダウンロードし、ports フレームワークを使って構築する方法 (チェックアウトおよび構築作業が簡単になります)。 &os; のドキュメントをアップデートするこれらの方法は、 &a.doceng; が毎月アップデートしている ドキュメンテーション ports によりサポートされています。 これらの ports は、&os; Ports Collection の docs 仮想カテゴリにまとめられています。 ドキュメンテーション ports の構築とインストール ドキュメンテーション ports では、 ports の構築フレームワークが用いられるので、 ドキュメントを簡単に構築できます。 この ports は、ドキュメントのソースを自動的にチェックアウトし、 環境変数やコマンドラインオプションを適切に設定して &man.make.1; を実行します。 また、他の &os; port, package のインストールと同様に簡単な方法で、 ドキュメントのインストールやアンインストールを行うことができます。 追加の機能として、この ports は ドキュメンテーションツールチェイン ports への依存を理解しているので、 構築時にはドキュメンテーションツールチェインも自動的にインストールされます。 ドキュメンテーション ports の構成は以下の通りです。 マスタ port, misc/freebsd-doc-en。 ドキュメンテーション port のファイルはここにあります。 この port は、すべてのドキュメンテーション ports のベースです。 デフォルトでは、英語の文書のみを構築します。 すべてのドキュメントの port, misc/freebsd-doc-all。 これは、すべての利用可能な言語のすべてのドキュメントを構築します。 最後に、各言語のために スレーブ port が用意されています。たとえば、misc/freebsd-doc-hu はハンガリー語のドキュメンテーション port です。 この port は、すべてマスタ port に依存し、 各言語の翻訳されたドキュメントをインストールします。 ソースからドキュメンテーション port をインストールするには、 以下のコマンドを (root 権限で) 実行してください。 &prompt.root; cd /usr/ports/misc/freebsd-doc-en &prompt.root; make install clean 英語版の分割された HTML 形式 ( と同じ形式) のドキュメントが構築され、/usr/local/share/doc/freebsd ディレクトリにインストールされます。 共通のオプション ドキュメンテーション ports にはたくさんのオプションが用意されており、 ports の振る舞いをデフォルトの設定から変更できます。 以下はその中からいくつかをリストアップしたものです。 WITH_HTML HTML 形式を構築します。 それぞれのドキュメントごとに単一版の HTML ファイルが構築されます。 整形されたドキュメントは、 article.html や book.html といった名前で、 画像とともにインストールされます。 WITH_PDF &adobe; Portable Document Format を構築します。 &adobe; &acrobat.reader;, Ghostscript、 または、他の PDF リーダで読むためのものです。 整形されたドキュメントは、 article.pdf や book.pdf といった名前でインストールされます。 DOCBASE ドキュメントのインストール先を設定します。 デフォルトのインストール先は /usr/local/share/doc/freebsd です。 デフォルトのターゲットディレクトリは、 Subversion を用いる方法とは異なります。 なぜならば、この節で説明をしている方法では port を用いてインストールしており、 ports は通常 /usr/local ディレクトリ以下にインストールされるためです。 PREFIX 変数を使うことで、 このディレクトリ以外にもインストールできます。 以下は、上記の変数を用いてハンガリー語のドキュメントを PDF 形式でインストールする方法を示す、簡単な例です。 &prompt.root; cd /usr/ports/misc/freebsd-doc-hu &prompt.root; make -DWITH_PDF DOCBASE=share/doc/freebsd/hu install clean ドキュメンテーション package の利用 前節で説明した、 ソースからドキュメンテーション port を構築する方法では、 ドキュメンテーションツールチェインをローカルにインストールする必要があり、 また、ports の構築のためにディスク容量を必要とします。 ドキュメンテーションツールチェインをインストールするリソースがない場合や、 ソースから構築する場合には多くのディスク容量を必要とするため、 構築済みのドキュメンテーション ports のスナップショットが用意されています。 &a.doceng; は、毎月 &os; ドキュメンテーション package のスナップショットをアップデートしています。 これらのバイナリ package は、システムに用意されている &man.pkg.add.1;, &man.pkg.delete.1; などの package 管理ツールを用いて扱うことができます。 バイナリ package を使うと、 インストールする言語に用意されている すべて の形式の &os; ドキュメントがインストールされます。 たとえば、以下のコマンドを実行すると、 ハンガリー語のドキュメントの最新 package がインストールされます。 &prompt.root; pkg_add -r hu-freebsd-doc ドキュメントの package は、言語ごとに対応する port に lang-freebsd-doc の形式で名前がつけられています。 ここで、lang は言語コードの短縮形です。 ハンガリー語の場合は hu、簡体字の場合には zh_cn です。 ドキュメンテーション ports のアップデート インストール済みのドキュメンテーション port をアップデートするには、 ports のアップデートツールが用意されていれば十分です。 たとえば、以下のコマンドを実行すると、ports-mgmt/portupgrade ツールで、package だけを使ってハンガリー語のドキュメントをアップデートします。 &prompt.root; portupgrade -PP hu-freebsd-doc Pav Lucistnik Based on information provided by Using Docsnap Updating and Upgrading Docsnap Updating and Upgrading Docsnap is an &man.rsync.1; repository for updating installed &os; Documentation in a relatively easy and fast way. A Docsnap server tracks the documentation sources, and builds them in HTML format every hour. The textproc/docproj is unneeded with Docsnap as only patches to the built documentation exist. The only requirement for using this technique is the net/rsync port or package. To add it, use the following command: &prompt.root; pkg_add -r rsync Docsnap has been originally developed for updating documentation installed to /usr/share/doc, but the following examples could be adapted for other directories as well. For user directories, it does not require root privileges. To update the documentation set, issue the following command: &prompt.root; rsync -rltvz docsnap.sk.FreeBSD.org::docsnap /usr/share/doc There is only one Docsnap server at the moment; the docsnap.sk.FreeBSD.org shown above. Do not use the flag here as there are some items installed into /usr/share/doc during make installworld, which would accidentally be removed. To clean up, use this command instead: &prompt.root; rsync -rltvz --delete docsnap.sk.FreeBSD.org::docsnap/??_??\.\* /usr/share/doc If a subset of documentation needs to be updated, for example, the English documentation only, the following command should be used: &prompt.root; rsync -rltvz docsnap.sk.FreeBSD.org::docsnap/en_US.ISO8859-1 /usr/share/doc ]]> 開発ブランチを追いかける -CURRENT -STABLE FreeBSD には二つの開発ブランチがあります。 それは &os.current; と &os.stable; です。 この章ではそれぞれについて簡単に説明し、 どのようにしてあなたのシステムを対応するツリーに対して、 どうやって常に最新の状態に保つかについて扱います。 まずは &os.current;、次に &os.stable; について説明します。 訳: &a.hanai;、1996 年 11 月 6 日 最新の &os; を追いかける これを読む前に、 心にとめておいて欲しいことがあります。 &os.current; とは &os; の開発の 最前線 だということです。 &os.current; のユーザは高い技術力を持つことが要求され、 自分のシステムが抱える困難な問題を自力で解決できなければなりません。 もし &os; を使い始めたばかりなら、 これを運用することについて十分検討を重ねた方が良いでしょう。 &os.current; ってなに? &os.current; は &os; の最新の、そして作業進行中のソースです。 中には現在開発途上のソフトウェア、 実験的な変更、あるいは過渡的な機能などが含まれています。 また、この中に入っている機能がすべて、 次の公式リリースに入るとは限りません。 &os.current; をソースからほぼ毎日コンパイルしている人は たくさんいますが、 時期によってはコンパイルさえできない状態になっていることもあります。 これらの問題は可能な限り迅速に解決されますが、 &os.current; が不幸をもたらすか、 それとも非常に素晴らしい機能をもたらすかは、 まさにソースコードを手に入れた瞬間によるのです! 誰が &os.current; を必要としてるの? &os.current; は、 次の三つの重要なグループを対象としています。 ソースツリーのある部分に関して活発に作業している &os; コミュニティのメンバ。 彼らにとっては 最新のもの にしておくのが 絶対に必要なことなのです。 活発にテストしている &os; コミュニティのメンバ。 彼らは、&os.current; が 健全である ことを可能な限り保証するために、 種々の問題を解決するのに時間を惜しまない人々です。 彼らはまた、様々な変更に関する提案や &os; の大まかな方向付けを行ないたいと思っている 人々でもあり、それを実装するためのパッチを提示します。 単に、様々な事に目を向け、参考のために (たとえば動かすためではなく読むために) 最新のソースを使いたいと思っている人々。 これらの人々はまた、 時々コメントやコードを寄稿してくれます。 &os.current; に期待しては<emphasis>いけない</emphasis>ことは? なにか新しくカッコイイモノがあると聞き、 自分の周囲では一番にそれを持ちたいがために、 リリース前のコードの断片を追いかけること。 新しい機能を得るために一番乗りになるということは、 新しいバグに最初にぶち当たるということです。 バグを修正するための素早い方法。 いかなるバージョンの &os.current; であれ、 元からあるバグを修正するのと同じく、 新しいバグを生み出すおそれがあります。 公式にサポートする こと。 わたしたちは 3 つの 公式な &os.current; のグループの一つに、 実際に属する人々を助けるのにベストを尽くしますが、 技術的なサポートを行なうには、単に「時間が足りない」のです。 これはわたしたちが外の人を助けるの好まない、 ケチで意地悪い人間だということではありません (もしそうなら &os; なんてやっていません)。 わたしたちは一日に何百通ものメッセージに答え、 かつ &os; の作業をすることなど出来ない! というだけのことなのです。 もし、&os; の改良作業を続けるか、 それとも実験的なコードに関するたくさんの質問に答えるか、 という二つの選択を迫られたら、開発者は前者を選ぶでしょう。 &os.current; を使う -CURRENT 使用 &a.current.name; と &a.svn-src-head.name; メーリングリスト に加わってください。 これは単に良い考えであるというだけでなく、 必須のことなのです。 もし &a.current.name; メーリングリストに入っていなければ、 さまざまな人がシステムの現在の状態について 述べているコメントを見ることは決してありませんし、 従って他の人が既に見つけて解決している 多くの問題に戸惑ってあきらめてしまうでしょう。 さらに言うと、システムを正常に保つための 重要な情報を見逃してしまう可能性もあります。 &a.svn-src-head.name; メーリングリストでは、 それぞれの変更についての commit ログを見ることができます。 また、それに関して起こり得る副作用の情報を得ることができますので、 参加する価値のあるメーリングリストです。 これらの、もしくは他のメーリングリストに入るには、 &a.mailman.lists.link; をたどって参加したいメーリングリ ストをクリックしてください。残りの手順の説明はそこにあります。 もし、ソースツリー全体の変更点を追いかけることに興味があれば、 &a.svn-src-all.name; メーリングリストを購読してください。 &os; ミラーサイト - からのソースの入手。以下の 3 つの方法のいずれかでできます。 + からソースの入手するには、以下のようないくつかの方法があります。 - svn + Subversion - cvsup - - cron -CURRENT - CVSup を使った同期 + Subversion を使った同期 + + + -CURRENT + CTM を使った同期 svn プログラムを使って、 希望する開発ブランチ、 もしくはリリースブランチをチェックアウトしてください。 この方法は、開発中の &os; リポジトリへのアクセスを提供しており、 推奨されています。 - Subversion を使って - -CURRENT ベースシステムをチェックアウトする際の - URL のプレフィックスは、 - http://svn.freebsd.org/base/head/ - です。 + Subversion ミラーサイト + のひとつの head ブランチから + -CURRENT コードをチェックアウトしてください。 リポジトリサイズの観点から、 希望するサブツリーのみをチェックアウトすることが推奨されます。 - - cvsup を - /usr/share/examples/cvsup にある - standard-supfile という名称の - supfile と合わせて使ってください。 - 上に挙げた見本の supfile - をカスタマイズするとともに、あなたの環境に合わせて cvsup を設定する必要があります。 - - - cvsup は、 - プロジェクトにおいて廃止されたので、 - 現在では推奨されていません。 - - - - サンプルファイルの standard-supfile - は、&os; の特定のセキュリティブランチを追いかけるためのものであり、 - &os.current; 用ではありません。 - このファイルの中にある次の行を - - *default release=cvs tag=RELENG_X_Y - - 以下に置き換えてください。 - - *default release=cvs tag=. - - 使用可能なタグに関する詳細な説明は、 - ハンドブックの CVS タグ の章にあります。 - - - -CURRENT CTM を使った同期 CTMを用いる。 (接続料が高額だったり、email でのアクセスしかできないような) あまり良質でない TCP/IP 接続の場合には、CTM を利用すると良いでしょう。ただし、 これには多くの手間がかかりますし、 壊れたファイルを受けとってしまう可能性もあります。 そのため、最近ではあまり使われなくなっており、 長い間使用できなくなってしまう事態が発生する可能性があります (訳注: 保守する人が少ないためです)。 インターネットに接続しているシステムであれば、 Subversion を利用されることを推奨します。 もし、ソースを眺めるだけでなく、 走らせるために入手しているのであれば、 一部だけ選ぶのではなく、&os.current; の全体を手に入れてください。 なぜなら、ソースのさまざまな部分が他の部分の更新に依存しており、 一部のみをコンパイルしようとすると、 ほぼ間違いなくトラブルを起こすからです。 -CURRENT コンパイル &os.current; をコンパイルする前に /usr/src にある Makefile を良く読んでください。 アップグレードの処理の一部として、 少なくとも一回は最初に 新しいカーネルをインストールし て、world を再構築 すべきでしょう。&a.current; と /usr/src/UPDATING を読めば、次のリ リースへ向けて移ってゆくに当たって時々必要となる既存シス テムからの新システムの構築手順についての最新情報が得られ るでしょう。 アクティブになってください! もし &os.current; を走らせているなら、わたしたちはそれに関するコメント、 特に拡張やバグ潰しに関する提案を欲しています。 コードを伴う提案はもっとも歓迎されるものです! 安定版の &os; を使う 訳: &a.jp.iwasaki; &os.stable; ってなに? -STABLE &os.stable; とは定期的に公開されるリリースを作成するための開発ブランチです。 このブランチに加えられる変更は原則として、 事前に &os.current; で試験ずみであるという特徴があります。 ただそうであっても、 これは開発用ブランチの一つであるということに注意してください。 つまり、ある時点における &os.stable; のソースが どんな場合にも使えるものであるとは限らないということです。 このブランチはもう一つの開発の流れというだけであって、 エンドユーザ向けのものではありません。 誰が &os.stable; を必要としているの? もしあなたが FreeBSD の開発過程に興味があるとか、 それに対する貢献を考えていて、特にそれが 次回の ポイント リリースに関係するもの であるなら &os.stable; を追うことを考えると良いでしょう。 セキュリティ上の修正は &os.stable; ブランチに対して行なわれますが、 そのために &os.stable; を追う必要はありません。 すべての FreeBSD セキュリティ勧告には 影響のあるリリースで問題点を修正する方法が説明されており これは正確ではありません。 実際わたしたちは何年もの間古いリリースの FreeBSD をサポートしてはいるのですが、 永遠にサポートし続けることはできません。 現時点での古いリリースの FreeBSD のセキュリティポリシーの全説明を知るには、 http://www.FreeBSD.org/security/ を参照してください。 、 セキュリティ上の理由のみから開発用ブランチ全体を追いかけることは、 同時に望ましくない変更点まで取り込んでしまう可能性があるからです。 わたしたちは &os.stable; ブランチがいつも安定に動作するように 努めていますが、それが保証されているというわけではありません。 また、コードは &os.stable; に加えられる前に &os.current; で開発されるのですが、&os.stable; のユーザは &os.current; よりも多いため、&os.current; で発見されなかった バグが &os.stable; で発見され、時々それが問題となることがあるのは 避けることができません。 このような理由から、わたしたちは盲目的に &os.stable; を追いかけることを推奨しません。 特に、最初に開発環境でコードを十分に試験せずに プロダクション品質が要求されるサーバを &os.stable; にアップグレードしてはいけません。 もしそうするための資源的な余裕がない場合は、 リリース間のバイナリアップデート機能を利用して、 最新の FreeBSD リリースを使うことを推奨します。 &os.stable; を使う -STABLE 利用する &a.stable.name; メーリングリストに加わってください。 このメーリングリストでは、 &os.stable; の構築に関連する事柄や、 その他の注意すべき点 に関する情報が流れています。 また開発者は議論の余地がある修正や変更を考えている場合に、 このメーリングリストで公表し、 提案された変更に関して問題が生じるかどうかを返答する機会をユーザに与えます。 追いかけているブランチに関連する SVN メーリングリストに参加してください。 たとえば、9-STABLE ブランチを追いかけているのであれば、 &a.svn-src-stable-9.name; メーリングリストに参加してください。 変更がなされるごとに作成される commit log やそれに伴う 起こりうる副作用についての情報を読むことができます。 これらの、もしくは他のメーリングリストに入るには、 &a.mailman.lists.link; をたどって参加したいメーリングリ ストをクリックしてください。残りの手順の説明はそこにあります。 もし、ソースツリー全体の変更点を追いかけることに興味があれば、 &a.svn-src-all.name; メーリングリストを購読してください。 もし、あなたが新しいシステムをインストールしようとしていて、 毎月公開されている &os.stable; からビルドされたスナップショットをインストールしたいなら、 スナップショット web ページをご覧ください。 もしくは、ミラーサイトから最近の &os.stable; リリースをインストールし、下記の説明に従って最新の &os.stable; のソースコードに更新することもできます。 もし、既に &os; の以前のリリースが動いている場合で、 これをソースからアップグレードしようとするならば、 &os; ミラーサイト - から簡単に行えます。これには次の 3 つの方法があります。 + から簡単に行えます。以下のようないくつかの方法があります。 - svn - - - cvsup + Subversion cron -STABLE Subversion を使った同期 svn プログラムを使って、 希望する開発ブランチ、 もしくはリリースブランチをチェックアウしてください。 この方法は、開発中の &os; リポジトリへのアクセスを提供しており、 推奨されています。 ブランチ名については、現在の開発のヘッドブランチは head、および リリースエンジニアリングのページ の特定のブランチでは stable/9、または releng/9.0 となります。 Subversion を使ってベースシステムをチェックアウトする際の - URL のプレフィックスは、 - http://svn.freebsd.org/base/ - となります。 + URL のプレフィックスは、Subversion ミラーサイト + で説明されています。 リポジトリサイズの観点から、 希望するサブツリーのみをチェックアウトすることが推奨されます。 - - cvsup を - /usr/share/examples/cvsup にある - stable-supfile という名称の - supfile と合わせて使ってください。 - 上に挙げた見本の supfile - をカスタマイズするとともに、あなたの環境に合わせて cvsup を設定する必要があります。 - - - cvsup は、 - プロジェクトにおいて廃止されたので、 - 現在では推奨されていません。 - - - -STABLE CTM を使って同期する CTM 機能を使います。 インターネットへの接続に高速で安価な回線を利用できないのであれば、 この方法を検討してみましょう。 基本的には、 ソースに迅速でオンデマンドなアクセスが必要で、 - 接続のバンド幅が問題でなければ、cvsup - か ftp を使いましょう。そうで + 接続のバンド幅が問題でなければ、 + Subversion を使いましょう。そうで ない場合は CTM を使いましょう。 -STABLE 構築、コンパイル &os.stable; をコンパイルする前に、 /usr/src にある Makefile をよ く読んでください。 少なくとも一回はアップグレードの処理の一部として最初に 新しいカーネルをインストールし て、world を再構築 すべきでしょう。&a.stable; と /usr/src/UPDATING を読めば、次のリ リースへ向けて移ってゆくに当たって時々必要となる既存シス テムからの新システムの構築手順についての最新情報が得られ るでしょう。 ソースの同期 訳: &a.jp.iwasaki;、1997 年 9 月 13 日 インターネット接続 (または電子メール) を使用して、 あなたの興味の対象によって &os; プロジェクトのソースのある一部分または全体の最新を 追いかける方法は色々あります。 私たちが提供している基本的なサービスは Subversion、Anonymous CVS、CVSup と CTM - です: + linkend="svn">Subversion + と CTM です。 ソースツリーの一部を最新のものに更新することは可能です。 ただし、サポートされているアップデート手順は、 ソースツリー全体を最新のものに更新して、 ユーザランド (/bin や /sbin にあるような、ユーザが実行するプログラム全体のこと) およびカーネルのソースから再構築することのみであることに注意してください。 カーネルだけ、あるいはユーザランドだけというように、 ソースツリーの一部を更新した場合は、問題が生じることがよくあります。 この時に発生する問題はコンパイル時のエラーからカーネルパニック、 データの破壊とさまざまです。 - CVS - anonymous + Subversion - Subversion, - Anonymous CVS と - CVSup は pull - 同期モデルを採用しています。 - Subversion の場合、ユーザ - (または cron スクリプト) が svn + Subversion + は pull 同期モデルを採用しています。 + ユーザ (または cron スクリプト) が svn を起動し、ファイルを最新状態にします。 Subversion は、 ローカルのソースツリーをアップデートする最も好ましい方法です。 - cvsup および cvs も同様の原理で動作しますが、 - Subversion への移行に伴い廃止されました。 届けられる更新情報はその時点の最新のものであり、 また必要な時にだけ取り寄せられます。 興味のある特定のファイルやディレクトリに限定して更新することも簡単にできます。 クライアント側のソースツリーの状態・ - 設定ファイルの指定に従い、サーバによって更新情報が素早く生成されます。 - 本当にやむを得ない理由がない限り、同期システムとして、 - Subversion を用いるべきです。 - 他の同期メカニズムは廃止されており、将来停止する予定です。 - + 設定ファイルの指定に従い、サーバによって更新情報が素早く生成されます。 CTM 一方、CTM はあなたが持っているソースとマスタアーカイブ上に あるそれとの対話的な比較をおこないませんし、 あるいは向こう側から変更点を pull したりもしません。 そのかわりに、前回の実行時からの変更を認識するスクリプトが マスタ CTM マシン上で一日に数回実行され、 すべての変更を compress して通し番号を振り、 さらに電子メールで転送できるようにエンコードします (印字可能な ASCII キャラクタのみです)。受信した後は、 これらの CTM のデルタ は自動 的にデコード、検査してユーザのソースのコピーに変更を適用する &man.ctm.rmail.1; によって処理可能となります。 - この処理は CVSup や - Anonymous CVS よりずっと効率 - 的であり、pull モデルというよりむしろ + この処理は Subversion + よりずっと効率的であり、pull モデルというよりむしろ push モデルで あるため、私たちのサーバ資源の負荷は軽くなります。 もちろん他のトレードオフもあります。うっかりアーカイブ - の一部を消してしまっても、CVSup + の一部を消してしまっても、Subversion は壊れた部分を検出して再構築してくれます。 - CTM はこれをやってくれませんし、 - Anonymous CVS - はおそらく他の何よりも深く混乱してしまうことが多いでしょう。 - もしソースツリーの一部を消してしまったら、(最新の CVS + CTM はこれをやってくれません。 + もしソースツリーの一部を消してしまったら + (そしてバックアップを取っていないのであれば)、(最新の CTM ベースデルタ から) 一からやり直し、 - CTM か Anonymous CVS - を使って悪い部分を消去し、再同期させることによって - すべてを再構築しなければなりません。 + CTM + を使ってすべてを再構築しなければなりません。 <quote>world</quote> の再構築 world の再構築 &os; のどれか特定のバージョン (&os.stable;、&os.current; など) について、ローカルのソースツリーを同期させたら、 そのソースツリーを使ってシステムを再構築できます。 バックアップの作成 システムを再構築する前にバックアップを 作成することの重要性は、いくら強調してもし過ぎると言うことはありません。 システム全体の再構築とは (以降に書かれた手順に従っている限り) 難しい作業ではありませんが、 どんなに注意していたとしても、 あなた自身、あるいはソースツリーで作業している他の人達に手違いがあった時には、 システムが起動しなくなってしまう状態になることがあるのです。 まず、バックアップがきちんと作成されていることを確認して、 fixit フロッピーか起動可能な CD を用意してください。 多分、それを使うことはないと思いますが、 あとで後悔することのないよう、念のため用意しておきましょう。 メーリングリストに参加する メーリングリスト もともと、&os.stable; と &os.current; のコードブランチは、 開発中のものです。 &os; の作業に貢献してくださっている人達も人間ですから、 時にはミスをすることだってあるでしょう。 そのような間違いは、単に警告を示す見慣れない 診断メッセージをシステムが、表示するような、 全く害のないものであることもあれば、システムを起動できなくしたり、 ファイルシステムを破壊してしまうような、 恐ろしい結果を招くものかも知れません。 万が一、このような問題が生じた場合、 問題の詳細と、どのようなシステムが影響を受けるかについて書かれた 注意 (heads up) の記事が 適切なメーリングリストに投稿され、そして、その問題が解決されると、 問題解決 (all clear) のアナウンス記事が同様に 投稿されます。 &os.stable; や &os.current; ブランチに追随するために試そうとするのに、 &a.stable; や &a.current; を過去にさかのぼって読まないというのは、 自ら災難を招くことになるでしょう。 訳注: これらのメーリングリストは英語でやりとりされているため、 日本語での投稿は歓迎されません。英語でのやりとりができない人は、 FreeBSD 友の会 の運営しているメーリングリストをあたってみるのがいいでしょう。 <command>make world</command> は使わないこと 古いドキュメントの多くが、この目的に make world を使うことを薦めています。 これは、重要な手順をいくつか抜かしてしまうので、 何をしているかよく分かっていなければ使うべきではありません。 ほぼあらゆる場合において、make world を実行するのは間違っており、 ここで説明されている手順を用いるべきです。 システムを更新する正式な方法 システムを更新する前に、 /usr/src/UPDATING を読んでください。 このファイルには、用意したソースコードで buildworld を行う前に必要な手順が書かれています。 その後、以下の手順を踏んでください。 この節で説明するアップデートのプロセスは、古いコンパイラ、 古いカーネル、古い world、そして古いコンフィグレーションファイルからなる、 古いバージョンの &os; をアップデートすることを想定しています。 ここで world は、コアシステムのバイナリ、ライブラリ、 プログラミングファイルを意味します。 コンパイラは world の一部ですが、 いくつか特別に気をつけなければならないことがあります。 また、新しいシステムのソースをすでに入手していることも仮定しています。 もしシステムのソースコードが古いようでしたら、 を読んで、 ソースコードを新しいバージョンへ同期する方法の詳細を理解してください。 ソースからのシステムのアップデートは、 当初予想していたものよりとらえがたいものです。 長い年月において避けられない依存問題が判明したため、 &os; の開発者達は、推奨されるアプローチを大きく変更しました。 この節では、現在推奨されているアップグレードの手順の背後にある、 理論的根拠について説明します。 連続したアップデートの手順は、以下の問題に対応している必要があります。 古いコンパイラは、 新しいカーネルをコンパイルできない可能性があります (古いコンパイラはときどきバグを含んでいます)。 そのため、新しいカーネルの構築には、 新しいコンパイラを使う必要があります。 特に、新しいカーネルを構築する前に、 新しいコンパイラが構築されていなければなりません。 必ずしも、新しいカーネルを構築する前に、新しいコンパイラが インストールされている 必要があることを意味しているわけではありません。 新しい world は、 新しいカーネルの機能に依存している可能性があるため、 新しい world をインストールする前に、 新しいカーネルがインストールされていなければなりません。 これら 2 つの重要事項は、 以下の説明で中心となる buildworld, buildkernel, installkernel, installworld の基本です。 現在推奨されているアップグレードプロセスを採用したほうが良いという理由をすべて含んでいるわけではありません。 以下では、もう少し明確ではない点についてリストアップします。 古い world は、新しいカーネルでは正しく動かないかも知れません。 そのため、新しいカーネルをインストールしたら、 直ちに新しい world をインストールしてください。 設定の中には、新しい world をインストールする前に変更すべきものがありますが、 古い world を壊す可能性があります。 そのため、一般的に設定のアップデートは、 2 つの手順が必要です。 多くの場合、アップデートのプロセスは、ファイルを置き換えたり、 追加のみを行い、古いファイルを削除しません。 このことが問題を引き起こす可能性があります。 そのため、アップデートにおいては、 手動で削除すべきファイルがあることを、 特定のステップで指定することもあります。 これは将来自動化されるかもしれないし、されないかもしれません。 これらを配慮し、以下の推奨手順が作られました。 アップデートの細かい手順においては、追加の手順が必要になるかもしれませんが、 この中心となるプロセスは、しばらくの間変わっていません。 make buildworld 新しいコンパイラと関連ツールを最初にコンパイルし、 その後、新しいコンパイラで、 新しい world の残りの部分をコンパイルします。 コンパイルされたものは、 /usr/obj に格納されます。 make buildkernel &man.config.8; と &man.make.1; を用いた古い方法とは異なり、 /usr/obj にある 新しい コンパイラが用いられます。 これにより、コンパイラとカーネルのミスマッチを防ぐことができます。 make installkernel 新しくアップデートされたカーネルで起動できるように、 新しいカーネルとカーネルモジュールをディスク上に配置します。 シングルユーザモードで再起動 シングルユーザモードは、 すでに実行されているソフトウェアをアップデートする際の問題を最小限にします。 また、新しいカーネル上で古い world が実行される際の問題も最小限にします。 mergemaster 新しい world における最初の設定ファイルのアップデートを行います。 たとえば、新しいユーザグループをシステムに追加したり、 パスワードデータベースに対し、新しいユーザ名を追加するかもしれません。 前回のアップデート後に、 新しいグループや特別のシステムのユーザアカウントが追加された場合に、 installworld のステップで、 新しくインストールされたシステムのユーザまたはシステムのグループ名を問題なく使うことができるように、 この作業がときどき必要となります。 make installworld world を /usr/obj からコピーします。 これで、ディスクには新しいカーネルと world が置かれたことになります。 mergemaster ディスクに新しい world が置かれたので、 残りの設定ファイルをアップデートします。 再起動 新しいカーネル、world そして設定ファイルがロードされたので、 再起動が必要です。 もし、&os; のあるブランチのあるリリースから、 同じブランチの最新リリースにアップデートするのであれば (たとえば 7.0 から 7.1)、 この手順にしたがわなくても良いでしょう。 なぜならば、コンパイラ、カーネル、ユーザランド、そして設定ファイルの間で、 重度のミスマッチが起きることはあまり考えられないためです。 マイナーなアップデートでは、新しいカーネルの構築とインストール後に、 古いアプローチである make world を用いてもうまくいくでしょう。 しかしながら、メジャーリリースをまたいだアップデートでは、 この方法を用いないと、何らかの問題にぶつかるでしょう。 大きなアップグレード (たとえば  4.X から 5.0 へのアップデート) においては、(たとえば installworld の前に特定のファイルの名前の変更や削除などの) 特別な追加のステップも必要となるでしょう。 /usr/src/UPDATING ファイルを注意深く読んでください。 特にファイルの最後には、 現在推奨されているアップグレードの手順が詳しく正確に説明されています。 この手続きは、 開発者たちがある種のミスマッチを完全に避けるために、長い年月をかけて進化してきました。 願わくば、この現在の手順が長い間安定してほしいものです。 まとめると、現在、ソースからの &os; のアップグレードにおいて推奨されている方法は以下となります。 &prompt.root; cd /usr/src &prompt.root; make buildworld &prompt.root; make buildkernel &prompt.root; make installkernel &prompt.root; shutdown -r now まれに buildworld の前に mergemaster -p を余分に実行することが必要な場合があります。その場合は UPDATING にそう書かれています。 &os; のメジャーバージョンをまたいで更新するのでなければ、 通常はこの手順を省略してもなんら問題ないでしょう。 installkernel が無事に終了したら、(たとえば、ローダのプロンプトから boot -s を使って) シングルユーザモードで立ち上げましょう。 それから、以下を実行してください。 &prompt.root; mount -u / &prompt.root; mount -a -t ufs &prompt.root; adjkerntz -i &prompt.root; mergemaster -p &prompt.root; cd /usr/src &prompt.root; make installworld &prompt.root; mergemaster &prompt.root; reboot この後の説明を読んでください 上述の手順は、 とりあえず着手するための簡単なまとめにすぎません。 それぞれの手順をきちんと理解するために、 この後の節を読んでください。 カスタムカーネルを利用したいと考えているならなおさらです。 <filename>/usr/src/UPDATING</filename> を読む 何を始めるにしろ、まず最初に /usr/src/UPDATING (もしくはあなたがソースコードを どこにコピーしたにせよそれに相当するファイル) を読みましょう。 このファイルにはあなたが遭遇するかも知れない問題に対する重要な情報を 含んでいたり、あなたが特定のコマンドを実行しなければならなくなった時 その順序を指示したりするはずです。 UPDATING があなたが読んだ事柄と矛盾している時は UPDATING が優先します。 UPDATING を読むということは、前述の 適切なメーリングリストを購読する代わりにはなりません。 二つの要求は相補的なもので排他的なものではないのです。 <filename>/etc/make.conf</filename> の確認 make.conf まず、/usr/share/examples/etc/make.conf と /etc/make.conf を調べてください。 最初のファイルには、デフォルトの定義 (多くのものはコメントアウトされています) が含まれています。 これらを設定してソースからシステムを再構築するには、 変数の定義を /etc/make.conf に付け加えてください。 /etc/make.conf に追加された設定は、 make を実行するときに常に適用されるので、 システムに必要な設定を書いておくと良いでしょう。 標準的なユーザなら、 /usr/share/examples/etc/make.conf の NO_PROFILE 行を /etc/make.conf にコピーし、 コメントをはずすと良いでしょう。 NOPORTDOCS など、他の定義についても、 コメントを外す必要があるかどうか調べておきましょう。 <filename>/etc</filename> にあるファイルの更新 /etc ディレクトリには、 システム起動時に実行されるスクリプトだけでなく、 あなたのシステムの設定に関連する情報の大部分が 含まれています。そのディレクトリに含まれる スクリプトは、FreeBSD のバージョンによって多少異なります。 また、設定ファイルのなかには、稼働中のシステムが日々利用している ものもあります。実際には、/etc/group などがそれに該当します。 make installworld によるインストールの段階では、 特定のユーザ名、あるいはグループが存在していることを 要求する場面があります。システムのアップグレードを行なう際には、 それらのユーザ名やグループが削除、あるいは変更されて存在していない可能性が 考えられますが、そういった場合、システムのアップグレードを 行なっている間に、問題が発生する原因になります。 make buildworld において、 それらのユーザ名やグループが存在するか確認が行われる場合もあります。 この例の一つは、 smmsp ユーザが追加された時です。 &man.mtree.8; が /var/spool/clientmqueue を作成しようとする時、 そのユーザ名 (およびグループ) が存在しないためにインストールに失敗してしまったのです。 解決方法は、buildworld の前に オプションをつけて &man.mergemaster.8; を実行することです。 これを実行すると、buildworld や installworld が成功するために必要なファイルだけを比較します。 もし、あなたがもっと神経質な人なら、あなたが名前を変更したり、 削除してしまったグループが所有しているファイルを、 次のようにして調べることもできます。 &prompt.root; find / -group GID -print これは GID (グループ名もしくは数字で示されたグループ ID) で 指定されたグループが所有するすべてのファイルを表示します。 シングルユーザモードへの移行 シングルユーザモード コンパイルは、シングルユーザモードで行なった方が良いでしょう。 そうすることで多少速度が向上する、というちょっとした利点が あるだけでなく、システムの再インストールは重要なシステムファイル、 標準コマンド、ライブラリ、インクルードファイルなどを操作します。 稼働中のシステムに (特に他のユーザがそのシステムにログインしている時に) そのような変更を加えることは、トラブルを引き起こす原因となります。 マルチユーザモード もう一つの方法として、マルチユーザモードでシステムを再構築して、 シングルユーザモードに移行してからそれをインストールする、 というのがあります。もしこのような方法で行ないたい場合は、 以下の手順を構築が完了するところまで飛ばしてください。 シングルユーザモードに移行するのを、 installkernel もしくは installworld しなければならなくなるま で後回しにできます。 稼働中のシステムでシングルユーザモードに移行するには、 スーパユーザ (root) 権限で次のコマンドを実行します。 &prompt.root; shutdown now あるいはシステムを再起動し、ブートプロンプトから single user を選択すると、 シングルユーザモードでシステムを起動できます。 起動後、シェルプロンプトから次のように実行してください。 &prompt.root; fsck -p &prompt.root; mount -u / &prompt.root; mount -a -t ufs &prompt.root; swapon -a これはファイルシステムをチェックした後、 / を読み書き可能にして再マウント、 /etc/fstab に指定されている、 それ以外の UFS ファイルシステムをすべてマウントしてから スワップを有効にします。 CMOS クロックが地域時間に設定されていて GMT ではない場合 (&man.date.1; コマンドが正しい時間と地域 を表示しないなら当てはまります)、 次のコマンドを実行する必要があるかもしれません。 &prompt.root; adjkerntz -i こうすれば、 確実に地域時刻が正しく設定されます — これを怠ると、 あとあと問題になるかもしれません。 <filename>/usr/obj</filename> の削除 システムが再構築される時、構築されたものは (デフォルトで) /usr/obj 以下のディレクトリに格納され、 そのディレクトリの下は /usr/src と同じ構造となります。 このディレクトリをあらかじめ削除しておくことにより、 make buildworld の行程にかかる時間を短縮させ、 依存問題に悩まされるようなトラブルを回避することができます。 /usr/obj 以下のファイルには、 変更不可 (immutable) フラグ (詳細は &man.chflags.1; 参照) がセットされているものがある可能性があります。 そのため、まず最初にそのフラグを変更しなければなりません。 &prompt.root; cd /usr/obj &prompt.root; chflags -R noschg * &prompt.root; rm -rf * ベースシステムの再構築 出力メッセージの保存 実行される &man.make.1; からの出力は、ファイルに保存すると良いでしょう。 もし、何か障害が発生した場合、エラーメッセージのコピーを手元に残すことができます。 何が悪かったのか、あなた自身がそれから理解することはできないかも 知れませんが、&os; メーリングリストに投稿して、 誰か他の人からの助言を得るために利用することができます。 ファイルに保存する最も簡単な方法は、&man.script.1; コマンドを 使い、引数に出力を保存したいファイル名を指定することです。 これを make world の直前に行ない、再構築が終了してから exit と入力すると、出力を保存することができます。 &prompt.root; script /var/tmp/mw.out Script started, output file is /var/tmp/mw.out &prompt.root; make TARGET … compile, compile, compile … &prompt.root; exit Script done, … 出力を保存する場合、/tmp ディレクトリの中に 保存してはいけません。 このディレクトリは、次の再起動で削除されてしまう可能性があります。 出力の保存には、(上の例のように) /var/tmpや root のホームディレクトリが適しています。 ベースシステムの構築 まず、カレントディレクトリを /usr/src に 変更しなければなりません。次のように実行してください。 &prompt.root; cd /usr/src (もちろん、ソースコードが他のディレクトリにある場合には、 /usr/src ではなく、 ソースコードのあるディレクトリに移動してください)。 make make world を行なうには、&man.make.1; コマンドを使用します。 このコマンドは、Makefile というファイルから、 FreeBSD を構成するプログラムの再構築方法や、 どういう順番でそれらを構築すべきかといったような 指示を読み込みます。 コマンドラインの一般的な書式は、次のとおりです。 &prompt.root; make -x -DVARIABLE target この例では、 が &man.make.1; に渡されるオプションになります。 どのようなオプションが利用できるかについては、マニュアルページを 参照してください。 は、 Makefile に渡される変数であり、 この変数は Makefile の動作をコントロールします。 また、/etc/make.conf で設定される変数も 同様です。これは変数を設定するもう一つの方法として用意されています。 &prompt.root; make -DNO_PROFILE target は、プロファイル版のライブラリを構築しないことを指定する もう一つの記法で、/etc/make.conf 中の NO_PROFILE= true # Avoid compiling profiled libraries の行に対応します。 target は、&man.make.1; に どのように動作するのかを指示するためのものです。 各々の Makefile には、数多くの異なる ターゲット (target) が定義されていて、 指定されたターゲットによって動作が決まります。 Makefile に書かれているターゲットには、 あなたが指定しても意味を持たないものも含まれます。 これらは、システムの再構築に必要な段階を、多くの さらに細かい段階に分割するため、構築の過程で利用されるものです。 大抵の場合、&man.make.1; にパラメータを指定する必要はないでしょうから、 コマンドラインは次のようなものになるでしょう。 &prompt.root; make target ここで、target は、多くのビルドオプションのどれかになります。 最初のターゲットはいつも buildworld になるでしょう。 その名前が示すように、buildworld は /usr/obj 以下に新しい完全な ディレクトリツリーを構築し、もう一つのターゲット installworld は、そのツリーを 現在のマシンにインストールします。 選択肢が分けられていることは、二つの理由から非常に有用です。 まず第一に、稼働中のシステムに全く影響を与えることなく、 安全にシステムの構築作業を行えることです。 構築作業は 何にも依存せず独立して行なわれる ため、 マルチユーザモードで稼働中のシステムでも、何一つ 悪影響を与えずに buildworld を 実行することができます。 ただし、installworld は シングルユーザモードで行なうことをおすすめします。 第二に、NFS マウントを利用することで、 ネットワーク上の複数のマシンをアップグレードすることが 可能な点があげられます。たとえば三台のマシン、 A, B, C をアップグレードしたい場合には、まずマシン A で make buildworld と make installworld を実行します。 それから、マシン B とマシン C でマシン A の /usr/src と /usr/obj を NFS マウントし、make installworld とすることで 構築済みのシステムを各マシンにインストールすることができるのです。 world ターゲットも利用可能ですが、 このターゲットの利用は推奨されていません。 次のコマンド &prompt.root; make buildworld を実行してください。ここで make に オプションをつけると、 同時にいくつかのプロセスを生成させることができます。 この機能はマルチ CPU マシンで特に効果を発揮します。 構築過程の大部分では CPU 性能の限界より I/O 性能の限界の方が問題となるため、シングル CPU マシンにも効果があります。 普通のシングル CPU マシンで以下のコマンド &prompt.root; make -j4 buildworld を実行すると、&man.make.1; は最大 4 個までのプロセスを同時に実行します。 メーリングリストに投稿された経験的な報告によると、 4 個という指定が最も良いパフォーマンスを示すようです。 もし、複数の CPU を備えたマシンで SMP 設定が行なわれたカーネルを 利用しているなら、6 から 10 の間の値を設定し、速度がどれくらい 向上するか確認してみてください。 システムの構築にかかる時間 world の再構築 時間 構築時間を決める要素はさまざまありますが、 十分新しいマシンであれば、 トリックや近道を使わずに普通に構築した場合、&os.stable; の構築には 1, 2 時間しかかからないでしょう。 &os.current; の構築は、もう少し時間がかかります。 新しいカーネルの構築とインストール カーネル (kernel) 構築、コンパイル 新しいシステムの全機能を完全に利用できるようにするには、 カーネルの再構築をする必要があります。 再構築は、ある種のメモリ構造体が変更された時には特に必須であり、 &man.ps.1; や &man.top.1; のようなプログラムは、 カーネルとソースコードのバージョンが一致しないと正常に動作しないでしょう。 最も簡単で安全にカーネルの再構築を行なう方法は、 GENERIC を使ったカーネルを構築・インストールすることです。 GENERIC にはあなたが必要とするデバイスがすべて含まれていない かも知れませんが、あなたのシステムをシングルユーザモードで 起動させるのに必要なものはすべて入っています。 これは新しいバージョンのシステムがきちんと動作するかどうか 調べる良い方法の一つです。 GENERIC で起動してから、 あなたがいつも使っているカーネルコンフィグレーションファイルを 使って新しいカーネルを構築することで、 システムが正常に動作しているかどうか確かめることができます。 &os; では、新しいカーネルを構築する前に build world を行うことが重要です。 カスタムカーネルを構築したい場合、既にコンフィグレー ションファイルがあるならば、単に KERNCONF=MYKERNEL を使ってください。 &prompt.root; cd /usr/src &prompt.root; make buildkernel KERNCONF=MYKERNEL &prompt.root; make installkernel KERNCONF=MYKERNEL なお、kern.securelevel を 1 より大きく していて、かつカーネルのバイナリファイル に noschg のようなフラグを設定している場合 は、installkernel を行うのにシングル ユーザモードに移行しなければなりません。それ以外の場合は、マル チユーザモードでこれらのコマンドを問題なく動かせるはずです。 kern.securelevel について詳しくは &man.init.8; を、ファイルの様々なフラグについて詳しくは &man.chflags.1; をご覧ください。 シングルユーザモードで再起動する single-user mode 新しいカーネルが動作するかどうかテストするために、 シングルユーザモードで再起動するべきです。 シングルユーザモードでの起動は、 に書かれている手順に従ってください。 新しいシステムバイナリのインストール 次に、ここで installworld を使うことで新しいシステムバイナリのインストールを行ないます。 それには、以下のコマンドを実行してください。 &prompt.root; cd /usr/src &prompt.root; make installworld make buildworld でコマンドラインから 変数を指定した場合は、同じ指定を make installworld のコマンドラインにも 指定しなければなりません。 ただし、オプションについてはその限りではありません。 たとえば は installworld で絶対に使ってはいけません。 たとえば以下のように実行したなら、 &prompt.root; make -DNO_PROFILE buildworld 以下のようにしてインストールしなければなりません。 &prompt.root; make -DNO_PROFILE installworld もしそうしなかった場合、 make buildworld の段階で構築されていない プロファイル版ライブラリをインストールしようとしてしまうでしょう。 <command>make installworld</command> で更新されないファイルの更新 システムの再構築は、いくつかのディレクトリ ( 特に、/etc や /var や /usr) において、 新規に導入されたり、変更された設定ファイルによる ファイルの更新は行なわれません。 これらのファイルを更新するもっとも簡単な方法は、&man.mergemaster.8; を使うことです。これは自分でやることも可能なので、そうしても かまいません。 いずれの方法に従うにせよ、 必ず /etc のバックアップを取って不測の事態に備えてください。 Tom Rhodes 寄稿: <command>mergemaster</command> mergemaster &man.mergemaster.8; ユーティリティは Bourne シェルスクリプトで、 /etc にある設定ファイルとソースツリーの /usr/src/etc にある設定ファイルの違いを確認するのを手伝ってくれます。 これを使うのが、ソースツリーにある設定ファイルにシステムの設定ファイルを 更新するために推奨される方法です。 始めるには、プロンプトから単に mergemaster と入力して、 ファイルの比較を開始するのを見てください。 mergemaster は / を起点とした一時的なルート環境を構築し、 さまざまなシステム設定ファイルを (訳注: デフォルトでは /var/tmp/temproot に) 置いていきます。 次にこれらのファイルは現在システムにインストールされているファイルと比較されます。 この時点で、異なるファイルは &man.diff.1; 形式で示され、 の記号は追加または変更された行を表し、 は完全に削除されたか新しく置き換えられた行を表します。 &man.diff.1; の書式とファイルの違いの表示方法についてのより詳しい情報は、 &man.diff.1; を参照してください。 &man.mergemaster.8; は食い違いが起きているファイルをそれぞれ示します。 ここでは新しいファイル (一時ファイルとして参照されています) を削除するか、 一時ファイルをそのままインストールするか、 一時ファイルと現在インストールされているファイルを統合するか、 もしくは &man.diff.1; の結果をもう一度見るか選択できます。 一時ファイルの削除を選ぶと、&man.mergemaster.8; に現在のファイルを変更しないで新しいバージョンを削除せよと伝えます。 この選択は、現在のファイルを変更する理由が分からないのであれば、 お勧めできません。 &man.mergemaster.8; のプロンプトで ? とタイプすれば、 いつでもヘルプが見られます。 ファイルのスキップを選ぶと、他のすべてのファイルを終えたあと、 もう一度そのファイルが提示されます。 一時ファイルをそのままインストールすることを選ぶと、 現在のファイルを新しいファイルで置き換えます。 ほとんどの手を加えていないファイルは、 これが一番よい選択です。 ファイルの統合を選んだ場合、 テキストエディタが起動され、両方のファイルの中身が提示されます。 画面上に並ぶ両方のファイルを見て新しいファイルを作成するために両方から必要な部分を選択し、 2 つのファイルを統合することができます。 並んでいるファイルを比較するとき、 l キーで左側の中身を選択し、 r キーで右側の中身を選択します。 最終出力は左右両方の部分でできたファイルになるでしょう。 このファイルをインストールすることができます。 たいてい、このオプシュンはユーザが設定を変更したファイルに使われます。 &man.diff.1; の結果をもう一度見る、を選択すると、 ちょうど先ほど &man.mergemaster.8; が選択肢を表示する前と同じように、 ファイルの相異点を見ることができます。 &man.mergemaster.8; がシステムファイルの比較を終えたあと、 他のオプションについてもプロンプトが表示されます。 &man.mergemaster.8; が、パスワードファイルを再構築したいかどうか尋ねることがあります。 最後に残った一時ファイルを削除するかどうかを尋ねて終了します。 手動での更新 手動で更新することを選んだ場合、 単にファイルを /usr/src/etc から /etc に コピーしただけでは正常に動作させることはできません。 これらのファイルには、インストールという 手順を踏まなければならないもの が含まれています。 /usr/src/etc ディレクトリは /etc ディレクトリにそのまま置き換えられるような コピーではないからです。 また、/etc にあるべきファイルのうちで /usr/src/etc にないものもあります。 &man.mergemaster.8; を (勧められた通り) 使っているのであれば、次の節 まで飛ばしてもかまいません。 手動で行う際の 一番簡単な方法は、ファイルを新しいディレクトリにインストールしてから、 以前のものと異なっている部分を調べて更新作業を行なうことです。 既存の <filename>/etc</filename> をバックアップする 理論的に考えて、このディレクトリが自動的に 処理されることはありませんが、念には念を入れておいて 損はありません。たとえば以下のようにして、 既存の /etc ディレクトリを どこか安全な場所にコピーしておきましょう。 &prompt.root; cp -Rp /etc /etc.old は再帰的なコピーを行ない、 はファイルの更新時間や所有者などを保存します。 また、新しい /etc やその他のファイルを インストールするための、仮のディレクトリを作っておく必要があります。 仮ディレクトリは /var/tmp/root に置くのが良いでしょう。 同様に、必要なサブディレクトリもこの下に置きます。 &prompt.root; mkdir /var/tmp/root &prompt.root; cd /usr/src/etc &prompt.root; make DESTDIR=/var/tmp/root distrib-dirs distribution 上の例は、必要なディレクトリ構造をつくり、ファイルをインストールします。 /var/tmp/root 以下に作られる、 たくさんの空のディレクトリは削除する必要があります。 一番簡単なやり方は、次のとおりです。 &prompt.root; cd /var/tmp/root &prompt.root; find -d . -type d | xargs rmdir 2>/dev/null これは空ディレクトリをすべて削除します。 (空でないディレクトリに関する警告を避けるために、 標準エラー出力は /dev/null に リダイレクトされます) この段階の /var/tmp/root には、 本来 / 以下にあるべきファイルが すべて含まれています。 各ファイルを順に見て、既存のファイルと異なる部分を 調べてください。 /var/tmp/root 以下に インストールされているファイルの中には、 . から始まっているものがあります。 これを書いている時点で、それに該当するファイルは /var/tmp/root/ と /var/tmp/root/root/ の中にある シェルスタートアップファイルだけですが、 他にもあるかも知れません (これは、あなたがこれをどの時点で読んでいるかに依存します)。 ls -a を使って確かめてください。 もっとも簡単な方法は、二つのファイルを比較するコマンド &man.diff.1; を使うことです。 &prompt.root; diff /etc/shells /var/tmp/root/etc/shells これは、あなたの /etc/shells ファイルと 新しい /var/tmp/root/etc/shells ファイルの 異なる部分を表示します。 これらを、あなたが書き換えたものに変更点をマージするか、 それとも既存のファイルを新しいもので上書きするかを 判断する材料にしてください。 新しい root ディレクトリ (<filename>/var/tmp/root</filename>) の名前に タイムスタンプを付けておくと、 異なるバージョン間の比較を楽に行なうことができます。 頻繁にシステムの再構築を行なうということは、 /etc の更新もまた、頻繁に行う必要がある ということです。これはちょっと手間のかかる作業です。 この作業は、あなたが /etc にマージした、 新しく変更されたファイルの最新のセットのコピーを保存しておくことで 素早く行なうことができます。 下の手順は、それを実現するための一つの方法です。 普通に make world します。/etc や 他のディレクトリを更新したくなったときは、ターゲット ディレクトリに、そのときの日付に基づく名前をつけてください。 たとえば 1998 年 2 月 14 日 だとすれば、以下のようにします。 &prompt.root; mkdir /var/tmp/root-19980214 &prompt.root; cd /usr/src/etc &prompt.root; make DESTDIR=/var/tmp/root-19980214 \ distrib-dirs distribution 上に説明されているように、 このディレクトリから変更点をマージします。 その作業が終了しても、 /var/tmp/root-19980214 を 削除してはいけません。 最新版のソースをダウンロードして再構築したら、 ステップ 1 にしたがってください。今度は、 /var/tmp/root-19980221 (更新作業が一週間おきだった場合) のような名前の、新しいディレクトリをつくることになるでしょう。 この段階で &man.diff.1; を使用し、 二つのディレクトリを比較する再帰的 diff を作成することで、 一週間の間に行なわれたソースへの変更による相違点を調べます。 &prompt.root; cd /var/tmp &prompt.root; diff -r root-19980214 root-19980221 これによって報告される相違点は、大抵の場合、 /var/tmp/root-19980221/etc と /etc との場合に比べて 非常に少ないものになります。 相違点が少ないため、変更点を既存の /etc ディレクトリにマージすることは、比較的容易になります。 ここまで終了したら、/var/tmp/root-* の 二つのうち、古い方のディレクトリは削除して構いません。 &prompt.root; rm -rf /var/tmp/root-19980214 この工程を、/etc へ変更点をマージする 必要があるたび、毎回繰り返します。 ディレクトリ名の生成を自動化するには、&man.date.1; を利用することができます。 &prompt.root; mkdir /var/tmp/root-`date "+%Y%m%d"` 再起動 これで、作業はおしまいです。 すべてがあるべき正しい場所に存在することをチェックしたら、 システムを再起動します。これは、単に &man.shutdown.8; を実行するだけです。 &prompt.root; shutdown -r now 作業の完了 ここまで来れば、&os; システムのアップグレードは成功です。 おめでとうございます。 もしちょっとした問題があった場合でも、 システムの一部を再構築するのは簡単です。 たとえば、アップグレードの途中で誤って /etc/magic を削除して /etc にマージしてしまい、 その結果 file コマンドが動作しなくなってしまったような場合を考えてみてください。 これを修復するには、次のコマンドを実行すれば修復することができます。 &prompt.root; cd /usr/src/usr.bin/file &prompt.root; make all install 質問ですか? 変更が行なわれたら、その度にシステムの再構築が必要になるのでしょうか? それは変更の性質によるので、なんとも言えません。 - たとえば、CVSup を実行したとき、最後に実行したときから比べて + たとえば、Subversion を実行したとき、最後に実行したときから比べて 次にあげるようなファイルが更新されていたとします。 src/games/cribbage/instr.c src/games/sail/pl_main.c src/release/sysinstall/config.c src/release/sysinstall/media.c src/share/mk/bsd.port.mk このときには、改めてシステム全体を再構築する必要はないでしょう。 適切なサブディレクトリに移って make all install を行うだけで更新することができます。 しかし、もし何らかの大きな変更が行なわれているとき、たとえば src/lib/libc/stdlib が変更されている場合には、 システム全体を再構築するか、もしくはそのうち、 少なくとも静的にリンクされているもの (と、あなたが追加した 静的にリンクされたプログラム) を作り直す必要があります。 結局のところ、どの時点で現在のシステムをアップグレードするかは あなたが決めることです。 2 週間ごとにシステムを再構築し、その 2 週間の変更を取り込めば 幸せかもしれませんし、 変更のあった部分だけ再構築し、依存関係を確かめたいと考えるかも知れません。 もちろん、それらはどのくらいの頻度でアップグレードしたいか、 そして &os.stable; か &os.current; のどちらを追いかけているのかによります。 signal 11 signal 11 (もしくは他のシグナル番号) のエラーがたくさん出て コンパイルが失敗します。何が起こっているんでしょうか? これは通常、ハードウェアに問題があることを示しています。 システムの再構築は、ハードウェアに対する負荷耐久試験を行なうための 有効な手段の一つで、メモリに関係する問題がよく報告されます。 その大部分は、コンパイラが奇妙なシグナルを受け取り、 不可解な異常終了となることで発見されます。 本当にこの問題によるものかどうかは、再構築をもう一度実行し、 異なる段階で異常終了が発生するか、ということから確認できます。 この場合には、マシンの部品を交換して、どの部分が悪いのかを 調べてみることくらいしかできることはありません。 終了したら /usr/obj を削除しても かまいませんか? 一言で答えるなら「削除しても構わない」です。 /usr/obj には、 コンパイルの段階で生成された すべてのオブジェクトファイルが含まれています。 通常 make buildworld の最初の段階では、 このディレクトリを削除して新しくつくり直すようになっています。 その場合には、構築終了後の /usr/obj を保存しておいても、あまり意味はありません。 削除すれば、大きなディスクスペースを (現在はだいたい 2 GB あります) 解放することができます。 しかし、もしあなたが何を行なおうとしているのか理解しているなら、 この段階を省略して make buildworld を行なうことができます。 こうすると、ほとんどのソースは再コンパイルされないため、 構築はかなり高速化されます。 これは裏をかえせば、デリケートな依存関係の問題によって、 システムの構築が奇妙な失敗に終わる可能性があるということです。 &os; メーリングリストではしばしば、構築の失敗が、 この段階の省略によるものだということを理解せずに 不満の声をあげる人がいます。 構築を中断した場合、その構築を途中から再開することはできますか? それは、あなたが問題に気付く前に、 どれだけの作業を終えているかによって変わります。 一般的に (そしてこれは確実でしっかりした 規則ではありませんが)、 make buildworld の過程では、 基本的なツール ( &man.gcc.1; や &man.make.1; のようなもの) や、システムライブラリの新しいコピーが作成されます。 その後まず、これらのツールやライブラリはインストールされてから 自分自身の再構築に使われ、もう一度、インストールされます。 全体のシステム (ここでは &man.ls.1; や &man.grep.1; といった 標準的なユーザプログラムを含みます) は、 その新しいシステムファイルを用いて作り直されることになります。 もし、再構築が最終段階に入っていること が (記録しておいた出力を見たりすることで) わかっていたら、 (全く悪影響を与えることなく) 次のようにすることができます。 … fix the problem … &prompt.root; cd /usr/src &prompt.root; make -DNO_CLEAN all これは、前回の make buildworld の作業をやり直しません。 次のメッセージ -------------------------------------------------------------- Building everything.. -------------------------------------------------------------- が make buildworld の出力にある場合には、 上のようにしてもほとんど悪影響が現れることはありません。 もしこのメッセージがないとか、よく分からないという場合には、 安全を確保し、後悔するようなことがないよう、 システムの再構築を最初からやり直しましょう。 どのようにすれば make world を高速化できますか? シングルユーザモードで動かしてください。 /usr/src と /usr/obj ディレクトリを、 異なるディスク上の別のファイルシステムに置いてください。 また可能ならば、異なるディスクコントローラに接続された ディスクを使ってください。 さらに高速化するには、これらのファイルシステムを &man.ccd.4; (連結ディスクドライバ) デバイスを 使って、複数のディスク上に置いてください。 プロファイル版の作成を無効化してください。 (/etc/make.conf で NO_PROFILE=true をセットします) 普通、それが必要になることはありません。 &man.make.1; に オプ ションを指定して、複数のプロセスを並列に実行させてく ださい。 これはプロセッサが単一か複数かによらず、 どちらも同様に恩恵を得ることができます。 /usr/src のある ファイルシステムを、 オプションを付けてマウント (もしくは再マウント) してください。 これは、そのファイルシステムにおいて、 最後にアクセスされた時刻の書き込みを抑制します。 おそらく、この情報が必要になることはないでしょう。 &prompt.root; mount -u -o noatime /usr/src 上の例は、 /usr/src 自身が独立したファイルシステムで あることを想定しています。 もしそうでないときには (たとえば /usr の 一部である場合には)、 /usr/src ではなく 適切なマウントポイントを指定する必要があります。 /usr/obj のあるファイルシステムを、 オプションをつけてマウント (もしくは 再マウント) してください。これによって、 ディスクへの書き込みが非同期になります。 つまり、書き込み命令はすぐに完了するのに対し、 実際にデータがディスクに書き込まれるのは、その数秒後になります。 これによって、書き込み処理の一括化が可能になるため、 劇的なパフォーマンスの向上が期待できます。 このオプションを指定すると、ファイルシステムは 壊れやすくなってしまうことに注意してください。 このオプションを付けていて、突然電源が落ちた場合には、 再起動後にファイルシステムが復旧不能になる可能性が 非常に高くなります。 もし、/usr/obj 自身が独立した ファイルシステムであるならば、これは問題になりません。 しかし、同じファイルシステムに、他の貴重なデータを置いているときには、 このオプションを有効にする前に、 バックアップをきちんと取っておきましょう。 &prompt.root; mount -u -o async /usr/obj もし /usr/obj 自身が ファイルシステムでない場合には、適切なマウントポイントを指すように、 上の例の名前を置き換えてください。 なにか悪いことがあったらどうすればいいですか? 自分の環境に前のビルドの余計なゴミが残っていないことをはっきりと確認してください。 とても簡単です。 &prompt.root; chflags -R noschg /usr/obj/usr &prompt.root; rm -rf /usr/obj/usr &prompt.root; cd /usr/src &prompt.root; make cleandir &prompt.root; make cleandir ええ、make cleandir は本当に 2 回実行するのです。 そして、make buildworld を行い、 全プロセスを最初からやり直してください。 まだ問題があれば、エラーと uname -a の出力を &a.questions; に送ってください。 自分の設定についてさらに質問されても答えられるよう用意してください! Anton Shterenlikht ベースとなったノートの提供: 使われなくなったファイル、ディレクトリ、ライブラリの削除 Deleting obsolete files, directories and libraries &os; の開発サイクルにおいて、 ファイルやシステムの一部が使われなくなることがあります。 それらの機能が別の場所で実装されたり、 ライブラリのバージョン番号が変わったり、 システムから完全に削除されることがあるためです。 システムのアップデート時に削除が必要になるのは、 古いファイル、ライブラリそしてディレクトリです。 これらのファイルを削除すると、記憶媒体 (およびバックアップ媒体) において不必要な容量を占めている古いファイルが、 システム上に散乱することがなくなります。 また、古いライブラリのセキュリティや安定性に問題があると、 ライブラリを新しくしてシステムを安定な状態にし、 古いライブラリの実装からシステムがクラッシュすることを防がなければなりません。 使われなくなったファイル、ディレクトリ、ライブラリは /usr/src/ObsoleteFiles.inc にまとめられています。この節では、 アップグレードの過程でこれらのファイルを削除する方法について説明します。 システムは、 で説明した方法で構築されていると仮定します。 make installworld と、 その後の mergemaster コマンドが無事に終わったら、 以下の方法で使われなくなったファイルやライブラリを確認してください。 &prompt.root; cd /usr/src &prompt.root; make check-old 見つかった古いファイルは、以下のコマンドで削除できます。 &prompt.root; make delete-old その他のターゲットについては /usr/src/Makefile をご覧ください。 使われなくなったファイルを削除する際、ファイルごとに確認が求められます。 以下のように make の BATCH_DELETE_OLD_FILES 環境変数を設定すると、 確認が省略され、自動的にファイルが削除されます。 &prompt.root; make -DBATCH_DELETE_OLD_FILES delete-old yes をコマンドへパイプでつなげても省略できます。 &prompt.root; yes|make delete-old Warning 使われなくなったファイルを削除すると、 削除したファイルに依存していたアプリケーションは壊れてしまいます。 特に、古いライブラリを削除する場合に起こり得ます。 通常、make delete-old-libs を実行する前に、 これらの古いライブラリを使っているプログラム、ports、 ライブラリを再構築する必要があります。 共有ライブラリをチェックするユーティリティとして、 Ports Collection の sysutils/libchk や sysutils/bsdadminscripts を利用できます。 使われなくなった共有ライブラリは、 新しいライブラリと競合し、以下のようなメッセージを表示することがあります。 /usr/bin/ld: warning: libz.so.4, needed by /usr/local/lib/libtiff.so, may conflict with libz.so.5 /usr/bin/ld: warning: librpcsvc.so.4, needed by /usr/local/lib/libXext.so, may conflict with librpcsvc.so.5 この問題を解決するには、 まずライブラリがどの port によってインストールされたかを調べて下さい。 &prompt.root; pkg_info -W /usr/local/lib/libtiff.so /usr/local/lib/libtiff.so was installed by package tiff-3.9.4 &prompt.root; pkg_info -W /usr/local/lib/libXext.so /usr/local/lib/libXext.so was installed by package libXext-1.1.1,1 見つかった port をアンインストールし、 再構築、再インストールしてください。 この過程は ports-mgmt/portmaster や ports-mgmt/portupgrade ユーティリティで自動化できます。 すべての ports が再構築され、 古いライブラリがどこにも使われていないことを確認したら、 以下のコマンドで古いライブラリを削除してください。 &prompt.root; make delete-old-libs Mike Meyer 寄稿: 複数のマシンで追いかける NFS 複数のマシンにインストール 同じソースツリーを追いかけたいマシンを複数持っているなら、 全部のマシンにソースをダウンロードして全部再構築するのは資源、 つまりディスクスペース、ネットワーク帯域、そして CPU サイクルの無駄使いに思えます。 実際これは無駄で、解決策は 1 つのマシンに仕事のほとんどをさせ、 残りのマシンは NFS 経由でそれをマウントする、というものです。 このセクションではそのやり方を概観します。 準備 まず初めに、同じバイナリで動かそうとするマシンたちを決めます。 このマシンたちのことをビルドセットと呼びましょう。 それぞれのマシンはカスタムカーネルを持っているかもしれませんが、 同じユーザランドバイナリを動かそうというのです。 このビルドセットから、 ビルドマシンとなるマシンを 1 台選びます。 ベースシステムとカーネルを構築するのはこのマシンになります。 理想的には、このマシンは make buildworld と make buildkernel を実行するのに十分な CPU を持った速いマシンであるべきです。 テストマシンとなるべきマシンも選びたいでしょう。 更新されたソフトウェアを使う前にそのマシンでテストするのです。 テストマシンはかなり長い時間落ちていても だいじょうぶなマシンであったほうがいいでしょう。 ビルドマシンでもかまいませんが、ビルドマシンである必要はありません。 このビルドセットのマシンはすべて /usr/obj と /usr/src を同じマシンの同じ場所からマウントする必要があります。 理想的にはビルドマシンの 2 つの違うドライブ上にあるとよいのですが、 ビルドマシンに NFS マウントされていてもかまいません。 ビルドセット自体が複数ある場合は、 /usr/src はひとつのビルドマシン上にあるべきです。 他のマシンからはそれを NFS マウントするようにしましょう。 最後にビルドセットの全てのマシン上の /etc/make.conf と /etc/src.conf がビルドマシンと一致していることを確認してください。 つまり、ビルドマシンはビルドセットのどのマシンもインストールしようとしている ベースシステムを全部ビルドしなければならないということです。 また、各ビルドマシンは /etc/make.conf にそれぞれのビルドマシンのカーネル名を KERNCONF で指定し、 ビルドマシンは自分自身のカーネルから順に全部のカーネル名を KERNCONF にリストアップしてください。 各マシンのカーネルもビルドするのであれば、 ビルドマシンは各マシンのカーネル設定ファイルを /usr/src/sys/arch/conf に持っていなければなりません。 ベースシステム さて、準備は整ったので、ビルドしましょう。 に書いてあるようにカーネルとベースシステムを構築してください。 でも、まだインストールしないでください。 ビルドが終わったら、テストマシンに移り、 ビルドしたばかりのカーネルをインストールしてください。 テストマシンが NFS 経由で /usr/src と /usr/obj をマウントしているなら、 シングルユーザで再起動したときネットワークを使えるようにしてマウントする必要があります。 もっとも簡単な方法は、 マルチユーザモードで起動して、shutdown now を実行してシングルユーザモードに移行することです。 そうしたら、カーネルとベースシステムをインストールし、 いつもするように mergemaster を実行できます。 終わったら、 テストマシンを再起動して通常のマルチユーザ動作に戻します。 テストマシンにあるものすべてがちゃんと動いている確信が得られたら、 同じ手順でビルドセットの他のマシンにも新しいソフトウェアをインストールします。 Ports ports ツリーにも同じアイデアが使えます。 最初に重要な点は、 ビルドセットのすべてのマシンに同じマシンの /usr/ports をマウントすることです。 そして、distfiles を共有するために、 /etc/make.conf を適切に設定します。 NFS マウントによってマップされる root ユーザが何であれ、DISTDIR はそのユーザが書き込める共通の共有ディレクトリに設定する必要があります。 各マシンは WRKDIRPREFIX を自分のマシンのビルドディレクトリに設定しなければなりません。 最後に、パッケージをビルドして配布しようとしているなら、 DISTDIR と同じように PACKAGES ディレクトリも設定してください。