9    ネットワークおよびネットワーク・サービスに関する問題の解決

この章では,ネットワークおよびネットワーク・サービス・ソフトウェアを使用する際に発生する問題を解決するための診断用マップについて説明します。 この章とともに適切なマニュアルを参照することにより,多くの問題をユーザ・レベルで解決することができます。

9.1 節9.2 節には診断マップの使用方法と,マップ内での開始位置を問題の種類ごとに示しています。 それ以降の各節には診断マップがあり,次に挙げる各種システムの問題を解決するための方法を説明しています。

9.1    診断マップの使用方法

ネットワークおよびネットワーク・サービスに関する問題は,さまざまな原因によって発生します。 この章の診断マップは,問題の原因を特定するために役立ちます。 同様の診断マップは,『ネットワーク管理ガイド:接続編』にも記載されています。 次の図に,診断マップの使用方法を示します。

図 9-1:  診断マップの使用方法

問題を切り分けた後,診断マップは,さまざまな問題解決ツールやユーティリティの使用方法について他の章を参照するように指示します。 また,場合によっては,特定のデバイスやソフトウェア製品のマニュアルを参照するよう指示します。

レイヤード・ソフトウェアを通してネットワークおよびネットワーク・サービス・ソフトウェアを使用している場合には,本書で説明していない問題が発生する場合があります。 詳しい情報については,該当する製品のマニュアルを参照してください。

9.2    準備

問題の解決を開始する前に,通信ハードウェアが使用できる状態になっていることを確認してください。 次のことを確認します。

既知の問題に関する最新の情報については,各製品のリリース・ノートを参照してください。

表 9-1は,問題解決の際に,まず診断マップのどの部分を参照すればよいかを示しています。

表 9-1:  問題解決のスタート・ポイント

問題の種類 スタート・ポイント
uucp コマンドのエラー

9.10 節

ネットワーク・コマンドのエラー

ネットワーク管理ガイド:接続編』の「PPP に関する問題の解決」および「SLIP に関する問題の解決」

ネットワーク管理ガイド:接続編』の「IPv4 ネットワークに関する問題の解決」および「IPv6 ネットワークに関する問題の解決」

ATM ネットワークへの接続

ネットワーク管理ガイド:接続編』の「ATM に関する問題の解決」

ネットワーク管理ガイド:接続編』の「IPv4 ネットワークに関する問題の解決」および「IPv6 ネットワークに関する問題の解決」

DHCP を使用した IP アドレスの取得

ネットワーク管理ガイド:接続編』の「DHCP に関する問題の解決」

ネットワーク管理ガイド:接続編』の「IPv4 ネットワークに関する問題の解決」および「IPv6 ネットワークに関する問題の解決」

NTP を使用している場合のシステム時間の修正 9.11 節
ホスト名情報の取得

9.4 節 (DNS/BIND を使用している場合)

9.6 節 (NIS を使用している場合)

ファイルへのアクセス

9.8 節 (NFSを使用している場合)

9.9 節 (AutoFSを使用している場合)

ネットワーク管理ガイド:接続編』の「IPv4 ネットワークに関する問題の解決」および「IPv6 ネットワークに関する問題の解決」

LAT を使用したホストへの接続 ネットワーク管理ガイド:接続編』の「LAT に関する問題の解決」
未知のエラー

ネットワーク管理ガイド:接続編』の「IPv4 ネットワークに関する問題の解決」

未知の IPv6 エラー

ネットワーク管理ガイド:接続編』の「IPv6 ネットワークに関する問題の解決」

メールの送信または受信

9.12 節

9.13 節 (POP または IMAP メールを使用している場合)

9.3    DNS/BIND サーバに関する問題の解決


ネットワーク・サービスの追加サブセットがインストールされていることを確認します。 次のコマンドを入力します。

# setld -i | grep OSFINET

このサブセットがインストール済みであれば,次のメッセージが表示されます。

OSFINETnnn installed Additional Networking Services  (Network-Server/Communications)

ネットワーク・サービスの追加サブセットがインストールされていない場合は,setld コマンドを使用してインストールします。 サブセットのインストールについての詳細は,『インストレーション・ガイド』を参照してください。


rcmgr ユーティリティを使用して /etc/rc.config.common ファイル内の BIND_SERVERTYPE エントリの値を表示します。

# rcmgr get BIND_SERVERTYPE

タイプが指定されていない場合は,SysMan Menu を実行して DNS サーバを構成します。 詳細は2.5 節を参照してください。


次のコマンドを実行し,BIND デーモン (named) が動作していることを確認します。

# ps -e | grep named

named プロセスが動作していない場合は,次のコマンドを実行して named デーモンを起動します。

# /sbin/init.d/named start


認証を使用可能にしているときに,セキュアな動的更新やセキュアなゾーン転送が成功しなかった場合には,syslogd デーモンが生成した daemon.log ファイルにエラーが記録されていないか調べます。 セキュアな動的更新の場合はマスタ・サーバ上,セキュアなゾーン転送の場合はマスタ・サーバとスレーブ・サーバ上のログを調べます。 syslogd メッセージ・ファイルの参照方法についての詳細は,10.4 節を参照してください。

syntax error near 'item' というメッセージが表示された場合,named.conf ファイルと鍵ファイル (通常は named.keys) 内の構文エラーを調べます。 カッコや引用符,セミコロンの抜けがないか確認します。 必要であれば,ファイルの内容を,2.6.3 項で紹介しているファイルの内容と比較します。

unknown key 'key-name' メッセージや Invalid TSIG secret "key-string" メッセージが表示された場合は,次の手順を実行します。

  1. 更新や転送に正しい鍵を使用していることを確認します。

  2. 鍵名のスペルを確認します。

  3. 鍵文字列が正しいかチェックします。 鍵を囲む引用符の間には,改行文字やスペース文字は使用できません。

  4. 鍵のアルゴリズムとして hmac-md5 を指定しており,鍵が正しく生成されていることを確認します。 必要であれば,新しい鍵を生成します。 詳細については,2.6 節を参照してください。

まだ問題がある場合はサービス担当者に報告してください。第 12 章 を章参照。

nslookup コマンドが,クライアントの nslookup コマンドで指定したホストの情報を返さない場合や,ホストの情報を全く返さない場合は,前述した手順で収集した BIND_SERVERTYPE エントリの値を基に,実行すべき手順を次の中から選びます。

