Blue Eyes Blue

論理ボリュームの拡張

＜環境＞RHEL 4

150GBのHDD3台でRAID5の構成になっているはずなのに、デフォルトの論理ボリューム容量がとても小さかった。サイズをを見ると、16GBとなっている。

$ df -h Filesystem 　　　　　　　サイズ 使用 残り 使用% マウント位置 /dev/mapper/VolGroup00-LogVol00 16G 12G 3.5G 78% / /dev/sda1 　　　　　　　　　　 251M 17M 221M 8% /boot

残りはどうなっているのか、fdiskで確認。

# fdisk コマンド (m でヘルプ): p Disk /dev/sda: 318.9 GB, 318901321728 bytes 255 heads, 63 sectors/track, 38770 cylinders Units = シリンダ数 of 16065 * 512 = 8225280 bytes デバイス Boot Start End Blocks Id System /dev/sda1 * 1 33 265041 83 Linux /dev/sda2 34 2391 18940635 8e Linux LVM

シリンダ数38770に対して、2391までしかパーティションが使用されていない。

＜TASK＞

未使用部分にパーティションを作成し、論理ボリュームとして登録、ディスク容量を増やす。

未使用のパーティションを/dev/sda3　として登録する。（ちょっと乱暴?）

（続き） コマンド (m でヘルプ): n コマンドアクション e 拡張 p 基本領域 (1-4) p 領域番号 (1-4): 3 最初 シリンダ (2392-38770, default 2392):　・・・Enter Using default value 2392 終点 シリンダ または +サイズ または +サイズM または +サイズK (2392-38770, default 38770):　・・・Enter Using default value 38770 コマンド (m でヘルプ): t 領域番号 (1-4): 3 16進数コード (L コマンドでコードリスト表示): 8e　・・・論理ボリュームとして 領域のシステムタイプを 3 から 8e (Linux LVM) に変更しました コマンド (m でヘルプ): p Disk /dev/sda: 318.9 GB, 318901321728 bytes 255 heads, 63 sectors/track, 38770 cylinders Units = シリンダ数 of 16065 * 512 = 8225280 bytes デバイス Boot Start End Blocks Id System /dev/sda1 * 1 33 265041 83 Linux /dev/sda2 34 2391 18940635 8e Linux LVM /dev/sda3 2392 38770 292214317+ 8e Linux LVM コマンド (m でヘルプ): w 領域テーブルは交換されました！ ioctl() を呼び出して領域テーブルを再読込みします。 警告: 領域テーブルの再読込みがエラー 16 で失敗しました: デバイスもしくはリソースがビジー状態です。 カーネルはまだ古いテーブルを使っています。 新しいテーブルは次回リブート時に使えるようになるでしょう。 ディスクを同期させます。

システムを再起動し、追加したパーティションをPVとして登録後、論理ボリュームに追加。

# pvcreate /dev/sda3 Physical volume "/dev/sda3" successfully created # pvdisplay --- Physical volume --- PV Name /dev/sda2 VG Name VolGroup00 PV Size 18.06 GB / not usable 731.00 KB Allocatable yes (but full) PE Size (KByte) 32768 Total PE 578 Free PE 0 Allocated PE 578 PV UUID VjWOIw-336o-Ra5V-zSsL-e1IM-5OPd-c6H2OT --- Physical volume --- PV Name /dev/sda3 VG Name VolGroup00 PV Size 278.68 GB / not usable 21.54 MB Allocatable yes PE Size (KByte) 32768 Total PE 8917 Free PE 1025 Allocated PE 7892 PV UUID 2LaLc8-d16T-u25q-nk4o-hr4C-ZTx7-DI8kUw

PVをVGに登録。ここで指定するVG名は、vgdisplayで表示されるVG Name。

