この章では、Solaris 8 リリースの名前空間を管理する際に発生する可能性のある問題のいくつかを説明します。
この章は問題のタイプで分類されています。各問題には、一般的な現象、問題の説明、および対策が示されています。この章の他に、NIS+ のさらに一般的なエラーメッセージをアルファベット順に表示した付録があります。エラーメッセージが特定できていれば、最初に付録 B 「エラーメッセージ」 を参照してください。問題が簡単か、または 1 つのエラーメッセージに特定できる場合には、その対策は付録 B 「エラーメッセージ」 に掲載されています。
NIS_OPTIONS
の環境変数を設定して、NIS+ デバッグオプションを制御できます。
オプションは、二重引用符で囲まれたオプションセットと共にスペースで区切られた NIS_OPTIONS
コマンドの後に指定されます。各オプションに name=value のフォーマットがあります。値は、特定のオプションに従って整数、文字列、ファイル名になります。整数値のオプションに対して、値が指定されていない場合には、デフォルト値は 1 になります。
NIS_OPTIONS
は次のオプションを認識します。
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 コマンドによって生成されるのと同じフォーマットで、優先サーバーを指定する (表 15-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" |
特定のサーバーに送られた API コールの簡単なリストを得るには、以下を入力します。
setenv NIS_OPTIONS "debug_calls server = sirius" |
この節では、日常的な NIS+ 名前空間の管理作業を行なっているときに発生する可能性のある問題について説明します。一般的な症状には次のようなものがあります。
「Illegal object type for operation」メッセージ
その他の「オブジェクトの問題」のエラーメッセージ
初期設定のエラー
チェックポイントのエラー
ユーザーをグループに追加するときのエラー
ログが大きすぎる場合、ディスク容量が不足した場合、ログの切り捨てのエラー
groups_dir や org_dir が削除できない
「症状」
このエラーメッセージには、いくつもの原因が考えられます。
データベース処理が DB_BADOBJECT の状態を返しました (db(3N) のエラーコードの詳細は、nis_db(3N) のマニュアルページを参照してください)。
長さを 0 に指定して、データベースオブジェクトを追加または変更しようとしました。
所有者を指定せずに、オブジェクトを追加しようとしました。
その処理はディレクトリオブジェクトを想定していますが、指定したオブジェクトは、ディレクトリオブジェクトではありませんでした。
ディレクトリを LINK オブジェクトにリンクしようとしました。
テーブルエントリにリンクしようとしました。
グループオブジェクトの処理が想定されていましたが、指定したオブジェクトのタイプはグループオブジェクトではありませんでした。
テーブルオブジェクトの処理が想定されていましたが、指定したオブジェクトはテーブルオブジェクトではありませんでした。
次の点をチェックしてください。
NIS+ が動作していることを、ping によって確認できるか
-H オプションで指定した NIS+ サーバーが、適切なサーバーであるか、また現在も動作しているか
rpc.nisd がサーバー上で動作しているか
その他クラスが、このドメインの読み取り権を持っているか
このマシンで、ネットマスクが正しく設定されているか
チェックポイント処理 (たとえば、nisping -C コマンドによる操作) が、継続してエラーを起こしている場合は、十分なスワップ空間やディスク容量があるかどうか確認してください。syslog 内のエラーメッセージもチェックします。core ファイルがディスク空間を使い果たしていないかどうかチェックします。
ユーザーをそのドメイン内のグループのメンバーとして追加する前に、そのユーザーは、ドメインの cred テーブルの中で LOCAL の資格を持つ NIS+ 主体クライアントになっていなければなりません。DES の資格を持っているだけでは、十分ではありません。
nisping -C を使用して定期的にチェックポイントを実行していないと、ログファイルが極端に大きくなることがあります。マスターサーバーのすべての複製サーバーが更新されるまでは、マスター上にあるログはクリアされません。複製がダウンしている場合や、サービスが行われていない場合、複製サーバーと通信できない場合は、その複製サーバーに対応するマスターをクリアできません。このため複製がダウンしているか、または一定時間使用できない場合には、「ディレクトリを削除する」で説明するとおり、マスターから複製を削除する必要があります。ディレクトリ org_dir とサブディレクトリ groups_dir を最初に削除してから、ディレクトリ自体を削除してください。
十分なディスク容量が確保できない場合は、様々なエラーメッセージが表示されます (詳細は、「ディスク容量の不足」を参照)。
まずはじめに、問題のファイルが存在するか、読み込み可能か、そのファイルに書き込み権が割り当てられているかどうかチェックしてください。
トランザクションログは、ls /var/nis/trans.log で表示できます。
ファイルの存在、アクセス権、読み取り権については、nisls -l と niscat で確認できます。
関係するメッセージは、syslog でチェックできます。
最も可能性のある原因は、適切なアクセス権を割り当てられているものの、ディスク容量が不足していることです。チェックポイント処理では、ログを切り捨て一時ファイルを削除する前に、ますログ一時ファイルのコピーを作成します。このため、一時ファイルを作成するためのディスク容量がない場合は、チェックポイント処理を進めることができません。使用可能なディスク容量をチェックし、必要であれば容量を確保してください。
NIS+ の多くのコマンドや操作にとって、ドメイン名は重要な役割を果たします。ルートサーバーを除いて、NIS+ のすべてのマスターと複製は、それ自身がサービスを提供するドメインより上にあるドメインのクライアントであるということに特に注意してください。サーバーまたは複製サーバーを、それ自身がサービスを提供するドメインのクライアントとして誤って扱った場合、「Generic system error」や「Possible loop detected in namespace directoryname:domainname」というエラーメッセージが表示されます。
たとえば、altair というマシンが、subdoc.doc.com. ドメインのクライアントだとします。サブドメイン subdoc.doc.com. のマスターサーバーが sirius というマシンだとすると、sirius は doc.com. ドメインのクライアントになります。したがって、ドメインの指定や変更を行うときは、混同しないように次のルールに注意してください。
クライアントマシンは、特定のドメインかサブドメインに所属します。
特定のサブドメインにサービスを提供するサーバーや複製サーバーは、そのドメインより上にあるサブドメインのクライアントです。
2 の規則の唯一の例外は、ルートマスターサーバーとルート複製サーバーです。これらは、それ自身がサービスを提供するドメインのクライアントになります。つまり、ルートドメインのクライアントになるのは、ルートマスターとルート複製だけです。
したがって、上の例では、マシン altair の完全指定名は、altair.subdoc.doc.com. です。マシン sirius の完全指定名は、sirius.doc.com. です。sirius は doc.com. のクライアントであり、subdoc.doc.com. のクライアントではないので、sirius.subdoc.doc.com. は間違いであり、エラーになります。
親ディレクトリを削除する前に、必ず org_dir と groups_dir を削除してください。ドメインの groups_dir と org_dir を削除する前に、nisrmdir を使用してドメインを削除すると、これらの 2 つのサブディレクトリは、どちらも削除できなくなります。
複製サーバーからディレクトリを削除または分離する場合には、最初にディレクトリの org_dir と groups_dir のサブディレクトリを削除してから、ディレクトリ自体を削除します。各サブディレクトリが削除された後に、削除しようとするディレクトリの親ディレクトリで nisping を実行する必要があります (「ディレクトリを削除する」を参照)。
nisping の操作に失敗すると、ディレクトリは完全に削除または分離されません。
この状態が発生したら、次の手順を実行して、修正する必要があります。
複製上の /var/nis/rep/serving_list で org_dir.domain が表示されないことを確認してください。
domain で nisping を実行します。
マスターサーバーから 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 デーモンを実行させています。通常の動作では、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+ データベースが壊れている場合は、壊れていないデータベースを、最新のバックアップから復元します。次に、バックアップの時点よりあとで、名前空間に加えられた変更を反映します。しかし、ログも壊れている場合は、バックアップを行なったあとで名前空間に加えられた変更を、再度手作業で行わなければなりません。
NIS+ テーブルが大きすぎると、rpc.nisd は失敗します。
「診断」
nisls を使って、NIS+ テーブルの大きさをチェックします。7K バイト以上のテーブルでは、rpc.nisd は失敗します。
「対策」
NIS+ テーブルの大きさを小さくします。ネームサービスとして NIS+ は、オブジェクト自体ではなく、オブジェクトへのリファレンスを格納するために設計されています。
この節では、NIS と NIS+ や以前のシステムとの間の互換性に関連する問題、またスイッチ構成ファイルに関連する問題を説明します。一般的な症状には次のようなものがあります。
「症状」
新しいユーザーや、最近パスワードを変更したユーザーが、ログインできません。または、特定のマシンからログインできますが、他のマシンからログインできません。そのようなユーザーに対して、次の表現が含まれているエラーメッセージが表示されることがあります。
「最初に考えられる原因」
NIS マシン上でパスワードが変更されました。
NIS+ の名前空間サーバーがサービスを提供しているドメインの中で、NIS を実行している Solaris 8 リリース のマシン上で、ユーザーまたはシステム管理者が passwd コマンドを使用してパスワードを変更した場合、そのユーザーのパスワードは、そのマシンの /etc/passwd ファイルの中だけで変更されています。そのユーザーが、ネットワーク上の他のマシンを使用してログインしても、そのマシン上では新しいパスワードは認識されません。NIS+ のパスワードテーブルに格納されている、古いパスワードを使用しなければなりません。
「診断」
そのユーザーの古いパスワードが、NIS+ の他のマシンでまだ有効かどうかチェックしてください。
「対策」
NIS+ を実行しているマシンで、passwd コマンドを使用して、ユーザーのパスワードを変更します。
「2 番目に考えられる原因」
パスワードの変更を行なっても、システム全体に反映されるまでに時間がかかります。
「診断」
名前空間の変更がドメインやシステム全体に反映されるまでに、ある程度の時間がかかります。ドメインのサイズや複製サーバーの台数により、数秒間で済むこともあれば、何十分もかかることがあります。
「対策」
変更結果がドメインに伝わるまで、常識的に受け入れられる程度の時間、待つだけです。または、nisping org_dir コマンドを使用して、システムを同期させることもできます。
変更した (または、新しくインストールした) nsswitch.conf ファイルが正しく実行されません。
「症状」
新しい nsswitch.conf ファイルをインストールしたか、または既存のファイルを変更しましたが、システムがその変更結果を反映していません。
「考えられる原因」
nsswitch.conf ファイルのインストールや変更を行なった後は、必ずマシンを再起動して、変更結果を有効にしなければなりません。nscd が nsswitch.conf ファイルをキャッシュに書き込むためです。
「対策」
nsswitch.conf(4) のマニュアルページの情報を参照して、現在の nsswitch.conf ファイルをチェックしてください。必要に応じてファイルを修正し、マシンを再起動します。
この節では、NIS+ がオブジェクトや主体を見つけることができない問題について説明します。一般的な症状には次のようなものがあります。
処理内容に関係する次の表現が含まれているエラーメッセージが表示されます。
NIS+ のオブジェクトが見つからない場合、最も可能性のある原因は、名前の入力を間違えたことです。構文をチェックし、正しい名前を使用しているかどうか確認してください。
「オブジェクト」が見つからない場合、考えられる原因として、正しくないパスを指定していることが挙げられます。また、NIS_PATH 環境変数が正しく設定されているかどうかも確認してください。
すべてのサーバーは、それ自身がサービスを提供しているドメインではなく、その上にあるドメインのクライアントであることに注意してください。この規則には、2 つの例外があります。
ルートマスターサーバーとルート複製サーバーは、ルートドメインのクライアントです。
NIS+ のドメイン名は、ピリオドで終わります。完全指定名を使用する場合は、ドメイン名の終わりにピリオドをつけなければなりません。ドメイン名の終わりにピリオドをつけないと、NIS+ は、それが部分指定名であると想定します。この規則の例外としては、/etc/defaultdomain ファイルの中では、マシンのドメイン名の終わりにピリオドをつけません。/etc/defaultdomain ファイルの中で、マシンのドメイン名にピリオドをつけると、起動時に「Could not bind to server serving domain name」というエラーメッセージが表示され、ネットワークへの接続に問題が生じます。
NIS+ のオブジェクトが削除されたため、または作成されていないために、現在は存在していなくて、見つからないこともあります。nisls -l を使用して、そのドメインに目的のオブジェクトが存在するかどうかチェックしてください。
NIS+ のオブジェクトの作成や変更を行うと、処理が完了して、特定の複製サーバーの情報が更新されるまでに、ある程度の遅れが発生します。通常の動作では、マスターかその複製から名前空間情報の照会が行われます。クライアントは、照会を複数のサーバー (マスターと複製) に自動的に分散し、システムの負荷のバランスを取ります。これは、どの時点でも、名前空間の情報をどのマシンが返してくるかわからないということを意味します。新しく作成されたオブジェクトや変更されたオブジェクトに関係するコマンドが、更新された情報をまだマスターから受け取っていない複製に送られた場合、「オブジェクトが見つかりません」というタイプのエラーか、同期していない古い情報を受け取ることになります。同様に、nisls のような、全体に関係するコマンドを使用して、まだ更新されていない複製サーバーに照会を行なった場合、新しく作成されたオブジェクトが含まれていないリストを受け取る可能性があります。
nisping を使用すると、同期していない状態にある複製サーバーを同期させることができます。
代わりに、NIS+ のコマンドで -M オプションを指定して、そのコマンドがドメインのマスターサーバーから名前空間の情報を受け取るように指定することも可能です。この方法を使用すると、確実に最新の情報を取得し、使用できます。ただし、-M オプションは、必要なときにだけ使用してください。複製サーバーを使用して名前空間のサービスを行う最大の理由は、負荷を分散して、ネットワークの効率を向上させることにあります。
/var/nis/data ディレクトリの中の 1 つまたは複数のファイルが、壊れているか削除されています。最新のバックアップから、これらのファイルを復元してください。
Solaris 2.4 以前では、/var/nis ディレクトリに hostname.dict、hostname.log という 2 つのファイルが含まれていました。またサブディレクトリ /var/nis/ hostname もありました。Solaris 2.5 においては、2 つのディレクトリ名は trans.log、data.dict、サブディレクトリ名は /var/nis/data となります。
/var/nis、/var/nis/data といったディレクトリや、その中のファイルは、nisinit などの NIS+ 設定プロシージャーによって作成されますが、名前の変更をしないようにしてください。
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+ コマンドはエントリレベルでのリンクは追跡しません。
この節では、ユーザーの所有権とアクセス権に関連する問題を説明します。
処理内容に関係する次の表現が含まれているエラーメッセージが表示されます。
Unable to stat NIS+ directory name
一般的に観察されるその他の現象
ユーザーまたはスーパーユーザーが、名前空間に関係する作業を行うことができない
アクセス権に関連して最も頻繁に発生する問題は、最も単純な問題です。行おうとしている業務に必要なアクセス権が、割り当てられていません。対象としているオブジェクトを指定して niscat -o を使用し、どのアクセス権が割り当てられているか確認します。他のアクセス権も必要な場合は、ユーザー自身、オブジェクトの所有者、システム管理者のうちの誰かが、そのオブジェクトのアクセス権の変更を行うことができます。詳細は、第 10 章「NIS+ のアクセス権の管理」と、第 12 章「NIS+ グループの管理」を参照してください。
ユーザーやマシンに適切な資格がない場合は、ほとんどの操作を行なったときにエラーが発生します。ホームドメインの cred テーブルを対象にして nismatch を使用し、正しい資格を割り当てられているかどうか確認します (資格に関連した問題の詳細は、「無効になった資格」を参照)。
セキュリティレベル 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 のスーパーユーザーは、名前空間の中で、読み込み専用のアクセス権だけを割り当てられます。
「症状」
ユーザーまたはスーパーユーザーが、keylogin を正しく実行できなくなります。
「Security exception on LOCAL system. UNABLE TO MAKE REQUEST.」エラーメッセージが表示されます。
最初の主体が読み込みアクセスを割り当てられていない場合、2 番目の主体が、本来表示できるはずのオブジェクトを見ることができなくなります。
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 テーブル内のユーザーの資格を変更します。
「無効になった資格」を参照してください。
この節では、パスワード、資格、暗号、その他セキュリティに関係した一般的な問題を取り上げます。
処理内容に関係する次の表現が含まれているエラーメッセージが表示されます。
Password [problems]
ユーザーまたはスーパーユーザーは、名前空間に関係する作業を行うことができません (「NIS+ の所有権とアクセス権の問題」を参照)。
原因としてもっとも多いのが、パスワードの誤入力です。もう一度入力するようユーザーに指示してください。「記憶しているパスワードが正しいか」、「パスワードでは大文字と小文字が区別されることを理解しているか」、「アルファベットの o と数字の 0、アルファベットの l と数字の 1 などを混同していないか」といったことについても確認してください。
「login incorrect」メッセージの原因としては他に以下のようなものが考えられます。
パスワードが管理者によってロックされている (「パスワードのロック」、「パスワードロックの解除」を参照)。
指定の日数以上ログインが行われなかったため、パスワードがロックされた (「ログインの間隔の最大値の指定」を参照)。
パスワードが有効期限を過ぎた (「パスワード使用権の有効期限」を参照)。
パスワードについては、第 11 章「パスワードの管理」を参照してください。
「Permission denied, password expired」といったタイプのメッセージは、「ユーザーのパスワードが有効期限を過ぎた」、「またはパスワード使用権が無効になった」といった理由で表示されることが最も多くなっています。詳細は第 11 章「パスワードの管理」を参照してください。
資格、アクセス権ともに正しいにもかかわらず、クライアントの要求が拒否されるという場合もあります。これはおそらく、名前空間のどこかに古い情報が存在することが原因です。
公開鍵など、資格に関する情報は、名前空間内の様々な場所に保存されています。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 コマンドを使用する。スーパーユーザー、一般ユーザーのどちらでログインしてもよい |
passwd マップ (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 コマンドを使用して調べることができます。
複製サーバーがドメインに追加されるか、サーバーの鍵が更新されるまでは、鍵の伝播はこの段階にとどまります。
4:複製サーバーがドメインに追加された場合の処理
複製サーバーがドメインに追加されると、nisping コマンドによって NIS+ テーブル (cred テーブルを含む) が新しい複製サーバーにダウンロードされます。これによって、元のサーバーの公開鍵も複製サーバーの 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 を終了してから行います。
主体 (ユーザーかマシン) の資格が無効になっている場合は、その主体は nisls のようなコマンドも含め、名前空間の操作や処理を行うことができなくなってしまいます。資格が無効になると、未認証クラスに割り当てられるアクセス権も含め、すべてのアクセス権が失われるからです。
「症状」
ユーザーまたはスーパーユーザーが、名前空間に関係する作業を行うことができなくなります。名前空間のどのような操作を行なっても、「permission denied」というタイプのエラーメッセージが表示されます。ユーザーまたはスーパーユーザーは、nisls を実行することも不可能になります。
「考えられる原因」
鍵の破損、物理的な破損、古い資格、その他何らかの不適切な点が、/etc/.rootkey ファイルの中にあります。
「診断」
または、その主体がリスト表示できる場合は、その主体としてログインを行い、主体が間違いなく承認されているはずのオブジェクトを対象として、NIS+ コマンドを実行します。たとえば、ほとんどの場合、未認証クラスにオブジェクトの読み込みは承認されているはずです。そこで、cred テーブルの中にリストされている主体は、nisls コマンドを正しく実行できるはずです。このコマンドを実行しても「permission denied」エラーが発生する場合は、おそらく、その主体の資格は無効になっています。
「対策」
「一般のユーザー」の場合、keylogout を実行してから、次に keylogin を実行して、その主体のログインを試みます。
「root」すなわち「スーパーユーザー」の場合、keylogout -f を実行してから、次に keylogin -r を実行します。
keyserv が、セッションを暗号化できません。このタイプの問題には、いくつかの原因が考えられます。
「考えられる原因と対策」
クライアントが keylogin を実行していません。keylogin を実行したかどうか確認します。クライアントが正しく keylogin を実行したかどうかを確かめるには、(そのクライアントで) nisdefaults -v を実行します。Principal Name という行に「not authenticated」というメッセージが返れば、クライアントが正しく keylogin を実行していないことになります。
クライアント (またはホスト) が、LOCAL や DES のような適切な資格を持っていません。クライアントの cred テーブルを対象にして niscat を実行し、クライアントが適切な資格を持っているかどうか確認します。必要に応じて、「NIS+ 主体の資格情報を作成する方法」に従って資格を追加します。
keyserv デーモンが動作していません。ps コマンドを使用して、keyserv が動作しているかどうか確認します。動作していない場合は、このデーモンを起動してから、keylogin を実行します。
keyserv が動作している場合は、Secure RPC や NIS+ のコールを行う終始動作しているはずのプロセスが、まだ動作していません。たとえば、automountd、rpc.nisd、sendmail などが動作していません。これらのプロセスが正しく動作しているかどうか確認します。動作していない場合は再起動します。
このマシンが、同じドメインの中で NIS+ のクライアントとして初期設定されている場合は、試みに keylogin -r を実行し、Secure RPC パスワードプロンプトでスーパーユーザーのログインパスワードを入力します。
cred テーブルの中に主体 (ユーザーまたはホスト) の NIS+ のパスワードが存在することを確認するために、主体のホームドメインの中で次のコマンドを実行します。
nisgrep -A cname=principal cred.org_dir. domainname |
nisgrep を別のドメインで実行する場合は、domainname には完全な名前を指定する必要があります。
ドメイン名は変更すべきではありません。
既存のドメイン名を変更すると、認証の問題が発生するはずです。ネットワーク全体で、オブジェクトの中に完全指定のドメイン名が埋め込まれているからです。ドメイン名を変更しないでください。
既にドメイン名を変更してしまい、認証の問題や、ドメイン名に関係する「malformed」や「illegal」などの表現が含まれているメッセージが表示されている場合は、ドメイン名を元の名前に戻します。ドメイン名を変更したい場合は、次の手順に従ってください。「新しい名前」を使用して「新しいドメイン」を作成し、新しいドメインでマシンをサーバーやクライアントとして設定し、これらが正しく動作していることを確認した上で、古いドメインを削除します。
NIS+ のクライアントとなっているマシンを、他のドメインのクライアントに変更したい場合は、/etc/.rootkey ファイルを削除し、ネットワーク管理者から受け取ったパスワードか nisclient スクリプトから取り出したパスワードを使用して、nispopulate スクリプトを実行し直します。
NIS+ のパスワードは、NIS+ の passwd テーブルの中に格納されています。ログインパスワードは、NIS+ の passwd テーブルか、各ユーザーの /etc/passwd ファイルの中に格納されています。ユーザーパスワードと NIS+ のパスワードは、同じでも違っていてもかまいません。/etc/passwd ファイル内のパスワードを変更するには、nsswitch.conf ファイルでの設定を「files」にするか、「-r files」というフラグを指定するかして passwd コマンドを実行する必要があります。
nsswitch.conf ファイルは、どの目的にどのファイルを使用するか指定します。nsswitch.conf ファイルが、システムの照会に対して誤った場所を指示している場合は、パスワードやアクセス権のエラーが発生するはずです。
主体のログインパスワードと 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 パスワードとログインパスワードが異なっているという問題を根本的に解決するには、具体的には以下の作業を行います。
ログインパスワードを使用してログインします。
keylogin プログラムを実行して、キーサーバーに保存される非公開鍵を一時的に復号し、一時的な NIS+ アクセス権を得ます。
chkey -p 実行して、cred テーブル中の暗号化された非公開鍵を、ユーザーのログインパスワードに基づいたものに固定的に変更します。
「症状」
「insufficient permission」や、「permission denied」などの、様々なエラーメッセージ
「考えられる原因」
サーバーやクライアントの設定や初期設定を行なったときに、/etc/.rootkey ファイルがすでに存在していました。以前そのマシンに NIS+ をインストールしたことがあり、NIS+ を削除したとき、または NIS や /etc への変更を行なったときに、.rootkey ファイルを削除しなかったためにこのような状態が起こります。
「診断」
/etc ディレクトリで ls -l と nisls -l org_dir を実行し、/etc/.rootkey の日付を、cred テーブルの日付と比較します。/etc/.rootkey の日付が明らかに cred テーブルより古い場合は、ファイルがあらかじめ存在していたことが考えられます。
「対策」
問題のあるマシンで、ルートとして keylogin -r コマンドを実行し、そのマシンをもう一度クライアントとして設定し直します。
「症状」
マシンのルートのパスワードを変更した結果、変更結果が反映されなかったか、スーパーユーザーとしてログインできなくなりました。
「考えられる原因」
セキュリティ上の理由から、passwd テーブルの中に、UserID 0 という項目を、設けるべきではありません。
ルートのパスワードを変更した際、ルートに対して chkey -p を実行していなかったり、何らかの問題が発生したことにより、変更が正しく行われませんでした。
「対策」
管理特権を持つユーザー (つまり、管理特権が割り当てられているグループに所属するメンバー) としてログインし、passwd を使用して、元のパスワードに戻します。元のパスワードが正しく機能するかどうか確かめてください。正しく機能すれば、passwd を使用してパスワードを変更した後、chkey -p を実行します。
NIS+ の名前空間の設定が終わり、すでに動作している状態でも、ルートマスターのマシンを使ってルートのパスワードを変更することは可能です。しかし、ルートマスターの鍵は変更しないでください。これらは、サブドメイン内のすべてのクライアント、複製サーバー、サーバーの中のすべてのディレクトリオブジェクトに埋め込まれているからです。chkey をルートで実行する際、必ず -p オプションを指定するようにすれば、ルートマスターの鍵を変更する必要はなくなります。
この節では、性能の低下とシステムのハングアップの問題を取り上げます。
処理内容に関係する次の表現が含まれているエラーメッセージが表示されます。
次の一般的な現象が観察されることもあります。
コマンドを実行しても、長時間、何も行われていないように見える
システムやシェルが、キーボードやマウスの操作に全く反応しない
NIS+ の動作が通常よりも遅い
誰かが nisping か nisping -C どちらかのコマンドを実行しました。または、rpc.nisd デーモンが、チェックポイントを実行しています。
再起動しないでください。nisping を実行しないでください。
nisping やチェックポイントを実行すると、サーバーは反応が遅くなったり、他のコマンドにすぐに応答しなくなったりすることがあります。名前空間のサイズに応じて、このようなコマンドが完了するまでに、かなりの時間を要します。これらのコマンドの実行中に、誰かが同様のコマンドを実行すると、所要時間は何倍にもなります。再起動も行わないでください。この種の問題は自然に解決します。サーバーが nisping やチェックポイントの実行を完了するまで待つだけです。
マスターサーバーと複製サーバーの同期が完全に行われている場合、同期が完了するまで、複製サーバーはサービスを停止します。再起動しないで待機してください。
NIS_PATH
変数が、明快かつ単純な値に設定されているかどうか確認します。たとえば、デフォルトでは org_dir.$:$ に設定されています。複雑な NIS_PATH
、特に他の変数を含んでいる変数は、システムの速度を低下させ、特定の操作にエラーを引き起こす可能性があります (詳細は、「環境変数 NIS_PATH」を参照)。
デフォルト以外のテーブルパスを指定するために nistbladm を使用することは避けてください。デフォルト以外のテーブルパスを指定すると、性能は低下します。
テーブルパスは使用しないでください。性能を低下させることになります。
1 つのドメインの中に複製サーバーが多すぎる場合は、複製作業を行なっている間はシステムの性能が低下します。1 つのドメインまたはサブドメインの中に、10 台より多くの複製サーバーを置くことは避けてください。ドメインの中の複製サーバーが 5 台より多い場合は、何台かを取り除いて性能が改善されるかどうか調べます。
再帰的なグループとは、他のグループを包含するグループのことです。グループの中に他のグループを含めると、システム管理者として行う作業は減少しますが、システムの速度は低下します。再帰的なグループを使うべきではありません。
rpc.nisd は、起動時に各ログを参照します。ログが大きい場合、rpc.nisd を起動する前に、nisping -C を使用して、チェックポイントを実行する方がよいかもしれません。
「症状」
-M オプションを指定して要求をマスターサーバーに送ったときに、マスターのマシンで rpc.nisd デーモンが終了していると、「server not responding」タイプのエラーメッセージが発生し、更新を行うことは認められません。-M オプションを指定しなかったときは、要求は機能している複製サーバーに自動的に転送されます。
「考えられる原因」
ホームディレクトリ名やホスト名の一部として大文字を使うと、rpc.nisd デーモンが終了することがあります。
「診断」
最初に、サーバー自体が起動されて、動作しているかどうか確認します。動作している場合は、ps -ef | grep rpc.nisd を実行し、デーモンが動作しているかどうか調べます。
「対策」
デーモンが終了している場合は、起動し直します。たびたびデーモンが終了する場合は、ご購入先にご連絡ください。
「症状」
あるマシンが他のドメインにある名前空間オブジェクトを探すのに、非常に長い時間がかかっています。
「考えられる原因」
nis_cachemgr を実行していません。
「診断」
ps -ef | grep nis_cachemgr を実行して、nis_cachemgr が動作しているかどうか確認します。
「対策」
そのマシンで、nis_cachemgr を起動します。
「症状」
NIS+ のスクリプトを使用して NIS+ をインストールした後、サーバーの動作が非常に遅く、緩慢です。
「考えられる原因」
nispopulate スクリプトを動作させた後、nisping -C -a を実行していません。
「対策」
nisping -C -a を実行して、できるだけ早くチェックポイントを実行します。
「症状」
niscat を実行すると、サーバーがビジーであるというエラーメッセージが表示されます。
「考えられる原因」
再同期を実行しているときのように重い負荷がかかっていて、サーバーがビジーです。
サーバーがスワップ空間を使い果たしました。
「診断」
swap -s を実行して、サーバーのスワップ空間をチェックします。
「対策」
NIS+ を実行するには、適度のスワップ空間とディスク容量を用意すべきです。必要に応じて、空間を増やします。
「症状」
NIS+ サーバーのホスト名を完全指定することは、推奨されていません。このような指定を行なった後、NIS+ の照会を実行すると、エラーメッセージを表示することなくハングアップが発生しました。次の可能性をチェックします。
「考えられる原因」
完全指定のホスト名は、次の条件を満たしていなければなりません。
ホスト名のドメイン部は、domainname コマンドの結果と完全に一致している
ホスト名を完全指定名に変更した後、/etc や /etc/inet 内のファイルに、新しいホスト名の情報を反映させる
ホスト名の終わりにピリオドをつける
「対策」
ハングアップした NIS+ プロセスを終了させ、ホストやサーバーの rpc.nisd も終了させます。上の 2 つの条件に合わせて、ホスト名を変更します。nisinit を使用してサーバーを初期設定します。ホスト名が正しいことを確認した後もハングアップが発生する場合は、この節の他の考えられる原因をチェックしてください。
この節では、メモリーやディスク容量のようなシステムリソースが不足したときの問題を取り上げます。
処理内容に関係する次の表現が含まれているエラーメッセージが表示されます。
システムのメモリーやスワップ空間が不足すると、NIS+ の様々な問題やエラーメッセージに遭遇します。一時的な解決策として、不必要なウィンドウやプロセスを終了させることが考えられます。必要に応じて、ウィンドウシステムを終了し、端末のコマンド行を使用します。それでもメモリー不足を知らせるメッセージが表示されるときは、スワップ空間やメモリーを追加するか、十分なスワップ空間やメモリーを持つシステムに切り替えます。
特定の状況では、アプリケーションやプロセスがメモリーを無駄に消費し、使用メモリーサイズが極端に大きくなることがあります。次のコマンドを実行すると、アプリケーションやプロセスの現在のサイズを知ることができます。
ps -el |
sz (サイズ) の列には、各プロセスの現在のメモリーサイズが表示されています。必要に応じて、サイズが同程度と思われるアプリケーションやプロセスを比較し、メモリーサイズが極端に大きいものが存在しないかどうか調べます。
ディスク容量が不足すると、様々なエラーメッセージが表示されます。ディスク領域の不足に共通する原因は、定期的に行われている tmp ファイルの削除やログファイルの切り捨てをしていないことです。切り捨てを行わないと、ログファイルと tmp ファイルは常時増加します。これらのファイルの増大速度はシステムごとに異なり、同じシステムでも状態によって変化します。非効率的なシステムや、名前空間に問題を抱えているシステムでは、ログファイルは非常に急速に増大します。
多くの問題が発生しているときは、ログファイルと /tmp のファイルを頻繁にチェックします。ディスク容量が不足して他の問題が発生する前に、ログファイルを切り捨て、/tmp ファイルを削除します。また、ルートディレクトリとホームディレクトリで core ファイルを探して削除します。
ログファイルを切り捨てるには、システムのチェックポイントを設けます。チェックポイントのプロセスがある程度の時間を要し、完了するまではシステムの速度を低下させることに注意してください。また、ファイルの切り捨てを行う前に完全なコピーを作成するので、ある程度のディスク容量を必要とします。
システムのチェックポイントを実行するには、nisping -C を実行します。
過度に負荷の大きいマシンでは、マシンの構成の中で指定されている、同時に実行できる最大のプロセス数に達する可能性があります。この結果、「unable to fork」のようなメッセージが表示されます。この問題を解決するために推奨されている方法は、不必要なプロセスを終了させることです。それでも問題が持続する場合は、システムの管理マニュアルの説明に従って、より多くのプロセスを扱えるようにシステムを構成し直してください。
この節では、一般ユーザーが遭遇する NIS+ の問題を取り上げます。
ユーザーがログインできない原因としては、以下のように様々なものが考えられます。
パスワードを忘れた
新しいパスワードを設定します。別のマシンのユーザーの場合は、nispasswd を使用します。この作業は NIS+ 管理者だけが行えます。
パスワードを間違えて入力した
ユーザーが、正しいパスワードを覚えているかどうか、また「パスワードでは大文字と小文字が区別される」、「アルファベットの o 、l と数字の 0 、1 は、まったく別のものである」という点を理解しているかどうかを確認します。
「Login incorrect」というタイプのメッセージが表示される
単純に「パスワードの入力を間違えた」という以外の原因については、「「Login Incorrect」というメッセージが表示された」を参照してください。
ユーザーのパスワード使用権が有効期限を過ぎている (「パスワード使用権の有効期限」を参照)。
指定された期間を超えてログインが行われなかった (「ログインの間隔の最大値の指定」を参照)。
nsswitch.conf ファイルの設定が正しくない
passwd エントリの設定は以下の 5 つのうちのいずれかにします。
passwd: files
passwd: files nis
passwd: files nisplus
passwd: compat
passwd: compat
passwd_compat: nisplus
これ以外の設定をすると、ユーザーがログインできなくなります (詳細は、「nsswitch.conf ファイルの必要条件」を参照)。
「症状」
最近パスワードを変更したユーザーが、ログインできません。または、特定のマシンからログインできますが、他のマシンからログインできません。
「考えられる原因」
パスワードの変更を行なっても、システム全体に反映されるまでに時間がかかります。試しに、古いパスワードを使ってログインしてみてください。
NIS+ が動作していないマシンで、パスワードを変更しました (「ユーザーが新しいパスワードを使ったときにログインできない」を参照) 。
「症状」
ユーザーが rlogin を使用して、他のドメインへのログインを試みましたが、「Permission denied」メッセージが表示されて、拒絶されました。
「考えられる原因」
他のドメインにリモートログイン (rlogin) するには、ユーザーはそのドメインで LOCAL の資格を持っていなければなりません。
「診断」
そのドメインで、nismatch username.domainname. cred.org_dir を実行し、LOCAL の資格を持っているかどうか調べます。
「対策」
リモートドメインから nisaddcred を使用し、そのドメインでの LOCAL の資格をユーザーに割り当てます。
原因として最も多いのが、古いパスワードの入力を間違えた (または忘れた) ということです。
他には以下のような原因が考えられます。
パスワードの最小値に、最大値よりも大きい値が設定されている (「nistbladm と シャドウ列のフィールド」参照)
パスワードがロックされている、あるいは有効期限を過ぎている (「「Login Incorrect」というメッセージが表示された」、「パスワードがロック状態、期限切れ、または無効である」を参照)
この節では、上記の問題に当てはまらない問題を取り上げます。
特定のホストが NIS+ を実行しているかどうか知りたい場合があります。NIS+ が動作しているか知るには、スクリプトが必要です。
次のどれかに一致する場合は、NIS+ が動作していると考えられます。
nis_cachemgr が動作している
ホストに /var/nis/NIS_COLD_START ファイルがある
nisls の実行に成功した
「症状」
更新が成功しなかったことを示すエラーメッセージが表示されます。次のメッセージが更新の成功を示すことに注意してください。「replica_update: number updates number errors 」
「考えられる原因」
次のエラーメッセージのどれかが表示された場合、サーバーがビジーであり、更新を延期すべきことがわかります。
replica_update: error result was Master server busy,
full dump rescheduled
replica_update:nis dump result Master server busy,
full dump rescheduled
これらのメッセージは、NIS+ のエラーコード定数、NIS_DUMPLATER (ある複製サーバーが、すでに同期を実行している) により、または、一緒に表示されます。
次のメッセージは、他の問題が起こっていることを示します。
replica_update: error result was ...
rootreplica_update: update failed nis dump result nis_perror
-C (診断チャンネルのオープン) オプションを指定した rpc.nisd が動作している場合は、マスターサーバーか複製サーバーのシステムログに、詳細な情報が記録されることもあります。
これらのメッセージは、次のような潜在的な問題が起こっていることを示しています。
サーバーが割り当てることができる子プロセスを使い果たした
読み込み専用の子プロセスがダンプを行うよう要求された
他の複製サーバーが、現在同期を実行している
「診断」
複製サーバーとマスターサーバー両方のシステムログから、詳細な情報を探します。情報が記録されている場合でも、詳細の程度は、システムのエラー報告レベルと、-C オプション (診断) を指定して rpc.nisd を実行したかどうかによって異なります。
「対策」
ほとんどの場合、これらのメッセージは、システムが修正することのできる、ソフトウェアの小さな問題が発生したことを意味しています。あるコマンドを実行した結果、これらのメッセージが表示された場合は、しばらく待って、もう一度同じコマンドを実行します。これらのメッセージが頻繁に表示される場合は、/etc/syslog.conf ファイル内のしきい値レベルを変更します。詳細は、syslog.conf(4) のマニュアルページを参照してください。
この節では、NIS を実行中のネットワーク上で発生する問題の解決方法を説明します。NIS クライアントで見うけられる問題と、NIS サーバーで見うけられるものを説明します。
NIS サーバーやクライアントをデバッグする前に、第 18 章「ネットワーク情報サービス (NIS)」を参照してください。その後で、この節で、問題を適切に解説する項を参照してください。
一般的な NIS バインディングの問題には次のようなものがあります。
クライアントのコマンドがバックグランドモードでゆっくりと処理されているか、通常よりも機能に時間がかかる
クライアントのコマンドがハングする。システム全体は正常で、新しいコマンドを実行できる場合でも、コマンドがハングすることがある
クライアントのコマンドがあいまいなメッセージと共に、またはまったくメッセージなしでクラッシュする
NIS バインディングの問題を示す現象が、1 つ以上のクライアントで発生している場合には、問題はクライアントにあります。多くの NIS クライアントが、プロパティを正確にバインドできない場合には、問題は 1 つ以上の NIS サーバーにある可能性があります。「NIS の問題が多くのクライアントに影響している」を参照してください。
1 つのクライアントに問題があっても、同じサブネットの他のクライアントが正常に機能しています。問題のあるクライアント上で、ls -l を /usr のようなディレクトリで実行します。これは、多くのユーザーが所有するファイルを含み、ここにはクライアント /etc/passwd ファイルにはないものも含まれます。この結果の表示に、ローカルの /etc/passwd には、名前ではなく番号として入ってないファイルの所有者が含まれる場合には、NIS サービスがクライアントで機能していないことを示します。
通常これらの現象は、クライアント ypbind プロセスが実行していないこと示します。ps -e を実行して、ypbind をチェックします。ypbind が見つからなければ、スーパーユーザーとしてログインし、次のように入力して、ypbind を起動します。
client# /usr/lib/netsvc/yp/ypstart |
あるクライアントに問題があり、他のクライアントは正常に機能していますが、ypbind は問題のあるクライアント上で実行しています。クライアントのドメインの設定が不正確な可能性があります。
クライアントで domainname コマンドを実行して、どのドメイン名が設定されているのかを調べます。
Client#7 domainname neverland.com |
NIS のマスターサーバー上の /var/yp 内の実際のドメイン名と、出力を比較します。実際の NIS ドメインは、/var/yp ディレクトリ内のサブディレクトリとして表示されます。
Client#7 ls /var/yp... -rwxr-xr-x 1 root Makefile drwxr-xr-x 2 root binding drwx------ 2 root doc.com ... |
マシン上での domainname の実行によって得たドメイン名が、/var/yp 内のディレクトリとして示されたサーバードメインと同じではない場合には、マシンの /etc/defaultdomain ファイルで指定されたドメイン名が間違っています。スーパーユーザーとしてログインして、マシンの /etc/defaultdomain ファイル内のクライアントのドメイン名を修正します。これによって、マシンを起動するたびに、ドメイン名が正しいかどうかが確認されます。ここでマシンを再起動しましょう。
ドメイン名では大文字と小文字を区別します。
ドメイン名が正しく設定されて、ypbind が実行中でも、コマンドがまだハングする場合には、ypbind コマンドを実行することによって、クライアントがサーバーにバインドされていることを確認してください。ypbind を起動したばかりの時は、ypwhich を数回実行します。特に最初のものは、ドメインがバインドされていないことを通知して、2 番目のものは成功します。
ドメイン名が正しく設定されていて、ypbind が実行中で、クライアントがサーバーと通信できないというメッセージを受け取った場合には、いくつかの問題があります。
バインドするサーバーのリストを含む /var/yp/binding/domainname/ypservers ファイルがクライアントにあるかどうかを確認します。ない場合には、ypinit -c を実行して、設定の順番にクライアントのバインド先のサーバーを指定します。
クライアントに /var/yp/binding/domainname/ypservers ファイルがあり、1 つ以上のサーバーが使用できない場合には、十分な数のサーバーがあるかどうかを調べます。ない場合には、yppinit -c を実行して、リストにサーバーを追加します。
クライアントの ypservers ファイルにリストされたサーバーのどれもが使用できない場合には、クライアントはブロードキャストモードで稼働中のサーバーを検索します。稼働中のサーバーがクライアントのサブネットにある場合には、クライアントはそれを見つけます (検索中はパフォーマンスが落ちる)。クライアントのサブネットに稼動中のサーバーがない場合には、次の方法で問題を解決できます。
セキュリティと管理の意味から、クライアントにブロードキャストを使ってサーバーを検索させるのではなく、クライアントの ypservers ファイルでクライアントのバインド先のサーバーを指定してください。ブロードキャストは、ネットワークを結合して、クライアントの速度を落とします。異なるクライアントに対して、異なるサーバーをリストすることによって、サーバー負荷の均衡がとれなくなります。
クライアント ypservers ファイルにリストされたサーバーが、/etc/hosts ファイルにエントリを持っているかどうかを確認します。持っていない場合には、NIS マップホストの入力ファイルにサーバーを追加して、「NIS マップに関する作業」で説明するとおりに、yppinit -c または ypinit -s を実行してマップを再構築します。
/etc/nsswitch.conf ファイルが設定されて、NIS の他にマシンのローカルの hosts ファイルを参照できるかどうかを確認します。スイッチについての詳細は 第 2 章「ネームサービススイッチ」を参照してください。
/etc/nsswitch.conf ファイルが設定されて、services と rpc に対して、files を参照できるかどうかを確認します。
ypwhich を同じクライアントで数回使うと、NIS サーバーが変わるので結果の表示が異なります。これは正常な状態です。NIS クライアントから NIS サーバーへのバインディングは、ネットワークや NIS サーバーを使用中の場合は時間の経過に伴って変化します。ネットワークは、すべてのクライアントが受け入れ可能な応答を NIS サーバーから受信した時点で安定します。クライアントのマシンが NIS サービスを得ているかぎりは、サービスの供給元は問題にはなりません。たとえば、NIS サーバーマシンがそれ自体の NIS サービスを、ネットワーク上の別の NIS サーバーから受けることがあります。
サーバーのバインディングが不可能な場合には、ypset コマンドを使えます。別のネットワークまたはサブネットの別のサーバーが使用可能な場合には、そのサーバーへのバインディングが一時的に可能になります。ただし、-ypset オプションを使用するためには、ypbind を -ypset または -ypsetme オプションのどちらかを指定して、実行する必要があります。
セキュリティの目的のために、-ypset と -ypsetme のオプションの使用は、制御された状態でのデバッグだけに限定してください。-ypset と -ypsetme のオプションの使用によって、セキュリティが侵害される恐れがあります。これらを実行中は、サーバーのバインディングをだれでも変更でき、他のユーザーを妨害したり、重要なデータへの未承認のアクセスが認められるためです。これらのオプションで ypbind を起動する場合には、いったん問題を確定したら、ypbind を消去して、これらのオプションを指定しないで再起動してください。
ypbind が、起動するたびに、すぐにクラッシュする場合には、システムの他の部分で問題を調べてください。以下を入力して、rpcbind デーモンの存在をチェックします。
% ps -ef | grep rpcbind |
rpcbind が存在しないか、または安定せず、動作に異常がある場合には、RPC のマニュアルを参照してください。
正常に機能しているマシンから、問題のあるクライアント上の rpcbind と通信ができる場合があります。稼動中のマシンから、以下を入力します。
% rpcinfo client |
問題のあるクライアント上の rpcbind に問題がない場合には、rpcinfo によって次の出力がされます。
program version netid address service owner ... 100007 2 udp 0.0.0.0.2.219 ypbind superuser 100007 1 udp 0.0.0.0.2.219 ypbind superuser 100007 1 tcp 0.0.0.0.2.220 ypbind superuser 100007 2 tcp 0.0.0.0.128.4 ypbind superuser 100007 2 ticotsord ¥000¥000¥020H ypbind superuser 100007 2 ticots ¥000¥000¥020K ypbind superuser ... |
マシンは異なるアドレスを持ちます。それらが表示されない場合には、そのサービスを ypbind が登録できていません。マシンを再起動して、再度 rpcinfo を実行します。ypbind プロセスがある場合には /usr/lib/netsvc/yp/ypbind を再起動しようとするたびに変更します。
1 つ以上のクライアントで、NIS バインディングの問題を示す現象が発生している場合には、それらクライアントに問題がある可能性があります (「1 つのクライアントに影響する NIS の問題」を参照)。多くのクライアントが正確にバインドできなくなっている場合には、1 つ以上の NIS サーバーに問題がある可能性があります。
ネットワークまたは NIS サーバーが過負荷状態で、クライアント ypbind プロセスに ypserv が時間以内に応答を戻せない場合には、NIS がハングする場合があります。
こういった状態では、ネットワーク上のすべてのクライアントで同じまたは類似した問題が発生します。ほとんどの場合に、この状態は一時的です。NIS サーバーが再起動して ypserv を再起動するか、または NIS サーバーまたはネットワーク自体の負荷が減少すると、通常、メッセージは消えます。
サーバーが起動して実行中であることを確認してください。サーバーが物理的に近くにない場合には、ping コマンドを使ってください。
サーバーが起動して実行中である場合には、クライアントマシンが正常に動作していることを調べて、ypwhich コマンドを実行します。ypwhich が応答しない場合には、それを消去します。NIS サーバーにスーパーユーザーになってログインし、次のように入力して NIS ypbind プロセスが実行中かどうかをチェックします。
# ps -e | grep yp |
-f オプションは ps と共に使わないでください。このオプションはユーザー ID を名前に変換しようとするため、より多くのネームサービスの検索が失敗するようになります。
ypbind または ypserv デーモンのどちらかが実行されていない場合には、それらを消去してから、次のように入力して再起動します。
# /usr/lib/netsvc/yp/ypstop # /usr/lib/netsvc/yp/ypstart |
ypbind または ypserv プロセスの両方が NIS サーバーで実行中の場合には、次のように入力します。
# ypwhich |
ypwhich が応答しない場合には、ypserv がハングしていて、再起動が必要な状態である可能性があります。サーバーに root でログインして、ypserv を消去し、次のように入力して再起動します。
# /usr/lib/netsvc/yp/ypstop # /usr/lib/netsvc/yp/ypstart |
NIS はマップをサーバー間で伝播するので、ネットワーク上に異なる NIS サーバーに、同じマップの異なるバージョンが存在することがあります。相違点が長時間継続しない場合には、このバージョンの違いは、許容可能です。
マップの不一致のもっとも一般的な原因は、マップの正常な伝播を妨げる何かが存在するためです。たとえば、NIS サーバーまたはルーターが、NIS サーバー間でダウンしている場合です。すべての NIS サーバーとそれらの間に存在するルーターが実行中の場合には、ypxfr は成功します。
サーバーとルーターが正常に機能している場合には、以下をチェックします。
ypxfr 出力のログをとります (「ypxfr 出力のログ」を参照)。
制御ファイルをチェックします (「crontab ファイルと ypxfr シェルスクリプトをチェックする」を参照)。
マスターの ypservers マップをチェックします (「ypservers マップをチェックする」を参照)。
特定のスレーブサーバーで、マップの更新に問題がある場合には、そのサーバーにログインして、ypxfr を対話形式で実行します。ypxfr が失敗すると、ypxfr がその失敗を通知するので、問題の修正が可能になります。ypxfr が成功しても、時々失敗するような場合には、メッセージのログを取るためにログファイルを作成します。ログファイルを作成するには、次のように入力します。
ypslave# cd /var/yp ypslave# touch ypxfr.log |
これによって、ypxfr からのすべての出力を保存する ypxfr.log ファイルが作成されます。
対話形式で実行中の出力 ypxfr の表示に出力は類似しますが、ログファイルの各行にタイムスタンプが押されます。タイムスタンプは、通常とは異なる順番になりますが、問題はありません。タイムスタンプは、ypxfr が実行し始めたことを示します。ypxfr のコピーが同時に実行しても、作業時間が異なる場合には、起動元とは異なる順番でサマリーステータス行をログファイルに記述していることがあります。任意の型の失敗が、断続的にログに示されます。
問題を解決したら、ログファイルを削除してログを停止します。削除しないと、ログは制限なく大きくなります。
root の crontab ファイルを調べて、それが起動した ypxfr シェルスクリプトをチェックします。これらファイルにタイプミスがあると、伝播の問題が発生します。/var/spool/cron/crontabs/root ファイル内でシェルスクリプトを参照できないか、または任意のシェルスクリプト内でマップを参照できない場合にも、エラーが発生します。
NIS スレーブサーバーが、ドメインに対するマスターサーバー上の ypservers マップにリストされていることも確認してください。リストされていない場合には、スレーブサーバーはサーバーとして正しく機能しますが、yppush はマップの変更をスレーブサーバーに伝播しません。
NIS スレーブサーバーの問題が明白ではない場合には、その問題を回避できます。その一方で、rcp または ftp を使ってデバッグし、一貫性のないマップの最新バージョンを問題のない NIS サーバーからコピーできます。たとえば、次のように問題のあるマップを転送します。
ypslave# rcp ypmaster:/var/yp/ mydomain/map.¥* /var/yp/ mydomain |
この場合 * の文字は、コマンド行でエスケープされて、ypslave でローカルにではなく、ypmaster で拡張されます。
ypserv プロセスがほとんど即座にクラッシュして、何度再起動しても安定しないときは、デバッグプロセスは、「ypbind のクラッシュ」で説明するものと実質的に同じです。rpcbind デーモンの存在を次のようにチェックしてください。
ypserver% ps -e | grep rpcbind |
デーモンが見つからない場合にはサーバーを再起動します。そうでない場合には、デーモンが実行中でないなら、以下を入力して、同様の出力を検索します。
% rpcinfo -p ypserver program vers proto port service 1000004 tcp 111 portmapper 1000003 tcp 111 portmapper 1000682 udp 32813 cmsd ... 1000071 tcp 34900 ypbind 1000042 udp 731 ypserv 1000041 udp 731 ypserv 1000041 tcp 732 ypserv 1000042 tcp 32772 ypserv |
マシンに異なるポート番号がある場合があります。ypserv プロセスを表わす 4 つのエントリは次のとおりです。
100004 2 udp 731 ypserv 100004 1 udp 731 ypserv 100004 1 tcp 732 ypserv 100004 2 tcp 32772 ypserv |
このエントリがなく、ypserv がそのサービスを rpcbind で登録できない場合には、マシンを再起動してください。これらのエントリがある場合には、rpcbind からサービスの登録を解除してから、ypserv を再起動します。rpcbind からサービスの登録を解除するには、サーバーで次のように入力します。
# rpcinfo -d number 1 # rpcinfo -d number 2 |
この場合 number は、rpcinfo によって通知される ID 番号です (前述の例では、100004)。
この節では、一般的な DNS の問題とその対策を説明します。
「症状」
DNS クライアントは、IP アドレスかホスト名でマシンを見つけられますが、サーバーは IP アドレスでしか見つかりません。
「考えられる原因と対策」
サーバーの nsswitch.conf ファイルの hosts 行から DNS を省略したために発生する可能性があります。たとえば、不完全な hosts 行は、次のようになります。
host:files |
DNS を使用中には、次のどちらかのように、すべてのマシンの nsswitch.conf ファイルの hosts レコード内に dns を含む必要があります。
hosts: dns nisplus [NOTFOUND=return] files |
hosts: nisplus dns [NOTFOUND=return] files |
「症状」
マシンまたはサーバーを追加または削除しても、変更が認識されず、その効果が現れません。またはある時は変更が認識され、別の時にはその効果が現れません。
「考えられる原因」
考えられる原因は、主マスターサーバー上の SOA のシリアル番号を増やすのを忘れた場合です。新しい SOA 番号がないので、主サーバーのものと一致させるためのデータ更新を副サーバーは行いません。このため、古い未変更のデータファイルで作業を行なっています。
この他に考えられる原因は、1 つ以上の主要なデータファイルの SOA のシリアル番号が、副サーバー上の対応するシリアル番号よりも小さい値に設定されたということです。たとえば、この状態は、主サーバー上のファイルを削除してから、ある種の入力ファイルを使って最初からそれを作成し直した場合に発生します。
考えられる 3 番目の原因は、主サーバーのデータファイルへの変更を行なった後に、HUP 信号を主サーバーに送信し忘れた場合です。
「診断と対策」
最初に、変更したデータファイルの SOA のシリアル番号と副サーバー上の対応するファイルをチェックします。
主ファイルの SOA のシリアル番号が、副ファイルのシリアル番号と同じか、またはそれ以下の場合には、主サーバーのファイルでシリアル番号を増加させて、副ファイルの番号よりも大きくなるようにします。たとえば、両方のファイルの SOA のシリアル番号が 37 の場合には、主サーバーのファイルの番号を 38 に変更します。次回、副サーバーが主サーバーをチェックすると、新しいデータがロードされます。主サーバーに、副サーバーへの転送を即座に強制するユーティリティがあります。これらユーティリティの 1 つがある場合には、主サーバーのチェックを待たずに副サーバーを更新できます。
最新の named nnnn restarted または、named nnn reloading nameserver エントリに対する syslog 出力をレビューします。そのエントリ用のタイムスタンプが、ファイルへの変更を終了した時間の前の場合には、サーバーを再起動するか、または、「in.named に DNS データを強制的に再読み込みさせる」で説明するとおりに新しいデータの読み取りを強制します。
「症状」
クライアントは完全指定名は検索できますが、短縮名は検索できません。
「考えられる原因と現象」
クライアントの /etc/resolv.conf ファイルで、ドメイン名の最後にスペースがないかをチェックします。スペースやタブはドメイン名の最後では許可されません。
「症状」
ゾーンのドメイン名の付いたデータは、ゾーンの主マスターサーバーからゾーンの副サーバーに正確に転送される一方で、リバースドメインデータは転送されません。つまり、副サーバーの host.rev ファイルが主サーバーから正確に更新されていません。
「考えられる原因」
副サーバーのブートファイルの構文エラー
「診断と対策」
副サーバーのブートファイルをチェックします。主サーバーのブートファイルの IP アドレスが、ホストデータに対するのと同じようにリバースゾーンエントリに対してリストされていることを確認してください。
たとえば、主サーバーの IP アドレスが、secondary in-addr.arpa レコードからなくなっているので、次のブートファイルは正しくありません。
; ; /etc/named.boot file for dnssecondary directory /var/named secondary doc.com 129.146.168.119 dnshosts.bakup secondary 168.146.129.in-addr.arpa doc.rev.bakup |
正しいファイルは次のようになります。
; ; /etc/named.boot file for dnssecondary directory /var/named secondary doc.com 129.146.168.119 dnshosts.bakup secondary 168.146.129.in-addr.arpa 129.146.168.119 doc.rev.bakup |
副サーバーがそのマスターから更新を得られないときは、「master unreachable」のメッセージをログに記録します。問題が修正されない場合には、副サーバーはゾーンを期限切れにして、クライアントからの要求への応答を停止します。これが発生すると、「server failed」のメッセージが表示されるようになります。
「症状」
問題が副サーバーにある場合には、一部のユーザーは、マスターから DNS 情報を獲得でき、問題なく操作できます。
「考えられる原因」
これらの問題に対して考えられる主な 2 つの原因は、副サーバーのブートファイル内のマスターに対する誤った IP アドレスとネットワーク障害があります。
「診断と対策」
副サーバーのブートファイルに、マスターに対する正しい IP アドレスがあるかをチェックします。次の行をチェックしてください。
secondary domain IPaddress hostsfile |
マスターの IP アドレスが、hosts ファイルで指定されたマスターに対するアドレスとマスターの実際の IP アドレスと一致することを確認してください。IP アドレスが誤っている場合には、それを修正してから副サーバーを再起動します。
マスターの IP アドレスが正しい場合には、マスターの IP アドレスを ping することによって、マスターが起動して、正しく実行中であることを確認します。たとえば、マスターを IP アドレス 129.146.168.119 に ping するには、次のように入力します。
% ping 129.146.168.119 -n 10 |
マスターが ping に応答しない場合には、それが起動して、正しく実行中であることを確認します。
マスターが実行中の場合には、ps を使って、それが named を実行中であることを確認します。named を実行していない場合には、再起動します。
マスターが named を正しく実行中の場合には、ネットワーク障害が発生している可能性があります。
「症状」
「考えられる原因」
主マスターサーバーの hosts.rev ファイルに PTR を持たないマシンでユーザーが作業をしています。
hosts.rev ファイル内のサブドメインがないか、または不正確な委任が行われています。
「診断と対策」
適切な hosts.rev ファイルをチェックして、ユーザーのマシンに対して PTR レコードがあることを確認します。たとえば、129.146.168.46 の IP アドレスを持つマシン altair.doc.com で、ユーザーが作業をしている場合には、doc.com の主マスターサーバーの doc.rev ファイルは、次のようなエントリを持つ必要があります。
46 IN PTR altair.doc.com. |
レコードがない場合には、それを hosts.rev ファイルに追加してから、サーバーを再起動するか、「in.named に DNS データを強制的に再読み込みさせる」で説明するとおりにデータを再ロードします。
hosts.rev ファイルの NS エントリをチェック、および修正してからサーバーを再起動するか、「in.named に DNS データを強制的に再読み込みさせる」で説明するとおりに、そのデータを再ロードします。
「症状」
次のような言い回しを伴ったコンソールまたは syslog のエラーメッセージは、たいてい DNS データとブートファイルの構文エラーによって発生します。
関連ファイルでスペルと構文のエラーをチェックしてください。
一般的な構文エラーは、ドメイン名で後ろに付く点 (ドット) の誤用 (禁じられている場合に使い、必要な場合に使わないなど) に起因します。「ドメイン名の終わりにつけるドット」を参照してください。
この節では、問題と共に、考えられる原因、診断、対策を示します。
FNS エラーについての一般的な情報については、「FNS エラーメッセージ」と付録 B 「エラーメッセージ」 を参照してください。
「症状」
「Cannot obtain initial context」というメッセージが表示されます。
「考えられる原因」
インストール時の問題により発生します。
「診断」
/usr/lib/fn/fn_ctx_initial.so というファイルを検索し、FNS が正しくインストールされているかどうかを確認します。
「対策」
fn_ctx_initial.so ライブラリをインストールします。
「症状」
fnlist を実行して初期コンテキストの内容を確認すると何も表示されないという状態です。
「考えられる原因」
NIS+ の設定によって起こる問題です。fn* コマンドを実行するユーザーやマシンに関連した組織に、ctx_dir ディレクトリがないことが原因です。
「診断」
nisls コマンドを使用して ctx_dir ディレクトリの有無を確認します。
「対策」
診断の結果 ctx_dir ディレクトリがなければ、fncreate -t org/nis+_domain_name/ を実行して作成します。
「症状」
「no permission」というメッセージが表示されます。
「考えられる原因」
このメッセージは、「コマンドを実行しようとしたが、アクセス権がない」ということを意味します。
「診断」
適切な NIS+ コマンドを使用してアクセス権を確認します (「FNS と NIS+ の詳細情報」を参照)。NIS+ 主体名は、nisdefaults コマンドで知ることができます。
また、使用している名前が正しいかどうかも確認する必要があります。たとえば、ルート組織のコンテキスト名は、org// を使用して決定します。ルート組織を操作する権限があるかどうか確認してください。myorgunit/ を指定する場合もあります。
「対策」
アクセス権が正しく設定されているにもかかわらずこのメッセージが表示される場合は、適切な資格が与えられていない可能性があります。
これには以下の原因が考えられます。
keylogin が実行されていない (NIS+ 主体はデフォルトでは「未認証」になる)
NIS+ 以外のソースに対して keylogin が実行された
/etc/nsswitch.conf ファイルに publickey: nisplus エントリがあるかどうか確認する
これはおそらく認証エラーとなる
「症状」
fnlist に組織名を指定して実行しても何も表示されません。
「考えられる原因」
NIS+ の設定によって発生する問題です。下位組織は NIS+ ドメインでなければなりません。NIS+ ドメインには、org_dir というサブディレクトリが必要です。
「診断」
nisls コマンドを使用して、どんなサブディレクトリが存在するかを調べます。nisls をサブディレクトリごとに実行すれば、どのサブディレクトリに org_dir があるかを確かめることができます。org_dir のあるサブディレクトリが下位組織になります。
「対策」
NIS+ ドメインに、org_dir というサブディレクトリを作成します。
「症状」
fncreate -t を、user (または username)、または host (または hostname) を指定して実行しても何も起こりません。
「考えられる原因」
NIS_GROUP
環境変数が設定されていません。ユーザーコンテキストあるいはホストコンテキストを作成した際、所有権が名前空間を設定した管理者ではなく、ホストまたはユーザーにあったようです。したがって、fncreate を実行するには、NIS_GROUP
変数を設定して、グループ内の管理者によってコンテキストの操作が行えるようにする必要があります。
「診断」
NIS_GROUP
環境変数をチェックします。
「対策」
NIS_GROUP
環境変数に、コンテキストの管理者のグループ名を設定します。
「症状」
ホストコンテキストまたはユーザーコンテキストに対して fndestroy を実行しても、コンテキストが削除されません。
「考えられる原因」
ホストコンテキストまたはユーザーコンテキストの所有権を持っていないことです。ユーザーコンテキストあるいはホストコンテキストを作成した際、所有権が名前空間を設定した管理者ではなく、ホストまたはユーザーにあったようです。
「診断」
NIS_GROUP
環境変数をチェックします。
「対策」
NIS_GROUP
環境変数に、コンテキストの管理者のグループ名を設定します。
「症状」
バインデイングを削除しようとすると、「name in use」というメッセージが表示されます。指定する名前によってコマンドが正しく実行される場合と、そうでない場合があります。
「考えられる原因」
コンテキストの名前のバインドを解除できません。この制限は、名前のないコンテキスト (orphaned context) が残るような場合に適用されます。
「診断」
fnlist コマンドを実行し、fnunbind に指定しようとする名前がコンテキストのものかどうか確認します。
「対策」
名前がコンテキストのものであれば、fndestroy コマンドを使用してコンテキストを削除します。
「症状」
-s オプションをつけて fnbind および fncreate を実行すると、指定する名前によっては「name in use」というメッセージが表示されます。
「考えられる原因」
fnbind -s、および fncreate -s を実行すると、既存のバインディングは上書きされます。ただしそれによって orphaned context ができるような場合、「name in use」というエラーメッセージが表示され、この操作は失敗します。
「診断」
fnlist コマンドを実行して、fnbind、fncreate に指定しようとする名前がコンテキストのものかどうか確認します。
「対策」
fndestroy コマンドを実行してコンテキストを削除してから、fnbind または fncreate を (先にエラーになった場合と同じ名前を指定して) 実行します。
「症状」
実体のない名前を指定して fndestroy、fnunbind を実行しても、操作が失敗したことがまったく知らされない。
「考えられる原因」
fndestroy、fnunbind のセマンティクスが、「端末名がバインドされていなくても、操作が success を返す」というようになっているためだと考えられます。
「診断」
問題が発生した場合と同じ名前を指定して fnlookup コマンドを実行します。「name not found」というメッセージが表示されるはずです。
「対策」
考えられる現象を参照。