jcoffey-dev
7141e565ea
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.
inbuxa-installer
One program that installs the inbuxa suite on the machine you run it on: the mail server, the administration console and the webmail, each as a container or on the host, in any mixture.
inbuxa survey what this machine is, as the installer sees it
inbuxa install --dry-run … what would happen, before any of it does
inbuxa install … do it
It only ever installs here. A second machine runs it too, and inbuxa join
points that machine at a server already running elsewhere.
What works today
This is early. What is built:
-
survey-- the machine's facts: distribution, init, whether Docker is usable by this user, Node's version, which of the suite's ports are free and what holds the ones that are not, memory, disk, and whether an install is already recorded here. It changes nothing. -
install --dry-run-- the whole plan: every file, unit, container, port, DNS record and credential, and a refusal with a reason when the machine cannot carry out what was asked. -
deps-- what a shape needs that this machine has not got, and, with--install, the doing of it: the Docker daemon from the distribution's own archive, the Compose plugin and Node from their official builds, both pinned by version and checked against a checksum in the source before anything is put in place.install --install-depsdoes the same as part of a run. A missing dependency is an offer, not a refusal. -
install --yes-- carries the plan out, for container shapes: writes the deployment, fetches the images, brings the mail server up in bootstrap mode with a credential that exists only for that step, completes bootstrap, brings the rest up without it, exempts the front ends from the auto-ban, creates the first mailbox, writescredentials.txtanddns.zone, and then checks that all three answer.
Not built yet: host installs, the terminal interface, join, status,
upgrade, uninstall. The design is in the inbuxa specification (§6.1 and
the installer draft); the phases are there too.
inbuxa install --local --domain example.test --install-deps --yes
is the shortest thing that works today: the whole suite on loopback, with no DNS and no certificates, on a machine that starts with nothing.
Building and testing
go build ./cmd/inbuxa
The installer writes units, creates users and takes ports 25 and 443, so it is tested on a throwaway virtual machine rather than on anybody's desk:
e2e/vm/up.sh a Debian 13 machine, in qemu, as you
e2e/vm/run.sh e2e/cases/survey.sh what it says about a machine
e2e/vm/run.sh e2e/cases/deps.sh the offer, and taking it
e2e/vm/run.sh e2e/cases/install-local.sh a whole suite, and signing in to it
e2e/vm/down.sh remove it
Each case starts from a copy of the machine taken when it was new, so a run
is free to break it and a failure is the installer's rather than the last
run's leftovers. e2e/vm/up.sh needs qemu, KVM and xorriso; nothing needs
root on your machine.
License
AGPL-3.0-or-later. Some of this began as ihasmail-oneshot, which is ours and under the same license.