Files
esh-pfi-infrastructure/persistent-memory.d/2026-09-03-mac-fleet-dsh.md
T

2.9 KiB

  • [2026-09-03] Three Macs onboarded with infra-ops + NOPASSWD sudo + the DeepSeek Harness, and the fourth is a script instead of a fourth hand-run.

    vuongs-mac-mini 10.100.79.2 infra-ops + lkraven esh-macbook-air 10.0.10.83 infra-ops + lkraven esh-mac-studio 10.0.10.10 infra-ops + vhpfi

Each: key auth, visudo-validated NOPASSWD drop-in, password rotated to 32 random chars and vaulted at <name>/infra-ops-password. dsh runs in the operator's own account on each, on a device-scoped LiteLLM key (<name>-dsh, scoped to gen-reasoning, scope verified 200/403 rather than trusted from the mint) — a laptop travels, and losing one should be one revocation, not a fleet key rotation.

scripts/provision-mac-dsh.sh <host> <account> [name] carries every trap; the operator-run half is docs/runbooks/mac-provisioning.md.

⚠ sudo -u <user> KEEPS THE CALLER'S $HOME. Without -H and an explicit HOME=, "$HOME/.local" resolved to the caller's home and an rm -rf aimed at a working install in another account. Only filesystem permissions stopped it. The script now refuses to run unless $HOME matches the target.

⚠ An account may not own its own home. A sudo mkdir before sysadminctl leaves /Users/<account> root-owned; the account authenticates, gets a shell, reports the right $HOME, and cannot write to it — surfacing as a bare "Permission denied" hours later.

⚠ A wrong USERNAME looks exactly like a wrong password. sshd answers Permission denied (publickey,password,keyboard-interactive) for a bad user, a bad password, AND a user outside com.apple.access_ssh. This produced a false diagnosis twice in one session — once where the password was a typo (no-password vs nopassword) and I blamed the access group, once where the Studio's operator account is vhpfi, not lkraven. Check dscl . -list /Users FIRST.

⚠ Rotation: use dscl . -passwd, not sysadminctl. With FileVault on and no Secure Token on the account, sysadminctl -resetPasswordFor refuses with "Operation is not permitted without secure token unlock". dscl works precisely because there is no token to desync. True on all three Macs.

⚠ FileVault kills remote access across reboots — the machine sits at the pre-boot unlock screen with no network. Nothing unattended should depend on a Mac being reachable after a restart.

⚠ macOS has no adduser, useradd, or timeout.

Harness config (all machines): high → the seat's xhigh via the gateway hook; maxTokens 32768 (the 256000 default left 6144 for input and overflowed on a two-word prompt); defaultContextWindow 262144; and models: replacing the provider's hard-coded DeepSeek catalog, which the web GUI reads INDEPENDENTLY of agent-default-model — without it the picker offers three models the gateway does not serve while headless runs work fine. Commits 6ca455a, 926fc2f.