La inmutabilidad en sistemas operativos

¿Qué es la inmutabilidad?

La inmutabilidad de los sistemas operativos se refiere a la característica de estos que impide al usuario modificar libremente el sistema de archivos raíz con el objetivo de evitar los problemas que esto puede provocar.

Estos sistemas operativos suelen incluir unos elementos básicos que se aíslan del resto de aplicaciones como el sistema de ficheros raíz, el entorno de escritorio, herramientas básicas del sistema y bibliotecas esenciales para el sistema operativo. Este conjunto de elementos constituye el núcleo del sistema que el usuario no puede modificar.

Para la instalación de otro tipo de aplicaciones, se usan sistemas de paquetería universal como Flatpak o Snap que permiten la instalación en entornos más aislados sin interactuar con el sistema raíz como hacen los gestores de paquetes tradicionales, así como contenedores que aíslan las aplicaciones del resto del sistema.

Fundamentos de los sistemas operativos inmutables

Este tipo de sistemas operativos se basa en tres conceptos clave para mantener la filosofía de la inmutabilidad y conseguir hacer sistemas funcionales pero en los que el usuario no necesite interactuar con el sistema raíz.

• Contenedores de aplicaciones. Los sistemas operativos inmutables usan gestores de contenedores como distrobox, docker o podman para instalar aplicaciones aisladas del sistema operativo en contenedores. Esta forma de instalar aplicaciones permite que no interactúen con los ficheros del sistema de archivos raíz del sistema operativo.

• Sistemas de paquetería universales. Los gestores de paquetes universales como flatpak o snap facilitan la instalación de aplicaciones de forma independiente a la distribución sobre la que se instalen. Consiguen esto haciendo paquetes más pesados pero que incluyen la mayor parte de las dependencias necesarias para el funcionamiento de la aplicación. Esto permite que la aplicación se instale y se ejecute sin interactuar con el sistema de ficheros raíz y de forma mucho más aislada que las aplicaciones instaladas usando gestores de paquetes tradicionales como apt o dnf.

• Sanpshots. Para garantizar la consistencia del sistema en todo momento, los sistemas operativos inmutables dependen enormemente del uso de snapshots o instantáneas que almacenan el estado del sistema operativo antes de hacer cualquier modificación en el sistema de ficheros raíz. Así, este tipo de sistemas operativos genera una instantánea del sistema cada vez que se modifica un fichero de configuración o se instala una herramienta usando el gestor de paquetes tradicional propio de la distribución.

¿A qué sector van destinados?

Por sus características, no parece que los sistemas operativos inmutables se vayan a convertir en una opción extendida en entornos profesionales de servidores. Se trata de sistemas que requieren un cambio de perspectiva a la hora de trabajar con ellos en cuanto a la interacción con el propio sistema operativo. Esto hace que cualquier operación sobre el sistema de ficheros raíz se ralentice mucho respecto a la dinámica de trabajo previa. Además, este tipo de sistemas operativos exigen muchos más recursos en cuanto a capacidad de almacenamiento, por ejemplo.

Aún así, cabe tener en cuenta que la creciente popularidad de los contenedores en el despliegue de aplicaciones puede suponer un cambio de paradigma en la gestión de servidores para el despliegue de aplicaciones si se combina con el uso de sistemas operativos inmutables en los servidores.

En cambio, parece que el planteamiento de este tipo de sistemas operativos se orienta más hacia las versiones de escritorio. Mientras que las distribuciones con las que se trabajan en entornos de servidores permiten el uso de una enorme variedad de herramientas que se ejecutan desde la línea de comandos, los sistemas de paquetería universal están más dirigidos a la distribución de aplicaciones con interfaz gráfica, diseñadas para su ejecución en un entorno de escritorio.

Además, los ordenadores que se usan como equipos personales o de trabajo en entornos de escritorio son menos sensibles a los requisitos de almacenamiento que conlleva el uso de los sistemas operativos inmutables, de manera que mientras que almacenar una instantánea de todo el sistema para cada modificación del sistema raíz en un servidor puede suponer un coste demasiado grande, en el caso de los ordenadores de escritorio, el uso de almacenamiento no suele ser tan intensivo y es más habitual que los dispositivos cuenten con espacio suficiente para almacenar estas instantáneas sin suponer un problema de rendimiento para los usuarios.

