Files
felhom-controller/REPORT.md
T
2026-06-12 21:08:27 +02:00

44 lines
3.0 KiB
Markdown
Raw Blame History

This file contains ambiguous Unicode characters
This file contains Unicode characters that might be confused with other characters. If you think that this is intentional, you can safely ignore this warning. Use the Escape button to reveal them.
# REPORT — felhom-controller v0.51.0
Offsite-backup UI (felhom-pbs = real DR) + Model-A double-nest fix. Pairs with felhom-agent v0.28.0
(whole-guest backup re-targeted to the offsite PBS tier). Live-deployed in guest 9201 on demo-felhom.
## Backups page — whole-guest backup shown as real DR
- `backupTargetLabel` returns **"Biztonsági szerver külön hardver (PBS)"** for a PBS-stored backup
(detected via `backupIsPBS` on the target id / archive volid), so the customer sees the backup
survives a host hardware failure.
- The app-data section's **"Távoli mentés"** card stops reading "nincs beállítva": new
`guestBackupView.Offsite` flag drives it to **"külön hardveren (PBS)"** with a ✓ when the whole-guest
backup landed on PBS.
- The restore-test "Visszaállítás ellenőrizve" trust signal is unchanged (already wired).
- Live: agent `/backup/status` reports `target_id=felhom-pbs`; `/restore-test/status` reports
`pass:true, verified:"boot+running", source_tier:"pbs"` → the page renders the PBS label, the offsite
card, and verified-restorable.
## Model-A double-nest fix
- Under slice-10 Model A the host agent binds `<drive>/felhom-data` onto the guest mountpoint, so an
enrolled drive's in-guest mount IS the felhom-data namespace root (basename need not be `felhom-data`,
e.g. `/mnt/felhom-usb`). The backup path helpers were re-prepending `felhom-data`, producing
`.../felhom-data/felhom-data/...` on the host (confirmed live: `/mnt/felhom-usb/felhom-data/felhom-data/...`).
- `appbackup` path helpers now take a **namespace ROOT** (no internal `felhom-data` join) plus a new
`NamespaceRoot(drivePath, inGuestDrive)`. `backup.Manager.namespaceRoot`/`AppNamespaceRoot` resolve
provenance (`drivePath != systemDataPath` ⟺ a registered in-guest drive → namespace root as-is; the
SSD-only `systemDataPath` fallback appends `felhom-data`).
- All parallel constructions updated coherently so writes, deletion (`GetStackBackupData`,
`RemoveStack` backups-base + `ProtectedHDDPaths` — legacy double-nest dirs KEPT protected), the
wipe-warning secondary scan, and export all agree. `api.router` passes the namespace root across the
package boundary. Result: a drive-resident app's DB-dump lands single-nested at `<drive>/backups/...`
in-guest = `<drive>/felhom-data/backups/...` on the host.
- New `appbackup` test asserts no doubled `felhom-data` segment for an in-guest drive and exactly one
for the system fallback. Full `go build ./...` + tests green.
## Decommission (P3) — NO controller change
- Permanent decommission is operator-signature-gated (never customer-confirmable), so it is wired
entirely agent-side (hub jobs-queue → signed-jobs runner). The controller deliberately exposes no
decommission UI. (felhom-agent v0.28.0.)
## Live deploy
- `gitea.dooplex.hu/admin/felhom-controller:0.51.0` running + healthy in guest 9201 (bootstrap-launched
via `/etc/felhom-controller-image`; prior 0.50.0). Startup clean (catalog sync, health ok,
FileBrowser mounts synced).