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

R-32 (decision 167): RESET purges the off-site folder through the sub-account's own login before deleting it

Browse Source 
Co-Authored-By: Claude Opus 5.5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_0159rPz1ZhFKsS53msqPYxtS
This commit is contained in:
authentik Default Admin
2026-10-07 10:07:50 +02:00
parent aeca52ea54
commit e03b18ea21
10 changed files with 259 additions and 5 deletions
Download Patch File Download Diff File Expand all files Collapse all files
documentation/architecture/07-backup-architecture.md
+10
View File
@@ -245,6 +245,16 @@ the identity bundle's shape is `{tunnel_token, pbs_token, wg_private_key, restic
**[DESIGN] Off-site deletion custody (decisions 68–69, 2026-10-03) — BUILT hub v0.127.0 / controller v0.289.1, live on both demo boxes.** The restic repository password stays on the box only. The box's off-site key is append-only (pinned in `authorized_keys`, written by the hub — the key registrar); the box never receives the sub-account password, which the hub stores encrypted at rest. Old snapshots are pruned by the box itself, only in a weekly window the hub opens, behind a fake-snapshot guard (R-822); the window has run live on both demo boxes since 2026-10-05 (R-95, closed). The guard's residual — past-dated fakes steering the keeps, and a window check that trusts the box's own counts — is R-822 and R-895. A Felhom-side pruner holding repository passwords is rejected.
**[DESIGN, built hub 2026-10-07 — R-32 option A, `09` §3 decision 167] What RESET does to the household's off-site
copy.** On the shared pool box a sub-account is a LOGIN, not the data: deleting it leaves its folder (measured
2026-07-21: 1.4 GB in two `.orphaned-*` folders after a RESET), and a re-enabled customer lands on the same folder
(`felhom-<customer id>`). So RESET's off-site leg now **purges first**: through the sub-account's own password login
(the route `DeleteSetAside` already uses — no main-account credential), it deletes the repository and every
`<repo>.orphaned-*` copy and nothing else, lists again, and only then deletes the sub-account. A purge that fails (or
no purge route) keeps the sub-account and fails the leg (`hetzner: failed`, a re-run resumes). The dedicated tier is
unchanged (the box is deleted with its data). The **move-aside for a reinstall WITHOUT RESET stays** — there custody
survives and the set-aside copy is still openable. Tests `TestDeprovision_R32_*`, `TestPurgeRepos_R32_*`.
**[FACT] Three parts of the Recipe are empty or wrong on the live fleet**, and they are exactly the
parts a host-loss recovery would read (INV Part D2.3): `hosts.dr_record_json` is `{}` on all three
hosts; `host_escrow.directive_json` is `{}` on both escrowed hosts; `dr_recipe.host_half.drives` is