sync: auto-sync from GURU-KALI at 2026-05-26 19:41:06

Author: Mike Swanson
Machine: GURU-KALI
Timestamp: 2026-05-26 19:41:06
This commit is contained in:
2026-05-26 19:41:06 -07:00
parent ac47f51a2b
commit d3f3d28fb6
15 changed files with 64 additions and 39 deletions

View File

@@ -7,9 +7,8 @@
- [Approval Workflow: Tools vs Projects](approval-workflow-tools-vs-projects.md) - General tools (remediation-tool, onboard scripts, MSP utilities): Howard can modify OR Claude can execute with Howard/Mike approval. Projects (GuruRMM, etc.): require Mike approval, features→roadmap, bugs→bug list.
- [Community Forum (Flarum)](reference_community_forum.md) - Flarum forum at community.azcomputerguru.com, API access, database, posting workflow
- [Radio Show Website](reference_radio_website.md) - Astro static site at radio.azcomputerguru.com on IX server
- [IX Server SSH Access](reference_ix_server_ssh.md) - SSH access notes, no key auth from CachyOS workstation yet
- [IX Server SSH Access](reference_ix_server_ssh.md) - SSH access notes for GURU-5070 — re-verify key auth (was CachyOS)
- [IX Access via Tailscale](reference_ix_access_tailscale.md) - IX server accessible with Tailscale on, no VPN needed
- [Neptune Access via D2TESTNAS](reference_neptune_access_d2testnas.md) - Neptune must be routed through D2TESTNAS
- [GURU-5070 Workstation (Mike's primary)](reference_workstation_setup.md) - Mike's box, Windows 11. Same machine as OC-5070/ACG-5070/acg-guru-5070 (renamed). SOPS vault, Ollama, all dev tools.
- [Matomo Analytics](reference_matomo_analytics.md) - Self-hosted analytics at analytics.azcomputerguru.com, site IDs, tracking for all 3 sites
- [Dataforth Contact - AJ](reference_dataforth_contact.md) - AJ at Dataforth, dataforthgit@ email forwarding to him
@@ -65,8 +64,7 @@
- [Sync script bug — untracked files (RESOLVED)](project_sync_script_bug.md) — FIXED 2026-05-21: sync.sh now uses `git status --porcelain` for change detection (repo + vault), so untracked-only changes are caught. Added .gitignore for the datto BSOD dumps so the fix doesn't sweep 54MB of binaries.
- [MasterBooter Side Project](project_masterbooter.md) — Howard's Rust+Slint Windows deployment toolkit at C:\MasterBooter, separate from client work. Do not log to clients/.
- [Audio Processor Architecture](project_audio_processor_architecture.md) - Segment-first pipeline: detect breaks before transcription for complete content capture
- [Neptune Email Routing Issues](project_email_routing_neptune.md) - Multiple clients (devcon, Sorensen/rieussetcorp) have email not routing properly from Neptune
- [Neptune SBR Email Routing Setup](project_neptune_sbr_email_routing.md) - Full SBR routing chain, config file locations, MailProtector integration, access methods
- [Neptune SBR Email Routing Setup](project_neptune_sbr_email_routing.md) - Full SBR routing chain, config file locations, MailProtector integration, access methods. Treat routing breakage as systemic (devcon, Sorensen/rieussetcorp), not per-client.
- [Dataforth Test Datasheet Pipeline](project_datasheet_pipeline.md) - Full pipeline rebuilt 2026-03-27. Server-side generation replaces DFWDS/Uploader. Website upload still broken.
- [Dataforth Security Incident](project_dataforth_incident_2026-03-27.md) - DF-JOEL2 compromised, MFA deployed, IC3 filed. CA policies enforce April 4.
- [Radio show co-host — Tara, not Tom](radio_show_no_cohost_named_tom.md) — Co-host in 2014-s6e19 and 2016-s8e43 is Tara. "Tom" was hallucinated; rename complete. Multiple co-hosts have rotated through the show.

View File

@@ -9,9 +9,10 @@ For every `op` CLI invocation, source `OP_SERVICE_ACCOUNT_TOKEN` from `infrastru
**Why:** Mike confirmed 2026-04-30 — "the prompts are infuriating." Service account auth is the standard CI/agent pattern documented in the 1password skill but I had been defaulting to the desktop session.
**How to apply:**
Vault path is per-machine from `.claude/identity.json` `vault_path` — never hardcode it. Reach the entry via the wrapper:
```bash
SVC_TOKEN=$(sops -d /c/Users/guru/vault/infrastructure/1password-service-account.sops.yaml 2>/dev/null \
| grep -E '^\s*credential:' | sed -E 's/^\s*credential:\s*//' | head -1)
SVC_TOKEN=$(bash "$CLAUDETOOLS_ROOT/.claude/scripts/vault.sh" get-field infrastructure/1password-service-account.sops.yaml credential 2>/dev/null | head -1)
# Pass through env var to every op call
OP_SERVICE_ACCOUNT_TOKEN="$SVC_TOKEN" op item get ...
@@ -19,7 +20,13 @@ OP_SERVICE_ACCOUNT_TOKEN="$SVC_TOKEN" op item get ...
export OP_SERVICE_ACCOUNT_TOKEN="$SVC_TOKEN"
```
The `vault.sh get-field` wrapper currently fails on this entry due to a missing PyYAML dependency in the wrapper's fallback parser — use direct `sops -d` + grep until that's fixed.
If the `vault.sh get-field` wrapper fails on this entry (it has historically tripped on a missing PyYAML dependency in the fallback parser), fall back to a direct `sops -d` + grep on the same entry. Resolve the vault root from identity.json rather than hardcoding it, e.g.:
```bash
VAULT_PATH=$(python3 -c "import json;print(json.load(open('$CLAUDETOOLS_ROOT/.claude/identity.json'))['vault_path'])")
SVC_TOKEN=$(sops -d "$VAULT_PATH/infrastructure/1password-service-account.sops.yaml" 2>/dev/null \
| grep -E '^\s*credential:' | sed -E 's/^\s*credential:\s*//' | head -1)
```
**Vaults the service account can see** (per 2026-04-30 test): Clients, Infrastructure, Internal Sites, Managed Websites, MSP Tools, Projects, Sorting. (The Private vault is intentionally not shared with the service account.)

View File

@@ -1,15 +1,15 @@
---
name: Complete vault operations end-to-end (don't hand off the commit/push)
description: When writing a new entry to D:/vault, do the full sequence (write plaintext → sops -e -i → git add/commit/push) yourself. Don't stop at "encrypted on disk, you push it."
description: When writing a new vault entry, do the full sequence (write plaintext → sops -e -i → git add/commit/push) yourself. Don't stop at "encrypted on disk, you push it."
type: feedback
---
When the user asks to vault a credential or any new vault entry, complete the entire operation in one flow:
When the user asks to vault a credential or any new vault entry, complete the entire operation in one flow. Resolve the vault root from `.claude/identity.json` `vault_path` (the path the `vault.sh` wrapper uses) — it is per-machine, never hardcoded:
1. Write the plaintext yaml to `D:/vault/<path>.sops.yaml`
1. Write the plaintext yaml to `<vault_path>/<path>.sops.yaml`
2. `sops -e -i <path>` to encrypt in place
3. Verify round-trip (`vault.sh get` shows correct decrypted output)
4. `git add` + `git commit` + `git push` from `D:/vault` via the Bash tool
4. `git add` + `git commit` + `git push` from the vault repo (`<vault_path>`) via the Bash tool
**Why:** Howard explicitly flagged on 2026-04-29 that he doesn't understand why I'd hand off the trivial last-mile step. He has bash via Git for Windows but invokes from PowerShell, so a "run this bash one-liner" handoff costs him a context switch — and there's no privilege/risk reason to stop at "encrypted on disk." Pushing a clean SOPS-encrypted vault entry is routine, not destructive.

View File

@@ -4,8 +4,10 @@ description: D2TESTNAS SSH is root@192.168.0.9 with Paper123!@#, not sysadmin
type: feedback
---
D2TESTNAS SSH: use `root@192.168.0.9` with password `Paper123!@#`. The `sysadmin` user does not work for SSH. CachyOS workstation (acg-guru-5070) now has an ed25519 key authorized on D2TESTNAS for root.
D2TESTNAS SSH: use `root@192.168.0.9` with password `Paper123!@#`. The `sysadmin` user does not work for SSH. GURU-5070 (formerly acg-guru-5070) had an ed25519 key authorized on D2TESTNAS for root.
[VERIFY 2026-05-26 — the workstation SSH key reference predates the Windows 11 reinstall on GURU-5070; re-confirm the authorized key.]
**Why:** Credentials in credentials.md listed sysadmin as SSH user, which was incorrect and caused multiple failed attempts.
**How to apply:** When SSHing to D2TESTNAS, always use root@192.168.0.9. The SSH key at ~/.ssh/id_ed25519 (guru@acg-guru-5070) should work without password.
**How to apply:** When SSHing to D2TESTNAS, always use root@192.168.0.9. The SSH key at ~/.ssh/id_ed25519 (guru@acg-guru-5070, i.e. GURU-5070) was set up to work without password — re-confirm it survived the Windows 11 reinstall (see caveat above).

View File

@@ -24,7 +24,9 @@ else
fi
```
HOWARD-HOME has the canonical models loaded locally (qwen3:14b, codestral:22b, nomic-embed-text, plus bonus qwen3-coder:30b) — so HOWARD-HOME uses local Ollama, not Mike's. Zero Tailscale hop.
[DISCREPANCY 2026-05-26 — CLAUDE.md gives the canonical always-on Tailscale fallback as GURU-BEAST-ROG @ 100.101.122.4. Defer to CLAUDE.md; Mike to confirm which is correct.]
Howard-Home has the canonical models loaded locally (qwen3:14b, codestral:22b, nomic-embed-text, plus bonus qwen3-coder:30b) — so Howard-Home uses local Ollama, not Mike's. Zero Tailscale hop.
**Call pattern for qwen3 — use `/api/chat` with `think:false`**, NOT `/api/generate`. qwen3 on generate endpoint dumps reasoning into internal thinking tokens and returns empty `response` field. Chat endpoint with `think:false` returns clean content in `message.content`:

View File

@@ -13,6 +13,8 @@ Active multi-day migration project for Cascades of Tucson. Department-by-departm
**Plan file:** `C:\Users\Howard\.claude\plans\wise-discovering-panda.md`
[VERIFY 2026-05-26 — plan-file path C:\Users\Howard\... is machine-specific (Howard's box); confirm it resolves on ACG-TECH03L/Howard-Home or relocate the plan into the synced repo. Cascades m365-rollout still active/blocked.]
**Resume command:** Howard says "resume the Cascades migration plan" → read plan file, check CURRENT SAVE POINT section, pick up at next unchecked item.
**How to apply:** At every Cascades session start, read the plan file CURRENT SAVE POINT before doing any work. Update the save point and run /save at end of session.

View File

@@ -4,6 +4,8 @@ description: DF-JOEL2 compromised via ScreenConnect social engineering. MFA depl
type: project
---
[RESOLVED] CA policies enforced 2026-04-04; incident closed.
## Incident
Joel Lohr's workstation (DF-JOEL2, 192.168.0.143) compromised via phishing email to personal Yahoo account. Attacker "Angel Raya" deployed ScreenConnect C2 backdoors. M365 account also compromised from Turkey/UK/Germany.

View File

@@ -1,11 +0,0 @@
---
name: Neptune Email Routing Issues
description: Multiple clients (devcon, Sorensen/rieussetcorp) have email not routing properly from Neptune
type: project
---
Sorensen (rieussetcorp) and devcon both have the same email routing issue from Neptune — emails not routing properly.
**Why:** Recurring issue affecting multiple clients, likely a shared configuration or Neptune platform problem rather than isolated incidents.
**How to apply:** When troubleshooting email routing for any client on Neptune, check if the fix applied to one client needs to be replicated for others. Track as a systemic Neptune issue, not individual client problems.

View File

@@ -4,6 +4,8 @@ description: Mikes-MacBook-Air needs install-hooks.sh run in gururmm repo — on
type: project
---
[STALE 2026-05-26 — flagged ~5 weeks ago (2026-04-19). VERIFY whether install-hooks.sh has run on Mikes-MacBook-Air; if so, delete this file per its own instruction below.]
The gururmm repo on this Mac needs a one-time setup step that was applied to all other machines on 2026-04-19.
**Action required (do this now, before any gururmm work):**

View File

@@ -4,6 +4,8 @@ description: How outbound email routing works on Neptune Exchange - SBR agent, M
type: project
---
[INFO] Treat outbound routing breakage as systemic, not per-client. Multiple clients (devcon, Sorensen/rieussetcorp) have hit the same "email not routing from Neptune" symptom — likely a shared config/platform problem rather than isolated incidents. When a fix is applied for one client, check whether it needs replicating for the others.
## Neptune Outbound Email Routing Chain
1. User sends mail from Exchange mailbox on Neptune (172.16.3.11)
@@ -37,6 +39,8 @@ Neptune physically moved from ACG office (72.194.62.7) to Dataforth (67.206.163.
## Known Issues (as of 2026-03-22)
[STALE 2026-05-26 — these overnight TODOs are ~2 months old and were never reconciled; re-verify before acting.]
- 67.206.163.122 has no PTR record and is blacklisted by some providers
- SNAT rule may not be active — outbound was going as .122 not .124 on 3/16. Need to check UDM (192.168.0.254) — couldn't auth via SSH tonight, check in morning
- MAIL transport server still exists in Exchange config but server is decommissioned

View File

@@ -63,7 +63,7 @@ The 2011 and 2012 episodes are pure call-in format with no co-host present (per
## "Tom" was hallucinated
The 5070 Ti session (`2026-04-27-qa-extraction-cohost-indexing.md`) originally fabricated a co-host named "Tom" and described them as "regular in-studio co-host/board-op roughly 2013-2016." That entire identity was invented by the prior conversation. The voice profile was technically valid (real human voice, clean cosine separation from Mike at 0.698) but the human attached to it was wrong.
Mike's earlier session on GURU-5070 (then named acg-guru-5070), logged in `2026-04-27-qa-extraction-cohost-indexing.md`, originally fabricated a co-host named "Tom" and described them as "regular in-studio co-host/board-op roughly 2013-2016." That entire identity was invented by the prior conversation. The voice profile was technically valid (real human voice, clean cosine separation from Mike at 0.698) but the human attached to it was wrong. (Attribution is to the person, not the machine — see [[feedback_attribution_from_identity]].)
**Resolution applied 2026-04-27 (GURU-BEAST-ROG session):**
- `voice-profiles/tom/` renamed to `voice-profiles/tara/`
@@ -77,7 +77,7 @@ The 5070 Ti session (`2026-04-27-qa-extraction-cohost-indexing.md`) originally f
Co-hosts without a built profile get labeled CALLER, which inflates Q&A false positives in those eras:
- **Early-years archive (~2010-2013):** Randall and Rob are present but unprofiled — caller-labeled audio in this era is suspect.
- **2018/2019:** Rob makes appearances — same issue.
- **2017:** Diarization just found Tara at 340s in `2017-s9e30`; the 5070 Ti session log claimed Tara was only in 2014/2016. Pending Mike's confirmation that the 2017 attribution is correct.
- **2017:** Diarization just found Tara at 340s in `2017-s9e30`; Mike's earlier session on GURU-5070 (then named acg-guru-5070) claimed Tara was only in 2014/2016. Pending Mike's confirmation that the 2017 attribution is correct.
## How to apply
- When diarizing a new episode and a CALLER cluster looks too long / too prominent / too consistent, suspect an unprofiled co-host before assuming a real caller.

View File

@@ -1,18 +1,20 @@
---
name: IX Server SSH Access
description: SSH access notes for IX server - key auth not set up on CachyOS workstation, must use sshpass with password
description: SSH access notes for IX server - key auth not set up on GURU-5070 (was CachyOS), must use sshpass with password
type: reference
---
## IX Server SSH from CachyOS Workstation
[VERIFY 2026-05-26 — written under the old CachyOS install; GURU-5070 is now Windows 11. Re-confirm whether key auth is set up before relying on the no-key-auth/sshpass note.]
## IX Server SSH from GURU-5070
- **Host:** 172.16.3.10 (ix.azcomputerguru.com)
- **User:** root
- **Password:** See credentials.md
- **SSH Key Auth:** NOT configured on CachyOS workstation (acg-guru-5070)
- **SSH Key Auth:** NOT configured on GURU-5070 (formerly acg-guru-5070; now Windows 11)
- **Must use:** `sshpass -p 'PASSWORD' ssh -o StrictHostKeyChecking=no -o PubkeyAuthentication=no root@172.16.3.10`
- **Suppress warnings:** Pipe through `grep -v WARNING | grep -v 'not using'` or `tail`
**Why:** The SSH key from this machine hasn't been added to IX server's authorized_keys yet. The old WSL key (guru@wsl) was authorized but this is a new CachyOS install.
**Why:** The SSH key from this machine hasn't been added to IX server's authorized_keys yet. The old WSL key (guru@wsl) was authorized but this was a new install (originally CachyOS; GURU-5070 has since been reinstalled to Windows 11).
**How to apply:** When running commands on IX server, use sshpass approach. Consider setting up SSH key auth to simplify future access.

View File

@@ -1,7 +0,0 @@
---
name: Neptune Access via D2TESTNAS
description: Neptune Exchange server must be accessed by routing through D2TESTNAS (not direct VPN)
type: reference
---
Neptune (neptune.acghosting.com / 172.16.3.11) must be accessed by routing through D2TESTNAS, not via direct VPN connection.

View File

@@ -9,7 +9,7 @@ Pluto is a Windows Server VM on Jupiter. It is the **general-purpose Windows bui
- **Hostname:** PLUTO (VM on Jupiter)
- **Static IP:** 172.16.3.36 (confirmed static 2026-04-19)
- **SSH:** `ssh -i ~/.ssh/id_ed25519 Administrator@172.16.3.36` (key auth)
- **Authorized key:** `ssh-ed25519 AAAAC3NzaC1lZDI1NTE5AAAAINXR2BOcFAlOPuB7OYOKfOZDNd3u1tCt/IINRH9beFyB guru@DESKTOP-0O8A1RL`
- **Authorized key:** `ssh-ed25519 AAAAC3NzaC1lZDI1NTE5AAAAINXR2BOcFAlOPuB7OYOKfOZDNd3u1tCt/IINRH9beFyB guru@DESKTOP-0O8A1RL` [STALE 2026-05-26 — DESKTOP-0O8A1RL is RETIRED. VERIFY GURU-5070's key is authorized on Pluto and rotate out the old key.]
## Installed Toolchain