apt purge a supprimé le VPN, mais le service démarre toujours au boot

apt purge annonce que le paquet a disparu, et pourtant un tunnel remonte à chaque démarrage. Le journal continue de grossir, les routes reviennent, et la machine se comporte comme si rien n'avait été retiré. L'installateur du fournisseur peut écrire des fichiers que le gestionnaire de paquets n'a jamais enregistrés, donc désinstaller un paquet et désinstaller un produit sont deux tâches différentes. Le runbook ci-dessous sépare les deux registres et termine la suppression volontairement.

Deux installateurs, deux registres différents

Les paquets Debian tiennent une liste de fichiers, et une purge efface exactement ce que cette liste nomme, plus la configuration du paquet. Un installateur shell ou un paquet .run ne tient pas une telle liste ; il écrit où il veut, généralement dans /opt, /usr/local et /etc/systemd/system. Aucun de ces chemins n'apparaît dans la liste de fichiers d'un paquet, donc dpkg ne les connaît ni ne les signale. Vous finissez avec deux propriétaires d'installation sur un seul système de fichiers, et un seul d'entre eux tient les comptes.

Interrogez dpkg sur le chemin précis avant de le supprimer. Un chemin qu'il désavoue est à vous de retirer, et la même réponse vous dit si une mise à jour ultérieure le remettrait.

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

Une unité et son lien wants sont des fichiers distincts

Activer est un acte distinct de l'installation. L'unité déclare des relations de cible dans sa section [Install], et systemctl enable transforme ces déclarations en liens symboliques dans le répertoire .wants/ de chaque cible. Deux chemins existent désormais : le fichier de l'unité, et le lien qui l'entraîne dans une cible de démarrage. Supprimez seulement le fichier et le lien ne pointe vers rien, ce qui produit une plainte au démarrage ; supprimez seulement le lien et l'unité reste démarrable par son nom. Les deux doivent partir.

Retirez-les dans l'ordre et rechargez ensuite, pour que systemd cesse de garder les anciennes définitions en mémoire.

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

Lisez FragmentPath au lieu de supposer l'emplacement, car un fournisseur a peut-être écrit dans /usr/lib/systemd/system ou /lib/systemd/system plutôt que dans /etc. Supprimer la copie attendue laisse l'effective tourner, et la correction semble réussir jusqu'au prochain rechargement. Listez à nouveau les fichiers d'unités une fois le rechargement terminé, et confirmez que le nom n'apparaît plus.

Trouvez le binaire qui maintient l'installation en vie

Une unité activée continue de démarrer le démon quoi que croie la base de paquets. Ce processus peut faire remonter le tunnel, rajouter des routes ou restaurer une règle de kill-switch, et le comportement paraît surnaturel jusqu'à ce que vous inspectiez la disposition. Suivez le chemin ExecStart et vérifiez si le binaire est toujours là, car un exécutable laissé sous /opt suffit à la disposition. Supprimer l'unité arrête le démarrage planifié ; cela ne supprime pas le programme.

Traitez les répertoires d'état avec le même soin. Les jetons de compte, les profils générés et les listes de serveurs en cache vivent sous /var/lib ou dans un répertoire personnel, et ce sont des identifiants, pas un cache jetable. Retirez-les une fois le service arrêté, délibérément, et notez ce que vous avez pris.

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

Choisissez un seul propriétaire du démarrage et testez-le

Trois candidats peuvent revendiquer le démarrage, et installer les trois produit une course plutôt qu'une double sécurité. Un fichier d'autostart de bureau ne s'exécute qu'après une connexion, une unité systemd s'exécute plus tôt mais exige un client qui fonctionne sans écran, et une entrée cron @reboot se déclenche selon un calendrier qui peut être faux pour un client réseau. La CLI du fournisseur peut en outre exiger un argument de serveur, car au démarrage il n'y a pas de session précédente à reprendre. Choisissez le candidat qui correspond à la façon dont le client s'authentifie, et écartez les autres.

Testez-le en redémarrant la machine et en regardant trois faits indépendants : l'état de l'unité, la liste des processus, et une nouvelle connexion vers quelque chose que vous pouvez vérifier. Un client qui exige un trousseau ou une connexion interactive échoue au démarrage même avec un fichier d'unité correct, et le journal le dit si vous le lisez au lieu de seulement l'état du service.

Soit vous donnez au client un identifiant qui fonctionne sans invite, soit vous le démarrez à la connexion. Les deux sont défendables, et les combiner est la façon dont un tunnel acquiert deux propriétaires qui se disputent.

Notez ce que la prochaine purge doit attendre

Notez deux faits après toute suppression manuelle : quel installateur a créé la disposition, et quel propriétaire la démarre maintenant. Cette note transforme la prochaine purge de surprise en point de liste de contrôle, et elle survit à la personne qui a fait le travail.

Conservez-la à côté de la configuration du service plutôt que dans un répertoire personnel, et datez-la, car une mise à jour du fournisseur peut restaurer une unité que vous avez supprimée. Comparer systemctl list-unit-files à cette note tous les quelques mois attrape la restauration tant que la correction est encore bon marché.