Échec de la suppression du paquet VPN dans prerm : que vérifier en premier

Les désinstallations peuvent s’arrêter en cours de route avec une erreur nommant un script de maintenance, laissant le VPN à moitié supprimé : les fichiers de configuration restent, le service peut encore tourner, et le gestionnaire de paquets refuse de continuer. Le correctif tentant d’un vieux fil de forum consiste à supprimer le script et à forcer la suppression. Cela traite le symptôme et écarte l’étape de nettoyage qui a échoué. Lisez d’abord l’étape et l’état du paquet.

Quelle étape du cycle de vie a réellement échoué

Les paquets Debian exécutent preinst et postinst à l’installation, et prerm et postrm à la suppression ou à la purge, le code de sortie de chaque script déterminant l’action suivante. Une erreur de prerm signifie que la suppression s’est arrêtée avant que les fichiers du paquet soient effacés ; une erreur de postrm signifie que la suppression a déjà eu lieu et que le nettoyage a échoué. Ce sont des situations différentes avec une récupération différente. La politique de la distribution attend aussi que les scripts tolèrent une exécution répétée, car une étape échouée doit être rejouée plutôt qu’évitée.

Notez la première erreur mot pour mot, avec le nom du paquet, la version et la version de la distribution. Les erreurs suivantes sont généralement des conséquences.

Lisez l’état du paquet avant de le modifier

Demandez au gestionnaire de paquets ce qu’il pense être arrivé avant d’émettre une autre commande.

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

La liste montre les indicateurs d’état du paquet, l’audit trouve les paquets laissés cassés ou à moitié configurés, et la suppression simulée imprime ce qu’apt ferait sans rien toucher. Une simulation qui échoue au même script confirme l’étape plutôt que le réseau. Notez le script nommé dans l’erreur et listez les fichiers d’informations du paquet si vous devez voir quels scripts existent. Rien de tout cela ne justifie encore de modifier ces fichiers.

Protégez la voie de gestion avant la réparation

Si le VPN transporte votre unique session SSH vers cet hôte, le supprimer met fin à votre accès au milieu de la réparation. Prévoyez d’abord une console, une interface de gestion hors bande ou une seconde route, et confirmez qu’elle fonctionne avant de commencer. Conservez le profil et toute instruction de réinscription dont vous aurez besoin ensuite, car une purge peut supprimer une configuration générée. Gardez les identifiants hors des notes que vous collez dans un ticket, et gardez les clés privées entièrement hors du diagnostic.

Traitez un contournement manuel documenté comme un dernier recours sous la conduite du propriétaire du paquet, en tenant compte des étapes omises. Ne supprimez jamais de scripts par joker, car la propre liste de nettoyage du paquet est le registre de ce qui reste à faire.

Séparez les résultats du paquet, du réseau et des identifiants

Trois résultats doivent être vérifiés indépendamment une fois la procédure prise en charge terminée. La transaction du paquet doit montrer un état propre, sans entrées à moitié configurées restant dans l’audit. Le réseau doit correspondre à ce que vous vouliez : le bon service arrêté, aucune route ni paramètre DNS obsolète, et un chemin fonctionnel pour le remplacement ou l’accès direct. Le côté distant est le troisième résultat, et les identifiants obsolètes doivent être retirés par le propriétaire de ce compte, car désinstaller un client ne révoque rien.

Reconnectez-vous ensuite et testez une destination autorisée. Un état de paquet propre avec un tunnel encore actif est un résultat différent d’un réseau propre, et seul le second vous dit que la suppression a réellement pris effet.