システム管理の基礎 syslogdの設定をマスターしよう：Linux管理者への道（3）（2/3 ページ）
syslogdによって記録されるログは、システムの運用・管理のための重要な手掛かりとなる。しかし、各環境固有の事情に合っていなければ、ログを取得する意味はない。syslogdやlogrotateの設定方法をマスターし、必要な情報を選別できるようにしよう。（編集局）
システムのログをつかさどるsyslogd
ログには、アプリケーションが独自に出力するものと、syslogdを利用して出力するものの2種類があります。
独自のログを出力する代表的なアプリケーションにはApacheやSquid、Sambaなどがあります。独自のログ設定を持つアプリケーションに関してはアプリケーションのマニュアルなどを読んでいただくとして、ほとんどのアプリケーションはsyslogdを利用してログを出力しています。以後は、syslogdを利用したログについて説明します（注）。
Linuxでは、主なログの出力先は/var/logディレクトリです。ディレクトリ内を確認すると分かりますが、前述したようにここには複数のファイルが存在します。この設定を行うファイルが/etc/syslog.confです。
syslog.confのフォーマット
syslog.confの書式は、スペースあるいはタブで分けられた2つのフィールド「selector」と「action」で構成されています（フィールドを分けるための空白はOSによって異なります。マニュアルで確認してください）。
selector action
取得するログの指定 取得したログの出力先
セレクタ（selector）
selectorは「facility」と「priority」（label）を「.」（ピリオド）で接続します。特定のactionに対して複数のselectorを指定したい場合は、「;」（セミコロン）で接続します。
facility.priority{;facility.priority}
取得する情報の分類.どのレベルから出力
ファシリティ（facility）
facilityはログの分類に当たるものです。syslogdを利用するプログラムは、「このログはこのfacilityに所属している」という情報をsyslogdに渡しています。syslogdの設定を行うことで、facilityに応じて扱い方を変更できます。
| facility | 対象のログ |
|---|---|
| auth（security） | 認証サービスのメッセージ（現在はauthprivが推奨されている） |
| authpriv | 認証サービス（カテゴリはauthと同じ。authとは出力結果が異なる） |
| cron | cronのメッセージ |
| daemon | デーモンのメッセージ |
| kern | カーネルのメッセージ |
| lpr | プリンタサービスのメッセージ |
| メールサービスのメッセージ | |
| news | ニュースサービスのメッセージ |
| syslog | syslogのメッセージ |
| user | ユーザープロセスのメッセージ |
| uucp | uucp転送を行うプログラムのメッセージ |
| local0〜7 | アプリケーションに依存する |
| facilityで指定できるキーワード | |
複数のfacilityを指定したい場合は「,」（カンマ）で接続して、
mail,ftp.warn
のように書くこともできます。local0からlocal7は、特定のプログラムが所属するfacilityを既存のものと分けたいときに利用します。以下はRed Hat Linux7.3の/etc/xinetd.confの内容ですが、facilityがauthprivで設定されています。スーパーサーバ経由で動作するサービスはfacilityがauthprivということです。
defaults
{
instances = 60
log_type = SYSLOG authpriv
log_og_success = HOST PID
loc_on_failure = HOST
cps = 25 30
}
includedir /etc/xinetd.d
例えば、特定のサービスをlocal0のfacilityにするには/etc/xinetd.d下の設定ファイルに以下の記述を追加します。telnetの例を挙げます。
service telnet
{
disable = no
flags = REUSE
socket_type = stream
wait = no
user = root
server = /usr/sbin/in.telnetd
log_on_failure += USERID
log_type = SYSLOG local0 ←追加
}
設定ファイルの編集後、xinetdを再起動させればtelnetのログがlocal0のfacilityで出力されます。
sshの場合、デフォルトでsshd_configに、
SyslogFacility AUTHPRIV
の記述があります。この「AUTHPRIV」の記述をほかのfacilityに変更すればよいのです。
プライオリティ（priority）
priorityは、プログラムが出力するメッセージのうち、ログのレベルの重要度を設定します。
| priority | 内容 |
|---|---|
| debug | デバッグ情報 |
| info | 情報 |
| notice | 通知 |
| warn | 警告 |
| err | 一般的なエラー |
| crit | 致命的なエラー |
| alert | 緊急に対処すべきエラー |
| emerg | システムが落ちるような状態 |
| 下になるほど重要度が高い | |
通常の設定を行うと、指定したpriority以上のログが出力されます。例えば、「err」を指定すればcrit、alert、emergのレベルの出力もされます。すなわち、重要度の低いpriorityを選択すればするほど、出力されるメッセージは多くなります。逆に、指定したpriorityよりも重要度の低いメッセージのみを出力させたい場合は、
mail.*;mail.!warn
のように記述します。この設定では、メールに関するメッセージのdebugとinfoとnoticeが出力されます（ここでの「*」はすべてのメッセージの意味）。
特定のpriorityのみを指定することも可能です。それには「=」を使用します。
kernel.=warn
のように記述すると、カーネルの警告メッセージだけが出力されます。これに「!」を合わせることで、特定のpriorityを除いたメッセージを出力することも可能です。
これらのpriorityの指定以外に、「none」を利用するとそのfacirityの出力を行いません。
| selector例 | 内容 |
|---|---|
| kernel.=warn | facilityがkernelでpriorityがwarnのみ出力 |
| mail.*;mail.!=crit | facilityがmailでpriorityがcrit以外のメッセージを出力 |
| .;daemon.none | facilityがdaemon以外の全メッセージを出力 |
どのfacilityをどのpriorityにするかは、何を監視したいかによります。重要なデータを見逃さないように、必要なデータが取得できるpriorityに変更しましょう。
アクション（action）
actionには、selectorで指定したメッセージをどこに、あるいはどのように出力するかを設定します。具体的には、
- どのファイルに出力するか（ファイルのパスを記述する）
- ほかのプログラムに渡す（「|」を利用）
- 他ホストに渡す（「@ホスト名」）
- ユーザーのコンソールに表示（システムに登録されているユーザー名）
になります。また、出力先のファイルとして/dev/consoleを指定することで、コンソールに表示させることも可能です。actionの設定例は以下のとおりです。
| 設定例 | 内容 |
|---|---|
| /var/log/samplelog | /var/log/samplelogへログを出力 |
| | /usr/local/bin/*** | ログをパイプでほかのプログラムへ渡す |
| /dev/console | ローカルのコンソールへ出力 |
| @remotehost | リモートホストのsyslogdへ送信（注） |
| root,user1 | rootとuser1に通知 |
| * | オンラインユーザーすべてに通知 |
| 注：詳細は後述 | |
以上の内容を踏まえて、デフォルトのsyslog.conf（注）を見てみましょう。
*.info;mail.none;authpriv.none;cron.none /var/log/messages 1.
authpriv.* /var/log/secure 2.
mail.* /var/log/maillog 3.
cron.* /var/log/cron 4.
*.emerg * 5.
uucp,news.crit /var/log/spooler 6.
local7.* /var/log/boot.log 7.
1.authprivとcronを除いたすべてのfacilityでinfo以上のメッセージを/var/log/messagesに出力
2.authprivのfacilityはすべてのメッセージを/var/log/secureに出力
3.mailのfacilityはすべてのメッセージを/var/log/maillogに出力
4.cronのfacilityはすべてのメッセージを/var/log/cronに出力
5.すべてのfacilityでemergのメッセージをオンラインユーザーのコンソールへ出力
6.uucpとnewsのfacilityでcrit以上のメッセージを/var/log/spoolerへ出力
7.local7のfacilityのすべてのメッセージを/var/log/boot.logへ出力
ログサーバによるログの一元管理
以前、ログを数カ月から数年間保存することを法制化しようという動きがありました。これは不正アクセスの情報を残すためでしたが、まだ実際の法律としては存在していません。
しかし、ログを残すことがネットワーク管理者の重要な作業の1つであることは間違いありません。不正アクセスを行う者にとって、ログには自分を特定する手掛かりとなる情報が記録されます。当然、ログを削除しようとするでしょう。これに対処するために、異なるホストをログサーバとして運用する方法があります。
前述したように、syslog.confの設定でactionに@ホスト名（あるいはIPアドレス）を入力すると、そのホストにログを転送することができます。ただし、ログを受け取るホスト側でも設定が必要です。ログサーバとしてホストを設定するには、syslogdに-rオプションを指定して起動します。syslogdを停止してから、
# /sbin/syslogd -r
で再実行します。Red Hat系であれば/etc/sysconfig/syslogに、
SYSLOGD_OPTIONS="-m 0 -r"
のように追記してsyslogdを再起動すれば、ログサーバとして使用できます。
ログサーバへ転送されたログは、ログサーバのsyslog.confの内容に従って処理されます。ここで注意すべき点は、ログサーバのユーザーとパスワードをほかのサーバと同じにしないことと、複数のサーバからログの転送を行うのであれば容量的に十分余裕を持たせておくことです。
以上で、syslogdの主な機能については網羅できているはずです。複数のサーバから必要な情報を洗い出す作業を少しでも減らそうとするなら、ログサーバを1台用意して、例えばpriorityがwarn以上のものを1つのファイルに出力するように設定することも可能です。
Copyright © ITmedia, Inc. All Rights Reserved.