test

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

第 24 章 NIS+ の問題解決

この章では、問題をいくつかの種類に分類しています。各問題について、一般的な症状を示し問題について説明してから、推奨する対策を 1 つまたは複数挙げています。

また、付録 A 「エラーメッセージ」では、NIS+ の詳細な共通エラーメッセージをアルファベット順に掲載しています。

注 –

NIS+ は、将来のリリースでサポートされない可能性があります。NIS+ から LDAP への移行支援ツールは、Solaris 9 オペレーティング環境で使用できます (『Solaris のシステム管理 (ネーミングとディレクトリサービス : DNS、NIS、LDAP 編)』を参照)。詳細については、http://www.sun.com/directory/nisplus/transition.html を参照してください。

NIS+ のデバッグオプション

NIS+ のデバッグオプション

NIS_OPTIONS の環境変数を設定して、NIS+ デバッグオプションを制御できます。

オプションは、二重引用符で囲まれたオプションセットと共にスペースで区切られた NIS_OPTIONS コマンドの後に指定されます。各オプションに name=value のフォーマットがあります。値は、特定のオプションに従って整数、文字列、ファイル名になります。整数値のオプションに対して、値が指定されていない場合には、デフォルト値は 1 になります。

NIS_OPTIONS は次のオプションを認識します。

表 24–1 NIS_OPTIONS オプションと値

オプション 

値 

動作 

debug_file

filename

デバッグの指定ファイルへの出力を指示する。このオプションが指定されていない場合は、デバッグは stdout に出力する

debug_bind

Number

サーバーの選択プロセスに関する情報を表示する 

debug_rpc

1 または 2

値が 1 の場合には、NIS+ に対する RPC コールを表示する。値が 2 の場合には、RPC コールと RPC の内容、引数、結果の両方を表示する 

debug_calls

Number

NIS+ API へのコールと、アプリケーションに戻される結果を表示する 

pref_srvr

String

nisprefadm コマンドによって生成されるのと同じフォーマットで、優先サーバーを指定する (表 20–1 を参照)。これは nis_cachemgr で指定された優先サーバーを上書きする

server

String

特定のサーバーを設定する 

pref_type

String

現在実装されていない 

例を以下に示します。(C シェルの使用を前提)


setenv NIS_OPTIONS “debug_calls=2 debug_bind debug_rpc”
 

setenv NIS_OPTIONS “debug_calls debug_file=/tmp/CALLS”
 

setenv NIS_OPTIONS “debug_calls server = sirius”

NIS+ の管理上の問題

この節では、日常的な NIS+ 名前空間の管理作業を行なっているときに発生する可能性のある問題について説明します。一般的な症状には次のようなものがあります。

無効なオブジェクトの問題

「症状」

このエラーメッセージには、いくつもの原因が考えられます。

nisinit のエラー

次の点をチェックしてください。

チェックポイントのエラーが続く

チェックポイント処理 (たとえば、nisping -C コマンドによる操作) が、継続してエラーを起こしている場合は、十分なスワップ空間やディスク容量があるかどうか確認してください。syslog 内のエラーメッセージもチェックします。core ファイルがディスク空間を使い果たしていないかどうかチェックします。

ユーザーをグループに追加することができない

ユーザーをそのドメイン内のグループのメンバーとして追加する前に、そのユーザーは、ドメインの cred テーブルの中で LOCAL の資格を持つ NIS+ 主体クライアントになっていなければなりません。DES の資格を持っているだけでは、十分ではありません。

ログが大きくなりすぎた

nisping -C を使用して定期的にチェックポイントを実行していないと、ログファイルが極端に大きくなることがあります。マスターサーバーのすべての複製サーバーが更新されるまでは、マスター上にあるログはクリアされません。複製がダウンしている場合や、サービスが行われていない場合、複製サーバーと通信できない場合は、その複製サーバーに対応するマスターをクリアできません。このため複製がダウンしているか、または一定時間使用できない場合には、ディレクトリを削除するで説明するとおり、マスターから複製を削除する必要があります。ディレクトリ org_dir とサブディレクトリ groups_dir を最初に削除してから、ディレクトリ自体を削除してください。

ディスク容量の不足

十分なディスク容量が確保できない場合は、様々なエラーメッセージが表示されます (詳細は、ディスク容量の不足を参照)。

トランザクションログファイルを切り捨てることができない

まずはじめに、問題のファイルが存在するか、読み込み可能か、そのファイルに書き込み権が割り当てられているかどうかチェックしてください。

最も可能性のある原因は、適切なアクセス権を割り当てられているものの、ディスク容量が不足していることです。チェックポイント処理では、ログを切り捨て一時ファイルを削除する前に、ますログ一時ファイルのコピーを作成します。このため、一時ファイルを作成するためのディスク容量がない場合は、チェックポイント処理を進めることができません。使用可能なディスク容量をチェックし、必要であれば容量を確保してください。

ドメイン名の混同

NIS+ の多くのコマンドや操作にとって、ドメイン名は重要な役割を果たします。ルートサーバーを除いて、NIS+ のすべてのマスターと複製は、それ自身がサービスを提供するドメインより上にあるドメインのクライアントであるということに特に注意してください。サーバーまたは複製サーバーを、それ自身がサービスを提供するドメインのクライアントとして誤って扱った場合、「Generic system error」や「Possible loop detected in namespace directoryname:domainname」というエラーメッセージが表示されます。

たとえば、altair というマシンが、subdoc.doc.com. ドメインのクライアントだとします。サブドメイン subdoc.doc.com. のマスターサーバーが sirius というマシンだとすると、sirius は doc.com. ドメインのクライアントになります。 したがって、ドメインの指定や変更を行うときは、混同しないように次のルールに注意してください。

  1. クライアントマシンは、特定のドメインかサブドメインに所属します。

  2. 特定のサブドメインにサービスを提供するサーバーや複製サーバーは、そのドメインより上にあるサブドメインのクライアントです。

  3. 2 の規則の唯一の例外は、ルートマスターサーバーとルート複製サーバーです。これらは、それ自身がサービスを提供するドメインのクライアントになります。つまり、ルートドメインのクライアントになるのは、ルートマスターとルート複製だけです。

