Repository navigation
desktop: guest-proxy-setup should follow the lane the host decides, not NIC presence #167
Description
Motivation
os-image/desktop/24.04/Dockerfile's guest-proxy-setup writes the session's proxy environment and the dconf proxy entry only when no interface beyond lo/sit0 exists. On a guarded bridge egress lane the NIC is nft-locked at claim, and #165 taught silkd to hand the proxy variables to execs there through the /etc/silkd-nic-locked marker; the desktop unit still tests NIC presence, so the GNOME session's browsers and osworld-server get neither a route nor the relay on that lane. docs/desktop.md documents the limitation and sends desktop pools to net=none with an egress policy.
Shape
The unit runs at boot; the marker lands right after silkd's readiness probe (golden build or cold boot), usually before multi-user.target but not guaranteed. Options: (a) have sandboxd write a lane file for every lane, not only the locked one, and make guest-proxy-setup wait a bounded time for it; (b) a guest-proxy.path unit that re-runs the setup when the marker appears and restarts osworld-server (the running session would still lack the environment). Decide which before touching the image.
Not in scope
The none lane, which already works; git verbs through the relay (the #165 follow-up).
Activity
CMGS commentedon Sep 14, 2026
#165 and #168 are merged: the marker is
/etc/silkd-nic-locked(written by sandboxd after the readiness probe on the golden build, the cold provision and a late reconcile lock), silkd's execs follow it, anddocs/desktop.mdnow says the desktop unit tests NIC presence only and sends desktop pools with web tasks through a none-lane egress policy. Nothing in the image changed; the decision between (a) and (b) above is still open.egress: write the host's lane verdict into every NIC-bearing guest