# vgextend VolGroup00 /dev/sda3 Volume group "VolGroup00" successfully extended # vgdisplay --- Volume group --- VG Name VolGroup00 ・・・これ System ID Format lvm2 Metadata Areas 2 Metadata Sequence No 4 VG Access read/write VG Status resizable MAX LV 0 Cur LV 2 Open LV 2 Max PV 0 Cur PV 2 Act PV 2 VG Size 296.72 GB PE Size 32.00 MB Total PE 9495 Alloc PE / Size 576 / 18.00 GB Free PE / Size 8919 / 278.72 GB　　・・・空きが増えたことを確認 VG UUID 7ABki7-KlrO-iOBF-DpEv-XGdo-rMcW-Du3y8a

LVの拡張。次は、+10GBだけ拡張する場合。いっぱいまで拡張する場合は Free PEのエクステント数（上記の場合、-L 8919）を指定する。

# lvextend -L +10G /dev/mapper/VolGroup00-LogVol00 Extending logical volume LogVol00 to 26.00 GB Logical volume LogVol00 successfully resized

拡張されたか確認

# vgdisplay --- Volume group --- VG Name VolGroup00 System ID Format 　　　　 lvm2 Metadata Areas 　 　2 Metadata Sequence No 5 VG Access 　　　read/write VG Status 　　　 resizable MAX LV 　　　 0 Cur LV 　 　　 2 Open LV 　　　 2 Max PV 　　　 0 Cur PV 　　　 2 Act PV 　　　　2 VG Size 　　　 296.72 GB PE Size 　　　 32.00 MB Total PE 　　　 9495 Alloc PE / Size 　　　896 / 28.00 GB ・・・+10GBされたことを確認 Free PE / Size 　　　8599 / 268.72 GB VG UUID 　　　7ABki7-KlrO-iOBF-DpEv-XGdo-rMcW-Du3y8a

論理ボリューム管理のGUIから拡張することも出来る。

ディスクチェックも行うため、時間がかかる（5~10分）。

拡張されたか確認

# vgdisplay --- Volume group --- VG Name VolGroup00 System ID Format lvm2 Metadata Areas 2 Metadata Sequence No 6 VG Access read/write VG Status resizable MAX LV 0 Cur LV 2 Open LV 2 Max PV 0 Cur PV 2 Act PV 2 VG Size 296.72 GB PE Size 32.00 MB Total PE 9495 Alloc PE / Size 8470 / 264.69 GB・・・16GB->264GBに Free PE / Size 1025 / 32.03 GB ・・・残さなくてよい VG UUID 7ABki7-KlrO-iOBF-DpEv-XGdo-rMcW-Du3y8a

パーティションとディスクサイズの確認。ディスクのサイズが259GB、使用量が5%となった。

# fdisk -l Disk /dev/sda: 318.9 GB, 318901321728 bytes 255 heads, 63 sectors/track, 38770 cylinders Units = シリンダ数 of 16065 * 512 = 8225280 bytes デバイス Boot Start End Blocks Id System /dev/sda1 * 1 33 265041 83 Linux /dev/sda2 34 2391 18940635 8e Linux LVM /dev/sda3 2392 38770 292214317+ 8e Linux LVM # df -Th Filesystem 　　　　　　　　　　　　Type サイズ 使用 残り 使用% マウント位置 /dev/mapper/VolGroup00-LogVol00 ext3 259G 12G 234G 5% / /dev/sda1 　　　　　　　　　　　　　 ext3 251M 17M 221M 8% /boot none 　　　　　　　　　　　　　　 tmpfs 2.0G 0 2.0G 0% ev/shm

tmpfsについて

http://d.hatena.ne.jp/naoya/20060217/1140176470

Cactiでディスク容量の監視、/boot 領域の監視追加

＜環境＞CentOS 4, 5, RHELなど　＋ snmpwalk 5.x.x

以前、「cactiでリモートホストのディスク容量を監視する」という記事を書いたが、RAID構成にしたサーバーの設定を変更するため、再びcactiのディスク容量監視設定を更新。ついでに、/boot　領域の設定も追加。

1. snmpwalkで現在のディスク情報（.1.3.6.1.4.1.2021.9.x.x）を確認。

システム領域の1台だけが参照できている。