したがって、上の例では、マシン altair の完全指定名は、altair.subdoc.doc.com. です。マシン sirius の完全指定名は、sirius.doc.com. です。sirius.subdoc.doc.com. という名前は正しくありません。sirius は doc.com. のクライアントで、subdoc.doc.com. のクライアントではないためエラーの原因になります。

org_dir や groups_dir を削除できない

親ディレクトリを削除する前に、必ず org_dir と groups_dir を削除してください。ドメインの groups_dir と org_dir を削除する前に、nisrmdir を使用してドメインを削除すると、これらの 2 つのサブディレクトリは、どちらも削除できなくなります。

複製の失敗からの NIS+ ディレクトリの削除または分離

複製サーバーからディレクトリを削除または分離する場合には、最初にディレクトリの org_dir と groups_dir のサブディレクトリを削除してから、ディレクトリ自体を削除します。各サブディレクトリが削除された後に、削除しようとするディレクトリの親ディレクトリで nisping を実行する必要があります (ディレクトリを削除する を参照)。

nisping の操作に失敗すると、ディレクトリは完全に削除または分離されません。

この状態が発生したら、次の手順を実行して、修正する必要があります。

  1. 複製上の /var/nis/rep/org_dir を削除します。

  2. org_dir.domain が、複製上の /var/nis/rep/serving_list に表示されないことを確認してください。

  3. domain で nisping を実行します。

  4. マスターサーバーから nisrmdir -f replica_directory を実行します。

分離しようとしている複製サーバーがダウンしているか、または通信不能である場合に nisrmdir -s コマンドは「Cannot remove replica name : attempt to remove a non-empty table」というエラーメッセージが出されます。

このような場合は、マスターサーバー上で nisrmdir -f -s replicaname コマンドを実行すれば、強制的に切り離すことができます。しかし、nisrmdir -f -s replicaname を使って通信不能な複製を分離する場合には、複製がオンライン状態に戻ったらすぐに、nisrmdir -f -s replicaname を再実行して、複製の /var/nis ファイルシステムを消去する必要があります。nisrmdir -f -s replicaname を再実行しないと、複製がサービスを再開した時に複製上に残された古い情報によって問題が発生します。

NIS+ データベースの問題

この節では、名前空間のデータベースとテーブルに関連する問題を説明します。一般的な症状には次のようなものがあります。処理内容に関係する次の表現が含まれているエラーメッセージが表示されます。

rpc.nisd が失敗します。

NIS+ の所有権とアクセス権の問題を参照してください。

rpc.nisd の複数の親プロセス

「症状」

次の表現が含まれている様々なエラーメッセージが表示されます。これらのメッセージは、データベースやトランザクションログが壊れていることを意味しています。

「考えられる原因」

複数の独立した rpc.nisd デーモンを実行させています。通常の動作では、rpc.nisd は他の rpc.nisd デーモンを子プロセスとして生成できます。このこと自体は問題はありません。しかし、1 台のマシン上で 2 つの rpc.nisd デーモンが親として動作している場合は、互いのデータを上書きし、ログとデータベースを壊してしまいます。このような現象が発生するのは、rpc.nisd が手作業で起動された場合です。

「診断」

ps -ef | grep rpc.nisd を実行します。親の rpc.nisd プロセスは、1 つしか動作していないことを確認します。

「対策」

「親」としての rpc.nisd のエントリが複数ある場合は、1 つを残して、他のデーモンの動作を終了させなければなりません。kill -9 process-id を実行し、もう一度 ps コマンドを実行して、他のデーモンが終了したかどうか確認します。

注 –

-B オプションを指定して rpc.nisd を起動した場合は、rpc.nisd_resolv デーモンも終了させる必要があります。

NIS+ データベースが壊れている場合は、壊れていないデータベースを、最新のバックアップから復元します。次に、バックアップの時点よりあとで、名前空間に加えられた変更を反映します。しかし、ログも壊れている場合は、バックアップを行なったあとで名前空間に加えられた変更を、再度手作業で行わなければなりません。

rpc.nisd の失敗

NIS+ テーブルが大きすぎると、rpc.nisd は失敗します。

「診断」

nisls を使って、NIS+ テーブルの大きさをチェックします。7K バイト以上のテーブルでは、rpc.nisd は失敗します。

「対策」

NIS+ テーブルの大きさを小さくします。ネームサービスとして NIS+ は、オブジェクト自体ではなく、オブジェクトへのリファレンスを格納するために設計されています。

NIS+ と NIS の互換性の問題

この節では、NIS と NIS+ や以前のシステムとの間の互換性に関連する問題、またスイッチ構成ファイルに関連する問題を説明します。一般的な症状には次のようなものがあります。

表示されるエラーメッセージの中には、次のようなものがあります。

ユーザーがパスワードを変更したあと、ログインできない

「症状」

新しいユーザーや、最近パスワードを変更したユーザーが、ログインできません。または、特定のマシンからログインできますが、他のマシンからログインできません。そのようなユーザーに対して、次の表現が含まれているエラーメッセージが表示されることがあります。

「最初に考えられる原因」

NIS マシン上でパスワードが変更されました。

NIS+ の名前空間サーバーがサービスを提供しているドメインの中で、NIS を実行している Solaris オペレーティング環境のマシン上で、ユーザーまたはシステム管理者が passwd コマンドを使用してパスワードを変更した場合、そのユーザーのパスワードは、そのマシンの /etc/passwd ファイルの中だけで変更されています。そのユーザーが、ネットワーク上の他のマシンを使用してログインしても、そのマシン上では新しいパスワードは認識されません。NIS+ のパスワードテーブルに格納されている、古いパスワードを使用しなければなりません。

「診断」

そのユーザーの古いパスワードが、NIS+ の他のマシンでまだ有効かどうかチェックしてください。

「対策」

NIS+ を実行しているマシンで、passwd コマンドを使用して、ユーザーのパスワードを変更します。

