node hand-over: the terminal hands a directory used as found to the mesh, asked of the node's engine (hq issue 356)

A module's condition told the operator to run the node-engine's hand-over at the machine, as root (issue 339), and the mesh had no channel for it. Now node hand-over <node> <path> is the controller's terminal's — a node subcommand that is not a read, so every verb and mesh-cli outside the terminal refuse it — and asks that node's engine on mesh.node.<node>.ask.hand-over, a request only the controller may publish and only that node's engine may hear and answer (its grant gains the subject and the right to answer what it was asked). The line's node and path are judged before anything is asked; the engine's answer is printed, a refusal as a refusal. Every text addressed to the operator names the nox line (ADR 0272); the condition's words stay plain.
2026-10-09 18:38:09 +02:00
parent 1c7c385839
commit 9006c82393
12 changed files with 397 additions and 21 deletions
@@ -46,7 +46,7 @@ bed asserts genesis **says** it found and took the tunnel.
 **Review changes (2026-09-24).** A spoke's `wg0.conf` names one peer — the hub — routed the
 whole range; the controller skips range-routed peers, so T2's enrolment carries no peer from the
 spoke. A hub that enrolled *before* this feature (a generated key) takes the tunnel over without
-re-enrolling: `mesh-host overlay take --tunnel wg0` on the machine rekeys the overlay key only and
+re-enrolling: `nox-mesh-host overlay take --tunnel wg0` on the machine rekeys the overlay key only and
 sends a signed rekey; the bed adds **R0** for it below. A takeover is composed only for a hub
 placed at the tunnel's address on the tunnel's port, and the host stops nothing until the declared
 interface matches the found one and the key file holds the found key; a mesh interface that fails
@@ -58,7 +58,7 @@ to start gives the found unit back. The host's account has three states: `not-ta
 - **R0 — a hub enrolled with its own key takes the tunnel over by rekeying.** Genesis is run
  adopted *without* the tunnel being found (the bed stops `wg-quick@wg0` for the run, so the
  installer sees no tunnel, then starts it again — the pre-feature shape). Then on the anchor:
-  `mesh-host overlay take --tunnel wg0`; `node show anchor` says "tunnel found wg0 …"; `overlay
+  `nox-mesh-host overlay take --tunnel wg0`; `node show anchor` says "tunnel found wg0 …"; `overlay
  place anchor --hub --endpoint 192.0.2.10:51900 --site hosting` (with `:51820` first, which must
  be refused naming 51900); `plan anchor --json` names `Address = 10.10.0.1/32`, `ListenPort =
  51900`, two `/32` peers, `takes-over` wg0 and nothing in 10.42.0.0/16; then `push anchor --wait
@@ -82,7 +82,7 @@ to start gives the found unit back. The host's account has three states: `not-ta
  - `overlay show` lists `anchor` as the hub over the tunnel it took over, and both peers under
    "peers of the tunnel … not nodes of the mesh", not yet enrolled.
 - **T2 — a peer enrols and keeps its address.** On `peer-a`: `node add peer-a --adopted`,
-  token issued, `mesh-host enrol --token …` **with the broker reached over the tunnel** (the
+  token issued, `nox-mesh-host enrol --token …` **with the broker reached over the tunnel** (the
  broker address in the token is `10.10.0.1:<bus>`, which only the tunnel routes); then `overlay
  place peer-a --site house` and a push. Assert: `node show peer-a` says a tunnel `wg0` was
  found and `overlay show` puts `peer-a` at **10.10.0.2**; the carried-peers list now says