タイプ

参照する項目

CLIENT

処理を中止してください。 このシステムは DNS/BIND サーバではないため,クライアントに名前解決サービスを提供できません。

MASTER

11.4 節

SLAVE

11.4 節

FORWARDER

11.5 節

CACHING

11.9 節

9.4    DNS/BIND クライアントに関する問題の解決


ネットワーク・サービスの追加サブセットがインストールされていることを確認します。 次のコマンドを入力します。

# setld -i | grep OSFINET

このサブセットがインストール済みであれば,次のメッセージが表示されます。

OSFINETnnn installed Additional Networking Services  (Network-Server/Communications)

ネットワーク・サービスの追加サブセットがインストールされていない場合は,setld コマンドを使用してインストールします。 サブセットのインストールについての詳細は,『インストレーション・ガイド』を参照してください。


rcmgr ユーティリティを使用して,/etc/rc.config.common ファイル内の BIND_SERVERTYPE エントリの値を表示します。

# rcmgr get BIND_SERVERTYPE

タイプが指定されていない場合は,DNS クライアントを構成するために SysMan Menu ユーティリティを実行します。 詳細は 2.5 節 を参照してください。

まだ問題がある場合はサービス担当者に報告してください。 第 12 章 を参照。

ネットワーク・コマンド (たとえば telnetrlogin,および rsh) のうち 1 つを実行しようとした場合にリモート・ホストが未知であると,次のメッセージが表示されます。

unknown host

次の手順に従ってください。

  1. /etc/svc.conf ファイルの内容を調べ,DNS が hosts データベース検索に使用されているかどうかをチェックします。 DNS が使用されている場合は,手順 2 に進んでください。 使用されていない場合は,/etc/svcsetup コマンドを使用して,/etc/svc.conf ファイルに追加します。

  2. nslookup コマンドを使用して,通信しようとしたリモート・ホストについての情報を検索します。 次のコマンドを入力します。

    # nslookup hostname
    

    コマンドが正常に終了する場合は,クライアントが正しく設定されています。 ネットワーク・コマンドを再実行します。 コマンドが異常終了する場合は,手順 3 に進んでください。

  3. /etc/resolv.conf ファイルを表示して,nameserver エントリのアドレスを検索します。

  4. ping コマンドを使用して,DNS/BIND サーバが到達可能であることを確認します。 到達可能なサーバがない場合は,ネットワーク管理者にお問い合わせください。ping コマンドに応答しないネーム・サーバがある場合は,そのネーム・サーバのエントリを resolv.conf ファイルから削除します。

  5. nslookup コマンドを再実行します。 コマンドが異常終了する場合は,9.3 節の DNS/BIND サーバに関する問題の解決手順を参照してください。

9.5    NIS サーバに関する問題の解決


ネットワーク・サービスの追加サブセットがインストールされていることを確認します。 次のコマンドを入力します。

# setld -i | grep OSFINET

このサブセットがインストール済みであれば,次のメッセージが表示されます。

OSFINETnnn installed Additional Networking Services  (Network-Server/Communications)

サブセットがインストールされていない場合には,setld コマンドを使用してインストールします。 サブセットのインストールについての詳細は,『インストレーション・ガイド』を参照してください。


rcmgr ユーティリティを使用して /etc/rc.config.common ファイル内の NIS_CONF エントリの値を表示します。

# rcmgr get NIS_CONF

何も返されない場合は,NIS サーバを構成するために SysMan Menu ユーティリティを実行します。 詳細については,3.3 節 を参照してください。


次のコマンドを実行し,portmap デーモンが動作していることを確認します。

# ps -e | grep portmap

portmap デーモンが動作していない場合は,次のコマンドを実行して NIS をいったん停止し,再起動します。

# /sbin/init.d/nis stop
# /sbin/init.d/nis start

portmap デーモンが起動しない場合は,サーバをリブートしてください。


次のコマンドを実行し,ypserv プロセスが動作していることを確認します。

# ps -e | grep yp

ypserv プロセスが動作していない場合は,次のコマンドを実行して NIS をいったん停止し,再起動します。

# /sbin/init.d/nis stop
# /sbin/init.d/nis start

ypserv プロセスが動作している場合は,ypwhich コマンドを実行します。 次のコマンドを入力します。

# ypwhich

何も返されない場合は, portmap プロセスのプロセス ID (PID) を調べて強制終了させます。 次のコマンドを入力します。

# ps -e | grep portmap
# kill -9 portmap_PID

注意

portmap デーモンは,他のネットワーク・サービスによっても使用されているため,終了させるとネットワーク・サービスが影響を受ける可能性があります。 したがって,問題が発生する可能性があることを,ユーザに通知してください。

次のコマンドを実行して NIS をいったん終了し,再起動します。

# /sbin/init.d/nis stop
# /sbin/init.d/nis start


マップ内の情報が正しいことを確認します。 次のコマンドを入力します。

# ypcat map_name

map_name 変数には,NISマップの名前を指定します。 情報が正しくない場合は,新しいマップを作成します。 次のコマンドを入力します。

# cd /var/yp
# make map_name

次のメッセージが表示されます。

map_name updated

make コマンドによって,データベースが更新されなかったことが示された場合は,次の手順に従ってください。

  1. /var/yp および /var/yp/domainname ディレクトリから database_name.time ファイルを削除します。

  2. make コマンドを使用して新しいマップを作成します。 次のコマンドを入力します。

    # cd /var/yp
    # make map_name
    

まだ問題がある場合はサービス担当者に報告してください。 第 12 章 を参照。

NIS マップの更新がスレーブ・サーバに受信されなかったと考えられる場合は,スレーブ・サーバで次の手順に従ってください。

  1. NIS マスタ・サーバが稼働しており,アクセス可能であることを,ping コマンドを使って確認します。

  2. ypxfr ログ・ファイルを作成します。 次のコマンドを入力します。

    # cd /var/yp
    # touch ypxfr.log
    

  3. マップ更新を取得するために,ypxfr を対話モードで実行します。 次のコマンドを入力します。

    # ypxfr mapname
    

  4. ypxfr.log ファイルの内容を調べ,すべての問題を解決します。 ログ・ファイルを削除してロギングをオフにします。

  5. /var/spool/cron/crontabs/root ファイル内の ypxfr エントリを確認します。 コマンド pg または /usr/bin/crontab -l を使用します。 スレーブ・サーバのエントリは,次のようになります。

    # Network Information Service: SLAVE server entries
    30 * * * * sh /var/yp/ypxfr_1perhour
    31 1,13 * * * sh /var/yp/ypxfr_2perday
    32 1 * * * sh /var/yp/ypxfr_2perday
    

  6. 対応する ypxfr シェル・スクリプト内にマップのエントリが存在することを確認します。

  7. syslogd デーモン・メッセージ・ファイルの内容を調べ,NIS メッセージの存在を確認します。 詳細については,10.4 節を参照してください。

  8. スレーブ・サーバがドメインの ypservers マップにあることを確認します。

