Agenten

Ein Agent deckt ein Netzwerk ab: die Stelle, von der aus Ihre Hypervisoren und Panels erreichbar sind. Alles, was Provibr mit Ihrer Infrastruktur tut, läuft über ihn.

• Die Verbindung ist ausgehend. Der Agent öffnet sie zur Plattform und hält sie offen; nichts muss aus dem Internet erreichbar sein, und es muss kein Port zu ihm weitergeleitet werden.
• Die Zugangsdaten bleiben auf Ihrer Seite. Sie gehen einmalig an den Agenten und werden in einem verschlüsselten Tresor auf diesem Host verschlossen; die Plattform speichert nur die Namen der Felder, die Sie ausgefüllt haben.
• Er meldet, was er beobachtet. Maschinen werden in kurzem Takt abgefragt, und alle paar Minuten läuft ein vollständiger Abgleich, und so bemerkt das Panel eine Maschine, die außerhalb von Provibr gestoppt wurde.
• Er fasst nur an, was Sie übergeben haben. Eine Ressource ohne Eintrag in Provibr wird ignoriert, gezählt und wieder vergessen. Der Agent übernimmt nie von sich aus eine Maschine.

Nichts Exotisches, und nichts, das Sie vorher installieren müssten. Der Agent ist ein einzelnes statisch gelinktes Binary: Er bringt seine eigene C-Bibliothek mit, es gibt also keine Laufzeitumgebung, keinen Interpreter und kein Distributionspaket, das passen müsste. Eine kleine virtuelle Maschine reicht völlig. Die Größen, die wir gemessen haben, stehen weiter unten auf dieser Seite.

Es gibt kein Paket zu installieren und keine Distribution, die passen müsste; was folgt, ist deshalb keine Liste unterstützter Systeme. Es ist die Liste der Systeme, auf denen dieser Build tatsächlich gestartet wurde. Alles andere mit einem 64-Bit-x86-Linux-Kernel sollte sich genauso verhalten, und wenn nicht, würden wir das gern erfahren.

Der Agent selbst ist klein und bleibt klein. Was wächst, ist der Bestand, den er beobachtet: Alle zwanzig Sekunden liest er von jedem verbundenen System die vollständige Liste der Maschinen, vergleicht sie mit der Runde davor und leitet nur weiter, was sich geändert hat. Alle fünf Minuten leitet er stattdessen das ganze Bild weiter, das Sicherheitsnetz für alles, was eine verlorene Nachricht sonst gekostet hätte. In derselben Runde fragt er Ihre Nodes, wie viel Kapazität sie haben.

Der Datenverkehr ist die andere Zahl, die man haben will. Diese tausend Maschinen kosten alle zwanzig Sekunden etwa 250 kB in Richtung Ihrer eigenen Systeme, also rund ein Gigabyte pro Tag in Ihrem eigenen Netzwerk, während zehn Maschinen 2,5 kB pro Runde kosten. Von dieser Zahl für tausend Maschinen reisen etwa 17 kB pro Runde zu uns weiter, rund 70 MB pro Tag, weil nur weitergeleitet wird, was sich geändert hat.

Macht die Art des Systems einen Unterschied? Kaum. Ob der Agent mit einem Hypervisor, einem Hosting-Panel oder einem Game-Panel spricht: Die Arbeit ist dieselbe, ein Aufruf pro System und Runde, ein Vergleich, eine Nachricht. Zwei Unterschiede sind echt, aber klein: Ein Hypervisor wird zusätzlich nach den Adressen in seinen Gastsystemen gefragt, höchstens alle fünf Minuten pro laufender Maschine, und ein Panel, das nichts misst, schickt keine Verbrauchszahlen. Was sich enorm unterscheidet, ist die Maschine auf der anderen Seite, und die wird nach dem bemessen, was auf ihr läuft, nicht nach dem Agenten.