$ /usr/bin/snmpwalk -v 1 192.168.10.10 -c public .1.3.6.1.4.1.2021.9 UCD-SNMP-MIB::dskIndex.1 = INTEGER: 1 UCD-SNMP-MIB::dskPath.1 = STRING: / UCD-SNMP-MIB::dskDevice.1 = STRING: /dev/md2 UCD-SNMP-MIB::dskMinimum.1 = INTEGER: 21865 UCD-SNMP-MIB::dskMinPercent.1 = INTEGER: -1 UCD-SNMP-MIB::dskTotal.1 = INTEGER: 150745360 UCD-SNMP-MIB::dskAvail.1 = INTEGER: 135526896 UCD-SNMP-MIB::dskUsed.1 = INTEGER: 7437380 UCD-SNMP-MIB::dskPercent.1 = INTEGER: 5 UCD-SNMP-MIB::dskPercentNode.1 = INTEGER: 2 UCD-SNMP-MIB::dskErrorFlag.1 = INTEGER: 0 UCD-SNMP-MIB::dskErrorMsg.1 = STRING:

2. /boot にマウントしたディスクの情報が取れるように、snmpd.confに追加。snmpの設定ファイルを再読み込み。

# vi /etc/snmp/snmpd.conf disk / 10000 // 最低10MBになったらsyscontactに通知 disk /boot // 最低10%になったら通知したければ、10%と追記 ： # service snmpd reload snmpd を再読み込み中:

3. snmpwalk で追加した/bootのディスク情報が正しく取れているか確認

$ /usr/bin/snmpwalk -v 1 192.168.10.10 -c public .1.3.6.1.4.1.2021.9 UCD-SNMP-MIB::dskIndex.1 = INTEGER: 1 UCD-SNMP-MIB::dskIndex.2 = INTEGER: 2 UCD-SNMP-MIB::dskPath.1 = STRING: / UCD-SNMP-MIB::dskPath.2 = STRING: /boot　・・・・これ UCD-SNMP-MIB::dskDevice.1 = STRING: /dev/md2 UCD-SNMP-MIB::dskDevice.2 = STRING: /dev/md0　・・・・これ、以下同様 UCD-SNMP-MIB::dskMinimum.1 = INTEGER: 21865 UCD-SNMP-MIB::dskMinimum.2 = INTEGER: -1 ：

4. cactiの設定変更

consoleのメニューから、New Graphsをクリック

Data Query [ucd/net - Get Monitored Partitions] 欄の緑丸"Reload Associated Query"をクリックしてクエリーを再読み込み（リモートサーバーの場合）。

表示された /boot 欄右横のチェックボックスをクリックし、create ボタンクリック

* Data Query [ucd/net - Get Monitored Partitions] 欄がない場合は、Data Sourceが登録されていない。

Devices - Associated Data Queries 欄のAdd Data Query: リストから

ucd/net - Get Monitored Partitions を選択し、add - save（リモートサーバーの場合）

5. グラフタイトルの編集

・グラフのタイトルを以下のようなマウント位置にしたい場合

　www.server.com - Disk Space - /

　www.server.com - Disk Space - /boot

consoleメニューから、Graph Management - Supplemental Graph Template Data のTitle欄を以下のように変更

|host_description| - Disk Space - |query_dskPath|

・グラフのタイトルを以下のようなディスク名にしたい場合

　www.server.com - Disk Space - /dev/md0

　www.server.com - Disk Space - /dev/mapper/VolGroup00-xx

|host_description| - Disk Space - |query_dskDevice|

6. 5分待ってGraphを確認

7. グラフがうまく表示できない場合の確認ポイント

・クエリーは正しいか

consoleメニューから、Graph Management - Template Name を確認

Data Queries - Template Name （ucd/net - Get Monitored Partitions）をクリック

XML Path欄のパスを確認

cactiが動いているサーバーで、このxmlの中身を確認

