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"
メッセージが表示された場合は,次の手順を実行します。
更新や転送に正しい鍵を使用していることを確認します。
鍵名のスペルを確認します。
鍵文字列が正しいかチェックします。
鍵を囲む引用符の間には,改行文字やスペース文字は使用できません。
鍵のアルゴリズムとして
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 章
を参照。
|
ネットワーク・コマンド (たとえば
telnet ,rlogin ,および
rsh ) のうち 1 つを実行しようとした場合にリモート・ホストが未知であると,次のメッセージが表示されます。
unknown host
次の手順に従ってください。
/etc/svc.conf
ファイルの内容を調べ,DNS が
hosts
データベース検索に使用されているかどうかをチェックします。
DNS が使用されている場合は,手順 2 に進んでください。
使用されていない場合は,/etc/svcsetup
コマンドを使用して,/etc/svc.conf
ファイルに追加します。
nslookup
コマンドを使用して,通信しようとしたリモート・ホストについての情報を検索します。
次のコマンドを入力します。
# nslookup hostname
コマンドが正常に終了する場合は,クライアントが正しく設定されています。
ネットワーク・コマンドを再実行します。
コマンドが異常終了する場合は,手順 3 に進んでください。
/etc/resolv.conf
ファイルを表示して,nameserver
エントリのアドレスを検索します。
ping
コマンドを使用して,DNS/BIND サーバが到達可能であることを確認します。
到達可能なサーバがない場合は,ネットワーク管理者にお問い合わせください。ping
コマンドに応答しないネーム・サーバがある場合は,そのネーム・サーバのエントリを
resolv.conf
ファイルから削除します。
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
コマンドによって,データベースが更新されなかったことが示された場合は,次の手順に従ってください。
/var/yp
および
/var/yp/domainname
ディレクトリから
database_name.time
ファイルを削除します。
make
コマンドを使用して新しいマップを作成します。
次のコマンドを入力します。
# cd /var/yp
# make map_name
|
まだ問題がある場合はサービス担当者に報告してください。
第 12 章
を参照。
|
NIS マップの更新がスレーブ・サーバに受信されなかったと考えられる場合は,スレーブ・サーバで次の手順に従ってください。
NIS マスタ・サーバが稼働しており,アクセス可能であることを,ping
コマンドを使って確認します。
ypxfr
ログ・ファイルを作成します。
次のコマンドを入力します。
# cd /var/yp
# touch ypxfr.log
マップ更新を取得するために,ypxfr
を対話モードで実行します。
次のコマンドを入力します。
# ypxfr mapname
ypxfr.log
ファイルの内容を調べ,すべての問題を解決します。
ログ・ファイルを削除してロギングをオフにします。
/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
対応する
ypxfr
シェル・スクリプト内にマップのエントリが存在することを確認します。
syslogd
デーモン・メッセージ・ファイルの内容を調べ,NIS メッセージの存在を確認します。
詳細については,10.4 節を参照してください。
スレーブ・サーバがドメインの
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
クライアントがサーバと通信できません。
次の手順に従ってください。
rcmgr
コマンドを使用して,domainname
コマンドによって返されたドメイン名がサーバの
/etc/rc.config.common
ファイル内の
NIS_DOMAIN
エントリの値に一致していることを確認します。
# rcmgr get NIS_CONF
ドメイン名が一致していないか,または環境特有の条件を満たしていない場合は,SysMan Menu ユーティリティを使用してクライアント・システムを再構成します。
(ドメイン名は大文字と小文字が区別される点に注意してください。) 詳細については,3.3 節
を参照してください。
ドメイン用の NIS サーバが最低でも 1 つ,ローカルのサブネットワークで実行されていることを確認します。
実行されていない場合は,SysMan Menu ユーティリティを使用してクライアントを再構成してから,
ypbind
コマンドで
-S
オプションを使用します。
サブネットワーク上の他のクライアントについて,NIS コマンドのいずれかによって問題が発生していないかどうかを調べます。
リモート・システムのサーバ・デーモンが実行されていることを確認します。
次のコマンドを入力します。
# rpcinfo -p server_name
また,次のコマンドを入力して,サーバ上で
ypserv
デーモンが現在実行されていることを確認します。
# rpcinfo -t server_name ypserv 2
上記のいずれか (または両方) のテストで正しい結果が得られなかった場合には,サーバ上で次のコマンドを実行し,NIS をいったん終了して再起動します。
# /sbin/init.d/nis stop
# /sbin/init.d/nis start
syslogd
デーモン・メッセージ・ファイルの内容を調べ,NIS メッセージの存在を確認します。
詳細については,
10.4 節
を参照してください。
サーバが実行されていることを確認します。
NIS サーバに関する問題の解決手順については,9.5 節を参照してください。
上記の手順を実行しても問題が解決しない場合は,次の手順に従ってください。
NIS を終了してから,起動します。
次のコマンドを入力します。
# /sbin/init.d/nis stop
# /sbin/init.d/nis start
これでも問題が解決しない場合は,手順 2 に進みます。
システムをリブートします。
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 デーモンが実行されていることを確認するには,次の手順に従ってください。
mountd
プロセスが実行されていることを確認します。
次のコマンドを入力します。
# ps -e | grep mountd
mountd
プロセスが実行されている場合は,手順 2 に進みます。
mountd
プロセスが実行されていない場合は,
次のコマンドを使用して NFS を終了してから,起動します。
# /sbin/init.d/nfs stop
# /sbin/init.d/nfs start
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 章
を参照。
|
ファイルがエクスポートされていることを確認するには,次の手順に従ってください。
次のコマンドを入力してファイルがエクスポートされていることを確認します。
# showmount -e
ファイルがエクスポートされている場合は,手順 3 に進みます。
ファイルがエクスポートされていない場合は,ファイルのエントリが
/etc/exports
ファイルにあることを確認します。
このファイルにエントリがない場合は,ファイルを編集し,エントリを作成します。
リモート・システムにファイルをマウントします。
ファイルがエクスポートされているにもかかわらずマウントできない場合には,rcmgr
ユーティリティを次のように使用して
/etc/rc.config
ファイル内の
NONROOTMOUNTS
エントリの値を表示し,そのファイルのマウントがユーザに許可されているかどうかを調べます。
# rcmgr get NONROOTMOUNTS
NONROOTMOUNTS
パラメータが 0 の場合,root ユーザだけがこのサーバからファイルをマウントできます。
root 以外のユーザがファイルをマウントできるようにするには,次のコマンドを入力します。
# rcmgr set NONROOTMOUNTS 1
次のコマンドを入力して,mountd
デーモンが,インターネット・アドレス・チェックをオンにして実行されていることを確認します。
# ps -e | grep mountd
-i
オプションが表示された場合は,クライアントの名前およびアドレスは,
/etc/hosts
ファイル,DNS または NIS
hosts
データベースのいずれかにあるはずです。
既知のホストだけがファイル・システムをマウントできます。
オプション
-d
または
-s
が表示された場合は,クライアント・システムがサーバと同じ DNS ドメインまたはサブドメインに属しているはずです。
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
デーモンが起動しない場合は,クライアントをリブートしてください。
|

