Oracle® Solaris 11.2 ディレクトリサービスとネームサービスでの作業: DNS と NIS

印刷ビューの終了

更新: 2014 年 7 月
 
 

複数のクライアントに影響する NIS の問題

1 台か 2 台のクライアントだけで、NIS のバインドに関する問題を示す症状が発生している場合は、そのクライアントに問題があると考えられます。1 台のクライアントに影響する NIS の問題を参照してください。複数のクライアントが正しくバインドできない場合は、1 台以上の NIS サーバーに問題があると考えられます。

rpc.yppasswddr で始まる制限のないシェルを制限付きと見なしている

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

  2. 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 クライアント) のどちらのデーモンも実行されていない場合は、次のように入力してそれらを再起動します。

# svcadm restart network/nis/client

NIS サーバー上で ypserv プロセスと ypbind プロセスの両方が実行されている場合は、ypwhich コマンドを実行します。このコマンドが応答しない場合は、ypserv デーモンがおそらくハングアップしているため、再起動してください。サーバー上で root としてログインしている間に、次のように入力して NIS サービスを再起動します。

# svcadm restart network/nis/server

サーバーに別のバージョンの NIS マップが存在する

NIS はマップをサーバー間で伝播するので、ネットワーク上のさまざまな NIS サーバーに、同じマップの異なるバージョンが存在することがあります。このバージョンの不一致は、これらの違いが短時間しか続かなければ正常であり、許容可能です。

マップの不一致のもっとも一般的な原因は、マップの正常な伝播を妨げる何かが存在するためです。たとえば、NIS サーバーまたはルーターが、NIS サーバー間でダウンしている場合です。すべての NIS サーバーと、それらのサーバー間にあるルーターが実行されている場合、ypxfr は成功します。

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

ypxfr の出力のロギング

特定のスレーブサーバーでマップの更新に関する問題が発生した場合は、そのサーバーにログインし、ypxfr コマンドを対話的に実行します。このコマンドが失敗した場合は、失敗した理由が示されるため、問題を解決することができます。このコマンドは成功するが、ときどき失敗していたと思われる場合は、メッセージのロギングを有効にするためにログファイルを作成します。ログファイルを作成するには、スレーブ上で次のように入力します。

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

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

この出力は、ypxfr が対話形式で実行しているときに表示する出力と似ていますが、ログファイルの各行にはタイムスタンプが記録されます。(タイムスタンプが通常とは異なった順序になることがあります。これは問題ありません。タイムスタンプは、ypxfr が実行を開始した時間を示します。ypxfr の複数のコピーが同時に実行されたが、それらの動作時間が異なった場合は、各サマリーステータス行が、それぞれの起動順序とは異なる順序で実際にログファイルに書き込まれることがあります。)断続的に発生するあらゆる種類の障害がログに記録されます。


注 - 問題を解決したら、ログファイルを削除してログを停止します。削除し忘れた場合は、そのファイルが無制限に拡張し続けます。
crontab ファイルと ypxfr シェルスクリプトをチェックする

rootcrontab ファイルを調べ、それが起動する 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 上で展開されます。

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

使用中のマシンには、異なる複数のポート番号があることがあります。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

ここで、numberrpcinfo によって報告された ID 番号 (前の例では 100004) です。