test

Solaris ネーミングの管理

NIS の問題が多くのクライアントに影響している

1 つ以上のクライアントで、NIS バインディングの問題を示す現象が発生している場合には、それらクライアントに問題がある可能性があります (「1 つのクライアントに影響する NIS の問題」を参照)。多くのクライアントが正確にバインドできなくなっている場合には、1 つ以上の NIS サーバーに問題がある可能性があります。

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

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

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

サーバーの誤動作

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

NIS デーモンを実行していない

サーバーが起動して実行中である場合には、クライアントマシンが正常に動作していることを調べて、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 サーバー間でダウンしている場合です。すべての NIS サーバーとそれらの間に存在するルーターが実行中の場合には、ypxfr は成功します。

サーバーとルーターが正常に機能している場合には、以下をチェックします。

ypxfr 出力のログ

特定のスレーブサーバーで、マップの更新に問題がある場合には、そのサーバーにログインして、ypxfr を対話形式で実行します。ypxfr が失敗すると、ypxfr がその失敗を通知するので、問題の修正が可能になります。ypxfr が成功しても、時々失敗するような場合には、メッセージのログを取るためにログファイルを作成します。ログファイルを作成するには、次のように入力します。 

ypslave# cd /var/yp 
ypslave# touch ypxfr.log

これによって、ypxfr からのすべての出力を保存する ypxfr.log ファイルが作成されます。

対話形式で実行中の出力 ypxfr の表示に出力は類似しますが、ログファイルの各行にタイムスタンプが押されます。タイムスタンプは、通常とは異なる順番になりますが、問題はありません。タイムスタンプは、ypxfr が実行し始めたことを示します。ypxfr のコピーが同時に実行しても、作業時間が異なる場合には、起動元とは異なる順番でサマリーステータス行をログファイルに記述していることがあります。任意の型の失敗が、断続的にログに示されます。

注 -

問題を解決したら、ログファイルを削除してログを停止します。削除しないと、ログは制限なく大きくなります。

crontab ファイルと ypxfr シェルスクリプトをチェックする

ルートの 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

このエントリがなく、ypserv がそのサービスを rpcbind で登録できない場合には、マシンを再起動してください。これらのエントリがある場合には、rpcbind からサービスの登録を解除してから、ypserv を再起動します。rpcbind からサービスの登録を解除するには、サーバーで次のように入力します。

# rpcinfo -d number 1 
# rpcinfo -d number 2

この場合 number は、rpcinfo によって通知される ID 番号です (前述の例では、100004)。