使い捨てメールアドレス発行サービス作りました
1セッションで最大6個までメールアドレスをワンクリックで発行できます。
メールアドレスは作成から2日間利用可能で、5MBまでのメールを受信できます。
途中だるくなったり設定うまくいかなったりで制作期間2ヶ月くらいという感じです。
フロントはnginx + unicorn(Rails)でバックのメールサーバにはPostfixとDovecot使いました。他にはmysql, debianで。
サーバはさくらのVPSで、 デプロイはcapistranoであるあるな構成です。
あと、ブログを引っ越しました。以降は http://blog.jiikko.com/ で書いていきます。
http://blog.jiikko.com/
最近, Lokka => はてブロ に移動する人がちらほら見るのですが今回は逆パターンです。
自分でCMSをホストするとなると画像のアップロードどうしようか考えてます。全部base64エンコードして本文に含めたらポータビリティとか思ったり。
デプロイツール
capistrano、ロールバックできるし一通りシムボリックリンク貼ってくれたりでだいたいのことはカバーしてれくるので導入コストはかかるが便利なんだけど、
railsをデプロイするために必要な周辺gemの調査が毎度めんどい。
思えばcapstrano2 => 3の時もめんどかった。cap2系はrailsにフォーカスして作られていたので必須gemほとんどなかったんだけど,
3系からrvm, bundlerあたりが別のgemに切りだされて、railsアプリをデプロイするにはcapistrano-rvm, capistrano-bundlerあたりが必要になった気がする。
それで、半年ぶり新しいcapを使おうと思ったらrvm周りのgemが謎な名前になってるじゃん。
https://github.com/rvm/rvm-capistrano https://github.com/rvm/rvm1-capistrano3
READMEに書いていた。
rvm-capistrano 1.3.0 with Autolibs requires at least RVM 1.19.0. capistrano 3.0.0 is a rewrite and does not work with this gem, use rvm1/capistrano3 it will be extended to match this gem functionality.
代謝するものだし仕方ないのかなと思いつつ、古いバージョンを使うのも嫌なので仕方なく今のcapistranoについて調べているところ。
まとめ
capistarano捨てて自家製秘伝のタレshellスクリプトでデプロイしよう！
μTRONキーボード買った感想
エルゴノミクスキーボードはMicroSoftのを半年くらい使っていてようやく気持ちよく使えるようになったところだったんだけど、値段が安いせいか割りとちゃんと押さないと判定されなかったり、EnterKeyが遠いし全体的にでかい。そしてESCキーの打刻感が最悪。
emacsキーバインドを常時マッピングしているので致命的にやばいって訳ではないんだけど若干ストレスなので、このキーボードにロックインされるのは不憫だと思っていた。
最近腱鞘炎というか手の甲が火を噴いてきたのでμTRONキーボードを買った。とりあえず糞高い。
使ってみてMenu、Alt、半角/全角が一番左に密集していたり、スペースとかTABの位置がぶっ飛んでいる場所にあるし、
左4列目がキー1つ分左に流れているのでとんでもないものを買ってしまった感がある。
だがしかしリマップしまくってなんとか自我を保っています。
Macのキーボードユーティリティのkarabinar でリマップしました。
↓リマップのprivate.xmlです。デバイスIDを指定してこのキーボードのみリマップするようにしています。
https://gist.github.com/jiikko/984be9bdd76d839332ae
現時点で言えることはkarabinar便利です。
これ書きながら思ったのだけどオフィス用と自宅用をおくなら、コスト的な意味でキネシスの左右分離でよかったんじゃねえの。
http://www.edikun.co.jp/kinesis/freestyle.htm
なお、このテキストはApple純正キーボードで書いています。
postfixとdovecot-lmtpを同じホストで使う意味ある？
メールボックスサーバが別のホストならわかるけど、同一だった場合意味あるのか？と思った。
タイトルの構成にするメリット
postfix vdaパッチなしでmaildir quotaを実現できる
新しいpostfixのバージョンにはvdaパッチがバグるとかありそうなので、パッチなし環境というのは少なくとも安定してると言えそう。
パフォーマンスがいい
postfix がメールボックスへの配送した場合、配送とquotaの処理をpostfixすることになるのでキューが詰まる、ということが起きるんじゃないかな。
その点、メールボックスの配送とquotaをdovecot-lmtpに任せた場合、上の仕事からpostffixのプロセスが開放されるのでより多くのメールを処理できる、ってことになるはず。
パフォーマンスあたりについて下記記事が言及してた。
http://ya.maya.st/d/201103c.html
_ dovecot は IMAP/POP サーバなので、メールボックスの扱いかたを知っている。どのユーザのメールボックスがどの場所に置いてあるかとか、mbox なのか Maildir なのかとか。もちろん postfix 側でもそれは設定することができるけど、dovecot と完全に同じ設定になっていなければならず、そのへんをチェックするのはめんどくさい。メールボックスへのアクセスを dovecot に一元化してしまえばそんなの気にしなくてもよくなる。
_ メールボックスに格納されるのは mbox だの Maildir だのといった形式的なものだけでなく、フォルダにどんなメールがあるかとかどのメールが未読でどれが既読かといった情報も含まれる。LDA/LMTP でローカル配送をおこなうと、配送が完了した時点でこのインデックスの更新もおこなわれる。MTA の LDA や procmail などの汎用品で配送する場合、インデックスの更新はログインしてメールボックスにアクセスしたときにおこなわれることになるが、前回ログアウト時からの差分が大きいとこの時間が馬鹿にならず、ひじょーに重く感じることになる。ローカル配送を LDA/LMTP でおこなうと IMAP が軽くなる。
_ ということで、dovecot の LDA/LMTP を使うことにはたくさんのメリットがありデメリットがない。もちろん、これは POP/IMAP サーバが dovecot ではなく cyrus などでも同じことがいえる。IMAP サーバに LDA/LMTP の機能があるならば MTA のものを使わずそっちを使うべき。
_ LDA と LMTP のどちらを使うか。LMTP は並列配送度を上げられるので大量のメールが届く環境ではかなり高速化できるかもしれないとか、LMTP は TCP で listen することもできるのでメールを受けるホストとメールボックスを置くホストを物理的に分離することが容易になるとか、LDA はメール1通ごとにプロセスを起動するけど LMTP はデーモンなのでプロセス起動のオーバーヘッドがないとかいうメリットがあるけど、うちのような小規模なところでは大差ない:-)。
lmtp使いましょう！！
手元の仮想環境で自分自身にメール送り、virtual Mailboxのメールボックスへの配送 と .forwardを発火させる
/etc/postfix/main.cf
mydestination = localhost, jiikko.com, prpr-antena.com transport_maps = hash:/home/koji/sites/mail_admin/config/server/local/transport
transport
jiikko.com lmtp:unix:private/dovecot-lmtp prpr-antena.com lmtp:unix:private/dovecot-lmtp
普通はドメイン毎でリレー先を変更するときに使うっぽい。
virtual_alias_maps には、以下のような結果が帰ってくるようにsql書いてる。
1436680161@prpr-antena.com: deployer@localhost, 1436680161@prpr-antena.com
mydestination にテスト用のドメイン を明記しているので、Virtual Mailboxのメールアドレスに(コマンドラインから)メールを送ると、local配送からの.forward発火とVirtual Mailboxへの配送ができてる。
(本番とmain.cfが微妙が違うけど)プロダクションコードが開発環境と本番環境の両方で動く状態になった。ここまでが長かった(´・ω・`)
rails nginx x-sendfile
rails4.2.0
http://wiki.nginx.org/NginxXSendfile
x-sendfileは、Railsのみで静的ファイルのアクセスコントロールとかをしたい時に使うといいみたい。
今回は、unicornワーカーが 少ない環境なのでワーカー確保のために使った。
コード
controller
send_fileメソッドでヘッダーに追加してくれるみたいなので、このままでOK。
# filepathは絶対パスになってる def show send_file(filepath, filename: file_name) end
config/environments/production.rb
以下をアンコメントするだけでOK。
config.action_dispatch.x_sendfile_header = 'X-Accel-Redirect' # for nginx
nginx.conf
location ~ ^/system/(.*) {
internal;
}
location / {
proxy_set_header X-Sendfile-Type X-Accel-Redirect; # いらないかも
proxy_set_header X-Accel-Mapping /var/www/rails_app_name/current/public/=/;
proxy_pass http://momiji;
}X-Accel-Redirectヘッダーに入ってくる値はファイルパスになっていてsend_fileと同じパスが入ってる。nginxのドキュメントルートと違うので修正が必要。
その修正というは、X-Accel-Mappingヘッダーでやっている。
ダメな例
controller
def show response.headers['X-Accel-Redirect'] = "/system/hoge.jpg" # nginxドキュメントルートからのパス send_file(filepath, filename: file_name) # filepathはファイルシステムのルートからのパス end
nginx
location ~ ^/system/(.*) {
internal;
}
location / {
proxy_set_header X-Sendfile-Type X-Accel-Redirect; # いらないかも
proxy_pass http://momiji;
}手動でヘッダーを追加しているパターン。
これだとX-Accel-Mapping が必要なくなるし一応動くのだけど、ログに`"X-Accel-Mapping header missing"`と出力されてしまうのでダメッポイ。
https://github.com/rack/rack/blob/b698f84e633426c208623282988bab0d2ac45931/lib/rack/sendfile.rb#L124
以上。
