suz-lab - blog

CentOS(6.2) & PostgreSQL(9.1) & PostGIS(1.5)

2012-02-20T19:00:00.002+09:00

スズキです。

CentOS(6.2)にPostgreSQL(9.1.2)をインストールし、
PostGIS(1.5.3)も利用できるようにしてみました。

CentOS(6.2)はもちろん「SUZ-LAB謹製 CentOS AMI」です。

【PostgreSQLのインストール】

依存パッケージのインストール

# yum -y install readline-devel

PostgreSQLのインストール

# curl -OL ftp://ftp2.jp.postgresql.org/pub/postgresql/source/v9.1.2/postgresql-9.1.2.tar.gz
# tar xvzf postgresql-9.1.2.tar.gz
# cd postgresql-9.1.2
# ./configure
# make
# make install

postgresユーザーとデータディレクトリの作成

# adduser postgres
# mkdir /usr/local/pgsql/data
# chown postgres.postgres /usr/local/pgsql/data

データベースクラスタの作成

# su - postgres
$ /usr/local/pgsql/bin/initdb -D /usr/local/pgsql/data
$ ls -1 /usr/local/pgsql/data/
PG_VERSION
base
global
pg_clog
pg_hba.conf
pg_ident.conf
pg_multixact
pg_notify
pg_serial
pg_stat_tmp
pg_subtrans
pg_tblspc
pg_twophase
pg_xlog
postgresql.conf

PostgreSQLの起動と確認

$ /usr/local/pgsql/bin/pg_ctl -D /usr/local/pgsql/data start
server starting
$ /usr/local/pgsql/bin/psql 
psql (9.1.2)

【PROJ.4のインストール】

# curl -OL http://download.osgeo.org/proj/proj-4.7.0.tar.gz
# tar xvzf proj-4.7.0.tar.gz
# cd proj-4.7.0
# make
# make install

【GEOSのインストール】

# curl -OL http://download.osgeo.org/geos/geos-3.3.2.tar.bz2
# bunzip2 geos-3.3.2.tar.bz2
# tar xvf geos-3.3.2.tar 
# cd geos-3.3.2
# ./configure
# make
# make install

【PostGISのインストール】

PostGISのインストール

# curl -OL http://postgis.refractions.net/download/postgis-1.5.3.tar.gz
# tar xvzf postgis-1.5.3.tar.gz
# cd postgis-1.5.3
# ./configure --with-pgconfig=/usr/local/pgsql/bin/pg_config
# make
# make install

共有ライブラリの認識

# /sbin/ldconfig

PostGISの利用

$ /usr/local/pgsql/bin/createdb sample
$ /usr/local/pgsql/bin/psql -d sample -f /usr/local/src/postgis-1.5.3/postgis/postgis.sql

次はPostgreSQL(9.1)のレプリケーションを試す予定。(明日の朝までに...)
--------
http://www.suz-lab.com

SimpleDBのドメイン内のデータを一覧表示(NextTokenに注意)

2012-02-15T18:25:00.000+09:00

スズキです。

SimpleDBはRDBのSELECTのようなクエリーが発行でき、
条件に該当するデータを取得することができます。

しかし、一回のAPIリクエストで取得できるデータ数は100件までで、
それ以降を取得するには、「NextToken」というものを利用して、
再度同様のクエリーをAPIでリクエストする必要があります。

具体的には、100件以上該当データがある場合、レスポンスにNextTokenが含まれ、
そのNextTokenを指定して、再度同様のクエリーをリクエストする形になります。
当然、次の100件でもデータが取りきれない場合は、レスポンスに同様に
NextTokenが含まれるので、それを用いて再度リクエストすることになります。

上記を考慮すると、すべてのデータを取得するには、NextTokenがあるかぎり、
複数のリクエストを行う必要があります。

ということで、PHPで簡単に作ってみました。

<?php
require_once(AWS_SDK_PATH . "/sdk.class.php");
date_default_timezone_set("Asia/Tokyo");

$sdb = new AmazonSDB(
    array("key" => SDB_KEY_ACCESS, "secret" => SDB_KEY_SECRET)
);
$sdb->set_region(AmazonSDB::REGION_APAC_NE1);

$query = "SELECT * FROM log WHERE uid >= '0' ORDER BY uid DESC";
$option = array();
do {
    $response = $sdb->select($query, $option);
    foreach($response->body->SelectResult->Item as $item) {
        print($item->Name . "\t");
        foreach($item->Attribute as $attribute) {
            print($attribute->Name  . ":");
            print($attribute->Value . "\t");
        }
        print("\n");
    }
    if(isset($response->body->SelectResult->NextToken)) {
        $option["NextToken"] = $response->body->SelectResult->NextToken;
    } else {
        $option["NextToken"] = null;
    }
} while($option["NextToken"] != null);

exit(0);
?>

実行すると下記のようになります。

# php list-data.php
4f3b67cf5396d8.04566676 uid:1 timestamp:1329293263 action:1 
4f3b65774e50c6.59284865 uid:1 timestamp:1329292663 action:1 
4f3b64ab8239a8.32909808 uid:1 timestamp:1329292459 action:1 
4f3b649b3a3cd1.62613728 uid:1 timestamp:1329292443 action:1 
4f3b625e9e17f1.40124430 uid:1 timestamp:1329291870 action:1 
4f3b58032f0737.20329909 uid:1 timestamp:1329289219 action:1
...

これ応用すれば、SipmleDBのバックアップも簡単に作れるかも。
--------
http://www.suz-lab.com

VPCのサブネット内で利用できるIPアドレスを取得(PHP)

2012-01-31T17:59:00.000+09:00

スズキです。

VPCでELBを利用していると、ELBは負荷に応じてスケールして
サブネット内のIPアドレスを消費してしまいます。

ですので、ELBが存在するサブネット内で十分は利用可能なIPアドレスがあるか、
逐次チェックしたいと思うはずです。

ということでPHP(AWS SDK)でVPCのサブネットの利用可能なIPアドレスを取得してみました。

#!/usr/bin/php
<?php
require_once("/opt/aws/php/latest/sdk.class.php");
$ec2 = new AmazonEC2("ACCESS_KEY", "SECRET_KEY");
$ec2->set_region("ap-northeast-1");
$response = $ec2->describe_subnets(array("SubnetId" => "subnet-xxxxxxxx"));
print((int)$response->body->subnetSet->item->availableIpAddressCount);
?>

実行すると下記のようになります。

# ./get-subnet-ip 
249

