Después de poco más de tres meses de desarrollo, se ha dado a conocer el lanzamiento de la nueva versión de systemd 259. Esta actualización introduce cambios en la arquitectura del sistema, destacando la apertura hacia bibliotecas estándar alternativas, una gestión de privilegios más rigurosa y un endurecimiento de los requisitos técnicos para futuras versiones.
Uno de los movimientos más comentados en este ciclo es la transición hacia una mayor modularidad y la limpieza de dependencias heredadas, preparando el terreno para un ecosistema de Linux que se aleja definitivamente de los estándares de décadas pasadas.
Principales novedades de systemd 259
La nueva versión systemd 259 se destaca por ser la primera versión en añadir compatibilidad parcial con Musl, la biblioteca estándar de C popular en distribuciones ligeras y entornos embebidos. Esta integración se gestiona a través de la opción libc en el sistema de compilación Meson. Sin embargo, debido a que Musl no implementa la funcionalidad NSS (Name Service Switch), varios componentes de systemd permanecen desactivados en esta configuración.
Entre las ausencias notables al compilar con Musl se encuentran nss-systemd, nss-resolve, systemd-homed, systemd-userdbd y el parámetro DynamicUser. Además, no es posible ejecutar systemd-nspawn sin privilegios bajo esta biblioteca. Los desarrolladores han advertido que el mantenimiento de este soporte en versiones futuras dependerá de la demanda de la comunidad y de la estabilidad de las capas de compatibilidad adicionales que se desarrollen.
Otra de las novedades que presenta la nueva versión es en la utilidad run0, diseñada como una alternativa moderna y segura a sudo, la cual ha recibido la nueva opción –empower. Esta función permite iniciar sesiones con privilegios elevados sin necesidad de cambiar el identificador de usuario (UID) a root.
Ademas de ello, en lugar de delegar el control total mediante el cambio de usuario, –empower utiliza indicadores de capacidades del kernel, como CAP_SYS_ADMIN, para otorgar los permisos estrictamente necesarios para realizar llamadas al sistema privilegiadas. Además, los procesos resultantes se integran en un grupo específico que les otorga acceso a acciones de Polkit, manteniendo una separación de privilegios más robusta que el modelo tradicional de sudo.
El fin de una era: Adiós a System V y nuevos requisitos
systemd 259 marca el comienzo del fin para la compatibilidad con los scripts de servicio de System V. Se ha anunciado que en la próxima versión se eliminarán definitivamente componentes históricos como systemd-sysv-generator, systemd-rc-local-generator y systemd-sysv-install.
Junto a esta limpieza de código antiguo, se han elevado significativamente los requisitos mínimos de software para el ecosistema systemd:
- Kernel de Linux: Mínimo versión 5.10.
- Glibc: 2.34.
- OpenSSL: 3.0.0.
- Util-linux: 2.37.
- Otros: Python 3.9.0, cryptsetup 2.4.0 y libseccomp 2.4.0.
Modularidad y carga dinámica en libsystemd
Como parte de una iniciativa para reducir las dependencias directas en el arranque, libsystemd ahora utiliza carga dinámica mediante dlopen() para bibliotecas como libacl, libblkid, libseccomp, libselinux y libmount. Esto significa que el sistema solo cargará estas bibliotecas en memoria cuando sus funciones específicas sean requeridas por un proceso, optimizando el uso de recursos. Asimismo, se ha integrado la funcionalidad de libcap directamente en libsystemd, simplificando la cadena de dependencias.
El manejo de logs ha cambiado su configuración por defecto: el modo de almacenamiento del diario (Journal) pasa de «automático» a «persistente», independientemente de si el directorio /var/log/journal existía previamente.
En el ámbito de redes y virtualización:
- systemd-networkd y systemd-nspawn: Se elimina el soporte para reglas NAT mediante iptables, dejando a nftables como la única opción compatible.
- systemd-resolved: Ahora permite el uso de ganchos locales (hooks) en /run/systemd/resolve.hook/ para intervenir en las solicitudes de resolución de nombres.
- systemd-importd: Se ha integrado la lógica para trabajar con archivos TAR de forma nativa. Además, tanto importd como machined ahora pueden ejecutarse a nivel de usuario, permitiendo gestionar imágenes en el directorio local del usuario (~/.local/state/machines/).
Otras innovaciones
La API basada en el protocolo Varlink recibio mejoras para permitir el acceso a configuraciones de servicios y realizar llamadas IPC como Reload() y Reexecute(). Para los administradores de sistemas, la inclusión de la propiedad OOMKills en los servicios será de gran utilidad, ya que permitirá rastrear cuántas veces un proceso fue finalizado por falta de memoria directamente desde las herramientas de systemd.
Finalmente, el arranque del sistema se vuelve más moderno con la eliminación del soporte para TPM 1.2 en systemd-boot, centrando todos los esfuerzos de seguridad en el estándar TPM 2.0.
Si estás interesado en poder conocer más al respecto, puedes consultar los detalles en el siguiente enlace.
Continúar leyendo...