Outlook にメールが届かない件対応

概要

EC2を利用してますがSESかまさずに
メール送信をしていた時に
以下のようなエラーが発生しました。

  • エラー内容

Dec 18 17:24:11 ip-xxx-xx-xx-xx postfix/smtp[4827]: 380D2A27ED: to=hogehoge@xxxxxxx.com, relay=xxxxxxx-com.mail.protection.outlook.com[xxx.xx.xx.xxx]:25, delay=6.1, delays=0.01/0/0.88/5.2, dsn=5.7.1, status=bounced (host xxxxxxx-com.mail.protection.outlook.com[xxx.xx.xx.xxx] said: 550 5.7.1 Service unavailable; Client host [yy.yy.yy.yyy] blocked using FBLW15; To request removal from this list please forward this message to delist@messaging.microsoft.com (in reply to RCPT TO command))

要約すると

hogehoge@xxxxxxx.com 宛のメールが Outlook でブラックリスト扱いされて弾かれています ( status=bounced )。
もしブラックリストから削除したい場合は、 delist@messaging.microsoft.com 宛に解除申請してください。

もうちょっと細かく

relay=xxxxxxx-com.mail.protection.outlook.com[xxx.xx.xx.xxx]:25
とある通り
MicroSoftがメールツールサービス Outlook が受信相手です。

送信元サーバIP yy.yy.yy.yyy のホストは FBLW15 基準でブラックリスト扱いされているので
サービスは利用できない = メールは受け取らない
というものです。

  • FBLW15 … MicroSoft独自のブラックリスト

対応

  • 宛先:
1
delist@messaging.microsoft.com
  • タイトル:
1
Please Remove My IP yy.yy.yy.yyy from your BlockList.
  • 内容
    1
    2
    3
    4
    Please remove this IP yy.yy.yy.yyy from your BlockList.

    Thanks.
    Kenzo Tanaka.

数分後に Microsoft Customer Support から返信が着た

  • メール内容
1
2
3
4
5
6
7
8
Hello ,

Thank you for your delisting request SRX1318598611ID. Your ticket was received on (Dec 21 2015 08:14 AM UTC) and will be responded to within 24 hours.

Our team will investigate the address that you have requested to be removed from our blocklist. If for any reason we are not able to remove your address, one of our technical support representatives will respond to you with additional information.

Regards,
Technical Support
  • 和訳すると
1
2
3
4
5
6
7
8
9
10
こんにちは

ブラックリスト申請の削除依頼を受け取りました。24時間以内に回答します。

削除要請頂いたアドレスをについて調査します。
何らかの理由で削除依頼を引き受けられない場合は、
当社の技術サポートから追加情報をお届け致します。

以上宜しくお願い致します。
テクニカルサポート

24時間待ってみる

メール着た!

1
2
3
4
5
6
7
8
9
10
11
Hello,

Thank you for contacting Microsoft Online Services Technical Support. This email is in reference to ticket number, 1318598611 which was opened in regards to your delisting request for yy.yy.yy.yyy

The IP address you submitted has been reviewed and removed from our block lists. Please note that there may be a 1-2 hour delay before this change propagates through our entire system.

We apologize for any inconvenience this may have caused you. As long as our spam filtering systems do not mark a majority of email from the IP address as spam-like, your messages will be allowed to flow as normal through our network. However, should we detect an increase in spam-like activity, the IP address may be re-added to our block list.

Should you have any further questions or concerns, please feel free to respond to this email.

Thank you again for contacting Microsoft Online Services technical support and giving us the opportunity to serve you.
  • 和訳
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
こんにちは

マイクロソフト・オンライン・サービス テクニカルサポートにお問い合わせいただきありがとうございます。
このメールはチケット番号 1318598611、IPアドレス(yy.yy.yy.yyy) をブラックリストから削除する様申請頂いた件についてです。

あなたが提出されたIPアドレスを見直し、ブロックリストから削除しました。
この変更は私たちの全システムに行き届くには 1〜2時間程掛かる見込みです。

ご不便お掛けしたことをお詫び申し上げます。
スパムフィルタリングシステムがスパムとおぼしきIPアドレスからの多くのE-mailをマークしない限り
あなたのメッセージは当社のネットワークを通じて通常通りに許可されるでしょう。
しかし、スパム行為が増加していることを検知する必要があり、ブロックリストに追加する可能性があります。

