systemd 259: cambios clave y requisitos del sistema

Informatec Digital » Recursos » systemd 259: cambios clave y requisitos del sistema

La aparición de systemd 259 como versión estable supone otro giro de tuerca en uno de los componentes más polémicos y esenciales del ecosistema Linux. Hablamos del marco de inicio y gestión de servicios que ya domina la mayoría de distribuciones, y que en esta entrega aprieta todavía más las tuercas en cuanto a requisitos técnicos, seguridad y abandono de tecnologías heredadas.

Esta actualización llega tras varios meses de trabajo intenso y se centra en tres grandes frentes: compatibilidad con nuevas bibliotecas C, endurecimiento de la seguridad y limpieza de código legacy (scripts SysV, TPM 1.2, iptables, etc.). Además, introduce cambios relevantes en la gestión de privilegios con run0, en el tratamiento de la memoria con systemd-oomd, en el almacenamiento de logs y en el modelo de dependencias internas de libsystemd.

systemd 259 y el soporte experimental para musl

Uno de los movimientos más comentados de esta versión es que systemd 259 incorpora por primera vez compatibilidad parcial con la biblioteca estándar de C musl. Esta biblioteca se utiliza mucho en sistemas ligeros, contenedores minimalistas y entornos embebidos, donde se busca simplicidad y un consumo reducido de recursos frente a glibc.

El soporte para musl se activa configurando la opción «libc» del sistema de compilación Meson con el valor «musl». No obstante, esta integración está lejos de ser completa: musl no implementa el mecanismo NSS (Name Service Switch), lo que obliga a deshabilitar varias piezas de systemd cuando se compila contra esta biblioteca.

En concreto, al construir systemd 259 con musl quedan fuera componentes clave como nss-systemd, nss-resolve, systemd-homed, systemd-userdbd y systemd-nsresourced. Tampoco está disponible la opción DynamicUser ni la posibilidad de ejecutar systemd-nspawn sin privilegios, algo especialmente relevante en entornos de contenedores donde se depende mucho de estas capacidades.

Los propios desarrolladores avisan de que no garantizan mantener este soporte a largo plazo. Su continuidad dependerá del interés real de la comunidad, de la madurez de las capas adicionales que aporten las funciones que musl no incluye y de los informes de errores específicos para esta biblioteca. Si la demanda es baja o el mantenimiento resulta demasiado complejo, no sería extraño que este soporte se revisara en futuras versiones.

Con todo, esta apertura hacia musl es importante a nivel simbólico: systemd llevaba años siendo criticado por su dependencia casi exclusiva de glibc, lo que lo hacía poco amigable para distribuciones alternativas y escenarios muy minimalistas. Este paso no soluciona todo, pero rompe con esa imagen de pieza totalmente cerrada a otras bibliotecas C.

run0 y el nuevo modelo de privilegios: alternativa a sudo

Otra gran protagonista de systemd 259 es la utilidad run0, planteada como sustituta moderna y más segura de sudo. Esta herramienta ya venía construida sobre systemd-run, pero ahora gana una capacidad clave: la opción --empower.

El nuevo argumento –empower permite iniciar una sesión con privilegios elevados sin cambiar el UID a root. En vez de hacer un cambio de usuario tradicional, run0 tira de las capacidades del kernel (por ejemplo, CAP_SYS_ADMIN) para otorgar exactamente los permisos que hacen falta para ejecutar acciones privilegiadas, reduciendo la exposición que supone convertirse en root por completo.

Además, los procesos que se arrancan con esta modalidad se agrupan en un grupo lógico «empower» con acceso a un conjunto amplio de acciones gestionadas por Polkit. La idea es que el aumento de privilegios sea granular y controlado, manteniendo una separación más estricta que la que suele ofrecer el sudo clásico, donde muchas veces se acaba abriendo demasiado la puerta.

Este enfoque encaja con la tendencia de evitar el uso directo del usuario root siempre que sea posible, algo muy valorado en seguridad. Ahora bien, la eficacia real de run0 aún tendrá que demostrarse en producción: habrá que ver cómo se integra con las políticas de cada distribución, cómo se configuran las capacidades en la práctica y qué tal se adapta la administración de sistemas al nuevo flujo de trabajo.

Fin del soporte a SysV init y limpieza de legado

systemd 259 supone también el inicio del fin definitivo de los scripts de servicio al estilo System V. La compatibilidad con estos mecanismos clásicos llevaba años marcada como “en retirada”, y ahora se concreta un calendario claro para su eliminación.

En esta versión se anuncia que, de cara a la siguiente gran entrega, desaparecerán componentes históricos como systemd-sysv-generator, systemd-rc-local-generator y systemd-sysv-install. Es decir, los scripts en /etc/init.d/ dejarán de ser tenidos en cuenta por systemd, lo que cierra una transición que se ha prolongado durante cerca de una década.

