2016年1月28日木曜日

AWS SESのバウンスメール通知をSNSで受けて、それをSQSと連携させてみた

AWSではSESと呼ばれるメールサービスがあります。Azureで言うところのSendGridみたいな、APIからメールが送れたり、MTAからリレーできたりする便利な奴なんですが、スパムに利用されないように、バウンスメール(ようするに不達で帰ってくるメール)が多いとスパマーと判定されてペナルティを食らうらしい・・・
参考:Amazon SES のバウンスに関するよくある質問

そのための仕組みとして、SESではバウンスメールアドレスを通知する仕組みがあります。
この仕組みを利用して、SNS経由で用意したAPIを叩いてDBの消しこみをする。なんて例が良く出てきます。
たとえばこんなのとか

ただ、当然というか、外部にAPIを晒すという事は、悪戯されたり不正アクセスをされたりするわけで、ちゃんと電子証明書の検証をしないといけない

これはこれで面倒そう・・・・
なので、SNSからさらにSQSを連携させ、バウンスメール処理をキューで処理する仕組みを構築してみました。
キューに貯める事により、複数台のサーバで並列して処理したりできますし、APIを作ったり外部へ晒したりしなくてよいです。

具体的な構築手順は例によってWiKiに記載しています。

今回、あまりAWS SDK for RubyでSQS処理するプログラムを見かけなかったので、作ってみました。
勿論SDKのVer2対応です!!


2016年1月24日日曜日

AWS Certificate Managerを試してみた。

Amazonが無料の証明書サービス、AWS Certificate Managerが発表されたので、早速試してみました。
具体的な取得方法については、例によってWiKiにまとめています。
アスタリスク証明書も取得できるのが地味にうれしいです。

基本的には普通のドメイン認証と同じ手順なのですが、確認するメールアドレスを選択できない。という地味な制限のため、転送設定とかCatchAll的な設定をしていたりするとちょっと悲しいことになります・・・・

まだ始まったばかりのサービスですので、バージニアリージョンしか使えません。
そして、取得した証明書を外部にDLすることは出来ません。
使えるのはELBとCloudFrontなどACMに対応しているもののみとなります。
つまり、EC2に入れて使う。なんてことは出来ません。
また、現在のところ使えるのはバージニアリージョンのみであり、東京リージョンのELBにセットすることは出来ませんでした。
ELBにセットしてアクセスしてみました。ちゃんとAmazonになっています。

証明書の有効期限は1年固定のようですが、自動的に更新されるそうです。
また、証明書の発行自体は無料ですが、CloudFrontにセットしたときの料金は通常通りかかると思います。(未確認ですが、SNI証明書にすれば通信料のみ課金だと思います。)


2016年1月23日土曜日

rsyncがあればlsyncもある。

ロードバランサ配下などで、複数のサーバ間でコンテンツの同期を取りたいときがあります。
いつまでたってもAWSのEFSが東京リージョンにこないし、個人的にNFSには過負荷時の謎の挙動など辛い思い出が多い。
かといって、Cronで定期的にrsyncというのもラグがあるしスマートじゃないなと調べていたところ、
ぴったりな記事を発見

rsyncがあるんだからlsyncがあっても不思議ではないよね。と思いながら、いざ検証しようとするも、lsyncのバージョンが違うので、設定ファイルの記述がそもそも違う。とか実はrsyncやxinetdはいらないんじゃないか?とか色々はまりました・・・

同期の罠については、ここが参考になりました。
また、lsyncの2.1系での設定についてはここが参考になりました。

いきなり双方向同期の設定は理解するのが難しいので、まずは検証ということで片方の同期を例に挙げます。

構成としてはこんな感じです。

サーバOYABUNに加えられた変更(追加や削除、編集など)を検知し、KOBUNサーバに反映させます。
反映させる通信手段としてSSH経由でrsyncかけます。ので、OYABUNとKOBUNの間でSSH接続を許可するのと、KOBUNサーバへ接続する秘密鍵をOYABUNサーバに設置しておきます。
ここまでがKOBUNサーバでやっておくことです。
以下はOYABUNサーバでの作業になります。

