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 plan now happens. "inbuxa install --local --domain example.test
--install-deps --yes" on a machine with nothing on it ends with a mail
server, a console and a webmail running, an administrator and a first
mailbox created, and the records the domain needs written out.
The sequence is the one ihasmail-oneshot worked out against a running
server, which is why its JMAP client and its Docker handling came across
nearly whole: bring the server up in bootstrap mode with a credential that
lives in an override file for that step only, complete bootstrap, bring the
rest up without it -- so no recovery credential outlives the setup -- exempt
the front ends from the auto-ban, restart for the settings that need it,
create the first account, and write down the password nothing else holds.
New here: three services rather than two. The console is static files that
learn their server's address at start, and the webmail is given the
first-party OAuth client secret that the server is given too.
Twenty checks in the lab, from a bare Debian 13. The two worth having are
the ones that catch an install that looks fine and is not: nothing in the
running server carries a recovery admin any more, and the account the
installer created can sign in to the webmail it installed.
Two bugs the lab caught, both of which would have shipped:
- the private addresses were worked out on a copy of the stack, so the
server was told the webmail speaks from "", and refused it.
- the console image rewrites index.html when it starts, so a read-only root
filesystem left it restarting forever. The webmail keeps read_only; the
console cannot have it until that rewrite moves.
jcoffey-dev