jcoffey-dev
cc77f62c01
Refusing because Docker is absent is not help. It is a chore handed back to the operator, who will then install it however the first search result says to -- which is how machines end up with a third-party apt repository and a signing key nobody chose. So the installer offers. It says what it would do, in the same words the plan uses, and does it only when told: --install-deps during a run, or "inbuxa deps --install" on its own for someone preparing a machine before they have a domain to give it. What it installs, and from where, is the part worth arguing about: - the Docker daemon: the distribution's own package. One package from an archive the machine already trusts beats a new source. - the Compose plugin: Debian's docker.io ships no compose v2 at all, so this is Docker's official static build, pinned by version with its checksum in the source beside it. - Node: the official tarball into /opt/inbuxa/node, deliberately off PATH so it runs the webmail's unit and nothing else. Every download is checked before it is put in place; a checksum that does not match stops the step rather than warning and carrying on. Tested from a bare Debian 13 in the lab: 25 checks, ending with docker and compose answering, node 22 where the unit will look for it, and the installer agreeing that nothing is missing any more. The last of those failed the first time -- the survey looked for node on PATH only, and so could not see the one it had just installed.
2.5 KiB
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.
Not built yet: applying the plan, 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.
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 rewind it, then run a case inside
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.