azcomputerguru/claudetools
1
0
Fork 0
Code Issues 58 Pull Requests Actions Packages Projects Releases Wiki Activity

sync: auto-sync from GURU-5070 at 2026-06-02 07:25:49

Browse Source 
Author: Mike Swanson
Machine: GURU-5070
Timestamp: 2026-06-02 07:25:49
This commit is contained in:
Mike Swanson
2026-06-02 07:25:55 -07:00
parent bc7716c7a9
commit 0daa7951b3
54 changed files with 1349 additions and 2 deletions
Download Patch File Download Diff File Expand all files Collapse all files

12
.claude/memory/feedback_rmm_identify_by_ip.md Normal file
View File

@@ -0,0 +1,12 @@
---
name: feedback_rmm_identify_by_ip
description: When the offending/target machine is known by external IP, identify the RMM agent by matching the IP — don't recon every candidate.
metadata:
type: feedback
---
When a task names a machine by its external IP (e.g. an auth-failure source from a server log), identify the RMM endpoint by **matching that IP**, not by dispatching recon to every candidate agent and inspecting them.
**Why:** Mike pushed back twice (2026-05-30) for probing both Pavon machines (Curves + Raiders) to find which had a stray GuruConnect client, when the offending external IP was already known. Matching IP is one lookup; reconning all candidates is noisy and slow.
**How to apply:** Get the source IP from the relevant server's logs first. To map IP -> agent: GuruRMM does NOT yet store agent IPs (no local_ip/external_ip fields — see GuruRMM todo 7459428e, 2026-05-30), so until that lands, have only the *candidate* endpoints report their external IP (`Invoke-RestMethod ipify`) and match — or narrow candidates by site/client first. Once the server stamps external_ip from X-Forwarded-For, query `/api/agents` directly. Related: [[reference_gitea_internal]].