NIS+ テーブルの構造

NIS+ は、さまざまなネットワーク情報をテーブルに格納します。NIS+ テーブルには、単純なテキストファイルやマップには見られない機能がいくつかあります。これらのテーブルは列エントリ構造をもち、検索パスを使用することや、リンクすることができ、しかも複数の設定方法があります。NIS+ にはあらかじめ構成された 16 個のシステムテーブルがあり、独自のテーブルを作成することもできます。表 5-1 は、事前構成した NIS+ テーブルを示します。

cred テーブルには NIS+ のセキュリティに関係する情報だけが入っています。これについては第 7 章「NIS+ 資格の管理」で説明します。

これらのテーブルには、ユーザー名からインターネットサービスまでの幅広い情報が格納されています。この情報の多くは、設定時または構成の手順の中で生成されます。たとえば、password テーブル内のエントリは、ユーザーアカウントが設定されたときに作成されます。hosts テーブル内のエントリは、ワークステーションがネットワークに加えられたときに作成されます。また、networks テーブル内のエントリは、新しいネットワークが設定されたときに作成されます。

この情報はこのような広範囲にわたる操作によって生成されるため、このマニュアルでは詳細を説明していません。ただし、テーブルの各列に含まれる情報については付録 C 「NIS+ テーブルの情報」 で要約し、NIS+ のグループとネットグループとを区別する場合など、混乱を避けるために必要な場合にだけ詳細を示します。テーブルの情報の詳細は、Solaris の「システム管理マニュアルセット」と「ネットワーク管理マニュアルセット」を参照してください。

ドメインにさらに多くのオートマウントマップを作成できますが、必ず NIS+ テーブルとして格納し、auto_master テーブルの中に入れてください。オートマウントマップを作成して、ユーザー用に作成された auto_master に追加するときは、列名にはキーと値が必要です。オートマウントの詳細は、オートマウントまたは NFS ファイルシステムの関連マニュアルを参照してください。

ネームサービスとして、NIS+ テーブルはオブジェクト自体ではなく、オブジェクトの参照情報を格納するように設計されています。そのため、NIS+ はエントリの大きなテーブルをサポートできません。テーブルに非常に大きなエントリがある場合、rpc.nisd は機能しません。

列とエントリ

NIS+ テーブルにはさまざまな種類の情報が格納されていますが、これらの基本構造はすべて同じで、行と列から構成されます。行は「エントリ」または「エントリオブジェクト」と呼ばれます。

クライアントは、キーだけではなく、任意の検索可能な列によっても情報にアクセスできます。たとえば、baseball という名前のワークステーションのネットワークアドレスを見つけるには、ホスト名の列を探して baseball を見つけます。

次に、baseball のエントリ行を移動して、そのネットワークアドレスを見つけます。

クライアントは、任意のレベルでテーブル情報にアクセスできる (つまり、テーブルに全体としてアクセスできる) ため、NIS+ は 3 つのレベルすべてにセキュリティ機構を提供しています。たとえば、管理者は、オブジェクトレベルで全員にテーブルの読み取り権を割り当て、列レベルで所有者に変更権を割り当て、エントリレベルでグループに変更権を割り当てることができます。テーブルのセキュリティの詳細は、第 10 章「NIS+ のアクセス権の管理」で説明しています。

検索パス

テーブルには、その「ローカル」ドメインについての情報だけが収められています。たとえば、doc.com. ドメイン内のテーブルには、doc.com. ドメインのユーザー、クライアント、およびサービスについての情報だけが収められています。sales.doc.com. ドメイン内のテーブルには、sales.doc.com. ドメインのユーザー、クライアント、およびサービスについての情報だけが収められています。

あるドメイン内のクライアントが、別のドメインに格納されている情報を見つけようとした場合、完全指定名を使用しなければなりません。「NIS+ の名前展開」で説明したように、環境変数 NIS_PATH が正しく設定されていれば、NIS+ サービスがこれを自動的に処理します。

情報を探すときにサーバーがたどる「検索パス」をどの NIS+ テーブルでも指定できます。この検索パスは、NIS+ テーブルをコロンで区切って順番に並べたものです。

table:table:table...

検索パス内のテーブル名は、完全指定をする必要はありません。テーブル名は、コマンド行で入力された名前と同じように展開されます。サーバーが自分のローカルテーブル内に情報を検出できなかった場合、サーバーはクライアントにテーブルの検索パスを返します。クライアントはそのパスを使用して、その情報が見つかるかまたは最後まで、検索パスに名前があるすべてのテーブルを順番に探していきます。

検索パスのメリットを次に示します。次のようなドメイン階層があるとします。

下位にある 3 つのドメインの hosts テーブルの内容は次のようになります。

ここで、sales.doc.com. ドメイン内の luna にログインしたユーザーが、別のクライアントにリモートログインする場合を考えてみます。このユーザーが完全指定名を指定しない場合、そのユーザーがリモートログインできるのは localhost、phoebus、europa、ganymede、および mailhost の 5 台のワークステーションだけです。

sales.doc.com. ドメインにある hosts テーブルの検索パスが、次のように、manf.doc.com. ドメインの hosts テーブルを指定していると仮定します。

hosts.org_dir.manf.doc.com.

これで sales.doc.com. ドメイン内のユーザーは、たとえば、rlogin sirius と入力することができ、NIS+ サーバーはこれを検出します。NIS+ サーバーはまずローカルドメインで sirius を探し、見つからなければ manf.doc.com. ドメイン内を探します。クライアントは manf.doc.com. ドメインをどのように認識するのでしょうか。第 4 章「NIS+ の名前空間」で説明したように、この情報はディレクトリキャッシュに格納されています。これがディレクトリキャッシュにない場合、クライアントは、第 4 章「NIS+ の名前空間」で説明したプロセスに従ってこの情報を入手します。

ただし、検索パスを指定する方法には、若干の欠点があります。ユーザーがたとえば、rlogin luba (luna でなく) などと間違った名前を入力した場合、サーバーは 1 つのテーブルではなく、3 つのテーブルを探さなければエラーメッセージを返せません。名前空間の全域に検索パスを設定した場合、1 つの操作は 2、3 のドメインではなく、10 個のドメイン内のテーブルを検索してから終了します。もう 1 つの欠点は、多数のクライアントが NIS+ テーブルにアクセスする必要があるとき、複数のサーバーのセットと通信するために、性能低下を招くという点です。

また、mailhost は別名として使用されることが多いため、特定のメールホストについての情報を探したいときは、その完全指定名 (mailhost.sales.doc.com. など ) を使用しなければなりません。そうしないと、NIS+ は検索したすべてのドメインで見つけたすべてのメールホストを返します。

テーブルの検索パスを指定するには、「nistbladm コマンド」で説明するように、nistbladm コマンドに -p オプションを付けて実行します。