From e558ca7ace3b6f503aabb180e51a53a88f17f7c9 Mon Sep 17 00:00:00 2001 From: Mitchell-Johnson Date: Tue, 22 Sep 2026 16:47:34 -0700 Subject: [PATCH] =?UTF-8?q?PLAN:=20to=20do=20=E2=80=94=20a=20public=20down?= =?UTF-8?q?load=20page=20and=20an=20updater=20that=20uses=20it?= MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Co-Authored-By: Claude Opus 5 --- PLAN.md | 29 +++++++++++++++++++++++++++++ 1 file changed, 29 insertions(+) diff --git a/PLAN.md b/PLAN.md index 1a5f973..d5c97c6 100644 --- a/PLAN.md +++ b/PLAN.md @@ -321,6 +321,35 @@ something long in one, switch away and back, refresh — it's all still there. `POST /api/password`, current password required), Access tokens (list/revoke the tokens hubs hold), About (version, host, arch, uptime, certificate). +## To do + +- **A public download page, and an updater that uses it** — asked for 2026-09-22, not + started. Today a release is *published* but not *offered*: `make publish` writes five + architectures, `SHA256SUMS`, `VERSION` and `install.sh` into + `/home/core/apps/hamlab-demo/site/dl/` (public at `https://hamlab-demo.bigham.dev`), and + the only way in is `curl -fsSL https://hamlab-demo.bigham.dev/install.sh | sh`. Updating + an existing install is a *hub* pushing its own binary to machines it manages + (`POST /api/self-update`, `hamlab push-nodes`, the Update buttons on the Machines page) — + which does nothing for an install that no hub of mine owns. Two halves: + - **The page.** A human-facing page at the download site: current version and when it was + built, a row per architecture with its size and checksum, the one-line install, and how + to update. Today `/dl/` is a bare directory listing. It should be generated by + `make publish` from the same VERSION and SHA256SUMS the release already writes, so it + cannot drift from the binaries beside it, and it should say plainly that the binaries + are unsigned and served over TLS from my own box. + - **The updater.** A Ham Lab anywhere asks the download site what the current version is, + says so in the UI when it is behind (the About card, and probably a rail badge like + Alerts has), and updates itself on request: fetch the binary for its own architecture, + check it against `SHA256SUMS`, then the same path `POST /api/self-update` already + takes — verify it runs, install atomically, re-exec in place. Decisions to make when it + is built: where the check lives (a `update_url` in `config.json`, defaulting to the + public site, so someone else's install can point elsewhere or switch it off); how often + it asks (daily is plenty, and it must be possible to say never); whether it ever updates + unattended (default no — an update restarts the daemon and drops open terminals); and + whether a hub offers to update its machines from the site when it is itself behind. + Downgrades are already refused by the installer's `vnum()` comparison; the updater + should use the same rule. + ## Open questions - Idle-session reaping policy (never / after N days) — leaning never; it's a