Solaris のシステム管理 (ネーミングとディレクトリサービス : NIS+ 編)

NIS+ 主体 (クライアント)

NIS+ 主体とは、NIS+ サービスに要求をするエンティティ (クライアント) のことです。

NIS+ 主体

一般ユーザーであってもスーパーユーザー (root) であってもログインをすれば NIS+ 主体になります。実際の要求は、前者の場合はクライアントユーザーから、後者の場合はクライアントマシンから送られます。つまり NIS+ 主体は、クライアントユーザーである場合と、クライアントマシンである場合とがあります。

また NIS+ サーバーから NIS+ サービスを提供するエンティティも、NIS+ 主体になることができます。すべての NIS+ サーバーは NIS+ クライアントにもなるので、サーバーが NIS+ の主体となる場合もあります。

NIS+ クライアント

NIS+ クライアントとは、NIS+ サービスを要求するように設定されたマシンです。NIS+ クライアントの設定では、セキュリティ資格 (credential) を設定し、クライアントを適切な NIS+ グループのメンバーとし、そのホームドメインを確認し、スイッチ構成ファイルを確認し、最後に NIS+ 初期設定スクリプトを実行します (詳細は、パート II「NIS+ の紹介と概要」を参照)。

NIS+ クライアントは、セキュリティ上の制約に従って、名前空間のどの部分にもアクセスできます。つまり、認証されており、しかも適切なアクセス権が与えられている場合、名前空間内のどのドメインの情報やオブジェクトにもアクセスできます。

クライアントは名前空間全域にアクセスできますが、1 つのクライアントが所属するドメインは 1 つだけであり、これをその「ホーム」ドメインと呼びます。クライアントのホームドメインは、インストール時に指定されるのが普通ですが、インストール後でも変更または指定できます。クライアントの IP アドレスや資格など、クライアントについてのすべての情報は、そのホームドメインの NIS+ テーブルに格納されています。

NIS+ クライアントであることと、NIS+ テーブルに登録されていることは、微妙な違いがあります。あるマシンについての情報を NIS+ テーブルに入力しても、そのマシンが自動的に NIS+ クライアントになるわけではありません。これは単に、すべての NIS+ クライアントがそのマシンの情報を使用できるようにするだけです。実際に NIS+ クライアントとして設定しない限り、そのマシンから NIS+ サービスを要求することはできません。

逆に、あるマシンを NIS+ クライアントにしても、そのマシンについての情報は NIS+ テーブルに入力されません。これは単に、そのマシンで NIS+ サービスを受信できるようにするだけです。管理者がそのマシンについての情報を明確に NIS+ テーブルに入力しないと、ほかの NIS+ クライアントはその情報を入手できません。

クライアントが名前空間へのアクセスを要求した場合、実際には、クライアントは名前空間内の特定ドメインへのアクセスを要求していることになります。したがって、クライアントは、アクセスしようとしているドメインをサポートするサーバーに自分の要求を送信します。簡単に表現すると次のようになります。


図には、doc.com ドメイン内のサーバーにアクセス中のクライアントを示します。図には、sales.doc.com サーバーにアクセス中のクライアントを示します。

クライアントはこのサーバーを、試行錯誤によって認識します。 クライアントは、自分のホームサーバーから始めて、正しいサーバーが見つかるまでサーバーを 1 台ずつ試していきます。サーバーがクライアントの要求に応じられない場合、サーバーは適切なサーバーの検索に役立つ情報をクライアントに送信します。やがて、クライアントは自分の情報キャッシュを構築し、適切なサーバーをより効率的に検索できるようになります。このプロセスの詳細を次に示します。

コールドスタートファイルとディレクトリキャッシュ

クライアントが初期設定されるとき、クライアントには「コールドスタートファイル」が与えられます。コールドスタートファイルの目的は、名前空間内のサーバーと連絡をとるための起点として使用できるディレクトリオブジェクトのコピーをクライアントに提供することです。ディレクトリオブジェクトには、アドレス、公開鍵、およびそのディレクトリをサポートするマスターサーバーと複製サーバーについての情報が収められています。通常、コールドスタートファイルには、クライアントのホームドメインのディレクトリオブジェクトが収められています。

コールドスタートファイルは、クライアントのローカルの「ディレクトリキャッシュ」を初期設定するためにだけ使用されます。ディレクトリキャッシュは、「キャッシュマネージャ」と呼ばれる NIS+ 機能によって管理されます。キャッシュマネージャには、クライアントが自身の要求を適切なサーバーに送信できるようにするためのディレクトリオブジェクトが格納されます。クライアントのコールドスタートファイルから取得された情報は、/var/nis 内の NIS_SHARED_DIRCACHE というファイルにダウンロードされます。

図には、クライアントのディレクトリキャッシュを初期化するコールドスタートファイルを示します。

名前空間のディレクトリオブジェクトのコピーを自分のディレクトリキャッシュに格納することによって、クライアントは、どのサーバーがどのドメインをサポートするかを知ることができます。クライアントのキャッシュの内容を表示するには、nisshowcache コマンドを使用してください (nisshowcache コマンド」を参照)。簡単な例を次に示します。

