この章では、NIS を実行しているネットワーク上で発生する問題の解決方法について説明します。NIS クライアントで発生する問題と、NIS サーバーで発生する問題を取り上げます。
NIS サーバーやクライアントで問題を解決しようとする前に、NIS 環境について説明している第 7 章「ネットワーク情報サービス (NIS) (概要)」を参照してください。その後この節で、各問題を適切に解説している節を参照してください。
NIS のバインドに関する一般的な問題には、次のようなものがあります。
クライアントのコマンドがバックグランドモードでゆっくりと処理されているか、通常よりも機能に時間がかかる
クライアントのコマンドがハングする。システム全体は正常で新しいコマンド を実行できる場合でも、コマンドがハングすることがある
クライアントのコマンドがあいまいなメッセージとともに、またはまったくメッセージなしでクラッシュする
NIS のバインドに関する問題を示す症状が、1 台か 2 台のクライアントだけで発生している場合には、問題は多くの場合クライアントにあります。多くの 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 コマンドを実行して、どのドメイン名が設定されているのかを調べます。
client7# domainname neverland.com
NIS のマスターサーバー上の /var/yp 内の実際のドメイン名と、出力を比較します。実際の NIS ドメインは、/var/yp ディレクトリ内のサブディレクトリとして表示されます。
Client7# 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 を数回実行します。通常、1 回目ではドメインがバインドされていないことが通知され、2 回目は成功します。
ドメイン名が正しく設定されていて ypbind が実行中のときに、クライアントがサーバーと通信できないというメッセージを受け取った場合には、いくつかの問題が考えられます。
バインドするサーバーのリストを含む /var/yp/binding/domainname/ypservers ファイルがクライアントにあるかどうかを確認します。ない場合には、ypinit -c を実行して、設定の順番にクライアントのバインド先のサーバーを指定します。
クライアントに /var/yp/binding/domainname/ypservers ファイルがあり、1 台か 2 台のサーバーが使用できない場合には、十分な数のサーバーがあるかどうかを調べます。ない場合には、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 オプションを使用するためには、-ypset または -ypsetme オプションのどちらかを指定して ypbind を実行する必要があります。
セキュリティ上の理由から、-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 を再起動しようとするたびにそれらのプロセスが変更される場合は、rpcbind デーモンが実行中であってもシステムをリブートをしてください。
1 台か 2 台のクライアントだけで、NIS のバインドに関する問題を示す症状が発生している場合は、そのクライアントに問題があると考えられます。1 台のクライアントに影響する NIS の問題を参照してください。複数のクライアントが正しくバインドできない場合は、1 台以上の NIS サーバーに問題があると考えられます。
次のような特殊な文字列が含まれている /etc/default/yppasswdd を作成します。 check_restricted_shell_name=1
「check_restricted_shell_name=1」文字列をコメント扱いにすると、「r」のチェックは行われません。
ネットワークまたは NIS サーバーが過負荷状態で、ypserv が指定時間内にクライアントの ypbind プロセスに応答を戻せない場合は、NIS がハングする可能性があります。
こういった状態では、ネットワーク上のすべてのクライアントで同じまたは類似した問題が発生します。ほとんどの場合、この状態は一時的です。NIS サーバーをリブートして ypserv を再起動するか、NIS サーバーまたはネットワーク自体の負荷が減少すると、メッセージは通常消えます。
サーバーが起動して実行中であることを確認してください。サーバーが物理的に近くにない場合には、ping コマンドを使ってください。
サーバーが起動されていて実行中の場合には、クライアントマシンが正常に動作していることを調べて、ypwhich コマンドを実行します。ypwhich が応答しない場合は、そのコマンドを強制終了します。次に、NIS サーバーで root としてログインし、次のように入力して 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 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 |
エントリが 1 つもなく、ypserv がそのサービスを rpcbind で登録できない場合にはマシンをリブートしてください。エントリがある場合には、rpcbind からサービスの登録を解除してから ypserv を再起動します。rpcbind からサービ スの登録を解除するには、サーバーで次のように入力します。
# rpcinfo -d number 1
# rpcinfo -d number 2
number は、rpcinfo によって通知される ID 番号です (前述の例では、100004)。