Die Größen unten sind deshalb keine gemessenen Mindestwerte; der Agent passt in weit weniger. Es ist das, was wir bestellen würden, denn ein Betriebssystem, seine Logs und Ihre eigenen Werkzeuge wollen mehr Platz als der Agent.

Alles oben ist das, was ein Agent braucht, um Ihre Systeme zu beobachten und zu steuern. Vier seiner Fähigkeiten verdienen darüber hinaus ein eigenes Wort, und jede davon fällt ehrlich zurück: Ist eine Voraussetzung nicht erfüllt, macht der Agent den Rest weiter und sagt Ihnen, welche Fähigkeit er nicht anbietet.

Maschinen über das Netzwerk installieren

Dafür muss der Agent im selben Netzwerksegment stehen wie die Maschine, die installiert wird, denn er beantwortet deren Boot-Anfrage direkt. Seine Unit trägt die zwei Capabilities, die er für die Boot-Ports braucht, bereits; sie sind eng gefasst und werden nur verwendet, solange eine Installation läuft. Was wirklich dazukommt, ist Festplattenplatz: Boot-Medien werden auf dem Host zwischengespeichert, standardmäßig bis zu 20 GB, das Älteste fliegt zuerst raus.

Automatisierungen ausführen

Automatisierungen sind Ihr eigenes TypeScript und laufen deshalb in einer Sandbox aus Kernel-Namespaces; die Laufzeitumgebung dafür gehört nicht zum Agenten: Eine festgelegte Version von Bun muss in dem Verzeichnis des Agenten liegen, das root gehört und in dem der Benutzer, unter dem der Agent läuft, sie nicht ersetzen kann. Ubuntu 24.04 und neuer schränken genau den Namespace ein, den das braucht; der Agent bringt ein AppArmor-Profil mit, das genau diese eine Erlaubnis für genau dieses eine Binary zurückgibt. Fehlt eines von beidem, sagt der Agent das beim Start, bietet die Fähigkeit nicht an und macht weiter. Jeder Lauf bekommt mindestens 4 GB Adressraum. Der ist virtuell und kein Arbeitsspeicher, der vorhanden sein müsste. Was eine laufende Automatisierung auf Ihrem Host wirklich kostet, haben wir nicht gemessen.

Den Host aus dem Panel neu starten

Ein Neustart ist eher eine Frage der Autorisierung als der Privilegien: Der Agent fragt logind, logind fragt polkit, und der Installer hinterlässt eine Regel, die genau zwei Aktionen für genau diesen Benutzer erlaubt. Hosts, die vor dieser Regel installiert wurden, brauchen einen erneuten Lauf des Installers, denn ein Update aus dem Panel ersetzt das Binary und nichts in /etc. Bis dahin lehnt das Panel ab und nennt den Grund.

Konsole und Diagnose

Nichts zu installieren. Ping und Traceroute verwenden einen ICMP-Socket, der keine Privilegien braucht, solange der Host ihn für die Gruppe des Systembenutzers erlaubt, was auf jedem Host, den wir gemessen haben, der Fall war. Wo nicht, misst der Agent stattdessen mit TCP und sagt Ihnen, welche Methode er verwendet hat. Die Konsole wird über die ohnehin schon offene Verbindung durchgereicht.

Auf dem Einstellungen-Tab des Agenten baut das Panel einen einzigen Befehl mit einem Installationslink darin. Führen Sie ihn als root auf dem Host aus. Der Link funktioniert einmal: Er hört auf zu funktionieren, sobald der Agent registriert ist, und spätestens nach 72 Stunden. Sie können jederzeit einen neuen erzeugen.

curl -fsSL https://app.provibr.com/api/install/<token> | sh

Was der Befehl der Reihe nach tut:

