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

注 - NIS ドメイン名では大文字と小文字が区別されます。
クライアントがサーバーにバインドされていない

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

ドメイン名が正しく設定され、ypbind デーモンも実行されているが、クライアントがサーバーと通信できないことを示すメッセージが表示される場合は、次のことを確認します。
- このクライアントには、バインドするサーバーのリストを含む /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 コマンドを実行することによって、リストにサーバーを追加します。
- /etc/inet/hosts ファイル内に、選択された NIS サーバーのエントリがありますか。選択された NIS サーバーを表示するには、svcprop –p config/ypservers nis/domain コマンドを使用します。これらのホストがローカルの /etc/inet/hosts ファイルに含まれていない場合は、ypinit –c または ypinit –s コマンドを実行することによって、hosts の NIS マップにサーバーを追加してマップを再構築します。詳細は、Oracle Solaris 11.2 ディレクトリサービスとネームサービスでの作業: DNS と NIS のNIS マップに関する作業を参照してください。
- ネームサービススイッチが NIS に加えて、システムのローカルの hosts ファイルを確認するように設定されていますか。詳細は、Oracle Solaris 11.2 ディレクトリサービスとネームサービスでの作業: DNS と NIS の第 2 章ネームサービススイッチについてを参照してください。
- ネームサービススイッチが最初に services の、次に rpc の files を確認するように設定されていますか。
ypwhich の表示に一貫性がない

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

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

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

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

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

注意 - セキュリティー上の理由から、–ypset または –ypsetme オプションの使用はお勧めできません。これらのオプションは、制御された環境でのデバッグの目的にのみ使用してください。–ypset または –ypsetme オプションを使用すると、重大なセキュリティー侵害につながる場合があります。デーモンの実行中、だれでもサーバーのバインドを変更することができるため、これによって機密データへの不正なアクセスが許可される場合があります。このどちらかのオプションを使用して 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 デーモンが実行されている場合でもシステムをリブートします。