Warewulf

Preface

In High Performance Computing (HPC) computing tasks are usually distributed among many compute threads which are spread across multiples cores, sockets and machines. These threads are thightly coupled together. For this compute clusters consist of a number of largely identical machines that need to be managed to maintain a well defined and identical setup across all nodes. Once clusters scale up there are many scalability factors to overcome. Warewulf is there to address this ‘administrative scaling’.

Warewulf is an operating system agnostic installation and management system for HPC clusters.
It is quick and easy to learn aud use as many settings are pre-configured to sensible defaults. It still provides the flexibility allowing to finely tune the configuration to local needs. It is released under the BSD license. Its source code is available at https://github.com/warewulf/warewulf. This is where the development happens as well.

Installing warewulf4

Compute clusters consist of at least one management or head node which is usually multi-homed connecting both to an external network and to a cluster private network as well as multiple compute nodes which reside solely on the private network. Other private networks dedicated to high speed task like RDMA and storage access may exist as well. Warewulf gets installed to one of the management nodes to manage and oversee the installation and management of the compute nodes. To install Warewulf on a cluster is running SUSE Linux Enterprise HPC 15 SP5, openSUSE Leap 15.5 or openSUSE Tumbleweed, simpy run:

zypper install warewul4

on this management node to install the SUSE-provided Warewulf package. This package seamlessly integrates into a SUSE system and should therefore be preferred over packages provided on Github.

During the installation the actual network configuration is written to the /etc/warewulf/warewulf.conf. These settings should be verified, as for multi homed hosts a sensible pre-configuration is not always possible.

Check /etc/warewulf/warewulf.conf for the following values:

ipaddr: 172.16.16.250
netmask: 255.255.255.0
network: 172.16.16.0

where ipaddr should be the ip address of this host management host. Also check the values of netmask and network - these should match this network.

Additionally, you should configure the ip addresse range for dynamic/unknown hosts:

dhcp:
  range start: 172.16.26.21
  range end: 172.16.26.50

If the ISC dhcpd server is used (default on SUSE) make sure the value of DHCPD_INTERFACE in the file /etc/sysconfig/dhcpd has been set to the right value.

You are now ready to start the warewulfd service itself which delivers the images to the nodes:

systemctl enable --now warewulfd.service

Now wwctl can be used to configure the the remaining services needed by warewulf. Run

wwctl configure --all

which will configure all warewulf related services.

Adding nodes and profiles to warewulf

Warewulf uses the concept of profiles which hold the generalized settings of the individual nodes. It comes with a predefined profile default, to which all new node will be assigned, if not set otherwise. You may obtain the values of the default profile with:

wwctl profile list default

Now, a node can be added with the command assigning it an IP address:

wwctl node add node01 -I 172.16.16.101

the mac address is known for this node, you can specify this as well:

wwctl node add node01 -I 172.16.16.101 -H cc:aa:ff:ff:ee

For adding several nodes at once you may also use a node range which results e.g.

wwctl node add node[01-10] -I 172.16.16.101

this will add the nodes with ip addresses starting at the specified address and incremented by warewulf.

Importing a container

Warewulf uses a special ¹ container as the base system to build OS images for the compute nodes. This is self contained and independent of the operating system installed on the warewulf host.

To import an openSUSE Leap 15.5 container use the command

wwctl container import docker://registry.opensuse.org/science/warewulf/leap-15.5/containers/kernel:latest leap15.5 --setdefault

This will import the specified container for the default profile.

Alternative container sources

Alternative containers are available from the openSUSE registry under the science project at

https://registry.opensuse.org/cgi-bin/cooverview?srch_term=project%3D%5Escience%3A

or from the upstream warewulf community repository

https://github.com/orgs/warewulf/packages?repo_name=warewulf-node-images

It is also possible to import an image from a chroot by using the path to chroot as argument for wwctl import.

Booting nodes

As a final preparation you should rebuild the container image by running

wwctl container build leap15.5

as well as all the configuration overlays with the command

wwctl overlay build

just in case the build of the image may have failed earlier due to an error. If you didn’t assign a hardware address to a node before you should set the node into the discoverable state before powering it on. This is done with

wwctl node set node01 --discoverable

Now the node(s) can be powered on and will boot into assigned container.

For a convenient experience you should now log out of and back into the warewulf host, as this way an ssh key for password-less login to the compute nodes will be created on the warewulf host. Note, that this key is not pass-phrase protected. If you require a pass phrase, it is probably a good idea to set one now:

ssh-keygen -p -f $HOME/.ssh/cluster

Also you should run

wwctl configure hostlist

to add the new nodes to the file /etc/hosts.

Additional configuration

The configuration files for the nodes are managed as Golang text templates. The resulting files are overlayed over the node images. There are two ways of transport for the overlays to the compute node, the

• system overlay
• runtime overlay where the system overlay is baked into the boot image of the compute node while the runtime overlay is updated on the nodes on a regular base (1 minute per default) via the wwclient service.

In the default configuration the overlay called wwinit is used as system overlay. You can list the files in this overlays with the command:

wwctl overlay list wwinit -a

which will show a list of all the files in the overlays. Files ending with the suffix .ww are interpreted as template by warewulf and the suffix is removed in the rendered overlay. The content of the overlay can be shown using the command

wwctl overlay show wwinit /etc/issue.ww

To render the template using the values for node01 use:

