diff --git a/ja_JP.eucJP/books/handbook/backups/chapter.sgml b/ja_JP.eucJP/books/handbook/backups/chapter.sgml index cf54c21787..6e5c0abb23 100644 --- a/ja_JP.eucJP/books/handbook/backups/chapter.sgml +++ b/ja_JP.eucJP/books/handbook/backups/chapter.sgml @@ -1,868 +1,862 @@ バックアップ - ハードウェアコンパチビリティの問題は現在のコンピュータ業界 - でもっとも多く起きる種類の問題であり, - FreeBSD もこれに無縁ではありません. - 市場にある驚くほど多様な種類の製品をサポートすることによって, - FreeBSDは 安価に普及している PC ハードウェアで - 動かすことができるという利点はこの点では不利でもあります. - FreeBSD のサポートするハードウェアを徹底的に調べて - 提供することは不可能ですが, このセクションでは FreeBSD - に含まれるデバイスドライバとそのドライバがサポートする - ハードウェアのカタログを示します. 可能で適切なものについては - 特定の製品についての注釈を含めました. - また, このハンドブックの - コンフィグレーションファイル のセクションにも - サポートされているデバイスのリストがありますので - そちらもご覧ください. - - FreeBSD はボランティアプロジェクトでテスト部門には - 資金がありませんから, より多くの情報をこのカタログに載せるには - あなたがたユーザに頼らなければなりません. - あなた自身の経験により, あるハードウェアが FreeBSD - で動くか動かないかがわかったとしたら &a.doc; へ e-mail - して知らせてください. サポートされているハードウェアについての - 質問は, &a.questions; (詳しいことは - メーリングリストを参照してください) へ宛ててください. - 情報を提供したり質問をする時は FreeBSD のバージョンと使っている - ハードウェアのできるだけ詳しい情報を含めることを - 忘れないでください. + + + 概要 + + この章ではデータのバックアップ方法とバックアップの作成に + 使われるプログラムの説明をします. もしあなたがこの章に何かを + 付け加えたいのなら, それを &a.doc; へ送ってください. + テープメディア 一般的なテープメディアには 4mm, 8mm, QIC, ミニカートリッジ, DLT があります. 4mm (DDS: Digital Data Storage) 4mm テープはワークステーションのバックアップメディアとして QIC から置き換えられつつあります. この傾向は QICドライブの製造のリーダであった Archiveを Connerが買収し QICドライブの製造を中止したことで加速しました. 4mmドライブは小型で静かですが 8mm ドライブの持っているような信頼性の評判はありません. カートリッジは 8mmカートリッジよりも安価で小型 (3 x 2 x 0.5 インチ; 76 x 51 x 12 mm) です. 4mmドライブ は 8mm同様にヘリカルスキャン (訳注: VTRと同様の回転ヘッドを使う方式) を使用しているという理由でヘッドの寿命は短いです. これらのドライブのデータスループットは 150kB/s程度から最大で500kB/s程度の範囲です. データ容量は 1.3GBから 2.0GBです. ハードウェア圧縮が多くのドライブで可能で, およそ 2倍の容量になります. マルチドライブテープライブラリユニットは1つの筐体に 6ドライブを持つことができ自動的にテープを交換します. ライブラリの容量は 240GBに達します. 現在の DDS-3 規格では, 12GB (圧縮時 24GB) までのテープ容量をサポートしています. 4mmドライブは 8mmドライブ同様にヘリカルスキャンを使います. ヘリカルスキャンの利点と欠点は 4mm ドライブ と 8mm ドライブ共通です. テープの寿命は 2000 回のパスあるいは 100 回のフルバックアップです. 8mm (Exabyte) 8mm テープは SCSI テープドライブとして最もよく使われているもので, データ交換用として最良の選択です. ほとんどのサイトには Exabyte の 2GB 8mm テープドライブがあるでしょう (訳注: Unix ワークステーションを何台も置いているようなサイトには 1 台くらいはあるというような意味です). 8mm ドライブは信頼性が高く, 使いやすく, 静かです. カートリッジは安価で小型です (4.8 x3.3 x 0.6 インチ; 122 x 84 x 15 mm). 欠点は, テープとヘッドの相対的な速度が高速なために 比較的ヘッドとテープの寿命が短いことです. データスループットは 250kB/s 程度から 500kB/s 程度の範囲です. データ容量は 300MB から 7GB です. ハードウェア圧縮が多くのドライブで可能で,およそ 2 倍の容量になります. 単一のユニットのドライブから, 1 つの筐体に 6 台のドライブと 120 巻のテープを持ったマルチドライブテープライブラリまで 利用することができます. ライブラリではテープはユニットにより 自動的に交換されます. ライブラリの容量は 840GB 以上に達します. - Exabyte 社製の “Mammoth” というモデルは, + Exabyte 社製の Mammoth というモデルは, テープ一本あたり 12GB (圧縮時 24MB) をサポートしています. このドライブの価格は, 通常のテープドライブの約 2 倍です. データはヘリカルスキャンを使ってテープに記録されます. ヘリカルスキャン方式ではヘッドはメディアに対してある傾き (約6度) に配置されます. テープはヘッドのある円筒の周の 270度にわたって接触します. テープが円筒面を走行する間, 円筒は回転しています. この結果, 高密度のデータのつまったトラックは, 狭い間隔でテープの上端と下端の間を斜めに横切ります. QIC QIC-150 テープとドライブはたぶん最も一般的に使われている ドライブとメディアでしょう. QIC テープドライブは現実的なバックアップドライブとして 少なくとも高価なものではありません. 欠点はメディアのコストです. QIC テープは 8mm や 4mm テープに比較して GB あたりのデータの保存で 5 倍ほど高価です. しかしあなたの必要とする量が半ダース程のテープで十分であれば, QICは正しい選択となるかもしれません. QIC は 最も一般的なテープドライブです. すべてのサイトに QICドライブのどれかの容量のものがあります. 問題は, QIC は同じようなテープ (まったく同じ場合もある) に多様な記録密度があることです. QIC ドライブは静かではありません. これらのドライブはデータ記録を 開始する前に音をたててシークしますし, リード, ライト, シークの時にはっきりと聞こえる音を出します. QIC テープの大きさは (6 x 4 x 0.7 インチ; 152 x 102 x 17 mm). ミニカートリッジ で使われている 1/4 インチ幅のテープについては別に議論します. テープライブラリやチェンジャはありません. データスループットは 150kB/s から 500kB/s の範囲です. データ容量の範囲は 40MB から 15GB です. ハードウェア圧縮が 最近の多くのドライブで使えるようになっています. QIC ドライブは DAT ドライブに置き換えられつつあり, あまり頻繁には利用されなくなっています. データは複数のトラックにわかれてテープに記録されます. トラックはテープメディアの 長さ方向の一端からもう一方の端までです. (訳注: 1トラックの read/write が終わるとテープの走行方向を反転させ次のトラックの read/write を行います) トラックの数と, それに対応するトラックの幅はテープの容量によって変わります. すべてではありませんがほとんどの最近のドライブは 少なくとも読み出しについては (場合によっては書き込みも) 下位互換性があります. QIC はデータの安全性についてはよいといわれています (ヘリカルスキャンドライブに比べて機構は単純でより丈夫です). テープは 5000回のバックアップで寿命となるでしょう. + * ミニカートリッジ +]]> + DLT DLTはここに示したドライブのタイプの中で 最高速のデータ転送レートです. 1/2 インチ (12.5mm) テープが単リールのカートリッジ (4 x 4 x 1 インチ; 100 x 100 x 25 mm) に入っています. カートリッジのひとつの側面全体がスイングゲートになっています. ドライブの機構がこのゲートを開け, テープリーダを引き出します. テープリーダには楕円形の穴があり, ドライブがテープを引っ掛けるのに使います. 巻き取りのためのリールはドライブの中にあります. ここに挙げた他のカートリッジはすべて ( 9 トラックテープはただ1つの例外です) 送りだしリールと巻き取りリールの両方がカートリッジの中に あります. データスループットは約1.5MB/sで, 4mm, 8mm, QIC テープドライブの3倍です. データ容量は単一のドライブで 10GBから 20GBの範囲です. マルチテープチェンジャ,マルチテープドライブ,5から 900巻のテープを1から20ドライブで扱う マルチドライブテープライブラリがあり, 50GB から 9TB の容量が得られます. 圧縮機能により, DLT Type IV フォーマットは 70GB までの容量をサポートします. データは ( QIC テープのように) テープの走行方向と並行に複数あるトラックへ記録されます. 2 つのトラックに同時書き込みを行います. Read/Write ヘッドの寿命は比較的長いと言えます. テープの走行が止まればヘッドと テープの間の相対運動はありません. AIT AIT は, Sony が発表した新しいフォーマットで, テープ一本あたり 50GB(圧縮時) の容量を持っています. テープには, 記録データ内容の索引情報が記録可能な メモリチップが内蔵されています. ドライブがこの索引情報を読みとることで, テープのどの部分にどのファイルが存在するかを 高速に調べることができるようになっています. 従来のドライブは, この処理に数分の時間を必要としていました. 直接テープのメモリチップと通信することでテープ内容を画面表示する SAMS:Alexandria のようなソフトウェアを使うことで, 40 を超える ATI テープライブラリを操作できるのはもちろんのこと, どのテープのどこに, どのファイルがバックアップされているのか調べたり, 正しいテープをセットしたり, テープ上のデータをリストアしたりすることが可能です. このようなテープライブラリにかかる費用は $20,000 台です. 業務用でないものはもう少し安価でしょう. 新品のテープを最初に使う場合 新品の完全な空テープを読もうとしたり書き込もうとすると処理 は失敗するでしょう. 次のようなコンソールメッセージが出るでしょう. sa0(ncr1:4:0): NOT READY asc:4,1 st0(ncr1:4:0): Logical unit is in process of becoming ready テープに識別ブロック (Identifire Block:block number 0) がありません.QIC-525標準の採用されている QICテープドライブのすべてで識別ブロックをテープに書きます. 2つの解決方法があります. (訳注: 方法1)mt fsf 1 によってテープドライブは識別ブロックをテープに書きます. (訳注: 方法2)フロントパネルのボタンを押してテープをとりだします. 再びテープを入れ,データをテープに &man.dump.8; します. &man.dump.8; はそのうちに DUMP: End of tape detected と表示し, コンソールには HARDWARE FAILURE info:280 asc:80,96と表示されるでしょう. mt rewindを使ってテープを巻戻します. この次からはテープの操作は成功するでしょう. バックアッププログラム よく使われる3つのプログラムは &man.dump.8;, &man.tar.1;, &man.cpio.1; です. ダンプとリストア &man.dump.8; と &man.restore.8; は伝統的な Unixのバックアッププログラムです. これらはドライブのファイルシステム上のファイル, リンク, ディレクトリをディスクブロックの集まりとして処理します. &man.dump.8; はデバイスやファイルシステム全体をバックアップし, 一部分のバックアップや, &man.ln.1; によるソフトリンクや 他のファイルシステムをマウントを行った, 1 つ以上のファイルシステムにまたがる ディレクトリツリーのバックアップはできません. &man.dump.8; はファイルやディレクトリを構成する データブロックをテープに書くだけで, ファイルやディレクトリをテープに書くことはありません. &man.dump.8; には初期の ATT UNIX のバージョン 6 (1975 年ごろ) に由来する癖が残っています. デフォルトのパラメタは 9 トラックテープ (6250 bpi) に適したものになっていて現在の高密度メディア (最大 62,182 ftpi) に適していません. 現在のテープドライブの容量を有効に利用するため, デフォルト値をコマンドラインで置き換えなければなりません. &man.rdump.8; と &man.rrestore.8; は他のコンピュータに接続されているテープドライブに ネットワーク経由でバックアップをします. どちらのプログラムもリモートテープドライブにアクセスするために &man.rcmd.3; と &man.ruserok.3; に依存しています. このためユーザがバックアップを実行するためには rhosts によるリモートアクセスが必要です. &man.rdump.8; と &man.rrestore.8; の引数はリモートコンピュータに適切なものを用います. &man.rrestore.8; はリモートコンピュータから使うのに適しています. (例えば FreeBSD コンピュータより komodo という名前の Sun に接続されている Exabyte テープドライブへ /sbin/rdump 0dsbfu 54000 13000 126 komodo:/dev/nrsa8 /dev/rda0a 2>&1 として rdumpしたような場合の restoreに使います) 警告: セキュリティは rhostsの管理にかかっています. あなたの状況を注意深く調べてください. Tar &man.tar.1; ATT Unix のバージョン 6 (1975ごろ) にさかのぼる事ができます. &man.tar.1; はファイルシステムと協調して機能し, ファイルやディレクトリをテープに書きます. &man.tar.1; は &man.cpio.1; で使えるようなフルレンジのオプションは持ちませんが &man.cpio.1; で使うような奇妙なコマンドパイプラインは必要ありません. 大部分の &man.tar.1; にはネットワーク経由のバックアップの機能はありませんが, FreeBSD で使用されている GNU の &man.tar.1; は, rdump とおなじ構文でリモートデバイスを扱うことができます. komodo というホスト名の Sun に繋いである Exabyte のテープデバイスに対して &man.tar.1; を実行するには, 次のようにします. /usr/bin/tar cf komodo:/dev/nrsa8 . 2>&1 リモートデバイスをサポートしていない tar を使用している場合は, パイプラインと &man.rsh.1; を使うことで, リモートテープデバイスにデータを送る事ができます. - (コマンド使用例はまだです) + + + &prompt.root; tar cf - . | rsh hostname dd of=tape-device obs=20b + + もしあなたがネットワークを越えるバックアップのセキュリティに + 困っているなら &man.rsh.1; の代わりに &man.ssh.1; を使うべきです. Cpio &man.cpio.1; は本来, Unix ファイルを磁気メディアで交換するためのプログラムです. &man.cpio.1; はバイトスワッピング, 多くの異なるアーカイブフォーマットの書き込みのオプション (それ以外にも多数のオプションがあります)があり, パイプで他のプログラムにデータを渡す事もできます. この最後に挙げた特徴により, &man.cpio.1; はインストールメディアについては優れた選択です. &man.cpio.1; は stdin からの入力でなければならず, ディレクトリツリーの探索や ファイルリストについての機能はありません. &man.cpio.1; はネットワーク経由のバックアップの機能はありません. リモートテープドライブにはパイプラインと &man.rsh.1; を使って送る事ができます. (コマンド使用例はまだです) Pax &man.pax.1; は tar と cpio に対する IEEE/POSIX の回答です. 長年の間, 様々なバージョンの tar や cpio は, 互いにわずかながら非互換性を有していました. 各々をしらみ潰しに標準化する代わりに, POSIX は新しいアーカイブユーティリティを作ることにしました. pax は専用に開発された新しいフォーマットに加えて, いくつもの cpio や tar のフォーマットの読み書きに対応しようと試みています. コマンド群は tar よりも cpio の方にいくぶん似ています. Amanda Amanda (Advanced Maryland Network Disk Archiver) は単一のプログラムではなくクライアント / サーバ型のバックアップシステムです. Amanda サーバは, Amanda クライアントであるネットワークで サーバに接続された複数のコンピュータから 一つのテープドライブへバックアップをおこないます. このような場合の一般的な問題はいくつもの大容量の ディスクからデータディレクトリをテープにバックアップするには 時間がかかりすぎてしまうという事です. Amanda はこの問題を解決します. Amanda は同時に複数のファイルシステムのバックアップをおこなう時に 「ホールディングディスク」を使う事ができます. Amandaの設定ファイルに書いたすべてのファイルシステムの フルバックアップを特定の間隔でとるために「アーカイブセット」 と呼ばれるテープグループを作ります. これには夜間に作られるすべてのファイルシステムの増分 (あるいは差分として) のバックアップも含みます. 障害の起きたファイルシステムの回復には最も新しい フルバックアップと増分のバックアップが必要です. 設定ファイルでバックアップのコントロールと Amanda によるネットワークトラフィック量を設定します. Amanda はデータをテープに書くのにバックアッププログラムの いずれかを使うでしょう. Amanda はその一部分でもパッケージでも利用可能ですが, デフォルトではインストールされません. 何もしない - “何もしない” + 何もしない というのはコンピュータのプログラムではありませんが, バックアップの戦略として最も広く採用されている物です. これには初期投資が必要ありません. したがわなければならないバックアップスケジュールもありません. ただ何もしないだけです. もしデータに何かが起きたら, 苦笑いして耐えてください. あなたにとって時間やデータの価値が少ないか - あるいはまったくないのであれば “何もしない” + あるいはまったくないのであれば 何もしない のはあなたのコンピュータに最も適した バックアッププログラムでしょう. しかし注意してください. Unix は便利なツールです. 6 ヶ月も使っていれば価値のあるファイルの 山ができ上がっているでしょう. - “何もしない” は + 何もしない は /usr/obj やその他の, コンピュータによってつくり出された ディレクトリツリーについては適切な方法です. 一つの例はこのハンドブックのファイルで, これらは SGML のファイルより生成された物です. HTML ファイルのバックアップを作る必要はありません. SGML のソースファイルは定期的にバックアップします. どのバックアッププログラムが最適でしょう? 定期的に &man.dump.8; しましょう. Elizabeth D. Zwicky はここで検討したプログラムすべてについて 拷問的なテストをおこないました. すべてのデータと Unixファイルシステムの状態すべてを保存するには明らかに &man.dump.8; でしょう. Elizabeth は大きく変化に富んだ異常な状態 (いくつかはあまり異常でもない状態のものもあります) になっているファイルシステムで, それぞれのプログラムでファイルシステムの バックアップとリストアを行ってテストしました. 特色のある状態には, ホールを持つファイル, ホールとヌルブロックを持つファイル, 奇妙な文字をファイル名に持つファイル, 読み出し不可, 書き込み不可のファイル, デバイスファイル, バックアップ中にファイルのサイズを変更する, バックアップ中にファイルの作成/削除をおこなうなどがあります. 彼女は1991年10月の LISA Vで結果の発表をしています.torture-testing Backup and Archive Programs を参照してください. 緊急時のリストア手順 災難の起きる前に 起き得るどのような災難に対しても以下の 4ステップだけが必要な準備です. ステップ 1では, ファイルシステムテーブル(/etc/fstab) やブートメッセージで示されるすべてのディスクの disklabelをそれぞれ2コピーづつプリント (例えば disklabel da0 | lpr を実行します) します. ステップ 2では, boot.flp と fixit.flp にそのシステムのすべてのデバイスドライバが 含まれているか確認します. 最も簡単な確認の方法は, フロッピーをドライブに入れてリブートし, ブートメッセージを確認することです. あなたのシステムのデバイスがすべて含まれ, 機能していれば, step 3へ飛んでください. そうでないなら, そのシステムのすべてのディスクをマウントでき, テープドライブにもアクセスできる 2種類のカスタムブートフロッピーディスクを作る必要があります. これらのフロッピーには &man.fdisk.8;, &man.disklabel.8;, &man.newfs.8;, &man.mount.8;, と利用したいバックアッププログラムが 入っていなければなりません. これらのプログラムはスタティックリンクされた プログラムである必要があります. &man.dump.8; を使うのであればフロッピーに &man.restore.8; を入れる必要があります. ステップ 3では, 通常の方法でバックアップを作ります. 最新のバックアップの後でおこなわれた変更は 回復することはできません. バックアップテープにライトプロテクトをしてください. ステップ 4では, フロッピー (boot.flp と fixit.flp あるいはステップ 2で作った2枚のカスタムブートフロッピーディスクです) とバックアップテープのテストをします. 手順のノートを作りましょう. このノートはブートフロッピーディスク, バックアップテープに入れておきプリントアウトしておきます. あなたがリストアをおこなうような時は おそらく錯乱状態でしょうからこのノートはバックアップを 破壊してしまうようなことを防ぐのに役立つでしょう (どのようにして破壊するって? tar xvf /dev/rsa0 とする替りに偶然 tar cvf /dev/rsa0 とタイプしてバックアップテープに上書きしてしまうかも しれません). 訳注: 上書きはライトプロテクトをしておけば防げますが, なんらかの原因でプロテクトがはずれているかもしれません. ちなみに訳者の経験から言えば上のようなミスタイプは 結構起きます. 安全性を増すために, 毎回ブートフロッピーディスクを作り, 2 巻のバックアップテープを取ります. 一方を離れた場所に保管します. 離れた場所は同じ建物の地下室ではいけません. 世界貿易センタービルにあった数多くの会社は 苦い経験よりこの教訓を得ました. 離れた場所とはコンピュータやディスクドライブから かなり離れていて物理的に分離されていなければなりません. ブートフロッピーディスクを作るスクリプトの一例 /mnt/sbin/init gzip -c -best /sbin/fsck > /mnt/sbin/fsck gzip -c -best /sbin/mount > /mnt/sbin/mount gzip -c -best /sbin/halt > /mnt/sbin/halt gzip -c -best /sbin/restore > /mnt/sbin/restore gzip -c -best /bin/sh > /mnt/bin/sh gzip -c -best /bin/sync > /mnt/bin/sync cp /root/.profile /mnt/root cp -f /dev/MAKEDEV /mnt/dev chmod 755 /mnt/dev/MAKEDEV chmod 500 /mnt/sbin/init chmod 555 /mnt/sbin/fsck /mnt/sbin/mount /mnt/sbin/halt chmod 555 /mnt/bin/sh /mnt/bin/sync chmod 6555 /mnt/sbin/restore # # create the devices nodes デバイスノードを作る # cd /mnt/dev ./MAKEDEV std ./MAKEDEV sd0 ./MAKEDEV sd1 ./MAKEDEV sd2 ./MAKEDEV st0 ./MAKEDEV pty0 cd / # # create minimum filesystem table 最小限のファイルシステムテーブル # cat > /mnt/etc/fstab < /mnt/etc/passwd < /mnt/etc/master.passwd < 災難の後に 重要な問題は, ハードウェアが生き残ったかどうかです. 定期的なバックアップを取っていれば ソフトウェアについて心配する必要はありません. ハードウェアがダメージを受けていたら, 最初にそのダメージを受けた部品を交換してください. ハードウェアに問題がなければ, フロッピーをチェックしてください. カスタムブートフロッピーディスクを使っているのであれば シングルユーザ(boot: プロンプトの出た時に -s とタイプしてください) でブートしてください. それから次の 「ファイルシステムを1つずつ回復する」 を読んでください. boot.flp と fixit.flp を使っているのであればこのまま読み続けてください. boot.flp を入れてブートしてください. 本来のインストールメニューが表示されるはずです. (ここで) Fixit--Repair mode with CDROM or floppy.オプションを選びます. 指示の通り fixit.flp を入れてください. restore とその他の必要なプログラムは /mnt2/standに置かれています. ファイルシステムを一つずつ回復する 最初のディスクのrootパーティションを &man.mount.8; (例えば mount /dev/da0a /mnt のように) マウントして見てください. ディスクラベルが破壊されている場合は &man.disklabel.8; を使ってあらかじめプリントしておいた通りに パーティションを作り直しラベルをつけてセーブしてください. &man.newfs.8; を使いファイルシステムを作り直します. ルートパーティションを読み書き可能にマウント (mount -u -o rw /mnt) しなおします. バックアッププログラムとバックアップテープを使って このファイルシステムのデータを回復します (例えば restore vrf /dev/sa0とします). ファイルシステムをアンマウント (umount /mntなど) して, 障害を受けたファイルシステムそれぞれについて 繰り返してください. システムが動き出したら, 新しいテープにデータをバックアップしてください. どのような理由で再び事故が起きたりデータが 失われるかはわかりません. これに時間を費す事で, 後々の災難から救われる事になります. + * 災難対策をしていませんでした. どうしたらいいでしょう? +]]> + フロッピーへのバックアップはどうですか? データをフロッピーにバックアップすることはできますか? 実はフロッピーはバックアップ向きのメディアとは言えません. というのは: 特に長期間に渡って保存する場合, 信頼性が低い. バックアップ, リストアがとても遅い. 容量が小さい(ハードディスク全体の日々のバックアップに １ダース, 長期間なら本当にたくさん). けれども, データをバックアップする他の手段がない場合には, まったくバックアップをしないよりもフロッピーを使うほうが良い でしょう. これを行う場合には, 高品質のものを使うようにしてください. まわりに何年も転がっていたフロッピーは使わない方よいでしょう. 評判のよいメーカの新品を使うことが理想です. どうやってデータをフロッピーにバックアップ するのですか? フロッピーへバックアップする最も良い方法は tar &man.tar.1; コマンドに (マルチ・ボリューム) 　　　　オプションを付けて, 複数のフロッピーにまたがるバックアップも できるようにする方法です. カレントディレクトリの全てのファイルとサブディレクトリを バックアップするには, 以下のようにします (root で): &prompt.root; tar Mcvf /dev/rfd0 * 1枚目のフロッピーがいっぱいになると &man.tar.1; は 次のボリュームを入れるようプロンプトを表示します. ( &man.tar.1; は, さまざまなメディアを扱えるので ボリュームと表示します. ここではフロッピーのことです) Prepare volume #2 for /dev/rfd0 and hit return: これは(ボリューム番号が増えながら) 指定された全てのファイルが 保存されるまで繰り返されます. バックアップを圧縮することはできませんか? 残念ながら, &man.tar.1; はマルチ・ボリュームに保存する場合は オプションを使うことができません. もちろん, すべてのファイルを &man.gzip.1; してから, フロッピーに &man.tar.1; して, ファイルを &man.gunzip.1; することはできます! リストアはどうしますか? 保存したファイル全てをリストアするには: &prompt.root; tar Mxvf /dev/rfd0 指定したファイルのみをリストアするには1枚目のフロッピーを セットして: &prompt.root; tar Mxvf /dev/rfd0 filename &man.tar.1; は, 必要なファイルを見つけるまで, 続きのフロッピーを セットするよう表示します. 別の方法として, どのフロッピーにファイルが入っているのかが 分かっているなら, そのフロッピーをセットして上記と同じコマンドを 使うこともできます. 最初のファイルが前のフロッピーから続いて いる場合は, &man.tar.1; は, 頼みもしないのに, そのファイルはリストア できないと警告します! diff --git a/ja_JP.eucJP/books/handbook/cutting-edge/chapter.sgml b/ja_JP.eucJP/books/handbook/cutting-edge/chapter.sgml index 87c38986fd..a439275635 100644 --- a/ja_JP.eucJP/books/handbook/cutting-edge/chapter.sgml +++ b/ja_JP.eucJP/books/handbook/cutting-edge/chapter.sgml @@ -1,2188 +1,2209 @@ 開発の最前線 再構成, 再編成, 一部更新: &a.jim; March 2000. 原作: &a.jkh;, &a.phk;, &a.jdp;, &a.nik;, およびたくさんのフィードバック. 概要 あるリリースから次のリリースまでの期間にも, FreeBSD の開発は 休みなく続けられています. この開発の最前線に興味を持っている人のために, 手元のシステムを最新の開発ツリーに同期させておくための, とても使いやすい仕掛けが何種類も用意されています. 注意: 開発の最前線は, 誰でもが扱えるという性質のものではありません! もしもあなたが, 開発途中のシステムを追いかけようか, それともリリース バージョンのどれかを使い続けようかと迷っているのなら, きっとこの章が参考になるでしょう. - -CURRENT vs. -STABLE + -CURRENT v.s.. -STABLE FreeBSD には二つの開発ブランチがあります. -CURRENT と -STABLE です. この章ではそれぞれについて少しだけ説明し, どのようにしてあなたの システムを対応するツリーに対して常に最新の状態にに保つかについて 記述します. まず -CURRENT を論じ, ついで -STABLE を論じます. 訳: &a.hanai; 6 November 1996. 最新のFreeBSDを追いかける これを読むならば, 心に止めておいて欲しいことがあります. -CURRENT とは FreeBSD の開発における 切断面 であり, 故にあなたが FreeBSD を使い始めたばかりなら あなたはこれがすることについて十分検討を重ねた方がいいでしょう. FreeBSD-current ってなに? FreeBSD-CURRENT とは, 文字通りに, 日々変更されている FreeBSD のソース のスナップショット以外の何ものでもありません. 中には現在開発途上のソフトウェア, 実験的な変更, あるいは過渡的な機能などが含まれています. また, この中に入っている機能がすべて次の公式リリースに 入るとはかぎりません. FreeBSD-CURRENT をソースからほとんど毎日コンパイルしている人はたくさん いますが, 時期によっては FreeBSD-CURRENT はコンパイルさえできない状態になっていることもあります. これらの問題は一般的には可能な限り素早く解決されますが, FreeBSD-CURRENT のソースが不幸をもたらすか, それとも非常に 素晴らしい機能をもたらすかというのは文字通り, ある与えられた 24 時間の間 のどの部分であなたがソースを手に入れたか, による場合もあります. 誰が FreeBSD-current を必要としてるの? FreeBSD-CURRENT は, 主に次の三つの重要なグループを対象としています. ソースツリーのある部分に関して活発に作業している FreeBSD グループのメンバー. 彼らにとっては 最新のもの にしておくのが 絶対に必要なことなのです. 活発にテストをする FreeBSD グループのメンバー. 彼らは, FreeBSD-CURRENT を 健全である ことを出来るだけ確認するために種々の問題と戦うのに 時間を費やすのを厭わない人々です. 彼らはまた, 様々な変更に関する提案や FreeBSD の大まかな方向付けを行ないたいと思っている 人々でもあります. 単に, 様々な事に目を向け, 参考のために (例えば, 動かすためではなく 読むため に) 最新のソースを使いたいと思っている FreeBSD (または他の) グループのまわりにいるメンバー. これらの人々はまた, 時々コメントやコードを寄稿してくれます. FreeBSD-CURRENT に期待しては<emphasis>いけない</emphasis>ことは? なにか新しくカッコイイモノがあると聞き, 自分の周囲では 一番にそれを持ちたいがためにリリース前のコードの断片を 追いかけること. バグを修正するための素早い方法. 我々によって 公式にサポートされている こと. 私たちは 3 つの 公式な FreeBSD-CURRENT のグループの一つに実際に属する 人々を助けるのにベストを尽くしますが, 技術的なサポートを行なうには 単に「時間が足りない」のです. これは我々が外の人を助けるの好まない, ケチで意地悪い人間だと いうことではなく (もしそうなら FreeBSD なんかやっていません), 文字通り我々は一日に 400 ものメッセージに答え かつ FreeBSD の作業をすることなど出来ない! ということなのです. もし, たくさんの質問に答えるか, それとも FreeBSD を良くする作業を続けるかという選択が与えられた場合, あなた方のほとんどは後者を支持する, と私は確信しています. FreeBSD-CURRENT を使う &a.current;と&a.cvsall;に加わって下さい. これは単に良い考えであるというだけでなく, 必須のことなのです. もし FreeBSD-current メーリングリストに入っていなければ, 様々な人がシステムの現在の状態について 述べているコメントを決して見ることはありませんし, 従って他の人が既に見つけて解決している多くの問題に戸惑っ てあきらめてしまうでしょう. さらに言うと, システムを正常に保つための 重要な情報を見逃してしまう可能性もあります. &a.cvsall; メーリングリストでは, それぞれの変更についての commit ログを見ることができますし, それに関して起こり得る副作用の情報を得ることができ, もう一つの加わるに値するメーリングリストです. これらのメーリングリストに入るには, &a.majordomo; へ subscribe freebsd-current subscribe cvs-all と書いたメールを送って下さい. オプションとして本文に help と書けば, Majordomo はあなたへ我々がサポ ートする様々なメーリングリストに参加 / 脱退する方法に関する詳しい ヘルプを送ります. ftp.FreeBSD.org からのソースの入手. 以下の3つの方法で行なうこと が出来ます. 下に述べられているCTMを用いる. 均一なレートの, 良質の TCP/IP 接続を持っていない人には, これが一番いい方法でしょう. cvsup を この supfile を用いて使用する. これは 2 番目に推薦される方法です. なぜなら, cvsup によって一度全体を入手し, 後は変更されたところだけを入手することが 出来るからです. たくさんの人が自動的にソースを最新のもに保つために cvsup を cron から起動しています. これを行なうための非常に簡単な方法は, 単に
&prompt.root; pkg_add -f \ ftp://ftp.FreeBSD.org/pub/FreeBSD/development/CVSup/cvsupit.tgz
とタイプすることです. ftp を使う. FreeBSD-current のソースツリーは常に ftp://ftp.FreeBSD.org/pub/FreeBSD/FreeBSD-current/ に 公開 されています. 我々はまた全体を compress/tar して入手できる wu-ftpd を使っています. 例えば, usr.bin/lex があったとすると, ftp> cd usr.bin ftp> get lex.tar とすることにより, ディレクトリ全体(この場合, usr.bin/lex以下全体) を tar ファイルとして入手することができます. 以上のことをまとめると, 必要に応じて迅速なアクセスをする必要があり, 接続のバンド幅が問題ではなければ cvsup か ftp を使いましょう. そうではなければ CTM を使いましょう. もしソースを, 眺めるだけでなく走らせるために入手しているのであれば, 一部だけ選ぶのではなく, current の全体を手に入れてください. なぜなら, ソースの様々な部分が他の部分の更新に依存しており, 一部のみをコンパイルしようとすると, ほぼ間違いなくトラブルを起こすからです. current をコンパイルする前に /usr/src にある Makefile をよく読んでください. アップグレードの処理の一部として, 少なくとも一回は最初に make world を行なうべきでしょう. &a.current; を読めば, 次のリリースへ向けて, 時々必要になる 他のブートストラップの方法に関して 常に最新情報を得ることが出来ます. アクティブになって下さい! もし FreeBSD-CURRENT を走らせているなら我々はそれに関するコメント, 特に拡張やバグ潰しに関する提案, を欲しています. コードを伴う提案はもっとも歓迎されるものです! FreeBSD の安定状態の持続 あなたが FreeBSD をプロダクション環境下で使っていて -CURRENT 系列からの修正の最新版を得ていることを確実にしたいなら -STABLE を使っていた方がいいでしょう. これは新しいリリースが まとめられた時 -RELEASE がこれから分岐するツリーです. たとえば, あなたが 3.4-RELEASE のコピーを持っていたとして, それは単に CD-ROM にまとめられた -STABLE 系列の snapshot に過ぎません. -RELEASE 以降に -STABLE にマージされた差分を入手するには -STABLE 系列を 追跡する必要があります. 訳: &a.jp.iwasaki;. FreeBSD-STABLE ってなに? FreeBSD-STABLE は, 次の本流のリリースを目指した新機能をあまり採り入 れない保守的な変更のための開発の支流です. 実験的またはテスト未完の変更はこの支流には取り入れられません (最新の FreeBSD を追いかける 参照). 誰が FreeBSD-STABLE を必要としているの? もしあなたが仕事で使用しているとか, なによりも FreeBSD システムの安定性を最重要視するなら, stable を追いかけることを考えるべきで しょう. stable の支流は前のリリースに関して効果的にバグフィックスされた 流れであるため, 最新のリリース ( &rel.current;-RELEASE 執筆時点) をインストールしているのであれば, 特にそうです. stable ツリーが常に完全に互換性があり安定するように努力し ていますが, たまに間違いがあることに注意してください (結局, 内容が吟味 されずに素早く送られた変更を含むソースがまだあるのです). また, current を stable へ移行する前に完璧なテストフィックスに最善を尽くしますが, 私たちのテストはすべてのケースを十分に網羅して いるとは限りません. もし何か stable で不具合があるようでしたら, 私たちにすぐに教えてください (次の節参照). FreeBSD-STABLE を使う &a.stable; へ加わってください. このメーリングリスト では, stable の構築に関連する事柄や, その他の注意すべき点 に関する情報が流れています. また開発者は議論の余地がある修正や変更を考えている場合に, このメーリングリストで公表し, 提案された変更に 関して問題が生じるかどうかを返答する機会を ユーザに与えます. また, &a.cvsall; メーリングリストでは, それぞれの変更がなされると 起こりうる副作用に関するすべての適切な情報と一緒に commit log を読むことができます. subscribe しておきたいもう一つのメーリングリストです. メーリングリストに参加するには, &a.majordomo へメッセージの本文に 次のように書いたメールを送ってください: subscribe freebsd-stable subscribe cvs-all オプションとして本文に `help' と書けば, Majordomo は私たちがサポートする様々なメーリングリストに参加 / 脱退する方法に関する詳しいヘルプを送付します. もし, あなたが新しいシステムをインストールしようとしていて それを可能な限り安定なものにしておきたいなら, 最新のブランチの snapshot を ftp://releng4.freebsd.org/pub/FreeBSD から取得し, これを一般のリリースのものと同様に インストールしてください. もし, 既に FreeBSD の以前のリリースが動いている場合で, これをソースからアップグレードしようとするならば, ftp.FreeBSD.org より簡単に これを行う事が出来ます. これには次の 3 つの方法があります. CTM 機能を使用する. 転送レートが安定している TCP/IP 接続でない場合は, この方法が適しています. cvsup を この supfile を用いて使用する. 一度コレクション全体を入手してしまえば, 前回からの変更部分だけですむので, 2 番目に推奨される方法です. 多くの人が cron から cvsup を実行し, 自動的にソースコードを最新の状態に保っています. これを簡単に扱うには次のようにタイプしてください.
&prompt.root; pkg_add -f \ ftp://ftp.FreeBSD.org/pub/FreeBSD/development/CVSup/cvsupit.tgz
 ftp を使用する. FreeBSD-STABLE 用のソースツリーは 常に次のところで公開されています: ftp://ftp.FreeBSD.org/pub/FreeBSD/FreeBSD-stable/ 私たちはまた, tar/compress でツリー全体を入手できる wu-ftpd を使用しています. 例えば : usr.bin/lex に対して: ftp> cd usr.bin ftp> get lex.tar とすることにより, ディレクトリ全体を tar ファイルとして入手することができます. 基本的には, ソースに迅速でオンデマンドなアクセスが必要で, 接続のバンド幅が問題でなければ, cvsup か ftp を使いましょう. そうで ない場合は CTM を使いましょう. stable をコンパイルする前に, /usr/src にある Makefile をよ く読んでください. 少なくとも一回はアップグレードの処理の一部として最初に make world を実行するべきでしょう. &a.stable; を読めば, 次のリリースに移行する に当たって時々必要となる既存システムからの 新システムの構築手順に ついての最新情報が得られるでしょう. あなたのソースを同期させる 訳: &a.jp.iwasaki;. 13 September 1997. インターネット接続 (または電子メール) を使用して, あなたの興味の対象によって FreeBSD プロジェクトのソースのある一部分または全体の最新を 追いかける方法は色々あります. 私たちが提供している基本的なサービスは Anonymous CVS, CVSup と CTM です: Anonymous CVS と CVSup は pull 同期モデルを採用しています. CVSup の場合, ユーザ (または cron スクリプト) が cvsup 起動し, どこかにある cvsupd サーバとやりとりしてファイルを 最新状態にします. 届けられる更新情報はその時点の最新のものであり, また必要な時にだけ取り寄せられます. 興味のある特定のファイルやディレクトリに 限定して更新することも簡単にできます. クライアント側のソースツリーの状態・ 設定ファイルの指定に従い, サーバによって更新情報が 素早く生成されます. Anonymous CVS は, このプログラムがリモートの CVS リポジトリから直接変更点を pull できるようにした &man.cvs.1; への拡張であるという点で, CVSup よりもずっと単純です. CVSup は効率の点ではるかにまさっていますが, Anonymous CVS の方が簡単に利用できます. 一方, CTM はあなたが持っているソースとマスタアーカイブ上に あるそれとの対話的な比較をおこないませんし, あるいは向こう側から変更点を pull したりもしません. そのかわりに, 前回の実行時からの変更を認識するスクリプトが マスタ CTM マシン上で一日に数回実行され, すべての変更を compress して通し番号を振り, さらに電子メールで転送できるようにエンコードします (印字可能な ASCII キャラクタのみです). 受信した後は, これらの CTM のデルタ は自動 的にデコード, 検査してユーザのソースのコピーに変更を適用する &man.ctm.rmail.1; によって処理可能となります. この処理は CVSup や Anonymous CVS よりずっと効率 的であり, pull モデルというよりむしろ push モデルで あるため, 私たちのサーバ資源の負荷は軽くなります. もちろん他のトレードオフもあります. うっかりアーカイブ の一部を消してしまっても, CVSup は壊れた部分を検出して再構築してくれます. CTM はこれをやってくれませんし, Anonymous CVS はおそらく他の何よりも深く混乱してしまうことが多いでしょう. もしソースツリーの一部を消してしまったら, (最新の CVS ベースデルタから) 一からやり直し, CTM か anoncvs を使って悪い部分を消去し, 再同期させることによって すべてを再構築しなければなりません. Anonymous CVS, CTM, CVSup についての 詳しい情報については, 以下の節を参照してください: Anonymous CVS 訳: &a.jp.sugimura;. 19 July 1998. <anchor id="anoncvs-intro">導入 Anonymous CVS (もしくは, anoncvs として知られています) は離れたところにある CVS リポジトリと同期を取るために FreeBSD に付属している CVS ユーティリティに含まれている機能です. 他にもありますが, それは FreeBSD のユーザが, 特別な権限なしに FreeBSD プロジェクトの公式な anoncvs サーバに読み取り専用で CVS の操作をすることができるようにするためのものです. それを使うには, 単に CVSROOT 環境変数を設定して適切な anoncvs サーバを指定し, cvs login を使って パスワード anoncvs を入力して下さい. そして次に, &man.cvs.1; コマンドを使うことで, 手元にあるリポジトリと同じようにアクセスでるようになります. CVSup と anoncvs のサービスは本質的に同じ機能ではないか ということも言われていますが, ユーザが同期を取る方法を選ぶときに影響を与えるような さまざまなトレードオフが存在します. 要約して言えば, CVSup はネットワーク資源の使い方においては非常に効率がよく, またはるかに技術的に洗練されたものですが, 相当な手間がかかります. CVSup を使うには, 特別なクライアントをまずインストールして設定しなくては 1bit も取ってくることができず, またそのとき CVSup では collections と呼んでいるかなり大きなかたまりだけからしか 取ってこれません. それに対して anoncvs では, CVS モジュールの名前を指定することで特定のプログラムの (ls や grep のような) 個々のファイルから調べることができます. もちろん, anoncvs は CVS リポジトリの読み取り専用の操作に対してのみ適しているので, もしあなたが FreeBSD プロジェクトのものと共有されたなにか ローカルなリポジトリを作ってそこでの開発を 行おうというときには, CVSup だけが唯一の手段となってしまいます. <anchor id="anoncvs-usage">Anonymous CVS を使う &man.cvs.1; を設定して Anonymous CVS リポジトリを使うには単に CVSROOT 環境変数を設定して FreeBSD プロジェクトの anoncvs サーバを指定するだけのことです. この文書を書いているときには, 次のサーバが利用できるようになっています. USA: :pserver:anoncvs@anoncvs.freebsd.org:/ncvs (cvs login コマンドを使い, プロンプトが表示されたらパスワード anoncvs を入力してください) CVS はかつて存在した (もしくは, 時にはこれから存在するものも :) ほとんどどんなバージョンの FreeBSD のソースを check out することができますが, あなたは &man.cvs.1; の リビジョン () のオプションや FreeBSD プロジェクトのリポジトリの中で それをどのように指定したらいいものかということを よく知っておく必要があります. タグには 2 種類あって, リビジョンタグとブランチタグがあります. リビジョンタグは特定の改訂版を指しており, それはいつも同じものを意味しています. 一方ブランチタグは, 指定されたときの指定された開発の流れにおける 最も新しい改訂版を示しています. ブランチタグは特定の改訂版を指していないために, その意味はきょうと明日では違うものになっているでしょう. ユーザが興味を持つと思われるブランチタグの一覧です (ports コレクションに 有効なタグはHEAD だけだという事を 心に留めておいてください). HEAD 主要部をなす流れ, すなわち FreeBSD-CURRENT のための名前です. また, どのリビジョンも 指定されなかったときにはこれになります. + + RELENG_4 + + + FreeBSD-4.X の開発のための流れです. + FreeBSD-STABLE としても知られています. + + + RELENG_3 FreeBSD-3.X の開発のための流れです. - FreeBSD-STABLE としても知られています. + 3.X-STABLE としても知られています. RELENG_2_2 FreeBSD-2.2.X の開発のための流れです. 2.2-STABLE としても知られています. このブランチは大部分が すたれています. ユーザが興味を持つであろうリビジョンタグの一覧です. これらのどれも ports コレクションには無効です. ports コレクションは複数のリビジョンを持ちません + + RELENG_4_0_0_RELEASE + + + FreeBSD 4.0 です. + + + RELENG_3_4_0_RELEASE FreeBSD-3.4 です. RELENG_3_3_0_RELEASE FreeBSD-3.3 です. RELENG_3_2_0_RELEASE FreeBSD-3.2 です. RELENG_3_1_0_RELEASE FreeBSD-3.1 です. RELENG_3_0_0_RELEASE FreeBSD-3.0 です. RELENG_2_2_8_RELEASE FreeBSD-2.2.8 です. RELENG_2_2_7_RELEASE FreeBSD-2.2.7 です. RELENG_2_2_6_RELEASE FreeBSD-2.2.6 です. RELENG_2_2_5_RELEASE FreeBSD-2.2.5 です. RELENG_2_2_2_RELEASE FreeBSD-2.2.2 です. RELENG_2_2_1_RELEASE FreeBSD-2.2.1 です. RELENG_2_2_0_RELEASE FreeBSD-2.2.0 です. ブランチタグを指定したときには, 普通はその開発の流れにおける 最も新しいバージョンのファイルを受け取ることができます. もし以前のバージョンのものが欲しいときには, 日付を オプションを使って指定すればよいです. これ以上のことは &man.cvs.1; man page を見てください. 例 本当はなにかする前には &man.cvs.1; のマニュアルページの全体を ちゃんと読んでからのほうがいいのですが, Anonymous CVS の使い方の本質的なところを簡単に例を挙げて説明します. -CURRENT (&man.ls.1;) をちょっと確認してから消してみます. &prompt.user; setenv CVSROOT :pserver:anoncvs@anoncvs.freebsd.org:/ncvs &prompt.user; cvs login プロンプトが表示されたら, パスワード anoncvs を入力します. &prompt.user; cvs co ls &prompt.user; cvs release -d ls &prompt.user; cvs logout - &man.ls.1; のバージョンを 2.2-STABLE + <title>&man.ls.1; のバージョンを 3.X-STABLE ブランチから調べてみます. &prompt.user; setenv CVSROOT :pserver:anoncvs@anoncvs.freebsd.org:/ncvs &prompt.user; cvs login プロンプトが表示されたら, パスワード anoncvs を入力します. -&prompt.user; cvs co -rRELENG_2_2 ls +&prompt.user; cvs co -rRELENG_3 ls &prompt.user; cvs release -d ls &prompt.user; cvs logout &man.ls.1; の変更点のリストを - (unidiff で) 作ってみます. + (unified diff で) 作ってみます. &prompt.user; setenv CVSROOT :pserver:anoncvs@anoncvs.freebsd.org:/ncvs &prompt.user; cvs login プロンプトが表示されたら, パスワード anoncvs を入力します. -&prompt.user; cvs rdiff -u -rRELENG_2_2_2_RELEASE -rRELENG_2_2_6_RELEASE ls +&prompt.user; cvs rdiff -u -rRELENG_3_0_0_RELEASE -rRELENG_3_4_0_RELEASE ls &prompt.user; cvs logout 他のどんなモジュールの名前が 使われているか検索してみます. &prompt.user; setenv CVSROOT :pserver:anoncvs@anoncvs.freebsd.org:/ncvs &prompt.user; cvs login プロンプトが表示されたら, パスワード anoncvs を入力します. &prompt.user; more modules/modules &prompt.user; cvs release -d modules &prompt.user; cvs logout 他の資料 次の資料は CVS を学ぶのに役に立つでしょう. CVS チュートリアル. Cal Poly によります. Cyclic Software, 商用として CVS を維持しています. CVSWeb は FreeBSD Project の CVS のための web インターフェースです. <command>make world</command> の利用 FreeBSD のどれか特定のバージョン (stable, current など) について, ローカルのソースツリーを同期させたら, そのソースツリーを使ってシステムを 再構築しなければなりません. バックアップを作成する システムを再構築する前にバックアップを 作成することの重要性は, いくら強調してもし過ぎると言うことはありません. システム全体の再構築とは (以降に書かれた手順に従っている限り)難しい作業ではありませんが, どんなに注意していたとしても, あなた自身, あるいはソースツリーで作業している他の人達に手違いがあった時には, システムが起動しなくなってしまう状態になることがあるのです. まず, バックアップがきちんと作成されていることを確認して下さい. - そして, fixit フロッピーを用意して下さい. 私は今までに, - 一度もバックアップや fixit フロッピーのお世話になったことはありませんし, + そして, fix-it フロッピーを用意して下さい. 私は今までに, + 一度もバックアップや fix-it フロッピーのお世話になったことはありませんし, これからもそうなるようなことはないと思っていますが, どういう場合であっても用意しておいて損はないでしょう. メーリングリストに参加する もともと, -STABLE と -CURRENT のコードブランチは, 開発中のものです. FreeBSD の作業に貢献してくださっている人達も人間ですから, 時にはミスをすることだってあるでしょう. そのような間違いは, 単に警告を示す見慣れない 診断メッセージをシステムが,表示するような, 全く害のないものであることもあれば, システムを起動できなくしたり, ファイルシステムを破壊してしまうような, 恐ろしい結果を招くものかも知れません. 万が一, このような問題が生じた場合, 問題の詳細と, どのようなシステムが影響を受けるかについて書かれた 注意(heads up)の記事が 適切なメーリングリストに投稿され, そして, その問題が解決されると, 問題解決(all clear)のアナウンス記事が同様に 投稿されます. -STABLE や -CURRENT ブランチを試したり, それらに 追随していくときに FreeBSD-stable@FreeBSD.ORG や FreeBSD-current@FreeBSD.ORG を読まないというのは, 自ら災難を招くことになるでしょう. 訳注: これらのメーリングリストは英語でやりとりされているため, 日本語での投稿は歓迎されません. 英語でのやりとりができない人は, FreeBSD 友の会 の運営しているメーリングリストをあたってみるのがいいでしょう. <filename>/usr/src/UPDATING</filename> を読む 何を始めるにしろ, まず最初に /usr/src/UPDATING (もしくはあなたがソースコードを どこにコピーしたにせよそれに相当するファイル) を読みましょう. このファイルにはあなたが遭遇するかも知れない問題に対する重要な情報を 含んでいたり, あなたが特定のコマンドを実行しなければならなくなった時 その順序を指示したりするはずです. UPDATING があなたが読んだ事柄と矛盾している時は UPDATING が優先します. UPDATING を読むということは, 前述の 適切なメーリングリストを購読する代わりにはなりません. 二つの要求は相補的なもので排他的なものではないのです. <filename>/etc/make.conf</filename> の確認 - まず, /etc/make.conf を調べて下さい. - ここには, ソースを再構築する際に使用される + まず, /etc/defaults/make.conf と + /etc/make.conf を調べてください. そこには + 最初から標準的なものが (多くのものはコメントアウトされていますが) + 含まれています. ソースからシステムを再構築するときに make が + /etc/make.conf に付け加えられた設定を使用します. + /etc/make.conf に追加された設定は make + を実行したときに常に使われることを覚えておいてください. + それらをあなたのシステムに合うように設定しておくとよいでしょう. + ( FreeBSD 開発者でない) 標準的なユーザならおそらく + /etc/defaults/make.conf の CFLAGS と + NOPROFILE の行を追加したいでしょう. 最初の状態では, すべてがコメントアウトされています. 必要だと思う項目のコメントをはずして下さい. (開発者でない)標準的なユーザならおそらく, CFLAGS と NOPROFILE のコメントをはずすことを考えると思います. もし, 浮動小数点演算ユニット(386DX, 486DX, Pentium と, それより上のクラスのマシン)がある場合には, HAVE_FPU の行のコメントをはずすことができます. </para> <!-- hrs:2000/01/13 386DX doesn't have FPU. --> <para>この定義は, FreeBSD 2.2.2 以降で廃止されました. </para> </note> <para>他の定義 (COPTFLAGS, NOPORTDOCS など) の定義行についても, コメントを外す必要があるかどうか調べておきましょう. </para> </sect2> <sect2> <title><filename>/etc/group</filename> の更新 /etc ディレクトリには, システム起動時に実行されるスクリプトだけでなく, あなたのシステムの設定に関連する情報の大部分が 含まれています. そのディレクトリに含まれる スクリプトは, FreeBSD のバージョンによって多少異なります. また, 設定ファイルのなかには, 稼働中のシステムが日々利用している ものもあります. 実際には, /etc/group などがそれに該当します. make world のインストールの段階では, 特定のユーザ名, あるいはグループが存在していることを 要求する場面があります. システムのアップグレードを行なう際には, それらのグループが削除, あるいは変更されて存在していない可能性が 考えられますが, そういった場合, システムのアップグレードを 行なっている間に, 問題が発生する原因になります. この種の例でもっとも記憶に新しいのは, ppp サブシステムがインストールされる時, そのサブシステムが利用する 解決方法は, /usr/src/etc/group を調べ, 自分のシステムのグループ名リストと比較することです. 最新のファイルに含まれていて, あなたのファイルに含まれていない グループ名があれば, あなたのファイルにそのグループ名をコピーして下さい. 同様に, 名前が異なるにも関わらず, /etc/group と /usr/src/etc/group で同じ GID を持っているグループ名があれば, /etc/group に含まれる, 該当するすべてのグループ名を変更しておかなければなりません. もし, あなたがもっと神経質な人なら, あなたが名前を変更したり, 削除してしまったグループが所有しているファイルを, 次のようにして調べることもできます. &prompt.root; find / -group GID -print これは GID(グループ名もしくは数字で示されたグループ ID)で 指定されたグループが所有するすべてのファイルを表示します. コンパイルは, シングルユーザモードで行なった方が良いでしょう. そうすることで多少速度が向上する, というちょっとした利点が あるだけでなく, システムの再インストールは重要なシステムファイル, 標準コマンド, ライブラリ, インクルードファイルなどを操作します. 稼働中のシステムに(特に他のユーザがログインしている時に)そのような 変更を加えることは, トラブルを引き起こす原因となります. </para> <para>自信家の方は, このステップを省略しても構いません.</para> <note> <title>FreeBSD 2.2.5-RELEASE 以降の場合 以下に詳しく述べられているように, 2.2.5-RELEASE 以降, ビルド(システムの構築)とインストールの行程を分離して行なうことが可能になりました. そのため, マルチユーザモードで新しいシステムのビルドを行ない, その後, シングルユーザモードに移行してから インストールを行なうことができます. 稼働中のシステムでシングルユーザモードに移行するには, スーパユーザ(root)権限で次のコマンドを実行します. &prompt.root; あるいはシステムを再起動し, ブートプロンプトから フラグを設定することで, シングルユーザモードで システムを起動させることができます. 起動後, シェルプロンプトから 次のように実行して下さい. &prompt.root; fsck -p &prompt.root; mount -u / &prompt.root; mount -a -t ufs &prompt.root; swapon -a これはファイルシステムをチェックした後, / を読み書き可能にして再マウント, /etc/fstab に指定されている, それ以外の UFS ファイルシステムをすべてマウントしてから スワップを有効にします. <filename>/usr/obj</filename> の削除 システムが再構築される時, 構築されたものは(デフォルトで) /usr/obj 以下のディレクトリに格納され, そのディレクトリの下は /usr/src と同じ構造となります. このディレクトリをあらかじめ削除しておくことにより, make world の行程にかかる時間を短縮させ, 依存問題に悩まされるようなトラブルを回避することができます. /usr/obj 以下のファイルには, 変更不可(immutable)フラグ(詳細は &man.chflags.1; 参照)がセットされているものがあります. そのため, まず最初にそのフラグを変更しなければなりません. &prompt.root; cd /usr/obj &prompt.root; chflags -R noschg * &prompt.root; rm -rf * <title>全バージョンに共通すること まず, カレントディレクトリを /usr/src に 変更しなければなりません. 次のように実行して下さい. &prompt.root; cd /usr/src (もちろん, ソースコードが他のディレクトリにある場合には, /usr/src ではなく, ソースコードのあるディレクトリに移動して下さい). make world を行なうには, &man.make.1; コマンドを使用します. このコマンドは, Makefile というファイルから, FreeBSD を構成するプログラムの再構築方法や, どういう順番でそれらを構築すべきかといったような 指示を読み込みます. コマンドラインの一般的な書式は, 次のとおりです. &prompt.root; make この例では, が &man.make.1; に渡されるオプションになります. どのようなオプションが利用できるかについては, マニュアルページを 参照して下さい. は, Makefile に渡される変数であり, この変数は Makefile の動作をコントロールします. また, /etc/make.conf で設定される変数も 同様です. これは変数を設定するもう一つの方法として用意されています. &prompt.root; make -DNOPROFILE=true target は, プロファイル版のライブラリを構築しないことを指定する もう一つの記法で, /etc/make.conf 中の NOPROFILE= true # Avoid compiling profiled libraries の行に対応します. target は, &man.make.1; に どのように動作するのかを指示するためのものです. 各々の Makefile には, 数多くの異なる ターゲット(target) が定義されていて, 指定されたターゲットによって, 動作が決まります. Makefile に書かれているターゲットには, あなたが指定しても意味を持たないものも含まれます. これらは, システムの再構築に必要な段階を, 多くの さらに細かい段階に分割するため, 構築の過程で利用されるものです. 大抵の場合, &man.make.1; にパラメータを指定する必要はないでしょうから, コマンドラインは次のようなものになるでしょう. &prompt.root; make target 出力の保存 実行される &man.make.1; からの出力は, ファイルに保存すると良いでしょう. もし, 何か障害が発生した場合, エラーメッセージのコピーに加え, どの時点でそれが起こったのか, 完全なリストが手元に残ります. 何が悪かったのか, あなた自身がそれから理解することはできないかも 知れません. しかし, FreeBSD メーリングリストに投稿して, 誰か他の人からの助言を得るために利用することができます. ファイルに保存する最も簡単な方法は, &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 world … compile, compile, compile … &prompt.root; exit Script done, … 出力を保存する場合, /tmp ディレクトリの中に 保存してはいけません. このディレクトリは, 次の再起動で削除されてしまう可能性があります. 出力の保存には, (上の例のように)/var/tmpや root のホームディレクトリが適しています. FreeBSD-2.2.2 と, それ以前のバージョン /usr/src/Makefile には, システム全体を再構築しインストールを行なう world ターゲットが含まれています. それを, 次のように使って下さい. &prompt.root; make world FreeBSD-2.2.5 と, それ以降のバージョン FreeBSD-2.2.5 から(実際には, -CURRENT ブランチで最初に作成され, 2.2.2 と 2.2.5 の間の時点で -STABLE に導入されたのですが), world ターゲットは buildworld と installworld の二つに分割されました. その名前が示すように, buildworld は /usr/obj 以下に新しい完全な ディレクトリツリーを構築し, installworld は, そのツリーを 現在のマシンにインストールします. これは, 二つの理由から非常に有用です. まず第一に, 稼働中のシステムに全く影響を与えることなく, 安全にシステムの構築作業を行えることです. 構築作業は何にも依存せず独立して行なわれるため, マルチユーザモードで稼働中のシステムでも, 何一つ 悪影響を与えずに buildworld を 実行することができます. ただし, installworld は シングルユーザモードで行なうことをおすすめします. 第二に, NFS マウントを利用することで, ネットワーク上の複数のマシンをアップグレードすることが 可能な点があげられます. 例えば三台のマシン, マシン A, マシン B, マシン C をアップグレードしたい場合には, まず マシン A で make buildworld と make installworld を実行します. それから, マシン B とマシン C で /usr/src を NFS マウントし, make installworld とすることで 構築済みのシステムを各マシンにインストールすることができるのです. 一方, world ターゲットも残されていますので, FreeBSD-2.2.2 の場合として示されている方法と同じように, このターゲットを利用することもできます. make world は, make buildworld に続けて make installworld を実行します. make buildworld と make installworld のコマンドを分けて実行する場合には, それぞれ同じ引数を &man.make.1; に渡さなければなりません. 次のように実行したとすると, &prompt.root; make -DNOPROFILE=true buildworld 構築されたシステムは次のようにしてインストールする必要があります. &prompt.root; make -DNOPROFILE=true installworld そうしないと, make buildworld の段階で 構築されていない, プロファイル版ライブラリのインストールを 試みることになります. (訳注: もちろん, それには失敗するのでエラーが発生します. ) -CURRENT と, それ以降 もし, -CURRENT を追跡しているなら, make コマンドに オプションを渡すことができます. このオプションにより, make は 同時に複数のプロセスを生成するようになります. これは, 実際に複数の CPU を備えているマシンに対して 非常に有効に働きます. また, コンパイルプロセスの大部分は CPU の処理ではなく入出力の処理に費やされるため, 単一の CPU を持つマシンでも同じように有効です. 単一の CPU を持つ典型的なマシンでは, 次のように実行します. &prompt.root; make -j4 target この時 &man.make.1; は, 最大 4 個までのプロセスを同時に実行します. メーリングリストに投稿された経験的な報告によると, 4 個という指定が最も良いパフォーマンスを示すようです. もし, 複数の CPU を備えたマシンで SMP 設定が行なわれたカーネルを 利用しているなら, 6 から 10 の間の値を設定し, 速度がどれくらい 向上するか確認してみて下さい. 注意して欲しいのですが, (この原稿を書いている時点では)この機能はまだ 実験段階です. そのため, ソースツリーへ変更が加えられたときに これが正常に機能しなくなる可能性があります. もし, このオプションを用いてシステムの構築に失敗した場合には, 障害を報告する前に, もう一度オプションを付けずに試してみて下さい. システムの構築にかかる時間 すべてが順調に進んでいたとしても, 一時間半から丸一日程度の時間がかかります. 一般的に言って, 200MHz の P6(訳注: Intel PentiumPro のこと) で 32MB 以上のメモリを搭載し, 標準的な SCSI ディスクドライブを利用していた とすると, make world の完了までに およそ一時間半の時間がかかります. この構成よりも性能が低ければ, それよりもさらに時間がかかるでしょう. <filename>/etc</filename> の更新 システムの再構築は, いくつかのディレクトリ ( 特に, /etc, や /var や /usr) において, 新規に導入されたり, 変更された設定ファイルによる ファイルの更新は行なわれません. これは, あなた自身の手や目, そして適切な &man.diff.1; の使用をによって行なわなければなりません. 単にファイルを /usr/src/etc から /etc に コピーしただけでは正常に動作させることはできません. これらのファイルには, インストールという 手順を踏まなければならないものが含まれています. /usr/src/etc ディレクトリは /etc ディレクトリにそのまま置き換えられるような コピーではないからです. また, /etc にあるべきファイルのうちで /usr/src/etc にないものもあります. 一番簡単な方法は, ファイルを新しいディレクトリにインストールしてから, 以前のものと異なっている部分を調べて更新作業を行なうことです. 既存の <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 | /usr/bin/perl -lne \ 'opendir(D,$_);@f=readdir(D);rmdir if $#f == 1;closedir(D);' これは深さ優先探索で各ディレクトリを走査し, 含まれるファイルの数が 2 個(スクリプト中の この段階の /var/tmp/root には, 本来 / 以下にあるべきファイルが すべて含まれています. 各ファイルを順に見て, 既存のファイルと異なる部分を 調べて下さい. /var/tmp/root 以下に インストールされているファイルの中には, /var/tmp/root/ と /var/tmp/root/root/ の中にある シェルスタートアップ ファイルだけですが, 他のものがあるかも知れません. (これは, あなたがこれをどの時点で読んでいるかに依存するので, もっとも簡単な方法は, 二つのファイルを比較するコマンド &man.diff.1; を使うことです. &prompt.root; diff /etc/shells /var/tmp/root/etc/shells これは, あなたの /etc/shells ファイルと 新しい /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"` <filename>/dev</filename> の更新 DEVFS もし, DEVFS を利用しているなら, この作業はおそらく必要ないでしょう. 安全のため, これはいくつかの段階に分けて行ないます. /var/tmp/root/dev/MAKEDEV を /dev にコピーします. &prompt.root; cp /var/tmp/root/dev/MAKEDEV /dev ここで, /dev のファイル一覧を記録しておきます. この一覧は, 各ファイルの許可属性, 所有者, メジャー番号, マイナー番号が 含まれている必要がありますが, タイムスタンプは含まれていてはいけません. これを行なう簡単な方法は, &man.awk.1; を使って, いくつかの情報を取り除くことです. &prompt.root; cd /dev &prompt.root; ls -l | awk '{print $1, $2, $3, $4, $5, $6, $NF}' > /var/tmp/dev.out デバイスファイルをつくり直します. &prompt.root; もう一度, ディレクトリのファイル一覧を記録します. 今回は /var/tmp/dev2.out です. この段階で, この二つのファイル一覧を調べて 作成に失敗したデバイスを探して下さい. 違いは一つもないはずなのですが, 安全のために一応チェックして下さい. &prompt.root; diff /var/tmp/dev.out /var/tmp/dev2.out 次のようなコマンドを使用し, ディスクスライスエントリを 再作成することで, ディスクスライスの矛盾を検出することができます. &prompt.root; sh MAKEDEV sd0s1 適当な組み合わせは, 環境によって異なります. <filename>/stand</filename> の更新 この段階は, 完全な更新を行なう場合にだけ必要な内容を含んでいます. 悪影響はありませんので, 省略しても構いません. 完全な更新を行なうために, /stand にあるファイルも同じように 更新したいと考えるかも知れません. これらのファイルは, /stand/sysinstall という バイナリファイルへのハードリンクです. このバイナリファイルは, 他のファイルシステム(特に /usr)が マウントされていない場合にも動作できるよう, 静的にリンクされていなければなりません. &prompt.root; cd /usr/src/release/sysinstall &prompt.root; make all install 1998 年 4 月 2 日以前のソースの場合 もし, 1998 年 4 月 2 日より古いソースコードを使っているか, Makefile のバージョンが 1.68 以降(FreeBSD-CURRENT および FreeBSD-3.X の場合), 1.48.2.21 以降(FreeBSD-2.2.X の場合)でなければ, 次のように NOSHARED=yes オプションを追加する必要があります. &prompt.root; make NOSHARED=yes all install 新しいカーネルのコンパイルとインストール 新しいシステムにおけるアドバンテージを完全に得るために, カーネルの再コンパイルをすべきです. 再コンパイルは, ある種のメモリ構造が変更された時には必須です. その場合, &man.ps.1; や &man.top.1; のようなプログラムは, カーネルとソースコードのバージョンが一致しないと 正常に動作しないでしょう. 新しい kernel をコンパイルするには, FreeBSD ハンドブックの指示にしたがってください. 過去に自分で設定したカーネルを構築している場合には, LINT コンフィグレーションファイルを注意深く調べて, 利用できる新しいオプションがあるかどうか確かめて下さい. この文書の以前の版では, カーネルの再構築の前に再起動することを推奨していました. これは以下の点で誤りです. &man.ps.1;, や &man.ifconfig.8;, &man.sysctl.8; といったコマンドが動作しなくなる恐れがあります. そうなると, マシンがネットワークに接続できなくなってしまいます. &man.mount.8; のような基本的なユーティリティが機能しなくなり, / や /usr 等を マウントできなくなってしまうかも知れません. これは, -STABLE の候補を追いかけている場合には あまり発生することはありませんが, -CURRENT を追いかけていて, 大規模なマージが行なわれている間には良く起こります. ローダブルカーネルモジュール (FreeBSD-3.X 以前は LKM と呼ばれていましたが, FreeBSD-3.X 以降は KLD と呼んでいます)は world の一部として 構築されるため, 古いカーネルがクラッシュする可能性があります. これらの理由から, どんな場合においても, 再起動する前に新しいカーネルを再構築し, インストールすることが 最も良い手順になります. 新しいカーネルは, make world (あるいは make installworld) が完了した後で 構築しなければなりません. もし, そうしない場合には (おそらく, あなたはシステムを更新する前にカーネルが構築されることを 確認したいのでしょう) 問題が起こるかも知れません. それは, カーネルソースに対して &man.config.8; コマンドが古いことが原因です. その場合には, 新しいバージョンの &man.config.8; でカーネルを構築することができます. &prompt.root; /usr/obj/usr/src/usr.sbin/config/config KERNELNAME これは, いつもうまく行くとは限りませんので, 新しいをカーネルをコンパイルする前に make world (あるいは make installworld)を完了させることが推奨されています. これで, 作業はおしまいです. すべてがあるべき正しい場所に存在することをチェックしたら, システムを再起動します. これは, 単に &man.fastboot.8; を実行するだけです. </para> <screen>&prompt.root; <userinput>fastboot</userinput></screen> </sect2> <sect2> <title>作業の完了 ここまで来れば, FreeBSD システムのアップグレードは成功です. おめでとうございます. さて, この時点で, 今までの間違った操作による小さな問題に 気付くことがあるかも知れません. たとえば, 私はかつて /etc/magic をアップグレードの途中で削除し, そのまま /etc にマージしてしまったことがあります. その結果, file コマンドは動作しなくなってしまったのです. すぐに思いついたのは, これを修復するには &prompt.root; cd /usr/src/usr.bin/file &prompt.root; だけで十分ではないか, ということでした. <qandaentry> <question> <para>変更が行なわれたら, その度にシステムの再構築が必要になるのでしょうか?</para> </question> <answer> <para> それは変更の性質によるので, なんとも言えません. 例えば, CVSup を実行したとき, 最後に実行したときから比べて 次にあげるようなファイルが更新されていたとします.</para> <screen><filename>src/games/cribbage/instr.c</filename> <filename>src/games/sail/pl_main.c</filename> <filename>src/release/sysinstall/config.c</filename> <filename>src/release/sysinstall/media.c</filename> <filename>src/share/mk/bsd.port.mk</filename></screen> <para> このときには, 改めてシステムを再構築する必要はありません. わたしなら, 適切なサブディレクトリに移って <command>make all install</command> を行うと思います. しかし, もし何らかの大きな変更が行なわれているとき, 例えば <filename>src/lib/libc/stdlib</filename> が変更されている場合には, システムを再構築するか, もしくはそのうち, 少なくとも静的にリンクされているもの(と, わたしが追加した 他のプログラムのうち, 静的にリンクされたもの)を 作り直すことでしょう. </para> <para>結局のところ, どの時点で現在のシステムをアップグレードするかは あなたが決めることです. 2 週間ごとにシステムを再構築し, その 2 週間の変更を取り込めば 幸せかもしれませんし, 変更のあった部分だけ再構築し, 依存関係を確かめたいと考えるかも知れません. <!-- hrs:2000/02/15 What's "every fortnight say"? s/say/day/? --> </para> <para> もちろん, それらはどのくらいの頻度でアップグレードしたいか, そして -STABLE か -CURRENT のどちらを追いかけているのかによります. </para> </answer> </qandaentry> <qandaentry> <question> <para>signal 12(もしくは他のシグナル番号)のエラーがたくさん出て コンパイルが失敗します. 何が起こっているんでしょうか?</para> </question> <answer> <para> これは通常, ハードウェアに問題があることを示しています. システムの再構築は, ハードウェアに対する負荷耐久試験を行なうための 有効な手段の一つで, メモリに関係する問題がよく報告されます. その大部分は, コンパイラが奇妙なシグナルを受け取り, 不可解な異常終了となることで発見されます. </para> <para> 本当にこの問題によるものかどうかは, 再構築をもう一度実行し, 異なる段階で異常終了が発生するか, ということから確認できます. </para> <para> この場合には, マシンの部品を交換して, どの部分が悪いのかを 調べてみることくらいしかできることはありません. </para> </answer> </qandaentry> <qandaentry> <question> <para>終了したら <filename>/usr/obj</filename> を削除しても かまいませんか?</para> </question> <answer> <para> それはあなたが次の機会に, システムの再構築をどう行なうつもりなのかによります. </para> <para><filename>/usr/obj</filename> には, コンパイルの段階で生成された すべてのオブジェクトファイルが含まれています. 通常 <quote/make world/ の最初の段階では, このディレクトリを削除して新しくつくり直すようになっています. その場合には, 構築終了後の <filename>/usr/obj</filename> を保存しておいても, あまり意味はありません. 削除すれば, 大きなディスクスペースを (現在はだいたい 150MB あります) 解放することができます. </para> <para> しかし, もしあなたが何を行なおうとしているのか理解しているなら, この段階を省略して <quote/make world/ を行なうことができます. こうすると, ほとんどのソースは再コンパイルされないため, 構築はかなり高速化されます. これは裏をかえせば, デリケートな依存関係の問題によって, システムの構築が奇妙な失敗に終わる可能性があるということです. FreeBSD メーリングリストではしばしば, 構築の失敗が, この段階の省略によるものだということを理解せずに 不満の声をあげる人がいます. </para> <para> もし, このような危険を承知した上でシステムの再構築を行なう場合には, 次のように変数 <makevar>NOCLEAN</makevar> を定義して構築します. </para> <screen>&prompt.root; <userinput>make -DNOCLEAN world</userinput></screen> </answer> </qandaentry> <qandaentry> <question> <para>構築を中断した場合, その構築を途中から再開することはできますか?</para> </question> <answer> <para> それは, あなたが問題に気付く前に, どれだけの作業を終えているかによって変わります. </para> <para><emphasis>一般的に</emphasis> (そしてこれは確実でしっかりした 規則ではありませんが), <quote>make world</quote> の過程では, 基本的なツール ( &man.gcc.1;, や &man.make.1; のようなもの) や, システムライブラリの新しいコピーが作成されます. その後まず, これらのツールやライブラリはインストールされてから 自分自身の再構築に使われ, もう一度, インストールされます. 全体のシステム (ここでは &man.ls.1; や &man.grep.1; といった 標準的なユーザプログラムを含みます) は, その新しいシステムファイルを用いて作り直されることになります. </para> <para> もし, 再構築が最終段階に入っていること が(記録しておいた出力を見たりすることで)わかっていたら, (全く悪影響を与えることなく)次のようにすることができます, </para> <screen><emphasis>… fix the problem …</emphasis> &prompt.root; <userinput>cd /usr/src</userinput> &prompt.root; <userinput>make -DNOCLEAN all</userinput></screen> <para> これは, 前回の <quote>make world</quote> の作業をやり直しません. </para> <para>次のメッセージ <screen>-------------------------------------------------------------- Building everything.. --------------------------------------------------------------</screen> が <quote>make world</quote> の出力にある場合には, 上のようにしてもほとんど悪影響が現れることはありません. </para> <para> もしこのメッセージがないとか, よく分からないという場合には, 安全を確保し, 後悔するようなことがないよう, システムの再構築を最初からやり直しましょう. </para> </answer> </qandaentry> <qandaentry> <question> <para>あるマシンを <emphasis/マスタ/ として, 他の多くのマシンを (NFSで) アップグレードできますか?</para> </question> <answer> <para>すべてのコンパイル作業をあるマシンで行ない, 構築されたものを他のマシンにネットワークを経由で <command>make install</command> することができるかどうかは, よく FreeBSD メーリングリストで尋ねられます. </para> <para>これはわたしが行った作業ではありませんので, 下に書かれている提案は, 他の人々から頂いたか, Makefile から推論したものです.</para> <para>取るべき適切な方法については, 利用している FreeBSD のバージョンに依存します.</para> <para> アップグレードしたマシンでは, この作業を行った後に <filename>/etc</filename> や <filename>/dev</filename> の 更新を行わなくてはなりません.</para> <para>2.1.7 とそれより古いものについて, Antonio Bemfica は 次に示すような方法を教えてくれました. </para> <screen>Date: Thu, 20 Feb 1997 14:05:01 -0400 (AST) From: Antonio Bemfica <bemfica@militzer.me.tuns.ca> To: freebsd-questions@FreeBSD.org Message-ID: <Pine.BSI.3.94.970220135725.245C-100000@militzer.me.tuns.ca> Josef Karthauser は質問しました: > どなたかネットワークを通してマシンをアップグレードするよい方法は知りませんか まず, メインとなるマシンで make world などをします. そして次のように, リモートのマシンから / や /usr をマウントします: main_machine% mount remote_machine:/ /mnt main_machine% mount remote_machine:/usr /mnt/usr そして, /mnt をインストール先に指定して 'make install' とします: main_machine% make install DESTDIR=/mnt これをネットワーク上の他のマシンについても繰り返してください. わたしの場合には, これでうまくいきました. Antonio</screen> <para>この仕組みは (わたしの知る限り) NFS サーバ上の <filename>/usr/src</filename> が書き込み可能である場合にのみ きちんと動作します. FreeBSD-2.1.7 とそれ以前では, この作業に <maketarget>install</maketarget> ターゲットを使います. </para> <para>FreeBSD-2.1.7 と FreeBSD-2.2.0 の間で <quote>reinstall</quote> ターゲットが導入されました. 上にあげた FreeBSD-2.1.7 向けの方法に加え, <quote>install</quote> の代わりに <quote>reinstall</quote> を 使うことができます. </para> <para>この方法では, NFS サーバ上の <filename>/usr/src</filename> ディレクトリへの書き込み権限は必要 <emphasis>ありません</emphasis>.</para> <para>Makefile の 1.68 から 1.107 の間のバージョンには, このターゲットに関するバグがありました. それは NFS サーバへの書き込み権限が <emphasis>必要になる</emphasis> というもので, このバグは FreeBSD-2.2.0 がリリースされる前に修正されました. この時期の -STABLE が動いている古いサーバでは, 問題になるかも知れません. </para> <para>FreeBSD-2.2.5 以降のバージョンでは, <quote>buildworld</quote> と <quote>installworld</quote> ターゲットが利用できます. これらを使ってソースツリーを一つのマシンで構築し, <filename>/usr/src</filename> と <filename>/usr/obj</filename> をリモートマシンで NFS マウントして, そこからインストールすることができます.</para> </answer> </qandaentry> <qandaentry> <question> <para>どのようにすれば make world を高速化できますか?</para> <itemizedlist> <listitem> <para>シングルユーザモードで動かしてください.</para> </listitem> <listitem> <para><filename>/usr/src</filename> と <filename>/usr/obj</filename> ディレクトリを, 異なるディスク上の別のファイルシステムに置いてください. また可能ならば, 異なるディスクコントローラに接続された ディスクを使って下さい. </para> </listitem> <listitem> <para>さらに高速化するには, これらのファイルシステムを <quote>ccd</quote> (連結ディスクドライバ) デバイスを 使って, 別々なディスク上に置いてください.</para> </listitem> <listitem> <para>プロファイル版の作成を無効化して下さい. (<filename>/etc/make.conf</filename> で <quote>NOPROFILE=true</quote> をセットします) 普通, それが必要になることはありません. </para> </listitem> <listitem> <para>また, <filename>/etc/make.conf</filename> の中の <quote>CFLAGS</quote> を, <quote>-O -pipe</quote> のように指定しましょう. <quote>-O2</quote> の最適化はさらに多くの時間を必要とし, しかも <quote>-O</quote> と <quote>-O2</quote> の 最適化には, ほtんど差はありません. <quote>-pipe</quote> を指定することで, コンパイラはテンポラリファイルの代わりにパイプを利用します. その結果, (メモリの利用は増えますが)ディスクアクセスが減ります. </para> </listitem> <listitem> <para>(もしあなたが十分に最近のバージョンの FreeBSD を使っているなら) 複数のプロセスを並列に実行させるため, make に <option>-j<n></option> オプションを指定してください. これはプロセッサが単一か複数かによらず, どちらも同様に恩恵を得ることができます.</para> </listitem> <listitem><para><filename>/usr/src</filename> のある ファイルシステムを, <quote>noatime</quote> オプションを付けてマウント(もしくは再マウント)してください. これは, そのファイルシステムにおいて, 最後にアクセスされた時刻の書き込みを抑制します. おそらく, この情報が必要になることはないでしょう.</para> <note> <para><quote>noatime</quote> が利用可能なのは, FreeBSD-2.2.0 以降です.</para> </note> <screen>&prompt.root; <userinput>mount -u -o noatime /usr/src</userinput></screen> <warning> <para>上の例は, <filename>/usr/src</filename> 自身が独立したファイルシステムで あることを想定しています. もしそうでないときには (例えば <filename>/usr</filename> の 一部である場合には), <filename>/usr/src</filename> ではなく 適切なマウントポイントを指定する必要があります. </para> </warning> </listitem> <listitem> <para><filename>/usr/obj</filename> のあるファイルシステムを, <quote>async</quote> オプションをつけてマウント (もしくは 再マウント) してください. これによって, ディスクへの書き込みが非同期になります. つまり, 書き込み命令はすぐに完了するのに対し, 実際にデータがディスクに書き込まれるのは, その数秒後になります. これによって, 書き込み処理の一括化が可能になるため, 劇的なパフォーマンスの向上が期待できます. <!-- hrs:2000/02/15 (for ja-translators) "be clusterd togather" is translated into "clusterization" --> </para> <warning> <para> このオプションを指定すると, ファイルシステムは 壊れやすくなってしまうことに注意してください. このオプションを付けていて, 突然電源が落ちた場合には, 再起動後にファイルシステムが復旧不能になる可能性が 非常に高くなります. </para> <para>もし, <filename>/usr/obj</filename> 自身が独立した ファイルシステムであるならば, これは問題になりません. しかし, 同じファイルシステムに, 他の貴重なデータを置いているときには, このオプションを有効にする前に, バックアップをきちんと取っておきましょう.</para> </warning> <screen>&prompt.root; <userinput>mount -u -o async /usr/obj</userinput></screen> <warning> <para>もし <filename>/usr/obj</filename> 自身が ファイルシステムでない場合には, 適切なマウントポイントを指すように, 上の例の名前を置き換えて下さい. </para> </warning> </listitem> </itemizedlist> </question> </qandaentry> </qandaset> </sect2> </sect1> </chapter> <!-- Local Variables: mode: sgml sgml-declaration: "../chapter.decl" sgml-indent-data: t sgml-omittag: nil sgml-always-quote-attributes: t sgml-parent-document: ("../book.sgml" "part" "chapter") End: --> diff --git a/ja_JP.eucJP/books/handbook/policies/chapter.sgml b/ja_JP.eucJP/books/handbook/policies/chapter.sgml index 702d9f2db8..0ede93bc81 100644 --- a/ja_JP.eucJP/books/handbook/policies/chapter.sgml +++ b/ja_JP.eucJP/books/handbook/policies/chapter.sgml @@ -1,480 +1,480 @@ <!-- The FreeBSD Documentation Project The FreeBSD Japanese Documentation Project - Original revision: 1.14 - $FreeBSD: doc/ja_JP.eucJP/books/handbook/policies/chapter.sgml,v 1.6 1999/11/13 15:35:01 kuriyama Exp $ + Original revision: 1.17 + $FreeBSD: doc/ja_JP.eucJP/books/handbook/policies/chapter.sgml,v 1.7 2000/01/06 03:44:46 kuriyama Exp $ --> <chapter id="policies"> <title>ソースツリーのガイドラインおよび方針 原作: &a.phk;. 訳者: &a.jp.mihoko; 6 September 1996 . 本章は, FreeBSD のソースツリーについてのさまざまなガイドラインや ポリシーについて書かれています. Makefile 中の <makevar>MAINTAINER</makevar> 1996年6月. FreeBSD 配布物の特定の部分が, 一人の人やグループによって保守 されている場合は, ソースツリーの当該 Makefile に MAINTAINER= email-addresses が付け加えられています. これを記述することによって, この部分が誰 に保守管理されているかを世界中のユーザに 伝えることができます. この意味は次のとおりです: 保守担当者がそのコードを所有し, そのコードに対する責任を持っ ています. すなわち, その人がそのコードに関するバグの修正やトラブル報告 に対する回答をします. また, そのコードが寄贈ソフトウェアの場合には, そのソフトウェアの 新しいバージョンに適切に追従させる作業をその人が行い ます. 保守担当者が決められているディレクトリに対して 変更をおこなう場合は, 変更をおこなう前に, その変更内容を保守担当者に送って, 保守担当者にレビューをしてもらってください. 保守担当者が, 電子メールに一定期間応答しない場合にのみ, 保守担当者がレビューすることなしに, 変更をおこなうことが認められます. しかしながら, そのような場合でも可能な限り, 変更点を第三者にレビュー してもらうようにしてください. もちろん, この義務を引き受けることができない人やグループを 保守管理者として追加することはできません. また, 保守管理者がソースツリー管理者 ("committer") である必要は ありません. - + 寄贈ソフトウェア 原作: &a.phk; and &a.obrien;. 訳者: &a.jp.mihoko; 1996年6月. FreeBSD 配布物のうちのいくつかのソフトウェアは FreeBSD プロジェクト 以外のところで保守されています. 歴史的な経緯から, 私たちはこれを 寄贈 ソフトウェアと 呼んでいます. perl や gcc, patch などがその例です. ここ数年来, この種のソフトウェアの取り扱いには, さまざまな方法が 取られてきましたが, どの方法にもいくつかの利点と欠点があります. これまで欠点のない明確な方法はありませんでした. 議論した結果, これらの方法のうちの一つが - “公式な”方法として選択され ました. その方法が, 今後, + 公式な方法として選択され ました. その方法が, 今後, この種のソフトウェアを取り込む場合に, 使用 されます. その上, この方法では, だれもが(cvs - にアクセス権のない人でさえ)“公式” + にアクセス権のない人でさえ)公式 バージョンのソースに対する差分を簡単に得ることができます. これは古い方法にはなかった大きな利点です. ですから, 既存の寄贈ソフトウェアも, この方法に収束していくことを強く望んでいます. この方法を使用することにより, 寄贈ソフトウェアの主な開発者に, 変更 点を返すのがとても容易になります. しかしながら結局, 寄贈ソフトウェアの取扱は, 実際に作業を行って いる人々に委ねられています. もしこの方法を使用することが, その人が扱っているパッケージには 極端に合わないような場合には, コアチームの承認さえあれば, これらの ルールに反しても, 他の開発者の一般的な合意は得られるでしょう. 将来にわたってパッケージを保守できるということは, 大変重要な事柄に なってきます. RCS のファイルフォーマットと CVS のベンダブランチの使用には不幸な設計上の制限があります. したがって, ベンダブランチの内容をいまだに引きずっているファイルに 対して小さな, 些細な変更, そして / あるいは 膨大な変更を加えることには, 強い反対があります. - “誤字訂正”はもちろんこの中に入りますし, - しかも“膨大な”の範疇に入るので, リビジョンが + しかも膨大なの範疇に入るので, リビジョンが 1.1.x.x であるファイルに対する誤字訂正は避けられることになっています. 一文字の変更したことによるリポジトリの肥大は, 非常に劇的なものになり得るのです. - プログラミング言語 Tcl は, + プログラミング言語 TCL は, この方法が活用されているよい例になっています: src/contrib/tcl には, このパッケージの保守管理者が 配布したソースが含まれています. この中からは FreeBSD に完全には適用 できない部分が削除されています. Tcl の場合は, mac, win, compat というサブディレクトリは, FreeBSD に取り込む前に削除されて いました. src/lib/libtcl には, ライブラリを生成したり, ドキュ メントをインストールする際に使用される, 標準の bsd.lib.mk の 規則を使用した「bmake スタイル」の Makefile だけが 含まれています. src/usr.bin/tclsh には, bsd.prog.mk 規則 を使用して, tclsh プログラムや関連するマニュアルページを生成 /インストール する bmake スタイルの Makefile だけが含まれています. src/tools/tools/tcl_bmake には, tcl ソフトウェアを更新する必要が生じたときの助けになる2つのシェルス クリプトが含まれています. これらは, ソフトウェアを構築するのに使用し たり, インストール対象になるソフトウェアではありません. ここ重要なのは, src/contrib/tcl ディレクトリが, 規則にしたがっ て作られているということです. つまり, できるだけ FreeBSD に特化した 変更をおこなわないようにしたソースを(RCS のキーワードを拡張しないで, CVS のベンダブランチに)おくようにし ています. freefall 上の「簡易取り込み」ツールは, 寄贈ソフトウェアを取り込む 手助けとなります. けれども, このツールの実行方法に疑問が生じた場合は, まずはじめに質問して, 失敗をしないようにしてください. そして, - その疑問を“解決して”からツールを使用してください. + その疑問を解決してからツールを使用してください. CVS に寄贈ソフトウェアを取り込む際には, 事故があってはいけません. よくあるような間違いをおかさないように, 十分注意してください. 先ほど述べたように, 残念なことに CVS にはベンダブランチという設計制限があります. このため, CVS に寄贈ソフトウェアを取り込むには, オリジナル配布ソースに - 適用されるベンダからの“公式”パッチと, + 適用されるベンダからの公式パッチと, ベンダブランチに逆輸入された 結果が必要です. ベンダブランチの一貫性を破壊したり, 将来, 新しいバージョンを取り込む 時に衝突を起こしてしまったりというような 困難な事態に陥らないように しなければなりません. そのために, FreeBSD が管理しているバージョンに 対して, 公式パッチを決して当ててはいけませんし, 公式パッチを "commit" してはいけません. 多くのパッケージが, 他のアーキテクチャや他の環境と FreeBSD との互換性を保ためのファイルをいくつか含んでいます. そこで, スペースを節約するために, FreeBSD にとっては無意味な配布ツリー上の一 部を削除することが許されています. けれども, 削除されずに残ったファイルに対する, 著作権の通知やリリース ノートのような情報を含んだファイルは, 決して削除しては いけませ ん . bmake Makefile が何らかのユーティリティによって, 配布ツリー から自動的に生成できると, うまくいけば, 新しいバージョンへの アップグレードをより簡単におこなうことができます. もしこのようなユーティリティを作成できた場合には, 将来の管理者に とって便利になるように, 移植の際に, src/tools ディレクトリ上に, (必要に応じて) そのユーティリティを必ずチェックインしてください. src/contrib/tcl レベルのディレクトリには, FREEBSD-upgrade と 呼ばれるファイルが追加されており, そのファイルでは 次のような内容が 記述されています. ディレクトリ上に存在するファイル オリジナルの配布物をどこから入手すればよいか また, 公式配布 サイトはどこか オリジナルの作者にパッチを送り返すためには, どこに送ればよいか FreeBSD に特化した変更点の概要 しかしながら, 寄贈ソースと一緒に FREEBSD-upgrade ファイルを 取り込まないでください. それよりむしろ, (訳注:このファイルを)初回に取り込んだ後は, コマンド cvs add FREEBSD-upgrade ; cvs ci を実行してください. src/contrib/cpio を例にすると, 次のようになります: このディレクトリは「ベンダ」ブランチ上のオリジナル配布ファイル の初期ソースが含まれています. いかなる事情があっても, パッチや cvs コミットによってこのディレクトリ上のファイルを アップグレードしてはいけません. (訳注:ベンダから配布された)新しいバージョンや公式パッチだけが (訳注:このディレクトリに)取り込まれなくてはいけません. ベンダの RCS Id が CVS に入ってしまうのを避けるために, "-ko" オプ ションをつけてインポートすることを忘れないで下さい. GNU cpio 2.4.2 を取り込むためには, 以下のファイルが削除されました: INSTALL cpio.info mkdir.c Makefile.in cpio.texi mkinstalldirs cpio を新しいバージョンにアップデートするためには, 次の作業を おこないます: 1. 空のディレクトリに新しいバージョンを取り出します. [ファイルに「いかなる変更」も加えてはいけません] 2. 上記にリストされたファイルと, FreeBSD には無意味な ファイルを削除します. 3. 次のコマンドを実行します: cvs import -ko -m 'Virgin import of GNU cpio v<version>' \ src/contrib/cpio GNU v<version> 例えば, バージョン 2.4.2 を取り込むためには, 次のように タイプします: cvs import -ko -m 'Virgin import of GNU v2.4.2' \ src/contrib/cpio GNU v2.4.2 4. FreeBSD に対するローカルな変更と, 新しいバージョンとの間での 矛盾を解消するために, ステップ 3 で出力された命令を実行します. いかなる事情があっても, この手順から外れてはいけません. cpio にローカルな変更を加えたい場合には, メインブランチ(別名 HEAD)に対して パッチを実行し, コミットしてください. 決して GNU のブランチにローカルな変更を加えないでください. ローカルにおこなわれたすべての変更を次のリリースに含めるために, "cpio@gnu.ai.mit.edu" に提出してください. obrien@FreeBSD.org - 30 March 1997 ソース管理上注意が必要なファイル (Encumbered files) 場合によっては FreeBSD のソースツリーの中にソース管理上 注意が必要なファイルを含む必要があるかも知れません. 例えば, デバイス を操作する前に, そのデバイスに小さなバイナリコードをダウンロード する必要があり, しかも我々が そのソースコードを持っていない場合, そのバイナリファイルのことをソース管理上注意が必要である(encumbered) と言います. 以下に挙げるガイドラインでは, ソース管理上注意が必要なファイルを FreeBSD ソースツリーにいれる方法を示します. システムのCPU(s)によってインタプリタされたり 実行されたりするファイルで, しかもソース形式でないファイルは すべて, ソース管理上注意が必要なファイルです. BSD または GNU よりも制限されたライセンスを持つファイルは すべて ソース管理上注意が必要なファイルです. ハードウェアによって使用されるダウンロード可能な バイナリコードを含むファイルは, (1) または (2) の条件が 当てはまらなければ, ソース管理上注意が必要なファイル ではありません. そのようなファイルはアーキテクチュアに依存しない ASCII 形式(file2c または uuencode が推奨されます)で保存 します. ソース管理上注意が必要なファイルはすべて, CVS リポジトリ に加える前に, Core team からの特別な承認 が必要です. ソース管理上注意が必要なファイルは src/contrib または src/sys/contrib に入ります. すべてのモジュールは一緒に置きます. ソース管理上とくに注意 を必要としないコードとコードを共有していない限りは, モジュールの置場を分ける必要はありません. オブジェクトファイルは arch/filename.o.uu> と命名されます. カーネルファイル; 必ず conf/files.* (構築を簡単にするため ) に記述するようにして下さい. 必ず LINT に記述して下さい, ただし, それをコメントアウトすべきかどうかは Core team がその都度 判断します. もちろん Core team は あとでそれを変更することもできます. リリースエンジニア は, それをそのリリースにいれるかどうかを決定します. ユーザ領域のファイル; Core team は, そ のコードが make world の中で構築される べきかどうかを決定します. リリースエンジニア は, それをそのリリースにいれるかどうかを決定します. 共有ライブラリ Contributed by &a.asami;, &a.peter;, and &a.obrien;. 9 December 1996. もしあなたが共有ライブラリをサポートする機能を port に追加した り, 共有ライブラリをサポートしていない他のソフトウェアに追加する 場合には, 共有ライブラリのバージョン番号を次の規則にしたがって つけてください. 一般的には, この規則は, ソフトウェアのリリースバージョンとは 全く関係ありません. 共有ライブラリを作成する三つの重要な規則は 次の通りです: 1.0 から始める 過去のバージョンに互換性のある変更の場合は, マイナー番号を増やす(ELF システムでは マイナー番号が無視されることに注意して下さい) 互換性のない変更の場合は, メジャー番号を増やす 例えば, 機能追加とバグ吸収の場合は, マイナー番号を増やします. 機能削除, 関数呼び出しのシンタックスなどが変更された場合は, 強制的にメジャー番号を変更します. メジャー.マイナーー (x,y) の形式のバージョン番号を使用します. FreeBSD における a.out 形式のダイナミックリンカは, x.y.z という形式のバージョン番号 は扱えません. この場合, y の後のバージョン番号 (つまり三つ目の数字)は, どのライブラリがリンクされているかを決めるために, 共有ライブラ リ番号を比較する際に, すべて無視されます. - “小さな”リビジョンだけが + 小さなリビジョンだけが 異なる二つの共有ライブラリが指定 されると, ld.so は, リビジョンの大きい方の共有ライブラリを リンクします. すなわち, もしあなたが libfoo.so.3.3.3 をリンク していたとすると, リンカは頭の 3.3 という部分だけを認識し, libfoo.so.3 ではじまり その後に 3 以上の数字が続くもののうち, 最も大きい番号 の付いているライブラリをリンクします. ld.so はいつも最も大きい - “マイナー” リビジョンのものを使うことに + マイナー リビジョンのものを使うことに 注意してください. 例えば, プログラムがはじめ libc.so.2.0 を リンクしていたとしても, libc.so.2.0 よりも libc.so.2.2 を優先して使用します. さらに, ELF ダイナミックリンカはマイナーバージョンを全く扱いません. しかし, 作成した Makefile がそのようなシステムでも 「きちんと動作できる」ように, メジャー番号およびマイナー番号を 指定する必要があります. 移植されていないライブラリに対しては, 共有ライブラリのバージョン番号はリリースごとに一度だけ変更し, また, 主要な共有ライブラリのバージョン番号は, OS の主リリースごとに 一度だけ変更する, というのが私たちのポリシーです. つまり, X.0 は (X+1).0 になります. あなたがシステムライブラリのバージョン番号を上げた場合は, Makefile の commit ログを確認してください. 結果としてそのリリースには, 共有ライブラリのバージョン番号が アップデートされた Makefile に入るので, 最初にその変更を 確かめるのがソースツリー管理者 ("committer") の責務です. その後のどんな変更も, そのリリースには入りません.