「2 番目に考えられる原因」

パスワードの変更を行なっても、システム全体に反映されるまでに時間がかかります。

「診断」

名前空間の変更がドメインやシステム全体に反映されるまでに、ある程度の時間がかかります。ドメインのサイズや複製サーバーの台数により、数秒間で済むこともあれば、何十分もかかることがあります。

「対策」

変更結果がドメインに伝わるまで、常識的に受け入れられる程度の時間、待つだけです。または、nisping org_dir コマンドを使用して、システムを同期させることもできます。

nsswitch.conf ファイルが正しく実行されない

変更した (または、新しくインストールした) nsswitch.conf ファイルが正しく実行されません。

「症状」

新しい nsswitch.conf ファイルをインストールしたか、または既存のファイルを変更しましたが、システムがその変更結果を反映していません。

「考えられる原因」

nsswitch.conf ファイルのインストールや変更を行なった後は、必ずマシンを再起動して、変更結果を有効にしなければなりません。nscd が nsswitch.conf ファイルをキャッシュに書き込むためです。

「対策」

nsswitch.conf(4) のマニュアルページの情報を参照して、現在の nsswitch.conf ファイルをチェックしてください。必要に応じてファイルを修正し、マシンを再起動します。

NIS+ オブジェクトが見つからない問題

この節では、NIS+ がオブジェクトや主体を見つけることができない問題について説明します。一般的な症状には次のようなものがあります。

処理内容に関係する次の表現が含まれているエラーメッセージが表示されます。

構文やスペリングの誤り

NIS+ のオブジェクトが見つからない場合、最も可能性のある原因は、名前の入力を間違えたことです。構文をチェックし、正しい名前を使用しているかどうか確認してください。

正しくないパス名

「オブジェクト」が見つからない場合、考えられる原因として、正しくないパスを指定していることが挙げられます。指定したパスが正しいことを確認してください。また、NIS_PATH 環境変数が正しく設定されているかどうかも確認してください。

ドメインレベルが正しく指定されていない

すべてのサーバーは、それ自身がサービスを提供しているドメインではなく、その上にあるドメインのクライアントであることに注意してください。この規則には、2 つの例外があります。

オブジェクトが存在しない

NIS+ のオブジェクトが削除されたため、または作成されていないために、現在は存在していなくて、見つからないこともあります。nisls -l を使用して、そのドメインに目的のオブジェクトが存在するかどうかチェックしてください。

複製サーバーの同期遅延

NIS+ のオブジェクトの作成や変更を行うと、処理が完了して、特定の複製サーバーの情報が更新されるまでに、ある程度の遅れが発生します。通常の動作では、マスターかその複製から名前空間情報の照会が行われます。クライアントは、照会を複数のサーバー (マスターと複製) に自動的に分散し、システムの負荷のバランスを取ります。これは、どの時点でも、名前空間の情報をどのマシンが返してくるかわからないということを意味します。新しく作成されたオブジェクトや変更されたオブジェクトに関係するコマンドが、更新された情報をまだマスターから受け取っていない複製に送られた場合、「オブジェクトが見つかりません」というタイプのエラーか、同期していない古い情報を受け取ることになります。同様に、nisls のような、全体に関係するコマンドを使用して、まだ更新されていない複製サーバーに照会を行なった場合、新しく作成されたオブジェクトが含まれていないリストを受け取る可能性があります。

nisping を使用すると、同期していない状態にある複製サーバーを同期させることができます。

代わりに、NIS+ のコマンドで -M オプションを指定して、そのコマンドがドメインのマスターサーバーから名前空間の情報を受け取るように指定することも可能です。この方法を使用すると、確実に最新の情報を取得し、使用できます。ただし、-M オプションは、必要なときにだけ使用してください。複製サーバーを使用して名前空間のサービスを行う最大の理由は、負荷を分散して、ネットワークの効率を向上させることにあります。

ファイルが見つからないか壊れている

/var/nis/data ディレクトリの中の 1 つまたは複数のファイルが、壊れているか削除されています。最新のバックアップから、これらのファイルを復元してください。

旧バージョンの /var/nis について

Solaris 2.4 以前では、/var/nis ディレクトリに hostname.dict、hostname.log という 2 つのファイルが含まれていました。またサブディレクトリ /var/nis/hostname もありました。Solaris 2.5 においては、2 つのディレクトリ名は trans.log、data.dict、サブディレクトリ名は /var/nis/data となります。

nisinit など NIS+ 設定プロシージャーによって作成された /var/nis、/var/nis/data といったディレクトリ、およびその下のファイルは、名前を変更しないでください。

Solaris 2.5 ではこれらのファイルの内容も変更されており、Solaris 2.4 以前との互換性はなくなっています。したがって、これらのファイルやディレクトリを Solaris 2.4 での名前にしてしまうと、Solaris 2.4、および 2.5 以降の rpc.nisd で機能しなくなりますので名前の変更をしないようにしてください。ディレクトリ名もファイル名も変更しないでください。

名前の中の空白

「症状」

ある時にはオブジェクトが存在し、別の時には存在しないことがあります。NIS+ や UNIX の特定のコマンドが NIS+ のオブジェクトが存在しない、または見つからないと報告しますが、別のコマンドは同じオブジェクトを見つけることができます。

「診断」

nisls を使用して、オブジェクト名を探します。オブジェクト名を注意深くチェックして、その名前が実際は空白で始まっていないかどうか確認してください。NIS+ のコマンド行を使用して NIS+ のオブジェクトを作成するときに、フラグの後に誤って空白文字を 2 回入力すると、NIS+ のコマンドの中には、2 番目の空白文字をオブジェクト名の一部と解釈するものがあります。

「対策」

NIS+ のオブジェクト名が空白で始まっている場合は、名前を変更して空白を取り除くか、いったん削除して初めから作成し直します。

オートマウンタを使用できない問題

「症状」

他のホスト上のディレクトリに移動できません。

「考えられる原因」