9.6    NIS クライアントに関する問題の解決


rcmgr ユーティリティを使用して, /etc/rc.config.common ファイル内の NIS_CONF エントリの値を表示します。

# rcmgr get NIS_CONF

何も返らなかった場合には,NIS クライアントを構成するために SysMan Menu ユーティリティを実行します。 詳細については,3.3 節 を参照してください。


/usr/sbin/svcsetup スクリプトを使用して,svc.conf ファイルに NIS エントリがあることを確かめます。 NIS エントリには,英字 yp が含まれています。

passwd および group データベースでの NIS 使用の有無は,セキュリティ統合アーキテクチャ (SIA) によって制御されます。 ただし,NIS を使用するには,両方のデータベースの最後の行に +: 文字列がなくてはなりません。


次のコマンドを実行し,portmap デーモンが動作していることを確認します。

# ps -e | grep portmap

portmap デーモンが動作していない場合は,次のコマンドを使用して NIS をいったん停止し,再起動します。

# /sbin/init.d/nis stop
# /sbin/init.d/nis start

portmap デーモンが起動しない場合は,クライアントをリブートしてください。


ypbind プロセスが実行されていることを確認します。 次のコマンドを入力します。

# ps -e | grep yp

ypbind プロセスが 1 つも実行されていない場合は,次のコマンドを使用して NIS を終了してから再起動します。

# /sbin/init.d/nis stop
# /sbin/init.d/nis start

ypbind プロセスが実行されている場合は,ypwhich コマンドを実行します。 次のコマンドを入力します。

# ypwhich

ypwhich コマンドが応答しない場合は,portmap プロセスを強制終了させます。 次のコマンドを入力します。

# kill -9 portmap_PID

次のコマンドを使用して NIS を終了し,起動します。

# /sbin/init.d/nis stop
# /sbin/init.d/nis start


ypwhich コマンドが連続して数回呼び出された場合に,一致しない情報を返すときは,クライアント・システムがバインドするサーバ・システムを変更しています。 この問題は,繰り返し発生する可能性があります。 特に,システムがビジー状態のネットワークにあるか,または NIS サーバがビジー状態の場合に発生しやすくなります。 すべてのクライアントが受けいれることのできる応答時間を NIS サーバから取得すると,システムは安定します。

ypwhich コマンドによって,ドメインがバインドされていないことが報告された場合は,システムがはじめからサーバ・システムにバインドされていなかったことになります。 ypcat コマンドを実行してから,ypwhich コマンドを再実行します。

まだ問題がある場合はサービス担当者まで報告してください。 第 12 章 を参照。

NIS コマンドがハングすると,コンソールに次のメッセージが表示されます。

yp: server not responding for domain domainname.
Still trying

クライアントがサーバと通信できません。 次の手順に従ってください。

  1. rcmgr コマンドを使用して,domainname コマンドによって返されたドメイン名がサーバの /etc/rc.config.common ファイル内の NIS_DOMAIN エントリの値に一致していることを確認します。

    # rcmgr get NIS_CONF
     
    

    ドメイン名が一致していないか,または環境特有の条件を満たしていない場合は,SysMan Menu ユーティリティを使用してクライアント・システムを再構成します。 (ドメイン名は大文字と小文字が区別される点に注意してください。) 詳細については,3.3 節 を参照してください。

  2. ドメイン用の NIS サーバが最低でも 1 つ,ローカルのサブネットワークで実行されていることを確認します。 実行されていない場合は,SysMan Menu ユーティリティを使用してクライアントを再構成してから, ypbind コマンドで -S オプションを使用します。

  3. サブネットワーク上の他のクライアントについて,NIS コマンドのいずれかによって問題が発生していないかどうかを調べます。

  4. リモート・システムのサーバ・デーモンが実行されていることを確認します。 次のコマンドを入力します。

    # rpcinfo -p server_name
    

    また,次のコマンドを入力して,サーバ上で ypserv デーモンが現在実行されていることを確認します。

    # rpcinfo -t server_name ypserv 2
    

    上記のいずれか (または両方) のテストで正しい結果が得られなかった場合には,サーバ上で次のコマンドを実行し,NIS をいったん終了して再起動します。

    # /sbin/init.d/nis stop
    # /sbin/init.d/nis start
    

  5. syslogd デーモン・メッセージ・ファイルの内容を調べ,NIS メッセージの存在を確認します。 詳細については, 10.4 節 を参照してください。

  6. サーバが実行されていることを確認します。 NIS サーバに関する問題の解決手順については,9.5 節を参照してください。

上記の手順を実行しても問題が解決しない場合は,次の手順に従ってください。

  1. NIS を終了してから,起動します。 次のコマンドを入力します。

    # /sbin/init.d/nis stop
    # /sbin/init.d/nis start
    

    これでも問題が解決しない場合は,手順 2 に進みます。

  2. システムをリブートします。

  3. SysMan Menu ユーティリティを実行して,NIS を再構成します。

9.7    NFS サーバに関する問題の解決


NFS Utilities サブセットがインストールされていることを確認します。 次のコマンドを入力します。

# setld -i | grep OSFNFS

このサブセットがインストール済みであれば,次のメッセージが表示されます。

OSFNFSnnn 
 installed  NFS(tm) Utilities  (Network-Server/Communications)

NFS Utilities サブセットがインストールされていない場合には,setld コマンドを使用してインストールします。 サブセットのインストールについての詳細は,『インストレーション・ガイド』を参照してください。


rcmgr ユーティリティを使用して /etc/rc.config.common ファイル内の NFSSERVING エントリの値を表示します。

# rcmgr get NFSSERVING

何も返されなかった場合は,NFS サーバを構成するために SysMan Menu ユーティリティを実行します。 詳細については 4.3 節 を参照してください。