Aunque el uso de sistemas operativos inmutables puede llevar más comodidad a los usuarios de ordenadores personales en el entorno doméstico, su principal potencial puede estar en los entornos profesionales en los que personas que no tienen conocimientos relacionados con la informática deben trabajar con estos equipos en su día a día. Este tipo de sistemas operativos permite que estos ordenadores de escritorio cuenten con las herramientas necesarias para que el trabajador desarrolle sus tareas pero impide que pueda ejecutar cualquier modificación sobre el sistema operativo que afecte al correcto funcionamiento del mismo, haciéndolo mucho más robusto y minimizando la probabilidad de que un error humano genere una incidencia en el parque informático de la empresa.

Distribuciones inmutables actuales

Casi todas las principales distribuciones de GNU/Linux cuentan con una versión de su sistema operativo inmutable a día de hoy. Algunos ejemplos son:

• Fedora Silverblue. Silverblue es la versión inmutable de la distribución Fedora derivada de Fedora Workstation. Esta distribución usa Flatpak como gestor de paquetes universales y Podman como gestor de contenedores. Silverblue usa GNOME como entorno de escritorio pero Fedora cuenta con otras opciones de sistemas operativos inmutables que usan otros entornos de escritorio diferentes.

• openSUSE MicroOS. MicroOS es la versión inmutable de openSUSE. De entre todas las distribuciones de sistemas operativos inmutables es una de las más orientadas al entorno de servidores. Usa el gestor de paquetes Flatpak y pretende aportar la robustez y seguridad que permiten los sistemas operativos inmutables al entorno de servidores. Está especialmente destinado al trabajo en servidores pequeños que ofrecen aplicaciones en contenedores o microservicios. También está destinado a su uso en dispositivos inteligentes.

• Vanilla OS. Vanilla OS es la distribución inmutable de Ubuntu. Desarrollada por Canonical, mantiene la filosofía de sencillez y facilidad de uso que caracteriza a Ubuntu aportando, además, las ventajas de los sistemas operativos inmutables en cuanto a seguridad de la integridad del sistema operativo. Vanilla OS usa el gestor de paquetes Snap, desarrollado también por Canonical.

• NixOS. NixOS es una distribución concebida para funcionar como un sistema operativo inmutable. Usa su propio sistema gestor de paquetería universal.

• Ubuntu Core. Otro sistema operativo inmutable derivado de Ubuntu es Ubuntu Core. Este sistema operativo está especialmente diseñado para su uso en dispositivos inteligentes.

• Bottlerocket. Bottlerocket es un sistema operativo inmutable desarrollado por Amazon que se puede usar al crear una instancia en Amazon Web Services. Este sistema operativo está diseñado para ejecutar aplicaciones sobre contenedores y suponer un mantenimiento mínimo a los usuarios de la plataforma.

• SteamOS. Algunas distribuciones de sistemas operativos no inmutables tienen están diseñadas con una utilidad más concreta y no son de propósito generalista. Es el caso de SteamOS, una distribución basada en Debian y desarrollada por Valve que está optimizada para videojuegos. Entre sus características cuenta con una gran compatibilidad con hardware de lo más variado.

• Endless OS. Otro sistema operativo inmutable de nicho es Endless OS, orientado a entornos educativos. El propio sistema operativo cuenta con una importante variedad de aplicaciones y contenido educativo preinstalado, con el planteamiento de que el usuario final no necesite instalar ninguna aplicación más para poder usar el equipo.

Además de los sistemas operativos listados, no paran de surgir nuevas distribuciones que se basan en la inmutabilidad del sistema operativo. Algunas de ellas están destinadas al uso en equipos de escritorio mientras que otras muchas se orientan al despliegue de aplicaciones en contenedores, como Talos Linux, que está diseñado para el uso de Kubernetes.

En conclusión

Aunque no es la primera vez que la idea de los sistemas operativos inmutables aparece en el mundo de la informática (ya hace décadas que existen los sistemas operativos live en CD sobre los que no se pueden hacer modificaciones), todo apunta a que esta vez han llegado para quedarse.

Y es que se dan varias circunstancias que, en conjunto, pueden suponer un cambio de paradigma en la forma en que se conciben los sistemas operativos.

Es evidente que los sistemas operativos inmutables tienen importantes ventajas como la seguridad y estabilidad que ofrecen o la facilidad para instalar aplicaciones a través de los sistemas de paquetería universal. Además, estas aplicaciones, al estar más aisladas, son mucho más fáciles de actualizar hasta el punto de que en un mismo sistema pueden convivir varias versiones de la misma aplicación.