まずは、OYABUNサーバにlsyncをインストールします。
yum install --enablerepo=epel lsyncd
次にlsyncの設定をします。
前提条件として、
  • KOBUNへ接続するユーザはwebmaster
  • 秘密鍵はOYABUNサーバの/home/webmaster/.ssh/webmaster_id_rsa
  • 同期するディレクトリは/var/www/html/images/と/var/www/somecontents/の2つ
とします。
/etc/lsync.confに設定がありますので、以下のように設定します。
KOBUNのところは実際はIPアドレスになります。

settings{
        statusFile = "/var/log/lsyncd.status",
        logfile = "/var/log/lsyncd/lsyncd.log",
        nodaemon = false,
        insist = 1,
}
sync {
    default.rsync,
    delay = 0,
    source = "/var/www/html/images/",
    target = "webmaster@KOBUN:/var/www/html/images/",
    delete = 'running',
    rsync = {
        rsh = "/usr/bin/ssh -i /home/webmaster/.ssh/webmaster_id_rsa -o StrictHostKeyChecking=no"
    }
}
sync {
    default.rsync,
    delay = 0,
    source = "/var/www/somecontents/",
    target = "webmaster@KOBUN:/var/www/somecontents/",
    delete = 'running',
    rsync = {
        rsh = "/usr/bin/ssh -i /home/webmaster/.ssh/webmaster_id_rsa -o StrictHostKeyChecking=no"
    }
}
このように、syncのところに複数書くと、複数のディレクトリを監視し、同期を取ることが出来ます。
今回はデーモンで動かしたいので、nodaemonはfalseにしています。
なお、rsync以外にも、S3で同期など色々出来るようです参考
また、設定ファイルの=はちゃんと両端にスペースを入れないと反映されなかったり挙動がおかしくなるので注意です。あとrsyncと同様最後は/で終わらせておくのが無難です。

設定が終わりましたら、起動と自動起動設定をします。
/etc/rc.d/init.d/lsync start
chkconfig lsync on
では、OYABUNサーバの/var/www/somecontentsに何か適当なファイルを作成してみましょう。
ほぼリアルタイムでファイル作成を検知し、rsyncにてKOBUNサーバに反映されます。
この設定をKOBUN側からOYABUN側に設定すれば、双方向同期ができます。
・・・が、2台ならいいですが、3台以上になると、双方向同期はカオスになるので、素直にNFSなりにしましょう。





2016年1月14日木曜日

sendmailでリレーサーバを構築するメモ

AWSなどで、ロードバランサ配下に複数台のサーバを配置し負荷分散と冗長構成をとった場合、はて、メールの送信どうするんだ?と悩んだのでメモ。
AWSに限らず、CentOSなんかで、メール送信をリレーサーバ経由にしたい場合にも使えます。


ロードバランサ配下のサーバにそれぞれEIPというかグローバルIPを割り当ててもいいのですが、
オートスケールをした場合グローバルIPが不定だったりして、SPFどうするんだ?という問題があります。
じゃぁAWSのSESつかうか。という方法が一番いい気がするのですが、バウンスメール処理をちゃんとしないといけないなど、結構手間な感じです。
GmailやSendGridなどをつかうのもいいのですが、手っ取り早く解決するにはメールサーバ用EC2を立てて、そこを中継させてあげればよさそうです。
また、その場合各サーバにはEIPを割り当てなくてもいい(別途SSH接続用踏み台サーバがいりますが)ので、セキュリティ面でもよさそうです。



まずは、メールリレーサーバにするEC2を用意します。
AmazonLinuxでは、デフォルトでSendMailが起動しています。初期設定では自分自身から送信のみできる状態になっています。

まずは、sendmailの設定である、sendmail.cfを作成するためのツールをインストールします。

 yum -y install sendmail-cf m4
次に念のためsendmail.mc及びsendmail.cfのバックアップを取ったうえで、sendmail.mcの設定を以下のように修正します。

dnl DAEMON_OPTIONS(`Port=smtp,Addr=127.0.0.1, Name=MTA')dnl


頭にdnlをつけてこの設定を無効化することにより、よそからのメール転送を許可するようになります。
しかし、このままですと、だれでもこのサーバを踏み台にメールを送れる要するにオープンリレーサーバ状態になりますので、リレーを受け付けるサーバを制限します。
なお、この設定はsendmail.mcに以下の記述がある前提になります。

FEATURE(`access_db',`hash -T<TMPF> -o /etc/mail/access.db')dnl