|
クライアントがリモートのファイル・システムまたはディレクトリをマウントできない場合は,次の手順に従ってください。
端末にエラー・メッセージが表示された場合は,付録 Cを参照して,そのエラーについて調べてください。
リモートの NFS サーバが,ローカル・ネットワーク上の
hosts
データベースに記述されていることを確認します。
リモート・システムのサーバ・デーモンが実行されていることを確認します。
次のコマンドを入力します。
# rpcinfo -p server_name
サーバによって,必要なファイルがエクスポートされていることを確認します。
次のコマンドを入力します。
# showmount -e server_name
NFS サーバに関する問題の解決手順は,9.7 節を参照してください。
サーバを実行できるが,依然問題が発生する場合は,クライアント・システムとリモート・サーバ間のイーサネット接続およびインターネット接続を確認します。
ネットワーク上の他のクライアントで,同じリモート・サーバによる問題が発生していないかどうかを調べます。
mount コマンド行または
/etc/fstab
ファイル内のエントリが正しいことを確認し,さらに次のことを確認します。
ホスト名がリモート NFS サーバの名前と一致している
該当するマウント・ポイントがシステムに存在している
認証エラーが表示されたら,次のことを確認します。
スーパユーザでない場合は,サーバが非ルート・マウントを許可していること。
ホスト名がサーバの
hosts
データベースにあること。
システムがサーバと同じドメインにない場合は,サーバによってドメイン・チェックが実行されていること。
サーバのオプションについては,
mountd (8)
を参照してください。
|
まだ問題がある場合はサービス担当者に報告してください。
第 12 章
を参照。
|
ファイル関連のタスクを実行するアプリケーション・プログラムがタスクを完了しないか,または完了に時間かかる場合は,次の手順に従ってください。
端末にエラー・メッセージが表示された場合は,付録 Cを参照して,そのエラーについて調べてください。
サーバの実行を確認します。
NFS サーバに関する問題の解決手順については,
9.7 節
を参照してください。
サーバが実行されている場合は,nfsd
デーモンによる CPU 時間の増加を確認します。
増加していない場合は,nfsd
デーモンを強制終了して,再起動します。
それでも解決しない場合は,サーバをリブートします。
リモートのファイル・システムまたはディレクトリが
hard
オプションを使用してマウントされている場合,サーバが再実行されるとプログラムが再開します。
リモート・サーバによって,ネットワーク上の他のクライアントで問題が発生しているかどうかを調べます。
問題ない場合は,クライアント・システムとリモート・サーバ間のイーサネット接続およびインターネット接続が正しく機能していることを確認します。
次のコマンドを入力して
nfsiod
デーモンの実行を確認します。
# ps -e | grep nfsiod
nfsiod
デーモンが実行されていない場合は,次のコマンドを入力して,いくつか起動します。
# /usr/sbin/nfsiod 7
nfsiod
デーモンはクライアントには必須ではありませんが,先読み/後書き機能があるため,I/O が高速になります。
ファイル・アクセス要求は成功するが,ファイル・ロック要求が無期限にハングする場合は,ローカルの
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 status
# rpcinfo -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 サービスが構成されて実行されていることを確認するには,次の手順に従ってください。
rcmgr
ユーティリティを使用して,/etc/rc.config.common
ファイル内の
AUTOFS ,AUTOFSD_ARGS ,AUTOFSMOUNT_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
次のコマンドを入力して,/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 の自動マウントが期待どおりに行われない場合は,次の手順に従ってください。
daemon.log
および
user.log
ファイルで AutoFS に関するエラー・メッセージを調べます。
syslogd
メッセージ・ファイルの表示についての詳細は,10.4 節
を参照してください。
autofsd
デーモンが報告するエラーの中では,エクスポートの許可が不十分であることと,サーバが応答しないために発生するタイムアウトが最も一般的です。
この場合も,NFS のトラブルシューティングについての基本的な説明は
9.7 節と
9.8 節を参照してください。
問題になっている自動マウントの AutoFS 介入ポイントが存在していることを確認します。
次のコマンドを入力して,システムの AutoFS 介入ポイントをすべてリストします。
# mount -e | grep autofs
期待した介入ポイントが定義されていない場合は,次のようにします。
注意
インダイレクト・マップには,介入ポイントが 1 つのみ関連付けられています。
関連する AutoFS マップが NIS から提供されている場合は,次のコマンドを入力して NIS のマップが最新バージョンであることを確認します。
# ypcat -d domain mapname
ypcat
コマンドが古いマップ・ファイルのエントリを表示した場合は,3.4.5 項の説明に従って,マップを更新して再配置します。
ypcat
コマンドの応答がない場合は,9.5 節
と
9.6 節
の NIS のトラブルシューティングを参照してください。
ローカルまたは NIS が配置したマップ・ファイルで,関連するエントリの構文と綴りを確認します。
マップ・ファイルの構文についての詳細は,付録 Aを参照してください。
最近に変更または削除した AutoFS マップがあるときには,対応するマウントまたはシンボリック・リンクを削除していることを確認します。
AutoFS は,アクティブなマウントまたはシンボリック・リンクで占有されている介入ポイントにファイル・システムを自動マウントすることはできません。
次のコマンドを入力して,現在システム上にマウントされている NFS ファイル・システムをリストします。
# mount -e -t nfs
このリスト上で,介入ポイントと相いれない AutoFS マウントを削除します。
次のコマンドを使用します。
# autofsmount -t directory
シンボリック・リンクは
mount
コマンドでは表示されないので,AutoFS が生成するシンボリック・リンクは手動で検索する必要があります。
必要に応じて,AutoFS マップのエントリを調べて,シンボリック・リンクでどのファイル・システムがサービスされるか確認し,それから
ls
-l
コマンドでそのリンクを探すこともできます (AutoFS の動作についての詳細は,A.4 節を参照してください)。
自動マウントに関連するシンボリック・リンクを発見したら,次のように
rm
コマンドを実行して削除できます。
# rm link
介入ポイントに手動でマウントしていた可能性のある 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
コマンドを実行して,目的の介入ポイントが存在していることを確認します。
まだ問題がある場合は,次のコマンドで,関連するマップ・ファイルに対する 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
ディレクトリで,Permissions ,Devices ,および
Systems
の各ファイル内にエントリが存在することを確認します。
エントリがない場合は,uucpsetup
スクリプトを実行します。
詳細については,
5.3 節を参照してください。
|