Aunque también conllevan algunas desventajas como el consumo de espacio en disco, la limitación en el número de aplicaciones que actualmente están disponibles en los sistemas de paquetería universal y la reconversión que supone también para el usuario adaptarse a este nuevo paradigma.

Sin embargo, el auge del uso de contenedores para el despliegue de aplicaciones tanto en entornos de escritorio como en entorno de servidores puede suponer el caldo de cultivo perfecto para la proliferación de este tipo de sistemas operativos.

Los SO inmutables de OpenSUSE y Red Hat

OpenSUSE MicroOS

MicroOS es el sistema operativo inmutable de OpenSUSE. Se trata de un sistema operativo Linux de creación relativamente reciente que usa imágenes pequeñas y ligeras, fácilmente escalable, con actualizaciones automáticas y continuas que no afectan al sistema y resistente a fallos, con una gran facilidad para la recuperación al permitir volver al estado de la última instantánea en cualquier momento.

Según sus desarrolladores, se trata de un sistema operativo del que el usuario no tiene que preocuparse y que está específicamente diseñado para el alojamiento de contenedores pero enfocado a un entorno de grandes implantaciones.

openSUSE MicroOS hereda los conocimientos de openSUSE Tumbleweed y SUSE Linux Enterprise, al tiempo que redefine el sistema operativo en una distribución pequeña, eficiente y fiable. openSUSE

El sistema operativo MicroOS cuenta con un sistema de ficheros raíz de sólo lectura que evita las modificaciones accidentales del sistema. Además, cuenta con la tecnología Transactional Updates, que aprovecha las instantáneas de btrfs (el sistema de ficheros que usa este sistema operativo) para aplicar actualizaciones de paquetes sin interferir con el sistema en funcionamiento.

Otras herramientas presentes en este sistema operativo son health-checker, que verifica el correcto funcionamiento del sistema y revierte los cambios que produzcan problemas; cloud-init, que configura el sistema durante su primer arranque en la nube; o Combustion e Ignition, que cumplen la misma función en el resto de imágenes.

Cabe destacar, además, que MicroOS es un sistema operativo de tipo rolling release, es decir, que cada nueva versión o instantánea liberada de openSUSE Tumbleweed produce automáticamente una nueva versión de este sistema operativo.

La innovación más reciente en el marco de este sistema operativo es que está en un proceso de modificación de nombre. Se están desarrollando dos nuevas versiones paralelas de MicroOS: Aeon y Kalpa. Cuando termine el desarrollo de estas nuevas versiones, openSUSE MicroOS pasará a llamarse Aeon cuando use un entorno de escritorio Gnome o Kalpa cuando use un entorno de escritorio Plasma. Ambos sistemas operativos están aún en desarrollo y todavía no se recomienda implementarlos en entornos de producción.

Fedora Silverblue

Fedora Silverblue es un sistema operativo inmutable basado en Fedora, la distribución rolling release del ecosistema Red Hat. Una de las características principales de este sistema operativo del proyecto fedora es la fiabilidad. Cada versión de Silverblue se actualiza durante unos 13 meses y cada actualización se aplica automáticamente en el reinicio del equipo, de manera que el sistema se mantiene consistente. Incluso se puede seguir trabajando en el equipo mientras se aplican las actualizaciones.

Además, se trata de un sistema operativo atómico, que se sólo se actualiza si la actualización se puede efectuar sin problemas. Si durante el proceso de actualización surge algún inconveniente, el sistema se revierte al último estado consistente y la actualización no se aplica.

Como el resto de sistemas operativos inmutables, Silverblue almacena instantáneas de la última versión funcional del sistema, a la que se puede recurrir en caso de que fuese necesario. Igualmente, las aplicaciones gráficas se instalan de forma aislada usando el gestor de paquetería universal Flatpak, que las mantiene separadas del sistema raíz.

Este sistema operativo también cuenta con una herramienta orientada al trabajo de los desarrolladores, toolbox, que facilita mantener la gestión de diferentes versiones de las mismas herramientas organizadas por proyectos sin que se afecten unas a otras o al propio sistema operativo.

El entorno de escritorio elegido por Fedora para desarrollar Silverblue es Gnome. Para la gestión de la paquetería propia del sistema operativo, esta distribución usa rpm-ostree, una sistema híbrido de paquetería e instantáneas basado en el gestor de paquetes RPM que permite actualizaciones atómicas y seguras del sistema raíz.