これも、また、Nagiosのプラグインにしよう。
--------
http://www.suz-lab.com

NagiosのCloudWatchプラグイン(PHP版)でRDSの監視

2012-01-30T23:45:00.000+09:00

スズキです。

こちらでEC2のCPU使用率が監視できるようになったので、

NagiosのCloudWatchプラグイン(PHP版)を実際に利用

今回はRDSの監視をしてみます。

RDSで監視する項目は、実装の都合上(後述)
CPUUtilization, DatabaseConnections, SwapUsage
としています。

Nagiosのコマンドは、下記のように設定します。

# RDS CPUUtilization
define command {
    command_name    check-cloudwatch-cpu_rds-cloudpack
    command_line    /opt/cloudpack/nagios/check_cloudwatch -f /opt/cloudpack/conf/$HOSTGROUPNAME$/credential.yml -n AWS/RDS -m CPUUtilization -s Average -u Percent -d DBInstanceIdentifier -r ap-northeast-1 -w $ARG1$ -c $ARG2$ -v $ARG3$
}

# RDS DatabaseConnections
define command {
    command_name    check-cloudwatch-connection_rds-cloudpack
    command_line    /opt/cloudpack/nagios/check_cloudwatch -f /opt/cloudpack/conf/$HOSTGROUPNAME$/credential.yml -n AWS/RDS -m DatabaseConnections -s Average -u Count -d DBInstanceIdentifier -r ap-northeast-1 -w $ARG1$ -c $ARG2$ -v $ARG3$
}

# RDS SwapUsage
define command {
    command_name    check-cloudwatch-swap_rds-cloudpack
    command_line    /opt/cloudpack/nagios/check_cloudwatch -f /opt/cloudpack/conf/$HOSTGROUPNAME$/credential.yml -n AWS/RDS -m SwapUsage -s Average -u Bytes -d DBInstanceIdentifier -r ap-northeast-1 -w $ARG1$ -c $ARG2$ -v $ARG3$
}

そのコマンドを利用して、下記のように監視設定します。

# RDS CPUUtilization
define service {
    use                    suzlab_cloudpack.jp-service
    host_name              suzlab_cloudpack.jp_suzlab-rds
    service_description    cpu_rds
    service_groups         cpu_rds
    check_command          check-cloudwatch-cpu_rds-cloudpack!60!80!suzlab
}

# RDS DatabaseConnections
define service {
    use                    suzlab_cloudpack.jp-service
    host_name              suzlab_cloudpack.jp_suzlab-rds
    service_description    connection_rds
    service_groups         connection_rds
    check_command          check-cloudwatch-connection_rds-cloudpack!50!100!suzlab
}

# RDS SwapUsage
define service {
    use                    suzlab_cloudpack.jp-service
    host_name              suzlab_cloudpack.jp_suzlab-rds
    service_description    swap_rds
    service_groups         swap_rds
    check_command          check-cloudwatch-swap_rds-cloudpack!0!0!suzlab
}

問題なければ下記のようにWebの方でも表示されているはずです。

RDS CPUUtilization

RDS DatabaseConnections

RDS SwapUsage

ちなみに現状のNagiosのCloudWatchプラグインのコードは次のようになっています。

#!/usr/bin/php
<?php
require_once("/opt/aws/php/latest/sdk.class.php");

// define status
$ok       = array("code" => 0, "name" => "OK");
$warning  = array("code" => 1, "name" => "WARNING");
$critical = array("code" => 2, "name" => "CRITICAL");
$unknown  = array("code" => 3, "name" => "UNKNOWN");

// set option
$option = getopt("c:w:f:r:n:m:s:u:d:v:");
$critical_size = $option["c"];
$warning_size  = $option["w"];
$credential    = yaml_parse_file($option["f"]);
$region        = $option["r"];
$namespace     = $option["n"];
$metrics       = $option["m"];
$statistics    = $option["s"];
$unit          = $option["u"];
$name          = $option["d"];
$value         = $option["v"];

// init cw
$cw = new AmazonCloudWatch($credential["accessKey"], $credential["secretKey"]);
$cw->set_region($region);
date_default_timezone_set("Asia/Tokyo");

// get metric statistics
$response = $cw->get_metric_statistics(
    $namespace,
    $metrics,
    "-10 minutes",
    "now",
    300,
    $statistics,
    $unit,
    array(
        "Dimensions" => array(
            array("Name" => $name, "Value" => $value)
        )
    )
);
$data = (float)$response->body->GetMetricStatisticsResult->Datapoints->member->$statistics->to_string();

// check status
if($data > $critical_size) {
    $status = $critical["code"];
} elseif($data > $warning_size) {
    $status = $warning["code"];
} elseif($data >= 0) {
    $status = $ok["code"];
} else {
    $status = $unknown["code"];
}

// output status
$output = " - ${namespace} ${metrics} ${statistics} ${name} ${value}: ${data} ${unit};| data=${data};${warning_size};${critical_size};0;";
switch($status) {
    case $ok["code"]:
        print("CloudWatch " . $ok["name"]       . $output);
        exit($ok["code"]);
    case $warning["code"]:
        print("CloudWatch " . $warning["name"]  . $output);
        exit($warning["code"]);
    case $critical["code"]:
        print("CloudWatch " . $critical["name"] . $output);
        exit($critical["code"]);
    case $unknown["code"]:
        print("CloudWatch " . $unknown["name"]  . $output);
        exit($unknown["code"]);
}
print("CloudWatch " . $unknown["name"] . $output);
exit($unknown["code"]);
?>

見てのとおり、WarningやCriticalは閾値「より大きい」の場合となっています...
RDSにはFreeableMemoryやFreeStorageSpaceと、閾値「より小さい」場合を
WarningやCriticalにする項目もあり、現状それには対応できていません...

次回は「より小さい」にも対応してRDSの監視をもっと細かく出来るようにしよう！
--------
http://www.suz-lab.com

NagiosのCloudWatchプラグイン(PHP版)を実際に利用

2012-01-27T20:57:00.002+09:00

スズキです。

少し時間がたってしまいましたが、下記で作成したNagiosのCloudWatchプラグインを
実際に利用して、EC2のCPU使用率を監視してみました。

NagiosのCloudWatchプラグイン(PHP版)

まずは、下記のようにコマンドを定義します。

define command {
    command_name    check-cloudwatch-cpu-cloudpack
    command_line    /opt/cloudpack/nagios/check_cloudwatch -f /opt/cloudpack/conf/$HOSTGROUPNAME$/credential.yml -n AWS/EC2 -m CPUUtilization -s Average -u Percent -d InstanceId -r ap-northeast-1 -w $ARG1$ -c $ARG2$ -v $ARG3$
}

