test

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

複数のクライアントに影響する 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 プロセスが実行中かどうかをチェックします。


# ps -e | grep yp
注 –

-f オプションを ps で使用しないでください。このオプションはユーザー ID を名前に変換しようとするため、より多くのネームサービス検索が失敗する可能性があります。

NIS サーバーデーモン (ypserv) も NIS クライアントデーモン (ypbind) も実行されていない場合、次のいずれかを入力してデーモンを再起動します。


# svcadm restart network/nis/server
or
# /usr/lib/netsvc/yp/ypstop
# /usr/lib/netsvc/yp/ypstart

ypbind と ypserv の両プロセスが NIS サーバーで実行中の場合は、ypwhich を実行します。ypwhich が応答しない場合は、ypserv がハングしたと考えられるため再起動が必要です。サーバーに root としてログインし、次のいずれかを入力して NIS サービスを再起動します。


# svcadm restart network/nis/server
or
# /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)。