Otros proyectos de sistemas operativos inmutables relacionados con Silverblue son Fedora Kinoite, que usa el entorno de escritorio Plasma o Fedora CoreOS, que es un sistema operativo inmutable minimalista, monolítico y que se actualiza automáticamente orientado al trabajo con contenedores y especialmente optimizado para el uso de Kubernetes.

Instalación de MicroOS y Silverblue

Instalación de MicroOS

La imagen iso de openSUSE MicroOS se puede descargar desde la página de descargas de la distribución. A diferencia de lo que ocurre con la mayoría de distribuciones de GNU/Linux tradicionales, que a penas exigen unos requisitos mínimos muy báicos, MicroOS necesita, como mínimo 1GB de memoria RAM, 5GB de disco para la partición raíz y otros 5GB de disco para la partición /var. Sin embargo, openSUSE recomienda contar con 2GB de RAM y 60GB de disco duro (20 para la raíz y 40 para la partición /var) en las máquinas en las que se vaya a instalar este sistema operativo.

Otra diferencia relevante entre MicroOS y los sistemas operativos tradicionales de GNU/Linux es que, generalmente, las imágenes de estos sistemas operativos suelen ser bastante ligeras. Al menos, suelen contar con una versión para instalación a través de internet que cuenta con la estructura mínima del sistema operativo e instala el resto de la paquetería desde los repositorios de la distribución. En el caso de MicroOS, las imágenes son, en geneeral, algo más pesadas, de unos 2,5GB.

Al iniciar la imagen iso de MicroOS se muestra un menú de arranque que incluye las opciones de arrancar desde el disco duro o instalar el sistema operativo junto con un menú de opciones avanzadas.

Al seleccionar la opción de instalación, lo primero que hace el sistema es inicializar la configuración de red. Para ello detecta los dispositivos de red y sus drivers, analiza el estado de la red, y lee la configuración tanto de los dispositivos como de la red.

La primera parte (y, prácticamente, la única) interactiva del proceso de instalación consiste en elegir la función del sistema. A diferencia del proceso de instalación de la mayoría de distribuciones de GNU/Linux en la que el usuario debe configurar los diferentes elementos del sistema, el instalador de MicroOS muestra una lista de posibles funciones que puede tomar el sistema que se instala para que el usuario elija la instalación predeterminada que mejor se adapte a la función que le va a dar a la máquina.

Según la opción que se elija, el instalador solicita una información u otra como, por ejemplo, el nombre de usuario y la contraseña o el servidor NTP para sincronizar el reloj del equipo.

Para hacer una configuración más específica de la instalación: por ejemplo, para elegir determinado software durante la instalación o hacer un determinado particionado manual hay que acceder a cada uno de los apartados del resumen de instalación que muestra el asistente al finalizar el proceso.

Por defecto, MicroOS crea en el disco duro una pequeña partición de arranque y dos particiones más de un tamaño similar entre ellas en las que monta los directorios raíz y /var. En un sistema operativo inmutable en el que las snapshots tienen una importancia crucial tiene especial sentido que el directorio /var, donde se suelen almacenar las instantáneas, esté separado de la raíz del sistema. Ambas particiones se crean usando un sistema de archivos btrfs.

Desde esa misma pantalla se puede pulsar el botón “instalar” para lanzar el instalador, que instala en el sistema toda la paquetería básica necesaria para su funcionamiento, así como los paquetes específicos que se hayan indicado en el menú de instalación.

Instalación de Silverblue

La imagen para la instalación de Fedora Silverblue se puede descargar desde la página de descargas del sistema operativo. A diferencia de MicroOS, Silverblue no especifica en su página de descargas los requisitos mínimos con los que debe contar la máquina sobre la que se instala el sistema. Sin embargo, las imágnes sí son de un tamaño similar a las que distribuye openSUSE. En este caso, la iso de Fedora Silverblue es de 2,8GB, mucho mayor que las imágenes netinstall de otras distribuciones como Debian, que a penas llegan a los 500MB.

El menú de arranque del instalador de Fedora Silverblue muestra diferentes opciones para instalar directamente el sistema operativo, instalarlo tras probarlo o resolver posible problemas.

La interfaz del instalador de Fedora Silverblue es muy similar a las del resto de distribuciones del ecosistema de Red Hat (como RHEL, CentOS, Fedora y otras distribuciones derivdas como AlmaLinux o Rocky Linux). La principal diferencia es que Silverblue casi no permite configurar ningún elemento del sistema durante la instalación, de hecho, el único aspecto del sistema al que se puede acceder desde el instalador es el de particionado.

