infra: join ludo-mini to hubris as Homelab cluster node "strong"
Reformatted the ludo-mini workstation to Proxmox VE 9.2.3 and joined it to hubris's existing single-node "Homelab" cluster (2 nodes, no QDevice yet). Added a second NVMe as its own LVM-thin pool (ludo-lvm). Renamed the wiki/inventory identity from ludo-mini to strong to match the OS/ cluster hostname, since bootstrap's client-enrollment lookup depends on that match. Also regenerated hosts/grimmory.yaml, which was missing from git despite being referenced by inventory.yaml. Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
This commit is contained in:
107
hosts/strong.md
Normal file
107
hosts/strong.md
Normal file
@@ -0,0 +1,107 @@
|
||||
# `strong` — Proxmox host
|
||||
|
||||
Second node in the `Homelab` cluster, alongside [hubris](hubris.md). Formerly
|
||||
a Linux dev workstation nicknamed "ludo" (or "ludo-mini") — reformatted to
|
||||
Proxmox VE on 2026-07-01. No LXCs/VMs deployed on it yet.
|
||||
|
||||
## At a glance
|
||||
|
||||
- **Role:** Proxmox VE 9.2.3 cluster member (kernel `7.0.12-1-pve`)
|
||||
- **Naming:** the OS/cluster hostname is `strong` (leftover from install,
|
||||
kept as-is). This wiki page and `inventory.yaml` also use `strong` as of
|
||||
2026-07-01 — earlier the same day the inventory entry was briefly named
|
||||
`ludo-mini`, but that was renamed so the hostname bootstrap needs
|
||||
(`hosts/$(hostname).yaml`) would just resolve. "Ludo"/"ludo-mini" remains
|
||||
the machine's everyday nickname; some older docs (investigations, the
|
||||
library-SSD migration plan) still refer to it that way — that's fine,
|
||||
those are historical.
|
||||
- **Hardware:** AMD Ryzen 7 PRO 6850U, 16 threads, 28 GiB RAM.
|
||||
- `nvme0n1` — MasonSemi MC3100 1TB (boot/OS): `pve-root` 96G, `pve-data`
|
||||
(thinpool) 815G, 8G swap.
|
||||
- `nvme1n1` — WD_BLACK SN7100 2TB, added 2026-07-01. Arrived with an
|
||||
existing APFS partition (previously used in a Mac) — wiped via
|
||||
`pvesh set nodes/strong/disks/wipedisk --disk /dev/nvme1n1`, then turned
|
||||
into its own LVM-thin pool via `pvesh create nodes/strong/disks/lvmthin`
|
||||
(handles pvcreate/vgcreate/lvcreate + storage.cfg registration in one
|
||||
step). Registered as Proxmox storage `ludo-lvm` (VG `ludo-lvm`, thinpool
|
||||
`ludo-lvm`, ~1.8 TiB usable — kept the `ludo-lvm` name since that's what
|
||||
was actually created live; not worth renaming), restricted `nodes strong`
|
||||
in `/etc/pve/storage.cfg` — same pattern as hubris's `library` pool.
|
||||
Empty so far; this is separate from the [library-SSD migration
|
||||
plan](../.hermes/plans/2026-06-03_110000-library-ssd-migration-to-ludo-mini.md)'s
|
||||
planned drive move from hubris (that hasn't happened) — this is
|
||||
general-purpose VM/CT capacity.
|
||||
- **Network:** `vmbr0` is bridged straight onto the household LAN —
|
||||
`192.168.178.181/24`, gateway `192.168.178.1`. Unlike hubris, there is no
|
||||
internal/uplink bridge split yet — `vmbr0` here plays the role hubris's
|
||||
`vmbr1` plays there. Reachable from the homelab subnet (`192.168.8.0/24`)
|
||||
via the existing Fritz!Box static route through hubris; no new cabling
|
||||
or routing was needed to join the cluster.
|
||||
- **Storage:** `local` + `local-lvm` (cluster-wide default names, shared
|
||||
with hubris by convention, actually separate per-node volumes). Hubris's
|
||||
`library` lvmthin pool is restricted to `nodes hubris` in
|
||||
`/etc/pve/storage.cfg` and does not exist here.
|
||||
- **Mesh:** Netbird not installed — fresh OS wiped whatever the old
|
||||
workstation had. Reachable today only via LAN routing (confirmed DNS for
|
||||
`*.hubris.network` already resolves correctly here via `192.168.8.2`).
|
||||
Add to Netbird if off-LAN access to this host itself (distinct from any
|
||||
future guests) is needed.
|
||||
- **Homelab-context client enrollment:** not done yet — no
|
||||
`/opt/homelab-context`, no age key, no `homelab` CLI. Separate from the
|
||||
Proxmox cluster join. See [agent-enrollment.md](../operations/agent-enrollment.md).
|
||||
|
||||
## Cluster membership
|
||||
|
||||
Joined hubris's single-node cluster (`Homelab`) via `pvecm add` on
|
||||
2026-07-01. See [hosts/hubris.md#cluster](hubris.md#cluster) for the full
|
||||
cluster picture, node IDs, and the quorum tradeoff (2 nodes, no QDevice —
|
||||
either node going down freezes management on the survivor).
|
||||
|
||||
## SSH
|
||||
|
||||
Root login via the same key set trusted on hubris (`root@hubris`,
|
||||
`d.toro.v@pm.me`) — installed 2026-07-01 by appending to
|
||||
`/root/.ssh/authorized_keys` (now symlinked to `/etc/pve/priv/authorized_keys`
|
||||
post cluster-join, so it's cluster-synced same as hubris). No password auth
|
||||
needed going forward.
|
||||
|
||||
## Related
|
||||
|
||||
- [hubris — Proxmox host](hubris.md)
|
||||
- [Library SSD migration plan](../.hermes/plans/2026-06-03_110000-library-ssd-migration-to-ludo-mini.md) — the larger project this is Phase 1 of (filename kept as-is, historical)
|
||||
- [Network](../infrastructure/network.md)
|
||||
- [SSH access](../infrastructure/ssh-access.md)
|
||||
- [Agent enrollment](../operations/agent-enrollment.md)
|
||||
|
||||
## Changelog
|
||||
|
||||
### 2026-07-01 — inventory identity renamed ludo-mini → strong
|
||||
Discovered while starting client enrollment: `bootstrap.sh` looks up
|
||||
`hosts/$(hostname).yaml`, and the OS hostname here is `strong`, not
|
||||
`ludo-mini`. Renaming the OS hostname was ruled out (already a cluster
|
||||
member — Proxmox doesn't support in-place node rename, only leave+rejoin).
|
||||
Renamed the wiki/inventory side instead: `inventory.yaml` key, this page
|
||||
(`hosts/ludo-mini.md` → `hosts/strong.md`), README, ssh-access.md all now
|
||||
say `strong`. "Ludo"/"ludo-mini" is still fine as a spoken nickname.
|
||||
|
||||
### 2026-07-01 — 2nd NVMe added; new LVM-thin pool `ludo-lvm`
|
||||
User added a WD_BLACK SN7100 2TB (`nvme1n1`), previously used in a Mac
|
||||
(arrived with an EFI + APFS partition table — confirmed disposable, wiped).
|
||||
Used Proxmox's own disk-management API rather than raw LVM commands:
|
||||
`pvesh set nodes/strong/disks/wipedisk --disk /dev/nvme1n1` to clear the old
|
||||
partition table/signatures, then `pvesh create nodes/strong/disks/lvmthin
|
||||
--name ludo-lvm --device /dev/disk/by-id/nvme-WD_BLACK_SN7100_2TB_251663803202
|
||||
--add_storage 1` to create the PV/VG/thinpool and register it as Proxmox
|
||||
storage in one step. Result: storage ID `ludo-lvm`, ~1.8 TiB, `content
|
||||
rootdir,images`, `nodes strong` (mirrors hubris's `library` node-restriction
|
||||
pattern — this pool only physically exists here). Empty — no VM/CT disks
|
||||
placed on it yet.
|
||||
|
||||
### 2026-07-01 — Proxmox install; joined Homelab cluster
|
||||
Reformatted from Linux workstation to Proxmox VE 9.2.3. SSH keys seeded from
|
||||
hubris's trusted set (root password used once, then discarded). Joined the
|
||||
existing `Homelab` cluster via `pvecm add 192.168.8.77 --use_ssh 1` from
|
||||
this node's side, using key-based SSH pre-authorized in both directions —
|
||||
no interactive password prompt needed for the join itself. Cluster now 2
|
||||
nodes (`hubris`, `strong`), quorate, no QDevice. Decided to leave hostname
|
||||
as `strong` and skip a QDevice for now — both revisitable later.
|
||||
Reference in New Issue
Block a user