Fleet Mac config #

Small idempotent scripts to keep @jeffrey's Macs (neo, blueberry, chicken, panda) consistently configured. Run from any host that can ssh the targets.

Memory guard (fleet-guard.sh) #

The failure story. Running swift build -c release on neo — an 8 GB Mac already loaded with agent sessions and Chrome — drove it into swap thrashing so hard that sshd couldn't even complete a handshake; every remote channel timed out until the load came back down. The straw was one heavy compile on a box that was already out of headroom.

The rule. Both fleet Macs (neo AND blueberry) are 8 GB / 6 cores — there is no roomy build host to route to. So the discipline is preflight, not route: never compile on a box that's already under memory pressure; check first, and only one build at a time.

fleet-guard.sh is that preflight check — dependency-free bash, self or any ssh-reachable host:

bash fleet-guard.sh probe self          # print RAM / free% / load / cores / swap
bash fleet-guard.sh probe neo           # same, for a remote host (one ssh round-trip)
bash fleet-guard.sh preflight self      # probe + OK/STRESSED verdict (exit 1 if stressed)
bash fleet-guard.sh guard-build self    # stricter: refuse a compile without build headroom
bash fleet-guard.sh remote neo -- <cmd> # guard-build neo, then ssh <cmd> only if it passes

preflight reports STRESSED when free memory drops below FLEET_MIN_FREE_PCT, 1-min-load-per-core exceeds FLEET_MAX_LOAD_PER_CORE, or swap-used passes FLEET_MAX_SWAP_MB. guard-build is stricter still — it demands FLEET_MIN_BUILD_FREE_PCT free on top of those, because a compile needs headroom the idle machine doesn't. A remote box that won't answer inside the ssh timeout is reported as unreachable / likely thrashing — do not pile on.

The two heavy Swift installers — slab/menubar-swift/install.sh and slab/menuband/install.sh — call fleet-guard.sh guard-build self before their swift build and abort loudly if it fails. (date-wizard/ has no install.sh; its build is a bare swift build, so guard it by hand: bash toolchain/macos/fleet/fleet-guard.sh guard-build self && swift build.)

Env overrides (defaults in parens):

Stats (menu-bar system monitor) #

stats-shared.plist is the canonical exelban/Stats config — it mirrors neo's menu bar: CPU / RAM / GPU / Disk as mini widgets + Network as speed; Sensors and Battery off. Machine-specific keys (remote_id, status-item/window positions) are excluded so each Mac lays out naturally.

bash stats-sync.sh all              # neo chicken panda
bash stats-sync.sh chicken panda    # specific hosts

Each run imports the config, registers Stats as a login item (launches at boot), and opens it. Stats' own auto-updater keeps versions at parity once it's running.

Login-at-startup uses a classic LaunchServices login item, because Stats 3.x's "Start at login" toggle is SMAppService-backed and not reliably settable from the CLI. Both mechanisms launch the same single-instance app, so there's no conflict.

SSH mesh #

fleet-keys.pub holds every fleet Mac's public identity key (jas@aesthetic laptop, jas-neo, chicken-to-neo, panda-to-neo, blueberry-to-neo). ssh-mesh.sh merges them into a host's authorized_keys (dedup by key blob, never removes) so any fleet Mac can reach any other.

bash ssh-mesh.sh all

Tailscale SSH's server is Linux-only, so it can't mesh these Macs — classic authorized_keys distribution is the durable path. The fleet is reachable over the tailnet by name/IP (e.g. blueberry = 100.79.75.53); the tailnet gives the network path, authorized_keys gives the auth.

Blueberry bootstrap #

Blueberry does not trust the fleet key yet and isn't SSH-reachable, so it can't be pushed to. blueberry-join.sh is a self-contained one-shot that adds the fleet keys to its authorized_keys and configures Stats. It's staged on neo, so run this on blueberry (blueberry already holds a key to neo):

ssh neo 'cat ~/blueberry-join.sh' > /tmp/bj.sh && bash /tmp/bj.sh

After that, blueberry joins the mesh and ssh-mesh.sh / stats-sync.sh work on it like any other host.