HydraIssues

Migrate hydraneck to a Pi scale, preserving its mesh identity 10.10.100.14

hydraneck is the last non-structural service still on its own Hetzner box
(hydraneck, 46.225.8.28, cx33 — renamed from hydraneckomada after Omada was
removed). It is a MikroTik-visibility service: it polls the venue MikroTik routers
via the RouterOS REST API over the WireGuard mesh. It monitors 3 routers today
(cloud-seven/mikrotik-cloud7, mobile-kit/mikrotik-mobile-kit,
rupelmonde/mikrotik-rupelmonde).

It IS migratable — verified

• arm64 build published (v0.11.0), pure Go, no exec.Command shell-outs,
  serve --dev --listen, small state (/root/.hydraneck/secrets.yaml, router
  creds).
• A container on a Pi CAN reach the mesh outbound: verified a scale on pi-node-003
  reaches the hub (10.10.0.1). So a hydraneck scale reaches the MikroTiks over the
  mesh exactly as the box does.

The one real catch — mesh IP is a trusted identity

The box sits on the mesh as 10.10.100.14, and the MikroTik firewalls
allowlist that source IP (Citymesh-managed; the citymesh-venue runbook records
"please allowlist ..." as a request to them). If hydraneck moves to a Pi and its
API calls source from the Pi's mesh IP (e.g. 10.10.100.19 via NAT), the routers
firewall-block it until Citymesh re-allowlists — per venue.

Every other scale in the fleet reaches the mesh via the Pi's NAT (sourcing from the
Pi's IP). hydraneck is the FIRST that must source from its own specific IP. That is
what makes this not a drop-in.

Approach — preserve 10.10.100.14

Give the hydraneck scale its OWN hydraguard-air peer keyed to Address
10.10.100.14 (its own tunnel inside the container, or the Pi holding a second
peer .14 and source-NATing hydraneck's traffic as .14) — NOT the shared Pi NAT.
The MikroTik firewalls then see the same source IP they already allowlist: zero
Citymesh coordination. The peer slot is hydraneck's identity and travels with the
service, not the box.

Note 10.10.100.14 cannot live on two peers at once, so the cutover is a brief
hand-off: free .14 from the box, give it to the scale, without leaving the routers
unwatched in between.

Why do it carefully / prove first

This is the first scale that needs a WireGuard tunnel inside the container (or Pi
source-NAT). Neither is validated in this fleet. Recommend proving the in-container
mesh identity on a throwaway test scale first; if it snags, the fallback is asking
Citymesh to allowlist the Pi's IP (external dependency, but known). A botched
cutover leaves the fleet blind to the venue routers — worth care, not speed.

Payoff

Retires the last non-structural Hetzner box. hydracluster's config references
hydraneck by DNS name (neck.url = https://hydraneck.experiencenet.com), so moving
the domain to a Pi is transparent to the control plane — no config change there.

Scope

Containerize (image likely already publishable), launch as a scale with its own
mesh peer .14, copy secrets.yaml, cut DNS. The novel 10% is the in-container mesh
identity. See the mesh-addressing model in
hydraskin/docs/runbooks/service-cutover.md and #444.