El menú de particionado es análogo al que usan el resto de distribuciones basadas en Red Hat. Sin embargo, tal y como avisan en su documentación, “Fedora Silverblue no ofrece una experiencia totalmente funcional para el arranque dual o el particionado manual” y, por tanto, es recomendable hacer la instalación usando el particionado automático.

Tras acceder al menú de particionado y validar el tipo de particionado deseado en la instalación, se puede lanzar el instalador.

Este instalador prerpara el disco, lo particiona e instala el sistema operativo con todos los paquetes necesarios para su funcionamiento. Si el proceso de instalación de openSUSE MicroOS es poco interactivo, la capacidad del usuario para intervenir en la instalación de Silverblue es mínima hasta el punto de que no se puede crear un usuario o elegir la paquetería que se instala junto al sistema operativo base.

Tras finalizar el proceso de instalación, se reinicia el sistema.

En el primer inicio de Silverblue, se muestra un asistente de configuración del sistema. Durante esta configuración, se puede configurar la privacidad, se puede activar el software de terceros y, además, se crea el usuario sin privilegios del sistema.

Gestión de paquetes y aplicaciones en MicroOS y Silverblue

Gestión de paquetes y aplicaciones en MicroOS

Aunque el gestor de paquetes de los diferentes sistemas operativos de openSUSE es zypper, en el caso de MicroOS este gestor de paquetes no puede efectuar ningún cambio en el sistema raíz. Para getionar la paquetería del sistema operativo se usa en esta distribución la herramienta transactional-update. Esta herramienta hace una instantánea del sistema en el momento previo a la instalación o actualización del paquete y, posteriormente, lo instala. De esta manera, el sistema garantiza que ante un posible fallo durante la instalación o actualización del paquete se puede volver al estado anterior.

Por ejemplo, para actualizar la paquetería del sistema se usa el comando transactional-update, que genera una instantánea del sistema operativo antes de usar zypper para instalar todas las actualizaciones necesarias en el sistema.

localhost:~ # transactional-update
Checking for newer version.
transactional-update 4.8.3 started
Options: 
Separate /var detected.
2024-12-18 16:57:40 tukit 4.8.3 started
2024-12-18 16:57:40 Options: -c1 open 
2024-12-18 16:57:42 Using snapshot 1 as base for new snapshot 2.
2024-12-18 16:57:42 /var/lib/overlay/1/etc
2024-12-18 16:57:42 No previous snapshot to sync with - skipping
Relabeled /var from system_u:object_r:unlabeled_t:s0 to system_u:object_r:var_t:s0
Relabeled /var/lib from unconfined_u:object_r:unlabeled_t:s0 to unconfined_u:object_r:var_lib_t:s0
ID: 2
2024-12-18 16:57:45 Transaction completed.
Calling zypper --no-cd dup
...
2024-12-18 16:59:26 Application returned with exit status 0.
2024-12-18 16:59:28 Transaction completed.
Trying to rebuild kdump initrd
2024-12-18 16:59:30 tukit 4.8.3 started
2024-12-18 16:59:30 Options: call 2 /sbin/mkdumprd 
2024-12-18 16:59:32 Executing `/sbin/mkdumprd`:
/var/lib/kdump not writable, not regenerating initrd.
2024-12-18 16:59:32 Application returned with exit status 0.
2024-12-18 16:59:33 Transaction completed.
2024-12-18 16:59:33 tukit 4.8.3 started
2024-12-18 16:59:33 Options: close 2 
2024-12-18 16:59:35 New default snapshot is #2 (/.snapshots/2/snapshot).
2024-12-18 16:59:35 Transaction completed.

Please reboot your machine to activate the changes and avoid data loss.
New default snapshot is #2 (/.snapshots/2/snapshot).
transactional-update finished

Como se muestra en la salida del comando, el último paso que realiza la herramienta transactional-update tras instalar todas las actualizaciones pendientes y mostrar el mensaje Transaction completed es generar una nueva instantánea en el directorio oculto .snapshots dentro del directorio raíz. Tras realizar un reinicio del sistema, se cargará esta nueva instantánea que ya contará con todas las actualizaciones instaladas. Mientras no se haga este reinicio, las actualizaciones aún no se aplicarán al sistema.

Este mecanismo de respaldo del sistema basado en las instantáneas permite, por ejemplo, arrancar el sistema desde una imagen previamente guardada en modo de sólo lectura desde el gestor de arranque grub. Esta opción puede ser muy útil en caso de necesitar acceder a un estado consistente previo del sistema para poder solventar algún error en el mismo.

