sync: auto-sync from GURU-5070 at 2026-06-30 17:21:06

Author: Mike Swanson
Machine: GURU-5070
Timestamp: 2026-06-30 17:21:06

.claude/memory/MEMORY.md

@@ -32,6 +32,8 @@
 - [Gitea Internal API Access](reference_gitea_internal.md) — git.azcomputerguru.com is NOT behind Cloudflare — it's the office Cox IP NAT'd to NPM (openresty) on Jupiter. Prefer internal 172.16.3.20:3000 for reliability (bypasses NPM SSL-renewal reload blips).
 - [Gitea git-op latency](reference_gitea_git_op_latency.md) — SSH (.20:2222) is SLOWEST (~1.5s); internal HTTP+token ~0.55s; SOPS lookup only ~0.33s. Don't switch to SSH for speed. Gitea SSH is .20:2222 (API ssh_url .21 is wrong).
 - [GuruRMM technical reference](reference_gururmm.md) — Server (172.16.3.30) layout + downloads dir `/var/www/gururmm/downloads` + `.channel` sidecar rollout control (stable/beta) + privileged server access via the server's OWN root RMM agent (hostname `gururmm`, no SSH needed; plink fallback) + API + `context=user_session` (WTS impersonation) + build-pipeline vendoring at `deploy/build-pipeline/` + Linux agent systemd sandbox trap.
+- [GuruRMM command timeout_seconds](reference_gururmm_command_timeout_seconds.md) — agent command dispatch honors `timeout_seconds`, NOT `timeout`; long jobs die ~300s / go zombie (`running`, empty stdout) otherwise. Cost Birth Biologic a full day.
+- [SharePoint Graph large-file upload](reference_sharepoint_graph_large_file_upload.md) — <4MB simple PUT, >=4MB MUST use chunked upload session (Content-Range); `\\?\` long paths; idempotent size-check; verify counts via /root/delta; single stream ~40Mbps (SPO throttle).
 - [RMM agent update model](rmm-agent-update-model.md) — Agent updates are server-PUSH on heartbeat (no self-poll); available versions = filesystem scan needing a `.sha256`; promote flips `.channel` sidecars beta→stable globally. Two stranders: beta-first freezes stable until an explicit promote; agents older than ~0.6.50 re-enroll with a NEW device_id/agent row when updated.
 - [GuruRMM physical server storage](gururmm-physical-server-storage.md) — New box 172.16.1.231 (temp IP→will be .30), Ubuntu 26.04, ssh key `gururmm-physical`/alias `gururmm-new`. SSD (915G root) = HOT (PG default tablespace + WAL + builds); HDD ext4 at `/data` = COLD (`gururmm_cold` PG tablespace for aged `agent_logs` partitions + downloads + backups + archive). The #3 retention answer.
 - [Trebesch DESKTOP-QNP3ON5 shell replacement](reference_trebesch_qnp3on5.md) — AT Trebesch box runs an Explorer shell replacement; explorer.exe owner check returns blank — use Win32_ComputerSystem.UserName. GuruRMM SWIFT-LION-2892.

.claude/memory/reference_gururmm_command_timeout_seconds.md

@@ -0,0 +1,20 @@
+---
+name: gururmm-command-timeout-seconds
+description: GuruRMM agent command dispatch honors timeout_seconds, NOT timeout — long jobs die at ~300s otherwise
+metadata:
+  type: reference
+---
+
+When dispatching a command to a GuruRMM agent (`POST {RMM}/api/agents/{id}/command`), the
+execution timeout is controlled by **`timeout_seconds`**, not `timeout`. Passing only
+`timeout` leaves the agent at its default cap (~300s): long-running commands get killed and
+often surface as a zombie `status: running` with empty stdout that never terminates.
+
+For multi-minute/multi-hour work (large uploads, big enumerations) set `timeout_seconds` high
+(e.g. 10800) — send both fields to be safe. Poll `GET {RMM}/api/commands/{command_id}` for
+`status` in {completed, failed, cancelled}; cancel a stuck one with
+`POST {RMM}/api/commands/{id}/cancel`.
+
+Cost the fleet a full day of failed Birth Biologic SharePoint uploads (Mac session) before
+this was spotted. See [[reference_sharepoint_graph_large_file_upload]]. Auth helper:
+`.claude/scripts/rmm-auth.sh` (internal `172.16.3.30:3001`).

.claude/memory/reference_sharepoint_graph_large_file_upload.md

@@ -0,0 +1,27 @@
+---
+name: sharepoint-graph-large-file-upload
+description: Uploading files to SharePoint via Graph — simple PUT <4MB, chunked upload session >=4MB; verify counts via delta
+metadata:
+  type: reference
+---
+
+Pushing a folder tree into a SharePoint doc library via Microsoft Graph (app-only):
+
+- **<4MB:** simple `PUT /drives/{drive}/root:/{path}:/content`.
+- **>=4MB:** MUST use an **upload session** — `POST .../root:/{path}:/createUploadSession`
+  then `PUT` the file in chunks (multiple of 320 KiB; 10 MB works) with a
+  `Content-Range: bytes {start}-{end}/{total}` header. In PowerShell 5.1
+  `Invoke-RestMethod -Headers @{ 'Content-Range'=... }` handles this fine. A naive script that
+  only does <4MB PUTs will silently skip every large file and never reach the target count.
+- **Long Windows paths (>260):** prefix the local path with `\\?\` for `[IO.File]` reads.
+- **Idempotent sync:** existence-check each file (`GET root:/{path}?$select=size`) and skip if
+  size matches — this also catches/repairs partial-upload residue from earlier failed runs.
+- **Throughput:** a single sequential upload stream to SharePoint Online plateaus ~40 Mbps
+  regardless of link speed (per-session SPO throttle + PS5.1 HTTP stack + Expect100Continue).
+  For speed use parallel file streams + larger chunks + `Expect100Continue=$false`.
+- **Verify total file count** with the Graph **delta** endpoint
+  (`/drives/{drive}/root/delta`) — whole-drive enumeration in a few paged calls, far cheaper
+  than recursive `/children`.
+
+Proven end-to-end on Birth Biologic Quality Systems (3,768 files, 301 >=4MB, ~29.7 GB;
+largest 3.94 GB). Dispatched via GuruRMM — see [[gururmm-command-timeout-seconds]].