Sakura VPSにおいてあるマシンから、自ドメイン宛にメールを送信した際、
Sakura側のmtaとして使っているexam4に以下のログが残っていたので調査
(送信後,5分ほど経過してから受信していたので、何かおかしいんだろうなと
思ってはいたものの放置してた。)
2017-10-10 08:31:05 1e1hQz-000487-Cd H=mta [mta ipv6 addr] TLS error on connection (gnutls_handshake): timed out
結果として,根本的な原因は不明なままだが,
mtaへipv4で接続すれば,見た所はエラーは解消した為,
dnsのエントリからmtaのAAAAレコードを削除することで対処した。
追記:
自ドメイン側でipv6 Path MTU Blackholeを発生させていたことが原因でした.
ルータの設定を見直して対処完了です。恥ずかしい x)
以下は、調査履歴と泣き言。
今朝気づいたらpostfixが止まっててびっくりした。
systemctl start postfix
とかしても、エラーは出ないが、動作もしない状態なので
頭抱えながら /lib/systemd/system/postfix.service を眺める
exec = /bin/true
… それはエラーにはならないねぇ。と今までどうやって動いてたんだ??と再びお悩み状態。
藁をもすがる状態で、/usr/share/doc/postfix/README.Debian を見てみたところ
postfixマルチインスタンスモードの時は下記をやれ
プライマリインスタンスは${INSTANCE_NAME}が”-“な
# systemctl daemon-reload
# systemctl enable postfix@${INSTANCE_NAME}.service
# systemctl start postfix@${INSTANCE_NAME}.service
みたいなことが書いてあるので、実施。
すると、まぁ、動作する
が、いつからこうなったんだろう・・・
ansible 2.4 での import_tasks の探索順
playbook ... (0) カレントディレクトリ
+ import.yml ... (I0)
+ roles
+ role_a
+ tasks
- main.yml ... (1)
- import.yml ... (I1)
+ handlers
- main.yml ... (2)
- import.yml ... (I2)
(1)でimport_tasksを実行 -> (I1) が優先, 無ければ(I0)
(2)でimport_tasksを実行 -> (I2) が優先, 無ければ(I1), (I0)の順で探索
配置がややこしくなるので、handlers以下にはmain.ymlだけを置いて
タスクはtasks以下に配置するのがよさげ.