|
ネットワーク・ハードウェアを次のように構成します。
リモート・ホストへの直接接続 -- ヌル・モデム・ケーブルまたはモデム・エリミネータ・ケーブルを使用してシステムをリモート・ホストと接続します。
リモート・ホストへの電話回線接続 -- 2本のケーブルを使用して,モデムと電話回線,システムとモデムをそれぞれ接続します。
使用するモデムは,リモート・ホストのモデムと互換性がなければなりません。
モデムが,次のように構成されていることを確かめます。
リモート・ホストへの TCP/IP 接続 -- ケーブルを使用してシステムをネットワークと接続します。
その後,Network Configurationアプリケーションを実行して,ネットワークを構成します。
ネットワークの設定についての詳細は,『ネットワーク管理ガイド:接続編』を参照してください。
|

|
リモート・システムにダイアル・アップできない場合は,次のことを確かめます。
ローカル・エンドとリモート・エンドの設定パラメータ (速度,パリティ,モデム制御,フロー制御,およびその他のターミナル属性など) がご使用のモデム・タイプに適合するように定義されていることを確認します。
リモート・ノードの電話番号をダイアルします。
Attached
メッセージやログイン・プロンプトが表示されない場合は,電話機をローカルの電話回線に接続して発信音が聞こえることを確認します。
発信音が聞こえない場合は,地域の電話会社に連絡してこの問題を解決します。
メッセージが表示されない場合は,ローカル・システムとモデム間のケーブルが正しく接続されており,ケーブルに損傷がないことを確認します。
発信音が聞こえる場合は,モデムが動作していることを確かめ,モデムに対して診断テストを実行します。
詳細については,モデムのマニュアルを参照してください。
別の電話機から,ローカル電話回線の電話番号をダイアルします。
ローカル側の電話が鳴り,会話ができる場合は,ローカル・エンドの電話回線には問題はありません。
会話ができないか,または電話が鳴らない場合は,地域の電話会社に連絡してこの問題を解決します。
手順2と3をリモート・ノードについて繰り返して,リモート・エンド側の問題を解決します。
電話回線に問題がない場合は,システム側がデータ端末レディ (DTR) 信号を上げたときに,
リモート・モデムが着信呼び出しに対して自動的に応答するように設定されていることを確認します。
システムは,コマンド
uugetty
または
getty
をポートに対して実行することによって DTR 信号を上げます。
|

