NIS(4)

yp − YP/NIS システムの詳細

yp

解説

YP サブシステムを使用すると、passwd, group, netgroup, hosts, services, rpc, bootparams, ethers の各ファイルのエントリを次の関数を通してネット ワーク管理することができます: getpwent(3), getgrent(3), getnetgrent(3), gethostent(3), getnetent(3), getrpcent(3), ethers(3) 。 bootparamd(8) デーモンは、 NIS ライブラリを直接呼び出します。なぜなら、標準 C ライブラ リでは、bootparams を読み込む関数が存在しないからです。 hosts, services, rpc のデータベースを NIS でサポートにするには、 /etc/host.conf ファイルの nis の行のコメントを外してください。残りのデータベースの NIS でのサポート については、適切なファイルに特別な意味を持つ ’+’ エントリを足すと有効にな ります。

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 をサポート しているものでは、古い形式の nbdm データベースを代わりに使用しています (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 つのタイプがあります。

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 のパスワードデータベースシステム (これは、 4.4BSD か らそのまま受け継がれたものです) には、 「シャドウパスワード」のサポートが 含まれています。標準的なパスワードデータベースには、暗号化されたユーザパ スワードは含まれていません。かわりに、暗号化されたパスワードは (他の情報 と一緒に) スーパユーザのみがアクセス可能なデータベースに分けて保存されて います。暗号化されたパスワードが 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 サーバとして 登録することもできます (FreeBSD は、 NIS v2 のみ使用しますが、その他のシ ステムでは、 SunOS 4.x もそうですが、バインドを確立する際に、 v1 および v2 の両方の機能を有するサーバを探索するものが多いです)。 FreeBSD の ypserv(8) は、実は NIS v1 リクエストを扱いません。しかし、この "対処モー ド (kludge mode)" は、v1 および v2 の両方の機能を有するサーバを頑固に探索 するシステムを黙らせるには便利です

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

FreeBSD では、現在 NIS クライアントにもサーバにもなることができますが、 ypupdated(8) あるいは、 yp_update() 関数はサポートされていません。これら には、両方とも安全な RPC が必要ですが、 FreeBSD では、これについてもサ ポートされていません。

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

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

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

YP サブシステムは、 Sun の実装と互換性を持たせるために、 Theo de Raadt が 最初から書きました。バグフィックスと改良および NIS サーバのサポートは、後 に Bill Paul が追加しました。サーバ側のコードは、もともと、 Peter Eriksson と Tobias Reber が書き、 GNU Public License に従っています。 Sun のコードは一切参照されませんでした。

4.2 Berkeley Distribution April 5, 1993 4.2 Berkeley Distribution