Error al eliminar el paquete VPN en prerm: qué comprobar primero

Las desinstalaciones pueden detenerse a medio camino con un error que nombra un script de mantenimiento, dejando la VPN medio eliminada: los archivos de configuración permanecen, el servicio puede seguir ejecutándose, y el gestor de paquetes se niega a continuar. La solución tentadora de un hilo antiguo del foro es borrar el script y forzar la eliminación. Eso trata el síntoma y descarta el paso de limpieza que falló. Lea primero la etapa y el estado del paquete.

Qué paso del ciclo de vida falló realmente

Los paquetes Debian ejecutan preinst y postinst en la instalación, y prerm y postrm en la eliminación o la purga, y el estado de salida de cada script determina la acción siguiente. Un error de prerm significa que la eliminación se detuvo antes de borrar los archivos del paquete; un error de postrm significa que la eliminación ya ocurrió y que la limpieza falló. Son situaciones distintas con recuperaciones distintas. La política de la distribución también espera que los scripts toleren una ejecución repetida, porque una etapa fallida debe reintentarse en lugar de evitarse.

Anote el primer error textualmente, junto con el nombre del paquete, la versión y la versión de la distribución. Los errores posteriores suelen ser consecuencias.

Lea el estado del paquete antes de cambiarlo

Pregunte al gestor de paquetes qué cree que ha ocurrido antes de emitir otro comando.

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

El listado muestra los indicadores de estado del paquete, la auditoría encuentra paquetes dejados rotos o a medio configurar, y la eliminación simulada imprime lo que haría apt sin tocar nada. Una simulación que falla en el mismo script confirma la etapa, no la red. Anote el script nombrado en el error y liste los archivos de información del paquete si necesita ver qué scripts existen. Nada de eso justifica todavía editar esos archivos.

Proteja la vía de gestión antes de la reparación

Si la VPN transporta su única sesión SSH hacia este host, eliminarla termina su acceso en medio de la reparación. Disponga primero de una consola, una interfaz de gestión fuera de banda o una segunda ruta, y confirme que funciona antes de empezar. Conserve el perfil y cualquier instrucción de reinscripción que necesitará después, porque una purga puede eliminar configuración generada. Mantenga las credenciales fuera de las notas que pega en un ticket, y mantenga las claves privadas completamente fuera del diagnóstico.

Trate una anulación manual documentada como último recurso bajo la guía del propietario del paquete, con los pasos omitidos contabilizados. Nunca borre scripts con comodines, porque la propia lista de limpieza del paquete es el registro de lo que aún queda por hacer.

Separe los resultados de paquete, red y credenciales

Hay que comprobar tres resultados de forma independiente cuando termine el procedimiento admitido. La transacción del paquete debe mostrar un estado limpio, sin entradas a medio configurar en la auditoría. La red debe coincidir con lo que pretendía: el servicio correcto detenido, sin rutas ni ajustes de DNS obsoletos, y una vía funcional para la sustitución o el acceso directo. El lado remoto es el tercer resultado, y las credenciales obsoletas deben retirarse a través del propietario de esa cuenta, porque desinstalar un cliente no revoca nada.

Después vuelva a conectarse y pruebe un destino permitido. Un estado de paquete limpio con un túnel que sigue ejecutándose es un resultado distinto de una red limpia, y solo el segundo le dice que la eliminación surtió efecto de verdad.