次に、下記のように作成したコマンドを利用して、EC2を監視するようにします。

define service {
    use                    admin_cloudpack.jp-service
    host_name              admin_cloudpack.jp_admin-a-ec2
    service_description    cloudwatch_cpu
    service_groups         cloudwatch_cpu
    check_command          check-cloudwatch-cpu-cloudpack!60!80!i-xxxxxxxx
}

今回はCPU使用率が60%でwarning、80%でcriticalになるようにしています。

Nagiosを再起動すると、下記のように監視できていることが確認できます。

次はRDSの監視も作ろう。
--------
http://www.suz-lab.com

VPCのSubnetとELBの関係(Availability Zone編)

2012-01-24T00:31:00.000+09:00

スズキです。

前回はVPC上で構築するELBと、ELBにアタッチするSubnetと、
そのSubnetで必要なIPアドレスについてまとめました。

VPCのSubnetとELBの関係(Available IP編)

そして、ELBにアタッチできるSubnetは複数アタッチすることができるので、
今回は、アタッチする複数のSubnetとAvailability Zoneの関係をまとめてみます。

まずは下記のようにaゾーンに属する2つのSubnentとbゾーンに属する
1つのSubnetを容易します。

あらかじめaゾーンのSubnet(10.0.0.0/24)をアタッチしておき、
さらに同じaゾーンのSubnet(10.0.4.0/25)をアタッチすると、

下記のように後からアタッチしたSubnetに入れ替わってしまいます。
どうも、同じゾーンのSubnetは複数アタッチできないようです。

このaゾーンのSubnet(10.0.4.0/25)がアタッチされた状態で、
bゾーンのSubnet(10.0.1.0/24)をアタッチすると、今度は追加される形で
アタッチされることがわかります。

今度は複数ゾーンのSubnetをアタッチに関して、Subnetで必要なIPアドレス数を
確認してみます。

まずは、aゾーン、bゾーン、それぞれの利用可能なIPアドレスの合計が
123未満の場合で試してみます。
(ELBを作成するにはSubnetに利用可能なIPアドレスが123必要です)

やはり、IPアドレスが足りない旨のエラーが出力されます。

次に、aゾーン、bゾーン、それぞれの利用可能なIPアドレスの合計が
123以上の場合で試してみます。

利用可能なIPアドレスの合計が123以上でも、まだ、
IPアドレスが足りない旨のエラーが出力されてしまいます。

そして、aゾーン、bゾーンのどちらか一方の利用可能なIPアドレスが
123以上の場合で試してみます。

一方のゾーンの利用可能なIPアドレスの合計が123以上でも、やはり、
IPアドレスが足りない旨のエラーが出力されてしまいます。

そして、aゾーン、bゾーンの両方の利用可能なIPアドレスが
123以上の場合で試してみます。

今度は無事、ELBを作成することができました。

つまり、ELBに対して複数のゾーン(Subnet)をアタッチする場合は、
どちらのSubnetの利用可能なIPアドレスも123以上、必要となることになります。

VPNとSubnetとELBの関係は、これである程度まとまったかな…
--------
http://www.suz-lab.com

VPCのSubnetとELBの関係(Available IP編)

2012-01-20T22:17:00.002+09:00

スズキです。

以前、VPCでELBを作成するときに、所属するSubnetのCIDRブロックに関して紹介しました。
(少なくとも"/25"ということでしたが)

VPC上のELBに対するサブネットのCIDRブロックについて

今回は、このELBとSubnetの関係を、もう少し掘り下げてみます。

まずはSubnetを、どこまで細かく切れるか確認してみます。

Netmaskは最小28、最大16ということになります。

では、最小の28でSubnet(10.0.2.0/28)を作ってみます。
ちなみに、この時に利用できるIP(Available IP)は11です。

そして、このSubnetに対してELBを作成してみます。

当然、Netmaskが25より小さいので作成できません。
エラーメッセージをみると、

ELBを作成するには少なくても123個の利用可能なIPアドレスが必要

ということになります。

ということで、Netmaskを25にして作成してみます。
この時に利用できるIP(Available IP)は123です。

当然、利用可能なIPアドレスが123個になるのでELBは作成できるのですが、
もう一つ同じSubnetにELBを作成しようとすると、今度は利用可能なIPアドレスが、
一つ減って122個なので、下記のように作成することができません。

つまり、Netmaskが25のSubnetでは、ELBは一つしか作成できないことになります。

今度は、Netmaskを24にして作成してみます。
この時に利用できるIP(Available IP)は251です。

すると、当然といえば当然ですが、下記のように複数のELBを同一のSubnetに
作成することができます。
(おそらく残りの利用可能なIPが122個になるまで作成できると思います)

そもそもELBが作成できるSubnetのNetmaskの最小が25になってるのは、
ELBが適切にスケールするためのはずです。
そうだと、ELB一つに対して、122個の利用可能なIPアドレスを用意しておく必要があると、
思ってしまうのですが、Netmaskが24の時は、おそらく残りのIPアドレスが122個になる、
129個のELBが作成できてしまうと思います。
この場合は、一つのELBに対して、平均１個弱のIPアドレスしかスケールのために
用意されてないことになります。

このあたりは、少し不思議な感覚になってしまいますが、そういうものなのでしょう…

とりあえず、整理できたぞ！
--------
http://www.suz-lab.com

skipfishでログイン後のページのセキュリティ診断

2012-01-20T20:36:00.001+09:00

スズキです。

下記でskipfishを現実的なスピードで実施できるようになったので、

skipfishを早く終了させるために

今回は、ログイン後のページに対してもセキュリティ診断してみます。

といっても、ログイン後の埋めこまれているCookieをskipfish実行時に指定するだけです。

Cookieの確認は下記のようにChromeなどのブラウザで行うことができます。

上記で確認した、ログイン維持に利用しているCookieを、
下記のようにskipfish実行時に指定(-C CAKEPHP=xxxxxxxxxxxxxxxxxxxxxxxxxx)します。

# ./skipfish -LVY -W /dev/null -C CAKEPHP=xxxxxxxxxxxxxxxxxxxxxxxxxx \
> -X /login -X /logout -o portal-auth http://www.suz-lab.com/

ここで、”-X”オプションは除外するパスを指定するもので、
今回はセッションがクリアされてしまう、ログイン(/login)とログアウト(/logout)を
除外するようにしています。

