One template serves two consumers with opposite needs. sys-svc-mail-msmtp
renders it to /root/.msmtprc, which the host itself reads, and web-app-wordpress
and web-app-moodle render the same file into their config directory, from where
it is mounted at /etc/msmtprc inside a container. resolve_smtp_host returned the
loopback for both, which is right for the first and meaningless for the second:
inside a container 127.0.0.1 is that container's own loopback and nothing is
listening on it.
WordPress 0 of run 31658270172 died on it. The deploy converged and then
"⏳ Wait for the delivery marker the healthcheck writes" retried sixteen times
before `assertion: wordpress_smoke_mail.rc == 0` evaluated to false. The reason
is in the rescue bundle rather than the log, identically in all three replicas
(containers/wordpress_wordpress.{1,2,3}.*.inspect.json):
msmtp: cannot connect to 127.0.0.1, port 587: Connection refused
msmtp: could not send mail (account default from /etc/msmtprc)
Those containers report Status: healthy with FailingStreak: 0, which is by
design since ebdadd91b decoupled the smoke mail from liveness -- the probe ends
on curl and the delivery assertion carries detection. The assertion was right;
the address it complained about was ours.
smtp_host gains in_container=, and the template passes it from a variable each
of the three call sites sets explicitly. There is deliberately no default: a
fourth consumer must fail loudly rather than silently inherit a loopback that
does not apply to it, which is the very defect being fixed. grep across roles,
utils and plugins finds exactly those three consumers today.
The alias needs pinning to resolve, and container_extra_hosts is the only
emitter of extra_hosts. It gained host_alias=, which appends
host.docker.internal at whatever reaches the host in the effective mode by
reusing _gateway_address -- host-gateway under compose, the stack host's routable
address under swarm. Hardcoding host-gateway at the call site would repeat the
mistake 7b1839681 already paid for: that alias resolves per node and misses the
one that publishes.
Measured, not assumed:
- all four resolver branches: host 127.0.0.1, container host.docker.internal,
bare infra node the manager, outside the rig the configured relay unchanged
- both branches again through a real ansible lookup call, because run() at
first did not forward the kwarg and Python-level testing would have missed
a silently ignored parameter
- the pin emits `host.docker.internal:host-gateway` under compose and
`host.docker.internal:<node address>` under swarm
- the destination exists under swarm: sockets-tcp.txt of all three nodes in
the same rescue bundle shows `LISTEN 0 4096 *:587 users:(("dockerd",…))`, so
the submission port is published on every interface of the node -- which is
why the container's own loopback missed it and the host alias will not
- and under compose by construction: mailu publishes submission on
MAILU_IP4_PUBLIC (templates/compose.yml.j2:12), which is
DOCKER_PUBLIC_BIND_HOST, which is 0.0.0.0 inside the rig
(group_vars/all/00_general.yml:46)
- 11 existing smtp_host unit tests stay green; make test-lint stays at 328
The moodle half fixes nothing that is currently red, and that is the point:
moodle renders the same broken file into two services but its healthcheck only
opens a TCP connection to the FPM port, so Moodle 0 of run 31658241728 passed
with mail that could never leave the container. It breaks when Moodle actually
sends -- a password reset, a forum subscription -- and no job would say so.
Not verified: that the relay accepts the message once reached. The port is
proven reachable, delivery is not.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
The template carried a three-way conditional across three {% set %} lines,
which was already at the edge of readability. Move the decision into
lookup('smtp_host') as plain control flow and pin all six cases in tests.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Alejandro Roman
kevinveenbirkenbachandClaude Opus 5