wwctl overlay show wwinit /etc/issue.ww -r node01

The overlay template itself may be edited using the command

wwctl overlay edit wwinit /etc/issue.ww

Please note that after editing templates the overlays aren’t updated automatically and should be rebuild with the command

wwctl overlay build

The variables available in a template can be listed with

wwctl overlay show debug /warewulf/template-variables.md.ww

Modifying the container

The node container is a self contained operating system image. You can open a shell in the image with the command

wwctl container shell leap15.5

After you have opend a shell in the image additional software can be installed with zypper.

The shell command provides the option --bind which allows to mount arbitrary host directories into the container during the shell session.

Please note that if a command exits with a status other than zero the image won’t be rebuilt automatically. So its also advised to rebuild the container with

wwctl conainer build leap15.5

after any change.

Network configuration

Warewulf allows to configure multiple network interfaces for the compute nodes. You can add another network interface for example for infiniband using the command

wwctl node set node01 --netname infininet -I 172.16.17.101 --netdev ib0 --mtu 9000 --type infiniband

This will add the infiniband interface ib0 to the node node01. You can now list the network interfaces of the node:

wwctl node list -n

As changes in the settings are not propagated to all configuration files, the node overlays should be rebuilt after this change running the command:

wwctl overlay build

After a reboot these changes will be present on the nodes, in the avove case the Infiniband interface will be active on the node.

A more elegant way to get same result is to create a profile to hold the values which are the same for all interfaces. In this case these are mtu and the netdev. A new profile for an Infiniband network is created using the command

wwctl profile add infiniband-nodes --netname infininet --netdev ib0 --mtu 9000 --type infiniband

Once this has been created, you may add this profile to a node and remove the node specific settings which are now part of the common profile by executing:

wwctl node set node01 --netname infininet --netdev UNDEF --mtu UNDEF --type UNDEF --profiles default,infiniband-nodes

You may list the data in a profile using this command:

wwctl profile list -A infiniband-nodes

Secure Boot

Switch to grub boot

Per default warewulf boots nodes via iPXE, which isn’t signed by SUSE and can’t be used when secure boot is enabled. In order to switch to grub as boot method you will have add/change following value in /etc/warewulf/warewulf.conf

warewulf:
  grubboot: true

After this change you will have to reconfigure dhcpd and tftp executing

wwctl configure dhcp
wwctl configure tftp

and rebuild the overlays with the command

wwctl overlay build

Also make sure that the packages shim and grub2-x86_64-efi for x86-64 or grub2-arm64-efi for arm are installed in the container. shim is required by secure boot.

Cross product secure boot

If secure boot is enabled on the compute nodes and you want to boot different products make sure that the compute nodes boot with the so called ‘http’ boot method: For secure boot the signed shim needs to match the signature of the other pieces of the boot chain - including the kernel. The ‘http’ method is handled by warewulfd which will look up the image to boot and pick the shim from the image to deploy to this node. Otherwise, the initial shim for PXE boot, which is the default boot method, is extracted from the host running the warewulfd server. Make sure, the node container contains the shim package. The host system shim will also be used for nodes which are in discoverable state and subsequently have no hardware address assigned yet.

Disk management

It is possible to manage the disks of the compute nodes with warewulf. Here, warewulf itself doesn’t manage the disks, but creates a configuration and service files for ignition to do this job.

Prepare container

As ignition and its dependencies aren’t installed in most of the containers you should install the packages ignition and gptfdisk in the container

wwctl container exec <container_name> zypper -n in -y ignition gptdisk

Add disk to configuration

For storage devices all the necessary structures must be configured which are

• physical storage device(s) to be used
• partition(s) on the disks
• filesystem(s) to be used

Disks

The path to the device e.g. /dev/sda must be used As diskname. The only valid configuration for disks is diskwipe which should be self explanatory.

Partitions

The partname is the name to the partition whick iginition uses as the path for the device files, e.g. /dev/disk/by-partlabel/$PARTNAME.

Additionally the size and number of the partition need be specified for all but the last partition (the one with the highest number) in which case this partition will be extended to the maximal size possible.

You should also set the boolean variable --partcreate so that a parition is created if it doesn’t exist.

Filesystems

Filesystems are defined by the partition which contains them, so the name should have the format /dev/disk/by-partlabel/$PARTNAME. A filesystem needs to have a path if it is to be mounted, but its not mandatory.

Ignition will fail, if there no filesystem type is defined.

Examples

You can add a scratch partition with

wwctl node set node01 \
  --diskname /dev/vda --diskwipe \
  --partname scratch --partcreate \
  --fsname scratch --fsformat btrfs --fspath /scratch --fswipe

This will be the only (and last) partition, therefore it does not require a size. To add another partition as swap partition, you many run:

wwctl node set n01 \
  --diskname /dev/vda \
  --partname swap --partsize=1024 --partnumber 1 \
  --fsname swap --fsformat swap --fspath swap

This adds the partition number 1 which will be placed before the scratch partition.

Version 4.6 of syslog-ng introduced windows-eventlog-xml-parser(), a dedicated parser for XML-formatted event logs from Windows. It makes the EventData portion of log messages more useful, as it combines two arrays into a list of name-value pairs.

https://www.syslog-ng.com/community/b/blog/posts/dedicated-windows-xml-eventlog-parser-in-syslog-ng

