manページ  — YP

YP サブシステムは、 /etc/rc.conf ファイル中で初期化されていて、かつ、 /var/yp ディレクトリが存在していれば (デフォルトの配布物では存在しています)、 /etc/rc ファイル中で自動的に実行されます。 デフォルトの NIS ドメインは、 domainname(1) コマンドで設定されている必要があります。 これについても、 /etc/rc.conf ファイルで指定されていれば、システム起動時に自動的に 行われます。

NIS は RPC ベースの クライアントサーバシステムであり、 NIS ドメイン内のマシンが同じ設定ファイルを共有できるように するシステムです。 NIS を使用することで、システム管理者は最低限の設定データだけで NIS クライアントシステムを立ち上げることができ、 1 つの場所から設定データを追加したり、消したり、変更したり することができます。

NIS のすべての情報の正当なコピーは NIS マスタサーバ と呼ばれる 1 つのマシン上に保存されます。 情報を保存するのに使用されるデータベースは NIS マップ と呼ばれています。 BSD Free では、 これらのマップは /var/yp/[domainname] に保存されます。 ここで、 [domainname] は、サービスを受けている NIS ドメイン名です。 1 つの NIS サーバで 一度に複数のドメインをサポートすることができます。そのため、 このような名前のディレクトリが複数あるということもあり得ます。 サポートされるドメイン 1 つにつき、1 つのディレクトリを持ちます。 ドメインはそれぞれ独立した NIS マップのセットを持っています。

BSD Free では、 NIS マップは Berkeley DB ハッシュのデータベースファイル (これは、 passwd(5) データベースファイルで使用されているフォーマットと同じものです) になっています。 他のオペレーティングシステムで、 NIS をサポートしているものでは、古い形式の nbdm データベースを 代わりに使用しています (Sun Microsystems 社が最初に NIS の実装を ndbm 上で行ったことが大きな要因です。他のベンダは、 自分達で別のデータベースフォーマットを使って実装を行わずに、 単に Sun のコードのライセンスを受けたということです)。 これらのシステムでは、データベースは通常 .dir ファイルと .pag ファイルに分けられています。ndbm コードは、これら 2 つの ファイルを使って、ハッシュデータベースの別々の部分を 保持するようになっています。Berkeley DB ハッシュの 方法では、この 2 つの部分に分かれている情報を保持するのに 単一のファイルを使います。 つまり、他のオペレーティングシステムでは、 passwd.byname.dir ファイルと passwd.byname.pag ファイルがあるのに対し (これら 2 つはどちらも同じマップの一部分です)、 BSD Free では、 passwd.byname という名前のファイルがひとつだけあります。 このフォーマットの違いは、たいして重要ではありません。 NIS サーバ ypserv(8) そして関連のあるツール群だけが、 NIS マップのフォーマットがどうなっているのかを知る 必要があります。 NIS クライアントシステムでは、 NIS データはすべて ASCII 形式で受け取ります。

NIS システムには、主要な 3 つのタイプがあります。

1. NIS クライアント… これは、 NIS サーバに情報の問い合わせをします。
2. NIS マスタサーバ… これは、 NIS マップの正当なコピーをすべて管理しています。
3. NIS スレーブサーバ… これは、 NIS マップのバックアップコピーを管理しています。バックアップ コピーは、定期的にマスタサーバが更新しています。

NIS クライアントは、 ypbind(8) デーモンを利用して NIS サーバといわゆる バインド を確立します。 ypbind(8) はシステムのデフォルトのドメインをチェックし ( domainname(1) コマンドで設定されます)、 RPC リクエストをローカルネットワーク上でブロードキャスト し始めます。 ypbind(8) がバインドを確立しようとしているドメイン名は、 これらのリクエストが指定します。 リクエストのあったドメインのサービスを行うように 設定されているサーバがこのブロードキャストメッセージを 受け取ると、 このサーバは、 ypbind(8) に対して応答します。そして、 ypbind(8) はこのサーバのアドレスを記録するのです。もし、複数の サーバが使用可能であるなら (例えば、マスタサーバ 1 台とスレーブサーバ数台というような場合)、 ypbind(8) は、一番最初に応答してきたサーバのアドレスを使用します。 この時点から、クライアントシステムは NIS リクエストをすべてこのサーバに送ります。 ypbind(8) は時々サーバに "ping" をかけ、サーバがまだ上がっていて、動作 しているかを確認します。この ping の応答を適切な時間内に 受け取らない場合は、 ypbind(8) は、バインドされていないという印をこのドメインにつけ、再度 ブロードキャストを始めて別のサーバの場所を特定 しようとします。

NIS マスタサーバおよびスレーブサーバでは、 NIS のリクエストはすべて ypserv(8) デーモンで扱います。 ypserv(8) デーモンは、 NIS クライアントから入ってくるリクエストを受け取り、 リクエストされたドメインおよびマップ名を対応するデータベース へのパスに変換し、そのデータベースからデータを取り出して クライアントに送り返すという仕事をしています。 特別なリクエストのセットがあり、 ypserv(8) はこのセットを扱えるように設計されています。そのほとんどが 標準 C ライブラリ内の関数として実装されています。

• yp_order() この関数は、特定のマップの作成日時を調べます。
• yp_master() この関数は、与えられたマップ / ドメインの NIS マスタサーバ名を獲得します。
• yp_match() この関数は、特定のマップ / ドメイン内のキーで与えられた ものに対応するデータを見つけます。
• yp_first() この関数は、特定のマップ / ドメイン内の最初の キーとデータのペアを獲得します。
• yp_next() この関数は、 ypserv(8) に特定のマップ / ドメイン内のキーを渡し、このキーのすぐ次に あるキーとデータの対を ypserv(8) に返してもらいます (関数 yp_first() と yp_next() とを用いて、 NIS マップを順番に検索できます)。
• yp_all() この関数は、マップの内容をすべて取り出します。

