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 マップ と呼ばれています。 FreeBSD では、 これらのマップは /var/yp/<domainname> に保存されます。 ここで、 <domainname> は、サービスを受けている NIS ドメイン名です。 1 つの NIS サーバで 一度に複数のドメインをサポートすることができます。そのため、 このような名前のディレクトリが複数あるということもあり得ます。 サポートされるドメイン 1 つにつき、1 つのディレクトリを持ちます。 ドメインはそれぞれ独立した NIS マップの集合を持っています。

FreeBSD では、 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 つはどちらも同じマップの一部分です)、 FreeBSD では、 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) デーモンが特定のサーバとバインドを確立するように することはできますが、このようにすると不便なことがあります。 この問題は、スレーブサーバをローカルネットワーク上に 置くだけで簡単に回避できます)。

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

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

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

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

システムによっては、例えば SunOS 4.x などでは、ホスト名を解決する関数 ((gethostbyname), gethostbyaddr() など) が正しく作動するためには NIS が動作している必要があるものがあります。 こういったシステムでは、 ypserv(8) デーモンは hosts.byname あるいは hosts.byaddr マップ中に存在していないホストに関する 情報を返すように要求された場合には、 DNS を参照します。 FreeBSD のリゾルバは、デフォルトで DNS を使います (望むなら、 NIS を使うようにもできます)。 そのため、 FreeBSD の NIS サーバは DNS をデフォルトでは参照しません。 しかし、特別なフラグをつけて ypserv(8) を起動した場合は DNS を参照するようになります。 また、 v1 サーバが存在することを強く要求するような システムをおとなしくさせるため、 ypserv(8) を NIS v1 サーバとして登録することもできます ( Fx は NIS v2 のみ使用しますが、その他のシステムでは、 SunOS 4.x もそうですが、バインドを確立する際に、 v1 および v2 の両方の機能を有するサーバを探索するものが多いです)。 FreeBSD の ypserv(8) は、実は NIS v1 リクエストを扱いません。 しかし、この "対処モード (kludge mode)" は、v1 および v2 の両方の機能を有するサーバを頑固に探索するシステムを 黙らせるには便利です。

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

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

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

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