セキュリティ診断対象のWebサーバのサクセスログで、
ちゃんとログインしていないとアクセスできないページが出力されていれば、成功です。

セキュリティ診断職人、ブラッシュアップしよう。
--------
http://www.suz-lab.com

暗号化ファイルシステム(cryptsetup)を更にDRBDで冗長化(2)

2012-01-18T18:52:00.002+09:00

スズキです。

こちらでDRBD上にcryptsetupで暗号化ファイルシステムを作成したので、

暗号化ファイルシステム(cryptsetup)を更にDRBDで冗長化(1)

今回は、スタンバイ状態のマシンにフェイルオーバーしても、
問題なくファイルシステムが利用できるか確認してみます。

まずは、アクティブマシンでの作業です。

ファイルシステムの中身を確認し、

# ls /mnt/encrypted/
lost+found  test.txt

アンマウントし、

# umount /mnt/encrypted/

DRBDもセカンダリにし、

# drbdsetup /dev/drbd0 secondary

DRBDの状態がセカンダリになっていることを確認しておきます。

# /etc/init.d/drbd status
drbd driver loaded OK; device status:
version: 8.3.12 (api:88/proto:86-96)
GIT-hash: e2a8ef4656be026bbae540305fcb998a5991090f build by dag@Build32R6, 2011-11-20 10:55:07
m:res    cs         ro                   ds                 p  mounted  fstype
0:mysql  Connected  Secondary/Secondary  UpToDate/UpToDate  C

次に、スタンバイマシンでの作業です。

まずは、DRBDをプライマリにします。

# drbdsetup /dev/drbd0 primary

次に、ちゃんとプライマリになっていることを確認します。

# /etc/init.d/drbd status
drbd driver loaded OK; device status:
version: 8.3.12 (api:88/proto:86-96)
GIT-hash: e2a8ef4656be026bbae540305fcb998a5991090f build by dag@Build32R6, 2011-11-20 10:55:07
m:res    cs         ro                 ds                 p  mounted  fstype
0:mysql  Connected  Primary/Secondary  UpToDate/UpToDate  C

そして、DRBDのデバイスをオープンします。オープン時に聞かれるパスフレーズは、
アクティブサーバで入力したものと同じ物を利用します。

# cryptsetup luksOpen /dev/drbd0 encrypted
Enter passphrase for /dev/drbd0:

最後に、マウントして、ファイルシステムとして利用できるようにします。

# mount -t ext4 /dev/mapper/encrypted /mnt/encrypted

ファイルシステムの中身を確認すると、
アクティブサーバと同様の状態であることがわかります。

# ls /mnt/encrypted/
lost+found  test.txt

Next Stepとしては、

(1)パスフレーズなしで利用できるよにする。
(2)Heartbeatと連動してフェイルオーバーするようにする。
(3)フェイルオーバー時に接続先も自動的に変更するよにする(EIP/VPCルーティング)

といった感じでしょうか？(上記もブログ化できるように頑張ります)

とりあえず、skipfishに戻るか...
--------
http://www.suz-lab.com

暗号化ファイルシステム(cryptsetup)を更にDRBDで冗長化(1)

2012-01-18T17:37:00.002+09:00

スズキです。

クラウド上だと、セキュリティを気にし、ディスクの暗号化が要件になることが
よくあります。このような場合は、下記で紹介されているようにcryptsetupと呼ばれる
オープンソースのツールを利用して実現することができます。

cryptsetupで暗号化ファイルシステムの作成 - lost and found ( for me ? )

今回は、この暗号化されたファイルシステム(ディスク)をさらに"DRBD"で
冗長化する方法を試してみます。

その前に、DRBDの状態を確認して、作業するマシンがプライマリになるように
しておきます。

# drbdsetup /dev/drbd0 primary
# /etc/init.d/drbd status
drbd driver loaded OK; device status:
version: 8.3.12 (api:88/proto:86-96)
GIT-hash: e2a8ef4656be026bbae540305fcb998a5991090f build by dag@Build32R6, 2011-11-20 10:55:07
m:res    cs         ro                 ds                 p  mounted  fstype
0:mysql  Connected  Primary/Secondary  UpToDate/UpToDate  C

まずは、cryptsetup(CentOS 6)をインストールします。

# yum -y install cryptsetup

次に、DRBDのデバイス(/dev/drbd0)をフォーマットします。
フォーマット時にパスフレーズを入力する必要もおります。

# cryptsetup -y luksFormat --cipher aes-cbc-essiv:sha256 --key-size 256 /dev/drbd0 

WARNING!
========
This will overwrite data on /dev/drbd0 irrevocably.

Are you sure? (Type uppercase yes): YES
Enter LUKS passphrase: 
Verify passphrase:

そして、フォーマットしたデバイスをオープンします。オープン時にも同様の
パスフレーズを入力します。オープンされると、/dev/mapper/encryptedという
デバイス(デバイスマッパー)が作成され、以後、このデバイスを利用していきます。

# cryptsetup luksOpen /dev/drbd0 encrypted
Enter passphrase for /dev/drbd0:

その後、ファイルシステムをフォーマットします。

# mkfs.ext4 /dev/mapper/encrypted 
mke2fs 1.41.12 (17-May-2010)
Filesystem label=
OS type: Linux
Block size=4096 (log=2)
Fragment size=4096 (log=2)
Stride=0 blocks, Stripe width=0 blocks
65408 inodes, 261615 blocks
13080 blocks (5.00%) reserved for the super user
First data block=0
Maximum filesystem blocks=268435456
8 block groups
32768 blocks per group, 32768 fragments per group
8176 inodes per group
Superblock backups stored on blocks: 
 32768, 98304, 163840, 229376

Writing inode tables: done                            
Creating journal (4096 blocks): done
Writing superblocks and filesystem accounting information: done

This filesystem will be automatically checked every 36 mounts or
180 days, whichever comes first.  Use tune2fs -c or -i to override.

最後にマウントすることでdrbdで冗長化された暗号化ファイルシステムが
利用できるようになります。

# mkdir /mnt/encrypted
# mount -t ext4 /dev/mapper/encrypted /mnt/encrypted

次は、フェイルオーバーしても(スタンバイマシンで)暗号化ファイルシステムが
利用できることを確認してみます。

多分、大丈夫...
--------
http://www.suz-lab.com

skipfishを早く終了させるために

2012-01-17T23:12:00.001+09:00

スズキです。

以前、下記よりskipfishを利用したセキュリティ診断を紹介しました。

"skipfish"でWebアプリのセキュリティ診断

