Novedades en systemd, IV

Lennart Poettering escribe artículos explicando las novedades en systemd. Parece que yo he venido a hacer lo mismo con resúmenes en español - que hago porque systemd es francamente interesante y proporciona a administradores y usuarios capacidades que todos deberían conocer. Así que he aquí esta nueva entrega de las noticias de systemd en los últimos meses (continuación de esta serie de posts) 

Estandarización de /etc

En primer lugar, han decidido intentar estandarizar tanto en ruta como en formato varios archivos de configuración básicos de /etc. Esta es una de esas cosas sencillas de hacer y de mero sentido común (¿de verdad es necesario que el archivo en el que se almacena el hostname tenga una ubicación diferente en cada distro?) que por puro politiqueo no se ha logrado hacer jamás. Para que luego digan que a Lennart Poettering le gusta romper cosas, systemd lee en primer lugar los archivos designados por la nueva estandarización, pero de no existir también soporta las divergencias individuales de cada distro, en caso de que aun no se hayan actualizado o no pretendan hacerlo.

Como consecuencia lógica de lo anterior, también pretende acabar a largo plazo con la diferencia entre /etc/sysconfig/* (RedHat/Suse) y /etc/default/* (Debian y derivados), aunque en este caso la pretensión no es de unificarlos sino directamente eliminar ambos, ya que la mayoría de lo que hay en ellos es inútil con la presencia de systemd, y lo restante no tiene sentido o no debería estar ahí. De nuevo, un cambio simple y de sentido común pospuesto durante demasiados años. 


Servicios instanciables

Algunos servicios, como CUPS o syslog, suelen tener una sola instancia funcionando en todo momento (nadie necesita dos syslogs funcionando simultáneamente). Existen, por contra, otros servicios que suelen instanciarse varias veces: un fsck para cada sistema de archivos a montar, un getty en cada terminal virtual. A estos últimos systemd los denomina "servicios instanciados" (yo prefiero "instanciables").

Para los servicios instanciables, systemd propone el uso de "plantillas" que permiten crear instancias desde la misma línea de comandos. Citando el ejemplo del enlace, existe una plantilla llamada serial-getty@.service, la cual puede recibir "objetivos" a instanciar como parámetros:

[Unit]

Description=Serial Getty on %I

BindTo=dev-%i.device

After=dev-%i.device systemd-user-sessions.service

[Service]

ExecStart=-/sbin/agetty -s %I 115200,38400,9600

De modo que el comando $ systemctl start serial-getty@ttyUSB0.service arrancará un getty en ttyUSB0. Y en el listado de servicios aparecerá cada instancia del servicio con su nombre. Y se puede detener la creación de nuevas instancias, desactivando la plantilla, sin que eso requiera detener las instancias ya iniciadas.

Este mecanismo permite hacer cosas muy curiosas. Mezclándolo con la capacidad de systemd de recibir conexiones a un puerto y pasar el socket abierto a otro programa, al estilo xinetd, Lennart propone que sshd sea un servicio instanciable. De ese modo, cada sesión ssh será una instanciación, y en el listado de servicios aparecerán todas las instancias, con la IP y puerto del usuario conectado como parte del nombre de cada instancia.

Otro ejemplo de estos servicios instanciables es como, en Fedora, han llegado al extremo de que, por defecto, en el arranque se inicia solamente un getty, el correspondiente a la tty1. Cuando el usuario pulsa (Ctrl+)Alt+F2, se instancia automáticamente el getty de tty2, pero no antes. De ese modo, el sistema se ahorra tener que configurar e iniciar preventivamente esos gettys.


Aislamiento de servicios

Linux soporta desde hace tiempo la capacidad de limitar varias capacidades de los procesos: aislarlo de la red, del resto de sistema de archivos, etc. Sin embargo, esta funcionalidad rara vez se usa. Con systemd, basta añadir una línea en la configuración del servicio. Por ejemplo, para que un servicio no pueda acceder a ningún tipo de interfaz de red presente en el sistema, basta añadir "PrivateNetwork=yes". He aquí una lista de capacidades de aislamiento, copiada del post de Lennart:

 · Aislar un servicio de la red: PrivateNetwork=yes

 · Proporcionar un /tmp virtual privado para el servicio: PrivateTmp=Yes

 · Prohibir acceso a directorios determinados: InaccessibleDirectories=/home /foo

 · Permitir el acceso a un directorio en modo de sólo-lectura: ReadOnlyDirectories=/var /bar

 · Limitar el número de subprocesos o, directamente, prohibir hacer fork(): LimitNPROC=1

 · Limitar el tamaño de los archivos, o incluso prohibir escribir nada: LimitFSIZE=0

 · Prohibir el acceso a todos los nodos de dispositivo de /dev excepto /dev/null: DeviceAllow= /dev/null rw

 · Limitar las capabilities de un proceso, por ejemplo, prohibir el uso de las interfaces de ptrace: CapabilityBoundingSet=~CAP_SYS_PTRACE


Y esto es todo, a falta de más novedades. Si algunos admiramos a Lennart Poettering y rechazamos las críticas que se le hacen no es por capricho: se trata de un programador excepcional que crea software excepcional.