Todos sabemos quién es Emiliano “Linuxito” Marini: sysadmin por vocación y el siempre ácido y agudo autor del blog Linuxito.com. Seguramente sea, de toda la variopinta comunidad de blogs linuxeros en español uno de los que mejor expresa el conocimiento técnico, derivado de su trabajo de mantenimiento real de servidores, algunos incluso relativamente críticos. También creo que todos sabemos cuál es su opinión sobre systemd y el estado actual de los sistemas Linux y cómo dicha opinión, no precisamente buena, le ha llevado a nada más ni nada menos que dedicar cada vez más tiempo a experimentar con sistemas BSD y a escribir sobre ellos, a pesar del nombre y dominio de su blog. Hablamos, pues, de alguien absolutamente preparado que sabe perfectamente de lo que habla y cuyo blog no puedo dejar de recomendar en este primer párrafo de esta entrada.

Todos sabéis también que mi opinión sobre systemd ha ido evolucionando de un rechazo bastante radical a una especie de resignación en la que intento ver lo positivo de este nuevo “invento” sin dejar de lado nunca los peligros que entraña. No creo que el cambio sea malo por sí mismo, pero es verdad que systemd está rompiendo una forma de hacer las cosas –la filosofía UNIX– que, en buena medida, es la que nos ha protegido hasta ahora de que un error en una parte del sistema pueda conllevar la caída de la totalidad del mismo. La filosofía UNIX consiste en que un sistema operativo –e, internamente, cada programa– debe estar formado por muchas herramientas interconectadas que hagan, cada una, solo una cosa y bien. Está demostrado que crear sistemas siguiendo este diseño lleva a sistemas mucho más flexibles, mucho más fáciles de mantener y en los que la propagación del daño ocasionado por un fallo o un ataque es mucho más limitado justamente por esa división de funciones: si falla un componente, es muy poco probable que ese fallo pueda abarcar a muchos otros, ya sea porque se produce una incompatibilidad de interfaz o porque los permisos de ejecución son diferentes o por lo que sea.

Esto no quiere decir que la filosofía UNIX sea una panacea: de hecho comporta un coste técnico, que es el de la multiplicación de interfaces, la cual puede ser perjudicial, por ejemplo, en sistemas integrados con memoria escasa en los que hay que priorizar que la eficiencia de los recursos hasta el más mínimo detalle y no se pueden estar regalando preciosos kilobytes de memoria ejecutando más de uno o dos procesos para conseguir un resultado. Obviamente un sistema x86_64 no entra en ese tipo de casos, por lo que para administrar y dominar la complejidad –para algunos, el verdadero objetivo de la programación y la creación de sistemas– en tal plataforma, está bastante comprobado que es la filosofía UNIX la que aporta un fundamento conceptual sólido para ello.

Ahora bien, no nos engañemos: hasta la fecha no ha existido ningún sistema operativo que siguiera al pie de la letra en todos y absolutamente todos sus componentes la filosofía UNIX. Ni los antiguos UNIX comerciales, ni BSD ni menos los sistemas GNU/Linux: todos ellos operan con núcleos monolíticos que aúnan en sí una buena cantidad de tareas en vez de distribuirlas en una “red” de componentes separados como lo intenta hacer, por ejemplo, el núcleo GNU Hurd. Sin embargo, lo que está claro es que en esos sistemas el espacio de usuario sí se organizaba, mayoritariamente, según la filosofía UNIX, con excepciones muy concretas como X11 –que aúna en sí mismo la gestión de dispositivos de entrada y la gestión de pantallas, tanto respecto del hardware como del software–, los entornos gráficos –en especial KDE 2.x y 3.x comparado con GNOME 2.x– y algunas herramientas de GNU como, por ejemplo, el famoso ejemplo de Emacs o el menos conocido caso de las opciones de grep que permiten incluso ejecutar código arbitrario sobre los resultados obtenidos. Hay otras “violaciones” de la filosofía UNIX más restringidas como, por ejemplo, algunas opciones de ls o de cat o de otros programas que podemos considerar “típicamente UNIX” que llevan a que se integren en un único punto funciones que, quizás, deberían constituir un programa en sí mismo que podamos hacer que se comunique con el otro. Aún así, es indudable que a grandes rasgos los sistemas Linux con espacio de usuario GNU o los BSD o los UNIX comerciales sí seguían una arquitectura general basada en la filosofía UNIX.

