docs(migration): add make-install-to-package runbook and no-move continuity tests for #50

Migration runbook at docs/install/migrate-from-makeinstall.md covers the mandatory remove-then-install path, why over-install is forbidden, no-move continuity guarantees, and reset-to-dormant expectations. Acceptance criteria MG-1 through MG-4 added to the install criteria section. Containerized tests verify no-move continuity: existing group makes sysusers a no-op, existing store dir makes tmpfiles a no-op, hand-edited config survives as a non-database file, and store schema is caught up by the upgrade-path migration. Dead code from a prior merge removed. Co-authored-by: CommandCodeBot <noreply@commandcode.ai>
2026-09-03 12:56:43 +05:30
parent 1873886b2f
commit c45b07003a
3 changed files with 347 additions and 38 deletions
@@ -0,0 +1,87 @@
+# Migrating from make-install to packages
+
+This runbook covers the transition from a `sudo make install` system to the native deb or rpm package. Packages are the primary delivery; `make install` remains as the dev fallback. The two deliveries are **mutually exclusive** per machine.
+
+## Why over-install is forbidden
+
+Installing a package over a make-install system silently breaks things:
+
+- **Stale admin units shadow vendor units.** `make install` places `fenris-collect.timer` and `fenris-collect.service` in `/etc/systemd/system/`. The package installs them in `/usr/lib/systemd/system/` (vendor placement). Systemd loads admin units first — the stale copy takes precedence, and the package update never reaches the running system.
+- **The local wrapper shadows the package wrapper.** `make install` places the `fenris` wrapper at `/usr/local/bin/fenris`. The package places it at `/usr/bin/fenris`. The shell finds `/usr/local/bin` first on PATH — the old checkout-relative wrapper runs instead of the package wrapper.
+
+Neither condition is reversible by reinstalling the package. The only safe path is remove-then-install.
+
+## Pre-migration checklist
+
+1. Confirm no monitoring period is actively running that you want to preserve across the gap:
+   ```
+   fenris status
+   ```
+   The migration resets the system to dormant (see [No-move continuity](#no-move-continuity) below). You opt back in with `fenris monitor resume`.
+
+2. If you have hand-edited configuration at `/etc/fenris/fenris.conf`, note it. The config survives the migration in place (see below).
+
+## Remove step
+
+```
+sudo make uninstall
+```
+
+This performs the **sanctioned disable** (`fenris-monitor disable --now`), closing the current monitoring period as `user_disabled`. It then removes all make-install artifacts: the venv at `/opt/fenris`, the wrapper at `/usr/local/bin/fenris`, the helpers at `/usr/libexec/fenris/`, the units in `/etc/systemd/system/`, and the polkit policy. The placement manifest at `/var/lib/fenris/manifest.txt` is removed.
+
+**What survives the remove:**
+
+- `/var/lib/fenris/observations.db` (and WAL sidecars, `.bak`) — the observation store
+- `/var/lib/fenris/` directory itself — root-written, group-read
+- `/etc/fenris/fenris.conf` — your hand-written configuration
+- The `fenris` system group — created by `groupadd -f` during make-install
+- Journal entries — age out naturally
+
+## Install step
+
+```
+sudo apt install fenris       # Debian/Ubuntu
+sudo dnf install fenris       # Fedora
+```
+
+The package installs into its own layout without touching the surviving store, config, or group.
+
+## No-move continuity
+
+These invariants are verified by the containerized acceptance tests (issue #50):
+
+| Asset | Make-install state | Package post-install | Mechanism |
+|---|---|---|---|
+| `fenris` group | Exists (`groupadd -f`) | Unchanged | `systemd-sysusers` is a no-op when the group already exists |
+| `/var/lib/fenris` directory | Exists (mode 2750, root:fenris) | Unchanged | `systemd-tmpfiles --create` is a no-op when the directory already exists |
+| `observations.db` + sidecars | Present from prior monitoring | Unchanged, never owned by the package | Package owns the directory only; store contents are never ghosted |
+| `/etc/fenris/fenris.conf` | Hand-edited device selector | Survives in place; package default lands as `.dpkg-new` / `.rpmnew` | dpkg conffile / rpm `%config(noreplace)` semantics |
+| Store schema | Version from prior Fenris release | Caught up by the upgrade-path migration | `postinst` / `%post` runs `migrate_to_latest()` on upgrade |
+
+The package detects the make-install system has been removed by the absence of the two markers:
+- `/var/lib/fenris/manifest.txt` (the placement manifest)
+- `/etc/systemd/system/fenris-collect.timer` (pre-manifest make installs)
+
+If either marker exists, the package installation aborts with a pointer to this runbook.
+
+## Reset-to-dormant
+
+`make uninstall`'s sanctioned disable closes the open monitoring period as `user_disabled`. After the package install, the system is dormant — the timer is installed but disabled, nothing is running, no monitoring period is open.
+
+To resume monitoring:
+
+```
+fenris monitor resume
+```
+
+This is the sanctioned opt-in. It enables the timer and opens the first monitoring period in one step. The migration costs at most one short sample gap (the interval between `make uninstall` and `fenris monitor resume`), honestly recorded in the endurance timeline.
+
+## Verification
+
+After migration, confirm the package is correctly installed:
+
+```
+fenris status
+```
+
+The status command should show the dormant state: timer disabled, no active monitoring period, and the observation store intact from the prior make-install system.
@@ -117,6 +117,13 @@ Status: Accepted — resolves [Define cross-cutting acceptance criteria](https:/
 - **IN-9** (P) The installer verifies `python3 ≥ 3.9` and fails cleanly otherwise; `/var/lib/fenris` is created with root-written group-read permissions; the database file is created lazily by the first write.
 - **IN-10** (P) Installed artifacts sit only at their fixed locations — units in `/etc/systemd/system`, helpers in `/usr/libexec/fenris`, polkit policy under `/usr/share/polkit-1/actions/`, configuration at `/etc/fenris`, observation store under `/var/lib/fenris` — and every placed file is recorded in the manifest (ADR 0004 §2; ADR 0003 §4).

+## Migration from make-install systems (ADR 0007 §10, spec §9)
+
+- **MG-1** (M) The migration runbook is published in the install docs (`docs/install/migrate-from-makeinstall.md`): mandatory remove-then-install steps, why over-install is forbidden (stale admin-directory units silently shadow vendor units; the local wrapper shadows the package wrapper), no-move continuity, and the reset-to-dormant expectation (the user opts back in with the sanctioned resume).
+- **MG-2** (A) The install guard is verified across the matrix: either make-install marker (the legacy placement manifest, or a unit file under the admin unit directory) causes an abort with a runbook pointer — never auto-clean. Tested by `test_migration_guard` on all four targets (Debian 12, Ubuntu 22.04, Ubuntu 24.04, Fedora 40).
+- **MG-3** (A) No-move continuity is verified in a container seeded with a make-install-shaped system: existing group makes sysusers a no-op, existing store directory makes tmpfiles a no-op, the hand-written configuration survives as a non-database file (package default lands beside it), and the store schema is caught up by the upgrade-path migration. Tested by `test_no_move_continuity_deb` and `test_no_move_continuity_rpm`.
+- **MG-4** (M) The migration costs at most one short sample gap, honestly recorded in the endurance timeline: `make uninstall`'s sanctioned disable closes the open period `user_disabled`; after migration the user opts back in with `fenris monitor resume`.
+
 ## Collector acquisition path (ADR 0006)

 - **AC-1** (P) Each collection run acquires counters and thermal evidence solely from `smartctl -a -j <device>` and controller identity (`subnqn`, `sn`, `mn`, `fr`, `transport`) solely from sysfs; no other acquisition path exists anywhere in the codebase.