installer 1.24.0: a PRE-EXISTING backup target is granted too (R-185)

configure_backup_target has two arms and only one granted. Case A creates the storage and grants in the same breath; the Scenario-F arm ('the target already exists') returned without granting. A box whose felhom-backup pre-dated the install therefore pointed local_backup_target at a storage its own token could not read — measured on BOTH demo boxes: {"data":[]} through the token while root lists three archives. That tier was never restore-tested and nothing said so, because an empty listing is also what a brand-new tier returns. The reuse arm now ensures the ACL through the same guarded wrapper. Scenario F is unviolated: the storage DEFINITION is untouched, and pveum acl modify is idempotent. BACKUP_TARGET_ID is deliberately NOT added to PVE_STORAGES — that list is granted a step before the target is resolved, and --acl-storages entries are preflight-checked for existence; the comment now says so. A gate asserts it: every arm that resolves the target must also grant on it. Red-proved by reverting the arm.
2026-08-03 18:58:49 +02:00
parent 7a5694341d
commit 688470c945
3 changed files with 93 additions and 2 deletions
@@ -1,3 +1,32 @@
+## 1.24.0 — a pre-existing backup target is granted too (2026-08-03, R-185)
+
+**`configure_backup_target` has two arms and only one of them granted.** The Case A arm creates the
+storage and calls `felhom-backup-target-apply grant` in the same breath — a box that builds its own
+target has always been fine. The **Scenario-F arm** — *"the target already exists, leave it exactly as
+it is"* — returned without ever granting.
+
+So a box whose `felhom-backup` pre-dated the install (created by the vzdump-target-move runbook, or
+surviving a reinstall) ended up with `local_backup_target: felhom-backup` while its token held
+`FelhomAgentStore` on only `local`, `local-lvm` and `felhom-pbs`. Measured on **both** demo boxes
+2026-08-03: the content API answers `{"data":[]}` through the agent's token while root lists three
+archives. That tier was invisible to the agent and never restore-tested — and nothing said so,
+because an empty listing is also what a brand-new tier returns.
+
+The reuse arm now ensures the ACL through the same guarded wrapper, so both arms leave the box in the
+same state. **Scenario F is unviolated:** the storage DEFINITION is still untouched — granting the
+role the agent is supposed to have on the target this script is about to write into `agent.json` is
+finishing the job, not retargeting the box. `pveum acl modify` is idempotent, so a box that already
+has the grant is unchanged and a box whose token was rotated gets it back.
+
+`$BACKUP_TARGET_ID` is deliberately **not** added to `PVE_STORAGES`, and the comment now says why: that
+list is granted in step 4/5, before the target has been resolved in step 6, and `--acl-storages`
+entries are preflight-checked for existence. The grant belongs with the resolution, which is where it
+already was for a newly created target.
+
+**A gate now asserts it** (`hostinstall_gates.py`): every arm of `configure_backup_target` that
+resolves the target must also grant on it. Red-proved by reverting the reuse arm — `resolves the
+backup target in 2 place(s) but grants in only 1`.
+
 ## v1.23.0 — the installer is published, not pushed (2026-08-03, R-110 + R-183)

 **Two channels moved off `main` in the same change, because either one left behind makes the other