<path_cacti>/resource/snmp_queries/net-snmp_disk.xml <interface> <name>Get Monitored Partitions</name> <oid_index>.1.3.6.1.4.1.2021.9.1.1</oid_index> <index_order>dskDevice:dskIndex</index_order> <index_order_type>numeric</index_order_type> <index_title_format>|chosen_order_field|</index_title_format> <fields> <dskIndex> <name>Index</name> <method>walk</method> <source>value</source> <direction>input</direction> <oid>.1.3.6.1.4.1.2021.9.1.1</oid> </dskIndex> <dskPath> <name>Mount Point</name> <method>walk</method> <source>value</source> <direction>input</direction> <oid>.1.3.6.1.4.1.2021.9.1.2</oid> </dskPath> ：

Unix - Get Mounted Partitions　のテンプレートの中身は、perlスクリプトだということが分かる。

<interface> <name>Get Unix Mounted Partitions</name> <description>Queries a list of mounted partitions on a unix-based host with the 'df' command.</description> <script_path>perl |path_cacti|/scripts/query_unix_partitions.pl</script_path> <arg_index>index</arg_index> <arg_query>query</arg_query> <arg_get>get</arg_get> <arg_num_indexes>num_indexes</arg_num_indexes> <output_delimeter>:</output_delimeter> <index_order>dskDevice</index_order> <index_order_type>alphabetic</index_order_type> <index_title_format>|chosen_order_field|</index_title_format> ：

このperlスクリプトは、df -P -k の結果を整形したもの。

つまり、Unix - Get Mounted Partitions で取得できるのは、cactiが動いているローカルのサーバーのディスク容量、ということになる。

・古いテンプレートが生きていないか

グラフを削除、追加していると古いテンプレートを消しそこなってしまうことがある。

グラフを削除するとき、古いData source も削除しておくこと。

表示内容がおかしかったらグラフをいったん削除し、New Graphsで再作成するのが簡単で速い。

2009年11月 5日 (木) cactiでリモートホストのディスク容量を監視する

メモリとSwap領域の確認

＜環境＞ CentOS などLinux 系 OS

メモリとSwap領域のサイズや状態を調べるには以下のような方法がある。

メモリとSwap領域のサイズ

$ cat /proc/meminfo MemTotal:      1032996 kB MemFree:        114212 kB Buffers:         77204 kB Cached:         561616 kB SwapTotal:     2031608 kB SwapFree:      2031608 kB ：

Swap領域のサイズを調べる

$ cat /proc/swaps Filename                 　　　　　　　　　　  Type         Size    Used    Priority /dev/mapper/VolGroup00-LogVol01         partition    2031608    0    -1

論理ボリューム/dev/mapper/VolGroup00-LogVol01の実態を調べる

#  lvdisplay /dev/mapper/VolGroup00-LogVol01   --- Logical volume ---   LV Name                /dev/VolGroup00/LogVol01   VG Name                VolGroup00   LV UUID                ObK2Z5-d17d-OP3S-lHbV-821p-lxe1-aWk6Fe   LV Write Access        read/write   LV Status              available   # open                 1   LV Size                1.94 GB   Current LE             62   Segments               1   Allocation             inherit   Read ahead sectors     auto   - currently set to     256   Block device           253:1

メモリ、Swap領域の使用状況を調べる　-k　KB単位表示、-m　MB単位表示

以下では約100MBがfreeとなっている。

$ free -kt              　total       　　　used       　 free     shared    buffers      cached Mem:       1032996     919016     113980          0      77192     561368 -/+ buffers/cache:     280456     752540 Swap:      2031608          0    2031608 Total:     3064604     919016    2145588

Swap領域の自動マウント設定を調べる

$ cat /etc/fstab # This file is edited by fstab-sync - see 'man fstab-sync' for details /dev/VolGroup00/LogVol00 /                       ext3    defaults        1 1 /dev/sda1                /boot                   ext3    defaults        1 2 : /dev/VolGroup00/LogVol01 swap                    swap    defaults        0 0

Swap領域の使用状況を調べる

