docs: R-185 closed — the silence as well as the grant
gates / gates (push) Successful in 8s

- OPEN-ITEMS: R-185 closed with the measurement, the corrected root cause (the
  installer's Scenario-F reuse arm, not PVE_STORAGES), and the live sequence.
  Records that demo-hp carried the same drift and was fixed too.
- capability map: the whole-guest row's HOST-tier half was OPTIMISTIC and now
  says so — that tier was not merely unproven, it was unprovable on both demo
  boxes, and every live proof cited was on the offsite tier.
- vzdump-target-move runbook: its item 5 predicted this; annotated (not
  rewritten) with what actually happened — the create arm did grant, the reuse
  arm did not, and it surfaced as a silent unreadable tier rather than the 403
  the item expected, because vzdump writes through a root path.
- CONTEXT: S-21 (an empty listing cannot distinguish forbidden from newborn; the
  measured trap that an ungranted path answers with INHERITED privileges) and
  S-22 (the Scenario-F arm must finish the job).
- STATUS: rewritten for the operator, back to one screen.
This commit is contained in:
2026-08-03 19:02:25 +02:00
parent 311dc06c13
commit e3187c86d5
5 changed files with 64 additions and 27 deletions
+18 -21
View File
@@ -23,12 +23,18 @@ Proven end to end on real hardware.
- **The off-site copy can be erased by the machine that made it.** The credential that writes it can
also delete it. A daily snapshot is armed as a stopgap, and we have never restored from that copy.
*(R-95, R-87)*
- **Nothing else open that affects a customer.** The three faults that were on this list yesterday —
the reserve watching the wrong step, the last app whose data was never saved, and the alert that
told you about one app and swallowed the rest — are all fixed and proven on a real machine.
## What shipped recently
- **A backup copy the machine was never allowed to read — and could not tell you about.** One demo
machine kept its whole-machine backups on a dedicated storage area the agent had never been granted
permission to read. Asked what was there it was told "nothing", while an administrator saw three
backups. **The permission was one command; the silence was the real fault** — a storage that answers
"nothing" looks exactly like a brand-new one, which is a normal, healthy state, so that copy had
never been test-restored and nothing had ever mentioned it. The machine now checks whether it is
allowed to read each copy it depends on and says so when it is not — the alert reached you by email
before the permission was granted, which is the whole point. **Both demo machines carried it and
both are fixed**, and new machines no longer inherit it. *(R-185)*
- **Three ways the alarm system was misreporting its own work — all fixed.** None of them ever risked
data. **(1)** When the machine proved a backup restores, that result could vanish if the agent was
restarted in the following quarter-hour — and yesterday's change made the gap a week rather than a
@@ -39,17 +45,9 @@ Proven end to end on real hardware.
published after the binary, and a new check catches the opposite mistake so nothing is traded away.
**(3)** A released binary can now be rebuilt by anyone and checked against the fingerprint you
approve — until today, rebuilding produced different bytes. *(R-189, R-188, R-186)*
- **Each backup is now proved, instead of the clock being obeyed.** The machine used to re-test a
backup every twenty-four hours on a timer that restarted whenever the software was updated, so the
test happened at an arbitrary time and a fresh backup could sit unproven while an old one was
re-checked. Now a copy is tested once, about a day after it is made, and not again until there is a
newer one — so the daily copy is proved daily and the weekly off-site copy weekly, each on its own.
The alert that says "this copy has not been proved lately" learned each copy's own rhythm in the
same change; without that it would have started complaining every night about a system that is
working. *(R-86)*
- **A failed backup now tells you about every app, once**, with every failure written down whether or
not it is emailed, and a message the machine decides not to send now leaves a record saying so.
*(R-182)*
- **Each backup is now proved, instead of the clock being obeyed** — tested once, about a day after
it is made, and not again until there is a newer one; the "not proved lately" alert learned each
copy's own rhythm in the same change. *(R-86)*
## What we're working on
@@ -67,17 +65,16 @@ Proven end to end on real hardware.
- **One small question, not urgent.** The automatic check cannot see which version you have told
machines to install, only which ones exist. Closing that needs either a password given to the build
server or a check inside the hub itself. *(R-184)*
- **Nothing else.** The question about whether the off-site endpoint counts as protected is
**settled — it does**, and the machine list now says so instead of asking.
- **Nothing else.**
## Changed since last update
- **2026-08-03** — Found and fixed a backup copy the machine was never permitted to read, on both demo
machines. The permission was one line; what mattered was that the machine now says so instead of
treating "I am not allowed" and "there is nothing here yet" as the same answer. *(R-185)*
- **2026-08-03** — Fixed three ways the alarm system misreported itself: a proof of a working backup
that could vanish on a restart (seen happening), a release that emailed a failure for a release
that worked, and a released binary nobody could rebuild and check. *(R-189, R-188, R-186)*
- **2026-08-03** — Backups are now proved one at a time, each about a day after it is made, instead of
on a timer; the "not proved lately" alert learned each copy's own rhythm so it does not complain
about a healthy weekly copy. You settled that the off-site endpoint is protected, and the machine
list records it. One thing found while testing: on the small demo machine the agent cannot see its
own local backups at all — a permission that was never granted — so that copy has never been
test-restored there. Written down, not yet fixed. *(R-86, R-185)*
on a timer; the "not proved lately" alert learned each copy's own rhythm. You settled that the
off-site endpoint is protected. *(R-86)*