ドメインの階層

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

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

たとえば、sales.com. および factory.com. というサブドメインが、.com. ドメインから作成されているとします。このとき、sales.com. ドメインのユーザー juan が factory.com. ドメインのユーザー myoko にメールを送信するには、送信先のユーザー名を myoko ではなく myoko@hostname.factory.com. または myoko@hostname.factory とする必要があります。送信先のユーザーが同じドメインに存在する場合は、myoko だけでかまいません。リモートログインでもドメイン間の完全指定名が必要です。

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

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

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

ドメインの階層 – Solaris 9

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