Claude c4649571df Wait for the tunnel interface, and prove the gateway answers ... Two things reported success while the tunnel console was unreachable. The services were restarted the moment the hub container counted as started, but the hub brings wg0 up as part of its start command — so they were binding an address that did not exist yet. They now wait for the interface. And readiness was a container-state check. A container can be up and running while the process inside it listens in a network namespace that was torn down underneath it: nothing errors, the address simply refuses connections, and "running" reports everything fine. It asks the gateway now, and only a real answer counts — because the consequence of getting this wrong is a client config naming a resolver that is not there, which takes the device's whole name resolution with it for as long as the tunnel is up. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>		2026-07-27 10:24:29 +02:00
..
lib	feat(deploy): releases you can pin to, and a version that tells the truth	2026-07-26 15:21:38 +02:00
clupilot.env.example	fix(deploy): an answer file with a space in a value killed the install	2026-07-26 18:49:58 +02:00
install-agent.sh	Serve the console inside the tunnel, without publishing the internal network	2026-07-27 10:14:33 +02:00
install.sh	Give the status page its own hostname, and name the right one for Stripe	2026-07-27 08:08:57 +02:00
update-agent.sh	Serve the console inside the tunnel, without publishing the internal network	2026-07-27 10:14:33 +02:00
update.sh	Wait for the tunnel interface, and prove the gateway answers	2026-07-27 10:24:29 +02:00