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

REPORT: day 2026-10-23 — controller 0.340.0 released (floor 06:41 UTC, MinAgent 0.158.1)
gates / gates (push) Successful in 1m28s
Details

Browse Source
This commit is contained in:
authentik Default Admin
2026-10-23 11:07:44 +02:00
parent caaa86eb3c
commit 32e61d5d1d
1 changed files with 22 additions and 53 deletions
Download Patch File Download Diff File Expand all files Collapse all files
REPORT.md
+22 -53
View File
@@ -1,59 +1,28 @@
# REPORT — night 2026-10-22 → 23: the stray-copy fix and the review fixes, nothing released
# REPORT — day 2026-10-23: controller 0.340.0 released (the operator's „go")
**What:** the night brief's controller parts (Part 1, the controller findings of Part 3). No release, no floor change.
Design read: `07-backup-architecture.md` §6.3, §8 (R-1180's guard), now §8.2b.
**What:** the day brief's Part 1. Design read: `07-backup-architecture.md` §6.3, §8; `09-update-architecture.md` §3
decision 250 (a release needs no golden; the floor carries it, MinAgent declared).
## Part 1 — the stray-copy fix (`66a69d4`, `912e592`)
## Release
The capped second-drive copy (R-1214) runs `rsync -a --delete` in its own container. A timeout, a controller restart
or a self-update killed only the `docker` CLI — the container went on deleting, outside every guard the controller
holds. Now:
- each copy container has a fixed name (`felhom-tier2-copy-<app>-<8 hex>`) and the label `felhom.tier2-copy=1`;
- a leftover of the same copy is removed before a new one starts; on any error, the timeout included, it is removed by
name;
- at start, BEFORE the scheduler and the web server, every labelled container is removed (each logged; retried every
minute until it succeeds; restores refused meanwhile);
- a restore is refused while any second-drive copy runs or a leftover may run;
- review C4/C7 in the same function: `--mount` (a path the daemon does not see is refused instead of created empty),
the controller's image ID with `--pull never`; `--no-healthcheck` (the 9202 proof showed the inherited health check).
- Main at `caaa86e` (the CHANGELOG header `## v0.340.0 … MinAgent: 0.158.1`; the four night sections now under it).
CI 2245 success. The operator answered „release main" for the text-only commits after the night-tested ones.
- Image `gitea.dooplex.hu/admin/felhom-controller:0.340.0`, digest
`sha256:a8d1c6458da4ea9d667f928498656a291771e0b3756b20f2fcc8c1cf9d516621`.
- 9202 smoke first (healthy, 0 errors, `/login` 200, start-up „no leftover").
- Per-customer floors for Tester 1, demo-hp, demo-felhom (303 `floor_set` each) → all three on 0.340.0 through the
normal update path: Tester 1 10 containers, demo-hp 24, N100 9; 0 unhealthy, 0 errors, 0 copy containers, each with the
start-up „no leftover" line. `https_only_check.py` rc 0, 28 OK, the negative control convicted.
- „Fájlok ↗" on Tester 1: `/__files/open` → 302 to `files.enkicsifelhom.hu/_felhom/sso`. Tester 1's manual second-drive
run: 3 apps, 0 copy containers left. demo-hp and demo-felhom: checked only without a session (302 /login) — no
dashboard password is held for them; their first night copy is tonight.
- Global floor 0.340.0, MinAgent 0.158.1: 303 `floor_set` at 06:41:04 UTC; the per-customer floors cleared; read back
from the hub DB with its WAL.
**Tests** (Docker-free seams): `TestStrayCopy_*` — 8 in `internal/backup`, 1 web, 1 wiring; each seen failing with its
mechanism removed. **9202 proof** (felhom.eu `audits/night-2026-10-23/P1-straycopy/`): rc.5; a controller restart in
the middle of a 16 GB copy → the new controller removed `felhom-tier2-copy-immich-948f2280` at start; a restore probe
during the copy was refused; the redone copy equals the source (54 s); a 15 s test build (rc.5 + a binary with the
limit set by ldflags, never pushed) → the timed-out container removed, the partial copy stopped growing. 9202 back on
0.339.0, test files and the test image removed.
## What it carries
## Part 3 — review findings (controller), verified at file:line
The stray-copy fix and the night's review fixes (R-1214, R-49 D21 = B, R-1187 c, R-1189 d, C3–C8, N2–N5, N9, S1, S2) —
see `CHANGELOG.md` v0.340.0. R-49 closed; R-1214 stays open for one dated check (2026-10-24: Tester 1's first night copy
in the capped container, memory „full" pressure under 20 %); R-1187 and R-1189 keep their unfixed parts.
| # | Finding | Verdict |
|---|---|---|
| C1 | the copy container outlives the CLI | REAL → fixed (Part 1) |
| C2 | two more import paths merge old and new data | REAL, pre-existing in 0.339.0 → R-1187 (recovery code: red-proof + 9202 proof first); not a hold |
| C3 | the R-1187 (c) refusal also catches an unhealthy app, with wrong advice | REAL → text fixed (`943c517`); the import path → R-1187 |
| C4 | `-v` creates a missing path on the daemon side | REAL → `--mount` (`66a69d4`) |
| C5 | the catch-up holds the whole-guest backup while its slow checks run | REAL → fixed (`943c517`, `TestC5_*`, red-proved) |
| C6 | two comments overstate the proof's catch-up | REAL → fixed |
| C7 | the image tag, not its ID; no `--pull never` | REAL → fixed; „no memory cgroup → uncapped": NOT-A-FINDING (every Felhom guest is an LXC on a cgroup-v2 Proxmox kernel; the guest's own memory figures come from it) |
| C8 | README: „out of every backup" | REAL → fixed (the `.fab` export and the whole-guest snapshot still hold it) |
## The second review (tonight's own code) and the commits' security review
| # | Finding | Verdict |
|---|---|---|
| N2 | one failed `docker rm` refused every restore until a restart | REAL → per-name strays, cleared by a later removal (`9d9e404`) |
| N3 | the start-up retry removed this process's own copies | REAL → `running` names skipped (`9d9e404`) |
| N4 | a second copy into the same destination killed the first | REAL → one copy per destination at a time (`9d9e404`) |
| N5 | `RunTier2` from the „Tier 2 on" save ignored a running restore | REAL, pre-existing → refused for every caller (`9d9e404`) |
| N9 | the import refusal advised removing an unhealthy app | REAL → „kérd az üzemeltető segítségét" (`9d9e404`) |
| S1 | the start-up removal could hit a copy starting between list and remove | REAL → the destination's lock (TryLock) (`1babfe9`) |
| S2 | a restore beginning between the copy's check and its record | REAL → one step under the restore record's lock, every leg asks again (`1babfe9`) |
Each with a test seen failing first; `-race` clean. **Re-proven on 9202 with rc.8** (felhom.eu
`audits/night-2026-10-23/P1-straycopy/1*`): two runs into the same destination → the second waited, no kill, no failure;
the restart mid-copy and the restore refusal as before; the redo equal to the source. Also corrected: the comment on
`OffsiteStateAwaitingRecoveryKey` claimed the hub's delivery check skips a held box — measured false on the test night
(felhom.eu R-1230, fixed in the hub).
**Images:** `0.340.0-rc.5` (= `66a69d4`), `0.340.0-rc.6` (= `943c517`), `rc.7` (= `9d9e404`, not used), `rc.8` (= `1babfe9`, on 9202 and on the test box for the night). CI: `66a69d4` 2227,
`912e592` 2228 green; `943c517` and the docs commit: see felhom.eu `REPORT-night-2026-10-23.md`.
Evidence: felhom.eu `documentation/audits/day-2026-10-23/01`–`06`. Full day: felhom.eu `REPORT-day-2026-10-23.md`.