From 512ab694869e77e983be4e13ca32a75379ceb554 Mon Sep 17 00:00:00 2001 From: Ryusuke SUZUKI Date: Sat, 6 Oct 2012 14:13:21 +0000 Subject: - Merge the following from the English version: r9149 -> r19116 head/ja_JP.eucJP/books/handbook/advanced-networking/chapter.xml Submitted by: FURUKAWA Jumpei Reviewed by: Hiroo Ono References: [doc-jp-work 794, 984, 1015, 1285, 1335, 1406, 1456, 1467, 1545, 1567, 1585, 1635, 1637, 1639, 1648, 1691, 1699, 1704, 1705, 1706] - Typo fix (polution -> pollution) Pointed out by: kano at na.rim.or.jp References: [doc-jp 17965, doc-jp-work 1635-1637] - Add the translation note about the end of the 6bone service. Submitted by: Hiroo Ono Suggested by: motoyuki@ Reference: [doc-jp-work 1705] - Related changes head/ja_JP.eucJP/books/handbook/basics/chapter.xml head/ja_JP.eucJP/books/handbook/disks/chapter.xml head/ja_JP.eucJP/books/handbook/install/chapter.xml --- .../books/handbook/advanced-networking/chapter.xml | 8743 +++++++++++++++----- ja_JP.eucJP/books/handbook/basics/chapter.xml | 2 +- ja_JP.eucJP/books/handbook/disks/chapter.xml | 2 +- ja_JP.eucJP/books/handbook/install/chapter.xml | 8 +- 4 files changed, 6731 insertions(+), 2024 deletions(-) diff --git a/ja_JP.eucJP/books/handbook/advanced-networking/chapter.xml b/ja_JP.eucJP/books/handbook/advanced-networking/chapter.xml index c723da61ec..0ec99700ba 100644 --- a/ja_JP.eucJP/books/handbook/advanced-networking/chapter.xml +++ b/ja_JP.eucJP/books/handbook/advanced-networking/chapter.xml @@ -3,145 +3,225 @@ The FreeBSD Documentation Project The FreeBSD Japanese Documentation Project - Original revision: 1.36 + Original revision: r19116 $FreeBSD$ --> 高度なネットワーク - + この章では - 以下の章では、 UNIX - システム上で良く利用されるネットワークサービスについて書かれています。 - これはもちろん、 あなたの FreeBSD - システムでの、 そのようなサービスの設定に関する内容です。 - + この章では &unix; + システム上で良く利用されるネットワークサービスについて説明します。 + FreeBSD が利用するすべてのネットワークサービスをどのように定義し、 + 設定し、テストし、そして保守するのかを扱います。さらに、 + 本章を通してあなたの役に立つ設定例が載っています。 + + この章を読めば以下のことが分かります。 + + + + ゲートウェイと経路の基本 + + + + FreeBSD をブリッジとして動作させる方法 + + + + ネットワークファイルシステム (NFS) の設定方法 + + + + ディスクレスマシンのネットワークブートの設定方法 + + + + ユーザアカウントを共有するためのネットワークインフォメーションサーバ (NIS) の設定方法 + + + + DHCP を用いて自動的にネットワーク設定を行う方法 + + + + ドメインネームサーバ (DNS) の設定方法 + + + + NTP プロトコルを用いて日時を同期してタイムサーバを設定する方法 + + + + ネットワークアドレス変換 (NAT) の設定方法 + + + + inetd デーモンの管理方法 + + + + PLIP 経由で二台のコンピュータを接続する方法 + + + + FreeBSD で IPv6 を設定する方法 + + - - ゲートウェイとルート + この章を読む前に、以下のことを行っておくべきです。 - 原作: &a.gryphon;. - 1995 年 10 月 6 日. + + + /etc/rc スクリプトの基本を理解していること + + + + 基礎的なネットワーク用語に精通していること + + + + + + + + Coranth + Gryphon + 寄稿: + + + + ゲートウェイと経路 + + + + ルーティング + ゲートウェイ + サブネット + あるマシンがネットワーク上で他のマシンをみつけることができるようにするには、 + あるマシンから他のマシンへどのようにたどり着くかを記述する適切な仕組みが必要です。 + この仕組みをルーティングと呼びます。 + 経路 (route) は 送信先 + (destination) と ゲートウェイ の + 2 つのアドレスの組で定義します。この組合せは、この + 送信先 へたどり着こうとする場合は、その + ゲートウェイ + を通じて通信することを示しています。 + 送信先には個々のホスト、サブネット、デフォルト + の 3 つの型があります。 + デフォルトルート + は他のどの経路も適用できない場合に使われます。 + デフォルトルートについてはのちほどもう少し詳しく述べます。 + また、ゲートウェイには、個々のホスト、インタフェース (リンク とも呼ばれます)、 - イーサネットハードウェアアドレスという 3つのタイ - プのゲートウェイについて説明します。 + イーサネットハードウェアアドレス (MAC アドレス) + の 3 つの型があります。 例 - 以下に示す netstat -r - の出力の例を使って、 ルーティン - グがいろいろと異なっている様子を説明することにします。 + 以下に示す netstat + の例を使って、ルーティングのさまざまな状態を説明します。 - Destination Gateway Flags Refs Use Netif Expire + &prompt.user; netstat -r +Routing tables + +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 +example.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 - を経由して送られるのではありません。 - +host2 0:e0:a8:37:8:1e UHLW 0 5 lo0 => +host2.example.com link#1 UC 0 0 +224 link#1 UC 0 0 + + デフォルトルート (default route) + 最初の 2 行はデフォルトルート + (次節で扱います) と、 + localhost への経路を示しています。 + + ループバックデバイス (loopback device) + localhost に割り当てるインタフェース + (Netif 欄) + としてこのルーティングテーブルが指定しているのは + lo0 + で、これはループバックデバイスともいいます。 + これは結局のところ出たところに戻るだけなので、 + この送信先あてのトラフィックは、LAN + に送られずに、すべて内部的に処理されます。 + + + イーサネット + MAC アドレス + 次の行では - 0:e0:... - というアドレスに注目しましょう。 - これはイーサネットハードウェアアドレスです。 FreeBSDは自動的に - ローカルなイーサネット上の任意のホスト - (この例ではtest0) を見つけ、 + 0:e0: から始まるアドレスに注目しましょう。 + これはイーサネットハードウェアアドレスで、MAC アドレスともいいます。 + FreeBSD はローカルなイーサネット上の任意のホスト + (この例では test0) を自動的に認識し、 イーサネットインタフェース ed0 - の所にそのホストへの経路を直接つけ加えます。 タイムアウト時間 - (Expireの 欄) - も経路のタイプと結びついており、 指定された時間が経過しても応 - 答がないときに使用します。 この場合、 - 経路情報は自動的に削除されま す。 これらのホストは、 RIP(Routing - Information Protocol) という、 - 最短パスの判定に基づいてローカルホストへの経路を - 決定する仕組みを利用することで認識されます。 - - 更に、 FreeBSDではローカルサブネット + にそのホストへの直接の経路をつけ加えます。 + この種の経路には、タイムアウト時間 (Expire 欄) + も結びつけられており、 + 指定された時間内にホストからの応答がないことを判断するのに用いられます。 + その場合、そのホストへの経路情報は自動的に削除されます。 + これらのホストは + RIP (Routing Information Protocol) という、 + 最短パス判定に基づいてローカルなホストへの経路を決定する仕組みを利用して認識されます。 + + サブネット + さらに FreeBSD + ではローカルサブネットへの経路情報も加えることができます (10.20.30.255 は 10.20.30 というサブネットに対するブロードキャストアドレスで、 - foobar.com - はこのサブネットに結びつけられているドメイン名) - への経路情報も加えることができます。 - link#1というのは、 - このマシンの最初のイーサネットカードのことをさします。 これら - については、 - 何も追加インタフェースが指定されていないことに気づく - でしょう。 - - これらの2つのグループ(ローカルネットワークホストと - ローカルサブネット) の両方とも、 routed - と呼ばれるデーモンによって自動的に経路が設定されます。 - routed を動かさなければ、 - 静的に定義した (つまり具体的に設定した) - 経路のみ存在することになります。 + example.com + はこのサブネットに結びつけられているドメイン名)。 + link#1 という名称は、 + このマシンの一つ目のイーサネットカードのことをさします。 + これらについては、 + 何も追加インタフェースが指定されていないことがわかります。 + + これら 2 つのグループ + (ローカルネットワークホストとローカルサブネット) + は、両方とも routed + というデーモンによって自動的に経路が設定されます。 + routed を動かさなければ、静的に定義した + (つまり明示的に設定した) 経路のみが存在することになります。 host1 の行は私たちのホストのことで、 - イーサネットアドレスで示されています。 送信側のホストの場合、 + イーサネットアドレスで示されています。送信側のホストの場合、 FreeBSDはイーサネットインタフェースへ送るのではなく、 - ループバックインタフェース - (lo0)を使います。 - - 2つあるhost2の行は、 - ifconfigのエイリアス (このようなことをする理由については - ethernetの章を参照してください) を使ったとき - にどのようになるかを示す例です。 - lo0の後にある=> - は、 インタフェースが - (このアドレスがローカルなホストを参照しているので) + ループバックインタフェース (lo0) + を使います。 + + 2 つある host2 の行は、 + &man.ifconfig.8; のエイリアスを使ったときにどのようになるかを示す例です + (このようなことをする理由については + Ethernet の節を参照してください)。 + lo0 の後にある => は、 + インタフェースが (このアドレスがローカルなホストを参照しているので) ループバックを使っているというだけでなく、 エイリアスになっていることも示しています。 - このような経路はエイリアスをサポートしている - ホストにのみ現れます。 - ローカルネットワーク上の他のすべてのホストでは - 単にlink#1となります。 - - 最後の行 (destinationが224のサブネット) - はマルチキャストで扱うものですが、 - これは他の章で説明します。 - - 他の欄については Flags - について説明する必要があります。 - それぞれの経路は欄に示されているように違った属性を - もっています。 - 以下にいくつかのフラグとこれらが何を意味しているかを示します。 + このような経路はエイリアスに対応しているホストにのみ現れます。 + ローカルネットワーク上の他のすべてのホストでは、 + それぞれの経路に対して単にlink#1 となります。 + + 最後の行 (送信先サブネット 224) + はマルチキャストで扱うものですが、これは他の節で説明します。 + + 最後に Flags (フラグ) + 欄にそれぞれの経路のさまざまな属性が表示されます。 + 以下にフラグの一部と、それが何を意味しているかを示します。 @@ -154,96 +234,93 @@ host2.foobar.com link#1 UC 0 0 H - Host: 経路の destinationが単一のホストです。 + Host: 経路の送信先が単一のホストです。 G - Gateway: この destinationへ送られると、 どこへ送れ - ばよいかを明らかにして、 + Gateway: この送信先へ送られると、 + どこへ送ればよいかを明らかにして、 そのリモートシステムへ送られます。 S - Static: この経路はシステムによって自動的に生成 - されたのではなく、 手動で作成されました。 + Static: + この経路はシステムによって自動的に生成されたのではなく、 + 手動で作成されました。 C - Clone: マシンに接続したときにこの経路に基づく - 新しい経路が作られます。 このタイプの経路は通常は - ローカルネットワークで使われます。 + Clone: + マシンに接続したときにこの経路に基づく新しい経路が作られます。 + この型の経路は通常はローカルネットワークで使われます。 W - WasCloned: ローカルエリアネットワーク(Clone) - の経路に基づいて - 自動的に生成された経路であることを示します。 + WasCloned: + ローカルエリアネットワーク (LAN) の + (Clone) 経路に基づいて自動的に生成された経路であることを示します。 L - Link: イーサネットハードウェアへの参照を含む - 経路です。 + Link: + イーサネットハードウェアへの参照を含む経路です。 - + デフォルトルート - ローカルシステムからリモートホストにコネクションを張る - 必要がある場合、 既知のパスが存在するかどうかを確認するためにル - ーティングテーブルをチェックします。 - 到達するためのパスを知っているサブネットの内部に - リモートホストがある場合 (Cloned routes)、 システムはインタフェース - から接続できるかどうかをチェックします。 - - 知っているパスがすべて駄目だった場合でも、 システムには - 最後の切り札の デフォルト ルートがあります。 - このルートは ゲートウェイルート (普通はシステムに - 1つしかありません) の特別なものです。 そして、 - フラグフィールドは必ず c - がマークされています。 このゲートウェイは、 LAN 内のホストにとっ - て、 外部 (PPPのリンクを経由する場合や、 - データラインに接続するハードウェアデバイスなど) - へ直接接続するマシンすべてのためのものです。 - - 外部に対するゲートウェイとして機能するマシンで - デフォルトルートを設定する場合、 + デフォルトルート + ローカルシステムからリモートホストにコネクションを張る必要がある場合、 + 既知の経路が存在するかどうかを確認するためにルーティングテーブルをチェックします。 + 到達するための経路を知っているサブネットの内部にリモートホストがある場合 + (Cloned routes)、 + システムはそのインタフェースから接続できるかどうか確認します。 + + 知っているパスがすべて駄目だった場合でも、 + システムには最後の手段として デフォルト + ルートがあります。このルートはゲートウェイルート + (普通はシステムに 1 つしかありません) の特別なものです。そして、 + フラグ欄には必ず c + が表示されています。このゲートウェイは、LAN + 内のホストにとって、どのマシンでも外部へ + (PPP リンク、DSL、ケーブルモデム、T1、 + またはその他のネットワークインタフェースのいずれかを経由して) + 直接接続するために設定されるものです。 + + 外部に対するゲートウェイとして機能するマシンでデフォルトルートを設定する場合、 デフォルトルートはインターネットサービスプロバイダ (ISP) のサイトのゲートウェイマシンになるでしょう。 それではデフォルトルートの一例を見てみましょう。 - 一般的な構成を示します。 + 一般的な構成を示します。 - -[Local2] <--ether--> [Local1] <--PPP--> [ISP-Serv] <--ether--> [T1-GW] - +[Local2] <--ether--> [Local1] <--PPP--> [ISP-Serv] <--ether--> [T1-GW] ホスト Local1 とホスト Local2 - を PPP で ISP のターミナルサーバと接続されているあなたの - サイトだとします。 - ISP はサイト内にロー カルなネットワークを持っていて、 - そこにはさまざまなものがあり、 - あなたの接続するサーバや ISP のインターネットへの - 接続点であるハードウェアデバイス (T1-GW) などがあります。 + はあなたのサイト内にあります。Local1 + はダイアルアップ PPP 接続経由で ISP に接続されています。 + この PPP サーバコンピュータは、その ISP + のインターネットへの接続点に向けた外部インタフェースを備えた他のゲートウェイコンピュータへ + LAN を通じて接続しています。 - あなたのマシンのデフォルトルートは - それぞれ次のようになります。 + あなたのマシンのデフォルトルートはそれぞれ次のようになります。 - host - default gateway - interface + ホスト + デフォルトゲートウェイ + インタフェース @@ -251,7 +328,7 @@ host2.foobar.com link#1 UC 0 0 Local2 Local1 - ethernet + Ethernet @@ -263,195 +340,1335 @@ host2.foobar.com link#1 UC 0 0 - なぜ (あるいは、 どうやって) Local1 の - デフォルトゲートウェイをISPのサーバでなく - T1-GWにセットするのか という質問がよくあります。 - - コネクションのローカルの側については、 - PPPのインタフェースは - ISPのローカルネットワーク上のアドレスを用いているため、 - ISPのローカルネットワーク上のすべてのマシンへの経路は - 自動的に生成されています。 つまり、 あなたのマシンは、 - どのようにT1-GW - まで届くかという経路を既に知っていることになりますから、 - ISPサーバに媒介的なトラフィックをかける必要はありません。 - - 最後になりましたが、 一般的にローカルネットワークでは - ...1 - というアドレスをゲートウェイアドレスとして使います。 ですから - (同じ例を用います)、 あなたのclass-Cのアドレス空間が - 10.20.30で ISPが - 10.9.9を用いている場合、 + なぜ (あるいは、どうやって) + デフォルトゲートウェイを、Local1 が接続されている + ISP のサーバではなく、T1-GW に設定するのか + という質問がよくあります。 + + PPP 接続で、あなたのサイト側の PPP インタフェースは、 + ISP のローカルネットワーク上のアドレスを用いているため、 + ISP のローカルネットワーク上のすべてのマシンへの経路は + 自動的に生成されています。 + つまりあなたのマシンは、どのようにして + T1-GW に到達するかという経路を既に知っていることになりますから、 + ISP サーバにトラフィックを送るのに、中間的な段階を踏む必要はありません。 + + 最後になりましたが、一般的にローカルネットワークでは + X.X.X.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) - + + + + + ホスト + デフォルトルート + + + + + 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つのサブネットとする - 場合に用いられます。 + デュアルホームホスト + デュアルホームホスト + + ここで扱うべき種類の設定がもう一つあります。 + それは 2 つの異なるネットワークにまたがるホストです。 + 技術的にはゲートウェイとして機能するマシン (上の例では + PPP コネクションを用いています) はすべてデュアルホームホストです。 + しかし実際にはこの言葉は、2 つの + LAN 上のサイトであるマシンを指す言葉としてのみ使われます。 + + 2 枚のイーサネットカードを持つマシンが、 + 別のサブネット上にそれぞれアドレスを持っている場合があります。 + あるいは、イーサネットカードが 1 枚しかないマシンで、 + &man.ifconfig.8; のエイリアスを使っているかもしれません。 + 物理的に分かれている 2 つのイーサネットのネットワークが使われているならば前者が用いられます。 + 後者は、物理的には 1 つのネットワークセグメントで、 + 論理的には 2 つのサブネットに分かれている場合に用いられます。 どちらにしても、 - このマシンがお互いのサブネットへのゲートウェイ (inbound - route) として定義されていることが分かるように、 おのお - ののサブネットでルーティングテーブルを設定します。 このマシンが - 2 つのサブネットの間のブリッジとして動作するという構成は、 パケ - ットのフィルタリングを実装する必要がある場合や、 一方向または双 - 方向のファイアウォールを利用したセキュリティを構築する場合によ - く用いられます。 + このマシンがお互いのサブネットへのゲートウェイ (inbound route) + として定義されていることが分かるように、 + おのおののサブネットでルーティングテーブルを設定します。このマシンが + 2 つのサブネットの間のルータとして動作するという構成は、 + パケットのフィルタリングを実装する必要がある場合や、 + 一方向または双方向のファイアウォールを利用したセキュリティを構築する場合によく用いられます。 + + このマシンが二つのインタフェース間で実際にパケットを受け渡すようにしたい場合は、 + FreeBSD でこの機能を有効にしないといけません。 + + + + ルータの構築 + + ルータ + + ネットワークルータは単にあるインタフェースから別のインタフェースへパケットを転送するシステムです。 + インターネット標準およびすぐれた技術的な慣習から、 + FreeBSD プロジェクトは + FreeBSD においてこの機能をデフォルトでは有効にしていません。 + &man.rc.conf.5; 内で次の変数を YES + に変更することでこの機能を有効にできます: + + gateway_enable=YES # Set to YES if this host will be a gateway + + このオプションは &man.sysctl.8; 変数の + net.inet.ip.forwarding を + 1 に設定します。 + 一時的にルーティングを停止する必要があるときには、 + この変数を一時的に 0 に設定しなおせます。 + + 次に、トラフィックの宛先を決めるために、 + そのルータには経路情報が必要になります。 + ネットワークが十分簡素なら、静的経路が利用できます。 + また、FreeBSD は BSD の標準ルーティングデーモンである + &man.routed.8; を備えています。これは RIP + (バージョン 1 および 2) および IRDP を扱えます。 + BGP バージョン 4、OSPF バージョン2、 + その他洗練されたルーティングプロトコルは + net/zebra + package を用いれば対応できます。 + また、より複雑なネットワークルーティングソリューションには、 + gated のような商用製品も利用可能です。 + + BGP + RIP + OSPF + + このように FreeBSD を設定したとしても、 + ルータに対するインターネット標準要求を完全に満たすわけではありません。 + しかし、通常利用に関しては十分といえます。 - ルーティングの伝播 + ルーティングの伝搬 + ルーティングの伝搬 - すでに外部との経路をどのように定義したらよいかは - 説明しました。 - しかし外部から私たちのマシンをどのようにして - 見つけるのかについては説明していません。 + 外部との経路をどのように定義したらよいかはすでに説明しました。 + しかし外部から私たちのマシンをどのようにして見つけるのかについては説明していません。 ある特定のアドレス空間 (この例では class-C のサブネット) におけるすべてのトラフィックが、 - 到着したパケットを内部で転送するネ - ットワーク上の特定のホストに送られるようにルーティングテーブル - を設定することができるのは分かっています。 + 到着したパケットを内部で転送するネットワーク上の特定のホストに送られるようにルーティングテーブルを設定することができるのは分かっています。 あなたのサイトにアドレス空間を割り当てる場合、 あなたのサブネットへのすべてのトラフィックがすべて - PPPリンクを通じてサイトに送 - ってくるようにサービスプロバイダはルーティングテーブルを設定し - ます。 しかし、 国境の向こう側のサイトはどのようにしてあなたの - ISPへ送ることを知るのでしょうか? + PPP リンクを通じてサイトに送ってくるようにサービスプロバイダはルーティングテーブルを設定します。 + しかし、国境の向こう側のサイトはどのようにしてあなたの + ISP へ送ることを知るのでしょうか? 割り当てられているすべてのアドレス空間の経路を維持する (分散している DNS 情報とよく似た) システムがあり、 - そのインターネット バックボーンへの接続点を定義しています。 + そのインターネットバックボーンへの接続点を定義しています。 バックボーン とは国を越え、 - 世界中のインターネットのトラフィックを運ぶ主要 - な信用できる幹線のことです。 どのバックボーンマシンも、 - あるネットワークから特定のバックボーンのマシンへ - 向かうトラフィックと、 - そのバックボーンのマシンからあなたのネットワークに届くサービス - プロバイダまでのチェーンのマスタテーブルのコピーを持っていま - す。 - - あなたのサイトが接続(プロバイダからみて内側にある - ことになります) したということを、 プロバイダからバックボー - ンサイトへ通知することはプロバイダの仕事です。 これが経 - 路の伝搬です。 + 世界中のインターネットのトラフィックを運ぶ主要な信用できる幹線のことです。 + どのバックボーンマシンも、 + あるネットワークから特定のバックボーンのマシンへ向かうトラフィックと、 + そのバックボーンのマシンからあなたのネットワークに届くサービスプロバイダまでのチェーンのマスタテーブルのコピーを持っています。 + + あなたのサイトが接続 + (プロバイダからみて内側にあることになります) したということを、 + プロバイダからバックボーンサイトへ通知することはプロバイダの仕事です。 + これが経路の伝搬です。 トラブルシューティング - - ルーティングの伝搬に問題が生じて、 いくつかのサイトが - 接続をおこなうことができなくなることがあります。 - ルーティングがどこでおかしくなっているかを明らかにするのに - 最も有効なコマンドはおそらく &man.traceroute.8; コマンドでしょ - う。 このコマンドは、 - あなたがリモートマシンに対して接続をおこなう - ことができない(例えば &man.ping.8; に失敗するような場合) - 場合も、 同じように有効です。 - - &man.traceroute.8; コマンドは、 + + traceroute + + 経路の伝搬に問題が生じて、 + いくつかのサイトが接続をおこなうことができなくなることがあります。 + ルーティングがどこでおかしくなっているかを明らかにするのに最も有効なコマンドはおそらく + &man.traceroute.8; コマンドでしょう。 + このコマンドは、あなたがリモートマシンに対して接続をおこなうことができない + (たとえば &man.ping.8; に失敗するような) + 場合も、同じように有効です。 + + &man.traceroute.8; コマンドは、 接続を試みているリモートホストを引数にして実行します。 - 試みているパスの経由するゲートウェイホストを表示し、 + 試みている経路が経由するゲートウェイホストを表示し、 最終的には目的のホストにたどり着くか、 - コネクションの欠如によって終ってしまうかのどちら - かになります。 + コネクションの欠如によって終ってしまうかのどちらかになります。 - より詳しい情報は、 &man.traceroute.8; + より詳しい情報は、&man.traceroute.8; のマニュアルページをみてください。 + + + マルチキャストルーティング + + マルチキャスト + options MROUTING + + FreeBSD はマルチキャストアプリケーションとマルチキャストルーティングの両方にネイティブ対応しています。 + マルチキャストアプリケーションを動かすのに FreeBSD + で特別な設定をする必要は一切ありません。 + アプリケーションは普通はそのままで動くでしょう。 + マルチキャストルーティングに対応するには、 + 下のオプションを追加してカーネルをコンパイルする必要があります。 + + options MROUTING + + さらに、/etc/mrouted.conf + を編集してルーティングデーモン &man.mrouted.8; + を設定し、トンネルと DVMRP を設置する必要があります。 + マルチキャスト設定についての詳細は mrouted + のマニュアルを参照してください。 + - - Bridging + + + + + Eric + Anderson + 原作: + + + + 無線ネットワーク + + 無線ネットワーク + + 802.11 + 無線ネットワーク + + + + はじめに + 常にネットワークケーブルをつないでいるという面倒なことをせずに、 + コンピュータを使用できることは、とても有用でしょう。 + FreeBSD は無線のクライアントとして、 + さらにアクセスポイントとしても使えます。 + + + + 無線の動作モード + 802.11 無線デバイスの設定には、BSS と IBSS + の二つの方法があります。 + + + BSS モード + BSS モードは一般的に使われているモードです。 + BSS モードはインフラストラクチャモードとも呼ばれています。 + このモードでは、 + 多くの無線アクセスポイントが + 1 つの有線ネットワークに接続されます。 + それぞれのワイヤレスネットワークは固有の名称を持っています。 + その名称はネットワークの SSID と呼ばれます。 + + 無線クライアントはこれらの無線アクセスポイントに接続します。 + IEEE 802.11 標準は無線ネットワークが接続するのに使用するプロトコルを規定しています。 + SSID が設定されているときは、 + 無線クライアントを特定のネットワークに結びつけることができます。 + SSID を明示的に指定しないことにより、 + 無線クライアントを任意のネットワークに接続することもできます。 + + + + IBSS モード + アドホックモードとも呼ばれる IBSS モードは、 + 一対一通信のために設計された通信方式です。 + 実際には二種類のアドホックモードがあります。 + 一つは IBSS モードで、アドホックモード、または + IEEE アドホックモードとも呼ばれます。 + このモードは IEEE 802.11 標準に規定されています。 + もう一つはデモアドホックモードもしくは Lucent アドホックモード + (そして時々、紛らわしいことに、アドホックモード) + と呼ばれるモードです。 + このモードは古く、802.11 が標準化する以前のアドホックモードで、 + これは古い設備でのみ使用されるべきでしょう。 + ここでは、どちらのアドホックモードについてもこれ以上言及しません。 + + + + + インフラストラクチャーモード + + アクセスポイント + + アクセスポイントは一つ以上の無線クライアントが、 + そのデバイスをセントラルハブとして利用できるようにする無線ネットワークデバイスです。 + アクセスポイントを使用している間、 + すべてのクライアントはアクセスポイントを介して通信します。 + 家屋や職場、または公園などの空間を無線ネットワークで完全にカバーするために、 + 複数のアクセスポイントがよく使われます。 + + アクセスポイントは一般的に複数のネットワーク接続 + (無線カードと、 + その他のネットワークに接続するための一つ以上の有線イーサネットアダプタ) + を持っています。 + + アクセスポイントは、出来合いのものを購入することもできますし、 + FreeBSD と対応している無線カードを組み合わせて、 + 自分で構築することもできます。 + いくつものメーカが、 + さまざまな機能をもった無線アクセスポイントおよび無線カードを製造しています。 + + + + FreeBSD のアクセスポイントの構築 + 無線ネットワーク + アクセスポイント + + + 要件 + + FreeBSD で無線アクセスポイントを設定するためには、 + 互換性のある無線カードが必要です。 + 現状では Prism チップセットのカードのみに対応しています。 + また FreeBSD + に対応している有線ネットワークカードも必要になるでしょう + (これを見つけるのは難しくないでしょう。 + FreeBSD は多くの異なるデバイスに対応しているからです) 。 + この手引きでは、 + 無線デバイスと有線ネットワークカードに接続しているネットワーク間のトラフィックを + &man.bridge.4; したいと仮定します。 + + FreeBSD がアクセスポイントを実装するのに使用する hostap + 機能はファームウェアの特定のバージョンで一番よく性能を発揮します。 + Prism 2 カードは、 + 1.3.4 以降のバージョンのファームウェアで使用すべきです。 + Prism 2.5 および Prism 3 カードでは、バージョン 1.4.9 + のバージョンのファームウェアで使用すべきです。 + それより古いバージョンのファームウェアは、 + 正常に動くかもしれませんし、動かないかもしれません。 + 現時点では、カードのファームウェアを更新する唯一の方法は、 + カードの製造元から入手できる &windows; + 用ファームウェアアップデートユーティリティを使うものです。 + + + + 設定 + はじめにシステムが無線カードを認識していることを確認してください。 + &prompt.root; ifconfig -a +wi0: flags=8843<UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST> mtu 1500 + inet6 fe80::202:2dff:fe2d:c938%wi0 prefixlen 64 scopeid 0x7 + inet 0.0.0.0 netmask 0xff000000 broadcast 255.255.255.255 + ether 00:09:2d:2d:c9:50 + media: IEEE 802.11 Wireless Ethernet autoselect (DS/2Mbps) + status: no carrier + ssid "" + stationname "FreeBSD Wireless node" + channel 10 authmode OPEN powersavemode OFF powersavesleep 100 + wepmode OFF weptxkey 1 + + 細かいことは気にせず、 + 無線カードがインストールされていることを示す何かが表示されていることを確かめてください。 + PC カードを使用していて、無線インタフェースを認識できない場合、 + 詳しい情報を得るために &man.pccardc.8; と &man.pccardd.8; + のマニュアルページを調べてみてください。 + + 次に、アクセスポイント用に + FreeBSD のブリッジ機能を担う部分を有効にするために、 + モジュールを読み込む必要があるでしょう。 + &man.bridge.4; モジュールを読み込むには、 + 次のコマンドをそのまま実行します。 + + &prompt.root; kldload bridge + + モジュールを読み込む時には、何もエラーはでないはずです。 + もしもエラーがでたら、カーネルに &man.bridge.4; + のコードを入れてコンパイルする必要があるかもしれません。 + ハンドブックのブリッジの節が、 + この課題を成し遂げる手助けをになるかもしれません。 + + ブリッジ部分が準備できたので、 + どのインタフェース間をブリッジするのかを + FreeBSD カーネルに指定する必要があります。 + これは、&man.sysctl.8; を使って行います。 + + &prompt.root; sysctl net.link.ether.bridge=1 +&prompt.root; sysctl net.link.ether.bridge_cfg="wi0 xl0" +&prompt.root; sysctl net.inet.ip.forwarding=1 + + さて、無線カードを設定するときです。 + 次のコマンドはカードをアクセスポイントとして設定します。 + + +&prompt.root; ifconfig wi0 ssid my_net channel 11 media DS/11Mbps mediaopt hostap up stationname "FreeBSD AP" + + この &man.ifconfig.8; コマンド行は + wi0 インタフェースを up + 状態にし、SSID を my_net に設定し、 + ステーション名を FreeBSD AP に設定します。 + オプションはカードを 11Mbps + モードに設定し、また + を実際に有効にするのに必要です。 + + オプションはインタフェースをアクセスポイントモードにします。 + オプションは使用するチャネルを + 802.11b に設定します。 + 各規制地域 (regulatory domain) で有効なチャネル番号は + &man.wicontrol.8; マニュアルに載っています。 + + さて、 + これで完全に機能するアクセスポイントが立ち上がり、動作しています。 + より詳しい情報については、&man.wicontrol.8;, &man.ifconfig.8; + および &man.wi.4; のマニュアルを読むとよいでしょう。 + + + また、下記の暗号化に関する節を読むこともおすすめします。 + + + + ステータス情報 + 一度アクセスポイントが設定されて稼働すると、 + 管理者はアクセスポイントを利用しているクライアントを見たいと思うでしょう。 + いつでも管理者は以下のコマンドを実行できます。 + + &prompt.root; wicontrol -l +1 station: +00:09:b7:7b:9d:16 asid=04c0, flags=3<ASSOC,AUTH>, caps=1<ESS>, rates=f<1M,2M,5.5M,11M>, sig=38/15 + + これは一つの局が、 + 表示されているパラメータで接続していることを示します。 + 表示された信号は、 + 相対的な強さを表示しているだけのものとして扱われるべきです。 + dBm やその他の単位への変換結果は、 + 異なるファームウェアバージョン間で異なります。 + + + + + クライアント + + 無線クライアントはアクセスポイント、 + または他のクライアントに直接アクセスするシステムです。 + + 典型的には、 + 無線クライアントが有しているネットワークデバイスは、 + 無線ネットワークカード 1 枚だけです。 + + 無線クライアントを設定するにはいくつか方法があります。 + それぞれは異なる無線モードに依存していますが、 + 一般的には BSS + (アクセスポイントを必要とするインフラストラクチャーモード) か、 + IBSS (アドホック、またはピアツーピアモード) のどちらかです。 + ここでは、アクセスポイントと通信をするのに、 + 両者のうちで最も広まっている BSS モードを使用します。 + + + 要件 + FreeBSD を無線クライアントとして設定するのに、 + 本当に必要なものはたった 1 つだけです。 + FreeBSD が対応している無線カードが必要です。 + + + + 無線 FreeBSD クライアントの設定 + + 設定をはじめる前に、 + あなたが接続しようとする無線ネットワークについていくつか知っておかなければなりません。 + この例では、my_net + という名前で暗号化は無効になっているネットワークに接続しようとしています。 + + Note: この例では暗号化を行っていないのですが、 + これは危険な状況です。次の節で、暗号化を有効にする方法と、 + なぜそれが重要で、 + 暗号技術によっては完全にはあなたを保護することができないのはなぜか、 + ということを学ぶでしょう。 + + カードが FreeBSD に認識されていることを確認してください。 + + &prompt.root; ifconfig -a +wi0: flags=8843<UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST> mtu 1500 + inet6 fe80::202:2dff:fe2d:c938%wi0 prefixlen 64 scopeid 0x7 + inet 0.0.0.0 netmask 0xff000000 broadcast 255.255.255.255 + ether 00:09:2d:2d:c9:50 + media: IEEE 802.11 Wireless Ethernet autoselect (DS/2Mbps) + status: no carrier + ssid "" + stationname "FreeBSD Wireless node" + channel 10 authmode OPEN powersavemode OFF powersavesleep 100 + wepmode OFF weptxkey 1 + + それでは、このカードをネットワークに合わせて設定しましょう。 + + &prompt.root; ifconfig wi0 inet 192.168.0.20 netmask 255.255.255.0 ssid my_net + + 192.168.0.20 と + 255.255.255.0 + を有線ネットワークで有効な + IP アドレスとネットマスクに置き換えてください。 + アクセスポイントは無線ネットワークと有線ネットワークの間でデータをブリッジしているため、 + ネットワーク上の他のデバイスには、このデバイスが、他と同様に、 + 有線ネットワーク上にあるかのように見えることに注意してください。 + + これを終えると、 + あなたは標準的な有線接続を使用しているかのように、 + 有線ネットワーク上のホストに ping を送ることができるでしょう。 + + 無線接続に関する問題がある場合は、 + アクセスポイントに接続されていることを確認してください。 + + &prompt.root; ifconfig wi0 + + いくらか情報が表示されるはずです。 + その中に以下の表示があるはずです。 + status: associated + + もしこのように接続されていると表示されなければ、 + アクセスポイントの範囲外かもしれないし、 + 暗号化が有効になっていないのかもしれないし、 + または設定の問題を抱えているのかもしれません。 + + + + + 暗号化 + + 無線ネットワーク + 暗号化 + + + 無線ネットワークを暗号化することが重要なのは、 + 十分保護された領域にネットワークを留める能力がもはやないからです。 + 無線データはその周辺全体にわたって放送されるので、 + それを読みたいと思う人はだれでも読むことができます。 + そこで暗号化が役に立ちます。 + 電波に載せて送られるデータを暗号化することによって、 + 興味を抱いた者が空中からデータを取得することをずっと難しくします。 + + クライアントとアクセスポイント間のデータを暗号化するもっとも一般的な方法には、 + WEP と &man.ipsec.4; の二種類があります。 + + + WEP + WEP + + WEP は Wired Equivalency Protocol + (訳注: 直訳すると、有線等価プロトコル) の略語です。WEP + は無線ネットワークを有線ネットワークと同程度に安全で確実なものにしようとする試みです。 + 残念ながら、これはすでに破られており、 + 破るのはそれほど苦労しません。 + これは、機密データを暗号化するという場合に、 + これに頼るものではないということも意味します。 + + なにも無いよりはましなので、 + 次のコマンドを使って、あなたの新しい FreeBSD アクセスポイント上で + WEP を有効にしてください。 + + &prompt.root; ifconfig wi0 inet up ssid my_net wepmode on wepkey 0x1234567890 media DS/11Mbps mediaopt hostap + + クライアントについては次のコマンドで WEP を有効にできます。 + + &prompt.root; ifconfig wi0 inet 192.168.0.20 netmask 255.255.255.0 ssid my_net wepmode on wepkey 0x1234567890 + + 0x1234567890 + をより特異なキーに変更すべきであることに注意してください。 + + + + IPsec + + &man.ipsec.4; + はネットワーク上で交わされるデータを暗号化するための、 + はるかに頑健で強力なツールです。 + これはネットワーク上の無線データを暗号化する明らかに好ましい方法です。 + ハンドブック内の IPsec 節で + &man.ipsec.4; セキュリティ、 + およびその実装方法の詳細を読むことができます。 + + + + + ツール + + 無線ネットワークをデバッグしたり設定するのに使うツールがわずかばかりあります。 + ここでその一部と、それらが何をしているか説明します。 + + + <application>bsd-airtools</application> パッケージ + + bsd-airtools パッケージは、 + WEP キークラッキング、 + アクセスポイント検知などの無線通信を監査するツールを含む完備されたツール集です。 + + bsd-airtools ユーティリティは + net/bsd-airtools port + からインストールできます。 + ports のインストールに関する情報はハンドブックの + を参照してください。 + + dstumbler プログラムは、 + アクセスポイントの発見および + S/N 比のグラフ化をできるようにするパッケージツールです。 + アクセスポイントを立ち上げて動かすのに苦労しているなら、 + dstumbler + はうまく行く手助けになるかもしれません。 + + 無線ネットワークの安全性をテストするのに、 + dweputils (dwepcrack, + dwepdump および dwepkeygen) + を使用することで、 + WEP があなたの無線安全性への要求に対する正しい解決策かどうか判断するのを助けられるかもしれません。 + + + + <application>wicontrol</application>, <application>ancontrol</application> および <application>raycontrol</application> ユーティリティ + + これらは、無線ネットワーク上で無線カードがどのように動作するかを制御するツールです。 + 上記の例では、無線カードが wi0 + インタフェースであるので、&man.wicontrol.8; + を使用することに決めました。 + もし Cisco の無線デバイスを持っている場合は、それは + an0 として動作するでしょうから、 + &man.ancontrol.8; を使うことになるでしょう。 + + + + <application>ifconfig</application> コマンド + ifconfig + + &man.ifconfig.8; は &man.wicontrol.8; + と同じオプションの多くを処理できますが、 + いくつかのオプションを欠いています。 + コマンドライン引数とオプションについて + &man.ifconfig.8; を参照してください。 + + - Written by Steve Peterson - steve@zpfe.com. + + 対応しているカード + + アクセスポイント + + 現在のところ (アクセスポイントとして) + BSS モードに対応した唯一のカードは Prism 2, 2.5 + または 3 チップセットを利用したデバイスです。 + &man.wi.4; に完全な一覧があります。 + + + + クライアント + + 現在、FreeBSD では、ほとんどすべての 802.11b + 無線カードに対応しています。 + Prism, Spectrum24, Hermes, Aironet または Raylink + のチップセットを利用したほとんどのカードは、 + (アドホック、ピアツーピア、そして BSS の) + IBSS モードで無線ネットワークカードとして動作するでしょう。 + + + + + + + + + Pav + Lucistnik + 原作: + +
pav@oook.cz
+ + + + + Bluetooth + + Bluetooth はじめに + Bluetooth は免許のいらない 2.4 GHz の帯域を利用して、 + 10 m 程度のパーソナルネットワークを作る無線技術です。 + ネットワークはたいていの場合、その場その場で、携帯電話や + PDA やノートパソコンなどの携帯デバイスから形成されます。 + Wi-Fi などの他の有名な無線技術とは違い、 + Bluetooth はより高いレベルのサービスを提供します。 + たとえば、FTP のようなファイルサーバ、ファイルのプッシュ、 + 音声伝送、シリアル線のエミュレーションなどのサービスです。 + + &os; 内での Bluetooth スタックは Netgraph フレームワーク + (&man.netgraph.4; 参照) を使って実現されています。 + &man.ng.ubt.4; ドライバは、 + 多種多様な Bluetooth USB ドングルに対応しています。 + Broadcom BCM2033 チップを搭載した Bluetooth デバイスは &man.ubtbcmfw.4; + および &man.ng.ubt.4; ドライバによって対応されています。 + 3Com Bluetooth PC カード 3CRWB60-A は &man.ng.bt3c.4; + ドライバによって対応されています。 + シリアルおよび UART を搭載した Bluetooth デバイスは &man.sio.4;, + &man.ng.h4.4; および &man.hcseriald.8; ドライバによって対応されています。 + この節では USB Bluetooth ドングルの使用法について説明します。 + Bluetooth に対応しているのは &os; 5.0 以降のシステムです。 + + + 訳注 + 5.0, 5.1 Release ではカーネルモジュールは利用可能ですが、 + 種々のユーティリティとマニュアルは標準でコンパイルされていません。 + + + + + + デバイスの挿入 + デフォルトでは Bluetooth + デバイスドライバはカーネルモジュールとして利用できます。 + デバイスを接続する前に、 + カーネルにドライバを読み込む必要があります。 + + &prompt.root; kldload ng_ubt + + Bluetooth デバイスがシステム起動時に存在している場合、 + /boot/loader.conf + からモジュールを読み込んでください。 + + ng_ubt_load="YES" + + USB ドングルを挿してください。コンソールに (または syslog に) + 下記のような表示が現れるでしょう。 + + ubt0: vendor 0x0a12 product 0x0001, rev 1.10/5.25, addr 2 +ubt0: Interface 0 endpoints: interrupt=0x81, bulk-in=0x82, bulk-out=0x2 +ubt0: Interface 1 (alt.config 5) endpoints: isoc-in=0x83, isoc-out=0x3, + wMaxPacketSize=49, nframes=6, buffer size=294 + + /usr/share/examples/netgraph/bluetooth/rc.bluetooth + を /etc/rc.bluetooth + のようなどこか便利な場所にコピーしてください。 + このスクリプトは Bluetooth + スタックを開始および終了させるのに使われます。 + デバイスを抜く前にスタックを終了するのはよい考えですが、 + (たいていの場合) しなくても致命的ではありません。 + スタックを開始するときに、下記のような出力がされます。 + + &prompt.root; /etc/rc.bluetooth start ubt0 +BD_ADDR: 00:02:72:00:d4:1a +Features: 0xff 0xff 0xf 00 00 00 00 00 +<3-Slot> <5-Slot> <Encryption> <Slot offset> +<Timing accuracy> <Switch> <Hold mode> <Sniff mode> +<Park mode> <RSSI> <Channel quality> <SCO link> +<HV2 packets> <HV3 packets> <u-law log> <A-law log> <CVSD> +<Paging scheme> <Power control> <Transparent SCO data> +Max. ACL packet size: 192 bytes +Number of ACL packets: 8 +Max. SCO packet size: 64 bytes +Number of SCO packets: 8 + + + + ホストコントローラインタフェース (HCI) + HCI + + ホストコントローラインタフェース (HCI) は、 + ベースバンドコントローラおよびリンクマネージャへのコマンドインタフェースを提供し、 + ハードウェアステータスおよびコントロールレジスタへアクセスします。 + このインタフェースは + Bluetooth ベースバンド機能へアクセスする画一的な方法を提供します。 + ホストの HCI 層は Bluetooth ハードウェア上の HCI ファームウェアと、 + データとコマンドをやり取りします。 + ホストコントローラトランスポート層 (つまり物理的なバス) のドライバは、 + 両方の HCI 層に相互に情報を交換する能力を与えます。 + + 一つの Bluetooth デバイスにつき、hci + タイプの Netgraph ノードが一つ作成されます。 + HCI ノードは通常 Bluetooth デバイスドライバノード (下流) と + L2CAP ノード (上流) に接続されます。 + すべての HCI 動作はデバイスドライバノード上ではなく、 + HCI ノード上で行われなくてはいけません。 + HCI ノードのデフォルト名は devicehciです。 + 詳細については &man.ng.hci.4; マニュアルを参照してください。 + + 最も一般的なタスクの一つに、無線通信的に近傍にある Bluetooth + デバイスの発見があります。 + この動作は inquiry (問い合わせ) と呼ばれています。 + Inquiry や他の HCI に関連した動作は &man.hccontrol.8; + ユーティリティによってなされます。 + 下記の例は、どの + Bluetooth デバイスが通信圏内にあるかを知る方法を示しています。 + デバイスのリストが表示されるには数秒かかります。 + リモートデバイスは discoverable (発見可能な) + モードにある場合にのみ + inquiry に返答するということに注意してください。 + + &prompt.user; hccontrol -n ubt0hci inquiry +Inquiry result, num_responses=1 +Inquiry result #0 + BD_ADDR: 00:80:37:29:19:a4 + Page Scan Rep. Mode: 0x1 + Page Scan Period Mode: 00 + Page Scan Mode: 00 + Class: 52:02:04 + Clock offset: 0x78ef +Inquiry complete. Status: No error [00] + + BD_ADDR は + Bluetooth デバイスに固有のアドレスです。 + これはネットワークカードの MAC アドレスに似ています。 + このアドレスはデバイスとの通信を続けるのに必要となります。 + BD_ADDR に人間が判読しやすい名前を割り当てることもできます。 + /etc/bluetooth/hosts ファイルには、 + 既知の Bluetooth ホストに関する情報が含まれています。 + 次の例はリモートデバイスに割り当てられている、 + 人間が判読しやすい名前を得る方法を示しています。 + + &prompt.user; hccontrol -n ubt0hci remote_name_request 00:80:37:29:19:a4 +BD_ADDR: 00:80:37:29:19:a4 +Name: Pav's T39 + + リモートの Bluetooth デバイス上で inquiry を実行すると、 + あなたのコンピュータは your.host.name (ubt0) + と認識されます。 + ローカルデバイスに割り当てられた名前はいつでも変更できます。 + + Bluetooth システムは一対一接続 (二つの + Bluetooth ユニットだけが関係します) または一対多接続を提供します。 + 一対多接続では、接続はいくつかの Bluetooth デバイス間で共有されます。 + 次の例は、ローカルデバイスに対するアクティブなベースバンド接続のリストを得る方法を示しています。 + + &prompt.user; hccontrol -n ubt0hci read_connection_list +Remote BD_ADDR Handle Type Mode Role Encrypt Pending Queue State +00:80:37:29:19:a4 41 ACL 0 MAST NONE 0 0 OPEN + + connection handle + はベースバンド接続の終了が必要とされるときに便利です。 + もっとも、通常はこれを手動で行う必要はありません。 + Bluetooth スタックはアクティブでないベースバンド接続を自動的に終了します。 + + &prompt.root; hccontrol -n ubt0hci disconnect 41 +Connection handle: 41 +Reason: Connection terminated by local host [0x16] + + 利用可能な HCI コマンドの完全な一覧を得るには、 + hccontrol help を参照してください。 + HCI コマンドのほとんどはスーパユーザ権限を必要としません。 + + + + ロジカルリンクコントロールおよびアダプテーションプロトコル (L2CAP) + L2CAP + + ロジカルリンクコントロールおよびアダプテーションプロトコル + (L2CAP) は、プロトコル多重化ケーパビリティおよび分割・再編成動作を備えた、 + 上位層プロトコルへのコネクション指向およびコネクションレスデータサービスを提供します。 + L2CAP は上位層プロトコルおよびアプリケーションが + 64 KB までの長さの + L2CAP データパケットを送受信することを可能にします。 + + L2CAP は チャネル の概念に基づいています。 + チャネルはベースバンド接続の上位に位置する論理的な接続です。 + それぞれのチャネルは多対一の方法で一つのプロトコルに結びつけられます。 + 複数のチャネルを同じプロトコルに結びつけることは可能ですが、 + 一つのチャネルを複数のプロトコルに結びつけることはできません。 + チャネル上で受け取られたそれぞれの L2CAP パケットは、 + 適切なより上位のプロトコルに渡されます。 + 複数のチャネルは同じベースバンド接続を共有できます。 + + 一つの Bluetooth デバイスに対して、l2cap + タイプの Netgraph ノードが一つ作成されます。 + L2CAP ノードは通常 Bluetooth HCI ノード (下流) と + Bluetooth ソケットノード (上流) に接続されます。 + L2CAP ノードのデフォルト名は devicel2cap です。 + 詳細については &man.ng.l2cap.4; マニュアルを参照してください。 + + 便利なコマンドに、他のデバイスに ping を送ることができる + &man.l2ping.8; があります。Bluetooth 実装によっては、 + 送られたデータすべては返さないことがあります。 + したがって次の例で 0 バイト は正常です。 + + &prompt.root; l2ping -a 00:80:37:29:19:a4 +0 bytes from 0:80:37:29:19:a4 seq_no=0 time=48.633 ms result=0 +0 bytes from 0:80:37:29:19:a4 seq_no=1 time=37.551 ms result=0 +0 bytes from 0:80:37:29:19:a4 seq_no=2 time=28.324 ms result=0 +0 bytes from 0:80:37:29:19:a4 seq_no=3 time=46.150 ms result=0 + + &man.l2control.8; ユーティリティは + L2CAP ノード上でさまざまな操作を行うのに使われます。 + この例は、ローカルデバイスに対する論理的な接続 (チャネル) + およびベースバンド接続の一覧を得る方法を示しています。 + + &prompt.user; l2control -a 00:02:72:00:d4:1a read_channel_list +L2CAP channels: +Remote BD_ADDR SCID/ DCID PSM IMTU/ OMTU State +00:07:e0:00:0b:ca 66/ 64 3 132/ 672 OPEN +&prompt.user; l2control -a 00:02:72:00:d4:1a read_connection_list +L2CAP connections: +Remote BD_ADDR Handle Flags Pending State +00:07:e0:00:0b:ca 41 O 0 OPEN + + 別の診断ツールが &man.btsockstat.1; です。 + これは &man.netstat.1; と同様の作業を、Bluetooth + ネットワークに関するデータ構造についての行います。 + 下記の例は上の &man.l2control.8; と同じ論理的な接続を示します。 + + &prompt.user; btsockstat +Active L2CAP sockets +PCB Recv-Q Send-Q Local address/PSM Foreign address CID State +c2afe900 0 0 00:02:72:00:d4:1a/3 00:07:e0:00:0b:ca 66 OPEN +Active RFCOMM sessions +L2PCB PCB Flag MTU Out-Q DLCs State +c2afe900 c2b53380 1 127 0 Yes OPEN +Active RFCOMM sockets +PCB Recv-Q Send-Q Local address Foreign address Chan DLCI State +c2e8bc80 0 250 00:02:72:00:d4:1a 00:07:e0:00:0b:ca 3 6 OPEN + + + + RFCOMM プロトコル + RFCOMM + + RFCOMM プロトコルは L2CAP + プロトコルを介してシリアルポートのエミュレーションを提供します。 + このプロトコルは ETSI (訳注: 欧州電気通信標準化機構) + 標準 TS 07.10 に基づいています。 + RFCOMM プロトコルは、単純な伝送プロトコルに RS-232 (EIATIA-232-E) + シリアルポートの 9 本の結線をエミュレートする項目を加えたものです。 + RFCOMM プロトコルは、二つの Bluetooth デバイス間で、最大 60 + までの同時接続 (RFCOMM チャネル) に対応しています。 + + RFCOMM の目的から、完全な通信経路は、異なるデバイス上 + (通信の端点) で動作している二つのアプリケーションと、 + その間の通信セグメントを含んでいます。RFCOMM + は、それが動いているデバイスのシリアルポートを利用するアプリケーションをカバーするためのものです。 + 通信セグメントはあるデバイスから他のデバイスへの Bluetooth リンクです + (直接接続)。 + + RFCOMM は直接接続している場合のデバイス間の接続、 + またはネットワークの場合のデバイスとモデムの間の接続にだけ関係があります。 + RFCOMM は、一方が Bluetooth 無線技術で通信し、 + もう一方で有線インタフェースを提供するモジュールのような、 + 他の構成にも対応できます。 + + &os; では RFCOMM プロトコルは Bluetooth ソケット層に実装されています。 + + + + デバイスのペアリング + pairing + + デフォルトでは Bluetooth 通信は認証されておらず、 + すべてのデバイスが他のすべてのデバイスと通信できます。 + Bluetooth デバイス (たとえば携帯電話) は特定のサービス + (たとえばダイアルアップサービス) を提供するために、 + 認証を要求することも選択できます。 + Bluetooth 認証は通常 PIN コード で行われます。 + PIN コードは最長 16 文字のアスキー文字列です。 + ユーザは両デバイスで同じ PIN コードを入力することを要求されます。 + 一度 PIN コードを入力すると、 + 両デバイスは リンクキー を作成します。 + その後、リンクキーはそのデバイス自身または、 + 不揮発性記憶デバイス内に格納できます。 + 次の機会には、両デバイスは前に作成されたリンクキーを使用するでしょう。 + このような手続きをペアリング (pairing) + と呼びます。いずれかのデバイス上でリンクキーが失われたときには、 + ペアリングをやり直さなければならないことに注意してください。 + + &man.hcsecd.8; デーモンが + Bluetooth 認証要求のすべてを扱う責任を負っています。 + デフォルトの設定ファイルは + /etc/bluetooth/hcsecd.conf です。 + PIN コードが 1234 + に設定された携帯電話に関する例は以下の通りです。 + + device { + bdaddr 00:80:37:29:19:a4; + name "Pav's T39"; + key nokey; + pin "1234"; + } + + PIN コードには (長さを除いて) 制限はありません。 + いくつかのデバイス (たとえば Bluetooth ヘッドフォン) + には固定的な PIN コードが組み込まれているかもしれません。 + オプションは &man.hcsecd.8; + デーモンがフォアグラウンドで動作するように強制するため、 + 何が起きているのか確認しやすくなります。 + リモートデバイスがペアリングを受け取るように設定して、 + リモートデバイスへの Bluetooth 接続を開始してください。 + リモートデバイスはペアリングが受け入れらた、と応答して + PIN コードを要求するでしょう。 + hcsecd.conf 内にあるのと同じ + PIN コードを入力してください。 + これであなたの PC とリモートデバイスがペアとなりました。 + また、リモートデバイスからペアリングを開始することもできます。 + 以下は hcsecd の出力例です。 + +hcsecd[16484]: Got Link_Key_Request event from 'ubt0hci', remote bdaddr 0:80:37:29:19:a4 +hcsecd[16484]: Found matching entry, remote bdaddr 0:80:37:29:19:a4, name 'Pav's T39', link key doesn't exist +hcsecd[16484]: Sending Link_Key_Negative_Reply to 'ubt0hci' for remote bdaddr 0:80:37:29:19:a4 +hcsecd[16484]: Got PIN_Code_Request event from 'ubt0hci', remote bdaddr 0:80:37:29:19:a4 +hcsecd[16484]: Found matching entry, remote bdaddr 0:80:37:29:19:a4, name 'Pav's T39', PIN code exists +hcsecd[16484]: Sending PIN_Code_Reply to 'ubt0hci' for remote bdaddr 0:80:37:29:19:a4 + + + + サービスディスカバリプロトコル (SDP) + SDP + + サービスディスカバリプロトコル (SDP) は、 + クライアントアプリケーションが、 + サーバアプリケーションが提供するサービスの存在とその属性を発見する手段を提供します。 + サービスの属性には提示されているサービスのタイプまたはクラス、 + および、サービスを利用するのに必要な仕組みまたはプロトコルの情報が含まれます。 + + SDP には SDP サーバと SDP クライアント間の通信が含まれます。 + SDP サーバは、サーバに関連づけられたサービスの特性について記述しているサービスレコードの一覧を維持しています。 + 各サービスレコードにはそれぞれ 1 つのサービスの情報が書かれています。 + クライアントは SDP リクエストを出すことによって、 + SDP サーバが維持しているサービスレコードから情報を検索できます。 + クライアントまたはクライアントに関連づけられたアプリケーションがサービスを利用することにしたら、 + サービスを利用するためには、 + サービスプロバイダへの接続を別途開かなければなりません。 + SDP はサービスとそれらの属性を発見するための仕組みを提供しますが、 + そのサービスを利用するための仕組みは提供しません。 + + 通常 SDP + クライアントは希望するサービスの特性に基づいてサービスを検索します。 + しかしながら、サービスに関する事前の情報なしに、 + どのタイプのサービスが SDP + サーバのサービスレコードに記述されているか知ることが望ましいことがあります。 + この、提供されている任意のサービスを閲覧する手順を、 + ブラウジング (browsing) と呼びます。 + + 現在のところ Bluetooth SDP サーバおよびクライアントは、 + ここ + からダウンロードできる第三者パッケージ + sdp-1.5 で実装されています。 + sdptool + はコマンドラインの SDP クライアントです。 + 次の例は SDP ブラウズの問い合わせ方法を示しています。 + + &prompt.root; sdptool browse 00:80:37:29:19:a4 +Browsing 00:80:37:29:19:A4 ... +Service Name: Dial-up Networking +Protocol Descriptor List: + "L2CAP" (0x0100) + "RFCOMM" (0x0003) + Channel: 1 + +Service Name: Fax +Protocol Descriptor List: + "L2CAP" (0x0100) + "RFCOMM" (0x0003) + Channel: 2 + +Service Name: Voice gateway +Service Class ID List: + "Headset Audio Gateway" (0x1112) + "Generic Audio" (0x1203) +Protocol Descriptor List: + "L2CAP" (0x0100) + "RFCOMM" (0x0003) + Channel: 3 + + + ... 等々。 + それぞれのサービスは属性の一覧 (たとえば RFCOMM チャネル) + を持っていることに注意してください。サービスによっては、 + 属性のリストの一部についてメモをとっておく必要があるかもしれません。 + Bluetooth 実装のいくつかは、サービスブラウジングに対応しておらず、 + 空の一覧を返してくるかもしれません。この場合、 + 特定のサービスを検索をすることは可能です。下記の例は + OBEX オブジェクトプッシュ (OPUSH) + サービスを検索する方法です。 + + &prompt.root; sdptool search --bdaddr 00:07:e0:00:0b:ca OPUSH + + &os; 上における Bluetooth クライアントへのサービス提供は + sdpd サーバが行います。 + &prompt.root; sdpd + + sdptool は、ローカル + SDP サーバにサービスを登録するのにも用いられます。 + 下記の例は PPP (LAN) + サービスを備えたネットワークアクセスを登録する方法を示しています。 + 一部のサービスでは属性 (たとえば RFCOMM チャネル) + を要求することに注意してください。 + + &prompt.root; sdptool add --channel=7 LAN + + ローカル SDP サーバに登録されたサービスの一覧は SDP + ブラウザの問い合わせを 特別な BD_ADDR + に送ることで得られます。 + + &prompt.root; sdptool browse ff:ff:ff:00:00:00 + + + + ダイアルアップネットワーク (DUN) および PPP (LAN) + を用いたネットワークアクセスプロファイル + + ダイアルアップネットワーク (DUN) プロファイルはほとんどの場合、 + モデムや携帯電話とともに使用されます。 + このプロファイルが対象とする場面は以下のものです。 + + + コンピュータから携帯電話またはモデムを、 + ダイアルアップインターネットアクセスサーバへの接続、 + または他のダイアルアップサービスを利用するための無線モデムとして使うこと + + データ呼び出しを受けるための、 + コンピュータによる携帯電話またはモデムの使用 + + + PPP (LAN) によるネットワークアクセスプロファイルは、 + 次の状況で利用できます。 + + + 単一の Bluetooth デバイスへの LAN アクセス + + + マルチ Bluetooth デバイスへの LAN アクセス + + + (シリアルケーブルエミュレーション上の PPP + ネットワーク接続を使用した) PC から PC への接続 + + + &os; ではどちらのプロファイルも &man.ppp.8; と + &man.rfcomm.pppd.8; (RFCOMM Bluetooth 接続を + PPP が制御可能なように変換するラッパ) で実装されています。 + いずれかのプロファイルが使用可能となる前に、 + /etc/ppp/ppp.conf 内に新しい + PPP ラベルが作成されていなければなりません。 + 例については、 &man.rfcomm.pppd.8; + のマニュアルページを参照してください。 + + 次の例では、DUN RFCOMM チャネル上で + BD_ADDR が 00:80:37:29:19:a4 のリモートデバイスへの RFCOMM + 接続を開くのに &man.rfcomm.pppd.8; が使われます。実際の RFCOMM + チャネル番号は SDP を介してリモートデバイスから得ます。 + 手動で RFCOMM チャネルを指定することもでき、その場合 + &man.rfcomm.pppd.8; は SDP 問い合わせを実行しません。 + リモートデバイス上の RFCOMM チャネルを見つけるには、 + sdptool を使ってください。 + + &prompt.root; rfcomm_pppd -a 00:80:37:29:19:a4 -c -C dun -l rfcomm-dialup + + PPP (LAN) サービスでネットワークアクセスを提供するためには、 + sdpd サーバが動いていなければなりません。 + これはローカル SDP サーバに LAN サービスを登録するのにも必要です。 + LAN サービスは RFCOMM チャネル属性を必要とすることに注意してください。 + /etc/ppp/ppp.conf ファイル内に + LAN クライアントの新しいエントリを作成しなければなりません。 + 例については &man.rfcomm.pppd.8; のマニュアルページを参照してください。 + 最後に、RFCOMM PPP サーバが実行され、 + ローカル SDP サーバに登録されているのと同じ + RFCOMM チャネルで待ち受けていなければなりません。 + 次の例は RFCOMM PPP サーバを起動する方法を示しています。 + + &prompt.root; rfcomm_pppd -s -C 7 -l rfcomm-server + + + + OBEX プッシュ (OPUSH) プロファイル + OBEX + + OBEX はモバイルデバイス間で広く使われている単純なファイル転送プロトコルです。 + これは主に赤外線通信で利用されており、ノートパソコンや + PDA 間の汎用的なファイル転送、および + PIM アプリケーションを搭載した携帯電話その他のデバイス間で名刺やカレンダーエントリを転送するのに用いられます。 + + OBEX サーバおよびクライアントは、 + ここ + からダウンロードできる obexapp-1.0 + という第三者のパッケージとして実装されています。 + このパッケージは openobex ライブラリ + (上記の obexapp に含まれます) および + devel/glib12 port を必要とします。 + なお、obexapp + はルート権限を必要としません。 + + OBEX クライアントは OBEX + サーバとの間でオブジェクトを渡したり (プッシュ) + および受け取ったり (プル) するのに使用されます。 + オブジェクトは、たとえば名刺や予定などになります。 + OBEX クライアントは RFCOMM チャネル番号を + SDP によってリモートデバイスから得ることができます。 + これは RFCOMM チャネル番号の代わりにサービス名を指定することによって行うことができます。 + 対応しているサービス名は IrMC, FTRN および OPUSH です。 + RFCOMM チャネルを番号で指定することもできます。 + 下記は、デバイス情報オブジェクトを携帯電話から受け取り、 + 新しいオブジェクト (名刺) が携帯電話に渡される場合の + OBEX セッションの例です。 + + &prompt.user; obexapp -a 00:80:37:29:19:a4 -C IrMC +obex> get +get: remote file> telecom/devinfo.txt +get: local file> devinfo-t39.txt +Success, response: OK, Success (0x20) +obex> put +put: local file> new.vcf +put: remote file> new.vcf +Success, response: OK, Success (0x20) +obex> di +Success, response: OK, Success (0x20) + + OBEX プッシュサービスを提供するためには、 + sdpd サーバが実行されていなければなりません。 + また OPUSH サービスをローカル SDP サーバに登録することも必要です。 + なお、OPUSH サービスには RFCOMM チャネル属性が必要です。 + 渡されるオブジェクトをすべて格納するルートフォルダを作成しなければいけません。 + ルートフォルダのデフォルトパスは + /var/spool/obex です。 + 最後に OBEX サーバが実行され、 + ローカル SDP サーバに登録されているのと同じ + RFCOMM チャネルで待ち受けていなければなりません。 + 下記の例は OBEX サーバの起動方法を示します。 + + &prompt.root; obexapp -s -C 10 + + + + シリアルポート (SP) プロファイル + シリアルポート (SP) プロファイルは Bluetooth デバイスが RS232 + (または同様の) シリアルケーブルエミュレーションを行えるようにします。 + このプロファイルが対象とする場面は、 + レガシーアプリケーションが、仮想シリアルポート抽象を介して + Bluetooth をケーブルの代替品として使うところです。 + + &man.rfcomm.sppd.1; + ユーティリティはシリアルポートプロファイルを実装します。 + Pseudo tty が仮想シリアルポート抽象概念として用いられます。 + 下記の例はリモートデバイスのシリアルポートサービスへ接続する方法を示します。 + なお、RFCOMM チャネルを指定する必要はありません。— + &man.rfcomm.sppd.1; は + SDP を介してリモートデバイスからその情報を得ることができます。 + これを上書きしたい場合にはコマンドラインで + RFCOMM チャネルを指定してください。 + + &prompt.root; rfcomm_sppd -a 00:07:E0:00:0B:CA -t /dev/ttyp6 +rfcomm_sppd[94692]: Starting on /dev/ttyp6... + + 接続された pseudo tty はシリアルポートとして利用することができます。 + + &prompt.root; cu -l ttyp6 + + + + トラブルシューティング - IP サブネットを作成し、 それらのセグメントをルータを - 使って接続したりせずに、 (Ethernet セグメントのような) - 物理ネットワークを二つのネットワークセグメントに分割することは - とても有効な場合があります。 - このような二つのネットワークを繋ぐデバイスはブリッジと呼ばれます。 - そして、 二つのネットワークインタフェイスカードを持つ FreeBSD - システムは、 ブリッジとして動作することができます。 + + リモートデバイスが接続できません + 古い Bluetooth + デバイスのなかにはロールスイッチング (role switching) + に対応していないものがあります。 + デフォルトでは &os; が新しい接続を受け付けるときに、 + ロールスイッチを実行してマスタになろうとします。 + これに対応していないデバイスは接続できないでしょう。 + なお、ロールスイッチングは新しい接続が確立されるときに実行されるので、 + ロールスイッチングに対応しているかどうかリモートデバイスに問い合わせることはできません。 + ローカル側でロールスイッチングを無効にする + HCI オプションがあります。 + + &prompt.root; hccontrol -n ubt0hci write_node_role_switch 0 + + + + 何かがうまくいっていないみたいです。何が実際に起こっているか確認できますか? + できます。 + ここ + からダウンロードできる第三者パッケージ + hcidump-1.5 を使ってください。 + hcidump ユーティリティは + &man.tcpdump.1; と似ています。 + これはターミナル上の Bluetooth パケットの内容の表示および + Bluetooth パケットをファイルにダンプするのに使えます。 + + + - ブリッジは、 各ネットワークインタフェイスに繋がる - デバイスの MAC 層のアドレス (例えば Ethernet アドレス) - を記憶します。 - ブリッジはトラフィックの送信元と受信先が異なったネットワーク上に - ある場合にのみ、 トラフィックを転送します。 + + + + + Steve + Peterson + 原作: + + + + ブリッジ - すなわち、 ブリッジはポート数の少ない Ethernet スイッチ - だ、 ということができます。 + + はじめに + IP サブネット + ブリッジ + IP サブネットを作成して、 + それらのセグメントをルータを使って接続することなしに、 + (Ethernet セグメントのような) + 一つの物理ネットワークを二つのネットワークセグメントに分割することはとても有効な場合があります。この方法で二つのネットワークを繋ぐデバイスは + ブリッジ と呼ばれます。 + 二つのネットワークインタフェースカードを持つ FreeBSD + システムは、ブリッジとして動作することができます。 + + ブリッジは、各ネットワークインタフェイスに繋がるデバイスの + MAC 層のアドレス (Ethernet アドレス) を記憶することにより動作します。 + ブリッジはトラフィックの送信元と受信先が異なったネットワーク上にある場合にのみトラフィックを転送します。 + + 多くの点で、ブリッジはポート数の少ない Ethernet + スイッチのようなものといえます。 - ブリッジがふさわしい状況とは + ブリッジがふさわしい状況 今日ブリッジが活躍する場面は大きく分けて二つあります。 トラフィックの激しいセグメント - ひとつは、 物理ネットワークセグメントがトラフィック - 過剰になっているが、 なんらかの理由によりネットワークを - サブネットに分け、 ルータで接続することができない場合です。 + ひとつは、 + 物理ネットワークセグメントがトラフィック過剰になっているが、 + なんらかの理由によりネットワークをサブネットに分け、 + ルータで接続することができない場合です。 - 編集部門と製作部門がおなじサブネットに同居している - 新聞社を例に考えてみましょう。 + 編集部門と製作部門がおなじサブネットに同居している新聞社を例に考えてみましょう。 編集部門のユーザはファイルサーバとして全員サーバ A を利用し、 製作部門のユーザはサーバ B を利用します。 すべてのユーザを接続するのには Ethernet が使われており、 高負荷となったネットワークは遅くなってしまいます。 - もし編集部門のユーザを一つのネットワークセグメントに - 分離することができ、 製作部門もユーザも同様にできるのなら、 + もし編集部門のユーザを一つのネットワークセグメントに分離することができ、 + 製作部門のユーザも同様にできるのなら、 二つのネットワークセグメントをブリッジで繋ぐことができます。 - ブリッジの "反対" 側へ向かうネットワークトラフィックだけが - 転送され、 各ネットワークセグメントの混雑は緩和されます。 + ブリッジの 反対 + 側へ向かうネットワークトラフィックだけが転送され、 + 各ネットワークセグメントの混雑は緩和されます。 パケットフィルタ/帯域制御用ファイアウォール + ファイアウォール + IP マスカレード - もうひとつは、 IP Masquerading (NAT) を使わずに - ファイアウォール機能を利用したい場合です。 + もうひとつは IP マスカレード (NAT) + を使わずにファイアウォール機能を利用したい場合です。 - ここでは DSL もしくは ISDN で ISP に接続している - 小さな会社を例にとってみましょう。 - この会社は ISP から 13 個のグローバル IP アドレスの割り当て - を受けており、 ネットワーク内には 10 台の PC が存在します。 - このような状況では、 サブネット化にまつわる問題から + ここでは DSL もしくは ISDN で + ISP に接続している小さな会社を例にとってみましょう。 + この会社は ISP からグローバル IP アドレスを + 13 個割り当てられており、ネットワーク上には 10 台の PC が存在します。 + このような状況では、サブネット化にまつわる問題から、 ルータを用いたファイアウォールを利用することは困難です。 + ルータ + DSL + ISDN ブリッジを用いたファイアウォールなら、 - IP アドレスの問題を気にすること無く、 DSL/ISDN ルータの - 下流側に置くように設定できます。 + IP アドレスの問題を気にすること無く、 + DSL/ISDN ルータの下流側に置くように設定できます。 @@ -459,23 +1676,26 @@ Local1 (10.20.30.1, 10.9.9.30) --> T1-GW (10.9.9.1) ブリッジを設定する - ネットワークインタフェイスカードの選択 + ネットワークインタフェースカードの選択 - ブリッジを利用するには少なくとも二つのネットワークカードが - 必要です。 - 残念なことに、 FreeBSD 4.0 ではすべてのネットワークインタフェイス - カードがブリッジ機能をサポートしているわけではありません。 - カードがサポートされているかどうかについては &man.bridge.4; + ブリッジを利用するには少なくとも二つのネットワークカードが必要です。 + 残念なことに FreeBSD 4.0 + ではすべてのネットワークインタフェースカードがブリッジ機能に対応しているわけではありません。 + カードに対応しているかどうかについては &man.bridge.4; を参照してください。 - 以下に進む前に、 二つのネットワークカードをインストールして - テストしてください。 + 以下に進む前に、 + 二枚のネットワークカードをインストールしてテストしてください。 カーネルコンフィグレーションの変更 + + カーネルオプション + options BRIDGE + - カーネルでブリッジ機能を有効にするには + カーネルでブリッジ機能を有効にするには: options BRIDGE @@ -484,22 +1704,20 @@ Local1 (10.20.30.1, 10.9.9.30) --> T1-GW (10.9.9.1) - ファイアウォール機能 - - ブリッジと同時にファイアウォール機能も利用しようとしている - 場合には、 IPFIREWALL オプションも指定する必要があります。 - ブリッジをファイアウォールとして設定する際の一般的な - 情報に関しては、 - を参照してください。 - - IP 以外のパケット (ARP など) がブリッジを通過するように - するためには、 ドキュメント化されていないファイアウォール用 - オプションを設定する必要があります。 このオプションは - IPFIREWALL_DEFAULT_TO_ACCEPT です。 - この変更により、 デフォルトではファイアウォールがすべての - パケットを accept するようになることに注意してください。 - この設定を行う前に、 この変更が自分のルールセットにどのような - 影響をおよぼすかを把握しておかなければなりません。 + ファイアウォール対応 + ファイアウォール + ファイアウォールとしてブリッジを利用しようとしている場合には + IPFIREWALL オプションも指定する必要があります。 + ブリッジをファイアウォールとして設定する際の一般的な情報に関しては、 + を参照してください。 + + IP 以外のパケット (ARP など) + がブリッジを通過するようにするためには、 + 文書化されていないファイアウォール用オプションを設定する必要があります。 + このオプションは IPFIREWALL_DEFAULT_TO_ACCEPT + です。この変更により、 + デフォルトではファイアウォールがすべてのパケットを受け入れるようになることに注意してください。この設定を行う前に、 + この変更が自分のルールセットにどのような影響をおよぼすかを把握しておかなければなりません。 @@ -508,8 +1726,7 @@ Local1 (10.20.30.1, 10.9.9.30) --> T1-GW (10.9.9.1) ブリッジで帯域制御機能を利用したい場合、 カーネルコンフィグレーションで DUMMYNET オプションを加える必要があります。 - 詳しい情報に関しては &man.dummynet.4; を参照 - してください。 + 詳しい情報に関しては &man.dummynet.4; を参照してください。 @@ -517,818 +1734,1310 @@ Local1 (10.20.30.1, 10.9.9.30) --> T1-GW (10.9.9.1) ブリッジを有効にする ブリッジを有効にするには、 - /etc/sysctl.conf に以下の行を加えてください: + /etc/sysctl.conf に以下の行を加えてください。 net.link.ether.bridge=1 - ブリッジを経由したパケットを ipfw でフィルタしたい場合には、 - - - net.link.ether.bridge_ipfw=1 + 指定したインタフェースでブリッジを可能にするには以下を加えてください。 - という行も付け加える必要があります。 - + net.link.ether.bridge_cfg=if1,if2 - - パフォーマンス + (if1 および + if2 + は二つのネットワークインタフェースの名前に置き換えてください)。 + ブリッジを経由したパケットを &man.ipfw.8 でフィルタしたい場合には、 + 以下の行も付け加える必要があります - 私のブリッジ/ファイアウォールは Pentium 90 で、 - 3Com 3C900B と 3c905B を使っています。 - 防護される側のネットワークは 10Mbps の half duplex で、 - ブリッジとルータ (Cisco 675) の間は 100Mbps full duplex で - 動作しています。 - パケットフィルタを利用しない場合、 防護されている 10Mbps - ネットワークから Cisco 675 への ping では、 - ブリッジにより 0.4 ミリ秒の遅延が発生しています。 + net.link.ether.bridge_ipfw=1 その他の情報 + ネットワークからブリッジに telnet したい場合、 ネットワークカードの一つに IP アドレスを割り当てれば OK です。 - 一般的に、 両方のカードに IP アドレスを割り当てるのは - よいアイデアではないとされています。 + 一般的に、両方のカードに + IP アドレスを割り当てるのはよい考えではないとされています。 ネットワーク内に複数のブリッジを設置する場合、 - 任意のワークステーション間で一つ以上の経路を持つことは - できません。 技術的には、 これは spanning tree link management - はサポートされていない、 ということを意味します。 + 任意のワークステーション間で一つ以上の経路を持つことはできません。 + 技術的には、 + これはスパニングツリーのリンク制御はサポートされていない、 + ということを意味します。 + + ブリッジは、ping にかかる時間を遅らせることがあります。特に、 + 一方のセグメントからもう一方へのトラフィックでそうなります。 - + + + + + Tom + Rhodes + 追記と再編成: + + + + + Bill + Swingle + 原作: + + + NFS - Written by &a.unfurl;, 4 March 2000. + NFS - FreeBSD がサポートしている多くのファイルシステムの中でも、 - NFS、 すなわち Network File System は極めてユニークな存在です。 - NFS はあるマシンから他のマシンへと、 ネットワークを通じて - ディレクトリとファイルを共有することを可能にします。 - NFS を使うことで、 ユーザやプログラムはリモートシステムのファイルを、 + FreeBSD がサポートしている多くのファイルシステムの中には、 + NFS + とも呼ばれているネットワークファイルシステムがあります。 + NFS はあるマシンから他のマシンへと、 + ネットワークを通じてディレクトリとファイルを共有することを可能にします。 + NFS を使うことで、 + ユーザやプログラムはリモートシステムのファイルを、 それがローカルファイルであるかのようにアクセスすることができます。 - NFS には以下の利点があります: + NFS が提供可能な最も特筆すべき利点のいくつかを以下にあげます。 - 一般的に使われるデータを単一のマシンに納める - ことができ、 ネットワーク上のユーザはデータにアクセスできる - ため、 ローカルワークステーションは多くのディクスを - 必要としません。 + 一般的に使われるデータを単一のマシンに納めることができ、 + ユーザはネットワークを通じてデータにアクセスできるため、 + ローカルワークステーションが使用するディスク容量が減ります。 ネットワーク上のすべてのマシンに、 - ユーザが独自のホームディレクトリを持つ必要がありません。 - 一旦 NFS 経由でアクセスできるディレクトリができれば、 - どこからでもアクセス可能です。 + ユーザが別々にホームディレクトリを持つ必要がありません。 + NFS サーバ上にホームディレクトリが設定されれば、 + ネットワークのどこからでもアクセス可能です。 - フロッピーや CD-ROM ドライブなどのストレージデバイスを、 - 追加のハードウェアなしにネットワーク上の他のマシンに - 使ってもらうことができます。 + フロッピーディスクや CDROM ドライブ、 + ZIP ドライブなどのストレージデバイスを、 + ネットワーク上の他のマシンで利用することができます。 + ネットワーク全体のリムーバブルドライブの数を減らせるかもしれません。 - どのようにして動作するのか + <acronym>NFS</acronym> はどのように動作するのか - NFS はクライアント、 サーバの二つの部分から - 構成されます。 - これは 需要(want)/供給(have) の関係として考えることができます。 - クライアントはサーバが 供給 している - データに対する 需要 があります。 - サーバはそのデータをクライアントと共有します。 - このシステムが適切に機能するために、 いくつかのプロセスが - 設定され正しく動作していなければなりません。 - - サーバは以下のデーモンを動作させなければなりません: - - - - nfsd - NFS クライアントからの - リクエストを処理する NFS デーモン。 - + NFS は最低二つの主要な部分、 + サーバと一つ以上のクライアントからなります。 + クライアントはサーバマシン上に格納されたデータにリモートからアクセスします。 + これが適切に機能するには、 + いくつかのプロセスが設定されて実行されていなければなりません。 - - mountd - nfsd から渡された - リクエストを実際に実行する NFS マウントデーモン。 - + &os; 5.X では portmap ユーティリティは + rpcbind ユーティリティに置き換わりました。 + したがって &os; 5.X では、ユーザは下記の例で、 + portmap の例のすべてを + rpcbind に置き換える必要があります。 - - portmap - NFS サーバの利用しているポートを - NFS クライアントから取得できるようにするためのポートマッパデーモン。 - - + サーバは以下のデーモンを動作させなければなりません: + + NFS + サーバ + + + portmap + + + mountd + + + nfsd + - クライアント側ではデーモンを一つ実行する必要があります: + + + + + デーモン + 説明 + + + + + nfsd + NFS + クライアントからのリクエストを処理する + NFS デーモン + + + mountd + &man.nfsd.8; から渡されたリクエストを実際に実行する + NFS マウントデーモン + + + portmap + NFS サーバの利用しているポートを + NFS + クライアントから取得できるようにするためのポートマッパデーモン + + + + - - - nfsiod - NFS サーバからのリクエストを - 処理する NFS 非同期 I/O デーモン。 - - + クライアント側では nfsiod + というデーモンも実行できます。 + nfsiod デーモンは NFS + サーバからのリクエストを処理します。 + これは任意であり、性能を改善しますが、 + 通常の正しい動作には必要としません。詳細については &man.nfsiod.8; + マニュアルページを参照してください。 - - NFS を設定する + + <acronym>NFS</acronym> の設定 + + NFS + 設定 + - 幸運なことに、 FreeBSD システムで設定を行うのは簡単です。 - 実行させなければならないプロセスは、 /etc/rc.conf - ファイルをちょっと編集することでブート時から実行させる - ことができます。 + NFS の設定は比較的素直な工程です。 + 動かさなければならないプロセスは /etc/rc.conf + ファイルを少し変更すれば起動時に実行させられます。 - NFS サーバでは、 以下の設定が必要です: + NFS サーバでは + /etc/rc.conf ファイルの中で、 + 以下のオプションが設定されていることを確かめてください。 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; - マニュアルページをお読み下さい。 + mountd は + NFS サーバが有効になっていれば、 + 自動的に実行されます。 + + クライアント側では /etc/rc.conf + 内に以下の設定があることを確認してください。 + + nfs_client_enable="YES" + + /etc/exports ファイルは NFS + サーバがどのファイルシステムをエクスポート + (ときどき 共有 と呼ばれます) するのかを指定します。 + /etc/exports ファイル中の各行は、 + エクスポートするファイルシステム、 + およびそのファイルシステムにアクセスできるマシンを指定します。 + ファイルシステムにアクセスできるマシンとともに、 + アクセスオプションも指定できます。 + このファイルで指定できるオプションはたくさんありますが、 + ここではほんの少しだけ言及します。&man.exports.5; + マニュアルページを読めば、 + 他のオプションは簡単にみつけられるでしょう。 - いくつか /etc/exports の設定例 - を示します: - - 以下の設定は、 - サーバと同じドメイン名(ドメイン名が無いので)か、 - /etc/hosts に記述のある三つのマシン - に対して、 /cdrom を export します。 - オプションは共有されるファイルシステムを - 読み込み専用にします。 - このフラグにより、 リモートシステムは共有されたファイルシステム - にたいして何の変更も行えなくなります。 - - /cdrom -ro moe larry curly - - 以下の設定は、 IP アドレスによる三つのホストに対して - /home を export します。 - この設定はプライベートネットワークで DNS が走っていない - 場合に便利な設定でしょう。 - フラグは指定されたファイルシステム - 以下のディレクトリに対しても同様に export します。 + いくつか /etc/exports の設定例を示します。 + + + NFS + エクスポートの例 + + 以下の例はファイルシステムのエクスポートの考え方を示しますが、 + あなたの環境とネットワーク設定に応じて設定は少し変わるでしょう。 + たとえば次の行は /cdrom + ディレクトリを、サーバと同じドメイン名か + (そのため、いずれもドメイン名がありません)、 + /etc/hosts + に記述されている三つの例となるマシンに対してエクスポートします。 + + フラグは共有されるファイルシステムを読み込み専用にします。 + このフラグにより、 + リモートシステムは共有されたファイルシステムに対して何の変更も行えなくなります。 + + /cdrom -ro host1 host2 host3 + + 以下の設定は IP アドレスで指定した 3 つのホストに対して + /home をエクスポートします。 + この設定はプライベートネットワークで + DNS が設定されていない場合に便利でしょう。 + 内部のホスト名に対して /etc/hosts + を設定するという手段もあります。 + 詳細については &man.hosts.5; を参照してください。 + + フラグはサブディレクトリがマウントポイントとなることを認めます。 + 言い替えると、これはサブディレクトリをマウントしませんが、 + クライアントが要求するか、 + または必要とするディレクトリだけをマウントできるようにします。 /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 されたファイルシステムを共有 - する際には、 そのような権限が与えられていなければなりません。 + 以下の設定は、サーバとは異なるドメイン名の + 2 台のクライアントがアクセスできるように + /a をエクスポートします。 + フラグは、リモートシステムの + root ユーザが、 + エクスポートされたファイルシステムに root + として書き込むことを許可します。 + -maproot=root フラグが無ければ、 + リモートマシンの root 権限を持っていても、 + 共有されたファイルシステム上のファイルを変更することはできないでしょう。 + + /a -maproot=root host.example.com box.example.org + + クライアントがエクスポートされたファイルシステムにアクセスするためには、 + そうする権限が与えられていなければなりません。 /etc/exports ファイルに クライアントが含まれているかどうか確認してください。 - - 必要な変更はすべて行ったので、 - FreeBSD を再起動してブート時からすべてが起動するようにするか、 - root で以下のコマンドを実行します: - - NFS サーバでは: + /etc/exports ファイルでは、 + それぞれの行が一つのファイルシステムを一つのホストにエクスポートすることを表します。 + リモートホストはファイルシステム毎に一度だけ指定することができ、 + それに加えて一つのデフォルトエントリを置けます。たとえば + /usr が単一のファイルシステムであると仮定します。 + 次の /etc/exports は無効です。 + + /usr/src client +/usr/ports client + + 単一のファイルシステムである /usr + は、2 行に渡って、同じホスト client + へエクスポートされています。 + この場合、正しい書式は次のとおりです。 + + /usr/src /usr/ports client + + あるホストにエクスポートされるある + 1 つのファイルシステムのプロパティは、 + 1 行ですべて指定しなければなりません。 + クライアントの指定のない行は、単一のホストとして扱われます。 + これはファイルシステムをエクスポートできる方法を制限しますが、 + 多くの場合これは問題になりません。 + + 下記は、 + /usr および /exports + がローカルファイルシステムである場合の、 + 有効なエクスポートリストの例です。 + + # Export src and ports to client01 and client02, but only +# client01 has root privileges on it +/usr/src /usr/ports -maproot=root client01 +/usr/src /usr/ports client02 +# The client machines have root and can mount anywhere +# on /exports. Anyone in the world can mount /exports/obj read-only +/exports -alldirs -maproot=root client01 client02 +/exports/obj -ro + + 変更が有効となるように、 + /etc/exports が変更されたら + mountd を再起動しなければなりません。 + これは mountd + プロセスに HUP シグナルを送ることで実行できます。 + + &prompt.root; kill -HUP `cat /var/run/mountd.pid` + + 他には、再起動すれば、FreeBSD はすべてを適切に設定します。 + しかしながら、再起動は必須ではありません。 + root + 権限で以下のコマンドを実行すれば、すべてが起動するでしょう。 + + NFS サーバでは: &prompt.root; portmap &prompt.root; nfsd -u -t -n 4 &prompt.root; mountd -r - NFS クライアントでは: + NFS クライアントでは: &prompt.root; nfsiod -n 4 - これでリモートのファイルシステムを実際にマウントする - 準備ができました。 - やり方は二通りあります。 - この例では、 サーバの名前は server で、 + これでリモートのファイルシステムを実際にマウントする準備がすべてできました。 + この例では、サーバの名前は server で、 クライアントの名前は client とします。 リモートファイルシステムを一時的にマウントするだけ、 - もしくは設定をテストするだけなら、 クライアント上で root - として以下のコマンドを実行してください: - + もしくは設定をテストするだけなら、クライアント上で + root + 権限で以下のコマンドを実行するだけです。 + + NFS + マウント + &prompt.root; mount server:/home /mnt - これにより、 クライアントの /mnt - ディレクトリにサーバの /home が - マウントされます。 - もしすべてが正しく設定されていれば、 クライアントの /mnt - に、 サーバにあるファイルすべてが見えるようになっているはずです。 + これで、サーバの /home + ディレクトリが、クライアントの /mnt + にマウントされます。もしすべてが正しく設定されていれば、 + クライアントの /mnt に入り、 + サーバにあるファイルすべてを見れるはずです。 - リモートファイルシステムを今後も (リブートする度に) - マウントしたいなら、 /etc/fstab - ファイルに設定を追加する必要があります。 - 例としてはこのようになります: + リモートファイルシステムを起動のたびに自動的にマウントしたいなら、 + ファイルシステムを /etc/fstab + ファイルに追加してください。 + 例としてはこのようになります。 server:/home /mnt nfs rw 0 0 - ほかのオプションに関しては &man.fstab.5; マニュアル - ページをお読み下さい。 + &man.fstab.5; + マニュアルページに利用可能なオプションがすべて掲載されています。 - 典型的な使い方 + 実用的な使い方 - NFS にはいくつかすてきな使い方があります。 - 私は自分が管理している LAN でそれらを利用しています。 - そのうちにいくつかをここで紹介しましょう。 + NFS には実用的な使用法がいくつもあります。 + ここで典型的な使用法をいくつか紹介しましょう。 - ネットワークには幾つかのマシンがありますが、 - CD-ROM ドライブを持っているのは一台だけです。 - なぜかって? それは一台の CD-ROM ドライブをほかのマシンと - NFS 経由で共有しているからです。 - フロッピードライブについても同じことがいえます。 - - ネットワーク内に多くのマシンがあると、 様々な場所に - ちらばる個人的なファイルは日に日に古くなってしまいます。 - 私はすべてのユーザのホームディレクトリを格納する、 - 中心となる NFS サーバを用意し、 LAN 上の残りのマシンと - 共有しています。 そうすることで、 どこにログインしても、 - 同じホームディレクトリを使うことができるのです。 + + NFS + 使用法 + + + + 何台ものマシンで CDROM + などのメディアを共有するように設定します。 + これは安上がりで、たいていは、 + 複数のマシンにソフトウェアをインストールするのにより便利な方法です。 + - マシンのひとつに FreeBSD を再インストールするなら、 - NFS こそその方法です。 ディストリビューション CD をファイル - サーバに入れ、 再インストールを実行するだけです。 + + 大規模なネットワークでは、 + すべてのユーザのホームディレクトリを格納するメイン + NFS + サーバを構築すると、ずっと便利でしょう。 + どのワークステーションにログインしても、 + ユーザがいつでも同じホームディレクトリを利用できるように、 + これらのホームディレクトリはネットワークに向けてエクスポートされます。 + - 共用の /usr/ports/distfiles - ディレクトリを用意して、 すべてのマシンで共有しています。 - この方法だと、 別のマシンで既にインストールしたことのある - port をインストールする場合、 再びすべてのソースをダウンロードする - 必要がなくなります。 + + 何台ものマシンで /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 がこの状態に陥ってしまうと、 正常に戻すことはできないため、 - 多くの場合、 クライアントを強制終了し、 - 再び実行することが唯一の解決法となります。 - + + + + + Wylie + Stilwell + 寄稿: + + + + + Chern + Lee + 再構成: + + + + <application>amd</application> による自動マウント + + amd + 自動マウントデーモン + + &man.amd.8; (自動マウントデーモン) は、 + ファイルシステム内のファイルまたはディレクトリがアクセスされると、 + 自動的にリモートファイルシステムをマウントします。 + また、一定の間アクセスされないファイルシステムは + amd + によって自動的にアンマウントされます。 + amd を使用することは、通常 + /etc/fstab + 内に記述する恒久的なマウントに対する、 + 単純な代替案となります。 + + amd はそれ自身を NFS サーバとして + /host および /net + ディレクトリに結びつけることによって動作します。 + このディレクトリ内のどこかでファイルがアクセスされると、 + amd は対応するリモートマウントを調べて、 + 自動的にそれをマウントします。 + /net が、エクスポートされたファイルシステムを + IP アドレスで指定してマウントするのに利用される一方で、 + /host + は、エクスポートされたファイルシステムをリモートホスト名で指定してマウントするのに利用されます。 + + /host/foobar/usr + 内のファイルにアクセスすると、 + amd はホスト + foobar からエクスポートされた + /usr をマウントします。 - 正しい解決法は、 - より高性能のイーサネットアダプタをFreeBSDシステムに - インストールすることですが、 - 満足な操作ができるような簡単な方法があります。 もし、 - FreeBSDシステムがサーバになるのなら、 - クライアントからのマウント時に - オプションをつけて下さい。 - もしFreeBSDシステムがクライアントになる - のなら、 NFSファイルシステムを - オプションつきでマウントして下さい。 - これらのオプションは自動的にマウントをおこなう場合には - クライアントの fstab - エントリの4番目のフィールドに指定してもよいですし、 - 手動マウントの場合は mount コマンドの - パラメータで指定してもよいでしょう。 - - NFSサーバとクライアントが別々のネットワーク上にあるような - 場合、 これと間違えやすい他の問題が起きることに注意して下さい。 - そのような場合は、 ルータが必要な UDP 情報をきちんと - ルーティングしているかを確かめて下さい。 - そうでなければ、 たとえあなたが何をしようと解決できないでしょう。 - + + <application>amd</application> + によるエクスポートされたファイルシステムのマウント + + showmount コマンドを用いて、 + リモートホストのマウントで利用できるものが見られます。 + たとえば、foobar + と名付けられたホストのマウントを見るために次のように利用できます。 + + &prompt.user; showmount -e foobar +Exports list on foobar: +/usr 10.10.10.0 +/a 10.10.10.0 +&prompt.user; cd /host/foobar/usr + - 次の例では、 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 ユニット - では保証されていません。 - 踏みつぶしが起こったとき、 - 影響を受けたユニットは再送されます。 そして受信され、 - 組み立てられ、 - 肯定応答される公平な機会が与えられるでしょう。 + 例のように showmount はエクスポートとして + /usr を表示します。 + /host/foobar/usr にディレクトリを変更すると、 + amd はホスト名 foobar + を解決し、お望みのエクスポートをマウントしようと試みます。 + + amd は + /etc/rc.conf 内に次の行を記述すれば、 + 起動スクリプトによって起動されます。 + + amd_enable="YES" + + さらに amd_flags オプションによって + amd + にフラグをカスタマイズして渡せます。デフォルトでは + amd_flags は次のように設定されています。 + + amd_flags="-a /.amd_mnt -l syslog /host /etc/amd.map /net /etc/amd.map" + + /etc/amd.map ファイルは、 + エクスポートがマウントされるデフォルトオプションを決定します。 + /etc/amd.conf ファイルは、 + amd + のより高度な機能の一部を設定します。 + + 詳細については &man.amd.8; および &man.amd.conf.5; + マニュアルページを参照してください。 - - - Diskless operation + + + + + John + Lind + 寄稿: + + + + 他のシステムとの統合についての問題 + + 訳: &a.jp.tomo;. 6 September 1996. + + ISA バス用のイーサネットアダプタの中には性能が悪いため、 + ネットワーク、特に NFS で深刻な問題がおきるものがあります。 + これは FreeBSD に限ったことではありませんが + FreeBSD でも起こり得ます。 + + この問題は (FreeBSD を使用した) PC + がシリコングラフィックス社やサン・マイクロシステムズ社などの高性能なワークステーションにネットワーク接続されている場合に頻繁に起こります。 + NFS マウントはうまく動作するでしょう。 + また、いくつかの操作もうまく動作するかもしれませんが、 + 他のシステムに対する要求や応答は続いていても、 + 突然サーバがクライアントの要求に対して応答しなくなります。これは、 + クライアントが FreeBSD + か上記のワークステーションであるときにクライアント側に起きる現象です。 + 多くのシステムでは、いったんこの問題が現われると、 + 行儀良くクライアントを終了する手段はありません。 + NFS がこの状態に陥ってしまうと正常に戻すことはできないため、 + 多くの場合クライアントをリセットすることが唯一の解決法となります。 + + 正しい解決法は、より高性能のイーサネットアダプタを + FreeBSD システムにインストールすることですが、 + 満足に動作させる簡単な方法があります。 + FreeBSD システムが サーバ になるのなら、 + クライアントからのマウント時に + オプションをつけて下さい。FreeBSD システムが + クライアント になるのなら、NFS ファイルシステムを + オプションつきでマウントして下さい。 + これらのオプションは自動的にマウントをおこなう場合には + クライアントの fstab + エントリの 4 番目のフィールドに指定してもよいですし、 + 手動マウントの場合は mount コマンドの + パラメータで指定してもよいでしょう。 + + NFS サーバとクライアントが別々のネットワーク上にあるような場合、 + これと間違えやすい他の問題が起きることに注意して下さい。 + そのような場合は、ルータが必要な + UDP 情報をきちんとルーティングしているかを確かめて下さい。 + していなければ、たとえあなたが何をしようと解決できないでしょう。 + + 次の例では fastws + は高性能ワークステーションのホスト (インタフェース) 名で、 + freebox は低性能のイーサネットアダプタを備えた + FreeBSD システムのホスト (インタフェース) 名です。 + また /sharedfs はエクスポートされる + NFS ファイルシステムであり (&man.exports.5; を参照) 、 + /project はエクスポートされたファイルシステムの、 + クライアント上のマウントポイントとなります。 + すべての場合において、アプリケーションによっては + や , + といった追加オプションがふさわしいかもしれないことに注意して下さい。 + + クライアント側 FreeBSD システム (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 は通常 + (より小さいサイズへ分割されるかもしれませんが) + 8 K の ブロック サイズで動作します。 + イーサネットのパケットサイズは最大 1500 バイト程度なので、 + 上位階層のコードにとっては 1 つのユニットであって、 + NFS ブロック + は複数のイーサネットパケットに分割されるものの、 + 上位階層のコードにとっては 1 つのユニットであって、 + ユニットとして受信され、組み立て直され、 + 肯定応答 (ACK) されなければなりません。 + 高性能のワークステーションは次々に NFS ユニットを構成するパケットを、 + 標準の許す限り間隔を詰めて次々に送り出すことができます。 + 小さく、容量の低いカードでは、 + 同じユニットの前のパケットがホストに転送される前に、 + 後のパケットがそれを踏みつぶしてしまいます。 + このため全体としてのユニットは、再構成も肯定応答もできません。 + その結果、 + ワークステーションはタイムアウトして再送を試みますが、 + 8 K のユニット全体を再送しようとするので、 + このプロセスは際限無く繰り返されてしまいます。 + + ユニットサイズをイーサネットのパケットサイズの + 制限以下に抑えることにより、 + 受信した完全なイーサネットパケットについて個々に肯定応答を返せることが保証されるので、 + デッドロック状態を避けられるようになります。 + + それでも、高性能なワークステーションが力任せに次々と + PC システムにデータを送ったときには踏みつぶしが起きるかもしれません。 + しかし、高性能のカードを使っていれば、NFS ユニット + で必ずそのような踏みつぶしが起きるとは限りません。 + 踏みつぶしが起きたら、影響を受けたユニットは再送されて、 + 受信され、組み立てられ、肯定応答される十分な見込みがあります。 + + - 原作: &a.martin; + + + + + Jean-François + Dockès + 更新: + + + + ディスクレス稼働 訳: &a.jp.yasu; - netboot.com/netboot.rom - によって、 ディスクのないクライアントでネットワーク経由で - FreeBSD マシンのブートを行い FreeBSD を走らせることができます。 - 2.0 ではローカルなスワップを持つことができます。 - NFS 経由のスワッピングもサポートされています。 + ディスクレスワークステーション + ディスクレス稼働 + + FreeBSD マシンはネットワークを通じて起動でき、 + そして NFS サーバからマウントしたファイルシステムを使用して、 + ローカルディスクなしで動作することができます。 + 標準の設定ファイルを変更する以上の、システムの修正は必要ありません。 + 必要な要素のすべてが用意されているので、 + このようなシステムを設定するのは簡単です。 + + + ネットワークを通じてカーネルを読み込む方法は、 + 少なくとも二つあります。 + + + PXE: &intel; の + Preboot Execution Environment (PXE) システムは、 + 一部のネットワークカードまたはマザーボードに組み込まれた、 + スマートなブート ROM の一形態です。 + 詳細については &man.pxeboot.8; を参照してください。 + + + port の + etherboot + (net/etherboot) は、 + ネットワークを通じてカーネルを起動する ROM + 化可能なコードを提供します。 + コードはネットワークカード上のブート PROM に焼き付けるか、 + あるいはローカルフロッピー (ハード) ディスクドライブ、 + または動作している &ms-dos; システムから読み込むことができます。 + 多くのネットワークカードに対応しています。 + + + + + + サンプルスクリプト + (/usr/share/examples/diskless/clone_root) + はサーバ上で、 + ワークステーションのルートファイルシステムの作成と維持をやり易くします。 + このスクリプトは少し書き換えないといけないでしょうが、 + 早く取り掛かれるようにします。 + + + + ディスクレスシステム起動を検知しサポートする標準のシステム起動ファイルが + /etc 内にあります。 + + + + 必要なら、NFS + ファイルまたはローカルディスクのどちらかにスワップできます。 + + + + ディスクレスワークステーションを設定する方法はいろいろあります。 + 多くの要素が関わっており、 + その多くはローカルの状況に合わせてカスタマイズできます。下記は、 + 単純さと標準の FreeBSD + 起動スクリプトとの互換性を強調した完全なシステムの設定を説明します。 + 記述されているシステムの特徴は次のとおりです。 - サポートされているイーサネットカード: - Western Digital/SMC 8003, 8013, 8216 とその互換ボード, - NE1000/NE2000 とその互換カード (再コンパイルが必要) + + + ディスクレスワークステーションは、 + 共有された読み取り専用の + ルートファイルシステムと、 + 共有された読み取り専用の + /usr を使用します。 + ルート ファイルシステムは、 + 標準的な FreeBSD (典型的にはサーバの) のルートのコピーで、 + 一部の設定ファイルが、ディスクレス稼働、 + また場合によってはそのワークステーションに特有のもので上書きされています。 + 書き込み可能でなければならない ルート + の部分は &man.mfs.8; ファイルシステムで覆われます。 + システムが再起動するときにはすべての変更が失われるでしょう。 + + + カーネルは DHCP (または BOOTP) および TFTP を用いて + etherboot によって読み込まれます。 + + + + 記述されているとおり、 + このシステムは安全ではありません。 + ネットワークの保護された範囲で使用されるべきであり、 + 他のホストから信頼されてはいけません。 + セットアップの手順 - - - サーバにするマシンを見つけます。 - このマシンには、 FreeBSD 2.0のバイナリとbootpを - 記憶するだけの十分なディスクスペースが必要です。 - tftp と NFS も使えます。 + + DHCP/BOOTP の設定 + + ディスクレス稼働 + 起動 + + + ネットワークを通じて設定を取得し、 + ワークステーションを起動するために一般的に使用されるプロトコルには、 + BOOTP と DHCP の 2 つがあります。 + それらはワークステーションのブートストラップ時に何ヵ所かで使用されます。 + + etherboot + はカーネルを見つけるために DHCP (デフォルト) または + BOOTP (設定オプションが必要) を使用します + (PXE は DHCP を使用します) 。 + + NFS ルートの場所を定めるためにカーネルは + BOOTP を使用します。 + + + + BOOTP だけを使用するようにシステムを設定することもできます。 + &man.bootpd.8; サーバプログラムは + FreeBSD のベースシステムに含まれています。 + + しかしながら、DHCP には BOOTP に勝る点が多々あります。 + (よりよい設定ファイル、PXE が使えること、 + そしてディスクレス稼働には直接関係しない多くの長所) + ここでは BOOTP だけ利用する場合と、 + BOOTP と DHCP を組み合わせた設定を扱います。特に ISC DHCP + ソフトウェアパッケージを利用する後者の方法に重点をおきます。 - テストしたマシン: + + ISC DHCP を使用する設定 + + DHCP + ディスクレス稼働 + + + isc-dhcp サーバは、 + BOOTP および DHCP リクエストの両方に答えることができます。 + + 4.4-Release の時点で isc-dhcp 3.0 + はベースシステムの一部では無くなりました。 + まずはじめに + net/isc-dhcp3 port + または対応する package をインストールする必要があるでしょう。 + ports および package に関する一般的な情報については + を参照してください。 + + isc-dhcp がインストールされると、 + 動作するために設定ファイルを必要とします + (通常 /usr/local/etc/dhcpd.conf + が指定されます) 。 + 下記にコメントを含めた例を示します。 + + + default-lease-time 600; + max-lease-time 7200; + authoritative; + + option domain-name "example.com"; + option domain-name-servers 192.168.4.1; + option routers 192.168.4.1; + + subnet 192.168.4.0 netmask 255.255.255.0 { + use-host-decl-names on; + option subnet-mask 255.255.255.0; + option broadcast-address 192.168.4.255; + + host margaux { + hardware ethernet 01:23:45:67:89:ab; + fixed-address margaux.example.com; + next-server 192.168.4.4; + filename "/tftpboot/kernel.diskless"; + option root-path "192.168.4.4:/data/misc/diskless"; + } + } + + + このオプションは + host 宣言の値を、 + ディスクレスホストへのホスト名として送るように + dhcpd に指示します。 + 別の方法として、ホスト宣言内に + option host-name margaux + を加えるものがあります。 + + + TFTP サーバを + next-server ディレクティブに指定します + (デフォルトは DHCP サーバと同じホストを使います)。 + + + カーネルとして + etherboot が読み込むファイルを + filename ディレクティブに指定します。 + PXE は相対的なファイル名を好むようです。 + また、カーネルではなく pxeboot + を読み込みます + (option filename "pxeboot")。 + + + + + ルートファイルシステムへのパスを、 + 通常の NFS 書式で root-path + オプションに指定します。 + + + + + BOOTP を使用する設定 + + BOOTP + ディスクレス稼働 + + + 続けて、bootpd + で同等のことをする設定です。 + これは /etc/bootptab におきます。 + + BOOTP を使用するために、デフォルトではない + NO_DHCP_SUPPORT オプション付きで + etherboot + をコンパイルしなければならないことと、PXE は DHCP + を 必要 とすることに注意してください。 + bootpd の唯一明白な利点は、 + これがベースシステムに存在するということです。 + + + .def100:\ + :hn:ht=1:sa=192.168.4.4:vm=rfc1048:\ + :sm=255.255.255.0:\ + :ds=192.168.4.1:\ + :gw=192.168.4.1:\ + :hd="/tftpboot":\ + :bf="/kernel.diskless":\ + :rp="192.168.4.4:/data/misc/diskless": + + margaux:ha=0123456789ab:tc=.def100 + + - - - HP9000/8xx / HP-UX 9.04以降 - (9.04以前では動きません) - + + <application>Etherboot</application> + を用いるブートプログラムの準備 + + + Etherboot + + + Etherboot + のウェブサイト には主に Linux システムについて述べた + 広範囲の文書 + が含まれています。 + しかし、それにもかかわらず有用な情報を含んでいます。 + 下記は FreeBSD システム上での etherboot + の使用法についての概観を示します。 + + まずはじめに net/etherboot + の package または port をインストールしなければなりません。 + etherboot port は通常 + /usr/ports/net/etherboot にあります。 + ports ツリーがシステムにインストールされている場合、 + このディレクトリ内で make + を実行すれば、よきに計らってくれます。 + ports および packages に関する情報は + を参照してください。 - - 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 - - また、 スワッピングが開始されるとクライアントの - スワップスペースはセンシティブな情報を含むようになるので、 - 不正なアクセスを防止するため、 このファイルへの - 読み書きのアクセス制限がなされていることを確認して下さい: - + ここで説明している方法では、ブートフロッピーを使用します。 + 他の方法 (PROM または DOS プログラム) については + etherboot + の文書を参照してください。 + + ブートフロッピーを作成するためには、 + etherboot + をインストールしたマシンのドライブにフロッピーディスクを挿入します。 + それからカレントディレクトリを etherboot + ツリー内の src + ディレクトリにして次のように入力します。 + + + &prompt.root; gmake bin32/devicetype.fd0 + + + devicetype は + ディスクレスワークステーションのイーサネットカードタイプに依存します。 + 正しい devicetype を決定するために、 + 同じディレクトリ内の NIC + ファイルを参照してください。 + - &prompt.root; chmod 0600 /swapfs/swap.192.1.2.4 - + + TFTP および NFS サーバの設定 + + + TFTP + ディスクレス稼働 + + + NFS + ディスクレス稼働 + + + TFTP サーバ上で tftpd + を有効にする必要があります。 + + + tftpd が提供するファイルを置くディレクトリ + (たとえば /tftpboot) + を作成してください。 + + + + /etc/inetd.conf + ファイルに以下の行を追加してください。 + + tftp dgram udp wait root /usr/libexec/tftpd tftpd -s /tftpboot + + 少なくとも PXE のいくつかのバージョンが TCP 版の + TFTP を要求するようです。その場合 + dgram udp を stream tcp + に置き換えた 2 番目の行を追加してください。 + + + + inetd + に設定ファイルを再読み込みさせてください。 + &prompt.root; kill -HUP `cat /var/run/inetd.pid` + + + + tftpboot + ディレクトリはサーバ上のどこにでも置けます。 + その場所が inetd.conf および + dhcpd.conf + の両方に設定されていることを確かめてください。 + + さらに NFS を有効にして + NFS サーバの適切なファイルシステムをエクスポートする必要があります。 + + + + この行を /etc/rc.conf + に追加してください。 + nfs_server_enable="YES" + + + + 下記を /etc/exports に加えることで、 + ディスクレスマシンのルートディレクトリが位置するファイルシステムをエクスポートしてください + (ボリュームのマウントポイントを適当に調節し、 + margaux + をディスクレスワークステーションの名前に置き換えてください)。 + + /data/misc -alldirs -ro margaux + + + mountd + に設定ファイルを再読み込みさせてください。 + /etc/rc.conf 内で NFS + をはじめて有効にする必要があったのなら、 + 代わりに再起動した方がよいかもしれません。 + &prompt.root; kill -HUP `cat /var/run/mountd.pid` + + + - - クライアントがそれぞれの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を作成します。 - - - + + options BOOTP # Use BOOTP to obtain IP address/hostname + options BOOTP_NFSROOT # NFS mount root filesystem using BOOTP info + options BOOTP_COMPAT # Workaround for broken bootp daemons. - - <filename>/</filename> および <filename>/usr</filename> - ファイルシステムを共有して使用する + BOOTP_NFSV3 および + BOOTP_WIRED_TO を利用してもよいかもしれません + (LINT を参照してください)。 - 今のところ、 これを行う公式に認められた方法はありませんが、 - 私はそれぞれのクライアントで /usr - ファイルシステムと個々の / - ファイルシステムを共有して使っています。 - どなたかこれをきちんと行うやり方の提案がありましたら、 - 私に、 もしくは &a.core; グループに知らせてください。 - + カーネルを構築して ( を参照)、 + dhcpd.conf に記述した名称で + tftp ディレクトリにコピーしてください。 + - - 特定の設定についてnetbootをコンパイルする + + ルートファイルシステムの準備 + + + ルートファイルシステム + ディスクレス稼働 + + + dhcpd.conf に + root-path として記載された + ディスクレスワークステーションのためのルートファイルシステムを作成する必要があります。 + + これを行う最も簡単な方法は + /usr/share/examples/diskless/clone_root + シェルスクリプトを使用することです。 + このスクリプトは、少なくともファイルシステムが作成される場所 + (DEST 変数) + を調節するために変更する必要があります。 + + 説明についてはスクリプトの一番上にあるコメントを参照してください。 + ベースシステムをどのように構築するか、 + またファイルがどのようにディスクレス稼働、サブネット、 + または個々のワークステーションに固有のバージョンによって、 + 選択的にオーバライドできるかを説明します。 + また、ディスクレスな場合の + /etc/fstab ファイルおよび + /etc/rc.conf ファイルの例を示します。 + + /usr/share/examples/diskless + 内の README + ファイルには、多くの興味深い背景情報が書かれています。 + しかし diskless ディレクトリ内の他の例と同じく、 + clone_root と + /etc/rc.diskless[12] + で実際に使われているものとは異なる設定方法が説明されています。 + ここに書かれている方法は + rc スクリプトの変更が必要になりますが、 + こちらの方が気に入ったというのでなければ、 + 参照にとどめてください。 + + + + スワップの設定 + + 必要なら、サーバに置かれたスワップファイルに + NFS 経由でアクセスできます。 + bootptab または + dhcpd.conf の正確なオプションは、 + 現時点では明確には文書化されていません。 + 下記の設定例は isc-dhcp 3.0rc11 + を使用して動作したと報告されているものです。 + + dhcpd.conf + に下記の行を追加してください。 + + # Global section + option swap-path code 128 = string; + option swap-size code 129 = integer 32; + + host margaux { + ... # Standard lines, see above + option swap-path "192.168.4.4:/netswapvolume/netswap"; + option swap-size 64000; + } + これは、少なくとも FreeBSD クライアントにおいては、 + DHCP/BOOTP オプションコードの 128 は + NFS スワップファイルへのパスで、オプションコード 129 + は KB 単位のスワップサイズだということです。 + もっと古いバージョンの dhcpd では + option option-128 "... + という書式が受け付けられましたが、もはや動かないようです。 + これに対して、/etc/bootptab + では次の書式を使います。 + + T128="192.168.4.4:/netswapvolume/netswap":T129=64000 + + + + + NFS スワップファイルサーバ側でスワップファイルを作成します。 + + &prompt.root; mkdir /netswapvolume/netswap + &prompt.root; cd /netswapvolume/netswap + &prompt.root; dd if=/dev/zero bs=1024 count=64000 of=swap.192.168.4.6 + &prompt.root; chmod 0600 swap.192.168.4.6 + 192.168.4.6 + はディスクレスクライアントの IP アドレスです。 + + + + NFS スワップファイルサーバ上で + /etc/exports + に下記の行を追加してください。 + + /netswapvolume -maproot=0:10 -alldirs margaux + それから、上述したように mountd + にエクスポートファイルを再読み込みさせてください。 + + + + + + 雑多な問題 - /sys/i386/boot/netboot/Makefile - の中の設定を変更して - コンパイルすることで、 netbootでNE1000/2000 - カードをサポートします。 - このファイルの先頭にあるコメントを見てください。 + + 読み取り専用の <filename>/usr</filename> + で動作させる + + + ディスクレス稼働 + 読み取り専用の /usr + + + ディスクレスワークステーションが X + を起動するように設定されている場合、 + xdm 設定ファイルを調整しなければならないでしょう。 + これはデフォルトでエラーファイルを + /usr に置きます。 + + + FreeBSD ではないサーバを使用する + + ルートファイルシステムを提供するサーバが FreeBSD + で動作していない場合、 + FreeBSD マシン上でルートファイルシステムを作成し、 + tar または cpio + を利用して置きたい場所にコピーしなければならないでしょう。 + この状況では、major/minor 整数サイズが異なっていることにより + /dev + 内のスペシャルファイルに関する問題が時々おこります。 + この問題を解決するには、非 FreeBSD + サーバからディレクトリをエクスポートして、 + そのディレクトリを FreeBSD マシンでマウントし、 + FreeBSD マシン上で MAKEDEV + を実行して正しいデバイスエントリを作成します + (FreeBSD 5.0 およびそれ以降では、&man.devfs.5; + を使用してユーザに意識させずにデバイスノードを割り当てるので、 + これらのバージョンでは + MAKEDEV は必要ありません)。 + + - + ISDN - 最終更新: Bill Lloyd wlloyd@mpd.ca. + + ISDN + 訳: &a.jp.kiroh;. 11 December 1996. ISDN 技術とハードウェアに関しては、 - + Dan Kegel's ISDN Page がよい参考になるでしょう。 - ISDN の導入手順は、 簡単にいって以下のようになります。 + 手軽な ISDN の導入手順は以下のようになります。 - ヨーロッパ在住の方は、 ISDN - カードの節に進んでください。 + ヨーロッパ在住の方は ISDN カードの節に進んでください。 - ISDN を使って、 - インターネットプロバイダに(専用線は使用せず)、 ダ - イアルアップ接続しようとしている場合は、 + ダイヤルアップ専用でない回線上で、 + インターネットプロバイダをつかってインターネットに接続するために + ISDN を使用することを第一に考えている場合は、 ターミナルアダプタの使用を考えてみてください。 - この方法はもっとも柔軟性があり、 プロバイダを変更した場 - 合の問題も少ないでしょう。 + この方法はもっとも柔軟性があり、 + プロバイダを変更した場合の問題も少ないでしょう。 - 2つの LAN の間を接続しようする場合や、 ISDN - 専用線を使用する場合 には、 - スタンドアローンルータ/ブリッジの使用を勧めます。 + 2 つの LAN を接続する場合や、 + ISDN 専用線を使用する場合には、 + スタンドアロンなルータまたはブリッジの使用を勧めます。 - どの方法を用いるかを決定するには、 - 費用が重要な要素になってきます。 以下に、 最も安価な方法から、 - 高価な方法まで順に説明していきます。 - - + 費用はどの解決法を選ぶかを決める重要な要因です。 + 以下に、最も安価な方法から、高価な方法まで順に説明していきます。 + + + + + + Hellmuth + Michaelis + 寄稿: + + + 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 + カード + + + FreeBSD の ISDN 実装は、パッシブカードを使用した DSS1/Q.931 + (または Euro-ISDN) 標準だけに対応しています。FreeBSD 4.4 + からは、ファームウェアが他の信号プロトコルにも対応している + 一部のアクティブカードにも対応しました。 + その中には、はじめて対応された一次群速度インタフェース (PRI) + ISDN カードもあります。 + + Isdn4bsd は IP over raw HDLC + または同期 PPP を利用して他の ISDN ルータに接続できるようにします。 + PPP では、カーネル PPP を spp を修正した isppp + ドライバとともに利用するか、または ユーザプロセス &man.ppp.8; + を利用するかのどちらかになります。ユーザ &man.ppp.8; + を利用すると、二つ以上の ISDN B チャネルを併せて利用できます。 + ソフトウェア 300 ボーモデムのような多くのユーティリティとともに、 + 留守番電話アプリケーションも利用可能です。 + + FreeBSD が対応している PC ISDN カードの数は増加しており、 + ヨーロッパ全域や世界のその他多くの地域でうまく使えることが報告されています。 + + 対応しているパッシブ ISDN カードのほとんどは Infineon + (前身は Siemens) の ISAC/HSCX/IPAC ISDN + チップセットを備えたカードですが、 + Cologne Chip から供給されたチップを備えた ISDN カード + (ISA バスのみ)、Winbond W6692 チップを備えた PCI カード、 + Tiger300/320/ISAC チップセットを組み合わたカードの一部、 + および AVM Fritz!Card PCI V.1.0 や AVM Fritz!Card PnP + のようなベンダ独自のチップセットに基づいたカードもあります。 + + 現在のところ、対応しているアクティブカードは + AVM B1 (ISA および PCI) BRI カードと AVM T1 PCI PRI カードです。 + + isdn4bsd についての文書は + FreeBSD システム内の /usr/share/examples/isdn/ + ディレクトリまたは + isdn4bsd + のウェブサイトを参照してください。 + そこにはヒントや正誤表や + isdn4bsd + ハンドブックのような、 + さらに多くの文書に対するポインタがあります。 + + 異なる ISDN プロトコルや、現在対応されていない ISDN PC + カードに対応することや、その他 isdn4bsd + を拡張することに興味があるなら、&a.hm; に連絡してください。 + + isdn4bsd のインストール、設定、 + そしてトラブルシューティングに関して質問があれば + &a.isdn.name; メーリングリストが利用可能です。 ISDN ターミナルアダプタ - ターミナルアダプタ (TA) はISDN に対して、 - 通常の電話線に対するモデムに相当するものです。 - - ほとんどの TA は、 標準のヘイズ AT + ターミナルアダプタ (TA) は ISDN で、 + 通常の電話線におけるモデムに相当するものです。 + モデム + ほとんどの TA は、標準のヘイズ AT コマンドセットを使用しているので、 単にモデムと置き換えて使うことができます。 - TA は、 基本的にはモデムと同じように動作しますが、 - 接続方法は異なり、 通信速度も古いモデムよりはるかに速くなります。 + TA は、基本的にはモデムと同じように動作しますが、 + 接続方法は異なり、通信速度も古いモデムよりはるかに速くなります。 PPP の設定を、 - モデムの場合と同じように行ってください。 とくにシリアル速度を - 使用できる最高速度に設定するのを忘れないでください。 - - プロバイダへの接続に TA を使用する最大のメリットは、 動的 - PPP を行えることです。 最近 IP アドレスが不足してきているため、 - ほとんどのプロバイダは、 専用の IP - アドレスを割り当てないようになっています。 - ほとんどのスタンドアローンルータは、 動的 IP - アドレスに対応していません。 - - 訳注: 最近の ISDN ルータでは、 IP - アドレスの動的割り当てに対応しているものも多いようです。 - ただし制限がある場合もありますので、 詳しくはメーカ - に問い合わせてください。 - - TA を使用した場合の機能や接続の安定性は、 使用している PPP - デーモンに完全に依存します。 そのため、 FreeBSD で PPP - の設定が完了していれば、 使用している既存のモデムを ISDN の TA - に簡単にアップグレードすることができます。 ただし、 それまでの - PPP のプログラムに問題があった場合、 その問題は TA + モデムの場合と同じように行ってください。 + 特にシリアル速度を使用できる最高速度に設定するのを忘れないでください。 + PPP + プロバイダへの接続に TA を使用する最大のメリットは、動的 + PPP を行えることです。 + 最近 IP アドレス空間がますます不足してきているため、 + ほとんどのプロバイダは、 + 固定 IP アドレスを割り当てないようになっています。 + ほとんどのスタンドアローンルータは、動的 IP + アドレス割り当てに対応していません。 + + + 訳注 + 最近の ISDN ルータでは + IP アドレスの動的割り当てに対応しているものも多いようです。 + ただし制限がある場合もありますので、 + 詳しくはメーカに問い合わせてください。 + + + TA を使用した場合の機能や接続の安定性は、使用している PPP + デーモンに完全に依存します。そのため、FreeBSD で PPP + の設定が完了していれば、使用している既存のモデムを ISDN の TA + に簡単にアップグレードすることができます。ただし、それまでの + PPP のプログラムに問題があった場合、その問題は TA に置き換えてもそのまま残ります。 - 最高の安定性を求めるのであれば、 ユーザープロセス - iijPPP ではなく、 カーネル + 最高の安定性を求めるのであれば、ユーザープロセス + iijPPP ではなく、カーネル PPPを使用してください。 - 以下の TA は、 FreeBSD で動作確認ずみです。 + 以下の TA は、FreeBSD で動作確認ずみです。 @@ -1340,69 +3049,66 @@ hostname myclient.mydomain - 他の TA もほとんどの場合うまく動作するでしょう。 TA - のメーカーでは、 TA がほとんどの標準モデム AT - コマンドセットを受け付けるようにするよう、 - 努力しているようです。 + 他の TA もほとんどの場合うまく動作するでしょう。TA + のメーカーでは、TA がほとんどの標準モデム AT + コマンドセットを受け付けるようにするよう努力しているようです。 外部 TA を使う際の最大の問題点は、 - モデムの場合と同じく良いシリアルカー - ドが必要であるということです。 - - シリアルデバイスの詳細、 - そして非同期シリアルポートと同期シリアルポートの差については、 - 同期・非同期の違いやシリアルデバイスについて説明したチュートリアル FreeBSD Serial - Hardware を参照してください。 - - 標準の PC シリアルポート(非同期)に接続された TA は、 128Kbs - の接続を行っていても、 最大通信速度が 115.2Kbs - に制限されてしまいます。 128Kbs の ISDN - の性能を最大限に生かすためには、 TA + モデムの場合と同じく良いシリアルカードが必要であるということです。 + + シリアルデバイスの詳細と、 + 非同期シリアルポートと同期シリアルポートの差を理解するには、FreeBSD + シリアルハードウェアチュートリアルを参照してください。 + + 標準の PC シリアルポート (非同期) に接続された TA は + 128 Kbs の接続を行っていても、最大通信速度が 115.2 Kbs + に制限されてしまいます。128 Kbs の ISDN + の性能を最大限に生かすためには TA を同期シリアルカードに接続しなければなりません。 - 内蔵 TA を購入して、 - 同期／非同期問題を片付けてしまおうとは思わないでく ださい。 - 内蔵 TA には、 単に標準 PC シリアルポートのチップが内蔵されてい - るだけです。 内蔵 TA の利点といえば、 - シリアルケーブルを買わなくていいと いうことと、 + 内蔵 TA を購入すれば、 + 同期/非同期問題を回避できるとは思わないでください。内蔵 TA には、 + 単に標準 PC シリアルポートのチップが内蔵されているだけです。 + 内蔵 TA の利点といえば、 + シリアルケーブルを買わなくていいということと、 電源コンセントが一つ少なくて済むということくらいでしょう。 - 同期カードと TA の組合せは 386 の FreeBSD - マシンの場合でも、 スタンドア - ローンのルータと同程度の速度は確保できます。 - またこの組合せでは、 ルータより柔軟な設定が可能です。 + 同期カードと TA + の組合せでも、スタンドアロンのルータと同程度の速度は確保できます。 + さらに、386 の FreeBSD マシンと組合せると、 + より柔軟な設定が可能です。 - 同期カード/TA を選ぶか、 スタンドアローンルータを選ぶかは、 + 同期カード/TA を選ぶか、スタンドアロンルータを選ぶかは、 多分に宗教的な問題です。 - メーリングリストでもいくつか議論がありました。 議論の内容に - ついては、 archives + メーリングリストでもいくつか議論がありました。議論の全容については、 + アーカイブ を参照してください。 - スタンドアローン ISDN ブリッジ/ルータ - - ISDN ブリッジやルータは、 OS 特有のものではありません。 - もちろん FreeBSD 特有のものでもありません。 + スタンドアロン ISDN ブリッジ/ルータ + + ISDN + スタンドアロン ブリッジ/ルータ + + ISDN ブリッジあるいはルータは、 + FreeBSD あるいは他の OS に特有のものでは皆目ありません。 ルーティングやブリッジング技術に関する詳細は、 ネットワークの参考書をご覧ください。 このページでは、 ルータとブリッジにどちらでもあてはまるように記述します。 - ISDN ルータ/ブリッジは、 - ローエンドの製品のコストが下がってきていることもあり、 - より一般的に使用されるようになるでしょう。 ISDN ルータは、 - 外見は小さな箱で、 - ローカルのイーサネットネットワーク(もしくはカード)と直接、 - 接続します。 また、 - 自身で他のブリッジ/ルータとの接続を制御します。 PPP - や他のプロトコルを使用するためのソフトウェアは、 - すべて組み込まれています。 - - ルータは、 完全な同期 ISDN 接続を使用するため、 通常の TA + ローエンド ISDN ルータ/ブリッジ製品は、 + 価格が下がってきていることもあり、 + より広く選択されるようになるでしょう。ISDN ルータは、 + ローカルイーサネットネットワークに直接接続し、 + 自身で他のブリッジ/ルータとの接続を制御する小さな箱です。PPP + や他の広く使用されているプロトコルをつかって通信するためのソフトウェアが組み込まれています。 + + ルータは、完全な同期 ISDN 接続を使用するため、通常の TA と比較してスループットが大幅に向上します。 ISDN ルータ/ブリッジを使用する場合の最大の問題点は、 @@ -1410,48 +3116,64 @@ hostname myclient.mydomain インターネットプロバイダとの接続を考えている場合には、 プロバイダと相談することをお勧めします。 - 事務所の LAN と家庭の LAN の間など、 二つの LAN + 事務所の LAN と家庭の LAN の間など、二つの LAN セグメントの間を接続しようとしている場合は、 - ブリッジ/ルータの使用がもっともメンテナンスが 簡単で、 - 努力が少なくてすむ方法です。 両側の機材を購入するのであれば、 - メーカー間の接続性の問題もないでしょう。 + これはもっともメンテナンスが簡単で、安くあがる解決方法です。 + 接続の両側の機材を購入するので、 + リンクがうまくいくであろうことを保証できます。 - たとえば家庭の LAN や出張所の LAN - を本社のネットワークに接続するためには、 + たとえば、 + 家庭のコンピュータや支店のネットワークを本社のネットワークに接続するためには、 以下のような設定が使用できます。 - 出張所 LAN または 家庭 LAN + 支店または家庭のネットワーク + + 10 base 2 + ネットワークは 10 Base 2 イーサネット (thinnet) + のバス型トポロジを用いています。ルータとネットワークの間は、 + 必要に応じて AUI/10BT トランシーバを使って接続してください。 - ネットワークは、 10 Base T イーサネットです。 - ルータとネットワークの間は、 必要に応じて AUI/10BT - トランシーバを使って接続します。 + + + + - - ---Sun ワークステーション + + ---Sun ワークステーション | ----FreeBSD マシン +---FreeBSD box | ---Windows 95 (別に勧めているわけじゃありません) | -スタンドアローンルータ +スタンドアロンルータ | -ISDN BRI ライン +ISDN BRI ライン + - - 家庭/出張所 LAN で、 - 一台しかコンピュータを接続しないのであれば、 クロス - のツイストペアケーブルを使用して、 - スタンドアローンルータと直結も可能です。 + + 10 Base 2 イーサネット + + + + 家庭/支店で一台しかコンピュータを使用しないのであれば、 + クロスのツイストペアケーブルを使用して、 + 直接スタンドアロンルータに接続することも可能です。 本社 LAN や他の LAN - ネットワークは、 ツイストペアイーサネットです。 + ネットワークは 10 base T イーサネット + (Twisted Pair) + のスター型トポロジを用いています。 - - -------Novell サーバ + + + + + + -------Novell サーバ | | |ハ ---Sun | | @@ -1461,192 +3183,255 @@ ISDN BRI | | |___---スタンドアローンルータ | - ISDN BRI ライン + ISDN BRI ライン + + + ISDN ネットワークダイアグラム + + - ほとんどのルータ/ブリッジでは、 別々の二つのサイトに対して、 - 同時にそれ - ぞれ独立した二つの PPP 接続が可能です。 - これは、 通常の TA ではサポートされない機能で、 - ルータ/ブリッジ接続の大きな利点です (シリアルポートを - 二つもつ特殊(そして高価な) TA では可能です)。 - チャンネル割り当てや MPP などと混同しないでください。 - - これは、 大変便利な機能です。 - たとえば事務所で専用線 ISDN 接続を使用していて、 - 別の ISDN ラインを購入したくないとします。 この場合、 - 事務所のルータは、 一つの専用線 B - チャンネル接続(64Kbs)を維持しつつ、 別 の B - チャンネルを他の用途に使用することができます。 たとえば、 - 他の場所 とのダイアルイン、 ダイアルアウトに使用したり、 - バンド幅を増やすために、 - インターネットとの接続への動的な割り当て(MPP - など)に使用したりすることが可能です。 - - またイーサネットブリッジは、 IP パケットだけでなく IPX/SPX - などすべての - プロトコルのパケットを中継することが可能です。 - + ほとんどのルータ/ブリッジの大きな利点は、 + 別々の二つのサイトに対して、同時 + にそれぞれ独立した二つの PPP + 接続が可能であることです。 + これは、シリアルポートを 2 つもった特定の (通常は高価な) + モデルを除いて、通常の TA では対応していません。 + チャネルボンディングや MPP などと混同しないでください。 + + たとえば、事務所で専用線 ISDN 接続を使用していて、 + 別の ISDN 回線を購入したくないときには大変便利な機能です。この場合、 + 事務所のルータは、インターネットに接続するための一つの専用線 B + チャネル接続 (64 Kbs) を管理し、 + 別の B チャネルを他のデータ接続に使用できます。 + 2 つ目の B チャネルは他の場所とのダイアルイン、 + ダイアルアウトに使用したり、バンド幅を増やすために、 + 1 つ目の B チャネルと動的に結合すること (MPPなど) + ができます。 + + IPX/SPX + またイーサネットブリッジは、IP パケット以外も中継できます。 + IPX/SPX など、使用するすべてのプロトコルを送ることが可能です。 - + + + + + Bill + Swingle + 原作: + + + + + Eric + Ogren + 追記: + + + Udo + Erdelhoff + + + 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 + Solaris + HP-UX + AIX + Linux + NetBSD + OpenBSD + NIS とは Network Information Services の略で + Sun Microsystems によって &unix; の (もともとは &sunos; の) + 集中管理のために開発されました。現在では事実上の業界標準になっており、 + 主要な &unix; ライクシステム + (&solaris;, HP-UX, &aix;, Linux, NetBSD, OpenBSD, FreeBSD、等々) + はすべてこれをサポートしています。 + + イエローページNIS + NIS は元々、イエローページといっていましたが、 + 商標問題から Sun はその名前を変えました。 + 古い用語 (および yp) はまだよく見られ、使用されています。 + + + NIS + ドメイン + NIS は RPC を使ったクライアント/サーバシステムです。 - これを使うと NISドメイン内のマシン間で、 - 共通の設定ファイルを共有することができます。 - また、 NIS を使うことでシステム管理者は最小限の設定データで - NIS クライアントを立ち上げることができ、 - 1 ヶ所から設定データの追加、 削除、 変更が可能です。 - - NIS は Windows NT のドメインシステムに似ています。 - 内部の実装は似ても似つかないものですが、 基本的な機能を - 対比することはできます。 + これを使うと NIS ドメイン内のマシン間で、 + 共通の設定ファイルを共有することができます。 + また NIS を使うことでシステム管理者は最小限の設定データで + NIS クライアントを立ち上げることができ、 + 1 ヶ所から設定データの追加、削除、変更が可能です。 + + Windows NT + NIS は &windowsnt; のドメインシステムに似ています。 + 内部の実装は似ても似つかないものですが、 + 基本的な機能を対比することはできます。 知っておくべき用語 / プロセス NIS サーバの立ち上げや NIS クライアントの設定など、 - NIS を FreeBSD に導入するにあたって、 - 目にするであろう用語や重要なユーザプロセスがいくつかあります。 + 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 し、 そこでパスワードを変更することになります。 - - - - + + portmap + + + + + + + 用語 + 説明 + + + + + NIS ドメイン名 + NIS マスタサーバとそのクライアントすべて + (スレーブサーバを含む) には NIS ドメイン名がついています。 + &windowsnt; ドメイン名と同様に、NIS ドメイン名は + DNS とは何の関係もありません。 + + + portmap + RPC (Remote Procedure Call, + NIS で使用されるネットワークプロトコル) + を利用するために実行しておかなければなりません。 + portmap が動作していなければ、 + NIS サーバを起動することも、 + NIS クライアントとして動作させることもできません。 + + + ypbind + NIS クライアントを + NIS サーバに結びつけます。 + これは NIS ドメイン名をシステムから取得し + RPC を用いてサーバに接続します。ypbind + は NIS 環境におけるクライアントとサーバ間の通信の中枢です。 + クライアントマシンの + ypbind が停止した場合は、NIS + サーバへアクセスすることができなくなります。 + + + ypserv + は NIS サーバでのみ実行されるべきもので、 + NIS サーバプロセスそのものです。&man.ypserv.8; + が停止した場合、サーバはもはや NIS + リクエストに応答することができなくなるでしょう + (できれば、後を引き継ぐスレーブサーバがあるとよいでしょう)。 + 今まで使っていたサーバが機能を停止したとき、 + 別のサーバに再接続しに行かない NIS の実装もいくつかあります + (FreeBSD のものは違います)。 + そのような場合に復帰するための唯一の方法は、 + サーバプロセス (あるいはサーバ全体)、もしくはクライアントの + ypbind + プロセスを再スタートすることです。 + + + rpc.yppasswdd + NIS マスターサーバで動かすべき、 + もう一つのプロセスです。これは NIS クライアントが + NIS パスワードを変更することを可能にするデーモンです。 + このデーモンが動作していないときは、 + ユーザは NIS マスタサーバにログインし、 + そこでパスワードを変更しなければなりません。 + + + + + 動作のしくみ - NIS 環境にあるホストは、 次の 3 種類に分類されます。 それは、 - マスターサーバ、 スレーブサーバ、 クライアントです。 - サーバは、 ホストの設定情報の中心的な情報格納庫の役割をします。 - マスターサーバは元となる信頼できる情報を保持し、 - スレーブサーバは、 冗長性を確保するため、 この情報をミラーします。 - そしてクライアントは、 サーバから情報の提供を受けて動作します。 - - この方法を用いることで、 数多くのファイルにある情報が共有できます。 - よく NIS で共有されるのは、 - master.passwd や group、 + NIS 環境にあるホストは、 + マスターサーバ、スレーブサーバ、クライアントの + 3 種類に分類されます。 + サーバは、ホストの設定情報の中心的な情報格納庫の役割をします。 + マスターサーバは元となる信頼できる情報を保持し、 + スレーブサーバは冗長性を確保するためこの情報をミラーします。 + そしてクライアントは、サーバから情報の提供を受けて動作します。 + + この方法を用いることで、数多くのファイルにある情報が共有できます。 + よく NIS で共有されるのは、 + master.passwd や group, hosts といったファイルです。 - クライアント上のプロセスで、 通常ローカルのファイルにある情報が必要 - となったとき、 - クライアントは接続しているサーバに問い合わせを行い、 その情報を得ます。 - + クライアント上のプロセスが、 + 通常ならローカルのファイルにある情報を必要とするときは、 + クライアントは代わりに接続している + NIS サーバに問い合わせを行います。 - マシンの分類 - - - - NIS マスターサーバ. - このサーバは Windows NT で言うところのプライマリ - ドメインコントローラにあたります。 - すべての NIS クライアントで利用されるファイルを保守し、 - passwd や - group、 その他 NIS - クライアントが参照するファイルは、 - マスターサーバにあります。 - - - 一つのマシンが一つ以上の NIS - ドメインのマスターサーバになることは可能です。 - しかし、 ここでは比較的小規模の NIS 環境を対象としているため、 - そのような場合については扱いません。 - - - - NIS スレーブサーバ。 - NT で言うところのバックアップドメインコントローラに似たもので、 - NIS スレーブサーバは NIS - マスターサーバのデータファイルのコピーを保持します。 - NIS スレーブサーバは重要な環境で必要とされる冗長性を提供し、 - マスターサーバの負荷のバランスをとります。 - NIS クライアントは常に最初にレスポンスを返したサーバを - NIS サーバとして接続しますが、 - これにはスレーブサーバも含まれます。 - - - NIS クライアント。 - NIS クライアントは大部分の NT ワークステーションのように、 - logon に際して - NIS サーバに対して (NT ワークステーションの場合では NT - ドメインコントローラに) 認証します。 - - + マシンの分類 + + + + NIS + マスタサーバ + + + + NIS マスターサーバ。 + このサーバは &windowsnt; + で言うところのプライマリドメインコントローラにあたります。 + すべての NIS クライアントで利用されるファイルを保守します。 + passwd や group、 + その他 NIS クライアントが参照するファイルは、 + マスターサーバにあります。 + + 一つのマシンが一つ以上の NIS + ドメインのマスターサーバになることは可能です。 + しかし、ここでは比較的小規模の NIS 環境を対象としているため、 + そのような場合については扱いません。 + + + + + NIS + スレーブサーバ + + + NIS スレーブサーバ。 + &windowsnt; のバックアップドメインコントローラに似たもので、 + NIS スレーブサーバは NIS + マスターサーバのデータファイルのコピーを保持します。 + NIS スレーブサーバは重要な環境で必要とされる冗長性を提供し、 + マスターサーバの負荷のバランスをとります。 + NIS クライアントは常に最初にレスポンスを返したサーバを + NIS サーバとして接続しますが、 + これにはスレーブサーバも含まれます。 + + + + + NIS + クライアント + + + NIS クライアント。 + NIS クライアントは大部分の &windowsnt; + ワークステーションのように、ログオンに際して + NIS サーバ (&windowsnt; ワークステーションの場合は + &windowsnt; ドメインコントローラ) + に接続して認証します。 + + @@ -1656,234 +3441,250 @@ ISDN BRI この節では NIS 環境の立ち上げ例を取り上げます。 - この節ではあなたが FreeBSD 3.3 以降を使っているものとします。 - ここで与えられる指示はおそらく FreeBSD の - 3.0 以降の、 どのバージョンでも機能するでしょうが、 - それを保証するものではありません。 + この節ではあなたが FreeBSD 3.3 + 以降を使っているものとします。 + ここで与えられる指示は おそらく FreeBSD の + 3.0 以降のどのバージョンでも機能するでしょうが、 + それを保証するものではありません。 - 計画を立てる + 計画を立てる - あなたが大学の小さな研究室の管理人であるとしましょう。 - この研究室は 15 台の FreeBSD マシンからなっていて、 - 現在はまだ集中管理されていません。 - すなわち、 各マシンは /etc/passwd と - /etc/master.passwd を各々が持っています。 + あなたが大学の小さな研究室の管理人であるとしましょう。 + この研究室は 15 台の FreeBSD マシンからなっていて、 + 現在はまだ集中管理されていません。 + すなわち、各マシンは /etc/passwd と + /etc/master.passwd を各々が持っています。 これらのファイルは手動でお互いに同期させています。 - つまり現時点では、 新しいユーザをあなたが追加するとき、 - adduser を 15 ヶ所すべてで実行しなければなりません。 - これは明らかに変える必要があるため、 + つまり現時点では、新しいユーザをあなたが追加するとき、 + 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] - その他のクライアントマシン - - - - + その結果、研究室の設定はこのようなものになります: + + + + + + マシンの名前 + IP アドレス + 役割 + + + + + 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 + ドメイン名 + + ここでいうドメイン名は、今まであなたが使っていた、 + いわゆる ドメイン名 と呼んでいたものとは違います。 正確には NIS ドメイン名 と呼ばれます。 - クライアントがサーバに情報を要求するとき、 - その要求には自分が属する NIS ドメインの名前が含まれています。 - これは、 1 つのネットワークに複数のサーバがある場合に、 - どのサーバが要求を処理すれば良いかを決めるために使われます。 - NIS ドメイン名とは、 関連のあるホストをグループ化するための名前である、 - と考えると良いでしょう。 + クライアントがサーバに情報を要求するとき、 + その要求には自分が属する NIS ドメインの名前が含まれています。 + これは 1 つのネットワークに複数のサーバがある場合に、 + どのサーバが要求を処理すれば良いかを決めるために使われます。 + NIS ドメイン名とは、 + 関連のあるホストをグループ化するための名前である、 + と考えると良いでしょう。 組織によってはインターネットのドメイン名を - NIS ドメイン名に使っているところがありますが、 - これはネットワークのトラブルをデバッグするときに混乱の原因となるため、 - お勧めできません。 - NIS ドメイン名はネットワーク内で一意でなければならないので、 - ドメイン名がドメインに含まれるマシンを表すようなものであれば、 - 分かりやすくなります。 たとえば - Acme 社のアート(Art)部門であれば、 - NIS ドメイン名を"acme-art"とすれば良いでしょう。 - - しかしながら、 オペレーティングシステムによっては、 - そのネットワークドメイン名を NIS - のドメイン名として使うものもあります (特に SunOS)。 - あなたのネットワークにそのような制限のあるマシンが 1 台でもあるときは、 NIS - のドメイン名としてインターネットのネットワークドメイン名を使わなければいけません。 - - - - サーバマシンの物理的な条件とは + NIS ドメイン名に使っているところがあります。 + これはネットワークのトラブルをデバッグするときに混乱の原因となるため、お勧めできません。 + NIS ドメイン名はネットワーク内で一意なければいけません。そして、 + ドメイン名がドメインに含まれるマシンを表すようなものであれば分かり易いです。 + たとえば Acme 社のアート (Art) 部門であれば NIS ドメイン名を + acme-art とすれば良いでしょう。この例では + NIS ドメイン名として test-domain + を使用します。 + + SunOS + しかしながらオペレーティングシステムによっては (特に &sunos;)、 + NIS ドメイン名をネットワークドメイン名として使うものもあります。 + あなたのネットワークにそのような制限のあるマシンが + 1 台でもあるときは、NIS + のドメイン名としてインターネットのネットワークドメイン名を使わなければいけません。 + + + + サーバマシンの物理的必要条件 NIS サーバとして使うマシンを選ぶ際には、 - いくつかの注意点があります。 - NIS における困ったことの一つに、 - クライアントのサーバへの依存度があります。 - クライアントが自分の NIS ドメインのサーバに接続できない場合、 - マシンが使用不能になることがよくあります。 - もし、 ユーザやグループに関する情報が得られなければ、 - ほとんどのシステムは一時的にですが停止してしまいます。 - こういったことを念頭に置いて、 - しょっちゅうリブートされるマシンや、 - 開発に使われそうなマシンを選ばないようにしなければなりません。 - 理想的には、 NIS サーバはスタンドアロンで - NIS サーバ専用となるマシンにするべきです。 - ネットワークの負荷が重くなければ、 - 他のサービスを走らせているマシンを NIS - サーバにしてもかまいません。 ただし NIS - サーバが使えなくなると、 - すべてのクライアントに影響をおよぼす、 - という点には注意しなければなりません。 - + いくつか注意すべき点があります。 + NIS に関する困ったことの一つに、 + クライアントのサーバへの依存度があります。 + クライアントが自分の NIS ドメインのサーバに接続できないと、 + マシンが使用不能になることがあまりに多いのです。 + もし、ユーザやグループに関する情報が得られなければ、 + ほとんどのシステムは一時的に停止してしまいます。 + こういったことを念頭に置いて、頻繁にリブートされるマシンや、 + 開発に使われそうなマシンを選ばないようにしなければなりません。 + 理想的には NIS サーバはスタンドアロンで + NIS サーバ専用のマシンにするべきです。 + ネットワークの負荷が重くなければ、 + 他のサービスを走らせているマシンを NIS サーバにしてもかまいません。 + ただし NIS サーバが使えなくなると、すべての + クライアントに影響をおよぼす、という点には注意しなければなりません。 + - NIS サーバ + NIS サーバ 元となるすべての NIS 情報は、 - NIS マスターサーバと呼ばれる 1 台のマシンに置かれます。 - この情報が格納されるデータベースを NIS マップと呼びます。 - FreeBSDでは、 このマップは + NIS マスターサーバと呼ばれる 1 台のマシンに格納されます。 + この情報が格納されるデータベースを NIS マップと呼びます。 + FreeBSD では、このマップは /var/yp/[domainname] に置かれます。 [domainname] は、 - サーバがサービスする NIS ドメインです。 - 1 台の NIS サーバが複数のドメインをサポートすることも可能です。 - つまり、 このディレクトリを各々のドメインごとに作ることができ、 - 各ドメインごと、 独立したマップの集合を持つことになります。 + サーバがサービスする NIS ドメインです。 + 1 台の NIS サーバが複数のドメインをサポートすることも可能です。 + つまり、このディレクトリを各々のドメインごとに作ることができます。 + それぞれのドメインは、独立したマップの集合を持つことになります。 NIS のマスターサーバとスレーブサーバ上では、 ypserv デーモンがすべての NIS 要求を処理します。 - ypserv は NIS クライアントからの要求を受け付け、 - ドメイン名とマップ名を対応するデータベースファイルへのパスに変換し、 - データをクライアントに返送します。 + ypserv は NIS クライアントからの要求を受け付け、 + ドメイン名とマップ名を対応するデータベースファイルへのパスに変換し、 + データをクライアントに返送します。 - + NIS マスターサーバの設定 - - やりたいことにもよりますが、 - 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 + に追加することだけで、 + あとは FreeBSD がやってくれます。 + + + + nisdomainname="test-domain" + この行はネットワークの設定後に (たとえば再起動後に) + NIS のドメイン名を test-domain + に設定します。 + + + + nis_server_enable="YES" + これは FreeBSD に次にネットワークが立ち上がったとき NIS + のサーバプロセスを起動させます。 + + + + nis_yppasswdd_enable="YES" + これは rpc.yppasswdd + デーモンを有効にします。上述したようにこれはユーザが NIS + のパスワードをクライアントのマシンから変更することを可能にします。 + + + + + NIS の設定によっては、 + さらに他のエントリを付け加える必要があるかもしれません。 + 詳細については、下記の + NIS クライアントとしても動作している 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 + + NIS マップの初期化 + + 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 マスタのためのマップを作るためには + システムに関するアカウント + (bin, tty, + kmem, games など) + や、NIS クライアントに伝えたくないアカウント + (たとえば root + や他の UID が 0 (スーパユーザ) のアカウント) + をすべて NIS マップから取り除かなければなりません。 + + + /var/yp/master.passwd が + グループまたは誰もが読めるようになっていないようにしてください + (モード 600)! + 必要なら chmod + コマンドを使ってください。 + + Tru64 UNIX + すべてが終わったら NIS マップを初期化します! + FreeBSD には、これを行うために ypinit + という名のスクリプトが含まれています + (詳細はそのマニュアルページをご覧ください)。 + このスクリプトはほとんどの &unix; OS に存在しますが、 + すべてとは限らないことを覚えておいてください。 + Digital Unix/Compaq Tru64 UNIX では ypsetup + と呼ばれています。NIS マスタのためのマップを作るためには オプションを ypinit - に与えます。 上述のステップを完了しているなら、 - 以下を実行して NIS マップを生成します。 + に与えます。上述のステップを完了しているなら、以下を実行して + NIS マップを生成します。 - ellington&prompt.root; ypinit -m test-domain + 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. @@ -1907,37 +3708,40 @@ Is this correct? [y/n: y] y 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 環境であるという前提に立っています。 + ypinit は + /var/yp/Makefile を + /var/yp/Makefile.dist から作成します。 + 作成された時点では、そのファイルはあなたが FreeBSD + マシンだけからなるサーバが 1 台だけの + NIS 環境を扱っていると仮定しています。 test-domain - はスレーブサーバを一つ持っていますので、 - /var/yp/Makefile - を編集する必要があります。 + はスレーブサーバを一つ持っていますので + /var/yp/Makefile + を編集しなければなりません。 - ellington&prompt.root; vi /var/yp/Makefile + ellington&prompt.root; vi /var/yp/Makefile - `NOPUSH = "True"' - としている行を (もし既にコメントアウトされていないならば) - コメントアウトしなければなりません。 - + 以下の行を (もし既にコメントアウトされていないならば) + コメントアウトしなければなりません。 - - NIS スレーブサーバの設定 + NOPUSH = "True" + + + NIS スレーブサーバの設定 + + NIS + スレーブサーバ + NIS スレーブサーバの設定はマスターサーバの設定以上に簡単です。 スレーブサーバにログオンし /etc/rc.conf - ファイルを前回と同様に編集します。 唯一の違うところは + ファイルを前回と同様に編集します。唯一の違うところは ypinit の実行に - オプションを使わなければいけないことです。 - オプションは NIS - マスターサーバの名前を要求し、 コマンドラインは以下のようになります。 + オプションを使わなければいけないことです。 + オプションは NIS マスターサーバの名前を要求し、 + コマンドラインは以下のようになります: - coltrane&prompt.root; ypinit -s ellington test-domain + coltrane&prompt.root; ypinit -s ellington test-domain Server Type: SLAVE Domain: test-domain Master: ellington @@ -1994,108 +3798,123 @@ 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 - に追加することで、 最新のものに保つことができます。 - + この例の場合 /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 マップに対する変更をスレーブサーバに伝えようとしますし、 + サーバが管理するシステムにとってパスワード情報はとても重要なので、 + 強制的に更新してしまうことはよい考えです。特に、 + マップファイルの更新がきちんと行なわれるかどうかわからないくらい混雑するネットワークでは、 + 重要になります。 + + スレーブサーバ上でも /etc/netstart + コマンドを実行して、NIS サーバを再起動してください。 - NIS クライアント + NIS クライアント NIS クライアントは ypbind - デーモンを使って、 特定の NIS - サーバとの間に結合 (binding) と呼ばれる関係を成立させます。 + デーモンを使って、特定の NIS + サーバとの間に結合 (binding) と呼ばれる関係を成立させます。 ypbind はシステムのデフォルトのドメイン - (domainname コマンドで設定されます) - をチェックし、 RPC 要求をブロードキャストパケットとしてローカルネットワークに送信します。 - この RPC 要求により、 ypbind - が結合を成立させようとしているドメイン名が指定されます。 + (domainname コマンドで設定されます) + を確認し、RPC 要求をローカルネットワークにブロードキャストします。 + この RPC 要求により ypbind + が結合を成立させようとしているドメイン名が指定されます。 要求されているドメイン名に対してサービスするよう設定されたサーバが - ブロードキャストパケットを受信すると、 - サーバは ypbind に応答し、 - ypbind は応答のあったサーバのアドレスを記録します。 - 複数のサーバがある(たとえば一つのマスターサーバと、 - 複数のスレーブサーバがある)場合、 - ypbind は、 - 最初に応答したサーバのアドレスを使用します。 - これ以降、 クライアントのシステムは、 - すべての NIS の要求をそのサーバに向けて送信します。 + ブロードキャストを受信すると、 + サーバは ypbind に応答しypbind + は応答のあったサーバのアドレスを記録します。複数のサーバ + (たとえば一つのマスターサーバと、複数のスレーブサーバ) + が利用可能な場合、ypbind は、 + 最初に応答したサーバのアドレスを使用します。 + これ以降、クライアントのシステムは、 + すべての NIS の要求をそのサーバに向けて送信します。 ypbind は、 - サーバが順調に動作していることを確認するため、 - 時々 ping をサーバに送ります。 - 反応が戻ってくるべき時間内に ping に対する応答が来なければ、 - ypbind は、 - そのドメインを結合不能(unbound)として記録し、 - 別のサーバを見つけるべく、 再びブロードキャストパケットの送信を行います。 + サーバが順調に動作していることを確認するため、 + 時々 ping をサーバに送ります。 + 反応が戻ってくるべき時間内に ping に対する応答が来なければ、 + ypbind は、そのドメインを結合不能 + (unbound) として記録し、別のサーバを見つけるべく、 + 再びブロードキャストパケットの送信を行います。 NIS クライアントの設定 - - FreeBSD マシンにおける NIS クライアントの設定は非常に単純です。 - - - - /etc/rc.conf - ファイルを編集して以下の行を追加し、 - ネットワークのセットアップ時に - NIS ドメイン名をセットして - ypbind を起動させます。 + + NIS + クライアントの設定 + + FreeBSD マシンを NIS クライアントにする設定は非常に単純です。 + + + + ネットワークの起動時に NIS ドメイン名を設定して + ypbind を起動させるために + /etc/rc.conf + ファイルを編集して以下の行を追加します。 nisdomainname="test-domain" nis_client_enable="YES" - + - - NIS サーバにあるすべてのパスワードエントリを取り込むため、 - vipw コマンドで以下の行を - /etc/master.passwd に追加します。 + + NIS サーバから、 + 利用可能なパスワードエントリをすべて取り込むため、 + /etc/master.passwd + からすべてのユーザアカウントを取り除いて、 + vipw コマンドで以下の行を + /etc/master.passwd の最後に追加します。 +::::::::: この行によって NIS - サーバのパスワードマップにアカウントがある人全員にアカウントが与えられます。 - この行を変更すると、 さまざまな NIS クライアントの設定を行なうことが可能です。 - 詳細は netgroups の部分を、 - さらに詳しい情報については、 O'Reilly の - Managing NFS and NIS をお読みください。 + サーバのパスワードマップにアカウントがある人全員にアカウントが与えられます。 + この行を変更すると、 + さまざまな NIS クライアントの設定を行なうことが可能です。 + 詳細は ネットグループ + を、さらに詳しい情報については、O'Reilly の + Managing NFS and NIS を参照してください。 - - + + /etc/master.passwd + 内に少なくとも一つのローカルアカウント + (つまり NIS 経由でインポートされていないアカウント) + を置くべきです。 + また、このアカウントは wheel + グループのメンバーであるべきです。 + NIS がどこか調子悪いときには、 + リモートからこのアカウントでログインし、 + root になって修復するのに利用できます。 + + + + NIS サーバにあるすべてのグループエントリを取り込むため、 - 以下の行を /etc/group に追加します。 + 以下の行を /etc/group に追加します。 +:*:: - - + + 上記の手順がすべて完了すれば、 - ypcat passwd によって - NIS サーバの passwd マップが参照できるようになっているはずです。 - + ypcat passwd によって + NIS サーバの passwd マップが参照できるようになっているはずです。 + @@ -2104,20 +3923,20 @@ nis_client_enable="YES" NIS セキュリティ 一般にドメイン名さえ知っていれば、 - どこにいるリモートユーザでも ypserv に RPC を発行して - NIS マップの内容を引き出すことができます。 - こういった不正なやりとりを防ぐため、 - ypserv には securenets と呼ばれる機能があります。 - これはアクセスを決められたホストだけに制限する機能です。 - ypserv は起動時に /var/yp/securenets ファイルから - securenets に関する情報を読み込みます。 + どこにいるリモートユーザでも &man.ypserv.8; に RPC を発行して + NIS マップの内容を引き出すことができます。 + こういった不正なやりとりを防ぐため、 + &man.ypserv.8; には securenets と呼ばれる機能があります。これは、 + アクセスを決められたホストだけに制限するのに使える機能です。 + &man.ypserv.8; は起動時に /var/yp/securenets + ファイルから securenets に関する情報を読み込みます。 - 上記のパス名は、 - オプションで指定されたパス名によって変わります。 - このファイルは、 空白で区切られたネットワーク指定とネットマスクのエントリからなっていて、 - # で始まる行はコメントとみなされます。 - 簡単な securenets ファイルの例を以下に示します。 + 上記のパス名は + オプションで指定されたパス名によって変わります。このファイルは、 + 空白で区切られたネットワーク指定とネットマスクのエントリからなっていて、 + # で始まる行はコメントとみなされます。 + 簡単な securenets ファイルの例を以下に示します。 # allow connections from local host -- mandatory @@ -2129,48 +3948,53 @@ nis_client_enable="YES" # between 10.0.0.0 to 10.0.15.255 10.0.0.0 255.255.240.0 - ypserv が上記のルールの一つと合致するアドレスからの要求を受け取った場合、 - 処理は通常に行なわれます。 - もしアドレスがルールに合致しなければ、 - その要求は無視されて警告メッセージがログに記録されます。 - また、 /var/yp/securenets が存在しない場合、 - ypserv はすべてのホストからの接続を受け入れます。 + &man.ypserv.8; + が上記のルールの一つと合致するアドレスからの要求を受け取った場合、 + 処理は正常に行なわれます。 + もしアドレスがルールに合致しなければ、 + その要求は無視されて警告メッセージがログに記録されます。 + また /var/yp/securenets が存在しない場合、 + ypserv はすべてのホストからの接続を受け入れます。 - ypserv は Wietse Venema 氏による + ypserv は Wietse Venema 氏による tcpwrapper パッケージもサポートしています。 - そのため、 /var/yp/securenets の代わりに - tcpwrapper の設定ファイルを使ってアクセス制御を行なうことも可能です。 - + そのため /var/yp/securenets の代わりに + tcpwrapper + の設定ファイルを使ってアクセス制御を行なうことも可能です。 これらのアクセス制御機能は一定のセキュリティを提供しますが、 - どちらも特権ポートのテストのような IP spoofing - 攻撃に対して脆弱です。 - すべての NIS 関連のトラフィックはファイアウォールでブロックされるべきです。 - - /var/yp/securenets - を使っているサーバは、 - 古風な TCP/IP 実装を持つ正しいクライアントへのサービスに失敗することがあります。 - これらの実装の中にはブロードキャストのホストビットをすべて 0 でセットしてしまったり + どちらも特権ポートのテストのような IP spoofing + 攻撃に対して脆弱です。すべての NIS + 関連のトラフィックはファイアウォールでブロックされるべきです。 + + /var/yp/securenets + を使っているサーバは、古い TCP/IP + 実装を持つ正当なクライアントへのサービスに失敗することがあります。 + これらの実装の中にはブロードキャストのホストビットをすべて + 0 でセットしてしまったり、 ブロードキャストアドレスの計算でサブネットマスクを見落としてしまったりするものがあります。 - これらの問題はクライアントの設定を正しく行なうことで修正できますが、 - 他の問題は問題となっているクライアントシステムの撤去か - /var/yp/securenets の放棄が必要です。 - - このような古風な TCP/IP の実装を持つサーバで - /var/yp/securenets - を使うことは非常に悪い考えであり、 - あなたのネットワークの大部分において - NIS の機能を失うことになるでしょう。 - - tcpwrapper - パッケージの使用はあなたの NIS サーバのレイテンシ (遅延) を増加させます。 - 追加された遅延は、 特に混雑したネットワークや遅い - NIS サーバでクライアントプログラムのタイムアウトを引き起こすに十分なだけ長いでしょう。 - 一つ以上のクライアントシステムがこれらの兆候を示したなら、 - あなたは問題となっているクライアントシステムを - NIS スレーブサーバにして自分自身に結び付くように強制すべきです。 + これらの問題にはクライアントの設定を正しく行なえば解決できるものもありますが、 + 問題となっているクライアントシステムを引退させるか、 + /var/yp/securenets + を使わないようにしなければならないものもあります。 + + このような古風な TCP/IP の実装を持つサーバで + /var/yp/securenets + を使うことは実に悪い考えであり、 + あなたのネットワークの大部分において + NIS の機能喪失を招きます。 + + tcpwrapper + tcpwrapper + パッケージを使うとあなたの NIS サーバのレイテンシ (遅延) + が増加します。特に混雑したネットワークや遅い NIS + サーバでは、遅延の増加によって、 + クライアントプログラムのタイムアウトが起こるかもしれません。 + 一つ以上のクライアントシステムがこれらの兆候を示したなら、 + あなたは問題となっているクライアントシステムを + NIS スレーブサーバにして自分自身に結び付くように強制すべきです。 @@ -2178,26 +4002,27 @@ nis_client_enable="YES" 何人かのユーザのログオンを遮断する わたしたちの研究室には basie という、 - 教員専用のマシンがあります。 わたしたちはこのマシンを - NIS ドメインの外に出したくないのですが、 - マスタ NIS サーバの passwd - ファイルには教員と学生の両方が載っています。 - どうしたらいいでしょう? + 教員専用のマシンがあります。わたしたちはこのマシンを + NIS ドメインの外に出したくないのですが、 + マスタ NIS サーバの passwd + ファイルには教員と学生の両方が載っています。 + どうしたらいいでしょう? 当該人物が NIS のデータベースに載っていても、 - そのユーザがマシンにログオンできないようにする方法があります。 - そうするには、 -username を - クライアントマシンの /etc/master.passwd - ファイルの末尾に付け足します。 - username - はあなたがログインさせたくないと思っているユーザのユーザ名です。 - これは vipw で行うべきです。 - vipw は /etc/master.passwd - への変更をチェックし、 編集終了後パスワードデータベースを再構築します。 - たとえば、 ユーザ bill が basie - にログオンするのを防ぎたいなら、 以下のようにします。 - - basie&prompt.root; vipw + そのユーザがマシンにログオンできないようにする方法があります。 + そうするには + -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 @@ -2225,201 +4050,206 @@ nobody:*:65534:65534::0:0:Unprivileged user:/nonexistent:/sbin/nologin basie&prompt.root; - - netgroups の利用 - - netgroups の部分の原作: - Udo Erdelhoff ue@nathan.ruhr.de. - 2000 年 7 月. - - 前節までに見てきた手法は, - 極めて少ないユーザ/マシン向けに個別のルールを必要としている場合にはうまく機能します。 - しかし大きなネットワークでは, - ユーザに触られたくないマシンへログオンを防ぐのを忘れるでしょうし, - そうでなくとも各マシンを個別に設定して回らなければならず、 + + + + + Udo + Erdelhoff + 寄稿: + + + + ネットグループの利用 + ネットグループ + + 前節までに見てきた手法は、 + 極めて少ないユーザ/マシン向けに個別のルールを必要としている場合にはうまく機能します。 + しかし大きなネットワークでは、 + ユーザに触られたくないマシンへログオンを防ぐのを + 忘れるでしょう し、 + そうでなくとも各マシンを個別に設定して回らなければならず、 集中管理という NIS の恩恵を失ってしまいます。 - NIS の開発者はこの問題を netgroups - と呼ばれる方法で解決しました。 - 彼らの目的とその意味合いは UNIX - のファイルシステムで使われている一般的なグループと比較できます。 - 主たる相違は数字による id を欠いていることと、 - ネットグループを定義するのにユーザアカウントと別のネットグループの、 - 両方を含められる機能です。 + NIS の開発者はこの問題を ネットグループ + と呼ばれる方法で解決しました。 + その目的と意味合いは &unix; + のファイルシステムで使われている一般的なグループと比較できます。 + 主たる相違は数値 ID が存在しないことと、 + ユーザアカウントと別のネットグループを含めたネットグループを定義できることです。 ネットグループは百人/台以上のユーザとマシンを含む、 - 大きく複雑なネットワークを扱うために開発されました。 - もし、 あなたがこのような状況を扱わなければならないなら便利なものなのですが、 - この複雑さは単純な例でネットグループの説明をすることをほとんど不可能にしています。 - この部の残りで使われている例は、 この問題を実演しています。 - - あなたの行なった、 研究室への NIS - の導入の成功が上司の目に止ったとしましょう。 - あなたの次の仕事は、 - あなたの NIS - ドメインをキャンパスの他のいくつものマシンを覆うものへ拡張することです。 - 二つの表は新しいユーザと新しいマシンの名前とその説明を含んでいます。 + 大きく複雑なネットワークを扱うために開発されました。 + あなたがこのような状況を扱わなければならないなら便利なものなのですが、 + 一方で、この複雑さは単純な例でネットグループの説明をすることをほとんど不可能にしています。 + この節の残りで使われている例は、この問題を実演しています。 + + あなたの行なった、 + 研究室への NIS の導入の成功が上司の目に止ったとしましょう。 + あなたの次の仕事は、あなたの NIS + ドメインをキャンパスの他のいくつものマシンを覆うものへ拡張することです。 + 二つの表は新しいユーザと新しいマシンの名前とその説明を含んでいます。 - - - - ユーザの名前 - 説明 - - - - - - alpha, beta - IT 学科の通常の職員 - - - - charlie, delta - IT 学科の新しい見習い - - - - echo, foxtrott, golf, ... - 一般の職員 - - - - able, baker, ... - まだインターン - - - + + + + ユーザの名前 + 説明 + + + + + + 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 - 重要なデータの入っていないひどく古いマシン。 - インターンでもこのマシンの使用を許されます。 - - - + war, death, famine, pollution + 最も重要なサーバ。IT 職員だけがログオンを許されます。 + + + + pride, greed, envy, wrath, lust, sloth + あまり重要でないサーバ。IT 学科の全員がログオンを許されます。 + + + + one, two, three, four, ... + 通常のワークステーション。 + 本当の 職員だけがログオンを許されます。 + + + + trashcan + 重要なデータの入っていないひどく古いマシン。 + インターンでもこのマシンの使用を許されます。 + + + もしあなたがこの手の制限を各ユーザを個別にブロックする形で実装するなら、 - あなたはそのシステムにログオンすることが許されていない各ユーザについて - -user という 1 行を、 - 各システムのパスワードに追加しなければならなくなるでしょう。 - もしあなたが 1 エントリでも忘れればトラブルに巻き込まれてしまいます。 + あなたはそのシステムにログオンすることが許されていない各ユーザについて + -user という 1 行を、各システムの + passwd に追加しなければならなくなるでしょう。 + もしあなたが 1 エントリでも忘れればトラブルに巻き込まれてしまいます。 最初のセットアップの時にこれを正しく行えるのはありえることかも知れませんが、 - 遂には連日の業務の間に例の行を追加し忘れてしまうでしょう。 - 結局マーフィーは楽観主義者だったのです。 + 遂には連日の業務の間に例の行を追加し忘れてしまうでしょう。 + 結局マーフィーは楽観主義者だったのです。 この状況をネットグループで扱うといくつかの有利な点があります。 - 各ユーザを別個に扱う必要はなく、 - ユーザを一つ以上のネットグループに割り当て、 - ネットグループの全メンバのログインを許可したり禁止したりすることができます。 - 新しいマシンを追加するときはネットグループへログインの制限を定義するだけ、 + 各ユーザを別個に扱う必要はなく、 + ユーザを一つ以上のネットグループに割り当て、 + ネットグループの全メンバのログインを許可したり禁止したりすることができます。 + 新しいマシンを追加するときはネットグループへログインの制限を定義するだけ、 新しいユーザを追加するときはそのユーザを一つ以上のネットグループへ追加するだけで、 - それぞれ行なうことができます。 - これらの変更は互いに独立なので、 - ユーザとマシンの組合わせをどうするか + それぞれ行なうことができます。 + これらの変更は互いに独立なので、 + ユーザとマシンの組合わせをどうするか は存在しなくなります。 - あなたの NIS のセットアップが注意深く計画されていれば、 - マシンへのアクセスを認めるにも拒否するにも中心の設定をたった一カ所変更するだけです。 + あなたの NIS のセットアップが注意深く計画されていれば、 + マシンへのアクセスを認めるにも拒否するにも中心の設定をたった一カ所変更するだけです。 - 最初のステップは NIS マップ netgroup の初期化です。 - FreeBSD の ypinit はこのマップをデフォルトで作りませんが、 - その NIS の実装はそれが作られさえすればそれをサポートするものです。 - 空のマップを作るには、 単に + 最初のステップは NIS マップネットグループの初期化です。 + FreeBSD の &man.ypinit.8; はこのマップをデフォルトで作りませんが、 + その NIS の実装はそれが作られさえすればそれをサポートするものです。 + 空のマップを作るには、単に ellington&prompt.root; vi /var/yp/netgroup とタイプして内容を追加していきます。 - わたしたちの例では、 すくなくとも - IT 職員、 IT 見習い、 一般職員、 インターンの - 4 つのネットグループが必要です。 + わたしたちの例では、すくなくとも 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) + (,golf,test-domain) INTERNS (,able,test-domain) (,baker,test-domain) - IT_EMP、 IT_APP - 等はネットグループの名前です。 - それぞれの括弧で囲まれたグループが一人以上のユーザアカウントをそれに登録しています。 - グループの 3 つのフィールドは + IT_EMP, IT_APP + 等はネットグループの名前です。 + それぞれの括弧で囲まれたグループが一人以上のユーザアカウントをそれに登録しています。 + グループの 3 つのフィールドは - - その記述が有効なホスト(群)の名称。 - ホスト名を特記しなければそのエントリはすべてのホストで有効です。 + + その記述が有効なホスト (群) の名称。 + ホスト名を特記しなければそのエントリはすべてのホストで有効です。 もしあなたがホスト名を特記するなら、 - あなたは闇と恐怖と全き混乱の領域となるでしょう。 - - - - このネットグループに所属するアカウントの名称。 - - - - そのアカウントの NIS ドメイン。 - もしあなたが一つ以上の NIS ドメインの不幸な仲間なら、 - あなたは他の NIS - ドメインからあなたのネットグループにアカウントを導入できます。 - + あなたは闇と恐怖と全き混乱の領域に入り込んでしまうでしょう。 + + + + このネットグループに所属するアカウントの名称。 + + + + そのアカウントの NIS ドメイン。 + もしあなたが一つ以上の NIS ドメインの不幸な仲間なら、 + あなたは他の NIS + ドメインからあなたのネットグループにアカウントを導入できます。 + - 各フィールドには、 ワイルドカードが使えます。 - 詳細は &man.netgroup.5; をご覧ください。 + 各フィールドには、ワイルドカードが使えます。 + 詳細は &man.netgroup.5; をご覧ください。 - 8 文字以上のネットグループ名は、 - 特にあなたの NIS - ドメインで他のオペレーティングシステムを走らせているときは使うべきではありません。 - 名前には大文字小文字の区別があります。 + ネットグループ + 8 文字以上のネットグループ名は、特にあなたの NIS + ドメインで他のオペレーティングシステムを走らせているときは使うべきではありません。 + 名前には大文字小文字の区別があります。 そのためネットグループ名に大文字を使う事は、 - ユーザやマシン名とネットグループ名を区別する簡単な方法です。 + ユーザやマシン名とネットグループ名を区別する簡単な方法です。 - NIS クライアントの中には (FreeBSD 以外で) - 多数のエントリを扱えないものもあります。 - たとえば SunOS の古い版では 15 - 以上のエントリを含むネットグループはトラブルを起こします。 - この制限は 15 ユーザ以下のサブ・ネットグループをいくつも作り、 - 本当のネットグループはこのサブ・ネットグループからなるようにすることで回避できます。 + (FreeBSD 以外の) NIS クライアントの中には + 多数のエントリを扱えないものもあります。 + たとえば &sunos; の古い版では 15 以上の + エントリ + を含むネットグループはトラブルを起こします。 + この制限は 15 ユーザ以下のサブネットグループをいくつも作り、 + 本当のネットグループはこのサブネットグループからなるようにすることで回避できます。 - BIGGRP1 (,joe1,domain) (,joe2,domain) (,joe3,domain) [...] + BIGGRP1 (,joe1,domain) (,joe2,domain) (,joe3,domain) [...] BIGGRP2 (,joe16,domain) (,joe17,domain) [...] -BIGGRP3 (,joe32,domain) (,joe33,domain) +BIGGRP3 (,joe31,domain) (,joe32,domain) BIGGROUP BIGGRP1 BIGGRP2 BIGGRP3 - 単一のネットグループに 225 人以上のユーザをいれたいときは、 - このやり方を繰り返すことができます。 + 単一のネットグループに 225 人以上のユーザをいれたいときは、 + このやり方を繰り返すことができます。 新しい NIS マップの有効化と配布は簡単です。 @@ -2428,24 +4258,24 @@ BIGGROUP BIGGRP1 BIGGRP2 BIGGRP3 ellington&prompt.root; make これで新しい 3 つの NIS マップ - netgroup、 - netgroup.byhost - netgroup.byuser ができるはずです。 + netgroup, + netgroup.byhost, + netgroup.byuser ができるはずです。 新しい NIS マップが利用できるか確かめるには - &man.ypcat.1; を使います。 + &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 番目のコマンドはユーザに対するネットグループのリストを得るのに使えます。 + の内容に似ているはずです。 + 2 番目のコマンドはホスト別のネットグループを作っていなければ出力されません。 + 3 番目のコマンドはユーザに対するネットグループのリストを得るのに使えます。 クライアント側の設定は非常に簡単です。 - サーバ war を設定するには、 - &man.vipw.8; を実行して以下の行 + サーバ war を設定するには、 + &man.vipw.8; を実行して以下の行 +::::::::: @@ -2455,109 +4285,110 @@ ellington&prompt.user; ypcat -k netgroup.byuser に入れ替えるだけです。 - 今、 ネットグループ IT_EMP - で定義されたユーザのデータだけが war - のパスワードデータベースに読み込まれ、 - そのユーザだけがログインを許されています。 + 今、ネットグループ IT_EMP + で定義されたユーザのデータだけが war + のパスワードデータベースに読み込まれ、 + そのユーザだけがログインを許されています。 残念ながらこの制限はシェルの ~ の機能や、 - ユーザ名やユーザの数値 id の変換ルーチンにも影響します。 - 言い換えれば、 - cd ~user はうまく動かず、 - ls -l はユーザ名のかわりに数値の id を表示し - find . -user joe -print は - No such user で失敗します。 - これを避けるためには、 - すべてのユーザのエントリをサーバにログインすることを許さずに読み込むことが必要です。 + ユーザ名や数値の ユーザ ID の変換ルーチンにも影響します。 + つまり、 + cd ~user はうまく動かず、 + ls -l はユーザ名のかわりに数値の ID を表示し + find . -user joe -print は + No such user で失敗します。 + これを避けるためには、すべてのユーザのエントリを + サーバにログインすることを許さずに + 読み込まなければなりません。 これはもう一行を /etc/master.passwd - に追加することで実現できます。 その行は - +:::::::::/sbin/nologin を含んでおり、 - すべてのエントリを読み込むが、 読み込まれたエントリのシェルは - /sbin/nologin で置き換えられる - ということを意味します。 passwd エントリの他のフィールドを + に追加することで実現できます。その行は以下の + + +:::::::::/sbin/nologin を含んでおり、 + これは + すべてのエントリを読み込むが、読み込まれたエントリのシェルは + /sbin/nologin で置き換えられる + ということを意味します。passwd エントリの他のフィールドを /etc/master.passwd - の既定値から置き換えることも可能です。 + の既定値から置き換えることも可能です。 - +:::::::::/sbin/nologin の行が - +@IT_EMP::::::::: - の行より後ろに位置することに注意してください。 - さもないと NIS から読み込まれた全ユーザが /sbin/nologin - をログインシェルとして持つことになります。 + +:::::::::/sbin/nologin の行が + +@IT_EMP::::::::: + の行より後ろに位置することに注意してください。 + さもないと NIS から読み込まれた全ユーザが /sbin/nologin + をログインシェルとして持つことになります。 - この変更の後では、 新しい職員が IT 学科に参加しても - NIS マップを一つ書き換えるだけで済みます。 - 同様にして、 あまり重要でないサーバのローカルの - /etc/master.passwd - のかつての - +::::::::: - 行を以下のように置き換えます。 + この変更の後では、新しい職員が IT 学科に参加しても + NIS マップを一つ書き換えるだけで済みます。 + 同様にして、あまり重要でないサーバのローカルの + /etc/master.passwd のかつての + +::::::::: 行を以下のように置き換えます。 +@IT_EMP::::::::: +@IT_APP::::::::: +:::::::::/sbin/nologin - この行は、 一般のワークステーションでは以下のようになります。 + この行は、一般のワークステーションでは以下のようになります。 +@IT_EMP::::::::: +@USERS::::::::: +:::::::::/sbin/nologin これでしばらく順調に運用していましたが、 - 数週間後、 ポリシに変更がありました。 - IT 学科はインターンを雇い始め、 IT - インターンは一般のワークステーションと余り重要ではないサーバを使うことが許され、 + 数週間後、ポリシに変更がありました。 + IT 学科はインターンを雇い始め、IT + インターンは一般のワークステーションと余り重要ではないサーバを使うことが許され、 IT 見習いはメインサーバへのログインが許されました。 - あなたは新たなネットグループ IT_INTERN を追加して新しい IT - インターンたちをそのグループに登録し、 - すべてのマシンの設定を変えて回ることにしました。 + あなたは新たなネットグループ IT_INTERN を追加して新しい IT + インターンたちをそのグループに登録し、 + すべてのマシンの設定を変えて回ることにしました。 古い諺にこうあります。 - 集中管理における過ちは、 大規模な混乱を導く。 + 集中管理における過ちは、大規模な混乱を導く。 いくつかのネットグループから新たなネットグループを作るという - NIS の機能は、 このような状況に対処するために利用できます。 - その方法の一つは、 役割別のネットグループを作ることです。 - たとえば、 重要なサーバへのログイン制限を定義するために - BIGSRV というネットグループを作り + NIS の機能は、このような状況に対処するために利用できます。 + その方法の一つは、役割別のネットグループを作ることです。 + たとえば、重要なサーバへのログイン制限を定義するために + BIGSRV というネットグループを作り あまり重要ではないサーバへは SMALLSRV - というネットグループを、 そして一般のワークステーション用に - USERBOX という第 3 のネットグループを - 作ることができます。 これらのネットグループの各々は、 - 各マシンにログインすることを許されたネットグループを含みます。 + というネットグループを、そして一般のワークステーション用に + 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 + 上述したようなポリシの変更を扱うことができるもうひとつの方法です。 + このシナリオでは、各マシンの /etc/master.passwd は + + で始まる 2 つの行からなります。 + 最初のものはそのマシンへのログインを許されたアカウントを追加するもので、 + 2 番目はその他のアカウントを /sbin/nologin をシェルとして追加するものです。 - マシン名をすべて大文字で記述したものをネットグループの名前として使うのは良いやり方です。 - 言い換えれば、 件の行は次のようになるはずです。 + マシン名をすべて大文字で記述したものをネットグループの名前として使うのは良い考えです。 + 言い換えれば、件の行は次のようになるはずです。 +@BOXNAME::::::::: +:::::::::/sbin/nologin - 一度、 各マシンに対してこの作業を済ませてしまえば、 - 二度とローカルの /etc/master.passwd - を編集する必要がなくなります。 - 以降のすべての変更は NIS マップの編集で扱うことができます。 - 以下はこのシナリオに対応するネットグループマップに、 - いくつかの便利な定義を追加した例です。 + 一度、各マシンに対してこの作業を済ませてしまえば、 + 二度とローカルの /etc/master.passwd + を編集する必要がなくなります。 + 以降のすべての変更は NIS マップの編集で扱うことができます。 + 以下はこのシナリオに対応するネットグループマップに、 + いくつかの便利な定義を追加した例です。 # Define groups of users first IT_EMP (,alpha,test-domain) (,beta,test-domain) @@ -2595,55 +4426,54 @@ ONE SECURITY TWO (,hotel,test-domain) # [...more groups to follow] - もしユーザアカウントを管理するデータベースの類を使っているなら、 - あなたはデータベースのレポートツールからマップの最初の部分を作れるようにしてあるべきです。 - この方法なら、 新しいユーザは自動的にマシンにアクセスできるでしょう。 + もしユーザアカウントを管理するのにデータベースの類を使っているなら、 + データベースのレポートツールからマップの最初の部分を作れるようにするべきです。 + そうすれば、新しいユーザは自動的にマシンにアクセスできるでしょう。 最後に使用上の注意を: - マシン別のネットグループを使うことが常に賢明というわけではありません。 - あなたが数ダースから数百の同一の環境のマシンを学生の研究室に配置しているのならば、 - NIS マップのサイズを手頃な範囲に押さえるために、 - マシン別のネットグループのかわりに役割別のネットグループを使うべきです。 + マシン別のネットグループを使うことが常に賢明というわけではありません。 + あなたが数ダースから数百の同一の環境のマシンを学生の研究室に配置しているのならば、 + NIS マップのサイズを手頃な範囲に押さえるために、 + マシン別のネットグループのかわりに役割別のネットグループを使うべきです。 忘れてはいけないこと - NIS 環境にある今、 今までとは違ったやり方が必要なことが - 2、3 あります。 + NIS 環境にある今、 + 今までとは違ったやり方が必要なことがいくつかあります。 - - 研究室にユーザを追加するときは、 - それをマスター NIS サーバにだけ追加しなければならず、 - さらにNIS マップを再構築することを忘れてはいけません。 - これを忘れると新しいユーザは NIS マスタ以外のどこにもログインできなくなります。 - たとえば、 新しくユーザ jsmith - をラボに登録したいときは以下のようにします。 - - &prompt.root; pw useradd jsmith + + 研究室にユーザを追加するときは、それをマスター 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 のマスタとスレーブをセキュアに、 - そして機能停止時間を最短に保ってください。 + pw useradd jsmith のかわりに + adduser jsmith を使うこともできます。 + + + 管理用アカウントを NIS マップから削除してください。 + 管理用アカウントやパスワードを、 + それらのアカウントへアクセスさせてはいけないユーザが居るかも知れないマシンにまで伝えて回りたいとは思わないでしょう。 + + + NIS のマスタとスレーブをセキュアに、 + そして機能停止時間を最短に保ってください。 もし誰かがこれらのマシンをクラックしたり、 - あるいは単に電源を落としたりすると、 - 彼らは実質的に多くの人を研究室へログインできなくしてしまえます。 + あるいは単に電源を落としたりすると、 + 彼らは実質的に多くの人を研究室へログインできなくしてしまえます。 - これはどの集中管理システムにとっても第一の弱点で、 - そして最も重要な弱点でしょう。 - あなたの NIS サーバを守らなければ怒れるユーザと対面することになるでしょう! - + これはどの集中管理システムにとってももっとも大きな弱点でしょう。 + あなたの NIS サーバを守らなければ怒れるユーザと対面することになるでしょう! + @@ -2651,264 +4481,310 @@ TWO (,hotel,test-domain) NIS v1 との互換性 FreeBSD の - ypserv は、 - NIS v1 クライアントを部分的にサポートします。 - FreeBSD の NIS 実装は NIS v2 プロトコルのみを使用していますが、 - ほかの実装では、 古いシステムとの下位互換性を持たせるため - v1 プロトコルをサポートしているものもあります。 - そのようなシステムに付いている - ypbind デーモンは、 - 必要がないにもかかわらず NIS v1 - のサーバとの結合を成立させようとします(しかも - v2 サーバからの応答を受信した後でも、 - ブロードキャストをし続けるかも知れません)。 - FreeBSD の ypserv は、 - クライアントからの通常のリクエストはサポートしていますが、 - v1 のマップ転送リクエストはサポートしていないことに注意してください。 - つまり FreeBSD の ypserv を、 - v1 だけをサポートするような古い NIS サーバと組み合わせて - マスターやスレーブサーバとして使うことはできません。 - 幸いなことに、 現在、 そのようなサーバが使われていることは - ほとんどないでしょう。 + ypserv は、 + NIS v1 クライアントを部分的にサポートしています。 + FreeBSD の NIS 実装は NIS v2 プロトコルのみを使用していますが、 + ほかの実装では、古いシステムとの下位互換性を持たせるため + v1 プロトコルをサポートしているものもあります。 + そのようなシステムに付いている + ypbind デーモンは、 + 必要がないにもかかわらず NIS v1 + のサーバとの結合を成立させようとします + (しかも v2 サーバからの応答を受信した後でも、 + ブロードキャストをし続けるかも知れません)。 + FreeBSD の ypserv は、 + クライアントからの通常のリクエストはサポートしていますが、 + v1 のマップ転送リクエストはサポートしていないことに注意してください。 + つまり FreeBSD の ypserv を、 + v1 だけをサポートするような古い NIS サーバと組み合わせて + マスターやスレーブサーバとして使うことはできません。 + 幸いなことに、現在、そのようなサーバが使われていることは + ほとんどないでしょう。 - + NIS クライアントとしても動作している NIS サーバ - 複数のサーバが存在し、 サーバ自身が NIS - クライアントでもあるようなドメインで ypserv が実行される場合には、 - 注意が必要です。 - 一般的に良いとされているのは、 - 他のサーバと結合をつくるようにブロードキャストパケットの送信をさせるのではなく、 - サーバをそれ自身に結合させることです。 - もし、 サーバ同士が依存関係を持っていて、 一つのサーバが停止すると、 - 奇妙なサービス不能状態に陥ることがあります。 - その結果、 すべてのクライアントはタイムアウトを起こして - 他のサーバに結合しようと試みますが、 - これにかかる時間はかなり大きく、 - サーバ同士がまた互いに結合してしまったりすると、 - サービス不能状態はさらに継続することになります。 + 複数のサーバが存在し、サーバ自身が NIS + クライアントでもあるようなドメインで + ypserv が実行される場合には注意が必要です。 + 一般的に良いとされているのは、 + 他のサーバと結合をつくるようにブロードキャストさせるのではなく、 + サーバをそれ自身に結合させることです。 + もし、サーバ同士が依存関係を持っていて、一つのサーバが停止すると、 + 奇妙なサービス不能状態に陥ることがあります。 + その結果、すべてのクライアントはタイムアウトを起こして + 他のサーバに結合しようと試みますが、 + これにかかる時間はかなり大きく、 + サーバ同士がまた互いに結合してしまったりすると、 + サービス不能状態はさらに継続することになります。 - ypbind に - オプションフラグを指定して実行することで、 - ホストを特定のサーバに結合することが可能です。 - + ypbind に + オプションフラグを指定して実行することで、 + ホストを特定のサーバに結合することが可能です。 + NIS サーバを再起動するたびに、これを手動で行いたくないなら、 + 次の行を /etc/rc.conf + に追加すればよいでしょう。 + + nis_client_enable="YES" # run client stuff as well +nis_client_flags="-S NIS domain,server" + + 詳細については &man.ypbind.8; を参照してください。 - libscrypt 対 libdescrypt - + パスワード形式 + + NIS + パスワード形式 + - 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 を使わなければいけなくなるでしょう。 + NIS を実装しようする人の誰もがぶつかる問題の一つに、 + パスワード形式の互換性があります。 + NIS サーバが DES 暗号化パスワード使っている場合には、 + 同様に DES を使用しているクライアントしか対応できません。 + たとえば &solaris； の NIS クライアントがネットワーク内にある場合、 + ほぼ確実に DES 暗号化パスワードを使用しなければならないでしょう。 + サーバとクライアントがどのライブラリを使用しているかは、 + /etc/login.conf を確認してください。 + ホストが DES 暗号パスワードを使用するように設定されている場合、 + default + クラスには以下のようなエントリが含まれます。 + + default:\ + :passwd_format=des:\ + :copyright=/etc/COPYRIGHT:\ + [Further entries elided] + + passwd_format + 特性について他に利用可能な値は + blf および md5 + (それぞれ Blowfish および MD5 暗号化パスワード) です。 + + /etc/login.conf を変更したときは、 + ログイン特性データベースも再構築しなければなりません。 + これは root + 権限で下記のようにコマンドを実行すればできます。 + + &prompt.root; cap_mkdb /etc/login.conf + + すでに /etc/master.passwd + 内に記録されているパスワード形式は、 + ログイン特性データベースが再構築された後、 + ユーザが彼らのパスワードをはじめて変更するまで変更されないでしょう。 + + 次に、 + パスワードが選択した形式で暗号化されることを確実にするために、 + さらに /etc/auth.conf 内の + crypt_default において、 + 選択したパスワード形式に高い優先順位がついていることも確認してください。 + そうするためには、選択した形式をリストの先頭に置いてください。 + たとえば DES 暗号化されたパスワードを使用するときは、 + エントリは次のようになります。 + + crypt_default = des blf md5 + + &os; 上の各 + NIS サーバおよびクライアントにおいて上記の手順に従えば、 + ネットワーク内でどのパスワード形式が使用されるかが + それらのマシン間で整合されているということを確信できます。 + NIS クライアント上で問題があれば、 + ここから問題となりそうな部分を探すと良いでしょう。 + 覚えておいてください: + 異種混在ネットワークに NIS サーバを配置したいときには、 + DES が最大公約数的な標準となるでしょうから、 + すべてのシステムで DES を使用しなければならないかもしれません。 - + + + + + Greg + Sutter + 原作: + + + DHCP - 原作: &a.gsutter;, 2000 年 3 月. - - DHCPとは何でしょう? - - - DHCP (Dynamic Host Configuration Protocol) は、 システムをネットワー - クに接続するだけで、 ネットワークでの通信に必要な情報を入手するこ - とができる仕組みです。 FreeBSD では、 ISC (Internet Software - Consortium) による DHCP の実装を使用しています。 したがって、 ここで - の説明のうち、 実装によって異なる部分は ISC のもの用になっています。 - + DHCP とは何でしょうか? + + ダイナミックホストコンフィギュレーションプロトコル + (DHCP) + DHCP + + + インターネットソフトウェアコンソーシアム (ISC) + + + DHCP (Dynamic Host Configuration Protocol) は、 + システムをネットワークに接続するだけで、 + ネットワークでの通信に必要な情報を入手することができる仕組みです。 + FreeBSD では ISC (Internet Software Consortium) による + DHCP の実装を使用しています。したがって、 + ここでの説明のうち実装によって異なる部分は ISC のもの用になっています。 この節で説明していること - - ハンドブックのこの節では DHCP システムの、 FreeBSD に組み込まれてい - る部分についてだけ説明しています。 ですから、 サーバについては説明 - していません。 後の節で紹介するリファレンスに加えて、 - DHCP のマニュアルページも有力な参考になることでしょう。 + この節は ISC DHCP + システムのクライアント側およびサーバ側の構成要素の両方について説明します。 + クライアント側のプログラムである dhclient は + FreeBSD のベースシステム内に含まれています。そして、サーバ側の要素は + net/isc-dhcp3 port + から利用可能です。下記の説明の他に、 + &man.dhclient.8;, &man.dhcp-options.5; および &man.dhclient.conf.5; + マニュアルページが役にたつ情報源です。 DHCP の動作 - - - クライアントとなるマシン上で DHCP のクライアントである dhclient を実 - 行すると、 まず設定情報の要求をブロードキャストします。 デフォルト - では、 このリクエストには UDP のポート 68 を使用します。 サーバは UDP の - ポート 67 で応答し、 クライアントの IP アドレスと、 ネットマスクやルー - タ、 DNS サーバなどの関連する情報を提供します。 これらの情報の - すべては DHCP の「リース」の形で送られ、 DHCP サーバ管理者によって決 - められたある一定の時間内でのみ有効になります。 これによって、 ネッ - トワークに存在しなくなったホストの IP アドレスは自動的に回収される - ことになります。 - - - - DHCP クライアントはサーバから非常に多くの情報を取得することができます。 - &man.dhcp-options.5; に、 その非常に大きなリストが載っています。 + UDP + クライアントとなるマシン上で、 + 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 のすべての配布 - に含まれています。 + FreeBSD は ISC の DHCP クライアントである + dhclient を完全に組み込んでいます。 + DHCP クライアントはインストーラと基本システムの両方で提供されています。 + ですから DHCP サーバを走らせているネットワーク上ではネットワーク関係の設定についての詳細な知識は必要になりません。 + dhclient は、3.2 以降のすべての + FreeBSD の配布物に含まれています。 + + sysinstall + + + DHCP は sysinstall + で対応されており、sysinstall でのネットワークインタフェイス設定の際は、 + このインタフェイスの設定として DHCP を試してみますか? + (Do you want to try DHCP configuration of this interface?) + という質問が最初になされます。 + これに同意することで dhclient が実行され、 + それが成功すればネットワークの設定情報は自動的に取得されます。 + + システム起動時に DHCP を使ってネットワーク情報を取得するように + するには、次の二つを行なう必要があります。 + + DHCP + 必要条件 + + + + bpf + デバイスがカーネルに組み込まれていることを確認します。 + これを組み込むには、カーネルコンフィグレーションファイルに + pseudo-device bpf + という行を追加し、カーネルを再構築します。 + カーネルの構築に関する詳細は、 + を参照してください。 + + bpf デバイスは、 + FreeBSD にはじめから用意されている + GENERIC カーネルに組み込まれていますので、 + 自分で設定を変えたカスタムカーネルを使っているのでなければ、 + DHCP を動作させるためにカーネルを再構築する必要はありません。 + + + セキュリティに関心のある方向けに注意しておきます。 + bpf + デバイスは、パケットスニファ (盗聴プログラム) + を動作させることができる + (ただし root 権限が必要) + デバイスです。 + bpf は DHCP を動作させるために + かならず必要ですが、 + セキュリティが非常に重要な場面では + DHCP をいつか使うかもしれないというだけで + bpf + デバイスをカーネルに追加すべきではないでしょう。 + + - - DHCP は sysinstall でサポートされてお - り、 sysinstall でのネットワークインタフェイス設定の際は、 「こ - のインタフェイスの設定として DHCP を試してみますか?」という質問 - が最初になされます。 これに同意することで dhclient が実行さ - れ、 それが成功すればネットワークの設定情報は自動的に取得されま - す。 + + /etc/rc.conf を編集して、 + 次の行を追加してください。 - システム起動時に、 DHCP を使ってネットワーク情報を取得するように - するには、 次の 2 つのステップを行なう必要があります。 + ifconfig_fxp0="DHCP" - - - 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" + + + で説明されているように fxp0 の部分を、 + 動的に設定したいインタフェースの名前で置き換えることを忘れないようにしてください。 + + + もし、使っている dhclient + の場所を変更していたり、dhclient + にフラグを渡したい場合は、同様に下のように書き加えてください。 + + dhcp_program="/sbin/dhclient" dhcp_flags="" - + - - DHCP サーバである dhcpd は、 ports - collectionに isc-dhcp2 として収録されていま - す。 この port はクライアント、 サーバ、 リレーエージェントから成 - る ISC の DHCP 配布物をすべて含んでいます。 - + + DHCP + サーバ + + DHCP サーバである dhcpd は、Ports Collection に + isc-dhcp2 として収録されています。 + この port はクライアント、サーバ、リレーエージェント、文書から成る + ISC の DHCP 配布物をすべて含んでいます。 関連ファイル - + + 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; で説明されていますが、 これを編集する - 必要はほとんど発生しないでしょう。 + /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; にもうすこし詳 - しい解説があります。 - - + /var/db/dhclient.leases + DHCP クライアントはこのファイルに有効なリースのデータベースをログとして記録します。 + &man.dhclient.leases.5; にもうすこし詳しい解説があります。 + @@ -2916,11 +4792,2842 @@ dhcp_flags="" 参考になる文献 DHCP のプロトコルは - RFC 2131 - に完全に記述されています。 また、 - dhcp.org - にも有用な - 情報源が用意されています。 + RFC 2131 + に完全に記述されています。また + dhcp.org + にも有用な情報源が用意されています。 + + + + DHCP サーバのインストールと設定 + + + この節で説明していること + + この節は DHCP の ISC (Internet Software Consortium) 実装を用いて + FreeBSD システムを + DHCP サーバとして動作させる方法の情報を提供します。 + + DHCP のサーバ部分は FreeBSD の一部として提供されません。 + したがって、このサービスを提供するために + net/isc-dhcp3 + port をインストールする必要があるでしょう。 + Ports Collection を使用する情報についての詳細は + を参照してください。 + + + + DHCP サーバのインストール + + DHCP + インストール + + FreeBSD システムを DHCP サーバとして設定するために、&man.bpf.4; + デバイスがカーネルに組み込まれていることを保証する必要があります。 + そうするためには、カーネルコンフィギュレーションファイルに + pseudo-device bpf を追加して、 + カーネルを再構築してください。 + カーネルの構築に関する詳細は + を参照してください。 + + bpf デバイスは、 + FreeBSD にはじめから用意されている GENERIC + カーネルの一部なので、DHCP + を動作させるためにカスタムカーネルを作成する必要はありません。 + + + セキュリティを特に意識する人は、bpf + bpf はパケットスニファ (盗聴プログラム) + が正常に (このようなプログラムはさらに特権アクセスを必要としますが) + 動作することを可能にするデバイスでもあることに注意してください。 + bpf は DHCP を使用するために必要 + です。 + しかし、セキュリティをとても気にしているなら、 + DHCP をいつか使うかもしれないというだけで + bpf + デバイスをカーネルに含めるべきではないでしょう。 + + + 次に行わねばならないのは、 + net/isc-dhcp3 port + によってインストールされた dhcpd.conf + のサンプルを編集することです。 + デフォルトでは、これは + /usr/local/etc/dhcpd.conf.sample で、 + 編集する前にこれを + /usr/local/etc/dhcpd.conf + にコピーするべきでしょう。 + + + + DHCP サーバの設定 + + DHCP + dhcpd.conf + + dhcpd.conf + はサブネットおよびホストに関する宣言で構成されます。 + 例を使って説明するのが最も簡単でしょう。 + + option domain-name "example.com"; +option domain-name-servers 192.168.4.100; +option subnet-mask 255.255.255.0; + +default-lease-time 3600; +max-lease-time 86400; +ddns-update-style none; + +subnet 192.168.4.0 netmask 255.255.255.0 { + range 192.168.4.129 192.168.4.254; + option routers 192.168.4.1; +} + +host mailhost { + hardware ethernet 02:03:04:05:06:07; + fixed-address mailhost.example.com; +} + + + + このオプションは、 + デフォルト探索ドメインとしてクライアントに渡されるドメインを指定します。 + これが意味するところの詳細については &man.resolv.conf.5; + を参照してください。 + + + + このオプションはクライアントが使用する、 + コンマで区切られた DNS サーバのリストを指定します。 + + + + クライアントに渡されるネットマスクです。 + + + + クライアントは特定のリース期限を要求することもできます。 + それ以外の場合は、サーバはこのリース期限値 (秒) + でリースを割り当てるでしょう。 + + + + これはサーバがリースする時間の最大値です。 + クライアントがこれより長いリースを要求しても、 + max-lease-time + 秒だけしか有効にならないでしょう。 + + + + このオプションは、リースが受理、またはリリースされたときに + DHCP サーバが DNS を更新しようとするかどうかを指定します。 + ISC 実装では、このオプションは 必要 です。 + + + + これはどの範囲の IP アドレスが、 + クライアントに割り当てるために予約されたプールに使用されるかを示します。 + この範囲に含まれている IP アドレスはクライアントに渡されます。 + + + + クライアントに供給されるデフォルトゲートウェイを宣言します。 + + + + (リクエストが生じた時に + DHCP サーバがホストを認識できるように) + ホストのハードウェア MAC アドレスを指定します。 + + + + ホストに常に同じ IP アドレスを付与することを指定します。 + DHCP サーバはリース情報を返す前にホスト名の名前解決をするので、 + ここにホスト名を書いても構いません。 + + + + dhcpd.conf + を書き終えたら以下のコマンドでサーバを起動できます。 + + &prompt.root; /usr/local/etc/rc.d/isc-dhcpd.sh start + + 今後サーバの設定に変更を加える必要が生じた時には、 + SIGHUP シグナルを + dhcpd に送っても、 + 多くのデーモンがそうであるようには、 + 設定ファイルが再読み込み されない + ことに注意してください。 + SIGTERM シグナルを送ってプロセスを停止し、 + それから上記のコマンドを用いて再起動させる必要があります。 + + + + ファイル + + DHCP + 設定ファイル + + + /usr/local/sbin/dhcpd + dhcpd は静的にリンクされ + /usr/local/sbin に置かれます。 + dhcpd + に関するそれ以上の情報は port とともにインストールされる + &man.dhcpd.8; マニュアルページにあります。 + + + /usr/local/etc/dhcpd.conf + dhcpd + はクライアントへのサービス提供をはじめる前に設定ファイル + /usr/local/etc/dhcpd.conf + を必要とします。このファイルは、 + サーバの稼働に関する情報に加えて、 + サービスされているクライアントに提供される情報のすべてを含む必要があります。 + この設定ファイルについての詳細は、 + port によってインストールされる &man.dhcpd.conf.5; + マニュアルページを参照してください。 + + + /var/db/dhcpd.leases + DHCP サーバは発行したリースのデータベースをこのファイルにログとして保持します。 + port によってインストールされる &man.dhcpd.leases.5; + にはもう少し詳しい説明があります。 + + + /usr/local/sbin/dhcrelay + dhcrelay は、DHCP + サーバがクライアントからのリクエストを、 + 別のネットワーク上にある DHCP サーバに転送する高度な環境下で使用されます。 + port とともに提供される &man.dhcrelay.8; + マニュアルページにはより詳細な情報が含まれます。 + + + + + + + + + + + Chern + Lee + 寄稿: + + + + DNS + + + 概観 + BIND + + FreeBSD はデフォルトでは + DNS プロトコルの最も一般的な実装である BIND + (Berkeley Internet Name Domain) を使用します。DNS はホスト名を + IP アドレスに、そして IP アドレスをホスト名に関連づけるプロトコルです。 + たとえば www.FreeBSD.org に対する問い合わせは + The FreeBSD Project の ウェブサーバの IP アドレスを受け取るでしょう。 + その一方で ftp.FreeBSD.org に対する問い合わせは、 + 対応する FTP マシンの IP アドレスを返すでしょう。 + 同様に、その逆のことも可能です。 + IP アドレスに対する問い合わせを行うことで、 + そのホスト名を解決することができます。 + DNS 検索を実行するために、 + システム上でネームサーバを動作させる必要はありません。 + + DNS + DNS は、 + 個々のドメイン情報を格納およびキャッシュした、 + 権威のあるルートサーバおよび他の小規模なネームサーバによる多少複雑なシステムによって、 + インターネット全体にわたって協調して動作します。 + + この文書は FreeBSD で安定版として利用されている + BIND 8.x について説明します。 + FreeBSD では BIND 9.x を net/bind9 + port からインストールできます。 + + RFC1034 および RFC1035 は DNS プロトコルを定義しています。 + + 現在のところ BIND は + Internet Software Consortium + (www.isc.org) によって保守されています。 + + + + 用語 + + この文書を理解するには + DNS 関連の用語をいくつか理解しなければいけません。 + + リゾルバ + 逆引き DNS + ルートゾーン + + + + + + 用語 + 定義 + + + + + + 正引き DNS + ホスト名から IP アドレスへの対応です。 + + + + オリジン (origine) + 特定のゾーンファイルによってカバーされるドメインへの参照です。 + + + + named, BIND, ネームサーバ + FreeBSD 内の BIND ネームサーバパッケージの一般名称です。 + + + + リゾルバ (resolver) + マシンがゾーン情報についてネームサーバに問い合わせるシステムプロセスです。 + + + + 逆引き DNS + 正引き DNS の逆です。つまり IP アドレスからホスト名への対応です。 + + + + ルートゾーン + インターネットゾーン階層の起点です。 + すべてのゾーンはルートゾーンの下に属します。 + これはファイルシステムのすべてのファイルがルートディレクトリの下に属することと似ています。 + + + + ゾーン + 同じ権威によって管理される個々の DNS ドメイン、 + DNS サブドメイン、あるいは DNS の一部分です。 + + + + + + + ゾーン + 例 + + + ゾーンの例: + + + + . はルートゾーンです。 + + + org. はルートゾーンの下のゾーンです。 + + + example.org は + org. ゾーンの下のゾーンです。 + + + foo.example.org. はサブドメインで、 + example.org. の下のゾーンです。 + + + + 1.2.3.in-addr.arpa は 3.2.1.* の + IP 空間に含まれるすべての IP アドレスを参照するゾーンです。 + + + + + 見て分かるように、ホスト名のより詳細な部分はその左側に現れます。 + たとえば example.org. は + org. より限定的です。同様に org. + はルートゾーンより限定的です。 + ホスト名の各部分のレイアウトはファイルシステムに非常に似ています。 + たとえば /dev はルートの下であることなどです。 + + + + ネームサーバを実行する理由 + + ネームサーバは通常二つの形式があります: + 権威のあるネームサーバとキャッシュネームサーバです。 + + 権威のあるネームサーバは以下の場合に必要です。 + + + + 問い合わせに対して信頼できる返答をすることで、 + ある人が DNS 情報を世界に向けて発信したいとき。 + + + example.org といったドメインが登録されており、 + その下にあるホスト名に IP アドレスを割り当てる必要があるとき。 + + + IP アドレスブロックが逆引き DNS エントリ (IP からホスト名への) + を必要とするとき。 + + + プライマリサーバがダウンしているかまたはアクセスできない場合に、 + 代わりに問い合わせに対してスレーブと呼ばれるバックアップネームサーバが返答しなければならないとき。 + + + + キャッシュネームサーバは以下の場合に必要です。 + + + + ローカルのネームサーバが、 + 外部のネームサーバに問い合わせするよりも、 + キャッシュしてより速く返答できるとき。 + + + ネットワークトラフィックの総量を減らしたいとき + (DNS のトラフィックはインターネットトラフィック全体の + 5% 以上を占めることが測定されています) + + + + www.FreeBSD.org に対する問い合わせを発したとき、 + リゾルバは大体の場合上流の ISP のネームサーバに問い合わせをして返答を得ます。 + ローカルのキャッシュ DNS サーバがあれば、 + 問い合わせはキャッシュ DNS サーバによって外部に対して一度だけ発せられます。 + 情報がローカルに蓄えられるので、 + 追加の問い合わせはいずれもローカルネットワークの外側にまで確認しなくてもよくなります。 + + + + 動作のしくみ + FreeBSD では BIND デーモンは自明な理由から + named と呼ばれます。 + + + + + + ファイル + 説明 + + + + + + named + BIND デーモン + + + + ndc + ネームデーモンコントロールプログラム + + + + /etc/namedb + BIND のゾーン情報が置かれるディレクトリ + + + + /etc/namedb/named.conf + デーモンの設定ファイル + + + + + + + ゾーンファイルは通常 /etc/namedb + ディレクトリ内に含まれており、ネームサーバによって処理される + DNS ゾーン情報を含んでいます。 + + + + BIND の起動 + + BIND + 起動 + + BIND はデフォルトでインストールされているので、 + すべてを設定することは比較的単純です。 + named デーモンが起動時に開始されることを保証するには、 + /etc/rc.conf に以下の変更をいれてください。 + + named_enable="YES" + デーモンを手動で起動するためには (設定をした後で) + &prompt.root; ndc start + + + + 設定ファイル + + BIND + 設定ファイル + + + <command>make-localhost</command> の利用 + 次のコマンドが + &prompt.root; cd /etc/namedb +&prompt.root; sh make-localhost + ローカル逆引き DNS ゾーンファイルを + /etc/namedb/localhost.rev + に適切に作成することを確認してください。 + + + + <filename>/etc/namedb/named.conf</filename> + + // $FreeBSD$ +// +// 詳細については named(8) マニュアルページを参照してください。プライマリサーバ +// を設定するつもりなら、DNS がどのように動作するかの詳細を確実に理解してくださ +// い。単純な間違いであっても、影響をうける相手に対する接続を壊したり、無駄な +// インターネットトラフィックを大量に引き起こし得ます。 + +options { + directory "/etc/namedb"; + +// "forwarders" 節に加えて次の行を有効にすることで、ネームサーバに決して自発的 +// に問い合わせを発せず、常にそのフォワーダにたいして尋ねるように強制すること +// ができます: +// +// forward only; + +// あなたが上流のプロバイダ周辺の DNS サーバを利用できる場合、その IP アドレス +// をここに入力し、下記の行を有効にしてください。こうすれば、そのキャッシュの +// 恩恵にあやかることができ、インターネット全体の DNS トラフィックが減るでしょう。 +/* + forwarders { + 127.0.0.1; + }; +*/ + + コメントが言っている通り、上流のキャッシュの恩恵を受けるために + forwarders をここで有効にすることができます。 + 通常の状況では、ネームサーバはインターネットの特定のネームサーバを調べて、 + 探している返答を見つけるまで再帰的に問い合わせを行います。 + これが有効になっていれば、まず上流のネームサーバ + (または 与えられたネームサーバ) に問い合わせて、 + そのキャッシュを利用するでしょう。 + 問い合わせをする上流のネームサーバが極度に通信量が多く、 + 高速であった場合、これを有効にする価値があるかもしれません。 + + ここに 127.0.0.1 + を指定しても動作 しません。 + 上流のネームサーバの IP アドレスに変更してください。 + + + /* + * あなたと利用したいネームサーバとの間にファイアウォールがある場合、 + * 下記の quiery-source 指令を有効にする必要があるでしょう。 + * 過去の BIND のバージョンは常に 53 番ポートに問い合わせをしますが、 + * BIND 8.1 はデフォルトで非特権ポートを使用します。 + */ + // query-source address * port 53; + + /* + * 砂場内で動作させている場合、ダンプファイルのために異なる場所を指定 + * しなければならないかもしれません。 + */ + // dump-file "s/named_dump.db"; +}; + +// 注意: 下記は将来のリリースで対応されるでしょう。 +/* +host { any; } { + topology { + 127.0.0.0/8; + }; +}; +*/ + +// セカンダリを設定することはより簡単な方法で、そのおおまかな姿が下記で説明さ +// れています。 +// +// ローカルネームサーバを有効にする場合、このサーバが最初に尋ねられるように +// /etc/resolv.conf に 127.0.0.1 を入力することを忘れないでください。さらに、 +// /etc/rc.conf 内で有効にすることも確認してください。 + +zone "." { + type hint; + file "named.root"; +}; + +zone "0.0.127.IN-ADDR.ARPA" { + type master; + file "localhost.rev"; +}; + +zone +"0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.IP6.INT" { + type master; + file "localhost.rev"; +}; + +// 注意: 下記の IP アドレスを使用しないでください。これはダミーでありデモや文書 +// だけを目的としたものです。 +// +// セカンダリ設定の例です。少なくともあなたのドメインが属するゾーンに対するセカ +// ンダリになることは便利かもしれません。プライマリの責を負っている IP アドレス +// をネットワーク管理者に尋ねてください。 +// +// 逆引き参照ゾーン (IN-ADDR.ARPA) を含めることを決して忘れないでください! +// (これは ".IN-ADDR.ARPA" を付け加えられたそれぞれの IP アドレスの最初のバイト +// の逆順です。) +// +// プライマリゾーンの設定をはじめる前に DNS および BIND がどのように動作するか +// 完全に理解してください。時々自明でない落し穴があります。それに比べるとセカン +// ダリを設定するのは単純です。 +// +// 注意: 下記の例を鵜呑みにして有効にしないでください。:-) 実際の名前とアドレス +// を代わりに使用してください。 +// +// 注意!!! FreeBSD は bind を砂場のなかで動かします (rc.conf 内の named_flags +// を参照してください)。セカンダリゾーンを含んだディレクトリは、bind によって +// 書き込み可能でなければなりません。次の手順が推奨されます: +// +// mkdir /etc/namedb/s +// chown bind:bind /etc/namedb/s +// chmod 750 /etc/namedb/s + + BIND を砂場 (sandbox) で + (訳注: chroot をもちいて) 動作させるための詳細は + 砂場で named を実行する を参照してください。 + + /* +zone "example.com" { + type slave; + file "s/example.com.bak"; + masters { + 192.168.1.1; + }; +}; + +zone "0.168.192.in-addr.arpa" { + type slave; + file "s/0.168.192.in-addr.arpa.bak"; + masters { + 192.168.1.1; + }; +}; +*/ + named.conf の中で、 + 上記は転送と逆引きゾーンのためのスレーブエントリの例です。 + + 新しくサービスするそれぞれのゾーンについて、新規のエントリを + named.conf に加えなければいけません。 + + たとえば example.org + に対する最もシンプルなゾーンエントリは以下のようになります。 + + zone "example.org" { + type master; + file "example.org"; +}; + + このゾーンは + 命令で示されているようにマスタで、ゾーン情報を + 命令で指示された + /etc/namedb/example.org + ファイルに保持しています。 + + zone "example.org" { + type slave; + file "example.org"; +}; + + スレーブの場合、 + ゾーン情報は特定のゾーンのマスタネームサーバから転送され、 + 指定されたファイルに保存されます。 + マスタサーバが停止するか到達できない場合には、 + スレーブサーバが転送されたゾーン情報を保持していて、 + サービスできるでしょう。 + + + + ゾーンファイル + example.org に対するマスタゾーンファイル + (/etc/namedb/example.org に保持されます) + の例は以下のようになります。 + + $TTL 3600 + +example.org. IN SOA ns1.example.org. admin.example.org. ( + 5 ; Serial + 10800 ; Refresh + 3600 ; Retry + 604800 ; Expire + 86400 ) ; Minimum TTL + +; DNS Servers +@ IN NS ns1.example.org. +@ IN NS ns2.example.org. + +; Machine Names +localhost IN A 127.0.0.1 +ns1 IN A 3.2.1.2 +ns2 IN A 3.2.1.3 +mail IN A 3.2.1.10 +@ IN A 3.2.1.30 + +; Aliases +www IN CNAME @ + +; MX Record +@ IN MX 10 mail.example.org. + + . + が最後についているすべてのホスト名は正確なホスト名であり、 + 一方で . + で終了しないすべての行はオリジンが参照されることに注意してください。 + たとえば www は www + オリジン + に展開されます。この架空のゾーンファイルでは、 + オリジンは example.org. なので + www は www.example.org. + に展開されます。 + + + ゾーンファイルの書式は次のとおりです。 + + recordname IN recordtype value + + + DNS + レコード + + DNS レコードに使われる最も一般的なものは以下のとおりです。 + + + + SOA + + ゾーン権威の起点 + + + + NS + + 権威のあるネームサーバ + + + + A + + ホストのアドレス + + + + CNAME + + 別名としての正規の名称 + + + + MX + + メールエクスチェンジャ + + + + PTR + + ドメインネームポインタ (逆引き DNS で使用されます) + + + + +example.org. IN SOA ns1.example.org. admin.example.org. ( + 5 ; Serial + 10800 ; Refresh after 3 hours + 3600 ; Retry after 1 hour + 604800 ; Expire after 1 week + 86400 ) ; Minimum TTL of 1 day + + + + example.org. + + このゾーンのオリジンでもあるドメイン名 + + + + ns1.example.org. + + このゾーンに対して権威のあるプライマリネームサーバ + + + + admin.example.org. + + このゾーンの責任者。@ + を置き換えた電子メールアドレスを指定します。 + (admin@example.org は + admin.example.org になります) + + + + + 5 + + ファイルのシリアル番号です。 + これはファイルが変更されるたびに増加させる必要があります。 + 現在では多くの管理者は yyyymmddrr + という形式をシリアル番号として使用することを好みます。 + 2001041002 は最後に修正されたのが 2001/04/10 で、後ろの 02 + はその日で二回目に修正されたものであるということを意味するでしょう。 + シリアル番号は、 + それが更新されたときにスレーブネームサーバに対してゾーンを通知するので重要です。 + + + + + +@ IN NS ns1.example.org. + + これは NS エントリです。 + このゾーンに対して権威のある返答を返すネームサーバはすべて、 + このエントリを一つ有していなければなりません。 + ここにある @ は + example.org. を意味します。 + @ はオリジンに展開されます。 + + +localhost IN A 127.0.0.1 +ns1 IN A 3.2.1.2 +ns2 IN A 3.2.1.3 +mail IN A 3.2.1.10 +@ IN A 3.2.1.30 + + A レコードはマシン名を示します。 + 上記のように ns1.example.org は + 3.2.1.2 に結びつけられるでしょう。 + ふたたびオリジンを示す @ + がここに使用されていますが、これは + example.org が + 3.2.1.30 + に結び付けられることを意味しています。 + + +www IN CNAME @ + + CNAME + レコードは通常マシンに別名を与えるときに使用されます。 + 例では www はオリジン、すなわち + example.org + (3.2.1.30) + のアドレスをふられたマシンへの別名を与えます。 + CNAME はホスト名の別名、 + または複数のマシン間で一つのホスト名をラウンドロビン + (訳注: 問い合わせがあるたびに別の IP アドレスを返すことで、 + 一台にアクセスが集中することを防ぐ手法) + するときに用いられます。 + + +@ IN MX 10 mail.example.org. + + MX レコードは、 + ゾーンに対してどのメールサーバがやってきたメールを扱うことに責任を持っているかを示します。 + mail.example.org + はメールサーバのホスト名で、10 はメールサーバの優先度を示します。 + + 優先度が 3,2 または + 1 などのメールサーバをいくつも置くことができます。 + example.org + へ送ろうとしているメールサーバははじめに一番優先度の高いメールサーバに接続しようとします。 + そして接続できない場合、二番目に優先度の高いサーバに接続しようとし、 + 以下、メールが適切に配送されるまで同様に繰り返します。 + + in-addr.arpa ゾーンファイル (逆引き DNS) に対しても + A または CNAME の代わりに + PTR エントリが用いられることを除けば、 + 同じ書式が使われます。 + + $TTL 3600 + +1.2.3.in-addr.arpa. IN SOA ns1.example.org. admin.example.org. ( + 5 ; Serial + 10800 ; Refresh + 3600 ; Retry + 604800 ; Expire + 3600 ) ; Minimum + +@ IN NS ns1.example.org. +@ IN NS ns2.example.org. + +2 IN PTR ns1.example.org. +3 IN PTR ns2.example.org. +10 IN PTR mail.example.org. +30 IN PTR example.org. + このファイルは上記の架空のドメインの + IP アドレスからホスト名への対応を与えます。 + + + + + キャッシュネームサーバ + + BIND + キャッシュネームサーバ + + キャッシュネームサーバはどのゾーンに対しても権威をもたないネームサーバです。 + キャッシュネームサーバは単に自分で問い合わせをし、 + 後で使えるように問い合わせの結果を覚えておきます。 + これを設定するには、ゾーンを何も含まずに、 + 通常通りネームサーバを設定してください。 + + + + 砂場で <application>named</application> を実行する + + BIND + 砂場での実行 + + + + chroot + + セキュリティを強めるために &man.named.8; を非特権ユーザで実行し、 + 砂場のディレクトリ内に &man.chroot.8; + して実行したいと思うかもしれません。 + こうすると named + デーモンは砂場の外にはまったく手を出すことができません。 + named が乗っ取られたとしても、 + これによって起こりうる損害が小さくなるでしょう。 + FreeBSD にはデフォルトで、そのための bind + というユーザとグループがあります。 + + 多くの人々は named + を chroot するように設定する代わりに、 + &man.jail.8; 環境内で named + を実行することを奨めるでしょう。 + この節ではそれは扱いません。 + + named は砂場の外 + (共有ライブラリ、ログソケットなど) にアクセスできないので、 + named + を正しく動作させるためにいくつもの段階を経る必要があります。 + 下記のチェックリストにおいては、砂場のパスは + /etc/namedb で、 + このディレクトリの内容には何も手を加えていないと仮定します。 + root 権限で次のステップを実行してください。 + + + + named + が存在することを期待しているディレクトリをすべて作成します。 + + &prompt.root; cd /etc/namedb +&prompt.root; mkdir -p bin dev etc var/tmp var/run master slave +&prompt.root; chown bind:bind slave var/* + + + + これらのディレクトリに対して + named + が必要なのは書き込み権限だけなので、それだけを与えます。 + + + + + + 基本ゾーンファイルと設定ファイルの編集と作成を行います。 + &prompt.root; cp /etc/localtime etc +&prompt.root; mv named.conf etc && ln -sf etc/named.conf +&prompt.root; mv named.root master + +&prompt.root; sh make-localhost && mv localhost.rev localhost-v6.rev master +&prompt.root; cat > master/named.localhost +$ORIGIN localhost. +$TTL 6h +@ IN SOA localhost. postmaster.localhost. ( + 1 ; serial + 3600 ; refresh + 1800 ; retry + 604800 ; expiration + 3600 ) ; minimum + IN NS localhost. + IN A 127.0.0.1 +^D + + + + これは named が &man.syslogd.8; + に正しい時刻でログを書き込むことを可能にします。 + + + + + + 4.9-RELEASE より前のバージョンの &os; を使用している場合、 + 静的リンクされた named-xfer + を構築し、砂場にコピーしてください。 + + &prompt.root; cd /usr/src/lib/libisc +&prompt.root; make cleandir && make cleandir && make depend && make all +&prompt.root; cd /usr/src/lib/libbind +&prompt.root; make cleandir && make cleandir && make depend && make all +&prompt.root; cd /usr/src/libexec/named-xfer +&prompt.root; make cleandir && make cleandir && make depend && make NOSHARED=yes all +&prompt.root; cp named-xfer /etc/namedb/bin && chmod 555 /etc/namedb/bin/named-xfer + + 静的リンクされた named-xfer + をインストールしたら、 + ソースツリーの中にライブラリまたはプログラムの古くなったコピーを残さないように、 + 掃除する必要があります。 + + &prompt.root; cd /usr/src/lib/libisc +&prompt.root; make cleandir +&prompt.root; cd /usr/src/lib/libbind +&prompt.root; make cleandir +&prompt.root; cd /usr/src/libexec/named-xfer +&prompt.root; make cleandir + + + + このステップは時々失敗することが報告されています。 + もし失敗した場合、次のコマンドを実行してください。 + + &prompt.root; cd /usr/src && make cleandir && make cleandir + + そして /usr/obj + ツリーを削除します。 + + &prompt.root; rm -fr /usr/obj && mkdir /usr/obj + + これはソースツリーからすべてのがらくたを一掃します。 + もう一度上記の手順を行うと、今度はうまく動作するでしょう。 + + + + バージョン 4.9-RELEASE 以降の + &os; を使用している場合 /usr/libexec + にある named-xfer + のコピーはデフォルトで静的リンクされています。 + 砂場にコピーするために単純に &man.cp.1; が使えます。 + + + + named が見ることができ、 + 書き込むことのできる dev/null + を作成します。 + + &prompt.root; cd /etc/namedb/dev && mknod null c 2 2 +&prompt.root; chmod 666 null + + + + /etc/namedb/var/run/ndc から + /var/run/ndc + へのシンボリックリンクを作成します。 + + &prompt.root; ln -sf /etc/namedb/var/run/ndc /var/run/ndc + + + これは単に &man.ndc.8; を実行するたびに + オプションを指定しなくてもよいようにするだけです。 + /var/run の中身は起動時に削除されるため、 + これが有用だと思うなら、このコマンドをルートの crontab に + + オプションを指定して追加してください。 + 詳細については &man.crontab.5; を参照してください。 + + + + + named が書き込める追加の + log ソケットを作成するように + &man.syslogd.8; を設定します。 + これを行うためには、/etc/rc.conf + 内の syslogd_flags 変数に + -l /etc/namedb/dev/log を加えてください。 + + + + 次の行を /etc/rc.conf に加えて + named が起動し、 + 自身を砂場内に chroot するように調整します + + named_enable="YES" +named_flags="-u bind -g bind -t /etc/namedb /etc/named.conf" + + + 設定ファイル /etc/named.conf + は 砂場のディレクトリに対して相対的な + フルパスで表されることに注意してください。 + つまり、上記の行で示されたファイルは実際には + /etc/namedb/etc/named.conf です。 + + + + + 次のステップは named + がどのゾーンを読み込むか、 + そしてディスク上のどこにゾーンファイルがあるのかを知るために + /etc/namedb/etc/named.conf を編集することです。 + 下記に例をコメントを加えて示します + (ここで特にコメントされていない内容については、 + 砂場の中で動作させない DNS サーバの設定と同じです)。 + + options { + directory "/"; + named-xfer "/bin/named-xfer"; + version ""; // Don't reveal BIND version + query-source address * port 53; +}; +// ndc control socket +controls { + unix "/var/run/ndc" perm 0600 owner 0 group 0; +}; +// Zones follow: +zone "localhost" IN { + type master; + file "master/named.localhost"; + allow-transfer { localhost; }; + notify no; +}; +zone "0.0.127.in-addr.arpa" IN { + type master; + file "master/localhost.rev"; + allow-transfer { localhost; }; + notify no; +}; +zone "0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.ip6.int" { + type master; + file "master/localhost-v6.rev"; + allow-transfer { localhost; }; + notify no; +}; +zone "." IN { + type hint; + file "master/named.root"; +}; +zone "private.example.net" in { + type master; + file "master/private.example.net.db"; + allow-transfer { 192.168.10.0/24; }; +}; +zone "10.168.192.in-addr.arpa" in { + type slave; + masters { 192.168.10.2; }; + file "slave/192.168.10.db"; +}; + + + + directory は + / を指定します。 + named + が必要とするファイルはすべてこのディレクトリにあります。 + (この指定は 通常の (訳注: 砂場内で動作させない) + ユーザにとっての /etc/namedb + と等価です)。 + + + + named-xfer + バイナリへの (named にとっての) + フルパスを指定します。 + named はデフォルトで + named-xfer を /usr/libexec + から探すようにコンパイルされているので、これが必要です + + + このゾーンに対するゾーンファイルを + named が見つけられるようにファイル名を + (上記と同様に directory からの相対パスで) + 指定します。 + + + このゾーンに対するゾーン情報がマスタサーバからが転送されたあとに、 + named + がゾーンファイルのコピーを書き込むファイル名を + (上記と同様に directory からの相対パスで) + 指定します。これが、上記のように設定段階で + slave ディレクトリの所有者を + bind に変更する理由です。 + + + + 上記のステップを完了したら、サーバを再起動するか &man.syslogd.8; + を再起動し、&man.named.8; を起動してください。その際、 + syslogd_flags および + named_flags + に新たに指定したオプションが有効になっていることを確かめてください。 + これで named + を砂場のなかで動作させることができているはずです! + + + + セキュリティ + + BIND は DNS の最も一般的な実装ではありますが、 + 常にセキュリティ問題を抱えています。 + 問題になり得る、また悪用可能なセキュリティホールが時々みつかります。 + + + 現在のインターネットおよび FreeBSD + のセキュリティ問題について常に最新の情報を得るために + CERT および + freebsd-security-notifications + を購読するとよいでしょう。 + + 問題が生じたとしても、 + 最新のソースからビルドした named を用意しておけば、 + 問題にならないかもしれません。 + + + + さらなる情報源 + + BIND/named のマニュアルページ: &man.ndc.8; &man.named.8; &man.named.conf.5; + + + + + ISC Bind + 公式ページ + + + + + BIND FAQ + + + + O'Reilly + DNS and BIND 4th Edition + + + + RFC1034 + - Domain Names - Concepts and Facilities + (ドメイン名、その概念と基盤) + + + + RFC1035 + - Domain Names - Implementation and Specification + (ドメイン名、その実装と仕様) + + + + + + + + + + Tom + Hukins + 寄稿: + + + + NTP + + NTP + + + 概説 + + 時間の経過とともに、コンピュータの時計はずれてしまいがちです。 + 時間が経つと、コンピュータの時計は正確でなくなってゆきます。 + NTP (Network Time Protocol) + は時計が正確であることを保証する方法の一つです。 + + インターネットサービスの多くは、 + コンピュータの時計が正確であることに依存しているか、 + あるいは多くを負っています。 + たとえば web サーバ は、 + あるファイルがある時刻以降に修正されていたらそのファイルを送ってほしいという要求を受け取るかもしれません。 + &man.cron.8; のようなサービスは所定の時間にコマンドを実行します。 + 時計が正確でない場合、 + これらのコマンドは期待したとおりには実行されないかもしれません。 + + + NTP + ntpd + + FreeBSD は &man.ntpd.8; NTP サーバを搭載しています。これは、 + マシンの時計を合わせるために他の NTP サーバに問い合わせをしたり、 + 他のマシンに対して時刻を報じるために使用できます。 + + + + 適切な NTP サーバの選択 + + + NTP + サーバ選択 + + + 時刻を同期するために利用する NTP サーバを、 + 一つ以上見つける必要があります。 + ネットワーク管理者、または ISP はこの目的のために + NTP サーバを設定しているかもしれません — + 本当にそうなのか確かめるためにドキュメントを確認してください。 + あなたの近くの NTP サーバを探せる + 公にアクセス可能な + NTP サーバのリスト があります。 + どのサーバを選択するとしても、そのサーバの運営ポリシを理解し、 + 要求されているなら利用許可を求めることを忘れないでください。 + + 使用しているサーバのうちのどれかが到達不能になるか、 + その時計の信頼性が低い場合、無関係の + NTP サーバをいくつか選択するとよいでしょう。 + &man.ntpd.8; は他のサーバから受け取った応答を賢く利用します — + 信頼できないサーバより信頼できるサーバを重視します。 + + + + マシンの設定 + + + NTP + 設定 + + + + 基本設定 + ntpdate + + マシンが起動するときだけ時計を同期させたい場合は + &man.ntpdate.8; が使えます。頻繁に再起動され、 + たまに同期すれば十分なデスクトップマシンには適切かもしれません。 + しかしほとんどのマシンでは &man.ntpd.8; を実行するべきです。 + + &man.ntpd.8; を動かしているマシンでも、起動時に + &man.ntpdate.8; を使用するのはよい考えです。 + &man.ntpd.8; プログラムは時計を徐々に変更します。しかし + &man.ntpdate.8; + は正しい時刻と現在設定されているマシンの時刻がどんなに離れていようとも時計を設定します。 + + 起動時に &man.ntpdate.8; を有効にするためには、 + ntpdate_enable="YES" を + /etc/rc.conf に追加してください。 + さらに、同期したいすべてのサーバおよび、&man.ntpdate.8; + に渡すあらゆるフラグを ntpdate_flags + に指定する必要があるでしょう。 + + + + 一般設定 + + + NTP + ntp.conf + + + NTP は &man.ntp.conf.5; に記述された書式の + /etc/ntp.conf ファイルによって設定されます。 + 簡単な例を以下に示します。 + + server ntplocal.example.com prefer +server timeserver.example.org +server ntp2a.example.net + +driftfile /var/db/ntp.drift + + server オプションは、 + 使用するサーバを一行に一つずつ指定します。サーバが上記の + ntplocal.example.com のように + prefer 引数とともに指定された場合、 + このサーバは他のサーバより優先されます。 + 優先されたサーバからの応答は、 + 他のサーバの応答と著しく異なる場合は破棄されますが、 + そうでなければ他の応答を考慮することなく使用されます。 + prefer 引数は、通常、 + 特別な時間モニタハードウェアを備えているような非常に正確であるとされている + NTP サーバに対して使用されます。 + + driftfile + オプションはシステム時計の周波数オフセットを格納するために使用するファイルを指定します。 + &man.ntpd.8; プログラムは、 + 時計の自然変動を自動的に補正するためにこれを用います。 + これにより、一定時間外部の時刻ソースから切り離されたとしても、 + 十分正確な時刻を維持することを可能にします。 + + driftfile オプションは、使用している NTP + サーバから過去に受け取った応答に関する情報を格納するために、 + どのファイルが使用されるか指定します。 + このファイルは NTP に関する内部情報を含んでいます。 + これは他のプロセスによって修正されてはいけません。 + + + + サーバへのアクセス制御 + + デフォルトでは NTP + サーバはインターネット上のすべてのホストからアクセスが可能です。 + /etc/ntp.conf 内で restrict + オプションを指定することによって、 + どのマシンがサーバにアクセスできるかを制御できるようにします。 + + NTP サーバにアクセスするマシンのすべてを拒否したいのなら、 + 以下の行を /etc/ntp.conf + に追加してください。 + + restrict default ignore + + あなたのネットワーク内のマシンにだけサーバに接続して時計を同期することを認めたいが、 + それらからサーバに対して設定を行うのを許さず、 + 同期する端末としても利用されないようにしたいのなら、 + 以下を加えてください。 + + restrict 192.168.1.0 mask 255.255.255.0 notrust nomodify notrap + + 192.168.1.0 + をあなたのネットワークの IP アドレスに + 255.255.255.0 + をあなたのネットワークのネットマスクに置き換えてください。 + + /etc/ntp.conf には複数の + restrict オプションを置けます。 + 詳細に付いては &man.ntp.conf.5; の + Access Control Support + サブセクションを参照してください。 + + + + + NTP サーバの実行 + + NTP サーバが起動時に実行されることを保証するために、 + xntpd_enable="YES" を + /etc/rc.conf に加えてください。 + &man.ntpd.8; にフラグを追加したい場合は + /etc/rc.conf 内の + xntpd_flags パラメータを編集してください。 + + マシンを再起動することなくサーバを実行したいときは、 + /etc/rc.conf 内の xntpd_flags + で追加されたパラメータをすべて指定して + ntpd を実行してください。以下に例を示します。 + &prompt.root; ntpd -p /var/run/ntpd.pid + + + &os; 5.X では /etc/rc.conf + 内のさまざまなオプションの名前が変わりました。 + したがって、上記の + xntpd に関するオプションは + ntpd に置き換えてください。 + + + + 一時的なインターネット接続で ntpd を使用する + + &man.ntpd.8; プログラムは正しく機能するために、 + インターネットへの常時接続を必要としません。しかしながら、 + オンデマンドでダイアルアップされるように設定された一時的な接続の場合、 + NTP トラフィックがダイアルを引き起こしたり、 + 接続を維持し続けるようなことを避けるようにした方がよいでしょう。 + ユーザ PPP を使用している場合、以下の例のように + /etc/ppp/ppp.conf 内で + filter ディレクティブが使用できます。 + + set filter dial 0 deny udp src eq 123 + # Prevent NTP traffic from initiating dial out + set filter dial 1 permit 0 0 + set filter alive 0 deny udp src eq 123 + # Prevent incoming NTP traffic from keeping the connection open + set filter alive 1 deny udp dst eq 123 + # Prevent outgoing NTP traffic from keeping the connection open + set filter alive 2 permit 0/0 0/0 + + 詳細については &man.ppp.8; 内の PACKET FILTERING + セクション、および /usr/share/examples/ppp/ + 内の例を参照してください。 + + + 小さい番号のポートをブロックするインターネットアクセスプロバイダでは、 + 応答があなたのマシンに到達しないので + NTP がきちんと動作しない場合もあります。 + + + + + さらなる情報源 + + NTP サーバに関する文書は HTML 形式で + /usr/share/doc/ntp/ にあります。 + + + + + + + + Chern + Lee + 寄稿: + + + + ネットワークアドレス変換 (NAT) + + + 概要 + + natd + + 一般に &man.natd.8; として知られている FreeBSD + ネットワークアドレス変換デーモンは、 + raw IP パケットを受信して、 + ソースアドレスをローカルマシンに変更し、 + そのパケットを外向きの IP パケットの流れに再注入するデーモンです。 + &man.natd.8; は、 + データが戻ってきたときに、データの本来の場所を判別し、 + もともと要求した相手へデータを返すことができるようにソース IP + アドレスとポートを変更します。 + インターネット接続共有 + IP マスカレード + NAT の最も一般的な使用法は、 + 一般的にはインターネット接続共有として知られているものを実行することです。 + + + + 設定 + IPv4 の IP 空間が足りなくなりつつあること、および、 + ケーブルや DSL のような高速の加入者回線利用者の増加によって、 + 人々はますますインターネット接続を共有する手段を必要としています。 + 一つの接続および + IP アドレスを通していくつものコンピュータを回線に接続する能力がある + &man.natd.8; が合理的な選択になります。 + + もっともよくあるのは、ユーザが 1 つの + IP アドレスでケーブルまたは DSL 回線に接続されたマシンを持っており、 + インターネットへのアクセスを + LAN 経由でいくつかのコンピュータに提供するのに、 + この接続されたコンピュータを使用したいという場合です。 + + そのためには、インターネットに接続されている FreeBSD + マシンはゲートウェイとして動作しなければなりません。 + このゲートウェイマシンは 2 つの NIC が必要です + (1 つはインターネットルータへ接続するためで、もう 1 つは + LAN に接続するためです)。 + LAN 上のすべてのマシンはハブまたはスイッチを通して接続されます。 + + + + + + + + _______ __________ ________ + | | | | | | + | Hub |-----| Client B |-----| Router |----- Internet + |_______| |__________| |________| + | + ____|_____ +| | +| Client A | +|__________| + + + + ネットワークレイアウト + + + + インターネット接続を共有するために、 + このような設定がよく使用されています。 + LAN 内のマシンの + 1 台がインターネットに接続しています。 + 残りのマシンはその ゲートウェイ + マシンを通してインターネットにアクセスします。 + + + + 設定 + + + カーネル + 設定 + + 次のオプションがカーネルコンフィギュレーションファイルに必要です。 + options IPFIREWALL +options IPDIVERT + + さらに、次のオプションを入れてもよいでしょう。 + options IPFIREWALL_DEFAULT_TO_ACCEPT +options IPFIREWALL_VERBOSE + + 下記の設定を /etc/rc.conf + で行わなければなりません。 + + gateway_enable="YES" +firewall_enable="YES" +firewall_type="OPEN" +natd_enable="YES" +natd_interface="fxp0" +natd_flags="" + + + + + + gateway_enable="YES" + マシンがゲートウェイとして動作するように設定します。 + sysctl net.inet.ip.forwarding=1 + コマンドを実行しても同じ効果がえられます。 + + firewall_enable="YES" + /etc/rc.firewall + にあるファイアウォールルールを起動時に有効にします。 + + firewall_type="OPEN" + これはあらかじめ定義されている、 + すべてのパケットを通すファイアウォールルールセットを指定します。 + 他のタイプについては /etc/rc.firewall + を参照してください。 + + + natd_interface="fxp0" + パケットを転送するインタフェースを指定します + (インターネットに接続されたインタフェース)。 + + + natd_flags="" + 起動時に &man.natd.8; に渡される追加の引数 + + + + + + /etc/rc.conf + に前述したオプションを定義すると、起動時に + natd -interface fxp0 が実行されます。 + これは手動でも実行できます。 + + LAN にぶら下がっているマシンおよびインタフェースのそれぞれには + RFC 1918 + で定義されているプライベートネットワーク空間の + IP アドレス番号を割り当て、デフォルトゲートウェイアドレスを + natd マシンの内側の + IP アドレスにすべきです。 + + たとえば LAN 側のクライアント + A および B は + IP アドレス 192.168.0.2 および + 192.168.0.3 を割り当てられており、 + natd マシンの LAN インタフェースは IP アドレス + 192.168.0.1 + を割り当てられています。 + クライアント A および B + のデフォルトゲートウェイは natd + マシンの 192.168.0.1 + に設定されなければなりません。 + natd マシンの外部、 + またはインターネットインタフェースは &man.natd.8; + の動作に際して特別の修正を必要としません。 + + + + ポート転送 + + &man.natd.8; の短所は、インターネットから + LAN 内のクライアントにアクセスできないということです。 + LAN 内のクライアントは外部に向けて接続を行うことはできますが、 + 入って来るものを受け取ることができません。これは、LAN + クライアントのどれかでインターネットサービスを動かそうとした場合に、 + 問題になります。これを何とかする単純な方法は + natd マシンから LAN クライアントへ、 + 選択したインターネットポートを転送することです。 + + たとえばクライアント A で実行されている + IRC サーバがあり、 + クライアント B 上で実行されている + web サーバがあるとします。 + これが正しく動作するには、ポート 6667 (IRC) および 80 (web) + への接続を対応するマシンに転送しなければなりません。 + + に適切なオプションを加えて + &man.natd.8; に渡さなければなりません。 + 書式は以下のとおりです。 + -redirect_port proto targetIP:targetPORT[-targetPORT] + [aliasIP:]aliasPORT[-aliasPORT] + [remoteIP[:remotePORT[-remotePORT]]] + + 上記の例では、引数は以下のようにします。 + + -redirect_port tcp 192.168.0.2:6667 6667 + -redirect_port tcp 192.168.0.3:80 80 + + これで適切な tcp ポートが + LAN クライアントマシンに転送されます。 + + + 引数は個々のポートを対応させるポート範囲を示すのに使えます。 + たとえば tcp 192.168.0.2:2000-3000 2000-3000 + は 2000 番から 3000番ポートに受け取られたすべての接続を、 + クライアント A 上の + 2000 番から 3000 番に転送します。 + + これらのオプションは &man.natd.8; を直接実行するか、 + /etc/rc.conf 内の + natd_flags="" + オプションに指定して使用できます。 + + 設定オプションの詳細については + &man.natd.8; をご覧ください。 + + + + アドレス転送 + アドレス転送 + 複数の IP アドレスが利用可能ですが、 + それらが 1 台のマシン上になければならないときには、 + アドレス転送が便利です。 + これを用いれば &man.natd.8; は LAN クライアントのそれぞれに外部 + IP アドレスを割り当てることができます。 + &man.natd.8; は LAN + クライアントから外部へ出て行くパケットを適切な外部の + IP アドレスで書き直し、 + そして特定の IP アドレスに対してやって来るトラフィックのすべてを、 + 指定された LAN クライアントに転送します。 + これは静的 NAT としても知られています。 + たとえば 128.1.1.1, + 128.1.1.2 および + 128.1.1.3 の IP アドレスが、 + natd + ゲートウェイマシンに属しているとします。 + 128.1.1.2 および + 128.1.1.3 は + LAN クライアントの A および B + に転送される一方で、128.1.1.1 は + natd ゲートウェイマシンの外部 + IP アドレスとして使用することができます。 + + の書式は以下のとおりです: + + -redirect_address localIP publicIP + + + + + + localIP + LAN クライアントの内部 IP アドレス + + + publicIP + LAN クライアントに対応する外部 IP アドレス + + + + + + 上記の例では引数は以下のようになります。 + + -redirect_address 192.168.0.2 128.1.1.2 +-redirect_address 192.168.0.3 128.1.1.3 + + と同様に、これらの引数は + /etc/rc.conf 内の + natd_flags="" + オプションで指定できます。アドレス転送では、 + 特定の IP アドレスで受け取られたデータはすべて転送されるので、 + port 転送は必要ありません。 + + natd マシン上の外部 IP アドレスは、 + アクティブで外部インタフェースにエイリアスされていなければなりません。 + やりかたは &man.rc.conf.5; を参照してください。 + + + + + + + + Chern + Lee + 寄稿: + + + + + <application>inetd</application> <quote>スーパサーバ</quote> + + + 概観 + + &man.inetd.8; は複数のデーモンに対する接続を制御するので、 + インターネットスーパサーバ と呼ばれます。 + ネットワークサービスを提供するプログラムは、 + 一般的にデーモン呼ばれます。inetd + は他のデーモンを管理するサーバを努めます。 + 接続が inetd によって受け付けられると、 + inetd + は接続がどのデーモンに対するものか判断して、 + そのデーモンを起動し、ソケットを渡します。 + inetd を 1 つ実行することにより、 + それぞれのデーモンをスタンドアロンモードで実行することに比べ、 + 全体としてのシステム負荷を減らします。 + + 基本的に、inetd + は他のデーモンを起動するために使用されます。しかし、 + chargen, auth + および daytime + のようなささいなプロトコルは直接扱われます。 + + この節ではコマンドラインオプションおよび設定ファイル + /etc/inetd.conf による + inetd の設定の基本を説明します。 + + + + 設定 + + inetd は + /etc/rc.conf の仕組によって初期化されます。 + デフォルトでは inetd_enable オプションは + NO に設定されています。 + しかし多くの場合、sysinstall + でセキュリティプロファイルを + medium に設定することにより、有効化されます。 + inetd_enable="YES" または + inetd_enable="NO" を + /etc/rc.conf に置くことで、起動時に + inetd を有効または無効にできます。 + + さらに inetd_flags オプションによって、 + いろいろなコマンドラインオプションを + inetd に渡すことができます。 + + + + コマンドラインオプション + + inetd 書式 + + + + + + -d + + + デバッグモードにします。 + + + + + -l + + + 成功した接続のログをとります。 + + + + + -w + + + 外部サービスに対して TCP Wrapper を有効にします + (デフォルト)。 + + + + + -W + + + inetd + 組み込みの内部サービスに対して TCP Wrapper を有効にします + (デフォルト)。 + + + + + -c maximum + + + サービス毎に同時に起動可能な最大値のデフォルトを指定します。 + デフォルトでは無制限です。サービスごとに指定する + + パラメータで上書きできます。 + + + + + -C rate + + + 1 分間にひとつの IP アドレスから起動されるサービスの、 + 最大値のデフォルトを指定します。デフォルトは無制限です。 + サービスごとに指定する + + パラメータで上書きできます。 + + + + + -R rate + + + あるサービスを 1 分間に起動できる最大の数を指定します。 + デフォルトは 256 です。rate に 0 を指定すると、 + 起動可能な数は無制限になります。 + + + + + -a + + + バインドする IP アドレスを一つ指定します。 + 代わりにホスト名も指定できます。この場合、ホスト名に対応する + IPv4 または IPv6 アドレスが使用されます。通常 + inetd が &man.jail.8; + 内で起動される時点で、ホスト名が指定されます。この場合、 + ホスト名は &man.jail.8; 環境に対応するものです。 + + ホスト名指定が使用され、 + IPv4 および IPv6 両方にバインドしたい場合、 + /etc/inetd.conf の各サービスに対して、 + 各バインドに対する適切なプロトコルのエントリが必要です。 + たとえば TCP ベースのサービスは、 + ひとつはプロトコルに tcp4 を使用し、 + もう一つは tcp6 を使用する、 + 2 つのエントリが必要です。 + + + + + -p + + + デフォルトとは異なる + PID を保持するファイルを指定します。 + + + + + /etc/rc.conf 内の + inetd_flags オプションを用いて、これらのオプションを + inetd に渡すことができます。デフォルトでは + inetd_flags は -wW に設定されており、 + これは inetd + の内部および外部サービスに対して TCP wrapper を有効にします。 + 初心者ユーザはこれらのパラメータを変更する必要は通常ありませんし、 + /etc/rc.conf に入力する必要もありません。 + + + 外部サービスは、接続を受け取ったときに起動される + inetd の外部にあるデーモンで、 + それに対して、内部サービスは inetd + 自身が提供する内部のデーモンです。 + + + + + + <filename>inetd.conf</filename> + + inetd の設定は + /etc/inetd.conf + ファイルによって制御されます。 + + /etc/inetd.conf が変更されたときは、 + 以下のように inetd プロセスに + HangUP シグナルを送ることにより、inetd + に設定ファイルを再読み込みさせられます。 + + + <application>inetd</application> への HangUP シグナル送付 + + &prompt.root; kill -HUP `cat /var/run/inetd.pid` + + + 設定ファイルのそれぞれの行は、 + 個々のデーモンについての指示になります。 + ファイル内のコメントは # が先頭につきます。 + /etc/inetd.conf の書式は以下のとおりです。 + + service-name +socket-type +protocol +{wait|nowait}[/max-child[/max-connections-per-ip-per-minute]] +user[:group][/login-class] +server-program +server-program-arguments + + IPv4 を利用する ftpd + デーモンのエントリの例です。 + + ftp stream tcp nowait root /usr/libexec/ftpd ftpd -l + + + + service-name + + + これは特定のデーモンのサービス名です。 + これは /etc/services + 内のサービスリストに対応していなければなりません。 + これは inetd + がどのポートで受け付けなければならないかを決定します。 + 新しいサービスが作成された場合、まずはじめに + /etc/services + 内に記載しなければなりません。 + + + + + socket-type + + + stream, + dgram, raw または + seqpacket のどれかを指定します。 + stream + はコネクションに基づいた TCP デーモンに使用しなければならず、 + 一方で dgram は + UDP 転送プロトコルを利用したデーモンに対して使用されます。 + + + + + protocol + + + 次のうちのどれか 1 つを指定します。 + + + + + + プロトコル + 説明 + + + + + tcp, tcp4 + TCP IPv4 + + + udp, udp4 + UDP IPv4 + + + tcp6 + TCP IPv6 + + + udp6 + UDP IPv6 + + + tcp46 + TCP IPv4 および v6 の両方 + + + udp46 + UDP IPv4 および v6 の両方 + + + + + + + + + {wait|nowait}[/max-child[/max-connections-per-ip-per-minute]] + + + は + inetd から起動したデーモンが、 + 自分のソケットを管理できるかどうかを示します。 + 通常マルチスレッド化されている stream ソケットデーモンは + を使用するべきである一方、 + ソケットタイプは + wait オプションを使用しなければなりません。 + + は新しいソケット毎に子のデーモンを起動する一方で、 + + は通常複数のソケットを 1 つのデーモンに渡します。 + + inetd + が起動できる子のデーモンの最大数は + オプションで設定できます。 + 特定のデーモンに対して、起動する数が + 10 までという制限が必要な場合、 + の後に /10 + を置きます。 + + に加えて、他にある + 1 つの場所から特定のデーモンへの最大接続数を制限するオプションが利用できます。 + + がそれです。ここに 10 を指定すると、特定の + IP アドレスからの特定のサービスへの接続を + 1 分間につき 10 回に制限します。 + これは故意または故意でない資源の浪費および、 + マシンへのサービス不能 (DoS) 攻撃を防ぐのに有用です。 + + または + はこの欄に必ず必要です。 + および + + は任意です。 + + または + + 制限をかけない + stream タイプのマルチスレッドデーモンの設定は + nowait になります。 + + 作成できる子プロセスの上限が 10 である同じデーモンの設定は + nowait/10 になります。 + + さらに、 + 1 分間に IP アドレスあたりの接続制限が 20、 + 子プロセスの上限が 10 である同じデーモンの設定は + nowait/10/20 になります。 + + 以下のように、これらのオプションはすべて + fingerd + デーモンのデフォルト設定に使われています。 + + finger stream tcp nowait/3/10 nobody /usr/libexec/fingerd fingerd -s + + + + + user + + + user はあるデーモンが実行するときのユーザ名を指定します。 + 一般的にデーモンは root + ユーザとして実行します。セキュリティを考慮して、 + いくつかのサーバは daemon ユーザ、 + または最低の権限が与えられている nobody + ユーザとして実行することも多く見られます。 + + + + + server-program + + + 接続を受け取ったときに実行するデーモンのフルパスです。 + デーモンが inetd + によって内部的に提供されるサービスの場合 + を使用します。 + + + + + server-program-arguments + + + ここには、起動するときにデーモンに渡される、 + argv[0] から始まる引数を指定して、 + と協調して動作します。 + mydaemon -d がコマンドラインの場合、 + の値に + mydaemon -d を指定します。 + また、デーモンが内部サービスの場合、ここに + を指定します。 + + + + + + + セキュリティ + + インストールの時に選択したセキュリティプロファイルによっては、 + 多くの inetd + のデーモンがデフォルトで有効になっているかもしれません。 + あるデーモンが特に必要でない場合には、それを無効にしてください! + 問題となっているデーモンが記述されている行の先頭に + # をおいて inetd + にハングアップシグナルを送ってください。 + fingerd のようないくつかのデーモンは、 + 動かそうとすべきではないかもしれません。なぜなら、 + それらは攻撃者に対してあまりにも多くの情報を与えるからです。 + + セキュリティをあまり考慮せず、 + 接続試行に対してタイムアウトまでの時間が長いか、 + タイムアウトしないデーモンもあります。 + これは、特定のデーモンに攻撃者がゆっくり接続要求を送ることによって、 + 利用可能なリソースを飽和させることを可能にします。ある種のデーモンに + および + 制限を設けることはよい考えかもしれません。 + + TCP wrapper はデフォルトで有効です。 + inetd + から起動されるさまざまなデーモンに対して + TCP 制限を設けることの詳細については + &man.hosts.access.5; マニュアルページを参照してください。 + + + + その他 + + daytime, + time, + echo, + discard, + chargen および + auth はすべて + inetd + が内部的に提供するサービスです。 + + auth サービスは identity + (ident, identd) ネットワークサービスを提供し、 + ある程度設定可能です。 + + 詳細については &man.inetd.8; マニュアルを参照してください。 + + + + + パラレルライン IP (PLIP) + + PLIP + パラレルライン IP + + PLIP はパラレルポート間で TCP/IP 通信を可能にします。 + これはネットワークカードの無いマシンやノートパソコンにインストールするときに役に立ちます。 + この節では以下について説明します。 + + + + パラレル (ラップリンク または パラレルクロス) + ケーブルの作成。 + + + + 2 台のコンピュータの PLIP による接続。 + + + + + パラレル (クロス) ケーブルの作成 + + コンピュータ用品店のほとんどでパラレル (クロス) + ケーブルを購入することができます。 + 購入することができないか、 + 単にケーブルがどのような構造であるか知りたい場合は、 + 次の表に通常のパラレルプリンタケーブルをもとに作成する方法が示されています。 + + + ネットワーク向けのパラレル (クロス) ケーブル結線 + + + + + A-名称 + + A-端 + + B-端 + + 説明 + + Post/Bit + + + + + + DATA0 +-ERROR + + 2 +15 + + 15 +2 + + Data + + 0/0x01 +1/0x08 + + + + DATA1 ++SLCT + + 3 +13 + + 13 +3 + + Data + + 0/0x02 +1/0x10 + + + + DATA2 ++PE + + 4 +12 + + 12 +4 + + Data + + 0/0x04 +1/0x20 + + + + DATA3 +-ACK + + 5 +10 + + 10 +5 + + Strobe + + 0/0x08 +1/0x40 + + + + DATA4 +BUSY + + 6 +11 + + 11 +6 + + Data + + 0/0x10 +1/0x80 + + + + GND + + 18-25 + + 18-25 + + GND + + - + + + +
+ + + + PLIP の設定 + + はじめに、ラップリンクケーブルを入手しなければなりません。 + 次に、両方のコンピュータのカーネルが &man.lpt.4; + ドライバ対応であることを確認してください。 + + &prompt.root; grep lp /var/run/dmesg.boot +lpt0: <Printer> on ppbus0 +lpt0: Interrupt-driven port + + パラレルポートは割り込み駆動ポートでなければなりません。 + &os; 4.X では、 + 以下のような行がカーネルコンフィギュレーションファイル内になければならないでしょう。 + + device ppc0 at isa? irq 7 + + &os; 5.X では /boot/device.hints + ファイルに以下の行がなければならないでしょう。 + + hint.ppc.0.at="isa" +hint.ppc.0.irq="7" + + それからカーネルコンフィギュレーションファイルに + device plip という行があるか、または + plip.ko + カーネルモジュールが読み込まれていることを確認してください。 + どちらの場合でも &man.ifconfig.8 コマンドを直接実行したときに、 + パラレルネットワークインタフェースが現れるはずです。 + &os; 4.X ではこのようになります。 + + &prompt.root; ifconfig lp0 +lp0: flags=8810<POINTOPOINT,SIMPLEX,MULTICAST> mtu 1500 + + &os; 5.X ではこのようになります。 + + &prompt.root; ifconfig plip0 +plip0: flags=8810<POINTOPOINT,SIMPLEX,MULTICAST> mtu 1500 + + パラレルインタフェースに対して用いられるデバイス名は + &os; 4.X + (lpX) と + &os; 5.X + (plipX) + 間で異なります。 + + 両方のコンピュータのパラレルインタフェースにラップリンクケーブルを接続します。 + + 両方のネットワークインタフェースパラメータを + root で設定します。 + たとえば、&os; 4.X を動作させている host1 と + &os; 5.X を動作させている host2 + の両ホストを接続したい場合は次のようにします。 + + host1 <-----> host2 +IP Address 10.0.0.1 10.0.0.2 + + 次のコマンドで host1 + 上のインタフェースを設定します。 + + &prompt.root; ifconfig lp0 10.0.0.1 10.0.0.2 + + 次のコマンドで host2 + 上のインタフェースを設定します。 + + &prompt.root; ifconfig plip0 10.0.0.2 10.0.0.1 + + さて、これで接続が確立したはずです。詳細については &man.lp.4; + および &man.lpt.4; マニュアルページをご覧ください。 + + さらに/etc/hosts + に両ホストを加えるとよいでしょう。 + + 127.0.0.1 localhost.my.domain localhost +10.0.0.1 host1.my.domain host1 +10.0.0.2 host2.my.domain + + 接続がうまくいっているか確かめるために、 + 両方のホスト上で互いを ping してください。 + たとえば host1 で以下を実行します。 + + &prompt.root; ifconfig lp0 +lp0: flags=8851<UP,POINTOPOINT,RUNNING,SIMPLEX,MULTICAST> mtu 1500 + inet 10.0.0.1 --> 10.0.0.2 netmask 0xff000000 +&prompt.root; netstat -r +Routing tables + +Internet: +Destination Gateway Flags Refs Use Netif Expire +host2 host1 UH 0 0 lp0 +&prompt.root; ping -c 4 host2 +PING host2 (10.0.0.2): 56 data bytes +64 bytes from 10.0.0.2: icmp_seq=0 ttl=255 time=2.774 ms +64 bytes from 10.0.0.2: icmp_seq=1 ttl=255 time=2.530 ms +64 bytes from 10.0.0.2: icmp_seq=2 ttl=255 time=2.556 ms +64 bytes from 10.0.0.2: icmp_seq=3 ttl=255 time=2.714 ms + +--- host2 ping statistics --- +4 packets transmitted, 4 packets received, 0% packet loss +round-trip min/avg/max/stddev = 2.530/2.643/2.774/0.103 ms + + + + + + + + Aaron + Kaplan + 原作: + + + + + Tom + Rhodes + 再構成と追記: + + + + + IPv6 + IPv6 (IPng IP next generation とも呼ばれます) + は、著名な IP プロトコル + (IPv4 とも呼ばれます) の新しいバージョンです。 + 他の最新の *BSD システムと同様に FreeBSD は KAME + IPv6 リファレンス実装を含んでいます。したがって、あなたの + FreeBSD システムには IPv6を試すために必要なものすべてが備わっています。 + この節では IPv6 の設定と実行に関して説明します。 + + 1990 年代のはじめには、人々は IPv4 + アドレス空間が急速に縮小していることに気づくようになりました。 + インターネットの成長率が増大するにしたがって、 + 2 つの心配ごとがでてきました。 + + + + アドレスの枯渇。 + 今日では、プライベートアドレス空間 + (10.0.0.0/8, + 192.168.0.0/24 など) + およびネットワークアドレス変換 (NAT) + が使用されているので、それほど心配されていません。 + + + + ルーティングテーブルのエントリが大きくなりすぎていました。 + これは今でも心配な事柄です。 + + + + IPv6 は以下の、そしてその他多くの問題を扱います。 + + + + 128 bit アドレス空間。言い換えると、理論上 + 340,282,366,920,938,463,463,374,607,431,768,211,456 + 個のアドレスが利用可能です。これは地球上の一平方メータあたり、 + およそ 6.67 * 10^27 個の IPv6 アドレスがあることを意味します。 + + + + ルータは、 + ルーティングテーブル内にネットワーク集約アドレスだけを格納することで、 + ルーティングテーブルの平均を 8192 項目程度に減らします。 + + + + 他にも以下のように IPv6 の便利な機能がたくさんあります。 + + + + アドレス自動設定 (RFC2462) + + + + エニーキャスト (anycast) アドレス + (one-out-of many + 訳注: 複数の異なるノードが応答する 1 つのアドレス。 + RFC2526 を参照してください)。 + + + + 強制マルチキャストアドレス + + + + IPsec (IP セキュリティ) + + + + シンプルなヘッダ構造 + + + + モバイル IP + + + + IPv4 から IPv6 への移行手段 + + + + + 詳細については下記を参照してください。 + + + + Sun.com の IPv6 概観 + + + + IPv6.org + + + + KAME.net + + + + 6bone.net + + + + + IPv6 アドレスの背景 + いくつか違うタイプの IPv6 アドレスがあります。 + ユニキャスト (Unicast)、エニーキャスト (Anycast) + およびマルチキャスト (Multicast) です。 + + ユニキャストアドレスは周知のアドレスです。 + ユニキャストアドレスへ送られたパケットは、 + まさにそのアドレスに属するインターフェースに到着します。 + + エニーキャストアドレスはユニキャストアドレスと構文上判別不可能ですが、 + インタフェース群に宛てられています。 + エニーキャストアドレスに送られたパケットは (ルータメトリック的に) + 最も近いインタフェースに到着します。 + エニーキャストアドレスはルータでしか使ってはいけません。 + + マルチキャストアドレスはインタフェース群を識別します。 + マルチキャストアドレスに送られたパケットは、 + マルチキャスト群に属するすべてのインタフェースに到着します。 + + IPv4 のブロードキャストアドレス + (通常 xxx.xxx.xxx.255) + は、IPv6 ではマルチキャストアドレスで表現されます。 + + + + 予約された IPv6 アドレス + + + + + IPv6 アドレス + プレフィックス長 (ビット) + 説明 + 備考 + + + + + + :: + 128 ビット + 不特定 + IPv4 の + 0.0.0.0 参照 + + + + ::1 + 128 ビット + ループバックアドレス + IPv4 の + 127.0.0.1 参照 + + + + ::00:xx:xx:xx:xx + 96 ビット + IPv4 埋め込みアドレス + 下位の 32 ビットは IPv4 アドレスです。 + IPv4 互換 IPv6 アドレス とも呼ばれます。 + + + + ::ff:xx:xx:xx:xx + 96 ビット + IPv4 射影 IPv6 アドレス + 下位の 32 ビットは IPv4 アドレスです。 + IPv6 に対応していないホストに対するアドレスです。 + + + + fe80:: + - feb:: + 10 ビット + リンクローカル + IPv4 のループバックアドレス参照 + + + + fec0:: + - fef:: + 10 ビット + サイトローカル +   + + + + ff:: + 8 ビット + マルチキャスト +   + + + + 001 (基数 2) + 3 ビット + グローバルユニキャスト + すべてのグローバルユニキャストアドレスはこのプールから割り当てられます。 + はじめの 3 ビットは 001 です。 + + + +
+ + + + IPv6 アドレスを読む + 正規の書式では + x:x:x:x:x:x:x:x + と表されます。それぞれの + x は 16 ビットの 16 進数です。たとえば + FEBC:A574:382B:23C1:AA49:4592:4EFE:9982 + となります。 + + すべてゼロの長い部分文字列がアドレス内によく現れます。 + そのため、そのような部分文字列は :: + に短縮することができます。 + たとえば、fe80::1 は正規形の + fe80:0000:0000:0000:0000:0000:0000:0001 + に対応します。 + + 3 番目の形式は、最後の 32 ビットの部分を + . を分割文字として使う、 + なじみ深い IPv4 (10 進) 形式で書くことです。 + たとえば 2002::10.0.0.1 + は (16 進) 正規形の + 2002:0000:0000:0000:0000:0000:0a00:0001 + に対応し、同時に 2002::a00:1 + と書くこととも等価です。 + + ここまで来れば、下記を理解することができるでしょう。 + + &prompt.root; ifconfig + + rl0: flags=8943<UP,BROADCAST,RUNNING,PROMISC,SIMPLEX,MULTICAST> mtu 1500 + inet 10.0.0.10 netmask 0xffffff00 broadcast 10.0.0.255 + inet6 fe80::200:21ff:fe03:8e1%rl0 prefixlen 64 scopeid 0x1 + ether 00:00:21:03:08:e1 + media: Ethernet autoselect (100baseTX ) + status: active + + fe80::200:21ff:fe03:8e1%rl0 + は自動的に設定されたリンクローカルアドレスです。 + これは自動設定の一環として、 + イーサネット MAC アドレスを変換したものを含んでいます。 + + IPv6 アドレス構造についての詳細は RFC2373 をご覧ください。 + + + + 接続 + + 現在、他の IPv6 ホストおよびネットワークに接続するためには + 4 つの方法があります。 + + + + 6bone 実験ネットワークに参加する。 + + + + 上流のプロバイダから IPv6 ネットワークの割り当てを受ける。 + 手順については、インターネットプロバイダに問い合わせてください。 + + + + IPv6 over IPv4 によるトンネル。 + + + + ダイアルアップ接続の場合 freenet6 port を使用する。 + + + + ここでは、現在もっともよく使われている方法と思われる + 6bone へ接続する方法を説明します。 + + はじめに 6bone サイトをみて、 + あなたに最も近い 6bone 接続先を見つけてください。 + 責任者に連絡すると、少しばかり運がよければ、 + 接続を設定する方法についての指示を受けられるでしょう。 + 多くのばあい、これには + GRE (gif) トンネルの設定が含まれます。 + + + 訳注 + 6bone は 3ffe:: (16 ビット) + という IPv6 アドレスを割り振られた実験目的のネットワークでしたが、 + 2006 年 6 月に運用を停止することになっています。 + 他の商用や試験的な IPv6 接続サービスを探してください。 + + + ここに &man.gif.4; トンネルを設定する典型的な例を示します。 + + &prompt.root; ifconfig gif0 create +&prompt.root; ifconfig gif0 +gif0: flags=8010<POINTOPOINT,MULTICAST> mtu 1280 +&prompt.root; ifconfig gif0 tunnel MY_IPv4_ADDR HIS_IPv4_ADDR +&prompt.root; ifconfig gif0 inet6 alias MY_ASSIGNED_IPv6_TUNNEL_ENDPOINT_ADDR + + 大文字になっている単語を、 + 上流の 6bone ノードから受け取った情報に置き換えてください。 + + これでトンネルが確立されます。&man.ping6.8; を + ff02::1%gif0 + に送ることによって、トンネルが動作しているか確かめてください。 + ping の応答を 2 つ受け取るはずです。 + + ff02:1%gif0 + というアドレスに興味をそそられている場合のために説明すると、 + これはマルチキャストアドレスです。 + %gif0 は、ネットワークインタフェース + gif0 + 上のマルチキャストアドレスが使用されるということを示しています。 + マルチキャストアドレスに対して ping + を送ったので、トンネルのもう一方の端も応答します。 + + ここまで来ると 6bone + アップリンクに経路設定することは比較的簡単でしょう。 + + &prompt.root; route add -inet6 default -interface gif0 +&prompt.root; ping6 -n MY_UPLINK + + &prompt.root; traceroute6 www.jp.FreeBSD.org +(3ffe:505:2008:1:2a0:24ff:fe57:e561) from 3ffe:8060:100::40:2, 30 hops max, 12 byte packets + 1 atnet-meta6 14.147 ms 15.499 ms 24.319 ms + 2 6bone-gw2-ATNET-NT.ipv6.tilab.com 103.408 ms 95.072 ms * + 3 3ffe:1831:0:ffff::4 138.645 ms 134.437 ms 144.257 ms + 4 3ffe:1810:0:6:290:27ff:fe79:7677 282.975 ms 278.666 ms 292.811 ms + 5 3ffe:1800:0:ff00::4 400.131 ms 396.324 ms 394.769 ms + 6 3ffe:1800:0:3:290:27ff:fe14:cdee 394.712 ms 397.19 ms 394.102 ms + + この出力はマシンによって異なります。 + これで、あなたが www/mozilla + のような IPv6 が利用可能なブラウザを持っていれば、 + IPv6 サイト + www.kame.net + にいって踊るカメを見ることができるでしょう。 + + + + IPv6 世界の DNS + IPv6 のための新しい DNS レコードが 2 種類あります。 + + + + AAAA レコード + + + + A6 レコード + + + + AAAA レコードは簡単に使えます。 + + MYHOSTNAME AAAA MYIPv6ADDR + + 上記をプライマリゾーン DNS ファイルに加えて、 + もらったばかりの IPv6 アドレスにホスト名を割り当ててください。 + あなた自身で DNS ゾーンを管理していない場合は、 + DNS プロバイダに頼んでください。 + bind の最新バージョン + (バージョン 8.3 および 9) は AAAA レコードに対応しています。 diff --git a/ja_JP.eucJP/books/handbook/basics/chapter.xml b/ja_JP.eucJP/books/handbook/basics/chapter.xml index b5c9630b9a..68e93842c8 100644 --- a/ja_JP.eucJP/books/handbook/basics/chapter.xml +++ b/ja_JP.eucJP/books/handbook/basics/chapter.xml @@ -618,7 +618,7 @@ drwxr-xr-x 2 robert robert 512 Nov 10 11:54 public_html また、次のような場合も、ディレクトリツリーを 別のファイルシステムに置く理由として良くあげられます。 それは、たとえば物理的に別のディスクにディレクトリツリーを置く場合、 - ネットワークファイルシステム (Network File System) や + ネットワークファイルシステム (Network File System) や CDROM ドライブのような別の仮想ディスクに置くという場合です。 diff --git a/ja_JP.eucJP/books/handbook/disks/chapter.xml b/ja_JP.eucJP/books/handbook/disks/chapter.xml index 0f688934d3..7c884b07d3 100644 --- a/ja_JP.eucJP/books/handbook/disks/chapter.xml +++ b/ja_JP.eucJP/books/handbook/disks/chapter.xml @@ -2399,7 +2399,7 @@ echo "The floppy has been unmounted and is now ready."]]> メモリ - これには、Network File System + これには、Network File System のようなネットワークファイルシステムや Coda, メモリベースのファイルシステムおよびファイルベースのファイルシステムがあります。 diff --git a/ja_JP.eucJP/books/handbook/install/chapter.xml b/ja_JP.eucJP/books/handbook/install/chapter.xml index eb08fabebe..1da0949819 100644 --- a/ja_JP.eucJP/books/handbook/install/chapter.xml +++ b/ja_JP.eucJP/books/handbook/install/chapter.xml @@ -2541,7 +2541,7 @@ installation menus to retry whichever operations have failed. &gui.yes; を選んだ場合、 dhclient を実行します。設定が成功すると、 ネットワーク設定情報が自動補完されます。 詳細については - を参照してください。 + を参照してください。 次のネットワーク設定画面では、LAN 用ゲートウェイシステムのイーサネットデバイス構成が表示されます。 @@ -2935,7 +2935,8 @@ use the current settings. ネットワークファイルシステム (NFS) を用いると、 ネットワークを介してファイルの共有を行うことができます。 コンピュータをサーバ、クライアントまたは両方に設定できます。 - より詳しい情報については を参照してください。 + より詳しい情報については + を参照してください。 NFS サーバ @@ -3795,8 +3796,7 @@ Retype new password : このオプションを選択しないままにしておくことが出来ます。 システムは更なる設定を後で必要とします。 クライアントやサーバの設定についての詳細は - をご覧ください。 - + をご覧ください。 その下のオプションが NFS server オプションです。 システムを NFS サーバにセットアップできます。 -- cgit v1.2.3