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.

La oportunidad de Ubuntu TV

En su día dejé a Ubuntu por Fedora, pero nunca hice ese cambio porque Ubuntu me pareciera mala distro (a diferencia de cuando dejé Debian), sino porque Fedora me parecía mejor. Con esto quiero decir que sigo considerando a Ubuntu la mejor distro Linux de escritorio en general, y a Canonical la Red Hat del escritorio.

Especialmente importante me parece el último punto, que Canonical sea como Red Hat. Como he defendido otras veces aquí, el éxito de Linux en el escritorio o en cualquier lado no puede basarse sólo en gente que contribuye en su tiempo libre. Es un crítico que existan empresas grandes, rentables y prósperas dispuesta a contratar a jornada completa a unos cuantos programadores, como Red Hat o Suse hicieron en servidores. Solo así es posible ser competitivos.

Y, en ese sentido, Ubuntu TV me parece una gran noticia, aunque técnicamente no esa "escritorio Linux".

Si, es cierto que sólo se ha presentado el software, y que ningún fabricante de televisiones se ha dignado a pasarse por allí para mostrar algún prototipo. También es cierto que Ubuntu TV podría quedarse en fracaso si no aparece ninguno. Y no es menos cierto que Ubuntu carece de lazos con las grandes multinacionales distribuidoras de contenidos (que en realidad es el mayor problema). Ah, y no olvidemos que Ubuntu es un objetivo potencial de los ataques monopolistas de las patentes de software.

Pero Ubuntu TV tiene una ventaja, y es que existe. Las "televisiones inteligentes" no son nuevas, tampoco lo son los tropecientos mil softwares y hardwares para Media Center. Sin embargo, se espera que haya un boom en el campo. Y el mero hecho de existir y estar ahí puede dar a Ubuntu TV la oportunidad de ser utilizado por un fabricante desesperado por no quedarse atrás, o uno que quiera probar varias opciones para saber cuál gusta más a sus clientes.

Cuando la aparición del iPhone hizo que los teléfonos táctiles se convirtieran en el estándar, el mero hecho de "estar ahí" fue fundamentalmente lo que acabó dando a Android el puesto de primer SO para smartphones. De haberse dado Microsoft más maña, hubieran sido ellos los ganadores. No sé hasta qué extremo llegará el tema de las televisiones inteligentes, ni cómo se acabará interactuando con ellas, ni si las distribuidoras de contenidos se han decidido ya a permitir a la gente pagar por contenidos o quieren seguir forzándoles a usar Megaupload descargas ilegales. Pero Ubuntu TV está ahí, y gracias a eso podrá tener una oportunidad.

Incluso si fracasa estrepitosamente y Ubuntu TV desaparece, el mero hecho de haber intentado anticiparse marca una diferencia fundamental con la que ha sido la tradición linuxera en la informática de consumo, que consistía en llegar mal y tarde a las novedades tecnológicas, y lloriquear porque las multinacionales privativas acaparaban todo.

Y si Ubuntu TV tiene algo de éxito, imagínense: podran ganar dinero y reinvertirlo. Quien sabe, incluso podrían hacer algo que contente a los críticos con Unity.

Windows y su nuevo sistema de archivos, ReFS

Microsoft ha publicado algunos detalles sobre un nuevo sistema de archivos, ReFS, "Resilient filesystem". Resumiendo mucho, se trata de un "ZFS para Windows" (pero hay matices que comentaré en este post que, para cambiar un poco, es sobre una noticia de hoy). Es más, mirando fechas no hay que ser un genio para darse cuenta de que fue desarrollado tras la aparición de ZFS y con el propósito de imitarle.

Lo cual no viene más que a confirmar una vez más el enorme impacto que ha tenido y sigue teniendo ZFS. Si tenemos en cuenta que para desarrollar y estabilizar un sistema de archivos son necesarios unos cuantos años, lo que se ha vivido en los últimos 7 años que han pasado desde que apareció ZFS es en realidad una revolución repentina y violenta en el mundillo: ha obligado a todo el mundo a desechar miles de líneas de código de una de las partes más críticas que hay en un sistema operativo, y reimplementarlo de cero.

ReFS merece, sin embargo, algunos comentarios. Teniendo en cuenta lo poquísimo que se puede comentar sobre un sistema de archivos de Microsoft, de los que nunca se sabe casi nada. Ni tan siquiera existe buena documentación pública sobre NTFS.

· Si leen el blog de Microsoft, verán que se afirma que no es una reescritura completa de NTFS, sino una reescritura de su "motor de almacenamiento". Esta afirmación puede llevar a pensar que se ha reescrito sólo "la parte de NTFS que escribe cosas al disco". Mi opinión es que esta idea se trata de una confusión: La diferenciación conceptual clara entre "VFS" y "sistema de archivo" es una noción muy linuxera. En Linux el VFS implementa, por ejemplo, la gestión del caché, y todos los sistemas de archivos lo reutilizan. En NTFS (o en ZFS) el "sistema de archivos" suele implementar casi todo por su cuenta (nadie soporta tantos sistemas de archivos como Linux, así que no tienen tantos incentivos para generalizar y reusar esas partes). Por eso, lo que Microsoft llama "cambio del motor de almacenamiento", en Linux se llamaría "nuevo sistema de archivos".

 · Al igual que Btrfs, parece que han escogido un espacio de direccionamiento de 64 bits, y no de 128 bits, como hizo ZFS. Que, en realidad es lo más lógico. Los 128 bits de ZFS son una exageración que quizás ZFS nunca llegue a necesitar. La verdad es que tampoco es tan importante, tanto 64 como 128 bits son una barbaridad.

