The installer knew one distribution: Debian, with docker, on a new enough
release. Everything else it would have offered and then failed at.
Three facts now decide what the matrix offers, and each is read from the
machine rather than assumed:
- The container runtime. Docker where the machine has one, podman on the Red
Hat family, which ships no docker at all. Both go through the same compose
plugin: compose speaks the Docker API and podman serves it, so there is one
compose file and one deployment path, not two. Telling a Fedora operator to
add Docker's own repository to a machine that already has a container
runtime would have been the wrong trade.
- glibc. The server binary is downloaded, not built here, and it is linked
against 2.39. Rocky 9 (2.34), Debian 12 and Ubuntu 22.04 cannot run it, so
the host shape is refused there with the version found and the container
shape named as the answer -- rather than installing a file that cannot
start.
- The operating system itself. This compiles for macOS and Windows because Go
compiles anything, and on either it would read no os-release, find no
systemd, and describe a machine that does not exist. It now says what it is
and exits.
Two bugs the other distributions found, both of which Debian could not have:
- The survey reported the first thing in the way and stopped, so on Fedora it
asked to start podman.socket, and then -- having done it -- asked for the
compose plugin. Needs are named now, not described, and reported together.
- apply used the survey taken before dependencies were installed, so on a
machine that had no runtime at all it installed podman and then reached for
docker. It re-surveys after resolving, and stops if containers still are
not usable.
The lab takes DISTRO now: debian13, debian12, ubuntu2404, fedora, rocky9,
arch, each with its own disk and ssh port so several can be up at once. The
cases no longer say "docker" either. install-local passes on Debian 13,
Fedora 43 and Rocky 9 -- 20 checks each, ending with a sign-in to the webmail
the installer put there.
The public shape now works end to end: real ports, Caddy in front, and both
programs that need certificates getting them from the same CA -- Caddy for
the front ends over TLS-ALPN-01, the mail server for its own names over
HTTP-01, which Caddy forwards on port 80.
Proved in the lab against Pebble, with a DNS stub answering every name with
the machine's own address, so no public name or public CA is involved:
twenty checks, ending with IMAPS and submissions presenting a certificate
for the mail host that verifies against the CA, and the webmail sending
sign-in to the server as the first-party client the server registered.
Two things the test found, both of which would have shipped:
- The proxy fronted four of the server's five names. The server puts
ua-auto-config in its own certificate too, so its challenge was never
forwarded, one name failed, and the whole order failed with it -- leaving
the mail ports on a self-signed certificate while everything else looked
healthy. The list now matches what the server asks for.
- Nothing waited for the certificate. An order that fails is not retried on
its own and a restart does not start a new one, so the install declared
itself finished over a self-signed certificate. It now waits, asks again
every 45 seconds, and reports the issuer -- or says plainly that the
server will keep trying once the domain resolves here, which is the
ordinary case on a first install.
--acme-directory and --acme-ca-root are what let a private CA be used: the
root is added to the server image's own bundle and given to Caddy, because
neither sees the other's trust store.
jcoffey-dev