Files
felhom.eu/documentation/audits/night-fixes-2026-10-26/README.md
T
admin ae3db89ab3
gates / gates (push) Successful in 1m56s
night fixes 2026-10-26: live proofs (R-1220, R-1232, R-1187, R-1298), register states, design lines; R-1300 filed; R-528 design
Evidence audits/night-fixes-2026-10-26/ (scanned: 0 secret hits).
2026-10-26 22:17:36 +01:00

68 lines
4.9 KiB
Markdown

# Night fixes 2026-10-26 → 27: live proofs (R-1220, R-1232, R-1187, R-1298)
Code on `main`, NOT released (the release block is Tuesday afternoon, attended). Test images were **local only**
(`0.346.0-night1/2/3`, `docker save`/`load` into 9202 — never pushed to the registry); the test agent
(`0.167.0-night1`) was a local build copied to the test VM only. Method: the endpoints the UI invokes, through the box
walk tools (`../catalog-sweep-2026-10-24/tools/`), and the product's own installer / uninstaller.
## R-1220 — an unreadable `app.yaml` counts as installed (controller `7e15a37`)
9202, throwaway Grimmory, its `app.yaml` made unreadable (byte copy saved, put back): after a stack rescan the
„Megőrzött adatok" page did **not** list its drive folder, and the controller logged the R-1220 WARN.
`r1187-r1220-9202-run1.txt` (step 2). PASS.
## R-1232 — a reinstalled box's first whole-box copy is not a week late (agent `3911cc6`)
VM 9375 on demo-hp's scratch NVMe: plain Proxmox (auto-install ISO with DooPlex's key), then the product's BYO installer
as **Tester4** (host `Tester4-b5dbbd`). Tester4's ep0 space held one archive of an EARLIER box (`ct/9201`, 2026-10-20,
key `23:58:…`); this box's key is `7c:3b:…`.
| | Agent | `GET /backup/due?target=felhom-pbs` |
|---|---|---|
| before | 0.166.0 (released) | `due: false`, „within cadence window", age 546,807 s — the foreign archive counted |
| after | 0.167.0-night1 (`main`) | `due: true`, „no successful backup recorded yet", `age_state: absent` |
The controller's first-backup valve then started the first whole-box copy at 20:13:55Z; it completed at 21:15:17 CET
(`ct/9201/2026-10-26T20:13:55Z`, this box's key) — 4 minutes after the swap. `r1232/1-…`, `2-…`, `3-first-run.txt`.
PASS. **Teardown:** the product's uninstall ran (`r1232/uninstall-console.txt`, `UNINSTALL_RC=0`; the first try stopped
at the confirmation prompt — it asks for the guest number, nothing destroyed), then VM 9375 destroyed, its ISO and work
files removed. **The operator deletes hub host `Tester4-b5dbbd`.** Tester4's ep0 space keeps this box's one archive
(a host delete keeps the tenancy, by design).
## R-1187 — the `.fab` export and import (controller `dfd0f8e` … `90a2530`)
9202, throwaway Grimmory (markers inside its bound drive folder `appdata/grimmory/data/cc-r1187`: a file owned
1000:1001 mode 0640, a link inside, a link to `/etc/hostname`):
- (a) a FIFO in the folder → the export **fails**, naming the FIFO's path (`r1187-9202-run2.txt`, `-run3.txt`, step 3);
without it the export carries both links AS links (the tar listing, step 4).
- (b) after the import: the file is back as 1000:1001 mode 640, the inside link is back, the outside link is **refused**
and listed in the import's WARN (run 2 and run 3).
- **Two import defects found by this proof, older than tonight, fixed and re-proven:** run 1 and run 2 ended
„waiting for DB: timeout" and left Grimmory down: (1) the import's compose runs lacked the controller's own
`USERDATA_PATH`/`IMPORT_PATH`, and compose's warning was read as the DB container id (`a3ed63e`); (2) the import used
`mysqladmin`/`mysql`, which the MariaDB 11+ images do not ship, so EVERY MariaDB 11+ import timed out (`90a2530`: the
import now loads through `appbackup.ImportDump`). **Run 3 on `0.346.0-night3`: the import succeeds and the app
answers.** `r1187-9202-run3.txt`.
- (g) AdventureLog (postgis): a superuser made with the app's own `createsuperuser`, export, the user deleted in the live
app, import → the user is back (read through the app's own ORM, `manage.py shell`). My front-door check (the Django
admin login page) answered 302 with no form both BEFORE and after — an instrument that did not reach the form, not a
result. `r1187g-9202.txt`. PASS on the ORM readback.
- (d) and (f): their unit tests are the proof (a running restore cannot be staged safely; a crafted bundle would be a
hand-made input).
## R-1298 — held-app reports only for installed apps (controller `b156e45`)
9202 on `0.346.0-night1`: the reporter skipped its four orphan holds by name („not reported (R-1298)", 0 sent). Then,
the controller stopped, `-clear-restore-hold` for `chaoscrash`, `chaosoom`, `chaosoomb`, `gokapi` → „no restore holds in
force"; PrivateBin's leftover removed through the product (volume, `app.yaml`, backup gone). `r1298/`.
## Teardown
- **9202:** back on 0.343.0 (image file restored, the test images removed); its standing apps only; no holds (the four
orphans cleared on purpose, per the brief); the drive's `appdata/` holds only paperless; no bundles in `exports/`.
- **demo-hp:** VM 9375 destroyed (own id), its ISO removed; nothing else provisioned.
- **Hub:** host `Tester4-b5dbbd` — the operator's delete. **DooPlex:** the local test images removed.
- Secrets: the evidence was scanned (the dashboard passwords, Tester4's passphrase, both hub tokens, the Resend key):
0 hits.