docs(installer): record the first real systemd verification #94

Merged
whitlocktech merged 1 commits from docs/installer-systemd-verified into main 2026-08-05 09:30:31 +00:00
Member

What & why

Docs half of installer#8. Phase 2 shipped service registration that had never been executed: a relocated test run deliberately skips it, sc create needs elevation, and systemd needs a Linux host. The plan's Phase 2 section said what was verified without saying that this was not, which is exactly the sort of gap that gets forgotten before a cutover.

It has now been run for real, on a privileged Debian 12 container with systemd as PID 1, installing into /usr/bin, /etc/runicgateway and /var/lib/runicgateway as root:

  • unit written and enabled; service comes up active, enabled as the unprivileged runicgateway user
  • sidecar.toml lands 600 owned by that user; database created under /var/lib, so the UOLINK_DB_PATH pin is doing its job
  • /health answers protocol 3
  • uninstall removes the service, the unit, the binary and the account, and leaves sidecar.toml, the database and all 24 overlay files in the ServUO tree untouched

That run found one bug only a real service host could show — user_created recorded per-run rather than as state, so an identical re-run rewrote install.json and uninstall silently left behind the account the installer had created. Recorded here with the reason it is invisible on Windows (the SCM's virtual account is not something the installer creates).

The section also now states plainly what is still unverified: the Windows SCM half, which needs an elevated shell this machine's automation does not have.

How it was tested

Prose only; every claim is an observation from the run described in installer#8, not from the design.

Checklist

  • I have read CONTRIBUTING.md.
  • The change builds and existing tests/checks pass locally.
  • I have added or updated tests/docs where it makes sense.
  • My commits are reasonably scoped with clear messages.

AI-assisted contributions (required)

  • No AI tools were used to produce this contribution.
  • AI tools were used. Tool(s): Claude Code (Opus 5). I have reviewed and understand every change, and take responsibility for it. AI-authored commits are marked with a Co-Authored-By trailer.

License

  • I agree that my contribution is licensed under this project's license (GNU GPL v3.0 or later), and I have the right to contribute it.
## What & why Docs half of **installer#8**. Phase 2 shipped service registration that had **never been executed**: a relocated test run deliberately skips it, `sc create` needs elevation, and systemd needs a Linux host. The plan's Phase 2 section said what was verified without saying that this was not, which is exactly the sort of gap that gets forgotten before a cutover. It has now been run for real, on a privileged Debian 12 container with systemd as PID 1, installing into `/usr/bin`, `/etc/runicgateway` and `/var/lib/runicgateway` as root: - unit written and `enable`d; service comes up `active, enabled` as the unprivileged `runicgateway` user - `sidecar.toml` lands `600` owned by that user; database created under `/var/lib`, so the `UOLINK_DB_PATH` pin is doing its job - `/health` answers protocol 3 - `uninstall` removes the service, the unit, the binary and the account, and leaves `sidecar.toml`, the database and all 24 overlay files in the ServUO tree untouched That run found one bug only a real service host could show — `user_created` recorded per-run rather than as state, so an identical re-run rewrote `install.json` and `uninstall` silently left behind the account the installer had created. Recorded here with the reason it is invisible on Windows (the SCM's virtual account is not something the installer creates). The section also now states plainly what is **still** unverified: the Windows SCM half, which needs an elevated shell this machine's automation does not have. ## How it was tested Prose only; every claim is an observation from the run described in installer#8, not from the design. ## Checklist - [x] I have read [CONTRIBUTING.md](CONTRIBUTING.md). - [x] The change builds and existing tests/checks pass locally. - [x] I have added or updated tests/docs where it makes sense. - [x] My commits are reasonably scoped with clear messages. ## AI-assisted contributions (required) - [ ] No AI tools were used to produce this contribution. - [x] AI tools were used. Tool(s): `Claude Code (Opus 5)`. I have reviewed and understand every change, and take responsibility for it. AI-authored commits are marked with a `Co-Authored-By` trailer. ## License - [x] I agree that my contribution is licensed under this project's license (**GNU GPL v3.0 or later**), and I have the right to contribute it.
wtclaude added 1 commit 2026-08-05 09:02:41 +00:00
Phase 2 shipped service registration that had never been executed: a
relocated test run deliberately skips it, `sc create` needs elevation,
and systemd needs a Linux host. It has now been run for real on a
privileged Debian 12 container with systemd as PID 1 — unit written and
enabled, service up as the unprivileged runicgateway user, sidecar.toml
600 and owned by it, database under /var/lib (so the UOLINK_DB_PATH pin
works), /health answering protocol 3, and uninstall taking the service,
unit, binary and account away while leaving the config, the database and
the whole ServUO tree alone.

That surfaced one bug only a real service host could show — user_created
was recorded per-run rather than as state, so an identical re-run
rewrote install.json and uninstall silently left behind the account the
installer had created (installer#8). Recorded here with the reason it is
invisible on Windows.

Also notes what is still unverified: the Windows SCM half, which needs an
elevated shell this machine's automation does not have.

Co-Authored-By: Claude <noreply@anthropic.com>
whitlocktech merged commit c47e0fb303 into main 2026-08-05 09:30:31 +00:00
whitlocktech deleted branch docs/installer-systemd-verified 2026-08-05 09:30:32 +00:00
Sign in to join this conversation.
No description provided.