この他にも、 ypserv(8) が扱うことのできるリクエストはいくつかあります (つまり、特定のドメインを扱うことができているのかどうかを 応答するもの (YPPROC_DOMAIN) や、ドメインを扱うことができる ときだけ応答し、そうでないときには黙っているもの (YPPROC_DOMAIN_NONACK) などです)。 しかし、これらは普通、 ypbind(8) のみが生成するリクエストであり、標準のユーティリティ で扱われるわけではありません。

ホストが膨大にあるネットワーク上では、ただ 1 台の マスタサーバを使うよりも、マスタサーバ 1 台と複数のスレーブサーバ を使う方が良いことが多いのです。スレーブサーバは、 マスタサーバと全く同じ情報を提供します。ですから、 マスタサーバ上のマップを変更するときはいつでも新しいデータを yppush(8) コマンドを使ってスレーブサーバに伝播させるようにすべきです。 NIS の Makefile ( /var/yp/Makefile) を使うと、この操作を自動的に行うことができます。 そのためには、管理者が Makefile ファイル中の NOPUSH=true と書かれた行をコメントアウトしてください (NOPUSH は、デフォルトでは true に設定されています。 デフォルトの設定では、 NIS サーバが 1 つだけの、小さなネットワーク用になっているからです)。 yppush(8) コマンドは、マスタサーバとスレーブサーバとの トランザクションを開始します。その間に、スレーブサーバは、 特定のマップをマスタサーバから、 ypxfr(8) コマンドを用いて転送します (スレーブサーバは、 ypserv(8) 内部で ypxfr(8) コマンドを自動的に呼び出します。そのため、管理者が直接 ypxfr(8) コマンドを実行する必要は普通ありません。それでも、 そうしたいなら、手で打って実行することもできます)。 スレーブサーバを管理すると、大きなネットワーク上の NIS のパフォーマンス向上に役立ちます。理由は次の通りです。

• NIS マスタサーバがクラッシュした場合や参照できない場合に、 バックアップサービスを提供します。
• マスタサーバの負荷が過度に増してしまわないように、 クライアントの負荷を複数のマシンに分散します。
• 1 つの NIS ドメインをローカルネットワークを越えて使用できます ( サーバが ypbind(8) のブロードキャストの範囲外の所にあったならば、 ypbind(8) デーモンはサーバの場所を自動的に決定できなかったでしょう。 ypset(8) コマンドを使って ypbind(8) デーモンが特定のサーバとバインドを確立するように することはできますが、このようにすると不便なことがあります。 この問題は、ただスレーブサーバをローカルネットワーク上に 置くだけで回避できます)。

BSD Free の ypserv(8) は、 BSD Free のクライアントシステムだけを使った場合、(他の NIS の実装よりも) 強化された セキュリティを提供するように設計されています。 BSD Free のパスワードデータベースシステム (これは、 BSD 4.4 からそのまま受け継がれたものです) には、 「シャドウパスワード」 のサポートが含まれています。標準的なパスワードデータベース には、暗号化されたユーザパスワードは含まれていません。 かわりに、暗号化されたパスワードは (他の情報と一緒に) スーパユーザのみがアクセス可能なデータベースに分けて 保存されています。 暗号化されたパスワードが NIS マップとして入手できるとしたら、 このセキュリティは全体的に機能しなくなるでしょう。なぜなら、 ユーザは誰でも NIS のデータを取得できるからです。

暗号化されたパスワードを NIS 経由で取得されないようにするため、 BSD Free の NIS サーバでは、特殊な方法でシャドウパスワードマップ ( master.passwd.byname と master.passwd.byuid) を扱います。サーバは、特権ポートで生成されたリクエストに 対する応答をするときのみ、シャドウパスワードマップに アクセスします。特権ポートへの接続が 許されているのは root だけなので、サーバは、そのような リクエストはすべて特権ユーザ (root) からのものであると 仮定するわけです。その他のポートからのアクセスはすべて 拒否されます。特権のないポートからリクエストを出しても サーバからはエラーコードが返ってくるだけです。 さらに、 BSD Free の ypserv(8) は、Wietse Venema の tcp ラッパパッケージをサポートしています。 tcp ラッパのサポートを有効にすると、管理者は、 ypserv(8) が限られたクライアントに対してのみ応答するように、設定可能です。

これらの機能強化によって、普通の NIS よりも優れたセキュリティを提供できますが、それでも 決して 100 パーセント効果があるわけではありません。 ネットワークにアクセスできる誰かがサーバをだまして シャドウパスワードマップを開示させるようにすることが それでも可能なのです。

クライアント側では、 BSD Free の getpwent(3) 関数は自動的に master.passwd マップを探し、存在していたらそれを使います。もし、 マップが存在していたら、それを使い、これら特別な マップの全フィールド (クラス、パスワードが使われている期間、 そしてアカウントの有効期限) をデコードします。もし、存在していないなら、 標準の passwd マップが代わりに使われます。

(これらの特殊な機能やフラグについての詳細は ypserv(8) のマニュアルページを参照してください)。

getservent(3) と getprotoent(3) 関数は、まだ NIS をサポートしていません。 幸いなことに、これらのファイルは それほど頻繁に更新する必要がありません。

マニュアルページをもっとたくさん書くべきです。特に、 ypclnt(3) についてはそうです。 しばらくは、手元の Sun マシンを探して、それ用の マニュアルを読んでください。

Sun もこのプログラムの著者も、起動時に ypbind がサーバを見つけられないとき に生じる問題を分かりやすく扱う方法を思い付きませんでした。