De igual modo se instalan nuevos paquetes en el sistema. En este caso, al comando transactional-update hay que añadirle la orden pkg install seguida del nombre del paquete que se quiere instalar.

localhost:~ # transactional-update pkg in tree
Checking for newer version.
transactional-update 4.8.3 started
Options: pkg in tree
Separate /var detected.
2024-12-18 17:06:47 tukit 4.8.3 started
2024-12-18 17:06:47 Options: -c2 open 
2024-12-18 17:06:47 Using snapshot 2 as base for new snapshot 4.
2024-12-18 17:06:47 /var/lib/overlay/2/etc
2024-12-18 17:06:47 Syncing /etc of previous snapshot 1 as base into new snapshot "/.snapshots/4/snapshot"
2024-12-18 17:06:47 SELinux is enabled.
ID: 4
2024-12-18 17:06:50 Transaction completed.
Calling zypper install
2024-12-18 17:06:53 tukit 4.8.3 started
2024-12-18 17:06:53 Options: callext 4 zypper -R {} install tree 
2024-12-18 17:06:55 Executing `zypper -R /tmp/transactional-update-8QTVUT install tree`:
Loading repository data...
Reading installed packages...
Resolving package dependencies...

The following NEW package is going to be installed:
  tree

1 new package to install.
...
Retrieving: tree-2.2.1-1.1.x86_64 (openSUSE-Tumbleweed-Oss) (1/1),  78.1 KiB    
Retrieving: tree-2.2.1-1.1.x86_64.rpm [...done (15.2 KiB/s)]
(1/1) Installing: tree-2.2.1-1.1.x86_64 [..done]
2024-12-18 17:07:30 Application returned with exit status 0.
2024-12-18 17:07:30 Transaction completed.
Trying to rebuild kdump initrd
2024-12-18 17:07:32 tukit 4.8.3 started
2024-12-18 17:07:32 Options: call 4 /sbin/mkdumprd 
2024-12-18 17:07:33 Executing `/sbin/mkdumprd`:
/var/lib/kdump not writable, not regenerating initrd.
2024-12-18 17:07:33 Application returned with exit status 0.
2024-12-18 17:07:34 Transaction completed.
2024-12-18 17:07:34 tukit 4.8.3 started
2024-12-18 17:07:34 Options: close 4 
2024-12-18 17:07:36 New default snapshot is #4 (/.snapshots/4/snapshot).
2024-12-18 17:07:36 Transaction completed.

Please reboot your machine to activate the changes and avoid data loss.
New default snapshot is #4 (/.snapshots/4/snapshot).
transactional-update finished

Nuevamente, la herramienta transactional-update genera una instantánea del sistema con el nuevo paquete instalado e indica que se debe reiniciar el sistema para aplicar los cambios. Sin embargo, este sistema operativo también permite cargar una instantánea del sistema en caliente para aplicar estos cambios sin necesidad de reiniciar la máquina.

Siguiendo con este ejemplo, tras haber generado la snapshot número 4 durante la ejecución del comando anterior, esta orden hace que el sistema cargue la nueva instantánea y la use para remplazar la instantánea sobre la que se basa el sistema en ejecución.

localhost:~ # transactional-update apply
Checking for newer version.
transactional-update 4.8.3 started
Options: apply
Separate /var detected.

Using default snapshot 4 to replace running system...
Applying /usr...
Applying /etc...
Applying /boot...
Executing systemctl daemon-reexec...
Executing create_dirs_from_rpmdb...
Executing systemd-tmpfiles --create...
=> Applied default snapshot as new base for running system!
   Running processes will not be restarted automatically.
transactional-update finished

Tras aplicar los cambios, el nuevo paquete está disponible en el sistema.

localhost:~ # tree
.
├── Desktop
│   ├── Home.desktop
│   └── trash.desktop
├── Documents
├── Downloads
├── Music
├── Pictures
├── Public
├── Templates
├── Videos
├── bin
└── inst-sys
    └── yast2-screen-shots

12 directories, 2 files

Otra práctica habitual en este tipo de sistemas operativos inmutables es el uso de sistemas de paquetería universal para la instalación de aplicaciones de escritorio. En este caso, MicroOS usa Flatpak como gestor de paquetería universal.

Aunque se puede usar desde la línea de comandos, el método más habitual de usar Flatpak es desde la herramienta gráfica de gestión de aplicaciones del sistema operativo. En el caso de MicroOS esta aplicación se llama Discover. Al acceder a ella por primera vez es necesario configurar las fuentes de Flatpak desde las que se van a descargar las aplicaciones. Para hacerlo, sólo hay que pulsar el botón en el que pone “Add Flathub”. Flathub es uno de los repositorios más populares de aplicaciones en Flatpak.

