Rimozione del pacchetto VPN non riuscita in prerm: cosa controllare per primo

Le disinstallazioni possono fermarsi a metà con un errore che nomina uno script di manutenzione, lasciando la VPN mezzo rimossa: i file di configurazione restano, il servizio potrebbe essere ancora in esecuzione, e il gestore dei pacchetti rifiuta di continuare. La soluzione tentante in un vecchio thread del forum è cancellare lo script e forzare la rimozione. Questo tratta il sintomo e scarta il passo di pulizia che ha fallito. Leggi prima la fase e lo stato del pacchetto.

Quale passo del ciclo di vita ha fallito davvero

I pacchetti Debian eseguono preinst e postinst all’installazione, e prerm e postrm alla rimozione o alla purga, e lo stato di uscita di ogni script determina l’azione successiva. Un errore da prerm significa che la rimozione si è fermata prima che i file del pacchetto venissero cancellati; un errore da postrm significa che la rimozione era già avvenuta e che la pulizia ha fallito. Sono situazioni diverse con ripristini diversi. La politica della distribuzione si aspetta anche che gli script tollerino un’esecuzione ripetuta, perché una fase fallita va ripetuta invece che evitata.

Annota il primo errore testualmente, insieme al nome del pacchetto, alla versione e alla release della distribuzione. Gli errori successivi sono di solito conseguenze.

Leggi lo stato del pacchetto prima di cambiarlo

Chiedi al gestore dei pacchetti cosa pensa sia successo prima di impartire un altro comando.

dpkg -l vpn-package
dpkg --audit
apt-get -s remove vpn-package

L’elenco mostra i flag di stato del pacchetto, l’audit trova pacchetti lasciati rotti o mezzi configurati, e la rimozione simulata stampa ciò che apt farebbe senza toccare nulla. Una simulazione che fallisce sullo stesso script conferma la fase, non la rete. Annota lo script nominato nell’errore ed elenca i file informativi del pacchetto se devi vedere quali script esistono. Nulla di tutto ciò giustifica ancora la modifica di quei file.

Proteggi il percorso di gestione prima della riparazione

Se la VPN trasporta la tua unica sessione SSH verso questo host, rimuoverla termina il tuo accesso a metà della riparazione. Predisponi prima una console, un’interfaccia di gestione fuori banda o una seconda rotta, e conferma che funzioni prima di iniziare. Conserva il profilo e eventuali istruzioni di nuova registrazione che ti serviranno dopo, perché una purga può eliminare configurazione generata. Tieni le credenziali fuori dalle note che incolli in un ticket, e tieni le chiavi private completamente fuori dalla diagnostica.

Tratta un override manuale documentato come ultima risorsa sotto la guida del proprietario del pacchetto, con i passi saltati conteggiati. Non cancellare mai script con wildcard, perché la lista di pulizia del pacchetto stesso è il registro di ciò che resta da fare.

Separa gli esiti di pacchetto, rete e credenziali

Tre esiti vanno controllati in modo indipendente quando la procedura supportata termina. La transazione del pacchetto dovrebbe mostrare uno stato pulito, senza voci mezze configurate rimaste nell’audit. La rete dovrebbe corrispondere a ciò che intendevi: il servizio giusto fermato, nessuna rotta o impostazione DNS obsoleta, e un percorso funzionante per la sostituzione o l’accesso diretto. Il lato remoto è il terzo esito, e le credenziali obsolete vanno ritirate tramite il proprietario di quell’account, perché disinstallare un client non revoca nulla.

Poi riconnettiti e prova una destinazione consentita. Uno stato del pacchetto pulito con un tunnel ancora in esecuzione è un esito diverso da una rete pulita, e solo il secondo ti dice che la rimozione ha davvero avuto effetto.