apt purge tog bort VPN:en, men tjänsten startar fortfarande vid uppstart

apt purge säger att paketet är borta, och ändå kommer det upp en tunnel vid varje start. Journalen växer vidare, rutterna kommer tillbaka, och maskinen beter sig som om ingenting hade tagits bort. En leverantörs installationsprogram kan skriva filer som pakethanteraren aldrig registrerade, så att avinstallera ett paket och att avinstallera en produkt är två olika jobb. Runbooken nedan skiljer de två registren och slutför borttagningen med avsikt.

Två installationsprogram, två olika register

Debian-paket håller en fillista, och en purge raderar exakt det listan namnger plus paketkonfigurationen. Ett skals installationsprogram eller ett .run-paket håller ingen sådan lista; det skriver var det vill, vanligtvis i /opt, /usr/local och /etc/systemd/system. Ingen av dessa sökvägar visas i något pakets fillista, så dpkg varken känner till eller rapporterar dem. Du slutar med två installationägare på ett filsystem, och bara en av dem för böcker.

Fråga dpkg om den specifika sökvägen innan du raderar den. En sökväg som det avsäger sig är din att ta bort, och samma svar säger om en senare uppgradering skulle lägga tillbaka den.

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

En unit och dess wants-länk är separata filer

Aktivering är en handling för sig, skild från installation. Uniten deklarerar målrelationer i sitt [Install]-avsnitt, och systemctl enable gör dessa deklarationer till symboliska länkar i varje måls .wants/-katalog. Nu finns två sökvägar: unitfilen och länken som drar in den i ett uppstartsmål. Raderar du bara filen pekar länken på ingenting, vilket ger ett klagomål vid start; raderar du bara länken förblir uniten startbar vid namn. Båda måste bort.

Ta bort dem i ordning och läs in på nytt efteråt, så att systemd slutar hålla de gamla definitionerna i minnet.

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 stället för att anta platsen, eftersom en leverantör kan ha skrivit till /usr/lib/systemd/system eller /lib/systemd/system i stället för /etc. Raderar du kopian du förväntade dig fortsätter den effektiva att köra, och rättelsen ser lyckad ut till nästa inläsning. Lista unitfilerna igen när inläsningen är klar och bekräfta att namnet inte längre syns.

Hitta binärfilen som håller arrangemanget vid liv

En aktiverad unit fortsätter starta daemonen vad paketdatabasen än tror. Den processen kan få tillbaka tunneln, lägga till rutter igen eller återställa en kill-switch-regel, och beteendet verkar övernaturligt tills du inspekterar arrangemanget. Följ ExecStart-sökvägen och kontrollera om binärfilen fortfarande är där, för en körbar fil lämnad under /opt är allt arrangemanget behöver. Att radera uniten stoppar den schemalagda starten; det raderar inte programmet.

Behandla tillståndskataloger med samma omsorg. Kontotoken, genererade profiler och cachelagrade serverlistor bor under /var/lib eller i en hemkatalog, och de är inloggningsuppgifter, inte slängbar cache. Ta bort dem när tjänsten stoppats, med avsikt, och notera vad 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älj en ägare av uppstarten och testa den

Tre kandidater kan göra anspråk på uppstarten, och att installera alla tre ger ett kapplöpning i stället för dubbel säkerhet. En autostartfil på skrivbordet körs först efter att någon loggat in, en systemd-unit körs tidigare men kräver en klient som fungerar utan skärm, och en cron-@reboot-post utlöses enligt ett schema som kan vara fel för en nätverksklient. En leverantörs-CLI kan dessutom kräva ett serverargument, eftersom det vid start inte finns någon tidigare session att återuppta. Välj kandidaten som matchar hur klienten autentiserar, och släpp de andra.

Testa det genom att starta om maskinen och titta på tre oberoende fakta: unitens tillstånd, processlistan och en ny anslutning till något du kan verifiera. En klient som kräver en nyckelring eller en interaktiv inloggning misslyckas vid start även med en korrekt unitfil, och journalen säger det om du läser den i stället för bara tjänstestatusen.

Antingen ge klienten en inloggningsuppgift som fungerar utan fråga, eller starta den vid inloggning i stället. Båda är försvarbara, och att kombinera dem är hur en tunnel får två ägare som slåss om den.

Skriv ner vad nästa purge ska förvänta sig

Notera två fakta efter varje manuell borttagning: vilket installationsprogram som skapade arrangemanget, och vilken ägare som startar det nu. Den anteckningen förvandlar nästa purge från en överraskning till en punkt på en checklista, och den lever längre än personen som gjorde jobbet.

Förvara den bredvid tjänstekonfigurationen och inte i en personlig katalog, och datera den, eftersom en leverantörsuppdatering kan återställa en unit du raderade. Att jämföra systemctl list-unit-files med den anteckningen varannan månad fångar återställningen medan rättelsen fortfarande är billig.