apt purge eliminou a VPN, pero o servizo aínda arrinca no inicio

apt purge di que o paquete xa non está e, con todo, un túnel volve aparecer en cada arrinque. O journal segue medrando, as rutas regresan e a máquina compórtase como se non se eliminase nada. O instalador do provedor pode escribir ficheiros que o xestor de paquetes nunca rexistrou, así que desinstalar un paquete e desinstalar un produto son tarefas distintas. O runbook seguinte separa os dous rexistros e remata a eliminación a propósito.

Dous instaladores, dous rexistros distintos

Os paquetes Debian manteñen unha lista de ficheiros, e unha purge borra exactamente o que esa lista nomea máis a configuración do paquete. Un instalador de shell ou un paquete .run non mantén esa lista; escribe onde quere, normalmente en /opt, /usr/local e /etc/systemd/system. Ningunha desas rutas aparece na lista de ficheiros de ningún paquete, polo que dpkg nin as coñece nin as informa. Acaba con dous propietarios da instalación nun só sistema de ficheiros e só un deles leva a contabilidade.

Pregunte a dpkg pola ruta concreta antes de borrala. Unha ruta que rexeita é súa para eliminar, e a mesma resposta dille se unha actualización posterior a devolvería.

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

Unha unidade e a súa ligazón wants son ficheiros separados

Habilitar é un acto distinto de instalar. A unidade declara relacións de destino na súa sección [Install], e systemctl enable converte esas declaracións en ligazóns simbólicas dentro do directorio .wants/ de cada destino. Agora existen dúas rutas: o ficheiro da unidade e a ligazón que a arrastra a un destino de arrinque. Borre só o ficheiro e a ligazón apunta á nada, o que produce unha queixa ao arrincar; borre só a ligazón e a unidade segue sendo arrincable polo nome. Ambos deben desaparecer.

Elimíneos en orde e recargue despois, para que systemd deixe de reter as definicións antigas na memoria.

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

Lea FragmentPath en lugar de supoñer a localización, xa que o provedor pode ter escrito en /usr/lib/systemd/system ou /lib/systemd/system en vez de /etc. Borrar a copia que esperaba deixa a efectiva en execución, e a corrección parece exitosa ata a seguinte recarga. Volva listar os ficheiros de unidade cando remate a recarga e confirme que o nome xa non aparece.

Atope o binario que mantén viva a disposición

Unha unidade habilitada segue arrincando o daemon crea o que crea a base de datos de paquetes. Ese proceso pode volver levantar o túnel, engadir rutas outra vez ou restaurar unha regra de kill-switch, e o comportamento parece sobrenatural ata que inspecciona a disposición. Siga a ruta de ExecStart e comprobe se o binario segue aí, porque un executábel deixado baixo /opt é todo o que a disposición necesita. Borrar a unidade detén o arrinque programado; non borra o programa.

Trate os directorios de estado co mesmo coidado. Os tokens de conta, os perfís xerados e as listas de servidores na caché viven baixo /var/lib ou nun directorio persoal, e son credenciais, non caché desbotábel. Elimíneos unha vez detido o servizo, deliberadamente, e anote o que levou.

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

Escolla un único propietario do inicio e probeo

Tres candidatos poden reclamar o inicio, e instalar os tres produce unha carreira en lugar dunha dobre seguridade. Un ficheiro de inicio automático de escritorio só se executa despois de que alguén inicie sesión, unha unidade systemd execútase antes pero necesita un cliente que funcione sen pantalla, e unha entrada cron @reboot dispara segundo un horario que pode ser incorrecto para un cliente de rede. A CLI do provedor pode ademais esixir un argumento de servidor, porque ao arrincar non hai sesión previa que retomar. Escolla o candidato que encaixa con como se autentica o cliente e descarte os demais.

Próbeo reiniciando a máquina e mirando tres feitos independentes: o estado da unidade, a lista de procesos e unha conexión nova a algo que poida verificar. Un cliente que necesita un chaveiro ou un inicio de sesión interactivo falla ao arrincar mesmo cun ficheiro de unidade correcto, e o journal dío se o le en lugar de só o estado do servizo.

Ou ben dea ao cliente unha credencial que funcione sen pregunta, ou ben arrínqueo ao iniciar sesión. Ambas son defendibles, e combinalas é como un túnel acaba con dous propietarios que pelexan por el.

Anote que debe esperar a próxima purge

Anote dous feitos tras calquera eliminación manual: que instalador creou a disposición e que propietario a arrinca agora. Esa nota converte a próxima purge de sorpresa nun punto dunha lista de comprobación, e sobrevive á persoa que fixo o traballo.

Gárdea xunto á configuración do servizo e non nun directorio persoal, e póñalle data, porque unha actualización do provedor pode restaurar unha unidade que borrou. Comparar systemctl list-unit-files con esa nota cada poucos meses detecta a restauración mentres aínda é barata de corrixir.