ドメイン名とディレクトリ名が同じ 

サポートするサーバー 

IP アドレス 

doc.com.

rootmaster 

172.29.6.77 

sales.doc.com.

salesmaster 

172.29.6.66 

manf.doc.com.

manfmaster 

172.29.6.37 

int.sales.doc.com.

Intlsalesmaster 

10.22.3.7 

これらのコピーを最新の状態に保つため、各ディレクトリオブジェクトには「生存期間」フィールドがあります。このデフォルト値は 12 時間です。クライアントがディレクトリオブジェクトを求めてディレクトリキャッシュを調べ、最近の 12 時間以内にこれが更新されていないことを発見した場合、キャッシュマネージャはオブジェクトの新しいコピーを獲得します。nischttl コマンド」で説明するように、ディレクトリオブジェクトの生存期間の値は、nischttl コマンドで変更できます。ただし、生存期間を長くするほどオブジェクトのコピーが古くなる可能性が高くなり、生存期間を短くするほどネットワークトラフィックとサーバーのロードが増加することに注意してください。

ディレクトリキャッシュは、これらのディレクトリオブジェクトをどうやって蓄積するのでしょうか。前に説明したように、コールドスタートファイルはキャッシュ内の最初のエントリを提供します。したがって、クライアントが最初の要求を送信するとき、コールドスタートファイルによって指定されたサーバーに要求を送信します。その要求がそのサーバーによってサポートされるドメインへのアクセスである場合、そのサーバーは要求に応答します。

図には、コールドスタートファイルで指定されたサーバにアクセスしているクライアントを示します。

その要求が別のドメイン (たとえば、sales.doc.com.) へのアクセスである場合、サーバーは、クライアントが適切なサーバーを探すのを助けようとします。サーバーが、自分のディレクトリキャッシュ内に該当するドメイン用のエントリを保有している場合、そのドメインのディレクトリオブジェクトのコピーをクライアントに送信します。クライアントは、その情報を今後の参照用として自分のディレクトリキャッシュにロードし、そのサーバーに要求を送信します。

図には、サーバーがディレクトリオブジェクトのコピーを自分のドメインに送信する様子を示します。図には、サーバーがディレクトリオブジェクトのコピーを自分のドメインに送信する様子を示します。

ほとんどありえないことですが、クライアントがアクセスしようとしているディレクトリオブジェクトのコピーを、サーバーが保有していない場合、そのサーバーは、自分のホームドメインのディレクトリオブジェクトのコピーをクライアントに送信します。ここには、そのサーバーの親のアドレスが登録されています。クライアントは、親サーバーを使ってこのプロセスを繰り返し、適切なサーバーを見つけるか、または名前空間内の全サーバーを試し終わるまで、これを繰り返します。クライアントがドメイン内の全サーバーを試し終わった後でどうするかは、そのネームサービススイッチ構成ファイルの指示によって決まります。

やがてクライアントは、名前空間内のすべてのディレクトリオブジェクトのコピーをキャッシュ内に蓄積します。したがって、これらディレクトリオブジェクトをサポートするサーバーの IP アドレスも蓄積することになります。クライアントがほかのドメインへのアクセス要求を送信する必要があるとき、通常は、自分のディレクトリキャッシュの中から自分のサーバー名を見つけ、そのサーバーにアクセス要求を直接送信できます。

NIS+ サーバーはクライアントでもある

NIS+ サーバーは NIS+ クライアントでもあります。サーバーとして設定するマシンは、まずクライアントとして初期化する必要があります。唯一の例外はルートマスターサーバーであり、このサーバーには独自の設定を行う必要があります。

つまり、サーバーはドメインをサポートするだけではなく、ドメインにも「所属する」のです。つまり、クライアントになることによって、サーバーにはホームドメインがあるということです。サーバーのホスト情報は自分のホームドメインの hosts テーブルに格納され、その DES 資格は自分のホームドメインの cred テーブルに格納されます。ほかのクライアントと同様、サーバーは、自分のディレクトリキャッシュに記録されているサーバーに対して、サービス要求を送信します。

忘れてはならない重要な点は、ルートドメインを除いて、サーバーのホームドメインは、そのサーバーがサポートするドメインの「親」ドメインであるということです。

つまり、サーバーは 1 つのドメイン内のクライアントをサポートしますが、別のドメインの「クライアント」になるのです。ルートドメインを除いて、サーバーは自分のサポートするドメインのクライアントにはなれません。ルートドメインをサポートするサーバーには親ドメインがないため、これらはルートドメイン自体に所属します。

たとえば、次のような名前空間を考えてみます。

この図は、異なるドメイン内のサーバーであり、クライアントでもあるサーバーを示しています。

各サーバーがどのドメインをサポートし、どのドメインに所属するかを次に示します。

サーバー 

サポートするドメイン 

所属するドメイン 

RootMaster 

doc.com. 

doc.com. 

SalesMaster 

sales.doc.com. 

doc.com. 

IntlSalesMaster 

intl.sales.doc.com. 

sales.doc.com. 

ManfMaster 

manf.doc.com. 

doc.com.