• Prüft, dass er als root auf einem 64-Bit-x86-Host läuft, und wählt curl oder wget, je nachdem, was vorhanden ist.
• Lädt das Binary und seine Prüfsumme herunter und prüft sie. Hat der Host überhaupt kein Werkzeug, um eine Prüfsumme zu berechnen, bricht er ab, statt die Prüfung zu überspringen.
• Legt den Systembenutzer und die beiden Verzeichnisse an, installiert das Binary und legt das Update-Skript samt seinem öffentlichen Schlüssel ab; beide gehören root, damit der Benutzer, unter dem der Agent läuft, sie nicht ersetzen kann.
• Fragt den Aktivierungscode im Terminal ab, holt damit die Lizenzdatei, wobei der Code als Request-Header mitreist, und installiert sie.
• Registriert sich als Systembenutzer, installiert dann die systemd-Unit und startet den Dienst.

Prüfen Sie das Ergebnis auf dem Host:

systemctl status provibr-agent
journalctl -u provibr-agent -f

Alles, was der Einzeiler tut, sind auch nur eine Handvoll Befehle, und das Panel schreibt sie Ihnen mit den aktuellen Werten aus. So sieht es aus.

1. 01

   Den Host vorbereiten: Systembenutzer, Verzeichnisse und Binary.

   shellKopieren

   # System user without a shell and without a home directory
   id -u provibr-agent >/dev/null 2>&1 || \
     sudo useradd --system --no-create-home --shell /usr/sbin/nologin provibr-agent
   
   # Directories for configuration (license, key) and state (identity, vault)
   sudo install -d -o provibr-agent -g provibr-agent -m 0750 /etc/provibr-agent
   sudo install -d -o provibr-agent -g provibr-agent -m 0700 /var/lib/provibr-agent
   
   # The binary from the download
   sudo install -o root -g root -m 0755 ./provibr-agent-linux-x86_64 /usr/local/bin/provibr-agent
   /usr/local/bin/provibr-agent version

2. 02

   Die Lizenzdatei ablegen. Sie laden sie auf der Agentenseite herunter; sie ist mit dem Aktivierungscode verschlüsselt und lässt sich pro Token einmal herunterladen.

   shellKopieren

   sudo install -o root -g provibr-agent -m 0640 \
     ./provibr-<agent>.plic /etc/provibr-agent/license.plic

3. 03

   Als Systembenutzer registrieren, mit dem Aktivierungscode.

   shellKopieren

   sudo -u provibr-agent /usr/local/bin/provibr-agent enroll \
     --license /etc/provibr-agent/license.plic --code XXXXX-XXXXX

4. 04

   Die Unit installieren und den Dienst starten.

   shellKopieren

   sudo install -o root -g root -m 0644 provibr-agent.service /etc/systemd/system/provibr-agent.service
   sudo systemctl daemon-reload
   sudo systemctl enable --now provibr-agent

Der Agent läuft auch als Container. Das Image enthält dieselbe signierte Release-Binärdatei wie der Linux-Download und sonst nichts: keine Shell, keinen Paketmanager, und er läuft als Benutzer ohne Root-Rechte. Er verbindet sich nur ausgehend, braucht also keine veröffentlichten Ports und keinen Service.

Die Registrierung geschieht beim ersten Start. Geben Sie dem Container den Installationslink aus dem Panel und den Aktivierungscode; er holt seine Lizenzdatei, registriert sich und speichert seine Identität auf dem Volume. Bei jedem weiteren Start wird diese Identität verwendet, und die beiden Werte werden nicht mehr gelesen.

Das Panel zeigt diesen Befehl mit dem Link und dem Code Ihres Agenten bereits ausgefüllt. Das Named Volume übernimmt den Eigentümer aus dem Image, sodass der Agent ohne chown hineinschreiben kann.

docker run -d --name provibr-agent --restart unless-stopped \
  --hostname provibr-agent \
  --read-only --cap-drop ALL --security-opt no-new-privileges \
  -v provibr-agent-data:/var/lib/provibr-agent \
  -e PROVIBR_INSTALL_URL='https://app.provibr.com/api/install/<token>' \
  -e PROVIBR_ACTIVATION_CODE='XXXXX-XXXXX' \
  ghcr.io/provibr/provibr-agent:latest

