TRMM-Linux-Agent-Konzept

abstract: Kurzfassung Linux-Hosts in TRMM laufen bei CORESTREAM inzwischen über einen eigenen Linux-Agent-Fork mit vorgebauten, SHA256-verifizierten Linux-Binaries und mobile-freundlichem curl | bash-Installer. Der frühere netvolt-/Live-Compile-Workaround entfällt. Der Pilot mit v2.11.0-cs4 wurde erfolgreich getestet; Mesh + tacticalagent.service funktionieren.

1. Problemstellung

warning: Show-Stopper im MSP-Alltag Linux-Hosts lassen sich in TRMM nur über einen umständlichen, nicht automatisierbaren Workaround aufnehmen. Pro Maschine von Hand — nicht skalierbar.

• Ursache = TRMM Paywall: Signierte Agenten (inkl. Linux) liefert TRMM nur an zahlende Sponsoren (Tier 1, monatlich) über einen eigenen Code-Signing-Server. Agent-Generate ohne Token → HTTP 400 → kein offizieller Linux-Agent.
• Workaround = netvolt-Script: pro Maschine manuell ausgeführt (Go live installieren, master live kompilieren, systemd einrichten). Sicherheitstechnisch bedenklich: ungepinntes master, Compile auf Kunden-Server.
• Fakt (geprüft im Code): Die 400 ist eine Paywall, kein Linux-Technik-Erfordernis. AgentUpdate (agent_unix.go) prüft keine Signatur — auf Linux ist Code-Signing irrelevant.

success: Lösung Eigenen Fork + Build-CI betreiben → vorgebaute, SHA256-verifizierte Linux-Binaries + sauberes curl | bash-Install-Script. Kein TRMM-Token, keine Paywall, kein manueller Umweg.

2. Ausgangslage (faktisch)

• Offizieller Agent kann Linux: agent_unix.go + install_unix.go, baut sauber (CGO_ENABLED=0 GOOS=linux ... go build -ldflags "-s -w").
• TRMM vertreibt Linux-Binary offiziell nicht → daher der netvolt-Umweg.
• netvolt/LinuxRMM-Script macht 3 Dinge:
  1. Go auf dem Zielhost installieren (go_install)
  2. Agent aus amidaware/rmmagent master live kompilieren (agent_compile)
  3. systemd-Unit + Mesh-Installer drüberlegen

bug: Sicherheitsproblem des Umwegs Lädt Go vom Web, clont master (ungepinnt!) und kompiliert zur Laufzeit auf dem Kunden-Server. Exakt die „fremdes Binary/Source vertrauen"-Falle aus dem 2021/22 Miner-Vorfall — nur als Live-Source statt als Binary.

3. Zielbild

Eigener Fork mit vorgebauten, verifizierten Linux-Binaries + sauberem Installer.

• Kein Go auf dem Client, kein Live-Compile
• Source-Commit + Binary per SHA256 verifiziert
• Update-Pfad zeigt auf das eigene Repo

4. Komponenten

4.1 Fork-Strategie

• Repo: internes Git (git.corestream.ch, OneDev) statt öffentliches GitHub-Repo
• Fork/Mirror von amidaware/rmmagent als internes Projekt, z.B. corestream/rmmagent
• Branches: main (= CORESTREAM) + upstream als Remote/Mirror
• Upstream-Commits nur geprüft mergen (Review-Diff + go mod verify); Sicherheitsfixes priorisieren

4.2 Build-CI (erzeugt die Binaries)

• Laufzeit: interne Build-VM / internes CI statt GitHub Actions
• Matrix: linux/amd64, linux/arm64, linux/386
• Build: CGO_ENABLED=0 GOOS=linux GOARCH=<arch> go build -ldflags "-s -w" -o rmmagent-linux-<arch>
• Artefakte: rmmagent-linux-{arch}, SHA256SUMS, optional zusätzlich mit internem Schlüssel signiert
• Storage: internes Git/Release- oder Artefakt-Repo (gepinnte Tags, z.B. v2.8.0-cs1), nicht öffentlich

4.3 Install-Script (Ersatz für netvolt)

• Öffentlicher Installer: https://git.corestream.ch/corestream/rmmagent/~raw/main/install-linux.sh
• Standard-One-Liner: curl -fsSL https://git.corestream.ch/corestream/rmmagent/~raw/main/install-linux.sh | sudo bash -s -- -c CLIENT -s SITE -t TOKEN
• Wenn -c, -s oder -t fehlen, fragt das Script interaktiv via /dev/tty nach; Token/Auth wird verdeckt gelesen.
• Lädt vorgebautes Binary vom internen Fork-Repo (aktuell v2.11.0-cs4, nicht master).
• SHA256-Verifikation vor Install gegen SHA256SUMS.
• Installiert Mesh standardmässig direkt via MeshCentral Linux-Agent-URLs, weil /api/v3/meshexe/ Linux nicht zuverlässig liefert.
• Liest nach der Mesh-Installation die lokale Mesh Node ID aus und übergibt sie an /api/v3/newagent/.
• Legt systemd-Unit tacticalagent.service an (Restart=always) und startet/aktiviert sie.
• Kein go_install, kein agent_compile auf dem Client.

