76a570da32
Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
44 lines
3.0 KiB
Markdown
44 lines
3.0 KiB
Markdown
# 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).
|