mitchell/hamlab
1
0
Fork 0
Code Issues Pull Requests Packages Projects Releases 14 Wiki Activity

PLAN: the KVM is a Sipeed NanoKVM at 10.0.0.217 — framing is fine, HTTP is the blocker

Browse Source 
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
This commit is contained in:
Mitchell-Johnson
2026-09-24 12:39:51 -07:00
co-authored by Claude Opus 5
parent 72c7f45e19
commit 260d5d4880
1 changed files with 31 additions and 25 deletions
Download Patch File Download Diff File Expand all files Collapse all files
PLAN.md
+31 -25
View File
@@ -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