その他質問や確認をご希望の際は、こちらのメールにご返信ください。

マイクロソフト・オンライン・サービス テクニカルサポートにご連絡いただき
お力添えできましたこと、誠に感謝致します。

やや和訳が…アグレッシブということで受け入れてください。
もっと良い和訳あったら頂きたいです。

以上でブラックリストから解除されたそうなので、
マイクロソフト・テクニカル・サービスからメールが届いてから
4〜5時間後に再度メール送信し問題ないことが確認できました。

IPアドレス/DNSのブラックリストチェック

以下サイトで試しておくのが良いかと思います。
何かの間違いで登録されていた、というスパムメールとして扱われている
ということになるので。

MySQLトラブルシューティング - ERROR 2006 (HY000) at line ***: MySQL server has gone away

概要

DBインポート時に掲題のエラーが発生しました。

インポートサイズが大きすぎる為です。

インポートデータサイズのデフォルト値は 1M です。

以下コマンドで確認できます。

1
mysql> show variables like 'max_allowed_packet';

対策

2点あります。

  • mysqlコマンドラインから設定 (一時的)
  • my.cnf に設定 (恒久的)

mysqlコマンドラインから一時的に引き上げる

再起動の必要がなく影響範囲が少なく済みます。
但し、再起動後、デフォルト値に戻るので
恒久的な対応が必要な場合
my.cnf に設定しmysqldを再起動する必要があります。

例) 10MB に設定

1
mysql> set global max_allowed_packet = 1000000;

my.cnf に max_allowed_packet を引き上げる様設定

my.cnf パス探索
1
2
3
# mysql --help | grep my.cnf
order of preference, my.cnf, $MYSQL_TCP_PORT,
/etc/my.cnf /etc/mysql/my.cnf /usr/etc/my.cnf ~/.my.cnf

以下の順で my.cnf を探しています。
/etc/my.cnf/etc/mysql/my.cnf/usr/etc/my.cnf~/.my.cnf

個々の環境で異なるので本当に存在するかも含め設定ファイルを見定めてください。

おおよそ /etc/my.cnf が一般的かと思います。

my.cnf に [mysqld] に属する様に設定します。

10MBに設定してみます。

1
2
[mysqld]
max_allowed_packet=10MB

以上設定して再起動で設定反映完了です。

確認

設定が反映されているか確認します。

1
2
3
4
5
6
7
mysql> show variables like 'max_allowed_packet';

+--------------------+----------+
| Variable_name | Value |
+--------------------+----------+
| max_allowed_packet | 10485760 |
+--------------------+----------+

以上

Redis - (error) NOAUTH Authentication required への対応

概要

経年運用し特にメモリも問題なかったRedisが突如接続エラーが発生したので
その際の対応をまとめました。

エラー内容

1
PHP Fatal error:  Uncaught exception 'RedisException' with message 'Failed to AUTH connection'

認証接続に失敗して Exception になっている。

Redisの設定周りで特にrequirepass を設定していないし
何故突然?という感じでした。

各環境でRedisの設定パスは異なると思いますが、自環境の場合以下です。
/etc/redis/6379.conf

以下のようにrequirepassはコメントアウトされている。

1
# requirepass

対応

  • process を kill する
    service redis restart のように redisを再起動しても状況は変わりませんでした。
1
2
3
# ps aux | grep 'redis' | grep -v 'grep'

root 12743 0.1 0.2 40604 2124 ? Ssl 10:50 0:00 /usr/local/bin/redis-server *:6379
  • 再度 redis を起動させる。

    1
    # service redis start
  • requirepass 設定

運用中でアプリケーション自体のソースをいじりたくなかったので
空のrequirepass を設定しました。

1
redis-cli> CONFIG SET REQUIREPASS ''

上記で取り急ぎ対応は問題なかったです。

総評

改めて利用する際には
認証設定をしてアプリケーションからも
passwordを指定して接続する仕組みが良いですね。

ただ何故急に発生したかは引き続き調査をしていきます。

理由がわかる方はコメントなどいただけましたら幸いです。

Git で削除したブランチを復活させる

概要

以下コマンドでブランチを強制的に削除した後、やっぱり必要だったのに、となったときの対処

