azcomputerguru/claudetools
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity
Files
840b0ce9d650ca1b941dcf94a183020e931e27d4
claudetools/clients/dataforth/session-logs/2026-07/2026-07-04-howard-mydata-tpsys-smt-controller-access.md
Howard Enos a733db1029 sync: auto-sync from HOWARD-HOME at 2026-07-04 14:18:41 
Author: Howard Enos
Machine: HOWARD-HOME
Timestamp: 2026-07-04 14:18:41
2026-07-04 14:19:11 -07:00

13 KiB
Raw Blame History

Dataforth — MYDATA TPSys SMT Controller Root Recovery + RMM Feasibility

User

  • User: Howard Enos (howard)
  • Machine: Howard-Home
  • Role: tech

Session Summary

Session began as a DOS 6.22 -> MS-DOS 7.1 upgrade plan for Dataforth's D2 test stations (64 QuickBASIC ATE machines), building toward a Ventoy/Clonezilla + PXE delivery scheme. Mike redirected to a different approach and that DOS-upgrade work was explicitly dropped (no artifacts saved for it).

The session then pivoted to a previously-undocumented Linux machine on Dataforth's VLAN 2 "mydata" SMT production network. Howard was physically at the console and had interrupted the boot. Checked the vault/wiki for a stored credential — none existed for this box (the only documented Linux at Dataforth is D2TESTNAS at 192.168.0.9, which is a different machine). With no credential on file, performed an in-place root password reset via the LILO bootloader: at the boot: prompt, booted linux init=/bin/bash rw to land in a passwordless root shell, remounted / read-write, and reset the password with passwd.

Enumerating /etc/passwd identified the machine as a MYDATA/Mycronic TPSys SMT pick-and-place line controller — login accounts were root, tpsys (TPSys User), tpspool (TPSys Spool), and postgres (uid 500). OS confirmed as Fedora Core 3 "Heidelberg" (Nov 2004), kernel 2.6.16.20 — a ~20-year-old appliance. Hostname prompt showed myserver.

Mike directed adding tpsys to the wheel group and enabling it to launch the TPSys app without a root-password prompt (passwordless sudo). Provided the safe gpasswd -a (append) method plus the scoped NOPASSWD sudoers pattern via visudo. Howard then asked about installing the GuruRMM agent on this box. Read the agent installer (agent/scripts/install.sh) and confirmed the agent is a hard no on this OS: modern glibc Rust binary (needs glibc ~2.17+, FC3 has ~2.3.5), kernel floor (Rust needs >=2.6.32, box is 2.6.16), and the installer targets systemd (FC3 is SysV init). Recommended agentless/external monitoring instead. Session ended at /save before Howard supplied the new root password and the machine's IP for vaulting.

Key Decisions

  • Dropped the DOS 7.1 upgrade work entirely — Mike is taking a different route. No plan artifacts, images, or scripts were committed for it.
  • Reset root via LILO init=/bin/bash rather than single-user/sulogin — on old Red Hat family systems single-user can invoke sulogin which itself demands the root password; init=/bin/bash bypasses init and guarantees a passwordless shell.
  • gpasswd -a tpsys wheel (append), never usermod -G — plain -G replaces all supplementary groups and would strip tpsys's existing memberships, risking the app.
  • Scoped NOPASSWD sudoers entry (whitelist the single launch command) recommended over blanket NOPASSWD: ALL, on a production controller.
  • GuruRMM agent ruled out for this machine — three independent hard blockers (glibc, kernel, no systemd). Recommended agentless monitoring (ICMP/TCP probe or SSH heartbeat from D2TESTNAS or the RMM server, both of which can reach VLAN 2 since inter-VLAN routing is open) and, if formalized, a /feature-request for legacy/appliance Linux monitoring.

Problems Encountered

  • No stored credential for the mydata controller — not in vault, not in wiki. Resolved by physical-console LILO root reset.
  • Context-loading miss (logged as correction) — initially grepped only the user's misspelling ("datforth"/"dataforth") and did not read the existing wiki articles until the user said "use the wiki." The wiki had full Dataforth infra. Logged via log-skill-error.sh --correction.
  • Minimal shell env under init=/bin/bash — /home appeared empty (separate partition not mounted; only / mounts) and PATH was stripped, so enumeration commands needed full paths / /etc/passwd was read directly. awk one-liner was mangled by quote handling; grep -E 'bash|/bin/sh' /etc/passwd worked and produced the account list.
  • X started at reboot unexpectedly — the box had likely been up for years and Howard had never watched it boot; TPSys's operator UI runs under X, so this was the normal graphical boot path, not damage from the reset.

Configuration Changes

On the mydata TPSys controller (Fedora Core 3, VLAN 2 mydata 192.168.1.x):

  • Root password reset to a new value (value not yet supplied to this session — pending vaulting).
  • Directed (may or may not have been completed by Howard before /save):
    • gpasswd -a tpsys wheel — add tpsys to wheel
    • visudo — ensure %wheel ALL=(ALL) ALL enabled; add scoped tpsys ALL=(root) NOPASSWD: <app-launch-command> for passwordless app start

