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

controller v0.119.0: storage-health coherence F8 + mapped_uid F4 — docs + CHANGELOG + REPORT + CONTEXT

Browse Source 
F8: share row fuses the shipped v0.117 classifier (fuseNetHealth) so it agrees with
the stacks stub badge (one classification, two surfaces). F4: mapped_uid range check
1..65533 at the door. §3 fork = option B (controller-only). Live-validated on 9201.

Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_017CDMFpFx84pfviCTVuGGhf
This commit is contained in:
authentik Default Admin
2026-07-12 09:44:22 +02:00
parent 5d91fc8cce
commit a6da64da15
4 changed files with 98 additions and 45 deletions
Download Patch File Download Diff File Expand all files Collapse all files
CHANGELOG.md
+28
View File
@@ -1,5 +1,33 @@
## Changelog
### v0.119.0 — storage-health coherence (F8) + mapped_uid validation (F4) (2026-07-12) — MinAgent: 0.81.0
Fixes CAMPAIGN-3 (`felhom.eu/documentation/audits/CAMPAIGN-3-2026-07-11.md`) storage-UI findings.
MinAgent UNCHANGED (0.81.0) — controller-only; the §3 design fork took the recommended option **B**
(reuse the shipped v0.117.0 classifier), so no agent change.
- **F8 (MED) — one classification, two surfaces.** The share row's health used to come only from the
agent's SERVER-LEVEL TCP dial (`server:2049/445`), which stays green when a *single* export is
`exportfs -u`'d — so the row showed benign "Készenlét" while the stacks/dashboard already showed the
stub reality. `networkStorageItems` now FUSES the agent view with the consuming-namespace
classification (`fuseNetHealth` → the same `system.ClassifyPathFS` the stacks stub badge reads): a new
`stub` health state wins over a benign idle/ok when the namespace sees local disk at `Where`; a
whole-server `unreachable` still wins over stub; autofs-healthy / network / inconclusive `unknown`
leave the agent health untouched (never manufacture a fault, never force-mount an idle trigger). The
row badge for `stub` = "Hibás — az alkalmazások nem a NAS-t látják". The row and the stacks/dashboard
badge now derive from ONE classification and can never contradict.
- **F4 (LOW) — mapped_uid/gid validated at the door.** `handleNetStorageAdd` range-checks the container
uid/gid (1..65533) after the `<=0` default, BEFORE the job starts. Out of range → an immediate,
friendly Hungarian 400 ("Az alkalmazás felhasználói azonosítója (uid) érvénytelen…"), nothing
installed — the campaign's `mapped_uid:101000` (a host-side mapped value) previously slipped past the
controller and failed only at the agent with a raw `agent_error`.
- **Live-validated (demo 9201):** F8 — `exportfs -u` while idle + drop-mount → the share row flipped to
`stub`/"Hibás — az alkalmazások nem a NAS-t látják" AND the stacks stub badge showed (4), the two
surfaces AGREE; re-export → row cleared to `ok`/"Elérhető" (healthy idle NOT downgraded). F4 —
`mapped_uid:101000` → 400 + friendly message, registry unchanged; `mapped_uid:1000` passed the range
check. Tests incl. the F8 fusion companion (revert → row idle → fail), the autofs-not-stub guard, and
the F4 boundary (65533 pass / 65534 fail), all green.
### v0.118.0 — backup integrity: atomic volume dumps (F7) + no single-copy (F6) + stale-primary sweep (F5) (2026-07-12) — MinAgent: 0.81.0
Fixes CAMPAIGN-3 (`felhom.eu/documentation/audits/CAMPAIGN-3-2026-07-11.md`) backup findings. MinAgent