# Teardown ledger — the campaign venues (2026-08-06) Three throwaway appliances had accumulated, each with its own storage sub-account, hub record, tunnel peer and off-site repository. **Two were destroyed here.** The third (`part4`, VM 323) was kept until Parts 1 and 3 had banked their findings, and goes separately. ## What was matched, and how Matched on **identity** — customer id → host id → off-site sub-account → wg peer — never on size. The hub's own delete-preview (`GET /configs//delete`) was used as an independent enumeration and agreed with the hand-built one in every field. ## The cascade is the hub's, not a hand-deletion `POST /configs//delete` runs the designed teardown: leg 1 hosts (including `DELETE FROM wg_peers WHERE host_id = ?`), leg 2 the committed reset with **external teardown FIRST** (off-site store + PBS namespace destroyed), leg 3 residue, leg 4 the customer record and **all** escrow ciphertext. Its own confirmation: „offsite tároló és PBS névtér megsemmisítve… Visszafordíthatatlan." **Six gates, all of which had to be satisfied deliberately** — three acknowledgements (`ack_hosts`/`ack_reset`/`ack_purge`), a type-to-confirm `confirm_id`, an `expect_hosts` race guard, and — the one that shaped the whole operation — **the cascade refuses to delete a live host**: > Delete refused: host c11-36d660 is ONLINE. Decommission the box first — the cascade never deletes a > live host. There is no hub decommission endpoint; the word appears only in that refusal. So both VMs were **stopped** and the hub was allowed to age them past its `stale_threshold` (**30m**, from the deployed `hub-config`) before the cascade would accept them. `rewalk` aged out at ~21 min of silence, `c11` at ~28 min — the two boxes' last reports had landed at different points in their cycles. ## Venue 1 — `c11` "Campaign 11" | Layer | Item | After | |---|---|---| | Machine | `demo-hp` VM **321** `c11-appliance` (200 G + 50 G + 50 G + efidisk, **20 G on disk**) | `qm destroy 321 --purge` — absent from `qm list` | | Hub host | `c11-36d660` | 0 occurrences | | Hub customer | `c11` (residue 340 rows, 1 superseded blob) | 0 occurrences | | Off-site | Storage Box sub-account **`u629488-sub4`** | 0 occurrences | | Off-site | `ep0` PBS namespace **`c11`** | gone | | Network | WireGuard peer **10.77.0.5** | 0 occurrences | ## Venue 2 — `rewalk` "Re-walk R-201" | Layer | Item | After | |---|---|---| | Machine | `demo-hp` VM **322** `rewalk-appliance` (**17 G on disk**) | `qm destroy 322 --purge` — absent | | Hub host | `rewalk-1ab77d` | 0 occurrences | | Hub customer | `rewalk` (residue 93 rows) | 0 occurrences | | Off-site | Storage Box sub-account **`u629488-sub5`** | 0 occurrences | | Off-site | `ep0` PBS namespace **`rewalk`** | gone | | Network | WireGuard peer **10.77.0.6** | 0 occurrences | ## Space returned, measured `c11-scratch` used: **58,578,256 KiB → 21,228,640 KiB** = **37.3 GB reclaimed**, against 20 G + 17 G measured before deletion. Free went 874.8 GB → 912.1 GB. ## The positive control An absence proves nothing unless the instrument can still find something. After each cascade the same greps were run for **`part4`**, which must survive: host `part4-905bdb` still present (2 rows), wg peer **10.77.0.7** still present, `ep0` namespace `part4` still present. So the zero counts above are measurements, not a broken query. `ep0` namespaces after both teardowns: `demo-felhom`, `demo-hp`, `part4` — exactly the three that should remain. Nothing on `ep0` outside the campaign's own namespaces was touched. ## Untouched, as scoped `demo-hp` itself and its guest 9201, `demo-felhom`, `drill-r50` (VM 300), DooPlex, the tester's box, and every `ep0` namespace that is not the campaign's own. ## Venue 3 — `part4` "Part 4 - no hand upgrade" (destroyed after the findings were written) Kept deliberately while Parts 1 and 3 read it: it was standing in the exact failed half-B state, and tearing it down first would have destroyed the evidence. Destroyed only after the diagnoses were committed (`70b6260`). | Layer | Item | After | |---|---|---| | Machine | `demo-hp` VM **323** `part4-appliance` (**16 G on disk**) | `qm destroy 323 --purge` — absent | | Hub host | `part4-905bdb` | 0 occurrences | | Hub customer | `part4` (residue 66 rows) | 0 occurrences | | Off-site | Storage Box sub-account **`u629488-sub6`** | 0 occurrences | | Off-site | `ep0` PBS namespace **`part4`** | gone | | Network | WireGuard peer **10.77.0.7** | 0 occurrences | Positive control for this one: **`demo-hp-bb76ea`** must survive the same greps, and does (2 rows). ## Final state - `demo-hp` guests: **VM 300 `drill-r50`** and **CT 9201** (demo-hp's own customer guest). All three campaign appliances are gone. - `ep0` namespaces: **`demo-felhom`, `demo-hp`** — only the two real demo boxes remain. - `c11-scratch` used: **58,578,256 KiB → 5,184,912 KiB = 53.4 GB reclaimed** across the three venues (20 G + 17 G + 16 G measured beforehand). Free 874.8 GB → 928.2 GB. ## Secrets that died with the venues Each cascade purged the customer record **and all escrow ciphertext** (leg 4). The recovery codes for these venues therefore no longer open anything: `R_C11_REWALK` and `R_PART4` in the operator's credentials file are now inert and can be removed at the operator's convenience. The working copies under `~/.config/part4/` on DooPlex were shredded. **One operational note carried over from the walk:** the `part4` retrieval passphrase was leaked into a session transcript on 2026-08-06 and rotated at the time; the customer it belonged to no longer exists.