apt purge hat das VPN entfernt, doch der Dienst startet weiterhin beim Booten

apt purge meldet, das Paket sei weg, und trotzdem kommt bei jedem Start wieder ein Tunnel hoch. Das Journal wächst weiter, Routen kehren zurück, und die Maschine verhält sich, als wäre nichts entfernt worden. Ein Hersteller-Installer kann Dateien schreiben, die der Paketmanager nie erfasst hat, daher sind ein Paket zu deinstallieren und ein Produkt zu deinstallieren zwei verschiedene Aufgaben. Das folgende Runbook trennt die beiden Aufzeichnungen und schließt die Entfernung bewusst ab.

Zwei Installer, zwei verschiedene Aufzeichnungen

Debian-Pakete führen eine Dateiliste, und eine purge löscht genau das, was diese Liste nennt, plus die Paketkonfiguration. Ein Shell-Installer oder ein .run-Bündel führt keine solche Liste; er schreibt, wohin er will, üblicherweise nach /opt, /usr/local und /etc/systemd/system. Keiner dieser Pfade erscheint in irgendeiner Paketdateiliste, also kennt dpkg sie weder noch meldet es sie. Am Ende gibt es zwei Installationseigentümer auf einem Dateisystem, und nur einer davon führt Bücher.

Fragen Sie dpkg vor dem Löschen nach dem konkreten Pfad. Ein Pfad, den es abstreitet, gehört Ihnen zur Entfernung, und dieselbe Antwort sagt Ihnen, ob ein späteres Upgrade ihn zurückbringen würde.

dpkg -S /etc/systemd/system/acmevpn.service
systemctl list-unit-files | grep -i acmevpn

Eine Unit und ihr wants-Link sind getrennte Dateien

Aktivieren ist ein vom Installieren getrennter Vorgang. Die Unit erklärt Zielbeziehungen in ihrem [Install]-Abschnitt, und systemctl enable macht diese Erklärungen zu symbolischen Links in jedem .wants/-Verzeichnis des Ziels. Nun existieren zwei Pfade: die Unit-Datei und der Link, der sie in ein Boot-Ziel zieht. Löschen Sie nur die Datei, zeigt der Link ins Leere, was beim Start eine Beschwerde erzeugt; löschen Sie nur den Link, bleibt die Unit unter ihrem Namen startbar. Beide müssen weg.

Entfernen Sie sie der Reihe nach und laden Sie danach neu, damit systemd die alten Definitionen nicht mehr im Speicher hält.

systemctl disable --now acmevpn.service
systemctl show -p FragmentPath -p ExecStart acmevpn.service
sudo rm /etc/systemd/system/acmevpn.service
sudo rm /etc/systemd/system/multi-user.target.wants/acmevpn.service
systemctl daemon-reload

Lesen Sie FragmentPath, statt den Ort anzunehmen, denn ein Hersteller hat vielleicht nach /usr/lib/systemd/system oder /lib/systemd/system geschrieben statt nach /etc. Löschen Sie die erwartete Kopie, läuft die wirksame weiter, und die Reparatur wirkt erfolgreich bis zum nächsten Neuladen. Listen Sie die Unit-Dateien nach dem Neuladen erneut auf und bestätigen Sie, dass der Name nicht mehr erscheint.

Finden Sie das Programm, das die Anordnung am Leben hält

Eine aktivierte Unit startet den Daemon weiter, egal was die Paketdatenbank glaubt. Dieser Prozess kann den Tunnel wieder hochbringen, Routen erneut hinzufügen oder eine Kill-Switch-Regel wiederherstellen, und das Verhalten wirkt überirdisch, bis Sie die Anordnung prüfen. Folgen Sie dem ExecStart-Pfad und prüfen Sie, ob das Programm noch da ist, denn eine unter /opt zurückgelassene ausführbare Datei ist alles, was die Anordnung braucht. Die Unit zu löschen beendet den geplanten Start; es löscht nicht das Programm.

Behandeln Sie Zustandsverzeichnisse mit derselben Sorgfalt. Kontotoken, generierte Profile und zwischengespeicherte Serverlisten liegen unter /var/lib oder in einem Home-Verzeichnis, und das sind Zugangsdaten, kein Wegwerf-Cache. Entfernen Sie sie nach dem Stoppen des Dienstes bewusst und notieren Sie, was Sie mitgenommen haben.

sudo ls -l /opt/acmevpn /usr/local/bin/acmevpn
sudo find /var/lib -maxdepth 2 -iname "*acme*"
systemctl is-enabled acmevpn.service

Wählen Sie einen Boot-Eigentümer und testen Sie ihn

Drei Kandidaten können den Start beanspruchen, und alle drei zu installieren erzeugt ein Rennen statt doppelter Sicherheit. Eine Desktop-Autostart-Datei läuft erst, nachdem sich jemand angemeldet hat, eine systemd-Unit läuft früher, braucht aber einen Client, der ohne Bildschirm funktioniert, und ein cron-@reboot-Eintrag feuert nach einem Zeitplan, der für einen Netzwerkclient falsch sein kann. Eine Hersteller-CLI kann zusätzlich ein Serverargument verlangen, weil es beim Start keine vorherige Sitzung zum Fortsetzen gibt. Wählen Sie den Kandidaten, der zur Art der Client-Authentifizierung passt, und verwerfen Sie die anderen.

Testen Sie es, indem Sie die Maschine neu starten und drei unabhängige Fakten prüfen: den Unit-Zustand, die Prozessliste und eine neue Verbindung zu etwas, das Sie verifizieren können. Ein Client, der einen Schlüsselbund oder eine interaktive Anmeldung braucht, scheitert beim Start selbst mit korrekter Unit-Datei, und das Journal sagt es, wenn Sie es lesen statt nur den Dienststatus.

Geben Sie dem Client entweder einen Zugangsdatensatz, der ohne Abfrage funktioniert, oder starten Sie ihn stattdessen bei der Anmeldung. Beides ist vertretbar, und beides zu kombinieren ist der Weg, wie ein Tunnel zwei Eigentümer bekommt, die darum streiten.

Notieren Sie, was die nächste purge erwarten sollte

Notieren Sie nach jeder manuellen Entfernung zwei Fakten: welcher Installer die Anordnung erzeugt hat und welcher Eigentümer sie jetzt startet. Diese Notiz verwandelt die nächste purge von einer Überraschung in einen Punkt einer Checkliste, und sie überlebt die Person, die die Arbeit gemacht hat.

Bewahren Sie sie neben der Dienstkonfiguration auf, nicht in einem persönlichen Verzeichnis, und datieren Sie sie, denn ein Herstellerupdate kann eine gelöschte Unit wiederherstellen. Ein Vergleich von systemctl list-unit-files mit dieser Notiz alle paar Monate erwischt die Wiederherstellung, solange die Korrektur noch billig ist.