Sometimes you have many log messages from an app, but none of them have the exact content you need. This is where the grouping-by() parser of syslog-ng can help. It allows you to aggregate information from multiple log messages into a single message.

In this blog, I will show you how to parse sshd logs using the patterndb parser of syslog-ng, and then create an aggregate message from the opening and closing log message using grouping-by.

https://www.syslog-ng.com/community/b/blog/posts/aggregating-messages-in-syslog-ng-using-grouping-by

Google con su monopolio casi exclusivo de lo que la gente conoce como internet ha contribuido con sus prácticas a que decaiga el uso de los feeds RSS aunque aún hay quienes los utilizamos

¿Quieres estar al tanto de las publicaciones de una web, blog que te gusta mucho? Una opción es visitarla todos los días para ver si ha publicado algo nuevo… pero hay otras opciones, por ejemplo usar los feeds RSS.

En resumen, cada web o blog (este blog mismo que estás leyendo) tiene disponible ese servicio que hace que gracias a un programa único puedas recopilar todas las novedades de esas webs o blogs recopiladas en un solo lugar en tu equipo.

Así podrás recopilarlas cuando tengas tiempo para leerlas, puedes guardarlas para consultarlas más adelante, ordenarlas, etiquetarlas, etc. Pero no solo sirve para webs o blogs. muchos otros servicios también se difunden usando esta tecnología.

Ahora que resuena en una parte de la comunidad de internet esa tendencia a retornar a los orígenes de la red, alejándonos de la comercialización, del seguimiento, del abuso de la persona que visita, de cobra por cookies, etc.

Los feeds RSS son una herramienta que ha estado ahí desde hace muchos años y fue muy utilizado. En este artículo repasaremos cómo Google con sus prácticas monopolistas ha querido también eliminar del imaginario de internet esta tecnología en favor de algo más centralizado (en su empresa) que permita cuntificar, monetizar y controlar al usuario.

Este artículo es una traducción del inglés de un artículo publicado por OpenRSS en agosto de 2023 en su web que puedes leer en este enlace:

• https://openrss.org/blog/how-google-helped-destroy-adoption-of-rss-feeds

Aunque los feeds RSS están vivos y todavía se utilizan mucho hoy en día, su nivel de adopción se ha visto afectado debido a lo difícil que ha sido para un puñado de empresas de tecnología populares utilizarlos.

Google, especialmente, ha confiado en el protocolo RSS de la web abierta para ganar tanta participación de mercado e influencia, pero continúa adoptando un comportamiento que explota la web abierta a expensas de sus usuarios.

Como resultado, Google ha contribuido por sí solo a la razón por la que muchos usuarios que alguna vez confiaron en los canales RSS hayan dejado de usarlos.

A continuación, profundizamos en el historial de Google de lo que parece ser un modelo de Abrazar, Extender y Extinguir.

La compañía ha construido y ampliado continuamente sus productos en torno al protocolo RSS abierto y gratuito para ganarse la confianza del usuario, solo para luego eliminar el soporte RSS una vez que han bloqueado a los usuarios e ignorar cualquier queja o solicitud para restaurarlo.

No sólo es un flagrante desprecio por el RSS y una gran decepción para quienes lo utilizan, sino que plantea una de las mayores amenazas a la libertad y apertura de Internet.

Google elimina el botón RSS del navegador Chrome

Las primeras versiones del navegador Chromium (en el que se basa el navegador Google Chrome) alguna vez vinieron con integración RSS incorporada.

El navegador tenía un botón RSS incorporado que se mostraba en la barra de direcciones del navegador cuando cualquier sitio web en el que se encontraba tuviera una fuente RSS disponible.

Al hacer clic en el botón, accederá a la fuente RSS de esa página web, lo que permitirá al usuario suscribirse fácilmente.

Luego, el botón RSS desapareció sin previo aviso y no se dio ninguna razón para su eliminación.

Google adquiere FeedBurner y limita el RSS

En 2007, Google adquirió FeedBurner, un servicio de feeds RSS que permite a los propietarios de sitios web monetizar sus feeds RSS.

FeedBurner funciona reemplazando los canales RSS ordinarios por canales privados que sólo pertenecen a Google.

Los feeds se modifican para incluir anuncios, enlaces de afiliados y otros mecanismos de seguimiento, como recuentos de lecturas, tasas de clics y recuentos de suscriptores. Luego, los usuarios de FeedBurner utilizan los feeds para realizar un seguimiento de sus lectores y monetizar su comportamiento.

Después de adquirir FeedBurner, Google cerró las API de FeedBurner en octubre de 2012, lo que impidió a los desarrolladores crear integraciones RSS de terceros para el servicio.

Luego, en julio de 2022, Google cambió drásticamente la infraestructura y el modelo operativo de FeedBurner al eliminar la mayoría de los servicios de FeedBurner de los que dependían sus usuarios de RSS, que incluían suscripciones por correo electrónico.

Esto dejó a muchas personas con URL de fuentes RSS que no funcionaban en sus correos electrónicos de suscripción y sin forma de solucionarlas.

Google cierra Google Reader

En 2005, Google creó Google Reader, una aplicación de lectura de RSS basada en web. Le permitía agregar fuentes RSS en cualquier lugar de Internet y organizarlas en carpetas en una interfaz limpia y minimalista.