Igualmente, la pestaña “Settings” de la aplicación “Discover” permite añadir una lista de repositorios de Flatpak a partir de su URL.

Tras añadir el repositorio a Flatpak, en la pestaña principal de “Discover” se muestra una lista de aplicaciones disponibles en Flatpak y que se pueden instalar en el sistema. Estas aplicaciones se instalan aisladas del sistema raíz, sin afectar al mismo y sin interactuar con él, lo que mantiene la inmutabilidad del sistema operativo.

Una tercera opción alternativa para la instalación de aplicaciones en este sistema operativo es el uso de contenedores. Es el caso de distrobox, una herramienta que permite gestionar contenedores para ejecutar aplicaciones con independencia del sistema operativo sobre el que lo hagan.

Esta herramienta se debe instalar como un paquete usando el sistema de instalación propio de MicroOS transactional-update.

localhost:~ # transactional-update pkg install distrobox
localhost:~ # transactional-update apply

Esta herramienta permite crear contenedores a partir de imágenes de otros sistemas operativos.

localhost:~ # distrobox create --name debian01 --image debian:latest
localhost:~ # distrobox enter debian01

En ellos se pueden instalar y ejecutar aplicaciones disponibles en esos sistemas opeativos y, además, exportar un acceso directo a esas aplicaciones al panel de aplicaciones del sistema.

Gestión de paquetes y aplicaciones en Silverblue

Como es habitual en los sistemas operativos inmutables, la versión Silverblue de Fedora tampoco permite el uso del gestor de paquetes propio del ecosistema Red Hat, dnf. La herramienta usada en Fedora Silverblue para interactuar con el sistema raíz y poder instalar y actualizar la paquetería del sistema es rpm-ostree. De forma análoga a transactional-update, esta herramienta hace una instantánea que guarda el estado presente del sistema operativo antes de efectuar ninguna modificación. Posteriormente, se instalan o actualizan los paquetes necesarios y, finalmente, se crea una nueva instantánea si los cambios han sido existosos. De nuevo, para aplicar los cambios es necesario reinicar el sistema.

root@fedora:~# rpm-ostree update
⠤ Receiving objects; 99% (15311/15315) 2,8 MB/s 974,2 MB                        2641 metadata, 12674 content objects fetched; 951438 KiB transferred in 428 seconds; 2,2 GB content written
Receiving objects; 99% (15311/15315) 2,8 MB/s 974,2 MB... done
Staging deployment... done
Upgraded:
  ImageMagick 1:7.1.1.38-1.fc41 -> 1:7.1.1.41-1.fc41
  ImageMagick-libs 1:7.1.1.38-1.fc41 -> 1:7.1.1.41-1.fc41
  PackageKit-glib 1.2.8-7.fc41 -> 1.2.8-8.fc41
...
  xorg-x11-xinit-1.4.2-3.fc41.x86_64
  xrdb-1.2.2-4.fc41.x86_64
Added:
  OpenCL-ICD-Loader-3.0.6-1.20241023git5907ac1.fc41.x86_64
  bootc-1.1.2-2.fc41.x86_64
  hiredis-1.2.0-3.fc41.x86_64
  opensc-libs-0.26.0-1.fc41.x86_64
Run "systemctl reboot" to start a reboot

Silverblue se refiere a cada una de las instantáneas que crea para guardar el estado del sistema operativo como “despliegues”. Tras aplicar alguna instalación o actualización, es necesario reiniciar el sistema para aplicar el nuevo “despliegue”.

De la misma forma se pueden instalar nuevos paquetes en el sistema.

oot@fedora:~# rpm-ostree install cmatrix
Checking out tree e3782ee... done
Enabled rpm-md repositories: fedora-cisco-openh264 updates fedora updates-archive
Importing rpm-md... done
rpm-md repo 'fedora-cisco-openh264' (cached); generated: 2024-03-11T19:22:31Z solvables: 3
rpm-md repo 'updates' (cached); generated: 2024-12-17T03:55:59Z solvables: 13865
rpm-md repo 'fedora' (cached); generated: 2024-10-24T13:55:59Z solvables: 76624
rpm-md repo 'updates-archive' (cached); generated: 2024-12-17T04:21:09Z solvables: 16853
Resolving dependencies... done
Will download: 1 package (40,1 kB)
Downloading from 'fedora'... done
Importing packages... done
Checking out packages... done
Running pre scripts... done
Running post scripts... done
Running posttrans scripts... done
Writing rpmdb... done
Writing OSTree commit... done
Staging deployment... done
Added:
  cmatrix-2.0-10.fc41.x86_64
