sync: auto-sync from DESKTOP-0O8A1RL at 2026-05-22 17:45:07
Author: Mike Swanson Machine: DESKTOP-0O8A1RL Timestamp: 2026-05-22 17:45:07
This commit is contained in:
@@ -656,3 +656,105 @@ None.
|
||||
- Ticket #32318: https://computerguru.syncromsp.com/tickets/110847587
|
||||
- Skill: `.claude/commands/syncro.md`
|
||||
- Bot alert message ID: 1507509925939777709
|
||||
|
||||
---
|
||||
|
||||
## Update: 17:40 PT — GuruRMM v0.6.27: user-session execution context
|
||||
|
||||
## User
|
||||
- **User:** Mike Swanson (mike)
|
||||
- **Machine:** DESKTOP-0O8A1RL
|
||||
- **Role:** admin
|
||||
- **Session span:** ~17:00–17:40 PT
|
||||
|
||||
---
|
||||
|
||||
## Session Summary
|
||||
|
||||
This session implemented user-session (non-SYSTEM) command execution in GuruRMM. An explore pass of the codebase revealed the feature was already ~80% complete: the agent side had a full `CommandContext` enum (`System` | `UserSession`), WTS token impersonation via `CreateProcessAsUserW` in `agent/src/watchdog/wts.rs`, a named pipe IPC path through the watchdog, and a dispatch branch in `execute_command()` that routes on context. The gap was entirely on the server side — `SendCommandRequest`, the server-side `CommandPayload`, and the DB `commands` table had no `context` field, so the agent always defaulted to `System`.
|
||||
|
||||
The Coding Agent wired the gap across all four layers: a new migration (`041_add_command_context.sql`) adds a `context TEXT NOT NULL DEFAULT 'system'` column; a `CommandContext` enum was added to `server/src/api/commands.rs` mirroring the agent's definition exactly (same `snake_case` serde, same `Default = System`) so the wire format is identical; `SendCommandRequest` gained an `Option<CommandContext>` field defaulting to `System` for backward compatibility; and `CommandPayload` in `server/src/ws/mod.rs` gained a `context: String` field with `#[serde(default = "default_command_context")]` so agents running before this change continue to receive `"system"` without error. The dashboard (`CommandTerminal.tsx`) gained a System/Active User Session radio toggle with an amber warning, and `Commands.tsx` shows an amber "User Session" badge in command history. A Linux/macOS stub in the agent returns exit code 1 with a clear error string rather than panicking, satisfying the agent parity rule.
|
||||
|
||||
The commit (`7b61ada`) was pushed to Gitea, triggering the build pipeline. Both Linux agent (86s) and Windows agent (Pluto MSVC) compiled with warnings only — no errors. The build completed as v0.6.27 in 374s total, Docker image pushed, server restarted. Coord lock released, all three components updated to `deployed 0.6.27`.
|
||||
|
||||
---
|
||||
|
||||
## Key Decisions
|
||||
|
||||
- **Option A (auto-select active console session) over Option B (user picks session):** For MSP workstation context, `WTSGetActiveConsoleSessionId` is the right call 95% of the time. Multi-user terminal server selection can be added later if a customer needs it.
|
||||
- **`CommandContext` enum defined independently on server side:** Rather than sharing a crate, the enum is duplicated with identical `serde` attributes. The wire format (`"system"` / `"user_session"`) is the contract — source duplication avoids a crate dependency between server and agent build targets.
|
||||
- **`#[serde(default)]` on `CommandPayload.context`:** Ensures agents on the previous version that receive a `CommandPayload` without a `context` field still work correctly, defaulting to `"system"`.
|
||||
- **Linux/macOS stub returns proper `CommandOutput` with exit code 1:** Satisfies the agent parity rule (Windows + Linux + macOS in same change) without a panic. Clear error message tells the tech exactly what's unsupported and why.
|
||||
|
||||
---
|
||||
|
||||
## Problems Encountered
|
||||
|
||||
- **First Coding Agent run used worktree isolation but changes were lost:** The agent prompt said "do not commit — coordinator will handle git." Worktrees are cleaned up if there are no commits, so the changes were discarded. Re-ran with explicit instruction to commit to the worktree branch. Second run succeeded.
|
||||
|
||||
---
|
||||
|
||||
## Configuration Changes
|
||||
|
||||
**GuruRMM repo (`azcomputerguru/gururmm`, commit `7b61ada`):**
|
||||
- `server/migrations/041_add_command_context.sql` — NEW: adds `context` column to `commands` table with `DEFAULT 'system'`
|
||||
- `server/src/db/commands.rs` — `context: String` added to `Command` and `CreateCommand` structs; INSERT updated to bind context as `$6`
|
||||
- `server/src/api/commands.rs` — `CommandContext` enum + `as_str()` added; `context: Option<CommandContext>` added to `SendCommandRequest`; `send_command()` resolves and passes context through
|
||||
- `server/src/ws/mod.rs` — `context: String` field added to `CommandPayload` with serde default; set on re-dispatch of queued commands
|
||||
- `agent/src/transport/websocket.rs` — `#[cfg(windows)]` and `#[cfg(not(windows))]` branches added around `UserSession` dispatch; Linux/macOS returns error string
|
||||
- `dashboard/src/api/client.ts` — `CommandContext` type alias; `context` field on `Command` interface and `commandsApi.send()`
|
||||
- `dashboard/src/components/CommandTerminal.tsx` — context state + radio toggle + amber warning + User Session badge in history
|
||||
- `dashboard/src/pages/Commands.tsx` — amber "User Session" badge in command list view
|
||||
|
||||
**claudetools repo:**
|
||||
- `projects/msp-tools/guru-rmm` — submodule bumped to `7b61ada` (v0.6.27)
|
||||
|
||||
---
|
||||
|
||||
## Credentials & Secrets
|
||||
|
||||
None accessed or created.
|
||||
|
||||
---
|
||||
|
||||
## Infrastructure & Servers
|
||||
|
||||
- GuruRMM server: 172.16.3.30:3001 — restarted as v0.6.27 after build
|
||||
- Pluto build server: 172.16.3.36 (Windows MSVC) — used for agent `.exe` compilation
|
||||
- Docker registry: 172.16.3.20:3000/azcomputerguru/gururmm-agent:0.6.27
|
||||
|
||||
---
|
||||
|
||||
## Commands & Outputs
|
||||
|
||||
```
|
||||
# Build result
|
||||
2026-05-23 00:39:57 - === Build complete: v0.6.27 — total 374s ===
|
||||
# Linux agent: 86s, Windows agent: ~288s via Pluto
|
||||
|
||||
# Coord lock
|
||||
POST /api/coord/locks → id: 17959962-48f5-4209-b1c7-c66f9f2b44d3
|
||||
DELETE /api/coord/locks/17959962-48f5-4209-b1c7-c66f9f2b44d3 → released
|
||||
|
||||
# Component updates
|
||||
PUT /api/coord/components/gururmm/server → deployed 0.6.27
|
||||
PUT /api/coord/components/gururmm/agents → deployed 0.6.27
|
||||
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.
|
||||
|
||||
---
|
||||
|
||||
## Reference Information
|
||||
|
||||
- GuruRMM commit: `7b61ada` — `feat(commands): wire user-session execution context through server, DB, and dashboard`
|
||||
- Build log: `/var/log/gururmm-build.log` on 172.16.3.30
|
||||
- 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`
|
||||
|
||||
Reference in New Issue
Block a user