Skip to main content

TRMM-Linux-Agent-Konzept

TRMM-Linux-Agent-Konzept

Kurzfassung

Tactical RMM (TRMM) dokumentiert inzwischen einen Linux-Agenten im Beta-Status. Code-signierte Agenten, einschliesslich Linux und macOS, stehen gemäss Hersteller ab Sponsor Tier 1 zur Verfügung. Dieser offizielle Weg ist für neue Installationen zu bevorzugen.

Ein organisationsintern gebauter Fork bleibt technisch möglich, verursacht aber dauerhafte Pflege-, Lieferketten- und Lizenzrisiken. Er ist keine gleichwertige Standardlösung.

abstract:Getestet: KurzfassungEin Linux-Hostsintern ingebauter TRMMAgent laufenauf beiBasis CORESTREAMvon 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 mitAgent v2.11.0-cs40 wurde auf Linux erfolgreich getestet; Mesh +registriert; tacticalagent.service funktionieren.und die Mesh-Verknüpfung funktionierten. Dieser Befund gilt nur für den damaligen Fork und dessen Build-Pipeline.

Generisch/aktuell: Die offiziellen Installationsschritte unten stammen aus der laufenden TRMM-Dokumentation. Funktionen und Dienstnamen sind nach jedem Agent-Update erneut zu prüfen, da der Linux-Agent als Beta bezeichnet wird.

Entscheid

    Standard: Offiziellen Linux-Installer aus der eigenen TRMM-Instanz verwenden. Ausnahme: Eigenbau nur, wenn der offizielle Bezug nachweislich nicht möglich ist und Security, Lizenz sowie Wartungsverantwortung geklärt sind. Nicht verwenden: Ungepinnte Fremdskripte, Builds direkt aus master oder Live-Kompilation auf verwalteten Zielsystemen.

    1.Offizielle ProblemstellungInstallation

      In TRMM Agents → Install Agent öffnen. Client, Site, Gerätetyp, Architektur, Ablaufzeit und Linux wählen. Generiertes Shellskript herunterladen und sicher auf den Zielhost übertragen. Ausführen: 
      chmod 700 ./rmm-<client>-<site>-<type>.sh
sudo ./rmm-<client>-<site>-<type>.sh
        Nach erfolgreichem Rollout löschen, denn das Skript enthält ein zeitlich gültiges Enrollment-Token: 
        rm -f ./rmm-<client>-<site>-<type>.sh

        warning: Show-Stopper im MSP-AlltagEin Linux-HostsDeployment-Link lassenwird sichlaut inTRMM-Dokumentation TRMMderzeit nicht angeboten. Das generierte Skript deshalb nur über einen umständlichen,geschützten, nichtkurzlebigen automatisierbarenAblageort Workaroundverteilen; aufnehmen.niemals Proin Maschineein vonöffentliches HandRepository —oder nichteine skalierbar.öffentliche Knowledge Base hochladen.

        Verifikation

        sudo systemctl status tacticalagent.service --no-pager
sudo journalctl -u tacticalagent.service -n 100 --no-pager

        Zusätzlich in TRMM prüfen:

        • UrsacheHost =erscheint TRMMbeim Paywall:erwarteten SignierteClient Agentenund (inkl.Standort.
        Linux)Letzter liefertCheck-in TRMMist aktuell. Checks und Skripte laufen mit erwarteten Rechten. Mesh/Remote-Zugriff ist vorhanden, sofern mitinstalliert. Neustart stellt Agent und Mesh wieder her.

        Funktionsumfang realistisch einordnen

        Der Feldtest des internen Forks v2.11.0 bestätigte Monitoring, Skriptausführung, Terminal und Mesh. In diesem Stand waren unter anderem Softwareinventar, grafisches Patch-Management, Service-Steuerung und Windows-spezifische Funktionen nicht oder nur aneingeschränkt zahlendevorhanden.

        Sponsoren

        Dies ist keine aktuelle, vollständige Produktmatrix. Vor dem Rollout muss die tatsächlich eingesetzte Agent-Version mit einem Testhost gegen die benötigten Funktionen geprüft werden.

        Kontrollierter Eigenbau (TierAusnahme)

        1, monatlich) über einen eigenen Code-Signing-Server. Agent-Generate ohne Token → HTTP 400 → kein offizieller Linux-Agent.
        1. WorkaroundUpstream-Tag =und netvolt-Script:Commit propinnen; Maschinenie manuelldirekt ausgeführt (Go live installieren,aus master live kompilieren, systemd einrichten). Sicherheitstechnisch bedenklich: ungepinntes master, Compile auf Kunden-Server.veröffentlichen.
        2. FaktÄnderungen (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!)reviewen 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 ForkAbhängigkeiten 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 priorisierenprüfen. In

                4.2isolierter Build-CI (erzeugtfür die Binaries)

                benötigten
                  Architekturen Laufzeit: interne Build-VM / internes CI statt GitHub Actionsbauen: Matrix: linux/amd64, linux/arm64, linux/386 Build: 
                  CGO_ENABLED=0 GOOS=linux GOARCH=<arch>amd64 go build -ldflagstrimpath -ldflags="-s -w" -o rmmagent-linux-<archamd64