NIS+ 環境では、NIS+ の必要条件に合わせて、オートマウンタの名前を変更しなければなりません。/etc/auto* テーブル名の一部としてピリオドが使用されている場合、NIS+ はそれらのテーブルをアクセスすることができません。たとえば、NIS+ は auto.direct というファイルにアクセスすることができません。

「診断」

nisls と niscat を使用して、オートマウンタのテーブル名が正しく割り当てられているかどうか確認します。

「対策」

ピリオドを下線 (_) に変更します。たとえば、auto.direct を auto_direct という名前に変更します。これらのテーブルを参照している可能性のある他のマップも変更してください。

テーブルエントリ間でのリンクが機能しない

nisln コマンド (またはその他のコマンド) を使って、テーブルエントリ間でのリンクは作成できません。NIS+ コマンドはエントリレベルでのリンクは追跡しません。

NIS+ の所有権とアクセス権の問題

この節では、ユーザーの所有権とアクセス権に関連する問題を説明します。一般的な症状には次のようなものがあります。

処理内容に関係する次の表現が含まれているエラーメッセージが表示されます。

一般的に観察されるその他の現象

アクセス権がない

アクセス権に関連して最も頻繁に発生する問題は、最も単純な問題です。行おうとしている業務に必要なアクセス権が、割り当てられていません。対象としているオブジェクトを指定して niscat -o を使用し、どのアクセス権が割り当てられているか確認します。他のアクセス権も必要な場合は、ユーザー自身、オブジェクトの所有者、システム管理者のうちの誰かが、そのオブジェクトのアクセス権の変更を行うことができます。詳細については、第 15 章「NIS+ のアクセス権の管理」 および 第 17 章「NIS+ グループの管理」を参照してください。

資格がない

ユーザーやマシンに適切な資格がない場合は、ほとんどの操作を行なったときにエラーが発生します。ホームドメインの cred テーブルを対象にして nismatch を使用し、正しい資格を割り当てられているかどうか確認します (資格に関連した問題の詳細は、無効になった資格を参照)。

サーバーがセキュリティレベル 0 で動作している

セキュリティレベル 0 で動作しているサーバーは、NIS+ の主体の資格の作成や管理を行いません。

セキュリティレベル 0 で動作しているサーバーで nispasswd を試みると、次のエラーメッセージが表示されます。「You name do not have secure RPC credentials in NIS+ domain domainname」

セキュリティレベル 0 は、管理者が名前空間の初期設定やテストを行う際にだけ使用されます。一般のユーザーがアクセスするような環境で使用すべきではありません。

ユーザーのログインがマシン名と同じ

マシン名と同じものを、ユーザーのログイン ID とすることはできません。ユーザー名と同じ名前をマシンに割り当てる (またはその逆) と、最初の主体は、セキュリティに関係するアクセス権を必要とする動作を行うことができなくなります。2 番目の主体の鍵が、cred テーブルの中にある、最初の主体の鍵を上書きするからです。さらに、2 番目の主体は、最初の主体に割り当てられていたアクセス権を持つようになります。

たとえば、saladin というログイン名を持つユーザーが、名前空間の中で読み込み専用のアクセス権を割り当てられていたとします。次に、saladin という名前を持つマシンをドメインに追加します。ユーザー saladin は、何らかの種類のアクセス権を必要とする名前空間の操作を行うことができなくなります。そして、マシン saladin のスーパーユーザーは、名前空間の中で、読み込み専用のアクセス権だけを割り当てられます。

「症状」

注 –

nisclient や nisaddcred を実行したときに、「Adding Key」ではなく「Changing Key」というメッセージが表示された場合は、そのドメインの中で、ユーザー名またはホスト名がすでに重複しています。

「診断」

nismatch を実行して、hosts テーブルや passwd テーブル内のホストとユーザーを表示し、各テーブルの中に、同じホスト名やユーザー名が存在しないか確認します。以下に例を示します。 


nismatch username passwd.org_dir

次に、ドメインの cred テーブルを対象にして nismatch を実行し、重複しているホスト名やユーザー名に、どのようなタイプの資格が割り当てられているかを調べます。LOCAL と DES 両方の資格が割り当てられている場合、cred テーブルのエントリはユーザーを表わしています。DES の資格だけが割り当てられている場合、エントリはマシンを表わしています。

「対策」

マシン名を変更します (ユーザー名を変更するより、マシン名を変更することをお勧めします)。次に、cred テーブルからそのマシンのエントリを削除し、nisclient を使用して、マシンを NIS+ のクライアントとして初期設定します (必要に応じて、nistbladm を使用し、そのマシンの別名を hosts テーブルの中に作成し、元のマシン名を別名として使用することもできます)。必要に応じて、cred テーブル内のユーザーの資格を変更します。

正しくない資格

無効になった資格を参照してください。

NIS+ のセキュリティの問題

この節では、パスワード、資格、暗号、その他セキュリティに関係した一般的な問題を取り上げます。

セキュリティ問題の症状

処理内容に関係する次の表現が含まれているエラーメッセージが表示されます。

ユーザーまたはスーパーユーザーは、名前空間に関係する作業を行うことができません (NIS+ の所有権とアクセス権の問題を参照)。

「Login Incorrect」というメッセージが表示された

原因としてもっとも多いのが、パスワードの誤入力です。もう一度入力するようユーザーに指示してください。「記憶しているパスワードが正しいか」、「パスワードでは大文字と小文字が区別されることを理解しているか」、「アルファベットの o と数字の 0、アルファベットの l と数字の 1 などを混同していないか」といったことについても確認してください。

「login incorrect」メッセージの原因としては他に以下のようなものが考えられます。

パスワードについては、第 16 章「パスワードの管理」を参照してください。

パスワードがロック状態、期限切れ、または無効である

「Permission denied, password expired」といったタイプのメッセージは、「ユーザーのパスワードが有効期限を過ぎた」、「またはパスワード使用権が無効になった」といった理由で表示されることが最も多くなっています。詳細については、第 16 章「パスワードの管理」を参照してください。

資格情報が古い