|
uucp
テストを実行して,リモート・システムへの接続をテストします。
10.1 節
および
10.2 節
を参照してください。
接続を確立できても,ファイル転送がタイムアウトや終了してしまう場合は,
5.3.5 項
および
uucico (8)
リファレンス・ページで説明されているように,
uucico
デーモンが使用するフロー制御のタイプの設定を試みてください。
|
まだ問題がある場合はサービス担当者に報告してください。
第 12 章
を参照。
|
tip
コマンドが異常終了する場合は,次の手順に従ってください。
システム名,接続速度,および電話番号が
/etc/remote
ファイルに記述されていること,またはシステム名と接続速度が
/etc/remote
ファイルに,電話番号が
/etc/phones
ファイルにそれぞれ記述されていることを確認します。
詳細については,
remote (4)
および
phones (4)
を参照してください。
/etc/remote
ファイルの
at
エントリを調べます。
エントリが正しい場合は,/etc/acucap
ファイルにモデムのエントリを作成します。
詳細については,
acucap (4)
を参照してください。
リモート・システムが,着信呼び出しに応答するように構成されていることを確認します。
|
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) が含まれる場合は,次の手順に従ってください。
サーバのシステム管理者に問い合わせて,サーバが実行している NTP デーモンを確認します。
/etc/ntp.conf
ファイルにあるサーバのエントリには,次のようにサーバ名の後に
version x
のフレーズが含まれている必要があります。
server host1 version x
/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
次の手順に従ってください。
hostname
が
xntpd
デーモンを実行していません。
該当するシステムの管理者に連絡してください。
ネットワーク接続がダウンしています。
解決手順については,『ネットワーク管理ガイド:接続編』の診断マップで「ホストに到達可能 ?」を参照してください。
それでも問題が解決しない場合は,次の手順に従ってください。
/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 節
を参照してください。
/etc/ntp.conf
ファイルの内容を調べ,その情報が正しいことを確認します。
このファイルには,NTP を実行していて,システム時間の同期をとりたいホストのエントリが含まれている必要があります。
サーバとピアのそれぞれに対して,正確なバージョン番号が指定されていることを確認します。
エントリを修正するには,SysMan Menu ユーティリティを使用します。
詳細については,6.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
|