Oder dasselbe als Docker-Compose-Datei:

# Provibr agent — Docker Compose.
#
# The agent connects outbound to the platform; it needs no published ports.
# On the first start it enrolls itself with the installation link and the
# activation code below, and stores its identity on the volume. After that the
# two values are no longer read; the link expires 72 hours after it was made.
#
# Update: change the image tag, then `docker compose up -d`. The volume keeps
# identity and credentials.
services:
  provibr-agent:
    image: ghcr.io/provibr/provibr-agent:latest
    container_name: provibr-agent
    hostname: provibr-agent
    restart: unless-stopped
    read_only: true
    cap_drop:
      - ALL
    security_opt:
      - no-new-privileges:true
    environment:
      PROVIBR_INSTALL_URL: "https://app.provibr.com/api/install/<token>"
      PROVIBR_ACTIVATION_CODE: "XXXXX-XXXXX"
    volumes:
      - provibr-agent-data:/var/lib/provibr-agent

volumes:
  provibr-agent-data:

Einfache Manifeste, kein Helm: ein Namespace, ein Secret mit Link und Code, ein Volume Claim und ein Deployment. Das Panel füllt das Secret für Ihren Agenten aus.

# Provibr agent — Kubernetes (plain manifests, no Helm).
#
# kubectl apply -f provibr-agent.yaml
#
# The agent connects outbound to the platform; there is no Service and no port.
# On the first start it enrolls itself with the installation link and the
# activation code from the Secret, and stores its identity on the volume. After
# that the Secret is no longer read; the link expires 72 hours after it was made.
#
# Exactly one replica, and Recreate: one agent is one identity (one
# certificate). Two pods would be two agents fighting over it.
apiVersion: v1
kind: Namespace
metadata:
  name: provibr-agent
---
apiVersion: v1
kind: Secret
metadata:
  name: provibr-agent-enrollment
  namespace: provibr-agent
type: Opaque
stringData:
  PROVIBR_INSTALL_URL: "https://app.provibr.com/api/install/<token>"
  PROVIBR_ACTIVATION_CODE: "XXXXX-XXXXX"
---
apiVersion: v1
kind: PersistentVolumeClaim
metadata:
  name: provibr-agent-data
  namespace: provibr-agent
spec:
  # One pod, and only one, may mount this volume. On clusters older than
  # Kubernetes 1.29 (or storage without it), use ReadWriteOnce instead; the
  # agent also refuses to start a second time on the same data directory.
  accessModes:
    - ReadWriteOncePod
  resources:
    requests:
      storage: 1Gi
---
apiVersion: apps/v1
kind: Deployment
metadata:
  name: provibr-agent
  namespace: provibr-agent
  labels:
    app.kubernetes.io/name: provibr-agent
spec:
  replicas: 1
  strategy:
    type: Recreate
  selector:
    matchLabels:
      app.kubernetes.io/name: provibr-agent
  template:
    metadata:
      labels:
        app.kubernetes.io/name: provibr-agent
    spec:
      hostname: provibr-agent
      automountServiceAccountToken: false
      enableServiceLinks: false
      securityContext:
        runAsNonRoot: true
        runAsUser: 65532
        runAsGroup: 65532
        fsGroup: 65532
        # Only when the volume root does not match yet; otherwise the kubelet
        # widens the modes on the private keys at every mount.
        fsGroupChangePolicy: OnRootMismatch
        seccompProfile:
          type: RuntimeDefault
        # The ping check uses an unprivileged ICMP socket. Some container
        # runtimes keep those closed, and then the check reports a source
        # error. This safe sysctl opens them for the agent's group only.
        sysctls:
          - name: net.ipv4.ping_group_range
            value: "65532 65532"
      containers:
        - name: agent
          image: ghcr.io/provibr/provibr-agent:latest
          args: ["run"]
          envFrom:
            # optional: the agent reads it on its first start only, so you can
            # delete the Secret once it is enrolled.
            - secretRef:
                name: provibr-agent-enrollment
                optional: true
          securityContext:
            allowPrivilegeEscalation: false
            readOnlyRootFilesystem: true
            capabilities:
              drop: ["ALL"]
          resources:
            requests:
              cpu: 50m
              memory: 32Mi
            limits:
              memory: 256Mi
          volumeMounts:
            - name: data
              mountPath: /var/lib/provibr-agent
      volumes:
        - name: data
          persistentVolumeClaim:
            claimName: provibr-agent-data

