Zum Inhalt

Agent-Versionierung

Agents und Collectors aktualisieren sich automatisch. Die passenden Binaries kommen mit jedem Vesana-Update auf den Server; Agents und Collectors holen sie beim nächsten Abruf ihrer Konfiguration.

Mechanismus

sequenceDiagram
    participant A as Agent / Collector
    participant S as Vesana-Server

    loop beim Config-Abruf (Agent alle 5 Min, Collector jede Minute)
        A->>S: Konfiguration abrufen
        S-->>A: Konfiguration + aktuelle Version + Download-Adresse
        alt Server-Version neuer als eigene
            A->>S: Binary laden
            A->>S: Signatur (<binary>.sig) laden
            A->>A: Signatur prüfen (sonst kein Update)
            A->>A: Binary ersetzen
            A->>A: Neustart (systemd / Windows-Dienst)
        end
    end
  • Version: Agent und Collector tragen dieselbe Versionsnummer wie der Vesana-Server (v1.<linie>.<patch>). Nach einem Server-Update ziehen die Agents innerhalb von etwa 5 Minuten nach, Collectors innerhalb einer Minute.
  • Nur vorwärts: Ist die Version des Servers nicht neuer als die eigene, passiert nichts. Ein Agent macht von sich aus nie ein Downgrade.
  • Download-Adresse: die Server-Adresse, die der Agent selbst verwendet (auch am Agent-Gateway oder bei abweichendem HTTPS-Port), sonst die eingetragene Agent-Server-Adresse. Ein gepinntes Zertifikat gilt auch für den Update-Download.
  • Prüfungen vor dem Ersetzen: Die Datei muss eine echte Programmdatei sein (eine HTML-Fehlerseite wird nie installiert) und höchstens 256 MiB groß.
  • Linux-Agent: Die Binary wird ersetzt, der Agent beendet sich, systemd startet ihn neu (Restart=always).
  • Windows-Agent: Die laufende Binary wird in vesana-agent.exe.old umbenannt, die neue an ihre Stelle gelegt; eine kurzlebige geplante Aufgabe startet den Dienst neu.
  • Collector und Aktiver Collector: Der Dienst legt das geprüfte Update nur bereit. Ein root-Helfer (eine systemd-Pfad-Unit, beim Collector vesana-collector-update.path) prüft die Signatur erneut, ersetzt die root-eigene Datei unter /opt/vesana-collector bzw. /opt/vesana-active-collector und startet den Dienst neu. Ein abgelehntes Update ersetzt nichts, der Grund steht im Journal. Details: Collector.

Signierte Updates

Jede Agent- und Collector-Binary, die Vesana ausliefert, trägt eine Signatur des Herstellers (Datei <binary>.sig daneben). Agent und Collector prüfen sie vor jedem Selbst-Update gegen Schlüssel, die fest in ihnen eingebaut sind:

  • Fehlt die Signatur oder passt sie nicht, gibt es kein Update. Der Agent läuft auf seiner Version weiter, die Überwachung ist nicht betroffen. Im Agent-Log steht der Grund; der nächste Versuch für dieselbe Version kommt nach einer Stunde.
  • Signiert wird beim Hersteller, nie auf deiner Instanz. Der Vesana-Server liefert Binary und Signatur nur aus. Selbst ein übernommener Vesana-Server kann einem Agent deshalb keine fremde Binary unterschieben — das schützt auch Agent Lock gegen einen Austausch der Binary.
  • Kein Zurück auf ältere Versionen: Die Signatur deckt Produkt, Version, Betriebssystem, Architektur, Prüfsumme und Größe ab. Eine ältere, echt signierte Version nimmt ein Agent nicht an.
  • Die Prüfung lässt sich nicht abschalten — auch nicht vom Server aus.

Die Erstinstallation prüft keine Signatur; sie ist über TLS bzw. den Zertifikats-Pin geschützt. Selbst gebaute Binaries tragen keine Hersteller-Signatur; ein Agent nimmt sie deshalb nicht als Update an, sie lassen sich nur über den Installer einspielen.

Welche Version läuft

In Vesana:

  • am Agent-Chip auf der Host-Seite und unter Host verwalten → Verbindung („Online · v1.…"),
  • für die ganze Flotte unter Admin → Agents & Collectors → Agent Lock (Spalte „Version").

Auf der Maschine:

vesana-agent --version                                              # Linux
& "$env:ProgramFiles\Vesana Agent\vesana-agent.exe" version          # Windows (PowerShell)

Was es nicht gibt

  • Kein Pausieren je Host und kein „Update jetzt anfordern". Jeder Agent folgt der Version seines Servers. Ein Neustart des Dienstes löst kein Update aus; geprüft wird beim nächsten regulären Config-Abruf.
  • Kein automatischer Rollback. Geht der Vesana-Server auf eine ältere Version zurück, bleiben die Agents auf ihrer neueren Version (kein Downgrade). Eine ältere Agent-Version bekommt eine Maschine nur über eine Neuinstallation.
  • Keine Update-Steuerung in der Agent-Config. Wer auf einer Instanz früher die Verteilung „Nur offline" eingestellt hatte, behält das: Agents dieser Instanz bekommen keine Update-Adresse und aktualisieren sich nicht. In der Oberfläche lässt sich das nicht mehr einstellen.

Windows-Setup-Assistent

vesana-agent-setup.exe ist nicht die nackte Binary, sondern ein Setup-Assistent. Der Download aus Vesana (Dialog „Agent einrichten") trägt die Server-Adresse schon vorausgefüllt und, wenn nötig, den Zertifikats-Fingerabdruck. Der Assistent:

  1. fragt Server-URL und Token ab (still: /S /TOKEN=… /SERVER=…),
  2. installiert das Programm nach C:\Program Files\Vesana Agent\,
  3. sperrt C:\ProgramData\Vesana\Agent auf SYSTEM und Administratoren und legt dort die config.yaml neu an,
  4. registriert den Windows-Dienst VesanaAgent und startet ihn.

Der Assistent ist nur für die Erstinstallation; danach aktualisiert sich der Agent selbst.

Anschluss