fix(release): ship gvproxy to Linux installs (native own-ip) - #982
fix(release): ship gvproxy to Linux installs (native own-ip)#982norrietaylor wants to merge 1 commit into
Conversation
The Linux component set omitted gvproxy, so the native (DM2) own-IP
datapath was dead on every installed Linux host: minimald resolved the
switch only at the fixed /usr/lib/minimal/bin/gvproxy, which no install
provides. The release workflow already stages pin-verified
gvproxy-linux-{amd64,arm64} artifacts; they were just never mapped to
Linux install components.
- stage-release.sh: add gvproxy rows for linux/amd64 and linux/arm64
(bin/gvproxy, same dest as the darwin row).
- switch: add installed_gvproxy_bin(), one shared definition of where
an install puts gvproxy (user-local $MINIMAL_BIN / ~/.local/bin,
else the system-wide /usr/lib/minimal/bin/gvproxy fallback).
- minimald: default the OwnIp switch path through the shared resolver
instead of the fixed system path, so an installed daemon finds the
user-local gvproxy. The --gvproxy-bin flag/config still wins.
- minvmd: delegate tiers 2/3 of its resolver to the shared definition
(its MINVMD_GVPROXY_BIN override tier is unchanged).
The minvmd half of the issue (VM mode on Linux installs) is deferred:
it needs libkrun/libkrunfw and the guest payload staged alongside it,
plus an arm64 minvmd build, all behind the frozen release workflow.
Refs: #980
Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
|
Warning Review limit reachedYou’ve reached a temporary PR review limit under our Fair Usage Limits Policy. Next review available in: 15 minutes Enable usage-based reviews in Billing to review now. Otherwise, wait until the next included review is available. How can I continue?After more reviews become available, a review can be triggered using the To avoid repeated limits, reduce automatic review volume by pausing incremental auto-reviews earlier, using label-based review opt-in, excluding WIP or generated PR titles, or requesting reviews manually when the PR is ready. If your team needs uninterrupted high-volume reviews, an organization admin can enable usage-based reviews. How do review limits work?CodeRabbit enforces per-developer PR review limits for each organization. Most developers receive the normal plan review availability. For paid Pro and Pro+ PR reviews, CodeRabbit uses adaptive limits for sustained high-volume activity. When a developer's recent PR review activity reaches the 95th percentile or higher among CodeRabbit users, additional reviews become available more gradually as earlier reviews age out of the rolling window. Please refer docs for additional details. Review details⚙️ Run configurationConfiguration used: Organization UI Review profile: CHILL Plan: Pro Run ID: ⛔ Files ignored due to path filters (1)
📒 Files selected for processing (8)
Comment |
Summary
Part of #980 — the gvproxy half. Linux installs now get
bin/gvproxy, and both daemons agree with the installer on where it lives, so native (DM2) own-IP sessions work on installed hosts.scripts/stage-release.sh: addgvproxy|linux|amd64andgvproxy|linux|arm64rows. The release workflow already uploads the pin-verifiedgvproxy-linux-{amd64,arm64}artifacts (#495); they were just never mapped to Linux install components. The installer is manifest-driven and needs no change.switch::installed_gvproxy_bin()(new): staging the binary alone would not revive own-ip — the installer stampsbin/components into~/.local/bin(or$MINIMAL_BIN), butminimaldresolved the switch only at the fixed/usr/lib/minimal/bin/gvproxy. The new function is the one shared definition of the installed location (user-local install if present, else the system path), in the crate whose charter is exactly "one definition rather than drifting copies" shared by both daemons.minimald: theOwnIpswitch default now goes through the shared resolver;--gvproxy-bin/ the config field still win, and theGVPROXY_BINenv var remains scoped to the netns proof only.minvmd: delegates tiers 2/3 ofresolve_gvproxy_path()to the shared definition — it already had exactly this user-local tier, now the two daemons cannot drift. ItsMINVMD_GVPROXY_BINoverride tier is unchanged.Deferred — the minvmd half of #980
VM-backed sessions on Linux installs stay out of scope, per the issue's own open questions:
minvmdneedslibkrun.so/libkrunfw.sostaged (plus an rpath story), the guest payload (data/{vmlinuz,rootfs.img,initramfs.cpio}) mapped for Linux, and an arm64minvmdbuild — all requiring changes to the frozen, CODEOWNER-gatedrelease.yml. Shippingbin/minvmdtoday would install a binary that cannot load libkrun, and the arm64 row would hard-fail staging (nominvmd-linux-arm64artifact exists).Verification
scripts/stage-release.sh --dry-runagainst a stand-in artifacts dir emits both new rows with correct dest/src;shellcheckclean.cargo test -p switch(incl. 2 new resolver tests),just test(darwin scope, 511 pass),just clippy,just fmt-check,just deny,just doctest— all green locally (macOS).cross check -p minimald --all-targets --target aarch64-unknown-linux-musl --lockedpasses; the single warning is the pre-existing musl-onlylibc::time_tdeprecation inguest.rs, untouched here.ci-linux-native's netns job (netns_root_integration.rs) covers the datapath, and the resolver change preserves its config-injection path.🤖 Generated with Claude Code
Note
Ship gvproxy to Linux installs for native own-IP sessions
gvproxyto the Linux amd64 and arm64 component lists in stage-release.sh, so the installer placesbin/gvproxyon Linux hosts.switch::installed_gvproxy_bin()function that prefers a user-localbin/gvproxyinstall, falling back to the system path.DEFAULT_GVPROXY_BINandinstaller_bin_dirconstants/helpers fromminimaldandminvmd; both now delegate to theswitchcrate.Macroscope summarized a919053.