Eliminación completa de Snap en Ubuntu Server

Introducción
Este artículo documenta el proceso de eliminación completa de Snap en Ubuntu Server, incluyendo la desinstalación de 
snapd, la limpieza de restos del sistema y el bloqueo explícito de su reinstalación mediante APT. Esta decisión afecta directamente a la capa base del sistema y al metapaquete 
ubuntu-server-minimal, por lo que se describe desde un punto de vista consciente y deliberado dentro del stack.
Snap se elimina en favor de un sistema más predecible, trazable y alineado con flujos clásicos de administración basados en APT y configuraciones versionadas.
Enfoque general
La eliminación se realiza en tres fases claras:
Retirada ordenada de snaps activos.
Desactivación del socket y servicio de 
snapd antes de purgarlo.
Limpieza manual de directorios persistentes y bloqueo de futuras reinstalaciones.
Este enfoque evita estados intermedios inconsistentes y reduce residuos en systemd, AppArmor y el filesystem.
Desarrollo
Comandos ejecutados
Los siguientes comandos reflejan la secuencia real aplicada en el sistema. Se muestran únicamente como referencia operativa del proceso descrito, no como guía paso a paso.
sudo snap list
sudo snap remove canonical-livepatch
sudo snap remove core22
sudo snap remove snapd
sudo systemctl stop snapd.socket
sudo systemctl disable --now snapd.service snapd.socket
sudo apt purge snapd -y
sudo rm -rf /snap
sudo rm -rf /var/snap
sudo rm -rf /var/lib/snapd
sudo rm -rf /var/cache/snapd
sudo tee /etc/apt/preferences.d/nosnap.pref > /dev/null <<EOF
Package: snapd
Pin: release a=*
Pin-Priority: -10
EOF
Qué se hizo y por qué
Inventario inicial de snaps
Se parte de un sistema con únicamente los snaps base de Ubuntu Server (
canonical-livepatch, 
core22, 
snapd). No existen aplicaciones de usuario dependientes de Snap, lo que permite una eliminación limpia sin impacto funcional.
Eliminación explícita de snaps instalados
Los snaps se eliminan en orden, comenzando por 
canonical-livepatch, seguido del runtime (
core22) y finalmente 
snapd. Esto evita dependencias colgantes y mensajes de error innecesarios.
Desactivación de servicios y sockets
Antes de purgar el paquete, se detienen y deshabilitan 
snapd.service y 
snapd.socket. Esto impide que systemd reactive el demonio durante el proceso de limpieza.
Purgado completo vía APT
Se purga 
snapd, lo que arrastra también 
ubuntu-server-minimal. Este metapaquete no contiene funcionalidad crítica en tiempo de ejecución; su eliminación no rompe el sistema, pero sí elimina la garantía de "perfil oficial" de Ubuntu Server, algo asumido conscientemente.
Limpieza manual de restos
Se eliminan directorios persistentes que no siempre desaparecen con el purgado:
/snap
/var/snap
/var/lib/snapd
/var/cache/snapd
Esto asegura que no queden estados residuales, namespaces ni reglas de AppArmor huérfanas.
Bloqueo de reinstalación de snapd
Se añade una preferencia de APT con prioridad negativa para evitar que 
snapd vuelva a instalarse como dependencia indirecta en futuras operaciones.
Validación
El comando 
snap deja de existir en el sistema.
systemctl status snapd confirma que el servicio no está presente.
No quedan sockets, mounts ni unidades relacionadas con Snap.
El sistema continúa funcionando con normalidad bajo gestión exclusiva de APT.
Consideraciones sobre Snap en entornos servidor
Snap no está diseñado pensando en servidores tradicionales, donde la previsibilidad, el control del ciclo de vida del software y la trazabilidad operativa son prioritarios. En este contexto, introduce varios inconvenientes relevantes:
Actualizaciones automáticas no controlables: Snap aplica actualizaciones de forma autónoma, fuera de ventanas de mantenimiento y sin integrarse en flujos de despliegue, testing o rollback.
Modelo de ejecución opaco: el uso de imágenes squashfs, montajes dinámicos, namespaces y perfiles AppArmor generados automáticamente dificulta la auditoría, el debugging y el hardening del sistema.
Activación implícita mediante systemd: el uso de 
snapd.socket puede reactivar servicios de forma indirecta, introduciendo comportamientos poco explícitos para entornos donde se prioriza la mínima sorpresa.
Consumo adicional innecesario: la duplicación de runtimes y los montajes adicionales suponen un sobrecoste de disco y memoria, especialmente poco justificado en VPS o sistemas con recursos limitados.
Dependencia de infraestructura externa: la Snap Store centralizada complica su uso en entornos aislados, regulados o con mirrors internos controlados.
En entornos servidor, Snap introduce más complejidad operativa de la que resuelve, sin aportar ventajas claras frente a modelos basados en APT y gestión explícita de versiones.
Decisiones importantes
La eliminación de 
ubuntu-server-minimal es intencional y aceptada. No implica pérdida de servicios, pero sí desvinculación del perfil base de Canonical.
A partir de este punto, cualquier software previamente empaquetado como snap debe instalarse vía APT, backports o binarios externos gestionados manualmente.
Resumen breve
Snap y 
snapd se eliminan completamente de Ubuntu Server mediante una secuencia controlada: retirada de snaps, desactivación de servicios, purgado del paquete, limpieza manual y bloqueo de reinstalación. El sistema resultante es más simple, predecible y alineado con flujos clásicos de administración.