Luego, en 2013, después de años de que los usuarios confiaran en él para sus feeds RSS, Google lo eliminó.

La razón que dio Google para eliminar Google Reader fue en un anuncio en el que afirmaban que «si bien el producto tiene seguidores leales, a lo largo de los años su uso ha disminuido».

Pero un ingeniero, que trabajaba para Google en ese momento, declaró: «Me sentí como si durante todo el tiempo que estuve en el proyecto, varias personas intentaran acabar con él».

Sin embargo, la acusación de Google sobre el bajo uso no infundió mucha confianza en la viabilidad de los canales RSS. Los usuarios se quedaron sin una aplicación de lectura de RSS, sin una alternativa comparable y sin educación por parte de Google sobre cómo continuar usando sus canales RSS sin Google Reader.

Esto llevó a los usuarios no sólo a dejar de usar Google Reader, sino también a abandonar por completo los feeds RSS.

Google elimina el RSS de las Alertas de Google

Google Alerts es un servicio ofrecido por Google que le notificará con una alerta cuando haya contenido nuevo en la web que coincida con un término de búsqueda que usted especifique.

En octubre de 2008, Google añadió la posibilidad de recibir alertas de Google en un canal RSS. Pero, en julio de 2013, Google decidió eliminarlo, convirtiendo el correo electrónico en la única opción para recibir alertas de Google. El motivo de la eliminación no estaba claro.

Finalmente, después de recibir una reacción violenta, Google restableció los canales RSS para las Alertas de Google. Pero en ese momento, muchos usuarios ya abandonaron los feeds RSS debido al cierre de Google Reader por parte de Google (mencionado anteriormente), por lo que el daño ya estaba hecho.

Google elimina su extensión de navegador RSS

Google proporcionó una extensión de Google Chrome que coloca un pequeño ícono RSS al lado de la URL de un sitio web en la barra del navegador si estás en una página web que tiene una fuente RSS.

A pesar de que se utilizó esta extensión, Google la eliminó. Pero luego, después de una reacción violenta, lo restableció una semana después, alegando que se eliminó por error. Y si bien restablecerlo era mejor que no hacerlo, eliminarlo seguía siendo un duro golpe para la confianza del usuario en el uso general del feed RSS.

Y si es cierto que se hizo sin querer, todavía muestra cuán poco prioritario se ha convertido el RSS para Google, a pesar de lo mucho que el RSS ha contribuido al crecimiento de la empresa.

Google elimina la integración RSS de Google News

En 2002, Google anunció Google News, el primer sitio de agregación de medios de la compañía, con la capacidad de agregar URL de fuentes RSS de toda la web.

Luego, después de que muchos usuarios de RSS quedaran bloqueados y dependieran de la aplicación Google News para sus feeds RSS, Google dejó de admitir el soporte RSS, lo que provocó que los feeds RSS de los usuarios dejaran de funcionar.

Luego, Google cerró por completo su soporte para feeds RSS en diciembre de 2017. La compañía no dio ninguna razón para eliminar el soporte para feeds RSS en su aplicación Google News.

Como resultado, los usuarios no tuvieron más remedio que buscar enlaces RSS alternativos para cada feed que agregaron a la aplicación Google News, mientras que los enlaces privativos y no abiertos de Google News continuaron funcionando bien.

Google sigue en ello…

El incidente más reciente ocurrió en mayo de 2021, cuando Google anunció que están trabajando en una actualización de Google Chrome que recupera la compatibilidad con RSS.

Pero no ha habido noticias sobre un lanzamiento oficial desde que se anunció hace años. No está claro cuáles serán las implicaciones de esta característica. Pero está claro que Google tiene un historial de crear productos con RSS y eliminar el soporte RSS una vez que ha establecido una base de usuarios.

Por lo tanto, no hay garantía de que, incluso si se lanza la función, seguirá estando disponible y siendo confiable para los usuarios de RSS con el tiempo.

Debido a que Google sin duda tiene una enorme influencia, esperamos que comprenda que incorporar funciones RSS en sus productos y luego eliminarlas afecta negativamente la percepción y la confianza del usuario en torno a RSS en general.

Los canales RSS son una parte vital de la web abierta. Por lo tanto, si Google decide continuar integrando funciones RSS en sus productos, es fundamental que las respalde, las mantenga a lo largo del tiempo y se asegure de que siempre sigan siendo una prioridad.

Si has leido hasta aquí, espero que te haya resultado interesanta esta interesante recopilación de lo que la gran empresa Google ha realizado con los RSS y los estándares abiertos.

Por mi parte sigo utilizando los RSS en mis equipos usando Akregator, aunque en el blog he escrito artículos y tutoriales sobre otros programas para recopilar los feeds RSS.

Además los feeds son la base sobre la que se mantiene PlanetaLibre, el agregador de blogs y webs en español sobre GNU/Linux y software libre. ¡Al que de hecho te puedes suscribir también mediante RSS!

¿Usas RSS? ¿Conoces este método de consultar aquello que te interesa? ¿Tienes algo que compartir al respecto? Usa los comentarios para compartirlo.

There are several changes happening in openSUSE’s rolling release Tumbleweed on a daily basis and integrating systemd-boot into has been evolving.

A shift from the traditional GRUB boot loader is promising better system boot performance and security.

An all-systems-go presentation by Ludwig Nussel sheds some light on the motivations, challenges and future direction of systemd-boot integration in openSUSE.