1
$ git branch -D <branch_name>

復活手順

  1. HEADの変更履歴を確認する
  2. HEADのログ番号からブランチ名作成
1
2
$ git reflog
$ git branch <branch_name> HEAD@{num}

-

例)

1
2
3
4
5
6
$ git reflog

c95c7e9 HEAD@{0}: merge release: Merge made by the 'recursive' strategy.
ad5bed0 HEAD@{1}: checkout: moving from release to master
ffe45df HEAD@{2}: merge develop: Merge made by the 'recursive' strategy.
6aa536b HEAD@{3}: checkout: moving from develop to release

上記のHEAD@{3}が消してしまったブランチに対してのcommitだ!
とわかれば、

1
$ git branch hogehoge HEAD@{3}

上記コマンド完了後、
git branchすると branch hogehogeが作成されたことがわかる。

なので、commitはこまめにしておくと良いです。

今更ながらMacでドットファイルを表示する

今更ながらMacでドットファイルを表示する

概要

Finder でドットファイルを開きたいという際にやっておく設定

環境

  • MacOSX Yosemite 10.10.3

手順

ターミナルを開き以下コマンド実行

1
$ defaults write com.apple.finder AppleShowAllFiles -boolean true

Finder アプリ再起動

1
$ killall Finder

これでドットファイルが反映されています。

元に戻したい場合

ターミナルで以下コマンド実行

1
$ defaults delete com.apple.finder AppleShowAllFiles

再起動

1
$ killall Finder

以上です

Twilio で電話通知

Twilio で電話通知

概要

障害検知をメールや Slack に流しても休日に業務系連絡を見ることは少ない。

その為、より検知報告に気付きやすくする様、

電話通知にするべく Twilio を導入する運びとなりました。

まずは利用するまでの簡単な手順をまとめました。

※コードのサンプルが Twilio のサイト内にあるので導入しやすかったです。

手順

1. Twilio にアクセス

以下リンクから Twilio にアクセスします。

http://twilio.kddi-web.com

2. 新規登録

名前、E-mail、パスワード(大小半角英数字)と

何にどの言語で利用するかを選択して

「始めましょう」をクリック。

「始めましょう」という日本語はユーザ目線でなく違和感ありますね。

3. アカウント認証

以下2つの認証方法があります。

  • 電話番号に SMS に確認コードを送信させる
  • 電話番号に Twilio から着信があり確認コードのダイヤルキーを入力する。

後者は Twilio の音声読み上げロボットから電話がかかって来るので

どんな感じで通知されるか試してみたい方は是非後者を選択してみてください。

スムーズなイントネーションではないですが、伝えたい気持ちは誰よりもあります。

4. Twilio から電話をかけてみる

アカウント認証確認後、Twilio 製品の「プログラマブル Voice」ページ Top に遷移しました。
メニューから ツール をクリックしツールページに遷移してください。

To 指定

音声通話>通話>電話をかける の API Explorer にて
必須To に 電話番号認証した番号を入力してください。

但し、日本番号(+81)の場合、
090******** の番号は

はじめの 0 を削除し、 +81 を prefix として追加し、

+8190******** となりますので注意してください。

URL 指定

条件Url に Twilio からの電話を受け取った際、

電話のキーダイヤルを押下した際の挙動を url 形式で指定可能です。

適当に準備できる Url がない場合は、

以下のような適当な Url で良いです。

http:/hogehoge.hogehoge.co.jp

通知実行

ページ下部の リクエストを発行する ボタンをクリックします。

※料金が発生します とありますが、Trial は料金を請求されるということはありません。

同アカウントでアップグレードする際は、発信した電話料金も合わせて請求されることになるので、テスト完了後は別途アカウントを取得することを推奨します。

電話を受け取る

Twilio から電話がかかってきたかと思います。

キーダイヤルを入力すると、 Url で指定したプログラムが動作しますが、

適当に入力したので

アプリケーションエラーが発生しました。電話を終了します。
と通知されるはずです。

実際にプログラムから使用する際は、

指定した Url でキー入力を受け取ってその後の挙動を制御する、

という流れになります。

実際に利用した例

担当した業務では、Zabbix からの障害検知を Twilio で担当者に電話報告(エスカレーション)するという仕組みを構築しました。

