資格、アクセス権ともに正しいにもかかわらず、クライアントの要求が拒否されるという場合もあります。これはおそらく、名前空間のどこかに古い情報が存在することが原因です。
公開鍵など、資格に関する情報は、名前空間内の様々な場所に保存されています。NIS+ は、この情報を保存先のオブジェクトの生存期間の値にもとづいて定期的に更新しますが、更新と更新との間にときおり情報のずれが起こります。その結果、一部の操作が行えなくなります。表 A-2 は、資格に関する情報を保存するオブジェクト、テーブル、ファイルと、そのリセットの方法を示したものです。
表 A-2 資格に関する情報の保存場所
項目 |
保存対象 |
リセットおよび更新の方法 |
---|---|---|
cred テーブル |
NIS+ 主体の非公開鍵と公開鍵。これらの鍵のマスターコピーとなる |
nisaddcred を使用して新しい資格を作成する。これによって既存の資格が更新される。chkey を使用しても同様のことが行える |
ディレクトリオブジェクト |
個々のサーバーの公開鍵のコピー |
ディレクトリオブジェクトに対して/usr/lib/nis/ nisupdkeys コマンドを実行する |
キーサーバー |
その時点でログインされている NIS+ 主体の非公開鍵 |
主体ユーザーに対して keylogin を実行する。または主体ワークステーションに対して keylogin -r を実行する |
NIS+ デーモン |
ディレクトリオブジェクトのコピー (そのサーバーの公開鍵のコピーが含まれる) |
デーモンおよびキャッシュマネージャを終了した後、再起動する |
ディレクトリキャッシュ |
ディレクトリオブジェクトのコピー (そのサーバーの公開鍵のコピーが含まれる) |
NIS+ キャッシュマネージャを終了した後、nis_cachemgr -i コマンドを使用して再起動する。-i オプションを指定すると、コールドスタートファイルによってディレクトリキャッシュがリセットされた後、キャッシュマネージャが再起動される |
コールドスタートファイル |
ディレクトリオブジェクトのコピー (そのサーバーの公開鍵のコピーが含まれる) |
ルートマスターで NIS+ デーモンを終了した後、再起動する。デーモンは、新しい情報を既存の NIS_COLD_START ファイルに再読み込みする。 まず、主体の /var/nis からコールドスタートファイルと共有ディレクトリファイルを削除し、キャッシュマネージャを終了する。次に nisinit -c を使用して主体を再初期化する。主体に対して「trusted」と指定したサーバーは、新しい情報を主体の既存のコールドスタートファイルに再読み込みする |
passwd テーブル |
ユーザーのパスワードまたはワークステーションのスーパーユーザーのパスワード |
passwd -r nisplus コマンドを使用する。これによって、NIS+ passwd テーブル、cred テーブルの中でパスワードが更新される |
passwd ファイル |
ユーザーのパスワードまたはワークステーションのスーパーユーザーのパスワード |
passwd -r nisplus コマンドを使用する。スーパーユーザー、一般ユーザーのどちらでログインしてもよい |
(NIS) |
ユーザーのパスワードまたはワークステーションのスーパーユーザーのパスワード |
passwd -r nisplus を使用する |
情報が古くなる原因として最も多いのが、サーバーの公開鍵のバージョンが古くなることです。一般に、この問題を解決するには、アクセスするドメインに対して nisupdkeys を実行します (nisupdkeys コマンドの使用方法の詳細は、第 7 章「NIS+ 資格の管理」を参照)。
鍵の中にはファイルやキャッシュに保存されているものもあるため、nisupdkeys ですべての問題を解決できるわけではありません。鍵を手作業で更新しなければならない場合もあります。この場合は、「サーバーの公開鍵の内容は、公開鍵が作成された後どのように名前空間オブジェクトに伝えられるのか」ということについて理解する必要があります。サーバーの公開鍵の伝播には、一般に以下の 5 つの段階があります。それぞれの詳細について説明します。
1:サーバーの公開鍵が作成される
NIS+ サーバーも初めは NIS+ クライアントなので、公開鍵の作成は他の NIS+ クライアントの公開鍵と同じ方法 (nisaddcred コマンドを使用する) で行います。公開鍵はその後、サーバーが実際にサポートするドメインではなく、サーバーのホームドメインの cred テーブルに保存されます。
2:公開鍵の内容がディレクトリオブジェクトに伝えられる
NIS+ ドメインと NIS+ サーバーの設定後は、サーバーとドメインを関係づけることができます。この「関係づけ」は、nismkdir コマンドで行います。nismkdir コマンドによってサーバーとディレクトリの関係づけが行われる際、サーバーの公開鍵も cred テーブルからドメインのディレクトリオブジェクトにコピーされます。たとえば、サーバーが doc.com. ルートドメインのクライアントで、sales.doc.com. ドメインのマスターサーバーになっているという場合を考えてみましょう。
公開鍵は cred.org_dir.doc.com. ドメインから、ディレクトリオブジェクト sales.doc.com. にコピーされます。以上のことは、niscat -o sales.doc.com. というコマンドを使用して確認できます。
3:ディレクトリオブジェクトの内容がクライアントファイルに伝えられる
nisinit ユーティリティまたは nisclient スクリプトを使用すれば、すべての NIS+ クライアントを初期化できます。
他の類似のコマンドと同様、nisinit (または nisclient) では、コールドスタートファイル /var/nis/NIS_COLDSTART が作成されます。コールドスタートファイルは、クライアントのディレクトリキャッシュ /var/nis/NIS_SHARED_DIRCACHE の初期化に使用されます。コールドスタートファイルには、クライアントのドメイン中のディレクトリオブジェクトのコピーが含まれています。ディレクトリオブジェクトには、すでにサーバーの公開鍵のコピーが含まれているため、これで公開鍵の内容はクライアントのコールドスタートファイルに伝えられたことになります。
また、クライアントがホームドメインの外のサーバーに対して要求をした場合、リモートドメインのディレクトリオブジェクトのコピーが、クライアントの NIS_SHARED_DIRCACHE ファイルに保存されます。クライアントのキャッシュの内容は、nisshowcache コマンドを使用して調べることができます (184 ページ参照)。
複製サーバーがドメインに追加されるか、サーバーの鍵が更新されるまでは、鍵の伝播はこの段階にとどまります。
4:複製サーバーがドメインに追加された場合の処理
複製サーバーがドメインに追加されると、nisping コマンドによって NIS+ テーブル (cred テーブルを含む) が新しい複製サーバーにダウンロードされます (185 ページ参照)。これによって、元のサーバーの公開鍵も複製サーバーの cred テーブルに保存されます。
5:サーバーの公開鍵が更新された場合の処理
サーバーの DES 資格 (サーバーのルート ID) を変更すると、公開鍵も変更されます。その結果、サーバー用に cred テーブルに保存される公開鍵が、以下の場所に保存されるものと矛盾します。
複製サーバーの cred テーブル (数分の間)
サーバーがサポートするドメイン中の、メインディレクトリオブジェクト (生存期間終了まで)
サーバーがサポートするドメイン中の、クライアントの NIS_COLDSTART ファイルおよび NIS_SHARED_DIRCACHE ファイル (生存期間終了まで、通常 12 時間)
サーバーがサポートするドメインに要求をしたクライアントの、NIS_SHARED_DIRCACHE ファイル (生存期間終了まで)
サーバーの鍵は、ほとんどの場所において数分〜 12 時間で自動的に更新されます。すぐに更新するには、以下のコマンドを使用します。
表 A-3 サーバーの鍵の更新
保存場所 |
コマンド |
参照ページ |
---|---|---|
複製サーバーの cred テーブル (nisping を使用しなくても、テーブルは数分で自動的に更新される) |
nisping コマンド | |
サーバーがサポートするドメインのディレクトリオブジェクト |
nisupdkeys コマンド | |
クライアントの NIS_COLDSTART ファイル |
nisinit -c コマンド | |
クライアントの NIS_SHARED_DIRCACHE ファイル |
nis_cachemgr コマンド |
nis_cachemgr の再起動は、既存の nis_cachemgr を終了してから行います。