apt purge ha rimosso la VPN, ma il servizio parte ancora all'avvio

apt purge dichiara che il pacchetto non c'è più, eppure un tunnel risale a ogni avvio. Il journal continua a crescere, le rotte tornano, e la macchina si comporta come se nulla fosse stato rimosso. L'installer del fornitore può scrivere file che il gestore dei pacchetti non ha mai registrato, quindi disinstallare un pacchetto e disinstallare un prodotto sono due lavori diversi. Il runbook qui sotto separa i due registri e completa la rimozione di proposito.

Due installer, due registri diversi

I pacchetti Debian tengono un elenco di file, e una purge cancella esattamente ciò che quell'elenco nomina più la configurazione del pacchetto. Un installer shell o un pacchetto .run non tiene un elenco del genere; scrive dove vuole, di solito in /opt, /usr/local e /etc/systemd/system. Nessuno di questi percorsi compare nell'elenco dei file di alcun pacchetto, quindi dpkg non li conosce né li segnala. Si finisce con due proprietari dell'installazione su un solo filesystem, e solo uno dei due tiene i conti.

Chiedete a dpkg del percorso specifico prima di cancellarlo. Un percorso che rifiuta è vostro da rimuovere, e la stessa risposta vi dice se un aggiornamento successivo lo rimetterebbe.

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

Un'unità e il suo collegamento wants sono file separati

Abilitare è un atto separato dall'installare. L'unità dichiara le relazioni di target nella sua sezione [Install], e systemctl enable trasforma quelle dichiarazioni in collegamenti simbolici nella directory .wants/ di ogni target. Ora esistono due percorsi: il file dell'unità e il collegamento che la trascina in un target di avvio. Cancellate solo il file e il collegamento non punta a nulla, il che produce una lamentela all'avvio; cancellate solo il collegamento e l'unità resta avviabile per nome. Devono andarsene entrambi.

Rimuoveteli in ordine e ricaricate dopo, così systemd smette di tenere le vecchie definizioni in 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

Leggete FragmentPath invece di supporre la posizione, perché il fornitore potrebbe aver scritto in /usr/lib/systemd/system o /lib/systemd/system anziché in /etc. Cancellare la copia che vi aspettavate lascia in funzione quella effettiva, e la correzione sembra riuscita fino al ricaricamento successivo. Elencate di nuovo i file delle unità quando il ricaricamento è finito, e confermate che il nome non compare più.

Trovate il binario che tiene in vita la sistemazione

Un'unità abilitata continua ad avviare il demone qualunque cosa creda il database dei pacchetti. Quel processo può far risalire il tunnel, riaggiungere rotte o ripristinare una regola di kill-switch, e il comportamento sembra soprannaturale finché non ispezionate la sistemazione. Seguite il percorso di ExecStart e controllate se il binario è ancora lì, perché un eseguibile lasciato sotto /opt è tutto ciò che serve alla sistemazione. Cancellare l'unità ferma l'avvio pianificato; non cancella il programma.

Trattate le directory di stato con la stessa cura. I token dell'account, i profili generati e gli elenchi di server in cache vivono sotto /var/lib o in una directory home, e sono credenziali, non cache da buttare. Rimuoveteli una volta fermo il servizio, deliberatamente, e annotate cosa avete preso.

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

Scegliete un solo proprietario dell'avvio e provatelo

Tre candidati possono reclamare l'avvio, e installarli tutti e tre produce una corsa invece di una doppia sicurezza. Un file di autostart del desktop viene eseguito solo dopo che qualcuno accede, un'unità systemd parte prima ma richiede un client che funzioni senza schermo, e una voce cron @reboot scatta secondo una pianificazione che può essere sbagliata per un client di rete. La CLI del fornitore può inoltre richiedere un argomento server, perché all'avvio non c'è una sessione precedente da riprendere. Scegliete il candidato che corrisponde a come il client si autentica, e scartate gli altri.

Provatelo riavviando la macchina e guardando tre fatti indipendenti: lo stato dell'unità, l'elenco dei processi e una nuova connessione a qualcosa che potete verificare. Un client che richiede un portachiavi o un accesso interattivo fallisce all'avvio anche con un file di unità corretto, e il journal lo dice se lo leggete invece di guardare solo lo stato del servizio.

O date al client una credenziale che funzioni senza richiesta, oppure avviatelo all'accesso. Entrambe sono difendibili, e combinarle è il modo in cui un tunnel si ritrova due proprietari che litigano per lui.

Annotate cosa deve aspettarsi la prossima purge

Annotate due fatti dopo qualsiasi rimozione manuale: quale installer ha creato la sistemazione, e quale proprietario la avvia ora. Quella nota trasforma la prossima purge da sorpresa a voce di una lista di controllo, e sopravvive alla persona che ha fatto il lavoro.

Conservatela accanto alla configurazione del servizio e non in una directory personale, e datatela, perché un aggiornamento del fornitore può ripristinare un'unità che avete cancellato. Confrontare systemctl list-unit-files con quella nota ogni pochi mesi intercetta il ripristino mentre la correzione è ancora economica.