sha256sum rmmagent-linux-amd64 > SHA256SUMS
                  1. 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 ausArtefakte 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.unveränderbar in einem zugriffsgeschützten Release-Repository ablegen. Server-/Update-URLsInstaller und Self-Update müssen aufdie Prüfsumme vor dem Ersetzen der Binärdatei validieren. Enrollment-Werte nur zur Laufzeit übergeben und nicht loggen. Rollback, Update-Überwachung und regelmässige Upstream-Diffs betreiben.

                      Eine SHA-256-Prüfsumme schützt nur dann vor Manipulation, wenn das interneManifest Artefaktlayoutüber zeigen:einen <BASE_URL>/<VERSION>/rmmagent-linux-<arch>getrennt plusvertrauenswürdigen <BASE_URL>/<VERSION>/SHA256SUMS.beziehungsweise signierten

                      4.5Kanal Securitybezogen (auswird. Miner-Review)

                      Sicherheits- und Lizenzgrenzen

                      • 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 oftDie 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 keinkeine Open-Source-Lizenz. OSI-Open-SourceSie —erlaubt verbietetdie Nutzung zur Überwachung eigener und verwalteter Kundensysteme, enthält aber weitgehende Einschränkungen für kommerzielle Bereitstellung, SaaS, Managed Hosting, Installation/Konfiguration als Dienstleistung sowie abgeleitete Werke. Vor Verteilung eines Forks, Rebranding oder einem kommerziellen Weiterverkauf.Angebot Internedie MSP-konkrete Nutzung OK;rechtlich Rebrandund nurgegebenenfalls intern,mit keinAmidaWare gebrandeterklären. SaaS-VerkaufWird ein abgeleitetes Werk Dritten bereitgestellt, sind die Pflichten zur Bereitstellung des vollständigen Quellcodes und zum Copyright-Hinweis zu beachten. Diese Notiz ist keine Rechtsberatung.

                        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 <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:

                                      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/<uid>/deploy/linux.sh oder Proxy-Alias https://rmm.corestream.ch/i/<uid>, damit Techniker keinen Token mehr manuell kopieren müssen.

                                                9. Offene EntscheidungenAbnahme

                                                • CI:Offizieller interneInstaller Build-VModer /freigegebener, internesgepinnter CIEigenbau statt GitHub Actionsverwendet
                                                • Artefakt-Storage:Keine internesTokens Git/Release-in Shell-History, Tickets, Logs oder Artefakt-RepoDokumentation
                                                • Rebrand-UmfangPrüfsumme/Signatur (Name/Logo) — Lizenzgrenze beachtenvalidiert
                                                • Linux-GapsCheck-in, füllenChecks, oderSkripte alsund „Monitoring-only"Remote-Zugriff akzeptieren?getestet
                                                • Update-Pfad:Neustart vollund eigenAgent-Update oder upstream-Releases spiegeln?getestet
                                                • macOS:Funktionslücken vorerstdokumentiert
                                                NEIN (2026-07-28)Lizenz- —und keinWartungsverantwortung Apple-Dev-Account nötiggeklärt

                                                VerwandtQuellen

                                                Tactical RMM License v1.0 Tactical RMM Agent (Upstream)

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

                                                Back to top