16 de abril de 2011

Novedades en systemd, III

(Continuación de esta serie)

Tal vez muchos de ustedes ya crean que systemd es de por si bueno y suficientemente interesante. Pues aun no han visto nada. Hoy toca hablar de dos nuevas características de systemd, que son una prueba de hasta que punto las cosas pueden mejorar dramáticamente cuando si se replantean a lo grande y con talento.

La primera tiene que ver con los chroot's. Últimamente me he dado cuenta (escuchando el podcast de Pánico en el Núcleo, por ejemplo) de que las cosas demasiado técnicas pierden a la gente, así que me pregunto si todo el mundo que lee esto sabrá que es un chroot. Lo resumiré diciendo que si uno tiene una distro en, por ejemplo, /mnt/debian, basta ejecutar "chroot /mnt/debian" para conseguir un shell que tenga como raiz (/) ese directorio, como si estuviera dentro de esa distro. En realidad, chroot es una forma antigua y muy primitiva (aunque también versátil) de virtualización, y suele utilizarse para todo tipo de cosas; en el caso de sistemas de inicio para crear una sandbox en servicios para mejorar la seguridad (pero no mucho, hace tiempo que se sabe que chroot no es nada seguro).

El caso es que Linux soporta, desde versiones tempranas, una característica inventada por Plan 9, llamada "diferentes espacios de nombres del sistema de archivos", que consiste en que cada proceso del sistema puede tener, opcionalmente, una visión diferente de los directorios del sistema de archivos. Un proceso puede, por ejemplo, montar un sistema de archivos en /mnt, o eliminar un directorio, y que esa operación solo sea visible para él, mientras el resto de procesos del sistema no se entera de nada. Con esto se puede implementar una sandbox al estilo chroot pero con seguridad de verdad.

Systemd permite a los servicios explotar esta característica añadiendo a los archivos de configuración una línea como "InaccessibleDirectories=/directorio", que hace que /directorio simplemente no sea visible ni accesible por el proceso. También está "ReadOnlyDirectories=/etc", que hace que /etc sea visible, pero en modo de solo lectura. Y, por cierto, también permite crear chroots simples con "RootDirectory=/directorio/del/chroot".

Pero no se queda ahí, uno de los problemas tanto de los chroots como de la nueva solución propuesta es que los números de los PIDs se comparten entre todo el sistema, así que se ha creado un comando, systemd-nspawn, que a lo anterior añade las capacidades de virtualización de PIDs del kernel, es decir, que permite crear una especie de contenedores/jaulas/zonas muy simples. Con lo cual, uno puede arrancar una distro con un comando como "$ systemd-nspawn -d /directorio/de/distro/debian /sbin/init". O sea, un sustituto del comando chroot.

La segunda característica que se ha añadido a systemd es la medición del tiempo de inicio, tanto de todo el sistema como de cada servicio. Para empezar, en cada inicio se deja en los logs un mensaje que notifica que el inicio se ha completado, el tiempo total que se ha tardado, y qué porción de tiempo se ha empleado en arrancar el kernel y cual en los programas de inicio. Con el comando "$ systemd-analyze blame" se puede ver una lista de todos los servicios iniciados y el tiempo que tardan en iniciarse cada uno. Y, finalmente, se ha integrado una especie de bootchart simple que puede verse con el comando "$ systemd-analyze plot > foo.svg".

Repito, un ejemplo de lo mucho que pueden mejorar las cosas cuando alguien con talento se las replantea como Dios manda.

3 comentarios:

  1. Wow.. Gracias..

    Ahora veo que mi maquina, algo viejita ya, gasta casi 5 segundos en iniciar sendmail.. Que yo sepa, no es necesario para una maquina domestica.. ¿No?

    ¿Como puedo desactivarlo? Estoy usando la beta fedora 15.

    Como siempre, muy buena la info.
    Saludos.

    ResponderEliminar
  2. Anónimo10:06 p. m.

    matias: yum remove sendmail

    y añade esto a /etc/sysconfig/crond:
    CRONDARGS="-s -m off"

    para que los mensages de cron se almacenen en syslog en vez de utilizar sendmail

    Hay una propuesta para eliminar el MTA (sendmail) de la instalacion por defecto:
    http://fedoraproject.org/wiki/Features/NoMTA

    ResponderEliminar
  3. matias: Aparte de lo que te ha dicho jjardon, con systemd lo harías con "systemctl disable NetworkManager.service"

    ResponderEliminar