例)以下のような挙動が実現できます。

Zabbix で障害検知



Twilio

↓ 電話

対応者

↓ 対応者が「1」をクリック

指定した Url のプログラム実行

↓「1」を受け取り、障害対応可能な旨を Zabbix へ通知

Zabbix (障害対応中)

Zabbix & Twilio 参考

zabbix-twillio

上記サイトでの zabbix-twilio 連携の手順で進めた場合、

twilio でキーダイヤル入力後、 以下のようなエラーが発生し、イベント登録ができません。

API error -32602: The "user.login" method must be called without the "auth" parameter

zabbix-twilio.php 内の Zabbix_APIクラスが古い為です。

zabbix-twilio.php

PhpZabbixApi

上記をダウンロードし、 php build.php で 以下 2 ファイルを生成し、

こちらを呼び出し Zabbix_ApiZabbixApi とを変更してください。

  • ZabbixApi.class.php

  • ZabbixApiAbstract.class.php

  • /var/www/html/zabbix-twilio/zabbix-twilio.php

1
2
3
4
5
+ require_once 'ZabbixApi.class.php';
+ use ZabbixApi\ZabbixApi;

- $api = new Zabbix_API ( $ZABBIX_API, $ZABBIX_USER, $ZABBIX_PASS );
+ $api = new ZabbixApi ( $ZABBIX_API, $ZABBIX_USER, $ZABBIX_PASS);

ZabbixApi は Basic 認証を設定している場合にも対処しています。

1
2
// 例)
$api = new ZabbixApi ( $ZABBIX_API, $ZABBIX_USER, $ZABBIX_PASS, $BASIC_AUTH_USER, $BASIC_AUTH_PASS);

検証環境

  • Amazon Linux AMI release 2015.09
  • Zabbix 2.5 (3.0α)
  • PHP 5.6.14
  • MySQL 5.5.46

以上

意外と容量食ってた yum cache

yum cache 容量

1
2
# du -sh /var/cache/yum
155M /var/cache/yum

155MByteある汗

yum cache 削除

1
2
3
4
5
# yum clean all
読み込んだプラグイン:fastestmirror
リポジトリーを清掃しています: base epel extras mysql-connectors-community mysql-tools-community mysql56-community nginx treasuredata updates
Cleaning up everything
Cleaning up list of fastest mirrors

yum cache容量確認

1
2
# du -sh /var/cache/yum
8.0K /var/cache/yum

スッキリ!

サーバから容量不足のアラートで少しでも容量減らしたいときに
役立ちました。

潤沢にサーバスペックを用意できるクライアントでない場合もあるので
地道に必要な知識だと感じました。

Kibana4 検索窓での検索 正規表現パターンマッチ等

Kibana4 検索窓での検索 正規表現パターンマッチ等

概要

アクセスログを fluentd で集積(aggregate)して
ElasticSearch へ保存、そのデータを kibana で表示しています。

ちょっとしたアクセスログ解析したい場合、
かつては、SSH でサーバにログインして
コマンド実行し検索するという工程を踏んでいました。

ですが、Kibana で検索することにより
サーバログインすることなく、検索がスムーズになりました。

リモートログインして誤った操作等もなくなる、
また本番環境アカウントの公開範囲を絞ることができ
良いことが増えました。

実際構築しても使う側がどう検索したら良いかわからないということが
ちょいちょいあったので
Kibana4 検索窓での検索方法を簡単にまとめました。

前提

  • Kibana4
  • ドメイン名を以下とする

http(s)://hogehoge.jp

範囲指定

  • http ステータスコード 200 から 400 検索

status: [200 TO 400]

否定

  • 例) 指定ドメイン以外のリファラ検索
  • referer という項目について 正規表現での否定(NOT)のパターンマッチで検索します。
1
NOT referer:/http(s?)\:\/\/hogehoge\.jp\/(.*)/

複合検索

  • 例) 指定ドメイン以外、且つ、200 ステータス
1
NOT referer:/http(s?)\:\/\/hogehoge\.jp\/(.*)/ AND status:200

随時、事例があれば追記していきます。

運用中のNginxをノーメンテでバージョンアップ&HTTP2.0モジュールを導入

運用中のNginxをノーメンテでバージョンアップ&HTTP2.0モジュールを導入