資格、アクセス権ともに正しいにもかかわらず、クライアントの要求が拒否されるという場合もあります。これは、名前空間のどこかに古い情報が存在することが原因である可能性があります。

資格情報の保存と更新

公開鍵など、資格に関する情報は、名前空間内の様々な場所に保存されています。NIS+ は、情報を格納しているオブジェクトの生存期間に応じてこの情報を定期的に更新しますが、場合によっては、更新の間に同期が失われることがあります。その結果、一部の操作が行えなくなります。表 24–2 は、資格に関する情報を保存するすべてのオブジェクト、テーブル、ファイルと、そのリセットの方法を示したものです。

表 24–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 コマンドを使用する。スーパーユーザー、一般ユーザーのどちらでログインしてもよい

passwd マップ

(NIS) 

ユーザーのパスワードまたはマシンのスーパーユーザーのパスワード 

passwd -r nisplus を使用する

古くなったキャッシュに保存された鍵の更新

情報が古くなる原因として最も多いのが、サーバーの公開鍵のバージョンが古くなることです。一般に、この問題を解決するには、アクセスするドメインに対して nisupdkeys を実行します (nisupdkeys コマンドの使用方法の詳細は、第 12 章「NIS+ 資格の管理」を参照)。

鍵の中にはファイルやキャッシュに保存されているものもあるため、nisupdkeys ですべての問題を解決できるわけではありません。鍵を手作業で更新しなければならない場合もあります。この場合は、「サーバーの公開鍵の内容は、公開鍵が作成された後どのように名前空間オブジェクトに伝えられるのか」ということについて理解する必要があります。サーバーの公開鍵の伝播には、一般に以下の 5 つの段階があります。それぞれの詳細について説明します。

1: サーバーの公開鍵が作成される

NIS+ サーバーはまず第 1 に、NIS+ クライアントです。つまり、NIS+ サーバーの公開鍵は、NIS+ クライアントの公開鍵と同様に、 nisaddcred コマンドによって生成されます。 公開鍵はその後、サーバーが実際にサポートするドメインではなく、サーバーのホームドメインの cred テーブルに保存されます。

2: 公開鍵の内容がディレクトリオブジェクトに伝えられる

NIS+ ドメインと NIS+ サーバーの設定後は、サーバーとドメインを関係づけることができます。この「関係づけ」は、nismkdir コマンドで行います。nismkdir コマンドによってサーバーとディレクトリの関係づけが行われる際、サーバーの公開鍵も cred テーブルからドメインのディレクトリオブジェクトにコピーされます。たとえば、サーバーが doc.com. ルートドメインのクライアントで、sales.doc.com. ドメインのマスターサーバーになっているという場合を考えてみましょう。

図 24–1 ディレクトリオブジェクトへの公開鍵の伝播

Graphic

公開鍵は 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 コマンドを使用して調べることができます。

複製サーバーがドメインに追加されるか、サーバーの鍵が更新されるまでは、鍵の伝播はこの段階にとどまります。

4: 複製サーバーがドメインに追加された場合の処理

複製サーバーがドメインに追加されると、nisping コマンド (nisping コマンド を参照) によって NIS+ テーブル (cred テーブルを含む) が新しい複製サーバーにダウンロードされます。これによって、元のサーバーの公開鍵も複製サーバーの cred テーブルに保存されます。

5: サーバーの公開鍵が更新された場合の処理

サーバーの DES 資格 (サーバーのルート ID) を変更すると、公開鍵も変更されます。その結果、サーバー用に cred テーブルに保存される公開鍵が、以下の場所に保存されるものと矛盾します。

サーバーの鍵は、ほとんどの場所において数分〜 12 時間で自動的に更新されます。すぐに更新するには、以下のコマンドを使用します。

表 24–3 サーバーの鍵の更新

保存場所 

コマンド名 

参照する項目 

複製サーバーの cred テーブル (nisping を使用しなくても、テーブルは数分で自動的に更新される)

nisping

nisping コマンド

サーバーがサポートするドメインのディレクトリオブジェクト  

nisupdkeys

nisupdkeys コマンド

クライアントの NIS_COLDSTART ファイル

nisinit -c

nisinit コマンド

クライアントの NIS_SHARED_DIRCACHE ファイル

nis_cachemgr

nis_cachemgr コマンド

注 –

nis_cachemgr の再起動は、既存の nis_cachemgr を終了してから行います。

無効になった資格

主体 (ユーザーかマシン) の資格が無効になっている場合は、その主体は nisls のようなコマンドも含め、名前空間の操作や処理を行うことができなくなってしまいます。資格が無効になると、未認証クラスに割り当てられるアクセス権も含め、すべてのアクセス権が失われるからです。

「症状」

ユーザーまたはスーパーユーザーが、名前空間に関係する作業を行うことができなくなります。名前空間のどのような操作を行なっても、「permission denied」というタイプのエラーメッセージが表示されます。ユーザーまたはスーパーユーザーは、nisls を実行することも不可能になります。

「考えられる原因」

鍵の破損、物理的な破損、古い資格、その他何らかの不適切な点が、/etc/.rootkey ファイルの中にあります。

「診断」

snoop を使用して、不適切な資格を識別します。

あるいは、その主体がリスト表示できる場合は、その主体としてログインを行い、主体が間違いなく承認されているはずのオブジェクトを対象として、NIS+ コマンドを実行します。たとえば、ほとんどの場合、未認証クラスにオブジェクトの読み込みは承認されているはずです。そこで、cred テーブルの中にリストされている主体は、nisls コマンドを正しく実行できるはずです。このコマンドを実行しても「permission denied」エラーが発生する場合は、おそらく、その主体の資格は無効になっています。

「対策」

Keyserv のエラー

keyserv が、セッションを暗号化できません。このタイプの問題には、いくつかの原因が考えられます。

「考えられる原因と対策」

マシンが以前は NIS+ のクライアントだった

このマシンが、同じドメインの中で NIS+ のクライアントとして初期設定されている場合は、試みに keylogin -r を実行し、Secure RPC パスワードプロンプトでスーパーユーザーのログインパスワードを入力します。

