YP(8) FreeBSD システム管理者マニュアル YP(8)
名称
|
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() yp_match() yp_first() yp_next() 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 マップが代わりに使われます。 互換性 |
|
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) のマニュアルページ を参照してください)。 |
バグ
|
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 のコード は一切参照されませんでした。 FreeBSD 10.0 April 5, 1993 FreeBSD 10.0 |