# df -H /dev/VolGroup00/LogVol01 Filesystem             Size   Used  Avail Use% マウント位置 -                      529M   173k   529M   1% /dev

メモリとSwapの使用量を動的に調べる

$top top - 11:18:08 up 5 days, 17:36,  3 users,  load average: 0.00, 0.00, 0.00 Tasks: 132 total,   1 running, 131 sleeping,   0 stopped,   0 zombie Cpu(s):  0.2% us,  0.0% sy,  0.0% ni, 99.8% id,  0.0% wa,  0.0% hi,  0.0% si Mem:   1032996k total,   919720k used,   113276k free,    77200k buffers Swap:  2031608k total,        0k used,  2031608k free,   561360k cached :

同じく、10秒おきにMB単位で表示　si... swap in、so... swap out

$ vmstat 10 -S M procs -----------memory---------- ---swap-- -----io---- --system-- ----cpu----  r  b   swpd   free   buff  cache   si   so    bi    bo   in    cs us sy id wa  0  0      0    111     75    548    0    0     1     5   32     2  0  0 100  0  0  0      0    111     75    548    0    0     0    13 1013   109  0  0 100  0  0  0      0    111     75    548    0    0     0     0 1013   102  0  0 100  0 :

Firefoxでflash プラグインがインストールできない

Firefoxを起動すると、Flashをインストールしろと表示されたので、ガイダンスに従いインストールしようとしたがインストールできず。Firefox起動時に必ず、getPlusPlus_Adobe.exe has encountered a problem と行ったPOP UP画面が表示される。

以下を参照し、uninstallerでflashを削除して再インストールしてもだめ。

Flash Player レスキュー！ - インストールができない(Windows)

ダウンロードマネージャー自体はインストールされていることを確認。

最初のPopUp画面の「ここをクリックしてください」をクリックし、詳細を確認。

ModName: kmw_dll.dll 　とあるので、ファイルのプロパティを見てみる。

犯人はKensingtonのドライバファイルだった。

C:¥WINDOWS¥system32¥kmw_dll.dll　を適当な場所に移動

Firefox再起動

Adobe ダウンロードマネージャーがFlash Playerをダウンロードするので、ガイダンスに従いインストール

移動したkmw_dll.dllを元の位置に戻す。

または以下のリンクからFlalsh Playerのzipファイルをダウンロードして、直接解凍インストール。ただしテスト用と記載があるので使用には注意。

テスト用のアーカイブ版 Flash Player の提供について

rpmで「メモリを確保できません」

＜環境＞

RHEL 4

libxml2のバージョンを知りたかったのでrpmを実行したら次のエラーが表示された。

rpmの結果表示中にCtrl+cなどで中断したりしていると、rpmがデータ検索時にDBファイルにアクセスして、テーブル内に一時的に作成する"locker entries"というものが残ってしまい、この現象が発生するらしい。

# rpm -qa | grep libxml rpmdb: Lock table is out of available locker entries エラー: db4 error(22) from db->close: 無効な引数です エラー: cannot open Packages index using db3 - メモリを確保できません (12) エラー: cannot open Packages database in /var/lib/rpm

以下でrpmのBerkley DBを削除後、再構築

# cd /var/lib/rpm/ # rm __db.* # rpm m --rebuilddb

rpmでバージョンチェック再実行で動作確認

# rpm -qa | grep libxml2 libxml2-python-2.x.x-xx.xx libxml2-2.x.x-xx.xx libxml2-devel-2.x.x-xx.xx

詳しくはRacker Hacker　参照

WARNING: Kernel Errors Present とOOM Killer

＜環境＞CentOS 4 + Apache 2.x

OOｍ Killerが動いて、httpdがkillされた、という話。

Logwatchに以下のようなWarningが。

WARNING: Kernel Errors Present [<c0405a71>] error_code+0x39/0x40 ...: 15 Time(s)

/var/log/messagesファイルの内容を確認。