cred テーブルにエントリがない

cred テーブルの中に主体 (ユーザーまたはホスト) の NIS+ のパスワードが存在することを確認するために、主体のホームドメインの中で次のコマンドを実行します。


nisgrep -A cname=principal cred.org_dir.domainname

nisgrep を別のドメインで実行する場合は、domainname には完全な名前を指定する必要があります。

ドメイン名が変更されている

ドメイン名は変更すべきではありません。

既存のドメイン名を変更すると、認証の問題が発生するはずです。ネットワーク全体で、オブジェクトの中に完全指定のドメイン名が埋め込まれているからです。

ドメイン名を変更しないでください。既にドメイン名を変更してしまい、認証の問題や、ドメイン名に関係する「malformed」や「illegal」などの表現が含まれているメッセージが表示されている場合は、ドメイン名を元の名前に戻します。ドメイン名を変更したい場合は、次の手順に従ってください。「新しい名前」を使用して「新しいドメイン」を作成し、新しいドメインでマシンをサーバーやクライアントとして設定し、これらが正しく動作していることを確認した上で、古いドメインを削除します。

マシンを新しいドメインに変更する

NIS+ のクライアントとなっているマシンを、他のドメインのクライアントに変更したい場合は、/etc/.rootkey ファイルを削除し、ネットワーク管理者から受け取ったパスワードか nisclient スクリプトから取り出したパスワードを使用して、nispopulate スクリプトを実行し直します。

/etc/passwd ファイルの中にある NIS+ のパスワードとログインパスワード

NIS+ のパスワードは、NIS+ の passwd テーブルの中に格納されています。ログインパスワードは、NIS+ の passwd テーブルか、各ユーザーの /etc/passwd ファイルの中に格納されています。ユーザーパスワードと NIS+ のパスワードは、同じでも違っていてもかまいません。/etc/passwd ファイル内のパスワードを変更するには、nsswitch.conf ファイルでの設定を「files」にするか、「-r files」というフラグを指定するかして passwd コマンドを実行する必要があります。

nsswitch.conf ファイルは、どの目的にどのファイルを使用するか指定します。nsswitch.conf ファイルが、システムの照会に対して誤った場所を指示している場合は、パスワードやアクセス権のエラーが発生するはずです。

Secure RPC パスワードとログインパスワードが異なる

主体のログインパスワードと Secure RPC パスワードが一致しないと、ログイン時に keylogin はパスワードを復号化できません。keylogin はデフォルトで主体のログインパスワードを使用することになっていて、また非公開鍵は主体の Secure RPC パスワードを使用して暗号化されているからです。

この場合、主体はシステムにログインすることはできますが、NIS+ においては未認証クラスとして扱われます。キーサーバーが、そのユーザーの非公開鍵を復号化されていない状態のまま持っているからです。NIS+ 環境では多くの場合、未認承クラスによる NIS+ オブジェクトへのアクセス (作成、削除、変更) が拒否されるため、この状態でユーザーが NIS+ オブジェクトにアクセスしようとしても「permission denied」といったタイプのエラーになってしまいます。

注 –

「ネットワークパスワード」と「Secure RPC パスワード」は、このコンテキストでは同義語として扱われる場合があります。ネットワークパスワードの入力を求められたら Secure RPC パスワードを入力します。

認証クラスを「未認承」以外にするには、ユーザーがこの状況で keylogin プログラムを実行し、パスワード入力を求める keylogin プロンプトが表示されたときに主体の Secure RPC パスワードを入力する必要があります (キーログインを参照)。

しかし keylogin を実行しても、現在のログインセッション以外には無効で、一時的な解決にしかなりません。キーサーバーはこの方法によって、復号化された形でユーザーの非公開鍵を持つようになるのですが、ユーザーの cred テーブル中の非公開鍵が Secure RPC パスワード (ユーザーのログインパスワードとは異なっている) を使用して暗号化されているという点に変わりはないからです。ログインし直してしまえば、状況はまったく元どおりになってしまいます。根本的に問題を解決するためには、cred テーブルの非公開鍵を、Secure RPC パスワードではなくログイン ID に基づいたものに変更する必要があります。この作業は、chkey プログラムを使用して行います (NIS+ 主体の鍵の変更を参照)。

Secure RPC パスワードとログインパスワードが異なっているという問題を根本的に解決するには、具体的には以下の作業を行います。

  1. ログインパスワードを使用してログインします。

  2. keylogin プログラムを実行して、キーサーバーに保存される非公開鍵を一時的に復号し、一時的な NIS+ アクセス権を得ます。

  3. chkey -p 実行して、cred テーブル中の暗号化された非公開鍵を、ユーザーのログインパスワードに基づいたものに固定的に変更します。

/etc/.rootkey ファイルがすでに存在している

「症状」

「insufficient permission」や、「permission denied」などの、様々なエラーメッセージ

「考えられる原因」

サーバーやクライアントの設定や初期設定を行なったときに、/etc/.rootkey ファイルがすでに存在していました。以前そのマシンに NIS+ をインストールしたことがあり、NIS+ を削除したとき、または NIS や /etc への変更を行なったときに、.rootkey ファイルを削除しなかったためにこのような状態が起こります。

「診断」

/etc ディレクトリで ls -l と nisls -l org_dir を実行し、/etc/.rootkey の日付を、cred テーブルの日付と比較します。/etc/.rootkey の日付が明らかに cred テーブルより古い場合は、ファイルがあらかじめ存在していたことが考えられます。

「対策」

問題のあるマシンで、root として keylogin -r コマンドを実行し、そのマシンをもう一度クライアントとして設定し直します。

root のパスワードを変更したための問題

「症状」

マシンの root のパスワードを変更した結果、変更結果が反映されなかったか、スーパーユーザーとしてログインできなくなりました。

「考えられる原因」

注 –

セキュリティ上の理由から、passwd テーブルの中に、UserID 0 という項目を、設けるべきではありません。

ルートのパスワードを変更した際、ルートに対して chkey -p を実行していなかったり、何らかの問題が発生したことにより、変更が正しく行われませんでした。