In the repo:

  • Created this session log.
  • errorlog.md — one --correction entry (context-loading/dataforth).

Credentials & Secrets

  • mydata TPSys controller root password — RESET this session. Value not captured in this session (Howard had not yet relayed it at /save). MUST be collected and vaulted at clients/dataforth/mydata-smt.sops.yaml. Also capture tpsys password if one was set.
  • Accounts present on the box: root (uid 0, /bin/bash), tpsys (TPSys app user), tpspool (TPSys spool), postgres (uid 500, TPSys database).
  • No secrets were exposed for existing infra beyond what is already vaulted.

Infrastructure & Servers

  • NEW / previously undocumented: MYDATA TPSys SMT line controller
    • Hostname: myserver
    • Network: Dataforth VLAN 2 "mydata" (192.168.1.0/24, gateway 192.168.1.1) — SMT production line. Exact IP not yet confirmed (candidate labels on this VLAN from the wiki: My9-PC, goldstar19, DESKTOP-FT0T4MK, plus unnamed industrial MACs).
    • OS: Fedora Core 3 "Heidelberg" (released Nov 2004), kernel 2.6.16.20, glibc ~2.3.5, bash 3.00, LILO bootloader, SysV init (no systemd).
    • Role: MYDATA/Mycronic pick-and-place SMT machine control software (TPSys). Operator UI runs under X (runlevel 5). Local PostgreSQL (uid 500) backs TPSys.
  • Related documented Dataforth infra (unchanged): D2TESTNAS 192.168.0.9 (Debian 13, the other on-site Linux box), UDM 192.168.0.254, inter-VLAN routing mydata -> main LAN is OPEN.

Commands & Outputs

LILO root reset (at boot: prompt):

linux init=/bin/bash rw
# -> bash-3.00# (passwordless root shell)
mount -o remount,rw /
grep -E 'bash|/bin/sh' /etc/passwd
#   root:x:0:0:root:/root:/bin/bash
#   ftp:x:14:50:FTP User:/var/ftp:/bin/bash
#   tpsys:x:119:119:TPSys User:/home/tpsys:/bin/bash
#   tpspool:x:119:119:TPSys Spool:/home/tpsys/spool:/bin/bash
#   postgres:x:500:500::/home/postgres:/bin/bash
passwd root
sync
reboot -f            # (echo b > /proc/sysrq-trigger as fallback)

Add tpsys to wheel + passwordless app launch (directed):

gpasswd -a tpsys wheel
id tpsys
grep -n wheel /etc/sudoers        # ensure %wheel ALL=(ALL) ALL uncommented
visudo                            # add: tpsys ALL=(root) NOPASSWD: /path/to/app
su - tpsys -c 'sudo -l'           # verify

RMM feasibility probe (as tpsys, read-only):

cat /etc/redhat-release   # -> Fedora Core release 3 (Heidelberg)
uname -r                  # -> 2.6.16.20

GuruRMM agent verdict: cannot run. Installer (projects/msp-tools/guru-rmm/agent/scripts/install.sh) downloads a modern glibc Rust binary and installs a systemd service. FC3 = glibc ~2.3.5 (needs ~2.17+), kernel 2.6.16 (Rust needs >=2.6.32), no systemd (SysV init). Three independent hard blockers.

Pending / Incomplete Tasks

  1. Collect the new root password (and tpsys password if set) from Howard and vault it at clients/dataforth/mydata-smt.sops.yaml — with host, VLAN/IP, OS, accounts, and the LILO init=/bin/bash recovery method documented. (Blocked on Howard relaying the value.)
  2. Confirm the machine's IP on 192.168.1.x (and the chassis label) to finish the vault + wiki entry.
  3. Verify the wheel/sudoers changes actually landed (id tpsys, sudo -l as tpsys) and that the passwordless app-launch command is correct — need the exact TPSys launch command/path from Howard.
  4. Confirm the controller booted cleanly into TPSys after the forced reboot (it is a live SMT controller).
  5. Monitoring decision: agentless (ICMP/TCP probe or SSH heartbeat from D2TESTNAS/RMM server) since the agent is impossible here. If Mike wants it formalized, capture via /feature-request (legacy/appliance Linux monitoring in GuruRMM).
  6. Add a wiki entry for this controller under clients/dataforth (new VLAN 2 SMT asset).

Reference Information

  • GuruRMM Linux installer: projects/msp-tools/guru-rmm/agent/scripts/install.sh
    • Download URL pattern: https://rmm.azcomputerguru.com/downloads/gururmm-agent-linux-amd64
    • Server WSS: wss://rmm-api.azcomputerguru.com/ws, installs systemd unit gururmm-agent
  • Dataforth wiki: wiki/clients/dataforth.md, wiki/projects/dataforth-dos.md
  • VLAN 2 "mydata" detail: wiki/clients/dataforth.md (Network section) — 192.168.1.0/24, 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.

Reference in New Issue View Git Blame Copy Permalink