第 7 章 ネットワーク情報サービス (NIS) (概要)
この章では、ネットワーク情報サービス (NIS) の概要について説明します。
NIS とは分散型ネームサービスであり、 ネットワーク上のオブジェクトおよびリソースを識別し、探索するメカニズムです。 NIS は、ネットワーク全体の情報に関する一様な記憶領域と検索方法を、トランスポートプロトコルやメディアに依存しない形式で提供します。
この章の内容は次のとおりです。
NIS の概要
システム管理者は、NIS を実行することにより、「マップ」と呼ばれる管理データベースをさまざまなサーバー (「マスター」と「スレーブ」) に分散させることができます。 さらに、これらの管理データベースを一元管理により自動的かつ確実な方法で更新できるため、どのクライアントもネットワーク全体を通して一貫した方法で同じネームサービス情報を共有できます。
NIS は DNS とは別に開発されたため、その目的もやや異なっています。 DNS が数値 IP アドレスの代わりにマシン名を使うことによって、通信を簡略化することに焦点を当てているのに対して、NIS は、多様なネットワーク情報を集中管理することによりネットワーク管理機能を高めることに焦点を当てています。 NIS には、マシン名とアドレスだけでなく、ユーザー、ネットワークそのもの、ネットワークサービスについての情報も格納されます。 このようなネットワーク「情報」の集まりを NIS の「名前空間」と呼びます。
注 –
「マシン」名の代わりに「ホスト」名が使われることがあります。 この解説では「マシン」名が使われていますが、一部の画面メッセージまたは NIS マップ名では「ホスト」名または「マシン」名が使われています。
NIS アーキテクチャ
NIS はクライアントサーバー方式を使用します。 NIS サーバーが NIS のクライアントへサービスを提供します。 主サーバーは「マスター」サーバーと呼ばれ、信頼性を保証するためにバックアップつまり「スレーブ」サーバーを持っています。 マスターサーバーとスレーブサーバーは、NIS の情報検索ソフトウェアを使い、NIS のマップを格納します。
NIS はドメインを使用して、マシン、ユーザー、およびネットワークを自分の名前空間に配置します。 しかし、ドメイン階層を使用しないため、NIS の名前空間はフラットになっています。
したがって、上記のような物理ネットワークは、次のように 1 つの NIS ドメインに配置されます。
NIS だけを使っても、NIS ドメインをインターネットに直接接続することはできません。 ただし、NIS を使用してインターネットへも接続したいと希望する組織では、NIS と DNS を組み合せることができます。 その場合、NIS を使用してすべてのローカル情報を管理し、DNS を使用してインターネットのホストを検索できます。 NIS は、NIS マップで情報が見つからない場合にホスト検索の機能を DNS へ転送する転送サービス機能を持っています。 Solaris オペレーティング環境では、ホスト検索要求を DNS だけに転送する、DNS で情報が見つからなければ次に NIS に転送する、あるいは NIS で情報が見つからなければ次に DNS に転送する、という切り替えも nsswitch.conf ファイルで設定できます。 詳細については、第 2 章「ネームサービススイッチ (概要)」を参照してください。
NIS マシンのタイプ
NIS マシンには、次の 3 つのタイプがあります。
-
マスターサーバー
-
スレーブサーバー
-
NIS サーバーのクライアント
NIS クライアントにはどのマシンでもなれますが、NIS サーバー (マスターまたはスレーブ) となるのはディスクが装備されているマシンだけです。 一般にサーバーは、多くの場合はそのサーバー自身のクライアントでもあります。
NIS サーバー
NIS サーバーは、FNS ファイルサーバーと同じマシンである必要はありません。
NIS サーバーには、マスターサーバーとスレーブサーバーがあり、 マスターサーバーとして指定されているマシンには、NIS 管理者が必要に応じて作成、更新する一群のマップが保存されます。 各 NIS ドメインには、マスターサーバーが 1 つだけ存在している必要があります。マスターサーバーは、パフォーマンスの低下を最小限に抑えながら NIS の更新をスレーブサーバーに伝播できます。
システム管理者は、ドメインに別の NIS サーバーをスレーブサーバーとして指定できます。 各スレーブサーバーには、マスターサーバーの NIS マップセットの完全なコピーが存在します。 マスターサーバーの NIS マップが更新されると、必ずこれらの更新がスレーブサーバーに伝播されます。 スレーブサーバーは、マスターサーバーからの要求のオーバーフローに対処して、「サーバー使用不可」エラーを最小限に抑えることができます。
通常、システム管理者はすべての NIS マップに対してマスターサーバーを 1 つ指定します。 ただし、各 NIS マップ内ではマスターサーバーのマシン名が符合化されているので、異なる複数のマップに対して異なる複数のサーバーを、マスターサーバーやスレーブサーバーとして動作するように指定することもできます。 管理の複雑さを最小限に抑えるには、1 つのドメイン内で作成されるすべてのマップに対して、マスターサーバーを 1 つだけ指定します。 この章の例では、1 つのサーバーがドメイン内のすべてのマップのマスターサーバーとなっています。
NIS クライアント
NIS クライアントでは、サーバー上のマップのデータを要求するプロセスが動作します。 各 NIS サーバーに保存されている情報は同じであるはずなので、クライアントではマスターサーバーとスレーブサーバーの区別は行われません。
NIS の要素
NIS ネームサービスは、次の要素から構成されています。
-
ドメイン (NIS ドメイン を参照)
-
マップ (NIS マップを参照)
-
デーモン (NIS デーモンを参照)
-
ユーティリティ (NIS ユーティリティ を参照)
-
NIS コマンドセット (NIS 関連コマンド を参照)
NIS ドメイン
NIS「ドメイン」は、共通の NIS マップセットを共有しているマシンの集合です。 各ドメインにはドメイン名が指定されており、共通の NIS マップセットを共有している各マシンがそのドメインに属しています。
どのマシンも指定されたドメインに属することができます。ただしこれは、そのドメインのマップに対するサーバーが同一ネットワーク上に存在する場合に限ります。 NIS クライアントマシンは、ブートプロセス中にドメイン名を取得して、NIS サーバーにバインドします。
NIS デーモン
NIS サービスは、表 7–1 に示す 5 つのデーモンで提供されます。
表 7–1 NIS デーモン|
デーモン |
機能 |
|---|---|
|
サーバープロセス |
|
|
バインドプロセス |
|
|
高速マップ転送 |
|
|
NIS パスワード更新デーモン ** 下の注を参照 ** |
|
|
他のマップ (publickey など) を更新する |
注 –
rpc.yppasswdd は、r で始まるすべてのシェルを制限付きとみなします。 つまり、r で始まるシェルを持っているユーザーが制約を受けます。 たとえば、/bin/rksh で作業しているユーザーはそのシェルを別のシェルに変更できません。 r で始まるシェルを持っているが、そのような制約を受けたくない場合は、第 10 章「NIS の障害追跡」の対処方法を参照してください。
NIS ユーティリティ
NIS サービスは、表 7–2 に示す 9 つのユーティリティでサポートされています。
表 7–2 NIS ユーティリティ|
ユーティリティ |
機能 |
|---|---|
|
NIS マップの dbm ファイルを作成する |
|
|
マップのデータを一覧表示する |
|
|
NIS データベースの作成、インストール、および NIS クライアントの ypservers リストの初期化を行う |
|
|
マップの特定エントリを検索する |
|
|
サーバーからマップ順序番号を取得する |
|
|
データを NIS マスターサーバーから NIS スレーブサーバーに伝播する |
|
|
特定サーバーにバインドを設定する |
|
|
NIS サーバー名およびニックネーム変換テーブルを表示する |
|
|
NIS マスターサーバーから NIS スレーブサーバーにデータを転送する |
NIS マップ
NIS マップの情報は、ndbm フォーマットで保存されます。 マップファイルのフォーマットについては、ypfiles(4) と ndbm(3C) のマニュアルページで説明しています。
NIS マップは、UNIX の /etc ファイルおよび他の構成ファイルを置換するように設計されているので、名前およびアドレスよりはるかに多くの情報を保存できます。 NIS が動作しているネットワーク上では、各 NIS ドメインの NIS マスターサーバーは、照会されるドメイン内の他のマシンの NIS マップセットを保持します。 NIS スレーブサーバーは、NIS マスターサーバーのマップのコピーを保持します。 NIS クライアントマシンは、マスターサーバーまたはスレーブサーバーから名前空間情報を取得できます。
NIS マップは、本質的には 2 つの列からなるテーブルです。 1 つの列は「キー」であり、もう 1 つの列はキーに関連する情報です。 NIS は、キーを検索してクライアントに関する情報を見つけます。 各マップでは異なるキーが使われるので、一部の情報はいくつかのマップに保存されます。 たとえば、マシン名とアドレスは、 hosts.byname および hosts.byaddr という 2 つのマップに保存されます。 サーバーがマシンの名前を持っており、そのマシンのアドレスを見つける必要がある場合は、サーバーは hosts.byname マップを調べます。 サーバーがマシンのアドレスを持っており、そのマシンの名前を見つける必要がある場合は、サーバーは hosts.byaddr マップを調べます。
NIS Makefile は、インストール時に NIS サーバーとして指定されたマシンの /var/yp ディレクトリに保存されます。 このディレクトリで make を実行すると、makedbm が入力ファイルからデフォルトの NIS マップを作成または更新します。
注 –
マップは必ずマスターサーバー上で作成してください。スレーブサーバーで作成したマップはマスターサーバーに自動的に格納されません。
デフォルトの NIS マップ
Solaris オペレーティング環境では、NIS マップのデフォルトセットが提供されます。 システム管理者は、これらのマップをすべて使用することも一部だけを使用することもできます。 また、他のソフトウェア製品のインストール時にシステム管理者が作成または追加したマップもすべて NIS で使用できます。
NIS ドメインのデフォルトのマップは、各サーバーの /var/yp/domainname ディレクトリに入っています。 たとえば、test.com ドメインに属しているマップは、各サーバーの /var/yp/test.com ディレクトリにあります。
表 7–3 には、デフォルトの NIS マップ、これらの NIS マップに存在する情報、および NIS 動作時にソフトウェアが対応する管理ファイルを調べているか否かが示されています。
表 7–3 NIS マップに関する説明|
マップ名 |
対応する NIS 管理ファイル |
説明 |
|---|---|---|
|
bootparams |
bootparams |
ブート時にクライアントが必要とするファイルのパス名 (ルート、スワップ、その他) を含む |
|
ethers.byaddr |
ethers |
マシン名と Ethernet アドレスを含む。 Ethernet アドレスはマップ内のキー |
|
ethers.byname |
ethers |
ethers.byaddr と同じ。ただしキーは、Ethernet アドレスではなくマシン名 |
|
group.bygid |
group |
グループセキュリティ情報を含む。キーはグループ ID |
|
group.byname |
group |
グループセキュリティ情報を含む。キーはグループ名 |
|
hosts.byaddr |
hosts |
マシン名と IP アドレスを含む。キーは IP アドレス |
|
hosts.byname |
hosts |
マシン名と IP アドレスを含む。キーはマシン (ホスト) 名 |
|
mail.aliases |
aliases |
エイリアスとメールアドレスを含む。キーはエイリアス |
|
mail.byaddr |
aliases |
メールアドレスとエイリアスを含む。キーはメールアドレス |
|
netgroup.byhost |
netgroup |
グループ名、ユーザー名、マシン名を含む。キーはマシン名 |
|
netgroup.byuser |
netgroup |
netgroup.byhost と同じ。ただし、キーはユーザー名 |
|
netgroup |
netgroup |
netgroup.byhost と同じ。ただし、キーはグループ名 |
|
netid.byname |
passwd, hosts group |
UNIX スタイルの認証に使用される。 マシン名とメールアドレスを含む (ドメイン名も含む)。 netid ファイルがある場合には、他のファイルを使用して利用できるデータの他にそれが参照される |
|
netmasks.byaddr |
netmasks |
IP 送出時に使用するネットワークマスクを含む。キーはアドレス |
|
networks.byaddr |
networks |
システムに認識されているネットワーク名、および IP アドレスを含む。キーは IP アドレス |
|
networks.byname |
networks |
networks.byaddr と同じ。ただし、キーはネットワーク名 |
|
passwd.adjunct.byname |
passwd と shadow |
C2 クライアント用の監査情報と隠蔽されたパスワード情報を含む |
|
passwd.byname |
passwd と shadow |
パスワード情報を含む。キーはユーザー名 |
|
passwd.byuid |
passwd と shadow |
passwd.byname と同じ。ただし、キーはユーザー ID |
|
protocols.byname |
protocols |
システムに認識されているネットワークプロトコルを含む |
|
protocols.bynumber |
protocols |
protocols.byname と同じ。 ただし、キーはプロトコル番号 |
|
rpc.bynumber |
rpc |
システムに認識されている RPC のプログラム番号と名前を含む。 キーは RPC のプログラム番号 |
|
services.byname |
services |
ネットワークに認識されているインターネットサービスを一覧表示する。 キーはポートまたはプロトコル |
|
services.byservice |
services |
ネットワークに認識されているインターネットサービスを一覧表示する。 キーはサービス名 |
|
ypservers |
なし |
ネットワークに認識されている NIS サーバーを一覧表示する |
新しい ipnodes マップ (ipnodes.byaddr および ipnodes.byname) が、NIS に追加されました。 このマップには、IPv4 アドレスと IPv6 アドレスの両方が格納されます。 ipnodes(4) のマニュアルページを参照してください。 NIS クライアントとサーバーは、IPv4 または IPv6 のどちらかの RPC トランスポートを使用して通信することができます。
NIS マップの使用
NIS を使うと、/etc ファイルシステムを使った場合に比べ、ネットワークデータベースの更新がはるかに簡単になります。 /etc ファイルシステムではネットワーク環境を更新するたびに各マシンの管理 /etc ファイルを変更する必要がありましたが、NIS ではこのような操作を行う必要はありません。
たとえば、NIS が動作しているネットワークに新しいマシンを追加する場合は、マスターサーバーの入力ファイルを更新し、make を実行するだけです。 これで、hosts.byname および hosts.byaddr マップが自動的に更新されます。 次に、これらのマップはすべてのスレーブサーバーに転送され、ドメインのすべてのクライアントマシン、およびこれらのクライアントマシンのプログラムはこれらのマップを使用することが可能になります。 クライアントマシンまたはアプリケーションがマシン名またはアドレスを要求すると、NIS サーバーは必要に応じて hosts.byname または hosts.byaddr マップを参照し、要求された情報をクライアントに送信します。
ypcat コマンドを使うと、マップの値を表示できます。 ypcat の基本的な使用形式は、次のとおりです。
% ypcat mapname |
mapname は、調べたいマップ名またはその「ニックネーム」です。 ypservers の場合のようにマップがキーだけで構成されている場合は、ypcat -k と入力してください。 ypcat -k と入力しない場合は、空白行が出力されます。 ypcat の他のオプションについては、ypcat(1) のマニュアルページに説明されています。
ypwhich コマンドを使うと、どのサーバーが特定マップのマスターサーバーなのかを判断できます。 次のように入力します。
% ypwhich -m mapname |
mapname は、検索するマスターサーバーのマップ名またはニックネームです。 mapname を入力すると、マスターサーバー名が表示されます。 詳細については、ypwhich(1) のマニュアルページを参照してください。
NIS マップのニックネーム
「ニックネーム」は、マップのフルネームのエイリアスです。 使用可能なマップのニックネーム (たとえば、passwd.byname の場合は passwd) を一覧表示するには、ypcat -x または ypwhich -x と入力してください。
ニックネームは、/var/yp/nicknames ファイルに保存されています。/var/yp/nicknames ファイルには、マップのニックネームとフルネームが 1 つの空白で区切られて入っています。 ニックネームのリストは、追加または更新できます。 ニックネーム数は現在、500 に制限されています。
NIS 関連コマンド
NIS サービスには、特殊なデーモン、システムプログラム、コマンドが含まれています。これらのコマンドについては次の表にまとめてあります。
表 7–4 NIS コマンドについてのまとめ|
コマンド名 |
説明 |
|---|---|
|
NIS クライアントが要求する NIS マップの情報を提供する。 ypserv は、完全なマップセットを備えた NIS サーバー上で動作するデーモン。 NIS サービスが機能するには、少なくとも 1 つの ypserv デーモンがネットワークに存在する必要がある |
|
|
クライアントに NIS サーバーバインド情報を提供する。 ypbind は、要求元クライアントのドメイン内のマップにサービスを提供する ypserv プロセスを見つけてバインドを行う。 ypbind はすべてのサーバーとクライアント上で実行される必要がある |
|
|
自動的に入力ファイルから NIS サーバーのマップを作成する。 ypinitはまた、クライアント上に /var/yp/binding/domain/ypservers 初期ファイルを作成する際にも使用される。 NIS マスターサーバーおよび NIS スレーブサーバーを初めて設定する場合は、ypinit を使用する |
|
|
Makefile を読み込むことで NIS マップを更新する (make を /var/yp ディレクトリで実行した場合)。 make を使うと、入力ファイルに基づいてすべてのマップを更新したり、個々のマップを更新したりできる。 NIS の make の機能については、ypmake(1M) のマニュアルページに説明されている |
|
|
makedbm は入力ファイルを取得し、これを dbm.dir および dbm.pag ファイルに変換する (これらのファイルは、NIS がマップとして使用できる有効な dbm ファイル)。 また、makedbm -u と入力すると、マップを分解できるため、システム管理者はマップを構成するキーと値のペアを参照できる |
|
|
NIS 自体を転送媒体として使い、NIS マップを遠隔サーバーから /var/yp/domain ローカルディレクトリに取り込む。 システム管理者は ypxfr を対話形式で実行したり、crontab ファイルから定期的に実行したりできる。 また、ypxfr が ypserv によって呼び出されると、転送が開始される |
|
|
ypxfr 要求 (一般にスレーブサーバーで発生する) に対してマップ転送サービスを提供する。 ypxfr は、マスターサーバー上でだけ動作する |
|
|
NIS マップの新バージョンを NIS マスターサーバーからそのスレーブサーバーにコピーする。 yppush の実行は、NIS マスターサーバー上で行う |
|
|
指定された NIS サーバーにバインドするように ypbind プロセスに要求する。 ypset は、セキュリティの関係上、通常のオペレーションで気軽に使用できるようには設計されていない。したがって、ypset はできる限り使用しない。 ypbind プロセスの ypset および ypsetme オプションについては、ypset(1M) および ypbind(1M) のマニュアルページを参照 |
|
|
yppoll |
指定されたサーバー上で NIS マップのどのバージョンが動作しているかを通知する。 yppoll はまた、NIS マップのマスターサーバーを一覧表示する |
|
NIS マップの内容を表示する |
|
|
NIS マップ内の指定された 1 つ以上のキーの値を出力する。 システム管理者は、NIS サーバーマップのバージョンを指定することはできない |
|
|
クライアントが現在どの NIS サーバーを使用して NIS サービスを取得しているかを表示する。また、-m mapname オプションを指定してこのコマンドを起動した場合は、どの NIS サーバーが各マップのマスターサーバーであるかが表示される。 -m だけを指定した場合は、使用可能なすべてのマップ名、およびこれらのマップのマスターサーバーが表示される |
NIS のバインド
NIS クライアントは、バインドプロセスにより NIS サーバーから情報を取得します。バインドプロセスは、サーバーリストおよび同報通信という 2 つのモードのどちらかで動作できます。
-
サーバーリストモード。 サーバーリストモードでは ypbind プロセスは、/var/yp/binding/domain/ypservers リストでドメイン内のすべての NIS サーバー名を調べます。 ypbindプロセスは、このファイルに存在するサーバーにだけバインドされます。 このファイルは、ypinit -c を実行すると作成されます。
-
同報通信モード。 ypbind プロセスはまた、RPC 同報通信を使ってバインドを開始できます。 同報通信は、それ以上配信されない唯一のローカルサブネットイベントです。したがって、クライアントと同じサブネット上に少なくとも 1 つのサーバー (マスターまたはスレーブ) が存在しなければなりません。 サーバーは、異なる複数のサブネット上に存在できます (マップはサブネット境界を超えて伝播されるため) 。 サブネット環境での 1 つの一般的方法は、NIS サーバーとしてサブネットルーターを使用することです。 この方法を使用すると、ドメインサーバーはどちらかのサブネットインタフェース上でクライアントにサービスを提供できます。
サーバーリストモード
サーバーリストモードでは、バインドプロセスは次のように動作します。
-
NIS マップで提供された情報を必要とする、NIS クライアントマシン上で動作しているプログラムが、ypbind にサーバー名を要求します。
-
ypbind が、/var/yp/binding/domainname/ypservers ファイルを調べてドメインの NIS サーバーリストを見つけます。
-
ypbind が、NIS サーバーリストの先頭サーバーへのバインドを開始します。 先頭サーバーが応答しない場合、ypbind はサーバーが見つかるまで、あるいは NIS サーバーリストの最後に達するまで、2 番目以降のサーバーへのバインドを順に試みます。
-
ypbind が、どのサーバーにアクセスすべきかをクライアントプロセスに通知します。 次に、クライアントプロセスが直接、サーバーに要求を送信します。
-
ypserv デーモンが、要求された情報をクライアントに送り返します。
同報通信モード
同報通信モードでは、バインドプロセスは次のように動作します。
-
ypbind が、RPC 同報通信を送出して NIS サーバーを探索します。
注 –このようなクライアントをサポートするには、NIS サービスを要求している各サブネット上に 1 つの NIS サーバーが存在する必要があります。
-
ypbind が、同報通信に応答する先頭サーバーへのバインドを開始します。
-
ypbind が、どのサーバーにアクセスすべきかをクライアントプロセスに通知します。 次に、クライアントプロセスが直接、サーバーに要求を送信します。
-
ypserv デーモンが、要求された情報をクライアントに送り返します。
通常、いったんクライアントがサーバーにバインドされると、何らかの原因でバインドが解除されるまではクライアントはサーバーにバインドされたままになります。 たとえば、サーバーがサービスを提供できなくなると、このサーバーがサービスを提供していたクライアントは、新しいサーバーにバインドされます。
どの NIS サーバーが現在、特定クライアントにサービスを提供しているかを調べる場合は、次のコマンドを入力してください。
%ypwhich machinename
machinename は、クライアント名です。 マシン名が指定されていない場合は、ypwhich はデフォルトとしてローカルマシン (コマンドが実行されるマシン) を使用します。
NIS に関する Solaris 9 と旧バージョンとの相違点
Solaris 9 の NIS の特徴は、次のとおりです。
NSKit が存在しない
NIS サービスは、2.6 以前の Solaris リリースには組み込まれていませんでした。 NIS サービスは今までは、個別販売される NSKit からインストールしなければなりませんでした。 現在、NIS サービスは Solaris 9 に組み込まれているため、Solaris 9 の NSKit はありません。
Solaris 2.6 以降のリリースには NIS サービスが組み込まれているので、SUNWnsktu および SUNWnsktr パッケージはもうありません。 NIS のインストールは、NIS サーバークラスタ (SUNWypu および SUNWypr パッケージが含まれている) により行われています。
NIS サービスは現在、/etc/init.d/yp スクリプトでは起動されません。/etc/init.d/yp スクリプトは現在、存在していません。 Solaris 9 では、まずマスターサーバーの NIS マップを ypinit スクリプトで作成し、次に ypstart で NIS を起動します。 NIS サービスの停止には、ypstop コマンドを使用します。
ypupdated デーモン
ypupdated デーモンは、NSKit の 2.6 以前のバージョンには組み込まれていませんでしたが、 Solaris 7 以降のリリース には組み込まれています。
/var/yp/securenets ファイル
/var/yp/securenets ファイルは、以前の NSKit リリースの場合と同様に、NIS サービスへのアクセスを制限するために使用されます。 このファイルが存在する NIS サーバーでは、ファイルに収められている IP アドレスのマシンおよびネットワークに対してのみ、問い合わせに答えたり、マップを提供したりします。 このファイルのフォーマットについては、securenets(4) のマニュアルページを参照してください。
securenets ファイルの例を次に示します。
255.255.255.10 192.168.0.1 host 13.13.14.1 host 13.13.14.2 |
上記において、255.255.255.10 はネットマスクで、13.13.13.255 はネットワークアドレスです。 1 行目の設定では、ypserv はサブネットの 13.13.13.255 の範囲のアドレスにのみ応答します。
/var/yp/securenets ファイルのエントリを変更したときは、ypserv と ypxfrd のデーモンを終了させて再起動をする必要があります。
マルチホームマシンのサポート
ypserv プロセスは、以前の NSKit リリースの場合と同様に、複数のネットワークアドレスを持つマシンをサポートします。 マシンマップが作成されると、Makefile は、複数のアドレスを持つマシンのマップに YP_MULTI_HOSTNAME エントリを作成します。 このエントリには、そのマシンのすべてのアドレスがリストされます。 マシンアドレスが必要な場合は、このリストに存在するアドレスのなかで、希望するアドレスに最も近いアドレスを使用しようとします。 詳細については、ypserv(1) のマニュアルページを参照してください。
希望するアドレスに最も近いアドレスの判断は算術的判断なので、アドレスの妥当性検査は行われません。 たとえば、マルチホームマシンが 6 つの IP アドレスを持っているが、このマルチホームマシン上の 5 つのインタフェースだけが正常に動作していると仮定します。 このマルチホームマシンに直接接続されていないネットワーク上のマシンは、ypserv からダウンインタフェースの IP アドレスを受け取ることができます。 このように、この仮説上のクライアントはマルチホームマシンにアクセスできません。
注 –
マルチホームマシンのすべてのアドレスは通常、有効でなければなりません。 特定のアドレスまたはマシンでサービスが提供できなくなる恐れがある場合は、そのアドレスまたはマシンは NIS マップから削除してください。
SunOS 4 互換モード
NIS は、パスワード構成ファイルを SunOS 4 (Solaris 1) パスワードフォーマットと Solaris 2 パスワードおよびシャドウファイルフォーマットの両方でサポートしています。
動作モードは、$PWDIR/shadow ファイルが存在するかどうかによって決定されます ($PWDIR は、/var/yp/Makefile ファイルに設定されている Makefile マクロセットです) 。 shadow ファイルが存在する場合、NIS は Solaris 2 モードで動作します。 shadow ファイルが存在しない場合、NIS は SunOS 4 モードで動作します。
SunOS 4 モードでは、すべてのパスワード情報が passwd ファイルに保存されています。 Solaris 2 モードでは、パスワード情報は shadow ファイルに保存され、ユーザーアカウント情報は passwd ファイルに保存されます。
make マクロ PWDIR が /etc ディレクトリに設定されている場合、Solaris 2 の passwd 処理要件の関係上、NIS は Solaris 2 モードでしか動作できません。 ただし、PWDIR が /etc 以外のディレクトリに設定されている場合、ユーザーは passwd 構成ファイルを SunOS 4 フォーマットでも Solaris 2 フォーマットでも保存できます。 rpc.yppasswdd デーモンはこれら両方のパスワードフォーマットを認識しますが、 Solaris リリース 2 フォーマットを使用することをお勧めします。
- © 2010, Oracle Corporation and/or its affiliates