Prove a machine joins through the tunnel in a bed of its own
mesh/delivery delivered
mesh/delivery-group group feat/a-machine-joins-through-the-tunnel delivered: every member is delivered
mesh/merge-gate pass: the change touches no module of the mesh's graph
mesh/repo-check pass: its merge-check.sh passed, each part in its toolchain: merge-check.sh (typescript), replays/merge-check.sh (go)

Two machines: the anchor raises the foundation, joins over its own
loopback and becomes the hub; the joiner makes its tunnel key, is issued
a token for it and enrols with the bus's port closed to its own address,
so the enrolment can arrive only over the tunnel (novox/hq ADR 0169). The
check that had been added to the two-node walk moves here, closing the
port the bundle publishes the bus on rather than the bus's own.

And the uplink's range may be named: behind a VPN client that routes
every private range, incus had none left to pick and no scenario could
be raised.
This commit is contained in:
jochen
2026-10-08 01:52:58 +02:00
parent 4b7ad9a387
commit e80a4b1642
7 changed files with 241 additions and 35 deletions
+4
View File
@@ -45,6 +45,10 @@ mesh-lab diagram --live <instance> draw what is actually standing
correctly and snapshots roughly 76× slower — which does not make the lab slow, it makes it
unused, and a warning about that is read once and ignored forever.
Behind a VPN client that routes every private range, incus finds no free range for the uplink a
machine fetches its images over, and nothing can be raised. Name one the host does not route:
`MESH_LAB_UPLINK_V4=192.168.231.1/24`.
If the incus socket is not reachable as your user — the group was granted to a session that
already existed — set `MESH_LAB_INCUS="sudo -n incus"`.