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

sync: auto-sync from GURU-5070 at 2026-07-04 13:52:09

Browse Source 
Author: Mike Swanson
Machine: GURU-5070
Timestamp: 2026-07-04 13:52:09
This commit is contained in:
Mike Swanson
2026-07-04 13:52:35 -07:00
parent 0da31cbb65
commit d5020a6415
1 changed files with 1 additions and 1 deletions
Download Patch File Download Diff File Expand all files Collapse all files

2
wiki/clients/dataforth.md
View File

@@ -137,7 +137,7 @@ Signal conditioning / data acquisition manufacturer in Tucson, AZ. Long-standing
| ESXi hosts | 192.168.0.122, 192.168.0.124 | VMware ESXi hypervisors | ESXi | — |
| UDM Firewall | 192.168.0.254 | Perimeter firewall/router | UniFi OS 5.1.15 | MAC d0:21:f9:6c:11:02. Also responds on 192.168.0.1. SSH: `azcomputerguru@192.168.0.254`, root SSH key added 2026-06-08, 2FA push required. Vault: `clients/dataforth/udm.sops.yaml`. C2 IPs blocked via iptables (NOT permanent — need to add to UniFi UI). Boot scripts in `/data/on_boot.d/`: `10-neptune-snat.sh` (Neptune outbound SNAT), `30-freepbx-sip-forward.sh` (SIP DNAT, WAN UDP 5060 source-locked to 66.7.123.0/24 → 192.168.100.2; SIP-only — do NOT add RTP forward). **[WARNING] Confirmed 2026-06-23: the SIP DNAT rule can be silently flushed by a UniFi controller provision/update, not only a reboot** — the on_boot.d script only re-applies at boot, so a mid-uptime provision event leaves inbound calls dead until the script is manually re-run. Recommend adding a persistent UI port-forward rule as a belt-and-suspenders measure (still not done as of 2026-07-04). |
| PBX (Sangoma FreePBX) | 192.168.100.2 | VoIP PBX — production phones on 192.168.100.0/24 | Sangoma FreePBX 17 / Asterisk 22.5.2, Debian 12 | FirstDigital PJSIP trunk; SBC 66.7.123.215:5060 (Sonus), match 66.7.123.0/24; IP-auth (no registration). `qualify_frequency=0` (FD SBC ignores OPTIONS — do NOT revert). TFTP provisioning for Cisco SPA502G phones. Extensions 201-343. SSH: `sangoma@192.168.100.2` (ACG SSH key also authenticates). Vault: `clients/dataforth/pbx.sops.yaml` — password corrected 2026-06-23 (prior entry had a backslash-escaping corruption in the stored value; re-verify the vault entry byte-for-byte before use rather than assuming it is stale). [WARNING] Re-apply `PJSip.class.php` line-504 patch after any `fwconsole ma updateall`. **NOTE:** `sangoma` user is in the `sudo` group but sudo authorization on this box appears not actually granted — verify before assuming privileged ops will work via sudo. |
| **MYDATA TPSys SMT Controller** (`myserver`) | **192.168.1.1** (VLAN2, SSH-confirmed 2026-07-04) | MYDATA/Mycronic TPSys pick-and-place SMT production-line controller | Fedora Core 3 "Heidelberg" (Nov 2004), kernel 2.6.16.20, glibc ~2.3.5, bash 3.00, **LILO** bootloader, **SysV init** (no systemd) | **NEW, discovered 2026-07-04.** On VLAN 2 "mydata" (192.168.1.0/24). **[WARNING] The box's own IP 192.168.1.1 collides with the address recorded as the VLAN 2 gateway — reconcile: either this box IS the gateway/router for the SMT line, or there is an IP conflict with the UDM. Confirm before relying on either.** TPSys operator UI runs under X started from tpsys's autologin `.profile` -> `startx` on tty1 (default runlevel is **3**, not 5); local PostgreSQL backs TPSys. Accounts: `root`, `tpsys` (TPSys app user), `tpspool` (TPSys spool), `postgres`. **No credential existed prior to discovery** — root was RESET via physical-console LILO recovery, vaulted at `clients/dataforth/mydata-smt.sops.yaml` (initial entry had a password typo, corrected 2026-07-04 — re-read the vault value byte-for-byte). **[CRITICAL] root was intentionally PASSWORDLESS on this appliance** — TPSys's launcher `/home/tpsys/bin/go` escalates repeatedly via `su -c` with no tty, so *setting a root password broke every escalation* -> PostgreSQL/controller never start -> **X comes up empty (fvwm2 only, no TPSys UI).** **Resolved 2026-07-04:** `gpasswd -a tpsys wheel` + uncommented `auth sufficient .../pam_wheel.so trust use_uid` in `/etc/pam.d/su` (backup `su.bak-20260704`), restoring passwordless `su` while keeping a real root password; verified across a reboot (TPSys `mmi` came up). **Do NOT blank root, remove tpsys from wheel, or re-comment the trust line — the SMT line goes down.** Remote access: ACG RSA key `clients/dataforth/mydata-smt-ssh-key.sops.yaml` (FC3 OpenSSH 3.9 needs legacy `-o KexAlgorithms=+diffie-hellman-group14-sha1 -o HostKeyAlgorithms=+ssh-rsa -o PubkeyAcceptedAlgorithms=+ssh-rsa -o MACs=+hmac-sha1 -o Ciphers=+aes128-cbc`), or root pw. **GuruRMM agent CANNOT run on this box** — see Patterns below. |
| **MYDATA TPSys SMT Controller** (`myserver`) | **192.168.1.1** (VLAN2, SSH-confirmed 2026-07-04) | MYDATA/Mycronic TPSys pick-and-place SMT production-line controller | Fedora Core 3 "Heidelberg" (Nov 2004), kernel 2.6.16.20, glibc ~2.3.5, bash 3.00, **LILO** bootloader, **SysV init** (no systemd) | **NEW, discovered 2026-07-04.** On VLAN 2 "mydata" (192.168.1.0/24). **[WARNING] The box's own IP 192.168.1.1 collides with the address recorded as the VLAN 2 gateway — reconcile: either this box IS the gateway/router for the SMT line, or there is an IP conflict with the UDM. Confirm before relying on either.** TPSys operator UI runs under X started from tpsys's autologin `.profile` -> `startx` on tty1 (default runlevel is **3**, not 5); local PostgreSQL backs TPSys. Accounts: `root`, `tpsys` (TPSys app user), `tpspool` (TPSys spool), `postgres`. **No credential existed prior to discovery** — root was RESET via physical-console LILO recovery, vaulted at `clients/dataforth/mydata-smt.sops.yaml` (initial entry had a password typo, corrected 2026-07-04 — re-read the vault value byte-for-byte). **[CRITICAL] root was intentionally PASSWORDLESS on this appliance** — TPSys's launcher `/home/tpsys/bin/go` escalates repeatedly via `su -c` with no tty, so *setting a root password broke every escalation* -> PostgreSQL/controller never start -> **X comes up empty (fvwm2 only, no TPSys UI).** **Resolved 2026-07-04:** `gpasswd -a tpsys wheel` + uncommented `auth sufficient .../pam_wheel.so trust use_uid` in `/etc/pam.d/su` (backup `su.bak-20260704`), restoring passwordless `su` while keeping a real root password; verified across a reboot (TPSys `mmi` came up). **Do NOT blank root, remove tpsys from wheel, or re-comment the trust line — the SMT line goes down.** Remote access: ACG RSA key `clients/dataforth/mydata-smt-ssh-key.sops.yaml` (FC3 OpenSSH 3.9 needs legacy `-o KexAlgorithms=+diffie-hellman-group14-sha1 -o HostKeyAlgorithms=+ssh-rsa -o PubkeyAcceptedAlgorithms=+ssh-rsa -o MACs=+hmac-sha1 -o Ciphers=+aes128-cbc`), or root pw. **DR backup (2026-07-04):** hybrid live image — partition table + MBR/LILO + raw `dd` of OS partitions (hda1/2/5/6) + `/home` tar + `pg_dumpall`, ~640 MB, SHA256-verified, with `README-RESTORE.md` runbook. Copies: **on-site** `D2TESTNAS:/root/dr-backups/mydata-tpsys/2026-07-04/`; **offsite** `AD1 C:\Shares\ITSvc\DR\mydata-tpsys\2026-07-04\` (inside AD1's MSP360 Files plan → B2 bucket `ACG-Dataforth`, nightly 2 AM). TODO: full offline 80 GB `dd`/Clonezilla image in a maintenance window; install a backup agent on D2TESTNAS so the on-site DR store self-protects to B2. **GuruRMM agent CANNOT run on this box** — see Patterns below. |
**Neptune Exchange (ACG infrastructure, physically at Dataforth D2):**
- `neptune.acghosting.com` | internal `172.16.3.11` | external inbound `67.206.163.124` / outbound `67.206.163.122`