244 lines
13 KiB
Markdown
244 lines
13 KiB
Markdown
# 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.
|