v0.56.0: Phase 4 — FileBrowser scoping + deploy DB-on-SSD note + monitoring descriptions

4A: scope FileBrowser bind to <drive>/appdata (recovery units + Tier 2 copies under
backups/ are no longer mounted into FileBrowser — customer can't browse/delete the
thing that restores them). 4B: deploy storage-selection step states the chosen drive
holds files while the DB runs on the fast internal SSD + is backed up with the app.
4C: buildStorageBars stable sort + purpose description on the monitoring storage list.

Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
This commit is contained in:
2026-06-13 13:35:43 +02:00
parent 88ca1178ae
commit 476a97376f
4 changed files with 46 additions and 3 deletions
+18
View File
@@ -1,5 +1,23 @@
## Changelog
### v0.56.0 — Phase 4: FileBrowser scoping + deploy DB-on-SSD note + monitoring storage descriptions (2026-06-13)
Polish layer closing the slice.
- **4A FileBrowser scoping (safety):** the FileBrowser bind mount is now scoped to each drive's
`appdata/` subtree (`<drive>/appdata:/srv/<name>`) instead of the whole drive root. The recovery
units + Tier 2 copies under `backups/` are therefore **not mounted into FileBrowser at all** — the
customer browses their userdata but cannot reach (or even see) the thing that restores them. The
appdata dir is `mkdir`-ed before the bind so the source exists. (`syncFileBrowserMounts`.)
- **4B Deploy-UI communication:** the storage-selection step now states plainly (Hungarian) that the
chosen drive holds the app's **files**, while its **database runs on the fast internal SSD** and is
backed up alongside the app — so "the DB is on the SSD" stops being a surprise. (`deploy.html`.)
- **4C Monitoring storage list:** `buildStorageBars` now sorts deterministically (by path) and carries a
**purpose description** explaining the user-data drives (rendered on the monitoring "Tárolók
kapacitása" list). Note: this list is the controller's registered user-data drives only (the agent's
local/local-lvm/pbs storage is not in this registry), so the role-tier sort/`local`-vs-`local-lvm`
descriptions belong to the agent-backed storage-management page, not here.
### v0.55.0 — Phase 3: auto off-drive Tier 2 (rootfs-headroom guard, durable off-disk target) (2026-06-13)
Tier 2 = an **off-drive copy** of each HDD app's recovery unit + bulk userdata to a **different physical