「対策」

管理特権を持つユーザー (つまり、管理特権が割り当てられているグループに所属するメンバー) としてログインし、passwd を使用して、元のパスワードに戻します。元のパスワードが正しく機能するかどうか確かめてください。正しく機能すれば、passwd を使用してパスワードを変更した後、chkey -p を実行します。

注意 – 注意 –

NIS+ の名前空間の設定が終わり、すでに動作している状態でも、ルートマスターのマシンを使って root のパスワードを変更することは可能です。しかし、ルートマスターの鍵は変更しないでください。これらは、サブドメイン内のすべてのクライアント、複製サーバー、サーバーの中のすべてのディレクトリオブジェクトに埋め込まれているからです。chkey をルートで実行する際、必ず -p オプションを指定するようにすれば、ルートマスターの鍵を変更する必要はなくなります。

NIS+ の性能の低下とシステムのハングアップの問題

この節では、性能の低下とシステムのハングアップの問題を取り上げます。

性能の低下の症状

処理内容に関係する次の表現が含まれているエラーメッセージが表示されます。

次の一般的な現象が観察されることもあります。

チェックポイントの実行

誰かが nisping か nisping -C どちらかのコマンドを実行しました。または、rpc.nisd デーモンが、チェックポイントを実行しています。

注意 – 注意 –

再起動しないでください。nisping を実行しないでください。

nisping やチェックポイントを実行すると、サーバーは反応が遅くなったり、他のコマンドにすぐに応答しなくなったりすることがあります。名前空間のサイズに応じて、このようなコマンドが完了するまでに、かなりの時間を要します。これらのコマンドの実行中に、誰かが同様のコマンドを実行すると、所要時間は何倍にもなります。再起動も行わないでください。この種の問題は自然に解決します。サーバーが nisping やチェックポイントの実行を完了するまで待つだけです。

マスターサーバーと複製サーバーの同期が完全に行われている場合、同期が完了するまで、複製サーバーはサービスを停止します。再起動しないで待機してください。

変数 NIS_PATH

NIS_PATH 変数が、明快かつ単純な値に設定されているかどうか確認します。たとえば、デフォルトでは org_dir.$:$ に設定されています。 複雑な NIS_PATH、特に他の変数を含んでいる変数は、システムの速度を低下させ、特定の操作にエラーを引き起こす可能性があります (詳細は、環境変数 NIS_PATH を参照)。

デフォルト以外のテーブルパスを指定するために nistbladm を使用することは避けてください。デフォルト以外のテーブルパスを指定すると、性能は低下します。

テーブルパス

テーブルパスは使用しないでください。性能を低下させることになります。

複製サーバーが多すぎる

1 つのドメインの中に複製サーバーが多すぎる場合は、複製作業を行なっている間はシステムの性能が低下します。1 つのドメインまたはサブドメインの中に、10 台より多くの複製サーバーを置くことは避けてください。ドメインの中の複製サーバーが 5 台より多い場合は、何台かを取り除いて性能が改善されるかどうか調べます。

再帰的なグループ

再帰的なグループとは、他のグループを包含するグループのことです。グループの中に他のグループを含めると、システム管理者として行う作業は減少しますが、システムの速度は低下します。再帰的なグループを使うべきではありません。

起動時の NIS+ データベースのログが大きい

rpc.nisd は、起動時に各ログを参照します。ログが大きい場合は、起動時の参照に時間がかかることがあります。rpc.nisd を起動する前に、nisping -C を使用して、チェックポイントを実行することをお勧めします。

マスターの rpc.nisd デーモンが終了している

「症状」

-M オプションを指定して要求をマスターサーバーに送ったときに、マスターのマシンで rpc.nisd デーモンが終了していると、「server not responding」タイプのエラーメッセージが発生し、更新を行うことは認められません。-M オプションを指定しなかったときは、要求は機能している複製サーバーに自動的に転送されます。

「考えられる原因」

ホームディレクトリ名やホスト名の一部として大文字を使うと、rpc.nisd デーモンが終了することがあります。

「診断」

最初に、サーバー自体が起動されて、動作しているかどうか確認します。動作している場合は、ps -ef | grep rpc.nisd を実行し、デーモンが動作しているかどうか調べます。

「対策」

デーモンが終了している場合は、起動し直します。たびたびデーモンが終了する場合は、ご購入先にご連絡ください。

nis_cachemgr がない

「症状」

あるマシンが他のドメインにある名前空間オブジェクトを探すのに、非常に長い時間がかかっています。

「考えられる原因」

nis_cachemgr を実行していません。

「診断」

ps -ef | grep nis_cachemgr を実行して、nis_cachemgr が動作しているかどうか確認します。

「対策」

そのマシンで、nis_cachemgr を起動します。

NIS+ のインストール後、サーバーの起動が非常に遅い

「症状」

NIS+ のスクリプトを使用して NIS+ をインストールした後、サーバーの動作が非常に遅く、緩慢です。

「考えられる原因」

nispopulate スクリプトを動作させた後、nisping -C -a を実行していません。

「対策」

nisping -C -a を実行して、できるだけ早くチェックポイントを実行します。

niscat が エラーメッセージ「Server busy. Try Again」を返す

「症状」

niscat を実行すると、サーバーがビジーであるというエラーメッセージが表示されます。

「考えられる原因」

「診断」

swap -s を実行して、サーバーのスワップ空間をチェックします。

「対策」

NIS+ を実行するには、適度のスワップ空間とディスク容量を用意すべきです。必要に応じて、空間を増やします。

ホスト名を変更した後で、NIS+ の照会がハングする

「症状」

NIS+ サーバーのホスト名を完全指定することは、推奨されていません。このような指定を行なった後、NIS+ の照会を実行すると、エラーメッセージを表示することなくハングアップが発生しました。次の可能性をチェックします。

「考えられる原因」

完全指定のホスト名は、次の条件を満たしていなければなりません。

「対策」

