1 台か 2 台のクライアントだけで、NIS のバインドに関する問題を示す症状が発生している場合は、そのクライアントに問題があると考えられます。単一クライアントに影響を与える NIS の問題のトラブルシューティングを参照してください。ただし、複数の NIS クライアントが正常にバインドできない場合は、1 台以上の NIS サーバーで問題が発生している可能性がもっとも高くなります。
次に示すのは、複数のクライアントに影響を与える可能性のある一般的な NIS の問題です。
rpc.yppasswdd が r で始まる制限のないシェルを制限付きと見なしている
この問題を解決するには、次の手順を実行します。
"check_restricted_shell_name=1" という特殊な文字列を含む /etc/default/yppasswdd ファイルを作成します。
"check_restricted_shell_name=1" の文字列がコメントアウトされている場合、r の確認は実行されません。
ネットワークまたはサーバーに接続できない
ネットワークまたは NIS サーバーがあまりにも過負荷であるために、ypserv デーモンがクライアントの ypbind プロセスから返された応答をタイムアウト期間以内に受信できない場合は、NIS がハングアップすることがあります。NIS はまた、ネットワークがダウンしている場合にもハングアップすることがあります。
このどちらの状況でも、ネットワーク上のすべてのクライアントで同じか、または同様の問題が発生します。ほとんどの場合、この状態は一時的です。これらのメッセージは通常、NIS サーバーが ypserv デーモンをリブートおよび再起動するか、NIS サーバー上またはネットワーク自体の負荷が減るか、またはネットワークが通常の動作を再開すると消えます。
サーバーの誤動作
サーバーが起動され、実行されていることを確認します。サーバーに物理的に近い場所にいない場合は、ping コマンドを使用して、サーバーに接続できるかどうかを確認します。
NIS デーモンが実行されていない
サーバーが起動および実行されている場合は、正常に動作しているクライアントを見つけて、そのクライアント上で ypwhich コマンドを実行してみてください。ypwhich コマンドが応答しない場合は、強制終了します。次に、NIS サーバー上で root 役割になり、NIS プロセスが実行されているかどうかを次のように確認します。
# ptree |grep ypbind 100759 /usr/lib/netsvc/yp/ypbind -broadcast 527360 grep yp
ypserv デーモン (NIS サーバー) も ypbind デーモン (NIS クライアント) デーモンも実行されていない場合は、これらのデーモンを次のように再起動します。
NIS クライアントサービスを次のように再起動します。
# svcadm restart network/nis/client
NIS サーバー上で ypserv プロセスと ypbind プロセスの両方が実行されている場合は、ypwhich コマンドを実行します。このコマンドが応答しない場合、ypserv デーモンはおそらくハングアップしているため、再起動してください。
サーバー上で、NIS サービスを次のように再起動します。
# svcadm restart network/nis/server
サーバーに NIS マップの異なるバージョンが存在する
NIS はサーバー間でマップを伝播するため、ネットワーク上の各種の NIS サーバー上に同じマップの異なるバージョンが見つかる場合があります。このバージョンの不一致は、その違いがそれほど長く続かなければ正常であり、受け入れ可能です。
マップの不一致のもっとも一般的な原因は、マップの正常な伝播が妨げられている場合です。たとえば、NIS サーバーまたは NIS サーバー間に配置されているルーターが停止している場合があります。すべての NIS サーバーおよび NIS サーバー間のルーターが実行されている場合、ypxfr コマンドは成功します。
サーバーおよびルーターが正常に機能している場合は、次のように処理を続行します。
ypxfr のログ出力をチェックします。Example 3–1 を参照してください。
svc:/network/nis/xfr:default ログファイルにエラーが表示されていないかどうかをチェックします。
制御ファイル (crontab ファイルと yupxfr シェルスクリプト) を確認します。
マスターサーバー上の ypservers マップをチェックします。
ypserv プロセスがクラッシュする
ypserv プロセスがほぼ即座にクラッシュし、起動を繰り返しても安定しない場合、デバッグプロセスは、ypbind のクラッシュに対するデバッグプロセスとほぼ同じです。
まず、次のコマンドを実行して、何らかのエラーが報告されているかどうかを確認します。
# svcs -vx nis/server
rpcbind デーモンが存在するかどうかを、次のようにチェックします。
# ptree |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
前の例では、次の 4 つのエントリが ypserv プロセスを表しています。
100004 2 udp 731 ypserv 100004 1 udp 731 ypserv 100004 1 tcp 732 ypserv 100004 2 tcp 32772 ypserv
これらのエントリが存在せず、ypserv がそのサービスを rpcbind に登録できない場合は、システムをリブートします。エントリが存在する場合は、ypserv を再起動する前に rpcbind からこのサービスの登録を解除します。たとえば、次のようにして rpcbind からこのサービスの登録を解除します。
# rpcinfo -d number 1 # rpcinfo -d number 2
ここで、number は rpcinfo によって報告された ID 番号 (前の例では 100004) です。
特定のスレーブサーバーでマップの更新に関する問題が発生している場合は、そのサーバーにログインし、ypxfr コマンドを対話的に実行します。
このコマンドが失敗した場合は、失敗した原因に関するメッセージが表示され、その問題を修正できるようになります。このコマンドは成功するが、失敗した場合もあったと疑われる場合は、次のように、そのスレーブサーバー上にログファイルを作成してメッセージのロギングを有効にします。
ypslave# cd /var/yp ypslave# touch ypxfr.log
このログファイルの出力は、ypxfr コマンドを対話的に実行したときの出力に似ていますが、ログファイル内の各行にはタイムスタンプが記録される点が異なります。タイムスタンプの順序が異常なことに気付いた場合、それは、ログには ypxfr コマンドが実際に実行された各時間が示されているためです。ypxfr の複数のコピーが同時に実行されたが、その完了にかかった時間が異なる場合は、各コピーによって、そのコマンドが実行されたのとは異なる順序でサマリーステータス行がログファイルに書き込まれる可能性があります。断続的に発生するあらゆる種類の障害がログに記録されます。
crontab ファイルと ypxfr シェルスクリプトを確認します。
root crontab ファイルを検査し、そのファイルが起動した ypxfr シェルスクリプトを確認します。これらファイルにタイプミスがあると、伝播に関する問題が発生します。/var/spool/cron/crontabs/root ファイル内でシェルスクリプトを参照できない場合のほか、いずれかのシェルスクリプト内でマップを参照できない場合にもエラーが発生することがあります。
ypservers マップを確認します。
また、NIS スレーブサーバーが、そのドメインのマスターサーバー上の ypservers マップに記載されていることも確認してください。記載されていない場合でも、スレーブサーバーは引き続きサーバーとして完全に動作しますが、yppush はマップの変更をそのスレーブサーバーに伝播しません。
壊れたスレーブサーバー上のマップを更新します。
NIS スレーブサーバーの問題が明らかでない場合は、scp または ssh コマンドを使用して、問題のデバッグ中に回避方法を実行できます。これらのコマンドは、一貫性のないマップの最新バージョンをいずれかの正常な NIS サーバーからコピーします。
次の例は、問題のあるマップを転送する方法を示しています。
ypslave# scp ypmaster:/var/yp/mydomain/map.\* /var/yp/mydomain
前の例では、* 文字がコマンド行でエスケープされ、それがローカルに ypslave でではなく、ypmaster で展開されるようにしています。