- user-level Node v22.23.0 LTS (static tarball, checksum-verified) + pi 0.79.7 installed -g into the user prefix (box is sudo-less: no root/apt/docker) - every /opt/externs/<client> wired to GLM 5.2 via the litellm gateway with an isolated PI_CODING_AGENT_DIR + scoped per-client key (models.json/settings.json + run-pi.sh launcher); replaces the scaffold's incorrect config.example guess - playbooks/install-pi-nh3-extdev.yaml: idempotent reproduce / add-client / upgrade (validated clean: 4 steps skipped, live gbcnc->GLM 5.2 round-trip OK) - README: settled role + per-client workspace layout; refresh system-details
nh3-extdev
NH3-site manager / external-dev box — 10.100.50.42. Fresh Debian 13
(trixie) VM on nh3-pve (QEMU: 8 vCPU / 7.8 GB / 250 GB, no GPU). Successor to
the retired nh3-ansible. Not a Docker-stack host (Docker not installed).
Reach: the dedicated agent identity only —
ssh nh3-extdev (alias) = ssh -i ~/.ssh/infra-ops_ed25519 infra-ops@10.100.50.42.
The infra-ops user here is sudo-LESS by design (operator decision
2026-06-17): key-only login, password locked, no NOPASSWD sudo, not in the
docker group — deliberately tighter than the rest of the fleet's infra-ops
identity ([reference_infra_ops_sudo_identity] in auto-memory, which is the
sudo variant). Management here is user-level only: files/repos/tooling under
the home dir, systemctl --user, world-readable system state. No root ops (apt,
system services, /etc, root-owned files) and no Docker unless a later,
explicit grant is made (command-scoped sudoers preferred over docker-group, which
is root-equivalent).
Purpose
NH3 client-agent control node (successor to the retired nh3-ansible): runs
the pi coding agent (earendil-works) on GLM 5.2, one isolated agent per
external client, to manage that client's infrastructure. Each client gets a
walled workspace under /opt/externs/<client>/; isolation is by directory +
credential, never a shared identity.
Per-client workspace layout (/opt/externs/<client>/)
/opt/externs/<client>/
├── AGENTS.md? (in repo/) # operating charter the agent loads every session
├── secrets.env # 600, gitignored — EXTERNS_<CLIENT>_GLM_KEY (scoped litellm key)
├── run-pi.sh # 700 launcher: sources secrets.env, sets PI_CODING_AGENT_DIR,
│ # cd repo/, exec pi (per-client isolated config + key)
├── .pi/ # this client's pi agent dir (PI_CODING_AGENT_DIR points here)
│ ├── models.json # provider litellm-glm -> gateway, models glm-5.2[/-reasoning]
│ ├── settings.json # defaultProvider litellm-glm, defaultModel glm-5.2
│ └── (sessions/auth) # pi-managed at runtime
├── repo/ # client infra workspace (own .git; AGENTS.md/scripts/servers/…)
└── .ssh/ # per-client scoped deploy key (reaches THIS client's hosts only)
Launch an agent: /opt/externs/<client>/run-pi.sh (add pi flags as needed, e.g.
-p "…" non-interactive). pi itself reaches GLM 5.2 through the litellm gateway
(http://10.250.50.70:4000/v1, reachable cross-site from NH3 — verified).
pi / Node install (user-level, no root)
Node and pi are installed user-level (the box is sudo-less): Node v22.23.0 LTS
from the official static tarball (checksum-verified) under
~/.local/node-v22.23.0-linux-x64/, with pi installed -g into that prefix
(pi --version → 0.79.7). PATH is wired in ~/.profile + ~/.bashrc.
Reproduce / add a client / upgrade: playbooks/install-pi-nh3-extdev.yaml
(idempotent — scripts/elway nh3-extdev --playbook …). It installs Node+pi and
wires every workspace in its clients var to GLM 5.2; the workspace scaffold
(dirs, secrets.env, deploy keys, repo/) is provisioned separately.
Notes
- Debian 13 (trixie) — newer than the fleet's Debian-12 baseline; watch for package/behaviour drift vs other hosts.
/etc/hostsnow carriesnh3-extdev(the oldunable to resolve hostsudo warning is silenced).- Stood up 2026-06-17; pi-on-GLM-5.2 client agents wired 2026-06-18.
system-details.txtis sudo-less, so docker/root-only sections are necessarily blank.