Agent installieren

systemd, Container, LXC, OpenWrt – alle Wege, alle Architekturen.

Der NODE64-Agent ist ein einzelnes, statisch gelinktes Programm ohne Abhängigkeiten. Keine Runtime, keine Bibliotheken, keine Pakete – eine Datei von rund sechs Megabyte.

Aktuell veröffentlicht ist Fassung 1.16.0. Welche bei dir läuft, sagt node64-agent --version.

Architekturen #

Architektur	Typische Geräte
`amd64`	Server, Mini-PCs, VMs
`arm64`	Raspberry Pi 3/4/5, ARM-Server, Apple-Silicon-VMs
`armv7`	Raspberry Pi 2, ältere SBCs
`armv6`	Raspberry Pi 1 und Zero
`386`	ältere x86-Systeme
`riscv64`	RISC-V-Boards
`mips64le`	Router mit MIPS-Prozessor

Das Installationsskript erkennt die Architektur selbst.

Weg 1: Linux mit systemd #

curl -sSL https://get.node64.de/install.sh | NODE64_TOKEN=dein-token sh

Das Skript prüft die SHA-256-Summe des Binaries, legt /usr/local/bin/node64-agent an, schreibt /etc/node64/agent.conf, richtet node64-agent.service ein und startet ihn. Schlägt die Prüfsummen-Kontrolle fehl, bricht es ab – lieber kein Agent als ein untergeschobener.

Ohne Token installiert das Skript nur; anbinden kannst du später:

node64-agent enroll --token=dein-token

Weg 2: Container #

docker run -d --name node64-agent \
  --network host \
  -e NODE64_TOKEN=dein-token \
  -e NODE64_HOST_ROOT=/host \
  -v /:/host:ro \
  -v node64-state:/var/lib/node64 \
  node64/agent:latest

Zwei Dinge sind wichtig:

NODE64_HOST_ROOT=/host zusammen mit -v /:/host:ro. Ohne das sieht der Agent nur den Container – keine Pakete des Hosts, keine Dienste, keine Konfiguration, und auch nicht dessen Logs. Mit dem eingehängten Dateisystem meldet er den Host; für die Log-Signale liest er dann das Journal unter /host/var/log/journal.
Ein dauerhaftes Volume für /var/lib/node64. Dort liegt die Identität des Geräts. Ohne Volume ist der Agent nach jedem Neustart ein neues Gerät.

Das Image ist ein FROM scratch-Image: kein Betriebssystem, keine Shell, nichts ausser dem Binary.

Weg 3: LXC-Container (Proxmox) #

Ein LXC ist für den Agenten ein normales Linux. Die Installation läuft wie bei Weg 1 – im Container, nicht auf dem Host. Willst du den Proxmox-Host selbst überwachen, installiere den Agenten dort ebenfalls; die Proxmox-Prüfungen greifen nur auf dem Host.

Weg 4: OpenWrt und andere ohne systemd #

curl -sSL https://get.node64.de/install.sh | NODE64_TOKEN=dein-token sh

Erkennt das Skript kein systemd, legt es ein Init-Skript an (/etc/init.d/node64-agent). Auf sehr kleinen Geräten kann der Speicherplatz knapp werden – das Binary lässt sich auch auf einen USB-Stick legen und von dort starten.

Konfiguration #

Der Agent liest in dieser Reihenfolge: Kommandozeile → Umgebungsvariable → Konfigurationsdatei → Vorgabe.

# /etc/node64/agent.conf
NODE64_SERVER=https://app.node64.de
NODE64_INTERVAL=15m
NODE64_SONAR=false

