2011年1月31日月曜日

EC2の障害復旧パターン

スズキです。

EC2で運用しているサーバがおかしくなったときの、
復旧パターンを下記にまとめてみました。
(cloudpackでも下記に近い形で復旧を試みています)

前提は、

- AMIはEBSベースのものを使用
- EBSはルートディスク用とデータディスク用の二つを利用
- OSはLinux(CentOS 5.x)
- プレミアムサポートには入っていない
- 本番運用前に初期AMIを作成

といった感じです。

(1) SSHでログイン
--------
OK: ★OS内で復旧作業(ログ調査、ミドルウェアのリスタートなど)して、終了。
NG: どうしようもないので、(2)へ。

(2) 他のAWS環境でもSSHでログイン
--------
NG: AWS全体に関わる障害の可能性が高いのでAWSに問い合わせ。
OK: インスタンス固有の問題として、(3)へ。

(3) インスタンスのリブート(& SSHでログイン)
※ついでにAMIも作成
--------
OK: ログインできれば、★へ。
NG: リブートでダメならストップ/スタートということで、(4)へ。

(4) インスタンスのストップ&スタート(& SSHでログイン)
--------
OK: ログインできれば、★へ。
NG: ストップ/スタートでダメならAMIから立ち上げ直しということで、(5)へ。

(5) ※で作成したAMIを同一ゾーンで立ち上げる(& SSHでログイン)
--------
OK: ログインできれば、★へ。
NG: ゾーンの問題を考慮して、(6)へ。

(6) ※で作成したAMIを別ゾーンで立ち上げる(& SSHでログイン)
--------
OK: ログインできれば、★へ。
NG: もうバックアップからの復旧しかないので、(7)へ。

(7) ルートディスクのスナップショット(バックアップ)からAMIを作成して起動(& SSHでログイン)
OK: ログインできれば、他のバックアップからルートディスクのデータを復旧して、(A)へ。
NG: スナップショットがダメなら最後の手段で、(8)へ。

(A) 障害発生インスタンスのデータディスク(EBS)をアタッチして動作確認
--------
OK: 問題なければ、★へ。。
NG: もうバックアップからの復旧しかないので、(B)へ。

(B) データディスクのスナップショット(バックアップ)からEBSを作成&アタッチして動作確認
--------
OK: 問題なければ、他のバックアップからデータを復旧して、★へ。。
NG: スナップショットがダメなら最後の手段で、(C)へ

(C) 初期AMIを起動しデータディスク(EBS)を切り離し、それをアタッチして動作確認
--------
OK: 問題なければ、他のバックアップからデータを復旧して、★へ。。
NG: 死亡。

(8) 初期AMIを起動(& SSHでログイン)
--------
OK: ログインできれば、他のバックアップからルートディスクのデータを復旧して、(A)へ。
NG: 死亡。

cloudpackの中の人が、わかりやすい図にしてくれるはず…
--------
http://www.suz-lab.com

2011年1月27日木曜日

"s3cmd"のまとめ

スズキです。

"s3cmd"に関して、いろいろ書いてきて、
記事が散らばってるので、ちょっとまとめてみました。

▼CentOSで"s3cmd"
http://blog.suz-lab.com/2010/03/centoss3cmd.html

▼"s3cmd"の導入
http://blog.suz-lab.com/2010/07/s3cmd.html

▼"s3cmd"で同期
http://blog.suz-lab.com/2010/08/s3cmd.html

▼"s3cmd"でヘッダの追加
http://blog.suz-lab.com/2010/09/s3cmd.html

でも近頃は、カスタムオリジンばかりで、あまり使わなくなっちゃったなー…
--------
http://www.suz-lab.com

ELBのSSL証明書を変更する

スズキです。

"Management Console"だと、ELBの再作成になってしまいますが、
APIを直接操作するツールなら、可能です。

具体的には下記で紹介した、
http://blog.suz-lab.com/2011/01/elb1ec2httpsssl.html
"Elastic Load Balancing API Tools"を利用すればいい話です。

コマンド的には、下記となります。

> elb-set-lb-listener-ssl-cert my-load-balancer ^
? -I AAAAAAAA ^
? -S SSSSSSSS ^
? --region ap-southeast-1 ^
? --lb-port 443 ^
? --cert-id arn:aws:iam::811118151095:server-certificate/ssl2

