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

NIS はマップをサーバー間で伝播するので、ネットワーク上のさまざまな NIS サーバーに、同じマップの異なるバージョンが存在することがあります。 相違点が長時間継続しない場合には、このバージョンの違いは許容可能です。

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

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

• ypxfr 出力のログをとります (ypxfr 出力のログ を参照)。

• 制御ファイルをチェックします (crontab ファイルと ypxfr シェルスクリプトをチェックする を参照)。

• マスターサーバー上の ypservers マップをチェックする (ypservers マップをチェックするを参照)。

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 で展開されます。