Falha na remoção do pacote VPN no prerm: o que verificar primeiro

As desinstalações podem parar a meio com um erro que nomeia um script de manutenção, deixando a VPN meio removida: os ficheiros de configuração permanecem, o serviço pode ainda estar a correr, e o gestor de pacotes recusa continuar. A correção tentadora num tópico antigo de fórum é apagar o script e forçar a remoção. Isso trata o sintoma e descarta o passo de limpeza que falhou. Leia primeiro a etapa e o estado do pacote.

Que passo do ciclo de vida falhou realmente

Os pacotes Debian executam preinst e postinst na instalação, e prerm e postrm na remoção ou na purga, com o estado de saída de cada script a determinar a ação seguinte. Um erro de prerm significa que a remoção parou antes de os ficheiros do pacote serem apagados; um erro de postrm significa que a remoção já ocorreu e que a limpeza falhou. São situações diferentes com recuperações diferentes. A política da distribuição também espera que os scripts tolerem uma execução repetida, porque uma etapa falhada deve ser repetida em vez de evitada.

Registe o primeiro erro textualmente, junto com o nome do pacote, a versão e a versão da distribuição. Os erros seguintes são normalmente consequências.

Leia o estado do pacote antes de o alterar

Pergunte ao gestor de pacotes o que pensa que aconteceu antes de emitir outro comando.

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

A listagem mostra os indicadores de estado do pacote, a auditoria encontra pacotes deixados quebrados ou meio configurados, e a remoção simulada imprime o que o apt faria sem tocar em nada. Uma simulação que falha no mesmo script confirma a etapa, não a rede. Anote o script nomeado no erro e liste os ficheiros de informação do pacote se precisar de ver que scripts existem. Nada disso justifica ainda editar esses ficheiros.

Proteja o caminho de gestão antes da reparação

Se a VPN transporta a sua única sessão SSH para este anfitrião, removê-la termina o seu acesso a meio da reparação. Disponibilize primeiro uma consola, uma interface de gestão fora de banda ou uma segunda rota, e confirme que funciona antes de começar. Guarde o perfil e quaisquer instruções de novo registo de que precisará depois, porque uma purga pode remover configuração gerada. Mantenha as credenciais fora das notas que cola num ticket, e mantenha as chaves privadas completamente fora do diagnóstico.

Trate uma substituição manual documentada como último recurso sob a orientação do proprietário do pacote, com os passos omitidos contabilizados. Nunca apague scripts com wildcards, porque a própria lista de limpeza do pacote é o registo do que ainda falta fazer.

Separe os resultados de pacote, rede e credenciais

Três resultados precisam de ser verificados de forma independente quando o procedimento suportado termina. A transação do pacote deve mostrar um estado limpo, sem entradas meio configuradas na auditoria. A rede deve corresponder ao que pretendia: o serviço certo parado, sem rotas ou definições de DNS obsoletas, e um caminho funcional para substituição ou acesso direto. O lado remoto é o terceiro resultado, e as credenciais obsoletas devem ser retiradas através do proprietário dessa conta, porque desinstalar um cliente não revoga nada.

Depois volte a ligar e teste um destino permitido. Um estado de pacote limpo com um túnel ainda em execução é um resultado diferente de uma rede limpa, e só o segundo lhe diz que a remoção produziu realmente efeito.