"--cert-id"で指定する値は、下記で紹介した方法で確認できます。
http://blog.suz-lab.com/2011/01/iam-command-line-toolkitielbssl.html

これで、ELBの証明書が更新できることがわかりました。
--------
http://www.suz-lab.com

"IAM Command Line Toolkit"を使ってELBで利用したSSL証明書の確認

スズキです。

以前紹介したようにELBにSSL証明書をインストールできるのですが、
http://blog.suz-lab.com/2011/01/elbssl-termination.html

ELBを削除しても、インストールした証明書は残っているらしく、
("Management Console"で新規のELBを作成すると以前の証明書が選択できる)
でも、"Management Console"では、その証明書が全く管理できない状態です。

そのような場合は、直接APIを操作するコマンドラインツールを利用する必要があり、
今回はIAMの話なので、下記の"IAM Command Line Toolkit"を試してみました。
http://aws.amazon.com/developertools/AWS-Identity-and-Access-Management/4143

と言ってもJavaのツールなので話は簡単で、
適当にダウンロードして展開して、
(以下"P:\common\sbin\iam"に展開したとして)
下記のように環境変数を設定すれば、準備OKです。

> set JAVA_HOME=P:\windows\sbin\java
> set AWS_IAM_HOME=P:\common\sbin\iam
> set PATH=%PATH%;%JAVA_HOME%\bin
> set PATH=%PATH%;%AWS_ELB_HOME%\bin

登録してある証明書のパス一覧を取得する場合は、
次のようなコマンドを実行します。

> iam-servercertlistbypath ^
? --aws-credential-file credentials.txt
--------
arn:aws:iam::811118151095:server-certificate/ssl1
arn:aws:iam::811118151095:server-certificate/ssl2
arn:aws:iam::811118151095:server-certificate/suz-lab
arn:aws:iam::811118151095:server-certificate/suz-ssl

ちゃんと、今まで作成した証明書がリストされています。

ちなみに"credentials.txt"は、下記のようにキー情報が書かれたファイルです。

--------【credentials.txt】--------
AWSAccessKeyId=AAAAAAAA
AWSSecretKey=SSSSSSSS
--------

これで、ELBの証明書まわりをAPIで実験する準備が整いました。
--------
http://www.suz-lab.com

2011年1月26日水曜日

ELBを利用して1つのEC2で複数ドメインのHTTPS(SSL)

スズキです。

EC2には一つのIPアドレスしか割り振られないので、
基本的に複数ドメインのHTTPS(SSL)ができません。

ですがELBを利用すると、1つのEC2で
複数ドメインのHTTPS(SSL)利用できます。

具体的な方法は、下記で紹介されています。
http://elwoodicious.com/2009/12/23/using-elb-to-serve-multiple-domains-over-ssl-on-ec2-for-giggles/

ただし、上記記事は、以下で紹介した
http://blog.suz-lab.com/2011/01/elbssl-termination.html
ELBの"SSL Termination"機能がなかったときのものなので、
今なら、もっとスマートに実現出来るはずです。

ELBの"SSL Termination"を利用した方法は下記となります。

(1) SSLを設定したELBを用意する。

(2) (1)とは別のSSLを設定したELBを用意する。

(3) (1)のホスト名と(2)のホスト名をバーチャルドメインとして設定をした
EC2(httpd)を用意する。

(4) EC2を(1)と(2)のELBに登録する。

このやり方なら、SSLの処理は各ELBで行い、実際のコンテンツは、
一つのEC2で公開する形となり、表記を実現することができます。

ただし、ここで一つ問題があります。
"Manegement Console"では1つのEC2を複数のELBに登録することができません。
実際に(4)を実施するには、APIベースのツールを利用する必要があります。

今回は"Elastic Load Balancing API Tools"を(Windowsで)使ってみました。
http://aws.amazon.com/developertools/Amazon-EC2/2536

使い方は簡単で、"P:\common\sbin\elb"に一式展開してあるとすると、
環境変数を下記のように設定すれば

> set JAVA_HOME=P:\windows\sbin\java
> set AWS_ELB_HOME=P:\common\sbin\elb
> set PATH=%PATH%;%JAVA_HOME%\bin;%AWS_ELB_HOME%\bin;

以下のコマンドでELB(my-load-balancer)に
EC2(i-xxxxxxxx)を追加することができます。