Variable	Bedeutung
`NODE64_SERVER`	Basis-URL der Plattform
`NODE64_TOKEN`	Einmal-Token, nur beim Anbinden
`NODE64_INTERVAL`	Melde-Rhythmus (`15m` oder `900`). Der Server darf ihn nach unten ziehen, dein Tarif entscheidet
`NODE64_SONAR`	Teilnahme am Messnetz, lokal abschaltbar
`NODE64_STATE_DIR`	wo Identität und Warteschlange liegen (Vorgabe `/var/lib/node64`)
`NODE64_HOST_ROOT`	Wurzel des zu prüfenden Dateisystems (für Container)
`NODE64_PROZESSWACHE`	Prozesswache (`true`/`false`, Vorgabe seit Agent 1.16: `true`). Hört am Kernel mit und sieht dadurch auch Prozesse, die nur Millisekunden leben — eine Shell, die der Webserver startet, ist bei der nächsten Abfrage längst weg. Sie liest ausschliesslich; Aufrufzeilen verlassen den Server nicht. Der übliche Weg ist der Schalter im Dashboard beim Gerät. Steht hier ein Wert, gewinnt er — in beide Richtungen. Steht nichts, gilt der zuletzt vom Server gehörte Stand und erst dann die Vorgabe. Braucht Systemrechte, nur Linux; ohne `CAP_NET_ADMIN` oder auf einem Kern ohne `CONFIG_PROC_EVENTS` bleibt sie aus und sagt das.
`NODE64_DEBUG`	ausführliche Ausgabe

Empfohlene Zusatzpakete #

Der Agent kommt ohne Fremdbibliotheken aus und braucht für den Grundbetrieb nichts weiter. Für zwei Bereiche greift er aber auf Systemwerkzeuge zurück, die nicht überall vorhanden sind:

Paket	Wofür	Ohne das Paket
`smartmontools`	Datenträger-Gesundheit – umgelagerte und schwebende Sektoren, Flash-Verschleiss, Selbsttests. Ein Laufwerk kündigt seinen Ausfall in aller Regel an; ohne dieses Paket sieht NODE64 die Ankündigung nicht.	Die Laufwerke sind bekannt, ihre Gesundheit nicht. Der Agent meldet den Bereich ausdrücklich als eingeschränkt.
`e2fsprogs`	ext2/3/4-Superblock: Fehlerzähler und Dateisystem-Zustand	Die Einhänge-Optionen kommen trotzdem an, der Fehlerzähler nicht. Auf fast allen Systemen ist das Paket ohnehin installiert.

apt install smartmontools     # Debian, Ubuntu, Proxmox
dnf install smartmontools     # Fedora, RHEL, Rocky
apk add smartmontools         # Alpine

Wenn du schon dabei bist: systemctl enable --now smartd lässt den Datenträger im laufenden Betrieb überwachen und nicht nur bei jedem NODE64-Lauf. Zwischen zwei Läufen liegen Stunden, und ein Laufwerk kann in dieser Zeit von „in Ordnung" auf „ausgefallen" wechseln.

Im Container braucht der Agent zusätzlich Zugriff auf die Geräte des Wirts, um SMART zu lesen. Ohne den Zugriff meldet er den Bereich als eingeschränkt – das ist gewollt und kein Fehler.

Befehle #

Befehl	Was er tut
`node64-agent enroll`	Gerät anbinden (einmalig, mit Token)
`node64-agent run`	Dauerbetrieb – das macht der Dienst
`node64-agent once`	einmal erheben und hochladen
`node64-agent show`	zeigt genau das, was hochgeladen würde
`node64-agent status`	Identität, Server, letzter Lauf, Warteschlange
`node64-agent logs --liste`	die gezählten Log-Muster
`node64-agent logs --muster NAME`	die echten Logzeilen dazu – lokal, nichts wird gesendet
`node64-agent update --check`	nachsehen, ob eine neuere Version vorliegt
`node64-agent update`	aktualisieren (signiert und geprüft)
`node64-agent stop`	zeigt, wie man ihn anhält
`node64-agent uninstall`	zeigt, wie man ihn sauber entfernt
`node64-agent version`	Version und Architektur

Aktualisieren #

curl -sSL https://get.node64.de/install.sh | sh