Für Kubernetes ist die Lizenzdatei der bessere Weg: Legen Sie statt des Installationslinks die Lizenzdatei und den Code in das Secret, binden Sie die Datei im Pod ein und setzen Sie PROVIBR_LICENSE_FILE auf ihren Pfad. Das Token in der Datei funktioniert genau einmal, das Secret enthält also nichts, womit sich der Agent ein zweites Mal registrieren ließe.

Standardmäßig aktualisiert sich ein Container nicht selbst: Das Image ist das Release. Das Panel zeigt, welches Image aktuell ist; laden Sie es und erstellen Sie den Container neu, oder setzen Sie den neuen Tag auf das Deployment. Das Volume behält Identität und Zugangsdaten. Automatische Updates überspringen diese Agenten; die Option unten ändert das.

docker pull ghcr.io/provibr/provibr-agent:latest
docker stop provibr-agent && docker rm provibr-agent
# then run the same docker run command again with the new image

kubectl -n provibr-agent set image deployment/provibr-agent agent=ghcr.io/provibr/provibr-agent:latest

Setzen Sie PROVIBR_SELF_UPDATE=volume oder aktivieren Sie die Option im Panel. Der Container nimmt dann an der Update-Schaltfläche und an den nächtlichen Updates teil: Eine neue Version wird heruntergeladen, ihre Signatur wird gegen den im Image eingebauten Plattformschlüssel geprüft, und sie wird auf dem Volume abgelegt. Der Container beendet sich mit Exitcode 0, Docker oder das Kubelet startet ihn neu, und die Binärdatei im Image startet die neue Version vom Volume, nachdem sie die Signatur noch einmal geprüft hat.

docker run -d --name provibr-agent --restart unless-stopped \
  --hostname provibr-agent \
  --read-only --cap-drop ALL --security-opt no-new-privileges \
  -v provibr-agent-data:/var/lib/provibr-agent \
  -e PROVIBR_INSTALL_URL='https://app.provibr.com/api/install/<token>' \
  -e PROVIBR_ACTIVATION_CODE='XXXXX-XXXXX' \
  -e PROVIBR_SELF_UPDATE=volume \
  ghcr.io/provibr/provibr-agent:latest

Eine neue Version hat 60 Sekunden Zeit, die Plattform zu erreichen. Gelingt das nicht, wird sie auf dem Volume als fehlerhaft markiert und nie wieder gestartet, und der Container kommt mit der vorherigen Version zurück. Wenn Sie ein neueres Image ausrollen, gilt das Image: Was für das alte Image auf dem Volume lag, wird nicht mehr verwendet.

Das Standard-Image enthält keine Automatisierungs-Runtime. Das Tools-Image mit dem Tag-Suffix -tools enthält denselben signierten Agenten auf Debian, ergänzt um die festgelegte Automatisierungs-Runtime, sodass Automatisierungen im Container laufen können. Die Docker-Beispiele geben ihm ein kleines /tmp und ein pids-Limit (--pids-limit); auf Kubernetes ist /tmp ein emptyDir im Arbeitsspeicher, und ein pids-Limit setzen Sie am Kubelet (podPidsLimit), nicht im Manifest. Das Root-Dateisystem bleibt schreibgeschützt.