概要

運用中の Nginx に HTTP2.0 モジュール http_v2_module を導入し
サイトのパフォーマンス向上を図ります。

※ Nginx 1.9.5 から http_spdy_modulehttp_v2_module に変更しています。

環境

  • CentOS Linux release 7.1.1503 (Core)
  • Nginx 1.9.3 インストール済み/稼働中

したいこと

  • Nginx のバージョンアップ (1.9.5 以上)
  • http_v2_module インストール

現状確認

1
2
3
4
5
6
7
# nginx -V

nginx version: nginx/1.9.3
built by gcc 4.8.3 20140911 (Red Hat 4.8.3-9) (GCC)
built with OpenSSL 1.0.1e-fips 11 Feb 2013
TLS SNI support enabled
configure arguments: --prefix=/etc/nginx --sbin-path=/usr/sbin/nginx --conf-path=/etc/nginx/nginx.conf --error-log-path=/var/log/nginx/error.log --http-log-path=/var/log/nginx/access.log --pid-path=/var/run/nginx.pid --lock-path=/var/run/nginx.lock --http-client-body-temp-path=/var/cache/nginx/client_temp --http-proxy-temp-path=/var/cache/nginx/proxy_temp --http-fastcgi-temp-path=/var/cache/nginx/fastcgi_temp --http-uwsgi-temp-path=/var/cache/nginx/uwsgi_temp --http-scgi-temp-path=/var/cache/nginx/scgi_temp --user=nginx --group=nginx --with-http_ssl_module --with-http_realip_module --with-http_addition_module --with-http_sub_module --with-http_dav_module --with-http_flv_module --with-http_mp4_module --with-http_gunzip_module --with-http_gzip_static_module --with-http_random_index_module --with-http_secure_link_module --with-http_stub_status_module --with-http_auth_request_module --with-threads --with-stream --with-stream_ssl_module --with-mail --with-mail_ssl_module --with-file-aio --with-ipv6 --with-http_spdy_module --with-cc-opt='-O2 -g -pipe -Wall -Wp,-D_FORTIFY_SOURCE=2 -fexceptions -fstack-protector-strong --param=ssp-buffer-size=4 -grecord-gcc-switches -m64 -mtune=generic'

※module や log, pid のパスは各環境に毎に異なります。

まずは 1.9.5 以上にバージョンアップして http_v2_module を導入したいと思います。

Nginx 1.9.6 インストール

今回は 2015.11.17 時点で最新の 1.9.6 をインストールします。

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
# cd /usr/local/src
# wget http://nginx.org/download/nginx-1.9.6.tar.gz
# tar xvf load/nginx-1.9.6.tar.gz
# cd nginx-1.9.6
# ./configure --prefix=/etc/nginx --sbin-path=/usr/sbin/nginx --conf-path=/etc/nginx/nginx.conf --error-log-path=/var/log/nginx/error.log --http-log-path=/var/log/nginx/access.log --pid-path=/var/run/nginx.pid --lock-path=/var/run/nginx.lock --http-client-body-temp-path=/var/cache/nginx/client_temp --http-proxy-temp-path=/var/cache/nginx/proxy_temp --http-fastcgi-temp-path=/var/cache/nginx/fastcgi_temp --http-uwsgi-temp-path=/var/cache/nginx/uwsgi_temp --http-scgi-temp-path=/var/cache/nginx/scgi_temp --user=nginx --group=nginx --with-http_ssl_module --with-http_realip_module --with-http_addition_module --with-http_sub_module --with-http_dav_module --with-http_flv_module --with-http_mp4_module --with-http_gunzip_module --with-http_gzip_static_module --with-http_random_index_module --with-http_secure_link_module --with-http_stub_status_module --with-http_auth_request_module --with-threads --with-stream --with-stream_ssl_module --with-mail --with-mail_ssl_module --with-file-aio --with-ipv6 --with-http_v2_module --with-cc-opt='-O2 -g -pipe -Wall -Wp,-D_FORTIFY_SOURCE=2 -fexceptions -fstack-protector-strong --param=ssp-buffer-size=4 -grecord-gcc-switches -m64 -mtune=generic'

# make
# make install

~~~ インストール完了 ~~~