El proyecto systemd rompe con eso deliberadamente, como sabéis. Insisto en que puede haber buenas razones para decidir romper con la filosofía UNIX, siempre y cuando uno ofrezca algo mejor que esté justificado para el contexto en el que se quiere aplicar una solución “nueva”. El arranque del espacio de usuario era un desastre mayúsculo, nos gustara o no: era una maraña de scripts organizados manualmente en un árbol jerárquico mediante priorización de los nombres de archivos. En el interior de muchos de ellos se repetía código de otros scripts que no se podía reutilizar porque unos y otros operaban en runlevels diferentes, por lo que era técnicamente imposible importar código dinámicamente para evitar tal duplicidad. Como ya os imaginaréis, esta situación complicaba muchísimo la depuración del arranque y, también, el mantenimiento de paquetes en distribuciones. Por eso, primero Canonical con Upstart y luego una porción de Freedesktop.org con systemd, se buscó un reemplazo que generara el árbol de dependencias de arranque por sí mismo del mismo modo que lo hacen los gestores de paquetes: el “humano” se dedica a crear unidades de descripción que enumeran las dependencias y es el ordenador quien genera el árbol de estas automáticamente a partir de esas unidades de descripción. Hasta aquí creo que todos estamos de acuerdo y que todos firmaríamos por una solución que solamente consistiera en eso.

