Go to main content
Oracle® Solaris 11.3 でのネットワーク管理のトラブルシューティング

印刷ビューの終了

更新: 2016 年 11 月
 
 

NIS の問題のトラブルシューティング

以降の情報では、ネットワーク情報サービス (NIS) (このガイドでは「niss」と呼びます) に関する問題をデバッグする方法について説明します。NIS サーバーまたはクライアントの問題をデバッグしようとする前に、Oracle Solaris 11.3 ディレクトリサービスとネームサービスでの作業: DNS と NIS の 第 5 章, ネットワーク情報サービスについてを確認してください。

NIS のバインドに関する問題のトラブルシューティング

    NIS のバインドに関する問題の一般的な現象を次に示します。

  • ypbind デーモンでサーバーが見つからないか、またはサーバーと通信できないというメッセージ。

  • サーバーが応答していないというメッセージ。

  • NIS が使用できないというメッセージ。

  • クライアント上のコマンドがバックグラウンドモードでゆっくり実行されるか、または通常よりはるかに低速である。

  • クライアント上のコマンドがハングアップする。システムが全体としては正常であり、新しいコマンドも実行できるにもかかわらず、コマンドがハングアップする場合がある。

  • クライアント上のコマンドが不明瞭なメッセージで、または何もメッセージを表示せずにクラッシュする。

単一の NIS クライアントに影響を与える問題のトラブルシューティング

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

    次に示すのは、単一クライアントに影響を与える一般的な NIS の問題です。

  • ypbind デーモンがクライアント上で実行されていない

    あるクライアントに問題がありますが、同じサブネット上のその他のクライアントは正常に動作しています。問題のあるクライアント上で、そのクライアントの /etc/passwd ファイル内に存在しないファイルを含む、多数のユーザーによって所有されているファイルが含まれているディレクトリ (/usr など) で ls –l コマンドを実行します。その結果の表示に、ローカルの /etc/passwd ファイル内に存在しないファイルの所有者が名前ではなく、番号として含まれている場合は、そのクライアント上で NIS サービスは動作していません。

    これらの現象は通常、クライアントの ypbind プロセスが実行されていないことを示します。NIS クライアントサービスが実行されているかどうかを次のように確認します。

    client# svcs \*nis\*
STATE          STIME    FMRI
disabled       Sep_01   svc:/network/nis/domain:default
disabled       Sep_01   svc:/network/nis/client:default

    これらのサービスが disabled 状態にある場合は、ログインして root 役割になり、NIS クライアントサービスを次のように開始します。

    client# svcadm enable network/nis/domain
client# svcadm enable network/nis/client

  • ドメイン名がないか、または正しくない

    あるクライアントに問題があり、その他のクライアントは正常に動作していますが、そのクライアント上で ypbind デーモンが実行されています。この場合は、そのクライアントでドメインが間違って設定されている可能性があります。

    そのクライアント上で domainname コマンドを実行して、どのドメイン名が設定されているかを確認します。

    client# domainname
example.com

    その出力を、NIS マスターサーバー上の /var/yp ディレクトリ内の実際のドメイン名と比較します。次の例に示すように、実際の NIS ドメインは /var/yp ディレクトリ内のサブディレクトリとして表示されます。

    client# ls -l /var/yp