> elb-register-instances-with-lb my-load-balancer ^
? -I AAAAAAAA ^
? -S SSSSSSSS ^
? --region ap-southeast-1 ^
? --instances i-xxxxxxxx
※ "-I"はアクセスキー、"-S"はシークレットキー。

この方法で、(1)、(2)のELBに対して、同一のEC2を登録すればOKです。

"Manegement Console"でも、
二つのELBに同一のEC2が登録されていることが確認できます。
--------
http://www.suz-lab.com

"Management Console"で"CloudWatch"のアラーム設定(AWS)

スズキです。

調子に乗って、2日連続のクイックレビューです。

今回は、こちらで紹介された、"Management Console"で
"CloudWatch"のアラームなどを設定する方法です。

まず、"Management Console"にサインインすると、下記のように、
CloudWatchのタブを確認することができます。


試験的に、ELBに接続されているEC2が0になったら、
アラームメールが送信されるように設定してみます。

タブを選択すると左のパネルに下記のメニューが表示されるので、
"Metrics > ELB"を選択します。


そして、次のように対象ELBのHealthyHostCountをチェックします。


すると、下部が以下のように表示されるので、"Ceate Alerm"ボタンを押して、


次のように、アラームを作成します。ここでは5分間、
ELBのHealthyHostCountが1未満だった場合にアラームが送信されるようにしています。


そして、送信先を設定します。


ここまで設定できたら、後は下記の確認画面となります。



すると、次のようなメールが届きます。

--------
You have chosen to subscribe to the topic:
arn:aws:sns:ap-southeast-1:811118151095:test

To confirm this subscription, click or visit the link below 
(If this was in error no action is necesary):
Confirm subscription

Please do not reply directly to this e-mail. If you wish to remove yourself
from recieving all future SNS subscription confirmation requests
please send email to sns-opt-out
--------

"Confirm subscription"がリンクになっているので、クリックすると下記画面が表示され、
SNSの該当トピックが購読(?)されます。



念のため、"Management Console"のSNSタブで確認すると、
上記の内容を確認することができます。



そして最後に、ELBを利用しているEC2のWebサーバを落としたら、
しっかりと、下記のアラームメールが届きました。


--------
You are receiving this email because your Amazon CloudWatch Alarm "test"
in the APAC - Singapore region has entered the ALARM state,
because "Threshold Crossed: 1 datapoint (0.33) was less than the threshold (1.0)."
at "Wednesday 26 January, 2011 08:25:38 UTC".

Alarm Details:
- Name:                       test
- Description:                test
- State Change:               OK -> ALARM
- Reason for State Change:    Threshold Crossed: 1 datapoint (0.33) was less than the threshold (1.0).
- Timestamp:                  Wednesday 26 January, 2011 08:25:38 UTC

Threshold:
- The alarm is in the ALARM state when the metric is LessThanThreshold 1.0 for 300 seconds.

Monitored Metric:
- MetricNamespace:            AWS/ELB
- MetricName:                 HealthyHostCount
- Dimensions:                 [LoadBalancerName = my-load-balancer]
- Period:                     300 seconds
- Statistic:                  Average
- Unit:                       null

State Change Actions:
- OK:
- ALARM: [arn:aws:sns:ap-southeast-1:811118151095:test]
- INSUFFICIENT_DATA:

--------


"cloudpack"の監視内容に反映しておかないと...
--------
http://www.suz-lab.com

SESを使ってみた(AWS)

スズキです。

久しぶりの24時間以内のクイックレビューです。

こちらで紹介されているようにAWSでEmail送信サービス(SES)がリリースされました。
(簡単な使い方はこちらで紹介されています)

今回は、"Amazon Simple Email Service Scripts"を利用して試してみました。

まずは適当なUnix環境でスクリプトのアーカイブをダウンロードして展開します。

# curl -OL http://aws-catalog-download-files.s3.amazonaws.com/AmazonSES-2011-01-24.zip
# unzip AmazonSES-2011-01-24.zip

展開したファイルは、以下の通りです。

ses-get-stats.pl : 統計情報の取得
ses-send-email.pl : メールの送信
ses-verify-email-address.pl : メールアドレスのチェック
SES.pm : 上記で使われるモジュール

※ READMEに従いPerlの環境(モジュールも含む)を用意しておく必要があります。

スクリプトができたら、下記コマンドで送受信するメールアドレスの認証です。
(この状態では認証したメールアドレスしか送受信できません)