Feb 1 21:53:06 server kernel: httpd invoked oom-killer: gfp_mask=0x201d2, order=0, oomkilladj=0 Feb 1 21:53:06 server kernel: [<c0136d45>] out_of_memory+0x72/0x1a4 Feb 1 21:53:06 server kernel: [<c014216a>] __alloc_pages+0x201/0x282 Feb 1 21:53:06 server kernel: [<c01493cc>] __do_page_cache_readahead+0xc4/0x1c : Feb 1 21:53:36 server kernel: Out of memory: Killed process 30258 (httpd).

"Out of memory"のため、httpdのプロセスをkill した、とある。

ググってみるとKernelが、空きメモリ容量が足りなくなった場合にOOM Killer（Out of Memory Killer）が動作し、ランダムに選択したアプリケーションを停止して空きメモリを確保しようとするものらしい。停止されたものがたまたま "httpd" だったようだ。

この間、10分弱で15プロセスがKillされている。

この時間のアクセスログを見ると、Webサーバーに大量のアクセスが見られた。子プロセスが大量に作られ、メモリ不足に陥ったことが想像できる。

OOM Killerが動作しないようにする方法もあるようだが、他の重要なプロセスがHaltするのは困るので、触らない。

どうも、"memory leak in httpd" が怪しい。httpd.conのMaxRequestsPerChildディレクティブの値を修正し、「個々の子サーバが稼働中に扱うリクエスト数の上限」を制限。Apache再起動（restart）して様子見。

<IfModule prefork.c> # MaxRequestsPerChild 4000 MaxRequestsPerChild 1000 : </IfModule>

KeepAlive が On の場合、リロードを繰り返しても最初のリクエストだけがMaxRequestsPerChildのカウントとして計上される。

MaxRequestsPerChildの値までリクエスト数が達すると、子プロセスは終了しメモリが解放される。

OOM killerとの危険な関係@IT

PHPでstrptimeを使った日付のフォーマットチェック

日付＋時刻形式のフォーマットチェックを簡単に行う方法

strptime関数では、フォーマットと値のチェックを行ってくれるのがよいところ。

以下、コマンドラインから実行するサンプル

最終的に年月日＋時分秒で整形する。

<?PHP $format = '%Y-%m-%d %H:%M:%S'; if($argc < 2) $strdt = "2010-2-14 10:02:20"; else $strdt = $argv[1]; echo "$strdt\n"; $date = strptime($strdt, $format); print_r($date); echo "\r\n"; if($date == false){ print "illegal date time format\r\n"; }else{ printf("%4d%s%02d%s%02d%s", ($date['tm_year'] + 1900), "年", ($date['tm_mon'] + 1), "月", $date['tm_mday'], "日 "); printf("%02d%s%02d%s%02d%s", $date['tm_hour'], "時", $date['tm_min'], "分", $date['tm_sec'], "秒\r\n"); } ?>

実行結果

$ php sample.php "2010-2-4 10:19:05" 2010-2-4 10:19:05 Array ( [tm_sec] => 5 [tm_min] => 19 [tm_hour] => 10 [tm_mday] => 4 [tm_mon] => 1 [tm_year] => 110 [tm_wday] => 4 [tm_yday] => 34 [unparsed] => ) 2010年02月04日 10時19分05秒 $ php strptime.php "2010-13-4 10:19:05" 2010-13-4 10:19:05 illegal date time format

Thunderbird 2.xから3.xへのアップデート

マスターパスワードをリセットする

アップデートに伴い、Software Security Deviceのマスターパスワードを求められるようになった。が、2.0の時のパスワードなんて覚えちゃいない。

ツール－＞オプション－＞詳細－＞証明書とたどる

セキュリティデバイスボタンをクリックすると、「デバイスマネージャー」画面が表示される。

パスワード変更ボタンをクリック

現在のパスワード欄を見ると、「設定なし」となっている。

ここで新しいパスワードを入力し再起動したが、うまく認証できず。結局次の方法でパスワードをリセットすることに。

ツールメニュー－＞エラーコンソールとクリック

コード欄に以下を入力