しかしこのskipfish、実際に利用してみると診断が全然終わりません。
アクセスログなどでアクセス内容を確認してみると、延々と、膨大な辞書ファイル上の
キーワードに対して、それらをファイル名としたURLのチェックをしています。

このURLチェックは実行時間を考えると現実的ではないので、下記のようなオプションで、
このチェックを行わないようにすることができます。

./skipfish -LVY -W /dev/null -o admin http://www.suz-lab.com/

オプションは下記のとおりです。

-L: do not auto-learn new keywords for the site
-V: do not update wordlist based on scan results
-Y: do not fuzz extensions in directory brute-force
-W wordlist: load an alternative wordlist (skipfish.wl)
(今回は辞書ファイルを使わないように"/dev/null"を指定しています)

これで、キーワードによるURLチェックがスキップでき、
セキュリティ診断を短時間で実施することができます。

ディレクトリ数が少ないサイトならいいんだけど...
--------
http://www.suz-lab.com

スナップショットからWindowsインスタンスを復元

2012-01-17T15:21:00.003+09:00

スズキです。

よく、スナップショットからAMIを作成して昔の状態のEC2インスタンスを復元する
ってことをやっているのですが、スナップショットからWindowsのAMIを作成することは、
現時点でできないようです。

なので、定期的にスナップショットはとっているものの、いざ復元するときは、
AMIにはできないので、Windows自体の復元はできず、Root Device(Cドライブ)を
適当にアタッチして、ファイルを取り出すことしかできないと思っていました。

そしたら cloudpack Night #1 で @oko_chang が、それに近い内容を発表してくれました。
(ありがとうございます！)

発表内容は、Windows AMIのリージョン間移行だったのですが、
移行元リージョンのWindowsをスナップショットとって移行先リージョンのWindowsで
復元するって部分は、まさに上記の問題の解決方法となります。

基本的な考え方は、インスタンスはストップするとRoot DeviceのEBSも交換できるので、
AMIを作るのではなく、スナップショットから作成したRoot DeviceのEBSを、
適当なWindowsのものと差し替えてしまうものです。

具体的な手順は下記となります。

まずはバックアップです。

(1)スナップショットを取るインスタンス(バックアップ元)を停止します。

(2)停止したインスタンスのEBS(Root Device)のスナップショットをとります。

(3)スナップショットがとれたら、取得元のインスタンスをターミネートします。

そして、復元です。

(4)スナップショットからEBSを作成します。

※サイズはスナップショットと同じ(30G)にします。
※ゾーン(AZ)は復元に使うインスタンスと同じ(a)にします。

(5)予め起動していた復元用インスタンス(Windows)を停止します。

(6)復元用インスタンスのEBS(Root Device)をデタッチします。

(7)復元用インスタンスにスナップショット(バックアップ元)から作成した
EBS(Root Device)をアタッチします。

※デバイスはRoot Deviceとしてアタッチするので"/dev/sda1"とします。

(8)復元用インスタンスをスタートします。

リモートデスクトップでログインすると、ちゃんとスナップショットをとったWindowsが
復元されていることを確認することができます。

今まで、できないと思って、再インストールしてた...
--------
http://www.suz-lab.com

S3オリジンのCloudFrontでインデックスドキュメントやエラードキュメントを利用できるようにする

2011-12-28T18:56:00.000+09:00

スズキです。

CloudFrontには"Default Root Object"という設定項目があり
"http://cloudfront.suz-lab.com/"などでアクセスすると、
上記項目で指定したファイル(ページ)が表示されるようになります。

しかし、"http://cloudfront.suz-lab.com/sub/"などの
サブディレクトリに対するアクセスには対応してません。

また、ステータスコード404などに対するエラードキュメントに関しても、
独自のエラーページを表示させることはできません。

CloudFrontのオリジンをS3にしている場合(S3オリジン)は、
まさに上記の制限が、そのままきいてしまいます。

ちなみにカスタムオリジンの場合はオリジン次第なので、オリジンサーバが
インデックスドキュメントやエラードキュメントを指定できるようにしていれば、
独自のエラードキュメントやアブディレクトリに対するインデックスドキュメントも
可能となります。

しかし、やはりコンテンツは、高い可用性と耐久性を誇るS3に置いておきたいところです。

そもそも、S3には"Web Site Hosting"と呼ばれる機能があり、その機能を有効にすると
サブディレクトリを含めたインデックスドキュメントとエラードキュメントを
独自のファイルに指定することができます。ただし、"Web Site Hosting"用のURLから
アクセスしてはじめて上記の機能を利用することができます。

ここでまた、CloudFrontに戻ります。

CloudFrontを設定するときに、S3オリジンでバケットを指定するのではなく、
カスタムオリジンで上記の"Web Site Hosting"のURLを指定することも、実はできます。

カスタムオリジンにすれば"Web Site Hosting"機能の結果がキャッシュされるため、
サブディレクトリを含めたインデックスドキュメントや独自のエラードキュメントも、
実質、利用できていることになります。

キャッシュ期間には注意です！
--------
http://www.suz-lab.com

VPC上のELBに対するサブネットのCIDRブロックについて

2011-12-27T14:02:00.000+09:00

スズキです。

VPC上のELBはサブネットに所属しますが、そもそもELBはスケールするので、
サブネットのIPアドレスレンジはある程度確保しておかなければいけないはずです。

じゃあ、いくつ確保しておけばいいのか？という話ですが、
下記に記載されていました。

How Do I Use Elastic Load Balancing in Amazon VPC?

つまり、次の引用のとおりです。

In order to ensure that your load balancer can scale properly,
the subnet that you attach the load balancer to should be at least a /25 CIDR block
and should have enough free IP addresses to scale.

ELBが適切にスケールできるように、ELBが所属するサブネットのCIDRブロックは
少なくとも"/25"にし、自由に利用できるIPアドレスを確保すべきです。

例えば、下記のようにサブネットを割り振る感じになると思います。

サブネット: 192.168.1.0/25
ネットマスク: 255.255.255.128
ネットワーク: 192.168.1.0
ホストのレンジ: 192.168.1.1 - 192.168.1.126
ブロードキャスト: 192.168.1.127

ちなみにVPCの場合、

192.168.1.1 192.168.1.2 192.168.1.3

の先頭３つのIPアドレスが予約されているので、実際にEC2に割り振れるIPアドレスは

192.168.1.4 - 192.168.1.126

となります。

とりあえずELBのサブネットは"/25"ってことですね。
--------
http://www.suz-lab.com