ネットワーク・ソフトウェアが構成されていることを確認します。 解決手順については,『ネットワーク管理ガイド:接続編』の診断マップで「ネットワーク構成済み ?」の部分を参照してください。


portmap デーモンが実行されていることを確認します。 次のコマンドを入力します。

# ps -e | grep portmap

portmap デーモンが実行されていない場合は,次のコマンドを使用して NFS を終了してから,再起動します。

# /sbin/init.d/nfs stop
# /sbin/init.d/nfs start

portmap デーモンが起動しない場合は,サーバをリブートしてください。


次のコマンドを入力して,NFS デーモンが portmap デーモンに登録されているかどうか確認します。

# rpcinfo -u server_name mount
# rpcinfo -u server_name nfs

どちらも登録されていない場合は,次のコマンドで NFS を起動します。

# /sbin/init.d/nfs start


NFS デーモンが実行されていることを確認するには,次の手順に従ってください。

  1. mountd プロセスが実行されていることを確認します。 次のコマンドを入力します。

    # ps -e | grep mountd
    

    mountd プロセスが実行されている場合は,手順 2 に進みます。 mountd プロセスが実行されていない場合は, 次のコマンドを使用して NFS を終了してから,起動します。

    # /sbin/init.d/nfs stop
    # /sbin/init.d/nfs start
    

  2. nfsd プロセスが実行されていることを確認します。 次のコマンドを入力します。

    # ps -e | grep nfsd
    

    nfsd プロセスが実行されていない場合は,次のコマンドを使用して NFS を終了してから起動します。

    # /sbin/init.d/nfs stop
    # /sbin/init.d/nfs start
    

また,NFS デーモンの状態を見るために SysMan Menu ユーティリティを使用することもできます。 次のコマンドを入力することによって,状態ダイアログ・ボックスへ直接いくことができます。

# /usr/sbin/sysman nfs_daemon_status

まだ問題がある場合はサービス担当者に報告してください。 第 12 章 を参照。

ファイルがエクスポートされていることを確認するには,次の手順に従ってください。

  1. 次のコマンドを入力してファイルがエクスポートされていることを確認します。

    # showmount -e
    

    ファイルがエクスポートされている場合は,手順 3 に進みます。

  2. ファイルがエクスポートされていない場合は,ファイルのエントリが /etc/exports ファイルにあることを確認します。 このファイルにエントリがない場合は,ファイルを編集し,エントリを作成します。 リモート・システムにファイルをマウントします。

  3. ファイルがエクスポートされているにもかかわらずマウントできない場合には,rcmgr ユーティリティを次のように使用して /etc/rc.config ファイル内の NONROOTMOUNTS エントリの値を表示し,そのファイルのマウントがユーザに許可されているかどうかを調べます。

    # rcmgr get NONROOTMOUNTS
    

    NONROOTMOUNTS パラメータが 0 の場合,root ユーザだけがこのサーバからファイルをマウントできます。 root 以外のユーザがファイルをマウントできるようにするには,次のコマンドを入力します。

    # rcmgr set NONROOTMOUNTS 1
    

  4. 次のコマンドを入力して,mountd デーモンが,インターネット・アドレス・チェックをオンにして実行されていることを確認します。

    # ps -e | grep mountd
     
    

    -i オプションが表示された場合は,クライアントの名前およびアドレスは, /etc/hosts ファイル,DNS または NIS hosts データベースのいずれかにあるはずです。 既知のホストだけがファイル・システムをマウントできます。 オプション -d または -s が表示された場合は,クライアント・システムがサーバと同じ DNS ドメインまたはサブドメインに属しているはずです。

  5. mountd デーモンによって,エクスポートされたファイルの古いファイル・ハンドルが返された場合は,mountd デーモンにハングアップ・シグナル (SIGHUP) を送信して,/etc/exports ファイルを,再び強制的に読み取らせます。 次のコマンドを入力します。

    # ps -e | grep mountd
    # kill -1 mountd_pid
    

9.8    NFS クライアントに関する問題の解決


NFS Utilities サブセットがインストールされていることを確認します。 次のコマンドを入力します。

# setld -i | grep OSFNFS

このサブセットがインストール済みであれば,次のメッセージが表示されます。

OSFNFSnnn  installed  NFS(tm) Utilities  (Network-Server/Communications)

NFS Utilities サブセットがインストールされていない場合には,setld コマンドを使用してインストールします。 インストール方法についての詳細は,『インストレーション・ガイド』を参照してください。


rcmgr ユーティリティを次のように使用して,/etc/rc.config.common ファイル内の NFS_CONFIGURED エントリの値を表示します。

# rcmgr get NFS_CONFIGURED

何も返されない場合,NFS クライアントを構成するために SysMan Menu ユーティリティを実行します。 詳細については,4.3 節 を参照してください。

ネットワーク・ソフトウェアが構成されていることを確認します。 解決手順については,『ネットワーク管理ガイド:接続編』で「ネットワーク構成済み ?」の部分を参照してください。


portmap デーモンが実行されていることを確認します。 次のコマンドを入力します。

# ps -e | grep portmap

portmap デーモンが見つからない場合は, 次のコマンドを使用して NFS を終了してから,再起動します。

# /sbin/init.d/nfs stop
# /sbin/init.d/nfs start

portmap デーモンが起動しない場合は,クライアントをリブートしてください。


クライアントがリモートのファイル・システムまたはディレクトリをマウントできない場合は,次の手順に従ってください。

  1. 端末にエラー・メッセージが表示された場合は,付録 Cを参照して,そのエラーについて調べてください。

  2. リモートの NFS サーバが,ローカル・ネットワーク上の hosts データベースに記述されていることを確認します。

  3. リモート・システムのサーバ・デーモンが実行されていることを確認します。 次のコマンドを入力します。

    # rpcinfo -p server_name
    

  4. サーバによって,必要なファイルがエクスポートされていることを確認します。 次のコマンドを入力します。

    # showmount -e server_name
    

  5. NFS サーバに関する問題の解決手順は,9.7 節を参照してください。 サーバを実行できるが,依然問題が発生する場合は,クライアント・システムとリモート・サーバ間のイーサネット接続およびインターネット接続を確認します。

  6. ネットワーク上の他のクライアントで,同じリモート・サーバによる問題が発生していないかどうかを調べます。

  7. mount コマンド行または /etc/fstab ファイル内のエントリが正しいことを確認し,さらに次のことを確認します。

    1. ホスト名がリモート NFS サーバの名前と一致している

    2. 該当するマウント・ポイントがシステムに存在している

  8. 認証エラーが表示されたら,次のことを確認します。

    1. スーパユーザでない場合は,サーバが非ルート・マウントを許可していること。

    2. ホスト名がサーバの hosts データベースにあること。

    3. システムがサーバと同じドメインにない場合は,サーバによってドメイン・チェックが実行されていること。 サーバのオプションについては, mountd(8) を参照してください。

