YP サブシステムは、 /etc/rc.conf ファイル中で初期設定されていて、かつ、 /var/yp ディレクトリが存在していれば (デフォルトの配布物では存在しています)、 /etc/rc ファイル中で自動的に起動されます。 デフォルトの NIS ドメインは、 domainname(1) コマンドで設定される必要があります。 これについても、 /etc/rc.conf ファイルで指定されていれば、システム起動時に自動的に 行われます。
NIS は RPC ベースのクライアント / サーバシステムであり、 NIS ドメイン内のマシンのグループが同じ設定ファイルを共有できるように するシステムです。 NIS を使用することで、システム管理者は最低限の設定データだけで NIS クライアントシステムを立ち上げることができ、 1 つの場所から設定データを追加したり、削除したり、変更したり することができます。
NIS のすべての情報の正当なコピーは NIS マスタサーバ と呼ばれる 1 つのマシン上に保存されます。 情報を保存するのに使用されるデータベースは NIS マップ と呼ばれています。 Fx では、 これらのマップは /var/yp/ Aq domainname に保存されます。 ここで、 Aq Ar domainname は、サービスを受けている NIS ドメイン名です。 1 つの NIS サーバで 一度に複数のドメインをサポートすることができます。そのため、 このような名前のディレクトリが複数あるということもあり得ます。 サポートされるドメイン 1 つにつき、1 つのディレクトリを持ちます。 ドメインはそれぞれ独立した NIS マップの集合を持っています。
Fx では、 NIS マップは Berkeley DB ハッシュのデータベースファイル (これは、 passwd(5) データベースファイルで使用されているフォーマットと同じものです) になっています。 他のオペレーティングシステムで、 NIS をサポートしているものでは、古い形式の ndbm データベースを 代わりに使用しています (その主な理由は、 Sun Microsystems 社が最初に NIS の実装を ndbm 上で行ない、他のベンダは 単に Sun のコードのライセンスを受けただけで、 自分達で別のデータベースフォーマットを使って実装を行わ なかったからです)。 これらのシステムでは、データベースは通常 .dir ファイルと .pag ファイルに分けられています。 ndbm コードは、これら 2 つの ファイルを使って、ハッシュデータベースの別々の部分を 保持するようになっています。Berkeley DB ハッシュの 方法では、この 2 つの部分に分かれている情報を保持するのに 単一のファイルを使います。 つまり、他のオペレーティングシステムでは、 passwd.byname.dir ファイルと passwd.byname.pag ファイルがあるのに対し (これら 2 つはどちらも同じマップの一部分です)、 Fx では、 passwd.byname という名前のファイルがひとつあるだけです。 このフォーマットの違いは、たいして重要ではありません。 NIS サーバ ypserv(8) そして関連のあるツール群だけが、 NIS マップのフォーマットがどうなっているのかを知る 必要があります。 NIS クライアントシステムでは、 NIS データはすべて ASCII 形式で受け取ります。
NIS システムには、主要な 3 つのタイプがあります。
NIS クライアントは、 ypbind(8) デーモンを利用してそれぞれの NIS サーバといわゆる バインド を確立します。 ypbind(8) ユーティリティはシステムのデフォルトのドメインをチェックし (domainname1 コマンドで設定されます)、 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 ライブラリ内の関数として実装されています。
この他にも、 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 のパフォーマンス向上に役立ちます。理由は次の通りです。
Fx の ypserv(8) は、 Fx のクライアントシステムだけを使った場合、(他の NIS の実装よりも) 強化された セキュリティを提供するように設計されています。 Fx のパスワードデータベースシステム (これは、 BSD 4.4 からそのまま受け継がれたものです) には、 「シャドウパスワード」 のサポートが含まれています。標準的なパスワードデータベース には、暗号化されたユーザパスワードは含まれていません。 かわりに、暗号化されたパスワードは (他の情報と一緒に) スーパユーザのみがアクセス可能なデータベースに分けて 保存されています。 暗号化されたパスワードが NIS マップとして入手できるとしたら、 このセキュリティは全体的に機能しなくなるでしょう。なぜなら、 ユーザは誰でも NIS のデータを取得できるからです。
暗号化されたパスワードを NIS 経由で取得されないようにするため、 Fx の NIS サーバでは、特殊な方法でシャドウパスワードマップ ( master.passwd.byname と master.passwd.byuid を扱います。 サーバは、特権ポートで生成されたリクエストに 対する応答をするときのみ、シャドウパスワードマップに アクセスします。特権ポートへの接続が 許されているのは root だけなので、サーバは、そのような リクエストはすべて特権ユーザ (root) からのものであると 仮定するわけです。その他のポートからのアクセスはすべて 拒否されます。特権のないポートからリクエストを出しても サーバからはエラーコードが返ってくるだけです。 さらに、 Fx の ypserv(8) は、 An Wietse Venema の tcp ラッパパッケージをサポートしています。 tcp ラッパのサポートを有効にすると、管理者は、 ypserv(8) が限られたクライアントマシンに対してのみ応答するように、設定可能です。
これらの機能強化によって、普通の NIS よりも優れたセキュリティを提供できますが、それでも 決して 100 パーセント有効であるわけではありません。 ネットワークにアクセスできる誰かがサーバをだまして シャドウパスワードマップを開示させるようにすることが それでも可能なのです。
クライアント側では Fx の getpwent(3) 関数は自動的に master.passwd マップを検索し、存在していたらそれを使います。もし、 マップが存在していたら、それを使い、これら特別な マップの全フィールド (クラス、パスワードが使われている期間、 そしてアカウントの有効期限) をデコードします。 もし、存在していないなら、 標準の passwd マップが代わりに使われます。
システムによっては、例えば SunOS 4.x などでは、ホスト名を解決する関数 Fn ( gethostbyname , Fn gethostbyaddr など) が正しく作動するためには NIS が動作している必要があるものがあります。 こういったシステムでは、 ypserv(8) デーモンは hosts.byname あるいは hosts.byaddr マップ中に存在していないホストに関する 情報を返すように要求された場合には、 DNS を参照します。 Fx のリゾルバは、デフォルトで DNS を使います (望むなら、 NIS を使うようにもできます)。 そのため、 Fx の NIS サーバは DNS をデフォルトでは参照しません。 しかし、特別なフラグをつけて ypserv(8) を起動した場合は DNS を参照するようになります。 また、 v1 サーバが存在することを強く要求するような システムをおとなしくさせるため、 ypserv(8) を NIS v1 サーバとして登録することもできます ( Fx は NIS v2 のみ使用しますが、その他のシステムでは、 SunOS 4.x もそうですが、バインドを確立する際に、 v1 および v2 の両方の機能を有するサーバを探索するものが多いです)。 Fx の ypserv(8) は、実は NIS v1 リクエストを扱いません。 しかし、この ``対処モード (kludge mode)'' は、v1 および v2 の両方の機能を有するサーバを頑固に探索するシステムを 黙らせるには便利です。
(これらの特殊な機能やフラグについての詳細は ypserv(8) のマニュアルページを参照してください)。
getservent(3) と getprotoent(3) 関数は、まだ NIS をサポートしていません。 幸いなことに、これらのファイルは それほど頻繁に更新する必要がありません。
マニュアルページをもっとたくさん書くべきです。特に ypclnt(3) についてはそうです。 しばらくは、手元の Sun マシンを探して、それ用の マニュアルを読んでください。
Sun もこの著者も、起動時に ypbind がサーバを見つけられないとき に生じる問題を分かりやすく扱う方法を思い付きませんでした。