sync: auto-sync from GURU-5070 at 2026-05-28 12:42:45

Author: Mike Swanson
Machine: GURU-5070
Timestamp: 2026-05-28 12:42:45

session-logs/2026-05-28-session.md

@@ -327,3 +327,51 @@ curl -s -X POST "https://computerguru.syncromsp.com/api/v1/tickets/111387456/add
 - Coord message (SPEC-013/014 decisions to Howard): e72b2145-b518-4f16-b78e-5ff84f29126c
 - Syncro dead-end paths: `POST /ticket_comments`, `POST /tickets/{id}/comments`, `POST /tickets/{id}/line_item`, `POST /tickets/{id}/line_items`, `PUT /tickets/{id}` with `line_items_attributes`
 - Working paths: `POST /tickets/{number}/comment`, `POST /tickets/{internal_id}/add_line_item`
+
+---
+
+## Update: 12:41 PT — Scileppi macOS RMM Enrollment + Glaztech Session Log
+
+### Session Summary
+
+Wrote and committed the Glaztech email delivery session log (`clients/glaztech/session-logs/2026-05-28-session.md`), then worked through enrolling Sylvia's Mac mini (Scileppi Law, `WEST-MEADOW-9025`) in GuruRMM — a task that had been blocked since May 7 when Howard found no macOS agent existed.
+
+On inspection, macOS binaries had actually been built today (v0.6.48: arm64, amd64, universal) and were present in `/var/www/gururmm/downloads/`. Two issues remained. First, the server code in `install.rs` expected binaries named `gururmm-agent-macos-aarch64-latest` and `gururmm-agent-macos-x86_64-latest`, but the build pipeline names them `arm64` and `amd64`. Created two symlinks on the server to bridge the naming gap — binary download route went from 500 to 200. Second, the nginx config was serving `/install/` as static files from `/var/www/gururmm/install/` rather than proxying to port 3001; this was fine because a purpose-built static script for Scileppi already existed there with the correct site UUID (`9571d9ff-2a43-40b8-9691-63ded40c85b8` = WEST-MEADOW-9025 Main Office, confirmed in DB).
+
+Ran the install on Sylvia's Mac (M2 arm64). Agent installed, LaunchDaemon loaded, WebSocket connected — but authentication failed with "Invalid API key" in a retry loop. Root cause: the static install script wrote `<key>SiteId</key>` in the plist, but the Rust struct in `macos_storage.rs` uses field name `site_id` (snake_case). The `plist` crate deserializes by exact field name, so the mismatch caused `read_site_id()` to return `Err`, which `.ok()` silently converted to `None`, causing `resolve_windows_config()` to skip enrollment entirely and fall back to the TOML file, which had `api_key = "will-auto-enroll"`. Fixed the key name in the server-side install script (`sed -i SiteId → site_id`), then patched the plist in place on Sylvia's Mac and restarted the LaunchDaemon. Agent enrolled successfully on the next startup.
+
+### Key Decisions
+
+- **Static install script over dynamic route** — The nginx config routes `/install/` to static files, not port 3001. The static `scileppi` script is more complete than the dynamic route anyway (handles both arm64 and x86_64, creates proper LaunchDaemon plist with log paths). Left nginx unchanged; dynamic macOS install routes are available internally but not the enrolled path for now.
+- **Symlinks over code change** — The naming mismatch (aarch64 vs arm64) was fixed with server-side symlinks rather than changing the Rust source and triggering a full build+deploy cycle.
+- **Patch plist in place on Sylvia's Mac** — Rather than having her re-run the install, a one-line `sed` to fix the key name plus a LaunchDaemon reload was faster and less disruptive.
+
+### Problems Encountered
+
+- **`/install/WEST-MEADOW-9025/macos` returned 404 externally, 200 internally** — nginx was serving static files, not proxying. The dynamic route in the Rust server worked fine when hit directly on port 3001. Not a bug — intentional static-file approach, just not documented.
+- **Binary download returned 500** — `gururmm-agent-macos-aarch64-latest` symlink missing; build pipeline uses `arm64` suffix, not `aarch64`. Fixed with symlinks.
+- **"Invalid API key" auth loop** — plist key name case mismatch (`SiteId` vs `site_id`). Silent deserialization failure caused TOML fallback with placeholder key.
+
+### Configuration Changes
+
+- `/var/www/gururmm/downloads/gururmm-agent-macos-aarch64-latest` → symlink to `gururmm-agent-macos-arm64-latest` (created)
+- `/var/www/gururmm/downloads/gururmm-agent-macos-x86_64-latest` → symlink to `gururmm-agent-macos-amd64-latest` (created)
+- `/var/www/gururmm/install/scileppi` — plist key fixed: `SiteId` → `site_id`
+- `/usr/local/etc/gururmm/site.plist` on Sylvia's Mac — same fix applied in place
+- `clients/glaztech/session-logs/2026-05-28-session.md` — created (Glaztech email delivery work)
+
+### Pending / Incomplete Tasks
+
+- **Scileppi wiki** — `wiki/clients/scileppi-law.md` should be updated to reflect successful enrollment of Sylvia's Mac mini. `enrolled: true`, GuruRMM state updated.
+- **Glaztech wiki** — No wiki article for glaztech yet. Run `/wiki-compile client:glaztech`.
+- **`install-mac.sh`** — A file `/var/www/gururmm/downloads/install-mac.sh` was noticed during the downloads listing. Not yet reviewed — may be redundant or may be a newer/better approach. Check before the next macOS enrollment.
+- **Dynamic macOS install route** — The nginx static-file serving for `/install/` means the `install_script_macos` Rust route is unreachable publicly. Fine for now but should be addressed before self-service macOS enrollment is documented for clients.
+- **plist key mismatch in dynamic route** — The `install_script_macos` Rust handler (install.rs) generates a macOS install script; that script likely has the same `SiteId` vs `site_id` bug if it writes a plist. Needs audit before the dynamic route is made the canonical path.
+
+### Reference Information
+
+- Scileppi site: `WEST-MEADOW-9025` / UUID `9571d9ff-2a43-40b8-9691-63ded40c85b8` / client Scileppi Law
+- Sylvia's Mac: `Mac-mini-2`, M2 arm64, macOS 14.4.1
+- Install script (fixed): `https://rmm.azcomputerguru.com/install/scileppi`
+- Glaztech session log: `clients/glaztech/session-logs/2026-05-28-session.md`
+- Symlinks created on gururmm-build (172.16.3.30): `aarch64-latest` → `arm64-latest`, `x86_64-latest` → `amd64-latest`