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
