diff --git a/ja_JP.eucJP/books/handbook/boot/chapter.sgml b/ja_JP.eucJP/books/handbook/boot/chapter.sgml
index 25208a1fd1..1ddb823e13 100644
--- a/ja_JP.eucJP/books/handbook/boot/chapter.sgml
+++ b/ja_JP.eucJP/books/handbook/boot/chapter.sgml
@@ -1,873 +1,873 @@
FreeBSD の起動のプロセス
この章では
起動
ブートストラップ (bootstrap)
計算機を起動しオペレーティングシステムをロードするプロセスは、
ブートストラッププロセス
、
もしくは単に 起動
と呼ばれます。
FreeBSD の起動プロセスを使えば、
システムをスタートするときに起きることを
かなり柔軟にカスタマイズすることができます。
同じ計算機にインストールされた
別のオペレーティングシステムを選択することもできますし、
同じオペレーティングシステムの違うバージョンを選択することも、
インストールされた別のカーネルを選択することさえできます。
この章では、指定できる設定オプションと FreeBSD
の起動プロセスのカスタマイズ方法について詳しく述べます。
この章では FreeBSD カーネルがスタートし、デバイスを検出し、
&man.init.8; を起動するまでに起きることすべてを扱います。
どの最中のことだかはっきりしていない人のために補足すると、
テキストの色が明るい白から灰色に変わるまでに起きていることです。
この章を読むと、以下のことが分かります。
どのように FreeBSD のブートストラップシステムが構成され、
そしてそれらが互いにどう関係しているのか
起動プロセスを制御するために FreeBSD
のブートストラップの各要素に付加できるオプション
&man.device.hints.5; の基本的な記述方法
x86 限定
この章では Intel x86 システム上で動作する FreeBSD
の起動プロセスだけを扱います。
起動時の問題
計算機の電源を入れ、オペレーティングシステムをスタートさせるのには、
おもしろいジレンマがあります。
定義により、計算機は
オペレーティングシステムがスタートするまで何もする方法を知りません。
ディスクからプログラムを動かすのも含みます。
では、計算機はオペレーティングシステムなしに
ディスクからプログラムを実行することができず、
オペレーティングシステムのプログラムがディスク上にあるのなら、
どうやってオペレーティングシステムをスタートさせるのでしょう?
この問題はほらふき男爵の冒険という本の中に
書かれている問題ととてもよく似ています。
登場人物がマンホールの下に半分落っこちて、
靴紐 (ブートストラップ) をつかんで自分を引っぱり、持ち上げるのです。
計算機の黎明期には、ブートストラップ
という用語でオペレーティングシステムをロードする
機構のことを指していたのですが、
いまは短く 起動 (ブート)
と言います。
x86 ハードウェアでは、基本入出力システム
(Basic Input/Output System: BIOS)
にオペレーティングシステムをロードする責任があります。
オペレーティングシステムをロードするために、
BIOS がハードディスク上のマスターブートレコード
(Master Boot Record: MBR)
を探します。
MBR はハードディスク上の特定の場所になければなりません。
BIOS には MBR をロードし起動するのに十分な知識があり、
オペレーティングシステムをロードするために必要な作業の残りは
MBR が実行できることを仮定しています。
BIOS
基本入出力システム (Basic Input/Output System)
BIOS
ディスク上にオペレーティングシステムを一つだけ
インストールしているなら、標準の MBR で十分です。
この MBR はディスク上の最初の起動可能なスライスを探し、
そのスライスにあるコードを起動して
残りのオペレーティングシステムをロードします。
ディスク上にオペレーティングシステムを複数インストールしているなら、
別の MBR —
複数のオペレーティングシステムのリストを表示できて、
起動するオペレーティングシステムを選択できるような MBR —
をインストールすることができます。
FreeBSD はそのような MBR とともに配布されており、
この MBR をインストールすることもできます。
他のオペレーティングシステムのベンダも
標準 MBR に代わる MBR を提供しています。
FreeBSD ブートストラップシステムの残りは 3 段階に分かれます。
第 1 ステージは MBR によって起動されるもので、
MBR は計算機を特定の状態にするために必要なことだけ知っていて、
第 2 ステージを起動します。
第 2 ステージでは、第 3 ステージを起動する前に、
もうちょっとやることができます。
第 3 ステージでオペレーティングシステムのロード作業を完了します。
起動作業がこれらの 3 段階に分かれているのは、
PC の規格がステージ 1 とステージ 2
で実行できるプログラムのサイズに制限を課しているからです。
これらの作業をつなぎ合わせることによって、
FreeBSD はより柔軟なローダ (loader) を提供しているのです。
カーネル (kernel)
init
その後カーネルが起動し、デバイスの検出と初期化を開始します。
そしてカーネルの起動が終わると、制御はユーザープロセスの
&man.init.8; へ移されます。&man.init.8; はまず
ディスクが利用可能であることを確かめ、
ファイルシステムのマウント、
ネットワークで利用するネットワークカードのセットアップ、
そして通常 FreeBSD システムで初期時に起動されるすべてのプロセスの起動、
といったユーザーレベルでのリソース (資源) 設定を行ないます。
MBR、起動ステージ 1、2 および 3
MBR、<filename>/boot/boot0</filename>
マスターブートレコード (MBR)
FreeBSD の MBR は /boot/boot0
にあります。これは MBR のコピーであり、
本当の MBR はディスク上の特別な部分、
つまり FreeBSD 領域の外に置く必要があります。
boot0 は非常に単純なプログラムです。
これは、MBR にあるプログラムは
512 バイトの大きさでなければならないという制限があるためです。
FreeBSD の MBR をインストールし、
かつハードディスク上に複数のオペレーティングシステムをインストールした場合、
起動時にこれと同じような画面が出るでしょう。
<filename>boot0</filename> のスクリーンショット
F1 DOS
F2 FreeBSD
F3 Linux
F4 ??
F5 Drive 1
Default: F2
他のオペレーティングシステム、特に &windows; は、
既存の MBR を自らの MBR で上書きしてしまうことで知られています。
もしそうなってしまったら、
もしくは既存の MBR を FreeBSD の MBR で置き換えたいのなら、
次のコマンドを使ってください。
&prompt.root; fdisk -B -b /boot/boot0 device
device は起動するデバイス名で、
たとえば 1 番目の IDE ディスクは
ad0、
2 番目の IDE コントローラに接続されている 1 番目の IDE ディスクは
ad2、
1 番目の SCSI ディスクは
da0
などとなります。
しかしながら、もしあなたが Linux ユーザで、
LILO
で起動プロセスを制御したいのなら、
FreeBSD 用に /etc/lilo.conf を編集して、
FreeBSD のインストールの際
を選択します。
FreeBSD のブートマネジャをインストールしたのであれば、
Linux を起動し直して
LILO の設定ファイル
/etc/lilo.conf を変更し、
次のオプションを加えることができます:
other=/dev/hdXY
table=/dev/hdb
loader=/boot/chain.b
label=FreeBSD
こうすれば、LILO から
FreeBSD と Linux を起動することができます。
この例では、ドライブ番号とパーティションを示すために
XY を使っています。
SCSI ドライブを使っているのであれば、
/dev/hdXY を
/dev/sdXY のように読み替えてください。
XY の指定方法は同じです。
は同じドライブ上に両方のオペレーティングシステムを置いてあるのであれば不要です。
これで /sbin/lilo -v を実行すると
システムに新しい変更が反映されるので、
画面のメッセージを見て確認します。
起動ステージ 1 <filename>/boot/boot1</filename> と起動ステージ 2
<filename>/boot/boot2</filename>
概念上、第 1 ステージと第 2 ステージは
ハードディスクの同じ領域上の同一のプログラムの部分部分です。
スペースの制約のため 2 つに分割されていますが、
いつも一緒にインストールします。
第 1 ステージと第 2 ステージは起動スライス (slice)
の起動セクタにあります。
起動セクタとは、
MBR 上にある boot0
もしくは他のプログラムが、起動のプロセスを続けるために
必要なプログラムがあると想定している場所です。
/boot
ディレクトリにあるファイルは実際に使われるファイルのコピーで、
実際のファイルは
FreeBSD ファイルシステムの外部に格納されています。
boot1 も非常に単純なプログラムです。
これは boot0 同様に、
512 バイトの大きさでなければならないという制限があるためです。
boot1 は boot2 を検索し、
実行するため、そのスライスの情報を保持する FreeBSD
のディスクラベル (disklabel)
に関する最低限の情報を持っています。
boot2 はもう少し高機能です。
これは FreeBSDのファイルシステム上でファイルを見つける能力を持ち、
実行するカーネルやローダを指定するための
簡単なインタフェイスを提供します。
ローダ (loader)
はさらに高機能なもので、
使いやすく簡単な起動設定が行なえる手段を提供します。
boot2 は通常それを起動します。
以前の boot2 には、
カーネルを直接起動する機能しかありませんでした。
<filename>boot2</filename> のスクリーンショット
>> FreeBSD/i386 BOOT
Default: 0:ad(0,a)/kernel
boot:
もし仮にインストールされた boot1 と
boot2 を変更したいのであれば、
&man.disklabel.8; を使ってください。
&prompt.root; disklabel -B diskslice
diskslice は起動するディスクとスライスで、
たとえば最初の IDE ディスクの 1 番目のスライスは
ad0s1 となります。
Dangerously Dedicated Mode
&man.disklabel.8; を使うとき、
ad0 のようにディスク名だけを指定すると、
スライスを持たない危険な専用ディスクを作成してしまいます。
たぶん間違いなく、そうしたいわけではないでしょうから、
必ず Return キーを押す前に
&man.disklabel.8; コマンドを二重にチェックしてください。
起動ステージ 3 <filename>/boot/loader</filename>
ブートローダ (boot-loader)
ローダは三段階の起動プロセスの最終段階です。
ローダは通常、ファイルシステム上の
/boot/loader
として存在しています。
ローダは、よりさまざまなコマンド群をサポートした
強力なインタプリタによって提供される簡易組み込みコマンド群を利用することで、
ユーザが利用しやすい設定手段となるように設計されています。
ローダプログラムの処理の流れ
ローダは初期化の際にコンソールとディスクの検出を行ない、
どのディスクから起動しているかを調べます。
そして必要な変数を設定してからインタプリタを起動し、
スクリプトからコマンドを送ったり手でコマンドを入力したりできます。
ローダ
ローダの設定
ローダは次に
/boot/loader.rc
を読み込み、通常、変数の標準値を定義した
/boot/defaults/loader.conf
と、そのマシンにローカルな変数を定義した
/boot/loader.conf
を読み込みます。
loader.rc
はそれらの変数にもとづき、
選択されたモジュールとカーネルをロードします。
ローダは最後に、標準設定で 10 秒のキー入力待ち時間を用意し、
入力がなければカーネルを起動します。
入力があった場合、簡易コマンド群が使えるプロンプトが表示され、
ユーザは変数を調整したり、
すべてのモジュールをアンロードしたり、
モジュールをロードしたりすることができます。
その後、最終的な起動や再起動へ移行します。
ローダの組み込みコマンド
もっともよく使われるローダのコマンドを以下に示します。
利用可能なコマンドをすべて知りたい場合、
&man.loader.8; を参照してください。
autoboot seconds
seconds
で与えられた時間内に入力がなければ、
カーネルの起動へと進みます。
カウントダウンを表示し、標準設定では 10 秒間です。
boot
-options
kernelname
すぐにカーネルの起動へ進みます。
オプション、カーネル名が指定されている場合は、
それらが使われます。
boot-conf
すべてのモジュールの設定を、
起動時と同じように変数にもとづいて自動的に行ないます。
このコマンドは、まず unload を行なって、
変数—普通 kernel
など—を変更した場合にのみ有効に働きます。
help
topic
/boot/loader.help
を読み込み、ヘルプメッセージを表示します。
topic に
- index 指定された場合、
+ index が指定された場合、
利用可能な topic を表示します。
include filename
…
指定されたファイル名のファイルを処理します。
ローダはファイルを読み込み、行単位で解釈します。
エラーが発生した場合、
include コマンドの実行はその時点で停止します。
load
type
filename
指定されたファイル名のカーネル、
カーネルモジュール、あるいは
type に指定された種類のファイルをロードします。
ファイル名以降に指定された引数はファイルへと渡されます。
ls
path
指定された path
にあるファイルを表示します。
path
が指定されていなければ、ルートディレクトリを表示します。
が指定されていればファイルサイズも表示されます。
lsdev
モジュールがロード可能なすべてのデバイスを表示します。
もし が指定されていれば、
より詳細な出力がされます。
lsmod
ロード済みのモジュールを表示します。
が指定されていれば、
より詳細な内容が出力されます。
more filename
LINES
単位でスクロールを停止しながら指定されたファイルを表示します。
reboot
すぐにシステムを再起動します。
set variable
set
variable=value
ローダの環境変数を設定します。
unload
すべてのロード済みモジュールを削除します。
ローダの使用例
次にあげるのは、ローダの実践的な使用例です。
シングルユーザモード
普段使っているカーネルをシングルユーザモードで起動します。
boot -s
普段使っているカーネルとモジュールをアンロードし、
古い (もしくは別の) カーネルをロードします。
kernel.old
unload
load kernel.old
kernel.GENERIC とすると、
インストールディスクに入っていた
generic カーネルを指定することができます。
また、直前にインストールされていたカーネル (たとえば、
カーネルを自分で設定したり、
アップグレードしたりした場合) を指定するには
kernel.old とします。
普段のカーネルで使っているモジュールを
指定したカーネルでロードする場合は、下のようにします。
unload
set kernel="kernel.old"
boot-conf
カーネルの設定スクリプト (通常、
カーネル起動時に設定される内容を自動化するスクリプト) をロードします。
load -t userconfig_script /boot/kernel.conf
カーネル起動時の応答
カーネル (kernel)
起動時の応答
カーネルがローダ (通常は)
かboot2
(ローダを迂回して) によってロードされると、
起動フラグを調べます。
もし起動フラグがあれば、それに応じて動作を調整します。
カーネル起動フラグ
カーネル (kernel)
起動フラグ
良く使われる起動フラグは次のとおりです。
カーネル初期化中に、
ルートファイルシステムとしてマウントするデバイスを尋ねます。
CDROM から起動します。
起動時にカーネルコンフィグレーションを行なう
UserConfig を実行します。
シングルユーザモードで起動します。
カーネル起動時により詳細な情報を表示します。
起動フラグはこの他にもあります。
それらについては &man.boot.8; を参照してください。
Tom
Rhodes
寄稿:
device.hints
Device Hints
これは FreeBSD 5.0 以降の機能です。
これ以前のバージョンには存在しません。
起動プロセスの間に &man.loader.8; は
&man.device.hints.5; を読み込みます。
このファイルにはカーネル起動の環境変数が格納されており、
これらの環境変数は device hints
と呼ばれることがあります。
device hints
はデバイスを設定するために
デバイスドライバが使用します。
device hints は ステージ 3 ブートローダ
でも設定できます。device hints は
set コマンドを用いて追加することが、
unset コマンドを用いて削除することができます。
show コマンドを用いて一覧を見ることもできます。
/boot/device.hints に設定されている変数は
このときに上書きすることができます。
ローダで設定した device hints の効果は一時的なものであるため、
次回起動するときには無効になります。
システムが起動すると、&man.kenv.1; コマンドでカーネル環境変数を
ダンプすることができます。
/boot/device.hints
は 1 行につき一つの変数を設定でき、
行頭の #
はその行がコメントであることを示しています。
書式は次の通りです。
hint.driver.unit.keyword="value"
ステージ 3 ブートローダ で設定するときの書式は次の通りです。
set hint.driver.unit.keyword=value
driver はデバイスドライバの名前、
unit はデバイスドライバのユニット番号、
keyword はヒントキーワードです。
キーワードは次の設定を指定します:
at:
デバイスがどのバスに接続されているか指定します。
port:
使用する I/O ポートの開始アドレスを指定します。
irq:
使用する IRQ を指定します。
drq:
使用する DMA チャネルを指定します。
maddr:
使用する物理メモリアドレスを指定します。
flags:
デバイスに対してさまざまなフラグを設定します。
disabled:
1 が設定されていると、そのデバイスは無効になります。
デバイスドライバはこのリスト以外の変数を設定できるかもしれませんし、
このリスト以外の変数を必要とするかもしれません。
したがって、デバイスドライバのマニュアルを読むことをおすすめします。
より多くの情報を知りたければ、&man.device.hints.5;,
&man.kenv.1;, &man.loader.conf.5;, &man.loader.8;
などのマニュアルを参照してください。
init
init: プロセス制御の初期化
カーネルの起動が完了すると、&man.init.8;
というユーザプロセスに制御が移されます。
これは /sbin/init、
もしくは loader の
init_path 変数で指定される場所にあります。
自動再起動 (automatic reboot)の動作
自動再起動では、
システム上で利用できるファイルシステムの一慣性を確認します。
もしそれに問題があって &man.fsck.8; がその不一致を修復できなければ、
管理者に直接対処させるため &man.init.8;
はシステムをシングルユーザモードへと移行させます。
シングルユーザモード
シングルユーザモード
コンソール (console)
このモードには、
自動再起動の処理中か、
ユーザが起動時に オプションを指定した場合、
あるいは loader で
boot_single 変数を設定することによって移行します。
また、
マルチユーザモードから
再起動オプション ()
や停止 (halt) オプション () なしで
&man.shutdown.8; を呼び出すとこのモードに移行します。
/etc/ttys
でシステムコンソール console
が insecure に設定されている場合、
システムはシングルユーザモードに移行する前に
root のパスワードを入力するように求めます。
<filename>/etc/ttys</filename> の insecure コンソール
# name getty type status comments
#
# If console is marked "insecure", then init will ask for the root password
# when going to single-user mode.
#
# 訳) console に "insecure" という印をつけると、シングルユーザモードへ移行する
# 際に init が root のパスワードを要求するようになります。
#
console none unknown off insecure
insecure コンソールとは、
あなた自身、コンソールが物理的に安全でないと考えていて、
root
のパスワードを知る人だけがシングルユーザモードを
使えるようにしたいという意味であり、
コンソールを安全でない状態で使いたいという意味ではありません。
そのため、安全性を求めるならば
secure でなく
insecure を選んでください。
マルチユーザモード
マルチユーザモード
&man.init.8; がファイルシステムが正常であると判断するか、
ユーザがシングルユーザモードを終了すると、
システムはマルチユーザモードへ移行し、
リソースの設定を始めます。
リソース設定 (rc)
rc ファイル群
リソース設定システムはデフォルト設定を
/etc/defaults/rc.conf から、
そのシステム独自の細かな設定を
/etc/rc.conf から読み込みます。
そして /etc/fstab
に記述されるシステムファイルシステムをマウントし、
ネットワークサービスの開始、
さまざまなシステムデーモンの開始、
そして最後に、ローカルにインストールされた package
の起動スクリプトの実行へと進みます。
リソース設定システムに関する参考資料は、&man.rc.8; にあります。
これはスクリプトそのものを調べることと同じくらい優れたものです。
シャットダウン動作
shutdown
&man.shutdown.8;
を用いてシステムを意図的にシャットダウンした場合、
&man.init.8; は
/etc/rc.shutdown
というスクリプトの実行を試みます。
そして、すべてのプロセスへ TERM
シグナルを送り、続いてうまく終了できなかったプロセスへ
KILL シグナルを送ります。
電源管理機能を持ったシステムで稼働している FreeBSD
では shutdown -p now コマンドによって、
直ちに電源を落とすことができます。FreeBSD を再起動するには、
shutdown -r now を実行するだけです。
&man.shutdown.8; を実行するには、root
であるか、operator グループのメンバ
でなければなりません。&man.halt.8; や &man.reboot.8; コマンドを
利用することもできますが、より多くの情報を知るために、
それらと &man.shutdown.8; のマニュアルページを参照してください。
電源管理機能は FreeBSD 5.X の &man.acpi.4;
がカーネルに組み込まれているか、
モジュールが読み込まれていることを必要とし、
FreeBSD 4.X の &man.apm.4; を必要とします。
diff --git a/ja_JP.eucJP/books/handbook/config/chapter.sgml b/ja_JP.eucJP/books/handbook/config/chapter.sgml
index c5158b9e5a..93e2533bbc 100644
--- a/ja_JP.eucJP/books/handbook/config/chapter.sgml
+++ b/ja_JP.eucJP/books/handbook/config/chapter.sgml
@@ -1,866 +1,866 @@
設定とチューニング
この章は &a.msmith; と &a.dillon; によって書かれたものをもとに、
&a.chern; と &a.murray によって書かれました。
この章では
System configuration
System optimization
システムを正しく設定することは、
作業の量を減らしメンテナンスや将来の更新の際の困難を減らします。
この章では FreeBSD システムの管理上の設定の側面について記述します。
またこの章では FreeBSD システムのパフォーマンスを最適化する
チューンについても記述します。
初期設定
パーティションのレイアウト
パーティションレイアウト
/etc
/var
/usr
基本パーティション
ファイルシステムのレイアウトを &man.disklabel.8; や
&man.sysinstall.8; で行う際、ハードディスクの外周部は
内周部よりもデータ転送が速いということを覚えておくことが大事です。
これに従えば、
ルートやスワップのような小さくて激しくアクセスされるファイルシステムを外周付近に、
/usr のようなより大きなパーティションはその内側に配置すべきでしょう。
そうするなら、パーティションを作成する際には、ルート、スワップ、
/var、/usr
のような順で作ってゆくのがよいでしょう。
/var パーティションのサイズは
あなたが計算機をどのように使おうとしているかを反映します。
/var は主としてメールボックスやプリントスプール、
ログファイルの保持に使われます。
特にメールボックスとログファイルは、
あなたのシステムのユーザ数やログの保持期間に依存して予期し得ぬサイズにまで成長します。
もしあなたがメールサーバを運用する予定なら /var
パーティションはギガバイト以上のものがよいでしょう。
さらに、/var/tmp は追加したくなるかもしれない
パッケージを収められるだけの大きさが必要です。
/usr パーティションはシステムを
サポートするのに必要なファイル群と、
&man.ports.7; 階層からインストールされたファイル群を収める
/usr/local と呼ばれるサブディレクトリを
その中に含みます。
ports をまったく使わずシステムのソース (/usr/src)
も不要だというのであれば、1 ギガバイトの /usr
パーティションだけで充分です。 しかし、ports
(特にウィンドウマネージャや Linux エミュレーションを使うバイナリ)
を少なからずインストールするのであれば
少なくとも /usr に 2 ギガバイトを薦め、
システムのソースも置こうというなら 3 ギガバイトの
/usr を推奨します。
このパーティションで必要になる量を過小評価してはいけません。
それは驚く程に蔓延るものなのです!
パーティションのサイズを考える時、
必要量にシステムの成長分を見込んでおいてください。
別のパーティションには潤沢にスペースが余っているのに、
あるパーティションでスペースが足らないままというのは
フラストレーションがたまるものです。
&man.sysinstall.8; の Auto-defaults
パーティションサイズを使ったことのある人なら、
そのルートや /var パーティションが
小さすぎることを知っているでしょう。
賢明かつ気前よくパーティションを切ってください。
スワップパーティション
swap サイズ
swap パーティション
経験からスワップサイズはメインメモリの 2 倍というのが一般的です。
つまり、計算機のメモリが 128 メガバイトならばスワップファイルは
256 メガバイトになります。 メモリの少ないシステムでは、
もっとスワップを増した方が性能がよくなります。 256
メガバイト未満のスワップでシステムを設計することはお薦めできません。
またスワップサイズを決める時に、
将来のメモリ増設のことも考えておくべきです。
カーネルの VM (訳註: virtual memory(仮想メモリ))
ページングアルゴリズムはスワップパーティションがメインメモリの
2 倍以上存在するときに最も性能を発揮するように設計されています。
スワップが少なすぎる設定は、
あなたが後にメモリを増設したときに問題を起すばかりではなく、
VM ページスキャニングのコードの能率を落します。
最後に、複数の SCSI ディスク
(や異なるコントローラで操作される複数の IDE ディスク)
を持つ大規模なシステムでは、それぞれのドライブ
(4 台まで) にスワップを設定することを強く推奨します。
各ドライブのスワップパーティションはほぼ同一サイズであるべきです。
カーネルは任意のサイズを扱うことができますが、
内部のデータ構造は最大のスワップパーティションの 4 倍に調節されます。
スワップパーティションをほぼ同一のサイズにしておくことで
カーネルはスワップスペースを最適なかたちで
- ディスクをまたいでストライブさせることができます。
+ ディスクをまたいでストライプさせることができます。
こだわりすぎる必要はありません。
スワップスペースは UNIX のつつましい美点です。
あなたが通常スワップをたくさん使わないとしても、
プログラムが暴走してもリブートさせられる前に回復する時間を多く得られます。
何故パーティション化するのか?
何故パーティション化してしまうのでしょう?
何故巨大な root パーティション一発では駄目なのでしょう?
そうすれば容量が溢れるかもと心配しなくてもすむのに!
いくつかの理由からそれはよいアイデアとは言えません。
まず各パーティションはアクセスの特徴がそれぞれ異なっていて、
分離しておくことでそれぞれの特徴に応じたチューンができるようになるからです。
root パーティションや /usr
パーティションはほとんどが読み出しでわずかな書き込みがあるだけですが
/var や /var/tmp
パーティションでは大量の読み書きが発生します。
システムを適切にパーティション化することで
小さいが書き込みの激しいパーティションによって引き起こされる
フラグメント化を読み出し専門のパーティションにまで波及させずにすみます。
また書き込みの激しいパーティションをディスクの周辺部に配置することで、
たとえばパーティションテーブル内で大きなパーティションの後のかわりに前に配置することで、
それが最も必要とされているパーティションの
I/O パフォーマンスを増大させることができます。
大きなパーティション内の I/O
パフォーマンスもまた必要とされているでしょうが、
それらは大きすぎてディスク周辺部へ移動させてやったとしても
/var
を周辺部に移動させることによって大きな効果が得られたのとは対照的に
意味のあるパフォーマンスの増加は見込めないでしょう。
基本的にリードオンリーな root
パーティションを小さくまとめておくことで
不幸なクラッシュを生き延びるチャンスが増大します。
中核となる設定
rc files
rc.conf
システムの設定情報が収められている主な場所は
/etc/rc.conf です。
このファイルにはシステムの起動時にシステムの設定を行なうものをはじめ
多岐に渡る設定情報が含まれています。
そのファイル名はダイレクトに、それが rc*
ファイル群の設定情報であることを示しています。
管理者は /etc/defaults/rc.conf
のデフォルトの設定を rc.conf ファイルにエントリを作ることで上書きすべきです。
デフォルトのファイルをそのまま /etc
にコピーするのはやめるべきです。
それはデフォルト値であってサンプルではないのです。
システム固有のすべての変更は rc.conf ファイルの中でするべきです。
管理の手間を減らす為、クラスター化されたアプリケーションには
サイト共通の設定とシステム固有の設定を分離する様々な戦略が適用できます。
推奨されるアプローチは、サイト共通の設定は
/etc/rc.conf.site のような別のファイルに置き、
それをシステム固有の設定情報しか含ませない
/etc/rc.conf からインクルードすることです。
rc.conf は &man.sh.1;
によって読み込まれているので、これはじつに簡単に達成できます。
たとえば、
rc.conf:
. rc.conf.site
hostname="node15.webcompany.com"
network_interfaces="fxp0 lo0"
ifconfig_fxp0="inet 10.1.1.1"
rc.conf.site:
defaultrouter="10.1.1.254"
saver="daemon"
blanktime="100"
rc.conf.site ファイルは
rsync 等を使うことで全システムに配布でき、
一方 rc.conf
ファイルはユニークなままを保つことができます。
システムを &man.sysinstall.8; や 'make world' 等で
更新した場合 rc.conf ファイルは上書きされません。
なのでシステムの設定情報が失われることもありません。
アプリケーションの設定
基本的に、インストールされたアプリケーションは独自の文法を持つ
固有の設定ファイルを持ちます。
これらのファイルがベースシステムから分離されているということは重要で、
このためパッケージ管理ツールによる配置と管理が容易になっています。
/usr/local/etc
基本的に、それらのファイルは /usr/local/etc
にインストールされます。
設定ファイルの数が多数にのぼるアプリケーションに対しては、
それら用にサブディレクトリが作られます。
通常、ports やパッケージがインストールされると
設定ファイルのサンプルが一緒にインストールされます。
大抵、識別のためにサフィックスとして ".default" がついています。
アプリケーションのための設定ファイルがまだ存在していなければ、
.defaults ファイルをコピーすることで作成できます。
以下は
/usr/local/etc/apache の例です。
-rw-r--r-- 1 root wheel 2184 May 20 1998 access.conf
-rw-r--r-- 1 root wheel 2184 May 20 1998 access.conf.default
-rw-r--r-- 1 root wheel 9555 May 20 1998 httpd.conf
-rw-r--r-- 1 root wheel 9555 May 20 1998 httpd.conf.default
-rw-r--r-- 1 root wheel 12205 May 20 1998 magic
-rw-r--r-- 1 root wheel 12205 May 20 1998 magic.default
-rw-r--r-- 1 root wheel 2700 May 20 1998 mime.types
-rw-r--r-- 1 root wheel 2700 May 20 1998 mime.types.default
-rw-r--r-- 1 root wheel 7980 May 20 1998 srm.conf
-rw-r--r-- 1 root wheel 7933 May 20 1998 srm.conf.default
srm.conf ファイルだけが変更されていることが即座に見てとれるでしょう。
後に apache を更新した時にも、
この変更されたファイルは上書きされることはありません。
サービスの起動
サービス
一つのシステムでサービスをいくつも立ち上げているということは
よくあることです。 それらには独自の立ち上げかたがあることがあり、
それぞれ有利な点があります。
/usr/local/etc/rc.d
Ports collection やパッケージからインストールしたソフトウェアは
しばしば /usr/local/etc/rc.d にスクリプトを置き、
システムが起動した時には 'start'、システムをシャットダウンする時には
'stop' の引数をつけてこれを実行します。
これは root によって実行されるべきであるようなシステムワイドな
サービスを起動する場合に推奨される方法です。
これらのスクリプトはパッケージの一部としてインストール時に記録され、
パッケージとともに削除されます。
/usr/local/etc/rc.d にある
一般的なスクリプトは次のようなものです。
#!/bin/sh
echo -n ' FooBar'
case "$1" in
start)
/usr/local/bin/foobar
;;
stop)
kill -9 `cat /var/run/foobar.pid`
;;
*)
echo "Usage: `basename $0` {start|stop}" >&2
exit 64
;;
esac
exit 0
このスクリプトはその目的を果すべく起動時に 、
シャットダウン時に をつけて呼ばれます。
サービスの中には固有のポートに接続を受けたときに
&man.inetd.8; から起動されるものもあります。
これはメールリーダサーバ (POP や IMAP 等) の場合によくあります。
これらのサービスは /etc/inetd.conf
ファイルを編集することで有効化されます。
このファイルの編集に関する詳細は &man.inetd.8; を見てください。
これらの他に /etc/rc.conf
による有効化/無効化がカバーされていないサービスもあります。
それらは伝統的に /etc/rc.local
にコマンドを書き込むことで実行されていました。
FreeBSD 3.1 にはデフォルトの /etc/rc.local
は存在していません。 もし管理者によって作られていれば、
その時は一般的なやりかたとして認められるべきでしょう。
rc.local は最後の場所と考えられているということを
知っておいてください。 サービスを起動させるのにもっといい場所があるなら
そこから始めてください。
/etc/rc.conf
でその他のコマンドを実行しないでください。
そのかわり、デーモンの起動やブート時のコマンド実行は
/usr/local/etc/rc.d にスクリプトを配置してください。
この他にサービスの起動に &man.cron.8; を利用することもできます。
このアプローチには、cron がそのプロセスを
crontab のオーナ権限で実行したり、サービスが非特権ユーザによって
立ち上げられ管理されるなどといった有利な点がいくつもあります。
これで cron の文書化されていない機能の利点を得ることができます。
日時の指定を '@reboot' で置き換えることでジョブは
システムがブートした直後、cron が起動した時に実行されます。
バーチャルホスト
バーチャルホスト
ip aliases
FreeBSD の非常にありふれた用途の一つにバーチャルサイトの
ホスティングがあります。
これは一つのサーバがネットワークには複数のサーバとして現れるものです。
これは一つのネットワークインタフェイスに
複数のアドレスを割当てることで実現されます。
ネットワークインタフェイスは "真の" アドレスを一つと
"別名" のアドレスを複数持ちます。 これらの別名は通常
/etc/rc.conf
に別名のエントリを置くことで追加されます。
'fxp0' インタフェイスへの別名のエントリは以下の様なものです。
ifconfig_fxp0_alias0="inet xxx.xxx.xxx.xxx netmask xxx.xxx.xxx.xxx"
別名のエントリは alias0 から始まり _alias1、_alias2
の様に増加してゆかなければなりません。 設定プロセスは
最初に欠けた番号のところで停まります。
別名のネットマスクの計算は重要ですが、幸いなことに非常に簡単です。
個々のインタフェイスについてそのネットワークのネットマスクを正しく
表現しているアドレスが必ず一つ必要です。
そのネットワークに所属しているそれ以外のアドレスのネットマスクは
全て 1 でなければなりません。
例として、fxp0 インタフェイスが二つのネットワークに接続されている
ものを考えてみましょう。 一つはネットマスクが 255.255.255.0 である
10.1.1.0 ネットワークで、もう一つはネットマスクが 255.255.255.240 である
202.0.75.16 ネットワークです。 システムは 10.1.1.0 には 10.1.1.1 として、
202.0.75.20 には 202.0.75.17 として現れるようにします。
以下のエントリはネットワークインタフェイスを上述の環境に正しく
設定するものです。
ifconfig_fxp0="inet 10.1.1.1 netmask 255.255.255.0"
ifconfig_fxp0_alias0="inet 10.1.1.2 netmask 255.255.255.255"
ifconfig_fxp0_alias1="inet 10.1.1.3 netmask 255.255.255.255"
ifconfig_fxp0_alias2="inet 10.1.1.4 netmask 255.255.255.255"
ifconfig_fxp0_alias3="inet 10.1.1.5 netmask 255.255.255.255"
ifconfig_fxp0_alias4="inet 202.0.75.17 netmask 255.255.255.240"
ifconfig_fxp0_alias5="inet 202.0.75.18 netmask 255.255.255.255"
ifconfig_fxp0_alias6="inet 202.0.75.19 netmask 255.255.255.255"
ifconfig_fxp0_alias7="inet 202.0.75.20 netmask 255.255.255.255"
設定ファイル
<filename>/etc</filename> のレイアウト
設定のための情報が含まれているディレクトリはたくさんあります。
それぞれ以下のものを含んでいます。
/etc
システム全般の設定情報。 ここにあるデータはシステム
固有のものです。
/etc/defaults
デフォルトのシステム設定ファイル。
/etc/mail
追加的な sendmail の設定、他の MTA の設定ファイル。
/etc/ppp
ユーザモード、およびカーネルモードの ppp プログラムの設定。
/etc/namedb
bind(8) のデータのデフォルトの置場。 通常
boot ファイルはここに置かれ、/var/db に置かれた他のデータを
参照するディレクティブを含みます。
/usr/local/etc
インストールされたアプリケーションの設定ファイル。
アプリケーションごとのサブディレクトリを含んでいることがあります。
/usr/local/etc/rc.d
インストールされたアプリケーションの起動/停止スクリプト。
/var/db
永続的なシステム固有のデータファイル。 たとえば
bind(8) のゾーンファイル、データベースファイル等。
ホスト名
hostnames
DNS
/etc/resolv.conf
resolv.conf
/etc/resolv.conf は FreeBSD に
インターネットドメインネームシステム (DNS)
にどのようにアクセスするかを指定します。
resolv.conf の最もよくあるエントリは
nameserver
リゾルバが問い合わせるべきネームサーバの IP アドレス。
サーバはリストの順に 3 番目まで問い合わせられます。
search
ホスト名をルックアップする検索リスト。
通常、ローカルなホスト名のドメインから決定されます。
domain
ローカルドメイン名。
基本的な resolv.conf。
search foobar.com
nameserver 147.11.1.11
-+nameserver 147.11.100.30
+nameserver 147.11.100.30
&man.dhclient.8; は通常 resolv.conf
を DHCP サーバから受け取った情報で書き換えます。
<filename>/etc/hosts</filename>
hosts
/etc/hosts は古きインターネットを
偲ばせるシンプルなテキストのデータベースです。
これはホスト名と IP アドレスをマッピングする DNS や NIS
と組み合わせて使われます。 LAN でつながれているローカルな計算機は、
名前引きを簡単にするために
&man.named.8; サーバを立ち上げるかわりにここに書くことができます。
さらに /etc/hosts
はインターネット名のローカルなレコードを提供し、
よくアクセスされる名前を外部に問い合わせるのを減らすためにも使えます。
# $FreeBSD$
#
# Host Database
# This file should contain the addresses and aliases
# for local hosts that share this file.
# In the presence of the domain name service or NIS, this file may
# not be consulted at all; see /etc/nsswitch.conf for the resolution order.
#
#
::1 localhost localhost.my.domain myname.my.domain
127.0.0.1 localhost localhost.my.domain myname.my.domain
#
# Imaginary network.
#10.0.0.2 myname.my.domain myname
#10.0.0.3 myfriend.my.domain myfriend
#
# According to RFC 1918, you can use the following IP networks for
# private nets which will never be connected to the Internet:
#
# 10.0.0.0 - 10.255.255.255
# 172.16.0.0 - 172.31.255.255
# 192.168.0.0 - 192.168.255.255
#
# In case you want to be able to connect to the Internet, you need
# real official assigned numbers. PLEASE PLEASE PLEASE do not try
# to invent your own network numbers but instead get one from your
# network provider (if any) or from the Internet Registry (ftp to
# rs.internic.net, directory `/templates').
#
/etc/hosts は、
次のようなごく簡単なフォーマットになっています。
[インターネットアドレス] [正式なホスト名] [別名1] [別名2] ...
例:
10.0.0.1 myRealHostname.foobar.com myRealHostname foobar1 foobar2
これ以上の情報は &man.hosts.5; をあたってください。
ログファイルに関係する設定
log files
<filename>syslog.conf</filename>
syslog.conf
syslog.conf
は &man.syslogd.8; プログラムのための設定ファイルです。
これはどのタイプの syslog メッセージを対応する
ログファイルに記録するかを指定します。
# $FreeBSD$
#
# Spaces ARE valid field separators in this file. However,
# other *nix-like systems still insist on using tabs as field
# separators. If you are sharing this file between systems, you
# may want to use only tabs as field separators here.
# Consult the syslog.conf(5) manpage.
*.err;kern.debug;auth.notice;mail.crit /dev/console
*.notice;kern.debug;lpr.info;mail.crit;news.err /var/log/messages
security.* /var/log/security
mail.info /var/log/maillog
lpr.info /var/log/lpd-errs
cron.* /var/log/cron
*.err root
*.notice;news.err root
*.alert root
*.emerg *
# uncomment this to log all writes to /dev/console to /var/log/console.log
#console.info /var/log/console.log
# uncomment this to enable logging of all log messages to /var/log/all.log
#*.* /var/log/all.log
# uncomment this to enable logging to a remote loghost named loghost
#*.* @loghost
# uncomment these if you're running inn
# news.crit /var/log/news/news.crit
# news.err /var/log/news/news.err
# news.notice /var/log/news/news.notice
!startslip
*.* /var/log/slip.log
!ppp
*.* /var/log/ppp.log
これ以上の情報は &man.syslog.conf.5; のマニュアルページに
あたってください。
<filename>newsyslog.conf</filename>
newsyslog.conf
newsyslog.conf は &man.newsyslog.8;
のための設定ファイルで、
通常 &man.cron.8; によって実行されるプログラム &man.newsyslog.8;
がログファイルをいつ保存して再編するかを決定します。
logfile は logfile.1
に移され、logfile.1 は
logfile.2 に、そして以下同様に移されます。
さらにログファイルを gzip 形式で保存することもできます。
この場合ファイル名は logfile.0.gz、logfile.1.gz
の様になります。
newsyslog.conf
はどのログファイルが管理され、どのくらいの期間保存され、
そしていつ touch されるかを指定します。
ログファイルはあるサイズに到達するか、ある決められた時刻・
日時で再編されあるいは保存されます。
# configuration file for newsyslog
# $FreeBSD$
#
# logfilename [owner:group] mode count size when [ZB] [/pid_file] [sig_num]
/var/log/cron 600 3 100 * Z
/var/log/amd.log 644 7 100 * Z
/var/log/kerberos.log 644 7 100 * Z
/var/log/lpd-errs 644 7 100 * Z
/var/log/maillog 644 7 * @T00 Z
/var/log/sendmail.st 644 10 * 168 B
/var/log/messages 644 5 100 * Z
/var/log/all.log 600 7 * @T00 Z
/var/log/slip.log 600 3 100 * Z
/var/log/ppp.log 600 3 100 * Z
/var/log/security 600 10 100 * Z
/var/log/wtmp 644 3 * @01T05 B
/var/log/daily.log 640 7 * @T00 Z
/var/log/weekly.log 640 5 1 $W6D0 Z
/var/log/monthly.log 640 12 * $M1D0 Z
/var/log/console.log 640 5 100 * Z
これ以上の情報は &man.newsyslog.8; のマニュアルページに
あたってください。
<filename>sysctl.conf</filename>
sysctl.conf
sysctl
sysctl.conf は
rc.conf によく似ています。
値は変数=値のかたちでセットされます。
指定された値はシステムがマルチユーザモードに移行した後でセットされます。
すべての変数がこのモードで設定可能というわけではありません。
以下は sysctl.conf のサンプルで
致命的なシグナルを記録しないように、また Linux プログラムに
それらが実際は FreeBSD 上で動いていることを知らせる様に
チューニングしています。
kern.logsigexit=0 # Do not log fatal signal exits (e.g. sig 11)
compat.linux.osname=FreeBSD
compat.linux.osrelease=4.3-STABLE
sysctl によるチューニング
sysctl
sysctl によるチューニング
&man.sysctl.8; は稼働中の FreeBSD
システムに変更を加えるためのインタフェイスです。
- これには経験を積んだ管理者用の TCP/IP スタックへや
+ これには経験を積んだ管理者用の TCP/IP スタックや
仮想メモリシステムのパフォーマンスを劇的に改善する
先進的なオプションが含まれます。
500 を越えるシステム変数を &man.sysctl.8; で読んだり
セットしたりできます。
中心において &man.sysctl.8; の機能は以下の二つに尽きます。
すなわちシステムの設定を読んで変更することです。
読むことができるすべての変数を表示するには以下のようにします。
&prompt.user; sysctl -a
個々の変数、たとえば
kern.maxproc を読むには以下のようにします。
&prompt.user; sysctl kern.maxproc
kern.maxproc: 1044
個々の変数をセットするには =
オプションを使います。
&prompt.root; sysctl kern.maxfiles=5000
kern.maxfiles: 2088 -> 5000
sysctl 変数の値は通常、文字列、数値、真偽値のいずれかです。
真偽値は yes の場合には 1 で no の場合には 0 です。
ディスクのチューニング
sysctl 変数
vfs.vmiodirenable
vfs.vmiodirenable
vfs.vmiodirenable sysctl
はデフォルトは 0 (オフ) であり (しかし近いうちにデフォルトが 1
になるでしょう)、0 (オフ) または 1 (オン) にセットすることができます。
このパラメータはディレクトリがシステムによってどのように
キャッシュされるかを制御します。
ほとんどのディレクトリは小さく、
ファイルシステムにおいては単一フラグメント (典型的には 1K)
であり、バッファキャッシュではさらに小さくなっています
(典型的には 512 バイト)。
しかしデフォルトモードで動作している時は、
大量のメモリを搭載していても
バッファキャッシュは固定数のディレクトリしかキャッシュしません。
この sysctl をオンにすると、バッファキャッシュが VM ページキャッシュを、
ディレクトリをキャッシュするために使うことを可能にします。
これによる利点は、全てのメモリがディレクトリを
キャッシュするのに使えるようになるということです。
欠点は、キャッシュに使われる最小のメモリの大きさが 512 バイトではなく
物理ページサイズ (大抵は 4K) になることです。
多数のファイルを操作するサービスを稼動しているなら、
常にこのオプションをオンにすることを推奨します。
そのようなサービスには、web キャッシュや大規模なメールシステム、
ニューズシステムなどが含まれます。
このオプションは一般にメモリを消費しますが、
性能を削減することはありません。
ただし実験して調べてみるべきでしょう。
hw.ata.wc
hw.ata.wc
FreeBSD 4.3 では IDE のライトキャッシュがオフになりました。
これは IDE
ディスクへの書き込み帯域幅を減らしてしまうことになりますが、
ハードドライブベンダに起因するデータの一貫性に関する
重大な問題のために必要なことだと考えられました。
基本的には、書き込み完了時期について IDE
ドライブが嘘をつくという問題です。
IDE ライトキャッシュがオンであると
IDE ハードドライブはデータを順番に書きこまないばかりか、
ディスクの負荷が高い時にはいくつかのブロックの書き込みを
無期限に延期してしまいます。 クラッシュや電源故障の場合、
ファイルシステムの重大な破壊をもたらします。
したがって私たちはデフォルトを安全側に変更しました。
残念ながらこれは大変な性能の低下をもたらし、
私たちはあきらめてこのリリース後にオンに戻しました。
hw.ata.wc sysctl 変数を見てデフォルトをチェックしてみるべきです。
もし IDE ライトキャッシュがオフになっていたら、
hw.ata.wc カーネル変数を 1 に戻すことでオンに戻すことができます。
これはブート時にブートローダから行わなければなりません。
カーネルがブートした後に行っても効果はありません。
&man.ata.4; を見てください。
ソフトアップデート
ソフトアップデート
tunefs
&man.tunefs.8; はファイルシステムを fine チューンするのに使えます。
この目的においてはソフトアップデートをオンオフすることを
考えるだけですみます。 以下の様にしてトグルします。
&prompt.root; tunefs -n enable /filesystem
&prompt.root; tunefs -n disable /filesystem
ファイルシステムはマウントされているあいだは &man.tunefs.8;
で変更することができません。 ソフトアップデートを有効にする
いい機会はシングルユーザモードでどのパーティションもマウント
されていない時です。
softupdates はメタデータの性能、
主にファイルの作成と削除の性能を劇的に改善します。
全てのファイルシステムで softupdates を有効にすることを推奨します。
softupdates に関して、2 つの欠点を意識すべきです。
1 つめは、softupdates
はクラッシュ時におけるファイルシステムの一貫性は保証しますが、
物理ディスクの更新が何秒か (1 分になることもあります!)
遅れる可能性が高いことです。
クラッシュした場合、より多くの成果が消えてしまうかもしれません。
2 つめは、softupdates
はファイルシステムブロックを解放するのを遅らせるということです。
あるファイルシステム (例えばルートファイルシステム) が満杯近くの時に
それに対する大規模な更新、たとえば make installworld
をすると、空き領域を使い果たして更新が失敗してしまうことがあります。
kernel の制限をチューニングする
kernel の制限をチューニングする
File/process 制限
kern.maxfiles
kern.maxfiles
kern.maxfiles はあなたのシステムの要求に
応じて増減させることができます。
この変数はあなたのシステムのファイル記述子の最大値を示します。
ファイル記述子テーブルが溢れるような時には dmesg に頻繁に
file: table is full
と表示されます。
ファイル、ソケット、パイプ(fifo) は
それぞれオープンされるとファイル記述子を一つ消費します。
大規模なプロダクションサーバでは
その時実行されているサービスの種類や数に応じては
あっさり数千のファイル記述子が必要になります。
kern.maxfile のデフォルト値は
kernel config ファイルの maxusers オプションで決ります。
kern.maxfiles は maxusers の値に応じて増加します。