ハングアップした NIS+ プロセスを終了させ、ホストやサーバーの rpc.nisd も終了させます。上の 2 つの条件に合わせて、ホスト名を変更します。nisinit を使用してサーバーを初期設定します。ホスト名が正しいことを確認した後もハングアップが発生する場合は、この節の他の考えられる原因をチェックしてください。

NIS+ のシステムリソースの問題

この節では、メモリーやディスク容量のようなシステムリソースが不足したときの問題を取り上げます。

リソースの問題

処理内容に関係する次の表現が含まれているエラーメッセージが表示されます。

メモリーの不足

システムのメモリーやスワップ空間が不足すると、NIS+ の様々な問題やエラーメッセージに遭遇します。一時的な解決策として、不必要なウィンドウやプロセスを終了させることが考えられます。必要に応じて、ウィンドウシステムを終了し、端末のコマンド行を使用します。それでもメモリー不足を知らせるメッセージが表示されるときは、スワップ空間やメモリーを追加するか、十分なスワップ空間やメモリーを持つシステムに切り替えます。

特定の状況では、アプリケーションやプロセスがメモリーを無駄に消費し、使用メモリーサイズが極端に大きくなることがあります。次のコマンドを実行すると、アプリケーションやプロセスの現在のサイズを知ることができます。


ps -el

sz (サイズ) の列には、各プロセスの現在のメモリーサイズが表示されています。必要に応じて、サイズが同程度と思われるアプリケーションやプロセスを比較し、メモリーサイズが極端に大きいものが存在しないかどうか調べます。

ディスク容量の不足

ディスク容量が不足すると、様々なエラーメッセージが表示されます。ディスク領域の不足に共通する原因は、定期的に行われている tmp ファイルの削除やログファイルの切り捨てをしていないことです。切り捨てを行わないと、ログファイルと tmp ファイルは常時増加します。これらのファイルの増大速度はシステムごとに異なり、同じシステムでも状態によって変化します。非効率的なシステムや、名前空間に問題を抱えているシステムでは、ログファイルは非常に急速に増大します。

注 –

多くの問題が発生しているときは、ログファイルと /tmp のファイルを頻繁にチェックします。ディスク容量が不足して他の問題が発生する前に、ログファイルを切り捨て、/tmp ファイルを削除します。また、ルートディレクトリとホームディレクトリで core ファイルを探して削除します。

ログファイルを切り捨てるには、システムのチェックポイントを設けます。チェックポイントのプロセスがある程度の時間を要し、完了するまではシステムの速度を低下させることに注意してください。

システムのチェックポイントを実行するには、nisping -C を実行します。

プロセス数の不足

過度に負荷の大きいマシンでは、マシンの構成の中で指定されている、同時に実行できる最大のプロセス数に達する可能性があります。この結果、「unable to fork」のようなメッセージが表示されます。この問題を解決するために推奨されている方法は、不必要なプロセスを終了させることです。それでも問題が持続する場合は、システムの管理マニュアルの説明に従って、より多くのプロセスを扱えるようにシステムを構成し直してください。

NIS+ のユーザーの問題

この節では、一般ユーザーが遭遇する NIS+ の問題を取り上げます。

ユーザーの問題

ユーザーがログインできない

ユーザーがログインできない原因としては、以下のように様々なものが考えられます。

ユーザーが新しいパスワードを使ったときにログインできない

「症状」

最近パスワードを変更したユーザーが、ログインできません。または、特定のマシンからログインできますが、他のマシンからログインできません。

「考えられる原因」

ユーザーがリモートドメインにログインできない

「症状」

ユーザーが rlogin を使用して、他のドメインへのログインを試みましたが、「Permission denied」メッセージが表示されて、拒絶されました。

「考えられる原因」

他のドメインにリモートログイン (rlogin) するには、ユーザーはそのドメインで LOCAL の資格を持っていなければなりません。

「診断」

そのドメインで、nismatch username. domainname. cred.org_dir を実行し、LOCAL の資格を持っているかどうか調べます。

「対策」

リモートドメインから nisaddcred を使用し、そのドメインでの LOCAL の資格をユーザーに割り当てます。

ユーザーがパスワードを変更できない

原因として最も多いのが、古いパスワードの入力を間違えた (または忘れた) ということです。

他には以下のような原因が考えられます。

NIS+ に関するその他の問題

この節では、上記の問題に当てはまらない問題を取り上げます。

NIS+ の動作

特定のホストが NIS+ を実行しているかどうか知りたい場合があります。NIS+ が動作しているか知るには、スクリプトが必要です。

次のどれかに一致する場合は、NIS+ が動作していると考えられます。

複製サーバーの更新のエラー

「症状」

更新が成功しなかったことを示すエラーメッセージが表示されます。次のメッセージが更新の成功を示すことに注意してください。「replica_update:number updates number errors」

「考えられる原因」

次のエラーメッセージのどれかが表示された場合、サーバーがビジーであり、更新を延期すべきことがわかります。

これらのメッセージは、NIS+ のエラーコード定数 NIS_DUMPLATER (ある複製がすでに再同期を実行している) によって、または同時に生成されます。

次のメッセージは、他の問題が起こっていることを示します。

-C (診断チャンネルのオープン) オプションを指定した rpc.nisd が動作している場合は、マスターサーバーか複製サーバーのシステムログに、詳細な情報が記録されることもあります。

これらのメッセージは、次のような潜在的な問題が起こっていることを示しています。

「診断」

複製サーバーとマスターサーバー両方のシステムログから、詳細な情報を探します。情報が記録されている場合でも、詳細の程度は、システムのエラー報告レベルと、-C オプション (診断) を指定して rpc.nisd を実行したかどうかによって異なります。

「対策」

ほとんどの場合、これらのメッセージは、システムが修正することのできる、ソフトウェアの小さな問題が発生したことを意味しています。あるコマンドを実行した結果、これらのメッセージが表示された場合は、しばらく待って、もう一度同じコマンドを実行します。これらのメッセージが頻繁に表示される場合は、/etc/syslog.conf ファイル内のしきい値レベルを変更します。詳細は、syslog.conf のマニュアルページを参照してください。