Mike Swanson
833815b5f2
Match a known external IP to the RMM agent rather than reconning every candidate machine (Mike's correction during the Pavon GuruConnect-client removal). Notes the GuruRMM agent-IP tracking gap (todo 7459428e). Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
1.2 KiB
name, description, metadata
| name | description | metadata | ||
|---|---|---|---|---|
| feedback_rmm_identify_by_ip | When the offending/target machine is known by external IP, identify the RMM agent by matching the IP — don't recon every candidate. |
|
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.