まだ問題がある場合はサービス担当者に報告してください。 第 12 章 を参照。

ファイル関連のタスクを実行するアプリケーション・プログラムがタスクを完了しないか,または完了に時間かかる場合は,次の手順に従ってください。

  1. 端末にエラー・メッセージが表示された場合は,付録 Cを参照して,そのエラーについて調べてください。

  2. サーバの実行を確認します。 NFS サーバに関する問題の解決手順については, 9.7 節 を参照してください。 サーバが実行されている場合は,nfsd デーモンによる CPU 時間の増加を確認します。 増加していない場合は,nfsd デーモンを強制終了して,再起動します。 それでも解決しない場合は,サーバをリブートします。 リモートのファイル・システムまたはディレクトリが hard オプションを使用してマウントされている場合,サーバが再実行されるとプログラムが再開します。

  3. リモート・サーバによって,ネットワーク上の他のクライアントで問題が発生しているかどうかを調べます。 問題ない場合は,クライアント・システムとリモート・サーバ間のイーサネット接続およびインターネット接続が正しく機能していることを確認します。

  4. 次のコマンドを入力して nfsiod デーモンの実行を確認します。

    # ps -e | grep nfsiod
    

    nfsiod デーモンが実行されていない場合は,次のコマンドを入力して,いくつか起動します。

    # /usr/sbin/nfsiod 7
    

    nfsiod デーモンはクライアントには必須ではありませんが,先読み/後書き機能があるため,I/O が高速になります。

  5. ファイル・アクセス要求は成功するが,ファイル・ロック要求が無期限にハングする場合は,ローカルの rpc.statd および rpc.lockd デーモンの実行を確認します。

    # ps -e | grep rpc.statd
    # ps -e | grep rpc.lockd
    

    これらのデーモンが実行されていない場合は,起動します。 次のコマンドを入力します。

    # /usr/sbin/rpc.statd
    # /usr/sbin/rpc.lockd
    

    また,サーバでローカルの rpc.statd および rpc.lockd デーモンの実行を確認します。

    # rpcinfo -p server_name | grep statusrpcinfo -p server_name | grep lockmgr
    

    それらが実行されていない場合は,サーバ・システム管理者にお問い合わせください。

また,NFS デーモンの状態を見るために,SysMan Menu ユーティリティを使用することもできます。 次のコマンドを入力することによって,状態ダイアログ・ボックスに直接行くことができます。

# /usr/sbin/sysman nfs_daemon_status

9.9    AutoFS に関する問題の解決


サーバおよびクライアント・システムで,NFS が正常に構成されて機能していることを確認します。 AutoFS では,NFS がファイル・システムのサービスを行う必要があります。

NFS の基本的なトラブルシューティングについての説明は,9.7 節9.8 節 にあります。


AutoFS サービスが構成されて実行されていることを確認するには,次の手順に従ってください。

  1. rcmgr ユーティリティを使用して,/etc/rc.config.common ファイル内の AUTOFSAUTOFSD_ARGSAUTOFSMOUNT_ARGS パラメータの値を表示します。

    # rcmgr -c get parameter
    

    パラメータが次のように設定されていることを確認します。

    • AUTOFS パラメータには 1 を設定する必要があります。 これは,システムのリブートや NFS サービスの再起動で起動されることを示します。

    • AUTOFSD_ARGS および AUTOFSMOUNT_ARGS パラメータには,autofsd デーモンおよび autofsmount コマンドに適した引数を構成する必要があります。 詳細は 4.6.3.2 項4.6.3.4 項autofsd(8)autofsmount(8) を参照してください。

      注意

      -D オプションを用いて AutoFS の環境変数を定義する場合,AUTOFSD_ARGS および AUTOFSMOUNT_ARGS パラメータに同じ変数を定義しなければなりません。

    必要に応じて,次のように rcmgr ユーティリティを使用して不適切なパラメータを変更します。

    # rcmgr -c set parameter "value"
    

    その後,次のコマンドで NFS を停止して再起動します。

    # /sbin/init.d/nfs stop
    # /sbin/init.d/nfs start
    

    この後,次のコマンドを入力すると,/usr/bin/autofsd デーモンが実行されていることを確認できます。

    # ps -e | grep autofsd
    

  2. 次のコマンドを入力して,/usr/sbin/automount デーモンが実行されていないことを確認します。

    # ps -e | grep automount
    

    AutoFS と Automount は,同じシステムで同時に実行することはできません。 automount デーモンが実行されている場合は,次のようにして関連プロセスを終了します。

    # kill -TERM automount-pid
    

    また,rc.config.common ファイル内の AUTOMOUNT パラメータの値を更新して,Automount が起動されないようにします。

    # rcmgr -c set AUTOMOUNT 0
    

    その後,次のコマンドで NFS を停止して再起動します。

    # /sbin/init.d/nfs stop
    # /sbin/init.d/nfs start
    

まだ問題がある場合はサービス担当者に報告してください。 第 12 章を参照。