NagiosのCloudWatchプラグイン(PHP版)

2011-12-26T13:28:00.001+09:00

スズキです。

以前、@j3tm0t0さんが公開してくれたNagiosのプラグイン、check_cloudwatchと
ほぼ同様のものをCloudWatchとの通信はPHPを使ったもので作ってみました。
(元祖check_cloudwatchはコマンドラインツールを利用しています)

下記のように利用できます。

# ./check_cloudwatch \
> -c 20 \
> -w 10 \
> -f credential.yml \
> -r ap-northeast-1 \
> -n AWS/EC2 \
> -m CPUUtilization \
> -s Average \
> -u Percent \
> -d InstanceId \
> -v i-xxxxxxxx \
CloudWatch CRITICAL - AWS/EC2 CPUUtilization Average InstanceId i-xxxxxxxx: 25.092 Percent;| data=25.092;10;20;0;

コードは下記のようになっています。(エラー処理が甘々ですが...)

require_once("/opt/aws/php/latest/sdk.class.php");

// define status
$ok       = array("code" => 0, "name" => "OK");
$warning  = array("code" => 1, "name" => "WARNING");
$critical = array("code" => 2, "name" => "CRITICAL");
$unknown  = array("code" => 3, "name" => "UNKNOWN");

// set option
$option = getopt("c:w:f:r:n:m:s:u:d:v:");
$critical_size = $option["c"];
$warning_size  = $option["w"];
$credential    = yaml_parse_file($option["f"]);
$region        = $option["r"];
$namespace     = $option["n"];
$metrics       = $option["m"];
$statistics    = $option["s"];
$unit          = $option["u"];
$name          = $option["d"];
$value         = $option["v"];

// init cw
$cw = new AmazonCloudWatch($credential["accessKey"], $credential["secretKey"]);
$cw->set_region($region);
date_default_timezone_set("Asia/Tokyo");

// get metric statistics
$response = $cw->get_metric_statistics(
    $namespace,
    $metrics,
    "-10 minutes",
    "now",
    300,
    $statistics,
    $unit,
    array(
        "Dimensions" => array(
            array("Name" => $name, "Value" => $value)
        )
    )
);
$data = (float)$response->body->GetMetricStatisticsResult->Datapoints->member->$statistics->to_string();

// check status
if($data > $critical_size) {
    $status = $critical["code"];
} elseif($data > $warning_size) {
    $status = $warning["code"];
} elseif($data > 0) {
    $status = $ok["code"];
} else {
    $status = $unknown["code"];
}

// output status
$output = " - ${namespace} ${metrics} ${statistics} ${name} ${value}: ${data} ${unit};| data=${data};${warning_size};${critical_size};0;";
switch($status) {
    case $ok["code"]:
        print("CloudWatch " . $ok["name"]       . $output);
        exit($ok["code"]);
    case $warning["code"]:
        print("CloudWatch " . $warning["name"]  . $output);
        exit($warning["code"]);
    case $critical["code"]:
        print("CloudWatch " . $critical["name"] . $output);
        exit($critical["code"]);
    case $unknown["code"]:
        print("CloudWatch " . $unknown["name"]  . $output);
        exit($unknown["code"]);
}
print("CloudWatch " . $unknown["name"] . $output);
exit($unknown["code"]);

AccessKey、SecretKeyは下記のファイルにまとめています。

accessKey: "XXXXXXXXXXXXXXXXXXXX"
secretKey: "ssssssssssssssssssssssssssssssssssssssss"

もう少しブラッシュアップしたら、また、ちゃんと紹介しようと思います。
--------
http://www.suz-lab.com

PostfixからSESにリレー(stunnel編)

2011-12-20T20:34:00.001+09:00

スズキです。

と言っても、下記のAWSドキュメント通りですが...

とりあえず、SESのSMPTポート(465)をたたいてみると、
下記のように何も反応が返って来ません。

# telnet email-smtp.us-east-1.amazonaws.com 465
Trying 107.22.229.233...
Connected to email-smtp.us-east-1.amazonaws.com.
Escape character is '^]'.

これは、SESへの(SMTP)接続はTLSでの暗号化を必要とするので、
当然、直接のtelnetでは接続できなくなります。

ということで、下記のようにstunnelをインストールして、
SESに対するTLSの処理はstunnelでおこない、stunnnelにはTLS無しで
透過的にSESに接続できるようにしてみました。

# yum -y install stunnel

stunnelの設定ファイルは下記のとおりです。

# cat /etc/stunnel/stunnel.conf
[smtp-tls-wrapper]
accept  = 2525
client  = yes
connect = email-smtp.us-east-1.amazonaws.com:465

stunnelの起動は次のとおりですが、起動スクリプトも、
どこかで用意しておきたいところです。

# /usr/bin/stunnel

そして、stunnelに対して接続すると、下記のように今度は無事、
SMTPのレスポンスが返ってくることがわかります。

# telnet localhost 2525
Trying 127.0.0.1...
Connected to localhost.
Escape character is '^]'.
220 email-smtp.amazonaws.com ESMTP SimpleEmailService-194655181

次は実際にPostfixからSESにリレーしてみます。
--------
http://www.suz-lab.com

そろそろCloudFormation(VpcCloudFormation編)

2011-12-19T23:14:00.001+09:00

スズキです。

下記で簡単な(EC2一つ立ち上げるだけの)CloudFormationを試しましたが、

そろそろCloudFormation(HelloCloudFormation編)

今回は、これをVPC上で立ち上げてみました。

テンプレートは下記のようになります。

{
  "AWSTemplateFormatVersion" : "2010-09-09",

  "Description" : "Create an Amazon EC2 instance running the SUZ-LAB CentOS AMI.",

  "Parameters" : {
    "KeyName" : {
      "Description" : "Name of an existing EC2 KeyPair to enable SSH access to the instance",
      "Type"        : "String"
    }
  },

  "Mappings" : {
    "RegionMap" : {
      "ap-northeast-1" : { "AMI" : "ami-de9126df" }
    }
  },

  "Resources" : {
    "Ec2Instance" : {
      "Type"       : "AWS::EC2::Instance",
      "Properties" : {
        "KeyName"          : { "Ref" : "KeyName" },
        "ImageId"          : { "Fn::FindInMap" : [ "RegionMap", { "Ref" : "AWS::Region" }, "AMI" ]},
        "InstanceType"     : "m1.small",
        "SubnetId"         : "subnet-9bd939f2",
        "PrivateIpAddress" : "10.0.0.100"
      }
    }
  },

  "Outputs" : {
    "InstanceId" : {
      "Description" : "InstanceId of the newly created EC2 instance",
      "Value"       : { "Ref" : "Ec2Instance" }
    }
  }
}

