test

Solaris ネーミングの管理

付録 A 問題と解決方法

この章では、Solaris 7 リリースの名前空間を管理する際に発生する可能性のある問題のいくつかを説明します。

NIS+ の問題解決

この章は問題のタイプで分類されています。各問題には、一般的な現象、問題の説明、および対策が示されています。この章の他に、NIS+ のさらに一般的なエラーメッセージをアルファベット順に表示した付録があります。エラーメッセージが特定できていれば、最初に付録 B 「エラーメッセージ」 を参照してください。問題が簡単か、または 1 つのエラーメッセージに特定できる場合には、その対策は付録 B 「エラーメッセージ」 に掲載されています。

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

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

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

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

表 A-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 コマンドによって生成されるのと同じフォーマットで、優先サーバーを指定する (表 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" 

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 は doc.com. のクライアントであり、subdoc.doc.com. のクライアントではないので、sirius.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. 複製上の /var/nis/rep/serving_list で org_dir.domain が表示されないことを確認してください。

  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+ データベースの問題

この節では、名前空間のデータベースとテーブルに関連する問題を説明します。一般的な症状には次のようなものがあります。

「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 7 リリース のマシン上で、ユーザーまたはシステム管理者が 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 となります。

/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+ コマンドはエントリレベルでのリンクは追跡しません。

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

この節では、ユーザーの所有権とアクセス権に関連する問題を説明します。

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

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

アクセス権がない

アクセス権に関連して最も頻繁に発生する問題は、最も単純な問題です。行おうとしている業務に必要なアクセス権が、割り当てられていません。対象としているオブジェクトを指定して niscat -o を使用し、どのアクセス権が割り当てられているか確認します。他のアクセス権も必要な場合は、ユーザー自身、オブジェクトの所有者、システム管理者のうちの誰かが、そのオブジェクトのアクセス権の変更を行うことができます。詳細は、第 10 章「NIS+ のアクセス権の管理」と、第 12 章「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」メッセージの原因としては他に以下のようなものが考えられます。

パスワードについては、第 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. ドメインのマスターサーバーになっているという場合を考えてみましょう。

図 A-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 コマンドによって NIS+ テーブル (cred テーブルを含む) が新しい複製サーバーにダウンロードされます。これによって、元のサーバーの公開鍵も複製サーバーの cred テーブルに保存されます。

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

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

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

表 A-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 テーブルより古い場合は、ファイルがあらかじめ存在していたことが考えられます。

「対策」

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

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

「症状」

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

「考えられる原因」

注 -

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

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

「対策」

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

注意 - 注意 -

NIS+ の名前空間の設定が終わり、すでに動作している状態でも、ルートマスターのマシンを使ってルートのパスワードを変更することは可能です。しかし、ルートマスターの鍵は変更しないでください。これらは、サブドメイン内のすべてのクライアント、複製サーバー、サーバーの中のすべてのディレクトリオブジェクトに埋め込まれているからです。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+ の問題を取り上げます。

ユーザーの問題

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

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

これ以外の設定をすると、ユーザーがログインできなくなります (詳細は、「nsswitch.conf ファイルの必要条件」を参照)。

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

「症状」

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

「考えられる原因」

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

「症状」

ユーザーが 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(4) のマニュアルページを参照してください。

NIS の問題と対策

この節では、NIS を実行中のネットワーク上で発生する問題の解決方法を説明します。NIS クライアントで見うけられる問題と、NIS サーバーで見うけられるものを説明します。

NIS サーバーやクライアントをデバッグする前に、第 18 章「ネットワーク情報サービス (NIS)」を参照してください。その後で、この節で、問題を適切に解説する項を参照してください。

症状

一般的な NIS バインディングの問題には次のようなものがあります。

1 つのクライアントに影響する NIS の問題

NIS バインディングの問題を示す現象が、1 つ以上のクライアントで発生している場合には、問題はクライアントにあります。多くの NIS クライアントが、プロパティを正確にバインドできない場合には、問題は 1 つ以上の NIS サーバーにある可能性があります。「NIS の問題が多くのクライアントに影響している」を参照してください。

ypbind がクライアントで実行されていない

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 が実行中で、クライアントがサーバーと通信できないというメッセージを受け取った場合には、いくつかの問題があります。

注 -

セキュリティと管理の意味から、クライアントにブロードキャストを使ってサーバーを検索させるのではなく、クライアントの ypservers ファイルでクライアントのバインド先のサーバーを指定してください。ブロードキャストは、ネットワークを結合して、クライアントの速度を落とします。異なるクライアントに対して、異なるサーバーをリストすることによって、サーバー負荷の均衡がとれなくなります。

ypwhich の表示に一貫性がない

ypwhich を同じクライアントで数回使うと、NIS サーバーが変わるので結果の表示が異なります。これは正常な状態です。NIS クライアントから NIS サーバーへのバインディングは、ネットワークや NIS サーバーを使用中の場合は時間の経過に伴って変化します。ネットワークは、すべてのクライアントが受け入れ可能な応答を NIS サーバーから受信した時点で安定します。クライアントのマシンが NIS サービスを得ているかぎりは、サービスの供給元は問題にはなりません。たとえば、NIS サーバーマシンがそれ自体の NIS サービスを、ネットワーク上の別の NIS サーバーから受けることがあります。

サーバーのバインディングが不可能な場合

サーバーのバインディングが不可能な場合には、ypset コマンドを使えます。別のネットワークまたはサブネットの別のサーバーが使用可能な場合には、そのサーバーへのバインディングが一時的に可能になります。ただし、-ypset オプションを使用するためには、ypbind を -ypset または -ypsetme オプションのどちらかを指定して、実行する必要があります。

注 -

セキュリティの目的のために、-ypset と -ypsetme のオプションの使用は、制御された状態でのデバッグだけに限定してください。-ypset と -ypsetme のオプションの使用によって、セキュリティが侵害される恐れがあります。これらを実行中は、サーバーのバインディングをだれでも変更でき、他のユーザーを妨害したり、重要なデータへの未承認のアクセスが認められるためです。これらのオプションで ypbind を起動する場合には、いったん問題を確定したら、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 を再起動しようとするたびに変更します。

NIS の問題が多くのクライアントに影響している

1 つ以上のクライアントで、NIS バインディングの問題を示す現象が発生している場合には、それらクライアントに問題がある可能性があります (「1 つのクライアントに影響する NIS の問題」を参照)。多くのクライアントが正確にバインドできなくなっている場合には、1 つ以上の NIS サーバーに問題がある可能性があります。

ネットワークまたはサーバーが過負荷

ネットワークまたは NIS サーバーが過負荷状態で、クライアント ypbind プロセスに ypserv が時間以内に応答を戻せない場合には、NIS がハングする場合があります。

こういった状態では、ネットワーク上のすべてのクライアントで同じまたは類似した問題が発生します。ほとんどの場合に、この状態は一時的です。NIS サーバーが再起動して ypserv を再起動するか、または NIS サーバーまたはネットワーク自体の負荷が減少すると、通常、メッセージは消えます。

サーバーの誤動作

サーバーが起動して実行中であることを確認してください。サーバーが物理的に近くにない場合には、ping コマンドを使ってください。

NIS デーモンを実行していない

サーバーが起動して実行中である場合には、クライアントマシンが正常に動作していることを調べて、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 サーバー間でダウンしている場合です。すべての NIS サーバーとそれらの間に存在するルーターが実行中の場合には、ypxfr は成功します。

サーバーとルーターが正常に機能している場合には、以下をチェックします。

ypxfr 出力のログ

特定のスレーブサーバーで、マップの更新に問題がある場合には、そのサーバーにログインして、ypxfr を対話形式で実行します。ypxfr が失敗すると、ypxfr がその失敗を通知するので、問題の修正が可能になります。ypxfr が成功しても、時々失敗するような場合には、メッセージのログを取るためにログファイルを作成します。ログファイルを作成するには、次のように入力します。 


ypslave# cd /var/yp
ypslave# touch ypxfr.log

これによって、ypxfr からのすべての出力を保存する ypxfr.log ファイルが作成されます。

対話形式で実行中の出力 ypxfr の表示に出力は類似しますが、ログファイルの各行にタイムスタンプが押されます。タイムスタンプは、通常とは異なる順番になりますが、問題はありません。タイムスタンプは、ypxfr が実行し始めたことを示します。ypxfr のコピーが同時に実行しても、作業時間が異なる場合には、起動元とは異なる順番でサマリーステータス行をログファイルに記述していることがあります。任意の型の失敗が、断続的にログに示されます。

注 -

問題を解決したら、ログファイルを削除してログを停止します。削除しないと、ログは制限なく大きくなります。

crontab ファイルと ypxfr シェルスクリプトをチェックする

root の crontab ファイルを調べて、それが起動した ypxfr シェルスクリプトをチェックします。これらファイルにタイプミスがあると、伝播の問題が発生します。/var/spool/cron/crontabs/root ファイル内でシェルスクリプトを参照できないか、または任意のシェルスクリプト内でマップを参照できない場合にも、エラーが発生します。

ypservers マップをチェックする

NIS スレーブサーバーが、ドメインに対するマスターサーバー上の ypservers マップにリストされていることも確認してください。リストされていない場合には、スレーブサーバーはサーバーとして正しく機能しますが、yppush はマップの変更をスレーブサーバーに伝播しません。

対策

NIS スレーブサーバーの問題が明白ではない場合には、その問題を回避できます。その一方で、rcp または ftp を使ってデバッグし、一貫性のないマップの最新バージョンを問題のない NIS サーバーからコピーできます。たとえば、次のように問題のあるマップを転送します。 


ypslave# rcp ypmaster:/var/yp/ mydomain/map.¥* /var/yp/ mydomain

この場合 * の文字は、コマンド行でエスケープされて、ypslave でローカルにではなく、ypmaster で拡張されます。

ypserv のクラッシュ

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 の問題とその対策を説明します。

クライアントはマシンを見つけられるが、サーバーはできない

「症状」

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 のシリアル番号と副サーバー上の対応するファイルをチェックします。

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 アドレスが、hosts ファイルで指定されたマスターに対するアドレスとマスターの実際の IP アドレスと一致することを確認してください。IP アドレスが誤っている場合には、それを修正してから副サーバーを再起動します。


% ping 129.146.168.119 -n 10

rlogin、rsh、ftp の問題

「症状」

「考えられる原因」

「診断と対策」

適切な 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 データを強制的に再読み込みさせる」で説明するとおりに、そのデータを再ロードします。

その他の DNS 構文エラー

「症状」

次のような言い回しを伴ったコンソールまたは syslog のエラーメッセージは、たいてい DNS データとブートファイルの構文エラーによって発生します。

関連ファイルでスペルと構文のエラーをチェックしてください。

一般的な構文エラーは、ドメイン名で後ろに付く点 (ドット) の誤用 (禁じられている場合に使い、必要な場合に使わないなど) に起因します。「ドメイン名の終わりにつけるドット」を参照してください。

FNS の問題と対策

この節では、問題と共に、考えられる原因、診断、対策を示します。

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」というメッセージが表示される (FNS)

「症状」

「no permission」というメッセージが表示されます。

「考えられる原因」

このメッセージは、「コマンドを実行しようとしたが、アクセス権がない」ということを意味します。

「診断」

適切な NIS+ コマンドを使用してアクセス権を確認します (「FNS と NIS+ の詳細情報」を参照)。NIS+ 主体名は、nisdefaults コマンドで知ることができます。

また、使用している名前が正しいかどうかも確認する必要があります。たとえば、ルート組織のコンテキスト名は、org// を使用して決定します。ルート組織を操作する権限があるかどうか確認してください。myorgunit/ を指定する場合もあります。

「対策」

アクセス権が正しく設定されているにもかかわらずこのメッセージが表示される場合は、適切な資格が与えられていない可能性があります。

これには以下の原因が考えられます。

fnlist で下位組織のリストが表示されない

「症状」

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 環境変数に、コンテキストの管理者のグループ名を設定します。

fnunbind を実行すると「name in use」というメッセージが表示される

「症状」

バインデイングを削除しようとすると、「name in use」というメッセージが表示されます。指定する名前によってコマンドが正しく実行される場合と、そうでない場合があります。

「考えられる原因」

コンテキストの名前のバインドを解除できません。この制限は、名前のないコンテキスト (orphaned context) が残るような場合に適用されます。

「診断」

fnlist コマンドを実行し、fnunbind に指定しようとする名前がコンテキストのものかどうか確認します。

「対策」

名前がコンテキストのものであれば、fndestroy コマンドを使用してコンテキストを削除します。

fnbind/fncreate -s を実行すると「name in use」というメッセージが表示される

「症状」

-s オプションをつけて fnbind および fncreate を実行すると、指定する名前によっては「name in use」というメッセージが表示されます。

「考えられる原因」

fnbind -s、および fncreate -s を実行すると、既存のバインディングは上書きされます。ただしそれによって orphaned context ができるような場合、「name in use」というエラーメッセージが表示され、この操作は失敗します。

「診断」

fnlist コマンドを実行して、fnbind、fncreate に指定しようとする名前がコンテキストのものかどうか確認します。

「対策」

fndestroy コマンドを実行してコンテキストを削除してから、fnbind または fncreate を (先にエラーになった場合と同じ名前を指定して) 実行します。

実体のない名前を指定して fndestroy / fnunbind を実行しても「Operation Failed」が返らない

「症状」

実体のない名前を指定して fndestroy、fnunbind を実行しても、操作が失敗したことがまったく知らされない。

「考えられる原因」

fndestroy、fnunbind のセマンティクスが、「端末名がバインドされていなくても、操作が success を返す」というようになっているためだと考えられます。

「診断」

問題が発生した場合と同じ名前を指定して fnlookup コマンドを実行します。「name not found」というメッセージが表示されるはずです。

「対策」

考えられる現象を参照。