AutoFS の自動マウントが期待どおりに行われない場合は,次の手順に従ってください。

  1. daemon.log および user.log ファイルで AutoFS に関するエラー・メッセージを調べます。 syslogd メッセージ・ファイルの表示についての詳細は,10.4 節 を参照してください。

    autofsd デーモンが報告するエラーの中では,エクスポートの許可が不十分であることと,サーバが応答しないために発生するタイムアウトが最も一般的です。 この場合も,NFS のトラブルシューティングについての基本的な説明は 9.7 節9.8 節を参照してください。

  2. 問題になっている自動マウントの AutoFS 介入ポイントが存在していることを確認します。

    次のコマンドを入力して,システムの AutoFS 介入ポイントをすべてリストします。

    # mount -e | grep autofs
    

    期待した介入ポイントが定義されていない場合は,次のようにします。

    注意

    インダイレクト・マップには,介入ポイントが 1 つのみ関連付けられています。

    1. 関連する AutoFS マップが NIS から提供されている場合は,次のコマンドを入力して NIS のマップが最新バージョンであることを確認します。

      # ypcat -d domain mapname
      

      ypcat コマンドが古いマップ・ファイルのエントリを表示した場合は,3.4.5 項の説明に従って,マップを更新して再配置します。

      ypcat コマンドの応答がない場合は,9.5 節9.6 節 の NIS のトラブルシューティングを参照してください。

    2. ローカルまたは NIS が配置したマップ・ファイルで,関連するエントリの構文と綴りを確認します。 マップ・ファイルの構文についての詳細は,付録 Aを参照してください。

    3. 最近に変更または削除した AutoFS マップがあるときには,対応するマウントまたはシンボリック・リンクを削除していることを確認します。 AutoFS は,アクティブなマウントまたはシンボリック・リンクで占有されている介入ポイントにファイル・システムを自動マウントすることはできません。

      次のコマンドを入力して,現在システム上にマウントされている NFS ファイル・システムをリストします。

      # mount -e -t nfs
      

      このリスト上で,介入ポイントと相いれない AutoFS マウントを削除します。 次のコマンドを使用します。

      # autofsmount -t directory
      

      シンボリック・リンクは mount コマンドでは表示されないので,AutoFS が生成するシンボリック・リンクは手動で検索する必要があります。 必要に応じて,AutoFS マップのエントリを調べて,シンボリック・リンクでどのファイル・システムがサービスされるか確認し,それから ls -l コマンドでそのリンクを探すこともできます (AutoFS の動作についての詳細は,A.4 節を参照してください)。

      自動マウントに関連するシンボリック・リンクを発見したら,次のように rm コマンドを実行して削除できます。

      # rm link
      

    4. 介入ポイントに手動でマウントしていた可能性のある NFS ファイル・システムを削除したことを確認します。

      次のコマンドを入力して,現在システムにマウントされている NFS ファイル・システムをリストします。

      # mount -e -t nfs
      

      このリスト上で,介入ポイントと相いれない手動マウントを削除します。 umount コマンドを使用し,必要に応じて /etc/fstab ファイルを編集します。

    マップ・ファイルの確認と AutoFS 介入ポイントのクリアが終了したら,autofsmount コマンドを適切な引数で実行して変更を適用します。 rc.config.common ファイルの AUTOFSMOUNT_ARGS パラメータで引数を定義した場合は,次のコマンドを実行できます。

    # /usr/sbin/autofsmount `rcmgr -c get AUTOFSMOUNT_ARGS`
    

    次に,mount -e コマンドを実行して,目的の介入ポイントが存在していることを確認します。

  3. まだ問題がある場合は,次のコマンドで,関連するマップ・ファイルに対する AutoFS 介入ポイントと自動マウントされたファイル・システムをすべて削除します。

    # /usr/sbin/autofsmount -M mapname
    

    注意

    使用中のファイル・システムはアンマウントできません。 まずユーザがそれを解放する必要があります。

    次に,以前と同じように autofsmount および mount -e コマンドを実行してマップを処理し,目的の介入ポイントが存在することを確認します。

9.10    UUCP に関する問題の解決


UNIX-to-UNIX Copy Facility サブセットがインストールされていることを確認します。 次のコマンドを入力します。

# setld -i | grep OSFUUCP

インストール済みであれば,次のメッセージが表示されます。

OSFUUCPnnn  installed UNIX(tm)-to-UNIX(tm) Copy Facility (General Applications)

このサブセットがインストールされていない場合は,setld コマンドを使用してインストールします。 サブセットのインストールについての詳細は,『システム管理ガイド』を参照してください。


ネットワーク・サービスの基本サブセット (ユーティリティの tip および cu が入っている) がインストールされていることを確認します。 次のコマンドを入力します。

# setld -i | grep OSFCLINET

インストール済みであれば,次のメッセージが表示されます。

OSFCLINETnnn  installed Basic Networking Services  (Network-Server/Communications)

ネットワーク・サービスの基本サブセットがインストールされていない場合は,setld コマンドを使用してインストールします。 サブセットのインストールについての詳細は,『インストレーション・ガイド』を参照してください。


/usr/lib/uucp ディレクトリで,PermissionsDevices,および Systems の各ファイル内にエントリが存在することを確認します。 エントリがない場合は,uucpsetup スクリプトを実行します。 詳細については, 5.3 節を参照してください。


ネットワーク・ハードウェアを次のように構成します。

  • リモート・ホストへの直接接続 -- ヌル・モデム・ケーブルまたはモデム・エリミネータ・ケーブルを使用してシステムをリモート・ホストと接続します。

  • リモート・ホストへの電話回線接続 -- 2本のケーブルを使用して,モデムと電話回線,システムとモデムをそれぞれ接続します。 使用するモデムは,リモート・ホストのモデムと互換性がなければなりません。 モデムが,次のように構成されていることを確かめます。

    • 強制データ・セット・レディ (DSR) を禁止していること。

    • 完全な状態メッセージ,つまり冗長な状態メッセージを可能にしていること。

    • 文字エコーを禁止していること。

    • パリティなしの8ビット文字を使用していること。

    • XON/XOFF フロー制御を禁止していること。

  • リモート・ホストへの TCP/IP 接続 -- ケーブルを使用してシステムをネットワークと接続します。 その後,Network Configurationアプリケーションを実行して,ネットワークを構成します。 ネットワークの設定についての詳細は,『ネットワーク管理ガイド:接続編』を参照してください。


