ドメインの階層

NIS+ ドメイン階層には、名前空間をより管理しやすい複数の構成要素に分割できる、という利点があります。各構成要素には独自のセキュリティ、情報管理、管理方針を持たせることができます。クライアントの数が 500 を超える場合、あるユーザーグループに異なるセキュリティに方針を設定したい場合、あるいは地理的に分散したサイトがある場合は、階層を使用することをお勧めします。

ドメイン階層の必要がなければ、階層を使用しません。こうすることにより、NIS+ への移行が簡略化されます。すべてのユーザーが同じ NIS ドメイン内にいる場合、これらのユーザーは、完全指定名を使用しなくてもお互いを直接認識することができます。しかし、NIS+ 階層を作成すると、ユーザーは別々のドメインに置かれます。つまり、完全指定名か完全指定パスを使用しないかぎり、あるドメインにいるユーザーは別のドメインにいるユーザーを直接認識することができません。

たとえば、sales.com. と factory.com. というサブドメインが .com. ドメインの下にあるとします。この場合、sales.com. ドメインのユーザー juan が factory.com. ドメインのユーザー myoko にメールを送るためには、彼女の名前を myoko@hostname.factory.com. (または myoko@hostname.factory) と指定する必要があります。この 2 人のユーザーが同じドメインにいたときには、myoko と指定するだけで十分でした。リモートログインでもドメイン間の完全指定名が必要です。

テーブル間のパスを使用すると、あるドメインのテーブルと別のドメインのテーブルとの間に接続を設定することができますが、ドメイン階層を使用するメリットはなくなります。また、NIS+ サービスの信頼性も低くなります。これは、クライアントが、各自のホームドメインの利用状況だけでなく、各自のテーブルにパス指定される他のドメインの利用状況にも依存するようになるためです。テーブル間のパスを使用すると、要求への応答時間も長くなります。

ドメインの階層 - Solaris 2.6 以前のリリース

Solaris 2.6 以前のリリースでは、各サブドメインの NIS+ サーバーは、そのドメインではなく、親ドメインに含まれます。ただし、ルートドメインは除きます。サーバーとサブドメインの関係がこのような関係になっていると、サーバーがネームサービスデータをサブドメインから取得できることを想定しているアプリケーションの場合に、問題が発生します。たとえば、サブドメインの NIS+ サーバーが NFS サーバーでもある場合、サーバーはネットグループ情報をサブドメインからではなく、サブドメインの上位ドメインから取り出します。このために、混乱が発生する可能性があります。階層によって問題が発生する可能性がある場合の別の例としては、遠隔ログインするユーザーが自分のワークステーションからでは実行できないコマンドを実行する場合に、この NIS+ サーバーも使用する場合です。ルートドメインが 1 つしかない場合には、NIS+ ルートサーバーは自分がサーバーであるドメイン内にいるので、このような問題は発生しません。

ドメインの階層 - Solaris 7

Solaris 7 では、ドメインの NIS+ サーバーは、自分がサーバーであるドメイン内に存在することができます。したがって、サーバーはクライアントが使用している名前をドメイン名に設定することができます。残りのドメインの階層との機密保護通信を実行できるサーバーの機能には影響を与えません。