ただつらつらと日記が書かれていくようです。
EC2のインスタンスって、デフォルトではNTPサーバについてはntp.orgのサーバがいくつか設定されていて、時刻を同期しようとするとインターネットへのアクセスが必要になっていた。まぁ、たいした通信量じゃないからいいんだけどさ…と思ってたら、re:Invent 2017で「Amazon Time Sync Service」が発表された。
端的には、EC2のNTPクライアント(chronydとか)で以下のIPアドレスにアクセスするように設定すればNTPサーバに同期できるらしい。
169.254.169.123
実際にやってみたら、Stratumは3。でも、ネットワーク的には近いところにあるようで(…って、リンクローカルアドレスだから当然か)他のNTPサーバを設定してあっても、NTPクライアントはAmazon Time Sync ServiceのIPアドレスを同期に使用していた。
C5とM5インスタンスではまだ使えないみたいではあるけれど、これはこれで便利かも(さくらインターネットは、かなり前からNTPサーバが用意してあったけども)
PHPmailerから、TLS対応のSMTPサーバにTLSで接続して、SMTP認証してメールを送信しようとしたら、PHPmailerがSMTPサーバへの接続でコケてエラーを吐いていた。
んで、SMTPサーバ側のpostfixのログを確認すると見慣れないエラーが出ていた。
warning: TLS library problem: 855:error:14094418:SSL routines:ssl3_read_bytes:tlsv1 alert unknown ca:s3_pkt.c:1493:SSL alert number 48:
どうやら、TLSのコネクションを張る際のエラーのようだった。ま、何かTLSにまつわるエラー(証明書とか接続先の確認とか)だろうって、とりあえずTLSで接続する際に、
$mail = new PHPMailer();
$mail->SMTPOptions = array(
'ssl' => array(
'verify_peer' => false,
'verify_peer_name' => false,
)
);
を使って、接続先の確認を省略するようにすると、無事にメールを送信できるようになったのだが、やっぱり、なんだか気持ち悪い。
ってことで、いろいろと調べてみたら、原因はPostfixに設定してあったSSL証明書に中間証明書を付けてなかったことだった。つまり、中間CAの証明書がないせいで、クライアントが持っているrootCAの証明書と、postfixにインストールしてある証明書が証明書チェーンでつながらなかったために発生していたエラーのようだった。…そういえば、先日、SSL証明書を入れ替えたときに、買ってきた証明書をそのままインストールしたような気がする…。あー、しまった。
…というわけで、postfixが読み込んでいる証明書をnginxと同じやりかたで、サーバ証明書と中間CAの証明書を1つのファイルにしてPostfixを再起動してみると、phpmailerから普通にTLSで接続してメールを投げることができた。
今回は自分でイジれるSMTPサーバだったから、証明書を入れ替え直して問題を解決したが、もし、中間CAの証明書を含んだ証明書に簡単に入れ替え直してもらえないようなMTPサーバを使わなきゃいけない場合は、前述のとおり、$mail->SMTPOptionsでpeerの確認を省略すれば送れるようにはなるけれど、一連のTLSの仕組みの重要な部分が確認できてない形で暗号化することになることは覚えておいた方がいいだろう。
Googleで「スピードテスト」を検索したら、いつの間にかGoogleがネットワークの帯域幅を測定する機能を実装していたようで。GoogleとMeasurement Lab（M-Lab）の提携で実現しているようだ。40MB程度のようだけど、ある程度のサイズのデータをサーバーとやりとりして計測するのは、他の計測サービスと同じのようだ。ま、他のサービスだと、flashが必須だったりするけど、このGoogleのサービスはflash不要らしい。手軽に計れていいな、と。
そういえば、半年前くらいに、ドコモの投げ売りでNexus5Xを648円で買ってみた。…で、ふと思い立って、先日、SIMロックを解除してみた。そもそも、SIMロックを外してみたものの、mineoのドコモプランのSIMを刺しっぱなしにしていて、折角、SIMロックを外したのに、なんか意味ないなーと思い、mineoのauプラン(VoLTEなSIM)のSIMを刺してみた。
Nexus5XのOSをAndroid O(えーと、確か、Oreoか)にしてあって、ちゃんと動くかなーと思ったけど、普通にLTEで通信できるし、テザリングもできた。今のところは、セルスタンバイ問題も発生しないみたいし、なかなか良好。…うん、それだけ(笑)
nginxのログを眺めていたら、GooglebotとウチのサーバとのTLSの暗号方式に「ECDHE-RSA-CHACHA20-POLY1305」を使ったみたいだった。記憶が怪しいけれど、ChromeではChaCha20-Poly1305を使えるようになっていたけれど、googlebotはまだ対応してなかったような気がしていたんだけどな。
WordPressの記事にGoogleMapを簡単に埋め込めるようにしてくれる、「MapPress Easy Google Maps」っていうプラグインがある。記事の編集画面の下側でボタンを押して、プロットしたいところの住所や名前を入れるとジオコーディングしてくれる機能もあったりして、まぁまぁ便利で使っていたんだけども。
このブログを始めとして、いくつかWordPressで構築してあるブログを運用しているが、その「MapPress Easy Google Maps」をインストールしてあって、普通に地図のプロットができるWordPressと、地図を編集しようとするとプロット地点の名称が保存できないWordPressがあって、ぱっと見で原因が分からなかった。
仕方ないからブラウザの開発ツールでエラーが出ていないか調べて見ると、tinymceが読み込まれていないエラー(Reference Error: tinyMCE is not defined)が出ているのを発見。tinymceというと、ビジュアルエディターで使われているモジュールのはず。その線で、2つのWordPressにインストールされているプラグインなどの差異を調べてみたが差異は発見されず…。
で、ブラウザを2つ起動して、「MapPress Easy Google Maps」がちゃんと動くWordPressと、動かないWordPressを見比べていたら、「MapPress Easy Google Maps」がちゃんと動いているWordPressでは、記事の編集画面のタイトルの下、本文を入力するtextareaの右上に「ビジュアル」「テキスト」と表示されていて切り替えることができたが、動かない方は、その切替用のリンクが存在していなかった。
確か、WordPressのどこかでビジュアルエディターを使う、使わないの設定を持っていたような…と思ったが、思い出せずテキトーにググってみたら、ユーザーのプロフィールで持っている設定(「ビジュアルリッチエディターを使用しない」)であることが判明。というわけで、動かない方のWordPressでビジュアルリッチエディターに関する設定をいじってみたら、難なく地図を編集できるようになった。地図のプロットの編集画面、よーくみるとTinyMCEをロードしてた。
まぁ、普通、こんな設定をいじらないんだろうけれど、一応、「MapPress Easy Google Maps」はこの設定に依存してましたってことで。プラグインの詳細ページのFAQの”Map Won’t Save”欄には、こんな感じで書かれていて、開発者の方もビジュアルリッチエディターの設定をいじっているケースは想定してなさそうなことがわかる。
This is caused by errors in another plugin or the theme. Disable all plugins and switch to a standard theme (for a moment). If you now see your map, re-activate until you find the problem.
ま、普通はいじらないもんなぁ…(てか、なんでいじってあったんだろう…)
AWSの管理コンソールにアクセスしようとしたら、なんか違和感があった。なんだろうなぁ…と思って、よーく見てみるとAWSのロゴが変わってるようだった。
以前のロゴは、ブロックを積んであるようなデザインの前面に「Amazon Web Services」って書いてあった感じだが、新しいロゴはAmazon
のロゴの下にある、スウォッシュマークのような矢印の上に「AWS」の文字が配置されているようなもの。AWSと略した状態で、十分に市民権を得たってことなんだろうな。新しいロゴは、なんかかわいいような気もするが、どっちかというと前のロゴの方がしっくりくるような気がしたりしなかったり…ま、要するに慣れってことかもしれない。
なぜか、Amazon LiunxのデフォルトのMTAはSendmail。ま、ベースとなっているRHELのデフォルトのMTAがSendmailだからなんだろうな、いやはや。最近はPostfixしか使っていないので、AmazonLinuxでサーバを構築する際は、まずはsendmailをアンインストールして、Postfixに入れ替えるという作業を行うことになる。
AmazonLinuxのサーバをオフィシャルなAMIから構築する場合には、sudo yum remove sendmailでsendmailをアンインストールして、sudo yum install postfixすれば、MTAの交換ができてしまうのだが、sendmailに依存するパッケージに「crontabs.noarch」があったりするのがちょっと…。ま、postfixを入れた後、再インストールすればいいわけだけど、うっかりわすれるとcronが動かなかったりする。「このサーバではログのローテーションが実行されないなー、不思議だなー」とか思っていると、MTA入れ替え後の「crontabs.noarch」の再インストールを忘れているってことがある(遠い目)
…で、こちらの記事「yumで複雑に依存しあった複数のパッケージを入れ替える」によると、yumはsendmailのアンインストールとpostfixのインストールを1つのトランザクションとして依存性を解決することができるらしい。
まずは、yumのシェルを起動。削除したいものとインストールしたいものを指定。その後、依存性の解決を行った後、で、そのトランザクションを実行という流れらしい。
sudo yum shell
remove (パッケージ名)
install (パッケージ名)
transaction solve
transaction run
試しに、sendmailをremoveして、postfixをinstallしてトランザクションの依存性を解決してみたが、sendmailに依存しているcrontabsなどは削除されることなく、そっとsendmailがアンインストールされ、postfixが必要とするmysql55-libとspostgresql92-libsと一緒にpostfixがインストールされた。
…って、これはAmazonLinuxに限ったことではなく、yumが使えるRHEL系のLinuxなら同じ事ができますね、はい。
zabbix-proxyをrpmでインストールした際に、zabbix-proxy用のMySQLにテーブルを作るためのSQLがいつもどこに置かれているのか分からなくなる。もう少し、proxyをインストールする機会があればいいけれど、そうもいかない。
というわけで、備忘のためにメモ。インストールした環境はAmazonLinux 2017.03。
/usr/share/doc/zabbix-proxy-mysql-2.2.18/create
…あ、そういえば、そろそろzabbixのバージョンも上げなきゃなぁ…。
EC2のインスタンスを起動するときに、VPCで既に設定してあるNICを使って起動しようとすると、ちょっと前は、そんなNICにもpublic IPが割り当てられてたような気がするんだけど…。さっき、既存のNICを使って起動としたら、以下のようなメッセージが出てきた。
We can no longer assign a public IP address to your instance
The auto-assign public IP address feature for this instance is disabled because you have selected an existing network interface for eth0. Public IPs can only be assigned to new network interfaces for eth0. To re-enable the auto-assign public IP address feature, please select a new network interface for eth0.
既存のNICはVPCのIPアドレスを固定するものだったので、それはそれとして割り当てて、public IPアドレスを付けたい場合は素直にElastic IPを使えってことだろうか。
追記：
ENIのNICを使うとPublic IPが割り当てられずに「…なんでだろう…」と悩み続けていた。VPCの「Auto-assign Public IP」もYesに変更したのになぁ…。で、仕方ないからNATインスタンスでも立てるかと思って、t2.microインスタンスを立ててiptablesの設定もして…最後にVPCの「Route Tables」を更新してインスタンスを起動してみると、Public IPが割り当てられた状態で起動してきた。結局、WebからのVPCの設定変更では変更が反映されなくて、「Auto-assign Public IP」がnoのままで、「Route Tables」を変更したタイミングで「Auto-assign Public IP」がYesに変わったような…なんか妙な感じしかしないけど、とりあえずPublic IPが割り当てられた…。んで、NATインスタンスを落として、VPCの「Route Tables」を元に戻した。
© 2024 ただのにっき。
Theme by Anders Noren — 上へ ↑