apt purge ha eliminat la VPN, però el servei encara arrenca en iniciar

apt purge diu que el paquet ha desaparegut, i tot i això un túnel torna a aixecar-se a cada arrencada. El journal continua creixent, les rutes tornen, i la màquina es comporta com si no shagués eliminat res. Linstal·lador del proveïdor pot escriure fitxers que el gestor de paquets mai no va enregistrar, per tant desinstal·lar un paquet i desinstal·lar un producte són feines diferents. El runbook següent separa els dos registres i acaba leliminació a propòsit.

Dos instal·ladors, dos registres diferents

Els paquets Debian mantenen una llista de fitxers, i una purge esborra exactament el que aquesta llista anomena més la configuració del paquet. Un instal·lador de shell o un paquet .run no manté cap llista així; escriu on vol, normalment a /opt, /usr/local i /etc/systemd/system. Cap daquests camins no apareix a la llista de fitxers de cap paquet, així que dpkg ni en sap res ni els informa. Acabeu amb dos propietaris de la instal·lació en un sol sistema de fitxers i només un dells porta els comptes.

Pregunteu a dpkg pel camí concret abans desborrar-lo. Un camí que rebutja és vostre per eliminar, i la mateixa resposta us diu si una actualització posterior el tornaria a posar.

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

La unitat i el seu enllaç wants són fitxers separats

Habilitar és un acte separat dinstal·lar. La unitat declara les relacions dobjactiu a la seva secció [Install], i systemctl enable converteix aquestes declaracions en enllaços simbòlics dins del directori .wants/ de cada objectiu. Ara hi ha dos camins: el fitxer de la unitat i lenllaç que larrossega cap a un objectiu darncada. Esborreu només el fitxer i lenllaç no apunta enlloc, cosa que produeix una queixa a larncada; esborreu només lenllaç i la unitat continua essent arrencable pel nom. Han de desaparèixer tots dos.

Elimineu-los en ordre i recarregueu després, perquè systemd deixi de retenir les definicions antigues a la memòria.

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

Llegiu FragmentPath en lloc de suposar la ubicació, ja que el proveïdor pot haver escrit a /usr/lib/systemd/system o /lib/systemd/system en comptes de /etc. Esborrar la còpia que esperàveu deixa lefectiva en funcionament, i la correcció sembla reeixida fins a la propera recàrrega. Torneu a llistar els fitxers de la unitat quan acabi la recàrrega i confirmeu que el nom ja no hi apareix.

Trobeu el binari que manté viu el muntatge

Una unitat habilitada continua iniciant el dimoni faci el que faci la base de dades de paquets. Aquest procés pot tornar a aixecar el túnel, tornar a afegir rutes o restaurar una regla de kill-switch, i el comportament sembla sobrenatural fins que no inspeccioneu la disposició. Seguiu el camí de ExecStart i comproveu si el binari encara hi és, perquè un executable deixat sota /opt és tot el que el muntatge necessita. Esborrar la unitat atura linici programat; no esborra el programa.

Tracteu els directoris destat amb la mateixa cura. Els testimonis de compte, els perfils generats i les llistes de servidors a la memòria cau viuen sota /var/lib o en un directori personal, i són credencials, no memòria cau per llençar. Elimineu-los un cop aturat el servei, deliberadament, i anoteu què us heu endut.

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

Trieu un sol propietari de larncada i proveu-lo

Tres candidats poden reclamar larncada, i instal·lar-los tots tres produeix una cursa en lloc duna doble seguretat. Un fitxer dinici automàtic descriptorpi només sexecuta després que algú iniciï sessió, una unitat systemd sexecuta abans però necessita un client que funcioni sense pantalla, i una entrada cron @reboot sactiva segons un horari que pot ser incorrecte per a un client de xarxa. La CLI del proveïdor pot requerir a més un argument de servidor, perquè a larncada no hi ha cap sessió prèvia per reprendre. Trieu el candidat que encaixi amb la manera com sautentica el client i descarteu els altres.

Proveu-ho reiniciant la màquina i mirant tres fets independents: lestat de la unitat, la llista de processos i una connexió nova a una cosa que pugueu verificar. Un client que necessita un clauer o un inici de sessió interactiu falla a larncada fins i tot amb un fitxer de unitat correcte, i el journal ho diu si el llegiu en lloc de només lestat del servei.

O bé doneu al client una credencial que funcioni sense cap sol·licitud, o bé inicieu-lo a linici de sessió. Tots dos són defensables, i combinar-los és com un túnel acaba amb dos propietaris que es barallen per ell.

Anoteu què ha desperar la propera purge

Anoteu dos fets després de qualsevol eliminació manual: quin instal·lador va crear el muntatge i quin propietari linicia ara. Aquesta nota converteix la propera purge duna sorpresa en un punt duna llista de comprovació, i sobreviu a la persona que va fer la feina.

Guardeu-la al costat de la configuració del servei i no en un directori personal, i dateu-la, perquè una actualització del proveïdor pot restaurar una unitat que heu esborrat. Comparar systemctl list-unit-files amb aquesta nota cada pocs mesos detecta la restauració mentre encara és barata de corregir.