doc/ja_JP.eucJP/man/man4/yp.4

.\" Copyright (c) 1992/3 Theo de Raadt <deraadt@fsa.ca>
.\" All rights reserved.
.\"
.\" Redistribution and use in source and binary forms, with or without
.\" modification, are permitted provided that the following conditions
.\" are met:
.\" 1. Redistributions of source code must retain the above copyright
.\"    notice, this list of conditions and the following disclaimer.
.\" 2. Redistributions in binary form must reproduce the above copyright
.\"    notice, this list of conditions and the following disclaimer in the
.\"    documentation and/or other materials provided with the distribution.
.\" 3. The name of the author may not be used to endorse or promote
.\"    products derived from this software without specific prior written
.\"    permission.
.\"
.\" THIS SOFTWARE IS PROVIDED BY THE AUTHOR ``AS IS'' AND ANY EXPRESS
.\" OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED
.\" WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE
.\" ARE DISCLAIMED.  IN NO EVENT SHALL THE AUTHOR BE LIABLE FOR ANY
.\" DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL
.\" DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS
.\" OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION)
.\" HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT
.\" LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY
.\" OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF
.\" SUCH DAMAGE.
.\"
.\"     from: @(#)yp.8	1.0 (deraadt) 4/26/93
.\"	%Id: yp.4,v 1.14 1997/12/22 07:35:40 charnier Exp %
.\" jpman %Id: yp.4,v 1.4 2000/02/06 17:48:28 horikawa Stab %
.\"
.Dd April 5, 1993
.Dt YP 4
.Os BSD 4.2
.Sh 名称
.Nm yp
.Nd YP/NIS システムの詳細
.Sh 書式
.Nm yp
.Sh 解説
.Nm YP
サブシステムを使用すると、passwd, group, netgroup, hosts,
services, rpc, bootparams, ethers の各ファイルのエントリ
を次の関数を通してネットワーク管理することができます:
.Xr getpwent 3 ,
.Xr getgrent 3 ,
.Xr getnetgrent 3 , 
.Xr gethostent 3 ,
.Xr getnetent 3 ,
.Xr getrpcent 3 ,
.Xr ethers 3 
。
.Xr bootparamd 8
デーモンは、
.Tn NIS
ライブラリを直接呼び出します。なぜなら、
標準 C ライブラリでは、bootparams を読み込む
関数が存在しないからです。
hosts, services, rpc のデータベースを
.Tn NIS
でサポートにするには、
.Pa /etc/host.conf
ファイルの
.Em nis
の行のコメントを外してください。
残りのデータベースの
.Tn NIS
でのサポートについては、
適切なファイルに特別な意味を持つ '+' エントリを足すと有効になります。
.Pp
.Nm YP 
サブシステムは、
.Pa /etc/rc.conf
ファイル中で初期化されていて、かつ、
.Pa /var/yp
ディレクトリが存在していれば
(デフォルトの配布物では存在しています)、
.Pa /etc/rc
ファイル中で自動的に実行されます。
デフォルトの
.Tn NIS
ドメインは、
.Xr domainname 1
コマンドで設定されている必要があります。
これについても、
.Pa /etc/rc.conf
ファイルで指定されていれば、システム起動時に自動的に
行われます。
.Pp
.Tn NIS
は
.Tn RPC 
ベースの
クライアントサーバシステムであり、
.Tn NIS
ドメイン内のマシンが同じ設定ファイルを共有できるように
するシステムです。
.Tn NIS
を使用することで、システム管理者は最低限の設定データだけで
.Tn NIS
クライアントシステムを立ち上げることができ、
1 つの場所から設定データを追加したり、消したり、変更したり
することができます。
.Pp
.Tn NIS
のすべての情報の正当なコピーは
.Em Tn NIS マスタサーバ
と呼ばれる 1 つのマシン上に保存されます。
情報を保存するのに使用されるデータベースは
.Em Tn NIS マップ
と呼ばれています。
.Bx Free 
では、
これらのマップは
.Pa /var/yp/[domainname]
に保存されます。
ここで、
.Pa [domainname]
は、サービスを受けている
.Tn NIS
ドメイン名です。
1 つの
.Tn NIS
サーバで
一度に複数のドメインをサポートすることができます。そのため、
このような名前のディレクトリが複数あるということもあり得ます。
サポートされるドメイン 1 つにつき、1 つのディレクトリを持ちます。
ドメインはそれぞれ独立した NIS マップのセットを持っています。
.Pp
.Bx Free 
では、
.Tn NIS
マップは Barkeley DB ハッシュのデータベースファイル
(これは、
.Xr passwd 5
データベースファイルで使用されているフォーマットと同じものです)
になっています。
他のオペレーティングシステムで、
.Tn NIS
をサポートしているものでは、古い形式の nbdm データベースを
代わりに使用しています
(Sun Microsystems 社が最初に
.Tn NIS
の実装を ndbm 上で行ったことが大きな要因です。他のベンダは、
自分達で別のデータベースフォーマットを使って実装を行わずに、
単に Sun のコードのライセンスを受けたということです)。
これらのシステムでは、データベースは通常
.Em .dir
ファイルと
.Em .pag
ファイルに分けられています。ndbm コードは、これら 2 つの
ファイルを使って、ハッシュデータベースの別々の部分を
保持するようになっています。Berkeley DB ハッシュの
方法では、この 2 つの部分に分かれている情報を保持するのに
単一のファイルを使います。
つまり、他のオペレーティングシステムでは、
.Pa passwd.byname.dir
ファイルと
.Pa passwd.byname.pag
ファイルがあるのに対し
(これら 2 つはどちらも同じマップの一部分です)、
.Bx Free
では、
.Pa passwd.byname
という名前のファイルがひとつだけあります。
このフォーマットの違いは、たいして重要ではありません。
.Tn NIS
サーバ
.Xr ypserv 8
そして関連のあるツール群だけが、
.Tn NIS
マップのフォーマットがどうなっているのかを知る
必要があります。
.Tn NIS
クライアントシステムでは、
.Tn NIS
データはすべて
.Tn ASCII
形式で受け取ります。
.Pp
.Tn NIS
システムには、主要な 3 つのタイプがあります。
.Bl -enum -offset indent
.It
.Pa Tn NIS クライアント…
これは、
.Tn NIS
サーバに情報の問い合わせをします。
.It
.Pa Tn NIS マスタサーバ…
これは、
.Tn NIS
マップの正当なコピーをすべて管理しています。
.It
.Pa Tn NIS スレーブサーバ…
これは、
.Tn NIS
マップのバックアップコピーを管理しています。バックアップ
コピーは、定期的にマスタサーバが更新しています。
.El
.Pp
.Tn NIS
クライアントは、
.Xr ypbind 8
デーモンを利用して
.Tn NIS
サーバといわゆる
.Em バインド
を確立します。
.Xr ypbind 8
はシステムのデフォルトのドメインをチェックし (
.Xr domainname 1
コマンドで設定されます)、
.Tn RPC
リクエストをローカルネットワーク上でブロードキャスト
し始めます。
.Xr ypbind 8
がバインドを確立しようとしているドメイン名は、
これらのリクエストが指定します。
リクエストのあったドメインのサービスを行うように
設定されているサーバがこのブロードキャストメッセージを
受け取ると、
このサーバは、
.Xr ypbind 8
に対して応答します。そして、
.Xr ypbind 8
はこのサーバのアドレスを記録するのです。もし、複数の
サーバが使用可能であるなら
(例えば、マスタサーバ 1 台とスレーブサーバ数台というような場合)、
.Xr ypbind 8
は、一番最初に応答してきたサーバのアドレスを使用します。
この時点から、クライアントシステムは
.Tn NIS
リクエストをすべてこのサーバに送ります。
.Xr ypbind 8
は時々サーバに "ping" をかけ、サーバがまだ上がっていて、動作
しているかを確認します。この ping の応答を適切な時間内に
受け取らない場合は、
.Xr ypbind 8
は、バインドされていないという印をこのドメインにつけ、再度
ブロードキャストを始めて別のサーバの場所を特定
しようとします。
.Pp
.Tn NIS
マスタサーバおよびスレーブサーバでは、
.Tn NIS
のリクエストはすべて
.Xr ypserv 8
デーモンで扱います。
.Xr ypserv 8
デーモンは、
.Tn NIS
クライアントから入ってくるリクエストを受け取り、
リクエストされたドメインおよびマップ名を対応するデータベース
へのパスに変換し、そのデータベースからデータを取り出して
クライアントに送り返すという仕事をしています。
特別なリクエストのセットがあり、
.Xr ypserv 8
はこのセットを扱えるように設計されています。そのほとんどが
標準 C ライブラリ内の関数として実装されています。
.Bl -bullet -offset indent
.It
.Fn yp_order
この関数は、特定のマップの作成日時を調べます。
.It
.Fn yp_master
この関数は、与えられたマップ / ドメインの
.Tn NIS
マスタサーバ名を獲得します。
.It
.Fn yp_match
この関数は、特定のマップ / ドメイン内のキーで与えられた
ものに対応するデータを見つけます。
.It
.Fn yp_first
この関数は、特定のマップ / ドメイン内の最初の
キーとデータのペアを獲得します。
.It
.Fn yp_next
この関数は、
.Xr ypserv 8
に特定のマップ / ドメイン内のキーを渡し、このキーのすぐ次に
あるキーとデータの対を
.Xr ypserv 8
に返してもらいます (関数
.Fn yp_first
と
.Fn yp_next
とを用いて、
.Tn NIS
マップを順番に検索できます)。
.It
.Fn yp_all
この関数は、マップの内容をすべて取り出します。
.El
.Pp
この他にも、
.Xr ypserv 8
が扱うことのできるリクエストはいくつかあります
(つまり、特定のドメインを扱うことができているのかどうかを
応答するもの (YPPROC_DOMAIN) や、ドメインを扱うことができる
ときだけ応答し、そうでないときには黙っているもの
(YPPROC_DOMAIN_NONACK) などです)。
しかし、これらは普通、
.Xr ypbind 8
のみが生成するリクエストであり、標準のユーティリティ
で扱われるわけではありません。
.Pp
ホストが膨大にあるネットワーク上では、ただ 1 台の
マスタサーバを使うよりも、マスタサーバ 1 台と複数のスレーブサーバ
を使う方が良いことが多いのです。スレーブサーバは、
マスタサーバと全く同じ情報を提供します。ですから、
マスタサーバ上のマップを変更するときはいつでも新しいデータを
.Xr yppush 8
コマンドを使ってスレーブサーバに伝播させるようにすべきです。
.Tn NIS
の Makefile
.Pf ( Pa /var/yp/Makefile )
を使うと、この操作を自動的に行うことができます。
そのためには、管理者が Makefile ファイル中の
.Em NOPUSH=true
と書かれた行をコメントアウトしてください
(NOPUSH は、デフォルトでは true に設定されています。
デフォルトの設定では、
.Tn NIS
サーバが 1 つだけの、小さなネットワーク用になっているからです)。
.Xr yppush 8
コマンドは、マスタサーバとスレーブサーバとの
トランザクションを開始します。その間に、スレーブサーバは、
特定のマップをマスタサーバから、
.Xr ypxfr 8
コマンドを用いて転送します
(スレーブサーバは、
.Xr ypserv 8
内部で
.Xr ypxfr 8
コマンドを自動的に呼び出します。そのため、管理者が直接
.Xr ypxfr 8
コマンドを実行する必要は普通ありません。それでも、
そうしたいなら、手で打って実行することもできます)。
スレーブサーバを管理すると、大きなネットワーク上の
.Tn NIS
のパフォーマンス向上に役立ちます。理由は次の通りです。
.Pp
.Bl -bullet -offset indent
.It
.Tn NIS
マスタサーバがクラッシュした場合や参照できない場合に、
バックアップサービスを提供します。
.It
マスタサーバの負荷が過度に増してしまわないように、
クライアントの負荷を複数のマシンに分散します。
.It
1 つの
.Tn NIS
ドメインをローカルネットワークを越えて使用できます (
サーバが
.Xr ypbind 8
のブロードキャストの範囲外の所にあったならば、
.Xr ypbind 8
デーモンはサーバの場所を自動的に決定できなかったでしょう。
.Xr ypset 8
コマンドを使って
.Xr ypbind 8
デーモンが特定のサーバとバインドを確立するように
することはできますが、このようにすると不便なことがあります。
この問題は、ただスレーブサーバをローカルネットワーク上に
置くだけで回避できます)。
.El
.Pp
.Bx Free
の
.Xr ypserv 8
は、
.Bx Free
のクライアントシステムだけを使った場合、(他の
.Tn NIS
の実装よりも) 強化された
セキュリティを提供するように設計されています。
.Bx Free
のパスワードデータベースシステム
(これは、
.Bx 4.4 
からそのまま受け継がれたものです)
には、
.Em 「シャドウパスワード」
のサポートが含まれています。標準的なパスワードデータベース
には、暗号化されたユーザパスワードは含まれていません。
かわりに、暗号化されたパスワードは
(他の情報と一緒に)
スーパユーザのみがアクセス可能なデータベースに分けて
保存されています。
暗号化されたパスワードが
.Tn NIS
マップとして入手できるとしたら、
このセキュリティは全体的に機能しなくなるでしょう。なぜなら、
ユーザは誰でも
.Tn NIS
のデータを取得できるからです。
.Pp
暗号化されたパスワードを
.Tn NIS
経由で取得されないようにするため、
.Bx Free
の
.Tn NIS
サーバでは、特殊な方法でシャドウパスワードマップ
.Pf ( Pa master.passwd.byname
と 
.Pa master.passwd.byuid )
を扱います。サーバは、特権ポートで生成されたリクエストに
対する応答をするときのみ、シャドウパスワードマップに
アクセスします。特権ポートへの接続が
許されているのは root だけなので、サーバは、そのような
リクエストはすべて特権ユーザ (root) からのものであると
仮定するわけです。その他のポートからのアクセスはすべて
拒否されます。特権のないポートからリクエストを出しても
サーバからはエラーコードが返ってくるだけです。
さらに、
.Bx Free
の
.Xr ypserv 8
は、Wietse Venema の tcp ラッパパッケージをサポートしています。
tcp ラッパのサポートを有効にすると、管理者は、
.Xr ypserv 8
が限られたクライアントに対してのみ応答するように、設定可能です。
.Pp
これらの機能強化によって、普通の
.Tn NIS
よりも優れたセキュリティを提供できますが、それでも
決して 100 パーセント効果があるわけではありません。
ネットワークにアクセスできる誰かがサーバをだまして
シャドウパスワードマップを開示させるようにすることが
それでも可能なのです。
.Pp
クライアント側では、
.Bx Free
の
.Fn getpwent 3
関数は自動的に
.Pa master.passwd
マップを探し、存在していたらそれを使います。もし、
マップが存在していたら、それを使い、これら特別な
マップの全フィールド
(クラス、パスワードが使われている期間、
そしてアカウントの有効期限)
をデコードします。もし、存在していないなら、
標準の
.Pa passwd
マップが代わりに使われます。
.Sh 互換性
システムによっては、例えば
SunOS 4.x などでは、
ホスト名を解決する関数
(
.Fn gethostbyname 
や
.Fn gethostbyaddr
など)
が正しく作動するためには
.Tn NIS
が動作している必要があるものがあります。
こういったシステムでは、
.Xr ypserv 8
デーモンは、
.Pa hosts.byname
あるいは
.Pa hosts.byaddr
マップ中に存在していないホストに関する
情報を返すように要求された場合には、
.Tn DNS
を参照します。
.Bx Free
のリゾルバは、デフォルトで
.Tn DNS
を使います
(望むなら、
.Tn NIS
を使うようにもできます)。
そのため、
.Bx Free
の
.Tn NIS
サーバは、
.Tn DNS
をデフォルトでは参照しません。
しかし、特別なフラグをつけて
.Xr ypserv 8
を起動した場合は
.Tn DNS
を参照するようになります。
また、
v1 サーバが存在することを強く要求するような
システムをおとなしくさせるため、
.Xr ypserv 8
を
.Tn NIS
v1 サーバとして登録することもできます
.Pf ( Bx Free
は、
.Tn NIS
v2 のみ使用しますが、その他のシステムでは、
.Tn SunOS
4.x もそうですが、バインドを確立する際に、
v1 および v2 の両方の機能を有するサーバを探索するものが多いです)。
.Bx Free
の
.Xr ypserv 8
は、実は
.Tn NIS
v1 リクエストを扱いません。
しかし、この "対処モード (kludge mode)"
は、v1 および v2 の両方の機能を有するサーバを頑固に探索するシステムを
黙らせるには便利です
.Pp
(これらの特殊な機能やフラグについての詳細は
.Xr ypserv 8
のマニュアルページを参照してください)。
.Sh バグ
.Bx Free
では、現在
.Tn NIS
クライアントにもサーバにもなることができますが、
.Xr ypupdated 8
あるいは、
.Fn yp_update
関数はサポートされていません。これらには、両方とも
安全な
.Tn RPC
が必要ですが、
.Bx Free
では、これについてもサポートされていません。
.Pp
.Xr getservent 3
と
.Xr getprotoent 3
関数は、まだ
.Tn NIS
をサポートしていません。
幸いなことに、これらのファイルは
それほど頻繁に更新する必要がありません。
.Pp
マニュアルページをもっとたくさん書くべきです。特に、
.Xr ypclnt 3 
についてはそうです。
しばらくは、手元の Sun マシンを探して、それ用の
マニュアルを読んでください。
.Pp
Sun もこのプログラムの著者も、起動時に ypbind がサーバを見つけられないとき
に生じる問題を分かりやすく扱う方法を思い付きませんでした。
.Sh 歴史
.Nm YP
サブシステムは、
Sun の実装と互換性を持たせるために、
.An Theo de Raadt
が最初から書きました。
バグフィックスと改良
および
.Tn NIS
サーバのサポートは、後に
.An Bill Paul
が追加しました。
サーバ側のコードは、もともと、
.An Peter Eriksson
と
.An Tobias Reber
が書き、
GNU Public License
に従っています。
Sun
のコードは一切参照されませんでした。