# ./ses-verify-email-address.pl -k credentials.conf -v suzuki@suz-lab.com

※ credentials.confは以下のような認証情報が記述されたファイルです。

--------【credentials.conf】--------
AWSAccessKeyId=AAAAAAAA
AWSSecretKey=SSSSSSSS
--------

すると、認証リクエストを行ったメールアドレスに下記メールが届きます。

--------
Dear Amazon SES customer:

We have received a request to authorize an email address for use with Amazon SES.
To confirm that you are authorized to use this email address,
please go to the following URL:

https://email-verification.us-east-1.amazonaws.com/?...

Your request will not be processed unless you confirm the address using this URL.

To learn more about sending email from Amazon SES,
please refer to the Amazon SES Developer Guide.

Sincerely, Amazon Web Services
--------

URLをクリックすると、次のページに遷移してメールアドレスが認証されます。


メールアドレスの認証が終わったら、下記コマンドでメールの送信です。

# ./ses-send-email.pl -k credentials.conf -s "Test" -f suzuki@suz-lab.com \
> suzuki@suz-lab.com < test.txt

"suzuki@suz-lab.com(-f)"から"suzuki@suz-lab.com"へ、タイトル"Test"の
本文が"test.txt"の内容のメールを送信しています。

無事にメールが届けば実験成功です。

ただ、これでは認証したメールアドレスしか送信できないので、
このままだと現実的ではありません。

認証してないメールアドレスにも送信できるようにするためには、
下記フォームから申請する必要があります。


これで大量メール配信(スパムじゃない)などで、
サーバ数とかを気にする必要がなくなるかも知れません。
--------
http://www.suz-lab.com

2011年1月25日火曜日

JMeterのテスト計画で利用できる関数

スズキです。

JMeterでテスト計画を作成するときに、
パラメーターに現在時刻を設定したり、
ランダム値を利用したりしたいときがあります。

URLのパラメータにUNIX時間を入れたい(キャッシュ対策!?)場合は、
${__time()}を利用することができます。

例えば、以下のようにしておくと、
/test.php?time=${__time()}

次のようにその時のUNIX時間が入ります。
/test.php?time=1234567890

また、ランダム値を入れたい場合は、${__Random(1,30)}を利用します。
(引数はランダム値の下限と上限です)

例えば、以下のようにしておくと、
test_${__Random(1,30)}

次のように1から30の間のランダム値が入ります。
test_18

また変数的な機能もあり、${__Random(1,30), test}としたときに、
結果が23だったとすると、その後${test}とすると、そのまま23になります。

関数を利用することで、高度なテストが簡単に作成することができます。
--------
http://www.suz-lab.com

JMeterでリモートクライアント

スズキです。

"/opt/jmeter"にJMeter一式が展開されている前提です。

リモートクライアントを起動するサーバで下記を実行します。

# /opt/jmeter/bin/jmeter-server > jmeter-server.log 2>&1 &

テストを実行するサーバでは、まず下記のように
設定ファイル"/opt/jmeter/bin/jmeter.properties"を調整します。

--------【jmeter.properties】--------
...
remote_hosts=xxx.xxx.xxx.xxx,yyy.yyy.yyy.yyy,zzz.zzz.zzz.zzz
...
--------
※ xxx.xxx.xxx.xxxなどはリモートクライアントのIPアドレスです。

次に以下のようなコマンドでテストを実行します。

# /opt/jmeter/bin/jmeter -r -n -t test.jmx -l test.jtl

※ test.jmxはJMeterで作成したテストファイルです。
※ test.jtlはテスト結果のXMLファイルです。

これで、リモートクライアントでテストが実行されます。
注意点としては、リモートクライアントが5台で、
テストファイルの記述が50スレッドでのテストの場合、
1台ずつ50スレッドのテストが事項されます。
--------
http://www.suz-lab.com

2011年1月21日金曜日

"Route 53"の利用

スズキです。

今、もっとも熱いAWSのプロダクトは"Elastic Beanstalk"かもしれませんが、
今回のクイックレビューは"Route 53"です。

"Route 53"はAWSが用意したDNSサービスで、
AWSのサービスらしく、すべてAPIが用意されており、
プログラムで、DNSの操作を行うことができます。

まずは、下記より"Route 53"が利用出来るようにサインアップしておく必要があります。
http://aws.amazon.com/route53/

