inbuxa/inbuxa-server
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases 2 Wiki Activity

Cutover: the old install is retired, and that changes what a rollback is

Browse Source 
John, 2026-09-20: committed, remove it. Done the same day as the cutover and
before the certificate-renewal gate this page proposed, which is the
operator's call to make and is recorded as such.

Archived first and the archive verified off-host by checksum, then the tree,
the unit and its drop-in removed. The stalwart user stays: redis-server runs
as it, which step 0's pgrep had already shown and which is exactly the kind
of thing that makes "remove the service user" a bad reflex.

Two things the doing taught, both for migration.md. The unit does not live
inside the tree it manages, so an archive of /opt/stalwart alone is not a
restorable rollback -- stalwart.service and its drop-in had to be saved
separately, and a tool that archives before retiring has to take them too.
And retiring changes what a rollback means: up to that moment it was a
service swap against a store still on disk, minutes and no restore; after
it, an untar, a chown, a unit to reinstate and a webmail image that is no
longer on the host. Still possible, slower, and no longer what the Rollback
section describes.
This commit is contained in:
jcoffey-dev
2026-09-20 01:58:34 -07:00
parent 80972695b9
commit d264429298
1 changed files with 28 additions and 0 deletions
Download Patch File Download Diff File Expand all files Collapse all files
docs/spec/cutover.md
+28
View File
@@ -195,6 +195,34 @@ store is forward-only. The rollback is the old store or nothing.
## Retiring the old install ## Retiring the old install
**Done, 2026-09-20.** `/opt/stalwart` and its unit were removed the same day
as the cutover, at the operator's decision and before the gate proposed
below. The section is kept because it describes the shape of the decision,
and because the migration tool has to offer it.
What was done, in order: the fork was confirmed to hold nothing open under
the old tree and to name it in neither its config nor its unit; the whole of
`/opt/stalwart` was archived and the archive verified off-host by checksum;
then the tree, `stalwart.service` and its drop-in were removed. The
`stalwart` user was **left alone** — `redis-server` runs as it, which
`pgrep -u stalwart` had already shown.
Two things worth carrying into `migration.md`:
- **The unit is not inside the tree.** `/opt/stalwart` does not contain
`/etc/systemd/system/stalwart.service` or its drop-in, so an archive of the
tree alone is not a restorable rollback. Both were saved separately beside
the tarball. A tool that archives before retiring has to take them too.
- **Retiring changes what a rollback is.** Up to that moment it was a service
swap against a store still on disk: stop one unit, start the other, minutes
and no restore. Afterwards it is an untar, a chown, a unit to reinstate and
a webmail image that no longer exists locally. Still possible, materially
slower, and no longer the thing the Rollback section describes.
The rest of this section is what was decided beforehand, and stands as the
recommendation for anyone else.
**The new stack depends on nothing in the old one.** That is the point of **The new stack depends on nothing in the old one.** That is the point of
the shape, not a side effect of it: `/opt/stalwart` is a reference, and the shape, not a side effect of it: `/opt/stalwart` is a reference, and
everything the fork needs — the store, the config, anything else found along everything the fork needs — the store, the config, anything else found along