| title | part | prev | next | description | tags | showBookMenu | weight | path | aliases | |||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
第16章 FreeBSD のアップデートとアップグレード |
パートIII. システム管理 |
books/handbook/l10n |
books/handbook/partiv |
freebsd-update もしくは Git を使った FreeBSD システムを最新の状態に更新する方法、ベースシステム全体を再構築しインストールする方法などの説明 |
|
true |
20 |
/books/handbook/cutting-edge/ |
|
あるリリースから次のリリースまでの期間にも、 FreeBSD の開発は休みなく続けられています。 最新の開発ツリーと同期することを好む人がいる一方で、公式のリリース版を好んで使う方もいます。 しかしながら、公式のリリースといえども、 セキュリティや他の重要な修正のため、時にはアップデートが必要となります。 FreeBSD は手元のシステムを最新の開発ツリーと同期するために必要なツールをすべて用意しているので、使用しているバージョンに関わらず、これらのツールを使って簡単にシステムのバージョンをアップグレードできます。 この章では、開発ブランチを追いかける方法、および、FreeBSD システムをアップデートする基本的なツールについて解説します。
この章では以下について説明します。
-
freebsd-update もしくは Git を使った FreeBSD システムの更新方法
-
インストールされているシステムと、変更が行われていない状態との比較方法
-
Git またはドキュメント用の ports を使って、 インストールされているドキュメントを最新版にアップデートする方法
-
2 つの開発ブランチ、FreeBSD-STABLE と FreeBSD-CURRENT の違いについて
-
ベースシステム全体を再構築しインストールする方法
この章を読む前に、以下の準備をしましょう。
-
ネットワーク接続の適切な設定 (crossref:advanced-networking[advanced-networking,高度なネットワーク])
-
サードパーティ製のソフトウェアのインストール方法の習得 (crossref:ports[ports,アプリケーションのインストール - packages と ports])
|
Note
|
この章を通じて、FreeBSD のソースコードのダウンロードやアップデートに |
すみやかにセキュリティパッチを適用し、 オペレーティングシステムをアップグレードして、 最新のリリースに保つことは、システム管理における重要な側面です。
これらの処理を行うために FreeBSD には freebsd-update と呼ばれるユーティリティが用意されています。
このユーティリティを用いると、FreeBSD のセキュリティおよび eratta アップデートをバイナリによって行うことができます。 手動でパッチもしくは新しいカーネルをコンパイルし、インストールする必要はありません。 バイナリアップデートは、セキュリティチームがサポートしているすべてのアーキテクチャとリリースで利用できます。 https://www.FreeBSD.org/ja/security/ には、サポートが行われているリリースや保守終了予定日の一覧があります。
このユーティリティは、マイナーリリースであったり、他のリリースブランチへのアップグレードにも対応しています。 新しいリリースにアップデートする前に、アップデートしようとしているリリースのアナウンスに目を通し、重要な情報がないかどうかを確認してください。 リリースのアナウンスは https://www.FreeBSD.org/ja/releases/ で確認できます。
|
Note
|
もし man:crontab[5] の中に man:freebsd-update[8] の機能が含まれていたら、 オペレーティングシステムのアップグレード作業を終えるまでは無効にしてください。 |
この節では、freebsd-update で使われる設定ファイルの説明、 セキュリティパッチの適応方法のデモンストレーション、 オペレーティングシステムをアップグレードする際に考慮すべき点について説明します。
freebsd-update のデフォルトの設定ファイルは、そのままでも用いることができます。
/etc/freebsd-update.conf の設定をデフォルトからきめ細かく調整して、 アップデートプロセスを制御するユーザもいます。
利用可能なオプションについてはこのファイルのコメントで説明されていますが、以下の項目については補足が必要でしょう。
# Components of the base system which should be kept updated. Components world kernel
このパラメータは、FreeBSD のどの部分を最新に維持するかを設定します。
デフォルトでは、ベースシステム全体、そしてカーネルをアップデートします。
src/base や src/sys のように、個々の項目を指定することもできます。
この部分についてはデフォルトのままにしておき、アップデートする項目をユーザがリストに加える形にするのがベストでしょう。
ソースコードとバイナリが同期していないと、長い年月の間に悲惨な結果がもたらされる可能性があります。
# Paths which start with anything matching an entry in an IgnorePaths # statement will be ignored. IgnorePaths /boot/kernel/linker.hints
/bin や /sbin 等の特定のディレクトリをアップデートで変更しないように、これらのパスを追加してください。
このオプションは、ローカルの変更点を freebsd-update が上書きすることを防ぐ目的にも利用できます。
# Paths which start with anything matching an entry in an UpdateIfUnmodified # statement will only be updated if the contents of the file have not been # modified by the user (unless changes are merged; see below). UpdateIfUnmodified /etc/ /var/ /root/ /.cshrc /.profile
このオプションは、指定したディレクトリにある設定ファイルを、ローカルで変更されていない場合のみアップデートします。
ユーザがこれらのファイルを変更していると、変更されたファイルの自動アップデートは行われません。
他に、KeepModifiedMetadata という別のオプションが存在します。
このオプションは、freebsd-update がマージ中に変更点を保存するようにします。
# When upgrading to a new FreeBSD release, files which match MergeChanges # will have any local changes merged into the version from the new release. MergeChanges /etc/ /var/named/etc/ /boot/device.hints
freebsd-update がマージすべきファイルが存在するディレクトリの一覧です。
ファイルのマージのプロセスは、man:mergemaster[8] と同様 man:diff[1] パッチの連続ですが、選択肢は少なく、マージを承認するか、エディタを起動するか、freebsd-update を中断するかどうかを選んでください。
もし、心配な点があれば、/etc をバックアップしてからマージを承認してください。
mergemaster の詳細な情報については、man:mergemaster[8] で確認してください。
# Directory in which to store downloaded updates and temporary # files used by FreeBSD 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 FreeBSD Update should figure out # which actually are installed and upgrade those (StrictComponents no)? # StrictComponents no
このオプションを yes に設定すると、freebsd-update は Components のリストが完全に正しいと判断し、このリスト以外の変更点については取り扱いません。
freebsd-update は、効率的に Components リストに属するファイルをアップデートします。
詳細については、man:freebsd-update.conf[5] を参照してください。
FreeBSD のセキュリティパッチを適用する過程は簡単になりました。
管理者は freebsd-update を使うことで、 システムを完全にパッチがあたった状態に保つ事ができます。
FreeBSD セキュリティ勧告の詳細については、crossref:security[security-advisories,FreeBSD セキュリティ勧告] の節で説明されています。
以下のコマンドを実行すると、FreeBSD のセキュリティパッチがダウンロードされ、インストールされます。 最初のコマンドは、未対応のパッチがあるかどうかを調べます。 もし未対応のパッチがある場合には、パッチが当てられた際に変更されるファイルのリストが作成されます。 2 番目のコマンドはパッチを適用します。
# freebsd-update fetch
# freebsd-update installアップデートによってカーネルにパッチが適用された場合には、システムを再起動して新しいカーネルで起動する必要があります。 もし、実行中のバイナリにパッチが適用された場合には、パッチが当てられたバイナリが使われるように、影響するアプリケーションを再起動する必要があります。
|
Note
|
通常、ユーザはシステムを再起動する必要があります。
カーネルアップデートによりシステムの再起動が必要かどうかを調べるには、 |
毎日一度アップデートがないかどうかを自動的に確認するように設定するには、 以下のエントリを /etc/crontab に追加してください。
@daily root freebsd-update cron
パッチが存在すると、自動的にダウンロードされますが、適用はされません。
root宛てにメールで、ダウンロードされたパッチを確認し、freebsd-update install とともに手動でインストールする必要のあることが通知されます。
うまく行かなかった場合には、freebsd-update を以下のように実行すると、最後の変更までロールバックできます。
# freebsd-update rollback
Uninstalling updates... done.カーネルまたはカーネルモジュールがアップデートされた場合には、 完了後にもう一度システムを再起動して、 影響のあったバイナリを再起動してください。
freebsd-update ユーティリティが自動的にアップデートするカーネルは GENERIC のみです。
カスタムカーネルをインストールしている場合には、freebsd-update によりインストールした後、カーネルを再構築し、もう一度インストールする必要があります。
デフォルトのカーネルの名前は GENERIC です。
man:uname[1] コマンドを使ってインストールされているかどうかを確認できます。
|
Note
|
GENERIC カーネルを、常に /boot/GENERIC に置いておいてください。 さまざまな問題を解決する際や、バージョンをアップグレードする際に助けとなります。 GENERIC カーネルを用意する方法については、FreeBSD 9.X 以降のシステムにおけるカスタムカーネル を参照してください。 |
/etc/freebsd-update.conf のデフォルトの設定を変更しない限り、freebsd-update は、他の更新と共にカーネルソースをアップデートします。
新しいカスタムカーネルの再構築と再インストールは、通常通り行うことができます。
freebsd-update は、常にカーネルをアップデートするとは限りません。
freebsd-update install によってカーネルソースが変更されなかった場合には、カスタムカーネルを再構築する必要はありません。
しかしながら freebsd-update は、/usr/src/sys/conf/newvers.sh を常にアップデートします。
これは、現在のシステムのパッチレベルを uname -r が -p で表示する時にこのファイルが参照されます。
そのため、何も変更されていない場合でも、カスタムカーネルを再構築することにより、uname がシステムの正確なパッチレベルを報告するようになります。
各システムにインストールされているアップデートをすばやく把握できるようになるので、特に複数のシステムを管理するときに助けとなります。
FreeBSD のマイナーバージョン間のアップグレード、たとえば、FreeBSD 9.0 から FreeBSD 9.1 へのアップグレードは、マイナーバージョン アップグレードと呼ばれます。
メジャーバージョン アップグレードは、FreeBSD 9.X から FreeBSD 10.X へのアップグレードといった、FreeBSD のメジャーバージョンが変わるようなアップグレードのことです。
どちらのアップグレードも、freebsd-update のターゲットにリリース番号を指定する事で実行できます。
|
Note
|
カスタムカーネルを使っているシステムでは、アップグレードを行う前に GENERIC カーネルが、/boot/GENERIC に置かれている事を確認してください。 GENERIC カーネルを用意する方法については、FreeBSD 9.X 以降のシステムにおけるカスタムカーネル を参照してください。 |
以下のコマンドを実行すると、FreeBSD 9.0 のシステムを FreeBSD 9.1 にアップグレードします。
# 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 のような重要なファイルを後で手動でマージする方もいます。
|
Note
|
すべてのパッチは別のディレクトリでマージされており、まだ、システムには反映されていません。 すべてのパッチが正しく適用され、すべての設定ファイルがマージされてプロセスがスムーズに進んだら、ユーザは以下のコマンドを用いて、変更点をディスクに反映してください。 # freebsd-update install |
パッチは最初にカーネルとカーネルモジュールに対して当てられます。 システムがカスタムカーネルを実行している場合には、man:nextboot[8] を使って次回の再起動時のカーネルを、アップデートされた /boot/GENERIC に設定してください。
# nextboot -k GENERIC|
Warning
|
GENERIC カーネルで再起動する前に、カーネルにシステムが適切に起動するために必要なすべてのドライバが含まれていること、もしアップデートしているコンピュータがリモートでアクセスしているのであれば、ネットワーク接続に必要なすべてのドライバも含まれていることを確認してください。 特に、これまで実行しているカスタムカーネルが、カーネルモジュールとして提供されているビルドインの機能を含んでいるのであれば、これらのモジュールを一時的に /boot/loader.conf の機能を用いて、GENERIC に読み込んでください。 アップグレードプロセスが終わるまでは、重要ではないサービスを無効にするとともに、必要のないディスクやネットワークのマウントなども避けることが推奨されています。 |
アップデートされたカーネルでコンピュータを再起動してください。
# shutdown -r nowシステムがオンラインに戻ったら、以下のコマンドを使って freebsd-update を再び実行してください。
アップデートプロセスの状態は保存されているので、freebsd-update を実行すると、古い共有ライブラリおよびオブジェクトファイルを削除するステップに進みます。
# freebsd-update install|
Note
|
使用しているライブラリのバージョン番号の付けられ方によって、 3 つのインストールフェーズが 2 つになる場合もあります。 |
アップグレードはこれで終了です。 もしメジャーアップグレードを行った場合には、メジャーバージョンアップグレード後の package のアップグレード で説明されているようにすべての ports および package を再構築してください。
freebsd-update を使う前に、GENERIC カーネルが /boot/GENERIC に置かれていることを確認してください。
ただ一度だけカスタムカーネルを構築したのであれば、/boot/kernel.old は GENERIC カーネルそのものです。
このディレクトリの名前を /boot/GENERIC へと変更してください。
もし、2 回以上カスタムカーネルを構築した後であったり、カスタムカーネルを構築した回数がわからなければ、現在のオペレーティングシステムのバージョンの GENERIC カーネルを入手してください。 コンピュータへの物理的なアクセスが可能であれば、インストールメディアから GENERIC カーネルをインストールできます。
# mount /cdrom
# cd /cdrom/usr/freebsd-dist
# tar -C/ -xvf kernel.txz boot/kernel/kernel別な方法としては、 GENERIC カーネルをソースから再構築して、 インストールしてください。
# cd /usr/src
# make kernel __MAKE_CONF=/dev/null SRCCONF=/dev/nullfreebsd-update がこのカーネルを GENERIC カーネルとして認識するために、GENERIC コンフィグレーションファイルは、とにかく変更してはいけません。
また、特別なオプションを指定しないで構築してください。
freebsd-update は、/boot/GENERIC が存在する事だけを必要とするので、GENERIC カーネルで再起動する必要はありません。
一般的に、マイナーバージョンアップグレードの後では、インストールされているアプリケーションは、問題なく動作するでしょう。
メジャーバージョンが異なるとアプリケーションバイナリーインタフェース (ABI) が異なるため、サードパーティ製のアプリケーションの多くは動作しなくなるでしょう。
メジャーバージョンアップグレード後には、インストールされているすべての packages, ports をアップグレードする必要があります。
package は、pkg upgrade を使ってアップグレードできます。
インストールされている ports をアップグレードする場合には、package:ports-mgmt/portmaster[] といったユーティリティを使ってください。
すべての package の強制的なアップグレードでは、バージョン番号が上がらない package に対しても、リポジトリから最新のバージョンで、インストールされている package を置き換えます。 FreeBSD のメージャーバージョンが変わるようなアップグレードでは、ABI のバージョンも変わるため、このようなアップグレードが必要になります。 強制的なアップグレードを行うには、以下のように実行してください。
# pkg-static upgrade -fインストールされているすべてのアプリケーションを再構築するには、以下のコマンドを実行してください。
# portmaster -afこのコマンドを実行すると、設定を変更するオプションを持つアプリケーションは、設定変更のスクリーンを表示し、ユーザからの指示待ちの状態で停止します。
この振る舞いをやめ、デフォルトのオプションを使用するには、上記のコマンドに -G を含めてください。
ソフトウェアのアップグレードが終わったら、最後にもう一度 freebsd-update を実行して、すべてのアップグレードプロセスのやり残し作業を行い、アップグレードのプロセスを完了してください。
# freebsd-update installGENERIC カーネルを一時的に読み込んでいたのであれば、crossref:kernelconfig[kernelconfig,FreeBSD カーネルのコンフィグレーション] に書かれている手順に従って、新しいカスタムを構築し、インストールしてください。
コンピュータを再起動し、新しい FreeBSD を立ち上げてください。 これでアップグレードのプロセスは完了です。
freebsd-update を用いて、インストールされている FreeBSD の状態と、正しく動作することが分かっている状態とを比較できます。
このコマンドは、現在のシステムのユーティリティ、ライブラリ、設定ファイルを評価するので、組み込みの侵入検知システム (IDS) として使うことができます。
|
Warning
|
このコマンドは、package:security/snort[] のような本当の IDS の置き換えになるものではありません。
|
比較を行うには、 結果の出力先のファイル名を指定してください。
# freebsd-update IDS >> outfile.idsシステムは検査され、リリースファイルの SHA256 ハッシュ値と現在インストールされているファイルのハッシュ値がファイルの一覧と共に、指定した出力先のファイルに送られます。
これらの行は極めて長いのですが、出力形式は簡単にすぐに解析できます。 たとえば、これらのリリースで異なっているすべてのファイルを知りたいのであれば、以下のコマンドを実行してください。
# 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 オプションに追加してください。
ブートコードおよびブートローダのアップデートプロセスについては、 man:gpart[8], man:gptboot[8], man:gptzfsboot[8] および man:loader.efi[8] のマニュアルを参照してください。
ドキュメントは、FreeBSD オペレーティングシステムの必須要素です。 FreeBSD ドキュメントの最新バージョンは、FreeBSD ウェブサイト (Documentation Portal) から入手できますが、 FreeBSD ウェブサイト、ハンドブック、FAQ および文書の最新版をローカルに用意しておくと便利です。
この章では、ソースまたは Ports Collection を使って、ローカルの FreeBSD ドキュメントを最新に保つ方法を説明します。
ドキュメントを編集したり、ドキュメントの誤りを報告する方法については、新しい貢献者のための FreeBSD ドキュメンテーションプロジェクト入門 (extref:{fdp-primer}[FreeBSD Documentation Project Primer]) をご覧ください。
ソースから FreeBSD ドキュメントを構築するのに必要なツールは、FreeBSD のベースシステムには含まれていません。 必要なツールは、新しい貢献者のための FreeBSD ドキュメンテーションプロジェクト入門で extref:{fdp-primer}[説明されているステップ, overview-quick-start] に従ってインストールしてください。
インストールしたら、git を使って、ドキュメントのソースをダウンロードしてください。
# git clone https://git.FreeBSD.org/doc.git /usr/doc最初にドキュメントのソースをダウンロードするには少し時間がかかります。 ダウンロードが終わるまでお待ちください。
ダウンロードしたドキュメントのソースをアップデートするには、 以下のコマンドを実行してください。
# git pull最新のドキュメントのソースのスナップショットを /usr/doc に用意できたら、インストールされているドキュメントをアップデートする準備はすべて整いました。
ドキュメントをアップデートするには、以下のように入力してください。
# cd /usr/doc
# makeFreeBSD には二つの開発ブランチがあります。 それは FreeBSD-CURRENT と FreeBSD-STABLE です。
この節ではそれぞれのブランチと対象としている読者についての説明と、 どのようにしてシステムの対応するブランチを最新の状態に保つかについて説明します。
FreeBSD-CURRENT とは FreeBSD の開発の "最前線" なので、FreeBSD-CURRENT のユーザは高い技術力を持つことが要求されます。 そこまでの技術力を持っていないが、開発ブランチを追いかけたいと考えているユーザは、かわりに FreeBSD-STABLE を追いかけると良いでしょう。
FreeBSD-CURRENT は FreeBSD の最新のソースコードであり、中には現在開発途上のソフトウェア、実験的な変更、あるいは過渡的な機能などが含まれています。 また、この中に入っている機能がすべて、次の公式リリースに入るとは限りません。 FreeBSD-CURRENT をソースからほぼ毎日コンパイルしている人はたくさんいますが、短い期間ではコンパイルさえできない状態になっている時期もあります。 これらの問題は可能な限り迅速に解決されますが、FreeBSD-CURRENT が不幸をもたらすか、それとも新しい機能をもたらすかは、まさにソースコードを同期した瞬間によるのです!
FreeBSD-CURRENT は、次の 3 つの重要なグループを対象としています。
-
ソースツリーのある部分に関して活発に作業している FreeBSD コミュニティのメンバ。
-
活発にテストしている FreeBSD コミュニティのメンバ。 彼らは、種々の問題を解決するのに時間を惜しまない人々であり、 さまざまな変更に関する提案や FreeBSD の大まかな方向付けを行ないたいと思っている人々でもあり、 パッチも提出します。
-
さまざまな事に目を向け、 参考のために最新のソースを使いたいと思っていたり、 時々コメントやコードを寄稿したいと考えているユーザ。
FreeBSD-CURRENT は、次のリリースの前に、最も早く新しい機能を入手する手段として、期待してはいけません。 リリース前の機能は十分にテストされていないため、バグを含んでいる可能性が大いにあるためです。 また、バグを修正するための素早い方法でもありません。 いかなるコミットは、元からあるバグを修正するのと同じく、新しいバグを生み出すおそれがあります。 FreeBSD-CURRENT には "公式のサポート" はありません。
FreeBSD-CURRENT を追いかけるには
-
{freebsd-current} と {dev-commits-src-main} メーリングリストに加わってください。 さまざまな人がシステムの現在の状態について述べているコメントを見たり、FreeBSD-CURRENT の現在の状態に関する重要な情報を見逃さないために、 必須の ことです。
{dev-commits-src-main} メーリングリストでは、それぞれの変更についての commit ログが記録されています。 また、それに関して起こり得る副作用の情報を得ることができますので、参加する価値のあるメーリングリストです。
これらのメーリングリストに入るには、 {mailing-lists} をたどって参加したいメーリングリストをクリックし、手順の説明にしたがってください。 FreeBSD-CURRENT だけでなく、ソースツリー全体の変更点を追いかけるのであれば、 {dev-commits-src-all} メーリングリストを購読してください。
-
FreeBSD-CURRENT のソースを同期してください。 通常は
gitを使って FreeBSD Git リポジトリのmainブランチから -CURRENT コードをチェックアウトしてください (crossref:mirrors[git,「Git を使う」] を参照してください)。 -
リポジトリのサイズが大きいため、興味のある部分や、パッチを当てる部分のソースのみを同期するユーザもいます。 しかしながら、ソースからオペレーティングシステムをコンパイルしようと思っているユーザは、一部分だけではなく、FreeBSD-CURRENT の すべて をダウンロードする必要があります。
FreeBSD-CURRENT をコンパイルする前に /usr/src/Makefile を注意深く読み、ソースを用いた FreeBSD のアップデート に書かれている手順に従ってください。 {freebsd-current} と /usr/src/UPDATING を読めば、次のリリースへ向けて移ってゆくに当たって、ときどき必要となる既存システムからの新システムの構築手順についての最新情報が得られるでしょう。
-
アクティブになってください! FreeBSD-CURRENT のユーザには、 拡張やバグ潰しに関して提案することが勧められています。 コードを伴う提案はいつでも歓迎されます!
FreeBSD-STABLE とは定期的に公開されるリリースを作成するための開発ブランチです。 このブランチに加えられる変更は FreeBSD-CURRENT よりゆっくりで、原則として、事前に FreeBSD-CURRENT で試験ずみであるという特徴があります。 ただそうであっても、これは開発用ブランチの一つであり、ある時点における FreeBSD-STABLE のソースがどんな場合にも使えるものであるとは限りません。 このブランチはもう一つの開発の流れというだけであって、エンドユーザ向けのものではありません。 もし試験をする資源的な余裕がない場合は、代わりに最新の FreeBSD リリースを使ってください。
FreeBSD の開発プロセスに興味があったり、それに対する貢献を考えていて、特にそれが次回の FreeBSD のリリースに関係するものであるなら FreeBSD-STABLE を追うことを考えると良いでしょう。
FreeBSD-STABLE ブランチはいつもコンパイルができ、安定に動作すべきですが、それが保証されているというわけではありません。 FreeBSD-STABLE のユーザは FreeBSD-CURRENT よりも多いため、FreeBSD-CURRENT で発見されなかったバグが FreeBSD-STABLE で発見され、ときどきそれが問題となることがあるのは避けることができません。 このような理由から、盲目的に FreeBSD-STABLE を追いかけるべきではありません。 特に、開発環境もしくはテスト環境でコードを十分に試験せずに、プロダクション品質が要求されるサーバを FreeBSD-STABLE にアップグレードしてはいけません。
FreeBSD-STABLE を追いかけるには
-
FreeBSD-STABLE の構築に関連する事柄や、その他の注意すべき点 に関する情報を得るために、 {freebsd-stable} メーリングリストに加わってください。 また開発者は議論の余地がある修正や変更を考えている場合に、このメーリングリストで公表し、提案された変更に関して問題が生じるかどうかを返答する機会をユーザに与えます。
追いかけているブランチに関連する git メーリングリストに参加してください。 たとえば、{betarel-current-major}-STABLE ブランチを追いかけているユーザは {dev-commits-src-branches} メーリングリストに参加してください。 このリストでは、変更がなされるごとに作成される commit log やそれに伴う起こりうる副作用についての情報が記録されています。
これらのメーリングリストに入るには、 {mailing-lists} をたどって参加したいメーリングリストをクリックし、手順の説明にしたがってください。 ソースツリー全体の変更点を追いかけるには、 {dev-commits-src-all} メーリングリストを購読してください。
-
新しい FreeBSD-STABLE システムをインストールするには、 crossref:mirrors[mirrors,ミラーサイト] から最近の FreeBSD-STABLE リリースをインストールするか、毎月公開されている FreeBSD-STABLE からビルドされたスナップショットを使ってください。 スナップショットの詳細については、www.freebsd.org/ja/snapshots をご覧ください。
既に FreeBSD が動いているシステムを FreeBSD-STABLE にアップグレードするには、
gitを使って、希望する開発ブランチのソースをチェックアウしてください。stable/9といったブランチ名は、www.freebsd.org/releng で説明されています。 -
FreeBSD-STABLE をコンパイルしたり FreeBSD-STABLE へとアップグレードする前に、 /usr/src/Makefile を注意深く読み、 ソースを用いた FreeBSD のアップデート に書かれている手順に従ってください。 {freebsd-stable} と /usr/src/UPDATING を読んで、次のリリースへ向けて移ってゆくに当たって、ときどき必要となる既存システムからの新システムの構築手順についての最新情報を得てください。
バグを追跡する際は、問題が発生したシステムの構築に用いられたソースコードのバージョンを把握することが重要となります。 FreeBSD は、バージョン情報をカーネルのコンパイル時に埋め込みます。 man:uname[1] を使ってこの情報を調べることができます。以下はその例です。
% uname -v
FreeBSD 14.0-CURRENT #112 main-n247514-031260d64c18: Tue Jun 22 20:43:19 MDT 2021 fred@machine:/usr/home/fred/obj/usr/home/fred/git/head/amd64.amd64/sys/FRED最後のフィールドから、カーネル名、ビルドを行ったユーザ、およびコンパイルを行った場所がわかります。 また、4 番目のフィールドは、いくつかの要素から構成されていることがわかります。
main-n247514-031260d64c18
main (1)
n247514 (2)
031260d64c18 (3)
(4)-
Git ブランチ名。 注意: n-番号の比較は、FreeBSD プロジェクトで作成されたブランチ (
main,stable/XXおよびreleng/XX) でのみ有効です。 ローカルブランチでは、親ブランチのコミットと n-番号が重複してしまいます。 -
n-番号は、ハッシュ値が含まれるようになった git リポジトリの使用開始からのコミットを数えたものです。
-
チェックアウトしたツリーのハッシュ値。
-
-dirtyが表示されることがあります。 変更点がコミットされていないツリーでカーネルが構築された場合に表示されます。 この例では、チェックアウトから変更なく FRED カーネルが構築されたため、出力されていません。
git rev-list コマンドを使って、ハッシュ値に対応する n-番号を調べることができます。
以下はその例です。
% git rev-list --first-parent --count 031260d64c18 (1)
247514 (2)-
変換する git ハッシュ値 (ここでは先の例のハッシュ値を使用しています)
-
n-番号
この数字は通常それほど重要ではありません。
しかしながら、バグの修正がコミットされた時には、この数字を使うことで、使用しているシステムでバグが修正されているかどうかを簡単に調べることができます。
ハッシュ値は簡単に目にする識別子である一方で n-番号はそうではありません。
そのため、開発者は通常 n-番号ではなくコミットのハッシュ値
(または、ハッシュ値を含む URL) を参照します。
セキュリティ勧告および errata 情報では n-番号が示されており、使用しているシステムの番号と直接比較できます。
git rev-list コマンドは、レポジトリのリビジョンをすべてカウントしますが、git の shallow clone はその情報を取得しないため、shallow clone を使用しなければならない場合には、n-番号は信頼できません。
ソースをコンパイルしてFreeBSD をアップデートする方法は、 バイナリを用いたアップデートに比べ、いくつもの利点があります。 特定のハードウェアをうまく利用するためのオプションを設定してコードを構築できます。 ベースシステムの特定の箇所の設定をデフォルトの設定から変更したり、必要がない部分を完全に削除して構築することもできます。 システムを構築することによるアップデートは、バイナリアップデートをインストールするだけのアップデートに比べ時間がかかりますが、利用環境に合わせた FreeBSD を作成するような完全なカスタマイズが可能です。
以下は FreeBSD をソースから構築してアップデートする典型的な方法についてのクイックリファレンスです。 その後の節では、各プロセスをより詳細に説明します。
|
Warning
|
man:mergemaster[8] から man:etcupdate[8] に移行する際に、初めて man:etcupdate[8] を実行すると、変更点が不適切にマージされ、衝突が起きてしまうことがあります。 これを避けるには、ソースを更新して新しく buildworld を行う 前に 以下のステップを行ってください。 # etcupdate extract (1)
# etcupdate diff (2)
|
-
アップデートおよびビルド
# git pull /usr/src (1) /usr/src/UPDATING の確認 (2) # cd /usr/src (3) # make -j4 buildworld (4) # make -j4 kernel (5) # shutdown -r now (6) # etcupdate -p (7) # cd /usr/src (8) # make installworld (9) # etcupdate -B (10) # shutdown -r now (11)
-
最新版のソースを入手してください。 ソースの入手およびアップデートに関する情報については ソースコードのアップデート をご覧ください。
-
ソースの構築の前後で必要となる手動の作業について、 /usr/src/UPDATING を確認してください。
-
ソースが置かれているディレクトリに移動してください。
-
world (カーネルを除くすべて) をコンパイルしてください。
-
カーネルをコンパイルしてインストールしてください。 ここに書かれているコマンドは、
make buildkernel installkernelと同じです。 -
新しいカーネルを使うため、 システムを再起動してください。
-
installworld を行う前に、/etc/ に置かれている設定ファイルのアップデートとマージを行ってください。
-
ソースが置かれているディレクトリに移動してください。
-
world をインストールしてください。
-
/etc/ に置かれている設定ファイルのアップデートとマージを行ってください。
-
新しく構築された world およびカーネルを利用するため、 システムを再起動してください。
FreeBSD のソースコードは /usr/src/ に置かれています。 このソースコードのアップデートには、Git バージョン管理システムを利用する方法が推奨されています。 まず、ソースコードがバージョン管理下にあることを確認してください。
# cd /usr/src
# git remote --v
origin https://git.freebsd.org/src.git (fetch)
origin https://git.freebsd.org/src.git (push)この結果は、/usr/src/ がバージョン管理下にあり、man:git[1] を使ってアップデートできることを示しています。
# git pull /usr/srcこのディレクトリをアップデートしていない期間が長いと、アップデートのプロセスには時間がかかります。 このプロセスが終わると、ソースコードは最新となり、次節以降で説明する構築のプロセスを実行できます。
|
Note
|
ソースコードの入手
man:uname[1] を使って FreeBSD のバージョンを確認してください。 # uname -r
10.3-RELEASEFreeBSD のバージョンおよびリポジトリブランチ から分かるように、 # mv /usr/src /usr/src.bak (1)
# git clone --branch releng/10.3 https://git.FreeBSD.org/src.git /usr/src (2)
|
まず最初に world (カーネルを除くオペレーティングシステムのすべて) をコンパイルします。 このステップを最初に実行するのは、カーネルの構築を最新のツールを使って行うようにするためです。 このステップが終わったら、カーネルそのものを構築します。
# cd /usr/src
# make buildworld
# make buildkernelコンパイルされたコードは /usr/obj に書き出されます。
これは基本のステップです。 構築をコントロールする追加のオプションについては、 以下で説明します。
FreeBSD ビルドシステムのいくつかのバージョンは、オブジェクトが一時的に置かれるディレクトリ /usr/obj に前回のコンパイルされたコードを残します。
これにより、変更されていないコードを再コンパイルせずにすむので、その後の構築時間を短縮できます。
すべてを再構築するには、構築を開始する前に、cleanworld を実行してください。
# make cleanworldマルチコアプロセッサを搭載するシステムでは、構築のためのジョブの数を増やすことで、構築にかかる時間を短縮できます。
sysctl hw.ncpu を使って、コアの数を確認してください。
ジョブの数がどのように構築の速さに影響するかを確実に知るには、プロセッサにより異なりますし、FreeBSD のバージョンにより使用されるビルドシステムも変わるため、実際に試してみるしか方法はありません。
試してみる最初のジョブの数の候補としては、コアの数の半分から倍の数の間で検討してみてください。
ジョブの数は、-j を使って指定します。
以下は 4 つのジョブで world とカーネルを構築する例です。
# make -j4 buildworld buildkernelソースコードが変更された場合には、buildworld を完了しなければいけません。
その後、いつでも buildkernel でカーネルを構築できます。
カーネルだけを構築するには、以下のように実行してください。
# cd /usr/src
# make buildkernelFreeBSD 標準のカーネルは、GENERIC と呼ばれる カーネルコンフィグレーションファイル に基づいています。 GENERIC カーネルには、最も良く使われるデバイスドライバやオプションが含まれています。 しかしながら、特定の目的に合わせてデバイスドライバやオプションを削除したり追加するためには、カスタムカーネルを構築することが有用であったり、必要となることがあります。
たとえば、極端に RAM が制限されているような小さな組み込みのコンピュータを開発しているユーザであれば、 必要のないデバイスドライバやオプションを削除することで、 カーネルを少しでも小さくできるでしょう。
カーネルのコンフィグレーションファイルは、 /usr/src/sys/arch/conf/ に置かれています。ここで、 arch は uname -m の出力です。 ほとんどのコンピュータは amd64 であり、 コンフィグレーションファイルが置かれているディレクトリは /usr/src/sys/amd64/conf/ です。
|
Tip
|
/usr/src は、削除されたり作り直されたりする可能性があるため、カスタムカーネルのコンフィグレーションファイルは、/root のような別のディレクトリで管理することが好ましいです。 カーネルコンフィグレーションファイルは、conf ディレクトリにリンクします。 このディレクトリが削除されたり、上書きされた場合には、カーネルコンフィグレーションファイルを新しいディレクトリにもう一度リンクしてください。 |
カスタムコンフィグレーションファイルは、GENERIC コンフィグレーションファイルをコピーして作成できます。 たとえば、ストレージサーバ用の STORAGESERVER という名前の新しいカスタムカーネルは、以下のようにして作成できます。
# cp /usr/src/sys/amd64/conf/GENERIC /root/STORAGESERVER
# cd /usr/src/sys/amd64/conf
# ln -s /root/STORAGESERVER .その後 /root/STORAGESERVER を編集し、 man:config[5] で示されるデバイスやオプションを追加したり削除してください。
コマンドラインからカーネルコンフィグレーションファイルを KERNCONF に指定することで、 カスタムカーネルを構築できます。
# make buildkernel KERNCONF=STORAGESERVERbuildworld および buildkernel が完了したら、 新しいカーネルと world をインストールしてください。
# cd /usr/src
# make installkernel
# shutdown -r now
# cd /usr/src
# make installworld
# shutdown -r nowカスタムカーネルを構築した場合は、 新しいカスタムカーネルを KERNCONF に設定して実行してください。
# cd /usr/src
# make installkernel KERNCONF=STORAGESERVER
# shutdown -r now
# cd /usr/src
# make installworld
# shutdown -r nowアップデートの完了までに、いくつかの最終作業が残されています。 デフォルトから変更した設定ファイルを新しいバージョンのファイルにマージし、古くなったライブラリを見つけて削除した後に、システムを再起動します。
man:etcupdate[8] は、/etc/ 以下のファイルのように installworld のプロセスで更新されないファイルをアップデートするツールです。 このツールは、ローカルにあるファイルに対する変更点を 3-way マージでアップデートします。 man:mergemaster[8] の対話的なプロンプトと対照的に、このツールはユーザによる操作を最小限になるように設計されています。
|
Note
|
一般的に、man:etcupdate[8] は、実行する際に特定の引数を必要としません。 しかしながら、man:etcupdate[8] を最初に使用した際に、どのようなアップデートが行われたかの健全性をチェックする便利なコマンドがあります。 # etcupdate diffこのコマンドにより、ユーザは設定の変更を検証できます。 |
man:etcupdate[8] が自動的にファイルをマージできない場合には、 以下を実行することで、手動の操作により衝突を解決できます。
# etcupdate resolve|
Warning
|
man:mergemaster[8] から man:etcupdate[8] に移行する際に、 最初に man:etcupdate[8] を実行すると、不適切に変更点がマージされ、誤った衝突が起こる可能性があります。 これを避けるには、ソースを更新して新しく buildworld を行う 前に 以下のステップを行ってください。 # etcupdate extract (1)
# etcupdate diff (2)
|
man:mergemaster[8] を用いることで、システムの設定ファイルに行われている変更を、これらのファイルの新しいバージョンにマージできます。
man:mergemaster[8] は、設定ファイルのアップデートで推奨されている man:etcupdate[8] の代価のツールです。
-Ui オプションを使って man:mergemaster[8] を実行すると、 ユーザが手を加えていないファイルのアップデートおよび新しく追加されたファイルのインストールを自動的に行います。
# mergemaster -Uiファイルのマージを手動で行う必要がある時は、ファイルの中で残す箇所の選択を対話的におこなうようなインタフェースが表示さます。 詳細については、man:mergemaster[8] をご覧ください。
アップデート後に、使われなくなったファイルやディレクトリが残ることがあります。 これらのファイルは、
# make check-oldで確認でき、以下のようにして削除できます。
# make delete-old同様に使われなくなったライブラリが残ることもあります。 これらのライブラリは、
# make check-old-libsで確認でき、以下のようにして削除できます。
# make delete-old-libsこれらの古いライブラリを利用しているプログラムは、ライブラリが削除されると動かなくなります。 これらのプログラムは、古いライブラリを削除した後に、再構築もしくは置き換える必要があります。
|
Tip
|
古いファイルとディレクトリのすべてを削除しても問題ないことを確認したら、コマンドに # make BATCH_DELETE_OLD_FILES=yes delete-old-libs |
複数のコンピュータで同じソースツリーを追いかけていて、全部のマシンにソースをダウンロードして全部を再構築するのは、ディスクスペース、ネットワーク帯域、そして CPU サイクルの無駄使いです。 解決策は 1 つのマシンに仕事のほとんどをさせ、残りのマシンは NFS 経由でそれをマウントする、というものです。 このセクションではそのやり方を概観します。NFS の使い方の詳細については、crossref:advanced-networking[network-nfs,「NFS」] をご覧下さい。
まず初めに、同じバイナリで動かそうとするマシンたちを決めます。
このマシンたちのことをビルドセットと呼びます。
それぞれのマシンはカスタムカーネルを持っているかもしれませんが、同じユーザランドバイナリを動かそうというのです。
このビルドセットから、 ビルドマシンとなるマシンを 1 台選びます。
ベースシステムとカーネルを構築するのはこのマシンになります。
理想的には、このマシンは make buildworld と make buildkernel を実行するのに十分な CPU を持った速いマシンであるべきです。
テストマシン となるべきマシンも選んでください。 更新されたソフトウェアを使う前にそのマシンでテストするのです。 テストマシンはかなり長い時間落ちていても だいじょうぶなマシンであったほうがいいでしょう。 ビルドマシンでもかまいませんが、ビルドマシンである必要はありません。
このビルドセットのマシンはすべて /usr/obj と /usr/src をビルドマシンから FTP 経由でマウントする必要があります。 ビルドセット自体が複数ある場合は、/usr/src はひとつのビルドマシン上にあるべきです。 他のマシンからはそれを NFS マウントするようにしましょう。
ビルドセットのすべてのマシン上の /etc/make.conf と /etc/src.conf がビルドマシンと一致していることを確認してください。
つまり、ビルドマシンはビルドセットのどのマシンもインストールしようとしているベースシステムを全部ビルドしなければならないということです。
また、各ビルドマシンは /etc/make.conf にそれぞれのビルドマシンのカーネル名を KERNCONF で指定し、ビルドマシンは自分自身のカーネルから順に全部のカーネル名を KERNCONF にリストアップしてください。
ビルドマシンは各マシンのカーネル設定ファイルを /usr/src/sys/arch/conf に持っていなければなりません。
ビルドマシンにて、ソースを用いた FreeBSD のアップデート に書いてあるようにカーネルとベースシステムを構築してください。
でも、まだビルドマシンにはインストールしないでください。
そのかわり、ビルドしたカーネルをテストマシンにインストールしてください。
FTP 経由で /usr/src および /usr/obj をテストマシンにマウントしてください。
その後、shutdown now を実行してシングルユーザモードに移行し、新しいカーネルとベースシステムをインストールし、いつもするように mergemaster を実行してください。
終わったら、再起動して通常のマルチユーザ動作に戻します。
テストマシンにあるものすべてがちゃんと動いている確信が得られたら、同じ手順でビルドセットの他のマシンにも新しいソフトウェアをインストールします。
ports ツリーにも同じ方法が使えます。
最初のステップは、ビルドセットのすべてのマシンが NFS 経由で /usr/ports をマウントすることです。
そして、distfiles を共有するように /etc/make.conf を設定します。
NFS マウントによってマップされる root ユーザが何であれ、DISTDIR はそのユーザが書き込める共通の共有ディレクトリに設定する必要があります。
ports をローカルでビルドする場合には、各マシンは WRKDIRPREFIX を自分のマシンのビルドディレクトリに設定しなければなりません。
また、ビルドシステムが packages をビルドしてビルドセットのコンピュータに配布するのであれば、DISTDIR と同じようにビルドシステム上の PACKAGES ディレクトリも設定してください。