| ナビゲーションリンクをスキップ | |
| 印刷ビューの終了 | |
|
Oracle Solaris 11.1 でのネームサービスおよびディレクトリサービスの作業 Oracle Solaris 11.1 Information Library (日本語) |
| ナビゲーションリンクをスキップ | |
| 印刷ビューの終了 | |
|
|
Oracle Solaris 11.1 でのネームサービスおよびディレクトリサービスの作業 Oracle Solaris 11.1 Information Library (日本語) |
4. Oracle Solaris Active Directory クライアントの設定 (タスク)
11. LDAP クライアントと Oracle Directory Server Enterprise Edition の設定 (タスク)
NIS のバインドに関する一般的な問題には、次のようなものがあります。
クライアントのコマンドがバックグランドモードでゆっくりと処理されているか、通常よりも機能に時間がかかる
クライアント上のコマンドがハングアップする。システム全体は正常で新しいコマンドを実行できる場合でも、コマンドがハングすることがあります
クライアントのコマンドがあいまいなメッセージとともに、またはまったくメッセージなしでクラッシュする
1 台か 2 台のクライアントだけで、NIS のバインドに関する問題を示す症状が発生している場合は、そのクライアントに問題があると考えられます。複数のクライアントが正しくバインドできない場合は、1 台以上の NIS サーバーに問題があると考えられます。「複数のクライアントに影響する NIS の問題」を参照してください。
あるクライアントに問題がありますが、同じサブネット上のほかのクライアントは正常に動作しています。問題のあるクライアント上の、多数のユーザー (そのクライアントの /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 コマンドを実行して、どのドメイン名が設定されているのかを調べます。
client7# domainname example.com
この出力を、NIS マスターサーバー上の /var/yp 内の実際のドメイン名と比較します。実際の NIS ドメインは、/var/yp ディレクトリ内のサブディレクトリとして表示されます。
client7# ls -l /var/yp -rwxr-xr-x 1 root Makefile drwxr-xr-x 2 root binding drwx------ 2 root example.com
マシン上で domainname を実行することによって返されたドメイン名が、/var/yp 内のディレクトリとして一覧表示されたサーバードメイン名と同じでない場合は、マシンの /etc/defaultdomain ファイルで指定されたドメイン名が正しくありません。「マシンの NIS ドメイン名を設定する方法」で示すように、NIS ドメイン名をリセットします。
注 - NIS ドメイン名では大文字と小文字が区別されます。
ドメイン名が正しく設定されており、ypbind が実行されていてもコマンドがまだハングアップする場合は、ypwhich コマンドを実行することによって、クライアントがサーバーにバインドされていることを確認します。ypbind を起動したばかりの場合は、ypwhich を何回か実行します (通常、1 回目にはドメインがバインドされていないことが報告され、2 回目には成功します)。
ドメイン名が正しく設定されていて ypbind が実行中のときに、クライアントがサーバーと通信できないというメッセージを受け取った場合には、いくつかの問題が考えられます。
クライアントに、バインド先のサーバーのリストが含まれた /var/yp/binding/domainname/ypservers ファイルが存在しますか。ない場合には、ypinit -c を実行して、設定の順番にクライアントのバインド先のサーバーを指定します。
クライアントに /var/yp/binding/domainname/ypservers ファイルがあり、1 つ以上のサーバーが使用できない場合には、十分な数のサーバーがあるかどうかを調べます。存在しない場合は、ypinit -c を実行することによって、このリストにサーバーを追加します。
/etc/inet/hosts ファイル内に、選択された NIS サーバーのエントリがありますか。選択された NIS サーバーを表示するには、svcprop -p config/ypservers nis/domain コマンドを使用します。これらのホストがローカルの /etc/inet/hosts ファイル内に含まれていない場合は、「NIS マップに関する作業」の説明に従って ypinit -c または ypinit -s コマンドを実行することによって、hosts の NIS マップにサーバーを追加してマップを再構築します。
ネームサービススイッチは NIS に加えて、マシンのローカルの hosts ファイルをチェックするように設定されていますか。このスイッチについての詳細は、第 2 章ネームサービススイッチ (概要)を参照してください。
ネームサービススイッチは、services と rpc で最初に files をチェックするように設定されていますか。スイッチについての詳細は、第 2 章ネームサービススイッチ (概要)を参照してください。
ypwhich を同じクライアントで数回使うと、NIS サーバーが変わるので結果の表示も変わります。これは正常です。NIS クライアントから NIS サーバーへのバインドは、ネットワークや NIS サーバーを使用中の場合は時間の経過に伴って変化します。ネットワークは、すべてのクライアントが受け入れ可能な応答時間を NIS サーバーから得られる点で安定した状態になります。クライアントのマシンが NIS サービスを得ている限りは、サービスの供給元は問題にはなりません。たとえば、NIS サーバーマシンがそれ自体の NIS サービスを、ネットワーク上の別の NIS サーバーから受けることもあります。
ローカルなサーバーのバインドが不可能な場合には ypset コマンドを使用すると、別のネットワークまたはサブネットの別のサーバーが使用可能な場合には、そのサーバーへのバインドが一時的に可能になります。ただし、-ypset オプションを使用するには、ypbind を -ypset または -ypsetme のどちらかのオプションを使用して起動する必要があります。詳細は、ypbind(1M) のマニュアルページを参照してください。
# /usr/lib/netsvc/yp/ypbind -ypset
別の方法については、「特定の NIS サーバーへのバインド」を参照してください。
 | 注意 - セキュリティー上の理由から、-ypset オプションや -ypsetme オプションの使用はお勧めできません。これらのオプションは、制御された環境でのデバッグの目的にのみ使用してください。-ypset オプションや -ypsetme オプションを使用すると、これらのデーモンの実行中にだれでもサーバーのバインドを変更でき、ほかのユーザーでトラブルが発生したり、機密データへの未承認のアクセスが許可されたりするため、重大なセキュリティー違反が発生する場合があります。これらのオプションを使用して ypbind デーモンを起動する必要がある場合は、問題を解決したあとに ypbind プロセスを強制終了し、これらのオプションなしでこのデーモンを再起動する必要があります。 ypbind デーモンを再起動するには、SMF を次のように使用します。 # svcadm enable -r svc:/network/nis/client:default |
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 が正常である場合、rpcinfo は次の出力を生成します。
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 デーモンが実行されていてもシステムをリブートします。
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 で登録できない場合にはマシンをリブートしてください。エントリが存在する場合は、ypserv を再起動する前に、rpcbind からこのサービスの登録を解除します。rpcbind からこのサービスの登録を解除するには、サーバー上で次のように入力します。
# rpcinfo -d number 1 # rpcinfo -d number 2
ここで、number は rpcinfo によって報告された ID 番号 (前の例では 100004) です。
|