前回同様、下記に示す上記のテンプレートURLを使って
AWS Management Consoleから起動すればOKです。

https://s3-ap-northeast-1.amazonaws.com/www.suz-lab.com/formation/VpcCloudFormation.template

ただし、サブネットやルーティング、Network ACLsなどの設定は、まだ、
できないようなので、VPC(サブネット/ルーティング/Network ACLs)の設定は
事前にしておく必要があるようです。

また、最近VPC上で利用できるようになったELBですが、こちらも、まだ、
対応していないようです。ですので、お金はかかりますがVPC上のELBも、
予め作成しておく必要があるようです。
(そしてインスタンスのぶら下げるのは手動になってしまうと思います)

次は何編にしよう？
--------
http://www.suz-lab.com

そろそろCloudFormation(HelloCloudFormation編)

2011-12-19T20:44:00.001+09:00

スズキです。

CloudFormationの用途に、一時的に利用する開発環境や検証環境、バックアップ環境の
起動/停止を一気にまとめて行うというものがあると思います。
(というか、それしか思い浮かばないのですが...)

ということで、そろそろ、そのような要件が出てきたので、
ちゃんと一から試すことにしました。(つまりHelloCloudFormationです)

下記は一番簡単な、AMIからEC2を起動するHelloCloudFormationテンプレートです。
(シンプルなテンプレートなので意味合いは直感的にわかると思います)

{
  "AWSTemplateFormatVersion" : "2010-09-09",

  "Description" : "Create an Amazon EC2 instance running the SUZ-LAB CentOS AMI.",

  "Parameters" : {
    "KeyName" : {
      "Description" : "Name of an existing EC2 KeyPair to enable SSH access to the instance",
      "Type" : "String"
    }
  },

  "Mappings" : {
    "RegionMap" : {
      "ap-northeast-1" : { "AMI" : "ami-de9126df" }
    }
  },

  "Resources" : {
    "Ec2Instance" : {
      "Type" : "AWS::EC2::Instance",
      "Properties" : {
        "KeyName" : { "Ref" : "KeyName" },
        "ImageId" : { "Fn::FindInMap" : [ "RegionMap", { "Ref" : "AWS::Region" }, "AMI" ]}
      }
    }
  },

  "Outputs" : {
    "InstanceId" : {
      "Description" : "InstanceId of the newly created EC2 instance",
      "Value" : { "Ref" : "Ec2Instance" }
    }
  }
}

ということで、上記のテンプレートを実際にAWS Management Consoleから利用してみます。

まずは、上記のテンプレートを下記のようにS3に配置します。

https://s3-ap-northeast-1.amazonaws.com/www.suz-lab.com/formation/HelloCloudFormation.template

次に、下記のように"Provide a Template URL"を選択し、テンプレートのURLを入力します。

そして、パラメータを入力します。ここで入力するパラメータは上記のテンプレートで
"Parameters"で定義されたもので、任意に指定することができます。

最後に、情報の確認して問題なければ、構築を開始します。

起動後、"Outputs"タグを確認すると、下記のようにテンプレートの"Outputs"で定義した情報が
出力されていることがわかります。

次は、VPC！
--------
http://www.suz-lab.com

S3にブラウザから直接アップロードするフォーム(HTML)をPHPで生成

2011-12-19T14:30:00.004+09:00

スズキです。

S3にブラウザから直接アップロードする方法を下記で紹介しましたが、

JAWS-UG宮崎第3回勉強会LT資料(Browser Uploads to S3 using HTML POST Forms)

そのときは、静的なHTMLフォームを前提として、Base64のpolicyやsignatureは
別プログラム(Ruby)で作成していました。

今回は、そのHTMLフォームをPHPで生成し、有効期限やアップロードファイル名、
リダイレクト先などを動的に変更できるようにしてみました。

コードは下記のとおりです。

<?php
$id         = "00000000";
$expiration = gmdate("Y-m-d\TH:i:s\Z",strtotime("1 minute"));
$redirect   = "http://www.suz-lab.com/index.html?id=$id";
$policy = <<<EOS
{
    "expiration": "$expiration",
    "conditions": [
        {"bucket": "www.suz-lab.com"},
        ["starts-with", "\$key", ""],
        {"acl": "private"},
        {"success_action_redirect": "$redirect"},
        ["starts-with", "\$Content-Type", ""],
        ["content-length-range", 0, 1048576]
    ]
}
EOS;
$signature = hash_hmac("sha1", base64_encode($policy), "SECRET_KEY", true);
?>
<html>
  <head>
    <meta http-equiv="Content-Type" content="text/html; charset=utf-8"/>
  </head>
  <body>
    <form action="http://www.suz-lab.com.s3.amazonaws.com/"
          method="post" enctype="multipart/form-data">
      <input type="hidden" name="key"
             value="<?php print("${id}.txt"); ?>"/>
      <input type="hidden" name="AWSAccessKeyId"
             value="ACCESS_KEY"/>
      <input type="hidden" name="acl"
             value="private"/>
      <input type="hidden" name="success_action_redirect"
             value="<?php print($redirect); ?>"/>
      <input type="hidden" name="policy"
             value="<?php print(base64_encode($policy)); ?>"/>
      <input type="hidden" name="signature"
             value="<?php print(base64_encode($signature)); ?>"/>
      <input type="hidden" name="Content-Type"
             value="text/plain"/>
      <input type="file"   name="file"/>
      <input type="submit" name="button" value="Upload"/>
    </form>
  </body>
</html>

上記は有効期限をHTMLフォームが作成されてから1分以内とし、アップロードファイル名や
リダイレクトURLにid(ユーザーIDなど)が反映されるようにしています。

S3へのアップロードが成功すると、下記にリダイレクトされ、リダイレクトURLに
事前につけておいたパラメータ(id=00000000)も引き継がれていることがわかります。

http://www.suz-lab.com/index.html?id=00000000&bucket=www.suz-lab.com&key=00000000.txt&etag=%22...%22

さらに、HTMLフォームが生成された後、1分後にアップロードすると、
次のように、ちゃんとエラーになりました。

これで、いつでも使えます！
--------
http://www.suz-lab.com/

JAWS-UG宮崎第3回勉強会LT資料(Browser Uploads to S3 using HTML POST Forms)

2011-12-17T09:14:00.001+09:00

スズキです。