openDialog("chrome://pippki/content/resetpassword.xul")

確認ダイアログが表示されるので、OKを押して完了。

ただし、そのほか登録していたメールアカウントのパスワードなどもすべて消去され、登録しなおし。。。

Rkhunterのwarningを更新する

<CentOS 4>

毎日送信されるRkhunter(Rootkit Hunter)のログにwarningが増えてきたので、更新することにした。

インストール時のプログラムのhashと、yumなどで更新後のプログラムのhashが依存関係の変更などにより異なるために起きるらしい。

以下手順。

How to refresh and clear Rkhunter warnings after yum updating of programs causing missing dependencies and mismatching of hash.

I've been receiving Rkhunter daily log containing many warnings as below.

Warning: The file properties have changed: File: /usr/bin/curl Current file modification time: 1269870022 Stored file modification time : 1253456113 Warning: The file properties have changed: File: /usr/bin/strace Current hash: 4578d559b5eab3a107dfe00c792ad6ec94dbe295 Stored hash : 166eea8bc4687a5a9850d608d00a35f1eaf4cf20 Current file modification time: 1234566226 Stored file modification time : 1234567890 :

Updates of Rkhunter database and hashes seem to be effective to clear these warnings. Following is the procedure I adapted to solve this problem successfully.

1. Update rkhunter database /　Rkhunterのデータベースを更新

# rkhunter --update [ Rootkit Hunter version 1.3.x ] Checking rkhunter data files... Checking file mirrors.dat [ No update ] Checking file programs_bad.dat [ No update ] Checking file backdoorports.dat [ No update ] Checking file suspscan.dat [ No update ] Checking file i18n/cn [ No update ] Checking file i18n/de [ No update ] Checking file i18n/en [ No update ] Checking file i18n/zh [ No update ] Checking file i18n/zh.utf8 [ No update ]

Renew rkhunter hashes / rkhunterのhashデータベースを更新

# rkhunter --propupd [ Rootkit Hunter version 1.3.x ] File updated: searched for 150 files, found 130, missing hashes 1

If there're still missing hashes, check rkhunter.log under /var/log .

もしまだ missing hashes があったらログの内容を確認。

# vi /var/log/rkhunter.log : [10:04:26] Warning: No hash value found for file '/usr/sbin/kudzu' [10:04:26] Hash command output: /usr/sbin/prelink: /usr/sbin/kudzu: at least one of file's dependencies has changed since prelinking [10:04:26] Try running the command 'prelink /usr/sbin/kudzu' to resolve dependency errors. [10:04:26] Info: Found 17 files in /usr/sbin ： [10:04:26] Info: File updated: searched for 150 files, found 130, missing hashes

This indicates kudzu's hash has been lost hash according to an update after the last prelinking.

prelink後にkudzuの依存関係が変更されているため、以下のコマンドを実行しろとある。

# prelink /usr/sbin/kudzu

Then update rkhunter hash databae again to confirm there's no warnings.

hashデータベースを更新し、warningが出なくなったことを確認

# rkhunter --propupd [ Rootkit Hunter version 1.3.x ] File updated: searched for 150 files, found 130

Rkhunter　- Root Kit Hunter についてはこちら

Selinuxで、bindのログをchrootの下に置く

＜環境＞CentOS 4＋Selinux 有効

bindはインストール済み。messagesファイルにbind関連のログは出力されているが、さらに詳細なログを別ファイルに出力する。

bindはchroot対応済み

最終的に、named.logを/var/named/chrootの下に出力する。

＜設定＞

/etc/named.conf 修正、ログ出力の設定を以下のように変更

ログのキーワードについては、「BINDのロギング機能」、「実用BIND9で作るDNSサーバ」などを参照

logging { channel "default-log" { file "/var/log/named.log" versions 4 size 5M; severity info; print-time yes; print-severity yes; print-category yes; }; category default{ "default-log"; }; category lame-servers { null; }; };

ログ出力用ディレクトリと、ファイルの準備

