Dockerは現時点(1.9)では複数のネットワークインタフェースをうまく扱うことができない

どうやら、Dockerはデフォルトのネットワークインタフェース間でしか通信を行うことができないらしい。

例えば、eth0とeth1と２つのネットワークインタフェースを持つような構成になっている場合に、コンテナはeth1との通信が一切できない。

このブログに理由と解決方法が載っていた。

http://williamsbdev.com/posts/docker-connection-marking/

パケットがdocker0を通る前にパケットにfwmarkという印を付けることでちゃんとルーティングされるようにするらしい。

ちょっときもい。

Android端末からHTTPSに繋ぐとセキュリティエラーになる問題の対処

まれにAndroid端末に対応していないSSL証明書もあるらしいが、おそらくほとんどは中間証明書のインストールをミスっているだけだと思う。

SSL証明書の公開鍵証明書には証明書本体だけでなく中間証明書を追加すること。

中間証明書は公開鍵証明書の発行元が登録完了後にメールに添付してくるか、発行元サイトなどで公開されている。

サーバーの設定

秘密鍵

自分で作成した秘密鍵を設定

こんな感じになる：

-----BEGIN RSA PRIVATE KEY-----
～
-----END RSA PRIVATE KEY-----

公開鍵証明書

送られてきた証明書と中間証明書を結合したファイル。

こんな感じになる：

-----BEGIN CERTIFICATE-----
～公開鍵証明書
-----END CERTIFICATE-----
-----BEGIN CERTIFICATE-----
～中間証明書
-----END CERTIFICATE-----

クラウド時代のプログラマについて考えたみた。

クラウド時代のプログラマについて考えたみた。

オンデマンドインスタンス型プログラマ

オンデマンドインスタンス型のプログラマは時間単位の報酬で作業を受ける。
プログラマに作業依頼にするには、ウェブコンソールから「インスタンスの作成」を行う。
ここで様々な種類のプログラマから作業内容にあったインスタンスタイプを選ぶことができる。
インスタンスタイプについては後述する。

スポットインスタンス型のプログラマ

プログラマはもしも定時にあがることができたなら家で少しだけ作業ができる。
強調しておくが、”もしも” 定時にあがれたらだ。
この空いた時間帯に副業として作業を依頼する分には少しだけ安く作業を請け負うことができる。

リザーブドインスタンス

もしプログラマに長期的に作業をしてもらいたい場合は、リザーブドインスタンスがお得だ。
あらかじめ年間に一定以上の作業を依頼する約束をすることで、安く作業を請け負ってもらうことができる。
ただし、もし約束しただけの作業を依頼できなかった場合でも、同等の報酬は払わなければならない。

インスタンスタイプ

プログラマにもタイプが存在し、作業に応じて向き不向きがある。
このため、クライアント様においては、作業内容に応じて適切なプログラマのインスタンスタイプを選ぶことが重要だ。

m4インスタンス

m4インスタンスは汎用的に使えるプログラマインスタンスタイプだ。特にこれに対して強いというものはないが
大抵のことをそれなりな感じにこなしてくれる。
どのインスタンスタイプを選べば分からない場合はとりあえずこれを選んでおけばいい。

c4インスタンス

とにかく特定の作業を早くこなしてもらいたい場合はこのインスタンスを使う。
ただし、このインスタンスタイプのプログラマはたくさんのことを覚えたり、たくさんのことを同時に行うのは苦手だ。

r3インスタンス

c4とは反対に、色んなことを同時にさせたり、記憶力の良いプログラマを所望する場合はこのインスタンスだ。

まとめ

冗談はさておき、実際もっと短いスパンで色んな仕事をこなすというのも面白いきはする。

MacでJavaの起動が遅い原因はアンチウイルスソフトだった

MacでJavaの起動がすごく遅いことに気づいた。
Javaのアプリケーションが重いのではなく、JavaのJVMそのものの起動が遅い。
java -version するだけでも10秒ほどかかった。

原因はアンチウイルスソフトだった。
リアルタイム保護機能が効いており、JVMを起動時にチェックしていたようだ。
私の場合はFortiClientというアンチウイルスソフトを使っていたが、これのリアルタイム保護を無効にすることでちゃんと１〜２秒で起動してくれるようになった。

ChromeのPush APIで「This site has been update in the background」という通知が表示される原因

「This site has been update in the background」はPUSH通知が来たが表示するメッセージがなかった場合に表示されるデフォルトのメッセージだ。
pushイベント内で showNotification() が確実に実行されるようにすることで、このメッセージを回避できるようになる。

evt.waitUntil() に渡すPromise内でshowNotification()することになるが、ちゃんと各箇所でPromiseをreturnしているか確認する必要がある。

私はfetch()のPromiseをリターンしていなかったためにこのメッセージ表示されており相当な時間ハマってしまった。

Amazon SESのTXTレコード設定、Value-Domain版

Amazon SESではドメインの認証をすることで、そのドメインからのメール送信ができるようになる。
ドメインの認証をするにはSESに指定された値をDNSのTXTレコードに設定する必要がある。

下記のように設定しなさい、と指示されるがValue-Domainの管理画面から設定する場合はどうするのか？
Name: _amazonses.example.com
Type: TXT
Value: <認証コード>

結論。

TXT _amazonses.example.com <認証コード>

で、認証が通りました。

SPFの設定だと v=～～ ~all とか書式があるから、なにかそういう書式が必要なのかと思って迷いました。
DNSは苦手です。

さくらのメールを使おうとしたら「550 5.7.1 Command rejected」と言われてメールを送信できなかった。vultrのせいだった。

さくらのメールボックスを借りてPEAR::Mailでメールを送信しようとしたところ、メールが送信できず困った。
PEAR::MailはMail::factoryの第２引数に渡すパラメーターで 'debug' => true を設定することでSMTPのやりとりを出力してくれる。
これでやりとりを見てみると Authentication OK という文字が見えることから、認証は成功しているようだが、そのあとすぐに「550 5.7.1 Command rejected」というメッセージがでて接続が切れていた。
なんとも不可解な動作にずっと悩んでいたが、どうもvultrというクラウドを使っていたことが原因のようだった。

こちらのブログを見つけられなかったらずっと悩んでいたかもしれない。感謝。

Vultrからメールが送れないのでSendGridを使う

このブログのリンク先の公式サイトにて、下記のメッセージを確認。

Do you allow outbound SMTP?
Outbound SMTP is blocked by default. To lift this restriction, you must contact our support team and fill out an authorization form.

しかし認証までうまくいくのは何故なのか謎すぎる。接続もできない状態であればすぐ気づいたのだけど。。。

解決策としては、やはりクラウドサービスを利用することにした。AWSは使い慣れているのでAWSのSESを使うことにした。EC2以外から使う場合は無料枠がないようなのでちょっと微妙だけれどほとんどメールなんて飛ばないだろうからいいやという判断。