El problema está en que en el mundo real systemd tuvo que incorporar cada vez más conocimientos sobre cada vez más partes del sistema para poder generar mejor el árbol de dependencias. Hasta cierto punto esto era deseable, pero el punto de inflexión que todos recordaréis fue la absorción de udev por parte de systemd y que llevó a Gentoo a apoyar OpenRC, además de un fork de udev que no dependiera de systemd. Dicha absorción implicaba que lo que antiguamente iba a ser un gestor de arranque de servicios arrancaría y gestionaría también la detección de hardware del sistema. A partir de aquí, systemd ha ido agregando justificada e injustificadamente pero siempre a pasos agigantados todas aquellas funciones que podríamos decir que operan en “segundo plano” en un determinado sistema, ante las advertencias de administradores de sistemas y de programadores, que alertaban y siguen alertando de que systemd estaba cambiando la arquitectura general de las distribuciones Linux más conocidas y la estaba transformando en algo cada vez más monolítico y cada vez más alejado de la filosofía UNIX. ¿El gran miedo? Que alguien descubra una vulnerabilidad de seguridad en systemd que pueda afectarlo por completo y, por tanto, acabar afectando toda la ejecución de un determinado sistema… Y no os olvidéis de que ya nos hemos enfrentado a un fallo de systemd –que Poettering no lo considera como tal– que puede dejar a un sistema UEFI inutilizado de forma irreparable simplemente mediante el borrado de unos archivos (el infame Issue #2402).

Por otro lado, hemos de convenir que systemd hace lo que hace de forma mucho más que correcta. Ya sabéis que utilizo systemd-boot –aunque realmente systemd-boot no funciona como parte integral de systemd– y que uso una imagen initramfs basada en systemd, lo cual permite sacar fuera de juego unos cuantos elementos del arranque del espacio de núcleo (kernelspace). La implementación de NTP de systemd es mucho más confiable que el antiguo y poco mantenido NTPd (si os interesa, consultad el funcionamiento de timectl), gracias a logind se ha podido encapsular X11 de manera que no funcione con privilegios de superusuario y un largo etcétera del cual no nos podemos olvidar la objetiva simplificación de la gestión de servicios. Ahora bien, sí, todas estas ventajas han tenido un precio: el precio de tener que consentir que systemd se apropie de todas estas funciones.

Toda esta introducción me ha parecido absolutamente necesaria para poder entender exactamente de cuál es la última polémica con systemd. Si hasta ahora systemd iba apropiándose de la gestión de casi todo aquello que se ejecuta en segundo plano y, por tanto, no cambiaba el comportamiento del sistema en sí, ahora ha dado un salto a la gestión de procesos de primer plano que cambia el comportamiento del sistema tal y como lo conocíamos. Bienvenidos al problema de KillUserProcesses y la solución propuesta por el propio systemd, systemd-run… el cual básicamente es un entorno de ejecución de programas.

Hasta systemd 229, los procesos iniciados por un usuario se ejecutaban hasta que estos terminaran por sí mismos o recibieran una señal de interrupción por parte del núcleo. Por ejemplo, un proceso de usuario podía continuar funcionando incluso cuando ese usuario cerrara su sesión o si, por alguna razón, la sesión se interrumpiera. Esto nos ha salvado la vida a muchísimos usuarios en muchísimas ocasiones cuando, por ejemplo, se tiene la mala suerte de perder la conexión a la red mientras se está conectado a un servidor mediante un túnel SSH. Al perderse la conexión, SSH cierra la sesión de usuario en el servidor, pero como el proceso que se hubiera iniciado continuaba hasta que acabara, no había riesgo ni de corrupción de datos ni de que se produjera ninguna consecuencia inesperada. Tan solo bastaba con volver a entrar en el servidor y continuar con lo que uno estuviera haciendo. Los que hemos trabajado con SSH usando una mala conexión sabemos que esto puede ser pan de cada día.

A partir de systemd 230, que es la versión estable actual –si es que se puede hablar de versiones “estables” de systemd–, systemd se encarga de matar todos los procesos de un usuario cuando se cierra la sesión, ya sea deliberada o accidentalmente. La razón de esta decisión está en que en ocasiones, al ejecutarse el cierre de sistema, procesos de usuario como PulseAudio se quedaban colgados esperando una orden y activaban la cuenta atrás de 90 segundos que seguramente habréis sufrido más de alguna vez al apagar un sistema Linux con systemd. Así pues, el equipo de systemd optó por la decisión más radical de que los procesos mueran al cerrarse la sesión del usuario, en un alarde de la filosofía “muerto el perro, muerta la rabia”.

Este comportamiento, que puede ser útil en un sistema de escritorio, es desastroso para un servidor. Una de las constantes de systemd, justamente, es pensarlo todo con la lógica de los sistemas de escritorio, ignorando que los sistemas Linux son usados mayoritariamente en servidores. Pues bien, el escenario de pérdida de conexión en una sesión SSH, en un sistema con systemd 230 se transforma en un peligro absoluto: predeterminadamente el proceso morirá y el sistema quedará en un estado no predecible, cosa que no debería suceder jamás.

Conscientes de este problema, al equipo de systemd se le ocurre proveer dos formas para evitar tal problema, pero ambas son parches para un problema que han inventado ellos mismos. La primera es que se puede configurar systemd para que utilice el comportamiento previo a la versión 230; se puede activar para la sesión usando loginctl enable-linger o de forma permanente estableciendo KillUserProcesses=no en /etc/systemd/logind.conf. La segunda es utilizar una aberración llamada systemd-run para ejecutar un proceso de forma que no muera con el cierre de sesión, ya que el proceso, aunque nominalmente se ejecutará en nombre del usuario, dependerá del proceso de systemd, que se ejecuta como root. Esto es aberrante por lo que implica: como ya he adelantado arriba, esto implica que systemd ya no es solo un gestor de lo que sucede en segundo plano, sino que ya directamente gestiona lo que sucede en primer plano, interponiéndose entre el sistema operativo y el usuario sin que haya realmente una justificación técnica para ello… y que una de las soluciones sea utilizar systemd como entorno de ejecución de programas ya es el colmo.

Si volvemos a la cuestión de la filosofía UNIX, tenemos que darnos cuenta de que systemd, que ya había roto la lógica UNIX en la gestión de los procesos de segundo plano, ahora la ha roto para los procesos de primer plano. Una de las bases de la filosofía UNIX es justamente lo que se llama “transparencia”; es decir, que los programas ejecutados se deben comportar de forma clara y predecible siempre respetando sus interfaces. Los programas no han cambiado con este cambio de systemd, pero ha sido este último el que cambia el comportamiento de los programas ejecutados a un comportamiento que es contrario a la práctica habitual y recomendable e intuitiva: lo normal y lógico es que un programa finalice cuando este deba finalizar o que, si debe ser finalizado por acción externa, lo sea por razones extraordinarias justificadas. El cierre de sesión no está en esas razones por lo que he explicado sobre los servidores y hablamos, como he dicho también antes, de un sistema mayoritariamente utilizado en servidores antes que en sistemas de escritorio. Cierto, ni Linux ni ningún otro sistema operativo ha seguido jamás al pie de la letra la filosofía UNIX, pero donde la seguían mejor era, justamente, con respecto a los procesos ejecutados por el usuario. Y, por último, qué decir de la simple existencia de systemd-run: que systemd ahora pueda ejecutar programas y definir su entorno de ejecución lo deja a un paso de transformarse en un espacio de usuario (userland) monolítico.

Los que tengáis servidores con systemd, estad atentos cuando os llegue la versión 230 a vuestra distribución, porque no podéis arriesgaros a un minuto con este comportamiento activado. Por ahora la situación no es grave porque las principales distribuciones para servidores no utilizan systemd 230, pero os llegará tarde o temprano: la próxima Debian 9.0 “Stretch” ya tiene systemd 230 en sus repositorios, por ejemplo, y todo dependerá de si deciden cambiar la configuración predeterminada o no. El tren se acerca y, en el intertanto, a ver qué otras cosas nos depara.

Insisto: a diferencia de Emiliano, me gusta la idea de systemd porque la gestión de los procesos de segundo plano era poco menos que caótica y redundante en los sistemas Linux. Objetivamente systemd hace muy bien todo aquello que debería hacer bien, pero es hora de que alguien le pare los pies ahora que han entrado en terrenos que no tienen nada que ver con lo que se supone que es su objetivo. No hay nada de malo en que los desarrolladores de systemd tengan ideas que sobrepasen el ámbito que debería tener systemd, pero entonces deberían crear proyectos diferenciados e independientes de systemd: systemd-boot, por ejemplo, que no es otra cosa que la continuación de Gummiboot, debería ser un proyecto diferente porque vale la pena como reemplazo del anticuado y farragoso GRUB. Ahora bien, cada vez que cae una noticia de que systemd asume una nueva responsabilidad no puedo dejar de pensar que, en buena parte, Emiliano tiene razón: systemd es un peligroso en sí mismo… Yo diría que es una idea peligrosa porque es una idea muy buena que se está llevando sin razonabilidad ninguna a extremos donde deja de ser tan buena.

Sí, la libertad tiene el peligro de que puede producir efectos que nos gusten y encuentro fantástico que exista un grupo de desarrolladores como el de systemd que tengan la valentía de romper esquemas preestablecidos, pero tienen que ser concientes de los efectos de sus decisiones y comunicarlas bien alto y bien claro para que las distribuciones tomen las cartas en el asunto que mejor consideren para sus fines. El proyecto systemd se está transformando en el eje central del funcionamiento de las distribuciones Linux y es hora de que entiendan cuán importante puede ser cualquier cambio que ejecuten.

Mi cábala es que tarde o temprano alguien hará un fork de systemd que sea una especie de “systemd-lite”. Soluciones como OpenRC son soluciones que miran al pasado y no aportan las ventajas incontestables de la interfaz de gestión de servicios que proporciona systemd. Sin embargo, con esta incursión inédita en los procesos de usuario, si ya discutíamos sobre si el nombre del sistema operativo es “Linux” o “GNU/Linux”, ahora tendremos que empezar a pensar seriamente si el nombre correcto no es más bien “systemd/Linux” o “systemd” a secas.


Fuente: https://etccrond.es/2016/06/linuxito-tiene-razon.html
______________________________________________________________________
Lista de correos del Grupo de Usuarios de Tecnologías Libres de Cuba.
Gutl-l@jovenclub.cu
https://listas.jovenclub.cu/cgi-bin/mailman/listinfo/gutl-l

Responder a