Skip to main content

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é

  1. 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.

  2. 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.

  3. 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.

  4. 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.

  5. 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.

  6. 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.

Back to top