From 260d5d4880cb62d942eff64c517d1c49375540c9 Mon Sep 17 00:00:00 2001 From: Mitchell-Johnson Date: Thu, 24 Sep 2026 12:39:51 -0700 Subject: [PATCH] =?UTF-8?q?PLAN:=20the=20KVM=20is=20a=20Sipeed=20NanoKVM?= =?UTF-8?q?=20at=2010.0.0.217=20=E2=80=94=20framing=20is=20fine,=20HTTP=20?= =?UTF-8?q?is=20the=20blocker?= MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Co-Authored-By: Claude Opus 5 --- PLAN.md | 56 +++++++++++++++++++++++++++++++------------------------- 1 file changed, 31 insertions(+), 25 deletions(-) diff --git a/PLAN.md b/PLAN.md index 2f5372a..4b9cde2 100644 --- a/PLAN.md +++ b/PLAN.md @@ -553,31 +553,37 @@ something long in one, switch away and back, refresh — it's all still there. item names the heavier pieces (multi-select and bulk actions, folder download, resumable uploads, a gallery, search) — worth doing the two together, since they are the same tab. -- **A KVM tab** — asked for 2026-09-24, not started. A tab that shows a **custom IP-KVM's - own web page** inside Ham Lab, so the machine's screen, keyboard and mouse are one click - away. **This is KVM the keyboard-video-mouse switch, not KVM the hypervisor** — the - Virtualization item above means the other one, and the two must not be confused when - either is built. No such device exists in the lab yet, so this starts with the hardware - (PiKVM, JetKVM, TinyPilot, or the home-built one Mitchell has in mind). - - **Where the entry lives is the design decision.** A KVM earns its keep exactly when the - machine is *down* — no OS, a bad kernel, a BIOS screen — which is when that host's Ham - Lab cannot answer. So the tab has to be **hub-side**, a list the hub holds, and it must - work for machines that run no Ham Lab at all. Configuring it as a `kvm_url` inside each - node's own `config.json` would fail in precisely the case it is for. - - **Framing is the first thing to test, before any UI is written.** Most IP-KVMs send - `X-Frame-Options: DENY` or `frame-ancestors 'none'` and simply refuse to be embedded — - Ham Lab sends both itself, on its own pages. A device whose nginx can be edited (PiKVM) - or that is home-built can be told to allow it; one that cannot will show a blank box, - and then the honest answer is a link that opens it in a tab rather than a fake embed. - - **Mixed content and certificates.** Ham Lab is served over HTTPS through NPM. A KVM on - plain HTTP will be blocked by the browser outright, and one with a self-signed - certificate fails silently inside an iframe. Either give it a proper cert and an NPM - host, or proxy it through the daemon — which already reverse-proxies nodes and carries - WebSockets (`proxyNode`), and a KVM's video and input streams are exactly that. Proxying - also solves the separate login, since the credential could be held once on the hub. - - Worth settling too: whether the tab is per machine (a machine's KVM shown on its page) - or one page listing every KVM; and whether a machine with no Ham Lab at all deserves a - first-class entry on the Machines page, which today only knows hosts that answer. +- **A KVM tab** — asked for 2026-09-24, not started. A tab that shows the **IP-KVM's own web + page** inside Ham Lab, so a machine's screen, keyboard and mouse are one click away. **This + is KVM the keyboard-video-mouse switch, not KVM the hypervisor** — the Virtualization item + above means the other one, and the two must not be confused when either is built. + - **The device**: a **Sipeed NanoKVM**, attached to `grid`, at **`10.0.0.217`** (MAC + `48:da:35:6f:d0:31`), serving a web UI on port 80. The only one in the lab so far, so the + tab must be built for a list of them, not hard-wired to one. + - **Framing works.** Probed 2026-09-24: the NanoKVM sends **no `X-Frame-Options` and no + `frame-ancestors`**, so unlike most of its competitors it does not refuse to be embedded. + An iframe is a real option and the fallback of "just link out" is not needed. + - **Mixed content is the actual blocker.** The NanoKVM is **HTTP only** — there is no + HTTPS listener at all — and Ham Lab is served over TLS, so a browser will refuse the + iframe outright. Something must give it HTTPS. Two routes: + - **Proxy it through the daemon**, which is the better one. Ham Lab already + reverse-proxies nodes over WebSockets (`proxyNode`), which is exactly what the KVM's + video and input streams need, and it puts the KVM behind **Ham Lab's own login** rather + than a second one. `/api/vm/info` answers **401**, so the device has its own auth; the + hub could hold that credential once instead of prompting per person. + - **Or an NPM proxy host** (`scripts/npm-proxy-host.sh`), which is two minutes of work — + but note what it means: `*.bigham.dev` is a wildcard to the public IP, so that would put + **BIOS-level keyboard and screen access to `grid` on the public internet** behind + whatever the KVM's own login is worth. If that route is taken it wants an NPM access + list or a LAN/WireGuard-only binding, decided deliberately. + - **Where the entry lives is still the design decision.** A KVM earns its keep when the + machine is *down* — no OS, a bad kernel, a BIOS screen — which is when that host's Ham Lab + cannot answer. So the list has to be **hub-side** and must work for machines running no + Ham Lab at all. A `kvm_url` inside each node's own `config.json` would fail in precisely + the case it exists for. + - Worth settling too: whether the KVM shows on its machine's page or on one page listing + every KVM; and whether a machine with no Ham Lab deserves a first-class entry on the + Machines page, which today only knows hosts that answer. ## Open questions