The primary motivation behind adopting systemd-boot lies in its simplicity and efficiency, especially when handling full-disk encryption. Traditional boot loaders like GRUB require embedding decryption code and key derivation functions that can complicate the boot loader code and the boot process; this could slow down the system at startup. With systemd-boot, these responsibilities are delegated to the Linux Kernel and user space, which helps to streamline the boot process.

MicroOS and Tumbleweed’s use of Btrfs and its snapshotting capabilities adds complexity to the boot process; this is being addressed by integrating systemd-boot with the snapshot management system to ensure each snapshot boots successfully and that kernel updates are handled gracefully within this dynamic environment.

To facilitate this integration, new packaging scripts and tools like sdbootutil were introduced to manage kernel versions, snapshots and boot entries. This tool plays a crucial role in making systemd-boot a practical choice for openSUSE users, as the way that the snapshots are managed are different in MicroOS than in Tumbleweed.

Using sdbootutil, the system will create new Type #1 boot entries in the EFI System Partition (ESP) to represent all the avaliable boot options, which will copy from the snapshot the new installed kernels into this partition. It will also generate good initrd for those snapshots.

When using full disk encryption, sdbootutil will also call the different commands that will update the policies required to automatically unlock the new snapshots using the internal Trusted Platform Module 2.0 (TPM2) device of the system.

Ideally, in the future, some if not all of this functionallity will be exported into systemd itself or other systems components in the distribution. These changes make this tools a good place to experiment, validate or discard the different approaches that openSUSE is leading with systemd-boot.

At this point, systemd-boot support in openSUSE is still considered experimental. Both Tumbleweed and MicroOS yast installers offer systemd-boot as an alternative to grub for the brave. There are also ready-made appliances for qemu that use systemd-boot and full-disk encryption by default.

Ayer mismo comentaba que el equipo de desarrollo de KDE había elaborado una guía para portarlos temas globales a Plasma 6 pretendiendo facilitar la migración de estos elementos tan característicoas de nuestro escritorio a los diseñadores. Pues bien, no sé si el gran Jomada ha seguido esa guía o no pero se ha apuntado el tanto de crear el primer tema Global Para Plasma 6 que ha bautzado con el nombre de Nothing (¿tendrá relación con el gran tema de Depeche Mode?) y que merece ser reconocido en este blog.

Primer tema Global Para Plasma 6: Nothing

Antes lo digo, antes aparece. Ya tenemos disponible para su descarga y aplicación algnos temas globales en la KDE Store. No obstante, y dado que suelo aprovecharme de su trabajo, hoy quiero rendir tributo al primer tema global de Plasma 6 que incluso me pareció ver que estaba incluído en el lanzamiento.

Este tema que destaca por su oscuridad y elegancia, combinando negros y grises, destacando la utiización de un rojo vivo que, evidentmente, contrasta y le mucha vida. Ha sido creado por Jomada, uno de los diseñadores más prolíficos, y en mi humilde opinión, con más gusto del ecosistema de la Comunidad KDE. Para este tema el propio Jorge recomienda el uso del tema de iconos Colloid Grey-black con lo que queda de fábula, como podéis ver en las imagen inferior.

Desde aquí agradezco de antemano el trabajo de estos diseñadores anónimos (porque aunque todo está referenciado poco caso se les hace) que invierten su tiempo en proporcionarnos opciones de tan alta calidad.

Más información: Tema Global Nothing KDE Store

Guía para portar los temas globales a Plasma 6

Debido al lanzamiento de KDE 6 (Plasma, aplicaciones y motor), y como se podía intuir, no solo el API de Plasma utilizada para crear widgets de escritorio (también conocidos como «applets» o «plasmoides«) ha cambiando sino que también se han visto afectados los temas globales, con lo que todos estos paquetes de software que cambian de con un simple click todo el aspecto de tu escritorio deberán ser adaptados ya que se pierde la compatibilidad.

Esto es tanto así que ya se ha creado la sección propia para temas de Plasma 6 en la KDE Store, aunque en el momento de escribir este artículo, ya hay casi una decena lo cual es significativo ya que nos augura un buena cantidad de opciones de personalización para nuestro entorno de escritorio en un periodo de tiempo muy corto.

Con la intención de que esto ocurra en el menor tiempo posible y que en breve tengamos un buen número de estas delicas visuales ideales para personalizar nuestro entorno de trabajo los diseñadores de KDE han creado una breve guía para portar los temas globales a Plasma 6.

En esta guía se especifica las novedades (como que ahora los temas son tratados como un kpackage lo que significa que necesitan de un archivo manifest.json para ser utilizados de forma correcta) o los grandes cambios (como que ya no se pueden utilizar enlaces simbólicos para cargar un tema Plasma).

Por supuesto, hay muchos cambios más como el cambio de nombre de las importaciones QML, en los scripts de diseño de escritorio, en las pantallas de bloqueo personalizadas o en los temas de inicio de sesión SDDM

En resumen, una excelente iniciativa que seguro que los desarrolladores de estas pequeñas (o no tanto) maravillas para nuestro

Más información: KDE Develop

La entrada Primer tema Global Para Plasma 6: Nothing se publicó primero en KDE Blog.

Recopilación y traducción del boletín mensual de noticias relacionadas con el software libre publicado por la Free Software Foundation.

