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 はまた、ネットワークがダウンしている場合にもハングアップすることがあります。
こういった状態では、ネットワーク上のすべてのクライアントで同じまたは類似した問題が発生します。ほとんどの場合、この状態は一時的です。これらのメッセージは通常、NIS サーバーがリブートして ypserv を再起動するか、NIS サーバー上またはネットワーク自体の負荷が減るか、またはネットワークが正常な動作を再開すると消えます。
サーバーが起動され、実行されていることを確認します。サーバーが物理的に近くにない場合には、ping コマンドを使ってください。
サーバーが起動されていて実行中の場合には、クライアントマシンが正常に動作していることを調べて、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 サーバーと、それらのサーバー間にあるルーターが実行されている場合、ypxfr は成功します。
サーバーとルーターが正常に機能している場合には、次のことをチェックします。
ypxfr のログ出力をチェックします。ypxfr の出力のロギングを参照してください。
svc:/network/nis/xfr:default ログファイルにエラーが表示されていないかどうかをチェックします。
制御ファイルをチェックします。crontab ファイルと ypxfr シェルスクリプトをチェックするを参照してください。
マスターサーバー上の ypservers マップをチェックします。(ypservers マップをチェックするを参照)。
特定のスレーブサーバーでマップの更新に関する問題が発生した場合は、そのサーバーにログインし、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 スレーブサーバーの問題が明らかでない場合は、scp または ssh コマンドを使用して、一貫性のないマップの最新バージョンをいずれかの正常な NIS サーバーからコピーすることによって、問題のデバッグ中に回避方法を実行できます。次に、問題のあるマップを転送する方法を示します。
ypslave# scp ypmaster:/var/yp/mydomain/map.\* /var/yp/mydomain
* の文字はコマンド行でエスケープされているため、ypslave 上でローカルにではなく、ypmaster 上で展開されます。
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
ここで、number は rpcinfo によって報告された ID 番号 (前の例では 100004) です。