The CLI up path only tolerated a not-yet-ready daemon via a 10s blocking
dial, so "netbird service start" immediately followed by "netbird up"
(e.g. a container entrypoint) failed with a generic "daemon not running"
error. The container entrypoint worked around this with a shell poll loop
(status --check live) before running up.
Move the readiness wait into the CLI, mirroring how the GUI already dials:
- DialClientGRPCServer now uses grpc.NewClient with a tuned reconnect
backoff and waits for the connection to reach READY (retrying on
TRANSIENT_FAILURE) up to a 30s deadline, instead of grpc.DialContext +
WithBlock with a hard 10s timeout.
- up now polls Status via waitForDaemonStatus, retrying while the RPC is
Unavailable (socket up but service not yet registered).
Add an explicit daemon-ready signal so clients can wait deterministically
instead of heuristically:
- New optional StatusResponse.daemonReady field (field 5, wire-compatible
with older GUIs/daemons which leave it unset). Regenerated with the
pinned protoc v33.1 toolchain so no version churn leaks into the diff.
- The server sets ready once Start succeeds and the DaemonService is
registered (SetReady, called from the service controller).
- waitForDaemonStatus waits for daemonReady=true (or an already-Connected
status), with a bounded grace window so older daemons that never set the
field are not blocked.
Simplify the container entrypoint accordingly: drop the readiness poll
loop (up now waits) and the now-dead NB_ENTRYPOINT_SERVICE_TIMEOUT env,
keeping only the daemon+up process glue and SIGTERM forwarding for clean
shutdown.
- introduce variables to avoid publishing latest docker tags and installers
- Refactor .goreleaser.yaml to simplify docker configurations and add environment-driven flags
- removed management debug containers (it was doing only log var)
- Stopped building arm v6 32bits in favor of v7 32 bits for services (not client)
- Add target argument to docker files
This will allow running netbird commands (including debugging) against the daemon and provide a flow similar to non-container usages.
It will by default both log to file and stderr so it can be handled more uniformly in container-native environments.