4.4 Update-Pfad

• Linux AgentUpdate ist im Fork gehärtet: Update-Binary wird nur ersetzt, wenn die SHA256 gegen ein benachbartes SHA256SUMS passt.
• Server-/Update-URLs müssen auf das interne Artefaktlayout zeigen: <BASE_URL>/<VERSION>/rmmagent-linux-<arch> plus <BASE_URL>/<VERSION>/SHA256SUMS.

4.5 Security (aus Miner-Review)

• Reproducible Builds, Checksum-Verifikation im Installer + Agent-Update
• Gepinnter Source-Tag (kein master)
• Build-Pipeline selbst reviewen (realistischere Angriffsfläche als Source)
• go mod verify im CI
• Niemals fremde vorgefertigte Binaries an Kunden ausliefern

5. Linux-Code Gaps

Funktionen in agent_unix.go sind oft Stub/nil — Linux kann weniger als Windows:

note: Fazit Linux-Agent taugt für Monitoring, Scripts, Terminal, Mesh — aber keine Software-Inventur, kein Patch-Mgmt, keine Service-UI. Feature-Gap, kein Bug. Entscheidung: Gaps füllen oder „Monitoring-only" akzeptieren?

6. Code-Signing-Strategie (Linux-fokussiert)

info: Kernpunkt Der 400-Fehler verschwindet komplett, sobald wir die Build-CI selbst betreiben — kein TRMM-Token, keine Paywall, kein manueller netvolt-Umweg mehr.

7. Risiken

caution: Wichtig

• Fork-Pflegeverantwortung dauerhaft (Build-Kette + Security-Tracking)
• CVEs manuell verfolgen (kein upstream-Auto-Patch)
• Lizenz: Tactical RMM License v1.0 ist kein OSI-Open-Source — verbietet kommerziellen Weiterverkauf. Interne MSP-Nutzung OK; Rebrand nur intern, kein gebrandeter SaaS-Verkauf

8. Rollout (Phasen)

1. Dev-VM: Fork + CI + Install-Script testen (Linux-VM bei euch)
2. Pilot: 1–2 eigene CORESTREAM-Hosts
3. Prod: ausgewählte Kunden-Linux-Server

8b. Scaffold-Stand 2026-08-17

success: Erster interner Scaffold gebaut Upstream amidaware/rmmagent wurde auf Tag v2.11.0 / Commit e6b61ba540af2df9d13247f96538397daa3c4f1f gepinnt, statisch geprüft und lokal als CORESTREAM-Scaffold vorbereitet.

Lokaler Arbeitsstand auf Hermes:

• Repo: /home/csgadmin/work/trmm-linux-agent/corestream-rmmagent
• Branch: main
• Commit df2b116: Import upstream v2.11.0
• Commit 252e601: CORESTREAM Build-/Installer-Scaffold
• Commit e54fa3f: Installer-One-Liner-Workflow verbessert (--api-url/--client-id/--site-id/--auth/--base-url, Preflight, Dry-run, klare Fehlerausgaben, One-Liner-Generator)
• Interner Remote vorbereitet: https://git.corestream.ch/corestream/rmmagent.git
• Push noch offen: OneDev verlangt HTTPS-Credentials/Token

Gebaut/verifiziert:

• Dockerized Go go1.24.13 verwendet — kein Go lokal auf Hermes installiert
• go mod verify: erfolgreich
• Linux-Builds: amd64, arm64, 386 erfolgreich
• Self-Update-Härtung: AgentUpdate lädt künftig ein benachbartes SHA256SUMS und ersetzt die Binary nur bei passender SHA256
• Unit-Tests für positive und negative Checksum-Verifikation: erfolgreich
• Installer-Wrapper: scripts/install-linux-corestream.sh — jetzt one-liner-fähig mit CLI-Flags, Preflight, klaren [OK]/[FEHLER]-Ausgaben und --dry-run für Download/SHA256-Test ohne Installation
• One-Liner-Generator: scripts/render-linux-oneliner.sh erzeugt einen sauber gequoteten kunden-/site-spezifischen Installationsbefehl
• Build-Script: scripts/build-linux.sh
• Audit-Report: docs/audit-v2.11.0.md

Artefakte lokal:

