あのAmazonより以下のようなメールが突然届いた。
xxxx(xxxx)様
拝啓
平素は格別のお引き立てにあずかり、
ありがたく厚くお礼申しあげます。この度は 1月度ご請求の代金を本来であれば3月末日迄にお支払いすべきところ、入金が遅れてしまい誠に申し訳ございません。当社システム不具合のためこのような結果となりましたが、現在緊急でこのシステム不具合の解消を行っております。現時点で明確なお支払日をご案内差し上げる事ができないのですが、不具合解消でき次第大至急お支払処理をさせて頂きますので、何卒お待ちくださいますようお願い申しあげます。
略儀ではございますが、取り急ぎ書面 にてお詫び申し上げます。
敬具
Amazonアソシエイト・プログラム
別にたいした金額ではないので、どうでもいいのだが、ちょっと面白かった。
ちなみに、和歌山県の串本町に引っ越しました。
さりげなく、ご報告。
できるのは、わかってたんですけど、一応テストしたのでご紹介を。
.htaccessに以下のような内容を記述して、FlashやAjaxのクロスドメイン制約を回避できるかどうかをテストした。
RewriteEngine on RewriteRule ^uploads/(.*) http://xxxx.s3.amazonaws.com/$1 [P]
結果は良好。
期待通りに外部サーバのswfやXMLを読み込むことができました。。
予想通り、若干重かったのですがCloudFrontとmod_cacheを組み合わせればこの部分は改善できそうです。
CloudFrontを使うには、２行目のURLをxxxxx.croudfront.netのように書き換えればOKです。
S3では認証パラメータをURLに渡すこともできるようなので、もしかしたらそうした方がいいのかもしれない。
Amazon S3では、HTTPエラーはXMLがかえされるので、これは表示したくない。
ProxyErrorOverride On
httpd.confに上記の記述を入れたら、解決できた。
以下のような内容をhttpd.confに追加した。
<VirtualHost>
--中略--
CacheRoot /path/to/cache
CacheIgnoreCacheControl On
CacheEnable disk /uploads/
CacheMinFileSize 0
CacheMaxFileSize 64000
CacheDirLevels 5
CacheDirLength 3
--中略--
</VirtualHost>
/path/to/cache内をのぞいたら意味不明なディレクトリができていたので、成功した模様。
詳細は後日確認する。
ちなみに、テストしたサーバーはmod_ruidを導入しているので、このキャッシュのオーナーもそこで指定したユーザーになっていた。（これ、本当におすすめです。）
この方法の最大のメリットは、初期費用をかけることなく、ほぼ無制限に大容量の信頼性の高いストレージが入手できたことです。
ブログなどのサービスを立ち上げる場合に、どうしてもストレージまわりにコストがかかってしまいます。
バックアップの心配も容量の心配もしなくていい時代がこんなに早くくるなんて。。。
Amazon EC2上のサーバーにMRTGをインストールしようかどうか迷っていたら、CloudWatchというサービスがあるのに気がついてしまいました。（おそっ）
このサービスはEC2インスタンスのCPU負荷やディスクIO、ネットワーク使用量などをXMLなどのデータで返してくれるコマンドで、かなり柔軟に様々なデータを提供してくれるので、さっそくこのAPIツールで得られた結果を元にグラフを作成するパッケージを作成しました。
CloudWatch APIを使用するために、あらかじめJDKのセットアップが必要だったりして、セットアップは若干めんどくさいのですが、MRTGを構築するよりははるかに簡単だと思います。
このパッケージ内のgchart.class.jsは、XMLデータをGoogle Chart API用のURLに変換する、自分でいうのも何ですがナイスなJavaScriptです。
単品で配布できるほどの汎用性はないのですが、それでもほとんどのGoogle Chart APIの機能はカバーできていますので、ご興味のある方は試してやってください。
気に入っていただいた方からの、ご褒美をお待ちしています。
毎回Google先生に聞いているのでよく使うものの個人的な覚え書き
KeyPairの新規作成
ec2-add-keypair KEY-PAIR | sed -e "1d" > KEY-PAIR.key
KeyPairの削除
ec2-delete-keypair KEY-PAIR
KeyPairの一覧
ec2-describe-keypairs
インスタンスの起動
ec2-run-instances AMI -k KEY-PAIR
インスタンスのリスト
ec2-describe-instances
インスタンスのコンソールを出力
ec2-get-console-output -r INSTANCE
インスタンスをCloudWatchで監視
ec2-monitor-instances INSTANCE
AmazonでCentOSのサーバーを構築する際に、今まではRightScaleさんが作ったイメージを利用していたのですが、やっぱりちょっと気持ちが悪いので、以下のサイトを参考にして自力で構築した。
基本的には上記の手順を踏めば問題なくインストールできたが、ec2-get-console-outputコマンドでコンソールを確認すると以下のようなエラーが出ているのを発見した。
これらのエラーはEC2だけでなくXen上にCentOSを構築する際にも発生するらしい。
*************************************************************** *************************************************************** ** WARNING: Currently emulating unsupported memory accesses ** ** in /lib/tls glibc libraries. The emulation is ** ** slow. To ensure full performance you should ** ** install a 'xen-friendly' (nosegneg) version of ** ** the library, or disable tls support by executing ** ** the following as root: ** ** mv /lib/tls /lib/tls.disabled ** ** Offending process: init (pid=1) ** *************************************************************** ***************************************************************
INIT: Id "2" respawning too fast: disabled for 5 minutes INIT: Id "3" respawning too fast: disabled for 5 minutes INIT: Id "4" respawning too fast: disabled for 5 minutes INIT: Id "5" respawning too fast: disabled for 5 minutes INIT: Id "6" respawning too fast: disabled for 5 minutes
このエラーを要約するとインストールされたglibcがXenに対応していないので対応したものに変えてということらしい。（今回はEC2ですが。。。）
あいにく日本語での対処方法はほとんど見つからなかったが、以下のサイトを参考にしてglibcのソースパッケージを再構築することで、メッセージが出なくなった。
administration:xen:howto:glibc [MathWiki]
作業内容は以下の通り。
以上でエラーが出なくなった。
このエラーについては正直言って意味が分からないのですが、そういものらしいというレベルの理解でよさそうなので。。。（笑）
対策内容は以下の通り。
/etc/inittabの46行目から50行目をコメントアウトする。
# Run gettys in standard runlevels 1:2345:respawn:/sbin/mingetty tty1 #2:2345:respawn:/sbin/mingetty tty2 #3:2345:respawn:/sbin/mingetty tty3 #4:2345:respawn:/sbin/mingetty tty4 #5:2345:respawn:/sbin/mingetty tty5 #6:2345:respawn:/sbin/mingetty tty6
Ec2上でCentOSを構築してもそのままでは停止したときに消えてしまうのでS3にバックアップする必要がある。
S3にバックアップするには、ec2-ami-toolsのインストール及びカーネルモジュールの修正が必要だった。
詳細は割愛しますが、以下のURLを参考にして対処した。
http://developer.amazonwebservices.com/connect/entry.jspa?externalID=798
あーめんどくさかった。。。
決算やら何やらで忙しくって、気がついたら1ヶ月以上このブログの存在を忘れてました。
AmazonのEC2のコマンドラインツールで、以下のようなエラーが出まくって何もできない事態が発生。
Client.InvalidSecurity: Request has expired
原因をネットで調べたらサーバーの時計が狂っているのが原因だった。
ちゃんちゃん。
cronに以下のような記述を登録して解決。
0 * * * * /usr/sbin/ntpdate ntp.jst.mfeed.ad.jp > /dev/null 2>&1
SPFレコードを設定したにもかかわらず、phpからのメールが送れないので、ちょっとイライラしながらエラーメールを確認すると、以下のようなメッセージが届いていた。
Diagnostic-Code: smtp; 550 DY-001 Mail rejected by Windows Live Hotmail for
policy reasons. We generally do not accept email from dynamic IP's as they
are not typically used to deliver unauthenticated SMTP e-mail to an
Internet mail server. http://www.spamhaus.org maintains lists of dynamic
and residential IP addresses. If you are not an email/network admin please
contact your E-mail/Internet Service Provider for help. Email/network
admins, please visit http://postmaster.live.com for email delivery
information and support
要は、spamhausに動的IPとして登録されているので拒否するとのことらしい。
というわけで、登録解除申請を行ったらあっさり解除された。
2時間ほどたってから再度テストすると無事に送信成功。
それにしても、spamhausには、このリスト（PBL）は「ブラックリストじゃない」って、でっかく書いてあるじゃん！
Microsoftさん、そんなの拒否リストに使用しないで！！
参考までにSPFレコードは以下のような感じ。
v=spf1 +ip4:xxx.xxx.xxx.xxx ~all
逆引きアドレスは設定していませんので、「xxxx.compute-1.amazonaws.com」のままですが、それでもメールは送信できるようです。