bindがchroot対応に変更されている場合は、bindは「/」と指定されると「/var/named/chroot/」を参照するようになる。

このため、ログファイルはchrootの下に置くようにディレクトリを設定。

# mkdir /var/named/chroot/var/log # chgrp named /var/named/chroot/var/log # chmod 770 /var/named/chroot/var/log # ll 合計 32 drwxrwx--- 2 root named 4096 1月 20日 14:29 log drwxr-x--- 8 root named 4096 1月 20日 11:37 named drwxrwx--- 3 root named 4096 3月 14日 2003 run drwxrwx--- 2 named named 4096 3月 14日 2003 tmp

この時点でbindを再起動。自動的にログファイルが生成されると思ったが以下のエラー

Jan 20 13:24:24 myserver named[3190]: loading configuration from '/etc/named.conf' Jan 20 13:24:24 myserver named[3190]: isc_log_open '/var/log/named.log' failed: file not found

ログファイルを作成し、書き込み権限を付与

# /var/named/chroot/var/log # touch named.log # chgrp named named.log # chmod g+w named.log

が、nslookupで以下のコマンドを実行してみると、messagesファイルにSelinuxのcontextエラーが。

C:\> nslookup > ls -d myserver.com :

# tail messages Jan 20 13:34:11 myserver kernel: audit(123456.123:1): avc: denied { getattr } for pid=3192 comm="named" name="named.log" dev=dm-0 ino=5839467 scontext=user_u:system_r:named_t tcontext=root:object_r:var_log_t tclass=file Jan 20 13:40:04 myserver kernel: audit(123456.123:3): avc: denied { write } for pid=3191 comm="named" name="log" dev=dm-0 ino=5839467 scontext=user_u:system_r:named_t tcontext=root:object_r:named_conf_t tclass=dir :

「named_tがvar_log_tのタイプを持つfileにgetattrアクセスしようとしたら拒否された」

ということで、ログファイルとディレクトリのコンテキストをchconで修正

# restorecon -Rv log/named.log restorecon reset context /var/named/chroot/var/log/named.log:system_u:object_r:named_zone_t->system_u:object_r:named_conf_t # restorecon -Rv log restorecon reset context /var/named/chroot/var/log:system_u:object_r:named_zone_t->system_u:object_r:named_conf_t

named_conf_t ? と思いつつ、再度nslookup実行。そもそもSelinuxの許可設定はされているのか。

# audit2allow -d -l allow named_t named_conf_t:dir write; allow named_t named_zone_t:file append; allow named_t var_log_t:file getattr; allow unconfined_t named_t:file relabelto;

named_conf_t:dir write 、ディレクトリへの書き込み許可のみ？

やはりエラー

Jan 20 14:49:44 myserver kernel: audit(123456.123:11): avc: denied { append } for pid=3191 comm="named" name="named.log" dev=dm-0 ino=5839467 scontext=user_u:system_r:named_t tcontext=system_u:object_r:named_conf_t tclass=file

結局、BIND 9 のFAQに載っていたコンテキストの設定が正解だった。

# chcon system_u:object_r:named_cache_t named.log # ll -Z -rw-rw-r-- root named system_u:object_r:named_cache_t named.log # chcon system_u:object_r:named_cache_t log # ll -Z drwxrwx--- root named system_u:object_r:named_cache_t log

nslookupを実行し、ログファイルが正しく更新されていることを確認

Jan 20 15:09:34.932 xfer-out: info: client 192.168.100.123#2500: transfer of 'myserver.com/IN': AXFR started

再び設定確認。追加されている。

# audit2allow -d -l allow named_t named_conf_t:dir write; allow named_t named_conf_t:file append; allow named_t named_zone_t:file append; allow named_t var_log_t:file { append getattr }; allow unconfined_t named_t:file relabelto;

このままだとmessagesファイルにも、bindのログが重複して出力されるので、messagesにはbindのログを出力しない設定をしたほうがよい。

ちなみに、このログファイル。名前を変えてもbindのログが出力されている。不思議・・・