Desde el lanzamiento de Fedora 34, poco a poco va emergiendo una edición de la distribución que hasta entonces había pasado bastante inadvertida (y que sigue pasando a grandes rasgos) en la escena mainstream de Linux: Silverblue. Para los que anden perdidos, nos referimos a lo que antes se llamaba antes Fedora Atomic Workstation, que consiste en un sistema operativo inmutable orientado al uso de contenedores.
Que Fedora Silverblue y su variante Kinoite con KDE Plasma sean sistemas operativos inmutables significa que hay una imagen base del sistema que el usuario no puede modificar ni eliminar, ni siquiera con permisos de administrador debido a que es de solo lectura. Esta perspectiva, que no es en sí tan novedosa, cambia de raíz la forma en la que tradicionalmente ha sido manejado el escritorio Linux, ya que aquí lo que hay es una imagen base del sistema que se va “reconstruyendo” con cada actualización o instalación de uno o varios paquetes RPM. En consecuencia, si se quieren aplicar los cambios en este frente, hay que reiniciar.
El principal beneficio para el usuario es disponer de un sistema en teoría más resiliente frente a los fallos gracias a que por un lado la parte inmutable debería de estar compuesta por componentes que funcionan siempre correctamente (lo que da a entender más estabilidad), mientras que por otro se impide la rotura accidental del sistema. Si algunos habéis pensado en el escándalo en torno a APT, Pop!_OS y Linus Tech Tips, estáis en lo cierto, porque ese es uno de los escenarios que Fedora Silverblue y Kinoite pretenden impedir con su diseño.
rpm-ostree, el “reconstructor” que da vida a Fedora Silverblue
La imagen del sistema operativo, que abarca la sección inmutable y otras que el usuario sí puede modificar (por ejemplo añadiendo aplicaciones en formato RPM, aunque de partida no es lo recomendable), está compuesta por paquetes RPM. Esta parte es manejada por rpm-ostree, que es básicamente un administrador de paquetes colocado sobre OSTree. Las posibilidades que ofrece rpm-ostree llegan a ser impresionantes si las comparamos con lo que estamos habituados a ver en el escritorio Linux, pero antes de profundizar en esta tecnología, vamos a explicar brevemente qué es OSTree.
Según la documentación oficial, “OSTree es un sistema de actualización para sistemas operativos basados en Linux que realiza actualizaciones atómicas de árboles completos del sistema de ficheros. No es un sistema de paquetes, sino que más bien está destinado a complementarlo. La arquitectura subyacente podría resumirse como un ‘git para los binarios del sistema operativo’”. A pesar de que OSTree no es un gestor de paquetes, sí permite agregar un administrador de paquetes en su parte superior, y eso último es precisamente lo que es rpm-ostree.
Lo expuesto hasta ahora puede resultar un tanto aterrador, y es que rpm-ostree es más difícil de explicar que de usar. Con el fin de ilustrar un poco y rebajar la posible incompresión del lector, vamos a poner una imagen del comando con el argumento ‘–help’.
Ayuda de rpm-ostree en Fedora Silverblue/Kinoite
¿Un poco mejor? Quizás así uno vea que, si sabe manejar de forma básica un gestor de paquetes, es capaz defenderse con rpm-ostree sin complicaciones. De hecho, la lógica para instalar nuevos componentes en formato RPM, eliminarlos, además de actualizar el sistema, es la misma desde el punto de vista de la interfaz de usuario (que no el funcionamiento interno). Eso sí, en caso de modificar esta parte con alguna acción, hay que reiniciar el sistema para que los cambios surtan efecto.
Debido a la naturaleza inmutable, hay una parte de la compuesta por paquetes RPM que el usuario no puede eliminar por la vía estándar, como Firefox y las partes de GNOME. Si el usuario quiere eliminar un componente de esa parte que no se le pemite modificar, tiene que usar el argumento ‘override’ de rpm-ostree.
Cada actualización o modificación de la parte manejada por rpm-ostree va generando una nueva versión de la imagen del sistema ajustándose a las posibles modificaciones que le hayan aplicado, por lo que, en caso de que una actualización o modificación esté dando problemas, el usuario tiene la posibilidad de volver a una imagen anterior y así recuperar el correcto funcionamiento del sistema operativo.
La función para iniciar una imagen anterior del sistema se llama rollback y hay dos formas de aplicarla: la primera es ir al menú de GRUB (rollback temporal) y seleccionar alguna imagen que no sea la última y la segunda consiste en aplicar un rollback permanente con el siguiente comando: rpm-ostree rollback
Actualizando o cambiando rama del sistema operativo
Otro mecanismo interesante de rpm-ostree es el salto entre versiones del sistema operativo. Una actualización de la versión 34 a la 35 de Fedora Silverblue se haría de la siguiente manera:
rpm-ostree rebase fedora:fedora/35/x86_64/silverblue
Este es probablemente uno de los puntos en los que se puede ver de manera sencilla el poder de rpm-ostree, porque este mecanismo, más que una actualización propiamente dicha, lo que hace es cambiar la rama en la que se basa la imagen del sistema operativo en un proceso que recuerda un poco al manejo de repositorios de Git.
Al ejecutar el comando ostree remote refs fedora se muestra una lista con las ramas disponibles. En las últimas versiones de Fedora, al menos desde Silverblue, están puestas a disposición las ramas de Silverblue y Kinoite para las tres arquitecturas soportadas: x86_64, PowerPC y ARM64. Este enfoque permite convertir Silverblue en Kinoite cuando uno quiera y con un solo comando:
rpm-ostree rebase fedora:fedora/35/x86_64/kinoite
Tras terminar el proceso de cambio de base, el usuario solo tiene que reiniciar la computadora y tendrá delante a SDDM para empezar a usar Fedora Kinoite en sustitución de Silverblue.
Añadiendo argumentos al kernel
Otro aspecto interesante de rpm-ostree es la manera de introducir argumentos del kernel. En las distribuciones Linux “tradicionales” esto se realiza a través de la modificación de la línea GRUB_CMDLINE_LINUX_DEFAULT= en el fichero ‘/etc/default/grub’ y luego actualizando el propio GRUB.
En Fedora Silverblue y Kinoite hay que recurrir a rpm-ostree, siendo el proceso es totalmente diferente. Aquí el usuario solo tiene que introducir una línea de comando con los argumentos del kernel que quiere aplicar y pulsar la tecla intro. La imagen del sistema se reconstruye y después hay que reiniciar.
De hecho, la parte de la configuración del arranque del tutorial sobre cómo forzar la activación de AMDGPU en gráficas GCN (Radeon) antiguas quedaría reducida a esto:
rpm-ostree kargs --append='radeon.cik_support=0 amdgpu.cik_support=1 radeon.si_support=0 amdgpu.si_support=1'
Cómo modificar la imagen base del sistema
Los componentes de la imagen base de Fedora Silverblue/Kionoite no se pueden desinstalar por la vía estándar. Uno de los miembros más sorprendentes de la imagen base del sistema es Firefox (que posiblemente esté ahí de esa forma para facilitar la instalación de las extensiones de GNOME), por lo que si el usuario introduce rpm-ostree remove firefox, verá que no se permite llevar a cabo el proceso de desinstalación. Sin embargo, eso no quiere decir que no haya ningún resorte para eliminar elementos como Firefox y GNOME Software.
Para quitar un componente de la imagen base del sistema (aunque más bien lo que hace es ocultarlo), el usuario tiene que recurrir el argumento ‘override’ en rpm-ostree, quedando el comando de la siguiente manera:
rpm-ostree override remove firefox
Flatpak, la principal vía para instalar aplicaciones gráficas en Silverblue y Kinoite
Fedora Silverblue y Kionoite son probablemente los sistemas Linux que más sentido dan a Flatpak, el formato de paquetes “universales” que destaca por el uso de sandbox para aislar las aplicaciones.
Cierto es que Flatpak ha dejado dividida a la comunidad, con algunos que dicen que es un avance para el escritorio Linux y con otros argumentando que los inconvenientes que acarrea superan a los beneficios. Más allá del debate, Silverblue y Kinoite son dos sistemas que empujan al usuario a usar Flatpak, mientras que en distribuciones con un enfoque más “tradicional” juega un rol más complementario para obtener versiones recientes de las aplicaciones o sustituir aquellas compilaciones en formato “tradicional” que no son satisfactorias.
Una de las ventajas que ofrece Flatpak es que no interacciona con los paquetes “tradicionales” (Deb, RPM, tar.xz… ) presentes en el sistema, pero sí con los servicios y características que ofrecen. Por ejemplo, la versión Flatpak de OBS Studio interacciona con la compilación de PipeWire que está en formato “tradicional” para poder grabar desde una sesión de Wayland.
Como bien sabrán aquellos que han lidiado con Flatpak de manera más o menos exhaustiva, el repositorio Flathub juega un papel importante en las ediciones inmutables de Fedora. De hecho, hasta cierto punto se puede considerar a Flathub como el RPM Fusion de Silverblue y Kionoite, y frente al repositorio de aplicaciones Flatpak de la propia distribución, cuenta con la ventaja de tener más aplicaciones con soporte para otros idiomas que no son el inglés (o al menos desde Flathub se instala junto con la aplicación, sin necesidad de más interacciones por parte del usuario).
Sin embargo, es importante tener en cuenta que Flatpak todavía adolece de problemas de integración con el sistema, lo que posiblemente empañe la experiencia con los sistemas operativos protagonistas de esta entrada.
Llevando esto a un terreno más personal, no puedo contar mi experiencia con Kinoite porque no la he usado fuera de una máquina virtual, pero sí uso Silverblue en máquina física desde hace unas semanas. Para tener toda mi organización personal en orden, he tenido que mover mi configuración de Evolution a las cuentas de GNOME. Lo bueno de esta disposición es que permite tener el correo configurado de forma rápida con solo marcar la casilla correspondiente y luego abrir Evolution o Geary. Debido a estos cambios forzados, ahora uso Geary como cliente de correo en lugar de Evolution.
Las aplicaciones utilizadas dependen de las preferencias y el flujo del usuario, pero hay una que gana bastante protagonismo en este contexto: Flatseal. Para refrescar un poco, se trata de un gestor gráfico de permisos que viene muy bien para evitar el excesivo uso de la consola de comandos y así mejorar la experiencia con ciertas aplicaciones en formato Flatpak, las cuales a través de la configuración de su sandbox pueden terminar presentando algunas limitaciones.
Tecnologías de contenedores
Las ediciones inmutables de Fedora son sistemas orientados a los desarrolladores, y con el fin de alejar al desarrollador de las partes más sensibles o críticas, nada mejor que emplear contenedores para realizar las tareas y las pruebas pertinentes. Dicho con otras a palabras, esta sección del artículo no está muy orientada al usuario común, pero son parte de la esencia de Fedora Silverblue y Kinoite.
Buildah
Buildah es una herramienta mediante línea de comandos para crear contenedores ajustados a los estándares de la Open Container Initiative, un proyecto que opera bajo The Linux Foundation y que se encarga de desarrollar los estándares abiertos relacionados con el software de contenedores, abarcando tanto la construcción como el despliegue.
Un contenedor puede ser entendido como un paquete de software estándar que agrupa el código de una aplicación, las bibliotecas y los archivos de configuración asociados junto a las dependencias necesarias para su ejecución. Este mecanismo permite a desarrolladores y profesionales TI implementar aplicaciones en entornos diferentes, como por ejemplo pasar de Debian a RHEL sorteando las diferencias que presentan cada uno de los sistemas operativos.
Una de las características más destacadas de los contenedores es el aislamiento de procesos, esto, unido a que la combinación de contenedores permite construir aplicaciones más complejas como si fueran un puzzle, hace necesario el uso de alguna plataforma de orquestación. Aquí es donde entran, por ejemplo, Kubernetes y Amazon ECS.
Podman
Podman es un motor de contenedores sin daemon “para desarrollar, administrar y ejecutar contenedores OCI” en un sistema operativo Linux. Proporciona un frontend de línea de comandos compatible con Docker a través de un alias. Gracias a eso, fue la herramienta empleada por este servidor cuando mostró la distribución Linux empleada por Microsoft como base para construir los contenedores Docker de .NET.
La razón de por qué existe Podman es para corregir o al menos mitigar algunos de los inconvenientes que Docker presentó en su momento. Para ello, lo que hace es “interactuar directamente con el registro de imágenes, con el contenedor y el almacenamiento de imágenes, y con el kernel de Linux a través del entorno de ejecución del contenedor” en lugar de emplear un demonio. De esta manera se elimina la gestión del proceso generado por el deamon de Docker a la vez que se mantiene la compatibilidad con las imágenes de contenedor y con buena parte de los argumentos empleados en la línea de comandos, siendo todo esto gestionado por el usuario común y no por root.
Toolbox
Toolbox es posiblemente la tecnología de contenedor más peculiar de Fedora Silverblue/Kinoite, ya que permite desplegar instancias de Fedora con DNF. Estos contenedores están ajustados a los estándares de la OCI y son capaces de soportar aplicaciones gráficas.
El propósito de Toolbox es la poder lidiar con un sistema Fedora dentro de un contenedor, haciendo que el anfitrión, el que ejecuta alguna edición inmutable (aunque también puede ser usado empleando la edición Workstation y los spins para escritorio como anfitrión), queda alejado de los cambios que se realizan en los contenedores Toolbox. De esta manera se consigue que el sistema anfitrión quede limpio y por lo tanto sea más estable y esté más libre de errores.
El uso básico de Toolbox no tiene ningún misterio, tal y como se puede ver en la siguiente imagen:
Creación y puesta en funcionamiento de un contenedor de Fedora con Toolbox
Tras instalar y ejecutar el popular neofetch, este ha sido el resultado:
Toolbox viene muy bien para hacer “tareas de riesgo” sobre un entorno Fedora sin que el sistema anfitrión sufra ninguna alteración que modifique su teórico buen funcionamiento. En caso de que un contenedor acabe roto por las circunstancias que sean, el usuario solo tiene que borrarlo y volverlo a crear.
Diseño del sistema de fichero (árbol de directorios)
Debido a que Silverbue y Kinoite son sistemas inmutables, los desarrolladores de dichas ediciones Fedora han decidido implementar algunos cambios en el árbol de directorios. Directorios como ‘/usr’ y ‘/bin’ son de solo lectura, mientras que ‘/etc’ sí permite modificaciones y el entorno de ejecución ha sido movido ‘/var’. Por otro lado, existen los siguientes enlaces simbólicos que parten de las ubicaciones “tradicionales” para minimizar el impacto de los cambios:
- /home → /var/home
- /opt → /var/opt
- /srv → /var/srv
- /root → /var/roothome
- /usr/local → /var/usrlocal
- /mnt→ /var/mnt
- /tmp → /sysroot/tmp
Se puede ver que tanto el directorio del usuario común como el de ‘root’ (administrador) han sido movidos a ‘/var’, que, como ya hemos dicho, es donde se aloja el entorno de ejecución de las ediciones inmutables de Fedora.
Estos cambios nos llevan a un pequeño detalle a tener muy en cuenta cuando se instala el sistema, y es que, en caso de querer poner las carpetas de usuario en una partición separada, lo suyo sería montarla en ‘/var/home’ y no en ‘/home’ (aunque en la versión 35 parece que ambas ubicaciones funcionan, pero oficialmente es ‘/var/home’).
Y ya que estamos con temas de instalación, otro paso muy recomendable es separar la carpeta de arranque (/boot) en una partición EXT4 de 1GiB.
Conclusión
A estas alturas, probablemente os hayáis dado cuenta de que estamos dando vueltas en torno a lo mismo: emplear tecnologías autocontenidas o de contenedores para así evitar la modificación del sistema principal. El concepto de aislamiento/sandbox es la base del ADN de Silverblue/Kinoite.
El concepto impulsado a través de OSTree no es solo un giro de tuerca en la gestión de los paquetes, sino que es todo un cambio de paradigma en la forma de usar de GNU/Linux. Otros sistemas que emplean este sistema de actualización son Endless, Fedora CoreOS, Fedora IoT, Red Hat Enterprise Linux CoreOS y GNOME Continuous.
Lo disruptivo de OSTree y el hecho de que no sea usado por los sistemas Linux más populares ha limitado su difusión entre los usuarios, pero la maduración de Silverblue y Kinoite (el segundo va un par de pasos por detrás) apunta a ser la puerta de entrada a la masificación de esta tecnología.
Sin embargo, este nuevo enfoque para los sistemas GNU/Linux puede terminar teniendo muchos detractores dentro de la comunidad, más viendo que esta, desde la consolidación de systemd, ha pasado en un porcentaje importante del vangurdismo al conservadurismo.
Para terminar, queremos avisar que, al menos de momento, tanto Silverblue como Kinoite no son plenamente funcionales para un arranque con múltiples sistemas operativos, así que recomendamos máxima precaución en caso de querer emplearlos en dicho contexto.
