ドメインの階層

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

ドメイン階層の必要がなければ、階層を使用しないことにより、NIS+ への移行が簡略化されます。これは、ルートドメインの場合を除くと、各サブドメインの NIS+ サーバは、そのサービスを提供するサブドメインの一部ではないためです。 NIS+ サーバは、サービスを提供するサブドメインの親ドメインに存在します。

このサーバとサブドメインの関係は、サーバがサブドメインからネームサービスデータを入手できることを前提としているアプリケーションにおいて、問題の原因となります。 たとえば、サブドメインの NIS+ サーバが NFS サーバでもある場合、そのサーバは、サブドメインからそのネットグループ情報を入手しません。そのかわり、サブドメインの上位にある親ドメインから情報を取り出します。このことは、混乱を招くおそれがあります。また、ユーザがリモートでログインし、各自のワークステーションからは実行できない特定のコマンドを実行するために NIS+ サーバを使用する場合にも、階層が問題の原因となる場合があります。ルートドメインが 1 つしかなければ、NIS+ のルートサーバは、サービスを提供するドメイン内にあるため、上記のような問題は起こりません。

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

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

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