Changes queued for next boot. Run "systemctl reboot" to start a reboot

Al igual que MicroOS, Silverblue también permite cambiar en caliente entre estos diferentes “despliegues”.

root@fedora:~# rpm-ostree apply-live
Computing /etc diff to preserve... done
Updating /usr... done
Updating /etc... done
Running systemd-tmpfiles for /run and /var... done
Added:
  cmatrix-2.0-10.fc41.x86_64
Successfully updated running filesystem tree.

Por otra parte, en Silverblue también se pueden instalar las aplicaciones del gestor de paquetería universal Flatpak. Por defecto, la herramienta gráfica de instalación de software de Fedora Silverblue tiene configurado los repositorios de Flatpak de la propia distribución. En estos repositorios hay disponible una gran variedad de aplicaciones que se instalan de forma aisladas en el sistema sin interactuar con el sistema de ficheros raíz.

Además, desde el menú de repositorios de software se pueden añadir nuevos repositorios a Flatpak como, por ejemplo, el repositorio Flathub, uno de los más usados por la comunidad de GNU/Linux.

Por último, cabe destacar que, tal y como se ha documentado en el apartado anterior, en Fedora Silverblue también se pueden ejecutar aplicaciones en contenedores usando gestores de contenedores como, por ejemplo, Distrobox.

En el repostorio Flathub de Flatpak se incluye una herramienta de interfaz gráfica que permite gestionar los contenedores creados con la herramienta Distrobox en los entornos de escritorio basados en Gnome. Desde su interfaz se pueden crear nuevos contenedores, acceder a la terminal de cada uno de ellos, cambiar el nombre, elegir el sistema operativo que usan, ver las aplicaciones instaladas en ellos, etc.

Para que BoxBuddy pueda funcionar, primero es necesario instalar Distrobox en el equipo. Esta instalación se debe hacer usando la opción de instalación de la distribución que permite la instalación de paquetes en el sistema raíz, en el caso de Fedora Silverblue, con rpm-ostree.

rpm-ostree install distrobox
sudo rpm-ostree apply-live

Pulsando el botón + de la ventana de BoxBuddy se abre el menú de creación de un nuevo contenedor. En este menú se puede indicar el nombre y distribución del contenedor y, con el botón crear, se inica su proceso de creación.

Cuando crea el contenedor, BoxBuddy abre una terminal desde la que se puede interactuar con este sistema. Además, desde la interfaz de esta herramienta se pueden ejecutar algunas acciones relevantes sobre el contenedor como abrir una terminal, actualizarlo, ver las aplicaciones instaladas en él, instalar aplicaciones desde un fichero .deb almacenado localmente, clonar el contenedor o eliminarlo.

En la terminal del contenedor se puede trabajar como en cualquier otro contenedor de distrobox. Por ejemplo, se puede instalar una aplicación determinada.

sudo apt update
sudo apt install deepin-calculator

Cuando finaliza la instalación de la paquetería necesaria, la aplicación aparece en la lista de aplicaciones que se muestra en la interfaz gráfica de BoxBuddy. Esta ventana permite no sólo ver las aplicaciones que están instaladas en el contenedor sino también ejecutarlas y exportarlas con el botón Añadir al Menú.

Cuando se exporta una aplicación con este botón, aparece en el panel de aplicaciones de Gnome (esquina inferior izquierda en la siguiente captura de pantalla) al igual que si se hubiese exportado desde la terminal del contenedor.

Otra herramienta interesante para usar en este tipo de sistemas operativos inmutables es Flatseal. Flatseal es una aplicación gráfica que permite gestionar los accesos de las diferentes aplicaciones instaladas con el gestor de paquetería universal Flatpak.

Fuentes

Los sistemas operativos inmutables en Linux

Qué es una distro inmutable de Linux y por qué tienen tantas ventajas

Qué es un Linux ‘inmutable’: estas son las ventajas que ofrece esta nueva categoría de sistema operativo

12 Immutable Linux Distributions for Those Looking to Embrace the Future

openSUSE MicroOS

MicroOS

Qué es Fedora Silverblue. Todavía hay espacio para distribuciones originales

Fedora Silverblue