claudetools/.claude/memory/gururmm-beast-windows-build-host.md

name, description, metadata

name	description	metadata
gururmm-beast-windows-build-host	GURU-BEAST-ROG (i9-14900K) is the PRIMARY GuruRMM Windows build host (Pluto 172.16.3.36 = fallback). Reached from .30 via Tailscale-on-.30 at Beast's tailnet IP 100.101.122.4 as user guru. build-windows.sh does `attempt_build beast || attempt_build pluto`.	type reference

Set up 2026-06-12. GURU-BEAST-ROG = PRIMARY Windows build host; Pluto (Administrator@172.16.3.36) = FALLBACK. deploy/build-pipeline/build-windows.sh selects via attempt_build beast || attempt_build pluto — falls back if Beast is unreachable/down OR its build fails.

Parallel build (lever A, 2026-06-12) — ~5.6 min, was ~10-21 min

run_remote_build() parallelises the 8 variants across concurrent SSH sessions instead of one serial cmd /c chain (the release profile is opt-level=z + lto=true + codegen-units=1, so each variant's codegen/LTO is single-threaded — concurrency overlaps those tails). Beast: 24c/32t, 128 GB.

• WAVE 1 (5 concurrent, stable toolchain): agent amd64 (target/release) + debug (target/debug-agent) + x86 (target/x86), tray, cleanup.
• WAVE 2 (2 concurrent, Rust 1.77): legacy amd64 (target/legacy-x64) + legacy x86 (target/legacy-x86). MSI (WiX) runs after wave 1, overlaps wave 2.
• Two hard rules learned (both broke the build on BOTH hosts first try):
  1. Every concurrent cargo needs its OWN --target-dir — sharing one (e.g. amd64+x86 both on target/) makes them block on cargo's per-build-dir lock and run serially ("Blocking waiting for file lock on build directory"). copy_artifacts() paths must match the per-variant dirs.
  2. Do NOT pre-resolve the legacy lock with cargo +1.77 fetch/generate-lockfile — a full-graph resolve on 1.77 dies parsing a transitive edition2024 dep (wit-bindgen), rc=101. Just move Cargo.lock aside and let the two cargo +1.77 build --features legacy invocations resolve scoped (no wit-bindgen); cargo's package-cache lock serialises their brief resolve safely, then they compile in parallel. Restore the lock after. Result: v0.6.66 built on Beast in 336s (cargo phase 319s), all 8 artifacts signed + published beta. vs Beast's first serial+cold build 622s and Pluto's 1269s.

How .30 reaches Beast

• Beast is on Wi-Fi 10.2.51.228 (a DIFFERENT LAN than the .30 office 172.16.3.x) + tailnet 100.101.122.4. .30 (office) could NOT reach it via the pfSense subnet route — the pfSense Tailscale SNAT-subnet-routes is deliberately OFF (so remotes see real LAN IPs), and the raw 172.16.x source didn't complete to Beast. Fix: installed Tailscale ON .30 (node gururmm-server/100.86.12.15, tailscale up --accept-routes=false) → reaches Beast 100.101.122.4 peer-to-peer (DERP-relayed, ~50ms — fine for SSH-driven builds). No pfSense/ACL changes. (Don't chase the subnet route again — Tailscale-on-.30 is the working path.)
• Build SSH user = guru (an admin; built-in Administrator is disabled). Pipeline path verified: root@.30 (/root/.ssh/id_ed25519) -> guru@100.101.122.4. Host key pinned in /opt/gururmm/beast_known_hosts. Both root's build key AND GURU-5070's key are in Beast's C:\ProgramData\ssh\administrators_authorized_keys (ACL: Administrators+SYSTEM only).

Beast build toolchain (under C:\Users\guru)

• Rust: stable + 1.77 toolchains, i686-pc-windows-msvc target for both; cargo/rustup in C:\Users\guru\.cargo\bin. sccache 0.8.2 (RUSTC_WRAPPER, SCCACHE_DIR=C:\sccache).
• MSVC 2022 Build Tools (was already installed). dotnet, git present.
• WiX 4.0.6 (dotnet tool, C:\Users\guru\.dotnet\tools\wix.exe) + extensions WixToolset.Util.wixext + WixToolset.UI.wixext @ 4.0.6 (matches Pluto). Repo clone at C:\gururmm (origin URL has the Gitea api-token embedded; credential.helper scrubbed local).

Gotchas (these bit during setup)

• WiX must be 4.x. v6/v7 require accepting a paid OSMF EULA (WIX7015). Install pinned: dotnet tool install --global wix --version 4.0.6 --add-source https://api.nuget.org/v3/index.json.
• Beast NuGet had only the VS offline feed — dotnet tool install wix AND wix extension add failed until dotnet nuget add source https://api.nuget.org/v3/index.json --name nuget.org.
• Wi-Fi is "Public" profile so the stock sshd firewall rule (Private-only) blocked LAN SSH; added rule ACG-Build-SSH-22 (inbound 22, scoped LocalSubnet+172.16.0.0/12+100.64.0.0/10).
• rustup hangs in a detached/no-console context (Start-Process). The pipeline runs builds via an SSH command (has a console) so it's fine; only background-launch validation stalled.

Build user / RMM

• Beast agent id 5233d75b-f589-43c4-b96e-cfa75365a78d (RMM). I bootstrapped SSH/firewall/toolchain via /rmm (agent runs as SYSTEM = elevated) then over SSH (guru@10.2.51.228 same-LAN from GURU-5070, or guru@100.101.122.4 over tailnet). Pluto build wiring unchanged. reference_pluto_build_server