fix(deploy): order cube-proxy.service after cube-sandbox-dns.service

[staryxchen]

Summary

• cube-sandbox-cube-proxy.service runs cube-proxy-start.sh, which calls docker build containing apk update. That step needs /etc/resolv.conf already rewritten away from the systemd-resolved loopback stub (127.0.0.53); otherwise Docker copies the loopback nameserver into the build container and apk update fails to resolve mirrors.tencent.com, breaking the one-click install on Ubuntu 24.04 and similar systemd-resolved hosts ([Bug Report] One-click install fails on Ubuntu 24.04: apk update can't resolve Tencent Alpine mirror during cube-proxy image build #345).
• PR feat(deploy): migrate one-click deployment to systemd management #331 introduced cube-sandbox-dns.service (oneshot running dns-host-route-up.sh) to perform that rewrite, but the two units were only co-pulled by cube-sandbox-control.target via Wants= with no explicit ordering — letting cube-proxy race ahead of the DNS rewrite.
• Add cube-sandbox-dns.service to After= so systemd waits for the oneshot to finish before starting cube-proxy, and to Wants= to match the file's existing After=/Wants= convention and keep the unit robust when started directly outside the control target.

Test plan

• Fresh Ubuntu 24.04 (systemd-resolved active, /etc/resolv.conf → 127.0.0.53): run online-install.sh | MIRROR=cn bash and confirm cube-proxy image build's apk update succeeds without manual /etc/docker/daemon.json workaround.
• systemctl list-dependencies cube-sandbox-cube-proxy.service shows cube-sandbox-dns.service in the resolved chain.
• After install, systemctl show cube-sandbox-cube-proxy.service -p After includes cube-sandbox-dns.service.
• systemctl restart cube-sandbox-cube-proxy.service (alone, outside the target) also brings up cube-sandbox-dns.service first.

Refs: #345, #331

[cubesandboxbot]

Claude finished @staryxchen's task in 26s —— View job

---

Code Review: fix(deploy): order cube-proxy.service after cube-sandbox-dns.service

Result: ✅ Looks good — no issues found.

Summary

The change adds cube-sandbox-dns.service to both After= and Wants= in cube-sandbox-cube-proxy.service (deploy/one-click/systemd/cube-sandbox-cube-proxy.service).

Analysis

Aspect	Assessment
Correctness	✅ The oneshot rewrites /etc/resolv.conf away from the systemd-resolved stub. After= guarantees it finishes before the proxy's ExecStart runs docker build.
Consistency	✅ Matches the file's existing convention — After= lists dependencies in the same order as Wants=.
Robustness	✅ Wants= is the right soft dependency here. Unlike Requires=, it won't fail the proxy unit if DNS fails, which is appropriate since DNS is a prerequisite for the proxy's build step, not a runtime dependency.
Edge case: standalone start	✅ systemctl start cube-sandbox-cube-proxy.service (outside the control target) now pulls in DNS via Wants=, thanks to the addition. Without it, a standalone start would race ahead of the DNS rewrite.
DNS unit type	✅ cube-sandbox-dns.service is Type=oneshot with RemainAfterExit=yes — correct for a one-time setup action. After= + Wants= compose properly with this type.

Test plan notes

The test plan in the PR description covers the right scenarios. One refinement:

• For the "fresh Ubuntu 24.04" test, it may also be worth confirming that systemctl status cube-sandbox-dns.service shows active (exited) before cube-proxy begins its ExecStart, which systemd-analyze plot can visualize.

No changes requested.