diff --git a/ja_JP.eucJP/books/handbook/advanced-networking/chapter.sgml b/ja_JP.eucJP/books/handbook/advanced-networking/chapter.sgml
index d579c195fe..3471715628 100644
--- a/ja_JP.eucJP/books/handbook/advanced-networking/chapter.sgml
+++ b/ja_JP.eucJP/books/handbook/advanced-networking/chapter.sgml
@@ -1,2936 +1,2936 @@
高度なネットワーク
この章では
以下の章では、 UNIX
システム上で良く利用されるネットワークサービスについて書かれています。
これはもちろん、 あなたの FreeBSD
システムでの、 そのようなサービスの設定に関する内容です。
ゲートウェイとルート
原作: &a.gryphon;.
1995 年 10 月 6 日.
訳: &a.jp.yuki;.
1996 年 9 月 6 日.
あるマシンが他のマシンをみつけることができるようにするには、
あるマシンから他のマシンへ、
どのようにたどり着くかを適切に記述するための仕組みが必要です。
この仕組みをルーティングと呼びます。 ルート(経路)
は
destination (目的地)
と gateway
(ゲートウェイ)
の 2 つのアドレスの組で定義します。 あなたが
destination へアクセスしようとした場合、
gateway
を通って送られることをこのペアは示しています。 destination
には個々のホスト、 サブネット、 デフォルト
の 3つの
タイプがあります。
デフォルトルート
は他への経路が適用できない
- 場合に使われます。 のちほどデフォルトルートについて少し述べること
+ 場合に使われます。 のちほどデフォルトルートについて少し述べることに
するとして、 ここでは、 個々のホスト、 インタフェース
(リンク
とも呼ばれます)、
イーサネットハードウェアアドレスという 3つのタイ
プのゲートウェイについて説明します。
例
以下に示す netstat -r
の出力の例を使って、 ルーティン
グがいろいろと異なっている様子を説明することにします。
Destination Gateway Flags Refs Use Netif Expire
default outside-gw UGSc 37 418 ppp0
localhost localhost UH 0 181 lo0
test0 0:e0:b5:36:cf:4f UHLW 5 63288 ed0 77
10.20.30.255 link#1 UHLW 1 2421
foobar.com link#1 UC 0 0
host1 0:e0:a8:37:8:1e UHLW 3 4601 lo0
host2 0:e0:a8:37:8:1e UHLW 0 5 lo0 =>
host2.foobar.com link#1 UC 0 0
224 link#1 UC 0 0
最初の2行はデフォルトルート(次の節で詳しく説明します)と、
localhostへの経路を示しています。
localhostのためのインタフェース
(Netifの欄)
はlo0で、
これはループバックデバイスとして知られています。
結局のところ戻るだけなので、 この
destinationへのすべてのトラフィックが
内部的に処理されるのであって、 LAN
を経由して送られるのではありません。
次の行では
0:e0:...
というアドレスに注目しましょう。
これはイーサネットハードウェアアドレスです。 FreeBSDは自動的に
ローカルなイーサネット上の任意のホスト
(この例ではtest0) を見つけ、
イーサネットインタフェース ed0
の所にそのホストへの経路を直接つけ加えます。 タイムアウト時間
(Expireの 欄)
も経路のタイプと結びついており、 指定された時間が経過しても応
答がないときに使用します。 この場合、
経路情報は自動的に削除されま す。 これらのホストは、 RIP(Routing
Information Protocol) という、
最短パスの判定に基づいてローカルホストへの経路を
決定する仕組みを利用することで認識されます。
更に、 FreeBSDではローカルサブネット
(10.20.30.255 は
10.20.30
というサブネットに対するブロードキャストアドレスで、
foobar.com
はこのサブネットに結びつけられているドメイン名)
への経路情報も加えることができます。
link#1というのは、
このマシンの最初のイーサネットカードのことをさします。 これら
については、
何も追加インタフェースが指定されていないことに気づく
でしょう。
これらの2つのグループ(ローカルネットワークホストと
ローカルサブネット) の両方とも、 routed
と呼ばれるデーモンによって自動的に経路が設定されます。
routed を動かさなければ、
静的に定義した (つまり具体的に設定した)
経路のみ存在することになります。
host1 の行は私たちのホストのことで、
イーサネットアドレスで示されています。 送信側のホストの場合、
FreeBSDはイーサネットインタフェースへ送るのではなく、
ループバックインタフェース
(lo0)を使います。
2つあるhost2の行は、
ifconfigのエイリアス (このようなことをする理由については
ethernetの章を参照してください) を使ったとき
にどのようになるかを示す例です。
lo0の後にある=>
は、 インタフェースが
(このアドレスがローカルなホストを参照しているので)
ループバックを使っているというだけでなく、
エイリアスになっていることも示しています。
このような経路はエイリアスをサポートしている
ホストにのみ現れます。
ローカルネットワーク上の他のすべてのホストでは
単にlink#1となります。
最後の行 (destinationが224のサブネット)
はマルチキャストで扱うものですが、
これは他の章で説明します。
他の欄については Flags
について説明する必要があります。
それぞれの経路は欄に示されているように違った属性を
もっています。
以下にいくつかのフラグとこれらが何を意味しているかを示します。
U
Up: この経路はアクティブです。
H
Host: 経路の destinationが単一のホストです。
G
Gateway: この destinationへ送られると、 どこへ送れ
ばよいかを明らかにして、
そのリモートシステムへ送られます。
S
Static: この経路はシステムによって自動的に生成
されたのではなく、 手動で作成されました。
C
Clone: マシンに接続したときにこの経路に基づく
新しい経路が作られます。 このタイプの経路は通常は
ローカルネットワークで使われます。
W
WasCloned: ローカルエリアネットワーク(Clone)
の経路に基づいて
自動的に生成された経路であることを示します。
L
Link: イーサネットハードウェアへの参照を含む
経路です。
デフォルトルート
ローカルシステムからリモートホストにコネクションを張る
必要がある場合、 既知のパスが存在するかどうかを確認するためにル
ーティングテーブルをチェックします。
到達するためのパスを知っているサブネットの内部に
リモートホストがある場合 (Cloned routes)、 システムはインタフェース
から接続できるかどうかをチェックします。
知っているパスがすべて駄目だった場合でも、 システムには
最後の切り札の デフォルト
ルートがあります。
このルートは ゲートウェイルート (普通はシステムに
1つしかありません) の特別なものです。 そして、
フラグフィールドは必ず c
がマークされています。 このゲートウェイは、 LAN 内のホストにとっ
て、 外部 (PPPのリンクを経由する場合や、
データラインに接続するハードウェアデバイスなど)
へ直接接続するマシンすべてのためのものです。
外部に対するゲートウェイとして機能するマシンで
デフォルトルートを設定する場合、
デフォルトルートはインターネットサービスプロバイダ (ISP)
のサイトのゲートウェイマシンになるでしょう。
それではデフォルトルートの一例を見てみましょう。
一般的な構成を示します。
[Local2] <--ether--> [Local1] <--PPP--> [ISP-Serv] <--ether--> [T1-GW]
ホスト Local1 とホスト Local2
を PPP で ISP のターミナルサーバと接続されているあなたの
サイトだとします。
ISP はサイト内にロー カルなネットワークを持っていて、
- そこにはまざまなものがあり、
+ そこにはさまざまなものがあり、
あなたの接続するサーバや ISP のインターネットへの
接続点であるハードウェアデバイス (T1-GW) などがあります。
あなたのマシンのデフォルトルートは
それぞれ次のようになります。
host
default gateway
interface
Local2
Local1
ethernet
Local1
T1-GW
PPP
なぜ (あるいは、 どうやって) Local1 の
デフォルトゲートウェイをISPのサーバでなく
T1-GWにセットするのか
という質問がよくあります。
コネクションのローカルの側については、
PPPのインタフェースは
ISPのローカルネットワーク上のアドレスを用いているため、
ISPのローカルネットワーク上のすべてのマシンへの経路は
自動的に生成されています。 つまり、 あなたのマシンは、
どのようにT1-GW
まで届くかという経路を既に知っていることになりますから、
ISPサーバに媒介的なトラフィックをかける必要はありません。
最後になりましたが、 一般的にローカルネットワークでは
...1
というアドレスをゲートウェイアドレスとして使います。 ですから
(同じ例を用います)、 あなたのclass-Cのアドレス空間が
10.20.30で ISPが
10.9.9を用いている場合、
デフォルトルートは次のようになります。
Local2 (10.20.30.2) --> Local1 (10.20.30.1)
Local1 (10.20.30.1, 10.9.9.30) --> T1-GW (10.9.9.1)
マルチホームホスト
ここで扱うべき他のタイプの設定があります。
それは2つの異なるネットワークにまたがるホストです。
技術的にはゲートウェイとして機能するマシン (上 の例では
PPPコネクションを用いています) はマルチホームホストで す。
しかし実際にはこの言葉は、
2つのローカルエリアネットワーク上のサ
イトであるマシンを指す言葉としてのみ使われます。
2枚のイーサネットカードを持つマシンが、 別のサブネット
上にそれぞれアドレスを持っている場合があります。 あるいは、
イーサネットカードを1枚持っているマシンで、
ifconfigのエイリアスを使っているかもしれません。
物理的に分かれている2つのイーサネットのネットワークが使われて
いるならば前者が用いられます。 後者は、 物理的には1つのネットワ
ークセグメントで、 論理的には分かれている 2つのサブネットとする
場合に用いられます。
どちらにしても、
このマシンがお互いのサブネットへのゲートウェイ (inbound
route) として定義されていることが分かるように、 おのお
ののサブネットでルーティングテーブルを設定します。 このマシンが
2 つのサブネットの間のブリッジとして動作するという構成は、 パケ
ットのフィルタリングを実装する必要がある場合や、 一方向または双
方向のファイアウォールを利用したセキュリティを構築する場合によ
く用いられます。
ルーティングの伝播
すでに外部との経路をどのように定義したらよいかは
説明しました。
しかし外部から私たちのマシンをどのようにして
見つけるのかについては説明していません。
ある特定のアドレス空間 (この例では class-C のサブネット)
におけるすべてのトラフィックが、
到着したパケットを内部で転送するネ
ットワーク上の特定のホストに送られるようにルーティングテーブル
を設定することができるのは分かっています。
あなたのサイトにアドレス空間を割り当てる場合、
あなたのサブネットへのすべてのトラフィックがすべて
PPPリンクを通じてサイトに送
ってくるようにサービスプロバイダはルーティングテーブルを設定し
ます。 しかし、 国境の向こう側のサイトはどのようにしてあなたの
ISPへ送ることを知るのでしょうか?
割り当てられているすべてのアドレス空間の経路を維持する
(分散している DNS 情報とよく似た) システムがあり、
そのインターネット バックボーンへの接続点を定義しています。
バックボーン
とは国を越え、
世界中のインターネットのトラフィックを運ぶ主要
な信用できる幹線のことです。 どのバックボーンマシンも、
あるネットワークから特定のバックボーンのマシンへ
向かうトラフィックと、
そのバックボーンのマシンからあなたのネットワークに届くサービス
プロバイダまでのチェーンのマスタテーブルのコピーを持っていま
す。
あなたのサイトが接続(プロバイダからみて内側にある
ことになります) したということを、 プロバイダからバックボー
ンサイトへ通知することはプロバイダの仕事です。 これが経
路の伝搬です。
トラブルシューティング
ルーティングの伝搬に問題が生じて、 いくつかのサイトが
接続をおこなうことができなくなることがあります。
ルーティングがどこでおかしくなっているかを明らかにするのに
最も有効なコマンドはおそらく &man.traceroute.8; コマンドでしょ
う。 このコマンドは、
あなたがリモートマシンに対して接続をおこなう
ことができない(例えば &man.ping.8; に失敗するような場合)
場合も、 同じように有効です。
&man.traceroute.8; コマンドは、
接続を試みているリモートホストを引数にして実行します。
試みているパスの経由するゲートウェイホストを表示し、
最終的には目的のホストにたどり着くか、
コネクションの欠如によって終ってしまうかのどちら
かになります。
より詳しい情報は、 &man.traceroute.8;
のマニュアルページをみてください。
Bridging
Written by Steve Peterson
steve@zpfe.com.
はじめに
IP サブネットを作成し、 それらのセグメントをルータを
使って接続したりせずに、 (Ethernet セグメントのような)
物理ネットワークを二つのネットワークセグメントに分割することは
とても有効な場合があります。
このような二つのネットワークを繋ぐデバイスはブリッジと呼ばれます。
そして、 二つのネットワークインタフェイスカードを持つ FreeBSD
システムは、 ブリッジとして動作することができます。
ブリッジは、 各ネットワークインタフェイスに繋がる
デバイスの MAC 層のアドレス (例えば Ethernet アドレス)
を記憶します。
ブリッジはトラフィックの送信元と受信先が異なったネットワーク上に
ある場合にのみ、 トラフィックを転送します。
すなわち、 ブリッジはポート数の少ない Ethernet スイッチ
だ、 ということができます。
ブリッジがふさわしい状況とは
今日ブリッジが活躍する場面は大きく分けて二つあります。
トラフィックの激しいセグメント
ひとつは、 物理ネットワークセグメントがトラフィック
過剰になっているが、 なんらかの理由によりネットワークを
サブネットに分け、 ルータで接続することができない場合です。
編集部門と製作部門がおなじサブネットに同居している
新聞社を例に考えてみましょう。
編集部門のユーザはファイルサーバとして全員サーバ A を利用し、
製作部門のユーザはサーバ B を利用します。
すべてのユーザを接続するのには Ethernet が使われており、
高負荷となったネットワークは遅くなってしまいます。
もし編集部門のユーザを一つのネットワークセグメントに
分離することができ、 製作部門もユーザも同様にできるのなら、
二つのネットワークセグメントをブリッジで繋ぐことができます。
ブリッジの "反対" 側へ向かうネットワークトラフィックだけが
転送され、 各ネットワークセグメントの混雑は緩和されます。
パケットフィルタ/帯域制御用ファイアウォール
もうひとつは、 IP Masquerading (NAT) を使わずに
ファイアウォール機能を利用したい場合です。
ここでは DSL もしくは ISDN で ISP に接続している
小さな会社を例にとってみましょう。
この会社は ISP から 13 個のグローバル IP アドレスの割り当て
を受けており、 ネットワーク内には 10 台の PC が存在します。
このような状況では、 サブネット化にまつわる問題から
ルータを用いたファイアウォールを利用することは困難です。
ブリッジを用いたファイアウォールなら、
IP アドレスの問題を気にすること無く、 DSL/ISDN ルータの
下流側に置くように設定できます。
ブリッジを設定する
ネットワークインタフェイスカードの選択
ブリッジを利用するには少なくとも二つのネットワークカードが
必要です。
残念なことに、 FreeBSD 4.0 ではすべてのネットワークインタフェイス
カードがブリッジ機能をサポートしているわけではありません。
カードがサポートされているかどうかについては &man.bridge.4;
を参照してください。
以下に進む前に、 二つのネットワークカードをインストールして
テストしてください。
カーネルコンフィグレーションの変更
カーネルでブリッジ機能を有効にするには
options BRIDGE
という行をカーネルコンフィグレーションファイルに追加して
カーネルを再構築してください。
ファイアウォール機能
ブリッジと同時にファイアウォール機能も利用しようとしている
場合には、 IPFIREWALL オプションも指定する必要があります。
ブリッジをファイアウォールとして設定する際の一般的な
情報に関しては、
を参照してください。
IP 以外のパケット (ARP など) がブリッジを通過するように
するためには、 ドキュメント化されていないファイアウォール用
オプションを設定する必要があります。 このオプションは
IPFIREWALL_DEFAULT_TO_ACCEPT です。
この変更により、 デフォルトではファイアウォールがすべての
パケットを accept するようになることに注意してください。
この設定を行う前に、 この変更が自分のルールセットにどのような
影響をおよぼすかを把握しておかなければなりません。
帯域制御機能
ブリッジで帯域制御機能を利用したい場合、
カーネルコンフィグレーションで DUMMYNET
オプションを加える必要があります。
詳しい情報に関しては &man.dummynet.4; を参照
してください。
ブリッジを有効にする
ブリッジを有効にするには、
/etc/sysctl.conf に以下の行を加えてください:
net.link.ether.bridge=1
ブリッジを経由したパケットを ipfw でフィルタしたい場合には、
net.link.ether.bridge_ipfw=1
という行も付け加える必要があります。
パフォーマンス
私のブリッジ/ファイアウォールは Pentium 90 で、
3Com 3C900B と 3c905B を使っています。
防護される側のネットワークは 10Mbps の half duplex で、
ブリッジとルータ (Cisco 675) の間は 100Mbps full duplex で
動作しています。
パケットフィルタを利用しない場合、 防護されている 10Mbps
ネットワークから Cisco 675 への ping では、
ブリッジにより 0.4 ミリ秒の遅延が発生しています。
その他の情報
ネットワークからブリッジに telnet したい場合、
ネットワークカードの一つに IP アドレスを割り当てれば OK です。
一般的に、 両方のカードに IP アドレスを割り当てるのは
よいアイデアではないとされています。
ネットワーク内に複数のブリッジを設置する場合、
任意のワークステーション間で一つ以上の経路を持つことは
できません。 技術的には、 これは spanning tree link management
はサポートされていない、 ということを意味します。
NFS
Written by &a.unfurl;, 4 March 2000.
FreeBSD がサポートしている多くのファイルシステムの中でも、
NFS、 すなわち Network File System は極めてユニークな存在です。
NFS はあるマシンから他のマシンへと、 ネットワークを通じて
ディレクトリとファイルを共有することを可能にします。
NFS を使うことで、 ユーザやプログラムはリモートシステムのファイルを、
それがローカルファイルであるかのようにアクセスすることができます。
NFS には以下の利点があります:
一般的に使われるデータを単一のマシンに納める
ことができ、 ネットワーク上のユーザはデータにアクセスできる
ため、 ローカルワークステーションは多くのディクスを
必要としません。
ネットワーク上のすべてのマシンに、
ユーザが独自のホームディレクトリを持つ必要がありません。
一旦 NFS 経由でアクセスできるディレクトリができれば、
どこからでもアクセス可能です。
フロッピーや CD-ROM ドライブなどのストレージデバイスを、
追加のハードウェアなしにネットワーク上の他のマシンに
使ってもらうことができます。
どのようにして動作するのか
NFS はクライアント、 サーバの二つの部分から
構成されます。
これは 需要(want)/供給(have) の関係として考えることができます。
クライアントはサーバが 供給 している
データに対する 需要 があります。
サーバはそのデータをクライアントと共有します。
このシステムが適切に機能するために、 いくつかのプロセスが
設定され正しく動作していなければなりません。
サーバは以下のデーモンを動作させなければなりません:
nfsd - NFS クライアントからの
リクエストを処理する NFS デーモン。
mountd - nfsd から渡された
リクエストを実際に実行する NFS マウントデーモン。
portmap - NFS サーバの利用しているポートを
NFS クライアントから取得できるようにするためのポートマッパデーモン。
クライアント側ではデーモンを一つ実行する必要があります:
nfsiod - NFS サーバからのリクエストを
処理する NFS 非同期 I/O デーモン。
NFS を設定する
幸運なことに、 FreeBSD システムで設定を行うのは簡単です。
実行させなければならないプロセスは、 /etc/rc.conf
ファイルをちょっと編集することでブート時から実行させる
ことができます。
NFS サーバでは、 以下の設定が必要です:
portmap_enable="YES"
nfs_server_enable="YES"
nfs_server_flags="-u -t -n 4"
mountd_flags="-r"
mountd は NFS サーバが有効になっている
場合、 自動的に実行されます。
nfsd への
、 フラグは
クライアントに UDP と TCP のサービスを提供することを指示します。
フラグは nfsd
が 4 つのコピーを立ち上げることを指示します。
クライアント側では、 以下のようにします:
nfs_client_enable="YES"
nfs_client_flags="-n 4"
nfsd と同様に、
は nfsiod
が 4 つのコピーを立ち上げることを指示します。
最後に /etc/exports という
設定ファイルを作成します。
exports ファイルはサーバのどのファイルシステムが
共有されるのか (exported
といいます)、
またどのクライアントが共有できるのかを指定します。
ファイル中の各行は、 共有されるファイルシステムを
指定します。
ファイル中で指定できるオプションはたくさんありますが、
そのうちの少ししか使うことはないでしょう。
より細かいことに関しては &man.exports.5;
マニュアルページをお読み下さい。
いくつか /etc/exports の設定例
を示します:
以下の設定は、
サーバと同じドメイン名(ドメイン名が無いので)か、
/etc/hosts に記述のある三つのマシン
に対して、 /cdrom を export します。
オプションは共有されるファイルシステムを
読み込み専用にします。
このフラグにより、 リモートシステムは共有されたファイルシステム
にたいして何の変更も行えなくなります。
/cdrom -ro moe larry curly
以下の設定は、 IP アドレスによる三つのホストに対して
/home を export します。
この設定はプライベートネットワークで DNS が走っていない
場合に便利な設定でしょう。
フラグは指定されたファイルシステム
以下のディレクトリに対しても同様に export します。
/home -alldirs 10.0.0.2 10.0.0.3 10.0.0.4
以下の設定は、 サーバとは異なるドメイン名の二つの
マシンに対して /a を export します。
フラグは、 リモートマシンの
root ユーザが共有されたファイルシステムに root として書き込むことを
許可します。
-maproot=0 フラグが無ければ、 リモートマシンの root 権限を
持っていても共有されたファイルシステム上のファイルを変更する
ことはできません。
/a -maproot=0 host.domain.com box.example.com
クライアントが export されたファイルシステムを共有
する際には、 そのような権限が与えられていなければなりません。
/etc/exports ファイルに
クライアントが含まれているかどうか確認してください。
必要な変更はすべて行ったので、
FreeBSD を再起動してブート時からすべてが起動するようにするか、
root で以下のコマンドを実行します:
NFS サーバでは:
&prompt.root; portmap
&prompt.root; nfsd -u -t -n 4
&prompt.root; mountd -r
NFS クライアントでは:
&prompt.root; nfsiod -n 4
これでリモートのファイルシステムを実際にマウントする
準備ができました。
やり方は二通りあります。
この例では、 サーバの名前は server で、
クライアントの名前は client とします。
リモートファイルシステムを一時的にマウントするだけ、
もしくは設定をテストするだけなら、 クライアント上で root
として以下のコマンドを実行してください:
&prompt.root; mount server:/home /mnt
これにより、 クライアントの /mnt
ディレクトリにサーバの /home が
マウントされます。
もしすべてが正しく設定されていれば、 クライアントの /mnt
に、 サーバにあるファイルすべてが見えるようになっているはずです。
リモートファイルシステムを今後も (リブートする度に)
マウントしたいなら、 /etc/fstab
ファイルに設定を追加する必要があります。
例としてはこのようになります:
server:/home /mnt nfs rw 0 0
ほかのオプションに関しては &man.fstab.5; マニュアル
ページをお読み下さい。
典型的な使い方
NFS にはいくつかすてきな使い方があります。
私は自分が管理している LAN でそれらを利用しています。
そのうちにいくつかをここで紹介しましょう。
ネットワークには幾つかのマシンがありますが、
CD-ROM ドライブを持っているのは一台だけです。
なぜかって? それは一台の CD-ROM ドライブをほかのマシンと
NFS 経由で共有しているからです。
フロッピードライブについても同じことがいえます。
ネットワーク内に多くのマシンがあると、 様々な場所に
ちらばる個人的なファイルは日に日に古くなってしまいます。
私はすべてのユーザのホームディレクトリを格納する、
中心となる NFS サーバを用意し、 LAN 上の残りのマシンと
共有しています。 そうすることで、 どこにログインしても、
同じホームディレクトリを使うことができるのです。
マシンのひとつに FreeBSD を再インストールするなら、
NFS こそその方法です。 ディストリビューション CD をファイル
サーバに入れ、 再インストールを実行するだけです。
共用の /usr/ports/distfiles
ディレクトリを用意して、 すべてのマシンで共有しています。
この方法だと、 別のマシンで既にインストールしたことのある
port をインストールする場合、 再びすべてのソースをダウンロードする
必要がなくなります。
Problems integrating with other systems
原作: John Lind john@starfire.MN.ORG.
訳: &a.jp.tomo;.
6 September 1996.
ISA用のイーサネットアダプタの中には性能が悪いため、
ネットワーク、 特に NFS で深刻な問題がおきるものがあります。
これは FreeBSD に限ったことではありませんが、 FreeBSD
でも起こり得ます。
この問題は、
(FreeBSDを使用した) PC がシリコン・グラフィックス社や
サン・マイクロシステムズ社などの高性能な WS
にネットワーク接続されている場合に頻繁に起こります。
NFS マウントはうまく行きます。 また、
いくつかの操作もうまく働きますが、 他のシステム (WS)
に対する要求や応答は続いていても、 突然サーバが
クライアントの要求に対して反応しなくなります。
これは、 クライアントが FreeBSD か上記の WS であるとき、
にクライアント側に起きる現象です。
多くのシステムでは、 いったんこの問題が現われると、
行儀良くクライアントを終了する手段はありません。
NFS がこの状態に陥ってしまうと、 正常に戻すことはできないため、
多くの場合、 クライアントを強制終了し、
再び実行することが唯一の解決法となります。
正しい
解決法は、
より高性能のイーサネットアダプタをFreeBSDシステムに
インストールすることですが、
満足な操作ができるような簡単な方法があります。 もし、
FreeBSDシステムがサーバになるのなら、
クライアントからのマウント時に
オプションをつけて下さい。
もしFreeBSDシステムがクライアントになる
のなら、 NFSファイルシステムを
オプションつきでマウントして下さい。
これらのオプションは自動的にマウントをおこなう場合には
クライアントの fstab
エントリの4番目のフィールドに指定してもよいですし、
手動マウントの場合は mount コマンドの
パラメータで指定してもよいでしょう。
NFSサーバとクライアントが別々のネットワーク上にあるような
場合、 これと間違えやすい他の問題が起きることに注意して下さい。
そのような場合は、 ルータが必要な UDP 情報をきちんと
ルーティングしているかを確かめて下さい。
そうでなければ、 たとえあなたが何をしようと解決できないでしょう。
次の例では、 fastwsは高性能のWSのホスト
(インタフェース)名で、
freeboxは低性能のイーサネットアダプタを備えた
FreeBSDシステムのホスト(インタフェース)名です。
また、 /sharedfs はエクスポートされる
NFS ファイルシステムであり (man exports
を見て下さい)、 /project
はエクスポートされたファイルシステムの
クライアント上のマウントポイントとなります。
全ての場合において、 や 、
といった追加オプションが
アプリケーションにより要求されるかもしれないことに
注意して下さい。
クライアント側 FreeBSD システム (freebox)
の例は:
freebox の /etc/fstab
に次のように書いて下さい:
fastws:/sharedfs /project nfs rw,-r=1024 0 0
freebox 上で手動で mount
コマンドを実行する場合は次のようにして下さい:
&prompt.root; mount -t nfs -o -r=1024 fastws:/sharedfs /project
サーバ側FreeBSDシステムの例は: fastws の
/etc/fstab に次のように書いて下さい:
freebox:/sharedfs /project nfs rw,-w=1024 0 0
fastws 上で手動で mount
コマンドで実行する場合は次のようにして下さい:
&prompt.root; mount -t nfs -o -w=1024 freebox:/sharedfs /project
近いうちにどのような 16 ビットのイーサネットアダプタでも
上記の読み出し、
書き込みサイズの制限なしの操作ができるようになるでしょう。
失敗が発生したとき何が起きているか関心のある人に、
なぜ回復不可能なのかも含めて説明します。 NFSは通常
(より小さいサイズへ分割されるかもしれませんが)
8Kのブロック
サイズで働きます。
イーサネットのパケットサイズは最大1500バイト程度なので、
上位階層のコードにとっては1つのユニットのままなのですが、
NFS ブロック
は
複数のイーサネットパケットに分割されます。 そして受信され、
組み立て直されてから肯定応答
されなければなりません。
高性能のWSは次々に NFSユニットを構成するパケットを、
基準の範囲内で間隔を詰めて次々に送り出すことができます。 小さく、
容量の低いカードでは、 同じユニットの
前のパケットがホストに転送される前に、 後のパケットがそれを
踏みつぶしてしまいます。
このため全体としてのユニットは再構成もされないし、
肯定応答もされません。 その結果、
WSはタイムアウトして再送を試みますが、
8Kのユニット全体を再送しようとするので、 このプロセスは
際限無く繰り返されてしまいます。
ユニットサイズをイーサネットのパケットサイズの
制限以下に抑えることにより、 受信された完全な
イーサネットパケットは個々に肯定応答を受けられることが
保証されるので、
デッドロック状態を避けることができるようになります。
高性能のカードを使っている場合でも、 高性能な WS
が力任せに次々と PC システムにデータを送ったときには
踏みつぶし が起きるかもしれません。
そのような踏みつぶし
は NFS ユニット
では保証されていません。
踏みつぶしが起こったとき、
影響を受けたユニットは再送されます。 そして受信され、
組み立てられ、
肯定応答される公平な機会が与えられるでしょう。
Diskless operation
原作: &a.martin;
訳: &a.jp.yasu;
netboot.com/netboot.rom
によって、 ディスクのないクライアントでネットワーク経由で
FreeBSD マシンのブートを行い FreeBSD を走らせることができます。
2.0 ではローカルなスワップを持つことができます。
NFS 経由のスワッピングもサポートされています。
サポートされているイーサネットカード:
Western Digital/SMC 8003, 8013, 8216 とその互換ボード,
NE1000/NE2000 とその互換カード (再コンパイルが必要)
セットアップの手順
サーバにするマシンを見つけます。
このマシンには、 FreeBSD 2.0のバイナリとbootpを
記憶するだけの十分なディスクスペースが必要です。
tftp と NFS も使えます。
テストしたマシン:
HP9000/8xx / HP-UX 9.04以降
(9.04以前では動きません)
Sun/Solaris 2.3. (bootpが必要)
クライアントにIP、gateway、netmaskを提供する
bootpサーバをセットアップします。
diskless:\
:ht=ether:\
:ha=0000c01f848a:\
:sm=255.255.255.0:\
:hn:\
:ds=192.1.2.3:\
:ip=192.1.2.4:\
:gw=192.1.2.5:\
:vm=rfc1048:
クライアントにブート情報を提供する TFTP サーバを
(bootp サーバと同じマシンに) セットアップします。
このファイルの名前は、
cfg.X.X.X.X
(もしくは
/tftpboot/cfg.X.X.X.X
)で、
ここで X.X.X.X はクライアントの
IP アドレスです。
このファイルの内容は netboot コマンドで有効です。
2.0では、 netboot は以下のようなコマンドを持ちます:
help
helpリストの表示
ip
クライアントのIPアドレスの表示/セット
server
bootp/tftp サーバのアドレスの表示/セット
netmask
netmaskの表示/セット
hostname name
hostnameの表示/セット
kernel
カーネル名の表示/セット
rootfs
root ファイルシステムの表示/セット
swapfs
swap ファイルシステムの表示/セット
swapsize
diskless swapsize を KBytes単位でセット
diskboot
ディスクからのブート
autoboot
ブートプロセスの続行
trans
|
トランシーバのオン|オフ
flags
ブートフラグの設定
完全にディスクレスな場合の一般的な cfg
ファイルは以下のようになります:
rootfs 192.1.2.3:/rootfs/myclient
swapfs 192.1.2.3:/swapfs
swapsize 20000
hostname myclient.mydomain
ローカルに swap
を持つマシンについては以下のようになります:
rootfs 192.1.2.3:/rootfs/myclient
hostname myclient.mydomain
NFS サーバがクライアントにroot(必要ならswapも)
ファイルシステムをexportしているか、 また、
クライアントがこれらのファイルシステムに
ルートアクセスできるか確認します。 FreeBSDにおける一般的な
/etc/exports ファイルは
以下のようになります:
/rootfs/myclient -maproot=0:0 myclient.mydomain
/swapfs -maproot=0:0 myclient.mydomain
そして、 HP-UX側では以下のようになります:
/rootfs/myclient -root=myclient.mydomain
/swapfs -root=myclient.mydomain
NFS経由でスワッピングを行う場合
(完全にディスクレスな場合の設定)、 クライアントが使用する
swap ファイルを dd で作成します。
もし、 swapfs コマンドが上記の例のように
引数 /swapfsを持ちそのサイズが 20000
である場合、 myclientに対するスワップファイルは
/swapfs/swap.X.X.X.X
で呼び出されます。 ここで
X.X.X.X はクライアントの IP
アドレスです。 例:
&prompt.root; dd if=/dev/zero of=/swapfs/swap.192.1.2.4 bs=1k count=20000
また、 スワッピングが開始されるとクライアントの
スワップスペースはセンシティブな情報を含むようになるので、
不正なアクセスを防止するため、 このファイルへの
読み書きのアクセス制限がなされていることを確認して下さい:
&prompt.root; chmod 0600 /swapfs/swap.192.1.2.4
クライアントがそれぞれのrootファイルシステムとして使う
ディレクトリにrootファイルシステムを展開します
(上記の例では/rootfs/myclient)。
HP-UX システム: サーバはHP9000/800
シリーズのマシンで、 HP-UX 9.04 以降が必要です。
これ以前のバージョンでは NFS
を経由するデバイスファイルが作成ができません。
/rootfs/myclient に
/dev を
展開する際に、 いくつかのシステム (HPUX) では
FreeBSD に合った デバイスファイルが作成されないので
注意してください。
その際には最初の起動時にシングルユーザモードに
移行して (ブートの段階でCtrl-Cを押す)、
/dev に移って
sh ./MAKEDEV all として、
クライアントからこれを 修正してください。
クライアントで netboot.com
を実行するか、 netboot.rom
ファイルから EPROMを作成します。
<filename>/</filename> および <filename>/usr</filename>
ファイルシステムを共有して使用する
今のところ、 これを行う公式に認められた方法はありませんが、
私はそれぞれのクライアントで /usr
ファイルシステムと個々の /
ファイルシステムを共有して使っています。
どなたかこれをきちんと行うやり方の提案がありましたら、
私に、 もしくは &a.core; グループに知らせてください。
特定の設定についてnetbootをコンパイルする
/sys/i386/boot/netboot/Makefile
の中の設定を変更して
コンパイルすることで、 netbootでNE1000/2000
カードをサポートします。
このファイルの先頭にあるコメントを見てください。
ISDN
最終更新: Bill Lloyd wlloyd@mpd.ca.
訳: &a.jp.kiroh;.
11 December 1996.
ISDN 技術とハードウェアに関しては、
Dan Kegel's ISDN Page がよい参考になるでしょう。
ISDN の導入手順は、 簡単にいって以下のようになります。
ヨーロッパ在住の方は、 ISDN
カードの節に進んでください。
ISDN を使って、
インターネットプロバイダに(専用線は使用せず)、 ダ
イアルアップ接続しようとしている場合は、
ターミナルアダプタの使用を考えてみてください。
この方法はもっとも柔軟性があり、 プロバイダを変更した場
合の問題も少ないでしょう。
2つの LAN の間を接続しようする場合や、 ISDN
専用線を使用する場合 には、
スタンドアローンルータ/ブリッジの使用を勧めます。
どの方法を用いるかを決定するには、
費用が重要な要素になってきます。 以下に、 最も安価な方法から、
高価な方法まで順に説明していきます。
ISDN カード
著者:&a.hm;.
このセクションの記述は、 DSS1/Q.931 ISDN
標準がサポートされている国のユーザにのみ有効です。
最近増えてきている PC ISDN カードのうちいくつかは、 FreeBSD
2.2.x 以降で isdn4bsd
ドライバパッケージによりサポートされています。
依然として開発中ではありますが、
ヨーロッパ中でうまく動作しているという報告があります。
最新の isdn4bsd は、
ftp://isdn4bsd@ftp.consol.de/pub/ から入手できます。
この ftp サイトでは、 ユーザ名として isdn4bsd
を使い、 パスワードにメールアドレスを使ってログインする
必要があります。 ログインできたら pub
ディレクトリに移動してください。 ユーザー名
ftp や anonymous
によるログインでは、 必要なファイルにたどりつけません。
isdn4bsd は、 IP over raw HDLC もしくは同期 PPP
を利用して他の ISDN ルータと接続できます。
留守番電話アプリケーションも使えます。
Siemens ISDN チップセット (ISAC/HSCX)
を使用したものを主に多くのカードがサポートされています。
他のチップセット (Motorola、 Cologn ChipDesigns)
のサポートは現在開発中です。
サポートされるカードの最新のリストは、
README
を参照してください。
他の ISDN プロトコルを追加したい場合や、
サポートされていない ISDN PC カード サポートしたい場合など
isdn4bsd を拡張したい場合は、 hm@kts.org
までご連絡ください。
majordomoによるメーリングリストが利用できます。
参加するには、 本文に
subscribe freebsd-isdn
と記入したメールを
&a.majordomo; 宛てに送ってください。
ISDN ターミナルアダプタ
ターミナルアダプタ (TA) はISDN に対して、
通常の電話線に対するモデムに相当するものです。
ほとんどの TA は、 標準のヘイズ AT
コマンドセットを使用しているので、
単にモデムと置き換えて使うことができます。
TA は、 基本的にはモデムと同じように動作しますが、
接続方法は異なり、 通信速度も古いモデムよりはるかに速くなります。
PPP の設定を、
モデムの場合と同じように行ってください。 とくにシリアル速度を
使用できる最高速度に設定するのを忘れないでください。
プロバイダへの接続に TA を使用する最大のメリットは、 動的
PPP を行えることです。 最近 IP アドレスが不足してきているため、
ほとんどのプロバイダは、 専用の IP
アドレスを割り当てないようになっています。
ほとんどのスタンドアローンルータは、 動的 IP
アドレスに対応していません。
訳注: 最近の ISDN ルータでは、 IP
アドレスの動的割り当てに対応しているものも多いようです。
ただし制限がある場合もありますので、 詳しくはメーカ
に問い合わせてください。
TA を使用した場合の機能や接続の安定性は、 使用している PPP
デーモンに完全に依存します。 そのため、 FreeBSD で PPP
の設定が完了していれば、 使用している既存のモデムを ISDN の TA
に簡単にアップグレードすることができます。 ただし、 それまでの
PPP のプログラムに問題があった場合、 その問題は TA
に置き換えてもそのまま残ります。
最高の安定性を求めるのであれば、 ユーザープロセス
iijPPP ではなく、 カーネル
PPPを使用してください。
以下の TA は、 FreeBSD で動作確認ずみです。
Motorola BitSurfer および Bitsurfer Pro
Adtran
他の TA もほとんどの場合うまく動作するでしょう。 TA
のメーカーでは、 TA がほとんどの標準モデム AT
コマンドセットを受け付けるようにするよう、
努力しているようです。
外部 TA を使う際の最大の問題点は、
モデムの場合と同じく良いシリアルカー
ドが必要であるということです。
シリアルデバイスの詳細、
そして非同期シリアルポートと同期シリアルポートの差については、
同期・非同期の違いやシリアルデバイスについて説明したチュートリアル FreeBSD Serial
Hardware を参照してください。
標準の PC シリアルポート(非同期)に接続された TA は、 128Kbs
の接続を行っていても、 最大通信速度が 115.2Kbs
に制限されてしまいます。 128Kbs の ISDN
の性能を最大限に生かすためには、 TA
を同期シリアルカードに接続しなければなりません。
内蔵 TA を購入して、
同期／非同期問題を片付けてしまおうとは思わないでく ださい。
内蔵 TA には、 単に標準 PC シリアルポートのチップが内蔵されてい
るだけです。 内蔵 TA の利点といえば、
シリアルケーブルを買わなくていいと いうことと、
電源コンセントが一つ少なくて済むということくらいでしょう。
同期カードと TA の組合せは 386 の FreeBSD
マシンの場合でも、 スタンドア
ローンのルータと同程度の速度は確保できます。
またこの組合せでは、 ルータより柔軟な設定が可能です。
同期カード/TA を選ぶか、 スタンドアローンルータを選ぶかは、
多分に宗教的な問題です。
メーリングリストでもいくつか議論がありました。 議論の内容に
ついては、 archives
を参照してください。
スタンドアローン ISDN ブリッジ/ルータ
ISDN ブリッジやルータは、 OS 特有のものではありません。
もちろん FreeBSD 特有のものでもありません。
ルーティングやブリッジング技術に関する詳細は、
ネットワークの参考書をご覧ください。
このページでは、
ルータとブリッジにどちらでもあてはまるように記述します。
ISDN ルータ/ブリッジは、
ローエンドの製品のコストが下がってきていることもあり、
より一般的に使用されるようになるでしょう。 ISDN ルータは、
外見は小さな箱で、
ローカルのイーサネットネットワーク(もしくはカード)と直接、
接続します。 また、
自身で他のブリッジ/ルータとの接続を制御します。 PPP
や他のプロトコルを使用するためのソフトウェアは、
すべて組み込まれています。
ルータは、 完全な同期 ISDN 接続を使用するため、 通常の TA
と比較してスループットが大幅に向上します。
ISDN ルータ/ブリッジを使用する場合の最大の問題点は、
各メーカーの製品間に相性の問題がまだ存在することです。
インターネットプロバイダとの接続を考えている場合には、
プロバイダと相談することをお勧めします。
事務所の LAN と家庭の LAN の間など、 二つの LAN
セグメントの間を接続しようとしている場合は、
ブリッジ/ルータの使用がもっともメンテナンスが 簡単で、
努力が少なくてすむ方法です。 両側の機材を購入するのであれば、
メーカー間の接続性の問題もないでしょう。
たとえば家庭の LAN や出張所の LAN
を本社のネットワークに接続するためには、
以下のような設定が使用できます。
出張所 LAN または 家庭 LAN
ネットワークは、 10 Base T イーサネットです。
ルータとネットワークの間は、 必要に応じて AUI/10BT
トランシーバを使って接続します。
---Sun ワークステーション
|
---FreeBSD マシン
|
---Windows 95 (別に勧めているわけじゃありません)
|
スタンドアローンルータ
|
ISDN BRI ライン
家庭/出張所 LAN で、
一台しかコンピュータを接続しないのであれば、 クロス
のツイストペアケーブルを使用して、
スタンドアローンルータと直結も可能です。
本社 LAN や他の LAN
ネットワークは、 ツイストペアイーサネットです。
-------Novell サーバ
| |
|ハ ---Sun
| |
| ---FreeBSD
| |
|ブ ---Windows 95
| |
|___---スタンドアローンルータ
|
ISDN BRI ライン
ほとんどのルータ/ブリッジでは、 別々の二つのサイトに対して、
同時にそれ
ぞれ独立した二つの PPP 接続が可能です。
これは、 通常の TA ではサポートされない機能で、
ルータ/ブリッジ接続の大きな利点です (シリアルポートを
二つもつ特殊(そして高価な) TA では可能です)。
チャンネル割り当てや MPP などと混同しないでください。
これは、 大変便利な機能です。
たとえば事務所で専用線 ISDN 接続を使用していて、
別の ISDN ラインを購入したくないとします。 この場合、
事務所のルータは、 一つの専用線 B
チャンネル接続(64Kbs)を維持しつつ、 別 の B
チャンネルを他の用途に使用することができます。 たとえば、
他の場所 とのダイアルイン、 ダイアルアウトに使用したり、
バンド幅を増やすために、
- インターネットとの接続への動的に割り当て(MPP
+ インターネットとの接続への動的な割り当て(MPP
など)に使用したりすることが可能です。
またイーサネットブリッジは、 IP パケットだけでなく IPX/SPX
などすべての
プロトコルのパケットを中継することが可能です。
NIS/YP
原作: &a.unfurl;,
2000 年 1 月 21 日,
監修: Eric Ogren eogren@earthlink.net,
Udo Erdelhoff ue@nathan.ruhr.de,
2000 年 6 月.
NIS/YP とは?
NIS とは Network Information Services の略で
Sun Microsystems によって Unix の (もともとは SunOS の)
集中管理のために開発されました。 現在では事実上の業界標準になっており、
主要な Unix は (Solaris、 HP-UX、 AIX、 Linux、 NetBSD、 OpenBSD、
FreeBSD、 等々) すべてこれをサポートしています。
NIS は元々、 イエローページ (または yp) として知られていましたが、
著作権を侵害しているとして Sun はその名を変えさせられました。
NIS は RPC を使ったクライアント/サーバシステムです。
これを使うと NISドメイン内のマシン間で、
共通の設定ファイルを共有することができます。
また、 NIS を使うことでシステム管理者は最小限の設定データで
NIS クライアントを立ち上げることができ、
1 ヶ所から設定データの追加、 削除、 変更が可能です。
NIS は Windows NT のドメインシステムに似ています。
内部の実装は似ても似つかないものですが、 基本的な機能を
対比することはできます。
知っておくべき用語 / プロセス
NIS サーバの立ち上げや NIS クライアントの設定など、
NIS を FreeBSD に導入するにあたって、
目にするであろう用語や重要なユーザプロセスがいくつかあります。
NIS ドメイン名. NIS マスターサーバ一つと
そのクライアント (スレーブサーバを含む) は一つの NIS ドメイン名を
持ちます。 NT のドメイン名同様、
NIS ドメイン名は DNS とは何の関係もありません。
portmap. portmap
は RPC (Remote Procedure Call、 NIS
で使われるネットワークプロトコル)
を利用するために実行しておかなければなりません。
portmap が動いていなければ、
NIS サーバの起動もクライアントとしての機能も得られません。
ypbind. ypbind
は NIS クライアントを NIS サーバに結び付け
ます。
これは NIS ドメイン名をシステムから受け、 RPC
を用いてサーバに接続します。 ypbind
はクライアントとサーバのコミュニケーションの中枢であり、
もしクライアントマシンの ypbind
が機能を停止した場合は
NIS サーバへアクセスできなくなります。
ypserv. ypserv
は NIS サーバでのみ実行されるもので、 NIS
のサーバプロセスそのものです。 ypserv が機能を停止したときは、
サーバは NIS リクエストに答えられなくなります
(運が良ければ、 スレーブサーバがいて代わりを努めるでしょう)。
今まで使っていたサーバが機能を停止したとき、
別のサーバに再接続しに行かない NIS の実装もいくつかあります
(FreeBSD のものは違います)。
そのような場合に復帰するための唯一の方法は、
サーバプロセス (あるいはサーバ全体)、 もしくはクライアントの
ypbind
プロセスを再スタートすることです。
rpc.yppasswdd.
rpc.yppasswdd は NIS
マスターサーバで動かされるべきもう一つのプロセスで、
NIS クライアントから
NIS パスワードを変更させるデーモンです。
このデーモンが動いていないときは、 ユーザは NIS マスターサーバに
login し、 そこでパスワードを変更することになります。
動作のしくみ
NIS 環境にあるホストは、 次の 3 種類に分類されます。 それは、
マスターサーバ、 スレーブサーバ、 クライアントです。
サーバは、 ホストの設定情報の中心的な情報格納庫の役割をします。
マスターサーバは元となる信頼できる情報を保持し、
スレーブサーバは、 冗長性を確保するため、 この情報をミラーします。
そしてクライアントは、 サーバから情報の提供を受けて動作します。
この方法を用いることで、 数多くのファイルにある情報が共有できます。
よく NIS で共有されるのは、
master.passwd や group、
hosts といったファイルです。
クライアント上のプロセスで、 通常ローカルのファイルにある情報が必要
となったとき、
クライアントは接続しているサーバに問い合わせを行い、 その情報を得ます。
マシンの分類
NIS マスターサーバ.
このサーバは Windows NT で言うところのプライマリ
ドメインコントローラにあたります。
すべての NIS クライアントで利用されるファイルを保守し、
passwd や
group、 その他 NIS
クライアントが参照するファイルは、
マスターサーバにあります。
一つのマシンが一つ以上の NIS
ドメインのマスターサーバになることは可能です。
しかし、 ここでは比較的小規模の NIS 環境を対象としているため、
そのような場合については扱いません。
NIS スレーブサーバ。
NT で言うところのバックアップドメインコントローラに似たもので、
NIS スレーブサーバは NIS
マスターサーバのデータファイルのコピーを保持します。
NIS スレーブサーバは重要な環境で必要とされる冗長性を提供し、
マスターサーバの負荷のバランスをとります。
NIS クライアントは常に最初にレスポンスを返したサーバを
NIS サーバとして接続しますが、
これにはスレーブサーバも含まれます。
NIS クライアント。
NIS クライアントは大部分の NT ワークステーションのように、
logon に際して
NIS サーバに対して (NT ワークステーションの場合では NT
ドメインコントローラに) 認証します。
NIS/YP を使う
この節では NIS 環境の立ち上げ例を取り上げます。
この節ではあなたが FreeBSD 3.3 以降を使っているものとします。
ここで与えられる指示はおそらく FreeBSD の
3.0 以降の、 どのバージョンでも機能するでしょうが、
それを保証するものではありません。
計画を立てる
あなたが大学の小さな研究室の管理人であるとしましょう。
この研究室は 15 台の FreeBSD マシンからなっていて、
現在はまだ集中管理されていません。
すなわち、 各マシンは /etc/passwd と
/etc/master.passwd を各々が持っています。
これらのファイルは手動でお互いに同期させています。
つまり現時点では、 新しいユーザをあなたが追加するとき、
adduser を 15 ヶ所すべてで実行しなければなりません。
これは明らかに変える必要があるため、
あなたはこのうち 2 台をサーバにして NIS を導入することを決めました。
その結果、 研究室の設定はこのようなものになります:
マシンの名前
IP address
役割
ellington
10.0.0.2
NIS マスタ
coltrane
10.0.0.3
NIS スレーブ
basie
10.0.0.4
教員用のワークステーション
bird
10.0.0.5
クライアントマシン
cli[1-11]
10.0.0.[6-17]
その他のクライアントマシン
もし NIS によるシステム管理の設定を行なうのが初めてなら、
どのようにしたいのか、 ひととおり最後まで考えてみることをお勧めします。
ネットワークの規模によらず、 いくつか決めるべきことがあるからです。
NIS ドメイン名を決める
ここでいうドメイン名は、 今まであなたが使っていた、
いわゆる ドメイン名
と呼んでいたものとは違います。
正確には NIS ドメイン名
と呼ばれます。
クライアントがサーバに情報を要求するとき、
その要求には自分が属する NIS ドメインの名前が含まれています。
これは、 1 つのネットワークに複数のサーバがある場合に、
どのサーバが要求を処理すれば良いかを決めるために使われます。
NIS ドメイン名とは、 関連のあるホストをグループ化するための名前である、
と考えると良いでしょう。
組織によってはインターネットのドメイン名を
NIS ドメイン名に使っているところがありますが、
これはネットワークのトラブルをデバッグするときに混乱の原因となるため、
お勧めできません。
NIS ドメイン名はネットワーク内で一意でなければならないので、
ドメイン名がドメインに含まれるマシンを表すようなものであれば、
分かりやすくなります。 たとえば
Acme 社のアート(Art)部門であれば、
NIS ドメイン名を"acme-art"とすれば良いでしょう。
しかしながら、 オペレーティングシステムによっては、
そのネットワークドメイン名を NIS
のドメイン名として使うものもあります (特に SunOS)。
あなたのネットワークにそのような制限のあるマシンが 1 台でもあるときは、 NIS
のドメイン名としてインターネットのネットワークドメイン名を使わなければいけません。
サーバマシンの物理的な条件とは
NIS サーバとして使うマシンを選ぶ際には、
いくつかの注意点があります。
NIS における困ったことの一つに、
クライアントのサーバへの依存度があります。
クライアントが自分の NIS ドメインのサーバに接続できない場合、
マシンが使用不能になることがよくあります。
もし、 ユーザやグループに関する情報が得られなければ、
ほとんどのシステムは一時的にですが停止してしまいます。
こういったことを念頭に置いて、
しょっちゅうリブートされるマシンや、
開発に使われそうなマシンを選ばないようにしなければなりません。
理想的には、 NIS サーバはスタンドアロンで
NIS サーバ専用となるマシンにするべきです。
ネットワークの負荷が重くなければ、
他のサービスを走らせているマシンを NIS
サーバにしてもかまいません。 ただし NIS
サーバが使えなくなると、
すべてのクライアントに影響をおよぼす、
という点には注意しなければなりません。
NIS サーバ
元となるすべての NIS 情報は、
NIS マスターサーバと呼ばれる 1 台のマシンに置かれます。
この情報が格納されるデータベースを NIS マップと呼びます。
FreeBSDでは、 このマップは
/var/yp/[domainname] に置かれます。
[domainname] は、
サーバがサービスする NIS ドメインです。
1 台の NIS サーバが複数のドメインをサポートすることも可能です。
つまり、 このディレクトリを各々のドメインごとに作ることができ、
各ドメインごと、 独立したマップの集合を持つことになります。
NIS のマスターサーバとスレーブサーバ上では、
ypserv デーモンがすべての NIS 要求を処理します。
ypserv は NIS クライアントからの要求を受け付け、
ドメイン名とマップ名を対応するデータベースファイルへのパスに変換し、
データをクライアントに返送します。
NIS マスターサーバの設定
やりたいことにもよりますが、
NIS マスターサーバの設定は比較的単純です。
FreeBSD は初期状態で NIS に対応しています。
必要なことは以下の行を /etc/rc.conf に追加し、
FreeBSD をリスタートすることだけです。
nisdomainname="test-domain"
この行はネットワークのセットアップ時に
(すなわち再起動したときに) NIS のドメイン名を
test-domain
にセットします。
nis_server_enable="YES"
これは FreeBSD に、 次にネットワークが立ち上がったとき NIS
のサーバプロセスを起動させます。
nis_yppasswdd_enable="YES"
これは rpc.yppasswdd デーモンを有効にします。
上述したようにこれはユーザが NIS
のパスワードをクライアントのマシンから変更することを可能にします。
あと、 あなたがしなければいけないことはスーパユーザ権限でコマンド
/etc/netstart を実行することです。
これにより /etc/rc.conf
で定義された値を使ってすべての設定が行なわれます。
NIS マップの初期化
NIS マップ とは
/var/yp ディレクトリにあるデータベースファイルです。
これらは NIS マスタの /etc
ディレクトリの設定ファイルから作られます。
唯一の例外は
/etc/master.passwd ファイルです。
これは、 root や他の管理用アカウントのパスワードまでその
NIS ドメインのすべてのサーバに伝えたくないという、
もっともな理由によるものです。 このため NIS
マップの初期化の前に以下を行う必要があります。
&prompt.root; cp /etc/master.passwd /var/yp/master.passwd
&prompt.root; cd /var/yp
&prompt.root; vi master.passwd
あなたはシステムに関するアカウント (bin、 tty、 kmem、 games、 etc)
をすべて削除しなければなりません。
またあなたが NIS クライアントに伝えたくないと思うアカウント
(たとえば root や他の UID が 0 (スーパユーザ) のアカウント)
についても削除する必要があります。
/var/yp/master.passwd が
グループや全世界から読めるようになっていないようにしてください
(モード 600)! 必要なら chmod コマンドを
使ってください。
すべてが終わったらマップを初期化します!
FreeBSD には、 これを行うために ypinit
という名のスクリプトが含まれています
(詳細はそのマニュアルページをご覧ください)。
このスクリプトはほとんどの UNIX OS で存在しますが、
すべてとは限らないことを覚えておいてください。
Digital Unix/Compaq Tru64 Unix では
ypsetup と呼ばれています。
NIS マスタのためのマップを作るためには
オプションを ypinit
に与えます。 上述のステップを完了しているなら、
以下を実行して NIS マップを生成します。
ellington&prompt.root; ypinit -m test-domain
Server Type: MASTER Domain: test-domain
Creating an YP server will require that you answer a few questions.
Questions will all be asked at the beginning of the procedure.
Do you want this procedure to quit on non-fatal errors? [y/n: n] n
Ok, please remember to go back and redo manually whatever fails.
If you don't, something might not work.
At this point, we have to construct a list of this domains YP servers.
rod.darktech.org is already known as master server.
Please continue to add any slave servers, one per line. When you are
done with the list, type a <control D>.
master server : ellington
next host to add: coltrane
next host to add: ^D
The current list of NIS servers looks like this:
ellington
coltrane
Is this correct? [y/n: y] y
[..output from map generation..]
NIS Map update completed.
ellington has been setup as an YP master server without any errors.
ypinit は
/var/yp/Makefile を
/var/yp/Makefile.dist から作成します。
作成されていれば、
そのファイルはあなたが扱っているのが FreeBSD
のみからなる、
サーバが一つだけの NIS 環境であるという前提に立っています。
test-domain
はスレーブサーバを一つ持っていますので、
/var/yp/Makefile
を編集する必要があります。
ellington&prompt.root; vi /var/yp/Makefile
`NOPUSH = "True"'
としている行を (もし既にコメントアウトされていないならば)
コメントアウトしなければなりません。
NIS スレーブサーバの設定
NIS スレーブサーバの設定はマスターサーバの設定以上に簡単です。
スレーブサーバにログオンし /etc/rc.conf
ファイルを前回と同様に編集します。 唯一の違うところは
ypinit の実行に
オプションを使わなければいけないことです。
オプションは NIS
マスターサーバの名前を要求し、 コマンドラインは以下のようになります。
coltrane&prompt.root; ypinit -s ellington test-domain
Server Type: SLAVE Domain: test-domain Master: ellington
Creating an YP server will require that you answer a few questions.
Questions will all be asked at the beginning of the procedure.
Do you want this procedure to quit on non-fatal errors? [y/n: n] n
Ok, please remember to go back and redo manually whatever fails.
If you don't, something might not work.
There will be no further questions. The remainder of the procedure
should take a few minutes, to copy the databases from ellington.
Transferring netgroup...
ypxfr: Exiting: Map successfully transferred
Transferring netgroup.byuser...
ypxfr: Exiting: Map successfully transferred
Transferring netgroup.byhost...
ypxfr: Exiting: Map successfully transferred
Transferring master.passwd.byuid...
ypxfr: Exiting: Map successfully transferred
Transferring passwd.byuid...
ypxfr: Exiting: Map successfully transferred
Transferring passwd.byname...
ypxfr: Exiting: Map successfully transferred
Transferring group.bygid...
ypxfr: Exiting: Map successfully transferred
Transferring group.byname...
ypxfr: Exiting: Map successfully transferred
Transferring services.byname...
ypxfr: Exiting: Map successfully transferred
Transferring rpc.bynumber...
ypxfr: Exiting: Map successfully transferred
Transferring rpc.byname...
ypxfr: Exiting: Map successfully transferred
Transferring protocols.byname...
ypxfr: Exiting: Map successfully transferred
Transferring master.passwd.byname...
ypxfr: Exiting: Map successfully transferred
Transferring networks.byname...
ypxfr: Exiting: Map successfully transferred
Transferring networks.byaddr...
ypxfr: Exiting: Map successfully transferred
Transferring netid.byname...
ypxfr: Exiting: Map successfully transferred
Transferring hosts.byaddr...
ypxfr: Exiting: Map successfully transferred
Transferring protocols.bynumber...
ypxfr: Exiting: Map successfully transferred
Transferring ypservers...
ypxfr: Exiting: Map successfully transferred
Transferring hosts.byname...
ypxfr: Exiting: Map successfully transferred
coltrane has been setup as an YP slave server without any errors.
Don't forget to update map ypservers on ellington.
この例の場合、 /var/yp/test-domain
というディレクトリが必要になります。
NIS マスターサーバのマップファイルのコピーはこのディレクトリに置かれますが、
あなたは、 これらが確実に最新のものに維持されるようにする必要があります。
次のエントリをスレーブサーバの /etc/crontab
に追加することで、 最新のものに保つことができます。
20 * * * * root /usr/libexec/ypxfr passwd.byname
21 * * * * root /usr/libexec/ypxfr passwd.byuid
この二行は、
スレーブサーバにあるマップファイルをマスターサーバのマップファイルと同期させるものですが、
必須というわけではありません。 なぜなら、
マスターサーバは、 NIS マップに対する変更をスレーブサーバに伝えようとするからです。
しかし、 サーバが管理するシステムにとってパスワード情報はとても重要なものですので、
強制的に更新してしまう方が良いでしょう。
特に、
マップファイルの更新がきちんと行なわれるかどうかわからないくらい混雑するネットワークでは、
重要なポイントになります。
コマンド /etc/netstart
をスレーブサーバでも実行してください。
NIS サーバを起動します。
NIS クライアント
NIS クライアントは ypbind
デーモンを使って、 特定の NIS
サーバとの間に結合 (binding) と呼ばれる関係を成立させます。
ypbind はシステムのデフォルトのドメイン
(domainname コマンドで設定されます)
をチェックし、 RPC 要求をブロードキャストパケットとしてローカルネットワークに送信します。
この RPC 要求により、 ypbind
が結合を成立させようとしているドメイン名が指定されます。
要求されているドメイン名に対してサービスするよう設定されたサーバが
ブロードキャストパケットを受信すると、
サーバは ypbind に応答し、
ypbind は応答のあったサーバのアドレスを記録します。
複数のサーバがある(たとえば一つのマスターサーバと、
複数のスレーブサーバがある)場合、
ypbind は、
最初に応答したサーバのアドレスを使用します。
これ以降、 クライアントのシステムは、
すべての NIS の要求をそのサーバに向けて送信します。
ypbind は、
サーバが順調に動作していることを確認するため、
時々 ping
をサーバに送ります。
反応が戻ってくるべき時間内に ping に対する応答が来なければ、
ypbind は、
そのドメインを結合不能(unbound)として記録し、
別のサーバを見つけるべく、 再びブロードキャストパケットの送信を行います。
NIS クライアントの設定
FreeBSD マシンにおける NIS クライアントの設定は非常に単純です。
/etc/rc.conf
ファイルを編集して以下の行を追加し、
ネットワークのセットアップ時に
NIS ドメイン名をセットして
ypbind を起動させます。
nisdomainname="test-domain"
nis_client_enable="YES"
NIS サーバにあるすべてのパスワードエントリを取り込むため、
vipw コマンドで以下の行を
/etc/master.passwd に追加します。
+:::::::::
この行によって NIS
サーバのパスワードマップにアカウントがある人全員にアカウントが与えられます。
この行を変更すると、 さまざまな NIS クライアントの設定を行なうことが可能です。
詳細は netgroups の部分を、
さらに詳しい情報については、 O'Reilly の
Managing NFS and NIS をお読みください。
NIS サーバにあるすべてのグループエントリを取り込むため、
以下の行を /etc/group に追加します。
+:*::
上記の手順がすべて完了すれば、
ypcat passwd によって
NIS サーバの passwd マップが参照できるようになっているはずです。
NIS セキュリティ
一般にドメイン名さえ知っていれば、
どこにいるリモートユーザでも ypserv に RPC を発行して
NIS マップの内容を引き出すことができます。
こういった不正なやりとりを防ぐため、
ypserv には securenets と呼ばれる機能があります。
これはアクセスを決められたホストだけに制限する機能です。
ypserv は起動時に /var/yp/securenets ファイルから
securenets に関する情報を読み込みます。
上記のパス名は、
オプションで指定されたパス名によって変わります。
このファイルは、 空白で区切られたネットワーク指定とネットマスクのエントリからなっていて、
#
で始まる行はコメントとみなされます。
簡単な securenets ファイルの例を以下に示します。
# allow connections from local host -- mandatory
127.0.0.1 255.255.255.255
# allow connections from any host
# on the 192.168.128.0 network
192.168.128.0 255.255.255.0
# allow connections from any host
# between 10.0.0.0 to 10.0.15.255
10.0.0.0 255.255.240.0
ypserv が上記のルールの一つと合致するアドレスからの要求を受け取った場合、
処理は通常に行なわれます。
もしアドレスがルールに合致しなければ、
その要求は無視されて警告メッセージがログに記録されます。
また、 /var/yp/securenets が存在しない場合、
ypserv はすべてのホストからの接続を受け入れます。
ypserv は Wietse Venema 氏による
tcpwrapper パッケージもサポートしています。
そのため、 /var/yp/securenets の代わりに
tcpwrapper の設定ファイルを使ってアクセス制御を行なうことも可能です。
これらのアクセス制御機能は一定のセキュリティを提供しますが、
どちらも特権ポートのテストのような IP spoofing
攻撃に対して脆弱です。
すべての NIS 関連のトラフィックはファイアウォールでブロックされるべきです。
/var/yp/securenets
を使っているサーバは、
古風な TCP/IP 実装を持つ正しいクライアントへのサービスに失敗することがあります。
これらの実装の中にはブロードキャストのホストビットをすべて 0 でセットしてしまったり
ブロードキャストアドレスの計算でサブネットマスクを見落としてしまったりするものがあります。
これらの問題はクライアントの設定を正しく行なうことで修正できますが、
他の問題は問題となっているクライアントシステムの撤去か
/var/yp/securenets の放棄が必要です。
このような古風な TCP/IP の実装を持つサーバで
/var/yp/securenets
を使うことは非常に悪い考えであり、
あなたのネットワークの大部分において
NIS の機能を失うことになるでしょう。
tcpwrapper
パッケージの使用はあなたの NIS サーバのレイテンシ (遅延) を増加させます。
追加された遅延は、 特に混雑したネットワークや遅い
NIS サーバでクライアントプログラムのタイムアウトを引き起こすに十分なだけ長いでしょう。
一つ以上のクライアントシステムがこれらの兆候を示したなら、
あなたは問題となっているクライアントシステムを
NIS スレーブサーバにして自分自身に結び付くように強制すべきです。
何人かのユーザのログオンを遮断する
わたしたちの研究室には basie という、
教員専用のマシンがあります。 わたしたちはこのマシンを
NIS ドメインの外に出したくないのですが、
マスタ NIS サーバの passwd
ファイルには教員と学生の両方が載っています。
どうしたらいいでしょう?
当該人物が NIS のデータベースに載っていても、
そのユーザがマシンにログオンできないようにする方法があります。
そうするには、 -username を
クライアントマシンの /etc/master.passwd
ファイルの末尾に付け足します。
username
はあなたがログインさせたくないと思っているユーザのユーザ名です。
これは vipw で行うべきです。
vipw は /etc/master.passwd
への変更をチェックし、 編集終了後パスワードデータベースを再構築します。
たとえば、 ユーザ bill が basie
にログオンするのを防ぎたいなら、 以下のようにします。
basie&prompt.root; vipw
[add -bill to the end, exit]
vipw: rebuilding the database...
vipw: done
basie&prompt.root; cat /etc/master.passwd
root:[password]:0:0::0:0:The super-user:/root:/bin/csh
toor:[password]:0:0::0:0:The other super-user:/root:/bin/sh
daemon:*:1:1::0:0:Owner of many system processes:/root:/sbin/nologin
operator:*:2:5::0:0:System &:/:/sbin/nologin
bin:*:3:7::0:0:Binaries Commands and Source,,,:/:/sbin/nologin
tty:*:4:65533::0:0:Tty Sandbox:/:/sbin/nologin
kmem:*:5:65533::0:0:KMem Sandbox:/:/sbin/nologin
games:*:7:13::0:0:Games pseudo-user:/usr/games:/sbin/nologin
news:*:8:8::0:0:News Subsystem:/:/sbin/nologin
man:*:9:9::0:0:Mister Man Pages:/usr/share/man:/sbin/nologin
bind:*:53:53::0:0:Bind Sandbox:/:/sbin/nologin
uucp:*:66:66::0:0:UUCP pseudo-user:/var/spool/uucppublic:/usr/libexec/uucp/uucico
xten:*:67:67::0:0:X-10 daemon:/usr/local/xten:/sbin/nologin
pop:*:68:6::0:0:Post Office Owner:/nonexistent:/sbin/nologin
nobody:*:65534:65534::0:0:Unprivileged user:/nonexistent:/sbin/nologin
+:::::::::
-bill
basie&prompt.root;
netgroups の利用
netgroups の部分の原作:
Udo Erdelhoff ue@nathan.ruhr.de.
2000 年 7 月.
前節までに見てきた手法は,
極めて少ないユーザ/マシン向けに個別のルールを必要としている場合にはうまく機能します。
しかし大きなネットワークでは,
ユーザに触られたくないマシンへログオンを防ぐのを忘れるでしょうし,
そうでなくとも各マシンを個別に設定して回らなければならず、
集中管理という NIS の恩恵を失ってしまいます。
NIS の開発者はこの問題を netgroups
と呼ばれる方法で解決しました。
彼らの目的とその意味合いは UNIX
のファイルシステムで使われている一般的なグループと比較できます。
主たる相違は数字による id を欠いていることと、
ネットグループを定義するのにユーザアカウントと別のネットグループの、
両方を含められる機能です。
ネットグループは百人/台以上のユーザとマシンを含む、
大きく複雑なネットワークを扱うために開発されました。
もし、 あなたがこのような状況を扱わなければならないなら便利なものなのですが、
この複雑さは単純な例でネットグループの説明をすることをほとんど不可能にしています。
この部の残りで使われている例は、 この問題を実演しています。
あなたの行なった、 研究室への NIS
の導入の成功が上司の目に止ったとしましょう。
あなたの次の仕事は、
あなたの NIS
ドメインをキャンパスの他のいくつものマシンを覆うものへ拡張することです。
二つの表は新しいユーザと新しいマシンの名前とその説明を含んでいます。
ユーザの名前
説明
alpha, beta
IT 学科の通常の職員
charlie, delta
IT 学科の新しい見習い
echo, foxtrott, golf, ...
一般の職員
able, baker, ...
まだインターン
マシンの名前
説明
war, death, famine, polution
最も重要なサーバ。 IT 職員だけがログオンを許されます。
pride, greed, envy, wraith, lust, sloth
あまり重要でないサーバ。 IT 学科の全員がログオンを許されます。
one, two, three, four, ...
通常のワークステーション。
本当の 職員だけがログオンを許されます。
trashcan
重要なデータの入っていないひどく古いマシン。
インターンでもこのマシンの使用を許されます。
もしあなたがこの手の制限を各ユーザを個別にブロックする形で実装するなら、
あなたはそのシステムにログオンすることが許されていない各ユーザについて
-user という 1 行を、
各システムのパスワードに追加しなければならなくなるでしょう。
もしあなたが 1 エントリでも忘れればトラブルに巻き込まれてしまいます。
最初のセットアップの時にこれを正しく行えるのはありえることかも知れませんが、
遂には連日の業務の間に例の行を追加し忘れてしまうでしょう。
結局マーフィーは楽観主義者だったのです。
この状況をネットグループで扱うといくつかの有利な点があります。
各ユーザを別個に扱う必要はなく、
ユーザを一つ以上のネットグループに割り当て、
ネットグループの全メンバのログインを許可したり禁止したりすることができます。
新しいマシンを追加するときはネットグループへログインの制限を定義するだけ、
新しいユーザを追加するときはそのユーザを一つ以上のネットグループへ追加するだけで、
それぞれ行なうことができます。
これらの変更は互いに独立なので、
ユーザとマシンの組合わせをどうするか
は存在しなくなります。
あなたの NIS のセットアップが注意深く計画されていれば、
マシンへのアクセスを認めるにも拒否するにも中心の設定をたった一カ所変更するだけです。
最初のステップは NIS マップ netgroup の初期化です。
FreeBSD の ypinit はこのマップをデフォルトで作りませんが、
その NIS の実装はそれが作られさえすればそれをサポートするものです。
空のマップを作るには、 単に
ellington&prompt.root; vi /var/yp/netgroup
とタイプして内容を追加していきます。
わたしたちの例では、 すくなくとも
IT 職員、 IT 見習い、 一般職員、 インターンの
4 つのネットグループが必要です。
IT_EMP (,alpha,test-domain) (,beta,test-domain)
IT_APP (,charlie,test-domain) (,delta,test-domain)
USERS (,echo,test-domain) (,foxtrott,test-domain) \
(,golf,test-domain)
INTERNS (,able,test-domain) (,baker,test-domain)
IT_EMP、 IT_APP
等はネットグループの名前です。
それぞれの括弧で囲まれたグループが一人以上のユーザアカウントをそれに登録しています。
グループの 3 つのフィールドは
その記述が有効なホスト(群)の名称。
ホスト名を特記しなければそのエントリはすべてのホストで有効です。
もしあなたがホスト名を特記するなら、
あなたは闇と恐怖と全き混乱の領域となるでしょう。
このネットグループに所属するアカウントの名称。
そのアカウントの NIS ドメイン。
もしあなたが一つ以上の NIS ドメインの不幸な仲間なら、
あなたは他の NIS
ドメインからあなたのネットグループにアカウントを導入できます。
各フィールドには、 ワイルドカードが使えます。
詳細は &man.netgroup.5; をご覧ください。
8 文字以上のネットグループ名は、
特にあなたの NIS
ドメインで他のオペレーティングシステムを走らせているときは使うべきではありません。
名前には大文字小文字の区別があります。
そのためネットグループ名に大文字を使う事は、
ユーザやマシン名とネットグループ名を区別する簡単な方法です。
NIS クライアントの中には (FreeBSD 以外で)
多数のエントリを扱えないものもあります。
たとえば SunOS の古い版では 15
以上のエントリを含むネットグループはトラブルを起こします。
この制限は 15 ユーザ以下のサブ・ネットグループをいくつも作り、
本当のネットグループはこのサブ・ネットグループからなるようにすることで回避できます。
BIGGRP1 (,joe1,domain) (,joe2,domain) (,joe3,domain) [...]
BIGGRP2 (,joe16,domain) (,joe17,domain) [...]
BIGGRP3 (,joe32,domain) (,joe33,domain)
BIGGROUP BIGGRP1 BIGGRP2 BIGGRP3
単一のネットグループに 225 人以上のユーザをいれたいときは、
このやり方を繰り返すことができます。
新しい NIS マップの有効化と配布は簡単です。
ellington&prompt.root; cd /var/yp
ellington&prompt.root; make
これで新しい 3 つの NIS マップ
netgroup、
netgroup.byhost
netgroup.byuser ができるはずです。
新しい NIS マップが利用できるか確かめるには
&man.ypcat.1; を使います。
ellington&prompt.user; ypcat -k netgroup
ellington&prompt.user; ypcat -k netgroup.byhost
ellington&prompt.user; ypcat -k netgroup.byuser
最初のコマンドの出力は /var/yp/netgroup
の内容に似ているはずです。
2 番目のコマンドはホスト別のネットグループを作っていなければ出力されません。
3 番目のコマンドはユーザに対するネットグループのリストを得るのに使えます。
クライアント側の設定は非常に簡単です。
サーバ war を設定するには、
&man.vipw.8; を実行して以下の行
+:::::::::
を
+@IT_EMP:::::::::
に入れ替えるだけです。
今、 ネットグループ IT_EMP
で定義されたユーザのデータだけが war
のパスワードデータベースに読み込まれ、
そのユーザだけがログインを許されています。
残念ながらこの制限はシェルの ~ の機能や、
ユーザ名やユーザの数値 id の変換ルーチンにも影響します。
言い換えれば、
cd ~user はうまく動かず、
ls -l はユーザ名のかわりに数値の id を表示し
find . -user joe -print は
No such user
で失敗します。
これを避けるためには、
すべてのユーザのエントリをサーバにログインすることを許さずに読み込むことが必要です。
これはもう一行を /etc/master.passwd
に追加することで実現できます。 その行は
+:::::::::/sbin/nologin を含んでおり、
すべてのエントリを読み込むが、 読み込まれたエントリのシェルは
/sbin/nologin で置き換えられる
ということを意味します。 passwd エントリの他のフィールドを
/etc/master.passwd
の既定値から置き換えることも可能です。
+:::::::::/sbin/nologin の行が
+@IT_EMP:::::::::
の行より後ろに位置することに注意してください。
さもないと NIS から読み込まれた全ユーザが /sbin/nologin
をログインシェルとして持つことになります。
この変更の後では、 新しい職員が IT 学科に参加しても
NIS マップを一つ書き換えるだけで済みます。
同様にして、 あまり重要でないサーバのローカルの
/etc/master.passwd
のかつての
+:::::::::
行を以下のように置き換えます。
+@IT_EMP:::::::::
+@IT_APP:::::::::
+:::::::::/sbin/nologin
この行は、 一般のワークステーションでは以下のようになります。
+@IT_EMP:::::::::
+@USERS:::::::::
+:::::::::/sbin/nologin
これでしばらく順調に運用していましたが、
数週間後、 ポリシに変更がありました。
IT 学科はインターンを雇い始め、 IT
インターンは一般のワークステーションと余り重要ではないサーバを使うことが許され、
IT 見習いはメインサーバへのログインが許されました。
あなたは新たなネットグループ IT_INTERN を追加して新しい IT
インターンたちをそのグループに登録し、
すべてのマシンの設定を変えて回ることにしました。
古い諺にこうあります。
集中管理における過ちは、 大規模な混乱を導く
。
いくつかのネットグループから新たなネットグループを作るという
NIS の機能は、 このような状況に対処するために利用できます。
その方法の一つは、 役割別のネットグループを作ることです。
たとえば、 重要なサーバへのログイン制限を定義するために
BIGSRV というネットグループを作り
あまり重要ではないサーバへは SMALLSRV
というネットグループを、 そして一般のワークステーション用に
USERBOX という第 3 のネットグループを
作ることができます。 これらのネットグループの各々は、
各マシンにログインすることを許されたネットグループを含みます。
あなたの NIS マップネットグループの新しいエントリは、
以下のようになるはずです。
BIGSRV IT_EMP IT_APP
SMALLSRV IT_EMP IT_APP ITINTERN
USERBOX IT_EMP ITINTERN USERS
このログイン制限の定義法は、
同一の制限を持つマシンのグループを定義できるときには便利なものです。
残念ながらこのようなケースは例外的なものです。
ほとんどの場合、 各マシンに基づくログイン制限の定義機能が必要となるでしょう。
マシンごとのネットグループの定義は、
上述したようなポリシの変更を扱うことができるもうひとつの方法です。
このシナリオでは、 各マシンの /etc/master.passwd は
``+'' で始まる２つの行を含みます。
最初のものはそのマシンへのログインを許されたアカウントを追加するもので、
2 番目はその他のアカウントを/sbin/nologin
をシェルとして追加するものです。
マシン名をすべて大文字で記述したものをネットグループの名前として使うのは良いやり方です。
言い換えれば、 件の行は次のようになるはずです。
+@BOXNAME:::::::::
+:::::::::/sbin/nologin
一度、 各マシンに対してこの作業を済ませてしまえば、
二度とローカルの /etc/master.passwd
を編集する必要がなくなります。
以降のすべての変更は NIS マップの編集で扱うことができます。
以下はこのシナリオに対応するネットグループマップに、
いくつかの便利な定義を追加した例です。
# Define groups of users first
IT_EMP (,alpha,test-domain) (,beta,test-domain)
IT_APP (,charlie,test-domain) (,delta,test-domain)
DEPT1 (,echo,test-domain) (,foxtrott,test-domain)
DEPT2 (,golf,test-domain) (,hotel,test-domain)
DEPT3 (,india,test-domain) (,juliet,test-domain)
ITINTERN (,kilo,test-domain) (,lima,test-domain)
D_INTERNS (,able,test-domain) (,baker,test-domain)
#
# Now, define some groups based on roles
USERS DEPT1 DEPT2 DEPT3
BIGSRV IT_EMP IT_APP
SMALLSRV IT_EMP IT_APP ITINTERN
USERBOX IT_EMP ITINTERN USERS
#
# And a groups for a special tasks
# Allow echo and golf to access our anti-virus-machine
SECURITY IT_EMP (,echo,test-domain) (,golf,test-domain)
#
# machine-based netgroups
# Our main servers
WAR BIGSRV
FAMINE BIGSRV
# User india needs access to this server
POLLUTION BIGSRV (,india,test-domain)
#
# This one is really important and needs more access restrictions
DEATH IT_EMP
#
# The anti-virus-machine mentioned above
ONE SECURITY
#
# Restrict a machine to a single user
TWO (,hotel,test-domain)
# [...more groups to follow]
もしユーザアカウントを管理するデータベースの類を使っているなら、
あなたはデータベースのレポートツールからマップの最初の部分を作れるようにしてあるべきです。
この方法なら、 新しいユーザは自動的にマシンにアクセスできるでしょう。
最後に使用上の注意を:
マシン別のネットグループを使うことが常に賢明というわけではありません。
あなたが数ダースから数百の同一の環境のマシンを学生の研究室に配置しているのならば、
NIS マップのサイズを手頃な範囲に押さえるために、
マシン別のネットグループのかわりに役割別のネットグループを使うべきです。
忘れてはいけないこと
NIS 環境にある今、 今までとは違ったやり方が必要なことが
2、3 あります。
研究室にユーザを追加するときは、
それをマスター NIS サーバにだけ追加しなければならず、
さらにNIS マップを再構築することを忘れてはいけません。
これを忘れると新しいユーザは NIS マスタ以外のどこにもログインできなくなります。
たとえば、 新しくユーザ jsmith
をラボに登録したいときは以下のようにします。
&prompt.root; pw useradd jsmith
&prompt.root; cd /var/yp
&prompt.root; make test-domain
pw useradd jsmith のかわりに
adduser jsmith を使うこともできます。
管理用アカウントを NIS マップから削除してください。
管理用アカウントやパスワードを、
それらのアカウントへアクセスされるべきでないユーザが居るかも知れないマシンにまで伝えて回りたいとは思わないでしょう。
NIS のマスタとスレーブをセキュアに、
そして機能停止時間を最短に保ってください。
もし誰かがこれらのマシンをクラックしたり、
あるいは単に電源を落としたりすると、
彼らは実質的に多くの人を研究室へログインできなくしてしまえます。
これはどの集中管理システムにとっても第一の弱点で、
そして最も重要な弱点でしょう。
あなたの NIS サーバを守らなければ怒れるユーザと対面することになるでしょう!
NIS v1 との互換性
FreeBSD の
ypserv は、
NIS v1 クライアントを部分的にサポートします。
FreeBSD の NIS 実装は NIS v2 プロトコルのみを使用していますが、
ほかの実装では、 古いシステムとの下位互換性を持たせるため
v1 プロトコルをサポートしているものもあります。
そのようなシステムに付いている
ypbind デーモンは、
必要がないにもかかわらず NIS v1
のサーバとの結合を成立させようとします(しかも
v2 サーバからの応答を受信した後でも、
ブロードキャストをし続けるかも知れません)。
FreeBSD の ypserv は、
クライアントからの通常のリクエストはサポートしていますが、
v1 のマップ転送リクエストはサポートしていないことに注意してください。
つまり FreeBSD の ypserv を、
v1 だけをサポートするような古い NIS サーバと組み合わせて
マスターやスレーブサーバとして使うことはできません。
幸いなことに、 現在、 そのようなサーバが使われていることは
ほとんどないでしょう。
NIS クライアントとしても動作している NIS サーバ
複数のサーバが存在し、 サーバ自身が NIS
クライアントでもあるようなドメインで ypserv が実行される場合には、
注意が必要です。
一般的に良いとされているのは、
他のサーバと結合をつくるようにブロードキャストパケットの送信をさせるのではなく、
サーバをそれ自身に結合させることです。
もし、 サーバ同士が依存関係を持っていて、 一つのサーバが停止すると、
奇妙なサービス不能状態に陥ることがあります。
その結果、 すべてのクライアントはタイムアウトを起こして
他のサーバに結合しようと試みますが、
これにかかる時間はかなり大きく、
サーバ同士がまた互いに結合してしまったりすると、
サービス不能状態はさらに継続することになります。
ypbind に
オプションフラグを指定して実行することで、
ホストを特定のサーバに結合することが可能です。
libscrypt 対 libdescrypt
NIS を実装しようする人の誰もがぶつかる問題の一つに、
暗号ライブラリの互換性があります。
NIS サーバが DES 暗号ライブラリを使っている場合には、
同様に DES を使用しているクライアントしかサポートできません。
サーバとクライアントがどのライブラリを使用しているかは、
/usr/lib
のシンボリックリンクを見ればわかります。
あるマシンが DES ライブラリを使うように設定されている場合、
リンクは以下のようになっています。
&prompt.user; ls -l /usr/lib/*crypt*
lrwxrwxrwx 1 root wheel 13 Jul 15 08:55 /usr/lib/libcrypt.a@ -> libdescrypt.a
lrwxrwxrwx 1 root wheel 14 Jul 15 08:55 /usr/lib/libcrypt.so@ -> libdescrypt.so
lrwxrwxrwx 1 root wheel 16 Jul 15 08:55 /usr/lib/libcrypt.so.2@ -> libdescrypt.so.2
lrwxrwxrwx 1 root wheel 15 Jul 15 08:55 /usr/lib/libcrypt_p.a@ -> libdescrypt_p.a
-r--r--r-- 1 root wheel 13018 Nov 8 14:27 /usr/lib/libdescrypt.a
lrwxr-xr-x 1 root wheel 16 Nov 8 14:27 /usr/lib/libdescrypt.so@ -> libdescrypt.so.2
-r--r--r-- 1 root wheel 12965 Nov 8 14:27 /usr/lib/libdescrypt.so.2
-r--r--r-- 1 root wheel 14750 Nov 8 14:27 /usr/lib/libdescrypt_p.a
マシンが FreeBSD の標準の MD5 暗号ライブラリを使うように
設定されている場合には、 以下のようになります。
&prompt.user; ls -l /usr/lib/*crypt*
lrwxrwxrwx 1 root wheel 13 Jul 15 08:55 /usr/lib/libcrypt.a@ -> libscrypt.a
lrwxrwxrwx 1 root wheel 14 Jul 15 08:55 /usr/lib/libcrypt.so@ -> libscrypt.so
lrwxrwxrwx 1 root wheel 16 Jul 15 08:55 /usr/lib/libcrypt.so.2@ -> libscrypt.so.2
lrwxrwxrwx 1 root wheel 15 Jul 15 08:55 /usr/lib/libcrypt_p.a@ -> libscrypt_p.a
-r--r--r-- 1 root wheel 6194 Nov 8 14:27 /usr/lib/libscrypt.a
lrwxr-xr-x 1 root wheel 14 Nov 8 14:27 /usr/lib/libscrypt.so@ -> libscrypt.so.2
-r--r--r-- 1 root wheel 7579 Nov 8 14:27 /usr/lib/libscrypt.so.2
-r--r--r-- 1 root wheel 6684 Nov 8 14:27 /usr/lib/libscrypt_p.a
NIS クライアントの認証でトラブルが発生した場合には、
ここから問題となりそうな部分を探すと良いでしょう。
NIS サーバを異種混在ネットワークに配置したいときは
DES が最大公約数となるでしょうから、
すべてのシステムで DES を使わなければいけなくなるでしょう。
DHCP
原作: &a.gsutter;, 2000 年 3 月.
DHCPとは何でしょう?
DHCP (Dynamic Host Configuration Protocol) は、 システムをネットワー
クに接続するだけで、 ネットワークでの通信に必要な情報を入手するこ
とができる仕組みです。 FreeBSD では、 ISC (Internet Software
Consortium) による DHCP の実装を使用しています。 したがって、 ここで
の説明のうち、 実装によって異なる部分は ISC のもの用になっています。
この節で説明していること
ハンドブックのこの節では DHCP システムの、 FreeBSD に組み込まれてい
る部分についてだけ説明しています。 ですから、 サーバについては説明
していません。 後の節で紹介するリファレンスに加えて、
DHCP のマニュアルページも有力な参考になることでしょう。
DHCP の動作
クライアントとなるマシン上で DHCP のクライアントである dhclient を実
行すると、 まず設定情報の要求をブロードキャストします。 デフォルト
では、 このリクエストには UDP のポート 68 を使用します。 サーバは UDP の
ポート 67 で応答し、 クライアントの IP アドレスと、 ネットマスクやルー
タ、 DNS サーバなどの関連する情報を提供します。 これらの情報の
すべては DHCP の「リース」の形で送られ、 DHCP サーバ管理者によって決
められたある一定の時間内でのみ有効になります。 これによって、 ネッ
トワークに存在しなくなったホストの IP アドレスは自動的に回収される
ことになります。
DHCP クライアントはサーバから非常に多くの情報を取得することができます。
&man.dhcp-options.5; に、 その非常に大きなリストが載っています。
FreeBSD への組み込み
FreeBSD は ISC の DHCP クライアントである
dhclient を完全に組み込んでいます。 DHCP クラ
イアントはインストーラと基本システムの両方で提供されています。
ですから DHCP サーバを走らせているネットワーク上ではネットワー
ク関係の設定についての詳細な知識は必要になりません。
dhclient は、 3.2 以降の FreeBSD のすべての配布
に含まれています。
DHCP は sysinstall でサポートされてお
り、 sysinstall でのネットワークインタフェイス設定の際は、 「こ
のインタフェイスの設定として DHCP を試してみますか?」という質問
が最初になされます。 これに同意することで dhclient が実行さ
れ、 それが成功すればネットワークの設定情報は自動的に取得されま
す。
システム起動時に、 DHCP を使ってネットワーク情報を取得するように
するには、 次の 2 つのステップを行なう必要があります。
bpf
デバイスがカーネルに組み込まれていることを確認します。
これを組み込むには、 カーネルコンフィグレーションファイルに
pseudo-device bpf
という行を追加し、 カーネルを再構築します。
カーネルの構築に関する詳細は、
を参照してください。
bpf デバイスは、
FreeBSD の出荷時に用意されている
GENERIC カーネルに組み込まれていますので、
自分で設定を変えたカスタムカーネルを使っているのでなければ、
DHCP を動作させるためにカーネルを再構築する必要はありません。
セキュリティに関心のある方向けに注意しておきます。
bpf
デバイスは、 パケットスニファ (盗聴プログラム)
を動作させることができる (ただし root 権限が必要)
デバイスです。
bpf は DHCP を動作させるために
かならず必要ですが、
セキュリティが非常に重要な場面では
DHCP を本当に使う時まで bpf
デバイスをカーネルに追加すべきではないでしょう。
/etc/rc.conf を編集して、
次の行を追加してください。
ifconfig_fxp0="DHCP"
fxp0 の部分を、 動的に設定したいインター
フェースの名前で置き換えることを忘れないようにしてください。
もし、 使っているdhclient の場所を変更してい
たり、 dhclient にフラグを渡したい場合は、 同
様に下のように書き加えてください。
dhcp_program="/sbin/dhclient"
dhcp_flags=""
DHCP サーバである dhcpd は、 ports
collectionに isc-dhcp2 として収録されていま
す。 この port はクライアント、 サーバ、 リレーエージェントから成
る ISC の DHCP 配布物をすべて含んでいます。
関連ファイル
/etc/dhclient.conf
dhclient は設定ファイル
/etc/dhclient.conf を必要とします。
大抵の場合、 このファイルはコメントだけであり、 デフォルトが
通常使いやすい設定になっています。 この設定ファイルは
マニュアルページ &man.dhclient.conf.5; で説明しています。
/sbin/dhclient
dhclient は静的にリンクされており、
/sbin に置かれています。 マニュアルページ
&man.dhclient.8; で dhclient コマンドについて
より詳しく説明しています。
/sbin/dhclient-script
dhclient-script は FreeBSD 特有の、 DHCP クラ
イアント設定スクリプトです。 これについてはマニュアルページ
&man.dhclient-script.8; で説明されていますが、 これを編集する
必要はほとんど発生しないでしょう。
/var/db/dhclient.leases
DHCP クライアントはこのファイルに有効なリースのデータベースを
ログとして記録します。 &man.dhclient.leases.5; にもうすこし詳
しい解説があります。
参考になる文献
DHCP のプロトコルは
RFC 2131
に完全に記述されています。 また、
dhcp.org
にも有用な
情報源が用意されています。
diff --git a/ja_JP.eucJP/books/handbook/cutting-edge/chapter.sgml b/ja_JP.eucJP/books/handbook/cutting-edge/chapter.sgml
index b02faa348d..d1576f03a5 100644
--- a/ja_JP.eucJP/books/handbook/cutting-edge/chapter.sgml
+++ b/ja_JP.eucJP/books/handbook/cutting-edge/chapter.sgml
@@ -1,2064 +1,2064 @@
Jim
Mock
再構成、再編成および改訂
Jordan
Hubbard
原作
Poul-Henning
Kamp
John
Polstra
Nik
Clayton
開発の最前線
この章では
あるリリースから次のリリースまでの期間にも、
&os; の開発は休みなく続けられています。
この開発の最前線に興味を持っている人のために、
手元のシステムを最新の開発ツリーに同期させておくための、
とても使いやすい仕掛けが何種類も用意されています。
注意: 開発の最前線は、
誰もが扱えるという性質のものではありません!
もしもあなたが、開発途中のシステムを追いかけようか、
それともリリースバージョンのどれかを使い続けようかと迷っているのなら、
きっとこの章が参考になるでしょう。
この章を読んで分かるのは:
2つの開発ブランチ、&os.stable; と &os.current; の違い
CVSup、
CVS、もしくは
CTM
を使ったシステム更新方法
make world
を使ってベースシステム全体を再構築しインストールする方法
この章を読む前に、以下の準備をしましょう。
ネットワーク接続の適切な設定 ()
サードパーティ製のソフトウェアのインストール方法の習得
()
&os.current; vs. &os.stable;
-CURRENT
-STABLE
FreeBSD には二つの開発ブランチがあります。
それは &os.current; と &os.stable; です。
この章ではそれぞれについて簡単に説明し、
どのようにしてあなたのシステムを対応するツリーに対して、
どうやって常に最新の状態に保つかについて扱います。
まずは &os.current;、次に &os.stable; について説明します。
訳: &a.hanai;、1996 年 11 月 6 日
最新の &os; を追いかける
これを読む前に、
心にとめておいて欲しいことがあります。
&os.current; とは &os; の開発の 最前線
だということです。
&os.current; のユーザは高い技術力を持つことが要求され、
自分のシステムが抱える困難な問題を自力で解決できなければなりません。
もし &os; を使い始めたばかりなら、
これを運用することについて十分検討を重ねた方が良いでしょう。
&os.current; ってなに?
&os.current; は &os; の最新の、そして作業進行中のソースです。
中には現在開発途上のソフトウェア、
実験的な変更、あるいは過渡的な機能などが含まれています。
また、この中に入っている機能がすべて、
次の公式リリースに入るとは限りません。
&os.current; をソースからほぼ毎日コンパイルしている人は
たくさんいますが、
時期によってはコンパイルさえできない状態になっていることもあります。
これらの問題は可能な限り迅速に解決されますが、
&os.current; が不幸をもたらすか、
それとも非常に素晴らしい機能をもたらすかは、
まさにソースコードを手に入れた瞬間によるのです!
誰が &os.current; を必要としてるの?
&os.current; は、
次の三つの重要なグループを対象としています。
ソースツリーのある部分に関して活発に作業している
&os; グループのメンバ。
彼らにとっては 最新のもの
にしておくのが
絶対に必要なことなのです。
活発にテストしている &os; グループのメンバ。
彼らは、&os.current;
が 健全である
ことを可能な限り保証するために、
種々の問題を解決するのに時間を惜しまない人々です。
彼らはまた、様々な変更に関する提案や
&os; の大まかな方向付けを行ないたいと思っている
人々でもあり、それを実装するためのパッチを提示します。
単に、様々な事に目を向け、参考のために
(たとえば動かすためではなく読むために)
最新のソースを使いたいと思っている人々。
これらの人々はまた、
時々コメントやコードを寄稿してくれます。
&os.current;
に期待しては<emphasis>いけない</emphasis>ことは?
なにか新しくカッコイイモノがあると聞き、
自分の周囲では一番にそれを持ちたいがために、
リリース前のコードの断片を追いかけること。
新しい機能を得るために一番乗りになるということは、
新しいバグに最初にぶち当たるということです。
バグを修正するための素早い方法。
いかなるバージョンの &os.current; であれ、
元からあるバグを修正するのと同じく、
新しいバグを生み出すおそれがあります。
公式にサポートする
こと。
わたしたちは 3 つの 公式な
&os.current; のグループの一つに、
実際に属する人々を助けるのにベストを尽くしますが、
技術的なサポートを行なうには、単に「時間が足りない」のです。
これはわたしたちが外の人を助けるの好まない、
ケチで意地悪い人間だということではありません
(もしそうなら &os; なんてやっていません)。
わたしたちは一日に何百通ものメッセージに答え、
かつ &os;
の作業をすることなど出来ない!
というだけのことなのです。
もし、&os; の改良作業を続けるか、
それとも実験的なコードに関するたくさんの質問に答えるか、
という二つの選択を迫られたら、開発者は前者を選ぶでしょう。
&os.current; を使う
&a.current;
と
&a.cvsall;
に加わってください。
これは単に良い考えであるというだけでなく、
必須のことなのです。
もし
&a.current;
に入っていなければ、
さまざまな人がシステムの現在の状態について
述べているコメントを見ることは決してありませんし、
従って他の人が既に見つけて解決している
多くの問題に戸惑ってあきらめてしまうでしょう。
さらに言うと、システムを正常に保つための
重要な情報を見逃してしまう可能性もあります。
&a.cvsall; では、
それぞれの変更についての
commit ログを見ることができます。
また、それに関して起こり得る副作用の情報を得ることができますので、
参加する価値のあるメーリングリストです。
これらのメーリングリストに入るには、
&a.majordomo; へ
subscribe freebsd-current
subscribe cvs-all
majordomo
と書いたメールを送ってください。
オプションとして本文に
help
と書けば、Majordomo からあなたへ、
わたしたちがサポートする様々なメーリングリストに参加
/脱退する方法に関する詳しいヘルプが送られます。
ftp.FreeBSD.org
からのソースの入手。
以下の 3 つの方法で行なうことができます。
cvsup
cron
-CURRENT
CVSup を使った同期
cvsup を
この supfile
を用いて使用する。
これがもっとも推奨される方法です。
なぜなら、cvsup によって一度全体を入手し、
後は変更されたところだけを入手することができるからです。
たくさんの人が自動的にソースを最新のものに保つために
cvsup を cron から起動しています。
上に挙げたサンプル supfile はカスタマイズして、環境に合わせて
cvsup を設定する必要があります。
その設定を行なうのにヘルプが必要であれば、単に
&prompt.root; pkg_add -f ftp://ftp.FreeBSD.org/pub/FreeBSD/ports/packages/All/cvsupit-3.1.tgz
とタイプしてください。
-CURRENT
ftp によるダウンロード
ftp を使う。
&os.current; のソースツリーは常に
ftp://ftp.FreeBSD.org/pub/FreeBSD/FreeBSD-current/
で 公開
されています。
全体を compress/tar して入手できる FTP ミラーもあります。
たとえば、
usr.bin/lex
があったとすると、
ftp> cd usr.bin
ftp> get lex.tar
とすることにより、ディレクトリ全体 (この場合、
usr.bin/lex以下全体) を tar
ファイルとして入手することができます。
-CURRENT
CTM を使った同期
CTMを用いる。
(接続料が高額だったり、email でのアクセスしかできないような)
あまり良質でない TCP/IP 接続の場合には、CTM
を利用すると良いでしょう。ただし、
これには多くの手間がかかりますし、
壊れたファイルを受けとってしまう可能性もあります。
そのため、最近ではあまり使われなくなっており、
長い間使用できなくなってしまう事態が発生する可能性があります
(訳注: 保守する人が少ないためです)。
9600bps 以上の速度で接続しているなら、
CVSup
を利用されることを推奨します。
もし、ソースを眺めるだけでなく、
走らせるために入手しているのであれば、
一部だけ選ぶのではなく、&os.current;
の全体を手に入れてください。
なぜなら、ソースのさまざまな部分が他の部分の更新に依存しており、
一部のみをコンパイルしようとすると、
ほぼ間違いなくトラブルを起こすからです。
&os.current; をコンパイルする前に
/usr/src にある Makefile
を良く読んでください。
アップグレードの処理の一部として、
少なくとも一回は最初に
make world
を行なうべきでしょう。
&a.current; を読めば、
次のリリースへ向けて時々必要になる他のブートストラップの方法に関して、
常に最新情報を得ることが出来ます。
アクティブになってください!
もし &os.current;
を走らせているなら、わたしたちはそれに関するコメント、
特に拡張やバグ潰しに関する提案を欲しています。
コードを伴う提案はもっとも歓迎されるものです!
安定版の &os; を使う
訳: &a.jp.iwasaki;
&os.stable; ってなに?
-STABLE
&os.stable; とは定期的に公開されるリリースを作成するための開発ブランチです。
このブランチに加えられる変更は原則として、
事前に &os.current; で試験ずみであるという特徴があります。
ただそうであっても、
これは開発用ブランチの一つであるということに注意してください。
つまり、ある時点における &os.stable; のソースが
どんな場合にも使えるものであるとは限らないということです。
このブランチはもう一つの開発の流れというだけであって、
エンドユーザ向けのものではありません。
誰が &os.stable; を必要としているの?
もしあなたが FreeBSD の開発過程に興味があるとか、
それに対する貢献を考えていて、特にそれが
次回の ポイント
リリースに関係するもの
であるなら &os.stable; を追うことを考えると良いでしょう。
セキュリティ上の修正は &os.stable; ブランチに対して行なわれますが、
そのために &os.stable; を追う必要はありません。
すべての FreeBSD セキュリティ勧告には
影響のあるリリースで問題点を修正する方法が説明されており
これは正確ではありません。
実際わたしたちは何年もの間古いリリースの FreeBSD
をサポートしてはいるのですが、
永遠にサポートし続けることはできません。
現時点での古いリリースの FreeBSD のセキュリティポリシーの全説明を知るには、
http://www.FreeBSD.org/security/
を参照してください
、
セキュリティ上の理由のみから開発用ブランチ全体を追いかけることは、
同時に望ましくない変更点まで取り込んでしまう可能性があるからです。
わたしたちは &os.stable; ブランチがいつも安定に動作するように
努めていますが、それが保証されているというわけではありません。
また、コードは &os.stable; に加えられる前に
&os.current; で開発されるのですが、&os.stable; のユーザは
&os.current; よりも多いため、&os.current; で発見されなかった
バグが &os.stable; で発見され、時々それが問題となることがあるのは
避けることができません。
このような理由から、わたしたちは盲目的に &os.stable;
を追いかけることを推奨しません。
特に、最初に開発環境でコードを十分に試験せずに
プロダクション品質が要求されるサーバを &os.stable;
にアップグレードしてはいけません。
もしそうするための資源的な余裕がない場合は、
リリース間のバイナリアップデート機能を利用して、
最新の FreeBSD リリースを使うことを推奨します。
&os.stable; を使う
-STABLE
利用する
&a.stable; へ加わってください。
このメーリングリストでは、
&os.stable; の構築に関連する事柄や、
その他の注意すべき点 に関する情報が流れています。
また開発者は議論の余地がある修正や変更を考えている場合に、
このメーリングリストで公表し、
提案された変更に関して問題が生じるかどうかを返答する機会をユーザに与えます。
また、&a.cvsall; では、
それぞれの変更がなされると、
起こりうる副作用に関するすべての適切な情報と一緒に
commit log を読むことができます。subscribe
しておきたいもう一つのメーリングリストです。
メーリングリストに参加するには、
&a.majordomo;
へメッセージの本文に次のように書いたメールを送ってください:
subscribe freebsd-stable
subscribe cvs-all
majordomo
オプションとして本文に `help' と書けば、
Majordomo はわたしたちがサポートするさまざまなメーリングリストに参加 /
脱退する方法に関する詳しいヘルプを送付します。
もし、あなたが新しいシステムをインストールしようとしていて
それを可能な限り安定なものにしておきたいなら、
最新のブランチの snapshot を
ftp://releng4.freebsd.org/pub/FreeBSD
から取得し、
これを一般のリリースのものと同様にインストールしてください。
もし、既に &os; の以前のリリースが動いている場合で、
これをソースからアップグレードしようとするならば、
ftp.FreeBSD.org より簡単に
これを行う事が出来ます。これには次の 3 つの方法があります。
-STABLE
CVSup を使った同期
cvsup を
この supfile
を用いて使用する。
一度コレクション全体を入手してしまえば前回からの変更部分だけですむので、
もっとも推奨される方法です。
多くの人が cron から cvsup を実行し、
自動的にソースコードを最新の状態に保っています。
これを簡単に扱うには次のようにタイプしてください。
&prompt.root; pkg_add -f ftp://ftp.FreeBSD.org/pub/FreeBSD/development/CVSup/cvsupit.tgz
-STABLE
FTP を使ったダウンロード
ftp を使用する。&os.stable;
用のソースツリーは
常に次のところで 公開
されています:
ftp://ftp.FreeBSD.org/pub/FreeBSD/FreeBSD-stable/
compress/tar でツリー全体を入手できる
FTP ミラーもあります。
たとえば:
usr.bin/lex
に対して:
ftp> cd usr.bin
ftp> get lex.tar
とすることにより、ディレクトリ全体を tar
ファイルとして入手することができます。
-STABLE
CTM を使って同期する
CTM 機能を使います。
インターネットへの接続に高速で安価な回線を利用できないのであれば、
この方法を検討してみましょう。
基本的には、
ソースに迅速でオンデマンドなアクセスが必要で、
接続のバンド幅が問題でなければ、cvsup
か ftp を使いましょう。そうで
ない場合は CTM
を使いましょう。
-STABLE
構築、コンパイル
&os.stable; をコンパイルする前に、
/usr/src にある Makefile をよ
く読んでください。
少なくとも一回はアップグレードの処理の一部として最初に
make world
を実行するべきでしょう。&a.stable; を読めば、
次のリリースに移行する
に当たって時々必要となる既存システムからの
新システムの構築手順に
ついての最新情報が得られるでしょう。
ソースの同期
訳: &a.jp.iwasaki;、1997 年 9 月 13 日
インターネット接続 (または電子メール) を使用して、
あなたの興味の対象によって &os;
プロジェクトのソースのある一部分または全体の最新を
追いかける方法は色々あります。
私たちが提供している基本的なサービスは Anonymous CVS、CVSup と CTM
です:
ソースツリーの一部を最新のものに更新することは可能です。
ただし、サポートされているアップデート手順は、
ソースツリー全体を最新のものに更新して、
ユーザランド (/bin や /sbin
にあるような、ユーザが実行するプログラム全体のこと)
およびカーネルのソースから再構築することのみであることに注意してください。
カーネルだけ、あるいはユーザランドだけというように、
ソースツリーの一部を更新した場合は、問題が生じることがよくあります。
この時に発生する問題はコンパイル時のエラーからカーネルパニック、
データの破壊とさまざまです。
anonymous CVS
Anonymous CVS と
CVSup は pull
同期モデルを採用しています。
CVSup の場合、ユーザ
(または cron スクリプト) が cvsup
- 起動し、どこかにある cvsupd
+ を起動し、どこかにある cvsupd
サーバとやりとりしてファイルを
最新状態にします。
届けられる更新情報はその時点の最新のものであり、
また必要な時にだけ取り寄せられます。
興味のある特定のファイルやディレクトリに
限定して更新することも簡単にできます。
クライアント側のソースツリーの状態・
設定ファイルの指定に従い、サーバによって更新情報が
素早く生成されます。
Anonymous CVS は、
このプログラムがリモートの CVS リポジトリから直接変更点を
pull できるようにした &man.cvs.1; への拡張であるという点で、
CVSup よりもずっと単純です。
CVSup
は効率の点ではるかにまさっていますが、
Anonymous CVS の方が簡単に利用できます。
CTM
一方、CTM
はあなたが持っているソースとマスタアーカイブ上に
あるそれとの対話的な比較をおこないませんし、
あるいは向こう側から変更点を pull したりもしません。
そのかわりに、前回の実行時からの変更を認識するスクリプトが
マスタ CTM マシン上で一日に数回実行され、
すべての変更を compress して通し番号を振り、
さらに電子メールで転送できるようにエンコードします
(印字可能な ASCII
キャラクタのみです)。受信した後は、
これらの CTM のデルタ
は自動
的にデコード、検査してユーザのソースのコピーに変更を適用する
&man.ctm.rmail.1; によって処理可能となります。
この処理は CVSup や
Anonymous CVS よりずっと効率
的であり、pull モデルというよりむしろ
push モデルで
あるため、私たちのサーバ資源の負荷は軽くなります。
もちろん他のトレードオフもあります。うっかりアーカイブ
の一部を消してしまっても、CVSup
は壊れた部分を検出して再構築してくれます。
CTM はこれをやってくれませんし、
Anonymous CVS
はおそらく他の何よりも深く混乱してしまうことが多いでしょう。
もしソースツリーの一部を消してしまったら、(最新の CVS
ベースデルタ
から) 一からやり直し、CTM か anoncvs
を使って悪い部分を消去し、再同期させることによって
すべてを再構築しなければなりません。
<command>make world</command> の利用
make world
&os; のどれか特定のバージョン (&os.stable;、&os.current; など)
について、ローカルのソースツリーを同期させたら、
そのソースツリーを使ってシステムを
再構築しなければなりません。
バックアップを作成する
システムを再構築する前にバックアップを
作成することの重要性は、いくら強調してもし過ぎると言うことはありません。
システム全体の再構築とは
(以降に書かれた手順に従っている限り) 難しい作業ではありませんが、
どんなに注意していたとしても、
あなた自身、あるいはソースツリーで作業している他の人達に手違いがあった時には、
システムが起動しなくなってしまう状態になることがあるのです。
まず、バックアップがきちんと作成されていることを確認して、
fix-it フロッピーを用意してください。
多分、それを使うことはないと思いますが、
あとで後悔することのないよう、念のため用意しておきましょう。
メーリングリストに参加する
メーリングリスト
もともと、&os.stable; と &os.current; のコードブランチは、
開発中のものです。
&os; の作業に貢献してくださっている人達も人間ですから、
時にはミスをすることだってあるでしょう。
そのような間違いは、単に警告を示す見慣れない
診断メッセージをシステムが、表示するような、
全く害のないものであることもあれば、システムを起動できなくしたり、
ファイルシステムを破壊してしまうような、
恐ろしい結果を招くものかも知れません。
万が一、このような問題が生じた場合、
問題の詳細と、どのようなシステムが影響を受けるかについて書かれた
注意 (heads up)
の記事が
適切なメーリングリストに投稿され、そして、その問題が解決されると、
問題解決 (all clear)
のアナウンス記事が同様に
投稿されます。
&os.stable; や &os.current; ブランチに追随するために試そうとするのに、
&a.stable; や &a.current; を過去にさかのぼって読まないというのは、
自ら災難を招くことになるでしょう。
訳注:
これらのメーリングリストは英語でやりとりされているため、
日本語での投稿は歓迎されません。英語でのやりとりができない人は、
FreeBSD 友の会
の運営しているメーリングリストをあたってみるのがいいでしょう。
<filename>/usr/src/UPDATING</filename> を読む
何を始めるにしろ、まず最初に
/usr/src/UPDATING (もしくはあなたがソースコードを
どこにコピーしたにせよそれに相当するファイル) を読みましょう。
このファイルにはあなたが遭遇するかも知れない問題に対する重要な情報を
含んでいたり、あなたが特定のコマンドを実行しなければならなくなった時
その順序を指示したりするはずです。
UPDATING があなたが読んだ事柄と矛盾している時は
UPDATING が優先します。
UPDATING を読むということは、前述の
適切なメーリングリストを購読する代わりにはなりません。
二つの要求は相補的なもので排他的なものではないのです。
<filename>/etc/make.conf</filename> の確認
make.conf
まず、/etc/defaults/make.conf と
/etc/make.conf を調べてください。そこには
最初から標準的なものが (多くのものはコメントアウトされていますが)
含まれています。ソースからシステムを再構築するときに make が
/etc/make.conf に付け加えられた設定を使用します。
/etc/make.conf に追加された設定は make
を実行したときに常に使われることを覚えておいてください。
そのため、システムに必要な設定を書いておくと良いでしょう。
標準的なユーザならおそらく、
/etc/defaults/make.conf の CFLAGS と
NOPROFILE のコメントをはずすことを考えると思います。
他の定義 (COPTFLAGS、
NOPORTDOCS など) の定義行についても、
コメントを外す必要があるかどうか調べておきましょう。
<filename>/etc</filename> にあるファイルの更新
/etc ディレクトリには、
システム起動時に実行されるスクリプトだけでなく、
あなたのシステムの設定に関連する情報の大部分が
含まれています。そのディレクトリに含まれる
スクリプトは、FreeBSD のバージョンによって多少異なります。
また、設定ファイルのなかには、稼働中のシステムが日々利用している
ものもあります。実際には、/etc/group
などがそれに該当します。
make world
のインストールの段階では、
特定のユーザ名、あるいはグループが存在していることを
要求する場面があります。システムのアップグレードを行なう際には、
それらのユーザ名やグループが削除、あるいは変更されて存在していない可能性が
考えられますが、そういった場合、システムのアップグレードを
行なっている間に、問題が発生する原因になります。
この例で記憶に新しいのは、
smmsp ユーザが追加された時です。
mtree が
/var/spool/clientmqueue
を作成しようとする時、
そのユーザ名 (およびグループ)
が存在しないためにインストールに失敗してしまったのです。
解決方法は、/usr/src/etc/group を調べ、
自分のシステムのグループ名リストと比較することです。
最新のファイルに含まれていて、あなたのファイルに含まれていない
グループ名があれば、あなたのファイルにそのグループ名をコピーしてください。
同様に、名前が異なるにも関わらず、
/etc/group と
/usr/src/etc/group で同じ GID を持っているグループ名があれば、
/etc/group に含まれる、
該当するすべてのグループ名を変更しておかなければなりません。
4.6-RELEASE からは、buildworld の前に
をつけて &man.mergemaster.8; を実行してもよいです。
これを実行すると、buildworld や
installworld
が成功するために必要なファイルだけを比較します。
古いバージョンの mergemaster
を使っていて、 がサポートされていない場合、
最初に実行するときソースツリーにある新しいバージョンのものを使ってください。
&prompt.root; cd /usr/src/usr.sbin/mergemaster
&prompt.root; ./mergemaster.sh -p
もし、あなたがもっと神経質な人なら、あなたが名前を変更したり、
削除してしまったグループが所有しているファイルを、
次のようにして調べることもできます。
&prompt.root; find / -group GID -print
これは GID (グループ名もしくは数字で示されたグループ ID) で
指定されたグループが所有するすべてのファイルを表示します。
シングルユーザモードへの移行
シングルユーザモード
コンパイルは、シングルユーザモードで行なった方が良いでしょう。
そうすることで多少速度が向上する、というちょっとした利点が
あるだけでなく、システムの再インストールは重要なシステムファイル、
標準コマンド、ライブラリ、インクルードファイルなどを操作します。
稼働中のシステムに (特に他のユーザがそのシステムにログインしている時に)
そのような変更を加えることは、トラブルを引き起こす原因となります。
マルチユーザモード
もう一つの方法として、マルチユーザモードでシステムを再構築して、
シングルユーザモードに移行してからそれをインストールする、
というのがあります。もしこのような方法で行ないたい場合は、
以下の手順を構築が完了するところまで飛ばしてください。
稼働中のシステムでシングルユーザモードに移行するには、
スーパユーザ (root) 権限で次のコマンドを実行します。
&prompt.root;
あるいはシステムを再起動し、ブートプロンプトから
フラグを設定することで、シングルユーザモードで
システムを起動させることができます。起動後、シェルプロンプトから
次のように実行してください。
&prompt.root; fsck -p
&prompt.root; mount -u /
&prompt.root; mount -a -t ufs
&prompt.root; swapon -a
これはファイルシステムをチェックした後、
/ を読み書き可能にして再マウント、
/etc/fstab に指定されている、
それ以外の UFS ファイルシステムをすべてマウントしてから
スワップを有効にします。
CMOS クロックが地域時間に設定されていて
GMT ではない場合、
次のコマンドを実行する必要があるかもしれません。
&prompt.root; adjkerntz -i
こうすれば、
確実に地域時刻が正しく設定されます — これを怠ると、
あとあと問題になるかもしれません。
<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 *
ソースの再構築
出力メッセージの保存
実行される &man.make.1; からの出力は、ファイルに保存すると良いでしょう。
もし、何か障害が発生した場合、エラーメッセージのコピーを手元に残すことができます。
何が悪かったのか、あなた自身がそれから理解することはできないかも
知れませんが、&os; メーリングリストに投稿して、
誰か他の人からの助言を得るために利用することができます。
ファイルに保存する最も簡単な方法は、&man.script.1; コマンドを
使い、引数に出力を保存したいファイル名を指定することです。
これを make world の直前に行ない、再構築が終了してから
exit と入力すると、出力を保存することができます。
&prompt.root; script /var/tmp/mw.out
Script started, output file is /var/tmp/mw.out
&prompt.root; make TARGET
… compile, compile, compile …
&prompt.root; exit
Script done, …
出力を保存する場合、/tmp ディレクトリの中に
保存してはいけません。
このディレクトリは、次の再起動で削除されてしまう可能性があります。
出力の保存には、(上の例のように) /var/tmpや
root のホームディレクトリが適しています。
ベースシステムの構築とインストール
まず、カレントディレクトリを /usr/src に
変更しなければなりません。次のように実行してください。
&prompt.root; cd /usr/src
(もちろん、ソースコードが他のディレクトリにある場合には、
/usr/src ではなく、
ソースコードのあるディレクトリに移動してください)。
make
make world を行なうには、&man.make.1; コマンドを使用します。
このコマンドは、Makefile というファイルから、
FreeBSD を構成するプログラムの再構築方法や、
どういう順番でそれらを構築すべきかといったような
指示を読み込みます。
コマンドラインの一般的な書式は、次のとおりです。
&prompt.root; make
この例では、 が
&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
&os; の 2.2.5 から (実際には、&os.current; ブランチで最初に作成され、
2.2.2 と 2.2.5 の間の時点で &os.stable; に導入されたのですが)、
world ターゲットは
buildworld と
installworld の二つに分割されました。
その名前が示すように、buildworld は
/usr/obj 以下に新しい完全な
ディレクトリツリーを構築し、
installworld は、そのツリーを
現在のマシンにインストールします。
これは、二つの理由から非常に有用です。
まず第一に、稼働中のシステムに全く影響を与えることなく、
安全にシステムの構築作業を行えることです。
構築作業は 何にも依存せず独立して行なわれる
ため、
マルチユーザモードで稼働中のシステムでも、何一つ
悪影響を与えずに buildworld を
実行することができます。
ただし、installworld は
シングルユーザモードで行なうことをおすすめします。
第二に、NFS マウントを利用することで、
ネットワーク上の複数のマシンをアップグレードすることが
可能な点があげられます。たとえば三台のマシン、マシン A、マシン B、
マシン C をアップグレードしたい場合には、まず
マシン A で make buildworld と
make installworld を実行します。
それから、マシン B とマシン C でマシン A の
/usr/src と /usr/obj を
NFS マウントし、make installworld とすることで
構築済みのシステムを各マシンにインストールすることができるのです。
world ターゲットも利用可能ですが、
このターゲットの利用は推奨されていません。
次のコマンド
&prompt.root; make buildworld
を実行してください。ここで make に
オプションをつけると、
同時にいくつかのプロセスを生成させることができます。
この機能はマルチ CPU マシンで特に効果を発揮します。
構築過程の大部分では CPU 性能の限界より
I/O 性能の限界の方が問題となるため、シングル CPU
マシンにも効果があります。
普通のシングル CPU マシンで以下のコマンド
&prompt.root; make -j4 buildworld
を実行すると、&man.make.1; は最大 4 個までのプロセスを同時に実行します。
メーリングリストに投稿された経験的な報告によると、
4 個という指定が最も良いパフォーマンスを示すようです。
もし、複数の CPU を備えたマシンで SMP 設定が行なわれたカーネルを
利用しているなら、6 から 10 の間の値を設定し、速度がどれくらい
向上するか確認してみてください。
ただし、この機能はまだ実験段階であるということに注意してください。
そのため、ソースツリーへ変更が加えられたときに
これが正常に機能しなくなる可能性があります。
もし、このオプションを用いてシステムの構築に失敗した場合には、
障害を報告する前に、もう一度オプションを付けずに試してみてください。
システムの構築にかかる時間
make world
時間
構築時間を決める要素はさまざまありますが、
現時点では Pentium III の 500 MHz、128 MB の RAM という構成で
トリックや近道を使わずに普通に構築した場合、
&os.stable; の構築に約 2 時間かかります。
&os.current; の構築は、もう少し時間がかかります。
新しいカーネルの構築とインストール
カーネル (kernel)
構築、コンパイル
新しいシステムの全機能を完全に利用できるようにするには、
カーネルの再構築をする必要があります。
再構築は、ある種のメモリ構造体が変更された時には特に必須であり、
&man.ps.1; や &man.top.1; のようなプログラムは、
カーネルとソースコードのバージョンが一致しないと正常に動作しないでしょう。
最も簡単で安全にカーネルの再構築を行なう方法は、
GENERIC を使ったカーネルを構築・インストールすることです。
GENERIC にはあなたが必要とするデバイスがすべて含まれていない
かも知れませんが、あなたのシステムをシングルユーザモードで
起動させるのに必要なものはすべて入っています。
これは新しいバージョンのシステムがきちんと動作するかどうか
調べる良い方法の一つです。
GENERIC で起動してから、
あなたがいつも使っているカーネルコンフィグレーションファイルを
使って新しいカーネルを構築することで、
システムが正常に動作しているかどうか確かめることができます。
もし &os; 4.0 以降のシステムにアップグレードする場合、
( に記載されている)
古いカーネル構築手順はおすすめできません。
代わりに、
buildworld
を使ってシステムを構築したあとに、
以下のコマンドを実行してください。
&prompt.root; cd /usr/src
&prompt.root; make buildkernel
&prompt.root; make installkernel
&os; の 4.0 以前にアップグレードする場合は、
古いカーネル構築手順に従う必要があります。
ただし、以下のコマンドを使って新しいバージョンの
&man.config.8; を利用することが推奨されています。
&prompt.root; /usr/obj/usr/src/usr.sbin/config/config KERNELNAME
シングルユーザモードで再起動する
single-user mode
新しいカーネルが動作するかどうかテストするために、
シングルユーザモードで再起動するべきです。
シングルユーザモードでの起動は、
に書かれている手順に従ってください。
新しいシステムバイナリのインストール
十分最近のバージョンの &os; を
make buildworld で構築しているなら、
次にここで installworld を
使うことで新しいシステムバイナリのインストールを行ないます。
それには、以下のコマンドを実行してください。
&prompt.root; cd /usr/src
&prompt.root; make installworld
make buildworld でコマンドラインから
変数を指定した場合は、同じ指定を
make installworld のコマンドラインにも
指定しなければなりません。
ただし、オプションについてはその限りではありません。
たとえば は
installworld で絶対に使ってはいけません。
たとえば以下のように実行したなら、
&prompt.root; make -DNOPROFILE=true buildworld
以下のようにしてインストールしなければなりません。
&prompt.root; make -DNOPROFILE=true installworld
もしそうしなかった場合、
make buildworld の段階で構築されていない
プロファイル版ライブラリをインストールしようとしてしまうでしょう。
<command>make world</command> で更新されないファイルの更新
システムの再構築は、いくつかのディレクトリ (
特に、/etc や /var や
/usr) において、
新規に導入されたり、変更された設定ファイルによる
ファイルの更新は行なわれません。
これらのファイルを更新するもっとも簡単な方法は、&man.mergemaster.8;
を使うことです。これは自分でやることも可能なので、そうしても
かまいません。
いずれの方法に従うにせよ、
必ず /etc
のバックアップを取って不測の事態に備えてください。
<command>mergemaster</command>
mergemaster
&man.mergemaster.8; ユーティリティは Bourne シェルスクリプトで、
/etc にある設定ファイルとソースツリーの
/usr/src/etc にある設定ファイルの違いを確認するのを手伝ってくれます。
これを使うのが、ソースツリーにある設定ファイルにシステムの設定ファイルを
更新するために推奨される方法です。
mergemaster は
3.3-RELEASE と 3.4-RELEASE の間に FreeBSD
のベースシステムに統合されました。
つまり、3.3 以降の -STABLE と -CURRENT のシステムにはすべて
これがあるということです。
始めるには、プロンプトから単に
mergemaster と入力して、
ファイルの比較を開始するのを見てください。
mergemaster は
/ を起点とした一時的なルート環境を構築し、
さまざまなシステム設定ファイルを
(訳注: デフォルトでは /var/tmp/temproot に)
置いていきます。
次にこれらのファイルは現在システムにインストールされているファイルと比較されます。
この時点で、異なるファイルは &man.diff.1; 形式で示され、
の記号は追加または変更された行を表し、
は完全に削除されたか新しく置き換えられた行を表します。
&man.diff.1; の書式とファイルの違いの表示方法についてのより詳しい情報は、
&man.diff.1; を参照してください。
&man.mergemaster.8; は食い違いが起きているファイルをそれぞれ示します。
ここでは新しいファイル (一時ファイルとして参照されています) を削除するか、
一時ファイルをそのままインストールするか、
一時ファイルと現在インストールされているファイルを統合するか、
もしくは &man.diff.1; の結果をもう一度見るか選択できます。
一時ファイルの削除を選ぶと、&man.mergemaster.8;
に現在のファイルを変更しないで新しいバージョンを削除せよと伝えます。
この選択は、現在のファイルを変更する理由が分からないのであれば、
お勧めできません。
mergemaster のプロンプトで とタイプすれば、
いつでもヘルプが見られます。
ファイルのスキップを選ぶと、他のすべてのファイルを終えたあと、
もう一度そのファイルが提示されます。
一時ファイルをそのままインストールすることを選ぶと、
現在のファイルを新しいファイルで置き換えます。
ほとんどの手を加えていないファイルは、
これが一番よい選択です。
ファイルの統合を選んだ場合、
テキストエディタが起動され、両方のファイルの中身が提示されます。
画面上に並ぶ両方のファイルを見て新しいファイルを作成するために両方から必要な部分を選択し、
2 つのファイルを統合することができます。
並んでいるファイルを比較するとき、
キーで左側の中身を選択し、
キーで右側の中身を選択します。
最終出力は左右両方の部分でできたファイルになるでしょう。
このファイルをインストールすることができます。
たいてい、このオプシュンはユーザが設定を変更したファイルに使われます。
diff の結果をもう一度見る、を選択すると、
ちょうど先ほど &man.mergemaster.8; が選択肢を表示する前と同じように、
ファイルの相異点を見ることができます。
&man.mergemaster.8; がシステムファイルの比較を終えたあと、
他のオプションについてもプロンプトが表示されます。
&man.mergemaster.8; パスワードファイルを再構築したいかどうか、
MAKEDEV を実行するかどうかを訊かれることがあります。
最後に残った一時ファイルを削除するかどうかを尋ねて終了します。
手動での更新
手動で更新することを選んだ場合、
単にファイルを
/usr/src/etc から /etc に
コピーしただけでは正常に動作させることはできません。
これらのファイルには、インストールという
手順を踏まなければならないもの
が含まれています。
/usr/src/etc ディレクトリは
/etc
ディレクトリにそのまま置き換えられるような
コピーではないからです。
また、/etc にあるべきファイルのうちで
/usr/src/etc にないものもあります。
&man.mergemaster.8; を使っているのであれば (お勧めです)、
次のセクションまで飛ばしてもかまいません。
手動で行う際の
一番簡単な方法は、ファイルを新しいディレクトリにインストールしてから、
以前のものと異なっている部分を調べて更新作業を行なうことです。
既存の <filename>/etc</filename> をバックアップする
理論的に考えて、このディレクトリが自動的に
処理されることはありませんが、念には念を入れておいて
損はありません。たとえば以下のようにして、
既存の /etc ディレクトリを
どこか安全な場所にコピーしておきましょう。
&prompt.root; cp -Rp /etc /etc.old
は再帰的なコピーを行ない、
はファイルの更新時間や所有者などを保存します。
また、新しい /etc やその他のファイルを
インストールするための、仮のディレクトリを作っておく必要があります。
仮ディレクトリは /var/tmp/root に置くのが良いでしょう。
同様に、必要なサブディレクトリもこの下に置きます。
&prompt.root; mkdir /var/tmp/root
&prompt.root; cd /usr/src/etc
&prompt.root; make DESTDIR=/var/tmp/root distrib-dirs distribution
上の例は、必要なディレクトリ構造をつくり、ファイルをインストールします。
/var/tmp/root 以下に作られる、
たくさんの空のディレクトリは削除する必要があります。
一番簡単なやり方は、次のとおりです。
&prompt.root; cd /var/tmp/root
&prompt.root; find -d . -type d | xargs rmdir 2>/dev/null
これは空ディレクトリをすべて削除します。
(空でないディレクトリに関する警告を避けるために、
標準エラー出力は /dev/null に
リダイレクトされます)
この段階の /var/tmp/root には、
本来 / 以下にあるべきファイルが
すべて含まれています。
各ファイルを順に見て、既存のファイルと異なる部分を
調べてください。
/var/tmp/root 以下に
インストールされているファイルの中には、
.
から始まっているものがあります。
これを書いている時点で、それに該当するファイルは
/var/tmp/root/ と
/var/tmp/root/root/ の中にある
シェルスタートアップファイルだけですが、
他のものがあるかも知れません。
(これは、あなたがこれをどの時点で読んでいるかに依存するので、
もっとも簡単な方法は、二つのファイルを比較するコマンド
&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
もし DEVFS を利用しているなら、この作業は必要ありません。
ほとんどの場合、&man.mergemaster.8; は
デバイスの再構築が必要であることを検出して自動的にそれを実行するのですが、
ここではデバイスの再構築を手動で行なう方法について説明します。
安全のため、これはいくつかの段階に分けて行ないます。
/var/tmp/root/dev/MAKEDEV を
/dev にコピーします。
&prompt.root; cp /var/tmp/root/dev/MAKEDEV /dev
MAKEDEV
/etc を更新するのに
&man.mergemaster.8; を使った場合、
MAKEDEV スクリプトは既に更新
されているでしょうが、(&man.diff.1; を使って)
チェックすることは無駄ではありませんし、
必要なら自分でコピーしてください。
ここで、/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
再起動
これで、作業はおしまいです。
すべてがあるべき正しい場所に存在することをチェックしたら、
システムを再起動します。これは、単に
&man.fastboot.8; を実行するだけです。
&prompt.root; fastboot
作業の完了
ここまで来れば、&os; システムのアップグレードは成功です。
おめでとうございます。
もしちょっとした問題があった場合でも、
システムの一部を再構築するのは簡単です。
たとえば、アップグレードの途中で誤って
/etc/magic を削除して
/etc にマージしてしまい、
その結果 file
コマンドが動作しなくなってしまったような場合を考えてみてください。
これを修復するには、次のコマンドを実行すれば修復することができます。
&prompt.root; cd /usr/src/usr.bin/file
&prompt.root;
質問ですか?
変更が行なわれたら、その度にシステムの再構築が必要になるのでしょうか?
それは変更の性質によるので、なんとも言えません。
たとえば、CVSup を実行したとき、最後に実行したときから比べて
次にあげるようなファイルが更新されていたとします。
src/games/cribbage/instr.c
src/games/sail/pl_main.c
src/release/sysinstall/config.c
src/release/sysinstall/media.c
src/share/mk/bsd.port.mk
このときには、改めてシステム全体を再構築する必要はないでしょう。
適切なサブディレクトリに移って
make all install を行うだけで更新することができます。
しかし、もし何らかの大きな変更が行なわれているとき、たとえば
src/lib/libc/stdlib が変更されている場合には、
システム全体を再構築するか、もしくはそのうち、
少なくとも静的にリンクされているもの (と、あなたが追加した
静的にリンクされたプログラム) を作り直す必要があります。
結局のところ、どの時点で現在のシステムをアップグレードするかは
あなたが決めることです。
2 週間ごとにシステムを再構築し、その 2 週間の変更を取り込めば
幸せかもしれませんし、
変更のあった部分だけ再構築し、依存関係を確かめたいと考えるかも知れません。
もちろん、それらはどのくらいの頻度でアップグレードしたいか、
そして &os.stable; か &os.current; のどちらを追いかけているのかによります。
signal 11 (もしくは他のシグナル番号) のエラーがたくさん出て
コンパイルが失敗します。何が起こっているんでしょうか?
signal 11
これは通常、ハードウェアに問題があることを示しています。
システムの再構築は、ハードウェアに対する負荷耐久試験を行なうための
有効な手段の一つで、メモリに関係する問題がよく報告されます。
その大部分は、コンパイラが奇妙なシグナルを受け取り、
不可解な異常終了となることで発見されます。
本当にこの問題によるものかどうかは、再構築をもう一度実行し、
異なる段階で異常終了が発生するか、ということから確認できます。
この場合には、マシンの部品を交換して、どの部分が悪いのかを
調べてみることくらいしかできることはありません。
終了したら /usr/obj を削除しても
かまいませんか?
一言で答えるなら「削除しても構わない」です。
/usr/obj には、
コンパイルの段階で生成された
すべてのオブジェクトファイルが含まれています。
通常 make world
の最初の段階では、
このディレクトリを削除して新しくつくり直すようになっています。
その場合には、構築終了後の /usr/obj
を保存しておいても、あまり意味はありません。
削除すれば、大きなディスクスペースを
(現在はだいたい 340MB あります) 解放することができます。
しかし、もしあなたが何を行なおうとしているのか理解しているなら、
この段階を省略して make world
を行なうことができます。
こうすると、ほとんどのソースは再コンパイルされないため、
構築はかなり高速化されます。
これは裏をかえせば、デリケートな依存関係の問題によって、
システムの構築が奇妙な失敗に終わる可能性があるということです。
&os; メーリングリストではしばしば、構築の失敗が、
この段階の省略によるものだということを理解せずに
不満の声をあげる人がいます。
構築を中断した場合、その構築を途中から再開することはできますか?
それは、あなたが問題に気付く前に、
どれだけの作業を終えているかによって変わります。
一般的に (そしてこれは確実でしっかりした
規則ではありませんが)、
make world
の過程では、
基本的なツール ( &man.gcc.1; や &man.make.1; のようなもの)
や、システムライブラリの新しいコピーが作成されます。
その後まず、これらのツールやライブラリはインストールされてから
自分自身の再構築に使われ、もう一度、インストールされます。
全体のシステム (ここでは &man.ls.1; や &man.grep.1; といった
標準的なユーザプログラムを含みます) は、
その新しいシステムファイルを用いて作り直されることになります。
もし、再構築が最終段階に入っていること
が (記録しておいた出力を見たりすることで) わかっていたら、
(全く悪影響を与えることなく) 次のようにすることができます。
… fix the problem …
&prompt.root; cd /usr/src
&prompt.root; make -DNOCLEAN all
これは、前回の make world
の作業をやり直しません。
次のメッセージ
--------------------------------------------------------------
Building everything..
--------------------------------------------------------------
が make world
の出力にある場合には、
上のようにしてもほとんど悪影響が現れることはありません。
もしこのメッセージがないとか、よく分からないという場合には、
安全を確保し、後悔するようなことがないよう、
システムの再構築を最初からやり直しましょう。
どのようにすれば make world を高速化できますか?
シングルユーザモードで動かしてください。
/usr/src と
/usr/obj ディレクトリを、
異なるディスク上の別のファイルシステムに置いてください。
また可能ならば、異なるディスクコントローラに接続された
ディスクを使ってください。
さらに高速化するには、これらのファイルシステムを
&man.ccd.4; (連結ディスクドライバ) デバイスを
使って、複数のディスク上に置いてください。
プロファイル版の作成を無効化してください。
(/etc/make.conf で
NOPROFILE=true
をセットします)
普通、それが必要になることはありません。
また、/etc/make.conf の中の
CFLAGS を、
のように指定しましょう。
の最適化はさらに多くの時間を必要とし、
しかも と の
最適化には、ほとんど差はありません。
を指定することで、
コンパイラはテンポラリファイルの代わりにパイプを利用します。
その結果、(メモリの利用は増えますが) ディスクアクセスが減ります。
&man.make.1; に オプションを指定して、
複数のプロセスを並列に実行させてください。
これはプロセッサが単一か複数かによらず、
どちらも同様に恩恵を得ることができます。
/usr/src のある
ファイルシステムを、
オプションを付けてマウント (もしくは再マウント) してください。
これは、そのファイルシステムにおいて、
最後にアクセスされた時刻の書き込みを抑制します。
おそらく、この情報が必要になることはないでしょう。
&prompt.root; mount -u -o noatime /usr/src
上の例は、
/usr/src 自身が独立したファイルシステムで
あることを想定しています。
もしそうでないときには (たとえば /usr の
一部である場合には)、
/usr/src ではなく
適切なマウントポイントを指定する必要があります。
/usr/obj のあるファイルシステムを、
async
オプションをつけてマウント (もしくは
再マウント) してください。これによって、
ディスクへの書き込みが非同期になります。
つまり、書き込み命令はすぐに完了するのに対し、
実際にデータがディスクに書き込まれるのは、その数秒後になります。
これによって、書き込み処理の一括化が可能になるため、
劇的なパフォーマンスの向上が期待できます。
このオプションを指定すると、ファイルシステムは
壊れやすくなってしまうことに注意してください。
このオプションを付けていて、突然電源が落ちた場合には、
再起動後にファイルシステムが復旧不能になる可能性が
非常に高くなります。
もし、/usr/obj 自身が独立した
ファイルシステムであるならば、これは問題になりません。
しかし、同じファイルシステムに、他の貴重なデータを置いているときには、
このオプションを有効にする前に、
バックアップをきちんと取っておきましょう。
&prompt.root; mount -u -o async /usr/obj
もし /usr/obj 自身が
ファイルシステムでない場合には、適切なマウントポイントを指すように、
上の例の名前を置き換えてください。
なにか悪いことがあったらどうすればいいですか?
自分の環境に前のビルドの余計なゴミが残っていないことをはっきりと確認してください。
とても簡単です。
&prompt.root; chflags -R noschg /usr/obj/usr
&prompt.root; rm -rf /usr/obj/usr
&prompt.root; cd /usr/src
&prompt.root; make cleandir
&prompt.root; make cleandir
ええ、make cleandir
は本当に 2 回実行するのです。
そして、make buildworld を行い、
全プロセスを最初からやり直してください。
まだ問題があれば、エラーと uname -a
の出力を &a.questions; に送ってください。
自分の設定についてさらに質問されても答えられるよう用意してください!
Mike
Meyer
複数のマシンで追っかける
NFS
複数のマシンにインストール
同じソースツリーを追いかけたいマシンを複数の持っているなら、
全部のマシンにソースをダウンロードして全部再構築するのは資源、
つまりディスクスペース、ネットワーク帯域、そして CPU サイクルの無駄使いに思えます。
実際これは無駄で、解決策は 1 つのマシンに仕事のほとんどをさせ、
残りのマシンは NFS 経由でそれをマウントする、というものです。
このセクションではそのやり方を概観します。
準備
まず初めに、同じバイナリで動かそうとするマシンたちを決めます。
このマシンたちのことをビルドセットと呼びましょう。
それぞれのマシンはカスタムカーネルを持っているかもしれませんが、
同じユーザランドバイナリを動かそうというのです。
このビルドセットから、
ビルドマシンとなるマシンを 1 台選びます。
ベースシステムとカーネルを構築するのはこのマシンになります。
理想的には、このマシンは make world
を実行するのに十分な CPU を持った速いマシンであるべきです。
テストマシンとなるべきマシンも選びたいでしょう。
更新されたソフトウェアを使う前にそのマシンでテストするのです。
テストマシンはかなり長い時間落ちていても
だいじょうぶなマシンであったほうがいいでしょう。
ビルドマシンでもかまいませんが、ビルドマシンである必要はありません。
このビルドセットのマシンはすべて
/usr/obj と
/usr/src
を同じマシンの同じ場所からマウントする必要があります。
理想的にはビルドマシンの 2 つの違うドライブ上にあるとよいのですが、
ビルドマシンに NFS マウントされていてもかまいません。
ビルドセット自体が複数ある場合は、
/usr/src はひとつのビルドマシン上にあるべきです。
他のマシンからはそれを NFS マウントするようにしましょう。
最後にビルドセットの全てのマシン上の
/etc/make.conf
がビルドマシンと一致していることを確認してください。
つまり、ビルドマシンはビルドセットのどのマシンもインストールしようとしている
ベースシステムを全部ビルドしなければならないということです。
また、各ビルドマシンは /etc/make.conf
にそれぞれのビルドマシンのカーネル名を
KERNCONF で指定し、
ビルドマシンは自分自身のカーネルから順に全部のカーネル名を
KERNCONF にリストアップしてください。
各マシンのカーネルもビルドするのであれば、
ビルドマシンは各マシンのカーネル設定ファイルを
/usr/src/sys/arch/conf
に持っていなければなりません。
ベースシステム
さて、準備は整ったので、ビルドしましょう。
に書いてあるようにカーネルとベースシステムを構築してください。
でも、まだインストールしないでください。
ビルドが終わったら、テストマシンに移り、
ビルドしたばかりのカーネルをインストールしてください。
テストマシンが NFS 経由で
/usr/src と
/usr/obj をマウントしているなら、
シングルユーザで再起動したときネットワークを使えるようにしてマウントする必要があります。
もっとも簡単な方法は、
マルチユーザモードで起動して、shutdown now
を実行してシングルユーザモードに移行することです。
そうしたら、カーネルとベースシステムをインストールし、
いつもするように
mergemaster を実行できます。
終わったら、
テストマシンを再起動して通常のマルチユーザ動作に戻します。
テストマシンにあるものすべてがちゃんと動いている確信が得られたら、
同じ手順でビルドセットの他のマシンにも新しいソフトウェアをインストールします。
Ports
ports ツリーにも同じアイデアが使えます。
最初に重要な点は、
ビルドセットのすべてのマシンに同じマシンの
/usr/ports をマウントすることです。
そして、distfiles を共有するために、
/etc/make.conf を適切に設定します。
NFS マウントによってマップされる root
ユーザが何であれ、DISTDIR
はそのユーザが書き込める共通の共有ディレクトリに設定する必要があります。
各マシンは WRKDIRPREFIX
を自分のマシンのビルドディレクトリに設定しなければなりません。
最後に、パッケージをビルドして配布しようとしているなら、
DISTDIR と同じように
PACKAGES ディレクトリも設定してください。
diff --git a/ja_JP.eucJP/books/handbook/disks/chapter.sgml b/ja_JP.eucJP/books/handbook/disks/chapter.sgml
index f98c004349..52115ad757 100644
--- a/ja_JP.eucJP/books/handbook/disks/chapter.sgml
+++ b/ja_JP.eucJP/books/handbook/disks/chapter.sgml
@@ -1,3304 +1,3304 @@
ストレージ
この章では
この章では、FreeBSD におけるディスクの使用方法を説明します。
これにはメモリディスク、ネットワークに接続されたディスク、
および標準的な SCSI/IDE 記憶デバイスが含まれます。
この章では、以下の分野について説明します。
物理ディスク上のデータ構成
について記述するために FreeBSD が使用する用語
(パーティションおよびスライス)
システムにハードディスクを追加する方法
メモリディスクのような仮想ファイルシステムを設定する方法
使用できるディスク容量を制限するためにクォータを設定する方法
攻撃者から保護するためにディスクを暗号化する方法
FreeBSD で CD や DVD を作成する方法
バックアップのためのさまざまな記憶メディアオプション
FreeBSD で利用できるバックアッププログラムの使用方法
フロッピーディスクにバックアップする方法
スナップショットとは何か、そしてそれを効果的に使用する方法
デバイス名
以下は、FreeBSD で対応している物理記憶デバイスとそれに対応するデバイス名のリストです。
物理ディスクへの名前付け
ドライブの種類
ドライブのデバイス名
IDE ハードドライブ
ad
IDE CD-ROM ドライブ
acd
SCSI ハードドライブおよび USB 大容量記憶デバイス
da
SCSI CD-ROM ドライブ
cd
その他の非標準的 CD-ROM ドライブ
ミツミ CD-ROM は mcd,
Sony CD-ROM は scd,
松下/パナソニック CD-ROM は matcd
&man.matcd.4; ドライバは 2002 年 10 月 5 日に
FreeBSD 4.X ブランチから削除されました。
また、FreeBSD 5.0 および 5.1 リリースには存在しませんが、
2003 年 6 月 16 日に
FreeBSD 5.X ブランチに復帰しました。
フロッピードライブ
fd
SCSI テープドライブ
sa
IDE テープドライブ
ast
フラッシュドライブ
&diskonchip; フラッシュデバイスは
fla
RAID ドライブ
&adaptec; AdvancedRAID は aacd, &mylex;
は mlxd および mlyd,
AMI &megaraid; は amrd,
Compaq Smart RAID は idad,
&tm.3ware; RAID はtwed
David
O'Brien
原作:
ディスクの追加
ディスク
追加
現在一つしかドライブがない計算機に新しく SCSI
ディスクを追加したいとしましょう。まずコンピュータの電源を切り、
コンピュータやコントローラ、
ドライブの製造元の説明書に従ってドライブを取り付けます。
このあたりの手順は非常に多岐にわたるため、
詳細はこの文書の範囲外です。
root ユーザでログインします。
ドライブの取り付け後は /var/run/dmesg.boot
を調べて新しいディスクが見つかっていることを確認しておきます。
この例では、新しく付けたドライブは da1 で、
我々はそれを /1 にマウントしたいとしましょう
(もし IDE ドライブを付けようとしているのなら、デバイス名は
4.0 以前のシステムでは wd1, ほとんどの 4.x
システムでは ad1 になるでしょう)。
パーティション
スライス
fdisk
FreeBSD は IBM-PC 互換のコンピュータで動くため、
PC BIOS のパーティションを考慮に入れる必要があります。
これは従来の BSD パーティションとは異なります。PC ディスクは 4 つまでの
BIOS パーティションエントリを持つことができます。
もしそのディスクを本当に FreeBSD 専用にしたい場合には
専用 モードで用いることもできます。
そうでない場合には、FreeBSD は PC BIOS
パーティションのどれか一つの中に入れることになります。
FreeBSD では、従来の BSD パーティションと混乱しないように
PC BIOS パーティションのことをスライスと呼びます。
また、別の OS がインストールされていたコンピュータで使われていたが
FreeBSD 専用にするディスク上でもスライスを用いることができます。
これは、他の OS の fdisk
ユーティリティを混乱させないためです。
スライスの場合、ドライブは /dev/da1s1e
として加えられるでしょう。これは、SCSI ディスクでユニット番号は 1
(二つめの SCSI ディスク), スライスは 1 (PC BIOS のパーティションが 1) で
BSD パーティション e, と読みます。
専用ディスクの場合だと単純に /dev/da1e
として加えられるでしょう。
&man.sysinstall.8; の利用
sysinstall
ディスクの追加
su
<application>sysinstall</application> の操作
sysinstall の使い易いメニューを利用して、
新しいディスクのパーティション分けやラベル付けを行なうことができます。
root ユーザでログインするか
su コマンドを用いるかして root 権限を取得します。
/stand/sysinstall を実行して Configure
メニューに入ります。FreeBSD Configuration Menu
の中でスクロールダウンして Fdisk
の項目を選びます。
<application>fdisk</application> パーティションエディタ
fdisk では、ディスク全体を
FreeBSD で使うために A を入力します。
remain cooperative with any future possible operating systems
と聞かれたら YES と答えます。
W で変更をディスクに書き込みます。ここで
q と入力して FDISK エディタを抜けます。
次にマスタブートレコードについて聞かれます。
ここでは既に動いているシステムにディスクを追加しようとしているので
None を選びます。
ディスクラベルエディタ
BSD パーティション
次に sysinstall を終了し、
もう一度起動する必要があります。同じ手順を踏んで今度は
Label オプションを選択し、
Disk Label Editor に入ります。
ここでは従来の BSD パーティションを作成します。
一つのディスクは a から h までのラベルがついた最大
8 つのパーティションを持つことができます。
いくつかのパーティションラベルは特別な用途に用いられます。
a パーティションはルートパーティション
(/) です。したがって、システムディスク
(つまり起動ディスク) のみに a
パーティションがあるべきです。b
パーティションはスワップパーティションに用いられ、
複数のディスクにスワップパーティションを作ることができます。
c は専用モードにおけるディスク全体、
もしくはスライスモードにおけるスライス全体を指します。
他のパーティションは汎用的に用いられます。
sysinstall のラベルエディタ
は、ルートパーティションでもスワップパーティションでもないパーティションには、e
パーティションを採用しようとします。ラベルエディタでファイルシステムを作成するには
C を入力してください。
FS (ファイルシステム) かスワップかを聞かれたら
FS を選びマウントポイント
(たとえば /mnt) を入力します。
インストール後のモードでディスクを追加する場合、
sysinstall は
/etc/fstab にエントリを追加しないため、
ここで指定するマウントポイントはそれほど重要ではありません。
さて、ディスクに新しいラベルを書き込み、
そこにファイルシステムを作る準備が整いました。早速
W を叩いて実行しましょう。
sysinstall からの、
新しいパーティションをマウントできない、
というエラーは無視してください。Label Editor から抜け、
sysinstall を終了します。
終了
最後に /etc/fstab を編集し、
新しいディスクのエントリを追加します。
コマンドラインユーティリティの利用
スライスの利用
このセットアップ方法では、
すでにコンピュータに他のオペレーティングシステムがインストールされていても
正しく協調動作することが可能で、他のオペレーティングシステムの
fdisk ユーティリティを混乱させることもありません。
新しいディスクにインストールする場合は、
この方法を用いることが推奨されています。
後述する 専用モード は、
そうしなければならない理由がある時にのみ、
利用するようにしてください。
&prompt.root; dd if=/dev/zero of=/dev/da1 bs=1k count=1
&prompt.root; fdisk -BI da1 # 新しいディスクの初期化
&prompt.root; disklabel -B -w -r da1s1 auto # ディスクにラベルを付ける
&prompt.root; disklabel -e da1s1 # 作成したディスクラベルを編集し、パーティションを追加する
&prompt.root; mkdir -p /1
&prompt.root; newfs /dev/da1s1e # 作成したすべてのパーティションに対してこれを繰り返す
&prompt.root; mount /dev/da1s1e /1 # パーティションをマウントする
&prompt.root; vi /etc/fstab # /etc/fstab に適切なエントリを追加する
IDE ディスクを使う場合は da の部分を
ad とします。4.X より前のシステムでは、
(訳注: ad ではなく)
wd としてください。
専用モード
OS/2
新しいドライブを他の OS と共有しない場合には
専用 モードを用いることもできます。
このモードはマイクロソフトの OS
を混乱させることを憶えておいてください
(しかし、それらによって壊されることはありません)。 一方、IBM の &os2;
はどんなパーティションでも見つけたら理解できなくても
専有
します。
&prompt.root; dd if=/dev/zero of=/dev/da1 bs=1k count=1
&prompt.root; disklabel -Brw da1 auto
&prompt.root; disklabel -e da1 # `e' パーティションの作成
&prompt.root; newfs -d0 /dev/da1e
&prompt.root; mkdir -p /1
&prompt.root; vi /etc/fstab # /dev/da1e エントリの追加
&prompt.root; mount /1
もう一つの方法は次の通り。
&prompt.root; dd if=/dev/zero of=/dev/da1 count=2
&prompt.root; disklabel /dev/da1 | disklabel -BrR da1 /dev/stdin
&prompt.root; newfs /dev/da1e
&prompt.root; mkdir -p /1
&prompt.root; vi /etc/fstab # /dev/da1e エントリの追加
&prompt.root; mount /1
&os; 5.1-RELEASE から、従来の &man.disklabel.8;
プログラムは &man.bsdlabel.8;
ユーティリティに置き換えられました。&man.bsdlabel.8; では、
使用されていない数多くのオプションやパラメタが削除されました。
たとえば オプションは &man.bsdlabel.8;
では取り除かれました。詳細については &man.bsdlabel.8;
のマニュアルページを参照してください。
RAID
ソフトウェア RAID
Christopher
Shumway
原作:
Jim
Brown
改訂:
RAID
ソフトウェア
RAID
CCD
Concatenated Disk Driver (CCD) の設定
大容量記録に関する解決法を選択する際にもっとも重視すべき要素は、
速度、信頼性、そして費用です。
三つを同時にバランスよく実現することは稀です。
通常、速くて信頼性のある大容量記録装置は高価であり、
費用を抑えようとすると速度または信頼性のどちらかが犠牲になります。
ここで例にあげるシステムの設計においては、
費用が最も重要な要素として、次に速度、最後に信頼性が選択されています。
このシステムでのデータ転送速度は結局のところネットワークによって制限されます。
信頼性は大変重要です。ただし、以下で説明する CCD ドライブは、
データ自体はすでに CD-R に完全にバックアップしてあるもの
(したがって交換は簡単にできます)
の、オンラインデータの役割をさせています。
あなた自身の要求事項を決定することは、
大容量記録に関する解決法を選択することの最初の段階です。
もしあなたの要求事項が費用より速度または信頼性を優先するなら、
解決法はこのシステムとは違うものになるでしょう。
ハードウェアのインストール
IDE システムディスクに加えて、Western Digital 製の
30GB, 5400RPM の IDE ディスク三台を使って、
以下に説明されているような約 90GB のオンラインストレージとなる
CCD ディスクを作成しました。各 IDE ディスクがそれぞれの
IDE コントローラとケーブルをもっていることが理想的ですが、
費用を最低限にするために、
IDE コントローラを追加していません。その代わり、それぞれの IDE
コントローラがマスタデバイスを一つ、
スレーブデバイスを一つ持つように、
ディスクはジャンパを使って設定されています。
再起動の際に、システム BIOS
が接続されたディスクを自動的に検出するように設定されました。
より重要なことは、FreeBSD が再起動の際にそれらを検出することです。
ad0: 19574MB <WDC WD205BA> [39770/16/63] at ata0-master UDMA33
ad1: 29333MB <WDC WD307AA> [59598/16/63] at ata0-slave UDMA33
ad2: 29333MB <WDC WD307AA> [59598/16/63] at ata1-master UDMA33
ad3: 29333MB <WDC WD307AA> [59598/16/63] at ata1-slave UDMA33
FreeBSD がディスクをすべて検出しないときは、
ジャンパを正しく設定してあるか確認してください。多くの IDE
ドライブは ケーブルセレクト
ジャンパを持っています。
これはマスタ/スレーブの関係を設定するジャンパでは
ありません。ドライブの文書を参照して、
正しいジャンパ設定を見つけてください。
次に、ファイルシステムの一部分として、
それらをどのように接続するのかを考慮します。&man.vinum.8;
および &man.ccd.4;
の両方を検討すべきでしょう。この設定では、&man.ccd.4;
を選択しました。
CCD の設定
&man.ccd.4; ドライバは、いくつかの同じディスクを使って、
一つの論理的ファイルシステムに連結することができます。
&man.ccd.4; を使用するためには、カーネルが &man.ccd.4;
に対応している必要があります。
次の行をカーネルコンフィギュレーションファイルに追加して、
カーネルを再構築し、再インストールしてください。
pseudo-device ccd 4
5.X システムでは、
上記の代わりに次の行を追加しなければなりません。
device ccd
FreeBSD 5.X では &man.ccd.4;
デバイスの数を指定する必要はありません。&man.ccd.4;
デバイスドライバは自己複製するようになりました —
新しいデバイスインスタンスは、
必要に応じてその都度自動的に作成されます。
FreeBSD 3.0 以降では、
カーネルモジュールを読み込んで
&man.ccd.4; に対応することもできます。
&man.ccd.4; を設定するために、まず &man.disklabel.8;
を使用してディスクにラベルを書き込まなくてはなりません。
disklabel -r -w ad1 auto
disklabel -r -w ad2 auto
disklabel -r -w ad3 auto
このコマンドはディスク全体を示す
ad1c,
ad2c および
ad3c に対するディスクラベルを作成します。
&os; 5.1-RELEASE から、従来の &man.disklabel.8;
プログラムは &man.bsdlabel.8;
ユーティリティに置き換えられました。&man.bsdlabel.8; では、
使用されていない数多くのオプションやパラメタが削除されました。
たとえば オプションは &man.bsdlabel.8;
では取り除かれました。詳細については &man.bsdlabel.8;
のマニュアルページを参照してください。
次に、ディスクラベルのタイプを変更します。
&man.disklabel.8; を使用してディスクラベルを編集してください。
disklabel -e ad1
disklabel -e ad2
disklabel -e ad3
このコマンドは EDITOR
環境変数に設定されているエディタ (一般的には &man.vi.1;)
でそれぞれのディスクの現在のディスクラベルを開きます。
変更されていないディスクラベルは以下のようになります。
8 partitions:
# size offset fstype [fsize bsize bps/cpg]
c: 60074784 0 unused 0 0 0 # (Cyl. 0 - 59597)
&man.ccd.4; で使用する e
パーティションを作成します。通常では c
パーティションの行をコピーすれば良いでしょう。しかし、
は 4.2BSD
でなければ なりません。
ディスクラベルは以下のようになるでしょう。
8 partitions:
# size offset fstype [fsize bsize bps/cpg]
c: 60074784 0 unused 0 0 0 # (Cyl. 0 - 59597)
e: 60074784 0 4.2BSD 0 0 0 # (Cyl. 0 - 59597)
ファイルシステムの構築
ccd0c
デバイスノードはまだ存在していないかも知れません。
そのときは、次のコマンドを実行して作成してください。
cd /dev
sh MAKEDEV ccd0
FreeBSD 5.0 では &man.devfs.5; が
/dev 以下のデバイスノードを自動的に管理するので、
MAKEDEVを使用する必要はありません。
すべてのディスクにラベルを書き込んだので、
&man.ccd.4; を構築してください。
これを行うためには、以下のようなオプションで
&man.ccdconfig.8; を使います。
ccdconfig ccd0 32 0 /dev/ad1e /dev/ad2e /dev/ad3e
各オプションの使用法と意味は以下の通りです。
一番目の引数は設定するデバイスです。この例の場合は
/dev/ccd0c です。
/dev/ の部分はオプションです。
ファイルシステムに対するインタリーブです。インタリーブは、
ディスクブロック内のストライプサイズを定義します。
ディスクブロックは通常 512 バイトです。したがって 32
インタリーブは 16,384 バイトとなります。
これは &man.ccdconfig.8; に対するフラグです。
ドライブミラーリングを有効にしたい場合、
ここにフラグを指定します。
この設定では &man.ccd.4; に対するミラーリングは提供しませんので、
0 (ゼロ) を指定しています。
この &man.ccdconfig.8; に対する最後の引数は、
アレイ内に置くデバイスです。
それぞれのデバイスに対する完全なパス名を使用します。
&man.ccdconfig.8; を実行すると &man.ccd.4; が設定されます。
これでファイルシステムをインストールすることが可能です。
オプションについて &man.newfs.8; を参照するか、
次のように実行してください。
newfs /dev/ccd0c
自動的に設定する
一般的に、再起動するたびに &man.ccd.4;
をマウントしたいと思うでしょう。これを行うために、
まず設定をしなければなりません。次のコマンドを用いて、
現在の設定を /etc/ccd.conf に書き出します。
ccdconfig -g > /etc/ccd.conf
/etc/ccd.conf が存在すると、
再起動の際に /etc/rc スクリプトが
ccdconfig -C を実行します。これにより、
&man.ccd.4; は自動的に設定された後、マウントされます。
シングルユーザモードで起動している場合には、
&man.ccd.4; を &man.mount.8; する前に、
アレイを設定するために次のコマンドを実行する必要があります。
ccdconfig -C
自動的に &man.ccd.4; をマウントするには、
/etc/fstab に &man.ccd.4;
のエントリ追加します。このように設定すると起動時にマウントされます。
/dev/ccd0c /media ufs rw 2 2
Vinum ボリュームマネージャ
RAID
ソフトウェア
RAID
Vinum
Vinum ボリュームマネージャは、
仮想ディスクドライブを実装したブロックデバイスドライバです。
Vinum は、ディスクハードウェアをブロックデバイスインタフェースから
分離し、データを配置します。
その結果、ディスク記憶装置を従来のスライスで扱うのと比較して、
柔軟性、性能および信頼性が向上しています。
&man.vinum.8; は RAID-0, RAID-1 および RAID-5 モデル、
そしてそれぞれの組合せを実装しています。
&man.vinum.8; の詳細については Vinum ボリュームマネジャ
を参照してください。
ハードウェア RAID
RAID
ハードウェア
FreeBSD は、さまざまなハードウェア RAID
コントローラにも対応しています。これらのデバイスはアレイを制御するための
特別なソフトウェアを FreeBSD で必要することなく、
RAID サブシステムを制御します。
カード上の BIOS を使用して、
カードはそれ自身でディスク操作のほとんどを制御します。以下は
Promise IDE RAID
コントローラを使用した設定の簡単な説明です。
このカードがインストールされ、システムが起動したときには、
情報の入力を促すプロンプトを表示します。
指示にしたがってカードの設定画面に進んでください。
接続されたドライブを組み合わせるように設定することができます。
設定後、ディスクは FreeBSD に対して単一のドライブのように見えます。
他の RAID レベルは適宜設定できます。
ATA RAID1 アレイの再構築
FreeBSD はアレイ内の障害ディスクを動作中に交換できます。
ただし、再起動前にそれを検知していることが必要です。
/var/log/messages または &man.dmesg.8;
の出力に次のような行があるでしょう。
ad6 on monster1 suffered a hard error.
ad6: READ command timeout tag=0 serv=0 - resetting
ad6: trying fallback to PIO mode
ata3: resetting devices .. done
ad6: hard error reading fsbn 1116119 of 0-7 (ad6 bn 1116119; cn 1107 tn 4 sn 11) status=59 error=40
ar0: WARNING - mirror lost
&man.atacontrol.8; を使用して詳細を調べてください。
&prompt.root; atacontrol list
ATA channel 0:
Master: no device present
Slave: acd0 <HL-DT-ST CD-ROM GCR-8520B/1.00> ATA/ATAPI rev 0
ATA channel 1:
Master: no device present
Slave: no device present
ATA channel 2:
Master: ad4 <MAXTOR 6L080J4/A93.0500> ATA/ATAPI rev 5
Slave: no device present
ATA channel 3:
Master: ad6 <MAXTOR 6L080J4/A93.0500> ATA/ATAPI rev 5
Slave: no device present
&prompt.root; atacontrol status ar0
ar0: ATA RAID1 subdisks: ad4 ad6 status: DEGRADED
ディスクを安全に取り外すために、
まずアレイから切り離します。
&prompt.root; atacontrol detach 3
ディスクを取り外します。
スペアのディスクを取り付けます。
&prompt.root; atacontrol attach 3
Master: ad6 <MAXTOR 6L080J4/A93.0500> ATA/ATAPI rev 5
Slave: no device present
アレイを再構築します。
&prompt.root; atacontrol rebuild ar0
再構築コマンドは完了するまで他の操作を受け付けません。しかし、
もう一つ別のターミナルを
(Alt
Fn
を押して) 開き、
次のコマンドを実行すると進行状態を確認することができます。
&prompt.root; dmesg | tail -10
[output removed]
ad6: removed from configuration
ad6: deleted from ar0 disk1
ad6: inserted into ar0 disk1 as spare
&prompt.root; atacontrol status ar0
ar0: ATA RAID1 subdisks: ad4 ad6 status: REBUILDING 0% completed
操作が完了するまでお待ちください。
Mike
Meyer
寄稿:
光メディア (CD & DVD) の作成と使用
CDROM
作成
はじめに
CD は他の一般的なディスクと異なる様々な特徴を持っています。
そもそもユーザが書き込むことができません。
また遅延なしで連続的に読み出せるように、
トラック間をヘッドが移動しないですむようにデザインされています。
さらにこのサイズのメディアの中ではシステムをまたぐデータの
移動が比較的簡単でもあります。
CD はトラックの概念を持っていますが、
これはデータを連続的に読み出すためのものであってディスクの物理特性ではありません。
FreeBSD で CD を作成するには、まず CD
のトラックとなるデータファイルを用意し、
そのトラックを CD に書き込みます。
ISO 9660
ファイルシステム
ISO 9660
ISO 9660 ファイルシステムはこの様な差異を扱うべく設計されました。
その結果、ファイルシステムは一般的に使用するのに差しつかえない程度に
制限されて標準化されています。幸いなことに、ISO 9660
ファイルシステムには拡張機構が提供されています。適切に書かれた CD は、
拡張機構に対応したシステムでは拡張を利用して、そうでないシステムでは
拡張機構を使用しない範囲で動作するようになっています。
sysutils/mkisofs
sysutils/mkisofs プログラムは
ISO 9660 ファイルシステムを含むデータファイルを作成するのに使われます。
これには様々な拡張をサポートするオプションがあり、
以下で説明します。 このソフトウェアは、ports の
sysutils/mkisofs
からインストールすることができます。
CD ライタ
ATAPI
CD に書き込むためのツールは、お使いの CD ライタが ATAPI
接続か否かにも依存します。ATAPI CD ライタなら、ベースシステムの一部である
burncd
プログラムを使います。SCSI や USB の CD ライタなら、ports の
sysutils/cdrecord
をインストールして
cdrecord
プログラムを使うべきでしょう。
burncd
が対応しているドライブは限定されています。
ドライブが対応されているかどうかを確認するには、
CD-R/RW supported
drives にある一覧を見てください。
CD ライタ
ATAPI/CAM ドライバ
&os; 5.X または &os; 4.8-RELEASE
以降のバージョンを使用している場合、
ATAPI/CAM モジュール を使用すると
ATAPI ハードウェア上で SCSI ドライブ用の
cdrecord
および他のツールを使用できるようになります。
mkisofs
sysutils/mkisofs は &unix;
ファイルシステムの名前空間におけるディレクトリツリーのイメージとして
ISO 9660 ファイルシステムを作成します。
最も簡単な使い方は以下の通りです。
&prompt.root; mkisofs -o imagefile.iso /path/to/tree
ファイルシステム
ISO 9660
このコマンドは /path/to/tree
以下のディレクトリツリーのコピーである ISO 9660
ファイルシステムを含んだ imagefile.iso
ファイルを作成します。この過程において、ファイル名は標準的な ISO 9660
ファイルシステムの制限に適合するようなファイル名に対応づけられ、
ISO ファイルシステムでファイル名を文字化できないファイルは除外されます。
ファイルシステム
HFS
ファイルシステム
Joliet
この制限を回避するために利用できるオプションはいくつもあります。
特に オプションは &unix; システムで標準的な Rock Ridge
拡張を有効にします。 オプションは Microsoft
のシステムで標準的な Joliet 拡張を有効にし、
オプションは &macos; で使用されている
HFS ファイルシステムを作成するために使われます。
FreeBSD でしか使わないのであれば、
オプションを使用するとあらゆるファイル名制限を無効にできます。
さらに オプションとともに使うことで
FreeBSD と同一のファイルシステムイメージを作成できますが、
これは ISO 9660 標準の多くを無視しています。
CDROM
ブータブル (起動可能な) CDROM の作成
一般的に使われる最後のオプションは オプションです。
これは El Torito
ブータブル CD
を作成するのに使う起動イメージのありかを指定します。
このオプションは引数として起動イメージへのパスを、
CD に書き込まれるディレクトリツリーの頂点からの相対位置で取ります。
したがって /tmp/myboot がブート可能な
FreeBSD システムで /tmp/myboot/boot/cdboot
にブートイメージがあるならば、以下のようにすることで ISO 9660
ファイルシステムのイメージを /tmp/bootable.iso
に作成することができます。
&prompt.root; mkisofs -U -R -b boot/cdboot -o /tmp/bootable.iso /tmp/myboot
この後、カーネルで vn (FreeBSD 4.X)
または md (FreeBSD 5.X)
が設定されていれば、
ファイルシステムを以下のようにしてマウントすることができます。
&prompt.root; vnconfig -e vn0c /tmp/bootable.iso
&prompt.root; mount -t cd9660 /dev/vn0c /mnt
FreeBSD 4.X および FreeBSD 5.X に対しては以下の通りです。
&prompt.root; mdconfig -a -t vnode -f /tmp/bootable.iso -u 0
&prompt.root; mount -t cd9660 /dev/md0 /mnt
/mnt と
/tmp/myboot が同一かどうか確認してください。
sysutils/mkisofs
には挙動を細かく制御するために他にもたくさんのオプションがあります。
特に、ISO 9660
レイアウトの変更や Joliet および HFS ディスク作成などの
詳細は &man.mkisofs.8; のマニュアルページをご覧ください。
burncd
CDROM
書き込み
あなたが持っているのが ATAPI CD ライタなら、CD に ISO
イメージを書き込むために burncd コマンドが使えます。
burncd はベースシステムの一部で
/usr/sbin/burncd としてインストールされています。
使い方はとても単純でオプションも少ししかありません。
&prompt.root; burncd -f cddevice data imagefile.iso fixate
以上のコマンドは imagefile.iso
のコピーを cddevice に書き込みます。
デフォルトのデバイスは /dev/acd0c です。
書き込み速度や操作完了後に CD を自動的に取り出す方法、
オーディオデータの書き込みなどのオプションについては &man.burncd.8;
を見てください。
cdrecord
あなたが持っている CD ライタが ATAPI ではなければ、
CD を書き込むのに cdrecord を使う必要があります。
cdrecord はベースシステムの一部ではなく、
sysutils/cdrtools の port または
適切な package を利用してインストールしなければなりません。
なお、ベースシステムを変更するとバイナリに矛盾が発生し、
コースター
を作ってしまうおそれがあります。
したがって、システムをアップグレードする度にこの port も作り直すか、
あるいはFreeBSD の安定版を追いかけているのならば、
新しいバージョンが利用できるようになった時に ports
をアップグレードする必要があります。
cdrecord にはたくさんのオプションがありますが、
基本的な使い方は burncd よりもさらに簡単です。
ISO 9660 イメージを書き込むには以下のようにします。
&prompt.root; cdrecord dev=device imagefile.iso
cdrecord のトリッキーな部分は、使用する
を見つけるところにあります。
適切な設定を見つけるためには cdrecord の
フラグを使います。
たとえば、以下のような結果が出力されるでしょう。
CDROM
書き込み
&prompt.root; cdrecord -scanbus
Cdrecord 1.9 (i386-unknown-freebsd4.2) Copyright (C) 1995-2000 Jörg Schilling
Using libscg version 'schily-0.1'
scsibus0:
0,0,0 0) 'SEAGATE ' 'ST39236LW ' '0004' Disk
0,1,0 1) 'SEAGATE ' 'ST39173W ' '5958' Disk
0,2,0 2) *
0,3,0 3) 'iomega ' 'jaz 1GB ' 'J.86' Removable Disk
0,4,0 4) 'NEC ' 'CD-ROM DRIVE:466' '1.26' Removable CD-ROM
0,5,0 5) *
0,6,0 6) *
0,7,0 7) *
scsibus1:
1,0,0 100) *
1,1,0 101) *
1,2,0 102) *
1,3,0 103) *
1,4,0 104) *
1,5,0 105) 'YAMAHA ' 'CRW4260 ' '1.0q' Removable CD-ROM
1,6,0 106) 'ARTEC ' 'AM12S ' '1.06' Scanner
1,7,0 107) *
リストにあるデバイスに対する適切な
の値がここに示されています。あなたの CD ライタをこのリストから見つけ、
カンマで区切られた 3 つの数値を
の値として使ってください。この例では CRW デバイスは 1,5,0
なので、適切な入力は となります。
値を明示するもっと簡単な方法もあります。詳細は &man.cdrecord.1;
を見てください。そこにはオーディオトラックを書き込む方法や、
書き込み速度その他を操作する方法も書かれています。
オーディオ CD の複製
CD からオーディオデータを連続したファイルに展開し、ブランク CD
にこれらのファイルを書き込むことで、オーディオ CD
を複製することができます。
この手順は ATAPI および SCSI ドライブの間で少し異なります。
SCSI ドライブ
cdda2wav を使用してオーディオを展開します。
&prompt.user; cdda2wav -v255 -D2,0 -B -Owav
cdrecord を使用して
.wav ファイルに書き出します。
&prompt.user; cdrecord -v dev=2,0 -dao -useinfo *.wav
に説明されているように
2.0
が適切に指定されていることを確かめてください。
ATAPI ドライブ
ATAPI CD ドライバでは、それぞれのトラックを
/dev/acddtnn のように利用できます。
ここで d はドライブ番号であり、
nn は二桁十進のトラック番号です。
一桁の場合 0 を前に付加する必要があります。
したがって、一番目のディスクの一番目のトラックは
/dev/acd0t01、二番目のトラックは
/dev/acd0t02、三番目のトラックは
/dev/acd0t03 などとなります。
適切なデバイスファイルが /dev
に存在することを確かめてください。
存在しなければ、たとえば次のようにして作成します。
&prompt.root; cd /dev
&prompt.root; sh MAKEDEV acd0t99
FreeBSD 5.0 では &man.devfs.5; が
/dev にエントリを自動的に作成、
管理するので、MAKEDEV
を使用する必要はありません。
&man.dd.1; を使用して各トラックを展開します。
ファイルを展開する際、ブロックサイズを指定しなければなりません。
&prompt.root; dd if=/dev/acd0t01 of=track1.cdr bs=2352
&prompt.root; dd if=/dev/acd0t02 of=track2.cdr bs=2352
...
burncd を使用して、
展開したファイルをディスクに書き込みます。
これらがオーディオファイルであること、
そして書き込みが終了したときに burncd
がディスクを固定 (fixate) することを明示しなければなりません。
&prompt.root; burncd -f /dev/acd0c audio track1.cdr track2.cdr ... fixate
データ CD の複製
データ CD を、sysutils/mkisofs
を用いて作成されたイメージファイルと機能的に等価なイメージファイルにコピーできます。
これを使用して、すべてのデータ CD を複製することができます。
ここでの例は CDROM デバイスが acd0
であるとしています。あなたの CDROM デバイスに読み替えてください。
CDROM の場合には、パーティション全体またはディスク全体
を指定するために c
をデバイス名の後に追加しなければなりません。
&prompt.root; dd if=/dev/acd0c of=file.iso bs=2048
これでディスクイメージを取り出すことができました。
すでに説明した方法を用いて CD に書き込むことができます。
データ CD の使用
さて、標準的なデータ CDROM を作成したので、
おそらく次はそれをマウントしてデータを読み出したいと思うでしょう。
デフォルトでは &man.mount.8; は、ファイルシステムタイプを
ufs としています。
次のように実行しようとすると、
&prompt.root; mount /dev/cd0c /mnt
Incorrect super block
というエラーが返されてマウントできないでしょう。
CDROM は UFS ファイルシステムではないために、
このような手順でマウントしようすると失敗します。
ファイルシステムのタイプが ISO9660 であると
&man.mount.8; に教えさえすれば、すべてはうまく動作します。
&man.mount.8; に
オプションを指定することでこれを行います。
たとえば /dev/cd0c の CDROM デバイスを
/mnt にマウントしたい場合は、
以下のように実行します。
&prompt.root; mount -t cd9660 /dev/cd0c /mnt
使用している CDROM インタフェースによっては、
デバイス名
(この例では /dev/cd0c)
が異なるかもしれないことに注意してください。
また、 オプションは、単に
&man.mount.cd9660.8; を実行します。
この例を以下のように短縮することもできます。
&prompt.root; mount_cd9660 /dev/cd0c /mnt
一般的にこの方法では、すべてのメーカの データ CDROM
を使用することができます。しかしながら、特定の ISO 9660
拡張が施されたディスクでは奇妙な動作をするかもしれません。
たとえば Joliet ディスクは、
すべてのファイル名を 2 バイトの Unicode 文字で格納します。
FreeBSD カーネルは (まだ) Unicode を理解できないので、
非英語文字はクエスチョンマークで表示されます
(FreeBSD 4.3 以降を使用している場合、CD9660 ドライバには適切な Unicode
変換表を読み込むための急ごしらえのフックが含まれています。
いくつかの共通のエンコードに対するモジュールは
sysutils/cd9660_unicode port
から利用可能です)。
CDROM をマウントしようとする時に、
Device not configured
と表示されるかもしれません。これは、ディスクがトレーにないと
CDROM ドライブが判断しているか、
ドライブがバス上に認識できないことを通常意味します。
ディスクが挿入されたことを CDROM ドライブが認識するには数秒かかりますので、
辛抱強く待ってください。
バスのリセットに返答するためのタイムアウトが短いために、時々 SCSI
CDROM は認識に失敗するかもしれません。SCSI CDROM を持っている場合は、
次のオプションをカーネルコンフィギュレーションファイルに追加して、
カーネルを再構築してください。
options SCSI_DELAY=15000
これより、SCSI バスを起動時に 15 秒間停止させて、
CDROM ドライブがバスリセットに応答する機会を与えます。
Raw データ CD の書き込み
ISO 9660 ファイルシステムを作成すること無く、
ファイルを直接 CD に書き込むこともできます。
この方法をバックアップ目的に使用している人もいます。
これは、標準 CD を書き込むよりもさらに速く実行することができます。
&prompt.root; burncd -f /dev/acd1c -s 12 data archive.tar.gz fixate
このように CD に書き込まれたデータを取得するには、
raw デバイスノードからデータを読み込まなくてはなりません。
&prompt.root; tar xzvf /dev/acd1c
このディスクを通常の CDROM としてマウントすることはできません。
このような CDROM は FreeBSD を除いて、
他のすべてのオペレーティングシステムでは読み込むことはできません。
CD をマウントしたいか、
その他のオペレーティングシステムとデータを共有したい場合は、
上記に説明したように
sysutils/mkisofs
を使用しなくてはなりません。
CD ライタ
ATAPI/CAM ドライバ
ATAPI/CAM ドライバの使用
このドライバは、ATAPI デバイス (CD-ROM, CD-RW, DVD ドライブなど)
へ SCSI サブシステムを通じてアクセスすることを可能にします。
これにより、sysutils/cdrdao または
&man.cdrecord.1; のようなアプリケーションが使用できるようになります。
このドライバを使用するためには、
カーネルコンフィギュレーションファイルに次の行を追加する必要があります。
device atapicam
device scbus
device cd
device pass
次の行もカーネルコンフィギュレーションファイルに必要です。
device ata
device atapicd
両方がすでに存在しなければなりません。
それから再構築し、新しいカーネルをインストールし、
コンピュータを再起動します。
起動プロセス中にディスクライタは以下のように表示されるでしょう。
acd0: CD-RW <MATSHITA CD-RW/DVD-ROM UJDA740> at ata1-master PIO4
cd0 at ata1 bus 0 target 0 lun 0
cd0: <MATSHITA CDRW/DVD UJDA740 1.00> Removable CD-ROM SCSI-0 device
cd0: 16.000MB/s transfers
cd0: Attempt to query device size failed: NOT READY, Medium not present - tray closed
ドライブは /dev/cd0
デバイスを通じてアクセスすることが可能となります。
たとえば、次のようにして CD-ROM を /mnt
にマウントします。
&prompt.root; mount -t cd9660 /dev/cd0c /mnt
root 権限で次のコマンドを実行して、
ライタの SCSI アドレスを得ることができます。
&prompt.root; camcontrol devlist
<MATSHITA CDRW/DVD UJDA740 1.00> at scbus1 target 0 lun 0 (pass0,cd0)
したがって、1,0,0 が &man.cdrecord.1;
およびその他の SCSI アプリケーションで使用する SCSI アドレスです。
ATAPI/CAM および SCSI システムの詳細は &man.atapicam.4; および
&man.cam.4; マニュアルページを参照してください。
Julio
Merino
原作:
Martin
Karlsson
改訂:
フロッピーディスクの作成と使用
フロッピーディスクにデータを格納することはしばしば役にたちます。
たとえば、ある人が他のリムーバブル記録メディアを何も持っていないときや、
小さなデータを他のコンピュータに移動させる必要があるときです。
この節では、FreeBSD におけるフロッピーディスクの使用方法を説明します。
主に 3.5 インチの DOS フロッピーのフォーマットと操作方法を扱いますが、
他のフロッピーディスクの形式についても概念は似ています。
フロッピーのフォーマット
デバイス
他のデバイスと同様に、フロッピーディスクは
/dev にあるエントリを通じてアクセスされます。4.X
およびそれ以前のリリースにおいて raw
フロッピーディスクにアクセスするには
/dev/fdN
または /dev/fdNX
を使用します。N はドライブ番号を表し、
大抵は 0 です。X は文字を表します。
5.0 およびそれ以降のリリースでは、単に
/dev/fdN を使用します。
4.X およびそれ以前のリリースでのディスクサイズ
/dev/fdN.size というデバイスもあります。
size
はフロッピーディスクのサイズをキロバイトで示したものです。
これらのエントリは低レベルフォーマットの際に、
ディスクサイズを決定するのに使用されます。
1440kB は以下の例で使用されるサイズです。
時々 /dev 下のエントリは (再)
作成されなければなりません。次のコマンドでこれを行います。
&prompt.root; cd /dev && ./MAKEDEV "fd*"
5.X およびそれ以降のリリースでのディスクサイズ
FreeBSD 5.0 では &man.devfs.5; が
/dev 内のエントリを自動的に管理するので、
MAKEDEVを使用する必要はありません。
所望のディスクサイズは &man.fdformat.1; に
フラグを通して渡されます。対応しているサイズは &man.fdcontrol.8;
のマニュアルページに掲載されていますが、最良に動作するのは
1440kB だと助言しておきます。
フォーマット
フロッピーディスクは、
使用前に低レベルフォーマットをする必要があります。
通常、ベンダは低レベルフォーマット済みのディスクを出荷していますが、
フォーマットはメディアの品質を確認するよい方法です。
より大きな (または小さな) ディスクサイズにすることも可能ですが、
ほとんどのフロッピーディスクのサイズは 1440kB で動作するように設計されています。
フロッピーディスクを低レベルフォーマットするには
&man.fdformat.1; を使用する必要があります。
このユーティリティは引数としてデバイス名を指定します。
ディスクが良好かあるいは不良であるかを決定するのに役立つので、
エラーメッセージをすべてメモに取っておいてください。
4.X 以前のリリースでのフォーマット
/dev/fdN.size デバイスを使ってフロッピーをフォーマットします。
新しい 3.5 インチフロッピーディスクをドライブに挿入し、
以下のコマンドを実行してください。
&prompt.root; /usr/sbin/fdformat /dev/fd0.1440
5.0 以降のリリースでのフォーマット
/dev/fdN
デバイスを使用してフロッピーをフォーマットします。
新しい 3.5 インチフロッピーディスクをドライブに挿入し、
以下のコマンドを実行してください。
&prompt.root; /usr/sbin/fdformat -f 1440 /dev/fd0
ディスクラベル
ディスクを低レベルフォーマットしたら、
次にディスクラベルを作成する必要があります。
ディスクラベルは後で破棄されますが、
システムがディスクのサイズとジオメトリを決定するのに必要になります。
新しいディスクラベルはディスク全体を引き継ぎ、
フロッピーのジオメトリに関する適切な情報のすべてが含まれます。
ディスクラベルに対するジオメトリの値は
/etc/disktab に掲載されています。
次のように &man.disklabel.8; を実行できます。
&prompt.root; /sbin/disklabel -B -r -w /dev/fd0 fd1440
&os; 5.1-RELEASE から、従来の &man.disklabel.8;
プログラムは &man.bsdlabel.8;
ユーティリティに置き換えられました。&man.bsdlabel.8; では、
使用されていないオプションおよびパラメタの数多くが削除されました。
たとえば オプションは &man.bsdlabel.8;
では取り除かれました。詳細については &man.bsdlabel.8;
マニュアルページを参照してください。
ファイルシステム
これでフロッピーを高レベルフォーマットする準備ができました。これは
FreeBSD がディスクを読み書きする新しいファイルシステムを作成します。
新しいファイルシステムを作成するとディスクラベルは破棄されます。
したがって、ディスクを再フォーマットするときには、
ディスクラベルを再作成しなくてはなりません。
フロッピーのファイルシステムには UFS または FAT を使用できます。
フロッピーに対しては FAT が一般的によりよい選択です。
フロッピー上に新しいファイルシステムを作成するには次のようにします。
&prompt.root; /sbin/newfs_msdos /dev/fd0
これでディスクが使用できるようになりました。
フロッピーの使用
フロッピーを使用するために、&man.mount.msdos.8;
(4.X 以前のリリース) または &man.mount.msdosfs.8;
(5.0 以後のリリース) を用いてマウントします。
Ports Collection から
emulators/mtools
を使用することもできます。
データテープの作成と使用
テープメディア
主要なテープメディアは 4mm, 8mm, QIC, ミニカートリッジ および DLT です。
4mm (DDS: Digital Data Storage)
テープメディア
DDS (4mm) テープ
テープメディア
QIC テープ
4mm テープはワークステーションのバックアップメディアの選択として
QIC に取って代わりつつあります。Conner が QIC
ドライブの主要なメーカである Archive を買収し、
QIC ドライブの製造を中止した時にこの傾向は非常に強まりました。4mm
ドライブは小さくて静かですが、8mm
ドライブが持っている信頼性ほど、その評判は良くありません。
また、4mm カートリッジは 8mm カートリッジに比べて安価でより小さくなっています
(3 x 2 x 0.5 インチ、76 x 51 x 12 mm)。
ただし、8mm と同様に、4mm のヘッドはヘリカルスキャン方式
(訳注: VTR と同様の回転ヘッドの方式)
を採用しているため、比較的短寿命です。
ドライブのデータスループットは、150 kB/s から
最大で 500 kB/s 程度です。 データ容量は 1.3 GB から 2.0
GB です。ドライブのほとんどで利用可能なハードウェア圧縮を使用すると、
容量が約二倍になります。
複数ドライブのテープライブラリユニットは単一のキャビネットに 6 つのドライブを収容可能で、自動的にテープの交換ができます。ライブラリの容量は
240 GB に達します。
DDS-3 標準は現在では 12 GB (圧縮により 24 GB)
までの容量に対応しています。
8mm ドライブと同様に 4mm ドライブはヘリカルスキャンを使用します。
ヘリカルスキャン方式の利点および欠点はすべて 4mm および 8mm
ドライブの両方に当てはまります。
テープは 2,000 回のパスあるいは 100
回のフルバックアップした後には交換するべきです。
8mm (Exabyte)
テープメディア
Exabyte (8mm) テープ
8mm テープはもっとも一般的な SCSI テープドライブです。
これらは交換型テープの最良の選択です。ほとんどすべてのサイトが Exabyte
2 GB 8mm テープドライブを所有しています。8mm
ドライブは信頼性があり、便利で静かです。カートリッジは安価で小型です
(4.8 x 3.3 x 0.6 インチ、122 x 84 x 15 mm)。8mm
テープの欠点の一つは、ヘッドを横切るテープの高い相対動作率により、
ヘッドとテープは比較的短寿命ということです。
データのスループットは 250 kB/s から 500 kB/s 程度です。
データサイズは 300 MB から 7 GB までです。
ほとんどのドライブで利用可能なハードウェア圧縮を利用すると、
容量が約二倍になります。
これらのドライブは単一のユニット、または 6 つのドライブと 120 のテープを一つのキャビネットに収容可能な複数のドライブのテープライブラリとして利用可能です。
テープはユニットによって自動的に取り換えられます。
ライブラリの容量は 840 GB 強に達します。
Exabyte の Mammoth
モデルは
一つのテープで 12 GB (圧縮により 24 GB) に対応し、
従来のテープドライブと比べ費用は約二倍になります。
データはヘリカルスキャンを用いてテープに記録されます。
ヘッダはメディアに対してある角度 (約 6 度) で配置されます。
テープはヘッドのある円筒の周の 270 度に渡って接触します。
テープが円筒面を走行する間、円筒は回転しています。
この結果、高密度のデータのつまったトラックは、
狭い間隔でテープの上端と下端の間を斜めに横切ります。
QIC
テープメディア
QIC-150
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 回のバックアップで寿命となるでしょう。
XXX* ミニカートリッジ
DLT
テープメディア
DLT
DLT はここに示したドライブのタイプの中で最高速のデータ転送レートを発揮します。
1/2 インチ (12.5mm) テープが単リールのカートリッジ
(4 x 4 x 1 インチ、100 x 100 x 25 mm) に入っています。
カートリッジのひとつの側面全体がスイングゲートになっています。
ドライブの機構がこのゲートを開け、テープリーダを引き出します。
テープリーダには楕円形の穴があり、
ドライブがテープを 引っ掛ける
のに使います。
巻き取りのためのリールはドライブの中にあります。
ここに挙げた他のカートリッジはすべて
(9 トラックテープはただ 1 つの例外です)
送りだしリールと巻き取りリールの両方がカートリッジの中にあります。
データスループットは約 1.5 MB/s で、4mm, 8mm, QIC
テープドライブの 3 倍です。データ容量は単一のドライブで 10 GB
から 20 GB の範囲です。マルチテープチェンジャ、
マルチテープドライブ、5 から 900 巻のテープを 1 から
20 ドライブで扱うマルチドライブテープライブラリがあり、
50 GB から 9 TB の容量が得られます。
圧縮によって、DLT タイプ 4 フォーマットは
70 GB の容量まで対応しています。
データは (QICテープのように) テープの走行方向と平行に複数ある
トラックへ記録されます。2 つのトラックに同時書き込みを行います。
read/write ヘッドの寿命は比較的長いと言えます。
テープの走行が止まればヘッドとテープの間の相対運動は無いからです。
AIT
テープメディア
AIT
AIT は、テープ一巻あたり (圧縮を用いて) 50 GB まで格納できる
Sony が開発した新しい形式です。
テープにはメモリチップが搭載されており、
テープの内容のインデックスを保持しています。
他のテープではテープ上のファイルの位置を把握するのに数分必要とするのですが、
このテープドライブではインデックスを読んで直ちに決定することができます。
SAMS:Alexandria
のようなソフトウェアは、テープのメモリチップと直接通信して、
スクリーンに内容を表示し、
どのファイルがどのテープにバックアップされたかを判断し、
正しいテープを見つけ、読み込み、
テープからデータを復元することができます。このソフトウェアを使うと、
40 以上の AIT テープライブラリを制御できます。
このようなライブラリは大体 $20,000 くらいするので、
愛好家が購入できる価格帯からは外れてしまいますが。
新品のテープを初めて使う場合
全く新品の空テープを読もうとしたり書き込もうとすると、
処理は失敗するでしょう。次のようなメッセージがコンソールに出力されるでしょう。
sa0(ncr1:4:0): NOT READY asc:4,1
sa0(ncr1:4:0): Logical unit is in process of becoming ready
テープに識別ブロック (Identifier Block:block number 0)
がありません。QIC-525 標準を採用したすべての QIC
テープドライブは識別ブロックをテープに書き込みます。
2 つの解決方法があります。
mt fsf 1
によりテープドライブはテープに識別ブロックを書き込みます。
フロントパネルのボタンを押してテープを取り出します。
再びテープを挿入し、データをテープに dump
します。
dump は
DUMP: End of tape detected と報告し、
コンソールには
HARDWARE FAILURE info:280 asc:80,96
と表示されるでしょう。
mt rewind を使ってテープを巻戻します。
次からはテープの操作はうまくいくでしょう。
フロッピーへのバックアップ
データをバックアップするのにフロッピーは使えますか?
バックアップフロッピー
フロッピーディスク
フロッピーディスクは以下の理由によって、
実際にバックアップをつくるための適切なメディアではありません。
メディアの信頼性が (特に長期間の場合) 低い。
バックアップとリストアがとても遅い。
容量が非常に小さい
(ハードディスク全体の日々のバックアップに 1 ダース、
長期間なら本当にたくさん)。
しかしながら、データをバックアップするのに他の方法がないのなら、
バックアップを取らないよりもフロッピーディスクを使う方がよいでしょう。
フロッピーディスクを使用せざるを得ないときは、
品質のよいディスクを使用してください。
事務所のその辺に数年転がっていたフロッピーは使わない方が良いでしょう。
評判のよいメーカからの新しいディスクを使用することが理想です。
それではどうやってデータをフロッピーにバックアップするのですか?
フロッピーにバックアップする一番の方法は
(マルチボリューム) オプション付きで &man.tar.1;
コマンドを使用することです。これにより、
複数のフロッピーにわたってバックアップすることが可能になります。
カレントディレクトリとサブディレクトリのすべてのファイルをバックアップするには以下のコマンドを (root 権限で) 使用します。
&prompt.root; tar Mcvf /dev/fd0 *
始めのフロッピーが一杯になったときには、
&man.tar.1; は次のボリュームを挿入するように要求します
(&man.tar.1; はさまざまなメディアを扱えるので、
ボリューム (この場合フロッピーディスク) と表記します)。
Prepare volume #2 for /dev/fd0 and hit return:
指定したファイルがすべて保存されるまで
(ボリューム番号を増やしながら) 繰り返されます。
バックアップを圧縮できますか?
tar
gzip
圧縮
残念なことに &man.tar.1; はマルチボリュームアーカイブに対して、
オプションを使うことができません。
もちろん、すべてのファイルを &man.gzip.1; で圧縮し、
それらを &man.tar.1; を用いてフロッピーに保存して、
それから再び &man.gunzip.1; を用いることは可能です。
どのようにしてバックアップをリストアしたらいいのでしょうか?
すべてのアーカイブをリストアするには以下のようにします。
&prompt.root; tar Mxvf /dev/fd0
特定のファイルだけをリストアするには二つの方法があります。
まず始めに、一番目のフロッピーを用いて以下のようにします。
&prompt.root; tar Mxvf /dev/fd0 filename
&man.tar.1; ユーティリティは、必要なファイルを見つけるまで次のディスクを挿入するように要求します。
二つ目の方法は、
必要なファイルがどのフロッピーに保存されているか分かっている場合、
単純にそのフロッピーを挿入して上記と同じコマンドを使用します。
あるフロッピー上にある一番目のファイルが、
その前のフロッピーから続いている場合は、
そのファイルのリストアを要求していなくても &man.tar.1;
はそれをリストアできないと警告することに注意してください!
バックアップの基本
主要なバックアッププログラムは
&man.dump.8;, &man.tar.1;, &man.cpio.1; の三つです。
ダンプとリストア
バックアップソフトウェア
ダンプ / リストア
dump
restore
伝統的な &unix; のバックアッププログラムは
dump および restore です。
これらはファイルシステムによって作成されたファイル、リンク、
ディレクトリの下位の抽象的概念であるディスクブロックの集合としてドライブを操作します。dump
はデバイス上のすべてのファイルシステムをバックアップします。
ファイルシステムの一部分だけ、または二つ以上のファイルシステムにわたるディレクトリツリーをバックアップすることはできません。dump
はファイルおよびディレクトリをテープに書き込みませんが、
ファイルおよびディレクトリを含んだ raw データブロックを書き込みます。
ルートディレクトリで dump を使用した場合、
/home, /usr
や他のディレクトリの多くをバックアップしなくてもよいでしょう。
通常これらは他のファイルシステムへのマウントポイントであるか、
シンボリックリンクであるからです。
dump には AT&T UNIX のバージョン 6
(およそ 1975 年) の初期から残る奇癖があります。
デフォルトのパラメタは、現在利用可能な高密度メディア (最大 62,182 ftpi)
ではなく、9 トラックテープ (6250 bpi) に最適な値となっています。
現在のテープドライブの容量を利用するために、
これらのデフォルトはコマンドライン上でオーバライドしなくてはいけません。
.rhosts
rdump および rrestore
を用いて他のコンピュータに接続されているテープドライブにネットワーク経由でデータをバックアップすることも可能です。
どちらのプログラムもリモートのテープドライブにアクセスするために
rcmd および ruserok
に依存しています。
したがって、バックアップを実行するユーザがリモートコンピュータの
.rhosts ファイルに書かれていなければなりません。
rdump および rrestore
の引数はリモートコンピュータに適切なものを用いなければなりません。
FreeBSD コンピュータから komodo と呼ばれる Sun
に接続されている Exabyte テープへ rdump
するには以下のようにします。
&prompt.root; /sbin/rdump 0dsbfu 54000 13000 126 komodo:/dev/nsa8 /dev/da0a 2>&1
注意:
ここではセキュリティが確保されており、
.rhosts
ファイルによる認証が許可されているものと暗黙的に仮定しています。
あなたの状況がこれにあてはまるか注意深く調べてください。
さらなる安全のために ssh 上で
dump および restore
を使用することも可能です。
<application>ssh</application> 上で <command>dump</command> を使用する
&prompt.root; /sbin/dump -0uan -f - /usr | gzip -2 | ssh1 -c blowfish \
targetuser@targetmachine.example.com dd of=/mybigfiles/dump-usr-l0.gz
<command>tar</command>
バックアップソフトウェア
tar
&man.tar.1; は AT&T UNIX の バージョン 6 (1975 年ごろ)
にまでさかのぼることができます。tar
はファイルシステムと協調して動作し、
ファイルとディレクトリをテープに書き込みます。tar
は &man.cpio.1;
で使用可能なフルレンジのオプションには対応していませんが、
tar は cpio
が使用するような奇妙なコマンドパイプラインを必要ありません。
tar
tar
の多くの版はネットワーク経由のバックアップには対応してません。
FreeBSD が使用している GNU 版の tar は、
rdump
と同様の構文でリモートデバイスに対応しています。
komodo と呼ばれる Sun に接続された Exabyte
テープドライブに tar
を実行するには以下のようにします。
&prompt.root; /usr/bin/tar cf komodo:/dev/nsa8 . 2>&1
リモートデバイスに対応していない版に対しては、パイプラインと
rsh
を使用してリモートテープドライブにデータを送ることができます。
&prompt.root; tar cf - . | rsh hostname dd of=tape-device obs=20b
ネットワークを越えたバックアップのセキュリティを懸念しているなら、
rsh の代わりに ssh
を使用するべきです。
<command>cpio</command>
バックアップソフトウェア
cpio
&man.cpio.1; は本来 &unix;
ファイルを磁気メディアで交換するためのプログラムです。
cpio はバイトスワッピング、
多くの異なるアーカイブフォーマットの書き込みオプション
(他にも多数のオプションがあります) があり、
パイプで他のプログラムにデータを渡すこともできます。
この最後にあげた特徴により、cpio
はインストールメディアとしては優れた選択です。cpio
はディレクトリツリーの探索の機能はなく、ファイルリストは
stdin からの入力でなくてはなりません。
cpio
cpio
はネットワーク経由のバックアップには対応していません。
以下のようにパイプラインと rsh
を用いてリモートテープドライブにデータを送ることができます。
&prompt.root; for f in directory_list; do
find $f >> backup.list
done
&prompt.root; cpio -v -o --format=newc < backup.list | ssh user@host "cat > backup_device"
directory_list
はバックアップしたいディレクトリのリストで、
user@host
はバックアップを実行したいユーザとホスト名の組であり、
backup_device
はバックアップを書き込みたいデバイスです
(たとえば /dev/nsa0)。
<command>pax</command>
バックアップソフトウェア
pax
pax
POSIX
IEEE
&man.pax.1; は tar と cpio
に対する IEEE/&posix; の答えです。長年の間、さまざまな版の
tar および cpio
は互いにわずかながら非互換性を有していました。
それらをしらみ潰しに標準化する代わりに、&posix;
は新しいアーカイブユーティリティを作りました。
pax は専用に開発された新しいフォーマットに加えて、
いくつもの cpio や tar
のフォーマットの読み書きに対応しようと試みています。コマンド群は
tar よりも cpio
の方にいくぶん似ています。
<application>Amanda</application>
バックアップソフトウェア
Amanda
Amanda
Amanda (Advanced Maryland
Network Disk Archiver) は単一のプログラムではなく、
クライアント/サーバ型のバックアップシステムです。
Amanda サーバは、
Amanda クライアントを有する
ネットワークに接続されたコンピュータからデータを受け取り、
備え付けられたテープドライブにバックアップします。
いくつもの大容量ディスクを備えたサイトでの共通の問題は、
データディレクトリをテープにバックアップするのに時間がかかりすぎることです。
Amanda はこの問題を解決します。
Amanda は
ホールディングディスク
を使用して、
同時に複数のファイルシステムのバックアップを行うことができます。
Amanda の設定ファイルにかかれたすべてのファイルシステムのフルバックアップを特定の間隔でとるために
アーカイブセット
と呼ばれるテープグループを作成します。
アーカイブセット
には
夜間に作成されるすべてのファイルシステムの増分 (または差分)
のバックアップも含まれます。
障害が起きたファイルシステムのリストアには、
最も新しいフルバックアップと増分のバックアップが必要です。
設定ファイルでバックアップの制御と
Amanda
によるネットワークトラフィック量を設定します。
Amanda は上記のバックアッププログラムのいずれかを使用してデータをテープに書き込みます。
Amanda は port または package
として利用可能です。デフォルトではインストールされていません。
何もしない
何もしない
というのはコンピュータのプログラムではありませんが、
バックアップの戦略として最も広く採用されています。
これには初期投資が必要ありません。
従わなければならないバックアップスケジュールもありません。
ただ何もしないだけです。データに何か起きたら苦笑いして耐えてください!
あなたにとって時間やデータの価値が少ないか、
あるいはまったくないのであれば 何もしない
のはあなたのコンピュータに最も適したバックアッププログラムでしょう。
しかし注意してください。&unix; は便利なツールです。6
ヵ月も使用していれば価値のあるファイルの山が出来上がっているでしょう。
何もしない
のはコンピュータによって正確に再作成される
/usr/obj
やその他のディレクトリツリーについては適切なバックアップ方法です。
HTML または &postscript; 版のこのハンドブックが一つの例です。
これらの文書形式は SGML ファイルから作成されたものです。
HTML または &postscript; ファイルのバックアップは必要ありません。
SGML ファイルは定期的にバックアップされます。
どのバックアッププログラムが最適ですか?
LISA
定期的に &man.dump.8; しましょう。
Elizabeth D. Zwicky
はここで検討したプログラムすべてについて拷問的なテストを行いました。
すべてのデータと &unix;
ファイルシステムの状態すべてを保存するのに最適なのは、明らかに
dump でしょう。
Elizabeth は大きく変化に富んだ異常な状態
(いくつかはあまり異常でない状態のものもあります)
のファイルシステムを作成し、それぞれのプログラムを用いてそれらのファイルシステムのバックアップとリストアのテストを行いました。特色のある状態には、
ホールを持つファイル、ホールとヌルブロックを持つファイル、
奇妙な文字をファイル名に持つファイル、読み込み不可、
書き込み不可のファイル、デバイスファイル、
バックアップ中のファイルのサイズ変更、
バックアップ中のファイルの作成および削除、などがあります。
彼女は 1991 年 10 月の LISA V で結果の発表をしています。
torture-testing Backup and Archive Programs を参照してください。
緊急時のリストア手順
惨事の起きる前に
起き得るどのような惨事に対しても、
必要な手順は以下の 4 ステップだけです。
disklabel
まず始めに、
各ディスクのディスクラベルとファイルシステムテーブル
(/etc/fstab)、
すべてのブートメッセージをそれぞれ 2 枚ずつ印刷します
(たとえば disklabel da0 | lpr)。
fix-it フロッピー
次に、ブートフロッピーと fix-it フロッピー
(boot.flp および fixit.flp)
にそのシステムのデバイスがすべて含まれているか確認します。
最も簡単に確認する方法は、フロッピーをドライブに入れてマシンをリブートしてブートメッセージを確認することです。
あなたのシステムのデバイスのすべてが含まれ、
機能していれば次のステップに進んでください。
そうでないなら、あなたのディスクのすべてをマウントでき、
テープドライブにもアクセスできるカスタムブートフロッピーを二つ作成する必要があります。
これらのフロッピーは fdisk,
disklabel, newfs,
mount
および利用したいバックアッププログラムを含んでいなければなりません。
これらのプログラムをスタティックリンクされていなければなりません。
dump を使用するのなら、このフロッピーに
restore も含まれていなければなりません。
続いて、定期的にバックアップテープを作成します。
最後のバックアップの後で行われた変更は回復することができないかもしれません。
バックアップテープにライトプロテクトをしてください。
最後に、フロッピー (boot.flp と
fixit.flp
または上記で作成した二枚のカスタムブートフロッピーディスク)
およびバックアップテープのテストをします。手順のメモを作りましょう。
このメモはブートフロッピーとバックアップテープにいれておき、
印刷しておきます。
リストアを行うときはおそらく取り乱しているでしょうから、
このメモはバックアップテープを壊すようなことを防ぐのに役立つでしょう
(どのように破壊してしまうのでしょう?
tar xvf /dev/sa0 とする代わりに、偶然
tar cvf /dev/sa0
と入力してバックアップテープを上書きしてしまうかもしれません)。
訳注
上書きはライトプロテクトをしておけば防げますが、
何らかの原因でプロテクトがはずれているかもしれません。
ちなみに訳者の経験から言えば、
上のようなミスタイプは結構起きます。
安全性を増すために、
ブートフロッピーと二巻のバックアップテープを毎回とります。
一方を離れた場所に保管します。
離れた場所は同じ事務所の建物の地下室ではいけません。
世界貿易センタービルにあった数多くの会社は、
苦い経験によりこの教訓を得ました。
離れた場所とは、コンピュータやディスクドライブからかなり離れて、
- 物理的に分離されされていなければなりません。
+ 物理的に分離されていなければなりません。
ブートフロッピーを作成するスクリプト
/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 da0
./MAKEDEV da1
./MAKEDEV da2
./MAKEDEV sa0
./MAKEDEV pty0
cd /
#
# create minimum file system table
#
cat > /mnt/etc/fstab < /mnt/etc/passwd < /mnt/etc/master.passwd <
惨事の後は
重要な問題は、ハードウェアが生き残ったかどうかです。
定期的にバックアップを取っていれば、
ソフトウェアについて心配する必要はありません。
ハードウェアに障害があれば、
コンピュータを使用する前にその部品を交換してください。
ハードウェアに問題が無ければ、フロッピーを確認してください。
カスタムブートフロッピーディスクを使用しているのであれば、
シングルユーザモードでブートしてください (boot:
プロンプトで -s を入力します)。
それから次の項に進んでください。
boot.flp と fixit.flp
を使用しているのであればこのまま読み進めてください。
boot.flp
フロッピーをフロッピードライブに入れて、
コンピュータを起動してください。
本来のインストールメニューが画面に表示されます。
Fixit--Repair mode with CDROM or floppy.
オプションを選択します。指示された通り
fixit.flp をいれてください。
restore と必要となるその他のプログラムは
/mnt2/stand にあります。
そして、ファイルシステムを一つずつ回復します。
mount
root パーティション
disklabel
newfs
最初のディスクのルートパーティションを mount
してみてください (たとえば mount /dev/da0a /mnt)。
ディスクラベルが破壊されている場合は、disklabel
を用いてあらかじめ印刷して保存しておいた通りにパーティションを作り直し、ディスクラベルを作成してください。
newfs を使用してファイルシステムを作り直します。
ルートパーティションを読み書き可能にマウントし直します
(mount -u -o rw /mnt)。
バックアッププログラムとバックアップテープを使用して、
このファイルシステムのデータを回復します
(たとえば restore vrf /dev/sa0)。
ファイルシステムをアンマウントします
(たとえば umount /mnt)。
障害を受けたファイルシステムそれぞれについて繰り返してください。
システムが動き出したら、
新しいテープにデータをバックアップしてください。
どのような理由で再び事故が起きたり、データが失われるかわかりません。
これに数時間を費すことで、後々の災難から救われます。
* I Did Not Prepare for the Disaster, What Now?
]]>
Marc
Fonvieille
再構成および追記:
ネットワーク、メモリ、そしてファイルベースのファイルシステム
仮想ディスク
ディスク
仮想
FreeBSD にはフロッピーや CD,
ハードディスクなどの手元の計算機に取り付けたディスクの他に、
別の形態のディスク、仮想ディスク、もあります。
NFS
Coda
ディスク
メモリ
これには、Network File System
のようなネットワークファイルシステムや Coda,
メモリベースのファイルシステムおよびファイルベースのファイルシステムがあります。
稼働させている FreeBSD のバージョンによって、
ファイルベースおよびメモリベースのファイルシステムを作成したり操作するために、異なるツールを使用しなければならないでしょう。
FreeBSD 4.X の使用者は必要なデバイスを作成するために
&man.MAKEDEV.8; を使用しなければならないでしょう。FreeBSD 5.0
以降では、&man.devfs.5; がデバイスノードを自動的に割り当ててくれるので、
使用者が意識する必要はありません。
FreeBSD 4.X でファイル中に構築されるファイルシステム
ディスク
ファイルベース (4.X)
&man.vnconfig.8;
ユーティリティを使えば擬似ディスクデバイスを設定し、
有効にすることができます。
vnode とはファイルの内部的な表現方法であり、
ファイルに関する操作の中心となるものです。つまり、&man.vnconfig.8;
はファイルシステムを生成したり操作したりするためにファイルを用いるのです。
一つ例を挙げると、
ファイルに収められたフロッピーや CD-ROM のイメージをマウントするために用いることができます。
&man.vnconfig.8; を使用するためには、
カーネルが &man.vn.4; デバイスに対応している必要があります。
そうでなければ、カーネルコンフィギュレーションファイルに
次の行を追加してカーネルを再構築し、システムを再起動してください。
pseudo-device vn
既にあるファイルシステムイメージのマウント
FreeBSD 4.X での vnconfig を用いた既存のファイルシステムイメージのマウント
&prompt.root; vnconfig vn0 diskimage
&prompt.root; mount /dev/vn0c /mnt
&man.vnconfig.8; を用いたファイルシステムイメージの新規作成
<command>vnconfig</command> を用いたファイルベースディスクの新規作成
&prompt.root; dd if=/dev/zero of=newimage bs=1k count=5k
5120+0 records in
5120+0 records out
&prompt.root; vnconfig -s labels -c vn0 newimage
&prompt.root; disklabel -r -w vn0 auto
&prompt.root; newfs vn0c
Warning: 2048 sector(s) in last cylinder unallocated
/dev/vn0c: 10240 sectors in 3 cylinders of 1 tracks, 4096 sectors
5.0MB in 1 cyl groups (16 c/g, 32.00MB/g, 1280 i/g)
super-block backups (for fsck -b #) at:
32
&prompt.root; mount /dev/vn0c /mnt
&prompt.root; df /mnt
Filesystem 1K-blocks Used Avail Capacity Mounted on
/dev/vn0c 4927 1 4532 0% /mnt
FreeBSD 5.X でファイル中に構築されるファイルシステム
ディスク
ファイルベース (5.X)
&man.mdconfig.8; ユーティリティは FreeBSD 5.X において
メモリディスク (&man.md.4;) を設定し、有効にするために使用されます。
&man.mdconfig.8; を使用するためには &man.md.4; モジュールを読み込むか、
カーネルコンフィギュレーションファイルに &man.md.4;
デバイスを追加してカーネルを再構築し、システムを再起動してください。
device md
&man.mdconfig.8; コマンドは、
三つのタイプのメモリベース仮想ディスクに対応しています。
&man.malloc.9; を用いて割り当てられたメモリディスク、
ファイルをベースにしたメモリディスク、
およびスワップ領域をベースにしたメモリディスクです。
想定される使用法は、ファイル内に保持されたフロッピーイメージまたは
CD イメージをマウントすることです。
既にあるファイルシステムイメージのマウント
FreeBSD 5.X での <command>mdconfig</command> を用いた既存のファイルシステムイメージのマウント
&prompt.root; mdconfig -a -t vnode -f diskimage -u 0
&prompt.root; mount /dev/md0c /mnt
&man.mdconfig.8; を用いたファイルシステムイメージの新規作成
<command>mdconfig</command> を用いたファイルシステムイメージの新規作成
&prompt.root; dd if=/dev/zero of=newimage bs=1k count=5k
5120+0 records in
5120+0 records out
&prompt.root; mdconfig -a -t vnode -f newimage -u 0
&prompt.root; disklabel -r -w md0 auto
&prompt.root; newfs md0c
/dev/md0c: 5.0MB (10240 sectors) block size 16384, fragment size 2048
using 4 cylinder groups of 1.27MB, 81 blks, 256 inodes.
super-block backups (for fsck -b #) at:
32, 2624, 5216, 7808
&prompt.root; mount /dev/md0c /mnt
&prompt.root; df /mnt
Filesystem 1K-blocks Used Avail Capacity Mounted on
/dev/md0c 4846 2 4458 0% /mnt
オプションを用いて
ユニット番号を指定しない場合、&man.mdconfig.8;
は未使用のデバイスを自動的に選択するために
&man.md.4; デバイスの auto-unit 機能を使用します。
割り当てられたユニットの名前は md4
のように標準出力に出力されます。&man.mdconfig.8;
の詳細についてはマニュアルページを参照してください。
&os; 5.1-RELEASE から、従来の &man.disklabel.8;
プログラムは &man.bsdlabel.8;
ユーティリティに置き換えられました。&man.bsdlabel.8; では、
使用されていないオプションおよびパラメタの数多くが削除されました。
たとえば オプションは &man.bsdlabel.8;
では取り除かれました。詳細については &man.bsdlabel.8;
マニュアルページを参照してください。
&man.mdconfig.8; ユーティリティは大変役に立ちますが、
ファイルベースのファイルシステムを作成するために、
多くのコマンドの入力が必要となります。FreeBSD 5.0 では
&man.mdmfs.8; と呼ばれるツールも用意されています。このプログラムは
&man.mdconfig.8; を用いて &man.md.4; ディスクを設定し、&man.newfs.8;
を用いて UFS ファイルシステムを作成し、&man.mount.8;
を用いてマウントします。たとえば、上記と同じファイルシステムを作成し、
マウントしたい場合は、下記のように入力するだけです。
&prompt.root; dd if=/dev/zero of=newimage bs=1k count=5k
5120+0 records in
5120+0 records in
5120+0 records out
&prompt.root; mdmfs -F newimage -s 5m md0 /mnt
&prompt.root; df /mnt
Filesystem 1K-blocks Used Avail Capacity Mounted on
/dev/md0 4846 2 4458 0% /mnt
ユニット番号を指定せずに
オプションを使用した場合、&man.mdmfs.8;
は未使用のデバイスを自動的に選択するために &man.md.4; デバイスの
auto-unit 機能を使用します。&man.mdmfs.8;
についての詳細はマニュアルページを参照してください。
FreeBSD 4.X でのメモリベースのファイルシステム
ディスク
メモリファイルシステム (4.X)
&man.md.4; ドライバは FreeBSD 4.X
においてメモリファイルシステムを作成するために単純で効果的な手段です。
メモリを割り当てるために &man.malloc.9; 関数が使用されます。
&man.vnconfig.8; を用いて作成したファイルシステムを例に取ると、
以下のようにします。
FreeBSD 4.X での md メモリディスク
&prompt.root; dd if=newimage of=/dev/md0
5120+0 records in
5120+0 records out
&prompt.root; mount /dev/md0c /mnt
&prompt.root; df /mnt
Filesystem 1K-blocks Used Avail Capacity Mounted on
/dev/md0c 4927 1 4532 0% /mnt
詳細については &man.md.4; マニュアルページを参照してください。
FreeBSD 5.X でのメモリベースのファイルシステム
ディスク
メモリファイルシステム (5.X)
メモリベースおよびファイルベースのファイルシステムに対しても
同じツール (&man.mdconfig.8; または &man.mdmfs.8;) を使用できます。
メモリベースのファイルシステムに対する記憶領域は
&man.malloc.9; 関数を用いて割り当てられます。
<command>mdconfig</command> を用いたメモリベースディスクの新規作成
&prompt.root; mdconfig -a -t malloc -s 5m -u 1
&prompt.root; newfs -U md1
/dev/md1: 5.0MB (10240 sectors) block size 16384, fragment size 2048
using 4 cylinder groups of 1.27MB, 81 blks, 256 inodes.
with soft updates
super-block backups (for fsck -b #) at:
32, 2624, 5216, 7808
&prompt.root; mount /dev/md1 /mnt
&prompt.root; df /mnt
Filesystem 1K-blocks Used Avail Capacity Mounted on
/dev/md1 4846 2 4458 0% /mnt
<command>mdmfs</command> を用いたメモリベースディスクの新規作成
&prompt.root; mdmfs -M -s 5m md2 /mnt
&prompt.root; df /mnt
Filesystem 1K-blocks Used Avail Capacity Mounted on
/dev/md2 4846 2 4458 0% /mnt
&man.mdconfig.8; のコマンドラインの を
に置き換えることで、&man.malloc.9;
関数によるファイルシステムを使用する代わりに
スワップ領域を使用することが可能です。デフォルトでは &man.mdmfs.8;
ユーティリティはスワップベースのディスクを作成します
( なし)。詳細は &man.mdconfig.8; および
&man.mdmfs.8; マニュアルページを参照してください。
システムからメモリディスクを切り離す
ディスク
メモリディスクの切り離し
メモリベースまたはファイルベースのファイルシステムが使用されていない場合、
すべてのリソースをシステムに開放するべきです。
はじめにファイルシステムをアンマウントします。
次にシステムからディスクを切り離し、リソースを開放するために
&man.mdconfig.8; を使用します。
たとえば /dev/md4 によって使用されたすべてのリソースを切り離し、開放するには以下のようにします。
&prompt.root; mdconfig -d -u 4
mdconfig -l コマンドを使用することによって、
設定された &man.md.4; デバイスについての情報を表示することが可能です。
FreeBSD 4.X では &man.vnconfig.8; はデバイスを切り離すのに使用されます。たとえば /dev/vn4 によって使用されたすべてのリソースを切り離し、開放するには以下のようにします。
&prompt.root; vnconfig -u vn4
Tom
Rhodes
寄稿:
ファイルシステムのスナップショット
ファイルシステム
スナップショット
FreeBSD 5.0 は
Soft Updates
と協調するファイルシステムスナップショットという新しい機能を提供します。
スナップショットは指定したファイルシステムのイメージを作成し、
また、ファイルとして扱うことができるようになります。
スナップショットファイルはアクションが実行されるファイルシステム内で作成されなければなりません。
また、ユーザは一つのファイルシステムあたり 20
までスナップショットを作成することができます。
有効なスナップショットはスーパーブロック内に記録されるので、
リブートしてから永続的にアンマウントおよびリマウントを記録します。
スナップショットが必要無くなったときは、
標準の &man.rm.1; コマンドを用いて削除することができます。
スナップショットはどんな順番で削除してもよいのですが、
その他のスナップショットが開放されたブロックのうちいくらかをおそらく必要とするので、
使用されていたすべてのスペースを得られるとは限りません。
初めてスナップショットを作成すると、root
でさえも書き込めないように
フラグ (&man.chflags.1; のマニュアルページを参照) が設定されます。
&man.unlink.1; コマンドは、スナップショットに
フラグが設定されていてもそれらを削除することのできる例外です。
したがって、スナップショットファイルを削除する前に、
フラグをクリアする必要はありません。
スナップショットは &man.mount.8; コマンドを用いて作成されます。
/var のスナップショットを
/var/snapshot/snap に作成したいときは、
以下のコマンドを使用します。
&prompt.root; mount -u -o snapshot /var/snapshot/snap /var
スナップショットにはいくつかの利用法があります。
スナップショットをバックアップ目的に使用する管理者もいます。
なぜならスナップショットは CD やテープに転送できるからです。
ファイルの完全性を検証するために、
&man.fsck.8; をスナップショットに実行してもよいでしょう。
スナップショットをマウントしたときにそのファイルシステムがクリーンであったとすると、
そのスナップショットをマウントするときはいつでもクリーンな
(そして変更のない) 結果を得るでしょう。
これは本質的には バックグラウンド &man.fsck.8; が行うことです。
スナップショット上で &man.dump.8; ユーティリティを実行すると、
スナップショットのファイルシステムとタイムスタンプが一致するダンプが返されるでしょう。
&man.dump.8; は オプションを使用することで、
一つのコマンドでスナップショットをとり、ダンプイメージを作成して、スナップショットを削除することが可能です。
ファイルシステムの 凍結された
イメージとしてスナップショットを
&man.mount.8; します。
/var/snapshot/snap のスナップショットを
&man.mount.8; するには以下のようにします。
&prompt.root; mdconfig -a -t vnode -f /var/snapshot/snap -u 4
&prompt.root; mount -r /dev/md4 /mnt
これで /mnt にマウントした
凍結状態の /var ファイルシステム構造を探索できます。
すべてがスナップショットが作成された時と同じ状態になるはずです。ただし、
以前に作成されたスナップショットがサイズ 0 のファイルとして現れることが唯一の例外です。
スナップショットの使用を終えた場合、以下のようにアンマウントできます。
&prompt.root; umount /mnt
&prompt.root; mdconfig -d -u 4
およびファイルシステムスナップショットに関する詳細については、
http://www.mckusick.com/
にある Marshall Kirk McKusick のウェブサイトを参照してください。
ここには技術的な論文もあります。
ファイルシステムクォータ
アカウンティング
ディスク領域
ディスククォータ
クォータは OS の持っているオプショナルな機能であり、
ファイルシステム毎にユーザやグループのメンバが使用するディスク容量やファイルの数を制限することができます。
この機能は、あるユーザやグループに割り当てられるリソースの量を制限することが望ましいようなタイムシェアリングシステムにおいてよく用いられます。
この機能を用いることによって使用可能なディスク容量の全てを一人のユーザやユーザのグループが使ってしまうことを防ぐことができます。
ディスククォータを使うためのシステム設定
ディスククォータの設定を始める前に、
まずはカーネルにクォータが組み込まれていることを確認しましょう。
カーネルのコンフィグレーションファイルに次の行を入れます。
options QUOTA
標準の GENERIC カーネルでは、
この機能は有効になっていませんので、
ディスククォータを利用するためには上記を設定後カーネルを構築しなおし、
作成されたカスタムカーネルをインストールしなければいけません。
カーネルのコンフィグレーションに関しては
をご覧ください。
次に /etc/rc.conf
でディスククォータを有効にする必要があります。
次の行を加えましょう。
enable_quotas="YES"
ディスククォータ
チェック
起動時の動作をさらに細かくコントロールするためにもう一つ設定用の変数があります。
通常、起動時には &man.quotacheck.8;
によりそれぞれのファイルシステムのクォータの整合性がチェックされます。
&man.quotacheck.8; の役割は、
クォータデータベースのデータが正しくファイルシステム上のデータを反映しているか確認することです。
これはかなり時間を食う処理であり、
起動にかかる時間に大きな影響を及ぼします。
このステップをとばしたい人のために
/etc/rc.conf に次の変数が用意されています。
check_quotas="NO"
もし 3.2-RELEASE よりも前の FreeBSD
を使っているならば設定はもっと単純で、一つの変数のみです。
次の行を /etc/rc.conf で設定してください。
check_quotas="YES"
最後に、ファイルシステム毎にディスククォータを有効にするために
/etc/fstab を編集する必要があります。
ここでユーザもしくはグループ、
あるいはその両方にクォータを設定することができるのです。
あるファイルシステム上にユーザ毎のクォータを有効にする場合には、
/etc/fstab
中でクォータを有効にしたいファイルシステムエントリのオプション部に
を加えます。
例えば次のようになります。
/dev/da1s2g /home ufs rw,userquota 1 2
同様に、グループクォータを有効にするには
キーワードの代わりに
を用います。
ユーザとグループの両方のクォータを有効にするには次のようにします。
/dev/da1s2g /home ufs rw,userquota,groupquota 1 2
デフォルトでは、
クォータファイルはそのファイルシステムのルートディレクトリに
ユーザ用、グループ用それぞれ
quota.user, quota.group
という名前で置かれます。さらに詳しい情報は &man.fstab.5;
をご覧ください。&man.fstab.5;
マニュアルには別の場所を指定することができると書いてはありますが、
あまり勧められません。なぜなら、
様々なクォータ関係のユーティリティがそれにうまく対処できるようにないためです。
この時点で、
一度システムを再起動して新しいカーネルで立ち上げましょう。
/etc/rc が自動的に適当なコマンドを実行し、
/etc/fstab
で有効にした全てのクォータ用に初期ファイルを作ってくれます。
従って、空のクォータファイルを手で作る必要は一切ありません。
通常の運用では &man.quotacheck.8; や
&man.quotaon.8;, &man.quotaoff.8;
といったコマンドを手で動かす必要はないのですが、
慣れるためにもこれらのマニュアルは読んでおきましょう。
クォータリミットの設定
ディスククォータ
制限
一旦クォータを有効にしたら本当に有効になっているのか確認しておきましょう。簡単な方法は次のコマンドを実行することです。
&prompt.root; quota -v
ディスクの使用状況と、クォータが有効になっているファイルシステムのクォータリミットが一行にまとめて出力されるでしょう。
さあ、&man.edquota.8; でクォータリミットを設定する準備ができました。
ユーザやグループが使用できるディスク容量や作成できるファイルの数に制限をかけるにはいくつかのオプションがあります。割り当てディスク容量を制限
(ブロッククォータ) することもファイル数を制限 (inode クォータ)
することも、両者を組み合わせることもできるのです。
これらの制限はそれぞれさらに二つのカテゴリ、
ハードリミットとソフトリミット、に分けることができます。
ハードリミット
ハードリミットを越えることはできません。
あるユーザが一旦ハードリミットにたっした場合、
そのファイルシステムではそれ以上の割り当ては望めません。
例えばあるファイルシステム上に
500 ブロックのハードリミットが設定されており現在
490 ブロックを使用している場合、さらに 10 ブロックしか使えないのです。
11 ブロックを使おうとすると失敗します。
ソフトリミット
一方、
ソフトリミットはある限られた時間内であれば越えることができます。
この時間は猶予期間として知られており、デフォルトでは 1 週間です。
あるユーザが自分のソフトリミットを猶予期間よりも長い間越えているとソフトリミットはハードリミットに変わり、それ以上使用することはできなくなります。
ユーザがソフトリミットよりも減らせば猶予期間はリセットされます。
以下は &man.edquota.8;
コマンドを実行した時に見ることになるであろう例です。
&man.edquota.8; コマンドが起動されると環境変数
EDITOR で指定されるエディタに入ります。
EDITOR が設定されていない場合には
vi が起動されます。
ここでクォータリミットを編集します。
&prompt.root; edquota -u test
Quotas for user test:
/usr: blocks in use: 65, limits (soft = 50, hard = 75)
inodes in use: 7, limits (soft = 50, hard = 60)
/usr/var: blocks in use: 0, limits (soft = 50, hard = 75)
inodes in use: 0, limits (soft = 50, hard = 60)
通常、クォータが有効になっているファイルシステム毎に 2 行あります。
一つはブロックリミット用でもう一つは inode リミット用です。
クォータリミットを変更したいところを書き変えるだけでかまいません。
たとえばこのユーザのブロックリミットを、ソフトリミットは 50 から 500
へ、ハードリミットは 75 から 600 に変更する場合、
/usr: blocks in use: 65, limits (soft = 50, hard = 75)
から
/usr: blocks in use: 65, limits (soft = 500, hard = 600)
へ書き換えます。新しいクォータリミットはエディタを終了すれば設定されます。
ある範囲の UID
に対してクォータリミットを設定したい場合がありますが、このような時には
&man.edquota.8; コマンドの
オプションを使うといいでしょう。まず、
あるユーザに割り当てたいクォータリミットを設定し、次に
edquota -p protouser startuid-enduid
を実行するのです。例えばユーザ test
にお望みのクォータリミットが付いているとしましょう。
次のコマンドにより 10,000 から 19,999 の間の UID
に対して同じクォータリミットを付けることができるのです。
&prompt.root; edquota -p test 10000-19999
さらに詳しいことは &man.edquota.8; のマニュアルページをご覧ください。
クォータリミットとディスク使用状況のチェック
ディスククォータ
チェック
&man.quota.1; または &man.repquota.8;
といったコマンドを使ってクォータリミットやディスクの利用状況を確認することができます。
&man.quota.1; コマンドは個々のユーザやグループのクォータやディスク利用状況を確認するのに使えます。
ユーザは自身のクォータ、そして所属するグループのグループのみ確認することができます。
スーパーユーザのみが他のユーザや所属していないグループのクォータと利用状況を見ることができます。
&man.repquota.8; コマンドを使うと、クォータが有効になっているファイルシステム用の全てのクォータやディスク容量のサマリを得ることができます。
以下は二つのファイルシステムにクォータ制限がかけられているユーザに対するquota -v コマンドの出力例です。
Disk quotas for user test (uid 1002):
Filesystem blocks quota limit grace files quota limit grace
/usr 65* 50 75 5days 7 50 60
/usr/var 0 50 75 0 50 60
猶予期間
上の例で、/usr
ファイルシステム上ではこのユーザは現在
50 ブロックというソフトリミットを 15 ブロックオーバーし
5 日間の猶予期間が残っています。アスタリスク *
はクォータリミットを越えているユーザを示していることに注意してください。
通常、そのユーザが全く使っていないファイルシステムは、
クォータリミットが付けられているとしても
&man.quota.1; コマンドの出力には現われません。
オプションを用いればそのようなファイルシステム、
上の例では /usr/var、
を表示することができます。
NFS 上の クォータ
NFS
クォータは NFS サーバ上のクォータサブシステムにより実行されます。
&man.rpc.rquotad.8; デーモンにより、NFS クライアント上の &man.quota.1;
コマンドは情報を得ることができ、クライアントマシン上のユーザが自分のクォータの統計を見ることができます。
/etc/inetd.conf において以下のように
rpc.rquotad を有効にしましょう。
rquotad/1 dgram rpc/udp wait root /usr/libexec/rpc.rquotad rpc.rquotad
そして以下のように inetd を再起動します。
&prompt.root; kill -HUP `cat /var/run/inetd.pid`
Lucky
Green
寄稿:
shamrock@cypherpunks.to
ディスクパーティションの暗号化
ディスク
暗号化
FreeBSD
は無許可のデータアクセスに対する優れたオンライン保護機能を提供します。
ファイルのパーミッションおよび強制的アクセスコントロール
(MAC: Mandatory Access Control)
(Mandatory Access Control (MAC) を参照)
は、コンピュータが動作中で、OS が実行中であるときに、
無許可の第三者がデータにアクセスするのを防ぐことに役立ちます。
しかしながら、攻撃者がコンピュータに物理的にアクセスし、
機密データをコピーし分析するためにコンピュータのハードドライブを別のシステムに移動させることができれば、
OS によって強化された許可属性は意味をなさなくなります。
攻撃者が電源の落ちたコンピュータや
ハードドライブを手にいれる手段にかかわらず、
GEOM ベースのディスク暗号化 (gbde: GEOM Based Disk Encryption)
は、著しい資源を持ち本気で攻撃を仕掛けるつもりでやってきた攻撃者からさえもコンピュータのファイルシステム上にあるデータを保護することができます。
個々のファイルだけを暗号化する煩わしい方法と異なり、
gbde
は全ファイルシステムを透過的に暗号化します。
平文テキストは決してハードドライブのプラッタに関係しません。
カーネルで gbde を有効にする
<username>root</username> になる
gbde
の設定をするにはスーパユーザの権限が必要になります。
以下のコマンドを実行して、
root になってください。
&prompt.user; su -
Password:
オペレーティングシステムのバージョンを確かめる
&man.gbde.4; が動作するには FreeBSD 5.0 以降が必要です。
以下のコマンドを実行して、
オペレーティングシステムのバージョンを確認してください。
&prompt.root; uname -r
5.0-RELEASE
カーネルコンフィギュレーションファイルに &man.gbde.4;
対応を追加する
お好みのテキストエディタを使用して、
以下の行をカーネルコンフィギュレーションファイルに加えます。
options GEOM_BDE
FreeBSD カーネルを設定、再コンパイル、インストールします。
この手順は で説明されています。
新しいカーネルで再起動します。
暗号化されたハードドライブの準備
以下の例では、システムに新しいハードディスクを追加しようとしています。このシステムは単一の暗号化されたパーティションを保持することになります。
このパーティションは /private
としてマウントされます。gbde は
/home および /var/mail
を暗号化するのにも使用できますが、
より複雑な指示を必要となるのでこの解説の範疇を越えています。
新しいハードドライブを追加する
で説明されている通りに新しいドライブをシステムに設置します。
この例では、新しいハードドライブは
/dev/ad4s1c パーティションに
加えられたものとします。
/dev/ad0s1*
デバイスは、この例のシステム上に存在する標準的な
FreeBSD パーティションを表します。
&prompt.root; ls /dev/ad*
/dev/ad0 /dev/ad0s1b /dev/ad0s1e /dev/ad4s1
/dev/ad0s1 /dev/ad0s1c /dev/ad0s1f /dev/ad4s1c
/dev/ad0s1a /dev/ad0s1d /dev/ad4
gbde ロックファイルを保持するディレクトリを作成する
&prompt.root; mkdir /etc/gbde
gbde ロックファイルには、
暗号化されたパーティションにアクセスするのに必要となる情報が格納されています。
ロックファイルにアクセスしない場合、
gbde は
膨大な手動による介在なしには (ソフトウェアは対応していません)、暗号化されたパーティションに含まれるデータを解読することはできないでしょう。
それぞれの暗号化されたパーティションは別々のロックファイルを使用します。
gbde パーティションを初期化する
gbde
パーティションは使用する前に初期化されなければなりません。
この初期化は一度だけ実行される必要があります。
&prompt.root; gbde init /dev/ad4s1c -i -L /etc/gbde/ad4s1c
エディタが開くので、
テンプレートをもとにさまざまなオプションを設定してください。
UFS1 または UFS2 で使用するには、sector_size を
2048 に設定してください。
$FreeBSD: src/sbin/gbde/template.txt,v 1.1 2002/10/20 11:16:13 phk Exp $
#
# Sector size is the smallest unit of data which can be read or written.
# Making it too small decreases performance and decreases available space.
# Making it too large may prevent filesystems from working. 512 is the
# minimum and always safe. For UFS, use the fragment size
#
sector_size = 2048
[...]
&man.gbde.8;
はデータを保護するのに使用するパスフレーズを二度尋ます。
パスフレーズはそれぞれ同じでなければなりません。
データを保護する gbde の能力は、
あなたが選択したパスフレーズの品質に完全に依存します。
記憶するのが簡単で、
安全なパスフレーズを選択する方法については、
Diceware Passphrase
ウェブサイトを参照してください。
gbde init コマンドは
gbde
パーティションに対するロックファイルを作成します。この例では
/etc/gbde/ad4s1c に格納されます。
gbde ロックファイルは、
すべての暗号化されたパーティションの内容とともにバックアップされなければ なりません。
ロックファイルだけを削除している間、
ロックファイルなしでは信念の固い攻撃者が
gbde
パーティションを解読することを防ぐことができない一方で、
正当な所有者は、&man.gbde.8; およびこの設計者にまったく支持されない膨大な量の作業なしには、
暗号化されたパーティション上のデータにアクセスすることができないでしょう。
カーネルに暗号化されたパーティションを接続する
&prompt.root; gbde attach /dev/ad4s1c -l /etc/gbde/ad4s1c
暗号化されたパーティションを初期化する際に選択したパスフレーズを入力するように求められます。
新しい暗号化デバイスは /dev に
/dev/device_name.bde
として現れます。
&prompt.root; ls /dev/ad*
/dev/ad0 /dev/ad0s1b /dev/ad0s1e /dev/ad4s1
/dev/ad0s1 /dev/ad0s1c /dev/ad0s1f /dev/ad4s1c
/dev/ad0s1a /dev/ad0s1d /dev/ad4 /dev/ad4s1c.bde
暗号化デバイス上にファイルシステムを作成する
カーネルに暗号化デバイスが接続されると、
デバイス上にファイルシステムを作成できます。
暗号化デバイス上にファイルシステムを作成するには &man.newfs.8;
を使用します。従来の UFS1 ファイルシステムで初期化するより、
新しい UFS2 ファイルシステムで初期化した方が高速なので、
オプションとともに &man.newfs.8;
を使用することが推奨されています。
&os; 5.1-RELEASE 以降では、
オプションはデフォルトです。
&prompt.root; newfs -U -O2 /dev/ad4s1c.bde
&man.newfs.8; は、デバイス名に
*.bde
拡張子によって認識される、
接続された gbde
パーティションに対して実行されなければなりません。
暗号化パーティションをマウントする
暗号化ファイルシステムに対するマウントポイントを作成します。
&prompt.root; mkdir /private
暗号化ファイルシステムをマウントします。
&prompt.root; mount /dev/ad4s1c.bde /private
暗号化ファイルシステムが利用可能か確かめる
これで暗号化ファイルシステムは &man.df.1; で見ることができ、
利用する準備ができました。
&prompt.user; df -H
Filesystem Size Used Avail Capacity Mounted on
/dev/ad0s1a 1037M 72M 883M 8% /
/devfs 1.0K 1.0K 0B 100% /dev
/dev/ad0s1f 8.1G 55K 7.5G 0% /home
/dev/ad0s1e 1037M 1.1M 953M 0% /tmp
/dev/ad0s1d 6.1G 1.9G 3.7G 35% /usr
/dev/ad4s1c.bde 150G 4.1K 138G 0% /private
存在する暗号化ファイルシステムをマウントする
システムを起動する度に、すべての暗号化ファイルシステムは
使用前にカーネルに接続し、
エラーの有無をチェックし、マウントする必要があります。
必要なコマンドは root
ユーザとして実行されなければなりません。
カーネルに gbde パーティションを接続する
&prompt.root; gbde attach /dev/ad4s1c -l /etc/gbde/ad4s1c
パーティションの暗号化を初期化する際に選択したパスフレーズを入力するように求められるでしょう。
ファイルシステムのエラーをチェックする
暗号化ファイルシステムを自動的にマウントするために
/etc/fstab に設定を掲載することはまだできないため、
マウントする前に &man.fsck.8; を実行して、
ファイルシステムのエラーをチェックしなければなりません。
&prompt.root; fsck -p -t ffs /dev/ad4s1c.bde
暗号化ファイルをマウントする
&prompt.root; mount /dev/ad4s1c.bde /private
これで暗号化ファイルシステムが利用できるようになりました。
暗号化パーティションを自動的にマウントする
スクリプトを作成して、暗号化パーティションを自動的に接続、
チェック、マウントすることは可能です。しかしながら、
安全上の理由によりスクリプトに &man.gbde.8;
パスワードを含めるべきではありません。その代わりに、コンソールまたは
&man.ssh.1; による接続からパスワードを入力するようなスクリプトが手動で実行されることが推奨されます。
gbde が採用した暗号の保護
&man.gbde.8; は 128bit AES の
CBC モードを使用してセクタペイロードを暗号化します。
ディスク上のそれぞれのセクタは異なる AES 鍵で暗号化されます。
セクタ鍵がユーザが入力したパスフレーズからどのように導き出されるかを含め、
gbde の暗号手法の設計についての詳細は、
&man.gbde.4; を参照してください。
互換性に関する問題
&man.sysinstall.8; は
gbde 暗号化デバイスと互換性がありません。
&man.sysinstall.8; を実行する前に
*.bde
デバイスはすべてカーネルから切断されなければなりません。
そうしないと、&man.sysinstall.8; が初めにデバイスを走査する際にクラッシュしてしまうでしょう。
暗号化デバイスを切断するには、以下のコマンドを使用します。
&prompt.root; gbde detach /dev/ad4s1c
&man.vinum.4; は &man.geom.4; サブシステムを使用しないので、
vinum ボリュームと
gbde
を併用できないことにも注意してください。