admin/felhom.eu
1
0
Fork 0
Code Issues Pull Requests Actions 1 Packages Projects Releases Wiki Activity

host-install v1.22.0 — E-2 Part 2: new boxes get a real backup target, or are told they do not

Browse Source 
Every box installed before this got local_backup_target "local" -- the vzdump
target on the SAME physical device as the guest, so a drive failure took the
guest and its only local backup together. E-1 fixed two machines by hand; this
fixes the installer.

Case A: an eligible secondary drive is already mounted -> create felhom-backup on
that drive's own mountpoint via the felhom-backup-target-apply wrapper (create +
grant) and point the primary tier at it.

Case B: system drive only -> the target stays on the system drive and this is
RECORDED AS DEGRADED, not as normal. The install still succeeds: a single-drive
appliance is a valid product, it just cannot survive drive loss.

Phase 0 inverts the emphasis: the installer has NO drive-enrollment step, so on a
fresh appliance Case A almost never fires. The common case is Case B with the
drive arriving later through the wizard (Part 3). Case A covers the reinstall
shape where an agent-generated .mount unit already brings the drive up by fs-UUID.

Eligibility suggests and refuses the absurd, never decides by transport: the
reference backup drive is an external USB HDD and BOTH demo boxes report
removable=0, so a transport rule disqualifies the reference drive and a removable
rule finds no candidate at all.

Scenario F: an already-configured box is never corrected -- an early return plus
setdefault, both load-bearing.

Proofs (installer-logic-tested against extracted functions with stubbed
pvesm/wrapper; NOT install-tested, no reinstall was performed):
  A -> create + grant, resolved felhom-backup
  B -> DEGRADED warnings, resolved local, rc=0 (install not failed)
  F -> skipped, 0 wrapper calls
  F red-proof (guard removed) -> 2 wrapper calls, i.e. it would have "corrected"
      a correct box
This commit is contained in:
authentik Default Admin
2026-07-29 09:06:32 +02:00
parent 3696188636
commit f6aed82940
2 changed files with 147 additions and 3 deletions
Download Patch File Download Diff File Expand all files Collapse all files
scripts/CHANGELOG.md
+46
View File
@@ -1,3 +1,49 @@
## v1.22.0 — E-2 Part 2: new boxes get a real backup target, or are told they do not (2026-07-29)
Every box installed before this got `local_backup_target: "local"` — the vzdump target on the SAME
physical device as the guest, so a drive failure took the guest and its only local backup together.
E-1 fixed two machines by hand; this fixes the installer.
**Case A** — an eligible secondary drive is already mounted: create `felhom-backup` on that drive's
own mountpoint through the new `felhom-backup-target-apply` wrapper (`create` + `grant`), and point
the primary tier at it.
**Case B** — system drive only: the target stays on the system drive and this is **recorded as
DEGRADED, not as normal** — two warning lines saying it protects against corruption but not against
a disk failure, and what to do about it. **The install still succeeds**: a single-drive appliance is
a valid product, it just cannot survive drive loss.
**Phase 0 reality check, which inverts the emphasis:** the installer has **no drive-enrollment
step** — `/mnt/felhom-drives` is agent-installed at runtime and drives are formatted/mounted through
the dashboard later. So on a fresh appliance **Case A almost never fires**; the common case is
Case B, with the drive arriving months later through the wizard (E-2 Part 3). Case A exists for the
reinstall/recovery shape, where an agent-generated `.mount` unit already brings the drive up by
fs-UUID.
**Eligibility suggests and refuses the absurd; it never decides by transport.** The reference
hardware forbids that: demo-felhom's backup drive is an external **USB HDD**, and **both** demo
boxes' drives report `removable=0`. A transport rule would disqualify the reference drive; a
removable rule would find no candidate at all. The filter is: a real mounted `ext4/xfs/btrfs` under
`/mnt`, on a `/dev` source, not the root device, ≥ 64 GB.
**SCENARIO F — an already-configured box is never "corrected".** `configure_backup_target` returns
early, changing nothing, when the storage id already exists; `setdefault` independently preserves an
existing box's whole `backup` block. Both guards are load-bearing and both were exercised.
Also installs (and uninstalls) `/usr/local/sbin/felhom-backup-target-apply`, 0755 root:root, with
`bash -n` before install — the pbs-apply pattern. The wrapper is the single place the F-1/F-2 laws
live, so the installer and the runtime move cannot drift.
**Proofs (harness against the extracted functions, stubbed pvesm/wrapper — installer-logic-tested,
NOT install-tested; no reinstall was performed):**
| Scenario | Result |
|---|---|
| A — eligible drive | `create felhom-backup /mnt/bigdisk` then `grant felhom-backup`; resolved `felhom-backup` |
| B — single drive | DEGRADED warnings, resolved `local`, **rc=0 — install not failed** |
| F — configured box | skipped, **0 wrapper calls** |
| F red-proof (guard removed) | **2 wrapper calls** — it would have "corrected" a correct box |
## felhom-host-install 1.21.0 — F-LEAK: the restore-test scratch band gets its own path-scoped grant (2026-07-28)
Campaign 8's F-LEAK: a restore-test whose restore **fails** leaves a scratch guest the agent cannot