リモート・システムにダイアル・アップできない場合は,次のことを確かめます。

  1. ローカル・エンドとリモート・エンドの設定パラメータ (速度,パリティ,モデム制御,フロー制御,およびその他のターミナル属性など) がご使用のモデム・タイプに適合するように定義されていることを確認します。

  2. リモート・ノードの電話番号をダイアルします。 Attached メッセージやログイン・プロンプトが表示されない場合は,電話機をローカルの電話回線に接続して発信音が聞こえることを確認します。 発信音が聞こえない場合は,地域の電話会社に連絡してこの問題を解決します。 メッセージが表示されない場合は,ローカル・システムとモデム間のケーブルが正しく接続されており,ケーブルに損傷がないことを確認します。

  3. 発信音が聞こえる場合は,モデムが動作していることを確かめ,モデムに対して診断テストを実行します。 詳細については,モデムのマニュアルを参照してください。

  4. 別の電話機から,ローカル電話回線の電話番号をダイアルします。 ローカル側の電話が鳴り,会話ができる場合は,ローカル・エンドの電話回線には問題はありません。 会話ができないか,または電話が鳴らない場合は,地域の電話会社に連絡してこの問題を解決します。

  5. 手順2と3をリモート・ノードについて繰り返して,リモート・エンド側の問題を解決します。

  6. 電話回線に問題がない場合は,システム側がデータ端末レディ (DTR) 信号を上げたときに, リモート・モデムが着信呼び出しに対して自動的に応答するように設定されていることを確認します。 システムは,コマンド uugetty または getty をポートに対して実行することによって DTR 信号を上げます。


uucp テストを実行して,リモート・システムへの接続をテストします。 10.1 節 および 10.2 節 を参照してください。

接続を確立できても,ファイル転送がタイムアウトや終了してしまう場合は, 5.3.5 項 および uucico(8) リファレンス・ページで説明されているように, uucico デーモンが使用するフロー制御のタイプの設定を試みてください。

まだ問題がある場合はサービス担当者に報告してください。 第 12 章 を参照。

tip コマンドが異常終了する場合は,次の手順に従ってください。

  1. システム名,接続速度,および電話番号が /etc/remote ファイルに記述されていること,またはシステム名と接続速度が /etc/remote ファイルに,電話番号が /etc/phones ファイルにそれぞれ記述されていることを確認します。 詳細については, remote(4) および phones(4) を参照してください。

  2. /etc/remote ファイルの at エントリを調べます。 エントリが正しい場合は,/etc/acucap ファイルにモデムのエントリを作成します。 詳細については, acucap(4) を参照してください。

  3. リモート・システムが,着信呼び出しに応答するように構成されていることを確認します。

9.11    NTP に関する問題の解決


rcmgr ユーティリティを使用して,/etc/rc.config ファイル内の XNTPD_CONF エントリの値を表示します。

# rcmgr get XNTPD_CONF

何も返されなかった場合は,NTP を構成するために SysMan Menu ユーティリティを実行します。 詳細については,6.3 節 を参照してください。


xntpd プロセスが実行されていることを確認します。 次のコマンドを入力します。

# ps -e | grep xntpd

また,xntpd デーモンの状態を見るために SysMan Menu ユーティリティを使用することもできます。 次のコマンドを入力することによって,状態ダイアログ・ボックスに直接行くことができます。

# /usr/sbin/sysman ntp_status

xntpd プロセスが 1 つも実行されていない場合は,次のコマンドを使用して NTP を起動します。

# /sbin/init.d/xntpd start


コマンド ntpq または xntpdc によってサーバ・ホストが見つからない場合は,次のメッセージが表示されます。

***Can't find host hostname

hostname が,/etc/hosts ファイル,DNS hosts データベース,または NIS hosts データベースにありません。 適切なファイルまたはデータベースを編集して,サーバ・ホストのエントリを追加します。


モニタ・プログラムの 1 つを実行して,peers コマンドからの出力の reach カラムに複数のゼロ (0) が含まれる場合は,次の手順に従ってください。

  1. サーバのシステム管理者に問い合わせて,サーバが実行している NTP デーモンを確認します。 /etc/ntp.conf ファイルにあるサーバのエントリには,次のようにサーバ名の後に version x のフレーズが含まれている必要があります。

    server host1 version x
    

  2. /etc/hosts ファイルの内容を調べ,各 NTP サーバのエントリが /etc/ntp.conf ファイルに指定されていることを確認します。 DNS または NIS のホスト情報を使用している場合は,hosts データベースに,各 NTP サーバのエントリがあることを確認します。

xntpdc hostname コマンドを実行しても何の情報も表示されない場合は,hostname サーバが NTP を実行していることを確認します。

まだ問題がある場合はサービス担当者に報告してください。 第 12 章 を参照。

ntpq 要求または xntpdc 要求がタイムアウトになる場合は,次のメッセージが表示されます。

hostname: timed out, nothing received
***Request timed out

次の手順に従ってください。

  1. hostnamexntpd デーモンを実行していません。 該当するシステムの管理者に連絡してください。

  2. ネットワーク接続がダウンしています。 解決手順については,『ネットワーク管理ガイド:接続編』の診断マップで「ホストに到達可能 ?」を参照してください。

それでも問題が解決しない場合は,次の手順に従ってください。

  1. /etc/rc.config ファイルの内容を調べ,次のようなエントリがあることを確かめます。

    XNTPD_CONF="YES"
    export XNTPD_CONF
    XNTP_SERV1=server1
    export XNTP_SERV1
    XNTP_SERV2=server2
    export XNTP_SERV2
    XNTP_SERV3=server3
    export XNTP_SERV3
    XNTPD_OPTS="-g"
    export XNTPD_OPTS
    

    このエントリが存在しないか,または正しくない場合は,/usr/sbin/ntpsetup スクリプトを実行します。 詳細については,6.3 節 を参照してください。

  2. /etc/ntp.conf ファイルの内容を調べ,その情報が正しいことを確認します。 このファイルには,NTP を実行していて,システム時間の同期をとりたいホストのエントリが含まれている必要があります。 サーバとピアのそれぞれに対して,正確なバージョン番号が指定されていることを確認します。 エントリを修正するには,SysMan Menu ユーティリティを使用します。 詳細については,6.3 節 を参照してください。

  3. /var/adm/syslog.dated/current/daemon.log ファイル内で,システムで発生している NTP の問題に関する情報を調べます。 詳細については,10.4 節を参照してください。

9.12    sendmail に関する問題の解決


/var/adm/sendmail ディレクトリに切り換えることによって,また,sendmail.cf および sendmail.cf.orig ファイルがあるかどうか確認することによって,メールが構成されたかどうかを確かめます。

いずれかのファイルが存在しない場合には,メール構成をするために SysMan Menu ユーティリティを実行します。 詳細については,6.3 節 を参照してください。


sendmail コマンドがスタートしていることを確認します。 次のコマンドを入力します。

# ps -e | grep sendmail

sendmail が実行されていない場合は,次のコマンドを使用してスタートさせます。

