Zum Inhalt

Agent-Versionierung

Agents und Collectors aktualisieren sich automatisch — der Server stellt neue Binaries bereit, die Clients holen sie beim nächsten Config-Refresh.

Mechanismus

sequenceDiagram
    participant A as Agent
    participant API as Server
    participant FS as /opt/vesana/agent-binaries/

    loop alle 5 Min (Agent) / 60 s (Collector)
        A->>API: GET /api/v1/agent/config
        API->>FS: aktuelle VERSION-Datei lesen
        API-->>A: {config, latest_version, binary_url}
        alt latest_version > eigene Version
            A->>FS: GET binary_url
            FS-->>A: neue Binary
            A->>A: SHA256 prüfen
            A->>A: alte Binary umbenennen, neue installieren
            A->>A: Service neu starten (systemd / Windows-Service)
        end
    end

Auf dem Server liegen die Binaries unter /opt/vesana/agent-binaries/:

agent-binaries/
├── VERSION                                    (z. B. "v1.4.2")
├── vesana-agent-linux-amd64
├── vesana-agent-windows-amd64.exe
├── vesana-agent-setup.exe                   (NSIS-Wizard für Windows)
└── install.sh                                 (One-Command-Installer)

Analog für Collectors unter /opt/vesana/collector-binaries/.

Versionsformat

Semver mit v-Prefix: v1.0.0, v1.4.2. Auto-Update-Mechanismus akzeptiert nur Vorwärts-Updates — ein Agent macht von sich aus kein Downgrade.

Welche Version läuft

In der UI: Admin → Hosts → Host-Detail → Agent-Box zeigt aktuelle Agent-Version + Server-Version + Status (up-to-date / pending update / outdated).

Auf der Maschine:

vesana-agent --version

Update pausieren

Wenn ein bestimmter Host nicht automatisch updaten soll (z. B. um eine spezifische Version zu pinnen):

Host-Detail → Agent → Auto-Update pausieren

Setzt ein Flag, das beim Config-Endpoint die latest_version für diesen Host nicht mehr anhängt — der Agent prüft dann nicht mehr.

Pausen-Status sichtbar in der Host-Liste als kleines Pausen-Icon neben der Versionsnummer.

Forciertes Update

# Auf der Maschine, falls Update klemmt:
sudo systemctl restart vesana-agent  # Linux
net stop VesanaAgent && net start VesanaAgent  # Windows

Force-Update vom Server triggern:

Host-Detail → Agent → Update jetzt anfordern

Setzt einen Marker in der DB. Beim nächsten Heartbeat des Agents wird das Update zwangsausgelöst.

Neue Version releasen (intern)

Operations-Detail

Dieser Abschnitt richtet sich an Personen, die Vesana entwickeln. Self-Hoster bekommen Updates über die GUI.

# 1. Tag setzen
git tag v1.5.0
git push origin v1.5.0

# 2. Agent + Collector bauen
cd agent && make build-all VERSION=v1.5.0
cd collector && make build VERSION=v1.5.0

# 3. Windows-Installer (NSIS) bauen
cd agent/deploy && makensis installer.nsi

# 4. Auf Server hochladen
SSH=...
scp agent/bin/vesana-agent          ${SSH}:/opt/vesana/agent-binaries/vesana-agent-linux-amd64
scp agent/bin/vesana-agent.exe      ${SSH}:/opt/vesana/agent-binaries/vesana-agent-windows-amd64.exe
scp agent/bin/vesana-agent-setup.exe ${SSH}:/opt/vesana/agent-binaries/vesana-agent-setup.exe

# 5. VERSION-Datei aktualisieren (triggert Auto-Update)
ssh ${SSH} 'echo "v1.5.0" > /opt/vesana/agent-binaries/VERSION'

# 6. Server-internen Agent neu starten
ssh ${SSH} 'systemctl stop vesana-agent && \
            cp /opt/vesana/agent-binaries/vesana-agent-linux-amd64 /usr/local/bin/vesana-agent && \
            systemctl start vesana-agent'

VERSION wird per make als Build-Argument an Go übergeben (-ldflags="-X main.Version=v1.5.0"). Ohne explizites VERSION= würde -dirty an den Versions-String gehängt, weil das Repo untracked Files enthält.

VERSION-Datei nicht ändern bevor Binary getestet ist

Eine falsche Binary plus falscher VERSION-Wert triggert das Auto-Update auf allen Agents/Collectors gleichzeitig. Wenn die Binary kaputt ist: alle Kunden-Agents im Eimer. Vor echo VERSION immer auf einer Test-Instanz verifizieren.

NSIS-Wizard für Windows

vesana-agent-setup.exe ist nicht die nackte Binary, sondern ein NSIS-Wizard mit Eingabefeldern für Server-URL und Token. Die Logik ist in agent/deploy/installer.nsi. Der Wizard:

  1. Fragt Server-URL und Token ab
  2. Installiert Binary nach C:\Program Files\Vesana\Agent\
  3. Schreibt Config nach C:\ProgramData\Vesana\Agent\config.yaml
  4. Registriert Windows-Service VesanaAgent
  5. Startet Service

Bei NSIS-Wizard-Builds: nach make build-all immer makensis installer.nsi ausführen, sonst ist die setup.exe nicht aktuell.

Auto-Update bei Custom-Builds

Wenn du den Agent mit Custom-Anpassungen baust und nicht autoupdaten willst:

  1. VESANA_AUTO_UPDATE=false in /etc/vesana-agent/config.yaml (bzw. Windows Registry)
  2. Service neu starten

Der Agent fragt dann nicht mehr nach Versions-Vergleich.

Rollback eines Agents

Es gibt keinen automatischen Agent-Rollback. Wenn eine neue Agent-Version Probleme macht:

  1. Server-VERSION-Datei zurücksetzen auf alte Version
  2. Auf den betroffenen Maschinen: alte Binary aus /usr/local/bin/.vesana-agent.bak (Backup vom Auto-Update) wiederherstellen
  3. Service neu starten

Bei flächendeckenden Problemen: VERSION-File zurücksetzen, Auto-Update der Agents pausieren, in Ruhe debuggen.

Anschluss