Las 2 AM más largas de tu vida
Todo administrador de sistemas tiene una historia parecida. Es viernes, o peor, es fin de mes. Lanzas un apt upgrade o un dnf update de rutina antes de irte a dormir, confiando en que al día siguiente todo seguirá funcionando igual. A las 2:14 de la madrugada salta la alerta: el servicio no arranca. Una librería se ha actualizado a una versión incompatible con tu aplicación, un demonio no levanta porque su configuración ya no encaja con el nuevo paquete, o directamente el propio gestor de paquetes se ha quedado a medias, dejando el sistema en un estado que no es ni el viejo ni el nuevo.
Empieza entonces el ritual conocido por cualquiera que lleve unos años en esto: revisar logs, comparar versiones de paquetes, intentar un apt install -f, buscar el commit exacto que rompió algo, y en el peor de los casos, restaurar desde una copia de seguridad que —con suerte— es de esa misma noche. Todo mientras el reloj corre y el negocio depende de que ese servidor vuelva a estar en pie.
¿Por qué ocurre esto? Porque el modelo de gestión de paquetes que ha dominado Linux durante más de dos décadas —el de Debian/Ubuntu con APT y dpkg, o el de RHEL/Fedora con DNF y RPM— es fundamentalmente imperativo y mutable. Cada install, upgrade o remove es una operación que modifica el sistema de archivos pieza por pieza, paquete por paquete, script de instalación tras script de instalación. El estado final de tu sistema depende del orden exacto en que se han aplicado años de comandos, muchos de ellos ejecutados a mano, a las tantas, bajo presión. Es, en esencia, una larga cadena de mutaciones sin un punto de control fiable al que volver.
Durante años hemos aceptado esto como el precio de tener un sistema flexible. Pero desde hace tiempo existe una corriente, cada vez más consolidada, que propone invertir el planteamiento: en lugar de mutar el sistema poco a poco y rezar para que todo siga encajando, ¿por qué no tratar el sistema operativo como una unidad atómica e inmutable, igual que ya hacemos con las imágenes de contenedores o con el firmware de un smartphone?
Esa es la idea que vamos a desmenuzar en esta primera entrega: qué significa realmente que un Linux sea «inmutable», cómo se organiza por dentro, y por qué el rollback —la capacidad de deshacer una actualización mala con un simple reinicio— cambia por completo la ecuación del riesgo operativo. En la segunda parte veremos cómo cambia el día a día real: cómo se instala software, cómo se despliegan servicios y cuándo merece (o no) la pena dar el salto.
¿Qué significa «inmutable» en un sistema operativo?
La palabra «inmutable» suena tajante, casi contradictoria aplicada a un sistema operativo que, evidentemente, necesita actualizarse. Conviene aclarar desde ya un matiz importante: ningún sistema Linux de propósito general es 100% inmutable. Lo que se vuelve de solo lectura es la parte del sistema que define su comportamiento base —el sistema operativo en sí—, mientras que los datos de usuario y la configuración local siguen siendo perfectamente editables. Es una inmutabilidad selectiva y arquitectónica, no una losa de cemento.
Dicho esto, el núcleo de la idea es sencillo:
El sistema operativo base (binarios, librerías, la propia estructura de
/usr) se distribuye y se actualiza como una imagen completa y versionada, no como un conjunto de paquetes independientes que se instalan por separado.
Esto tiene una consecuencia directa: ya no puedes «tocar» el sistema base con comandos sueltos tipo apt install libfoo. En su lugar, cada cambio genera una nueva versión completa del sistema, que convive con la anterior hasta que decides (o no) hacerla permanente.
Dos analogías que lo hacen evidente
1. Actualizaciones al estilo smartphone.
Cuando tu teléfono Android o iPhone se actualiza, no reemplaza archivo por archivo el sistema operativo mientras lo usas. Descarga la nueva versión completa, la deja preparada en un espacio separado, y en el siguiente reinicio arranca directamente con ella. Si algo sale mal —cosa rarísima, precisamente por este diseño—, el propio sistema puede volver atrás. Nadie se plantea hacer un apt upgrade manual en un iPhone paquete a paquete; simplemente hay una versión de sistema instalada, y otra lista para sustituirla. Los Linux inmutables trasladan exactamente ese modelo al servidor y al escritorio.
2. El sistema operativo como un repositorio Git.
Otra forma de verlo, quizá más cercana para un sysadmin: imagina que el sistema operativo tiene su propio historial de «commits». Cada actualización es un commit nuevo sobre el árbol de archivos de /usr. El comando rpm-ostree status, por ejemplo, te enseña literalmente un historial de «despliegues» (deployments), cada uno con su hash, muy parecido a un git log. ¿La actualización de hoy rompió algo? Haces lo equivalente a un git checkout al commit anterior —en este caso, rpm-ostree rollback— y reinicias. El sistema vuelve exactamente al estado binario que tenía antes, sin ambigüedades, sin «casi» y sin scripts de desinstalación que dejan restos.
Esta analogía con Git no es casual: la tecnología que hace esto posible en el ecosistema Fedora/RHEL, llamada libostree (u OSTree), fue descrita por su propio creador, Colin Walters, como «git para binarios del sistema operativo«. OSTree versiona árboles de archivos completos usando técnicas de hashing e hipervínculos (hardlinks) muy similares a las de Git, permitiendo almacenar múltiples versiones del sistema en el mismo disco de forma eficiente, sin duplicar cada archivo que no ha cambiado.
Inmutable vs. Atómico: no son sinónimos
En el mismo saco suelen mezclarse dos propiedades que conviene distinguir porque no son lo mismo:
- Inmutable describe qué partes del sistema no se pueden modificar directamente en caliente (típicamente
/usr, y a menudo la raíz/completa se monta en modo solo lectura). - Atómico describe cómo se aplican los cambios: como una operación de todo-o-nada. O se aplica la actualización completa, o no se aplica nada; nunca hay un estado intermedio «a medias» tras un corte de luz o un proceso interrumpido.
Un sistema puede ser atómico sin ser estrictamente inmutable —NixOS es el ejemplo más claro, como veremos más abajo—, pero en la práctica los sistemas que suelen recibir la etiqueta «Linux inmutable» combinan ambas propiedades: una base de solo lectura, actualizada mediante transacciones atómicas.
La arquitectura por dentro: cómo conviven /usr, /etc y /var
Aquí es donde el concepto deja de ser abstracto y se convierte en algo que puedes tocar con ls y mount. La clave de todo el diseño está en separar por responsabilidad las distintas carpetas del sistema de archivos, algo que el propio Filesystem Hierarchy Standard (FHS) ya insinuaba pero que estas distribuciones llevan hasta sus últimas consecuencias.
/usr: el sistema operativo en sí, de solo lectura
En un Linux inmutable, /usr deja de ser «una carpeta más» para convertirse en la unidad de despliegue del sistema operativo. Ahí viven los binarios (/usr/bin, que en muchas distribuciones modernas ya es un enlace simbólico que engloba también /bin, /sbin y /usr/sbin), las librerías compartidas, y en el caso de rpm-ostree, incluso la propia base de datos RPM se reubica dentro de /usr/share/rpm para que quede versionada junto con el resto.
/usr se monta en modo solo lectura durante el funcionamiento normal del sistema. Ni tú, ni una aplicación con fallos de seguridad, ni un script mal escrito ejecutado como root puede alterar un binario del sistema en caliente. Si necesitas modificar algo ahí, no editas el archivo: generas un nuevo despliegue completo (una nueva «imagen» del sistema) que sustituirá a la actual en el próximo arranque.
Esto es radicalmente distinto del modelo tradicional, donde apt install paquete escribe directamente sobre /usr/bin, /usr/lib y compañía mientras el sistema sigue funcionando, con el riesgo de que un proceso ya en ejecución esté usando en ese preciso instante el archivo que se está sobrescribiendo.
/etc: configuración local, mutable y fusionada de forma inteligente
/etc sigue siendo editable, como siempre. Aquí es donde tú personalizas tu sistema: la configuración de red, tus reglas de sshd_config, tus unidades de systemd personalizadas. La diferencia interesante es cómo sobrevive /etc a una actualización.
Como la nueva versión del sistema trae también su propio /etc «de fábrica» (el que el paquete original definía por defecto), rpm-ostree hace algo elegante: en cada despliegue nuevo realiza un three-way merge entre la versión antigua de /etc de fábrica, la versión nueva de /etc de fábrica, y tus cambios locales. El resultado es que tus modificaciones se preservan, y a la vez tu sistema recibe los cambios de configuración por defecto que trae la nueva versión, de forma muy similar a como Git resuelve un merge de tres vías entre dos ramas y un ancestro común.
/var: el estado y los datos, siempre persistentes
/var es el tercer pilar, y almacena todo lo que es estado, no definición: logs, bases de datos, colas de correo, contenido servido, cachés. /var nunca se toca en un rollback ni se sustituye en una actualización: es completamente independiente del ciclo de vida de /usr. Esto es justamente lo que hace seguro un rollback: puedes volver el sistema operativo a la versión de ayer sin perder ni un solo registro de tu base de datos de hoy.
El árbol de directorios: tradicional vs. inmutable
El siguiente esquema resume visualmente la diferencia de fondo entre ambos modelos:
MODELO TRADICIONAL (Debian/Ubuntu, RHEL clásico)
══════════════════════════════════════════════════
/
├── /usr ── RW ── modificado paquete a paquete (apt/dnf)
│ ↳ estado = suma de miles de operaciones
│ imperativas, sin un punto de retorno fiable
├── /etc ── RW ── mezclado con archivos de /usr sin separación clara
├── /var ── RW ── datos y logs
└── /boot ── un único kernel activo, sin versión "anterior" lista
Actualización = editar el sistema EN VIVO, paquete a paquete
Rollback = manual, vía snapshots externos (LVM, backups)
Riesgo = alto: estado intermedio posible tras un fallo
MODELO INMUTABLE / ATÓMICO (Silverblue, MicroOS, bootc…)
══════════════════════════════════════════════════════════
/
├── /usr ── RO ── ÁRBOL VERSIONADO (estilo Git/OSTree)
│ │
│ ├── deployment N-1 (versión anterior, intacta)
│ ├── deployment N (versión activa actual) ← /
│ └── deployment N+1 (nueva, preparada, en espera)
│
├── /etc ── RW ── config local, con merge de 3 vías en cada
│ despliegue nuevo
├── /var ── RW ── datos y logs, INDEPENDIENTES de /usr,
│ nunca se tocan en un rollback
└── /boot ── varias entradas de arranque, una por deployment
Actualización = se descarga y prepara UNA imagen nueva completa
Rollback = elegir el deployment anterior en el arrancador,
o `rpm-ostree rollback` + reinicio
Riesgo = bajo: nunca hay estado "a medias"
La diferencia de fondo no es solo técnica, es filosófica: en el modelo tradicional el sistema es la acumulación histórica de todo lo que le has hecho; en el modelo inmutable el sistema es el resultado de aplicar una definición completa, y esa definición es sustituible en bloque.
El salvavidas: el mecanismo de rollback
Si hay una única razón por la que merece la pena entender este modelo, es esta: el rollback deja de ser una operación de emergencia y se convierte en una operación trivial, probada y cotidiana.
En un sistema tradicional, «hacer rollback» de una actualización rota normalmente implica una de estas opciones, todas incómodas:
- Restaurar un snapshot de LVM o Btrfs tomado antes de la actualización (si es que te acordaste de tomarlo).
- Reinstalar paquete a paquete versiones anteriores, si es que siguen disponibles en el repositorio.
- Restaurar desde una copia de seguridad completa, con la consiguiente pérdida de tiempo y, potencialmente, de datos recientes.
En un sistema inmutable basado en OSTree, el flujo es distinto de raíz porque la versión anterior nunca desaparece: sigue en disco, completa, lista para arrancar. El procedimiento típico con rpm-ostree es así de directo:
# Ver el historial de despliegues (como un "git log" del sistema)
$ rpm-ostree status
State: idle
Deployments:
● fedora:fedora/40/x86_64/silverblue
Version: 40.20240521.0 (2024-05-21T10:00:00Z)
fedora:fedora/40/x86_64/silverblue
Version: 40.20240514.0 (2024-05-14T09:00:00Z)
# El despliegue marcado con ● es el activo. El segundo es el anterior,
# intacto, esperando por si lo necesitas.
# Si la actualización de hoy trae problemas, un solo comando:
$ sudo rpm-ostree rollback
# Y confirmas con un reinicio:
$ sudo systemctl rebootTras el reinicio, el sistema arranca exactamente con los mismos binarios, las mismas librerías y la misma configuración de sistema que tenía antes de la actualización problemática. No hay reconstrucción, no hay reinstalación de paquetes, no hay «a ver si esta vez sí». Es determinista: literalmente arrancas un árbol de archivos que ya existía, verificado por su propio hash.
Esto mismo es aplicable, con matices, a cualquier arrancador de estos sistemas: en openSUSE MicroOS y Aeon, transactional-update combina esta misma filosofía con snapshots de Btrfs, de modo que cada actualización crea un snapshot nuevo del sistema de archivos raíz y el gestor de arranque (GRUB con soporte para snapshots) te deja elegir en el menú de arranque qué snapshot iniciar, incluso si el sistema no llega a arrancar con normalidad.
Y en los sistemas basados en bootc (el enfoque que Red Hat está impulsando para RHEL, y que generaliza la idea de «contenedor arrancable»), toda la imagen del sistema operativo se construye, distribuye y versiona igual que una imagen OCI de contenedor —con su registro, sus tags, su historial— y bootc upgrade / bootc rollback funcionan exactamente sobre esa misma lógica de despliegues alternativos.
En los tres casos el mensaje de fondo es idéntico: una actualización rota se soluciona con un reinicio, no con una guardia de madrugada.
Cierre: esto es solo la base
Hasta aquí hemos hablado del sistema operativo en sí: cómo se estructura, cómo se actualiza y cómo se recupera cuando algo sale mal. Es, literalmente, los cimientos del edificio.
Pero en cuanto empiezas a usar un sistema así en serio, surge la pregunta obvia, casi de manera inmediata: si ya no puedo hacer apt install o dnf install libremente sobre el sistema base, ¿cómo diablos instalo mis herramientas de trabajo, mi navegador, mi entorno de desarrollo o los servicios que necesito correr en producción?
Esa pregunta —el cambio de mentalidad y de flujo de trabajo diario— es exactamente de lo que trata la Parte II de esta serie: cómo Flatpak resuelve las aplicaciones de escritorio, cómo Podman se convierte en la forma natural de correr servicios, y cómo herramientas como Distrobox y Toolbx te devuelven, bajo demanda y sin ensuciar el sistema base, esa terminal tradicional que tanto vamos a echar de menos al principio.
Nos vemos en la Parte II.
Índice de la serie
- Parte I (este artículo): inmutabilidad, atomicidad, arquitectura de directorios y rollback.
- Parte II: Flatpak, Podman, Distrobox/Toolbx, casos de uso reales y cuándo NO conviene dar el salto.