1 台か 2 台のクライアントだけで、NIS のバインドに関する問題を示す症状が発生している場合は、そのクライアントに問題があると考えられます。 1 台のクライアントに影響する NIS の問題 を参照してください。 複数のクライアントが正しくバインドできない場合は、1 台以上の NIS サーバーに問題があると考えられます。
次のような特殊な文字列が含まれている /etc/default/yppasswdd を作成します。 "check_restricted_shell_name=1"
「check_restricted_shell_name=1」文字列をコメント扱いにすると、「r」のチェックは行われません。
ネットワークまたは NIS サーバーが過負荷状態で、クライアント ypbind プロセスに ypserv が時間以内に応答を戻せない場合には、NIS がハングする場合があります。
こういった状態では、ネットワーク上のすべてのクライアントで同じまたは類似した問題が発生します。 ほとんどの場合、この状態は一時的です。 NIS サーバーが再起動して ypserv を再起動するか、または NIS サーバーまたはネットワーク自体の負荷が減少すると、通常、メッセージは消えます。
サーバーが起動して実行中であることを確認してください。 サーバーが物理的に近くにない場合には、ping コマンドを使ってください。
サーバーが起動されていて実行中の場合には、クライアントマシンが正常に動作していることを調べて、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 サーバーとそれらの間に存在するルーターが実行中の場合には、ypxfr は成功します。
サーバーとルーターが正常に機能している場合には、次のことをチェックします。
ypxfr 出力のログをとります (ypxfr 出力のログ を参照)。
制御ファイルをチェックします (crontab ファイルと ypxfr シェルスクリプトをチェックする を参照)。
マスターサーバー上の ypservers マップをチェックする (ypservers マップをチェックするを参照)。
特定のスレーブサーバーでマップの更新に問題がある場合には、そのサーバーにログインして ypxfr を対話形式で実行します。 ypxfr が失敗すると ypxfr がその理由を通知するので、問題の修正が可能になります。 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 スレーブサーバーの問題が明白ではない場合には、rcp または ftp を使ってデバッグし、一貫性のないマップの最新バージョンを問題のない NIS サーバーからコピーして問題を解決できます。 以下に問題のあるマップを転送する方法を示します。
ypslave# rcp ypmaster:/var/yp/mydomain/map.\* /var/yp/mydomain |
* の文字はコマンド行でエスケープされて、ypslave でローカルにではなく ypmaster で展開されます。
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)。