diff --git a/ja_JP.eucJP/books/handbook/advanced-networking/chapter.sgml b/ja_JP.eucJP/books/handbook/advanced-networking/chapter.sgml index d15330974e..8b5536403d 100644 --- a/ja_JP.eucJP/books/handbook/advanced-networking/chapter.sgml +++ b/ja_JP.eucJP/books/handbook/advanced-networking/chapter.sgml @@ -1,1665 +1,2237 @@ 高度なネットワーク + + 概要 + + 以下の章では, UNIX システム上で頻繁に利用されるネットワーク + サービスに言及しています. これはもちろん, + あなたの FreeBSD システムでそのようなサービスを設定する場合に + 関係してきます. + + ゲートウェイとルート 原作: &a.gryphon;. 6 October 1995. 訳: &a.jp.yuki;. 6 September 1996. ある計算機が他の計算機をみつけることができるようにするには, ある計算機から他の計算機へ, どのようにたどり着くかを適切に記述するための仕組みが必要です. - この仕組みをルーティングと呼びます. “ルート(経路)”は - “destination (目的地) ”と “gateway - (ゲートウェイ) ”の 2つのアドレスの組で定義します. あなたが + この仕組みをルーティングと呼びます. ルート(経路)は + destination (目的地) と gateway + (ゲートウェイ) の 2 つのアドレスの組で定義します. あなたが destination へアクセスしようとした場合, gateway を通って送られることをこのペアは示しています. destination - には個々のホスト, サブネット, “デフォルト”の 3つの + には個々のホスト, サブネット, デフォルト の 3つの タイプがあります. - “デフォルトルート”は他への経路が適用できない + デフォルトルート は他への経路が適用できない 場合に使われます. のちほどデフォルトルートについて少し述べること するとして, ここでは, 個々のホスト, インタフェース - (“リンク”と も呼ばれます), + (リンク とも呼ばれます), イーサネットハードウェアアドレスという 3つのタイ プのゲートウェイについて説明します. 例 以下に示す netstat -r の出力の例を使って, ルーティン グがいろいろと異なっている様子を説明することにします. Destination Gateway Flags Refs Use Netif Expire default outside-gw UGSc 37 418 ppp0 localhost localhost UH 0 181 lo0 test0 0:e0:b5:36:cf:4f UHLW 5 63288 ed0 77 10.20.30.255 link#1 UHLW 1 2421 foobar.com link#1 UC 0 0 host1 0:e0:a8:37:8:1e UHLW 3 4601 lo0 host2 0:e0:a8:37:8:1e UHLW 0 5 lo0 => host2.foobar.com link#1 UC 0 0 224 link#1 UC 0 0 最初の2行はデフォルトルート(次の節で詳しく説明します)と, localhostへの経路を示しています. localhostのためのインタフェース (Netifの欄) はlo0で, これはループバックデバイスとして知られています. 結局のところ戻るだけなので, この destinationへのすべてのトラフィックが 内部的に処理されるのであって, LAN を経由して送られるのではありません. 次の行では 0:e0:... というアドレスに注目しましょう. これはイーサネットハードウェアアドレスです. FreeBSDは自動的に ローカルなイーサネット上の任意のホスト (この例ではtest0) を見つけ, イーサネットインタフェース ed0 の所にそのホストへの経路を直接つけ加えます. タイムアウト時間 (Expireの 欄) も経路のタイプと結びついており, 指定された時間が経過しても応 答がないときに使用します. この場合, 経路情報は自動的に削除されま す. これらのホストは, RIP(Routing Information Protocol) という, 最短パスの判定に基づいてローカルホストへの経路を 決定する仕組みを利用することで認識されます. 更に, FreeBSDではローカルサブネット (10.20.30.255 は 10.20.30 というサブネットに対するブロードキャストアドレスで, foobar.com はこのサブネットに結びつけられているドメイン名) への経路情報も加えることができます. link#1というのは, この計算機の最初のイーサネットカードのことをさします. これら については, 何も追加インタフェースが指定されていないことに気づく でしょう. これらの2つのグループ(ローカルネットワークホストと ローカルサブネット) の両方とも, routed と呼ばれるデーモンによって自動的に経路が設定されます. routed を動かさなければ, 静的に定義した (つまり具体的に設定した) 経路のみ存在することになります. host1 の行は私たちのホストのことで, イーサネットアドレスで示されています. 送信側のホストの場合, FreeBSDはイーサネットインタフェースへ送るのではなく, ループバックインタフェース (lo0)を使います. 2つあるhost2の行は, ifconfigのエイリアス (このようなことをする理由については ethernetの章を参照してください) を使ったとき にどのようになるかを示す例です. lo0の後にある=> は, インタフェースが (このアドレスがローカルなホストを参照しているので) ループバックを使っているというだけでなく, エイリアスになっていることも示しています. このような経路はエイリアスをサポートしている ホストにのみ現れます. ローカルネットワーク上の他のすべてのホストでは 単にlink#1となります. 最後の行 (destinationが224のサブネット) はマルチキャストで扱うものですが, これは他の章で説明します. 他の欄については Flags について説明する必要があります. それぞれの経路は欄に示されているように違った属性を もっています. 以下にいくつかのフラグとこれらが何を意味しているかを示します. U Up: この経路はアクティブです. H Host: 経路の destinationが単一のホストです. G Gateway: この destinationへ送られると, どこへ送れ ばよいかを明らかにして, そのリモートシステムへ送られます. S Static: この経路はシステムによって自動的に生成 されたのではなく, 手動で作成されました. C Clone: マシンに接続したときにこの経路に基づく 新しい経路が作られます. このタイプの経路は通常は ローカルネットワークで使われます. W WasCloned: ローカルエリアネットワーク(Clone) の経路に基づいて 自動的に生成された経路であることを示します. L Link: イーサネットハードウェアへの参照を含む 経路です. デフォルトルート ローカルシステムからリモートホストにコネクションを張る 必要がある場合, 既知のパスが存在するかどうかを確認するためにル ーティングテーブルをチェックします. 到達するためのパスを知っているサブネットの内部に リモートホストがある場合 (Cloned routes), システムはインタフェース から接続できるかどうかをチェックします. 知っているパスがすべて駄目だった場合でも, システムには - 最後の切り札の “デフォルト”ルートがあります. + 最後の切り札の デフォルト ルートがあります. このルートは ゲートウェイルート (普通はシステムに 1つしかありません) の特別なものです. そして, フラグフィールドは必ず c がマークされています. このゲートウェイは, LAN 内のホストにとっ て, 外部 (PPPのリンクを経由する場合や, データラインに接続するハードウェアデバイスなど) へ直接接続するマシンすべてのためのものです. 外部に対するゲートウェイとして機能するマシンで デフォルトルートを設定する場合, デフォルトルートはインターネットサービスプロバイダ (ISP) のサイトのゲートウェイマシンになるでしょう. それではデフォルトルートの一例を見てみましょう. 一般的な構成を示します. [Local2] <--ether--> [Local1] <--PPP--> [ISP-Serv] <--ether--> [T1-GW] ホスト Local1 とホスト Local2 を PPP で ISP のターミナルサーバと接続されているあなたの サイトだとします. ISP はサイト内にロー カルなネットワークを持っていて, そこにはまざまなものがあり, あなたの接続するサーバや ISP のインターネットへの 接続点であるハードウェアデバイス (T1-GW) などがあります. あなたのマシンのデフォルトルートは それぞれ次のようになります. host default gateway interface Local2 Local1 ethernet Local1 T1-GW PPP - “なぜ (あるいは, どうやって) Local1 の + なぜ (あるいは, どうやって) Local1 の デフォルトゲートウェイをISPのサーバでなく - T1-GWにセットするのか”という質問がよくあります. + T1-GWにセットするのか という質問がよくあります. コネクションのローカルの側については, PPPのインタフェースは ISPのローカルネットワーク上のアドレスを用いているため, ISPのローカルネットワーク上のすべてのマシンへの経路は 自動的に生成されています. つまり, あなたのマシンは, どのようにT1-GW まで届くかという経路を既に知っていることになりますから, ISPサーバに媒介的なトラフィックをかける必要はありません. 最後になりましたが, 一般的にローカルネットワークでは ...1 というアドレスをゲートウェイアドレスとして使います. ですから (同じ例を用います), あなたのclass-Cのアドレス空間が 10.20.30で ISPが 10.9.9を用いている場合, デフォルトルートは次のようになります. Local2 (10.20.30.2) --> Local1 (10.20.30.1) Local1 (10.20.30.1, 10.9.9.30) --> T1-GW (10.9.9.1) マルチホームホスト ここで扱うべき他のタイプの設定があります. それは2つの異なるネットワークにまたがるホストです. 技術的にはゲートウェイとして機能するマシン (上 の例では PPPコネクションを用いています) はマルチホームホストで す. しかし実際にはこの言葉は, 2つのローカルエリアネットワーク上のサ イトであるマシンを指す言葉としてのみ使われます. 2枚のイーサネットカードを持つマシンが, 別のサブネット 上にそれぞれアドレスを持っている場合があります. あるいは, イーサネットカードを1枚持っているマシンで, ifconfigのエイリアスを使っているかもしれません. 物理的に分かれている2つのイーサネットのネットワークが使われて いるならば前者が用いられます. 後者は, 物理的には1つのネットワ ークセグメントで, 論理的には分かれている 2つのサブネットとする 場合に用いられます. どちらにしても, このマシンがお互いのサブネットへのゲートウェイ (inbound route) として定義されていることが分かるように, おのお ののサブネットでルーティングテーブルを設定します. このマシンが 2 つのサブネットの間のブリッジとして動作するという構成は, パケ ットのフィルタリングを実装する必要がある場合や, 一方向または双 方向のファイアウォールを利用したセキュリティを構築する場合によ く用いられます. ルーティングの伝播 すでに外部との経路をどのように定義したらよいかは 説明しました. しかし外部から私たちのマシンをどのようにして 見つけるのかについては説明していません. ある特定のアドレス空間 (この例では class-C のサブネット) におけるすべてのトラフィックが, 到着したパケットを内部で転送するネ ットワーク上の特定のホストに送られるようにルーティングテーブル を設定することができるのは分かっています. あなたのサイトにアドレス空間を割り当てる場合, あなたのサブネットへのすべてのトラフィックがすべて PPPリンクを通じてサイトに送 ってくるようにサービスプロバイダはルーティングテーブルを設定し ます. しかし, 国境の向こう側のサイトはどのようにしてあなたの ISPへ送ることを知るのでしょうか? 割り当てられているすべてのアドレス空間の経路を維持する (分散している DNS 情報とよく似た) システムがあり, そのインターネット バックボーンへの接続点を定義しています. - “バックボーン” とは国を越え, + バックボーン とは国を越え, 世界中のインターネットのトラフィックを運ぶ主要 な信用できる幹線のことです. どのバックボーンマシンも, あるネットワークから特定のバックボーンのマシンへ 向かうトラフィックと, そのバックボーンのマシンからあなたのネットワークに届くサービス プロバイダまでのチェーンのマスタテーブルのコピーを持っていま す. あなたのサイトが接続(プロバイダからみて内側にある ことになります) したということを, プロバイダからバックボー ンサイトへ通知することはプロバイダの仕事です. これが経 路の伝搬です. トラブルシューティング ルーティングの伝搬に問題が生じて, いくつかのサイトが 接続をおこなうことができなくなることがあります. ルーティングがどこでおかしくなっているかを明らかにするのに 最も有効なコマンドはおそらく &man.traceroute.8; コマンドでしょ う. このコマンドは, あなたがリモートマシンに対して接続をおこなう ことができない(例えば &man.ping.8; に失敗するような場合) 場合も, 同じように有効です. &man.traceroute.8; コマンドは, 接続を試みているリモートホストを引数にして実行します. 試みているパスの経由するゲートウェイホストを表示し, 最終的には目的のホストにたどり着くか, コネクションの欠如によって終ってしまうかのどちら かになります. より詳しい情報は, &man.traceroute.8; のマニュアルページをみてください. + + Bridging + + Written by Steve Peterson + steve@zpfe.com. + + + はじめに + + IP サブネットを作成し, それらのセグメントをルータを + 使って接続したりせずに, (Ethernet セグメントのような) + 物理ネットワークを二つのネットワークセグメントに分割することは + とても有効な場合があります. + このような二つのネットワークを繋ぐデバイスはブリッジと呼ばれます. + そして, 二つのネットワークインターフェイスカードを持つ FreeBSD + システムは, ブリッジとして動作することができます. + + ブリッジは, 各ネットワークインターフェイスに繋がる + デバイスの MAC 層のアドレス (例えば Ethernet アドレス) + を記憶します. + ブリッジはトラフィックの送信元と受信先が異なったネットワーク上に + ある場合にのみ, トラフィックを転送します. + + すなわち, ブリッジはポート数の少ない Ethernet スイッチ + だ, ということができます. + + + + ブリッジがふさわしい状況とは + + 今日ブリッジが活躍する場面は大きく分けて二つあります. + + + トラフィックの激しいセグメント + + ひとつは, 物理ネットワークセグメントがトラフィック + 過剰になっているが, なんらかの理由によりネットワークを + サブネットに分け, ルータで接続することができない場合です. + + 編集部門と製作部門がおなじサブネットに同居している + 新聞社を例に考えてみましょう. + 編集部門のユーザはファイルサーバとして全員サーバ A を利用し, + 製作部門のユーザはサーバ B を利用します. + すべてのユーザを接続するのには Ethernet が使われており, + 高負荷となったネットワークは遅くなってしまいます. + + もし編集部門のユーザを一つのネットワークセグメントに + 分離することができ, 製作部門もユーザも同様にできるのなら, + 二つのネットワークセグメントをブリッジで繋ぐことができます. + ブリッジの "反対" 側へ向かうネットワークトラフィックだけが + 転送され, 各ネットワークセグメントの混雑は緩和されます. + + + + パケットフィルタ/帯域制御用ファイアウォール + + もうひとつは, IP Masquerading (NAT) を使わずに + ファイアウォール機能を利用したい場合です. + + ここでは DSL もしくは ISDN で ISP に接続している + 小さな会社を例にとってみましょう. + この会社は ISP から 13 個のグローバル IP アドレスの割り当て + を受けており, ネットワーク内には 10 台の PC が存在します. + このような状況では, サブネット化にまつわる問題から + ルータを用いたファイアウォールを利用することは困難です. + + ブリッジを用いたファイアウォールなら, + IP アドレスの問題を気にすること無く, DSL/ISDN ルータの + 下流側に置くように設定できます. + + + + + ブリッジを設定する + + + ネットワークインターフェイスカードの選択 + + ブリッジを利用するには少なくとも二つのネットワークカードが + 必要です. + 残念なことに, FreeBSD 4.0 ではすべてのネットワークインターフェイス + カードがブリッジ機能をサポートしているわけではありません. + カードがサポートされているかどうかについては &man.bridge.4; + を参照してください. + + 以下に進む前に, 二つのネットワークカードをインストールして + テストしてください. + + + + カーネルコンフィグレーションの変更 + + カーネルでブリッジ機能を有効にするには + + option BRIDGE + + という行をカーネルコンフィグレーションファイルに追加して + カーネルを再構築してください. + + + + ファイアウォール機能 + + ブリッジと同時にファイアウォール機能も利用しようとしている + 場合には, IPFIREWALL オプションも指定する必要があります. + ブリッジをファイアウォールとして設定する際の一般的な + 情報に関しては, + を参照してください. + + IP 以外のパケット (ARP など) がブリッジを通過するように + するためには, ドキュメント化されていないファイアウォール用 + オプションを設定する必要があります. このオプションは + IPFIREWALL_DEFAULT_TO_ACCEPT です. + この変更により, デフォルトではファイアウォールがすべての + パケットを accept するようになることに注意してください. + この設定を行う前に, この変更が自分のルールセットにどのような + 影響をおよぼすかを把握しておかなければなりません. + + + + 帯域制御機能 + + ブリッジで帯域制御機能を利用したい場合, + カーネルコンフィグレーションで DUMMYNET + オプションを加える必要があります. + 詳しい情報に関しては &man.dummynet.4; を参照 + してください. + + + + + ブリッジを有効にする + + ブリッジを有効にするには, + /etc/sysctl.conf に以下の行を加えてください: + + + net.link.ether.bridge=1 + + ブリッジを経由したパケットを ipfw でフィルタしたい場合には, + + + net.link.ether.bridge_ipfw=1 + + という行も付け加える必要があります. + + + + パフォーマンス + + 私のブリッジ/ファイアウォールは Pentium 90 で, + 3Com 3C900B と 3c905B を使っています. + 防護される側のネットワークは 10Mbps の half duplex で, + ブリッジとルータ (Cisco 675) の間は 100Mbps full duplex で + 動作しています. + パケットフィルタを利用しない場合, 防護されている 10Mbps + ネットワークから Cisco 675 への ping では, + ブリッジにより 0.4 ミリ秒の遅延が発生しています. + + + + その他の情報 + + ネットワークからブリッジに telnet したい場合, + ネットワークカードの一つに IP アドレスを割り当てれば OK です. + 一般的に, 両方のカードに IP アドレスを割り当てるのは + よいアイデアではないとされています. + + ネットワーク内に複数のブリッジを設置する場合, + 任意のワークステーション間で一つ以上の経路を持つことは + できません. 技術的には, これは spanning tree link management + はサポートされていない, ということを意味します. + + + NFS + Written by &a.unfurl;, 4 March 2000. + + FreeBSD がサポートしている多くのファイルシステムの中でも, + NFS, すなわち Network File System は極めてユニークな存在です. + NFS はあるマシンから他のマシンへと, ネットワークを通じて + ディレクトリとファイルを共有することを可能にします. + NFS を使うことで, ユーザやプログラムはリモートシステムのファイルを, + それがローカルファイルであるかのようにアクセスすることができます. + + + NFS には以下の利点があります: + + + + 一般的に使われるデータを単一のマシンに納める + ことができ, ネットワーク上のユーザはデータにアクセスできる + ため, ローカルワークステーションは多くのディクスを + 必要としません. + + + + ネットワーク上のすべてのマシンに, + ユーザが独自のホームディレクトリを持つ必要がありません. + 一旦 NFS 経由でアクセスできるディレクトリができれば, + どこからでもアクセス可能です. + + + + フロッピーや CD-ROM ドライブなどのストレージデバイスを, + 追加のハードウェアなしにネットワーク上の他のマシンに + 使ってもらうことができます. + + + + + どのようにして動作するのか + + NFS はクライアント, サーバの二つの部分から + 構成されます. + これは 需要(want)/供給(have) の関係として考えることができます. + クライアントはサーバが 供給 している + データに対する 需要 があります. + サーバはそのデータをクライアントと共有します. + このシステムが適切に機能するために, いくつかのプロセスが + 設定され正しく動作していなければなりません. + + サーバは以下のデーモンを動作させなければなりません: + + + + nfsd - NFS クライアントからの + リクエストを処理する NFS デーモン. + + + + mountd - nfsd から渡された + リクエストを実際に実行する NFS マウントデーモン. + + + + クライアント側ではデーモンを一つ実行する必要があります: + + + + nfsiod - NFS サーバからのリクエストを + 処理する NFS 非同期 I/O デーモン. + + + + + + NFS を設定する + + 幸運なことに, FreeBSD システムで設定を行うのは簡単です. + 実行させなければならないプロセスは, /etc/rc.conf + ファイルをちょっと編集することでブート時から実行させる + ことができます. + + NFS サーバでは, 以下の設定が必要です: + + +nfs_server_enable="YES" +nfs_server_flags="-u -t -n 4" +mountd_flags="-r" + + mountd は NFS サーバが有効になっている + 場合, 自動的に実行されます. + nfsd への + , フラグは + クライアントに UDP と TCP のサービスを提供することを指示します. + フラグは nfsd + が 4 つのコピーを立ち上げることを指示します. + + クライアント側では, 以下のようにします: + + +nfs_client_enable="YES" +nfs_client_flags="-n 4" + + nfsd と同様に, + は nfsiod + が 4 つのコピーを立ち上げることを指示します. + + 最後に /etc/exports という + 設定ファイルを作成します. + exports ファイルはサーバのどのファイルシステムが + 共有されるのか (exported といいます), + またどのクライアントが共有できるのかを指定します. + + ファイル中の各行は, 共有されるファイルシステムを + 指定します. + ファイル中で指定できるオプションはたくさんありますが, + そのうちの少ししか使うことはないでしょう. + より細かいことに関しては &man.exports.5; + マニュアルページをお読み下さい. + + + いくつか /etc/exports の設定例 + を示します: + + 以下の設定は, + サーバと同じドメイン名(ドメイン名が無いので)か, + /etc/hosts に記述のある三つのマシン + に対して, /cdrom を export します. + オプションは共有されるファイルシステムを + 読み込み専用にします. + このフラグにより, リモートシステムは共有されたファイルシステム + にたいして何の変更も行えなくなります. + + /cdrom -ro moe larry curly + + 以下の設定は, IP アドレスによる三つのホストに対して + /home を export します. + この設定はプライベートネットワークで DNS が走っていない + 場合に便利な設定でしょう. + フラグは指定されたファイルシステム + 以下のディレクトリに対しても同様に export します. + + /home -alldirs 10.0.0.2 10.0.0.3 10.0.0.4 + + 以下の設定は, サーバとは異なるドメイン名の二つの + マシンに対して /a を export します. + フラグは, リモートマシンの + root ユーザが共有されたファイルシステムに root として書き込むことを + 許可します. + -maproot=0 フラグが無ければ, リモートマシンの root 権限を + 持っていても共有されたファイルシステム上のファイルを変更する + ことはできません. + + + + /a -maproot=0 host.domain.com box.example.com + + クライアントが export されたファイルシステムを共有 + する際には, そのような権限が与えられていなければなりません. + /etc/exports ファイルに + クライアントが含まれているかどうか確認してください. + + + + 必要な変更はすべて行ったので, + FreeBSD を再起動してブート時からすべてが起動するようにするか, + root で以下のコマンドを実行します: + + NFS サーバでは: + + &prompt.root; nfsd -u -t -n 4 +&prompt.root; mountd -r + + NFS クライアントでは: + + &prompt.root; nfsiod -n 4 + + これでリモートのファイルシステムを実際にマウントする + 準備ができました. + やり方は二通りあります. + この例では, サーバの名前は server で, + クライアントの名前は client とします. + リモートファイルシステムを一時的にマウントするだけ, + もしくは設定をテストするだけなら, クライアント上で root + として以下のコマンドを実行してください: + + &prompt.root; mount server:/home /mnt + + これにより, クライアントの /mnt + ディレクトリにサーバの /home が + マウントされます. + もしすべてが正しく設定されていれば, クライアントの /mnt + に, サーバにあるファイルすべてが見えるようになっているはずです. + + + リモートファイルシステムを今後も (リブートする度に) + マウントしたいなら, /etc/fstab + ファイルに設定を追加する必要があります. + 例としてはこのようになります: + + server:/home /mnt nfs rw 0 0 + + ほかのオプションに関しては &man.fstab.5; マニュアル + ページをお読み下さい. + + + + 典型的な使い方 + + NFS にはいくつかすてきな使い方があります. + 私は自分が管理している LAN でそれらを利用しています. + そのうちにいくつかをここで紹介しましょう. + + ネットワークには幾つかのマシンがありますが, + CD-ROM ドライブを持っているのは一台だけです. + なぜかって? それは一台の CD-ROM ドライブをほかのマシンと + NFS 経由で共有しているからです. + フロッピードライブについても同じことがいえます. + + ネットワーク内に多くのマシンがあると, 様々な場所に + ちらばる個人的なファイルは日に日に古くなってしまいます. + 私はすべてのユーザのホームディレクトリを格納する, + 中心となる NFS サーバを用意し, LAN 上の残りのマシンと + 共有しています. そうすることで, どこにログインしても, + 同じホームディレクトリを使うことができるのです. + + マシンのひとつに FreeBSD を再インストールするなら, + NFS こそその方法です. ディストリビューション CD をファイル + サーバに入れ, 再インストールを実行するだけです. + + 共用の /usr/ports/distfiles + ディレクトリを用意して, すべてのマシンで共有しています. + この方法だと, 別のマシンで既にインストールしたことのある + port をインストールする場合, 再びすべてのソースをダウンロードする + 必要がなくなります. + + + + Problems integrating with other systems + 原作: &a.jlind;. 訳: &a.jp.tomo;. 6 September 1996. ISA用のイーサネットアダプタの中には性能が悪いため, ネットワーク, 特に NFS で深刻な問題がおきるものがあります. これは FreeBSD に限ったことではありませんが, FreeBSD でも起こり得ます. この問題は, (FreeBSDを使用した) PC がシリコン・グラフィックス社や サン・マイクロシステムズ社などの高性能な WS にネットワーク接続されている場合に頻繁に起こります. NFS マウントはうまく行きます. また, いくつかの操作もうまく働きますが, 他のシステム (WS) に対する要求や応答は続いていても, 突然サーバが クライアントの要求に対して反応しなくなります. これは, クライアントが FreeBSD か上記の WS であるとき, にクライアント側に起きる現象です. 多くのシステムでは, いったんこの問題が現われると, 行儀良くクライアントを終了する手段はありません. NFS がこの状態に陥ってしまうと, 正常に戻すことはできないため, 多くの場合, クライアントを強制終了し, 再び実行することが唯一の解決法となります. - “正しい”解決法は, + 正しい解決法は, より高性能のイーサネットアダプタをFreeBSDシステムに インストールすることですが, 満足な操作ができるような簡単な方法があります. もし, FreeBSDシステムがサーバになるのなら, クライアントからのマウント時に オプションをつけて下さい. もしFreeBSDシステムがクライアントになる のなら, NFSファイルシステムを オプションつきでマウントして下さい. これらのオプションは自動的にマウントをおこなう場合には クライアントの fstab エントリの4番目のフィールドに指定してもよいですし, 手動マウントの場合は mount コマンドの パラメータで指定してもよいでしょう. NFSサーバとクライアントが別々のネットワーク上にあるような 場合, これと間違えやすい他の問題が起きることに注意して下さい. そのような場合は, ルータが必要な UDP 情報をきちんと ルーティングしているかを確かめて下さい. そうでなければ, たとえあなたが何をしようと解決できないでしょう. 次の例では, fastwsは高性能のWSのホスト (インタフェース)名で, freeboxは低性能のイーサネットアダプタを備えた FreeBSDシステムのホスト(インタフェース)名です. また, /sharedfs はエクスポートされる NFS ファイルシステムであり (man exports を見て下さい), /project はエクスポートされたファイルシステムの クライアント上のマウントポイントとなります. 全ての場合において, や , といった追加オプションが アプリケーションにより要求されるかもしれないことに 注意して下さい. クライアント側 FreeBSD システム (freebox) の例は: freebox の /etc/fstab に次のように書いて下さい: fastws:/sharedfs /project nfs rw,-r=1024 0 0 freebox 上で手動で mount コマンドを実行する場合は次のようにして下さい: &prompt.root; mount -t nfs -o -r=1024 fastws:/sharedfs /project サーバ側FreeBSDシステムの例は: fastws の /etc/fstab に次のように書いて下さい: freebox:/sharedfs /project nfs rw,-w=1024 0 0 fastws 上で手動で mount コマンドで実行する場合は次のようにして下さい: &prompt.root; mount -t nfs -o -w=1024 freebox:/sharedfs /project 近いうちにどのような 16 ビットのイーサネットアダプタでも 上記の読み出し, 書き込みサイズの制限なしの操作ができるようになるでしょう. 失敗が発生したとき何が起きているか関心のある人に, なぜ回復不可能なのかも含めて説明します. NFSは通常 (より小さいサイズへ分割されるかもしれませんが) - 8Kの“ブロック” サイズで働きます. + 8Kのブロック サイズで働きます. イーサネットのパケットサイズは最大1500バイト程度なので, 上位階層のコードにとっては1つのユニットのままなのですが, - NFS“ブロック”は + NFS ブロックは 複数のイーサネットパケットに分割されます. そして受信され, 組み立て直されてから肯定応答 されなければなりません. 高性能のWSは次々に NFSユニットを構成するパケットを, 基準の範囲内で間隔を詰めて次々に送り出すことができます. 小さく, 容量の低いカードでは, 同じユニットの 前のパケットがホストに転送される前に, 後のパケットがそれを 踏みつぶしてしまいます. このため全体としてのユニットは再構成もされないし, 肯定応答もされません. その結果, WSはタイムアウトして再送を試みますが, 8Kのユニット全体を再送しようとするので, このプロセスは 際限無く繰り返されてしまいます. ユニットサイズをイーサネットのパケットサイズの 制限以下に抑えることにより, 受信された完全な イーサネットパケットは個々に肯定応答を受けられることが 保証されるので, デッドロック状態を避けることができるようになります. 高性能のカードを使っている場合でも, 高性能な WS が力任せに次々と PC システムにデータを送ったときには 踏みつぶし が起きるかもしれません. そのような踏みつぶし - は NFS “ユニット” + は NFS ユニット では保証されていません. 踏みつぶしが起こったとき, 影響を受けたユニットは再送されます. そして受信され, 組み立てられ, 肯定応答される公平な機会が与えられるでしょう. + Diskless operation 原作: &a.martin; 訳: &a.jp.yasu; netboot.com/netboot.rom によって, ディスクのないクライアントでネットワーク経由で FreeBSD マシンのブートを行い FreeBSD を走らせることができます. 2.0 ではローカルなスワップを持つことができます. NFS 経由のスワッピングもサポートされています. サポートされているイーサネットカード: Western Digital/SMC 8003, 8013, 8216 とその互換ボード, NE1000/NE2000 とその互換カード (再コンパイルが必要) セットアップの手順 サーバにするマシンを見つけます. このマシンには, FreeBSD 2.0のバイナリとbootpを 記憶するだけの十分なディスクスペースが必要です. tftp と NFS も使えます. テストしたマシン: HP9000/8xx / HP-UX 9.04以降 (9.04以前では動きません) Sun/Solaris 2.3. (bootpが必要) クライアントにIP,gateway,netmaskを提供する bootpサーバをセットアップします. diskless:\ :ht=ether:\ :ha=0000c01f848a:\ :sm=255.255.255.0:\ :hn:\ :ds=192.1.2.3:\ :ip=192.1.2.4:\ :gw=192.1.2.5:\ :vm=rfc1048: クライアントにブート情報を提供する TFTP サーバを (bootp サーバと同じマシンに) セットアップします. このファイルの名前は, cfg.X.X.X.X (もしくは /tftpboot/cfg.X.X.X.X )で, ここで X.X.X.X はクライアントの IP アドレスです. このファイルの内容は netboot コマンドで有効です. 2.0では, netboot は以下のようなコマンドを持ちます: help helpリストの表示 ip クライアントのIPアドレスの表示/セット server bootp/tftp サーバのアドレスの表示/セット netmask netmaskの表示/セット hostname name hostnameの表示/セット kernel カーネル名の表示/セット rootfs root ファイルシステムの表示/セット swapfs swap ファイルシステムの表示/セット swapsize - diskless swapsize を Kbytes単位でセット + diskless swapsize を KBytes単位でセット diskboot ディスクからのブート autoboot ブートプロセスの続行 trans | トランシーバのオン|オフ flags ブートフラグの設定 完全にディスクレスな場合の一般的な cfg ファイルは以下のようになります: rootfs 192.1.2.3:/rootfs/myclient swapfs 192.1.2.3:/swapfs swapsize 20000 hostname myclient.mydomain ローカルに swap を持つマシンについては以下のようになります: rootfs 192.1.2.3:/rootfs/myclient hostname myclient.mydomain NFS サーバがクライアントにroot(必要ならswapも) ファイルシステムをexportしているか, また, クライアントがこれらのファイルシステムに ルートアクセスできるか確認します. FreeBSDにおける一般的な /etc/exports ファイルは 以下のようになります: /rootfs/myclient -maproot=0:0 myclient.mydomain /swapfs -maproot=0:0 myclient.mydomain そして, HP-UX側では以下のようになります: /rootfs/myclient -root=myclient.mydomain /swapfs -root=myclient.mydomain NFS経由でスワッピングを行う場合 (完全にディスクレスな場合の設定), クライアントが使用する swap ファイルを dd で作成します. もし, swapfs コマンドが上記の例のように 引数 /swapfsを持ちそのサイズが 20000 である場合, myclientに対するスワップファイルは /swapfs/swap.X.X.X.X で呼び出されます. ここで X.X.X.X はクライアントの IP アドレスです. 例: &prompt.root; dd if=/dev/zero of=/swapfs/swap.192.1.2.4 bs=1k count=20000 また, スワッピングが開始されるとクライアントの スワップスペースはセンシティブな情報を含むようになるので, 不正なアクセスを防止するため, このファイルへの 読み書きのアクセス制限がなされていることを確認して下さい: &prompt.root; chmod 0600 /swapfs/swap.192.1.2.4 クライアントがそれぞれのrootファイルシステムとして使う ディレクトリにrootファイルシステムを展開します. (上記の例では/rootfs/myclient). HP-UX システム: サーバはHP9000/800 シリーズのマシンで, HP-UX 9.04 以降が必要です. これ以前のバージョンでは NFS を経由するデバイスファイルが作成ができません. /rootfs/myclient に /dev を 展開する際に, いくつかのシステム (HPUX) では FreeBSD に合った デバイスファイルが作成されないので 注意してください. その際には最初の起動時にシングルユーザモードに 移行して (ブートの段階でCtrl-Cを押す), /dev に移って sh ./MAKEDEV all として, クライアントからこれを 修正してください. クライアントで netboot.com を実行するか, netboot.rom ファイルから EPROMを作成します. <filename>/</filename> および <filename>/usr</filename> ファイルシステムを共有して使用する 今のところ, これを行う公式に認められた方法はありませんが, 私はそれぞれのクライアントで /usr ファイルシステムと個々の / ファイルシステムを共有して使っています. どなたかこれをきちんと行うやり方の提案がありましたら, 私に, もしくは &a.core; グループに知らせてください. 特定の設定についてnetbootをコンパイルする /sys/i386/boot/netboot/Makefile の中の設定を変更して コンパイルすることで, netbootでNE1000/2000 カードをサポートします. このファイルの先頭にあるコメントを見てください. ISDN 最終更新: &a.wlloyd;. 訳: &a.jp.kiroh;. 11 December 1996. ISDN 技術とハードウェアに関しては, Dan Kegel's ISDN Page がよい参考になるでしょう. ISDN の導入手順は, 簡単にいって以下のようになります. ヨーロッパ在住の方は, ISDN カードの節に進んでください. ISDN を使って, インターネットプロバイダに(専用線は使用せず), ダ イアルアップ接続しようとしている場合は, ターミナルアダプタの使用を考えてみてください. この方法はもっとも柔軟性があり, プロバイダを変更した場 合の問題も少ないでしょう. 2つの LAN の間を接続しようする場合や, ISDN 専用線を使用する場合 には, スタンドアローンルータ/ブリッジの使用を勧めます. どの方法を用いるかを決定するには, 費用が重要な要素になってきます. 以下に, 最も安価な方法から, 高価な方法まで順に説明していきます. ISDN カード 著者:&a.hm;. このセクションの記述は, DSS1/Q.931 ISDN 標準がサポートされている国のユーザにのみ有効です. 最近増えてきている PC ISDN カードのうちいくつかは, FreeBSD 2.2.x 以降で isdn4bsd ドライバパッケージによりサポートされています. 依然として開発中ではありますが, ヨーロッパ中でうまく動作しているという報告があります. 最新の isdn4bsd は, ftp://isdn4bsd@ftp.consol.de/pub/ から入手できます. この ftp サイトでは, ユーザ名として isdn4bsd を使い, パスワードにメールアドレスを使ってログインする 必要があります. ログインできたら pub ディレクトリに移動してください. ユーザー名 ftp や anonymous によるログインでは, 必要なファイルにたどりつけません. isdn4bsd は, IP over raw HDLC もしくは同期 PPP を利用して他の ISDN ルータと接続できます. 留守番電話アプリケーションも使えます. Siemens ISDN チップセット (ISAC/HSCX) を使用したものを主に多くのカードがサポートされています. 他のチップセット (Motorola, Cologn ChipDesigns) のサポートは現在開発中です. サポートされるカードの最新のリストは, README を参照してください. 他の ISDN プロトコルを追加したい場合や, サポートされていない ISDN PC カード サポートしたい場合など isdn4bsd を拡張したい場合は, hm@kts.org までご連絡ください. majordomoによるメーリングリストが利用できます. 参加するには, 本文に subscribe freebsd-isdn と記入したメールを &a.majordomo; 宛てに送ってください. ISDN ターミナルアダプタ ターミナルアダプタ (TA) はISDN に対して, 通常の電話線に対するモデムに相当するものです. ほとんどの TA は, 標準のヘイズ AT コマンドセットを使用しているので, 単にモデムと置き換えて使うことができます. TA は, 基本的にはモデムと同じように動作しますが, 接続方法は異なり, 通信速度も古いモデムよりはるかに速くなります. PPP の設定を, モデムの場合と同じように行ってください. とくにシリアル速度を 使用できる最高速度に設定するのを忘れないでください. プロバイダへの接続に TA を使用する最大のメリットは, 動的 PPP を行えることです. 最近 IP アドレスが不足してきているため, ほとんどのプロバイダは, 専用の IP アドレスを割り当てないようになっています. ほとんどのスタンドアローンルータは, 動的 IP アドレスに対応していません. 訳注: 最近の ISDN ルータでは, IP アドレスの動的割り当てに対応しているものも多いようです. ただし制限がある場合もありますので, 詳しくはメーカ に問い合わせてください. TA を使用した場合の機能や接続の安定性は, 使用している PPP デーモンに完全に依存します. そのため, FreeBSD で PPP の設定が完了していれば, 使用している既存のモデムを ISDN の TA に簡単にアップグレードすることができます. ただし, それまでの PPP のプログラムに問題があった場合, その問題は TA に置き換えてもそのまま残ります. 最高の安定性を求めるのであれば, ユーザープロセス iijPPP ではなく, カーネル PPPを使用してください. 以下の TA は, FreeBSD で動作確認ずみです. Motorola BitSurfer および Bitsurfer Pro Adtran 他の TA もほとんどの場合うまく動作するでしょう. TA のメーカーでは, TA がほとんどの標準モデム AT コマンドセットを受け付けるようにするよう, 努力しているようです. 外部 TA を使う際の最大の問題点は, モデムの場合と同じく良いシリアルカー ドが必要であるということです. シリアルデバイスの詳細, そして非同期シリアルポートと同期シリアルポートの差については, ハンドブックのシリアルポート の 節を参照してください. 標準の PC シリアルポート(非同期)に接続された TA は, 128Kbs の接続を行っていても, 最大通信速度が 115.2Kbs に制限されてしまいます. 128Kbs の ISDN の性能を最大限に生かすためには, TA を同期シリアルカードに接続しなければなりません. 内蔵 TA を購入して, 同期／非同期問題を片付けてしまおうとは思わないでく ださい. 内蔵 TA には, 単に標準 PC シリアルポートのチップが内蔵されてい るだけです. 内蔵 TA の利点といえば, シリアルケーブルを買わなくていいと いうことと, 電源コンセントが一つ少なくて済むということくらいでしょう. 同期カードと TA の組合せは 386 の FreeBSD マシンの場合でも, スタンドア ローンのルータと同程度の速度は確保できます. またこの組合せでは, ルータより柔軟な設定が可能です. 同期カード/TA を選ぶか, スタンドアローンルータを選ぶかは, 多分に宗教的な問題です. メーリングリストでもいくつか議論がありました. 議論の内容に ついては, archives を参照してください. スタンドアローン ISDN ブリッジ/ルータ ISDN ブリッジやルータは, OS 特有のものではありません. もちろん FreeBSD 特有のものでもありません. ルーティングやブリッジング技術に関する詳細は, ネットワークの参考書をご覧ください. このページでは, ルータとブリッジにどちらでもあてはまるように記述します. ISDN ルータ/ブリッジは, ローエンドの製品のコストが下がってきていることもあり, より一般的に使用されるようになるでしょう. ISDN ルータは, 外見は小さな箱で, ローカルのイーサネットネットワーク(もしくはカード)と直接, 接続します. また, 自身で他のブリッジ/ルータとの接続を制御します. PPP や他のプロトコルを使用するためのソフトウェアは, すべて組み込まれています. ルータは, 完全な同期 ISDN 接続を使用するため, 通常の TA と比較してスループットが大幅に向上します. ISDN ルータ/ブリッジを使用する場合の最大の問題点は, 各メーカーの製品間に相性の問題がまだ存在することです. インターネットプロバイダとの接続を考えている場合には, プロバイダと相談することをお勧めします. 事務所の LAN と家庭の LAN の間など, 二つの LAN セグメントの間を接続しようとしている場合は, ブリッジ/ルータの使用がもっともメンテナンスが 簡単で, 努力が少なくてすむ方法です. 両側の機材を購入するのであれば, メーカー間の接続性の問題もないでしょう. たとえば家庭の LAN や出張所の LAN を本社のネットワークに接続するためには, 以下のような設定が使用できます. 出張所 LAN または 家庭 LAN ネットワークは, 10 Base T イーサネットです. ルータとネットワークの間は, 必要に応じて AUI/10BT トランシーバを使って接続します. ---Sun ワークステーション | ---FreeBSD マシン | ---Windows 95 (別に勧めているわけじゃありません) | スタンドアローンルータ | ISDN BRI ライン 家庭/出張所 LAN で, 一台しかコンピュータを接続しないのであれば, クロス のツイストペアケーブルを使用して, スタンドアローンルータと直結も可能です. 本社 LAN や他の LAN ネットワークは, ツイストペアイーサネットです. -------Novell サーバ | | |ハ ---Sun | | | ---FreeBSD | | |ブ ---Windows 95 | | |___---スタンドアローンルータ | ISDN BRI ライン ほとんどのルータ/ブリッジでは, 別々の二つのサイトに対して, 同時にそれ ぞれ独立した二つの PPP 接続が可能です. これは, 通常の TA ではサポートされない機能で, ルータ/ブリッジ接続の大きな利点です (シリアルポートを 二つもつ特殊(そして高価な) TA では可能です). チャンネル割り当てや MPP などと混同しないでください. これは, 大変便利な機能です. - たとえば事務所で専用線インターネット ISDN 接続を使用していて, + たとえば事務所で専用線 ISDN 接続を使用していて, 別の ISDN ラインを購入したくないとします. この場合, 事務所のルータは, 一つの専用線 B チャンネル接続(64Kbs)を維持しつつ, 別 の B チャンネルを他の用途に使用することができます. たとえば, 他の場所 とのダイアルイン, ダイアルアウトに使用したり, バンド幅を増やすために, インターネットとの接続への動的に割り当て(MPP など)に使用したりすることが可能です. またイーサネットブリッジは, IP パケットだけでなく IPX/SPX などすべての プロトコルのパケットを中継することが可能です. NIS/YP 原作: &a.unfurl;, 2000 年 1 月 21 日. NIS/YP とは? NIS は RPC を使ったクライアント/サーバシステムです. これを 使うことで. NISドメイン内のマシン間で共通の設定ファイルを共有すること ができます. また, NIS を使うことでシステム管理者は最小限の設定データ で NIS クライアントを立ち上げることができ, 1 ヶ所から設定データの 追加, 削除, 変更が可能です. 動作のしくみ NIS 環境にあるホストは, 次の 3 種類に分類されます. それは, マスターサーバ, スレーブサーバ, クライアントです. サーバは, ホストの設定情報の中心的な情報格納庫の役割をします. マスターサーバは元となる信頼できる情報を保持し, スレーブサーバは, 冗長性を確保するため, この情報をミラーします. そしてクライアントは, サーバから情報の提供を受けて動作します. この方法を用いることで, 数多くのファイルにある情報が共有できます. よく NIS で共有されるのは, master.passwd や group, hosts といったファイルです. クライアント上のプロセスで, 通常ローカルのファイルにある情報が必要 となったとき, クライアントは接続しているサーバに問い合わせを行い, その情報を得ます. NIS/YP を使う 計画を立てる もし NIS によるシステム管理の設定を行なうのが初めてなら, どのようにしたいのか, ひととおり最後まで考えてみることをお勧めします. ネットワークの規模によらず, いくつか決めるべきことがあるためです. NIS ドメイン名を決める ここでいうドメイン名は, 今まであなたが使っていた, - いわゆる“ドメイン名” + いわゆる ドメイン名 と呼んでいたものとは違います. - 正確には“NIS ドメイン名”と呼ばれます. + 正確には NIS ドメイン名 と呼ばれます. クライアントがサーバに情報を要求するとき, その要求には自分が属する NIS ドメインの名前が含まれています. これは, 1 つのネットワークに複数のサーバがある場合に, どのサーバが要求を処理すれば良いかを決めるために使われます. NIS ドメイン名とは, 関連のあるホストをグループ化するための名前である, と考えると良いでしょう. 組織によってはインターネットのドメイン名を NIS ドメイン名に使っているところがありますが, これはネットワークのトラブルをデバッグするときに混乱の原因となるため, お勧めできません. NIS ドメイン名はネットワーク内で一意なければならないので, ドメイン名がドメインに含まれるマシンを表すようなものであれば, 分かりやすくなります. たとえば Acme 社のアート(Art)部門であれば, NIS ドメイン名を"acme-art"とすれば良いでしょう. サーバマシンの物理的な条件とは NIS サーバとして使うマシンを選ぶ際には, いくつかの注意点があります. NIS における困ったことの一つに, クライアントのサーバへの依存度があります. クライアントが自分の NIS ドメインのサーバに接続できない場合, マシンが使用不能になることがよくあります. もし, ユーザやグループに関する情報が得られなければ, ほとんどのシステムは一時的にですが停止してしまいます. こういったことを念頭に置いて, しょっちゅうリブートされるマシンや, 開発に使われそうなマシンを選ばないようにしなければなりません. 理想的には, NIS サーバはスタンドアロンで NIS サーバ専用となるマシンにするべきです. ネットワークの負荷が重くなければ, 他のサービスを走らせているマシンを NIS サーバにしてもかまいません. ただし NIS サーバが使えなくなると, すべてのクライアントに影響をおよぼす, という点には注意しなければなりません. NIS サーバ 元となるすべての NIS 情報は, NIS マスターサーバと呼ばれる 1 台のマシンに置かれます. この情報が格納されるデータベースを NIS マップと呼びます. FreeBSDでは, このマップは /var/yp/[domainname] に置かれます. [domainname] は, サーバがサービスする NIS ドメインです. 1 台の NIS サーバが複数のドメインをサポートすることも可能です. つまり, このディレクトリを各々のドメインごとに作ることができ, 各ドメインごと, 独立したマップの集合を持つことになります. NIS のマスターサーバとスレーブサーバ上では, ypserv デーモンがすべての NIS 要求を処理します. ypserv は NIS クライアントからの要求を受け付け, ドメイン名とマップ名を対応するデータベースファイルへのパスに変換し, データをクライアントに返送します. NIS マスターサーバの設定 やりたいことにもよりますが, NIS マスターサーバの設定は比較的単純です. FreeBSD には ypinit という便利なスクリプトがあり, これを使うと初期設定を 非常に簡単に行なうことができます. この設定を順調に進めるためには, いくつか事前にやらなければならないことがあります. NIS ドメイン名が設定されていることを, domainname コマンドで確認してください. ホストが属していないドメインに対しても ypinit を実行することはできますが, domainname が設定されていなければ この段階で設定すると良いでしょう. master.passwd ファイルが /var/yp に置かれていることを確認してください. NIS は, クライアントと共有するパスワードを このファイルから取得します. このファイルがない場合, ypinit はエラー終了します. これは, 新しい master.passwd でも, すでに存在する /etc/master.passwd を コピーしたものでもかまいません. コピーする場合には, ユーザ全体やグループに対する読み出し許可属性が 設定されていないことを確認してください. ypserv デーモンを起動してください. ypinit が動作するには, ypserv が RPC(Remote Procedure Call) の呼び出しに反応することが必要になります. 通常の設定では, ypserv にオプションフラグを指定する必要はありません. 以上の手順が終了したら, フラグを付けて ypinit を 実行してください. 立てようとしているマスターサーバのドメイン名が domainname に設定したものと異なっているなら, そのドメインを指定することができます. 下の例では, NIS のドメイン名を test-domain としています. # ypinit -m test-domain Server Type: MASTER Domain: test-domain Creating an YP server will require that you answer a few questions. Questions will all be asked at the beginning of the procedure. Do you want this procedure to quit on non-fatal errors? [y/n: n] n Ok, please remember to go back and redo manually whatever fails. If you don't, something might not work. At this point, we have to construct a list of this domains YP servers. master.example.com is already known as master server. Please continue to add any slave servers, one per line. When you are done with the list, type a <Control D>. master server : master.example.com next host to add: ^D The current list of NIS servers looks like this: master.example.com Is this correct? [y/n: y] y Building /var/yp/test-domain/ypservers... Running /var/yp/Makefile... NIS Map update started on Fri Dec 3 16:54:12 PST 1999 for domain test-domain Updating hosts.byname... Creating new /var/yp/passwd file from /var/yp/master.passwd... Updating netid.byname... Updating hosts.byaddr... Updating networks.byaddr... Updating networks.byname... Updating protocols.bynumber... Updating protocols.byname... Updating rpc.byname... Updating rpc.bynumber... Updating services.byname... Updating group.byname... Updating group.bygid... Updating passwd.byname... Updating passwd.byuid... Updating master.passwd.byname... Updating master.passwd.byuid... NIS Map update completed. master.example.com has been setup as an YP master server without any errors. NIS サーバをきちんと動作させるためには, /etc/rc.conf に数行, 追加する必要があります. 次のような行があることを確認して下さい. nis_server_enable="YES" nis_server_flags="" nis_yppasswdd_enable="YES" nis_yppasswdd_flags="" ほとんどの場合, NIS サーバで yppasswd を 実行させることを考えるでしょう. こうすると, クライアントマシンにいるユーザが, パスワードなどのユーザ情報をリモートから変更することが可能になります. NIS スレーブサーバの設定 NIS スレーブサーバの設定は, マスターサーバの設定よりも簡単で, ypinit コマンドを使うだけでほとんど終わりです. - 前述の例と同じように, NIS ドメイン名として “test-domain” + 前述の例と同じように, NIS ドメイン名として test-domain を使っています. # ypinit -s master.example.com test-domain Server Type: SLAVE Domain: test-domain Master: master.example.com Creating an YP server will require that you answer a few questions. Questions will all be asked at the beginning of the procedure. Do you want this procedure to quit on non-fatal errors? [y/n: n] n Ok, please remember to go back and redo manually whatever fails. If you don't, something might not work. There will be no further questions. The remainder of the procedure should take a few minutes, to copy the databases from master.example.com. -Transfering netgroup... -ypxfr: Exiting: Map successfully transfered -Transfering netgroup.byuser... -ypxfr: Exiting: Map successfully transfered -Transfering netgroup.byhost... -ypxfr: Exiting: Map successfully transfered -Transfering master.passwd.byuid... -ypxfr: Exiting: Map successfully transfered -Transfering passwd.byuid... -ypxfr: Exiting: Map successfully transfered -Transfering passwd.byname... -ypxfr: Exiting: Map successfully transfered -Transfering group.bygid... -ypxfr: Exiting: Map successfully transfered -Transfering group.byname... -ypxfr: Exiting: Map successfully transfered -Transfering services.byname... -ypxfr: Exiting: Map successfully transfered -Transfering rpc.bynumber... -ypxfr: Exiting: Map successfully transfered -Transfering rpc.byname... -ypxfr: Exiting: Map successfully transfered -Transfering protocols.byname... -ypxfr: Exiting: Map successfully transfered -Transfering master.passwd.byname... -ypxfr: Exiting: Map successfully transfered -Transfering networks.byname... -ypxfr: Exiting: Map successfully transfered -Transfering networks.byaddr... -ypxfr: Exiting: Map successfully transfered -Transfering netid.byname... -ypxfr: Exiting: Map successfully transfered -Transfering hosts.byaddr... -ypxfr: Exiting: Map successfully transfered -Transfering protocols.bynumber... -ypxfr: Exiting: Map successfully transfered -Transfering ypservers... -ypxfr: Exiting: Map successfully transfered -Transfering hosts.byname... -ypxfr: Exiting: Map successfully transfered +Transferring netgroup... +ypxfr: Exiting: Map successfully transferred +Transferring netgroup.byuser... +ypxfr: Exiting: Map successfully transferred +Transferring netgroup.byhost... +ypxfr: Exiting: Map successfully transferred +Transferring master.passwd.byuid... +ypxfr: Exiting: Map successfully transferred +Transferring passwd.byuid... +ypxfr: Exiting: Map successfully transferred +Transferring passwd.byname... +ypxfr: Exiting: Map successfully transferred +Transferring group.bygid... +ypxfr: Exiting: Map successfully transferred +Transferring group.byname... +ypxfr: Exiting: Map successfully transferred +Transferring services.byname... +ypxfr: Exiting: Map successfully transferred +Transferring rpc.bynumber... +ypxfr: Exiting: Map successfully transferred +Transferring rpc.byname... +ypxfr: Exiting: Map successfully transferred +Transferring protocols.byname... +ypxfr: Exiting: Map successfully transferred +Transferring master.passwd.byname... +ypxfr: Exiting: Map successfully transferred +Transferring networks.byname... +ypxfr: Exiting: Map successfully transferred +Transferring networks.byaddr... +ypxfr: Exiting: Map successfully transferred +Transferring netid.byname... +ypxfr: Exiting: Map successfully transferred +Transferring hosts.byaddr... +ypxfr: Exiting: Map successfully transferred +Transferring protocols.bynumber... +ypxfr: Exiting: Map successfully transferred +Transferring ypservers... +ypxfr: Exiting: Map successfully transferred +Transferring hosts.byname... +ypxfr: Exiting: Map successfully transferred slave.example.com has been setup as an YP slave server without any errors. Don't forget to update map ypservers on master.example.com. この例の場合, /var/yp/test-domain というディレクトリが必要になります. NIS マスターサーバのマップファイルのコピーは, このディレクトリに置かれ, 最新のものに維持されていなければなりません. 次のエントリをスレーブサーバの /etc/crontab に追加することで, 最新のものに保つことができます. 20 * * * * root /usr/libexec/ypxfr passwd.byname 21 * * * * root /usr/libexec/ypxfr passwd.byuid この二行は, スレーブサーバにあるマップファイルを, マスターサーバのマップファイルと同期させるものですが, 必須というわけではありません. なぜなら, マスターサーバは, NIS マップに対する変更を スレーブサーバに伝えようとするからです. しかし, サーバが管理するシステムにとってパスワード情報はとても重要なものですので, 強制的に更新してしまう方が良いでしょう. 特に, マップファイルの更新がきちんと行なわれるかどうか わからないくらい混雑するネットワークでは, 重要なポイントになります. NIS クライアント NIS クライアントは ypbind デーモンを使って, 特定の NIS サーバとの間に結合(binding)と呼ばれる関係を成立させます. ypbind は, システムのデフォルトのドメイン(domainname コマンドで設定されます)をチェックし, RPC 要求を ブロードキャストパケットとしてローカルネットワークに送信します. この RPC 要求により, ypbind が結合を成立させようとしているドメイン名が指定されます. 要求されているドメイン名に対してサービスするよう設定されたサーバが ブロードキャストパケットを受信すると, サーバは ypbind に応答し, ypbind は応答のあったサーバのアドレスを記録します. 複数のサーバがある(たとえば一つのマスターサーバと, 複数のスレーブサーバがある)場合, ypbind は, 最初に応答したサーバのアドレスを使用します. これ以降, クライアントのシステムは, すべての NIS の要求をそのサーバに向けて送信します. ypbind は, サーバが順調に動作していることを確認するため, - 時々 “ping” をサーバに送ります. + 時々 ping をサーバに送ります. 反応が戻ってくるべき時間内に ping に対する応答が来なければ, ypbind は, そのドメインを結合不能(unbound)として記録し, 別のサーバを見つけるべく, 再びブロードキャストパケットの送信を行います. NIS クライアントの設定 FreeBSD マシンにおける NIS クライアントの設定, 非常に簡単です. まず, ホストの NIS ドメイン名を設定します. これは, domainname コマンドで設定するか, 以下のエントリを /etc/rc.conf に追加して, ブート時に設定されるようにしてください. nisdomainname="test-domain" NIS サーバにある, すべてのパスワードエントリを取り込むため, vipwコマンドで以下の行を /etc/master.passwd に追加します. +::::::::: この行によって, NIS サーバのパスワードマップにアカウントがある人全員に, アカウントが与えられます. この行を変更すると, さまざまな NIS クライアントの設定を行なうことが可能です. これ以上詳しく知りたい方は, O'Reilly の Managing NFS and NIS をお読みください. NIS サーバにある, すべてのグループエントリを取り込むため, 以下の行を /etc/group に追加します. 　　　 +:*:: 上記の手順がすべて完了すれば, ypcat passwd によって NIS サーバの passwd マップが参照できるようになっているはずです. NIS セキュリティ 一般に, ドメイン名さえ知っていれば, どこにいるリモートユーザでも ypserv に RPC を発行し, NIS マップの内容を引き出すことができます. こういった不正なやりとりを防ぐため, ypserv には securenets と呼ばれる機能があります. これはアクセスを決められたホストだけに制限する機能です. ypserv は起動時に, /var/yp/securenets ファイルから securenets に関する情報を読み込みます. 上記のパス名は, オプションで指定されたパス名によって変わります. このファイルは, 空白で区切られた ネットワーク指定とネットマスクのエントリからなっていて, - “#” で始まる行はコメントとみなされます. + # で始まる行はコメントとみなされます. 簡単な securenets ファイルの例を以下に示します. # allow connections from local host -- mandatory 127.0.0.1 255.255.255.255 # allow connections from any host # on the 192.168.128.0 network 192.168.128.0 255.255.255.0 # allow connections from any host # between 10.0.0.0 to 10.0.15.255 10.0.0.0 255.255.240.0 ypserv が上記のルールの一つと合致するアドレスからの要求を受け取った場合, 処理は通常に行なわれます. もしアドレスがルールに合致しなければ, その要求は無視されて警告メッセージがログに記録されます. また, /var/yp/securenets が存在しない場合, ypserv は, すべてのホストからの接続を受け入れます. ypserv は, Wietse Venema 氏による tcpwrapper パッケージもサポートしています. そのため, /var/yp/securenets の代わりに tcpwrapper の設定ファイルを使ってアクセス制御を行なうことも可能です. これらのアクセス制御機能は一定のセキュリティを提供しますが, - どちらも特権ポートのテストのような “IP spoofing” + どちらも特権ポートのテストのような IP spoofing 攻撃に対して脆弱です. NIS v1 との互換性 FreeBSD の ypserv は, NIS v1 クライアントを部分的にサポートします. FreeBSD の NIS 実装は NIS v2 プロトコルのみを使用していますが, ほかの実装では, 古いシステムとの下位互換性を持たせるため v1 プロトコルをサポートしているものもあります. そのようなシステムに付いている ypbind デーモンは, 必要がないにもかかわらず NIS v1 のサーバとの結合を成立させようとします(しかも v2 サーバからの応答を受信した後でも, ブロードキャストをし続けるかも知れません). FreeBSD の ypserv は, クライアントからの通常のリクエストはサポートしていますが, v1 のマップ転送リクエストはサポートしていないことに注意してください. つまり FreeBSD の ypserv を, v1 だけをサポートするような古い NIS サーバと組み合わせて マスターやスレーブサーバとして使うことはできません. 幸いなことに, 現在, そのようなサーバが使われていることは ほとんどないでしょう. NIS クライアントとしても動作している NIS サーバ 複数のサーバが存在し, サーバ自身が NIS クライアントでもあるようなドメインで ypserv が実行される場合には, 注意が必要です. 一般的に良いとされているのは, 他のサーバと結合をつくるようにブロードキャストパケットの送信をさせるのではなく, サーバをそれ自身に結合させることです. もし, サーバ同士が依存関係を持っていて, 一つのサーバが停止すると, 奇妙なサービス不能状態に陥ることがあります. その結果, すべてのクライアントはタイムアウトを起こして 他のサーバに結合しようと試みますが, これにかかる時間はかなり大きく, サーバ同士がまた互いに結合してしまったりすると, サービス不能状態はさらに継続することになります. ypbind に オプションフラグを指定して実行することで, ホストを特定のサーバに結合することが可能です. libscrypt 対 libdescrypt NIS を実装しようする人の誰もがぶつかる問題の一つに, 暗号ライブラリの互換性があります. NIS サーバが DES 暗号ライブラリを使っている場合には, 同様に DES を使用しているクライアントしかサポートできません. サーバとクライアントがどのライブラリを使用しているかは, /usr/lib のシンボリックリンクを見ればわかります. あるマシンが DES ライブラリを使うように設定されている場合, リンクは以下のようになっています. &prompt.user; ls -l /usr/lib/*crypt* lrwxrwxrwx 1 root wheel 13 Jul 15 08:55 /usr/lib/libcrypt.a@ -> libdescrypt.a lrwxrwxrwx 1 root wheel 14 Jul 15 08:55 /usr/lib/libcrypt.so@ -> libdescrypt.so lrwxrwxrwx 1 root wheel 16 Jul 15 08:55 /usr/lib/libcrypt.so.2@ -> libdescrypt.so.2 lrwxrwxrwx 1 root wheel 15 Jul 15 08:55 /usr/lib/libcrypt_p.a@ -> libdescrypt_p.a -r--r--r-- 1 root wheel 13018 Nov 8 14:27 /usr/lib/libdescrypt.a lrwxr-xr-x 1 root wheel 16 Nov 8 14:27 /usr/lib/libdescrypt.so@ -> libdescrypt.so.2 -r--r--r-- 1 root wheel 12965 Nov 8 14:27 /usr/lib/libdescrypt.so.2 -r--r--r-- 1 root wheel 14750 Nov 8 14:27 /usr/lib/libdescrypt_p.a マシンが FreeBSD の標準の MD5 暗号ライブラリを使うように 設定されている場合には, 以下のようになります. &prompt.user; ls -l /usr/lib/*crypt* lrwxrwxrwx 1 root wheel 13 Jul 15 08:55 /usr/lib/libcrypt.a@ -> libscrypt.a lrwxrwxrwx 1 root wheel 14 Jul 15 08:55 /usr/lib/libcrypt.so@ -> libscrypt.so lrwxrwxrwx 1 root wheel 16 Jul 15 08:55 /usr/lib/libcrypt.so.2@ -> libscrypt.so.2 lrwxrwxrwx 1 root wheel 15 Jul 15 08:55 /usr/lib/libcrypt_p.a@ -> libscrypt_p.a -r--r--r-- 1 root wheel 6194 Nov 8 14:27 /usr/lib/libscrypt.a lrwxr-xr-x 1 root wheel 14 Nov 8 14:27 /usr/lib/libscrypt.so@ -> libscrypt.so.2 -r--r--r-- 1 root wheel 7579 Nov 8 14:27 /usr/lib/libscrypt.so.2 -r--r--r-- 1 root wheel 6684 Nov 8 14:27 /usr/lib/libscrypt_p.a NIS クライアントの認証でトラブルが発生した場合には, ここから問題となりそうな部分を探すと良いでしょう. + + + DHCP + + Written by &a.gsutter;, March 2000. + + + DHCPとは何でしょう? + + + DHCP (Dynamic Host Configuration Protocol) は, システムをネットワー + クに接続するだけで, ネットワークでの通信に必要な情報を入手するこ + とができる仕組みです. FreeBSD では, ISC (Internet Software + Consortium) による DHCP の実装を使用しています. したがって, ここで + の説明のうち, 実装によって異なる部分は ISC のもの用になっています. + + + + + この節で説明していること + + + ハンドブックのこの節では DHCP システムの, FreeBSD に組み込まれてい + る部分についてだけ説明しています. ですから, サーバについては説明 + していません. 後の節で紹介するリファレンスに加えて, + DHCP のマニュアルページも有力な参考になることでしょう. + + + + DHCP の動作 + + + クライアントとなるマシン上で DHCP のクライアントである dhclient を実 + 行すると, まず設定情報の要求をブロードキャストします. デフォルト + では, このリクエストには UDP のポート 68 を使用します. サーバは UDP の + ポート 67 で応答し, クライアントの IP アドレスと, ネットマスクやルー + タ, DNS サーバなどの関連する情報を提供します. これらの情報の + すべては DHCP の「リース」の形で送られ, DHCP サーバ管理者によって決 + められたある一定の時間内でのみ有効になります. これによって, ネッ + トワークに存在しなくなったホストの IP アドレスは自動的に回収される + ことになります. + + + + DHCP クライアントはサーバから非常に多くの情報を取得することができます. + &man.dhcp-options.5; に, その非常に大きなリストが載っています. + + + + FreeBSD への組み込み + + + FreeBSD は ISC の DHCP クライアントである + dhclient を完全に組み込んでいます. DHCP クラ + イアントはインストーラと基本システムの両方で提供されています. + ですから DHCP サーバを走らせているネットワーク上ではネットワー + ク関係の設定についての詳細な知識は必要になりません. + dhclient は, 3.2 以降の FreeBSD のすべての配布 + に含まれています. + + + DHCP は sysinstall でサポートされてお + り, sysinstall でのネットワークインターフェイス設定の際は, 「こ + のインターフェイスの設定として DHCP を試してみますか?」という質問 + が最初になされます. これに同意することで dhclient が実行さ + れ, それが成功すればネットワークの設定情報は自動的に取得されま + す. + + + システム起動時に, DHCP を使ってネットワーク情報を取得するように + するには, /etc/rc.conf に次のように加えて + ください. + + +ifconfig_fxp0="DHCP" + + + + fxp0 の部分を, 動的に設定したいインター + フェースの名前で置き換えることを忘れないようにしてください. + + + + + もし, 使っているdhclient の場所を変更してい + たり, dhclient にフラグを渡したい場合は, 同 + 様に下のように書き加えてください. + + +dhcp_program="/sbin/dhclient" +dhcp_flags="" + + + + DHCP サーバである dhcpd は, ports + collectionに isc-dhcp2 として収録されていま + す. この port はクライアント, サーバ, リレーエージェントから成 + る ISC の DHCP 配布物をすべて含んでいます. + + + + + 関連ファイル + + + /etc/dhclient.conf + dhclient は設定ファイル + /etc/dhclient.conf を必要とします. + 大抵の場合, このファイルはコメントだけであり, デフォルトが + 通常使いやすい設定になっています. この設定ファイルは + マニュアルページ &man.dhclient.conf.5; で説明しています. + + + + /sbin/dhclient + + dhclient は静的にリンクされており, + /sbin に置かれています. マニュアルページ + &man.dhclient.8; で dhclient コマンドについて + より詳しく説明しています. + + + /sbin/dhclient-script + + dhclient-script は FreeBSD 特有の, DHCP クラ + イアント設定スクリプトです. これについてはマニュアルページ + &man.dhclient-script.8; で説明されていますが, これを編集する + 必要はほとんど発生しないでしょう. + + + /var/db/dhclient.leases + + DHCP クライアントはこのファイルに有効なリースのデータベースを + ログとして記録します. &man.dhclient.leases.5; にもうすこし詳 + しい解説があります. + + + + + + + 参考になる文献 + + DHCP のプロトコルは + RFC 2131 + に完全に記述されています. また, + dhcp.org + にも有用な + 情報源が用意されています. + +