· ReFS utiliza, como es de esperar en cualquier derivado de ZFS, técnicas de "copy-on-write" ("allocate-on-write", lo llaman ellos): Cuando se cambia algo, en lugar de escribir sobre los bloques que contienen los datos viejos, lo que se hace es escribir en bloques vacíos. Una vez escritos, las estructuras de datos que apuntaban a los datos viejos se modifican -también, a su vez, usando "copy-on-write"- para que apunten a los nuevos.

· Es curioso, sin embargo, que por defecto, cuando se utilice un sólo disco, ReFS no utilizará copy-on-write en los datos y, aparentemente, tampoco checksums, sólo en los metadatos. Se activarán por defecto sólamente con múltiples discos, en discos únicos habrá que hacerlo manualmente, en el formateo. Es decir, en configuraciones unidisco ReFS será, por defecto, equivalente a Btrfs montado con las opciones "nodatacow" y "nodatasum". Sin embargo, será posible activar ambas características manualmente para archivos y directorios determinados (Btrfs también permite desactivar esas características a nivel de archivo). Para ello, las aplicaciones, o los usuarios, tendrán que marcar un archivo como "integrity stream".

· Como ZFS, ReFS soporta "scrubbing", es decir, un proceso de validación de todos los checksums del sistema de archivos. Sin embargo, las aplicaciones podrán deshabilitar el scrubbing para un archivo determinado, del mismo modo que se desactiva el "integrity stream".

· ReFS utiliza una estructura de árbol, para representar en el disco todos los metadatos. Se utiliza la implementación del árbol lo mismo que un roto que para un descosido: un árbol puede almacenar un listado de directorios, otro puede almacenar la lista de extents de un archivo, y los nodos en los árboles que pueden apuntar a otros árboles.

· Sin embargo, no conocemos detalles de la implementación del B+Tree de ReFS. Btrfs utiliza una estructura de datos creada de un trabajador de IBM, que lo diseñó explícitamente para crear un sistema de archivos tipo ZFS (a quien le gusten las discusiones de estructuras de datos y algoritmos puede echarle un ojo). La verdad, no tengo ni idea de si la implementación de ReFS será mejor, peor, o incluso una copia disimulada. Y nunca lo sabremos, porque Microsoft nunca llegará a este nivel de detalle.

· Aunque parezca sorprendente, ReFS no parece implementar por si mismo ningún tipo de capacidad de replicación de datos o metadatos, ni de gestión de múltiples discos en forma de "pool". Quien lo implementará será "Storage Spaces", un gestor de volúmenes que verá la luz en Windows 8 y que implementará esas funciones tanto para NTFS tradicional como para ReFS.

· Por ello sospecho (aunque no puedo asegurar) que a diferencia de ZFS y Btrfs, que han reescrito de cero su propio gestor de volúmenes, Microsoft ha decidido extender su gestor de volúmenes para implementar nuevas características. No estoy seguro del alcance de esta decisión: en Linux también podrían haberse implementado algunas características de ZFS extendiendo Ext3 y LVM, y Btrfs podría haberse implementado sobre ese LVM mejorado. No se hizo así, pero Microsoft parece haber intentado esa vía.

· Probablemente como consecuencia de lo anterior, y a falta de más detalles, parece ser que ReFS es incapaz de duplicar metadatos dentro de una misma partición, como si hacen ZFS y Btrfs. Es más, no parece que a la hora de duplicar ReFS permitirá diferenciar entre replicación de datos y de metadatos. En una misma partición ReFS detectará corrupciones de metadatos gracias a los checksums, pero si los Storage Spaces no tienen configurados varios discos para mirroring no se podrá acceder a otra copia, y parte del sistema de archivos se volverá inservible (por esa razón ZFS y Btrfs duplican los metadatos incluso en una misma partición).

· Una característica curiosa de ReFS: Si gracias a los checksums se detecta corrupción en alguna parte del disco que no se puede corregir, bien por ausencia de copias, bien por corrupción que se ha expandido a todas las copias, se puede hacer un proceso llamado "salvage" ("salvamento"), que consiste en descartar las partes dañadas. Pongamos, por ejemplo, que el directorio C:/FOO está corrupto, pues el proceso de "salvage" se carga ese directorio dañado a lo bestia.

· Algunas características como enlaces duros no estarán disponibles. Pero no estarán disponibles no porque no les haya dado tiempo a implementarlas, sino por eleccion. La verdad, no entiendo el por qué.

· ReFS sólo estará disponible en Windows 8 Server, y no se podrá instalar Windows sobre él. Teniendo en cuenta que se sabe que Apple está diseñando un nuevo sistema de archivos que seguramente tendrá características de ZFS, añado a mis predicciones para 2012/13 que veremos un OS X con nuevo sistema de archivos y características de ZFS antes de que ReFS llegue a los Windows de escritorio.