"Route 53"の操作は以下の"dnscurl.pl"を利用するので
http://aws.amazon.com/developertools/Amazon-Route-53/9706686376855511
適当な(Perlが使える)UNIX環境上で作業することにします。

▼"dnscurl.pl"のダウンロード

# curl -OL http://awsmedia.s3.amazonaws.com/catalog/attachments/dnscurl.pl

※必要に応じてCPANモジュールを入れておく必要があります。

▼認証ファイルの作成

# vi secret.conf
--------
%awsSecretAccessKeys = (
 "suz-lab" => {
  id => "AAAAAAAA",
  key => "SSSSSSSS",
 },
);
--------
# chmod 600 secret.conf

※idにはAWSのアクセスキー、keyにはAWSのシークレットキーを記述します。

▼ゾーン作成ファイルの作成

# vi hosted_zone.xml
--------
<?xml version="1.0"?>
<CreateHostedZoneRequest
  xmlns="https://route53.amazonaws.com/doc/2010-10-01/">
 <Name>suz-lab.com.</Name>
 <CallerReference>suz-lab</CallerReference>
 <HostedZoneConfig>
  <Comment>suz-lab zone</Comment>
 </HostedZoneConfig>
</CreateHostedZoneRequest>
--------

▼ゾーンの作成

# perl dnscurl.pl --keyfile secret.conf --keyname suz-lab -- -X POST ¥
> -H "Content-Type: text/xml; charset=UTF-8" ¥
> --upload-file hosted_zone.xml ¥
> https://route53.amazonaws.com/2010-10-01/hostedzone
--------
<?xml version="1.0"?>
<CreateHostedZoneResponse
  xmlns="https://route53.amazonaws.com/doc/2010-10-01/">
 <HostedZone>
  <Id>/hostedzone/Z3M5OPEHXP6JOU</Id>
  <Name>suz-lab.com.</Name>
  <CallerReference>suz-lab</CallerReference>
  <Config>
   <Comment>suz-lab zone</Comment>
  </Config>
 </HostedZone>
 <ChangeInfo>
  <Id>/change/CP1BS9HXHYGRO</Id>
  <Status>PENDING</Status>
  <SubmittedAt>2011-01-21T11:06:37.156Z</SubmittedAt>
 </ChangeInfo>
 <DelegationSet>
  <NameServers>
   <NameServer>ns-170.awsdns-21.com</NameServer>
   <NameServer>ns-956.awsdns-55.net</NameServer>
   <NameServer>ns-1914.awsdns-47.co.uk</NameServer>
   <NameServer>ns-1102.awsdns-09.org</NameServer>
  </NameServers>
 </DelegationSet>
</CreateHostedZoneResponse>
--------

※Id(Z3M5OPEHXP6JOU)はよく使うので覚えておきます。
※設定すべきネームサーバもいくつか取得できます。

▼ゾーンの確認

# perl dnscurl.pl --keyfile secret.conf --keyname suz-lab -- ¥
> https://route53.amazonaws.com/2010-10-01/hostedzone/Z3M5OPEHXP6JOU
--------
<?xml version="1.0"?>
<GetHostedZoneResponse
  xmlns="https://route53.amazonaws.com/doc/2010-10-01/">
 <HostedZone>
  <Id>/hostedzone/Z3M5OPEHXP6JOU</Id>
  <Name>suz-lab.com.</Name>
  <CallerReference>suz-lab</CallerReference>
  <Config>
   <Comment>suz-lab zone</Comment>
  </Config>
 </HostedZone>
 <DelegationSet>
  <NameServers>
   <NameServer>ns-170.awsdns-21.com</NameServer>
   <NameServer>ns-956.awsdns-55.net</NameServer>
   <NameServer>ns-1914.awsdns-47.co.uk</NameServer>
   <NameServer>ns-1102.awsdns-09.org</NameServer>
  </NameServers>
 </DelegationSet>
</GetHostedZoneResponse>
--------

▼レコード作成ファイルの作成

# vi resource_record.xml
--------
<?xml version="1.0"?>
<ChangeResourceRecordSetsRequest
  xmlns="https://route53.amazonaws.com/doc/2010-10-01/">
 <ChangeBatch>
  <Comment>add test</Comment>
  <Changes>
   <Change>
    <Action>CREATE</Action>
    <ResourceRecordSet>
     <Name>test.suz-lab.com.</Name>
     <Type>A</Type>
     <TTL>14400</TTL>
     <ResourceRecords>
      <ResourceRecord>
       <Value>192.168.1.10</Value>
      </ResourceRecord>
     </ResourceRecords>
    </ResourceRecordSet>
   </Change>
  </Changes>
 </ChangeBatch>
