VPN-Paketentfernung in prerm fehlgeschlagen: Was zuerst zu prüfen ist

Deinstallationen können mittendrin mit einem Fehler stoppen, der ein Maintainer-Skript nennt, und das VPN halb entfernt zurücklassen: Konfigurationsdateien bleiben zurück, der Dienst läuft möglicherweise noch, und der Paketmanager weigert sich fortzufahren. Die verlockende Lösung in einem alten Forenbeitrag ist, das Skript zu löschen und die Entfernung zu erzwingen. Das behandelt das Symptom und verwirft den Reinigungsschritt, der fehlgeschlagen ist. Lesen Sie zuerst die Phase und den Paketzustand.

Welcher Lebenszyklusschritt tatsächlich fehlgeschlagen ist

Debian-Pakete führen preinst und postinst bei der Installation sowie prerm und postrm bei Entfernung oder vollständiger Löschung aus, wobei der Exit-Status jedes Skripts die nächste Aktion bestimmt. Ein Fehler von prerm bedeutet, dass die Entfernung stoppte, bevor die Dateien des Pakets gelöscht wurden; ein Fehler von postrm bedeutet, dass die Entfernung bereits erfolgt ist und die Reinigung fehlschlug. Das sind unterschiedliche Situationen mit unterschiedlicher Wiederherstellung. Die Distributionsrichtlinie erwartet außerdem, dass Skripte einen wiederholten Lauf tolerieren, weil eine fehlgeschlagene Phase wiederholt und nicht vermieden werden sollte.

Halten Sie den ersten Fehler wörtlich fest, zusammen mit Paketname, Version und Distributionsrelease. Spätere Fehler sind meist Folgen.

Lesen Sie den Paketzustand, bevor Sie ihn ändern

Fragen Sie den Paketmanager, was seiner Ansicht nach passiert ist, bevor Sie einen weiteren Befehl absetzen.

dpkg -l vpn-package
dpkg --audit
apt-get -s remove vpn-package

Die Auflistung zeigt die Zustandsflags des Pakets, die Prüfung findet Pakete, die beschädigt oder halb konfiguriert zurückgelassen wurden, und die simulierte Entfernung gibt aus, was apt tun würde, ohne etwas anzufassen. Eine Simulation, die am selben Skript scheitert, bestätigt die Phase statt des Netzwerks. Notieren Sie das im Fehler genannte Skript und listen Sie die Informationsdateien des Pakets auf, wenn Sie sehen müssen, welche Skripte existieren. Nichts davon rechtfertigt es vorerst, diese Dateien zu bearbeiten.

Schützen Sie den Verwaltungsweg vor der Reparatur

Wenn das VPN Ihre einzige SSH-Sitzung zu diesem Host trägt, beendet die Entfernung Ihren Zugang mitten in der Reparatur. Richten Sie zuerst eine Konsole, eine Out-of-Band-Verwaltungsschnittstelle oder eine zweite Route ein, und bestätigen Sie, dass sie funktioniert, bevor Sie beginnen. Bewahren Sie das Profil und alle Anweisungen zur erneuten Registrierung auf, die Sie später brauchen, weil eine vollständige Löschung erzeugte Konfiguration entfernen kann. Halten Sie Anmeldedaten aus den Notizen heraus, die Sie in ein Ticket einfügen, und halten Sie private Schlüssel vollständig aus der Diagnose heraus.

Behandeln Sie eine dokumentierte manuelle Übersteuerung als letztes Mittel unter Anleitung des Paketeigentümers, mit den übersprungenen Schritten abgerechnet. Löschen Sie niemals Skripte per Platzhalter, weil die eigene Bereinigungsliste des Pakets festhält, was noch zu tun bleibt.

Trennen Sie Ergebnisse für Paket, Netzwerk und Anmeldedaten

Drei Ergebnisse sind unabhängig zu prüfen, sobald das unterstützte Verfahren endet. Die Pakettransaktion sollte einen sauberen Zustand zeigen, ohne halb konfigurierte Einträge in der Prüfung. Das Netzwerk sollte dem entsprechen, was Sie beabsichtigt haben: der richtige Dienst gestoppt, keine veralteten Routen oder DNS-Einstellungen und ein funktionierender Weg für Ersatz oder direkten Zugang. Die Gegenseite ist das dritte Ergebnis, und veraltete Anmeldedaten sollten über den Inhaber jenes Kontos außer Kraft gesetzt werden, weil das Deinstallieren eines Clients nichts widerruft.

Verbinden Sie sich dann erneut und testen Sie ein erlaubtes Ziel. Ein sauberer Paketzustand mit einem weiterhin laufenden Tunnel ist ein anderes Ergebnis als ein sauberes Netzwerk, und nur das zweite sagt Ihnen, dass die Entfernung tatsächlich wirksam wurde.