mirror of
https://github.com/kevinveenbirkenbach/computer-playbook.git
synced 2026-11-08 11:46:35 +00:00
kevinveenbirkenbachandClaude Opus 5
f46c4d0bab
A swarm job lost every published port of the mail stack without anything reporting it. dockerd aborted the whole ingress program: Failed to add ingress: failed to program ingress ports: failed to bind host port 0.0.0.0:995/tcp: address already in use /proc/net/tcp named the squatter: 10.100.1.1:995 -> 10.100.1.11:2049, the node's own NFS client. The mount carries no noresvport, so the kernel drew a source port from the 665-1023 reserved window and landed on pop3s. Afterwards none of 25/465/993/995/4190/8095 was bound while a sibling service's port was, and stalwart still reported 1/1 healthy because its healthcheck runs inside the container. The e2e CLI probe found it two hours later as ECONNREFUSED on SMTP 25. 993 and 995 are the only published ports repository-wide inside that window, so this is luck of the draw on any NFS-backed swarm host that runs the mail role. insecure on the kernel export is not separate hygiene, it is the other half: kernel nfsd defaults to secure and answers a mount from an unprivileged source port with EACCES, so noresvport without it would break every kernel-flavor mount. It reaches the kernel flavor only, since templates/exports.j2 is reached from tasks/flavor/kernel/main.yml alone. The ganesha flavor needs nothing: ganesha.conf.j2 sets no Privileged_Port and the default already accepts unprivileged clients. What it costs: the next deploy of every existing NFS client sees a pending opts change and remounts the shared state. The role already anticipates that, releasing DIR_BACKUPS first when the check-mode probe reports a change. Nothing bind-mounts that path into a container, so the exposure is a host-side job holding it at that instant, which fails loudly rather than silently. Not yet proven in effect: a source port is chosen when the RPC connection is established, so a plain remount can leave a running mount on its old reserved port until the next real mount. Reading /proc/net/tcp after the first deploy on an existing client is what confirms it. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>