Nos complace anunciar Synex 13 Immutable Alpha 1, la primera imagen pública de una nueva edición de Synex construida alrededor de un modelo generacional y transaccional.
A diferencia de las ediciones tradicionales, Synex Immutable no modifica directamente el sistema que se encuentra en ejecución. El root activo permanece read-only y las actualizaciones se preparan sobre una nueva generación Btrfs independiente, que sólo pasa a formar parte del arranque una vez completadas y validadas todas las operaciones.
Este desarrollo comenzó a partir del estudio de la arquitectura de openSUSE MicroOS y de una pregunta concreta: cómo trasladar a Synex las propiedades de un sistema transaccional sin adoptar un modelo basado en imágenes como OSTree y conservando APT, dpkg, GRUB y la estructura habitual del sistema.
El resultado no reproduce el layout ni las herramientas de MicroOS. Sobre sus mismas ideas fundamentales —generaciones, modificaciones fuera del sistema activo, coherencia entre software y package manager y rollback desde el arranque— desarrollamos una implementación propia adaptada a Synex.
Un sistema dividido en generaciones
Synex Immutable utiliza Btrfs como base de la arquitectura.
Cada estado arrancable del sistema se representa mediante una generación:
@immutable-generations/gen-0001
@immutable-generations/gen-0002
@immutable-generations/gen-0003
...Cada una de ellas tiene además un STATE asociado:
@immutable-state/gen-0001
@immutable-state/gen-0002
@immutable-state/gen-0003
...El root de una generación publicada permanece read-only.
STATE, en cambio, contiene aquellas partes administrativas que deben evolucionar junto con ese root pero que necesitan continuar siendo modificables en determinadas etapas, entre ellas /etc, la base de datos de dpkg, el estado de APT, ucf, DKMS, debconf y metadata utilizada por systemd.
De esta manera una generación no está formada solamente por sus binarios.
Conceptualmente:
GENERATION
=
root
+
/etc
+
estado administrativo dpkg/APT
+
kernel/initramfs
+
entrada de boot validadaEl objetivo es que cuando el sistema avanza o vuelve a una generación anterior, el software y la metadata que describe ese software permanezcan siempre coherentes entre sí.
Root read-only, pero sin convertir todo el sistema en read-only
Una de las decisiones centrales fue separar claramente sistema, configuración y datos persistentes.
Durante el funcionamiento normal:
/ -> generación activa RO
/etc -> STATE de la generación RW
/var -> persistente RW
/home -> persistente RW
/root -> persistente RW
/boot/grub -> persistente RW
/tmp -> tmpfs RWEsto permite mantener /etc modificable para el administrador sin convertirlo en un estado global compartido por todas las generaciones.
Al mismo tiempo, determinadas partes de /var que pertenecen al package manager se superponen mediante bind mounts desde el STATE correspondiente y se presentan read-only mientras el sistema está funcionando:
/var/lib/dpkg
/var/lib/apt
/var/lib/ucf
/var/lib/dkms
/var/cache/debconfEl resto de /var continúa siendo persistente.
Esta separación es importante porque un rollback del sistema no debe implicar automáticamente un rollback de documentos, perfiles, logs, bases de datos o estado de aplicaciones.
En Synex Immutable:
rollback del sistema no significa rollback de los datos persistentes.
Las actualizaciones ocurren en otra generación
El flujo transaccional comienza con:
sudo synex-immutable createEl comando toma como origen la generación que se encuentra realmente activa y crea a partir de ella una nueva generación pending.
Por ejemplo:
gen-0001 active
gen-0002 pendingLa nueva generación tiene tanto su root como su STATE en modo read-write, pero no reemplaza ni modifica los mounts del sistema en ejecución.
La generación activa continúa funcionando normalmente.
Las operaciones de paquetes se realizan después mediante:
sudo synex-immutable apt update
sudo synex-immutable apt full-upgradeo con las variantes install, remove, purge y upgrade.
APT no se ejecuta sobre el root activo.
synex-immutable crea un mount namespace privado, monta allí la generación pending y construye un chroot transaccional donde se presentan conjuntamente:
root pending RW
/etc pending RW
dpkg DB pending RW
APT state pending RWMientras tanto, fuera de ese entorno el usuario continúa ejecutando la generación anterior, cuyo root y estado administrativo permanecen protegidos.
APT y dpkg siguen siendo APT y dpkg
Una decisión del proyecto fue no reemplazar el ecosistema de paquetes existente.
Synex Immutable continúa utilizando APT y dpkg.
La diferencia está en dónde se ejecutan.
Dentro del entorno transaccional APT trabaja con las mismas rutas que espera encontrar normalmente:
/etc
/var/lib/dpkg
/var/lib/aptpero esas rutas corresponden a la futura generación.
Esto permite mantener el modelo y el formato de paquetes habitual de Synex sin necesidad de convertir aplicaciones y componentes del sistema a un formato específico de una edición inmutable.
Durante estas operaciones se aplica además policy-rc.d para impedir que los maintainer scripts intenten iniciar o reiniciar servicios dentro del chroot transaccional.
Una vez terminada cada operación, Synex ejecuta:
dpkg --auditpara comprobar la consistencia del estado de paquetes.
seal: una generación no se publica solamente porque terminó APT
Completar una actualización no convierte automáticamente a la pending en una generación arrancable.
Ese paso se realiza explícitamente:
sudo synex-immutable seal gen-0002Antes de comprometerla, seal valida entre otras cosas:
- la existencia y coherencia del root y su STATE;
- el layout completo de STATE;
- el
fstabcorrespondiente a esa generación; - el estado de dpkg;
- la existencia de un kernel e initramfs coherentes;
- la presencia del hook de Synex Immutable dentro del initramfs;
- que no queden mounts transaccionales activos.
Sólo entonces sincroniza el estado y cambia el root a read-only.
Pero el proceso todavía no terminó.
seal ejecuta automáticamente:
update-grubvalida el grub.cfg resultante con grub-script-check y comprueba que exista una entrada exacta para esa generación con los rootflags Btrfs correspondientes.
Recién después de completar correctamente esa secuencia la generación se considera sellada y publicada.
GRUB también forma parte de la arquitectura
Synex Immutable incorpora su propio generador:
/etc/grub.d/09_synex-immutableÉste descubre las generaciones disponibles y sólo publica aquellas que reúnen las condiciones necesarias para arrancar.
Cada entrada apunta directamente al kernel e initramfs que pertenecen a esa generación:
Synex Immutable - gen-0002con:
rootflags=subvol=@immutable-generations/gen-0002Las generaciones se ordenan desde la más reciente y GRUB utiliza normalmente la última generación sellada como entrada predeterminada.
El generador convencional 10_linux queda deshabilitado de forma controlada mediante dpkg-statoverride, evitando crear entradas que salteen el modelo generacional.
/boot forma parte de cada generación, por lo que kernel e initramfs avanzan y retroceden con ella.
/boot/grub, en cambio, permanece fuera de las generaciones como estado persistente compartido.
Volver a una generación anterior
Synex Immutable Alpha 1 todavía no incorpora un comando específico de rollback.
En esta primera versión, volver a un estado anterior consiste simplemente en seleccionar otra generación sellada desde GRUB.
Por ejemplo:
gen-0001
gen-0002
gen-0003pueden coexistir como estados arrancables independientes.
Si el usuario inicia gen-0001, Synex reconoce esa generación como la activa. Si desde allí crea una nueva generación, no sobrescribe las posteriores: asigna un nuevo número pero toma como origen el sistema que realmente se encuentra ejecutando.
Esto permite continuar trabajando desde un estado anterior sin destruir el historial existente.
Una arquitectura transaccional, no atomicidad absoluta de la máquina
Existe una frontera deliberada en el modelo.
/var general continúa siendo persistente y se expone también dentro de las transacciones. Sobre él se superponen únicamente las rutas administrativas que pertenecen a STATE.
Por eso modificaciones realizadas por un maintainer script sobre rutas como:
/var/lib/dpkg
/var/lib/aptpertenecen a la generación pending.
Pero modificaciones sobre:
/var/log
/var/cache
/var/lib/<aplicación>pueden afectar inmediatamente al estado persistente.
Esto significa que Synex Immutable no pretende ofrecer atomicidad de todos los efectos posibles de una máquina.
La garantía buscada es otra:
atomicidad fuerte de la generación del sistema y de su estado administrativo de paquetes.
Los datos persistentes mantienen deliberadamente una vida independiente.
De MicroOS a una arquitectura propia de Synex
El punto de partida conceptual de este desarrollo fue openSUSE MicroOS.
Antes de implementar Synex Immutable estudiamos su comportamiento real en una instalación limpia: estructura Btrfs, snapshots, /etc, RPM DB, entorno transaccional, boot, rollback, abort de transacciones y la separación entre sistema generacional y estado persistente.
Ese análisis dejó una conclusión importante: un sistema transaccional no se define simplemente por montar / read-only.
La unidad real es la generación.
MicroOS resuelve ese problema con transactional-update, Tukit, Snapper, una RPM DB generacional y su propia integración con el boot.
Synex conserva las propiedades que consideramos fundamentales, pero las implementa de otra manera:
MicroOS Synex Immutable
------------------------- --------------------------------------
transactional-update synex-immutable
Tukit TransactionMount + GenerationManager
Snapper snapshots generaciones Btrfs propias
RPM DB generacional STATE v2 para dpkg/APT
systemd-boot/BLS GRUB + 09_synex-immutable
writable /etc por snapshot STATE generacionalNo buscamos reproducir literalmente el layout de MicroOS.
El trabajo posterior estuvo centrado en resolver los problemas propios de Synex y del ecosistema APT/dpkg: qué estado debía acompañar a una generación, cómo ejecutar maintainer scripts sin tocar el sistema activo, cómo tratar /etc, cómo conservar /var, cómo incorporar kernel e initramfs y cómo hacer que GRUB forme parte del compromiso de una actualización.
El resultado mantiene una característica que considerábamos importante desde el comienzo: Synex Immutable sigue siendo Synex.
No requiere convertir el sistema a un modelo de despliegue basado en OSTree ni reemplazar APT y dpkg. La arquitectura transaccional se construye alrededor de ellos.
Calamares y la creación de GEN1
La instalación también forma parte del modelo.
Calamares comienza trabajando sobre un root convencional temporal:
@y crea independientemente los subvolúmenes persistentes necesarios.
Al finalizar la instalación, los módulos específicos de Synex Immutable convierten ese staging en:
@immutable-generations/gen-0001
@immutable-state/gen-0001GEN1 es validada, sellada y publicada en GRUB.
Una vez confirmado que la configuración de arranque es válida, el root temporal @ se elimina definitivamente.
El sistema instalado queda así sin un root mutable convencional alternativo fuera de la arquitectura de generaciones.
Este proceso fue implementado y probado tanto en sistemas UEFI como BIOS.
Synex Package Manager en la edición Immutable
En esta primera Alpha, Synex Package Manager continúa pudiendo utilizarse para la gestión de aplicaciones Flatpak.
La integración específica con Synex Immutable forma parte del trabajo pendiente de las próximas versiones.
El objetivo es que el backend de SPM pueda detectar automáticamente cuándo se está ejecutando sobre la variante Immutable y, a partir de esa información, mostrar únicamente las funciones compatibles con este modelo.
En ese esquema, SPM quedará orientado a la gestión de Flatpak y a las opciones relacionadas con ese formato, mientras que las modificaciones del sistema base mediante APT seguirán realizándose a través de synex-immutable.
Conceptualmente:
Estado actual
Flatpak
↓
Synex Package Manager
Sistema base / APT
↓
synex-immutableY como evolución prevista:
SPM detecta Synex Immutable
│
└── muestra únicamente
las funciones compatibles
con la ediciónDe esta forma la separación entre aplicaciones de usuario y sistema base ya está definida arquitectónicamente, aunque la adaptación automática de la interfaz de SPM todavía no forma parte de Alpha 1.
Alpha 1 y próximos pasos
Synex 13 Immutable Alpha 1 implementa ya el núcleo completo del modelo generacional:
- root activo read-only;
/etcgeneracional y writable;- STATE v2 para dpkg/APT;
- creación y descarte de generaciones pending;
- transacciones APT aisladas;
- validación con
dpkg --audit; - sellado de generaciones;
- publicación y validación automática de GRUB;
- boot de generaciones anteriores;
- persistencia independiente de
/var,/homey/root; - instalación completa mediante Calamares en UEFI y BIOS.
Algunas capas permanecen deliberadamente fuera de esta primera Alpha.
Entre ellas se encuentran la gestión y retención de generaciones selladas, un comando administrado de rollback/default, health checking después del boot, fallback automático ante una generación defectuosa y el tratamiento de cambios realizados sobre /etc activo mientras ya existe una generación pending.
La Alpha también permitirá ampliar las pruebas sobre paquetes complejos y maintainer scripts que interactúan con áreas persistentes del sistema.
Documentación técnica
Junto con esta publicación ponemos a disposición un documento técnico completo sobre el diseño e implementación de Synex Immutable:
Synex Immutable: arquitectura transaccional y modelo de funcionamiento
La documentación recorre en detalle el layout Btrfs, STATE v2, los mounts utilizados durante runtime, la arquitectura de bind mounts, el entorno transaccional de APT, las validaciones de seal, GRUB, el bootstrap desde Calamares, rollback y los límites actuales de atomicidad.
La intención es que la arquitectura de esta edición no sea una caja negra y que quienes quieran evaluar, estudiar o colaborar con el proyecto puedan conocer con precisión qué ocurre detrás de cada generación.
Disponibilidad
Synex 13 Immutable Alpha 1 está disponible para descarga inmediata.
Por tratarse de una versión Alpha, está orientada principalmente a pruebas, evaluación de la arquitectura y detección de incompatibilidades antes de avanzar hacia las siguientes etapas de desarrollo.
Como siempre, recomendamos verificar la suma de comprobación de la imagen descargada antes de crear el medio de instalación.