La Free Software Foundation (FSF) es una organización creada en Octubre de 1985 por Richard Stallman y otros entusiastas del software libre con el propósito de difundir esta filosofía, frente a las restricciones y abusos a los usuarios por parte del software privativo.

La Fundación para el software libre (FSF) se dedica a eliminar las restricciones sobre la copia, redistribución, entendimiento, y modificación de programas de computadoras. Con este objeto, promociona el desarrollo y uso del software libre en todas las áreas de la computación, pero muy particularmente, ayudando a desarrollar el sistema operativo GNU.

Mensualmente publican un boletín (supporter) con noticias relacionadas con el software libre, sus campañas, o eventos. Una forma de difundir los proyectos, para que la gente conozca los hechos, se haga su propia opinión, y tomen partido si creen que la reivindicación es justa!!

• En este enlace podéis leer el original en inglés: https://www.fsf.org/free-software-supporter/2024/march
• Y traducido en español (cuando el equipo de traducción lo tenga disponible) en este enlace: https://www.fsf.org/free-software-supporter/2024/marzo

Puedes ver todos los números publicados en este enlace: http://www.fsf.org/free-software-supporter/free-software-supporter

Después de muchos años colaborando en la traducción al español del boletín, desde inicios del año 2020 decidí tomarme un descanso en esta tarea.

Pero hay detrás un pequeño grupo de personas que siguen haciendo posible la difusión en español del boletín de noticias de la FSF.

¿Te gustaría aportar tu ayuda en la traducción y colaborar con la FSF? Lee el siguiente enlace:

• https://victorhckinthefreeworld.com/2016/12/22/quieres-ayudar-a-traducir-el-boletin-mensual-de-la-free-software-foundation/

Por aquí te traigo un extracto de algunas de las noticias que ha destacado la FSF este mes de marzo de 2024.

Los demócratas vuelven a la carga, tratando de romper los algoritmos de caja negra abiertos

Del 16de febrero porThomas Claburn

Los legisladores demócratas han propuesto una vez más una legislación para garantizar que el código fuente del software utilizado para las investigaciones criminales pueda ser examinado y esté sujeto a pruebas estandarizadas por parte del gobierno.

El 15 de febrero, los representantes de la Cámara de Representantes Mark Takano (D-CA) y Dwight Evans (D-PA) reintrodujeron la Ley de Justicia en Algoritmos Forenses de 2024, un proyecto de ley que prohíbe el uso de afirmaciones de secretos comerciales o que los abogados defensores revisen el código fuente relevante para casos penales y establece un régimen federal de pruebas para software forense.

Dado que se puede utilizar software privativo para encarcelar de por vida a un presunto delincuente, es imperativo que estos programas sean software libre para garantizar un juicio justo.

• https://www.theregister.com/2024/02/16/black_box_government/

El software libre no es la antítesis del éxito comercial

Del 12 de febrero

Un malentendido común con respecto al concepto de software libre, o una pregunta que puede verse planteada por personas en Internet en diferentes salas de chat, foros y demás, proviene de la idea errónea de que «libre» en «software libre» significa libre como tal en «cerveza gratis», es decir, gratis.

En este artículo, Gabriel Cezarin Popovici, pasante del equipo de campañas de la Free Software Foundation (FSF), explica por qué desarrollar software libre y ganar dinero no tienen por qué excluirse mutuamente.

• https://www.fsf.org/blogs/community/free-software-is-not-antithetical-to-commercial-success

Noticias de GNU Emacs de febrero

Del 26 de febrero Sacha Chua

Sacha Chua recopila unos cuantas noticias de este mes de febrero sobre las novedades en GNU Emacs.

• 2024-02-26
• 2024-02-19
• 2024-02-12
• 2024-02-05

Estas son solo algunas de las noticias recogidas este mes, ¡¡pero hay muchas más muy interesantes!! si quieres leerlas todas (cuando estén traducidas) visita este enlace:

• https://www.fsf.org/free-software-supporter/2024/marzo

Y todos los números del «supporter» o boletín de noticias de 2024 en español, francés, portugués e inglés aquí:

• https://www.fsf.org/free-software-supporter/2024

—————————————————————

1) Introduction

The dnf5daemon-server component offers a collection of D-Bus interfaces to interact with the dnf5 package manager on the system. An openSUSE community packager wanted to add the additional D-Bus component to the openSUSE Tumbleweed distribution. New D-Bus system services require a review by the SUSE security team. In the course of this review I found the issues described in this report.

The version of dnf5 I reviewed for this is 5.1.9, and any source code references below are based on the corresponding version tag in the upstream Git repository.

2) D-Bus Interface Design

The dnf5daemon-server offers a main interface “org.rpm.dnf.v0.SessionManager” on which clients can create a new session, which results in a new dynamically allocated D-Bus object being registered on the bus. This session object provides a set of additional D-Bus interfaces for modifying package manager configuration, for installing or removing packages or for inspecting metadata about packages and repositories on the system.

The dnf5daemon-server is running as root and can be autostarted via the D-Bus system bus if it is not already running. Any other users with access to the D-Bus system bus may talk to it.

For certain privileged operations the D-Bus service implements Polkit authentication. Only three operations are protected by Polkit:

• org.rpm.dnf.v0.rpm.RepoConf.write
• org.rpm.dnf.v0.rpm.execute_transaction
• org.rpm.dnf.v0.rpm.Repo.confirm_key