# nginx -V
nginx version: nginx/1.9.6
built by gcc 4.8.3 20140911 (Red Hat 4.8.3-9) (GCC)
built with OpenSSL 1.0.1e-fips 11 Feb 2013
TLS SNI support enabled
configure arguments: --prefix=/etc/nginx --sbin-path=/usr/sbin/nginx --conf-path=/etc/nginx/nginx.conf --error-log-path=/var/log/nginx/error.log --http-log-path=/var/log/nginx/access.log --pid-path=/var/run/nginx.pid --lock-path=/var/run/nginx.lock --http-client-body-temp-path=/var/cache/nginx/client_temp --http-proxy-temp-path=/var/cache/nginx/proxy_temp --http-fastcgi-temp-path=/var/cache/nginx/fastcgi_temp --http-uwsgi-temp-path=/var/cache/nginx/uwsgi_temp --http-scgi-temp-path=/var/cache/nginx/scgi_temp --user=nginx --group=nginx --with-http_ssl_module --with-http_realip_module --with-http_addition_module --with-http_sub_module --with-http_dav_module --with-http_flv_module --with-http_mp4_module --with-http_gunzip_module --with-http_gzip_static_module --with-http_random_index_module --with-http_secure_link_module --with-http_stub_status_module --with-http_auth_request_module --with-mail --with-mail_ssl_module --with-file-aio --with-ipv6 --with-http_v2_module --with-http_geoip_module --with-cc-opt='-O2 -g -pipe -Wp,-D_FORTIFY_SOURCE=2 -fexceptions -fstack-protector --param=ssp-buffer-size=4 -m64 -mtune=generic'

version が 1.9.6 となり
configure arguments に --with-http_v2_module が追加されていることがわかります。

要点は元々導入済み http_spdy_modulehttp_v2_module に変更しビルドです。
--with-http_spdy_module がなければ --with-http_v2_module 追加です。

nginx server ディレクティブ修正

ssl http2.0 対応する様、修正します

1
2
3
server {
- listen 443;
+ listen 443 ssl http2;

Nginx configure test & reload

  • configure test 実施します。
  • 以下のように syntax is ok が出ない場合は設定に誤りがあるので修正してください。
1
2
3
4
# nginx -t

nginx: the configuration file /etc/nginx/nginx.conf syntax is ok
nginx: configuration file /etc/nginx/nginx.conf test is successful
  • 設定を再読み込みします。
1
# nginx -s reload

上記で設定完了です。
これまでノーメンテでバージョンアップし、http_v2_module インストールができました。

早速 https スキーマとなるページにアクセスしてみましょう。

http2.0 設定確認

  • Chrome ブラウザの Extension SPDY インディケータで確認
  • FireFox 開発ツール> ネットワーク > ヘッダから確認

SPDY インディケータで確認

HTTP/2 and SPDY indicator

拡張モジュールをインストールして確認してみると
SPDY インディケータが青くなっていることが確認できます。

FireFox 開発ツール> ネットワーク > ヘッダから確認

参考サイト

Elasticsearch curatorで不要Indexをまとめて削除

概要

fluentd + ElasticSearch + kibana を運用していますが
ある日ElasticSearchが動作しなくなる事象が発生しました。

過去indexが溜まりに溜まってメモリ不足というエラー。

logはS3にアップロードしているし、
不要なIndexは適宜削除して対策しました。

環境

  • CentOS Linux release 7.0.1406 (Core)
  • ElasticSearch 1.7.1
  • Python 2.7.5
  • pip 7.1.0

curator インストール

  • ElasticSearchをインストールしているサーバにて以下実施
1
# pip install curator

curator コマンド実行

  • ElasticSearchをインストールしているサーバにて以下実施
1
2
3
4
5
6
7
8
# 14日(2週間)経過でclose
curator --host localhost close indices --prefix logstash --older-than 14 --time-unit days --timestring %Y.%m.%d

# 35日(4週間)経過でdelete
curator --host localhost delete indices --prefix logstash --older-than 35 --time-unit days --timestring %Y.%m.%d

# 2日経過でbloom filter無効化
curator --host localhost bloom indices --prefix logstash --older-than 2 --time-unit days --timestring %Y.%m.%d

上記をjenkinsで SSH plugin
リモートサーバにログインして実行するよう、
設定して定期ポーリングで1日1回実行させてます。

以上