-rwxr-xr-x 1 root Makefile
drwxr-xr-x 2 root binding
drwx------ 2 root example.com

    NIS クライアント上の domainname コマンドの出力に表示されたドメイン名が、/var/yp ディレクトリ内のサブディレクトリとして表示されたサーバードメイン名と同じでない場合は、nis/domain サービスの config/domain プロパティー内のドメイン名が正しくありません。NIS ドメイン名をリセットします。手順については、Oracle Solaris 11.3 ディレクトリサービスとネームサービスでの作業: DNS と NIS の マシンの NIS ドメイン名を設定する方法を参照してください。

    注 -  NIS ドメイン名では大文字と小文字が区別されます。

  • NIS クライアントがサーバーにバインドされない

    ドメイン名が正しく設定され、ypbind デーモンが実行されているにもかかわらず、依然としてコマンドがハングアップする場合は、ypwhich コマンドを実行することによって、クライアントがサーバーにバインドされていることを確認してください。直前に ypbind デーモンを起動した場合は、ypwhich コマンドを実行します。ypwhich コマンドを複数回実行することが必要になる場合があります。通常、このコマンドをはじめて実行した場合は、ドメインがバインドされていないことが報告されます。このコマンドを 2 回目に実行すると、正常に処理が続行されるはずです。

  • NIS サーバーが使用できない

    ドメイン名が正しく設定され、ypbind デーモンも実行されているが、NIS クライアントがサーバーと通信できないことを示すメッセージが表示される場合は、次のことを確認します。

    • このクライアントには、バインドするサーバーのリストを含む /var/yp/binding/domainname/ypservers ファイルが存在しますか。選択された NIS サーバーを表示するには、svcprop –p config/ypservers nis/domain コマンドを使用します。存在しない場合は、ypinit –c コマンドを実行して、このクライアントがバインドするサーバーを希望順に指定します。

    • クライアントに /var/yp/binding/domainname/ypservers ファイルが存在する場合は、1 または 2 台のサーバーが使用できなくなる事態に備えて、そのリストに十分な台数のサーバーが含まれていますか。選択された NIS サーバーを表示するには、svcprop –p config/ypservers nis/domain コマンドを使用します。含まれていない場合は、ypinit –c コマンドを実行することによって、リストにサーバーを追加します。

  • ypwhich の表示に一貫性がない

    ypwhich コマンドを同じクライアント上で複数回実行すると、NIS サーバーが変更されるため、その結果の表示は変化します。これは正常な動作です。NIS クライアントから NIS サーバーへのバインドは、ネットワークや NIS サーバーを使用中の場合は時間の経過に伴って変化します。ネットワークは、可能であれば常に、すべてのクライアントが NIS サーバーから受け入れ可能な応答時間を受信した時点で安定した状態になります。クライアントが NIS サービスを受けるかぎり、そのサービスがどこから来ているかは問題になりません。たとえば、ある NIS サーバーが、ネットワーク上の別の NIS サーバーから NIS サービスを受けることができます。

  • NIS サーバーのバインドが不可能な場合の対処

    ローカルサーバーのバインドが不可能な極端なケースでは、可能であれば、ypbind コマンドの ypset オプションを使用して、別のネットワークまたはサブネット上の別の NIS サーバーへのバインドを一時的に許可します。–ypset オプションを使用するには、–ypset または –ypsetme のどちらかのオプションを使用して ypbind デーモンを起動する必要があることに注意してください。詳細は、ypbind(1M) のマニュアルページを参照してください。

    # /usr/lib/netsvc/yp/ypbind -ypset

    別の方法については、Oracle Solaris 11.3 ディレクトリサービスとネームサービスでの作業: DNS と NIS の 特定の NIS サーバーへのバインドを参照してください。

    Caution

    注意  -  セキュリティー上の理由から、–ypset または –ypsetme オプションの使用はお勧めできません。これらのオプションは、制御された環境でのデバッグの目的にのみ使用してください。–ypset または –ypsetme オプションを使用すると、重大なセキュリティー侵害につながる場合があります。デーモンの実行中、だれでも NIS サーバーのバインドを変更できるため、これによって機密データへの不正なアクセスが許可される場合があります。このどちらかのオプションを使用して ypbind デーモンを起動する必要がある場合は、問題を修正したあとに ypbind プロセスを強制終了し、次にこれらのオプションを指定せずにデーモンを再起動してください。 ypbind デーモンを次のように再起動します。 

    # svcadm enable -r svc:/network/nis/client:default
    ypset(1M) のマニュアルページを参照してください。

  • ypbind デーモンがクラッシュする

    ypbind デーモンが起動のたびにほぼ即座にクラッシュする場合は、svc:/network/nis/client:default サービスログに問題が含まれていないかどうか調べてください。rpcbind デーモンの存在を次のように確認します。

    % ps -e |grep rpcbind

    rpcbind デーモンが存在しないか、安定しないか、または異常な動作を行う場合は、svc:/network/rpc/bind:default ログファイルを確認してください。詳細は、rpcbind(1M) および rpcinfo(1M) のマニュアルページを参照してください。

    正常に機能しているシステムから、問題のあるクライアント上の rpcbind デーモンと通信できる可能性があります。

    機能しているシステムから、次のコマンドを実行します。

    % rpcinfo client

    問題のあるシステム上の rpcbind デーモンが正常な場合は、次の出力が表示されます。

    program	version	netid	address	service	owner