</ChangeResourceRecordSetsRequest>
--------

▼レコードの作成

# perl dnscurl.pl --keyfile secret.conf --keyname suz-lab -- -X POST ¥
> -H "Content-Type: text/xml; charset=UTF-8" ¥
> --upload-file resource_record.xml ¥
> https://route53.amazonaws.com/2010-10-01/hostedzone/Z3M5OPEHXP6JOU/rrset
--------
<?xml version="1.0"?>
<ChangeResourceRecordSetsResponse
  xmlns="https://route53.amazonaws.com/doc/2010-10-01/">
 <ChangeInfo>
  <Id>/change/C25KZ8FGH5KOSA</Id>
  <Status>PENDING</Status>
  <SubmittedAt>2011-01-21T11:33:28Z</SubmittedAt>
 </ChangeInfo>
</ChangeResourceRecordSetsResponse>
--------

▼レコードの確認

# host test.suz-lab.com ns-170.awsdns-21.com
--------
Using domain server:
Name: ns-170.awsdns-21.com
Address: 205.251.192.170#53
Aliases:
test.suz-lab.com has address 192.168.1.10

これで、"Route 53"でDNSレコードの管理ができるようになりました。

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

2011年1月18日火曜日

「AWS+」から「cloudpack」へ、そして「AWS Solution Provider」に!

スズキです。

今更の話ですが、
昨年末に「AWS+」は「cloudpack」に名称を変更しています。
http://www.cloudpack.jp/

そして、本日、その「cloudpack」が「AWS Solution Provider」として、
掲載されました。
http://aws.amazon.com/solutions/solution-providers/cloudpack/

「AWS Solution Provider」の名に恥じぬよう、今後も引き続き頑張ります!
--------
http://www.aws-plus.com

2011年1月17日月曜日

"gitweb"をインストール

スズキです。

Webアプリ開発用AMIでは、バージョン管理にgitを利用することにしています。
リポジトリの内容を簡単に確認できるよう"gitweb"をインストールしてみました。

インストールは"yum"(rpmforge)で簡単に可能です。
# yum install gitweb

まずは下記のようなコマンドで"git"のリポジトリを作成しておく必要があります。
# su - suz-lab
$ git init
$ git add conf
$ git add zend
$ git commit
※"/home/suz-lab/conf"と"/home/suz-lab/zend"をリポジトリに追加しています。

そして、下記のように"/etc/gitweb.conf"にプロジェクトのディレクトリを指定します。
--------【/etc/gitweb.conf】--------
...
our $projectroot = "/home/suz-lab";
...
--------

これで下記のようなURLにアクセスすることで、
"git"のリポジトリを確認することができます。
http://xxx.xxx.xxx.xxx/git/

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

ELBのIPアドレスを逆引きしてみると

スズキです。

ELBのIPアドレスを逆引きしてみると、下記のようになります。

my-load-balancer-xxxxxxxxxx.ap-southeast-1.elb.amazonaws.com

xxx.xxx.xxx.xxx

ec2-xxx-xxx-xxx-xxx.ap-southeast-1.compute.amazonaws.com

もしかしたら、ELBの実態はEC2なのかもしれません。
--------
http://www.suz-lab.com

ELBの"SSL Termination"を利用

スズキです。

久しぶりのクイックレビュー(cloudpack)です。

今回も全然クイックではありませんが、近頃、ELBのSSLまわりやっているので、
"SSL Termination"機能の利用方法です。

まずは、いつもと同様に"AWS Management Console"にて、ELBを追加します。
そのときに、下記のように、
Secure HTTP Server / HTTPS (Secure HTTP)
を選択します。
※今回はELBの443番ポートをEC2の80番ポートに転送するようになっています。


選択したら、右側のSaveボタンをすると下記のようになるので、
そのままContinueボタンで次に進みます。


すると、以下のように、証明書の入力画面になるので、キーと証明書を入力して、
Continueボタンで次に進みます。


そして、いつも通りのヘルスチェック関係の設定になり、


