Files
felhom.eu/documentation/operations/nodes.md
T
admin 8ec45f3b42 docs: node inventory for the two-host fleet; demo-hp on the tailnet
New documentation/operations/nodes.md: HP t740 hardware, disks (SanDisk system
SSD 182195804614; Toshiba 1TB NVMe 58BS11AFT8MQ PRESENT AND UNENROLLED, still
NTFS, do not touch), the five-NIC map and the trap that cost the first install,
and the access path - no SSH key is baked, auth is the hub-vaulted G1
break-glass password.

tailscale.md gains demo-hp, the operator-lab-exception warning so a future
product-shape audit does not conclude the product ships tailscale, and the
--accept-dns evidence: the join omitted the flag, MagicDNS rewrote
/etc/resolv.conf, and it was reverted. Harmless at the vacation site, would
have bitten silently at home where split-horizon matters.

OPEN: key expiry still enabled on demo-hp (2027-01-17) - needs an admin-console
toggle or an API token; a pre-auth key cannot do it.
2026-07-21 18:51:05 +02:00

105 lines
5.4 KiB
Markdown

# Fleet node inventory — the physical demo/lab hosts
> Added 2026-07-21, when the fleet stopped being one box. Two Proxmox hosts now check in to the hub.
> This is the operator-facing inventory: what the hardware is, how to reach it, and what is
> deliberately NOT enrolled on it.
## The fleet
| | `demo-felhom-8363b5` | `demo-hp-bb76ea` |
|---|---|---|
| Hardware | N100 mini-PC | **HP t740 Thin Client** (s/n `8CN944035T`) |
| CPU / RAM | Intel N100 | **AMD Ryzen Embedded V1756B**, 8 threads / **30 GiB** |
| Firmware | AMI AN3PLUS-class | **AMI M42 v01.10 (11/11/2020)** |
| PVE node name | `demo-felhom` | `felhom-host` |
| Customer | `demo-felhom` | `demo-hp` |
| Agent | 0.92.1 | 0.92.1 |
| SSH alias | `felhom-pve` | **`demo-hp`** |
| Tailnet | `100.70.170.35` | **`100.76.96.79`** |
| Loader used to install | `mkimage` (unsigned, SB **off** — firmware workaround) | **`shim`, Secure Boot ENABLED** |
**Both are at the VACATION site** and travel home with the rest of the kit **~2026-08-02**. While
away, their LAN addresses are on that site's `192.168.0.0/24`: N100 `.147`/`.162`, HP `.87`. The
tailnet addresses are the stable ones — use those.
## demo-hp — the HP t740, in detail
### Disks
| device | model | serial | role |
|---|---|---|---|
| `sda` | SanDisk X600 M.2 2280 SATA 128GB | `182195804614` | **system disk** — PVE, LVM (`pve-root` 39.6G, `pve-data` thin pool, guest 9201's three volumes) |
| `nvme0n1` | KXG50PNV1T02 NVMe TOSHIBA 1024GB | `58BS11AFT8MQ` | **PRESENT AND UNENROLLED — do not touch** |
> **The NVMe is a future Tárhely candidate and is deliberately outside everything.** It still holds
> its previous **NTFS** partition, is not mounted, and appears in no LVM PV and no ZFS pool. The
> install ISO's exact-serial filter pinned `sda` only, which is why it survived. **It joins the
> product later through the normal Tárhely (storage) flow — never through the installer, and never
> by hand.** Anything that formats it before that decision is a mistake.
### NIC map — and the trap
This board has **five wired interfaces**, and the obvious one is the wrong one:
| interface | MAC | driver | what it is | state at this site |
|---|---|---|---|---|
| `enp1s0f0` | `a0:36:9f:5d:07:20` | `igb` | 4-port expansion card | no carrier, **no DHCP** |
| `enp1s0f1` | `a0:36:9f:5d:07:21` | `igb` | ″ | no carrier |
| `enp1s0f2` | `a0:36:9f:5d:07:22` | `igb` | ″ | no carrier |
| `enp1s0f3` | `a0:36:9f:5d:07:23` | `igb` | ″ | no carrier |
| **`enp2s0f0`** | `7c:d3:0a:77:d9:76` | `r8169` | **onboard port — the one that works** | carrier up, 1000 Mb, **this is `vmbr0`'s port** |
| `wlo1` | `24:ee:9a:e5:05:b0` | `iwlwifi` | wifi | unused |
**This trap cost the first install.** The 4-port card got no lease, and instead of aborting the
installer baked its `192.168.100.2` fallback as a **static** `vmbr0` address and completed — a box
that looked installed and could never call home. Repaired on the console by bridging `vmbr0` to
`enp2s0f0`. Filed as **R-59** (must hard-abort) and **R-60** (first-boot NIC sweep self-heal).
Current, post-repair: `vmbr0` static `192.168.0.87/24`, gw `192.168.0.1`, bridge-port `enp2s0f0`.
No trace of `192.168.100.2` remains. `wg-felhom` `10.77.0.3/32` up to the hub. Guest **9201
`demo-hp`** running.
### Access — there is no baked SSH key
`ssh demo-hp` resolves to the tailnet address, but **no operator public key is on this box** — the
HP profile deliberately left `FELHOM_ROOT_SSH_KEY` blank. Authentication is the **G1 break-glass
root password vaulted in the hub**, `host_recovery` row `demo-hp-bb76ea` (set at day-0,
2026-07-21 16:24 UTC).
Retrieval (operator-side, and **shred the copy** — that DB holds every host's secret):
```bash
sudo kubectl -n felhom-system exec <hub-pod> -- cat /data/hub.db > /tmp/x.db
python3 -c "import sqlite3;print(sqlite3.connect('/tmp/x.db').execute(
\"SELECT secret FROM host_recovery WHERE host_id='demo-hp-bb76ea'\").fetchone()[0])"
shred -u /tmp/x.db
```
Then `sshpass -e ssh root@demo-hp` (sshpass is on DooPlex, not on the nodes).
**This is the lockout filed as R-61**: the ISO mints a throwaway root password per build and discards
the plaintext, so the console is unreachable without a working hub and network — precisely what you
may be trying to fix. Slice 1 is to emit the baked password into the build report.
`demo-hp-lan` (`192.168.0.87` via `ProxyJump felhom-pve`) is the fallback while the box is away.
## Tailscale on demo-hp is an OPERATOR-LAB EXCEPTION
> **Read this before any product-shape audit.** `demo-hp` is **customer-shaped** — it is a normal
> appliance install with a real customer record (`demo-hp`), a real guest, and a real day-0.
> **Tailscale is not part of that shape.** It was installed by hand on 2026-07-21 purely so the
> operator can reach a lab box that lives on someone else's LAN.
>
> **Real customer boxes never get tailscale.** Their operator access is the WireGuard tunnel plus
> the H1 OOB path, and nothing else. If a future audit finds tailscale on `demo-hp` and concludes
> the product ships it — that conclusion is wrong, and this paragraph is the reason. The same
> exception already applies to `felhom-pve`.
Details, and the two hard rules that apply to any host node, in `operations/tailscale.md`.
## What is NOT enrolled here (deliberately)
- The **1TB NVMe** on demo-hp — see above.
- **No PBS datastore, no offsite target** on demo-hp yet; the DR tier is the N100's.
- **No second customer guest** beyond 9201.