Para administradores que todavía mantenían servicios personalizados basados en scripts SysV, esto obliga a ponerse manos a la obra: hay que inventariar todos esos scripts y migrarlos a unidades nativas de systemd (.service, .socket, etc.). Las distribuciones grandes ya tienen casi toda esta transición hecha, pero en entornos a medida o instalaciones antiguas aún pueden quedar “reliquias” funcionando en segundo plano.

Este proceso de limpieza de legado no se limita a SysV. En versiones recientes de systemd ya se venía retirando soporte para métodos clásicos como /forcefsck o /fastboot, sustituyéndolos por parámetros de kernel y mecanismos de credenciales más modernos. Con 259, la dirección es la misma: menos compatibilidad hacia atrás a cambio de un código base más mantenible y coherente.

Requisitos mínimos de systemd 259: kernel, bibliotecas y entorno

Uno de los cambios que más impacto puede tener en sistemas antiguos es el aumento de los requisitos mínimos de software para ejecutar systemd 259. Esta versión ya no se preocupa por hardware ni stacks demasiado viejos, y empuja de forma clara hacia plataformas modernas.

Entre los requisitos destacados que se consolidan en systemd 259 están: una apuesta por plataformas modernas

• Kernel de Linux 5.10 como mínimo (con una recomendación de ir al menos a 5.14).
• glibc 2.34 como versión mínima de la biblioteca estándar GNU.
• OpenSSL 3.0.0 como base obligatoria para las funciones de cifrado soportadas.
• util-linux 2.37 como requisito para las utilidades básicas del sistema.
• libxcrypt 4.4.0 para la gestión de funciones criptográficas relacionadas con contraseñas.
• cryptsetup 2.4.0 y libseccomp 2.4.0 para cifrado de volúmenes y filtrado de llamadas al sistema.
• Python 3.9.0 como dependencia mínima para herramientas auxiliares.
• En algunas notas se menciona también elfutils 0.177 como parte del conjunto de dependencias actualizadas.

Este endurecimiento implica que equipos muy antiguos o distribuciones que se aferran a ramas de kernel previas a 5.10 quedan automáticamente fuera del soporte para esta versión, salvo que actualicen su base tecnológica. A cambio, se logra un ecosistema más homogéneo, con menos casos especiales y soluciones de compromiso.

Para la mayoría de distribuciones generalistas de escritorio y servidor, estos requisitos no deberían ser un drama: las ramas LTS modernas del kernel ya superan de sobra la barrera de 5.10, y las bibliotecas citadas están ampliamente difundidas. Los mayores problemas pueden llegar en sistemas embebidos, appliances o instalaciones muy conservadoras que no se actualizan con frecuencia.

seguridad reforzada: TPM 2.0, cifrado y restricciones de dispositivos

En el campo de la seguridad, systemd 259 aprieta el paso con varias decisiones de calado. La más visible es que systemd-boot y systemd-stub abandonan definitivamente el soporte para TPM 1.2, de forma que a partir de ahora solo se contempla TPM 2.0 como estándar de referencia.

Este cambio significa que, en sistemas que se apoyaban en TPM 1.2 para gestionar políticas de arranque seguro o claves de cifrado, será necesario actualizar el hardware (por ejemplo, cambiando la placa base) si se quiere seguir usando esas funciones con las nuevas versiones de systemd-boot. Muchos usuarios de escritorio Linux tienen TPM y Secure Boot desactivados, así que es posible que ni noten el cambio, pero en entornos corporativos o de alta seguridad sí puede tener impacto.

En entregas previas, como systemd 258, ya se habían realizado ajustes importantes en esta línea: OpenSSL pasó a ser la única biblioteca de cifrado soportada por systemd-resolved y systemd-importd, dejando fuera alternativas como GnuTLS y libgcrypt. Todo ello apunta a una consolidación en torno a un conjunto de herramientas criptográficas más reducido y controlado.

También en la rama 258 se introdujeron restricciones más severas de acceso por defecto a tty/pts: los nodos se crean con permisos 0600 en lugar de 0620, evitando que otros usuarios puedan escribir en nuestras terminales. Es otro ejemplo de cómo systemd lleva tiempo ajustando detalles de bajo nivel que, sumados, refuerzan la seguridad global del sistema.

libsystemd más modular y con carga dinámica

En busca de más eficiencia y de una menor carga de dependencias, systemd 259 introduce cambios profundos en la forma en que libsystemd interactúa con otras bibliotecas del sistema. El objetivo es que no todo se arrastre desde el inicio, sino que se cargue solo cuando hace falta.