同じディレクトリ(/etc/mail/)にaccessというファイルがあります。(access.dbではありません)
これに

connect:10.0.0.100 RELAY

のように、リレーを許可するサーバのIPを列挙します。
調べた感じ、10.0.0.0/24のような指定はできないようですが、

connect:10.0.0. RELAY

のような指定はできるようです。

さて、ご存知の通り、sendmailはPostfixなどと違い、設定ファイルをコンパイル(?)しないといけません。

以下のコマンドを実行し、sendmail.cfファイルを作成します。

m4 /etc/mail/sendmail.mc > /etc/sendmail.cf
作成したら、sendmailを再起動させ、設定を有効化します。

/etc/rc.d/init.d/sendmail restart
では、実際にリレーメールサーバにメールを送信し、リレーされることを確認します。
自分はお手軽にrubyでメール送信プログラムを作成しました。


# -*- encoding: utf-8 -*-
require 'mail'
mail = Mail.new
options = { :address => "10.0.0.20", #リレーメールサーバのIP
            :port => 25,
            :authentication => :plain,
            :enable_starttls_auto => true }
mail.charset = "utf-8"
mail.from "test@example.com"
mail.to "hogehoge@gmail.com"
mail.subject "タイトル"
mail.body "本文"
mail.delivery_method(:smtp, options)
mail.deliver

これをリレーする元サーバ、つまりaccessファイルで許可したサーバ内で実行します。
DNSの設定やSPFの設定が正しければ、メールが届いているはずです。
ちゃんと中継されたかはメールのヘッダ情報にリレーメールサーバのIPが記録されているはずですので、そこで確認する事が出来ます。






2016年1月10日日曜日

EdgeOS Touch Meeting ver 0.1に参加してきました。

当日の朝6時過ぎまで検証作業をしつつ、少し仮眠をしたら午前中はLT駆動開発、午後はEdgeOS Touch Meeting ver 0.1に参加してきました。


EdgeOSとは、このところ遊んでいるEdgeRouterで用いられている、VyOSからフォークしたDebianベースのOSです。
今回、広島サーバユーザ友の会(仮称)メンバー3人がEdgeRouterを購入したので、それで遊んでみよう。と集まりました。

自分は以前Vyattaの設定をしたことがあり、今回のお題としてなにをしようかと思案していたところ、OpenVPNというリクエストを頂きましたので、ついでにLDAP連携も試してみました。

本当はちゃんと検証したうえでやりたかったのですが、流石に金曜夜帰宅してから構築、検証は無理がありました(汗
しかも、OpenLDAPに詰まったのでWindowsServerで代用したのはいいのですが、メモリケチってEssentialにした結果余計にハマるという罠が・・・

なんだかんだと当日時間内に構築は出来たのですが、本当は用意するはずだったスライドが全く手がついていなかったので、後日作ったものを乗っけておきます。



2016年1月2日土曜日

新年早々・・・というわけではないのですが。

あけましておめでとうございます。
新年はサーバ切り替えとZabbixのグラフを見ながら自宅待機というのが恒例になりつつあります。

ちなみに初夢はミニマニストになって身の回りのものをザクザク処分し、37歳で人生をリセットするというもので、あまり詳細を書くとドン引きされそうですが、手順書をつくったり記録に残したり細部にこだわってみたりとまぁ自分らしいなぁと。
37才かぁ。あと一年ですね。色々準備しないと。

閑話休題

久々に引っ張り出したゲーミングノートPCが不調で、ざくっと修理したのですが、
ベンチマーク代わりに、数年前にワゴンに投売りしていたゲーム(未開封)をやってみるか。と、
随分前にジャンクで購入したジョイパッドを引っ張り出したのですが、どうも動きがおかしいので、
チェックプログラムで見てみたところ、アナログスティック部分が動作していないことが判明。
なんかいつも何かやる前に修理している気がする・・・

VRがダメになっていたので、分解して洗浄してみました。

ついでに摺動部をマイナスドライバで少し持ち上げて抵抗体に接触するように。
一部抵抗体がすり減ってNGだった以外復活したようです。

アクションゲームは相変わらず全然だめでしたが・・・