第3回 AWS User Group - Japan【宮崎】勉強会
でLTします。

LTの内容は下記の資料の通り、
HTMLフォームからS3に直接ファイルをアップロードする方法についてです。

Browser Uploads to S3 using HTML POST Forms

View more presentations from Hiroyasu Suzuki

それでは、宮崎の皆さん、よろしくお願いします。
--------
http://www.suz-lab.com

Varnishで"www.suz-lab.com"を"suz-lab.com"にリダイレクト

2011-12-09T18:26:00.000+09:00

スズキです。

以前下記で、Varnishによる"suz-lab.com"を"www.suz-lab.com"に
リダイレクトする方法を紹介しましたが、

Varnishでリダイレクト専用Webサーバの構築

今回は、その逆の"www.suz-lab.com"を"suz-lab.com"にリダイレクトする方法です。

上記の設定は、設定ファイル"default.vcl"の"vcl_error"で行い、
具体的には下記のようになります。

sub vcl_error {
    if(req.http.host == "www.suz-lab.com") {
      set obj.http.Location = "http://" regsub(req.http.host, "www\.(.*)", "\1") req.url;
      set obj.status = 301;
    }
    return(deliver);
}

近頃、S3への小細工は、全部Varnishでやってます...
--------
http://www.suz-lab.com

オレゴンリージョン(us-west-2)のAKI(pv-grub-hd0/00)

2011-12-07T23:22:00.000+09:00

スズキです。

下記AMIの作成にて、

SUZ-LAB謹製 CentOS AMI (6.0.5 64bit us-west-2)

"User Provided Kernel"で使うAKI(pv-grub-hd0/00)を調査したのでまとめておきます。

▼aki-c2e26ff2
ec2-public-images-us-west-2/pv-grub-hd0_1.02-i386.gz.manifest.xml

▼aki-c0e26ff0
ec2-public-images-us-west-2/pv-grub-hd00_1.02-i386.gz.manifest.xml

▼aki-98e26fa8
ec2-public-images-us-west-2/pv-grub-hd0_1.02-x86_64.gz.manifest.xml

▼aki-94e26fa4
ec2-public-images-us-west-2/pv-grub-hd00_1.02-x86_64.gz.manifest.xml

他のリージョンに関しては、下記でまとめてあります。

"User Provided Kernel"で使う"pv-grub-hd0/00"が1.02になってた

久しぶりにAMIのリージョン移行した...
--------
http://www.suz-lab.com

SUZ-LAB謹製 CentOS AMI (6.0.5 64bit us-west-2)

2011-12-07T22:54:00.003+09:00

スズキです。

オレゴンリージョン(us-west-2)にリリースしました。

AMIを「suz」で検索してもらえれば、

811118151095/suz-lab_ebs_centos-core-i386-6.0.5

として見つかるはずです。

AMIの内容は、下記と同様となります。
SUZ-LAB謹製 CentOS AMI (6.0.5 64bit ap-northeast-1)

ただし利用しているAKIは下記となります。

▼aki-98e26fa8
ec2-public-images-us-west-2/pv-grub-hd0_1.02-x86_64.gz.manifest.xml

Enjoy!
--------
http://www.suz-lab.com

SUZ-LAB謹製 CentOS AMI (6.0.5 64bit ap-northeast-1)

2011-12-07T00:08:00.000+09:00

スズキです。

下記をアップデートしました。

SUZ-LAB謹製 CentOS AMI (6.0.2 64bit ap-northeast-1)

AMIを「suz」で検索してもらえれば、

811118151095/suz-lab_ebs_centos-core-x86_64-6.0.5

として見つかるはずです。

アップデート内容は下記の32bitのものと同じになります。

SUZ-LAB謹製 CentOS AMI (6.0.3 32bit ap-northeast-1)

SUZ-LAB謹製 CentOS AMI (6.0.4 32bit ap-northeast-1)

SUZ-LAB謹製 CentOS AMI (6.0.5 32bit ap-northeast-1)

Enjoy!
--------
http://www.suz-lab.com

SUZ-LAB謹製 CentOS AMI (6.0.5 32bit ap-northeast-1)

2011-12-06T22:46:00.000+09:00

スズキです。

下記をアップデートしました。

SUZ-LAB謹製 CentOS AMI (6.0.4 32bit ap-northeast-1)

AMIを「suz」で検索してもらえれば、

811118151095/suz-lab_ebs_centos-core-i386-6.0.5

として見つかるはずです。

アップデート内容は下記となります。

パッケージのアップデート

# yum -y update

よく要求されるセキュリティ要件を反映

まず、"/etc/pam.d/password-auth"を下記のように修正しています。

▼6回以上の失敗アクセスがあった場合、システム管理者がリセットするまで無効とする。

auth        required      pam_tally2.so deny=6

▼過去4回のパスワードを回転使用できないようにする。

password    sufficient    pam_unix.so try_first_pass use_authtok nullok sha512 shadow remember=4

最終的に"/etc/pam.d/password-auth"は下記のようになっています。

auth        required      pam_env.so
auth        required      pam_tally2.so deny=6
auth        sufficient    pam_unix.so try_first_pass nullok
auth        required      pam_deny.so

account     required      pam_unix.so

password    requisite     pam_cracklib.so try_first_pass retry=3 type=
password    sufficient    pam_unix.so try_first_pass use_authtok nullok sha512 shadow remember=4
password    required      pam_deny.so

session     optional      pam_keyinit.so revoke
session     required      pam_limits.so
session     [success=1 default=ignore] pam_succeed_if.so service in crond quiet use_uid
session     required      pam_unix.so

次に、監査ログ(/var/log/audit/audit.log)へのアクセス情報も記録するように、
"/etc/audit/audit.rules"に下記を追加しておきます。

-w /var/log/audit/audit.log

"audit.log"にアクセス(tail)すると、下記のように記録されます。

type=SYSCALL msg=audit(1323176229.195:36): arch=40000003 syscall=5 success=yes exit=3 a0=bf9b27d8 a1=8000 a2=0 a3=bf9b1050 items=1 ppid=875 pid=902 auid=0 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 tty=pts0 ses=1 comm="tail" exe="/usr/bin/tail" key=(null)
type=CWD msg=audit(1323176229.195:36):  cwd="/var/log/audit"
type=PATH msg=audit(1323176229.195:36): item=0 name="/var/log/audit/audit.log" inode=7132 dev=ca:01 mode=0100600 ouid=0 ogid=0 rdev=00:00

Enjoy!
--------
http://www.suz-lab.com