# /sbin/init.d/sendmail start


ユーザが他のユーザにメールを送信できない場合は,次の手順に従ってください。

  1. aliases データベースが変更されたかどうかをチェックします。 変更されていた場合は,newaliases コマンドを使用してデータベースを更新します。

  2. syslogd デーモンが生成した mail.log ファイル内で,該当するメール・メッセージを調べます。 メッセージがその宛先に到達している場合,宛先のシステムには該当するアドレスがありません。 ユーザのアドレスが正しいかどうか確認してください。 syslogd メッセージ・ファイルの見方についての説明は,10.4 節 を参照してください。


メール・メッセージを送信しても受信者が受信しなかった場合は,次の手順に従ってください。

  1. アドレスが正しいことを確認します。

  2. ping コマンドを使用して,リモート・ノードに到達可能であることを確認します。

  3. syslogd デーモンによって生成された mail.log ファイルの,送信者のユーザ名を検索します。 syslogd メッセージ・ファイルの見方についての説明は,10.4 節 を参照してください。 エントリがあった場合は,メッセージ ID を書き留めます。 送信者のユーザ名が見つからない場合は,再びメッセージを送信します。

  4. メッセージ ID を使用して,mail.log ファイルの "from" エントリと "to" エントリを検索します。 "from" エントリはあるが "to" エントリがない場合は,sendmail がメッセージを受信しなかったか,またはメッセージが破損したかのいずれかです。 次のコマンドを入力して,/var/spool/mqueue ディレクトリ内の,該当するメッセージ ID を含むファイルを見つけます。

    ls -l /var/spool/mqueue/*fmessage_ID
    

    次のような結果が考えられます。

    • 制御ファイル qf*message_ID はあるが,データ・ファイル (df*message_ID) がない場合は,メッセージが破損しています。

    • "from" エントリも "to" エントリもあるが,状態が延期の場合は,メッセージはキューに入っています。

    • 対応する送信済みのエントリがない場合は,mailq コマンドを使用すると,ファイルを送信して延期の理由が表示されます。

    • "from" エントリも "to" エントリもあるが,状態が送信済みの場合は,メッセージが宛先に配布済みです。 ローカル内での配布の場合は,メッセージが宛先に配布されたはずです。 リモートへの配布の場合は,リモート・ホストのシステム管理者にメッセージを探索してもらってください。

まだ問題がある場合はサービス担当者に報告してください。 第 12 章 を参照。

sendmail が正常に作動しない場合は,次の手順に従ってください。

  1. リジェクトされたメッセージ内のエラー・メッセージを調べます。

  2. syslogd デーモンによって生成された mail.log ファイル内のエラー・メッセージを調べます。 syslogd メッセージ・ファイル群の内容については,10.4 節を参照してください。

sendmail エラー・メッセージのリストは,付録 E を参照してください。

9.13    POP および IMAP に関する問題の解決


サーバに Additional Networking Services サブセットがインストールされていることを確認します。 次のコマンドを入力します。

# setld -i | grep OSFINET

インストール済みであれば,次のメッセージが表示されます。

OSFINETnnn installed Additional Networking Services  (Network-Server/Communications)

このサブセットがインストールされていない場合は,setld コマンドを使用してインストールします。 インストール方法についての詳細は,『インストレーション・ガイド』 を参照してください。


ユーザが POP (Post Office Protocol) サーバまたは IMAP (Internet Message Access Protocol) サーバに接続できない場合は,次の手順に従ってください。

  1. ユーザが正しいサーバに接続を試みていることを確認します。

  2. ping コマンドを使用して,そのサーバに到達可能であることを確認します。

  3. 7.4.1 項 および 7.5.1 項 で説明するように,/etc/passwd/etc/services,または /etc/inetd.conf ファイルの POP または IMAP エントリを確認します。 必要に応じて,ネットワーク・サービスを再起動し,変更内容を有効にします。


ユーザが有効なユーザ名とパスワードを指定していることを確認します。 mailusradm ユーティリティを使用して,サーバ上に POP または IMAP アカウントが存在することを確認し,また,必要に応じてパスワードを変更します。


ユーザが POP または IMAP サーバからメールを検索できない場合は,次の手順に従ってください。

  1. ユーザが,POP3 または IMAP4 と互換性があるメール・プログラムを使用していることを確認します。

  2. POP の場合は,/usr/spool/mail ディレクトリで,ユーザ名と同じ名前のロック・ファイルを探します。 存在する場合は,そのファイルを削除してロックを除去します。

  3. IMAP の場合は,cyradm コマンドを使用して,ユーザが IMAP メール・フォルダ用の正しい ACL を持っていることを確認します。 詳細については,7.5.8 項 および cyradm(8) を参照してください。

  4. syslogd デーモンによって生成された mail.log ファイル内で,POP または IMAP に関連するエラー・メッセージを調べます。 syslogd メッセージ・ファイルの表示については,10.4 節 を参照してください。

  5. configdirectory/log ディレクトリで,ユーザのアカウント名を付けたディレクトリを作成します (通常,ログ・ディレクトリは /var/imap/log です。 システム上の configdirectory の位置については,/etc/imapd.conf ファイルを参照してください)。 ユーザがサーバにアクセスを試みるときにセッションのログを調べ,どこでエラーが起こっているか確認します。

まだ問題がある場合はサービス担当者に報告してください。 第 12 章 を参照。

ユーザが新しいメールを受信できない場合は,次の手順に従います。

  1. syslogd デーモンが生成した mail.log ファイル内のエラー・メッセージを調べます。 syslogd メッセージ・ファイルの内容については,10.4 節を参照してください。

  2. IMAP を使用している場合には,構成ディレクトリ (user および quota) を参照して,az の各サブディレクトリが存在していること (7.5.2 項を参照),これらのサブディレクトリにユーザ用の適切なファイルが格納されていること (7.5.6 項を参照),および /var/imap ディレクトリと /var/spool/imap ディレクトリ内のすべてのディレクトリとファイルが imap ユーザによって所有されていることを確認します。

ユーザがメールを送信できない場合は,次の手順に従います。

  1. ユーザが,正しい SMTP サーバに接続を試みていることを確認します。

  2. ping コマンドを使用して,SMTP サーバに到達可能であることを確認します。

  3. sendmail の問題の解決方法については,9.12 節を参照してください。