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: Go auf dem Zielhost installieren ( go_install) Agent aus amidaware/rmmagent master live kompilieren ( agent_compile) 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= go build -ldflags "-s -w" -o rmmagent-linux- 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: //rmmagent-linux- plus //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: Funktion Linux-Status Bedeutung GetDisks / checkin / RunScript / Terminal / Mesh ✅ implementiert Kern-RMM funktioniert GetInstalledSoftware {} (leer) Keine Software-Inventur SendSoftware {} kein Reporting GetServiceDetail / ControlService / EditService Windows-only Service-Steuerung nur via Script PatchMgmnt nil kein Patch-Management CreateSchedTask / ListSchedTasks nil kein GUI-Task-Scheduling GetWinUpdates / InstallUpdates Windows kein OS-Update-Mgmt GetEventLog Windows kein Eventlog InstallChoco Windows kein Chocolatey 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) Plattform Signing nötig? Maßnahme Linux ❌ nein SHA256-Verifikation statt Signatur (reicht, da wir Build kontrollieren) macOS 🚫 vorerst NEIN (2026-07-28) kein Apple-Dev-Account; bei Bedarf später nachrüsten Windows ❌ vorerst raus läuft weiter via TRMM-Sponsor / unsigniert + AV-Exclusion 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) Dev-VM: Fork + CI + Install-Script testen (Linux-VM bei euch) Pilot: 1–2 eigene CORESTREAM-Hosts 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 //rmmagent-linux- 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: In Tactical RMM Client/Site und Enrollment-/Deployment-Token bestimmen. 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 Wenn Werte nicht direkt im Befehl stehen, fragt der Installer interaktiv nach: Client-ID Site-ID Enrollment-Token/Auth verdeckt 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//deploy/linux.sh oder Proxy-Alias https://rmm.corestream.ch/i/, 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.