ELBにぶら下がるEC2インスタンスを選択して、


確認したら、



下記画面で、SSL Termination"機能をもったELBが作成されます。


HTTPSでELBにアクセスすると、ELBからはEC2にHTTPでアクセスされるので、
EC2側でHTTPSでアクセスされたものかどうか確認したい場合は、
こちらで紹介したようにHTTPヘッダをチェックする必要があります。

--------

"phpinfo()"でタイムゾーン関係のWarning

スズキです。

"phpinfo()"を実行すると、Apacheのエラーログに
下記のようなWarningが出力されることがあります。

--------
PHP Warning: phpinfo():
It is not safe to rely on the system's timezone settings.
You are *required* to use the date.timezone setting or the
date_default_timezone_set() function.
In case you used any of those methods and you are still getting this warning,
you most likely misspelled the timezone identifier.
We selected 'Asia/Tokyo' for 'JST/9.0/no DST' instead in
/home/suz-lab/zend/public/phpinfo.php on line 1
--------

PHP用にタイムゾーンを設定しろ!、ということなので、
"/etc/php.ini"を下記のようにすることで、Warningが出力されないようになります。

--------【/etc/php.ini】--------
...
[Date]
date.timezone = Asia/Tokyo
...
--------

ブログ書くペースが戻ってきたかも…
--------
http://www.suz-lab.com

ELBの"SSL Termination"を利用したときのHTTPヘッダ

スズキです。

ELBの"SSL Termination"経由でアクセスすると、
EC2のプログラム側には、下記のヘッダがつくようになります。

X-Forwarded-For: xxx.xxx.xxx.xxx
X-Forwarded-Port: 443
X-Forwarded-Proto: https

EC2にはHTTP(80番ポート)でアクセスされるので、
HTTPSでのアクセスかどうか確認するには、上記のヘッダをチェックする必要があります。
※上記ポート番号(443や80)は、変更することもできます。
--------
http://www.suz-lab.com

sudoで/etc/init.d/httpdをパスワード無しに実行

スズキです。

Webアプリ開発用AMI作成中につき…

まずは、インストールです。
# yum install sudo

次に、設定を下記のように編集します。
# visudo
--------
...
suz-lab ALL=(root) NOPASSWD: /etc/init.d/httpd
--------

そして、対象ユーザーにスイッチです。
# su - suz-lab

最後に、sudoで/etc/init.d/httpdを実行します。
$ sudo /etc/init.d/httpd restart

無事、実行出来れば、完了です。
--------
http://www.suz-lab.com

2011年1月11日火曜日

"FileETag None"でETagを消す(Apache)

スズキです。

HTTPレスポンスのETagにinode情報が含まれているとよくないという
セキュリティのチェックポイントがあります。

その対策として、ETag自体を出力しない方法です。
(Apache 2.2.x です)

まず、デフォルト状態のレスポンスはこんな感じで
ETagが含まれています。

# telnet localhost 80
--------
Trying 127.0.0.1...
Connected to localhost.
Escape character is '^]'.
GET /test.txt HTTP/1.1
Host: localhost
HTTP/1.1 200 OK
Date: Tue, 11 Jan 2011 01:27:59 GMT
Server: Apache/2.2.3 (CentOS)
Last-Modified: Tue, 11 Jan 2011 01:27:01 GMT
ETag: "cc068-5-fb348340"
Accept-Ranges: bytes
Content-Length: 5
Connection: close
Content-Type: text/plain; charset=UTF-8
test
Connection closed by foreign host.
--------

ETagを消すには、httpd.confに下記を記述します。
--------【httpd.conf】--------
...
FileETag None
--------

するとHTTPレスポンスが以下のようになり、
ETagが消えていることがわかります。

# telnet localhost 80
--------
Trying 127.0.0.1...
Connected to localhost.
Escape character is '^]'.
GET /test.txt HTTP/1.1
Host:localhost
HTTP/1.1 200 OK
Date: Tue, 11 Jan 2011 01:37:10 GMT
Server: Apache/2.2.3 (CentOS)
Last-Modified: Tue, 11 Jan 2011 01:27:01 GMT
Accept-Ranges: bytes
Content-Length: 5
Connection: close
Content-Type: text/plain; charset=UTF-8
test
Connection closed by foreign host.
--------

セキュリティを意識したApacheの設定は、一旦、まとめておこう。
--------
http://www.suz-lab.com