apt purge a eliminat VPN-ul, dar serviciul pornește în continuare la boot

apt purge spune că pachetul a dispărut, și totuși un tunel apare la fiecare pornire. Journalul continuă să crească, rutele revin, iar mașina se comportă ca și cum nimic nu ar fi fost eliminat. Instalatorul furnizorului poate scrie fișiere pe care managerul de pachete nu le-a înregistrat niciodată, așa că dezinstalarea unui pachet și dezinstalarea unui produs sunt două lucrări diferite. Runbook-ul de mai jos separă cele două evidențe și încheie eliminarea în mod deliberat.

Doi instalatori, două evidențe diferite

Pachetele Debian țin o listă de fișiere, iar un purge șterge exact ce numește lista plus configurația pachetului. Un instalator shell sau un pachet .run nu ține o astfel de listă; scrie unde vrea, de obicei în /opt, /usr/local și /etc/systemd/system. Niciuna dintre aceste căi nu apare în lista de fișiere a vreunui pachet, așa că dpkg nici nu le știe, nici nu le raportează. Rămâneți cu doi proprietari ai instalării pe un singur sistem de fișiere, iar doar unul dintre ei ține evidența.

Întrebați dpkg despre calea concretă înainte de a o șterge. O cale pe care o renegă este a dumneavoastră spre eliminare, iar același răspuns spune dacă o actualizare ulterioară ar readuce-o.

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

Un unit și legătura sa wants sunt fișiere separate

Activarea este un act separat de instalare. Unit-ul declară relații de țintă în secțiunea [Install], iar systemctl enable transformă acele declarații în legături simbolice în directorul .wants/ al fiecărei ținte. Acum există două căi: fișierul unit-ului și legătura care îl trage într-o țintă de pornire. Ștergeți doar fișierul și legătura nu arată spre nimic, ceea ce produce o reclamație la pornire; ștergeți doar legătura și unit-ul rămâne pornibil după nume. Ambele trebuie să dispară.

Eliminați-le în ordine și reîncărcați după aceea, ca systemd să nu mai țină definițiile vechi în memorie.

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

Citiți FragmentPath în loc să presupuneți locația, fiindcă furnizorul poate fi scris în /usr/lib/systemd/system sau /lib/systemd/system și nu în /etc. Ștergerea copiei pe care o așteptați lasă copia efectivă să ruleze, iar remedierea pare reușită până la următoarea reîncărcare. Listați din nou fișierele unit-urilor după ce reîncărcarea se termină și confirmați că numele nu mai apare.

Găsiți binarul care ține aranjamentul în viață

Un unit activat continuă să pornească demonul orice ar crede baza de date a pachetelor. Acel proces poate readuce tunelul, poate adăuga din nou rute sau poate restaura o regulă kill-switch, iar comportamentul pare supranatural până inspectați aranjamentul. Urmați calea ExecStart și verificați dacă binarul mai este acolo, fiindcă un executabil lăsat sub /opt este tot ce are nevoie aranjamentul. Ștergerea unit-ului oprește pornirea programată; nu șterge programul.

Tratați directoarele de stare cu aceeași grijă. Tokenurile de cont, profilurile generate și listele de servere din cache trăiesc sub /var/lib sau într-un director home, iar acestea sunt acreditări, nu cache de aruncat. Eliminați-le după ce serviciul este oprit, în mod deliberat, și notați ce ați luat.

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

Alegeți un singur proprietar al pornirii și testați-l

Trei candidați pot revendica pornirea, iar instalarea tuturor trei produce o cursă în loc de siguranță dublă. Un fișier de pornire automată de desktop rulează doar după ce cineva se conectează, un unit systemd rulează mai devreme dar are nevoie de un client care funcționează fără ecran, iar o intrare cron @reboot se declanșează după un program care poate fi greșit pentru un client de rețea. CLI-ul furnizorului poate cere în plus un argument de server, fiindcă la pornire nu există o sesiune anterioară de reluat. Alegeți candidatul care se potrivește cu modul în care clientul se autentifică și renunțați la ceilalți.

Testați-l repornind mașina și privind trei fapte independente: starea unit-ului, lista proceselor și o conexiune nouă către ceva ce puteți verifica. Un client care cere un inel de chei sau o autentificare interactivă eșuează la pornire chiar și cu un fișier unit corect, iar journalul spune asta dacă îl citiți în loc de doar starea serviciului.

Fie dați clientului o acreditare care funcționează fără întrebare, fie porniți-l la autentificare. Ambele sunt de apărat, iar combinarea lor este felul în care un tunel ajunge cu doi proprietari care se ceartă pe el.

Notați la ce ar trebui să se aștepte următorul purge

Notați două fapte după orice eliminare manuală: ce instalator a creat aranjamentul și ce proprietar îl pornește acum. Acea notă transformă următorul purge dintr-o surpriză într-un punct de listă de verificare și supraviețuiește persoanei care a făcut treaba.

Păstrați-o lângă configurația serviciului și nu într-un director personal, și datați-o, fiindcă o actualizare a furnizorului poate restaura un unit pe care l-ați șters. Compararea systemctl list-unit-files cu acea notă la câteva luni prinde restaurarea cât timp corectarea este încă ieftină.