Ohne Token installiert das Skript nur die neue Version; die Identität in /var/lib/node64/state.json bleibt. Der Agent aktualisiert sich nicht von selbst – ein Programm, das sich unbeaufsichtigt neue Binaries zieht, ist auf einem überwachten System das falsche Signal.

Anhalten, ohne zu entfernen #

Manchmal soll der Agent nur eine Weile schweigen – für eine Wartung, einen Umzug, einen Test.

systemctl stop node64-agent        # anhalten
systemctl start node64-agent       # weiterlaufen lassen
systemctl disable node64-agent     # auch nach einem Neustart aus

Auf OpenWrt und anderen Systemen ohne systemd:

/etc/init.d/node64-agent stop
/etc/init.d/node64-agent start
/etc/init.d/node64-agent disable

Was dabei passiert: Das Gerät bleibt im Dashboard stehen und wird nach einiger Zeit als überfällig und dann als offline geführt. Das ist Absicht – ein angehaltener Agent soll nicht aussehen wie ein gesundes System.

Willst du die Sicherheitsprüfung pausieren, ohne dass das Gerät als ausgefallen gilt, geht das im Dashboard unter Gerät › Einstellungen › Sicherheitsprüfung. Dann erhebt der Agent gar nichts mehr – er meldet sich aber weiter, und das Gerät bleibt sichtbar.

Welche Befehle auf deinem System gelten, sagt dir der Agent selbst:

node64-agent stop

Vollständig entfernen #

In einem Schritt – dasselbe Skript, das installiert hat, räumt auch wieder auf:

curl -sSL https://get.node64.de/install.sh | sh -s -- --uninstall

Oder von Hand. Der Agent zeigt die Befehle für genau deine Maschine an, mit den tatsächlichen Pfaden und dem tatsächlich vorhandenen Init-System:

node64-agent uninstall

Ausgeschrieben für Linux mit systemd:

systemctl stop node64-agent
systemctl disable node64-agent
rm -f /etc/systemd/system/node64-agent.service
systemctl daemon-reload
rm -f /usr/local/bin/node64-agent
rm -rf /etc/node64 /var/lib/node64

Die Zeile mit der Unit-Datei wird gern vergessen. systemctl disable meldet den Dienst nur ab; die Datei bleibt liegen und taucht später in jedem systemctl list-unit-files wieder auf. Ohne daemon-reload merkt systemd zudem nicht, dass sie weg ist.

Für OpenWrt:

/etc/init.d/node64-agent stop
/etc/init.d/node64-agent disable
rm -f /etc/init.d/node64-agent
rm -f /usr/local/bin/node64-agent
rm -rf /etc/node64 /var/lib/node64

Gegenprobe #

command -v node64-agent          # gibt nichts aus
ls /etc/node64 /var/lib/node64   # nicht vorhanden
systemctl list-unit-files | grep node64   # keine Zeile

Was bewusst stehen bleibt #

Das Gerät im Dashboard. Es verschwindet nicht von selbst – sonst wäre ein abgestürzter Server nicht von einem entfernten zu unterscheiden, und genau diesen Unterschied willst du sehen.

Löschen unter Geräte › das Gerät › Löschen. Damit gehen auch seine Befunde, Messwerte und Verläufe; der Geräteschlüssel wird ungültig. Ein später neu installierter Agent braucht dann ein neues Token.

Die Protokolle des Dienstes (journalctl -u node64-agent) gehören dem System, nicht uns. Sie werden regulär rotiert – wir fassen sie nicht an.

Der Agent entfernt sich nicht selbst. Er ändert grundsätzlich nichts am System, und dafür gibt es keine Ausnahme – auch nicht für sich. Deshalb zeigt er die Befehle, statt sie auszuführen. Wer es in einem Schritt will, nimmt das Installationsskript: Das darf löschen, denn es hat auch angelegt.

Der Agent braucht keinen offenen Port. Er baut die Verbindung auf, nicht der Server. Das gilt auch für das Messnetz: Aufträge werden abgeholt, nie zugestellt.

Wenn etwas nicht klappt #

Siehe Fehlerbehebung.