ipv6とtlsでトラブル発覚

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)

以下は、調査履歴と泣き言。

続きを読む ipv6とtlsでトラブル発覚

Debian stretch のpostfix

今朝気づいたら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

みたいなことが書いてあるので、実施。
すると、まぁ、動作する
が、いつからこうなったんだろう・・・

メモ: import_tasks の探索順

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以下に配置するのがよさげ.