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

sync: auto-sync from HOWARD-HOME at 2026-07-04 14:18:41

Browse Source 
Author: Howard Enos
Machine: HOWARD-HOME
Timestamp: 2026-07-04 14:18:41
This commit is contained in:
Howard Enos
2026-07-04 14:19:09 -07:00
parent d5020a6415
commit a733db1029
2 changed files with 54 additions and 0 deletions
Download Patch File Download Diff File Expand all files Collapse all files

52
clients/dataforth/session-logs/2026-07/2026-07-04-howard-mydata-tpsys-smt-controller-access.md
View File

@@ -189,3 +189,55 @@ binary and installs a **systemd** service. FC3 = glibc ~2.3.5 (needs ~2.17+), ke
gw 192.168.1.1, D2-SMT switch, inter-VLAN routing to main LAN open.
- Vault target (to create): `clients/dataforth/mydata-smt.sops.yaml`
- Fedora Core 3 "Heidelberg": released 2004-11-08, kernel 2.6.x, glibc 2.3.5.
---
## Update: 12:20 PT — mydata cred vaulted, wiki compiled, VPN groundwork, sysadmin cred pull
**mydata TPSys controller — credential captured + vaulted.** Howard relayed the reset root
password: `D@ataF0rth`. Created and SOPS-encrypted `clients/dataforth/mydata-smt.sops.yaml`
(root cred + full context; decrypt-verified round-trip). IP later confirmed by Howard as
**192.168.1.1** (`sops set` into the entry). NOTE: 192.168.1.1 was the address our old wiki
note called the VLAN 2 *gateway* — I flagged this as a possible collision/conflict, but
**Howard confirmed onsite there is NO VLAN 2 issue** (logged as a `--correction`: should not
have raised an alarm from a stale-note assumption over the onsite check). Records updated to
"verified OK", not a warning.
**Wiki:** ran `/wiki-compile client:dataforth --full` (Sonnet subagent). Rebuilt
`wiki/clients/dataforth.md` (520 -> 581 lines, sources 67 -> 73), folded in the MYDATA
controller across Infrastructure/Workstations/GuruRMM-cannot-enroll/Access(vault-path-only)/
Patterns(agent-floor + LILO recovery)/Active Work/History, plus the post-6/23 logs (PBX
inbound fix, DFORTH-Ship BSOD, test-data-chain audit). Syncro live: 30.0 hrs, 0 tickets, 50
assets. Subagent caught+scrubbed an accidental inline of the PBX raw password mid-draft;
independent re-scan confirmed the staged file clean before apply. Committed + pushed. `index.md`
row + header updated.
**VPN groundwork (Howard wants Dataforth OpenVPN on Howard-Home to SSH into machines).**
Established (all read-only, NO changes to any Dataforth machine per Howard's "Mike is messing
with the mydata box" instruction):
- OpenVPN **server = Dataforth UDM** (192.168.0.254, subnet 192.168.6.0/24). Reached only via
D2TESTNAS jump (UDM not off-LAN SSH-routable).
- Howard-Home has **OpenVPN Connect 3.9.0** (profiles at `%APPDATA%\OpenVPN Connect\profiles`;
existing `1781585349795.ovpn` left untouched) + **Tailscale** (can see d2testnas 100.85.152.90,
guru-5070-1 100.81.65.103).
- No Dataforth OpenVPN profile in the vault; only known working profile is on GURU-5070.
- d2testnas Tailscale SSH: key-auth **denied** for Howard-Home (password works; but no
`sshpass`/`plink` here for non-interactive). UDM root SSH key is `DESKTOP-0O8A1RL` (not
Howard-Home).
- Decision: Howard chose **Option B** (mint a dedicated `howard-home` client profile on the
UDM) over reusing GURU-5070's (duplicate-CN bump risk). **Then Howard said he already HAS
the config file** — so the profile-minting is moot; he imports his `.ovpn` locally himself.
**Dataforth sysadmin credential** (requested for SSH/WinRM to servers over the VPN), from
vault: `INTRANET\sysadmin` / `Paper123!@#` (SSH username `sysadmin`, drop domain prefix). AD1
vault entry had the **same stale backslash** quirk (`Paper123\!@#`) as the DOS-pipeline docs —
**fixed** via `sops set clients/dataforth/ad1.sops.yaml` -> clean `Paper123!@#`, decrypt-verified,
committed. AD2 entry was already clean. Reminder surfaced: pin OpenVPN adapter MTU to 1400 or
bulk SSH/SCP to AD2 blackholes (see [[ad2-ssh-mtu-blackhole]]).
**Vault commits this update:** mydata-smt add (`b3c6029`), mydata IP set (`4fa6f4f`), ad1
backslash fix (`8102f13`).
**Still open:** confirm `tpsys` wheel+NOPASSWD sudo landed and TPSys booted clean (Mike is on
that box — hands off); stand up agentless monitoring for the FC3 controller; Howard to confirm
his OpenVPN profile connects + SSH into the target machine works.

2
errorlog.md
View File

@@ -19,6 +19,8 @@ Categories (the `[type]` tag): _(none)_ = skill/command execution failure ·
<!-- Append entries below this line -->
2026-07-04 | Howard-Home | wiki-compile/dataforth | [correction] flagged 192.168.1.1 as a VLAN2 gateway/IP collision WARNING from a stale wiki note; Howard confirmed onsite there is no VLAN2 conflict - should have checked/trusted the onsite verification instead of raising an alarm from an assumption
2026-07-04 | Howard-Home | bash/quoting | [friction] inline PS-in-bash heredoc with nested quotes mangled by CommandLineToArgvW on dispatch to RMM; fixed by file+EncodedCommand path [ctx: ref=feedback_windows_quote_stripping]
2026-07-04 | GURU-5070 | dataforth/mydata-tpsys | [correction] root was intentionally PASSWORDLESS on the MYDATA TPSys controller because the app launcher bin/go escalates via 'su -c' with no tty; setting a root password broke all escalation and left X empty (no TPSys UI). Correct fix: keep root pw but add tpsys to wheel + uncomment pam_wheel 'trust' in /etc/pam.d/su. Never blank root or remove wheel-trust or the SMT line goes down. [ctx: machine=myserver ip=192.168.1.1 os=FC3 ref=wiki/clients/dataforth.md]