• /home/csgadmin/work/trmm-linux-agent/corestream-rmmagent/dist/v2.11.0-cs2/
• /home/csgadmin/work/trmm-linux-agent/packages/corestream-rmmagent-scaffold-v2.11.0-cs3.tar.gz
• /home/csgadmin/work/trmm-linux-agent/packages/corestream-rmmagent-scaffold-v2.11.0-cs2.tar.gz
• /home/csgadmin/work/trmm-linux-agent/packages/corestream-rmmagent-linux-artifacts-v2.11.0-cs2.tar.gz

Checksums der Linux-Binaries:

• rmmagent-linux-amd64: 4215c699fb5526a1b3567cf91cff6011c300a2634a87d8755e301eedbf471925
• rmmagent-linux-arm64: 752bb9b9247c9e1e4e1e479c752a53f9ef9d759f6474f7853a9b33bbca055899
• rmmagent-linux-386: 9ad05849fe0fdd470a46c4b52611113f81f46a613f61955236965ac1ff5176e0

Package-Checksums:

• corestream-rmmagent-scaffold-v2.11.0-cs3.tar.gz: 9b25c2e476f8c80b06a4bb11212e1796bc294fcaa5ed944e05fa80510d2bb3ef
• corestream-rmmagent-scaffold-v2.11.0-cs2.tar.gz: 372fda6e73d5c50b2938ca073550b35a42568977aeec531fc2cd013d5ab8f5ec
• corestream-rmmagent-linux-artifacts-v2.11.0-cs2.tar.gz: 2991b7560ec2492b17ba1ad8d353ea05af3070a2373b16e3fdafa4aafba8fcb1

success: Self-Update-Härtung erledigt Der Installer und der Linux-Self-Update-Pfad verifizieren jetzt SHA256. Voraussetzung: Update-URLs zeigen auf internes Artefaktlayout <BASE_URL>/<VERSION>/rmmagent-linux-<arch> und daneben liegt SHA256SUMS.

8c. Produktiver Installer-Stand 2026-09-09

success: Pilot bestätigt Der kurze Linux-Installer wurde mit v2.11.0-cs4 auf einer Testmaschine erfolgreich ausgeführt. Agent registriert sich im RMM, Mesh wird installiert und tacticalagent.service läuft.

Aktueller Prozess für Techniker:

1. In Tactical RMM Client/Site und Enrollment-/Deployment-Token bestimmen.

2. Auf Linux-Zielhost folgenden Befehl ausführen:

   curl -fsSL https://git.corestream.ch/corestream/rmmagent/~raw/main/install-linux.sh | sudo bash -s -- -c CLIENT -s SITE -t TOKEN

3. Wenn Werte nicht direkt im Befehl stehen, fragt der Installer interaktiv nach:

   • Client-ID
   • Site-ID
   • Enrollment-Token/Auth verdeckt

4. Nach Installation prüfen:

   • RMM: Host erscheint unter der gewählten Client/Site.
   • Systemd: tacticalagent.service läuft.
   • Mesh: Remote-Control-Verknüpfung ist vorhanden.

Aktueller Artefaktstand v2.11.0-cs4 im OneDev-Raw-Pfad:

• rmmagent-linux-386: 52e81126768a95f64cfc52fcf4c4641c7d6a95b09db09e1d83804c14378d1843
• rmmagent-linux-amd64: 480aa5d95b33a6cc6bf025c5b850cb1ae989a2e7cfea42c97d114c2559420900
• rmmagent-linux-arm64: eaa2d66389a83a7cd7193599310b96d5722deafd664beff3e553e720f227702f

Relevante Commits:

• 28ee3a2 — Installer legt tacticalagent.service selbst an.
• ca80646 — Linux Mesh Node ID wird während Installation synchronisiert.
• f11af1a — Linux Mesh-Agent wird direkt von MeshCentral geladen.

Offen für nächsten Ausbau:

• Saubere Deployment-URL im RMM-Backend, z.B. https://api.corestream.ch/clients/<uid>/deploy/linux.sh oder Proxy-Alias https://rmm.corestream.ch/i/<uid>, damit Techniker keinen Token mehr manuell kopieren müssen.

9. Offene Entscheidungen

• CI: interne Build-VM / internes CI statt GitHub Actions
• Artefakt-Storage: internes Git/Release- oder Artefakt-Repo
• Rebrand-Umfang (Name/Logo) — Lizenzgrenze beachten
• Linux-Gaps füllen oder als „Monitoring-only" akzeptieren?
• Update-Pfad: voll eigen oder upstream-Releases spiegeln?
• macOS: vorerst NEIN (2026-07-28) — kein Apple-Dev-Account nötig

Verwandt

• Knowledge Base/2026/Linux/ — weitere Linux-Themen
• CORESTREAM/Konzepte/ — CORESTREAM-Architektur

Quelle: Obsidian Knowledge Base/TacticalRMM/TRMM-Linux-Agent-Konzept.md · Stand: 2026-09-20 · Automatisiert publiziert durch Hermes.