test

Solaris のシステム管理 (ネーミングとディレクトリサービス : DNS、NIS、LDAP 編)

第 10 章 NIS の障害追跡

この章では、NIS を実行しているネットワーク上で発生する問題の解決方法について説明します。 NIS クライアントで発生する問題と、NIS サーバーで発生する問題を取り上げます。

NIS サーバーやクライアントで問題を解決しようとする前に、NIS 環境について説明している第 7 章「ネットワーク情報サービス (NIS) (概要)」を参照してください。 その後この節で、各問題を適切に解説している節を参照してください。

NIS のバインドに関する問題

症状

NIS のバインドに関する一般的な問題には、次のようなものがあります。

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

1 台か 2 台のクライアントだけで、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 コマンドを実行して、どのドメイン名が設定されているのかを調べます。 


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

注 –

セキュリティと管理の意味から、クライアントにブロードキャストを使ってサーバーを検索させるのではなく、クライアントの 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 台か 2 台のクライアントだけで、NIS のバインドに関する問題を示す症状が発生している場合は、そのクライアントに問題があると考えられます。 1 台のクライアントに影響する NIS の問題 を参照してください。 複数のクライアントが正しくバインドできない場合は、1 台以上の NIS サーバーに問題があると考えられます。

rpc.yppasswdd が r で始まる制限のないシェルを制限付きとみなしている

  1. 次のような特殊な文字列が含まれている /etc/default/yppasswdd を作成します。 "check_restricted_shell_name=1"

  2. 「check_restricted_shell_name=1」文字列をコメント扱いにすると、「r」のチェックは行われません。

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

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

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

サーバーの誤動作

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

NIS デーモンが実行されていない

サーバーが起動されていて実行中の場合には、クライアントマシンが正常に動作していることを調べて、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 サーバー間でダウンしている場合です。 すべての 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
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)。