sync: auto-sync from DESKTOP-0O8A1RL at 2026-05-22 20:28:41

Author: Mike Swanson Machine: DESKTOP-0O8A1RL Timestamp: 2026-05-22 20:28:41
2026-05-22 20:28:43 -07:00
parent 91bcf97112
commit 1e674881aa
3 changed files with 146 additions and 8 deletions
--- a/.claude/worktrees/agent-a8a74266c2d9fe9f8/.gitignore
+++ b/.claude/worktrees/agent-a8a74266c2d9fe9f8/.gitignore
@@ -0,0 +1 @@
+.grepai/
--- a/projects/msp-tools/guru-rmm
+++ b/projects/msp-tools/guru-rmm
--- a/session-logs/2026-05-22-session.md
+++ b/session-logs/2026-05-22-session.md
@@ -123,7 +123,7 @@ closed a ~3-week drift where the global command set lagged the repo (e.g. `/sync
 `feature-request`/`forum-post`/`inject-standards`/`shape-spec` were missing globally). Also fixed
 the long-standing untracked-only detection bug (switched `git diff-index --quiet HEAD --` to
 `[ -n "$(git status --porcelain)" ]` in both the repo and vault blocks) and guarded the change
-with a `.gitignore` entry for 54 MB of datto BSOD dumps so the fix wouldn't sweep them into git.
+with a `.gitignore` entry for 54 MB of datto BSOD dumps so the fix would not sweep them into git.

 Reconciled the Syncro memory set with the add_line_item switch, fixed the `UserPromptSubmit` hook
 (which had been erroring on BEAST and silently swallowing coord messages), and resolved a
@@ -131,7 +131,7 @@ contradiction in Rob's Syncro scope (full access granted and revoked simultaneou
 full Syncro including billing.

 ### Key Decisions
- **Bot asks questions in plain text, not via AskUserQuestion** — the tool doesn't render in
+- **Bot asks questions in plain text, not via AskUserQuestion** — the tool does not render in
  Discord; a posted question + the persistent thread session is the mechanism.
 - **#bot-alerts helper reads the token from the vault first, `.env` fallback** — so it works on any
  machine (Howard's, DESKTOP), not just BEAST where the `.env` lives. Soft-fails (exit 0) so a
@@ -139,7 +139,7 @@ full Syncro including billing.
 - **Fixed the root cause of command drift in `sync.sh` (Phase 5b)** rather than just re-copying once
  — the automated script had skipped the doc's "copy to global" step entirely.
 - **Gitignored the datto dumps instead of letting the sync fix commit them** — 54 MB of binary
-  memory dumps don't belong in a config repo; ignoring keeps them as local working files.
+  memory dumps do not belong in a config repo; ignoring keeps them as local working files.
 - **Reconciled rather than deleted obsolete timer memories** — followed Mike's keep-and-mark-
  SUPERSEDED pattern; `timer_response_shape` retained as HISTORICAL for the rare manual-timer case.
 - **Hook now uses `$CLAUDE_PROJECT_DIR`/`$HOME/ClaudeTools` + trailing `true`** — robust on every
@@ -255,7 +255,7 @@ After the estimate was complete, Mike noted that the standard workflow requires

 ### Infrastructure & Servers

- Syncro PSA: `https://computerguru.syncromsp.com/api/v1`
+- Syncro PSA API: `https://computerguru.syncromsp.com/api/v1`

 ### Commands & Outputs

@@ -393,7 +393,7 @@ POST /estimates  {"customer_id": 15353550, "ticket_id": 110841689, ...}
 POST /tickets/110841689/comment  {"subject": "...", "body": "...", "hidden": true, "do_not_email": true}
 # -> comment id: 412474488, hidden: true  [OK]

-POST /tickets/110841689/comments  (plural — wrong)
+POST /tickets/110841689/comments  (plural -- wrong)
 # -> 404
 ```

@@ -550,7 +550,7 @@ GET /customers?query=Arizona+Computer+Guru -> ID 15353550
 # Estimate created
 POST /estimates -> estimate ID 23967587, number #7189, status: Fresh

-# Laptop line item — $0 on POST (known bug)
+# Laptop line item -- $0 on POST (known bug)
 POST /estimates/23967587/line_items {product_id: 32252, price_retail: 845.00} -> price: "0.0"
 PUT /estimates/23967587/line_items/124973048 {price: 845.00, price_retail: 845.00} -> price: "845.0" [OK]

@@ -747,7 +747,7 @@ PUT /api/coord/components/gururmm/dashboard → deployed 0.6.27
 ## Pending / Incomplete Tasks

 - **Linux/macOS user-session execution (Phase 2):** Current stub returns an error. Real implementation would need `su -c` / `runuser` (Linux) or `launchctl asuser` (macOS). No timeline set.
- **Multi-session selection (Option B):** If a customer runs terminal servers with multiple concurrent users, the current auto-select-console approach won't be sufficient. Deferred.
+- **Multi-session selection (Option B):** If a customer runs terminal servers with multiple concurrent users, the current auto-select-console approach will not be sufficient. Deferred.

 ---

@@ -758,3 +758,140 @@ PUT /api/coord/components/gururmm/dashboard → deployed 0.6.27
 - Docker image: `172.16.3.20:3000/azcomputerguru/gururmm-agent:0.6.27`
 - Dashboard: https://rmm.azcomputerguru.com
 - Key agent files: `agent/src/watchdog/wts.rs`, `agent/src/watchdog/pipe.rs`, `agent/src/transport/websocket.rs:889`
+
+---
+
+## Update: 20:17 PT — GuruRMM dashboard wizard, server build, user_session validation
+
+- **User:** Mike Swanson (mike)
+- **Machine:** DESKTOP-0O8A1RL
+- **Role:** admin
+- **Session span:** ~18:00–20:17 PT (continuation — earlier context covered VPN + feature coding)
+
+---
+
+### Session Summary
+
+This update covered the final shipping phase for two GuruRMM features coded in the prior context window: the client+site creation wizard (`ClientSiteWizard.tsx`) and site delete. A mandatory code review was run on all four changed dashboard files (wizard component, Clients.tsx, Sites.tsx, ClientDetail.tsx). The review approved with one UX fix: the standalone "Add Site" flow in Sites.tsx was silently discarding the API key returned at site creation time. The fix wired that key into the existing `ApiKeyModal` (same path the key regeneration flow already uses). A redundant `as CreateSiteResponse` type cast was also removed from the wizard. Both changes committed, dashboard pushed to `azcomputerguru/gururmm` at `ecf3714`.
+
+Agent version was bumped to 0.6.28 in `agent/Cargo.toml` and pushed (`7c62470`). The version bump was needed to activate the `user_session` command context feature (WTS token impersonation, added in `7b61ada`). Mike asked whether the server build was manual — confirmed yes, then noted that the dashboard and user_session server-side changes from `7b61ada` also needed a server rebuild. The server build via `build-server.sh` failed on two compile errors: `tower::limit::ConcurrencyLimitLayer` referenced without the `limit` feature enabled, and `db::CreateCommand` missing the new `context` field in `user_inventory.rs`. Both fixed directly on the server, committed as `bd78e5c`, and the build completed (v0.3.3, 4m 30s). Database migration 041 (`add_command_context`) was applied. Server fix commit pushed back to Gitea.
+
+The Gitea webhook triggered a parallel Linux + Pluto (Windows x64/x86 + tray + MSI) agent build. The full build completed in 28 seconds (sccache hot). Windows binaries were signed and deployed to `/var/www/gururmm/downloads/`. Agent on DESKTOP-0O8A1RL reported `agent_version: 0.6.28`. Initial `user_session` test returned `failed` / exit code -1. DB inspection of `stderr` revealed the cause: the GuruRMMWatchdog service was running an older binary that did not know the `RunInUserSession` command variant. A system-context command restarted the watchdog service, which loaded the new binary. Retesting immediately confirmed `user_session` working: `stdout: "azuread\mikeswanson\r\n"`.
+
+Throughout testing, the GuruRMM API appeared to return null `output`/`error` fields for all commands. This was a false alarm — the actual field names in the API response are `stdout`/`stderr`. The jq filter used during testing was querying the wrong field names, producing null. The DB was always storing output correctly.
+
+The watchdog-not-updated bug was patched in the updater: `agent/src/updater/mod.rs` now stops and restarts `GuruRMMWatchdog` after the binary is replaced on disk and before the main service restarts (Step 6.5). This ensures future updates keep the watchdog in sync with the agent. Fix committed and pushed as `9db5f88`, will ship as part of 0.6.29 in the next build.
+
+---
+
+### Key Decisions
+
+- **Fix Sites.tsx create flow to show API key** — the code review found that the standalone Add Site modal discarded the `api_key` returned by the server at creation time. Since the `ApiKeyModal` already existed for the regenerate-key flow, wiring it to the create flow was a one-line fix. The wizard already handled this correctly.
+- **Fix server compile errors directly on server, then push to Gitea** — rather than fixing locally and waiting for the webhook to rebuild, fixed on the server to unblock the build immediately. Committed and pushed so Gitea stays the source of truth.
+- **Restart watchdog manually as immediate unblock** — rather than waiting for a code fix + rebuild cycle to test `user_session`, restarted the watchdog service via RMM command to load the current binary. This validated the feature immediately and separated the "does it work" question from the "will it survive updates" question.
+- **Watchdog restart inserted before `restart_service()` in updater** — placement chosen so the new watchdog binary is running before the main service restarts, giving it time to open its named pipe server before the restarted agent tries to connect via IPC.
+
+---
+
+### Problems Encountered
+
+- **Server compile error: `tower::limit` feature missing** — `src/api/mod.rs` imported `tower::limit::ConcurrencyLimitLayer` but `server/Cargo.toml` only had `features = ["util", "timeout"]` for tower. Fixed: added `"limit"` to tower features. Applied via `sed -i` directly on server.
+- **Server compile error: `CreateCommand` missing `context` field in `user_inventory.rs`** — `7b61ada` added `context: String` to `CreateCommand` but `src/api/user_inventory.rs:166` was not updated. Fixed: added `context: "system".to_string()` to the struct literal.
+- **user_session failed: watchdog parse error** — GuruRMMWatchdog service was running an older binary. The serde tag-based `WatchdogCommand` enum on the running watchdog did not include `RunInUserSession`, causing a parse error on the pipe. Resolution: restarted the watchdog service via an RMM system-context command.
+- **Output appeared null in all API responses** — jq filter used `{status, output, error, exit_code}` but the actual API fields are `stdout` and `stderr`. jq silently returns null for missing keys. DB queries confirmed output was always stored correctly.
+
+---
+
+### Configuration Changes
+
+**`azcomputerguru/gururmm` repo (commits ecf3714 → 9db5f88):**
+- `dashboard/src/components/ClientSiteWizard.tsx` — new file; 4-step client+site creation wizard
+- `dashboard/src/pages/Clients.tsx` — "Add Client" opens wizard; edit uses separate modal
+- `dashboard/src/pages/Sites.tsx` — delete action + two-step inline confirm; create flow now shows API key via ApiKeyModal
+- `dashboard/src/pages/ClientDetail.tsx` — sites tab gets delete action with agent count warning
+- `agent/Cargo.toml` — version bumped 0.6.27 → 0.6.28
+- `server/Cargo.toml` — tower features added `"limit"` (`bd78e5c`, fixed on server)
+- `server/src/api/user_inventory.rs` — `CreateCommand` struct literal added `context: "system".to_string()` (`bd78e5c`)
+- `agent/src/updater/mod.rs` — Step 6.5 added: stop/start `GuruRMMWatchdog` after binary replacement on Windows (`9db5f88`)
+
+**Live server (172.16.3.30):**
+- `/opt/gururmm/gururmm-server` — rebuilt as v0.3.3
+- `gururmm` PostgreSQL DB — migration 041 (`add_command_context`) applied
+- `/var/www/gururmm/downloads/` — new 0.6.28 binaries: windows-amd64, windows-x86, tray, base MSI (signed)
+
+---
+
+### Credentials & Secrets
+
+No new credentials created this session. Existing credentials used:
+- GuruRMM API auth: `claude-api@azcomputerguru.com` / `ClaudeAPI2026!@#` (vault: `projects/gururmm/api-server.sops.yaml`)
+- Server SSH: `guru@172.16.3.30` — key auth (`~/.ssh/id_ed25519`)
+- PostgreSQL (gururmm DB): `gururmm:43617ebf7eb242e814ca9988cc4df5ad@localhost:5432/gururmm` (vault: `projects/gururmm/database.sops.yaml`)
+
+---
+
+### Infrastructure & Servers
+
+| Host | IP | Role |
+|------|----|------|
+| gururmm-server | 172.16.3.30 | GuruRMM API (Rust/Axum v0.3.3), PostgreSQL, build trigger, downloads |
+| Pluto | 172.16.3.36 | Windows build server (cargo + WiX MSI); SSH as `Administrator@172.16.3.36` |
+| Gitea | 172.16.3.20:3000 | `azcomputerguru/gururmm` repo; webhook ID 1 triggers `/opt/gururmm/build-agents.sh` |
+| DESKTOP-0O8A1RL | local | Mike's machine; test agent `c043d9ac-4020-4cab-a5f4-b90213d11e73`; confirmed user_session working |
+
+Agent services on DESKTOP-0O8A1RL:
+- `GuruRMMAgent` — main agent (0.6.28)
+- `GuruRMMWatchdog` — watchdog (manually restarted to 0.6.28 this session)
+
+---
+
+### Commands & Outputs
+
+**Server build (after compile fixes):**
+```
+=== Server Build Complete: v0.3.3 ===
+[OK] Server deployed and running
+```
+
+**Agent build (webhook, 0.6.28):**
+```
+2026-05-23 01:55:22 - === Build complete: v0.6.28 — total 28s ===
+```
+
+**Migration verify:**
+```
+41/installed add command context
+```
+
+**user_session test (after watchdog restart):**
+```sql
+SELECT status, exit_code, stdout, context FROM commands WHERE id='5c6283d2-...';
+ completed | 0 | azuread\mikeswanson\r\n | user_session
+```
+
+**Watchdog old-binary error (from DB stderr):**
+```
+Parse error: unknown variant `RunInUserSession`, expected one of
+`RestartMainService`, `SuppressMonitoring`, `StopSelf`, `PerformUpdate`, `UpdateConfig`
+```
+
+---
+
+### Pending / Incomplete Tasks
+
+- **BridgettePSHomeComputer (Peaceful Spirit)** — still offline. When online: run full VPN deployment script via RMM, then admin must run `Set-VpnConnection -L2tpPsk` interactively. See `clients/peaceful-spirit/session-logs/2026-05-22-session.md`.
+- **Agent 0.6.29** — watchdog restart fix (`9db5f88`) needs to be built by Pluto. Build triggered on push; verify `gururmm-agent-windows-amd64-0.6.29.exe` exists in downloads once pipeline completes.
+- **Pre-login VPN verification (Peaceful Spirit)** — confirm VPN auto-connects at Windows login screen on Maras-HP-Laptop and PST-SURFACE.
+
+---
+
+### Reference Information
+
+- **GuruRMM Gitea repo:** `http://172.16.3.20:3000/azcomputerguru/gururmm`
+- **Commits this session:** `ecf3714` (dashboard), `7c62470` (agent 0.6.28 bump), `bd78e5c` (server compile fixes), `9db5f88` (watchdog restart in updater)
+- **Build log:** `/var/log/gururmm-build.log` on 172.16.3.30
+- **Agent test ID (DESKTOP-0O8A1RL):** `c043d9ac-4020-4cab-a5f4-b90213d11e73`
+- **Dashboard:** https://rmm.azcomputerguru.com
+- **Watchdog service name:** `GuruRMMWatchdog` (constant: `crate::service::windows::WATCHDOG_SERVICE_NAME`)
+- **Updater fix location:** `agent/src/updater/mod.rs` lines ~208-247 (Step 6.5)
+- **Server migration path:** `server/migrations/041_add_command_context.sql`