この節では、NIS を実行中のネットワーク上で発生する問題の解決方法を説明します。NIS クライアントで見うけられる問題と、NIS サーバーで見うけられるものを説明します。
NIS サーバーやクライアントをデバッグする前に、第 17 章「ネットワーク情報サービス (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 と -ypbind のオプションの使用は、制御された状態でのデバッグだけに限定してください。-ypset と -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 を再起動しようとするたびに変更します。
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 のコピーが同時に実行しても、作業時間が異なる場合には、起動元とは異なる順番でサマリーステータス行をログファイルに記述していることがあります。任意の型の失敗が、断続的にログに示されます。
問題を解決したら、ログファイルを削除してログを停止します。削除しないと、ログは制限なく大きくなります。
ルートの 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 100000 4 tcp 111 portmapper 100000 3 tcp 111 portmapper 100068 2 udp 32813 cmsd ... 100007 1 tcp 34900 ypbind 100004 2 udp 731 ypserv 100004 1 udp 731 ypserv 100004 1 tcp 732 ypserv 100004 2 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)。