...
100007    3    udp6      ::.191.161          ypbind     1
100007    3    tcp6      ::.135.200          ypbind     1
100007    3    udp       0.0.0.0.240.221     ypbind     1
100007    2    udp       0.0.0.0.240.221     ypbind     1
100007    1    udp       0.0.0.0.240.221     ypbind     1
100007    3    tcp       0.0.0.0.250.107     ypbind     1
100007    2    tcp       0.0.0.0.250.107     ypbind     1
100007    1    tcp       0.0.0.0.250.107     ypbind     1
100007    3    ticlts    2\000\000\000       ypbind     1
100007    2    ticlts    2\000\000\000       ypbind     1
100007    3    ticotsord 9\000\000\000       ypbind     1
100007    2    ticotsord 9\000\000\000       ypbind     1
100007    3    ticots    @\000\000\000       ypbind     1
...

    アドレスが表示されない場合は (システムによってアドレスは異なります)、ypbind デーモンでそのサービスを登録できませんでした。システムをリブートし、rpcinfo コマンドを再度実行してください。ypbind プロセスがそこに存在し、NIS サービスを再起動しようとするたびに変更される場合は、rpcbind デーモンが実行されている場合でもシステムをリブートします。

複数の NIS クライアントに影響を与える問題のトラブルシューティング

1 台か 2 台のクライアントだけで、NIS のバインドに関する問題を示す症状が発生している場合は、そのクライアントに問題があると考えられます。単一の NIS クライアントに影響を与える問題のトラブルシューティングを参照してください。ただし、複数の NIS クライアントが正常にバインドできない場合は、1 台以上の NIS サーバーで問題が発生している可能性がもっとも高くなります。

    次に示すのは、複数のクライアントに影響を与える可能性のある一般的な NIS の問題です。

  • rpc.yppasswdd コマンドが r で始まる制限のないシェルを制限付きと見なしている

    この問題を解決するには、次の手順を実行します。

    1. "check_restricted_shell_name=1" という特殊な文字列を含む /etc/default/yppasswdd ファイルを作成します。

    2. "check_restricted_shell_name=1" の文字列がコメントアウトされている場合、r の確認は実行されません。

  • ネットワークまたはサーバーに接続できない

    ネットワークまたは NIS サーバーがあまりにも過負荷であるために、ypserv デーモンがクライアントの ypbind プロセスから返された応答をタイムアウト期間以内に受信できない場合は、NIS がハングアップすることがあります。NIS はまた、ネットワークがダウンしている場合にもハングアップすることがあります。

    このどちらの状況でも、ネットワーク上のすべてのクライアントで同じか、または同様の問題が発生します。ほとんどの場合、この状態は一時的です。これらのメッセージは通常、NIS サーバーが ypserv デーモンをリブートおよび再起動するか、NIS サーバー上またはネットワーク自体の負荷が減るか、またはネットワークが通常の動作を再開すると消えます。

  • NIS サーバーの誤動作

    NIS サーバーが起動され、実行されていることを確認します。サーバーに物理的に近い場所にいない場合は、ping コマンドを使用して、サーバーに接続できるかどうかを確認します。

  • NIS デーモンが実行されていない

    NIS サーバーが起動および実行されている場合は、正常に動作しているクライアントを見つけて、そのクライアント上で ypwhich コマンドを実行してみてください。ypwhich コマンドが応答しない場合は、強制終了します。次に、NIS サーバー上で root 役割になり、NIS プロセスが実行されているかどうかを次のように確認します。

    # ptree |grep ypbind