docker run -d --name provibr-agent --restart unless-stopped \
  --hostname provibr-agent \
  --read-only --cap-drop ALL --security-opt no-new-privileges \
  --tmpfs /tmp:rw,noexec,nosuid,size=16m --pids-limit 256 \
  -v provibr-agent-data:/var/lib/provibr-agent \
  -e PROVIBR_INSTALL_URL='https://app.provibr.com/api/install/<token>' \
  -e PROVIBR_ACTIVATION_CODE='XXXXX-XXXXX' \
  ghcr.io/provibr/provibr-agent:latest-tools

Manche Funktionen brauchen den Host selbst, und den hat ein abgeschotteter Container nicht:

• Netzwerkinstallationen (PXE): Sie brauchen das Host-Netzwerk und Ports unter 1024.
• Den Host aus dem Panel neu starten: Der Container hat keinen Zugriff auf das Init-System des Hosts.
• Automatisierungen im Standard-Image: Es enthält keine Automatisierungs-Runtime, und die Sandbox, die sie auf einem Host bekommen, braucht User-Namespaces, die ein abgeschotteter Container nicht gewährt. Das Tools-Image führt sie stattdessen im Container selbst aus.
• Host-Messwerte: CPU, Speicher und Laufzeit beschreiben die Maschine, auf der der Container läuft, nicht seine eigenen Limits.

Wenn Sie einen Agenten anlegen, zeigt das Panel den Aktivierungscode genau einmal. Er wird nirgends festgehalten, auch nicht als Hash. Mit diesem Code ist die Lizenzdatei verschlüsselt, sodass die Datei auf Ihrem Host mit etwas verschlüsselt ist, das nicht auf diesem Host liegt.

Die Lizenzdatei selbst trägt kein Geheimnis über Ihre Infrastruktur. Sie sagt dem Agenten, zu welcher Plattform er gehört, welcher Zertifizierungsstelle er vertrauen soll und mit welchem einmalig gültigen Token er sich registriert.

Die Agentenliste zeigt alles auf einmal: Status, Version, ob er gerade verbunden ist, wann er zuletzt gesehen wurde und wann sein Zertifikat abläuft.

• Name und Beschreibung können Sie jederzeit ändern; sie sind nur Bezeichnungen. Ein Name, der schon in einer ausgelieferten Lizenzdatei steht, bleibt, wie er war, was kosmetisch ist und kein Grund, neu zu registrieren.
• Ob er verbunden ist, wird aus einem Live-Signal mit kurzer Gültigkeit gelesen und nicht daraus, wann zuletzt eine Zeile geschrieben wurde. Lässt es sich nicht feststellen, sagt das Panel das, statt zu behaupten, Ihr Agent sei ausgefallen.
• Version und Betriebssystem sind das, was der Agent bei seiner letzten Verbindung gemeldet hat. Ein Agent, der sich nie verbunden hat, zeigt einen Strich statt einer Vermutung.
• Wählen Sie mehrere Agenten in der Liste aus, um sie in einem Zug zu aktualisieren. Die Schaltfläche zählt nur die Agenten, die sich gerade wirklich aktualisieren lassen, sodass Sie vor dem Klick sehen, dass zwölf ausgewählte drei aktualisierte bedeuten.
• Der Fortschritt wird aus dem laufenden Befehl gelesen und nicht aus etwas, das sich Ihr Browser gemerkt hat. Ein Neuladen nimmt ihn also wieder auf.

Registrierung ausstehend

Im Panel angelegt, noch nicht registriert. Ein Token und ein Aktivierungscode warten auf ihn, ein Zertifikat gibt es noch nicht.

Registriert

Er hat ein eigenes Zertifikat und darf sich verbinden. Das ist der einzige Zustand, in dem er Arbeit bekommen kann, und der einzige, in dem er sich nicht löschen lässt.

Widerrufen

Von Ihnen zurückgezogen. Seine Sitzung ist geschlossen, offene Token verfallen, und er darf nicht zurückkommen.

Widerrufen ist der Schalter für den Fall, dass ein Host kompromittiert, außer Betrieb genommen oder schlicht nicht mehr Ihrer ist. Es wirkt, ohne dass Sie den Host anfassen.

