sync: auto-sync from GURU-5070 at 2026-06-02 07:25:49
Author: Mike Swanson Machine: GURU-5070 Timestamp: 2026-06-02 07:25:49
This commit is contained in:
@@ -68,3 +68,66 @@ None touched. Personal/local file task only.
|
||||
- Import template reference: `C:\Users\Howard\Downloads\Sample CSV file for importing contacts.csv` (92-col Outlook format, no BOM, ASCII)
|
||||
- Outlook target address book: `Contacts - treb737@earthlink.net`
|
||||
- Dedup summary: 664 -> 627; 0 contacts share a name or email in the final file.
|
||||
|
||||
---
|
||||
|
||||
## Update: 07:24 PDT — Sonnet wiki recompile test + Linux agent drift investigation
|
||||
|
||||
### Session Summary
|
||||
|
||||
Ran the first live test of the Sonnet-subagent wiki recompile (the engine swap from Ollama qwen3:8b done the prior session) against a real article: `peaceful-spirit`, chosen because it was stale (2026-05-24) and had genuinely new source material (the recovered RADIUS log + cross-linked manual log). The Sonnet subagent produced a high-quality full recompile — preserved all existing Patterns/History verbatim, added 3 well-sourced Patterns and 2 History rows, and absorbed the RADIUS/NPS and 2026-05-27 BridgettePSHomeComputer work. It also correctly extracted the real Syncro customer ID (278525, "Peaceful Spirit Massage") from a session log even though my API name-search for "peaceful spirit" returned only unrelated businesses.
|
||||
|
||||
The main-agent review step caught two issues before write: (1) the subagent inlined three raw secrets (sysadmin password, UCG root password, NPS shared secret) into the article — stripped back to vault-references; (2) the Syncro ID was verified against the live API rather than trusted blind (it checked out). Committed the recompile (dc2c754) and then hardened the synthesis brief with rule 6b — never inline raw secrets, vault-reference only (5189f28).
|
||||
|
||||
Investigated the GuruRMM Linux-agent fleet drift that GURU-KALI flagged (every pre-30da053 Linux agent supposedly running new binary on an old strict-sandbox systemd unit -> BUG-016 mint+lose device_id on restart). Verified all four Linux agents (all on 0.6.52): gururmm (172.16.3.30, ProtectSystem=false permissive unit, .device-id persists since Apr 16), Jupiter (172.16.3.20, Unraid non-systemd host, no /var/lib/gururmm), ix (172.16.3.10, NO_SANDBOX_DIRECTIVES, .device-id persists since May 28), and GURU-KALI (already remediated 2026-06-01). NONE carry the strict-sandbox unit — GURU-KALI was the only affected host, so the "fleet-wide" concern is disproven and there is no remediation script to run.
|
||||
|
||||
The investigation surfaced a real bug instead: GuruRMM Linux agent remote-command execution stalls or fails. Commands dispatched to online Linux agents (Jupiter, ix) either sat in status=running for 5+ minutes with no completion or returned status=failed with empty output, while Windows agents execute fine. This is why the GURU-KALI unit fix had to be applied by hand over SSH rather than pushed via /rmm. Filed as a todo.
|
||||
|
||||
### Key Decisions
|
||||
|
||||
- Verified the Sonnet subagent path end-to-end rather than trust the prior session's Claude-direct test; the review step proved necessary (caught secret leakage) and stays.
|
||||
- Hardened the prompt (rule 6b) so secret leakage is prevented at the source, not just caught in review.
|
||||
- Verified the Linux drift per-host with live evidence rather than accept GURU-KALI's blanket framing; reached ix via paramiko + the vault root password after RMM command + root-key SSH both failed.
|
||||
- Closed the ix-verify todo as done (verified, no refresh needed); kept the command-exec bug open as the real follow-up.
|
||||
|
||||
### Problems Encountered
|
||||
|
||||
- Sonnet draft inlined raw secrets from session logs into the wiki — caught in review, stripped, and prevented going forward via rule 6b.
|
||||
- Syncro name-search for "peaceful spirit" matched unrelated businesses (the Syncro business name is "Peaceful Spirit Massage"); the real ID came from the session log and was API-verified.
|
||||
- GuruRMM Linux remote-command execution non-functional (stalls/fails) — blocked RMM-based verification of Jupiter/ix; worked around with direct SSH/paramiko. Filed as a bug.
|
||||
- ix root SSH refused key auth; used the vault root password via paramiko (BatchMode had masked the password-auth path on the first attempt).
|
||||
|
||||
### Configuration Changes
|
||||
|
||||
- [modified, committed dc2c754] `wiki/clients/peaceful-spirit.md` (full Sonnet recompile) + `wiki/index.md`
|
||||
- [modified, committed 5189f28] `.claude/commands/wiki-compile.md` (added rule 6b: never inline raw secrets)
|
||||
- No other repo changes — the Linux investigation was read-only (live queries + SSH).
|
||||
|
||||
### Infrastructure & Servers
|
||||
|
||||
- GuruRMM Linux agents (all v0.6.52): gururmm 172.16.3.30 (Ubuntu 22.04), Jupiter 172.16.3.20 (Debian/Unraid host), ix.azcomputerguru.com 172.16.3.10 (Rocky/CloudLinux WHM/cPanel, ext 72.194.62.5, WHM 2087 / cPanel 2083), GURU-KALI (Kali, offline).
|
||||
- Fleet totals: 93 agents (87 Windows, 4 Linux, 2 macOS).
|
||||
- ix SSH: root@172.16.3.10:22, password in vault `infrastructure/ix-server.sops.yaml`.
|
||||
- Peaceful Spirit: Syncro customer 278525 ("Peaceful Spirit Massage"), ticket #32271.
|
||||
|
||||
### Commands & Outputs
|
||||
|
||||
- RMM auth + agent list: `POST http://172.16.3.30:3001/api/auth/login` -> token; `GET /api/agents`.
|
||||
- Per-host unit check: `systemctl cat gururmm-agent | grep -iE "StateDirectory|ProtectSystem|ReadWritePaths"; ls -l /var/lib/gururmm/.device-id; journalctl -u gururmm-agent --since -7days | grep -ci "persist device ID|EROFS|read-only"`.
|
||||
- ix reached via paramiko (root + vault password) after `ssh -o BatchMode=yes root@172.16.3.10` returned "Permission denied (publickey,...)".
|
||||
- RMM command dispatch to Jupiter/ix returned status=running (never completed) / status=failed (empty output).
|
||||
|
||||
### Pending / Incomplete Tasks
|
||||
|
||||
- **OPEN todo 57e142aa** (gururmm): Linux agent remote-command execution stalls/fails — investigate command_type handling + WS command channel.
|
||||
- ix-verify todo ad7bbc61 — CLOSED (not at risk).
|
||||
- Optional: recompile `wiki/projects/gururmm.md` to capture the command-exec bug + the verified "device-id drift was KALI-only" finding.
|
||||
- Loose end: GURU-KALI flagged the fleet drift in the coord record as an open concern; a coord reply documenting "all Linux hosts verified clean, no script needed" would close that loop (offered, not yet sent).
|
||||
|
||||
### Reference Information
|
||||
|
||||
- Commits: dc2c754 (peaceful-spirit Sonnet recompile), 5189f28 (wiki-compile rule 6b)
|
||||
- Todos: 57e142aa (Linux cmd-exec bug, open), ad7bbc61 (ix verify, done)
|
||||
- GuruRMM API: http://172.16.3.30:3001 (admin@azcomputerguru.com)
|
||||
- Linux agent IDs: Jupiter 443bfabb-9213-4157-8be6-2b6d5d3113b2, ix 4ad2e426-b03f-4c5d-817c-c8c675ba73a0
|
||||
- BUG-016 upstream fix: gururmm commit 30da053 (OnceLock device_id + StateDirectory=gururmm)
|
||||
|
||||
Reference in New Issue
Block a user