Systemd, ¿será un estándar de facto?

Imaginemos un sistema para la gestión de demonios (servicios) que sea extremadamente fácil de configurar y administrar, que aproveche al máximo las capacidades del núcleo del sistema operativo, que nos proporcione mecanismos para securizar nuestro sistema, de manera simple y fácil. Pues esto existe y se llama systemd.

Una breve introducción.

Este sistema surge como alternativa al clásico SysVinit, de la mano de Lennart Poettering, Kay Sievers, con el apoyo por parte de Red Hat.

Es mucho más que un simple lanzador de demonios: Incorpora journal (para los logs), permite temporizar acciones (cron), paraleliza la ejecución de demonios, centraliza la configuración del sistema, permite vigilar directorios y archivos (lanzando acciones, según los eventos producidos), gestiona dependencias de demonios y un largo etc.

Utiliza Cgroups, una característica de Linux, que permite un control excelente sobre la ejecución de los demonios, entre otras cosas. Esta característica es la utilizada por LXC, para virtualizar, por ejemplo.

Un ejemplo de la utilización de systemd como cron, la encontramos aquí. Una implementación que permite la sustitución de estos demonios, la encontramos aquí.

Un ejemplo de fortificación de demonios,  sería ésta. Vemos cómo fortificar fail2ban, que se ejecuta con usuario root, es extremadamente sencillo y comprensible. Todas las opciones disponibles, las encontramos aquí.

Fácil, simple y limpio. Seguro que si no conocías estas opciones, estás ya fortificando el sistema….

Dado que el clásico sistema de inicio estaba algo obsoleto, Ubuntu creó su propio sistema, upstart, que también acelera el arranque, paralelizando la ejecución de demonios, pero no incorpora las bondades de systemd.

Hace poco, Red Hat y CentOS han anunciado su mutua colaboración. Además, Red Hat migrará a systemd en su próxima versión. Esto hace que, aquellas distribuciones que todavía no han migrando a systemd o upstart, tengan que considerar cambiar su sistema de inicio.

Si Ubuntu optara por systemd, se convertiría en un estándar automáticamente. No nos engañemos: Aunque systemd sea mucho mejor, sería, de manera indirecta, un reconocimiento, por parte de Canonical, de una derrota frente a Red Hat.

Debian, ¿está en tu mano?

Bajo mi punto de vista, la reina de la estabilidad, Debian, es quién, realmente, podría hacer que systemd sea un estándar. Si lo adopta, todas sus hijas, menos una, lo adoptarán. Dado que algunas nietas se están planteando cambiar el sistema base a Debian, serían más. A esto le añadimos el prestigio de Debian, que aumentaría la popularidad y la confianza en systemd.

Conocemos a Debian por ser un sistema GNU/Linux, sin embargo, Debian es mucho más. Además de ofrecer un sistema con Linux, lo ofrece con Hurd y con kFreeBSD. Aquí está el problema para migrar a systemd.

Alternativas y efectos colaterales.

Veamos las posibles opciones, a grandes rasgos, con mi humilde valoración:

• Sysvinit: En el plano de servidores, tendría que competir con las distribuciones que, al utilizar systemd, añaden un mecanismo fácil de configurar, para securizar y con soporte de sockets, dbus, etc, necesario en un sistema actual. Ninguna variante de esta opción soporta cgroups o dbus, lo que, en un sistema actual, podríamos decir que este sistema de inicio, para Linux, está obsoleto. Además, requiere de un esfuerzo adicional para el mantenimiento de los init scripts. Esto puede afectar al status de estabilidad.
• Upstart. Opción algo mejor, pero con un inconveniente: Abusa de ptrace, lo que complica enormemente la depuración del proceso de inicio. Esto, a largo plazo, puede afectar a la estabilidad. Además, sigue sin utilizar nativamente cgroups y otras características, lo que hace más complejo llegar al mismo nivel de securización o mantenimiento que permite systemd.
• Systemd. La mejor opción, sin duda, para Linux. Sin embargo, require hacer «apaños» para kFreeBSD. Esto hace que aumente el nivel de acoplamiento en las variantes con kFreeBSD o Hurd, lo que obliga a un esfuerzo extra para mantener la estabilidad.

Conclusión.

La opción systemd es la tomada por grandes distribuciones como Fedora, ArchLinux, OpenSUSE, Mageia, Red Hat (a partir de la siguiente versión), Sabayon Linux, etc. lo que ofrece un amplio soporte, de una gran calidad.

Basadas en SysVinit solo quedan Slackware, utilizando la variante BSD y Gentoo, con su propia versión, pero que no soporta dbus y, cgroups, lo hace de manera rudimentaria y experimental (a efectos prácticos, no lo soporta).

Independientemente de la opción por defecto elegida, las distribuciones que no utilizan systemd, lo ofrecen como alternativa.

Si no has probado systemd, te recomiendo que lo pruebes, en Debian, Ubuntu y Gentoo, podemos encontrarlo en sus repositorios como versión alternativa, para que puedas comprobar las ventajas que ofrece.

Algo me queda claro: Este sistema consigue una configuración fácil de administrar y de depurar, dando soporte a las necesidades actuales y aprovechando las ventajas que Linux nos ofrece, que va a facilitar enormemente el día a día de los administradores de sistemas, aumentando la productividad.

Por mi parte, he hecho un breve resumen, para una mayor comprensión de las opciones, ventajas, inconvenientes y posición de los desarrolladores de Debian, podéis seguir el debate aquí.

Tome Debian la decisión que tome, tiene riesgos que asumir y va a levantar ampollas, así que, cojan sus palomitas, tomen asiento y disfruten de esta película.