2014年2月11日火曜日

DD-WRT でシスログを USB メモリに書き込み

はじめに

DD-WRT でログを USB メモリーに書き込むようにします。

一応、Web GUI の Services -> Services で Syslogd を有効にすることはできますが、この場合はログの書き込み先が /var/log/messages 又は IP アドレスを指定したリモートサーバーとなり、それ以外を指定することはできません。

/var/log/messages に書き込まれたログは DD-WRT を再起動すると消えてしまい、あまり都合良くありません。

なので、今回は WebGUI での Syslogd の設定は Disable とし、別の方法で Syslogd を起動してログを USB メモリーに書き込むようにします。

また、将来 Optware をインストールすることを意識してファイルシステムの選択やマウントポイントを決めました。

無線 LAN ルーター本体は WZR-300HP で、「 Buffalo WZR-300HP に DD-WRT インストール 」で DD-WRT をインストールしてます。

USB メモリーのフォーマット

OTRW2 (Optware the right way Take 2) 」によると USB メモリのファイルシステムは ext2 が良いようです。ext3 でジャーナルを使うと、フラッシュメモリーの寿命を縮めるかもしれないらしいです。

パーティション作成

DD-WRT では fdisk を使えないようなので、Ubuntu をインストールした PC に USB メモリを挿してパーティションを作成します。

作成後のパーティションはこんな感じになりました。

$ sudo fdisk -l /dev/sdb

Disk /dev/sdb: 4089 MB, 4089446400 bytes
61 heads, 60 sectors/track, 2182 cylinders
Units = cylinders of 3660 * 512 = 1873920 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
Disk identifier: 0xabcabcab

   Device Boot      Start         End      Blocks   Id  System
/dev/sdb1               1        2182     3993030   83  Linux

今回の PC 環境では USB メモリは /dev/sdb でした。環境によっては別のデバイスになる場合もあり、間違えると別のディスクの大事なデーターを誤って削除してしまう場合もあるので、 デバイス名の指定には注意する必要があります。

ext2 でフォーマット
$ sudo mkfs.ext2 /dev/sdb1

これも誤って別の大事なデーターを消してしまわないようにデバイス名の指定は注意する必要があります。

USB メモリをマウント

フォーマットした USB メモリを無線 LAN ルーターに挿します。

Web GUI の Services -> USB タブ
  • Core USB Support を Enable
  • USB Storage Support を Enable
  • Automatic Drive Support を Enable
  • Disk Mount Point は /opt を選択 (後々の Optware のためにこれにします)
  • Save ボタンを押す
  • Apply Settings ボタンを押す
  • USB メモリがマウントされ、Disk Info にマウントされた情報が表示されました

ちゃんと /opt にマウントされてます

# mount | grep opt
/dev/sda1 on /opt type ext2 (rw,relatime,errors=continue)

Syslogd を起動

USB メモリにシスログ保存用のディレクトリを作成

# mkdir -p /opt/some/where

Web GUI の Services -> Services タブで Syslogd が Disable になっていることを確認。「はじめに」で説明したとおり、ここの Syslogd では USB メモリにログを書き込めないので Disable にしときます。

Web GUI の Administration -> Commands タブ
Commands ダイアログボックスに以下を入力
/bin/busybox syslogd -L -s 8192 -b 10 -O /opt/some/where/messages
/bin/busybox klogd

なぜ /bin/busybox を付けてるか興味がある人は後の「おまけ」を参照して下さい。

Save Startup ボタンを押す

システムを再起動

# reboot

Syslogd と Klogd が起動しています

# ps www | grep log
 1581 root      1044 S    /bin/busybox syslogd -L -s 8192 -b 10 -O /opt/some/where/messages
 1583 root      1040 S    /bin/busybox klogd
 1811 root      1044 S    grep log

ログファイルもできました

# ls -la /opt/some/where/messages
-rw-r--r--    1 root     root         41242 Feb 11 12:15 /opt/some/where/messages

Firewall ログを出力するようにする

今の状態で、無線 LAN に関するログが MAC アドレス等と共に出力されます。これだけでなく、Firewall のログも出力されるようにします。

Web GUI の Security -> Firewall タブの Log Management
  • Log を Enable
  • Log Level は High を選択 (これはお好みで。Medium や Low を選択すると出力されるログが少なくなるようです)
  • Dropped, Rejected は Enable を選択、Accepted は Disable を選択 (これもお好みで)
  • Save ボタンを押す
  • Apply Settings ボタンを押す

おまけ

Syslogd と Klogd の起動は上に書いたように /bin/busybox を付けてますが、/bin/busybox を付けずに

/sbin/syslogd -L -s 8192 -b 10 -O /opt/some/where/messages
/sbin/klogd

こんな感じでも一応 Syslogd と Klogd が起動します。

しかし、Web GUI で Syslog とは無関係な設定箇所を保存したり適用したりするタイミングなどで Syslogd と Klogd のプロセスが落ちてしまいます。

この場合のプロセスは

2013 root      1044 S    /sbin/syslogd -L -s 8192 -b 10 -O /opt/some/where/messages
2017 root      1040 S    /sbin/klogd

となっており、どうやらもともと Web GUI で Syslog の Enable/Disable を管理しているので、いろいろなタイミングで

killall syslogd
killall klogd

が実行されているっぽいです。(これに気づくのにかなり時間がかかりました。)

この killall を回避しないといけないのですが、DD-WRT はたまたま

# ls -la /sbin/syslogd /sbin/klogd
lrwxrwxrwx    1 root     root            14 Mar 25  2013 /sbin/klogd -> ../bin/busybox
lrwxrwxrwx    1 root     root            14 Mar 25  2013 /sbin/syslogd -> ../bin/busybox

というように Syslogd と Klogd の本体は busybox なので、busybox コマンドの引数に syslogd と klogd を指定する方法を使い

/bin/busybox syslogd -L -s 8192 -b 10 -O /opt/some/where/messages
/bin/busybox klogd

これで起動したところ、各プロセスは以下のようになりました。

1581 root      1044 S    /bin/busybox syslogd -L -s 8192 -b 10 -O /opt/some/where/messages
1583 root      1040 S    /bin/busybox klogd

これで killall を回避できてるっぽく、今のところうまく動いてます。


0 件のコメント:

コメントを投稿