apt purge fjernede VPN, men tjenesten starter stadig ved opstart

apt purge siger, at pakken er væk, og dog kommer der stadig en tunnel op ved hver opstart. Journalen vokser fortsat, ruterne kommer tilbage, og maskinen opfører sig, som om intet er fjernet. En leverandørs installationsprogram kan skrive filer, som pakkehåndteringen aldrig har registreret, så at afinstallere en pakke og at afinstallere et produkt er forskellige opgaver. Runbooken nedenfor adskiller de to registre og afslutter fjernelsen med vilje.

To installationsprogrammer, to forskellige registre

Debian-pakker holder en filliste, og en purge sletter præcis det, listen angiver, plus pakkekonfigurationen. Et shell-installationsprogram eller et .run-bundt holder ingen sådan liste; det skriver, hvor det vil, typisk i /opt, /usr/local og /etc/systemd/system. Ingen af disse stier optræder i nogen pakkes filliste, så dpkg hverken kender eller rapporterer dem. Du ender med to installationsejere på ét filsystem, og kun én af dem holder regnskab.

Spørg dpkg om den konkrete sti, før du sletter den. En sti, den frasiger sig, er din at fjerne, og det samme svar fortæller, om en senere opgradering ville lægge den tilbage.

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

En unit og dens wants-link er separate filer

Aktivering er en handling for sig, adskilt fra installation. Uniten erklærer målrelationer i sin [Install]-sektion, og systemctl enable gør disse erklæringer til symbolske links i hvert måls .wants/-mappe. Nu findes der to stier: unitfilen og det link, der trækker den ind i et opstartsmål. Sletter du kun filen, peger linket på intet, hvilket giver en klage ved opstart; sletter du kun linket, forbliver uniten startbar ved navn. Begge skal væk.

Fjern dem i rækkefølge, og genindlæs bagefter, så systemd holder op med at have de gamle definitioner i hukommelsen.

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

Læs FragmentPath i stedet for at antage placeringen, da en leverandør kan have skrevet til /usr/lib/systemd/system eller /lib/systemd/system frem for /etc. Sletter du den kopi, du forventede, kører den effektive videre, og rettelsen ser ud til at lykkes indtil næste genindlæsning. List unitfilerne igen, når genindlæsningen er færdig, og bekræft, at navnet ikke længere optræder.

Find den binære fil, der holder arrangementet i live

En aktiveret unit bliver ved med at starte dæmonen, uanset hvad pakkedatabasen tror. Den proces kan bringe tunnelen tilbage, tilføje ruter igen eller gendanne en kill-switch-regel, og adfærden virker overnaturlig, indtil du undersøger opsætningen. Følg ExecStart-stien, og kontroller, om den binære fil stadig er der, for en eksekverbar fil efterladt under /opt er alt, hvad arrangementet behøver. Sletning af uniten stopper den planlagte start; den sletter ikke programmet.

Behandl tilstandsmapper med samme omhu. Kontotokener, genererede profiler og cachelagrede serverlister ligger under /var/lib eller i en hjemmemappe, og de er legitimationsoplysninger, ikke cache, man smider ud. Fjern dem, når tjenesten er stoppet, med vilje, og noter, hvad du tog.

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

Vælg én opstartsejer, og test den

Tre kandidater kan gøre krav på opstarten, og installerer man alle tre, får man et kapløb i stedet for dobbelt sikkerhed. En automatisk startfil på skrivebordet kører først, efter nogen logger ind, en systemd-unit kører tidligere, men kræver en klient, der virker uden skærm, og en cron-@reboot-post udløses efter en tidsplan, der kan være forkert for en netværksklient. En leverandør-CLI kan desuden kræve et serverargument, fordi der ved opstart ikke er nogen tidligere session at genoptage. Vælg den kandidat, der passer til, hvordan klienten godkender, og drop de andre.

Test det ved at genstarte maskinen og se på tre uafhængige fakta: unitens tilstand, proceslisten og en ny forbindelse til noget, du kan verificere. En klient, der kræver en nøglering eller et interaktivt login, fejler ved opstart selv med en korrekt unitfil, og journalen siger det, hvis du læser den i stedet for kun tjenestestatus.

Giv enten klienten en legitimationsoplysning, der virker uden en prompt, eller start den ved login i stedet. Begge er forsvarlige, og at kombinere dem er, hvordan en tunnel får to ejere, der slås om den.

Skriv ned, hvad den næste purge skal forvente

Noter to fakta efter enhver manuel fjernelse: hvilket installationsprogram der skabte arrangementet, og hvilken ejer der nu starter det. Den note gør den næste purge fra en overraskelse til et punkt på en tjekliste, og den lever længere end personen, der udførte arbejdet.

Opbevar den ved siden af tjenestekonfigurationen frem for i en personlig mappe, og datér den, fordi en leverandøropdatering kan gendanne en unit, du slettede. Ved at sammenligne systemctl list-unit-files med den note hver par måneder fanges gendannelsen, mens den stadig er billig at rette.