yp(4) FreeBSDドキュメントJMan

YP(4) FreeBSD カーネルインタフェースマニュアル YP(4)

名称

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

書式

解説

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 つのタイプがあります。

             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 のパスワードデータベースシステム (これは、 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