100759 /usr/lib/netsvc/yp/ypbind -broadcast
527360 grep yp

    ypserv デーモン (NIS サーバー) も ypbind デーモン (NIS クライアント) デーモンも実行されていない場合は、これらのデーモンを次のように再起動します。

    NIS クライアントサービスを次のように再起動します。

    # svcadm restart network/nis/client

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

    サーバー上で、NIS サービスを次のように再起動します。

    # svcadm restart network/nis/server

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

    NIS はサーバー間でマップを伝播するため、ネットワーク上の各種の NIS サーバー上に同じマップの異なるバージョンが見つかる場合があります。このバージョンの不一致は、その違いがそれほど長く続かなければ正常であり、受け入れ可能です。

    マップの不一致のもっとも一般的な原因は、マップの正常な伝播が妨げられている場合です。たとえば、NIS サーバーまたは NIS サーバー間に配置されているルーターが停止している場合があります。すべての NIS サーバーおよび NIS サーバー間のルーターが実行されている場合、ypxfr コマンドは成功します。

      サーバーおよびルーターが正常に機能している場合は、次のように処理を続行します。

    • ypxfr のログ出力をチェックします。使用例 21を参照してください。

    • svc:/network/nis/xfr:default ログファイルにエラーが表示されていないかどうかをチェックします。

    • 制御ファイル (crontab ファイルと yupxfr シェルスクリプト) を確認します。

    • マスターサーバー上の ypservers マップをチェックします。

  • ypserv プロセスがクラッシュする

    ypserv プロセスがほぼ即座にクラッシュし、起動を繰り返しても安定しない場合、デバッグプロセスは、ypbind のクラッシュに対するデバッグプロセスとほぼ同じです。

    まず、次のコマンドを実行して、何らかのエラーが報告されているかどうかを確認します。

    # svcs -vx nis/server

    rpcbind デーモンが存在するかどうかを、次のようにチェックします。

    # ptree |grep rpcbind

    デーモンが見つからない場合は、NIS サーバーをリブートします。このデーモンが実行されている場合は、次のコマンドを実行し、同様の出力を探してください。

    # rpcinfo -p ypserver
    program vers     proto port   service
100000  4        tcp   111    portmapper
100000  3        tcp   111    rtmapper
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

    前の例では、次の 4 つのエントリが ypserv プロセスを表しています。

    100004  2        udp   731    ypserv
100004  1        udp   731    ypserv
100004         tcp   732    ypserv
100004  2t       tcp   32772  ypserv

    これらのエントリが存在せず、ypserv がそのサービスを rpcbind に登録できない場合は、システムをリブートします。エントリが存在する場合は、ypserv を再起動する前に rpcbind からこのサービスの登録を解除します。たとえば、次のようにして rpcbind からこのサービスの登録を解除します。

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

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

使用例 21  ypxfr コマンドの出力のロギング

  • 特定のスレーブサーバーでマップの更新に関する問題が発生している場合は、そのスレーブサーバーにログインし、ypxfr コマンドを対話的に実行します。

    このコマンドが失敗した場合は、失敗した原因に関するメッセージが表示され、その問題を修正できるようになります。このコマンドは成功するが、失敗した場合もあったと疑われる場合は、次のように、そのスレーブサーバー上にログファイルを作成してメッセージのロギングを有効にします。

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

    このログファイルの出力は、ypxfr コマンドを対話的に実行したときの出力に似ていますが、ログファイル内の各行にはタイムスタンプが記録される点が異なります。タイムスタンプの順序が異常なことに気付いた場合、それは、ログには ypxfr コマンドが実際に実行された各時間が示されているためです。ypxfr の複数のコピーが同時に実行されたが、その完了にかかった時間が異なる場合は、各コピーによって、そのコマンドが実行されたのとは異なる順序でサマリーステータス行がログファイルに書き込まれる可能性があります。断続的に発生するあらゆる種類の障害がログに記録されます。

    注 -  問題を解決したら、ログファイルを削除することによってロギングを無効にします。削除し忘れた場合は、そのファイルが無制限に拡張し続けます。

  • crontab ファイルと ypxfr シェルスクリプトを確認します。

    root crontab ファイルを検査し、そのファイルが起動した 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 で展開されるようにしています。

Copyright © 2012, 2016, Oracle and/or its affiliates. All rights reserved.  
前へ
次へ