#
# UserDir is disabled by default since it can confirm the presence
# of a username on the system (depending on home directory
# permissions).
#
372 UserDir disable →コメント化する
・・・
379 #UserDir public_html →非コメント化する
387 #→非コメント化
・・・ →非コメント化
398 # →非コメント化
なお、372行目と379行目のオリジナルからの変更は、372行目または379行目のどちらか一方の変更のみでよい。
③ユーザのホームディレクトリ／ホームページディレクトリ、ファイルの属性設定に間違いがある。
正しい設定：
ディレクトリ ：drwx--x--x
ホームページファイル ：-rw-r--r--
Q5. マニュアルページが表示されてしまう。
A5. WWW設定（httpd.conf）でマニュアル表示が有効になっている。
Alias /manual "/var/www/manual"
Q6. 日本語表示で文字化けが起こる。
A6. WWW設定（httpd.conf）のデフォルト文字コード設定（AddDefaultCharset。デフォルトはISO-8859-1）とそのホームページファイルのMETA句のCHARSETの設定、そして、実際の記述コード、の対応が正しくない。
Q7. 評価プログラムevalで以下のエラーとなる。
[3:FAIL] - '/etc/httpd/conf/httpd.conf'('ServerAdmin /')
A7. WWW設定（httpd.conf）のServerAdminの指定でユーザ名@ドメイン名となっていない。
Q8. 評価プログラムevalで以下のエラーとなる。
[3:FAIL] - '/etc/httpd/conf/httpd.conf'('ServerName /')
A8. WWW設定（httpd.conf）のServerNameの指定でサーバ名が正しくないか、または、ポート番号記述（「:80」）が抜けている。
Q9. サーバステータス情報（http://www.example.com/server-status/）が表示されない。
A9. WWW設定（httpd.conf）のサーバステータス情報の有効化、または、サーバステータス情報ディレクトリの設定、がされていない。
#ExtendedStatus On ←サーバステータス情報の有効化がコメント
・・・
# ←サーバステータス情報ディレクトリ
# SetHandler server-status
# Order deny,allow
# Deny from all
# Allow from .your-domain.com
#
Q10. クライアントからのアクセスログ（/var/log/access_log）にクライアントのホスト名ではクライアントのIPアドレスが記録されている。
A10. クライアントからアクセスがあったとき、httpdサーバがそのクライアントのホスト名をログするためには、httpd設定ファイルhttpd.confでホスト名解決の設定「HostnameLookups On」があり、DNSの逆引き名前解決（httpdサーバが接続してきたクライアントのIPアドレスによる逆引き）が可能なことが必要条件。
第9日-2 プロクシサーバ（squid）
Q1. プロクシサーバがエラーで再起動する、または、プロクシの反応が遅い。
A1. プロクシ設定（squid.conf）のキャッシュ関係のサイズ設定が小さい。
cache_mem、cache_dir、など
Q2. プロクシサーバへの接続ができない。
A2. プロクシ設定（squid.conf）のアクセス制御設定（acl、http_access）、または、ブラウザ側のプロクシ設定（プロクシサーバのIPアドレスとポート番号）、に間違いがある。または、squidが起動していない。システム再起動時にsquidが起動していない場合、chkconfigでsquidが自動起動設定になっていない。
Q3. プロクシサーバのログが見づらい。
A3. プロクシ設定（squid.conf）のログ形式がhttpログ形式となっていない。
# emulate_httpd_log off ←オフ状態
Q4. ローカルのWWWサーバへもプロクシサーバ経由となってしまう。
A4. プロクシ設定（squid.conf）のアクセス制御設定（acl、http_access）、または、ブラウザ側のプロクシ設定（「例外設定」）、に間違いがある。
Q5. ログがすぐ消えてしまう。
A5. ログローテーション設定（/etc/logrotate.d/squid）内の記述が短期間となっている。
/var/log/squid/access.log、/var/log/squid/cache.log、/var/log/squid/store.log
weekly ←週単位
rotate 5 ←5世代
第10日-1 SAMBA
Q1. samba設定（smb.conf）を何度も変更しているうちに、大幅に変わってしまい、元へ戻せなくなってしまった。
A2. オリジナル（初期）ファイルをあらかじめ保存しておかなかった。
Q2. sambaサーバがWindowsクライアントのワークグループ内に表示されない。
A2. samba設定（smb.conf）のワークグループ名（workgroup）が同じでない。
Q3. Windowsクライアントからネットワークアクセスできない。
A3. samba設定（smb.conf）のアクセス関係設定が間違っている。
hosts allow、interfaces
または、smb（smbdとnmbd）が起動していない。システム再起動時にsmbが起動していない場合、chkconfigでsmbが自動起動設定になっていない。
Q4. Windowsクライアントからのファイルやフォルダ作成がうまくできない。
A4. samba設定（smb.conf）の属性設定が間違っている。
正しい設定：
create mode = 0644
directory mode = 0755
Q5. Windowsクライアントからsambaサーバへ接続したときのパスワードがエラーとなる。
A5. Windows 9Xの場合、Windowsへのログオンをそのユーザ名で行って（ログオン時にはパスワード不要）いないか、または、Windows XPなどでは、接続後入力したユーザ名やパスワードが正しくない。または、passwdファイルからmksmbpasswdとsmbpasswdで作成したsmbpasswdファイルが正しくない。
Q6. UNIX/Linux側（samba）からsmbclientでWindowsの共有ファイルにアクセスできない。
A6. UNIX/Linux側でのhostsにWindowsシステムの名前とIPアドレスが記述されていない（IPアドレスで接続する場合は、不要）。または、samba設定（smb.conf）のinterfaces設定が間違っている。
Q7. 192.168.0のネットワーク上のすべてのシステムからのアクセスが拒否されてしまう。
A7. samba構成ファイル（/etc/samba/smb.conf）のアクセス許可するクライアントの設定「hosts allow」の値として、「192.168.0.」を「192.168.0」と間違って指定した（最後の「.」を忘れる）場合、192.168.0のネットワーク上のすべてのシステムのアクセスが拒否されてしまう。また、「192.168.0.」と「127.」との間には１つ以上の空白が必要。
第10日-2 スーパーサーバ（xinetd）/telnet/ftp
Q1. ログが記録されない。
A1. スーパーサーバ設定（xinetd.conf）のlog_type指定が間違っている、または、２つ指定してしまった。または、そのログファイルをあらかじめtouchコマンドなどで作成していない。
Q2. telnetやftp、pop3などxinetd経由すべてのアクセスができない。
A2. スーパーサーバ設定（xinetd.conf）のonly_from、no_accessで間違いがある。
Q3. telnetサーバへのアクセスができない。
A3. telnet設定（/etc/xinetd.d/telnet）のdisable設定を無効化していない。
Q4. ftpサーバへのアクセスができない。
A4. vsftp設定（/etc/xinetd.d/vsftpd）のdisable設定を無効化していない、または、server_argsにvsftpd設定ファイルを指定していない、または、vsftpd設定ファイル（vsftpd.conf）がスタンドアロンモード設定（listen=YES）となっている。あるいはまた、アクセスしたユーザがftpd拒否ユーザリスト（vsftpd.ftpusers または vsftpd.user_list）に記載されている。
Q5. ftpクライアントから接続時、ファイル一覧（ls）でユーザとグループ欄に名前ではなく、数値IDが表示される。
A5. vsftpd設定ファイル（vsftpd.conf）内でデフォルトが数値設定となっている（text_userdb_names=NO）。これを「text_userdb_names=YES」とすれば名前表示となる。
Q6. ftpクライアントから接続時、ファイル一覧（ls）で表示される。
A6. vsftpd設定ファイル（vsftpd.conf）内の時間表示がデフォルトのGMT（グリニッジ標準時）表示となっている（use_localtime=NO）。これを「use_localtime=YES」とすればローカル時間になる。
Q7. vsftpd（バージョン1.1.3）のxinetd経由の実行時に、
①ftpユーザとしてはanonymousしかログインできない（エラーメッセージ＝530 This FTP server is anonymous only.）。
②－xinetd経由で実行できない（エラー・メッセージ＝500 OOPS: could not bind listening socket）。
A7. ①rpmパッケージで作成されたxinetd用のvsftpdサービス設定ファイル（/usr/share/doc/vsftpd-1.1.3/vsftpd.xinetd）を/etc/xinetd.d/vsftpdとして（disable行のコメント化して）実行すると、vsftpdプログラム（/usr/sbin/vsftpd）自体はデフォルトのvsftpd設定ファイル「/etc/vsftpd.conf」を使用しようとする。しかし、RedHat Linux 9のvsftpdパッケージの設定ファイルは「/etc/vsftpd/vsftpd.conf」として提供されるので、設定ファイルがないものとして、vsftpdはすべてのパラメータをデフォルトで処理する。ユーザアカウントを使用可能にするlocal_enableはNO、anonymousを使用可能にするanonymous_enableはYES、のため、anonymousしかログインできない。/etc/xinetd.d/vsftpdのserver_argsに、local_enableをYESとした「/etc/vsftpd/vsftpd.conf」を指定すればユーザログインが可能になる。
②/etc/vsftpd/vsftpd.confで、スタンドアロン・モードしか許さない「listen=YES」がデフォルトで設定されているためである。この行をコメント化するか削除することでスタンドアロン・モードを無効にして、vsftpdをxinetdから実行できるようにすればよい。
Q8. vsftpdをスタンドアロンモードに設定したが、ftp接続ができない。
A8. vsftpd設定ファイルの「listen=YES」を行先頭から記述しない（先頭に空白が入る）場合や既にxinetd（inetdモードのvsftpd）を起動している場合にはエラーで接続できない。
【注意】なお、vsftpd.confのマニュアルには重要な注意として「オプション=値」で空白をはさむ場合はエラーである、と記述されている。つまり、行先頭が「#」ならばコメント文で無視され、その他の行では、英文字から始まるオプション、＝、値、の間には空白をはさんではいけないのだが、さらに「前後（前も後ろも、行の先頭も行の最後も）」に空白をはさんでもエラーとなる。ここで、重要な「エラー」だが、エラーであるかどうかは、スタンドアロンモード時はvsftpdがプロセスとして起動しているか、xinetdモード時は実際にアクセスして接続できるかどうか、でしかわからない。つまり、messagesをはじめとしてログには記載されないので、十分な注意が必要である。
第12日-1 sudo
Q1. telnet接続した後、sudoコマンドを実行できない。
A1. sudo設定ファイル（sudoers）のHost_AliasにIPアドレスを設定した。または、User_Aliasにそのユーザを指定していない。または、Host_Alias と User_Alias と Cmnd_Alias の組み合わせが正しくない。
Q2. sudoで特定のコマンドを実行できない。
A2. Cmnd_Aliasの定義行が複数にわたる場合、継続行指定（行終端が「\」）となっていない。
Q3. sudoコマンド実行時に管理者パスワードを入力したがはじかれた。
A3. sudoコマンドに対するパスワードはその実行ユーザのパスワードである。
Q4. sudoコマンドでパスワードが入力要求されないときがある。
A4. sudoコマンドでのパスワード入力は初回実行時と一定時間間隔（デフォルトで5分）でのみ必要となる。
Q5. suがあるのでsudoは不要ではないのか。
A5. sudoは、suを使用禁止、または、suの利用可能ユーザを限定して、セキュリティを強化するもので、sudoはユーザやユーザが管理者として利用できるコマンドなどを制限して管理者権限を分散させるものである。
【備考】なお、一般ユーザがsuを利用できないようにしたり、suの利用可能ユーザを一定のグループ内のユーザのみとするには、「ファイル＝/etc/pam.d/su」で以下の設定を行う。
①root以外はsuを使用できないようにするには：
3行目として以下を追加する。
auth required /lib/security/$ISA/pam_deny.so
②suをwheelグループ内のユーザのみ利用可能にするには：
上記追加を削除し、新6行目を有効行とする。
auth required /lib/security/$ISA/pam_wheel.so use_uid
また、グループファイル/etc/groupのwheelに利用可能ユーザを追加する。
③suをすべてのユーザに開放するには上記wheel設定をコメント化する。
第12日-2 SSH（V1）
Q1. sshd設定で①"PermitRootLogin No"を設定すると起動／再起動時に下記のエラーとなる。
sshdを起動中:/etc/ssh/sshd_config line 37: Bad yes/without-password/forced-commands-only/no argument: No
[失敗]
②"PasswordAuthentication No"を設定すると起動／再起動時に下記のエラーとなる。
sshdを起動中:/etc/ssh/sshd_config line 57: Bad yes/no argument: No
[失敗]
A1. sshd設定ファイル（/etc/ssh/sshd_config）内の設定キーワード値は全文字が小文字でないと正しく起動されない。
Q2. sshを実行するとセキュリティログ（/var/log/secure）に下記のエラーメッセージが出力される。
Feb 15 20:05:57 server sshd[2236]: lastlog_perform_login: Couldn't stat /var/log/lastlog: No such file or directory
Feb 15 20:05:57 server sshd[2236]: lastlog_openseek: /var/log/lastlog is not a file or directory!
Feb 15 20:05:57 server sshd[2234]: lastlog_perform_login: Couldn't stat /var/log/lastlog: No such file or directory
Feb 15 20:05:57 server sshd[2234]: lastlog_openseek: /var/log/lastlog is not a file or directory!
A2. 最終ログインの記録ファイル「/var/log/lastlog」が存在しないためのエラーである。この場合、「touch」コマンドでlastlogファイルを作成する。
Q3. sshd設定ファイル（/etc/ssh/sshd_config）でプロトコルをバージョン２，１の順に指定（Protocol 2,1）したが、バージョン２が優先されない。
A3. 「Protocol」の指定順序は優先順序ではない。ssh利用時の優先順序はクライアント側での設定･処理となる。
Q4. TeraTermPro+TTSSHでのTeraTermProのメニューにSSH関係の項目が表示されない。
A4. TTSSHパッケージファイルをTeraTermProのプログラムディレクトリ内に展開後、ユーザ環境変数の「TERATERM_EXTENSIONS=1」設定を行ってから起動しないとSSH関係メニューが表示されない。
第13日 SSL
◇SSL-WEB:
Q1. httpsでサーバ接続したときに、黄色い三角囲いの感嘆符マークの以下のような証明書のセキュリティ警告が表示される。
「セキュリティ証明書の名前が無効であるか、またはサイト名と一致しません。」
A1. SSLサーバ名と、ブラウザのhttpsで指定したサーバ名が一致しないためで、SSLサーバ名を指定すれば警告が解消される。また、一致した場合、緑色の丸囲いのチェックマークの以下のメッセージが表示される。
「このセキュリティ証明書には、表示しようとしているページの名前と一致する有効な名前があります。」
Q2. httpdを（再）起動したとき、ssl_error_logに以下のようなエラーメッセージが出力されている。
[Sun Jan 17 17:34:06 2010] [warn] RSA server certificate CommonName (CN) `www.example.co.jp' does NOT match server name!?
A2. SSLサーバのサイト証明書作成時に指定したサーバ名とhttpdのssl設定ssl.confで設定したサーバ名が異なっているためである。
Q3. サイト証明書発行要求の略語CSRは何の略名か。
A3. CSR：Certificate Signing Request、証明書署名依頼
Q4. SSLサイト証明書の有効期間を365日に設定できない。
A4. 設定は最終的に、サイト証明書（CRT）生成時に決定される。
openssl x509 -days 365 -in server.csr -out server.crt -req -signkey server.key
Q5. 「サイト証明書発行要求（CSR）の作成」と「自己署名サイト証明書（CRT）の作成」を同時に行った場合、httpd起動時に警告メッセージが表示される。
CSR/CRT同時作成コマンド：
openssl req -new -x509 -days 365 -key server.key -out server.crt
警告メッセージ：
[warn] RSA server certificate is a CA certificate (BasicConstraints: CA == TRUE !?)
A5.自己署名のサーバ証明書がCA証明書（他のサーバ証明書発行に利用する証明書）となる、という警告メッセージである。もし、自己署名サーバ証明書がCA証明書とならない、つまり、単にサーバ証明書とするようにするためには、openssl設定ファイル（/usr/share/ssl/openssl.cnf）で以下のような変更を行う（オリジナルとの差異）。
「basicConstraints = CA:true」⇒「basicConstraints = CA:false」
*)basicConstraints:証明書の使い方を定義する。例えば、CA:TRUE は、その証明書が root CA 証明書であること。
Q6. 作成されたサイト証明書の内容を見るためにはどうしたらよいか。
A6. サイト証明書の詳細は以下のコマンドで表示可能である。
openssl x509 -noout -text -in server.crt
Q7. httpdを起動時に以下のエラーとなる。
httpdを起動中: Syntax error on line 117 of /etc/httpd/conf.d/ssl.conf:
SSLCertificateFile: file '/etc/httpd/conf/ssl.crt/server.crt' does not exist or is empty
[失敗]
A7. ssl.confで設定されるサーバ証明書server.crtが既定のディレクトリ'/etc/httpd/conf/ssl.crt/'内に存在しない。
Q8. httpdを起動時に以下のエラーとなる。
httpdを起動中: Syntax error on line 125 of /etc/httpd/conf.d/ssl.conf:
SSLCertificateKeyFile: file '/etc/httpd/conf/ssl.key/server.key' does not exist or is empty
[失敗]
A8. ssl.confで設定されるサーバキーserver.keyが既定のディレクトリ'/etc/httpd/conf/ssl.key/'内に存在しない。
Q9. メンバーページへの登録された利用者のアクセスが、ユーザ名とパスワードの入力画面が何度も繰り返されるだけで接続が許可されない。ログ（･ヴァr/log/httpd/ssl_error_log）には以下のエラーメッセージが表示されている。
[Sat Jan 30 19:02:55 2010] [error] [client 192.168.0.11] (13)!!!!!!!!!!!!!!!!: Could not open password file: /etc/httpd/conf/passwd
[Sat Jan 30 19:02:55 2010] [error] [client 192.168.0.11] user user1 not found: /secure.shtml
A9. httpパスワードファイルpasswdの所有者属性が作成時のroot所有に設定されているためである。正しくするには、所有者をhttpdの実行者（httpd.confのUserで指定されテいるユーザ名）のapacheに変更する。
◇SSL-メール：
Q1. SSLメールサービス（xinetd）の起動時に①ログ（/var/log/messages）に以下のエラーメッセージが表示される。
bind failed (Address already in use (errno = 98)). service = pop3s
②「nmap localhost」を行うと「995/tcp open pop3s」となっていて、メール受信を行うと受信成功し、maillogにはpop3が記録されている。
A1. ①このエラーメッセージは、サービスpop3sが二重に起動されてしまったときに表示されるものである。pop3sが二重起動となっているとすると、smtpsも同様だと思われる。このエラーのよくあるケースは、スタンドアロンモードとinetdモードの２つを一緒に動作させてしまった（スタンドアロンモードを起動したままで、続いてinetdモードも起動してしまった）ような場合である。この２つは同時には実行できないので、スタンドアロンモードを実行後、続けて、inetdモードを行う場合には、「killall stunnel」でスタンドアロンモードのstunnelを停止してから、xinetdを起動する。
②ipop3dプログラムのpop3s機能が動作したか、pop3機能が動作したかの区別は、ipop3dプログラムのpop3s機能を使用した場合、ipop3d/pop3sの動作となり、スタンドアロンモードおよびinetdモードのstunnel/pop3s機能を使用した場合、ipop3d/pop3の動作となる。①のように、スタンドアロンモードの（stunnelによる）smtps/pop3sが起動したままで、inetdモードの設定を行ってもinetdモードの設定は有効にはなっていないので、クライアントからの接続はスタンドアロンモードでの接続となる。
Q2. メールサーバのログmaillogにはipop3dのクライアントとして「host=localhost.localdomain [127.0.0.1]」ではなく、クライアントのIPアドレスが記録されている。
A2. クライアントはSSLポート（pop3s=995）ではなく、通常のポート（pop3=110）から接続した。そして、サーバではpop3s設定を行っているにもかかわらず、pop3sから起動されるpop3がipop3dプログラム直接か、または、pop3sからはxinetdのpop3へのアクセスであり、アクセス設定で「127.0.0.1」のみからのアクセス許可（「only_from = 127.0.0.1」）とはなっていない（どこからでもアクセスできる）設定、の場合である。
Q3. メールクライアントからSSL受信を行ったところエラーとなり、サーバのメールログmaillogに以下のエラーメッセージが表示された。
Jan 30 20:20:54 server ipop3d[4189]: pop3s SSL service init from 192.168.0.8
Jan 30 20:20:54 server ipop3d[4189]: Unable to load certificate from /usr/share/ssl/certs/ipop3d.pem, host=[192.168.0.8]
Jan 30 20:20:54 server ipop3d[4189]: SSL error status: error:02001002:system library:fopen:No such file or directory
Jan 30 20:20:54 server ipop3d[4189]: SSL error status: error:20074002:BIO routines:FILE_CTRL:system lib
Jan 30 20:20:54 server ipop3d[4189]: SSL error status: error:140DC002:SSL routines:SSL_CTX_use_certificate_chain_file:system lib
A3. SSLメール受信アクセス（pop3sポート）はipop3dプログラムで行う設定になっているが、ipop3dの証明書（ipop3d.pem）が既定のディレクトリ「/usr/share/ssl/certs/」内に存在しないため、証明書を確認できないエラーとなった。問題は、ipop3d証明書をこのディレクトリ内で作成（make）することで解決される。なお、デフォルトのipop3d.pemは「国識別コード--, 都道府県=SomeState, 市区=SomeCity, 組織名=SomeOrganization, 部署名=SomeOrganizationalUnit, サーバ名=localhost.localdomain/管理者メールアドレス=root@localhost.localdomain」で作成されている。
第14日 SSHトンネル
Q1. FD-SSH（ssh-1.2.14-win32bin）でtelnetのポート転送を下記のパラメータで行ったところ、telnet接続ができなかった。
-L 23:192.168.0.27:23
A1. ファイアウォールまたは、スーパーサーバのtelnet設定、でlocalhostからしかtelnet接続できない設定となっているためである。
Q2. FD-SSH（ssh-1.2.14-win32bin）でtelnetのポート転送を下記のパラメータで行ったところ、telnet接続ができなかった。
-L 23:localhost:23
A2. ファイアウォールまたは、スーパーサーバのtelnet設定、でlocalhostからのtelnet接続ができない設定となっているためである。
Q3. SSHクライアントからSSHサーバへコマンドラインで接続しようとしたとき、エラーとなった。
A3. コマンドラインは1行で指定しないとエラーとなる。
Q4. SSH（V1）処理時後に評価プログラムevalを実行すると下記のエラーメッセージが表示される。
[3:FAIL] - '/home/user1/.ssh/identity'('モード間違い')
A4. ユーザの.sshディレクトリ内のプライベート鍵の属性が他人から読み込み可能になっているセキュリティ上の危険性があるためである。
-rw-r--r-- 1 user1 user1 543 10 24 2006 identity
そこで、ユーザuser1のみが処理（読み書き）可能な（属性0600）ように変更する。
Q5. SSH-FTPトンネル接続でコマンドが正しいにもかかわらずFTPサーバへの接続ができない。
A5. パッシブモードでのデータコネクションポートが正しくない（クライアント指定間違い、または、サーバでの設定間違い）。
Q6. SSH-FTPトンネル接続をlogoutで終了しようとしたら、以下のメッセージが表示されてSSH接続を終了できない。
Waiting for forwarded connections to terminate...
The following connections are open:
#0 port 21, connection from localhost.localdomain port 1077 (t4 r6 i0/0 o0/0 fd 10/10)
A6. ポート転送指定したFTP接続がまだクローズされていないため。ポート転送をクローズすればSSH接続も終了する。
Q7. SSH-FTPトンネル接続しようとして、まちがって、実IPアドレスでFTP接続したら接続してしまった。
A7. xinetdのvsftpd設定で「only_from = 127.0.0.1」が指定されていないため。
Q8. サーバのxinetd/vsftpdの「only_from = 127.0.0.1」をはずした通常のFTP接続は可能だが、SSH-FTPトンネル接続で「only_from = 127.0.0.1」を設定するとSSHトンネルによるFTPパッシブ接続ができない。
A8. ファイアウォール（iptables）でloインタフェースのアクセスが許可されていない。
Q9. SSH-FTPトンネル接続でファイルダウンロード中に以下のエラーメッセージが表示されてダウンロードできなかった。
/home/user1/testfile.tar.gz がダウンロードできませんでした。
500 OOPS: vsf_sysutil_bind
A9. vsftpd設定（vsftpd.conf）のデータコネクション用のパッシブポート範囲（pasv_min_port ～ pasv_max_portまで）の数が少ないため、ファイル一覧取得を含む多数のデータ送受信処理を行うとポートが足りなくなる。なお、データコネクションポートは１送受信終了後TCPクローズ確認時間待ちとして数分のクローズ処理時間を必要とする。
Q10. SSH-FTPトンネル接続でファイル一覧取得中に以下のエラーメッセージが表示されて一覧表示できなかった。
ファイル一覧 がダウンロードできませんでした。
500 OOPS: vsf_sysutil_bind
A10. 「A13.」と同様。
Q11. SSHトンネル経由のVNC接続ができない。
A11. VNCサーバの設定（/etc/sysconfig/vncservers のディスプレイ番号/ユーザ名）が正しく設定されていないか、または、クライアントvncviewerの接続指定（IPアドレス＝127.0.0.1/ポート番号）が正しく対応していない。VNCサーバ設定の「ディスプレイ番号」＋5900がクライアントでのポート番号となる。
Q12. http経由のvnc接続ができない。
A12. ファイアウォールのポート5801が許可されていないか、または、httpのURL指定（vncサーバ名/ポート番号＝5801）が正しく対応していない。
Q13. VNCサーバの起動シェルスクリプトの変更時、日本語ロケール設定でエラーとなる。
A13. ロケール（日本語）設定の行は「＝」の前後に空白を入れてはならない。前後どちらか一方でも空白を入れると有効にならないので注意が必要。
Q14. SSHトンネルコマンド実行時に以下のメッセージが表示され、SSH接続できない。
@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@
@ WARNING: HOST IDENTIFICATION CHANGED! @
@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@
It IS POSSIBLE THAT SOMEONE IS DOING SOMETHING NASTY!
Someone could be eavesdropping on you right now(man-in-the-middle attack)!
It is also possible that the host key has just been changed.
Add correct host key in ./.ssh/known_hosts to get rid of this massege.
Password authentication is disabled to avoid trojan horses.
Permission denied.
A14. ①「...to avoid trojan horses.」までのWARNINGメッセージは、SSHトンネルコマンドが存在するディレクトリ内のサブディレクトリ.ssh内の「known_hosts」（接続したホストのホスト鍵を格納するファイル）内に、今接続しようとしているサーバ名の鍵が既に存在するが、その内容と、今接続しようとしているサーバのホスト鍵（/etc/ssh/ssh_host_key.pub）とが異なる、ことを意味している。
原因としては、以前接続した（成功した）後、サーバOSの再インストール（ホスト鍵も再生成）など、ホスト鍵の生成が新たに行われたような場合に起こる。
復旧は、Windowsの.ssh内の「known_hosts」の既存（古い）ホスト鍵を削除する（その行、１行を削除する。メモ帳で「書式->右端で折り返す」をはずして、行単位表示にしてから１行削除。または、ホストから公開鍵（/etc/ssh/ssh_host_key.pub）をFDなどで持ってきて追加してもよい。そのとき、その行先頭にサーバ名を付加する（名前の後に空白１個をおく）。
②「Permission denied.」は、ユーザ名（「-l」指定）、identityファイルの指定、または、サーバ上のそのユーザの.sshディレクトリ内のauthorized_keysファイル内のそのユーザの公開鍵およびその所有者、のいずれかが正しくないとき起こる。
具体的には、identityファイル内に記述されたサーバのユーザ名が、サーバ上で「ssh-keygen -t rsa」で生成したユーザ名と異なったり内容が異なる、あるいは、このユーザ名が「-l」指定のユーザ名と異なる、あるいは、authorized_keysファイル内のユーザ名（鍵の行の最後に記述されているユーザ名）が「-l」指定のユーザ名または「-i」指定のidentityファイル内のユーザ名と異なる、authorized_keysの所有者が「-l」指定のユーザ名または「-i」指定のidentityファイル内のユーザ名と異なる、などの場合。
復旧は、「-l」指定のユーザ名、「-i」指定のidentityファイル、authorized_keyの所有者、など正しく対応するものに修正する。identityファイルが間違っているならば、サーバ上のidentityファイルを再度コピーしてくる。それでもだめならば、サーバ上で再度ssh-keygenで再生成して持ってくる（identity.pubをauthorized_keysに追加することを忘れない）。
第15日 ファイアウォール（iptables）
Q1. ファイアウォールを設定・起動したら、今まで導入したサーバで接続できないものがある。
A1. 設定が今までのクライアント/アプリケーションに対応していない。特に、SSHやSSLのトンネル経由の場合、loインタフェースを通す設定が必要。なお、これまでに行ったサーバのテストは全部一応行っておく必要がある。
Q2. ファイアウォールを設定後、システムを再起動したらログインのウィンドウ画面（X-Window）が開かなくなってしまった。
A2. X-Window画面はXサーバをloインタフェース経由で利用するので、loインタフェース経由のアクセスを許可しなければならない。
Q3. ファイアウォールを再起動したら、何の接続もできなくなってしまった。
A3. デフォルト設定が正しく拒否設定されていて、追加したフィルタルールに間違いがある、ため。
Q4. ファイアウォールのフィルタブロックのログが大量となり、見づらい。
A4. ブロックログは一般的なものではなく、特定のものに、あるいは、トラブル時やテスト時など特定の時期に絞って設定する。それ以外は、ログしないようにするとよい。
Q5. iptablesルールファイルを変更後、iptablesを再起動したら下記のエラーとなった。
iptables: Bad argument `COMMIT'
Try `iptables-restore -h' or 'iptables-restore --help' for more information.[失敗]
A5. ルールテーブルの最後のCOMMIT（テーブル発効）の文字の後ろに空白があると、エラーとなる。
第16日 SSH-V2
Q1. PuTTYの鍵生成の処理が止まってしまう。
A1. PuTTYの鍵生成はランダム演算のためにマウスを動かし続ける。
Q2. PuTTYを起動のたびに情報設定しなければならない。
A2. 情報設定後の保存（「Save」）がなされていない。
Q3. WinSCPで日本語表示されない。
A3. ①日本語モジュール（WinSCP.jp）がWinSCPプログラムフォルダ内に存在しないため。パッケージ（jp.zip）を展開して格納すればよい。
②WinSCPの「Language]設定がなされていない。
③Windows 9X系システムでは日本語の文字化けが起こる場合がある。
④何回かインストールを繰り返した場合で、アンインストールしてからインストールせずに（WinSCPが既存のシステム上で）、別フォルダにインストールしたような場合、日本語設定メニューが表示されず、日本語設定ができない場合がある。このような場合、WinSCP再インストール時に以下の設定を行うことで、日本語設定メニューの表示ができる。
「Select Additional Tasks」画面の「■Add installation directory to search path[%PATH%]」
なお、システムの環境変数PATHにWinSCPインストール先フォルダを設定してもよい。
Q4. WinSCPでSSHサーバに接続できない。
A4. 秘密鍵の設定が正しくないか、または、パスフレーズ入力に間違いがある。
Q5. WinSCPコンソールでコマンドがきかない。
A5. 追加キー入力が必要なコマンドを入力してしまった。
Q6. PuTTYgenで生成した公開鍵をFDでSSHサーバに持ってゆき、authorized_keysに追加したが、その鍵を使ったPuTTY接続ができない。
A6. OpenSSHのペースト用の公開鍵文字列以外はOpenSSHサーバ上での鍵変換が必要（「SSH Tectia Client」などでも同様）。
ssh-keygen -i -f 公開鍵 >> authorized_keys
第17日 VMware
Q1. VMwareによるLinuxサーバインストール手順は、実際のシステムでの手順と同じか。
A1. VMwareのインストールとLinuxディストリビューションのインストール領域の確保後の、Linuxサーバインストールは同じ手順。
ただし、PC自体の物理メモリが２５６ＭＢくらいまでは「仮想マシン」の「メモリ」設定で調整しないと動作しない場合がある。
Q2. Windows側からVMware/Linuxサーバに接続できない。
A2. Windowsファイアウォールで拒否されている。
Q3. VMwareでLinux用ディスク領域が２GBより大きく取れない。
A3. VMware用のWindowsディスク領域はFAT形式で確保すると2GBまでで、それより大きい場合はNTFSで確保する必要がある。
Q4. VMwareメモリ領域が不足してVMwareワークステーション/プレイヤが実行できない。
A4. VMware実行のための領域が不足しているので、４MB単位で実メモリ近くまで増加させながら実行できるようにする。
Q5. VMware上のLinuxサーバにtelnet で接続する場合の相手のサーバ名またはIPアドレスがわからない。
A5. 相手サーバ名またはIPアドレスは、VMwareでインストールしても、個別PCでインストールしても、同じ（VMware上のLinuxインストール時に設定したもの）。
第18日 IPsec(FreeS/WAN)
Q1. IPsecトンネルの「left」と「right」はどう決めるか。
A1. どちらか一方を「left」、反対側を「right」とするのみで、何の制限もない。
Q2. 以下のような設定（ipsec.conf）で「setup start」を実行したら、以下のエラーとなった。
[設定]
31 # IPsec tunnel
32 conn c2g-to-dgx
33
34 left=192.168.0.17
35 right=192.168.0.27
[エラーメッセージ]
ipsec_setup: (/etc/ipsec.conf, line 34) parameter is not within a section -- `start' aborted
A2. セクション内の各行は必ずTABが先頭でなければならず、途中に空白行は入れてはいけない。
Q3. 手動鍵設定で「down」を行ったところ、以下のエラーとなった。
ipsec manual: fatal error in "xgx-to-dgx": no IPsec-enabled interfaces found
/usr/local/lib/ipsec/_confread: line 580: 6553 Done if test
"$include"; then
ipsec _include --inband $config;
・・・以下省略
A3. 以下のように終了手順を間違えた可能性がある。
677 /usr/local/sbin/ipsec setup stop
678 /usr/local/sbin/ipsec manual --down xgx-to-dgx
Q4. 自動鍵交換方式で「auto --up」を行ったところ、以下のエラーとなった。
whack: Pluto is not running (no "/var/run/pluto.ctl")
A4. 以下のようにIPsec設定ファイル（ipsec.conf）でpluto（鍵交換モジュール）が有効になっていない可能性がある。
pluto=no
Q5. RSA公開鍵認証で「setup start」を実行したところ、以下のエラーとなった。
ipsec_setup: (/etc/ipsec.conf, line 37) section header "04mrtAX4ub6luDg3bFwC0o2v60f40FezH0YRHAqiNnJnn/Bjiz8iJixWAczKJE2sjgGc77PfhU2DqSak" has wrong number of fields (1) -- `start' aborted
A5. 以下のようにIPsec設定ファイル（ipsec.conf）の鍵の値設定が複数行にわたっている可能性がある。よくあるケースでは、コピー＆ペーストの際に間違えるケースが多い。
36 leftrsasigkey=0sAQOTa/Rd7wAqdOG7K3GYfMngvi/UOuIMqMhjbYxUSjOhvNQeH2RLX1Z4
37 04mrtAX4ub6luDg3bFwC0o2v60f40FezH0YRHAqiNnJnn/Bjiz8iJixWAczKJE2sjgGc77PfhU2DqSak
38 WfJ/5S6xoFuMLM41YD0CtdzIEjudVwsRoswXfyexH7KTQ0O4L7QEeEMQyeoLnlCaZPMvBfwBh2rGr7uM
39 AooHHRoUFBCAk4L4z5sLnzAvHVHL0G42wmIJS1mjuAplbQMUkd+h4v2UNmjO12PthhQIgugVjb9tyG8Z
40 m1c+NeA3ROqLeZZvd/ENAdtsvsKsUvUYCaMVKNfhxcojRIaB
Q6. RSA公開鍵認証をDNS方式で行うために、RSA公開鍵をDNS正引きゾーンファイル内に格納し、DNSを再起動したところ下記のエラーになった。
Feb 4 17:40:53 dgx named[6806]: dns_master_load: db.example:8: unknown RR type 'RSA'
A6. 以下のように、正引きゾーンファイルにRSA公開鍵を格納する際、コメント行（先頭が#の行）をそのまま格納してしまった。
8 # RSA 2048 bits dgx.network-mentor.com Sat Mar 31 16:39:34 2007
9 dgx.network-mentor.com. IN KEY 0x4200 4 1 AQOOvCzQ6RG4spp/cuSCRkU8dtZTo...
ゾーンファイル内のコメント行は先頭が「；（セミコロン）」である。
Q7. RSA公開鍵認証をDNS方式で行うために、RSA公開鍵をDNS逆引きゾーンファイル内に格納し、DNSを再起動したところ下記のエラーになった。
Feb 4 18:14:28 xgx named[10759]: dns_master_load: db.192.168.0:9: ignoring out-of-zone data (xgx.network-mentor.com)
A7. 以下のように、逆引きゾーンファイルにRSA公開鍵を格納する際、KEYレコードの先頭のホスト名をそのままにして格納してしまった。
9 xgx.network-mentor.com. IN KEY 0x4200 4 1 AQOTa/Rd7wAqd...
逆引きゾーンファイル内に格納する場合は、ホスト名ではなくPTR/IPアドレスでなくてはならない。
Q8. IPsec接続を行うシステム間でIPsec通信ができないときがある。
A8. IPsecシステム間で、互いにsetupを行った後のどちらか一方の「auto --up」から「auto --down」の間でのみIPsec通信が可能であり、それ以外ではIPsec通信できない。
Q9. IPsec接続を行うシステム間で通信自体ができないときがある。
A9. IPsecシステム間で、互いにsetupを行った後にどちらか一方の「auto --up」から「auto --down」の間でIPsec通信を行った後、片側で「setup stop」を行ってから「」を行うか、または、相手も同様に「」を行うまでの間はIPsec通信も非IPsec通信（平文IPsec通信）どちらも不可能となる。
Q10. システム起動時のIPsec自動起動を設定して、システム起動直後のIPsec通信ができない。
A10. システム起動時にはIPsecはDNSの起動より前に起動されるための下記のエラーとなる。
Apr 2 19:16:57 dgx ipsec__plutorun: 028 failure to fetch key for 192.168.0.37 from DNS: failure querying DNS for TXT of 37.0.168.192.in-addr.arpa.: Host name lookup failure
Apr 2 19:16:57 dgx ipsec__plutorun: 028 failure to fetch key for 192.168.0.37 from DNS: failure querying DNS for KEY of 37.0.168.192.in-addr.arpa.: Host name lookup failure
Apr 2 19:16:57 dgx ipsec__plutorun: ...could not add conn "xgx-to-dgx"
第19日-1 snort
Q1. スニファモードでtelnetの３パケットを監視して処理するテストがすぐ終わってしまう。
A1. Windowsのネットワークコンピュータ処理のNetBIOSパケットが１５分/４５分間隔でネットワーク上に送出されるので、snortはタイミングによってこのパケットを捕捉して終了してしまうことがある。
Q2. ユーザsnortを指定してsnortの設定確認テストを行ったり、snortを起動スクリプトで実行したりしたとき、alertファイル「/var/log/snort/alert」への書き込みが「Permission denied」でエラー終了してしまう。
A2. この実行より前にテストなどでユーザ指定しないsnortをコマンドで実行した場合、alertファイルがrootのみのrw属性で作成され、以降のユーザsnortによる書き込みができなくなってしまう。このalertファイルを削除しておけばよい。
Q3. rootへのsnortのエラー通知（/var/log/*/snortが存在しない、という）が日次的に送られている。
/etc/cron.daily/logrotate:
error: error accessing /var/log/snort/*: No such file or directory
error: snort:4 glob failed for /var/log/snort/*/*log
A3. snortのログローテーション設定「/etc/logrotate.d/snort」で上記エラーとなるディレクトリ／ファイルのログローテーション設定を行っているため、ログ・ローテーション時に毎回rootにエラー・メールが通知される。上記ディレクトリ／ファイルは、NIC（ネットワーク･カード）が複数の場合に、それぞれのNICに対応する/var/log/snort/下のサブディレクトリ内にalertやログを書き込むためのものである。NICが１つのみであるならば、これらディレクトリを削除すればよい。
Q4. SnortSnarfでsnortのログを分析したとき、最初の情報のみで更新されない。
A4. snortのログをsnortsnarf.plで変換をかける必要があるので、その更新にはsnortログのたびにこのコマンドを実行する必要がある。
Q5. システム再起動後、snortのalertテストを行ったところ、反応が非常に遅くなったり、ハングアップのような状態となる。
A5. snortの自動起動設定を行った後、自動起動スクリプトで実行中のsnortと重複してこのような状態に陥る。
第19日-2 tripwire
Q1. データベース初期化（「tripwire --init」）で長いエラーリストが表示される。
A1. tripwireは多数のOSに対応するためパッケージではそれらOSでのチェック情報を広く含んでいる。そのため、Linuxでは不要な情報もあり、初期化時にこれらが存在しないというエラーが多数報告される。したがって、適切（必要）なものだけを残すようにテキストポリシーファイル「twpol.txt」をviで修正し、twpolの更新とデータベースの初期化を繰り返す必要がある。
第20日-1 ストリーミングサーバ（DSS:Darwin Streaming Server）
Q1. DSSパッケージ（ DarwinStreamingSrvr5.5-Linux.tar.gz）をrpmインストールしたところ、依存する「libstdc++.so.6」が見つからないというエラーで異常終了した。
A1. RHL9では「libstdc++.so.5」が使用されているため、DSSパッケージは「DarwinStreamingSrvr5.0.1.1-Linux.tar.gz」がそれに対応している。DSSパッケージの以降のバージョンを使用する場合、対応するモジュールが必要になのので注意が必要。
Q2. DSSのカスタマイズのためのWWWブラウザによる接続ができない。
A2. DSSのTCPポート1220に接続するので、サーバ側ではファイアウォールでクライアントからサーバポート1220/TCPへの接続を通す設定になっていなければならない。
Q3. DSSに接続できない、または、ストリーミングができない。
A3. クライアントおよびサーバのファイアウォールで下記のポートを通す設定になっていなければならない。
サーバ：RTSP（554）/TCP、RTP/RTCP（6970-6999）/UDP
クライアント：RTP/RTCP（6970-6999）/UDP
Q4. DSSのクライアントで必要なモジュールは何か。
A4. QuickTime Playerプログラムが必要。また、WWWブラウザで使用するにはQuickTimeプラグインが必要。
Q5. WWWブラウザからのホームページでのストリーミング再生ができない。
A5. そのWWWブラウザでQuickTimeプラグインが設定されていないか、または、DSS/WWWサーバ側でそのムービーのリンクイメージファイルが作成されていないか正しい設定でない。リンクイメージとホームページでの設定例は下記のようになる。
ファイル：linkimage.mov（拡張子）
rtsptext rtsp://www.example.com/sample.mp4
ホームページの関連部分：
<EMBED SRC="http://www.example.com/linkimage.mov"
href="rtsp://www.example.com/sample.mp4"
target="QuickTimePlayer">
Q6. クライアントからのDSSへのアクセス制御がうまくできない。
A6. アクセスファイル「qtaccess」が利用するムービーのディレクトリ「 /usr/local/movies」内にあり、規定の形式で記述されていて、それぞれの設定に対応するファイルが存在する、ときのみアクセス制御が正しく行われる。
qtaccess例：
AuthUserFile /etc/streaming/qtusers
AuthGroupFile /etc/streaming/qtgroups
require valid-user
/etc/streaming/qtusers例：
realm Streaming Server
DSSadmin:ONx5MwnPbsEOo:5d48af388f3e275fed29e9770787107d
qtuser1:9SSE/TyK64eAs:f5c0b38c327ed82f8592e2bb923d507d
/etc/streaming/qtgroups例：
admin:DSSadmin
Q7. クライアントからDSSに接続してムービーを再生するときにムービー毎に認証されない。
A7. アクセスファイル（qtaccess）のあるディレクトリ単位に認証されるので1度認証されると同じディレクトリ内の他のムービーはそれ以降、ブラウザを再起動しない限り、認証処理はない。
第20日-2 データベース（MySQL）
Q1. MySQL利用環境設定のために最初にMySQLサーバをバックグラウンドで開始したが、下記のようにすぐに終了してしまった。
[root@dgx root]# safe_mysqld -u root &
[1] 2351
[root@dgx root]# Starting mysqld daemon with databases from /var/lib/mysql
071209 17:38:36 mysqld ended
[1]+ Done safe_mysqld -u root
また、ログ（mysqld）には下記のログが記録されていた。
071209 17:38:36 /usr/libexec/mysqld: Table 'mysql.host' doesn't exist
071209 17:38:36 mysqld ended
071209 17:39:31 /usr/libexec/mysqld: Shutdown Complete
A1. 「MySQLリファレンスマニュアル」にあるように、サーバ起動の前に、権限テーブルをインストールしておく必要ががある。最初に、「/usr/bin/mysql_install_db」スクリプト・コマンドにより、権限管理の mysql データベースとテスト用の test データベース、root ユーザの権限エントリなどを作成する。
[root@dgx root]# /usr/bin/mysql_install_db
Preparing db table
Preparing host table
Preparing user table
Preparing func table
Preparing tables_priv table
Preparing columns_priv table
Installing all prepared tables
[root@dgx root]# ls -al /var/lib/mysql
合計 16
drwxr-xr-x 4 mysql mysql 4096 12月 9 17:39 .
drwxr-xr-x 22 root root 4096 10月 18 23:06 ..
drwx------ 2 root root 4096 12月 9 17:39 mysql
srwxrwxrwx 1 root root 0 12月 9 17:38 mysql.sock
drwx------ 2 root root 4096 12月 9 17:39 test
Q2. ユーザmysqlでMySQLサーバをバックグラウンドで開始したが、下記のようにすぐに終了してしまった。
[root@xgx root]# safe_mysqld -u mysql &
[1] 2205
[root@xgx root]# Starting mysqld daemon with databases from /var/lib/mysql
071209 19:34:01 mysqld ended
[1]+ Done safe_mysqld -u mysql
また、ログ（mysqld）には下記のログが記録されていた。
071209 19:34:01 /usr/libexec/mysqld: Can't find file: './mysql/host.frm' (errno: 13)
071209 19:34:01 mysqld ended
A2. 初期化や初期設定をrootでコマンドにより行ったため、MySQLライブラリ情報ディレクトリ（/var/lib/mysql/mysql）以下のディレクトリ／ファイルが所有者および所有者グループがrootで作成されている。そのため、ユーザmysqlがアクセスできない。下記のように、所有者および所有者グループをmysqlに変更すればよい。
chown mysql.mysql /var/lib/mysql/mysql （mysqlディレクトリ所有者/グループ設定）
第20日-3 XOOPS
Q1. WWWブラウザからのXOOPSインストール･ウィザードが途中でハングアップしたり、異常終了してしまう。
A1. XOOPSインストールに必要なPHP4、MySQL、php-mysqlがインストールされていない。
Q2. XOOPSインストール・ウィザードの設定書き込みでエラーとなる。
A2. XOOPSの書き込みディレクトの属性が書き込みできるようになっていない。
エラーとならないようには、以下のように属性を設定する。
chmod 0777 uploads/ cache/ templates_c/
また、mainfile.phpはインストール時に誰からも書き換え可能なようにパーミッションを0666に設定する。
なお、XOOPSインストールを行うディレクトリinstallはインストール後、XOOPS運用を開始したならば不要である。したがって無用なセキュリティリスクを放置しないためにこのinstallは削除する。また、mainfile.phpもインストール後は0644に変更する。
以上は、XOOPSインストール後に管理メニューに入った時に下記のような赤い注意メッセージで注意喚起されるのでそれにしたがう。
注意：ファイル/var/www/html/xoops/install/がサーバ上に存在します。インストール完了後は必ず削除してください。
注意：ファイル/var/www/html/xoops/mainfile.phpへの書き込みが可能となっています。このファイルのパーミッション設定を変更してください。
Q3. XOOPSインストール・ウィザードの途中で赤文字のメッセージのエラーとなる。
A3. 入力情報がデータベース作成時と異なる。
第21日 DNSの拡張
◇TSIG：
Q1. nslookupでTSIG鍵を設定したDNSサーバに名前解決を行ったが問い合わせが拒否されてしまった。
A1. nslookupではTSIG鍵が必要な名前解決はできない。
Q2. digでTSIG鍵を指定して名前解決を行ったが、クライアントには以下のタイム・エラーの応答が返った。
;; Couldn't verify signature: clocks are unsynchronized
また、サーバではmessagesログに以下のエラーが記録された。
Sep 19 11:48:16 dgx named[1676]: client 192.168.0.37#1027: request has invalid signature: tsig verify failure
A2. クライアントとサーバの日時の同期が取れていないと同期（sinchronization）エラーで処理が受け付けられない。あらかじめ、日時を同じにしておくか、インターネット接続可能な場合、2台のシステムがインターネット上のntp（Network Time Protocol。時間）サーバに接続して時刻同期調整しておく必要がある。
【詳細解説】TSIG時刻同期チェック処理
RFC2845（*1）で規定されているTSIG時刻同期チェックの規定で、BINDでもこれを使用している。
TSIG-RRには署名時間（タイムスタンプ「Time Signed」）とファッジ（許容時間間隔「Fudge」）が設定され、受け取り側の処理時の時間がこの許容時間外（「Time Signed」+/-「Fudge」範囲外）の場合には送受信者間の時刻同期がとれていないとしてエラーになる。
サーバ側でこの時刻同期はずれが検出された場合には、TSIGエラーコード18（BADTIME）のエラー応答をクライアントに返し（ログ＝*2）、クライアント側でサーバからの応答RRに時刻同期はずれを検出した場合には、タイム・エラーとする。
この時刻同期は中間者によるリプレイ攻撃などへの対策である。
なお、ファッジは大き過ぎるとリプレイ攻撃されやすくなり、小さすぎるとNTP時刻同期失敗やネットワーク遅延などによる処理不可が発生しやすくなるので、RFC2845では「300秒（5分）」を推奨しており、BINDでもこの時間が設定されている。
（*1）RFC2845: Secret Key Transaction Authentication for DNS (TSIG)
Q3. digでTSIG鍵を指定して名前解決を行ったが、クライアントには以下のエラーの応答が返った。
;; Couldn't verify signature: tsig indicates error
A3. digで設定した鍵（オプション「-k」で指定した鍵）が、クライアントとサーバで対応しないか、または指定のエラー。
Q4. プライマリ－セカンダリ間のTSIG鍵によるDNSゾーン転送ができない。
A4. プライマリDNSサーバとセカンダリDNSサーバ間での鍵とゾーン転送の２つの設定が一致しなければゾーン転送できない。
プライマリDNSサーバではnamed設定（named.conf）のserverステートメントでセカンダリDNSサーバのIPアドレスとkeyステートメントで共有秘密鍵（アルゴリズムと共有秘密鍵値）を設定し、セカンダリDNSサーバへのゾーン転送（allow-transfer）を許可設定する。一方、セカンダリDNSサーバでは、スレーブ設定を行い、serverステートメントでプライマリDNSサーバのIPアドレスとkeyステートメントで共有秘密鍵（アルゴリズムと共有秘密鍵値）を設定する。
◇ドメイン内DNSゾーン情報更新：
Q1. 外部接続のないローカルドメイン内でのサブドメインのプライマリDNSサーバからメインドメインのセカンダリDNSサーバへのDNSゾーン転送ができない。
A1. プライマリDNSサーバのゾーン情報更新によるセカンダリDNSサーバへのゾーン転送は、セカンダリDNSサーバの名前解決から始まる。この名前解決はインターネットのDNSツリーにしたがってルートDNSサーバに対してから始まる。DNSツリーを降りてきながら名前解決ができると、そのIPアドレス宛にゾーン更新の通知（「DNS NOTIFY」）が行われる。そして、セカンダリDNSサーバからプライマリDNSサーバにゾーン転送要求が送られてきて、ゾーン転送が行われる。外部接続のないローカルドメイン内での場合、最初のセカナダリDNSサーバの名前解決ができず、「DNS NOTIFY」が行われない。
このような場合、「DNS NOTIFY」先（セカンダリDNSサーバ）のIPアドレスを明示する（①）か、または、DNS転送先を強制的に固定する（②）、とゾーン転送が可能になる。
①DNS上位問い合わせ自体の最初をセカンダリDNSに強制転送する：
optionsセクションに以下の記述を加える。
forwarders { 192.168.3.2; };
②notifyでDNS検索を行わないように、notify先を明示する：
zoneセクションに以下の記述を加える。
notify explicit;
also-notify { 192.168.3.2; };
◇サブドメイン・メールサーバのDNS設定：
Q1. インターネットからサブドメイン内のメールサーバにはメールが届くがメインのメールサーバにメールが届かない。
A1. インターネット向けのグローバルDNSサーバの正引きゾーンファイルのMXレコードにワイルドカードMXしか設定されていない。ドメインのMXレコードが設定されていない。
（誤）; Wild Card MX
* IN MX 10 mail.example.com.
（正）; MX for domain itself
@ IN MX 10 mail.example.com.
; Wild Card MX for subdomains
* IN MX 10 mail.example.com.
◇rndc：
Q1. rndc設定後namedを再起動すると下記のエラーとなる。
Dec 6 17:29:36 dgx named[3412]: /etc/named.conf:13: couldn't find key 'rndc-key' for use with command channel 127.0.0.1#953
A1. rndc鍵ファイル内のrndc鍵名とnamed設定ファイルnamed.confで指定したrndc鍵名が一致していない。
Q2. rndcによるnamedの再起動ができない。
A2. rndcでは停止はサポートされているが、起動はサポートされていない。
◇内部クライアント：
Q1. 社内クライアントからインターネット上のWWWサーバへアクセスしたときに拒否されることがある。
A1. クライナト用のグローバルIPアドレスに対するホスト名がそのドメインのDNSサーバに設定されていないとき、そうしたドメインのクライアントからアクセスを受けたWWWサーバでセキュリティ・チェック（アドレス偽称のクライアントからのアクセスを禁止する）を行っている場合がある。
◇MX別名：
Q1. ときどき外部からのメールが届かず、相手に以下のようなエラーメールが送られてしまうことがある。
553 5.3.5 mailf1.example.co.jp. config error: mail loops back to me (MX problem?)
554 5.3.5 ... Local configuration error
A1. 正引きゾーンファイルのバックアップ用メールサーバのMXレコードの右辺にCNAME名（別名）が指定してある場合、プライマリメールサーバがダウンしてバックアップ用のメールサーバが一時的にそのときのメールを受け取ってから再度メールサーバに中継しようとする。このとき、まだ、プライマリメールサーバがダウンしていると、再度、バックアップ用メールサーバ（自分自身）にメールを送ろうとする。もし、このMXレコードの右辺のメールサーバ名をバックアップ用メールサーバ自身が自分の名前だと認識できれば、自分自身には送る必要がないのでプライマリメールサーバの起動をまた、待つことになるが、認識できないので（別名はDNS内でのみ有効）、送出動作を行ってエラーとなってしまう。
CNAME名はMXレコードの右辺に記述してはいけない。これは、RFC(974,1034,1123,1912,2181,2821）で禁止されている。
第22日 sendmail機能拡張
Q1. 送信者認証（SMTP-AUTH）で送信専用ユーザアカウントを作成してメール送信を行ったが拒否された。
A1. ①Sendmail.confでsasldbが設定されていない。
または、②送信者認証設定後、sendmailを再起動していない。
または、③メールクライアントのアカウント設定で認証設定（ユーザ名/パスワード）が正しくない。
Q2. メールサーバで送信者認証（SMTP-AUTH）の設定をしたにもかかわらず、メールクライアントで送信者認証設定をしていなくてもメール送信できてしまう。
A2. ローカル内宛には送信者認証（SMTP-AUTH）を使わなくてもメール送信できる。外部宛では送信者認証（SMTP-AUTH）が必須となる。
Q3. 送信者認証（SMTP-AUTH）でSASLをバージョン１からバージョン２に移行したら、送信者認証できなくなってしまった。
A3. ①sasldbで認証を行う場合、/etc/sasldb2が使用されていない。pwcheck_methodがauxpropとなっていない。
または、②バージョン１でpwcheck_methodがpasswd/shadow/pamなどを使用していた場合、バージョン２でpwcheck_methodにsaslauthdを指定してsaslauthdを起動させなければならないが、そうなっていない。
Q4. 送信者認証（SMTP-AUTH）動作確認処理を行うとき、CFパッケージから作成したsendmail.cfをバックアップしておき、送信者認証（SMTP-AUTH）処理後、元へ戻してsendmailを再起動するとCFパッケージで作成したsendmail.cfではなく、送信者認証（SMTP-AUTH）用のsendmail.cfで動作してしまう。
A4. 送信者認証（SMTP-AUTH）用のsendmail.mcより古い作成日時のsendmail.cfがあると、sendmail起動スクリプトで/etc/mail/Makefileによりそのsendmail.mcからsendmail.cfがmakeされ、sendmail.cfがsendmail.mcより新しい日時となる。/etc/rc.d/init.d/sendmail中の「make all -C /etc/mail -s」参照。
Q5. sendmail.mcからsendmail.cfを作成したとき、送ってくる相手メールサーバのドメイン名解決ができなくても着信を受け付けてしまう。
A5. RHL9用のsendmail.mcのベースファイルでは、相手のドメイン名解決ができない相手からの着信を許可する設定となっている。
FEATURE(`accept_unresolvable_domains')dnl
これをコメント化すれば、名前解決できない相手からは着信を拒否することになる。
Q6. ORBS設定時、ドメイン内からのメール送信に時間がかかったり、送信できない。
A6. accessファイルでローカル発信を無条件許可する設定となっていない。
Q7. 自動返信がうまくできない。
A7. 「vacation -I」が未実行、または、「.forward」ファイルの設定間違い（特に、CFパッケージ/RHL9では先頭の「\」を指定すると宛先エラー"User Unknown"となる）。
Q8. 自動返信が1回しか行われない。
A8. 1度自動返信した相手には、1週間たつまではあらためて自動返信を行うことはない。
第23日 WWW拡張
第23日-1 ◇アクセス制御：
Q1. httpd設定のallow/deny設定で許可したホストからのアクセスが拒否される。
A1. 拒否および許可の両方の対象となった場合、order指示子の順序の最後の指示が適用される。以下の指定ではhost-aがdeny（deny from all）とallow（allow host-a）の両方の指示子の対象となるが、order指示子の順序の最後の指示子denyが有効となる。
order allow,deny
deny from all
allow host-a
【備考】order,allow,denyの適用のルールは以下のようになる。
①orderで指定された最後の指示子のすべてが暗黙的に初期値デフォルトになる。
②allowとdenyの両方が指定されている場合でアクセス者が両方の対象となった場合、orderで指定された指示子allow/denyの順序の最後の指示子の指定の方が有効になる。
第23日-2 ◇カウンタ：
Q1. カウント・プログラム wwwcount2.6 をインストール・設定してカウンタを表示させたら、以下のエラーとなった。
Host: "dgx" is not authorized
A1. カウント・プログラム設定ファイル（count.cfg）の[authorized]セクション（サーバの名前とIPアドレスを設定）にクライアントのURLで指定した名前 "dgx" が存在しないため。ここにサーバの名前とIPアドレスのすべてを指定しなければならない。
Q2. カウント・プログラム wwwcount2.6 をインストール・設定してカウンタを表示させたら、以下のエラーとなった。
Could not write to counter file: /usr/local/etc/Counter/data/count.dat
A2. カウンタ・ファイル（count.dat）にhttpdのユーザ（apache）がアクセスできないため。そこで、以下のように所有者・モードを設定する。
-rw------- apache apache /usr/local/etc/Counter/data/count.dat
その他、以下の設定も必要。
-rwx------ apache apache /var/www/cgi-bin/Count.cgi
また、以下のディレクトリとそれ以下のサブディレクトリの所有者・グループを変更する。
drwxr-xr-x apache apache /usr/local/etc/Counter
第23日-3 ◇バーチャルホスト：
Q1. 名前ベースのバーチャルホストにクライアントから2つ目のサーバ名でアクセスしたがメインのホームページが表示されてしまった。
A1. httpd設定ファイル（httpd.conf）内の名前ベースバーチャルホスト設定（NameVirtualHost *）が有効でない（コメントのまま）。
Q2. 名前ベースのバーチャルホストにクライアントからIPアドレスでアクセスしたらメインのホームページが表示されてしまった。
A2. IPアドレスではメインのサーバへアクセスする。
Q3. httpd設定ファイル（httpd.conf）内のバーチャルホスト（VirtualHost）タグを設定してhttpdを再起動したところ以下のエラーとなった。
httpdを起動中: [Thu Feb 11 18:40:44 2010] [error] VirtualHost _default_:443 -- mixing * ports and non-* ports with a NameVirtualHost address is not supported, proceeding with undefined results [ OK ]
なお、ブラウザからどのバーチャルサーバへアクセスしても、"Bad request!" と "Error 400" がブラウザ上に表示され、アクセスできない。サーバのログとしては、下記のようにhttpdログにアクセス記録があり、SSLエラーログにエラー記録がある。
[root@dgx conf]# tail /var/log/httpd/access_log（1つ目のバーチャルホストのログ）
clhost.example.com - - [11/Feb/2010:20:20:04 +0900] "GET / HTTP/1.01." 400 1004 "-" "Mozilla/4.0 (compatible; MSIE 7.0; Windows NT 6.0; GTB6.4; Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.1; SV1) ; SLCC1; .NET CLR 2.0.50727; .NET CLR 3.5.30729; .NET CLR 3.0.30729)"
[root@dgx conf]# tail /var/log/httpd/access2_log（2つ目のバーチャルホストのログ）
clhost.example.com - - [11/Feb/2010:20:20:08 +0900] "GET / HTTP/1.01." 400 993 "-" "Mozilla/4.0 (compatible; MSIE 7.0; Windows NT 6.0; GTB6.4; Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.1; SV1) ; SLCC1; .NET CLR 2.0.50727; .NET CLR 3.5.30729; .NET CLR 3.0.30729)"
[root@dgx conf]# tail /var/log/httpd/ssl_error_log（SSLエラーログ）
[Thu Feb 11 20:20:04 2010] [error] SSL handshake failed: HTTP spoken on HTTPS port; trying to send HTML error page
[Thu Feb 11 20:20:04 2010] [error] SSL Library Error: 336027804 error:1407609C:SSL routines:func(118):reason(156)
[Thu Feb 11 20:20:08 2010] [error] SSL handshake failed: HTTP spoken on HTTPS port; trying to send HTML error page
[Thu Feb 11 20:20:08 2010] [error] SSL Library Error: 336027804 error:1407609C:SSL routines:func(118):reason(156)
A3. httpd設定ファイル（httpd.conf）内のconf.dのIncludeダイレクティブ（Include conf.d/*.conf）が有効になっているため、バーチャルホストとSSLの両方でアクセス処理がされているが、conf.d/ssl.confによるSSL処理が先に行われてエラーを返す一方でバーチャルホストへのアクセスもなされている。。
なお、SSL（https）でSSLページにはアクセスできないが、SSL（https）で通常ページを指定してアクセスするとそれぞれのバーチャルホストの通常ページが表示される。つまり、バーチャルホストタグ（VirtualHost）を使用するSSLとバーチャルホストでは、SSL認証が先に実行され、次にバーチャルホストが実行される、httpdの処理手順にしたがう。したがって、バーチャルホストのバーチャルホストタグ（VirtualHost）とSSLのバーチャルホストタグ（VirtualHost）で対象を明示しない限り、両方がかち合ってしまい、SSL→バーチャルホストの順に処理される。
●Includeダイレクティブを無効（#Include conf.d/*.conf）にした場合、上記エラーメッセージが表示されなくなり、名前ベースのバーチャルホストが有効になる。ただし、SSLが利用できない。
●名前ベースのバーチャルホストを有効にし、SSLも利用するには、httpd設定ファイル（httpd.conf）内のconf.dのIncludeダイレクティブ（Include conf.d/*.conf）を有効にすると同時に、バーチャルホストタグ（VirtualHost）とSSL設定ファイル（ssl.conf）のバーチャルホストタグを以下のように変更する。
httpd.confの全バーチャルホスト関連部分
オリジナル：
変更後 ： ←このセクションはポート80（http）が対象、の意味
SSL設定ファイル（ssl.conf）のバーチャルホストタグ：
オリジナル：
変更後 ： ←このセクションはポート443（https）が対象、の意味
ただし、上記SSL設定ではどのバーチャルホストへのSSLアクセスでもssl.confで指定したサーバのSSLページが表示される（以降【備考】参照）。
【備考－「通常ページとSSLページを両方有効にするバーチャルホストの設定」】
複数のバーチャルホストで通常ページとSSLをともに有効にしたいならば、バーチャルホストタグ（VirtualHost）のパラメータで対象サーバとポートを明示する必要がある（SSLのバーチャルホストタグの部分のみでも可能＝(*1））。そうすれば、バーチャルホストとSSLを共用できる。IPベースのバーチャルホストではバーチャルホストタグ（VirtualHost）のパラメータで対象サーバを明示しているため、SSLと共用できるが、SSLのバーチャルホストタグ（VirtualHost）のパラメータを"_default_:80"（や"*:443"）のままとしておくとSSLアクセスは１つのサーバにしかアクセスできない。"_default_:443"ではなく、"IPアドレス:443" 別にSSLのバーチャルホストセクション（"" ～ ""）を指定すれば、「通常ページとSSLページが両方有効なバーチャルホスト」が可能になる。
（*1）正確には、httpd.confの "Listen 80" と指定した後のバーチャルホストの "" のように、IPアドレスのみでも、ssl.confのバーチャルホストタグ（VirtualHost）で "" と指定すれば、SSL(https）アクセスが"IPアドレス:443" 別に処理され、httpアクセス（"IPアドレス:80"）はhttpd.conf内の "" で処理されるので問題はない。しかし、 "" のように明示しておいたほうが確実である。
【参考１－apacheマニュアルの"Listen"の説明】
Listen する複数のアドレスとポートを指定するために、 複数の Listen ディレクティブを使用することができます。 その場合、サーバは指定されたすべてのアドレスとポートで、 リクエストに対する応答を行ないます。
サーバが 80 番ポートと 8000 番ポートの両方で接続を受け付ける設定の例:
Listen 80
Listen 8000
二つのインターフェースとポート番号において接続を受け付ける設定の例:
Listen 192.170.2.1:80
Listen 192.170.2.5:8000
Q4. IPベースのバーチャルホストを起動したところ下記のエラーとなった。
httpdを起動中: [Fri Feb 12 11:40:18 2010] [warn] NameVirtualHost *:0 has no VirtualHosts [ OK ]
A4. httpd.confのIPベース設定をしたにもかかわらず、名前ベースの設定 "NameVirtualHost *" が指定されているため。ただし、アクセスは正しく処理される。
Q5. IPベースのバーチャルホストでメインサーバに関するバーチャルホストセクション（"" ～ ""）を指定しなかったが、メインサーバにアクセスできた。
A5. IPベースのバーチャルホストの場合、メインサーバの設定が既にあり、バーチャルホスト部分を追加する場合には、メインサーバ部分はその既存のものが使用されるため、追加設定する必要がない（追加設定しても処理上は問題ない）。
【参考２－バーチャルホストの設定確認】
バーチャルホストの設定は以下のコマンドで確認可能。
[root@dgx ~]# /usr/sbin/apachectl -t -D DUMP_VHOSTS
VirtualHost configuration:
192.168.0.27:443 www.example.com (/etc/httpd/conf.d/ssl.conf:91)
192.168.0.27:80 www.example.com (/etc/httpd/conf/httpd.conf:1066)
192.168.0.227:443 www.example2.com (/etc/httpd/conf.d/ssl.conf:267)
192.168.0.227:80 www.example2.com (/etc/httpd/conf/httpd.conf:1073)
Syntax OK
これからもＳＳＬ処理が先であることがわかる。
第23日-4 ◇ユーザホームページ：
Q1. ユーザホームページがブラウザから表示できない。
A1. ①httpd設定httpd.confでユーザホームページ表示が以下のように無効のままであり、ブラウザには "Object not found!" と "Error 404" が表示される。
オリジナル 有効化
---------- ------
372 UserDir disable →コメント化
379 #UserDir public_html →非コメント化
387 #→非コメント化
～ →非コメント化
398 # →非コメント化
なお、372行目と379行目のオリジナルからの変更は、372行目または379行目のどちらか一方の変更のみでよい。
②URL指定が正しくない（ブラウザには "Object not found!" と "Error 404" が表示される）。正しくは、"http://www.example.com/~user1/"
③ユーザのディレクトリ属性が正しくない。正しくは、ユーザディレクトリおよびpublic_htmlディレクトリの属性が "drwx--x--x" で（エラー時、ブラウザには "Forbidden" と "permission" エラーが表示される）、public_html内のファイルの属性が "-rw-r--r--" である（エラー時、ブラウザには "Access forbidden!" と "Error 403" エラーが表示される）。
第24日 SSHトンネルゲートウェイ
Q1. 下記コマンドをユーザで実行したSSHトンネルゲートウェイに、リモートクライアントからアクセスしたところ接続エラー（E1）となる。
[user1@dgx .ssh]$ ssh -1 -l user1 -i identity -L 2323:localhost:23 192.168.0.18
（リモートクライアントでの接続エラーE1）
C:\Users\user1>telnet dgx 2323
接続中: dgx...ホストへ接続できませんでした。 ポート番号 2323: 接続に失敗しました
A1. sshクライアントシステムのSSHクライアント設定（ssh_config）で "GatewayPorts yes" が設定されていない。
Q2. SSHトンネルゲートウェイ用の下記コマンドをSSHクライアントでユーザから実行したところ実行エラー（E2）となった。
[user1@dgx .ssh]$ ssh -1 -l user1 -i identity -L 23:localhost:23 192.168.0.18
（実行エラーE2)
Privileged ports can only be forwarded by root.
A2. 転送するポート23は特権ポート（PrivilegedPort＝0～1023）なので管理者rootでしか実行できない。
Q3. SSHトンネルゲートウェイ用の下記コマンドをSSHクライアントで管理者rootから実行したところ警告メッセージ（W1）が表示された（ssh実行自体は成功）。
[root@dgx .ssh]# ssh -1 -l user1 -i identity -L 23:localhost:23 192.168.0.18
Enter passphrase for RSA key 'identity':
bind: Address already in use
channel_setup_fwd_listener: cannot listen to port: 23
Could not request local forwarding.
Last login: Fri Feb 12 20:33:45 2010 from 192.168.0.27
[user1@h2g ~]$
A3. SSHクライアントシステムの/etc/servicesでこのシステムのtelnetサーバがポート23を使用する設定のままとなっていて、ポート23をSSH転送で使用するための変更がされていない（ポート23をSSH転送で使用するならば、telnetサーバが使用するポートを本来のその23ではなく別のポートに変更する必要がある）。
第25日 現実のファイアウォール
Q1. ファイアウォールの再起動時にルール設定エラーがあったとき、すべての着信が通ってしまった。
A1. 着信（INPUT）チェインのデフォルト設定が許可（ACCEPT）であると、再起動時のすべてのチェインのフラッシュ（Flush）により、デフォルトのみ有効のままであるのでそのエラールールまでの設定と全着信ACCEPTとなってしまう。
Q2. サーバにpingを行ったが応答がない。
A2. pingのプロトコルICMPについてサーバでは、以下のメッセージタイプ（icmp-type）の着信のみ許可し、他は拒否するのが基本。
0：エコー応答、3：宛先不到達、4：発信元送信抑制、11：時間超過
Q3. サーバからの外部インターネットへの発信ができない。
A3. サーバが参照するDNSサーバが自分自身の場合、ループバック・インタフェースが許可されていなければ名前解決ができないので外部接続ができない。
Q4. セカンダリDNSサーバのゾーン更新がなされない。
A4. セカンダリDNSサーバからのポート53（DNS）/TCP宛着信が許可されていないとセカンダリDNSサーバからのゾーン転送要求が着信できない。
Q5. ルータのログがサーバに保存されない。
A5. ルータからのポート514（syslog）/UDP宛着信が許可されていないとルータからのサーバ宛ログ送信ができない。なお、ルータでのsyslogホスト設定（*1）、または、サーバでのsyslog受付設定（*2）、がなくてもログが保存されない。
（*1）syslog host syslogサーバのIPアドレス
（*2）Linuxでは /etc/sysconfig/syslog での "-r"（リモートシステムからのログ有効化）オプション
Q6. ファイアウォールのログで拒否ログか許可ログかすぐには判別できない。
A6. ログを取るルールで拒否と許可でログプレフィックスが設定（"--log-prefix プレフィクス文字列"）されていないか、または、同じプレフィックスであるため。
© CopyRight by Network Mentor, Ltd.
Last Update: 2010 January