Linuxサーバ運用マニュアル
定常運用において，サービスのチェックは重要です。普段は正常に稼動しているサービスは，何らかの障害で，突然停止するかもしれません。定期的にチェックを行なっていれば，障害の早期発見につながり，復旧までの時間も短縮できます。また，定期的なチェックにおいて，どの程度まで突っ込んでチェックするかというのもポイントです。詳しくチェックし過ぎると管理者の負担も大きいですし，逆に適当なチェックを行なうと障害を見落とす可能性があります。システム管理の専従者ならともかく，SOHOなどの環境では他の業務に影響が出ない程度に詳しくチェックすることが大切です。
具体的にチェックするものは，アプリケーションの動作，アプリケーションのログ，プロセスの状態，ログインサービスなどです。アプリケーションの動作チェックは，定常のチェックでは特にデバッグモードなどを使用するのではなく，たとえばWWWサーバのチェックならWWWブラウザでホームページを表示する，メールサーバのチェックなら日常のメールのやりとりがそのままチェックになるなど，クライアントとしてサービスを利用する形程度にします。
アプリケーションのログは，アプリケーション毎に決まったログに出力されるものと，syslogに出力されるものがあります。syslogに出力されるものは，grepを用いて必要な部分を抽出するのが有効です。
Linux> grep sendmail /var/log/syslog | tail May 19 14:01:33 gauntlet sendmail[5836]: OAA05836: SYSERR(root): mailer prog died with signal 213 May 19 14:03:52 gauntlet sendmail[5853]: OAA05853: SYSERR(root): mailer prog died with signal 213 May 19 14:37:06 gauntlet sendmail[6322]: OAA06322: SYSERR(root): mailer prog died with signal 213 May 19 15:38:36 gauntlet sendmail[6948]: PAA06948: SYSERR(root): mailer prog died with signal 213 |
Linux> tail /usr/local/var/apache/log/access.log 10.0.1.254 - - [21/Nov/1998:15:03:09 +0900] "GET /~joe/crack/navy_m1.txt HTTP/1.0" 200 2749 10.0.1.254 - - [21/Nov/1998:15:05:18 +0900] "GET /~joe/hack/hack.htm HTTP/1.0" 200 4201 10.0.1.254 - - [21/Nov/1998:15:06:06 +0900] "GET /~joe/hack/hack/index.htm HTTP/1.0" 200 18544 10.0.1.254 - - [21/Nov/1998:15:12:16 +0900] "GET /joe/travel/travel.htm HTTP/1.0" 404 280 |
プロセスの状態のチェックは，psとgrepを利用します。このとき重要なのは，正常に運用できている状態でどんなプロセスが動いているかを調べておくことです。比較対象がなくては，チェックになりません。
以下に，プロセス状態のチェックの例を紹介します。
Linux> ps aux | grep sendmail root 3283 0.0 1.0 932 316 p0 S 18:56 0:00 grep sendmail |
以下に，サービス毎のチェック対象をまとめておきます。
使用しているアプリケーションはASHの場合の例なので，設定やバージョンにあわせてログの出力先などをチェックして下さい。また，inetd起動型のプロセスの場合はセッションが繋がっていない間はプロセスは起動していないので，psを入力してもプロセス名は表示されないので注意してください。
| サーバ | アプリケーション | プロセス名 | ログの出力先（例） |
|---|---|---|---|
| メールサーバ | sendmail | sendmail | /var/log/syslog /var/log/messagesなど |
| WWWサーバ | Apache | httpd | /usr/local/var/apache/log/access.log |
| プロキシサーバ | DeleGate | delegated | /usr/local/etc/delegate/log/8080.httpなど |
| FTPサーバ | wu-ftp | ftpd | /var/log/syslog /var/log/messagesなど |
| ファイルサーバ | Samba | smbd nmbd | /usr/local/samba/var/log.smb /usr/local/samba/var/log.nmb |
| ダイヤルアップサーバ | mgetty | mgetty | /var/log/mgetty.ttyS0 COMポート番号によりttySnのn（数字）は決まる |
ログをチェックする際に，ただ漠然とログを眺めていっても効率はあまりよくありません。効率よくログをチェックするためには，アプリケーションから出力されるエラーメッセージをキーワードにしてgrepでログを抽出します。エラーメッセージはアプリケーション毎に違う形で出力されるので，キーワードはアプリケーション毎に変えていく必要があります。
以下に，ログ抽出方法の例を紹介します。grepに-iオプションをつけて実行すると，大文字小文字を区別せず検索するので，ヒット率が上がるので，活用しましょう。
Linux> grep -i sendmail /var/log/syslog | grep -i err | less Dec 6 23:15:30 gauntlet sendmail[87]: NOQUEUE: SYSERR(root): getrequests: accept: No route to host Dec 20 01:23:57 gauntlet sendmail[87]: NOQUEUE: SYSERR(root): getrequests: accept: Connection reset by peer Jan 10 21:59:03 gauntlet sendmail[87]: NOQUEUE: SYSERR(root): getrequests: accept: No route to host May 17 16:06:04 gauntlet sendmail[7694]: QAA07694: SYSERR(root): mailer prog died with signal 213 |
エラーメッセージが頻繁に出力されていた場合，サービスの不具合や不正アクセスの疑いがありますので、原因の調査をしましょう。全部チェックするのは大変ですが、エラーの数をチェックするだけでも、ある程度の効果はあります。
以下に，ログチェックの際のキーワードをまとめておきます。
| キーワード | 内容 |
|---|---|
| warning err abort | エラー全般 定義ファイルのミスなど |
| timeout timed out | ネットワークの通信異常 サーバの高負荷状態など |
| refused reject not permitted denied | アクセス制御の設定ミス 何らかの不正アクセスなど |
| fail incorrect invalid | パラメータの設定ミス 不正なパスワード入力など |
| /phf /php /test-cgi | CGIの不正利用 |
| null connection eof received | ポートスキャン |
| authentication failed repeated login failures login incorrect | 辞書アタック |
| passwd | パスワードファイルへの不正アクセス |
ポートスキャン，辞書アタックなどは，サーバへの不正アクセスの一種です。これらについては，今後詳しい説明をしていきます。
/var/log/wtmpには，ユーザーのログイン履歴が特殊な形式で記録されています。このログイン履歴は，lastコマンドで参照することができます。lastコマンドは，標準出力にログを流しつづけるので，lessなどにパイプしてやるのがよいでしょう。また，lastlogは先頭が最新で，後ろのほうに行くにしたがって古いログとなっています。ログイン履歴を調査して，不審なユーザーがログインしていないかチェックしましょう。
Linux> last | less joe ftp pc22.lo.ash.or.j Mon May 31 02:59 - 03:00 (00:01) joe ttyp0 pc23.lo.ash.or.j Wed May 26 00:59 - 01:05 (00:06) yanagi ttyS0 115200 Tue May 25 06:02 - 06:09 (00:07) hasimoto ttyp0 pc22.lo.ash.or.j Tue May 21 22:48 - 23:19 (00:31) |
また，ユーザー毎のログイン履歴を抽出して定期的にユーザーに送付し，ログイン履歴の確認をとりましょう。パスワードが盗難され，本人以外の誰かがログインしている可能性があります。lastコマンドの引数にユーザー名を渡してやると，ユーザー毎のログイン履歴を抽出できます。
Linux> last yanagi | less yanagi ttyS0 115200 Tue May 25 06:02 - 06:09 (00:07) yanagi ttyS0 115200 Sun May 16 21:02 - 21:16 (00:13) yanagi ttyS0 115200 Sun May 16 00:28 - 00:33 (00:05) yanagi ttyS0 115200 Fri May 14 05:56 - 06:02 (00:06) |
また，wtmpファイルは基本的にハードディスクの容量がいっぱいになるまで，内容が追加されつづけるので，定期的にバックアップをとりログを切り替えましょう。
Linux> mv /var/log/wtmp /var/log/wtmp.backup Linux> cp /dev/null /var/log/wtmp |
lastコマンドは，wtmpファイルのバックアップを直接参照することはできないので，以下のように切り替えて参照します。
Linux> mv /var/log/wtmp /var/log/wtmp.real Linux> mv /var/log/wtmp.backup /var/log/wtmp Linux> last | less バックアップの参照が終わったら，wtmpファイルのオリジナルを 忘れずに元に戻しておく。 Linux> mv /var/log/wtmp /var/log/wtmp.backup Linux> mv /var/log/wtmp.real /var/log/wtmp |
mgettyのログには，ユーザー名の情報は記載されていませんが，ダイヤルアップを受けた時間，モデムの状態などが記録されています。lastlogと比較して，ダイヤルアップ時間とログイン時間に違いがないか確認します。もし，「ダイヤルアップされていないのにダイヤルアップユーザーがログインしていた」りすれば，不正アクセスやwtmpファイルの改ざんの可能性があります。
Linux> grep -i connect /var/log/mgetty.ttyS0 | less 05/25 04:38:58 yS0 waiting for ``CONNECT'' ** found ** 05/25 06:01:44 yS0 waiting for ``CONNECT'' ** found ** 05/25 06:32:50 yS0 waiting for ``CONNECT'' ** found ** 05/26 03:05:02 yS0 waiting for ``CONNECT'' ** found ** |
モデムの状態をチェックします。mgettyのログからエラーメッセージを抽出し，モデムに異常がないかチェックします。モデムに異常があった場合には，モデムのケーブルが抜けていないか確認する，モデムをハードウェア的にリセットするなどの対処を行ないましょう。
Linux> grep -i warning /var/log/mgetty.ttyS0 | less 03/13 08:59:25 yS0 WARNING: DSR is off - modem turned off or bad cable? 03/13 09:00:11 yS0 WARNING: DSR is off - modem turned off or bad cable? 03/13 09:05:58 yS0 WARNING: DSR is off - modem turned off or bad cable? 03/13 09:06:43 yS0 WARNING: DSR is off - modem turned off or bad cable? |
これまでに、さまざまなチェック方法などを説明してきました。ただし、人力でやるには手間がかかりすぎ、ミスも発生します。そこでそれを自動化する方法を考えましょう。
と，いうわけで次回は「cronで自動化しよう！」です。
（ＡＳＨマルチメディア研究会／ｊｏｅ，高柳）