apt purge heeft de VPN verwijderd, maar de dienst start nog steeds bij het opstarten

apt purge zegt dat het pakket weg is, en toch komt er bij elke start weer een tunnel op. Het journal blijft groeien, routes komen terug, en de machine gedraagt zich alsof er niets is verwijderd. Een installatieprogramma van een leverancier kan bestanden schrijven die de pakketbeheerder nooit heeft geregistreerd, dus zijn een pakket verwijderen en een product verwijderen twee verschillende klussen. De runbook hieronder scheidt de twee registraties en rondt de verwijdering bewust af.

Twee installatieprogramma's, twee verschillende registraties

Debian-pakketten houden een bestandslijst bij, en een purge wist precies wat die lijst noemt plus de pakketconfiguratie. Een shell-installatieprogramma of een .run-bundel houdt zo'n lijst niet bij; het schrijft waar het wil, meestal in /opt, /usr/local en /etc/systemd/system. Geen van die paden staat in de bestandslijst van welk pakket dan ook, dus dpkg kent ze niet en meldt ze niet. Je eindigt met twee installatie-eigenaren op één bestandssysteem, en slechts één van hen houdt de boeken bij.

Vraag dpkg naar het specifieke pad voordat je het wist. Een pad dat het afwijst is van jou om te verwijderen, en hetzelfde antwoord zegt of een latere upgrade het zou terugzetten.

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

Een unit en zijn wants-link zijn aparte bestanden

Inschakelen is een aparte handeling van installeren. De unit verklaart doelrelaties in zijn [Install]-sectie, en systemctl enable maakt van die verklaringen symbolische links in de .wants/-map van elk doel. Nu bestaan er twee paden: het unitbestand en de link die het in een opstartdoel trekt. Verwijder je alleen het bestand, dan wijst de link naar niets, wat bij het opstarten een klacht oplevert; verwijder je alleen de link, dan blijft de unit bij naam startbaar. Beide moeten weg.

Verwijder ze in volgorde en herlaad daarna, zodat systemd de oude definities niet meer in het geheugen houdt.

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

Lees FragmentPath in plaats van de locatie aan te nemen, want een leverancier heeft misschien naar /usr/lib/systemd/system of /lib/systemd/system geschreven in plaats van /etc. Als je de verwachte kopie wist, blijft de effectieve draaien, en de reparatie lijkt geslaagd tot de volgende herlaad. Vermeld de unitbestanden opnieuw als het herladen klaar is, en bevestig dat de naam niet meer verschijnt.

Vind het programma dat de opzet in leven houdt

Een ingeschakelde unit blijft de daemon starten, wat de pakketdatabase ook gelooft. Dat proces kan de tunnel terugbrengen, routes opnieuw toevoegen of een kill-switch-regel herstellen, en het gedrag lijkt bovennatuurlijk tot je de opzet inspecteert. Volg het pad van ExecStart en controleer of het programma er nog is, want een uitvoerbaar bestand dat onder /opt is achtergelaten is alles wat de opzet nodig heeft. De unit verwijderen stopt de geplande start; het verwijdert het programma niet.

Behandel statusmappen met dezelfde zorg. Accounttokens, gegenereerde profielen en gecachte serverlijsten staan onder /var/lib of in een thuismap, en dat zijn inloggegevens, geen wegwerpcache. Verwijder ze nadat de dienst is gestopt, bewust, en noteer wat je hebt meegenomen.

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

Kies één eigenaar van het opstarten en test hem

Drie kandidaten kunnen het opstarten opeisen, en alle drie installeren levert een wedloop op in plaats van dubbele zekerheid. Een autostartbestand van de desktop draait pas nadat iemand inlogt, een systemd-unit draait eerder maar vereist een client die zonder scherm werkt, en een cron-@reboot-regel gaat af volgens een schema dat voor een netwerkclient verkeerd kan zijn. De CLI van de leverancier kan bovendien een serverargument vereisen, omdat er bij het opstarten geen eerdere sessie is om voort te zetten. Kies de kandidaat die past bij hoe de client zich authenticeert, en laat de andere vallen.

Test het door de machine opnieuw op te starten en naar drie onafhankelijke feiten te kijken: de toestand van de unit, de proceslijst en een nieuwe verbinding naar iets dat je kunt verifiëren. Een client die een sleutelhanger of een interactieve login nodig heeft, faalt bij het opstarten zelfs met een correct unitbestand, en het journal zegt dat als je het leest in plaats van alleen de dienststatus.

Geef de client ofwel inloggegevens die zonder vraag werken, of start hem in plaats daarvan bij het inloggen. Beide zijn verdedigbaar, en ze combineren is hoe één tunnel twee eigenaren krijgt die erom vechten.

Schrijf op wat de volgende purge moet verwachten

Noteer twee feiten na elke handmatige verwijdering: welk installatieprogramma de opzet heeft gemaakt, en welke eigenaar hem nu start. Die notitie verandert de volgende purge van een verrassing in een punt op een controlelijst, en ze leeft langer dan de persoon die het werk deed.

Bewaar haar naast de dienstconfiguratie en niet in een persoonlijke map, en dateer haar, want een leveranciersupdate kan een unit herstellen die je hebt verwijderd. Door systemctl list-unit-files elke paar maanden met die notitie te vergelijken, betrap je de herstelling terwijl de reparatie nog goedkoop is.