apt purge fjernet VPN-en, men tjenesten starter fortsatt ved oppstart

apt purge sier at pakken er borte, og likevel kommer det opp en tunnel ved hver oppstart. Journalen vokser videre, rutene kommer tilbake, og maskinen oppfører seg som om ingenting er fjernet. En leverandørs installasjonsprogram kan skrive filer som pakkebehandleren aldri registrerte, så å avinstallere en pakke og å avinstallere et produkt er to ulike jobber. Runbooken nedenfor skiller de to registrene og fullfører fjerningen med vilje.

To installasjonsprogrammer, to ulike registre

Debian-pakker holder en filliste, og en purge sletter nøyaktig det listen navngir, pluss pakkekonfigurasjonen. Et skallinstallasjonsprogram eller et .run-bunt holder ingen slik liste; det skriver hvor det vil, vanligvis i /opt, /usr/local og /etc/systemd/system. Ingen av disse stiene vises i noen pakkes filliste, så dpkg verken kjenner eller rapporterer dem. Du ender med to installasjonseiere på ett filsystem, og bare én av dem fører regnskap.

Spør dpkg om den konkrete stien før du sletter den. En sti den fraskriver seg, er din å fjerne, og det samme svaret forteller om en senere oppgradering ville lagt den tilbake.

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

En enhet og dens wants-lenke er separate filer

Aktivering er en handling for seg, atskilt fra installasjon. Enheten erklærer målrelasjoner i [Install]-delen, og systemctl enable gjør disse erklæringene om til symbolske lenker i hvert måls .wants/-mappe. Nå finnes det to stier: enhetsfilen og lenken som drar den inn i et oppstartsmål. Sletter du bare filen, peker lenken på ingenting, noe som gir en klage ved oppstart; sletter du bare lenken, forblir enheten startbar ved navn. Begge må bort.

Fjern dem i rekkefølge og last inn på nytt etterpå, slik at systemd slutter å holde de gamle definisjonene 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

Les FragmentPath i stedet for å anta plasseringen, siden en leverandør kan ha skrevet til /usr/lib/systemd/system eller /lib/systemd/system framfor /etc. Sletter du kopien du forventet, kjører den effektive videre, og rettelsen ser vellykket ut til neste innlasting. List enhetsfilene på nytt når innlastingen er ferdig, og bekreft at navnet ikke lenger vises.

Finn binærfilen som holder ordningen i live

En aktivert enhet fortsetter å starte daemonen uansett hva pakkedatabasen tror. Den prosessen kan bringe tunnelen tilbake, legge til ruter igjen eller gjenopprette en kill-switch-regel, og atferden virker overnaturlig til du undersøker ordningen. Følg ExecStart-stien og sjekk om binærfilen fortsatt er der, for en kjørbar fil etterlatt under /opt er alt ordningen trenger. Å slette enheten stopper den planlagte starten; det sletter ikke programmet.

Behandle tilstandsmapper med samme omhu. Kontotokener, genererte profiler og hurtiglagrede serverlister bor under /var/lib eller i en hjemmemappe, og de er legitimasjon, ikke kastbar hurtiglagring. Fjern dem når tjenesten er stoppet, med vilje, og noter hva du tok.

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

Velg én eier av oppstarten og test den

Tre kandidater kan gjøre krav på oppstarten, og å installere alle tre gir et kappløp i stedet for dobbel sikring. En automatisk startfil på skrivebordet kjører først etter at noen logger inn, en systemd-enhet kjører tidligere men krever en klient som virker uten skjerm, og en cron-@reboot-oppføring utløses etter en plan som kan være feil for en nettverksklient. En leverandør-CLI kan i tillegg kreve et serverargument, fordi det ved oppstart ikke finnes noen tidligere økt å fortsette. Velg kandidaten som passer til hvordan klienten autentiserer, og dropp de andre.

Test det ved å starte maskinen på nytt og se på tre uavhengige fakta: enhetens tilstand, prosesslisten og en ny forbindelse til noe du kan verifisere. En klient som krever en nøkkelring eller en interaktiv innlogging, feiler ved oppstart selv med en korrekt enhetsfil, og journalen sier det hvis du leser den i stedet for bare tjenestestatusen.

Enten gi klienten en legitimasjon som virker uten en forespørsel, eller start den ved innlogging i stedet. Begge er forsvarlige, og å kombinere dem er hvordan én tunnel får to eiere som slåss om den.

Skriv ned hva den neste purge skal forvente

Noter to fakta etter enhver manuell fjerning: hvilket installasjonsprogram som lagde ordningen, og hvilken eier som starter den nå. Den noten gjør den neste purge fra en overraskelse til et punkt på en sjekkliste, og den lever lenger enn personen som gjorde arbeidet.

Oppbevar den ved siden av tjenestekonfigurasjonen og ikke i en personlig mappe, og dater den, fordi en leverandøroppdatering kan gjenopprette en enhet du slettet. Å sammenligne systemctl list-unit-files med den noten hver par måneder fanger gjenopprettingen mens den fortsatt er billig å rette.