Concretamente, libsystemd pasa a usar dlopen() para cargar dinámicamente librerías como libacl, libblkid, libseccomp, libselinux y libmount. Esto significa que estas dependencias no se enlazan de forma rígida en tiempo de compilación ni se cargan siempre en memoria: solo se activan cuando alguna funcionalidad específica lo requiere.

Este mismo mecanismo con dlopen() también se aplica a la integración con el subsistema de auditoría de Linux y con PAM. De esta forma, el arranque y la operación normal de systemd pueden ser más ligeros en entornos que no necesitan todas esas piezas al mismo tiempo.

Por otro lado, la funcionalidad proporcionada anteriormente por la biblioteca libcap se ha integrado directamente en libsystemd. Así se elimina una dependencia externa más, simplificando la cadena de construcción y reduciendo posibles puntos de fallo o incompatibilidad.

En líneas generales, este enfoque aporta una mejor modularidad y un menor footprint de memoria y disco, especialmente en sistemas donde se busca un arranque rápido y un conjunto de servicios muy ajustado.

Cambios en red y contenedores: adiós iptables, hola nftables

El área de redes y virtualización también sufre cambios relevantes. A partir de systemd 259, systemd-networkd y systemd-nspawn dejan de soportar la creación de reglas NAT mediante iptables/libiptc. El único backend de firewall admitido pasa a ser nftables.

Esto afecta directamente a contenedores gestionados con systemd-nspawn que dependían de NAT vía iptables, así como a redes definidas en systemd-networkd que utilizaban reglas de traducción de direcciones con el backend clásico. En pruebas con versiones candidatas, se han observado fallos silenciosos en la funcionalidad de NAT hasta que se migraba toda la configuración a nftables.

Más allá de la traducción de direcciones, systemd-resolved gana la capacidad de usar ganchos locales en /run/systemd/resolve.hook/, que se ejecutan cada vez que se realiza una consulta de resolución de nombres local. Esto abre la puerta a personalizaciones avanzadas de DNS y lógica específica por parte del administrador.

En el ámbito de la importación y gestión de imágenes, systemd-importd incorpora lógica nativa para trabajar con archivos TAR, apoyándose en libarchive de la utilidad tar de GNU. Además, tanto systemd-importd como systemd-machined pueden ahora ejecutarse en modo usuario, gestionando imágenes de sistema colocadas en ~/.local/state/machines/.

Para controlar estos modos, la utilidad importctl añade las opciones «–user» y «–system», permitiendo elegir fácilmente si queremos operar en el contexto del usuario o a nivel de sistema. Este enfoque resulta útil para entornos de desarrollo y pruebas donde no se quiere tocar la configuración global de la máquina.

Journal persistente por defecto y gestión del espacio en disco

Otro cambio con impacto práctico es la modificación del modo de almacenamiento por defecto del journal, el subsistema de logs de systemd. Hasta ahora, el comportamiento “automático” dependía de la existencia o no del directorio /var/log/journal.

Con systemd 259, el modo predeterminado pasa a ser «persistente», independientemente de si esa carpeta existía antes o no. Es decir, el journal se guardará en disco de forma permanente por defecto, en lugar de limitarse a almacenamiento volátil en RAM.

Esta decisión tiene pros y contras. Por un lado, facilita mucho el diagnóstico de problemas, ya que los logs sobreviven a los reinicios sin que el administrador tenga que hacer nada especial. Por otro, en sistemas embebidos, contenedores ligeros o entornos con almacenamiento muy limitado, puede traducirse en un aumento notable del consumo de disco.

En esos escenarios será más importante que nunca ajustar las políticas de rotación y tamaño del journal, o incluso forzar un modo de almacenamiento distinto si se quiere evitar un desgaste excesivo (por ejemplo, en memorias flash con ciclos de escritura limitados).

systemd-oomd, seguimiento de OOM y control de recursos

La gestión de memoria y los escenarios de “Out Of Memory” también reciben mejoras interesantes. El componente systemd-oomd, encargado de reaccionar ante situaciones de memoria insuficiente, incorpora nuevas propiedades para ofrecer más visibilidad.

En concreto, ahora se dispone de las propiedades OOMKills y ManagedOOMKills en los servicios, que recogen el número de procesos terminados por el kernel o por el propio systemd-oomd debido a falta de memoria. Esta información puede consultarse directamente con las herramientas de systemd, facilitando el análisis posterior de incidentes.

Cuando un proceso se descontrola y empieza a “zamparse” la RAM hasta el punto de poner en jaque al sistema, estas métricas permiten ver de un vistazo qué unidades se han visto afectadas, cuántas veces se ha disparado el mecanismo de OOM y qué componentes están provocando más presión de memoria.

