名称

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 を読み込む関数が存在しないからです。 NIS サポートは、 nsswitch.conf(5) で有効にします。

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) は、管理者が /var/yp/Makefile.local を作成して、 NOPUSH 変数を空にするなら、自動的に、これを行います:

NOPUSH=

( NOPUSH は、 NIS サーバが 1 つだけの小さなネットワーク用になっているので、デフォルトで true に設定されています)。 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, shadow.byname と shadow.byuid) を扱います。サーバは、特権ポートで生成されたリクエストに対する応答をするときのみ、シャドウパスワードマップにアクセスします。特権ポートへの接続が許されているのは、root だけなので、サーバは、そのようなリクエストは、すべて特権ユーザ (root) からのものであると仮定するわけです。その他のポートからのアクセスは、すべて拒否されます。特権のないポートからリクエストを出してもサーバからはエラーコードが返ってくるだけです。さらに、 FreeBSD の ypserv(8) は、 Wietse Venema の tcp ラッパパッケージをサポートしています。 tcp ラッパのサポートを有効にすると、管理者は、 ypserv(8) が限られたクライアントマシンに対してのみ応答するように、設定可能です。

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

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

互換性

FreeBSD ではない NIS サーバを passwd(5) ファイルに対して適用する場合は、 FreeBSD でパスワードに使用しているデフォルトの MD5 形式は、恐らく使用できないでしょう。もしそうであれば、互換性を確保するため login.conf(5) に設定している passwd_format の値を“ des”と変更してください。

システムによっては、例えば 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) のマニュアルページを参照してください)。

関連項目

domainname(1), ypcat(1), ypmatch(1), ypwhich(1), nsswitch.conf(5), yp_mkdb(8), ypbind(8), ypinit(8), yppoll(8), yppush(8), ypserv(8), ypset(8), ypxfr(8)

歴史

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

バグ

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

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

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

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