• Eine laufende Sitzung wird innerhalb einer Minute geschlossen. Dem Agenten wird der Grund genannt, statt ihn einfach zu trennen.
• Der Agent löscht daraufhin seine eigene Identität, sein Zertifikat und seinen Zugangsdaten-Tresor. Die Zugangsdaten für Ihren Hypervisor sind damit von diesem Host verschwunden.
• Offene Registrierungs-Token verfallen, sodass eine bereits heruntergeladene Lizenzdatei nicht mehr für eine Rückkehr taugt.

Löschen entfernt den Agenten aus dem Panel. Das ist ein eigener Schritt neben dem Widerrufen, und er ist bewusst wählerisch damit, wann er erlaubt ist.

• Ein registrierter Agent lässt sich nicht löschen. Widerrufen Sie ihn zuerst, sonst würden Sie den Eintrag zu etwas entfernen, das noch verbunden ist.
• Ein Agent, an dem Integrationen oder Server hängen, lässt sich ebenfalls nicht löschen, und die Ablehnung nennt beide Anzahlen. Diese Einträge hängen am Agenten, ein Klick würde also Ihren Bestand mitnehmen.
• Hat der Agent nie einen Befehl ausgeführt und nie einen Server gehabt, verschwindet der Eintrag wirklich. Sonst wird er überall ausgeblendet, seine Befehlshistorie bleibt aber erhalten, denn ein Audit-Trail, den man durch Löschen seines Gegenstands beseitigen kann, ist keiner.

Das Widerrufen räumt die Geheimnisse des Agenten ab, lässt die Dateien aber liegen. Um den Host zu säubern, bietet das Panel einen zweiten Einzeiler an, und dieselben vier Schritte von Hand.

1. 01

   Den Dienst stoppen, deaktivieren und die Unit entfernen.

   shellKopieren

   # Stop the service and forget the unit
   sudo systemctl disable --now provibr-agent
   sudo rm -f /etc/systemd/system/provibr-agent.service
   sudo systemctl daemon-reload
   sudo systemctl reset-failed provibr-agent 2>/dev/null || true

2. 02

   Das Binary, das Update-Skript und den Update-Schlüssel entfernen.

   shellKopieren

   # Binary, update script and the trust anchor of the update step
   sudo rm -f /usr/local/bin/provibr-agent
   sudo rm -f /usr/local/lib/provibr-agent/apply-update.sh /usr/local/lib/provibr-agent/license-signing.pub
   
   # The polkit rule that allowed host.reboot (and its 0.105 fallback)
   sudo rm -f /etc/polkit-1/rules.d/49-provibr-agent-reboot.rules /etc/polkit-1/localauthority/50-local.d/49-provibr-agent-reboot.pkla
   
   # Only if nothing else lives in there
   sudo rmdir /usr/local/lib/provibr-agent 2>/dev/null || true

3. 03

   Die Daten entfernen. Das ist der Schritt, auf den es ankommt: Hier liegen die Lizenz, der Tresorschlüssel und die verschlüsselten Zugangsdaten.

   shellKopieren

   # License and vault key
   sudo rm -rf /etc/provibr-agent
   
   # Identity, encrypted credential vault, outbox and staged updates
   sudo rm -rf /var/lib/provibr-agent

4. 04

   Den Systembenutzer entfernen.

   shellKopieren

   sudo userdel provibr-agent
   sudo groupdel provibr-agent 2>/dev/null || true

Danach sollten beide Befehle überhaupt nichts ausgeben:

ls -d /etc/provibr-agent /var/lib/provibr-agent /usr/local/lib/provibr-agent /usr/local/bin/provibr-agent /etc/systemd/system/provibr-agent.service /etc/polkit-1/rules.d/49-provibr-agent-reboot.rules /etc/polkit-1/localauthority/50-local.d/49-provibr-agent-reboot.pkla 2>/dev/null
id provibr-agent 2>/dev/null
# Both commands should print nothing at all