Para administradores de entornos de alto nivel de carga o sistemas con recursos muy ajustados, esta mayor capacidad de observabilidad sobre los OOM resulta especialmente útil, ya que ayuda a identificar servicios mal dimensionados o fugas de memoria que antes podían pasar desapercibidas.

Otras mejoras notables en systemd 259

Además de los grandes bloques anteriores, systemd 259 viene cargado de numerosas mejoras y pequeños ajustes repartidos por todo el ecosistema. Muchas son muy técnicas, pero conviene repasarlas porque juntas suman un cambio relevante.

Entre las novedades de la API, la interfaz basada en el protocolo Varlink se amplía para permitir acceder a la configuración de servicios y ejecutar llamadas IPC como Reload() y Reexecute(). También se añaden llamadas específicas para manejar funcionalidades de systemd-repart, systemd-resolved y systemd-networkd.

En el terreno de configuración y unidades, se introduce la opción ExecReloadPost, que permite lanzar comandos justo después de recargar la configuración de un servicio. Además, los archivos de configuración que terminen en «.ignore» pasan a ser descartados automáticamente, un truco sencillo para desactivar ficheros sin tener que borrarlos o renombrarlos de forma más drástica.

Las unidades temporales ganan la propiedad RootDirectoryFileDescriptor, que define el descriptor de archivo correspondiente al directorio raíz, y se suma una nueva opción UserNamespacePath, que permite vincular una unidad a un espacio de nombres de usuario especificando una ruta en /proc. En systemd-nspawn, aparece la directiva NamespacePath en la sección de los archivos .nspawn para indicar el espacio de nombres de red a utilizar.

Otros componentes como systemd-sysext y systemd-confext incorporan ficheros de configuración dedicados en /etc/systemd/systemd-sysext.conf y /etc/systemd/systemd-confext.conf. Las variables de entorno SYSTEMD_SYSEXT_OVERLAYFS_MOUNT_OPTIONS y SYSTEMD_CONFEXT_OVERLAYFS_MOUNT_OPTIONS permiten ajustar las opciones de montaje para Overlayfs.

En el mundo de udev, se añade la opción OPTIONS=»dump-json» a systemd-udevd para mostrar el estado actual de un evento en formato JSON, la función net_id genera nombres predecibles para interfaces inalámbricas en sistemas con DeviceTree y se crean enlaces simbólicos /dev/gpio/by-id/... para dispositivos GPIO.

La parte de usuarios y cuentas también se refuerza: la base de datos de usuarios incorpora un campo UUID, la utilidad userdbctl admite la opción «–uuid» para buscar por este identificador, y homectl update ahora soporta «–recovery-key» para añadir claves de recuperación a cuentas existentes.

En systemd-homed se incorporan las opciones «–prompt-shell» y «–prompt-groups» durante el primer arranque mediante systemd-homed-firstboot.service, y en systemd-firstboot aparece «–prompt-keymap-auto» para preguntar por el mapa de teclado cuando se usa la consola local en el primer inicio.

El gestor de arranque systemd-boot suma la posibilidad de definir el nivel de detalle del log con el parámetro log-level en loader.conf o con el campo SMBIOS io.systemd.boot.loglevel. Además, se consolidan requisitos más estrictos para particiones como XBOOTLDR, que ahora debe ir en VFAT, en línea con lo que ya se pide a la ESP en sistemas UEFI modernos.

En el plano de red avanzada, systemd-networkd añade las opciones EmitDomain y Domain para el servidor DHCP y se implementa un controlador que determina los nombres de host emitidos a través de DHCP con ayuda de la resolución DNS. Por su parte, systemd-modules-load pasa a cargar módulos del kernel de forma paralela, reduciendo los tiempos de arranque en equipos con muchos controladores.

Finalmente, en el apartado de integridad, systemd-integrity-setup suma soporte para algoritmos HMAC-SHA256, PHMAC-SHA256 y PHMAC-SHA512, ampliando el abanico de opciones criptográficas disponibles para proteger la integridad del sistema.

Con todo este conjunto de cambios, systemd 259 se consolida como una versión muy técnica, exigente y claramente orientada al futuro. Empuja a dejar atrás tecnologías heredadas como SysV init, iptables o TPM 1.2, refuerza la seguridad y el control de recursos, mejora la modularidad interna y abre la puerta a nuevas configuraciones con musl, aunque sea de forma parcial y condicional. Para usuarios finales en distribuciones de lanzamiento puntual, muchas de estas novedades pasarán casi desapercibidas; para administradores y proyectos que vivan pegados a la última versión, es el momento de revisar cuidadosamente scripts, unidades y requisitos de hardware antes de dar el salto.