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.
72 lines
3.3 KiB
Markdown
72 lines
3.3 KiB
Markdown
# 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-deps` does 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, writes `credentials.txt` and `dns.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.
|
|
|
|
[ihasmail-oneshot]: https://git.coffeylabs.org/inbuxa/ihasmail-oneshot
|