These relate to changing the repository configuration, executing transactions or importing new trusted signing keys. Transactions cover all kinds of changes introduced through the package manager.

All of these operations require auth_admin privileges on Polkit level. The integration of the Polkit authorization logic is correct as far as I can tell.

The per-session D-Bus interface provided by dnf5daemon-server is rather large and many calls take additional key/value maps to tune the behaviour of the package manager logic contained in libdnf5. In summary, the libdnf5 library is attached very closely to the D-Bus system bus via dnf5daemon-server.

3) Local Root Exploit via Configuration Dictionary (CVE-2024-1929)

While the privileged operations mentioned above are correctly protected by Polkit, there are issues with the D-Bus interface long before Polkit is even invoked.

The org.rpm.dnf.v0.SessionManager.open_session method takes a key/value map of configuration entries. A sub-entry in this map, placed under the “config” key, is another key/value map. The configuration values found in it will be forwarded as configuration overrides to the libdnf5::Base configuration. The spot where this happens is found in session.cpp:63.

Practically all libdnf5 configuration aspects can be influenced here, as can be seen in the ConfigMain class in config_main.hpp. Already when opening the session via D-Bus, the libdnf5 will be initialized using these override configuration values. There is no sanity checking of the content of this “config” map, which is untrusted data.

There are surely a lot of different ways to exploit this possibility to influence the libdnf5 configuration. The simplest approach to get full root privileges I found is to trick the library into loading a plug-in shared library under control of the unprivileged user.

To do this, the “pluginpath” and “pluginconfpath” configuration entries need to be supplied and need to point to a user-controlled path. There the unprivileged user can place a configuration file that in turn points towards a user controlled shared library. The library will then dlopen() this user controlled shared library, which will lead to full code execution in the context of the root user.

3.1) Proof of Concept

A proof of concept I wrote shows this vulnerability in action. I successfully tested this exploit also on Fedora 39 using dnf5daemon-server version 5.1.10. The only precondition for this exploit is that the dnf5daemon-server package is installed on the system. Any local user, even nobody, can obtain root privileges this way.

3.2) Bugfix

To fix this, I suggested to enforce a whitelist of configuration parameters that are allowed to be overridden. Only a very small subset of values should be allowed for unprivileged clients.

In upstream commit e51bf2f0d such a whitelist enforcement has been implemented for dnf5daemon-server.

3.3) CVE Assignment

Red Hat Product Security assigned CVE-2024-1929 for this issue.

4) No Limit on Number of Open Sessions / Bad Session Close Behaviour (CVE-2024-1930)

There is no limit on how many sessions D-Bus clients may create using the open_session() D-Bus method. In my tests I was able to quickly create about 4,500 sessions and keep them open. For each session a thread is created in dnf5daemon-server. This spends a couple of hundred megabytes of memory in the process. Further connections will become impossible, likely because no more threads can be spawned by the D-Bus service.

In some cases I even managed to cause the D-Bus service to abort() as a result of hitting resource limits. If the service continues running and the client disconnects, then the cleanup code found in SessionManager::on_name_owner_changed() runs for each session that has been created. Each Session holds a ThreadsManager, where the thread associated with each session originates from. It is a thread that is busy-waiting to join other threads, the code for this is found in threads_manager.cpp:33. Since there is a sleep of one second in this thread’s loop it takes about ~4,500 seconds for all the threads from the 4,500 sessions to be joined one by one. The service will be unreachable for more than an hour.

4.1) Bugfix

To fix this, I suggested to limit the number of sessions for each unprivileged user in the system to a sensible value. Also the busy-wait loop in ThreadsManager seems ill-devised. Maybe using a condition variable to inform the cleanup thread of new work would be more efficient. Having a dedicated ThreadsManager and join-thread for each session seems a bit overkill, too.

In upstream commit c090ffeb79 the maximum number of sessions is limited to three sessions. The problematic thread joining behaviour has not been addressed as of now.

4.2) CVE Assignment

Red Hat Product Security assigned CVE-2024-1930 for this issue.

5) Untrusted locale Setting for each Session

Another part of the per-session setup is the use of an untrusted locale setting in session.cpp:54. This string is passed to the C library’s newlocale() function in threads_manager.cpp:92. A danger here is that arbitrary user controlled files or symlinks could be processed by the C library, which could lead to various issues like information leaks, denial of service or even code execution. I looked into the GNU glibc implementation of newlocale(), and luckily it already implements a very careful locale lookup algorithm, that prevents that arbitrary paths are accessed if crafted locale strings are passed to it. This outcome might change if a different C library is used.

Whether anything bad could happen, apart from file system issues, when exotic locales are selected for a thread running in dnf5daemon-server is another question that I did not investigate more closely.

For hardening purposes I suggested that dnf5daemon-server performs a sanity check of the locale string to prevent a string that contains e.g. a slash character / from being used. I don’t know of any upstream commits that address this yet, but upstream stated that they intend to work on this in the future.

6) dnfdaemon-client Demands Full Root

Although the D-Bus service implements Polkit for privileged operations, the dnf5daemon-client refuses to perform privileged operations for non-root users. For example:

user$ dnf5daemon-client distro-sync
This command has to be run with superuser privileges (under the root user on most systems).

The code for this is found in various sub-command implementations:

