Jim
Mock
再構成、再編成および改訂:
Jordan
Hubbard
原作:
Poul-Henning
Kamp
John
Polstra
Nik
Clayton
&os; のアップデートとアップグレード
この章では
あるリリースから次のリリースまでの期間にも、
&os; の開発は休みなく続けられています。
最新の開発ツリーと同期することを好む人もいますし、
公式のリリース版を好んで使う方もいます。
しかしながら、公式のリリースといえども、
セキュリティや他の重要な修正のため、時にはアップデートを行う必要があります。
使用しているバージョンに関わらず、&os; は、
手元のシステムを最新の開発ツリーと同期するために必要なツールをすべて用意しています。
そして、これらのツールは、&os; のバージョンをアップグレードするために使えます。
この章では、開発ブランチを追いかける方法、および、&os;
システムをアップデートする基本的なツールについて解説しています。
この章を読んで分かるのは:
システムと Ports Collection
のアップデートに用いるユーティリティについて
freebsd-update,
Subversion もしくは
CTM
を使った &os; システムの更新方法
インストールされているシステムと、変更が行われていない状態との比較方法。
Subversion
またはドキュメント用の ports を使って、
インストールされているドキュメントを最新のものにアップデートする方法。
2 つの開発ブランチ、&os.stable; と &os.current; の違い
ベースシステム全体を再構築しインストールする方法
この章を読む前に、以下の準備をしましょう。
ネットワーク接続の適切な設定 ()
サードパーティ製のソフトウェアのインストール方法の習得
()
この章を通じて、
&os; のソースコードをダウンロードしたりアップデートするのに
svn が用いられます。
このコマンドを使うためには、devel/subversion port または package
をインストールしておく必要があります。
Tom
Rhodes
寄稿:
Colin
Percival
ベースとなったノートの提供:
&os; Update
Updating and Upgrading
freebsd-update
updating-upgrading
セキュリティパッチを適用することは、コンピュータソフトウェア、
特にオペレーティングシステムを管理する上で重要な役割を果たします。
しかしながら、&os; においては、
このプロセスは簡単なものではありませんでした。
ソースコードにパッチを当て、コードからバイナリを再構築し、
バイナリを再びインストールする必要がありました。
現在の &os; では freebsd-update
と呼ばれるユーティリティが追加され、状況は変わりました。
このユーティリティは 2 つの機能を持っています。
第一に、&os; ベースシステムのビルドやインストールを行うことなく、
バイナリによってセキュリティおよび eratta アップデートできます。
第二に、このユーティリティはマイナーおよびメジャーリリースのアップグレードに対応しています。
バイナリアップデートは、
セキュリティチームがサポートしているすべてのアーキテクチャとリリースで利用できます。
新しいリリースにアップデートする前に、
アップデートしようとしているリリースのアナウンスに目を通し、
重要な情報がないかどうかを確認してください。
リリースのアナウンスは
で確認できます。
もし crontab の中に
&man.freebsd-update.8; の機能が含まれていたら、
以下の作業を行うまでは無効にしておいてください。
設定ファイル
/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
リストに属するファイルをアップデートします。
セキュリティパッチ
以下のコマンドを実行すると、&os;
のセキュリティパッチがダウンロードされ、インストールされます。
&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/portmaster
といったユーティリティを使ってアップグレードすることが推奨されています。
インストールされているアプリケーションのブルートフォース的な再構築は、
以下のコマンドにより行うことができます。
&prompt.root; portmaster -af
このコマンドは、すべての ports を適切に再インストールしようとします。
BATCH 環境変数を
yes に設定しておくと、
アップデートプロセスの途中の質問に対し
yes と答えるようになるので、
ビルドプロセスでの手動操作を省略できます。
カスタムカーネルの取り扱い
カスタムカーネルを使用している場合には、アップグレードのプロセスは、
幾分複雑となります。
アップグレードの手順は &os; のバージョンによって変わります。
&os; 8.X におけるカスタムカーネル
GENERIC カーネルが
/boot/GENERIC
に置かれている必要があります。
もし GENERIC
カーネルがシステムに存在しない場合には、
以下のどれかの方法で用意してください。
ただ一度だけカスタムカーネルを構築したのであれば、
/boot/kernel.old
は GENERIC カーネルそのものです。
このディレクトリの名前を
/boot/GENERIC
へと変更してください。
コンピュータへの物理的なアクセスが可能であれば、
以下のコマンドを実行することで、
インストールメディアから GENERIC
カーネルをインストールできます。
&prompt.root; mount /cdrom
&prompt.root; cd /cdrom/X.Y-RELEASE/kernels
&prompt.root; ./install.sh GENERIC
ここで X.Y-RELEASE
を実際のリリース番号に置き換えてください。
GENERIC は、デフォルトで /boot/GENERIC
にインストールされます。
上記の方法がすべて失敗するのであれば、
GENERIC カーネルをソースから再構築して、
インストールしてください。
&prompt.root; cd /usr/src
&prompt.root; env DESTDIR=/boot/GENERIC make kernel __MAKE_CONF=/dev/null SRCCONF=/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
は GENERIC カーネルそのものです。
ただ単にこのディレクトリの名前を
/boot/kernel
へと変更してください。
コンピュータへの物理的なアクセスが可能であれば、
以下のコマンドで、インストールメディアから
GENERIC
カーネルをインストールできます。
&prompt.root; mount /cdrom
&prompt.root; cd /cdrom/usr/freebsd-dist
&prompt.root; tar -C/ -xvf kernel.txz boot/kernel/kernel
上記の方法が失敗するのであれば、
GENERIC カーネルをソースから再構築して、
インストールしてください。
&prompt.root; cd /usr/src
&prompt.root; make kernel __MAKE_CONF=/dev/null SRCCONF=/dev/null
freebsd-update は、このカーネルを
GENERIC カーネルとして扱います。
GENERIC コンフィグレーションファイルは、
とにかく変更してはいけません。
また、特別なオプションを指定しないで構築してください。
この時点で GENERIC
カーネルで再起動する必要はありません。
アップグレードを行う
freebsd-update
によるメジャー、またはマイナーバージョンのアップデートでは、
リリースバージョンをターゲットにして実行します。
以下のコマンドは、&os; 9.1 にアップデートします。
&prompt.root; freebsd-update -r 9.1-RELEASE upgrade
コマンドを実行すると、freebsd-update
は設定ファイルと現在のシステムを評価し、
アップデートするために必要な情報を収集します。
画面には、どのコンポーネントが認識され、
どのコンポーネントが認識されていないといったリストが表示されます。
たとえば以下のように表示されます。
Looking up update.FreeBSD.org mirrors... 1 mirrors found.
Fetching metadata signature for 9.0-RELEASE from update1.FreeBSD.org... done.
Fetching metadata index... done.
Inspecting system... done.
The following components of FreeBSD seem to be installed:
kernel/smp src/base src/bin src/contrib src/crypto src/etc src/games
src/gnu src/include src/krb5 src/lib src/libexec src/release src/rescue
src/sbin src/secure src/share src/sys src/tools src/ubin src/usbin
world/base world/info world/lib32 world/manpages
The following components of FreeBSD do not seem to be installed:
kernel/generic world/catpages world/dict world/doc world/games
world/proflibs
Does this look reasonable (y/n)? y
ここで、freebsd-update
はアップグレードに必要なすべてのファイルをダウンロードします。
何をインストールし、どのように進むかといった質問をされることもあります。
カスタムカーネルを使っていると、
上記のステップで以下のような警告が表示されます。
WARNING: This system is running a "MYKERNEL" kernel, which is not a
kernel configuration distributed as part of FreeBSD 9.0-RELEASE.
This kernel will not be updated: you MUST update the kernel manually
before running "/usr/sbin/freebsd-update install"
この時点ではこの警告を無視してもかまいません。
アップデートされた GENERIC カーネルは、
アップグレードプロセスの途中で利用されます。
すべてのパッチがローカルシステムへダウンロードされたら、
次にパッチが適用されます。
このプロセスには時間がかかります。
この時間はコンピュータの性能とワークロードに依存します。
その後、設定ファイルがマージされます。
このプロセスでは、ユーザはファイルをマージするか、
画面上にエディタを立ち上げて手動でマージするかを尋ねられます。
プロセスが進むごとに、成功したマージのすべての結果の情報がユーザに示されます。
マージに失敗したり、無視した場合には、プロセスが中断します。
ユーザによっては /etc
のバックアップを取り、
master.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; portmaster -f
この作業の終了後、最後にもう一度
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; のベースシステムには、
Ports Collection をアップデートする &man.portsnap.8; があります。
このユーティリティは、&os; のサイトに接続し、セキュリティキーを検証し、
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
ドキュメントは、&os; オペレーティングシステムの必須要素です。
&os; ドキュメントセットの最新バージョンは、&os; ウェブサイト
から入手できますが、
ネットワーク接続が遅い、もしくはまったく接続できないユーザもいます。
ローカルのドキュメントを最新の &os;
ドキュメントセットにアップデートする方法がいくつも用意されています。
Subversion
を用いたドキュメントのアップデート方法
&os; のドキュメントのソースは、
svn を用いて入手できます。
この節では以下について説明します。
ドキュメントツールチェインのインストール方法。
このツールは、&os;
のドキュメントをソースから再構築するのに必要です。
svn を用いて、
ドキュメントのソースを
/usr/doc
以下にダウンロードする方法。
&os; ドキュメントをソースから再構築し、
/usr/share/doc
以下にインストールする方法。
ドキュメントのビルドシステムにおいてサポートされているビルドオプションの説明。
たとえば、翻訳されたドキュメンテーションのみを構築するオプションや、
ある特定の出力フォーマットを指定するようなオプションについて説明します。
svn
およびドキュメントツールチェインのインストール
&os; のドキュメントをソースから再構築するには、
ツールのコレクションが必要です。
これらのツールは多くのディスク容量を使用するため、
&os; ベースシステムの一部ではありません。
また、すべての &os; ユーザにとって有用というわけではなく、&os;
のために新しいドキュメントを活発に執筆している方や、
頻繁にドキュメントをソースからアップデートする方に向けたものです。
svn を含め必要なツールは、
textproc/docproj メタ port
からインストールできます。この port は、
&os; ドキュメンテーションプロジェクトにより開発されています。
ドキュメントの &postscript; や PDF 版が必要なければ、かわりに
textproc/docproj-nojadetex
をインストールすることも考えてよいでしょう。
このドキュメンテーションのツールチェインは、
teTeX
と呼ばれる組版エンジンを除いたすべてをインストールします。
teTeX は大きなツールのコレクションです。
そのため、もし PDF 出力を本当に必要としなければ、
このツールをインストールしないことはとても賢明です。
ドキュメントのソースをアップデートする
以下の例では、svn を使って
western US ミラーから HTTPS プロトコルを用いて、
ドキュメントのソースをダウンロードします。
&prompt.root; svn checkout https://svn0.us-west.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 にダウンロードしたら、
インストールされているドキュメントをアップデートする準備がすべて整いました。
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
FORMATS を設定して、
以下のようにインストールする出力形式を指定できます。
&prompt.root; cd /usr/doc
&prompt.root; make FORMATS='html html-split' install clean
ドキュメントを編集したり、訂正したものを提出する方法については、
新しい貢献者のための &os;
ドキュメンテーションプロジェクト入門 をご覧ください。
Marc
Fonvieille
ベースとなった作業:
ドキュメンテーション ports
Updating and Upgrading
documentation package
Updating and Upgrading
これまでのセクションでは、ソースコードを用いた &os;
ドキュメントのアップデート方法について説明してきました。
すべての &os; システムで、
ソースからドキュメントをアップデートすることは難しいかも知れませんし、
できたとしても現実的ではないこともあります。
ドキュメントをソースから構築するには、
かなり大きなツールとユーティリティから構成される
ドキュメンテーションツールチェイン
が必要なためです。
また、svn
リポジトリからソースをチェックアウトし、
チェックアウトしたソースからドキュメントを手動で構築する方法について、
それなりに熟知している必要もあります。
この節では、インストールされている
&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。
すべての英語文書の ports をインストールします。
すべてのドキュメントの port
, misc/freebsd-doc-all。
これは、すべての利用可能な言語のすべてのドキュメントを構築します。
各言語のために スレーブ port
が用意されています。たとえば、misc/freebsd-doc-hu
はハンガリー語のドキュメンテーション port です。
たとえば、 と同じ形式である、
英語版の分割された HTML 形式を構築し、
/usr/local/share/doc/freebsd
にインストールするには以下の port をインストールしてください。
&prompt.root; cd /usr/ports/misc/freebsd-doc-en
&prompt.root; make install clean
共通のオプション
ドキュメンテーション ports
にはたくさんのオプションが用意されており、
以下のように
ports の振る舞いをデフォルトの設定から変更できます。
WITH_HTML
HTML 形式を構築します。
各ドキュメントに対し、単一版の HTML ファイルが構築されます。
整形されたドキュメントは、
article.html や
book.html といった名前で、
必要に応じて画像とともにインストールされます。
WITH_PDF
&adobe; Portable Document Format (PDF) を構築します。
整形されたドキュメントは、
article.pdf や
book.pdf
といった名前でインストールされます。
DOCBASE
ドキュメントのインストール先を設定します。
デフォルトのインストール先は /usr/local/share/doc/freebsd
です。
デフォルトのターゲットディレクトリは、
svn
を用いる方法とは異なります。
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 と同様に、ドキュメンテーション port
をアップデートできます。
たとえば、以下のコマンドを実行すると、ports-mgmt/portupgrade
から、package だけを使ってインストールされているハンガリー語のドキュメントをアップデートします。
&prompt.root; portmaster -PP hu-freebsd-doc
開発ブランチを追いかける
-CURRENT
-STABLE
&os; には二つの開発ブランチがあります。
それは &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; は、
次の 3 つの重要なグループを対象としています。
ソースツリーのある部分に関して活発に作業している
&os; コミュニティのメンバ。
彼らにとっては 最新のもの
にしておくのが
絶対に必要なことなのです。
活発にテストしている &os; コミュニティのメンバ。
彼らは、&os.current;
が 健全である
ことを可能な限り保証するために、
種々の問題を解決するのに時間を惜しまない人々です。
これらのテスターは、さまざまな変更に関する提案や
&os; の大まかな方向付けを行ないたいと思っている
人々でもあり、それを実装するためのパッチを提示します。
単に、さまざまな事に目を向け、
参考のために最新のソースを使いたいと思っている人々。
これらの人々はまた、
時々コメントやコードを寄稿してくれます。
&os.current;
に期待してはいけないことは?
次のリリースの前に、最も早く新しい機能を入手すること。
リリース前の機能は十分にテストされていないため、
バグを含んでいく可能性が大いにあります。
バグを修正するための素早い方法。
いかなるコミットは、
元からあるバグを修正するのと同じく、
新しいバグを生み出すおそれがあります。
公式のサポート
はありません。
&os.current; を使う
&a.current.name; と &a.svn-src-head.name;-CURRENT使用 メーリングリスト
に加わってください。
さまざまな人がシステムの現在の状態について述べているコメントを見たり、
システムを正常に保つための重要な情報を見逃さないために、
必須の ことです。
&a.svn-src-head.name; メーリングリストでは、
それぞれの変更についての
commit ログが記録されています。
また、それに関して起こり得る副作用の情報を得ることができますので、
参加する価値のあるメーリングリストです。
これらのメーリングリストに入るには、
&a.mailman.lists.link;
をたどって参加したいメーリングリストをクリックし、
手順の説明にしたがってください。
ソースツリー全体の変更点を追いかけるのであれば、
&a.svn-src-all.name; メーリングリストを購読してください。
&os; ミラーサイト
からソースの入手するには、以下のようないくつかの方法があります。
svnSubversion を使って、
希望する開発ブランチ、
もしくはリリースブランチをチェックアウトしてください。
この方法は、開発中の &os; リポジトリへのアクセスを提供しており、
推奨されています。
Subversion ミラーサイト
のひとつの head ブランチから
-CURRENT-CURRENTSubversion を使った同期 コードをチェックアウトしてください。
リポジトリサイズの観点から、
希望するサブツリーのみをチェックアウトすることが推奨されます。
CTM-CURRENTCTM を使った同期を用いる。
接続料が高額だったり、email でのアクセスしかできないような、
あまり良質でない TCP/IP 接続の場合には、CTM
を利用すると良いでしょう。ただし、Subversion
ほどには信頼はできません。
そのため、インターネットに接続しているシステムであれば、
Subversion
を利用されることを推奨します。
もし、ソースを眺めるだけでなく、
走らせるために入手するのであれば、
一部だけ選ぶのではなく、&os.current;
の全体を手に入れてください。
ソースのさまざまな部分が他の部分の更新に依存しており、
一部のみをコンパイルしようとすると、
ほぼ間違いなく問題が起きます。
&os.current; をコンパイル-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; を追う必要はありません。
すべての &os; セキュリティ勧告には
EOL に達していないすべてのリリースに対する問題点の修正方法が説明されています。
現時点での古いリリースの FreeBSD
のセキュリティポリシーの全説明を知るには、http://www.FreeBSD.org/ja/security/
を参照してください。
。
&os.stable; ブランチはいつもコンパイルができ、
安定に動作すべきですが、
それが保証されているというわけではありません。
また、コードは &os.stable; に加えられる前に
&os.current; で開発されるのですが、&os.stable; のユーザは
&os.current; よりも多いため、&os.current;
で発見されなかったバグが &os.stable; で発見され、
ときどきそれが問題となることがあるのは避けることができません。
このような理由から、盲目的に &os.stable;
を追いかけるべきではありません。
特に、最初に開発環境もしくはテスト環境でコードを十分に試験せずに、
プロダクション品質が要求されるサーバを &os.stable;
にアップグレードしてはいけません。
もし試験をする資源的な余裕がない場合は、
リリース間のバイナリアップデート機能を利用して、
最新の FreeBSD リリースを使うことを推奨します。
&os.stable; を使う
-STABLE
利用する
&os.stable; の構築に関連する事柄や、
その他の注意すべき点 に関する情報を得るために、
&a.stable.name; メーリングリストに加わってください。
また開発者は議論の余地がある修正や変更を考えている場合に、
このメーリングリストで公表し、
提案された変更に関して問題が生じるかどうかを返答する機会をユーザに与えます。
追いかけているブランチに関連する
svn メーリングリストに参加してください。
たとえば、9-STABLE ブランチを追いかけているユーザは
&a.svn-src-stable-9.name; メーリングリストに参加してください。
このリストでは、
変更がなされるごとに作成される commit log やそれに伴う
起こりうる副作用についての情報が記録されています。
これらのメーリングリストに入るには、
&a.mailman.lists.link;
をたどって参加したいメーリングリストをクリックし、
手順の説明にしたがってください。
ソースツリー全体の変更点を追いかけるには、
&a.svn-src-all.name; メーリングリストを購読してください。
毎月公開されている &os.stable;
からビルドされたスナップショットの新しいシステムをインストールするには、
詳細について、
スナップショット
をご覧ください。
もしくは、ミラーサイトから最近の
&os.stable; リリースをインストールし、下記の説明に従って最新の
&os.stable; のソースコードに更新することもできます。
既に &os; の以前のリリースが動いているシステムを
&os; ミラーサイト
からアップグレードするには、
以下のようないくつかの方法があります。
svnSubversion を使って、
希望する開発ブランチ、
もしくはリリースブランチをチェックアウしてください。
この方法は、開発中の &os; リポジトリへのアクセスを提供しており、
推奨されています。
ブランチ名については、現在の開発のヘッドブランチは
head、および リリースエンジニアリングのページ
の特定のブランチでは
stable/9、または
releng/9.0 となります。
Subversion-STABLESubversion を使った同期
を使ってベースシステムをチェックアウトする際の
URL のプレフィックスは、Subversion ミラーサイト
で説明されています。
リポジトリサイズの観点から、
希望するサブツリーのみをチェックアウトすることが推奨されます。
インターネットへの接続に高速な回線を利用できないのであれば、
CTM-STABLECTM を使って同期する
を検討してみましょう。
&os.stable;-STABLE構築、コンパイル をコンパイルする前に、
/usr/src/Makefile をよく読んでください。
アップグレードの処理の一部として最初に
新しいカーネルをインストールして、
world を再構築 してください。&a.stable; と
/usr/src/UPDATING を読んで、
次のリリースへ向けて移ってゆくに当たって、
ときどき必要となる既存システムからの新システムの構築手順についての最新情報を得てください。
ソースの同期
訳: &a.jp.iwasaki;、1997 年 9 月 13 日
インターネット接続または電子メールを使用して、&os;
プロジェクトのソースのある一部分または全体の最新を追いかける方法は色々あります。
基本的なサービスは Subversion
と CTM です。
ソースツリーの一部を最新のものに更新することは可能です。
ただし、サポートされているアップデート手順は、
ソースツリー全体を最新のものに更新し、
/bin, /sbin
といったユーザ空間で動作するもの、
およびカーネルソースを再構築することのみです。
ソースツリーの一部だけであったり、カーネルだけ、
もしくはユーザランドのプログラムだけを更新した場合は、
問題が生じることがよくあります。
この時に発生する問題はコンパイル時のエラーからカーネルパニック、
データの破壊とさまざまです。
Subversion
Subversion
は pull 同期モデルを採用しています。
ユーザ (または cron スクリプト) が svn
を起動し、ファイルを最新状態にします。
Subversion は、
ローカルのソースツリーをアップデートする最も好ましい方法です。
更新情報はその時点の最新のものであり、
ユーザはいつダウンロードするかをコントロールします。
特定のファイルやディレクトリに限定して更新することも簡単にできます。
更新情報はサーバによって素早く生成されます。
CTM
一方、CTM
はあなたが持っているソースとマスタアーカイブ上に
あるそれとの対話的な比較をおこないませんし、
あるいは向こう側から変更点を pull したりもしません。
そのかわりに、前回の実行時からの変更を認識するスクリプトが
マスタ CTM マシン上で一日に数回実行され、
すべての変更を compress して通し番号を振り、
さらに電子メールで、印字可能な ASCII
キャラクタのみで転送できるようにエンコードします。
受信した後は、
これらの CTM のデルタ
は自動
的にデコード、検査してユーザのソースのコピーに変更を適用する
&man.ctm.rmail.1; によって処理可能となります。
この処理は Subversion
よりずっと効率的であり、pull モデルというよりむしろ
push モデルであるため、
サーバ資源の負荷は軽くなります。
他のトレードオフもあります。
Subversion であれば、
うっかりローカルのアーカイブの一部を消してしまっても、
壊れた部分を検出して再構築してくれます。
CTM はこれをやってくれません。
もしソースツリーの一部を消してしまい、
そしてバックアップを取っていないのであれば、最新の CTM
ベースデルタ
を用いて、一からやり直し、
CTM
を使ってすべてを再構築しなければなりません。
world
の再構築
world
の再構築
&os.stable;、&os.current; などの
&os; のどれか特定のバージョンについて、
ローカルのソースツリーを同期させたら、
そのソースツリーを使ってシステムを再構築できます。
バックアップの作成
システムを再構築する前に、
バックアップを作成することの重要性は、
いくら強調してもし過ぎると言うことはありません。
システム全体の再構築とは難しい作業ではありませんが、
どんなに注意していたとしても、
ソースツリーそのものに手違いがあった時には、
システムが起動しなくなってしまう状態になることがあるのです。
まず、バックアップがきちんと作成されていることを確認して、
起動可能インストールメディアを用意してください。
多分、それを使うことはないと思いますが、
あとで後悔することのないよう、念のため用意しておきましょう。
メーリングリストに参加する
メーリングリスト
もともと、&os.stable; と &os.current; のコードブランチは、
開発中のものです。
&os; の作業に貢献してくださっている人達も人間ですから、
時にはミスをすることだってあるでしょう。
そのような間違いは、
単に警告を示す見慣れない診断メッセージをシステムが表示するような、
まったく害のないものであることもあれば、システムを起動できなくしたり、
ファイルシステムを破壊してしまうような、
恐ろしい結果を招くものかも知れません。
問題が生じた場合、
問題の詳細と、どのようなシステムが影響を受けるかについて書かれた
注意 (heads up)
の記事が適切なメーリングリストに投稿されます。
そして、その問題が解決されると、
問題解決 (all clear)
のアナウンス記事が同様に投稿されます。
&os.stable; や &os.current; ブランチを追随しているユーザで、
&a.stable; や &a.current; を読まないというのは、
自ら災難を招くようなものです。
訳注:
これらのメーリングリストは英語でやりとりされているため、
日本語での投稿は歓迎されません。英語でのやりとりができない人は、
FreeBSD 友の会
の運営しているメーリングリストをあたってみるのがいいでしょう。
make world は使わないこと
古いドキュメントの中には、
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
ここでは、
/usr/obj にある
新しい コンパイラが用いられます。
これにより、コンパイラとカーネルのミスマッチを防ぐことができます。
make installkernel
新しくアップデートされたカーネルで起動できるように、
新しいカーネルとカーネルモジュールをディスク上に配置します。
シングルユーザモードで再起動
シングルユーザモードは、
すでに実行されているソフトウェアをアップデートする際の問題を最小限にします。
また、新しいカーネル上で古い world が実行される際の問題も最小限にします。
mergemaster
新しい world における最初の設定ファイルのアップデートを行います。
たとえば、新しいユーザグループをシステムに追加したり、
パスワードデータベースに対し、新しいユーザ名を追加するかもしれません。
前回のアップデート後に、
新しいグループや特別のシステムのユーザアカウントが追加された場合に、
installworld のステップで、
新しくインストールされたシステムのユーザまたはシステムのグループ名を問題なく使うことができるように、
この作業がときどき必要となります。
make installworld
world を /usr/obj からコピーします。
これで、ディスクには新しいカーネルと world が置かれたことになります。
mergemaster
ディスクに新しい world が置かれたので、
残りの設定ファイルをアップデートします。
make
delete-old
このターゲットは (使われなくなった) ファイルを削除します。
もし使われなくなったファイルがディスクに残っていると、
問題が起きる可能性があるため重要な作業です。
たとえば、古い utmp.h が残っていると、
新しい utmpx.h をインストールしたときに、
問題が起きる ports があります。
再起動
新しいカーネル、world そして設定ファイルがロードされたので、
再起動が必要です。
make delete-old-libs
使われなくなったライブラリが新しいライブラリと競合することを避けるため削除します。
古いライブラリを削除する前にすべての ports を再構築する必要があります。
もし、&os; のあるブランチのあるリリースから、
同じブランチの最新リリースにアップデートするのであれば
(たとえば 9.0 から 9.1)、
この手順にしたがわなくても良いでしょう。
なぜならば、コンパイラ、カーネル、ユーザランド、そして設定ファイルの間で、
重度のミスマッチが起きることはあまり考えられないためです。
マイナーなアップデートでは、新しいカーネルの構築とインストール後に、
古いアプローチである
make world
を用いてもうまくいくでしょう。
メジャーリリースをまたいだアップデートでは、
この方法を用いないと、何らかの問題にぶつかるでしょう。
大きなアップグレードにおいては、
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; make delete-old
&prompt.root; reboot
&prompt.root; make delete-old-libs
この後の説明を読んでください
この後の節ではそれぞれのステップについて詳しく説明しています。
特にカスタムカーネルを利用する場合について説明しています。
/usr/src/UPDATING を読む
アップデートする前に、
/usr/src/UPDATING を読んでください。
このファイルには潜在的な問題や
特定のコマンドの順などの重要な情報が含まれています。
UPDATING がこの節に書かれているものと矛盾している時は
UPDATING を優先してください。
UPDATING を読むということは、
適切なメーリングリストを購読する代わりにはなりません。
二つの要求は相補的なもので排他的なものではないのです。
/etc/make.conf の確認
make.conf
&man.make.1; のオプションの説明は、&man.make.conf.5; や
/usr/share/examples/etc/make.conf にあります。
これらの設定を /etc/make.conf に追加して、
&man.make.1; の実行やプログラムの構築方法を設定してください。
ある設定を変更したことにより、影響が広い範囲におよび、
驚くべき結果をもたらす可能性があります。
両方のファイルに書かれているコメントを読むことと、
デフォルトの設定は、パフォーマンスと安全性の観点から選ばれていることを覚えておいてください。
/etc/make.conf で設定されたオプションは、
&man.make.1; が使われる際には常に有効となります。
Ports Collection からアプリケーションをコンパイルする時、
ユーザが書いた C プログラムや &os;
オペレーティングシステムを構築する際に影響を及ぼします。
/etc/src.conf を確認する
src.conf
/etc/src.conf は、
ソースコードを用いたオペレーティングシステムの構築についてコントロールします。
/etc/make.conf とは異なり、
/etc/src.conf に書かれた設定は、
&os; オペレーティングシステムそのものを構築するときにのみ影響します。
このファイルで設定可能な多くのオプションについては、
&man.src.conf.5; に記述されています。
一見したところ無効にされている、
使われていないカーネルモジュールやビルドオプションに注意してください。
ときどき予期しなかったり、わずかな影響を与えることがあります。
/etc にあるファイルの更新
/etc には、
システム起動時に実行されるスクリプトだけでなく、
システムの設定に関連する情報の大部分が含まれています。
そのディレクトリに含まれるスクリプトは、
&os; のバージョンによって多少異なります。
設定ファイルのなかには、/etc/group
のように稼働中のシステムが日々利用しているものもあります。
make installworld によるインストールの段階では、
特定のユーザ名、あるいはグループが存在していることを
要求する場面があります。システムのアップグレードを行なう際には、
それらのユーザ名やグループが削除、
あるいは変更されて存在していない可能性が考えられます。
make buildworld において、
それらのユーザ名やグループが存在するか確認が行われる場合もあります。
解決方法は、buildworld の前に
をつけて &man.mergemaster.8; を実行することです。
これを実行すると、buildworld や
installworld
が成功するために必要なファイルだけを比較します。
名前を変更したり、削除してしまったグループが所有しているファイルを、
次のようにして調べることもできます。
&prompt.root; find / -group GID -print
このコマンドはグループ名もしくは数字で示されるグループ ID
で指定されたグループ GID
が所有するすべてのファイルを表示します。
シングルユーザモードへの移行
シングルユーザモード
コンパイルは、シングルユーザモードで行なうことを考えてください。
システムの再インストールは重要なシステムファイル、
すべての標準システムのバイナリ、ライブラリ、インクルードファイルを操作します。
稼働中のシステムに (特に他のユーザがそのシステムにログインしている時に)
そのような変更を加えることは、トラブルを引き起こす原因となります。
マルチユーザモード
もう一つの方法として、マルチユーザモードでシステムを再構築して、
シングルユーザモードに移行してからそれをインストールする、
というのがあります。もしこのような方法で行ないたい場合は、
以下の手順を構築が完了するところまで飛ばしてください。
installkernel もしくは
installworld を実行する際に、
シングルユーザモードに移行してください。
&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
こうすれば、
確実に地域時刻が正しく設定されます。
/usr/obj の削除
システムが再構築される時、構築されたものはデフォルトで
/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
make
world を再構築するには、&man.make.1; を使用してください。
このコマンドは、Makefile から、
&os; を構成するプログラムの再構築方法や、
どういう順番でそれらを構築すべきかといったような指示を読み込みます。
コマンドラインの一般的な書式は、次のとおりです。
&prompt.root; make -x -DVARIABLE target
この例では、 が
&man.make.1; に渡されるオプションになります。
どのようなオプションが利用できるかについては、&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 の段階で構築されていない
プロファイル版ライブラリをインストールしようとしてしまうでしょう。
make installworld で更新されないファイルの更新
システムの再構築は、いくつかのディレクトリ、
特に、/etc や
/var や
/usr において、
新規に導入されたり、変更された設定ファイルによる
ファイルの更新は行なわれません。
これらのディレクトリのファイルを更新するもっとも簡単な方法は、
&man.mergemaster.8; を使うことです。
必ず /etc
のバックアップを取って不測の事態に備えてください。
Tom
Rhodes
寄稿:
mergemaster
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; を (勧められた通り)
使っているのであれば、次の節
まで飛ばしてもかまいません。
手動で行う際の一番簡単な方法は、
ファイルを新しいディレクトリにインストールしてから、
以前のものと異なっている部分を調べて更新作業を行なうことです。
既存の /etc をバックアップする
たとえば以下のようにして、
既存の /etc
をどこか安全な場所にコピーしておきましょう。
&prompt.root; cp -Rp /etc /etc.old
ここで、 は再帰的なコピーを行ない、
はファイルの更新時間や所有者などを保存します。
新しい /etc
やその他のファイルをインストールするための、
仮のディレクトリを作ってください。
&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
以下にインストールされているファイルの中には、
.
から始まっているものがあります。
ls -a を使って確かめてください。
もっとも簡単な方法は、二つのファイルを比較するコマンド
&man.diff.1; を使うことです。
&prompt.root; diff /etc/shells /var/tmp/root/etc/shells
このコマンドは、/etc/shells ファイルと
新しい /var/tmp/root/etc/shells
ファイルの異なる部分を表示します。
内容を確認して、書き換えたものに変更点をマージするか、
それとも既存のファイルを新しいもので上書きするかを判断してください。
新しい root ディレクトリ
(/var/tmp/root) の名前に
タイムスタンプを付けておくと、
異なるバージョン間の比較を楽に行なうことができます。
頻繁にシステムの再構築を行なうということは、
/etc の更新もまた、
頻繁に行う必要があるということです。
これはちょっと手間のかかる作業です。
この作業は、あなたが /etc
にマージした、
新しく変更されたファイルの最新のセットのコピーを保存しておくことで
素早く行なうことができます。
普通に make world します。
/etc や
他のディレクトリを更新したくなったときは、ターゲット
ディレクトリに、そのときの日付に基づく名前をつけてください。
&prompt.root; mkdir /var/tmp/root-20130214
&prompt.root; cd /usr/src/etc
&prompt.root; make DESTDIR=/var/tmp/root-20130214 \
distrib-dirs distribution
上に説明されているように、
このディレクトリから変更点をマージします。
その作業が終了しても、
/var/tmp/root-20130214
を削除してはいけません。
最新版のソースをダウンロードして再構築したら、
ステップ 1 にしたがってください。今度は、
新しい日付を反映したディレクトリを作成してください。
この例では、/var/tmp/root-20130221
という新しいディレクトリをつくります。
&man.diff.1; を使用し、
二つのディレクトリを比較する再帰的 diff を作成することで、
一週間の間に行なわれたソースへの変更による相違点を調べます。
&prompt.root; cd /var/tmp
&prompt.root; diff -r root-20130214 root-20130221
これによって報告される相違点は、大抵の場合、/var/tmp/root-20130221/etc
と
/etc
との相違点に比べて非常に少ないものになります。
相違点が少ないため、変更点を既存の
/etc
にマージすることは、比較的容易になります。
ここまで終了したら、
/var/tmp/root-*
の二つのうち、古い方のディレクトリは削除して構いません。
&prompt.root; rm -rf /var/tmp/root-20130214
この工程を、
/etc
へ変更点をマージする必要があるたび、繰り返してください。
ディレクトリ名の生成を自動化するには、&man.date.1;
を利用してください。
&prompt.root; mkdir /var/tmp/root-`date "+%Y%m%d"`
Anton
Shterenlikht
ベースとなったノートの提供:
使われなくなったファイル、ディレクトリの削除
Deleting obsolete files and directories
&os; の開発サイクルにおいて、
ファイルやシステムの一部が使われなくなることがあります。
それらの機能が別の場所で実装されたり、
ライブラリのバージョン番号が変わったり、
システムから完全に削除されることがあるためです。
システムのアップデート時に削除が必要になるのは、
古いファイル、ライブラリそしてディレクトリです。
これらのファイルを削除することで、
記憶媒体やバックアップ媒体において不必要な容量を占めている古いファイルが、
システム上に散乱することがなくなります。
また、古いライブラリのセキュリティや安定性に問題があると、
ライブラリを新しくしてシステムを安定な状態にし、
古いライブラリによりシステムがクラッシュすることを防がなければなりません。
使われなくなったファイル、ディレクトリ、ライブラリは
/usr/src/ObsoleteFiles.inc
にまとめられています。以下の手順により、
アップグレードの過程でこれらのファイルを削除できます。
make
installworld
と、その後の mergemaster が無事に終わったら、
以下の方法で使われなくなったファイルやライブラリを確認してください。
&prompt.root; cd /usr/src
&prompt.root; make check-old
見つかった古いファイルは、以下のコマンドで削除できます。
&prompt.root; make delete-old
その他のターゲットについては
/usr/src/Makefile をご覧ください。
使われなくなったファイルを削除する際、
ファイルごとに確認が求められます。
確認を省略し、自動的にファイルを削除するには、
以下のように BATCH_DELETE_OLD_FILES
を設定してください。
&prompt.root; make -DBATCH_DELETE_OLD_FILES delete-old
yes
をコマンドへパイプでつなげても省略できます。
&prompt.root; yes|make delete-old
再起動
すべてがあるべき正しい場所に存在することをチェックしたら、
&man.shutdown.8; を実行してシステムを再起動してください。
&prompt.root; shutdown -r now
使われなくなったライブラリの削除
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 が再構築され、
古いライブラリがどこにも使われていないことを確認したら、
以下のコマンドで古いライブラリを削除してください。
&prompt.root; make delete-old-libs
ここまで来れば、&os; システムのアップグレードは成功です。
おめでとうございます。
もしちょっとした問題があった場合でも、
システムの一部を再構築するのは簡単です。
たとえば、アップグレードや /etc
のマージの途中で誤って
/etc/magic を削除してしまい、
その結果 &man.file.1; が動作しなくなってしまったような場合には、
次のコマンドを実行して修復してください。
&prompt.root; cd /usr/src/usr.bin/file
&prompt.root; make all install
質問ですか?
変更が行なわれたら、その度にシステムの再構築が必要になるのでしょうか?
それは変更の性質によるので、なんとも言えません。
たとえば、svn を実行したとき、
次にあげるようなファイルが更新されていたとします。
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 11signal 11
(もしくは他のシグナル番号) のエラーがたくさん出て
コンパイルが失敗します。何が起こっているんでしょうか?
これは通常、ハードウェアに問題があることを示しています。
システムの再構築は、ハードウェアに対する負荷耐久試験を行なうための
有効な手段の一つで、メモリに関係する問題がよく報告されます。
その大部分は、
不可解な異常終了となることで発見されます。
本当にこの問題によるものかどうかは、make
をもう一度実行し、
異なる段階で異常終了が発生するか、ということから確認できます。
このエラーに対応するには、マシンの部品を交換して、
どの部分が悪いのかを調べてみてください。
終了したら /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/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; に送ってください。
設定についてさらに質問されても答えられるよう用意してください!
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
を自分のマシンのビルドディレクトリに設定しなければなりません。
最後に、packages をビルドして配布するのであれば、
DISTDIR と同じように
PACKAGES ディレクトリも設定してください。