|
ユーザが他のユーザにメールを送信できない場合は,次の手順に従ってください。
aliases
データベースが変更されたかどうかをチェックします。
変更されていた場合は,newaliases
コマンドを使用してデータベースを更新します。
syslogd
デーモンが生成した
mail.log
ファイル内で,該当するメール・メッセージを調べます。
メッセージがその宛先に到達している場合,宛先のシステムには該当するアドレスがありません。
ユーザのアドレスが正しいかどうか確認してください。
syslogd
メッセージ・ファイルの見方についての説明は,10.4 節
を参照してください。
|

|
メール・メッセージを送信しても受信者が受信しなかった場合は,次の手順に従ってください。
アドレスが正しいことを確認します。
ping
コマンドを使用して,リモート・ノードに到達可能であることを確認します。
syslogd
デーモンによって生成された
mail.log
ファイルの,送信者のユーザ名を検索します。
syslogd
メッセージ・ファイルの見方についての説明は,10.4 節
を参照してください。
エントリがあった場合は,メッセージ ID を書き留めます。
送信者のユーザ名が見つからない場合は,再びメッセージを送信します。
メッセージ 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
が正常に作動しない場合は,次の手順に従ってください。
リジェクトされたメッセージ内のエラー・メッセージを調べます。
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) サーバに接続できない場合は,次の手順に従ってください。
ユーザが正しいサーバに接続を試みていることを確認します。
ping
コマンドを使用して,そのサーバに到達可能であることを確認します。
7.4.1 項
および
7.5.1 項
で説明するように,/etc/passwd ,/etc/services ,または
/etc/inetd.conf
ファイルの POP または IMAP エントリを確認します。
必要に応じて,ネットワーク・サービスを再起動し,変更内容を有効にします。
|

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

|
ユーザが POP または IMAP サーバからメールを検索できない場合は,次の手順に従ってください。
ユーザが,POP3 または IMAP4 と互換性があるメール・プログラムを使用していることを確認します。
POP の場合は,/usr/spool/mail
ディレクトリで,ユーザ名と同じ名前のロック・ファイルを探します。
存在する場合は,そのファイルを削除してロックを除去します。
IMAP の場合は,cyradm
コマンドを使用して,ユーザが IMAP メール・フォルダ用の正しい ACL を持っていることを確認します。
詳細については,7.5.8 項
および
cyradm (8)
を参照してください。
syslogd
デーモンによって生成された
mail.log
ファイル内で,POP または IMAP に関連するエラー・メッセージを調べます。
syslogd
メッセージ・ファイルの表示については,10.4 節
を参照してください。
configdirectory/log
ディレクトリで,ユーザのアカウント名を付けたディレクトリを作成します (通常,ログ・ディレクトリは
/var/imap/log
です。
システム上の
configdirectory
の位置については,/etc/imapd.conf
ファイルを参照してください)。
ユーザがサーバにアクセスを試みるときにセッションのログを調べ,どこでエラーが起こっているか確認します。
|
まだ問題がある場合はサービス担当者に報告してください。
第 12 章
を参照。
|
ユーザが新しいメールを受信できない場合は,次の手順に従います。
syslogd
デーモンが生成した
mail.log
ファイル内のエラー・メッセージを調べます。
syslogd
メッセージ・ファイルの内容については,10.4 節を参照してください。
IMAP を使用している場合には,構成ディレクトリ (user
および
quota ) を参照して,a
〜
z
の各サブディレクトリが存在していること (7.5.2 項を参照),これらのサブディレクトリにユーザ用の適切なファイルが格納されていること (7.5.6 項を参照),および
/var/imap
ディレクトリと
/var/spool/imap
ディレクトリ内のすべてのディレクトリとファイルが
imap
ユーザによって所有されていることを確認します。
ユーザがメールを送信できない場合は,次の手順に従います。
ユーザが,正しい SMTP サーバに接続を試みていることを確認します。
ping
コマンドを使用して,SMTP サーバに到達可能であることを確認します。
sendmail
の問題の解決方法については,9.12 節を参照してください。
|