$ grep -r 'throw UnprivilegedUserError' -C 1
dnf5daemon-client/commands/downgrade/downgrade.cpp-    if (!libdnf5::utils::am_i_root()) {
dnf5daemon-client/commands/downgrade/downgrade.cpp:        throw UnprivilegedUserError();
dnf5daemon-client/commands/downgrade/downgrade.cpp-    }
--
dnf5daemon-client/commands/distro-sync/distro-sync.cpp-    if (!libdnf5::utils::am_i_root()) {
dnf5daemon-client/commands/distro-sync/distro-sync.cpp:        throw UnprivilegedUserError();
dnf5daemon-client/commands/distro-sync/distro-sync.cpp-    }
--
dnf5daemon-client/commands/install/install.cpp-    if (!libdnf5::utils::am_i_root()) {
dnf5daemon-client/commands/install/install.cpp:        throw UnprivilegedUserError();
dnf5daemon-client/commands/install/install.cpp-    }
--
dnf5daemon-client/commands/remove/remove.cpp-    if (!libdnf5::utils::am_i_root()) {
dnf5daemon-client/commands/remove/remove.cpp:        throw UnprivilegedUserError();
dnf5daemon-client/commands/remove/remove.cpp-    }
--
dnf5daemon-client/commands/upgrade/upgrade.cpp-    if (!libdnf5::utils::am_i_root()) {
dnf5daemon-client/commands/upgrade/upgrade.cpp:        throw UnprivilegedUserError();
dnf5daemon-client/commands/upgrade/upgrade.cpp-    }
--
dnf5daemon-client/commands/reinstall/reinstall.cpp-    if (!libdnf5::utils::am_i_root()) {
dnf5daemon-client/commands/reinstall/reinstall.cpp:        throw UnprivilegedUserError();
dnf5daemon-client/commands/reinstall/reinstall.cpp-    }

It doesn’t make sense that the client forces users to run as root (and thereby increase the attack surface by running also the client code as root) when the service could authenticate the user via Polkit.

I suggested to drop this root-check code in the client, and rely on the authentication logic in the service side code. If authentication fails, then the client code can still hint at the possibility to run the program as root. I am not aware on any upstream commits that address this yet, but upstream stated that they intend to work on this in the future.

7) General Review Summary

In summary my impression is that the libdnf5 library is too closely connected to the D-Bus system bus. The library itself is unaware of the fact that it is running with partially untrusted input. The dnf5daemon-server code needs to carefully filter untrusted input before it is passed to the generic library code.

8) Timeline

9) References

• dnf5 repository on GitHub
• dnf5 5.1.9 Git version tag (the version that has been reviewed)
• code that imports untrusted configuration settings into libdnf5
• bugfix commit for issue 3)
• bugfix commit for issue 4)

El pasado 28 de febrero fue el megalanzamiento 6 de la Comunidad KDE. De una tacada tuvimos disponible Plasma 6, KDE Gears 24.02 y KDE Frameworks 6, la trinidad del desarrollo de KDE. Pero en realidad faltaba una pieza de este gran engranaje. Me complace compartir con vosotros que Plasma Mobile salta también a Plasma 6, con lo que ya tenemos todas las columnas el proyecto preparadas para seguir evolucionando y llevando el Software Libre a nuevas cuotas de grandeza.

Plasma Mobile salta también a Plasma 6

Se me acumulan los lanzamientos. Tengo pendiente desgranar todos los lanzamiento de la Comunidad KDE pero hoy domingo quiero dedicarlo al proyecto dedicado a los dispositivos más portables que podemos tener en nuestras manos: los smartphones y las tabletas.

Y es que el pasado 1 de marzo fue anunciado que a la estela del Megalanzamiento se realizaba también el salto de Plasma Mobile a las tecnologías Qt6/KF6 de la Comunidad KDE, lo cual significaba una mejora importante y, lo más importante, la sincronización de todos los productos de la «marca» KDE.

En palabras de sus desarrolladores:

El equipo de Plasma Mobile se complace en anunciar el lanzamiento de Plasma 6 para dispositivos móviles.
Ha sido un largo año de desarrollo y adaptación desde nuestra última versión importante del shell, así como de las aplicaciones móviles.

Y, a continuación, nos invitan a leer su larga entrada donde describen las novedades más detacadas y nos emplazan visitar una entrada específica Devin de para conocer los detalles técnicos de Plasma 6 en Plasma Mobile.

Más información: Plasma Mobile

¿Qué es Plasma Mobile?

Para los que no lo conozcan Plasma Mobile es la alternativa libre a interfaz gráfica para smartphones de la Comunidad KDE, hablé de él hace un tiempo y, poco a poco, se está convirtiendo en un clásico del blog.

Su idea es muy simple, tras conquistar tu escritorio KDE la Comunidad también quiere conquistar tu teléfono móvil… aunque todavía lo tenga complicado por todas las limitaciones de hardware que todavía tiene este campo de la tecnología.

No obstante, confiemos que de igual forma se han ido conquistando los ordenadores de sobremesa, portátiles y servidores, lleguemos un día que podamos tener libertad total en nuestros smartphones.

Y para cuando eso ocurra la Comunidad KDE estará preparada para ello y por eso está confeccionando un catálogo más que decente de aplicaciones con tecnología adaptativa.

La entrada Plasma Mobile salta también a Plasma 6 se publicó primero en KDE Blog.