Table of Contents

• 1) Introduction
• 2) D-Bus and Polkit Additions
  • 2.1) systemd v260.2 and v261 Reviews
  • 2.2) Polkit Rules File in upower
  • 2.3) New Polkit Action aa-notify.from_file in AppArmor
  • 2.4) New Polkit Actions in fwupd 2.1.4
  • 2.5) Changes in Polkit Rules in gnome-initial-setup
  • 2.6) D-Bus and Varlink Services in wall-broadcaster
  • 2.7) Transactional Update Notifier D-Bus Service
  • 2.8) Plasma Kameleon RGB LED Helper
  • 2.9) Samba Helper in kdenetwork-filesharing
  • 2.10) GNOME Remote Desktop Race Condition in new pcscd API in 51.beta
• 3) Review of File-Based Linux Capabilities
  • 3.1) After-the-Fact Review of Slipped Capabilities
  • 3.2) CAP_NET_RAW for cacti-spine
  • 3.3) CAP_PERFMON for ksystemstats6
• 4) Revisit of Apptainer
• 5) Restriction of Varlink Service Packaging
• 6) pam-ssh-agent Module
• 7) wireguard-tools: Update Logic for resolv.conf
• 8) wicked: Command Injection via DHCP Options (CVE-2026-44932)
• 9) Conclusion

1) Introduction

This edition of the spotlight series covers both spring and summer 2026, since we did not get around to publishing a dedicated spring article due to high workload in our team. Some of the highlights that kept us busy during that time were:

• Incomplete privilege drop in cosmic-greeter when accessing files in user home directories.
• Defense-in-depth issues in a D-Bus helper in plasma-login-manager.
• Disk space exhaustion in the malcontent parental control system.
• Various issues leading to privilege escalation in qSnapper, a GUI frontend for the snapper utility.
• Local Denial-of-Service attack vectors in seunshare, a sandboxing program from SELinux userspace utilities.
• Escalation of Network Manager and UDisks2 Privileges in PortProtonQt, a GUI application for launching Windows games on Linux.
• Full remote system compromise in a network protocol in OpenRGB.
• Authentication bypass in LACT, a GPU manager application for Linux.

Apart from these dedicated publications, we want to shed some light on some less visible efforts in our team during these past months. Topics that we will cover this time are various changes to D-Bus service configuration and Polkit policies which we will cover in section 2). In section 3) we will look into a number of file-based Linux capability assignments in packages. In section 4) we will discuss a revisit of the starter-suid setuid-root binary in the Apptainer container runtime. In section 5) we will point out new whitelisting restrictions in SUSE distributions regarding the packaging of Varlink services. In section 6) we will examine the pam-ssh-agent module which was recently packaged for openSUSE. In section 7) we will discuss concerns about a script in wg-quick for setting up DNS for Wireguard VPN interfaces. Finally, in section 8) we will look at a shell command injection issue we found in the wicked network configuration framework, which can lead to remote root code execution in combination with dracut.

2) D-Bus and Polkit Additions

As usual, many of our reviews were concerned with D-Bus services and Polkit authentication. We look into packages containing D-Bus interfaces and Polkit policies, both when they are first introduced and if they are later modified. In the past months we dealt with a number of reviews of this type, discussed in the following sub-sections.

2.1) systemd v260.2 and v261 Reviews

As we pointed out in previous spotlight editions, systemd is a heavy user of D-Bus and Polkit and also started backporting new features from the mainline development to existing release branches, resulting in an increased review effort on our end.

This time we looked into the follow-up release v260.2, which introduced Polkit actions org.freedesktop.machine1.inspect-machines and org.freedesktop.machine1.inspect-images in the context of systemd-machined. Nothing problematic was found in these two additions.

The new major release of systemd v261 also resulted in a review bug for us. Various Polkit actions were added to our systemd-experimental package, as well as a couple to systemd-machined and systemd-resolved. In this case we also had nothing to complain about and allowed the changes to enter openSUSE Tumbleweed.

2.2) Polkit Rules File in upower

The energy management software upower triggered a review due to a Polkit rules file which appeared in the package. Polkit rules are JavaScript drop-in files which alter the outcome of Polkit authentication requests based on custom logic. In this case a strange rule was added to upower, allowing the root user to perform system power state changes like rebooting or entering suspend. Since the root user is by default allowed to perform any Polkit operation anyway, we asked our upower packager to investigate what the supposed purpose of the rules file might be. He was unable to find out, however, therefore we decided to simply drop this rule file from the package to avoid unnecessary administration efforts. It could be that the rules file is intended to be used on systems where even the root user has limited capabilities.

2.3) New Polkit Action aa-notify.from_file in AppArmor

The AppArmor utility aa-notify, which allows system administrators to easily whitelist AppArmor violations, added an additional Polkit action net.apparmor.pkexec.aa-notify.from_file. This action allows to read in additional AppArmor commands from a file on disk. All the Polkit actions related to aa-notify require auth_admin authentication and are inherently risky, since they provide full system access via various angles. The defense-in-depth and separation of privileges is not ideal here, but we decided to accept the change, since there are no better alternatives available for managing AppArmor profiles.

2.4) New Polkit Actions in fwupd 2.1.4

The firmware update daemon is another heavy user of D-Bus and Polkit. We reviewed it many times in the past already as changes to the API appeared. Security-wise we rarely found tangible issues, but the interface is vast and only parts of it are actually authenticated, while the rest offers access to public information and similar code paths which are assumed to be uncritical.

For the recent update of fwupd to 2.1.4 we reviewed a couple of additional Polkit actions, some of which adding authentication to previously unrestricted D-Bus methods. We couldn’t find any issues in the API changes, and accepted the new version into openSUSE Tumbleweed.

2.5) Changes in Polkit Rules in gnome-initial-setup

gnome-initial-setup is a wizard intended for single-user systems to create a user account with administrator privileges after installation of Gnome-based systems. Its approach is to allow a special gnome-initial-setup user to obtain a range of root-like privileges to perform the necessary initial setup logic.

The security boundary between the gnome-initial-setup user and root is very thin, but the approach is still better than running the setup wizard with full root privileges. A somewhat worrying aspect of the component is that the wizard automatically starts after system boot when there are “no user accounts present” in the system, which is a condition that might be possible to fake or force by way of other security issues in the system.

We have reviewed the package a couple of times in the past. This time a change to the Polkit rules in the package appeared, which led us to looking into the code once again. The change allows gnome-initial-setup to invoke Polkit action org.freedesktop.home1.passwd-home without providing a password, for setting up a portable home directory managed by systemd. This does not change the general security concept of gnome-initial-setup, which is why we accepted the change into openSUSE.

2.6) D-Bus and Varlink Services in wall-broadcaster

A while ago a new D-Bus and Varlink service called wall-broadcaster was added to openSUSE Tumbleweed. This service aims to replace the old-school wall setuid binary, which allows to write terminal messages to all users in the system. Messages processed by this service are also forwarded on D-Bus level e.g. to interested consumers in graphical desktop environments.

We inspected the privileged components and protocols and could not find any security issues, which is why we accepted the new services.

2.7) Transactional Update Notifier D-Bus Service

txnupd is a notifier for SUSE systems based on transactional-update. It sends out a D-Bus signal propagating the results of a transactional update process. The corresponding D-Bus service was recently renamed, which triggered a follow-up review. The privileged daemon which emits the D-Bus signal is only accessible by root and does not cross privilege boundaries, thus this is a rather worry-free case of a D-Bus service.

Still we identified an issue during the review, namely that the same script was used in two different modes, in a privileged and an unprivileged context, mixing two different security domains, which could potentially lead to future issues when developers overlook this detail when making changes. We managed to improve the service in this regard by splitting the script into two different ones for better separation of security concerns.

2.8) Plasma Kameleon RGB LED Helper

A new D-Bus service was added to kdeplasma6-addons which deals with the synchronization of RGB LED devices, like illuminated keyboards, with the color scheme of the KDE Plasma desktop. We looked into the privileged D-Bus helper for this feature and found the interface to be small and offer little attack surface, thus we accepted the new component into openSUSE.

2.9) Samba Helper in kdenetwork-filesharing

A D-Bus service in the kdenetwork-filesharing package which interacts with Samba network shares saw changes in its D-Bus configuration and Polkit policy. The name of the helper binary was changed and additional Polkit actions for starting and stopping the Samba daemon were added. We could not identify newly introduced security issues and thus accepted the changes into openSUSE.

2.10) GNOME Remote Desktop Race Condition in new pcscd API in 51.beta

Our GNOME packagers reached out to us regarding changes they ran into in the GNOME Remote Desktop beta release for version 51. The GNOME Remote Desktop component is constantly growing in complexity, by now amounting to about 75,000 lines of Glib-based C code. This time a new daemon called grd-pcscd was added, which offers an additional D-Bus API to deal with smart cards by interacting with the pcscd smart card management daemon. The approach of the D-Bus interface is a bit unusual:

• there is a new org.gnome.RemoteDesktop.Pcscd.Connect D-Bus method which is accessible to arbitrary users without authorization checks. The method takes a file descriptor as sole argument, which is supposed to refer to a pcscd connection that grd-pcscd should use for further smart card operations.
• the daemon runs a separate D-Bus session on this file descriptor via Glib’s g_dbus_connection_new().
• the session of the process calling Pcscd.Connect is looked up via the caller’s PID. Based on the session ID obtained this way, another D-Bus interface is then made available in the daemon under /org/gnome/RemoteDesktop/Pcscd/<session-id>, offering the org.gnome.RemoteDesktop.Pcscd.Session interface. All methods on this interface are protected by Polkit auth_admin actions and therefore offer no additional attack surface.

We checked possible attack vectors resulting from crafted data sent on the file descriptor passed to the Pcscd.Connect() method. The Glib functions processing D-Bus messages on this file descriptor are pretty robust, however, and valid D-Bus messages will not reach any additional code paths as long as no further configuration takes place via the privileged Pcscd.Session API.

We found the lookup of the caller’s session ID based on its PID problematic, however. This is a race condition that allows the caller to attempt to let the daemon see the session of another user in the system, by cycling PIDs. This allows a local unprivileged attacker to at least block other users’ smart card usage. Even worse, it allows to potentially spoof pcscd replies or intercept sensitive data like smart card PINs provided in other users’ sessions.

We created a private upstream bug describing the problem. Since the issue only made it into the 51.beta release of GNOME, there was no necessity for coordinated disclosure and we also did not assign CVEs. We are happy that we helped to prevent this issue from reaching the final release of GNOME 51.

3) Review of File-Based Linux Capabilities

File-based capabilities work much the same as setuid-root binaries: special extended attributes are set on executable binary programs which tell the Linux kernel to automatically execute the program with additional Linux capabilities in effect. During the past months we looked into quite a number of Linux capability assignment requests, which we will discuss in detail in the following sub-sections.

3.1) After-the-Fact Review of Slipped Capabilities

Special file-based permissions like setuid/setgid bits or Linux capabilities have been managed in SUSE distributions via the permissions package for a long time already. Packaging of such bits is restricted and requires mandatory reviews by our team. Recently it came to our attention that a loophole sneaked into our checkers, resulting in a couple of packages which use file-based capabilities reaching openSUSE Tumbleweed without us having looked into them.

Historically the RPM packaging format did not support embedding of Linux capabilities into package metadata in the first place, thus there was no need to reject them on this level: only a warning was emitted by our rpmlint integration when capabilities appeared. With recent releases of the RPM package manager, this restriction is no longer present. Our RPM checkers recognized the capabilities which lacked a whitelisting but did not trigger fatal build errors. This allowed the affected packages to reach openSUSE Tumbleweed without going through the intended security review process.

Once we noticed this, we quickly adjusted our checkers to prevent such cases in the future and looked into the packages that slipped into production without a review. The following paragraphs discuss the reviews we performed in this context.

CAP_NET_ADMIN and CAP_NET_RAW for ttl

The ttl package assigned cap_net_admin and cap_net_raw to the ttl binary for tracing network routes. During our review we identified that actually only cap_net_raw was necessary and we could successfully drop the broader cap_net_admin privilege. Otherwise we deemed the code paths for cap_net_raw safe and accepted the capability formally into our whitelistings.

CAP_SYS_RESOURCE for noisetorch

The noisetorch package provides a virtual microphone in Pulseaudio and assigns cap_sys_resource to the noisetorch binary for bypassing realtime scheduling limits. We looked into this a longer time ago already and rejected the capability, because the use case for the additional privilege was not very convincing.

There exists a corner case in Pulseaudio that can cause it to exceed realtime scheduling limits when loading plugins. The noisetorch plugin seems to trigger this corner case in some situations, which is why it temporarily bypasses scheduling limits by modifying the Pulseaudio process based on the cap_sys_resource capability. Furthermore the noisetorch program attempts to modify its own executable by adding the cap_sys_resource capability via a privilege escalation dialog, should it be missing. This mixture of a capability being used to work around what looks like a bug in Pulseaudio and the fact that the program tries to apply its own policy regarding file-based capabilities is what led us to reject this request previously.

After looking into the matter again we decided to accept the capability this time, provided that the package would be patched to disable the self-modification logic, which we deem unsuitable, since it bypasses our permissions profiles. A corresponding patch was implemented and we proceeded with a formal whitelisting of cap_sys_resource for noisetorch.

CAP_NET_ADMIN for cloud-hypervisor

The cloud-hypervisor package is a virtual machine manager and uses cap_net_admin to configure privileged virtual machine networking. During our review we focused on the code paths that deal with cap_net_admin only, because the project consists of 150,000 lines of Rust code, not counting vendored code. We could not find issues in the cap_net_admin usage and therefore formally accepted this use of capabilities as well.

3.2) CAP_NET_RAW for cacti-spine

Cacti is a system and network monitoring tool, and cacti-spine is a C program used as a drop-in replacement for a PHP-based program in Cacti for polling network services. In this context it asks for cap_net_raw privileges to send out ICMP messages. According to upstream documentation the utility is even intended to be used with full setuid-root privileges: this is not a good idea at all, however, since it is not very careful in parsing and processing command line arguments, among other issues. Assigning cap_net_raw is acceptable, though; we could not find any tangible security issues in this configuration.

3.3) CAP_PERFMON for ksystemstats6

The ksystemstats6 package contains the helper program ksystemstats_intel_helper, for which an openSUSE user requested the cap_perfmon capability. The helper utility needs it to calculate the GPU usage in the system. The rarely seen cap_perfmon allows programs to open otherwise privileged performance event counters. The utility is only 200 lines long; for prudence we requested to apply a patch with a hardening to the program which also made it into the upstream repository by now. After this patch arrived in the openSUSE package we granted the capability in openSUSE Tumbleweed.

4) Revisit of Apptainer

Apptainer is a container runtime (formerly called Singularity) which we already reviewed a couple of times in the past, since it contains a setuid-root binary starter-suid. The early reviews around the year 2019 uncovered a number of security issues in this area. A few years ago we dropped the starter-suid binary from our packaging, because upstream implemented new features which we believed made the extra privileges unnecessary.

A SUSE customer recently ran into issues because of a specific Apptainer use case they had, which still relied on the starter-suid program being installed. For this reason we revisited the Apptainer code base to check the current situation of this sensitive helper binary.

The logic executed by the starter-suid program is still highly complex and its execution paths hard to follow. We could not identify any new issues in the code this time, however, which is why we accepted the setuid-root binary back into SUSE distributions. Since we are still unhappy about the overall complexity of the program we are relying on an opt-in model: users need to become a member of the apptainer group to use it, which limits the attack surface.

5) Restriction of Varlink Service Packaging

With Varlink services becoming more widespread, we decided to introduce whitelisting restrictions for packages wanting to submit them to SUSE distributions. Contrary to D-Bus services, there is no central instance managing the Inter-Process-Communication of Varlink, and there are also no standard configuration files that every Varlink service ships. Varlink applications simply define a path where the Varlink UNIX domain socket will be placed and that is about all there is to it.

A kind of standard pattern in systemd socket units for Varlink daemons is that they contain a FileDescriptorName=varlink directive. This is what we have decided to rely on to restrict the packaging of Varlink services. We looked into all existing socket units of this kind in openSUSE and did not find any tangible security issues in them. From now on, when packages contain new Varlink socket units, a mandatory review by our team will be required before they can be added to SUSE distributions.

6) pam-ssh-agent Module

Recently we received a request to allow the pam-ssh-agent module into openSUSE. The module performs PAM authentication based on SSH public keys: a random payload is requested to be signed by an SSH private key; the signature is then verified by the PAM module based on a list of configured trusted public keys.

The PAM module is of moderate size, consisting of about 1,500 lines of Rust (not counting vendored sources). The code and documentation generally show security-consciousness, which is a good thing. We identified a few aspects in the PAM module that could be problematic, mostly as a result of bad configuration:

• the PAM module can be configured to look for acceptable public keys in the to-be-authenticated user’s home directory, which allows to basically bypass local sudo authentication, for example. This is also documented in the upstream README.
• an authorized_keys_command can be configured to call a program which produces authorized public keys. If an untrusted program is configured here then this would result in issues in local authentication scenarios.
• the authorized_keys_command is by default run with the privileges of the to-be-authenticated user; an option allows to change this to be run as root, however, which could easily lead to security issues further down the chain.
• a special authentication path in the PAM module inspects the SSH_AUTH_INFO_0 environment variable, if the current PAM stack file is named “ssh”. Public keys found in this environment variable are implicitly trusted by the PAM module, assuming that sshd already took care of the authentication, verifying the public key(s). This is a bit of a heuristic, which could break in some (highly) unexpected scenarios.

In spite of these uncertainties we are generally content with the quality and documentation of the PAM module and accepted it into openSUSE. It is up to system administrators to configure this PAM module carefully to avoid any security issues.

7) wireguard-tools: Update Logic for resolv.conf

An openSUSE user was concerned about the security of wg-quick, a script which is part of the wireguard-tools package, a collection of utilities for the Wireguard VPN solution. wg-quick is supposed to bring up a WireGuard VPN interface in a worry-free manner.

A Linux-specific “DNS hatchet” is applied during build time of wireguard-tools on openSUSE. Hatchets are overrides of the script logic in wg-quick, a rather makeshift approach at customizing the logic towards specific operating systems.

The openSUSE user approached us because he was worried about the mount logic that this “DNS hatchet” implements for /etc/resolv.conf. During the review we found the approach of the script a bit unexpected but not unsafe at all. The script is concerned with the safe update of name server configuration in /etc/resolv.conf, a resource which is difficult to manage in Linux, because there is no central mechanism for maintaining the consistency of the file when multiple programs want to modify it. VPN clients are a typical use case when this results in problems: the VPN client adds VPN-specific name servers, thereby overriding previously existing name servers from static configuration or provided by DHCP servers. When the configuration is blindly overwritten this results in the loss of the original DNS configuration; once the VPN connection is terminated, DNS is no longer working.

To prevent this situation, the “DNS hatchet” performs a bind-mount of the new configuration file over the original one in /etc/resolv.conf. The resulting file will be read-only, preventing further modifications of the configuration until the VPN connection is terminated. When the VPN is shutdown, the bind-mounted file will be unmounted again and the original name server configuration reinstated.

We have no security concerns about this logic, and explained the situation to the creator of the review bug accordingly.

8) wicked: Command Injection via DHCP Options (CVE-2026-44932)

wicked is the network configuration framework used in SUSE Linux Enterprise 15-SP7 and earlier. Its DHCP clients dump the settings of an acquired lease into files below /run/wicked/leaseinfo.*, which contain lines of the form KEY='value'.

We found that the values of a number of DHCP options, among them POSIXTZSTRING, were written out verbatim, enclosed in single quotes but without any validation or escaping:

fprintf(out, "%s='%s'\n", __ni_keyword_format
        (&key, prefix, name, index),
        val_to_print);

A DHCP server can thus place a single quote in an option value and break out of the quoting. A dnsmasq configured with

dhcp-option=100,'; chmod a+w /etc/shadow; /bin/true '

results in the following line in the leaseinfo file:

POSIXTZSTRING=''; chmod a+w /etc/shadow; /bin/true ''

The interesting part about this issue is who actually executes this. wicked itself never sources these files; it only passes them on to netconfig modify, which rejects any line whose value is not strictly single-quoted. There was, however, also no documentation stating how the leaseinfo files were intended to be consumed. Since their syntax looks exactly like shell variable assignments, third party code simply started to source them from shell scripts. We found several examples of this in our distributions and in the wild, among them dracut’s network-legacy module, the SUSE cloud-netconfig scripts and SystemImager.

The dracut case is the nastiest one: ifup.sh sources the leaseinfo file as root in the initrd, turning the issue into unauthenticated code execution as root for an attacker on the local or adjacent network. The network-legacy module is not active by default, but it is pulled in by plausible setups such as remote unlocking via dracut-sshd, or systems that need NFS, iSCSI or NBD during early boot. We confirmed this end-to-end on SLE-15-SP7.

We rated the issue CVSS:3.1/AV:A/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H (8.8 High) and CVSS:4.0/AV:A/AC:L/AT:P/PR:N/UI:N/VC:N/VI:L/VA:N/SC:H/SI:H/SA:H (5.8 Medium). This is a nice example of the improved precision of CVSS v4.0, which is able to express that the impact materializes in a subsequent system rather than in wicked itself.

The issue was handled under embargo and fixed by wicked upstream: single quotes are now rejected in all string options and discarded values are logged as warnings; should a suspect string still pass the input check, single quotes are additionally escaped in the leaseinfo output. The fix was released for all maintained SLE and openSUSE codestreams, including a rebuild of the initrd, which carries its own copy of wicked.

9) Conclusion

As can be seen from this edition of the spotlight series, maintaining the security of a complete Linux distribution is no small feat both in terms of volume and range of topics that have to be covered by our team. We continue to contribute to the overall security of the Linux ecosystem by reviewing code, publishing security reports and contributing back upstream to be able to provide our users and customers with a robust and secure Linux distribution that you can trust.

Veremos cómo lanzar un script (o cualquier otra tarea) en un equipo remoto mediante SSH y dejarlo ejecutándose en segundo plano con una sesión de tmux, de forma que siga funcionando aunque cerremos la conexión.

Este artículo surgió como una búsqueda de una necesidad que tenía. Lo que quería era conectarme a un equipo remoto mediante ssh, y en ese equipo remoto, lanzar una tarea, en mi caso dejar corriendo un script, y poder dejarlo funcionando en segundo plano en el equipo remoto aunque me desconectara de ssh.

La solución que encontré fue utilizar tmux, una herramienta que permite crear sesiones de terminal persistentes y volver a ellas más adelante. Podemos iniciar una tarea en el equipo remoto, desconectarnos y dejar que continúe ejecutándose sin necesidad de mantener abierta la conexión SSH. Veamos cómo hacerlo.

Primero defino el escenario, un equipo local desde el que me conecto a un equipo en remoto (ambos con GNU/Linux, por supuesto) mediante ssh. Y en el equipo remoto quiero dejar corriendo un script aunque después me desconecte o incluso apague el equipo local.

Las sesiones en tmux

Una vez conectado mediante ssh al equipo remoto, la clave es ejecutar tmux y abrir una nueva sesión. Según la definición de las sesiones en la web de tmux:

Una sesión tmux es un espacio de trabajo persistente que agrupa ventanas y paneles y continúa ejecutándose en segundo plano incluso después de desconectarse. Las sesiones sobreviven caídas de SSH, cambios de red y cierres de terminales, lo que convierte a tmux en la herramienta estándar para el trabajo con servidores remotos.

Vale, es algo muy sencillo para quien trabaja de administrador de sistemas y se tiene que conectar a equipo, pero yo no lo sabía y por eso este tutorial (para mi yo del futuro y para ti).

Abrir una sesión en tmux en el equipo remoto

Vale, conectados al equipo remoto (en el que tiene que estar instalado tmux, of course!) ahora vamos a abrir una sesión a la que le pondremos un nombre para identificarla (pondremos el nombre que queramos). Para ello en el equipo remoto ejecutamos:

tmux new -s nombre_sesión

Y nos abrirá tmux con la sesión que hayamos nombrado. Ahora podemos hacer lo que necesitemos. En mi caso quiero dejar corriendo un script. Lo ejecuto y lo dejo corriendo

Desconectarse de la sesión

Con el script corriendo en la sesión recién creada, podemos dejarlo corriendo y desconectarnos de la sesión mientras el script sigue funcionando en segundo plano.

Para eso ejecutamos

Ctrl+a d

Aquí cabe destacar que tmux utiliza una combinación de teclas para ejecutar comandos a la que llaman prefix. De manera predeterminada es Ctrl+b, pero yo la tengo modificada a Ctrl+a. Si tu no la has cambiado seguirá siendo Ctrl+b (una combinación de teclas poco cómoda de pulsar)

Por tanto pulsamos (en mi caso) Ctrl+a (soltamos) y después la tecla d, para decirle a tmux que queremos desconectarnos de la sesión.

Tmux se cierra, pero la sesión con nuestro script en segundo plano sigue activa, mostrando en la terminal el mensaje:

[detached (from session nombre_sesion)]

Ahora podemos desconectarnos de ssh si queremos.

Volver a conectarnos a una sesión previa

Más tarde, podremos volver a conectarnos a esa sesión de tmux en la que dejamos corriendo nuestro script. Para ello, podemos hacer que tmux nos de un listado de las sesiones activas, para eso ejecutamos:

tmux ls

Y nos mostraría algo similar a (cambiando nombre y fechas, obviamente):

script_monitor: 1 windows (created Wed Sep  9 15:05:21 2026)
prueba2: 1 windows (created Wed Sep  9 16:41:26 2026)

Vale, pues queremos conectarnos a la sesión script_monitor para eso ejecutamos

tmux a -t script_monitor 

Y se abrirá tmux tal como lo habíamos cerrado previamente, con sus ventanas o divisiones si las hubiera y nuestro script ha estado funcionando todo el tiempo normalmente.

Terminar una sesión

Después ya podremos detener el script y cerrar la ventana de tmux con Ctr+a x y terminará la sesión.

O podremos matar la sesión sin entrar en ella mediante

tmux kill-session -t nombre_sesión

Espero que os haya resultado útil. Yo lo he necesitado estos días para conectarme a mi miniPC desde el portátil y dejar corriendo unos scripts y quería compartirlo por el blog, aunque sé que es un tema que se ha tratado en otros muchos sitios.

Enlaces de interés

• https://tmux.app/sessions/
• https://victorhckinthefreeworld.com/2021/05/17/guia-visual-sobre-tmux/
• https://victorhckinthefreeworld.com/2018/01/23/guia-rapida-de-tmux-expande-las-posibilidades-de-la-consola-de-linux/

Hace mucho tiempo que tenía ganas de traer a esta creadora de contenidos al blog porque su canal rezuma calidad por todos los lados y, por fin, lo hago con un vídeo titulado «35 años de Linux: 35 curiosidades que cambiaron la informática» de «La Chica de Sistemas» con el que conmemoraba el aniversario de un proyecto que ha cambiado el mundo. No os lo podéis perder.

35 años de Linux: 35 curiosidades que cambiaron la informática

El mundo de los creadores de contenido de GNU/Linux en grandes plataformas como Youtube es reducido, algo que parece que está cambiando poco a poco. Si buscas por la red de vídeos más grande la internet (ojalá fuera libre) nos encontramos con canales como «Salmorejo Geek«, «Aprendiendo con Marga«, «Linux Center», «Planeta Tecno«, «Juan J.J. – Linuxeroerrante» , o el extinto «Karla’s Project» (que esperemos que un día vuelva con nosotros). Seguro que me dejo alguno, ponédmelo en comentarios.

A esta lista creciente de canales hay uno que merece la pena subscribirse por muchas razones entre las que destacan la calidad de los mismos y su cadencia: La Chica de Sistemas.

Si visitáis el canal os podéis encontrar vídeos de todo tipo desde filosofía y programación a sistemas operativos y Software Libre, sin olvidar historia, administración de sistemas o tutoriales, en los cuáles La Chica de Sistemas demuestra un amplio conocimiento en todas las ramas de la informática.

Siendo más técnico, y para los que les gustan los números, el canal presenta unos 64 vídeos, no son muchos pero cada vídeo tiene gran calidad por lo que todos son recomendables, y unos 48.000 suscriptores, lo que supone disponer de una comunidad consolidada dentro de un nicho especializado como la administración de sistemas Linux/Unix, la programación y el desarrollo.

Sin más, os dejo el maravilloso vídeo «35 años de Linux: 35 curiosidades que cambiaron la informática» y os invito a suscribiros y a darle a la campanita. Seguro que no os arrepentís… y seguro que no será el único vídeo que promociono desde el blog.

En palabras de su creadora

¿Cómo pasó un proyecto «solo por diversión» a dominar el mundo? En este video exploramos la historia de Linux a través de 35 curiosidades increíbles en su 35 aniversario.

Desde el primer mensaje de Linus Torvalds hasta cómo el kernel de Linux se convirtió en la base de internet, los superordenadores y hasta los teléfonos que usamos hoy.

Si te apasiona la informática, los sistemas operativos y quieres entender por qué Linux cambió el mundo para siempre, este recorrido por sus secretos mejor guardados es para vos.

El 25 de agosto de 1991, un estudiante finlandés de 21 años publicó un mensaje en Usenet anunciando que estaba desarrollando un sistema operativo libre, «solo por hobby» y que «no sería nada grande ni profesional como GNU».

Treinta y cinco años después, ese experimento casero se convirtió en el kernel Linux: la pieza de software que transformó la historia de la informática y sobre la que corre prácticamente toda la infraestructura digital moderna, desde servidores en la nube y supercomputadoras hasta teléfonos móviles y misiones espaciales.

Para celebrar este 35° aniversario, repasamos 35 historias, secretos de arquitectura, debates históricos y curiosidades que marcaron el camino de esta obra maestra del código abierto.

Si os ha gustado el vídeo y el canal, no dejéis de visitarlo, suscribiros y compartirlo.

La entrada «35 años de Linux: 35 curiosidades que cambiaron la informática» de La Chica de Sistemas se publicó primero en KDE Blog.

There is a question that comes up often in openSUSE forum threads or a Reddit comment section and that is what version of X does one actually get on Leap versus Tumbleweed?

Until recently the honest answer was very often “go look it up yourself, package by package” unless someone actually had the answer.

Now there is a better one.

The openSUSE version diff tool!!! Yes github.com/openSUSE/osdiff tooling generates a complete, machine-built comparison of source package versions across Tumbleweed and the current Leap releases.

The idea of listing source package versions in a consumable format grew out of a discussion community member Axel Braun raised at a weekly Release Engineering meeting. The site republishes itself automatically. No guessing, no anecdotes, no six-month-old blog post. Just the numbers.

The tool pulls the archive indexes straight from download.opensuse.org; this is for open-source software (oss) and non-oss, x86_64 and noarch and it’s done for Tumbleweed, Leap 16.1, and Leap 16.0; then it compares the upstream version of every source package it finds. The result is a single sortable, filterable table with a timestamp on it.

The scale is worth pausing on. A recent run covers 17,532 source packages: 17,143 in Tumbleweed, 10,574 in Leap 16.1, 10,551 in Leap 16.0, with 10,264 present in both Tumbleweed and Leap 16.1. Every package lands in one of five status buckets:

The page carries maintainer information and it is careful about what it claims: only the upstream version is compared, not the RPM release. That distinction matters, and the tool states it up front rather than quietly blurring it.

Open data changes the conversation. The single most valuable thing here isn’t the HTML page. It’s the downloads sitting at the bottom of it: diff.json, diff.json.gz, and diff.csv.

This open data turns a nice webpage into infrastructure. Anyone can pull the JSON, and the shape of the data is stable enough to build on. Which is where use cases start multiplying.

• Prospective users deciding between Leap and Tumbleweed. Someone who needs a specific toolchain version for work can confirm it in ten seconds rather than installing and finding out.

• Media, reviewers, and documentation writers can immediately find information they need to dive deeper into a related topic. This page gives a journalist instant information to help them determine if a flavor of openSUSE has exposure fixes. Distribution comparisons are notoriously prone to stale or half-remembered version numbers, and a wrong number in a review can stick around for years in search results. A citable, timestamped, auto-generated source removes the excuse for guessing. If you write about openSUSE, you now have a footnote you can actually point at.

• Aggregators like DistroWatch where the site tracks package versions across dozens of distributions do enormous manual or semi-manual work to keep tables current. Machine-readable exports of an entire distribution’s package set, refreshed automatically, is exactly the kind of upstream cooperation that makes that work cheaper and more accurate. What do you say DistroWatch? Want to know “what’s in what” tables.

• Packagers and maintainers get immediate knowledge. The tool attaches the maintainer names to those rows so somebody knows who to ask.

• Contributors looking for a first task. One of the hardest parts of joining a distribution project is finding something concrete to do. A filtered list of packages that are behind, with maintainers listed, is a genuinely welcoming on-ramp.

• Sysadmins and platform teams gain quick confirmation for their development. Before migrating a fleet from Leap 16.0 to 16.1, or evaluating whether a workload can move from Tumbleweed to Leap, the practical question is which dependencies shift and by how much. The 16.0-versus-16.1 columns answer that directly, and the CSV drops into a spreadsheet or a diff script without ceremony.

• Developers targeting openSUSE will know which library versions your users will have, this is the compatibility matrix. It also tells you whether your own package is present in Leap at all.

• Researchers and the merely curious can have a lot of fun with the open-data. Full-distribution version data, published openly on a recurring basis, is a dataset. Software-ecosystem researchers and people who just enjoy graphing things now have raw material that didn’t exist in convenient form before.

Having Leap package versions visible alongside Tumbleweed’s is a meaningful shift in how a release gets communicated. Historically, “what will be in the next Leap?” was answered in release notes near the end of the cycle, or reconstructed by people willing to dig through OBS. Publishing the state of the in-development distribution as it evolves means the community can see the release taking shape rather than being handed a finished summary.

Small tools like this rarely get the attention they deserve, but a table that is always correct, always current, and freely downloadable quietly removes an entire category of friction from a project. We hope you enjoy it.

Me alegra compartir con todos vosotros la quinta actualización de Plasma 6.7, continuando así la serie de revisión de software que le dotará de más estabilidad, mejores traducción y resolución de errores. Estas actualizaciones son 100% recomendables y casi obligatorias para cualquier usuario ya que lo único que hacen es mejorar la versión sin comprometer sus funcionalidades.

Quinta actualización de Plasma 6.7

No existe Software creado por la humanidad que no contenga errores. Es un hecho incontestable y cuya única solución son las actualizaciones. Es por ello que en el ciclo de desarrollo del software creado por la Comunidad KDE se incluye siempre las fechas de las mismas siguiendo una especie de serie de Fibonacci.

Así que me congratula en presentar que hoy martes 8 de septiembre de 2026, unos meses después de liberar el código de Plasma 6.7 la Comunidad KDE presenta la quinta actualización de errores.

Más información: KDE

Las novedades generales de Plasma 6.7

Aprovecho para realizar un listado de las novedades generales de Plasma 6.7:

• Escritorios virtuales por pantalla: Ahora es posible configurar escritorios virtuales de forma independiente para cada monitor.
• Prueba del volumen del micrófono: Se ha añadido una herramienta para comprobar los niveles de entrada de audio, facilitando el diagnóstico de problemas con el micrófono.
• Caracteres especiales en teclado virtual: Al usar el teclado virtual, es posible mantener pulsada una tecla para acceder a los caracteres especiales asociados a ella.
• Interruptor rápido de temas: Se incluye un nuevo control para cambiar instantáneamente entre los temas globales claros y oscuros.
• Calendario lunar vietnamita: Se ha integrado este calendario en el sistema para permitir su uso junto al gregoriano.
• Mejora en «Aplicaciones en segundo plano»: La bandeja del sistema ahora muestra también las aplicaciones que utilizan el sistema de segundo plano moderno, frecuente en paquetes Flatpak.
• Monitorización de impresión: El icono de la bandeja del sistema para impresoras ahora muestra una placa indicando el número de trabajos activos.
• Gestión de colas de impresión: Se ha introducido una nueva herramienta para gestionar colas de impresión, diseñada tanto para un uso doméstico sencillo como para la gestión avanzada de múltiples impresoras.
• Acceso rápido a escritorios en Vista general: Desde la Vista general (Meta + W), ahora es posible cambiar entre escritorios virtuales usando el ratón o las teclas RePág y AvPág.
• Favoritos por arrastrar y soltar: Se ha simplificado la gestión de favoritos en los lanzadores y menús de aplicaciones mediante la función de arrastrar y soltar.

Más información: KDE

• 
  Tantas maneras de hacer clic y desplazarse – Esta semana en Plasmaseptiembre 5, 2026
  Bienvenidos a «Tantas maneras de hacer clic y desplazarse» de «Esta semana en Plasma», donde nos presentan como se sigue preparando Plasma 6.8 para ser un nuevo hito en el desarrollo de este entorno de trabajo libre.
• 
  Las aplicaciones de QtWidgets se unen a Union – Esta semana en Plasmaagosto 29, 2026
  Bienvenidos pues a «Las aplicaciones de QtWidgets se unen a Union» de «Esta semana en Plasma», donde nos presentan como se sigue preparando Plasma 6.8 para ser un nuevo hito en el desarrollo de este entorno de trabajo libre.
• 
  Mejoras en la interfaz y en el rendimiento – Esta semana en Plasmaagosto 22, 2026
  «Mejoras en la interfaz y en el rendimiento» de «Esta semana en Plasma», donde nos presentan como se está preparando Plasma 6.8 para ser un nuevo hito en el desarrollo de este entorno de trabajo libre.

La entrada Quinta actualización de Plasma 6.7 se publicó primero en KDE Blog.

Después de 25 años, ha llegado el momento de pasar el relevo del proyecto Packman. Si no se encuentra a nadie que desee continuar con Packman, se suspenderá el proyecto el 31/12/2026.

El pasado 27 de agosto de 2027 en un correo en alemán e inglés a la lista de correo del proyecto, se anunciaba que los actuales responsables del proyecto Packman tenían intención de dejar su papel y pasarle el testigo a quien quisiera hacerse cargo.

Si no encontraban a nadie que tuviera conocimientos, tiempo y dinero para mantenerlo, el próximo 1 de enero de 2027 todo sería ya historia después de 25 años de servicio.

Llevo utilizando openSUSE desde 2011, más o menos, y desde siempre, nada más instalar el sistema, a la hora de configurar los repositorios, una de las primeras cosas que siempre hacía, era añadir el repositorio Packman en openSUSE y darle además una prioridad mayor frente a los repositorios oficiales de openSUSE.

Así que cuando me he enterado de la noticia, me he sentido primero un poco descolocado y después me he dado cuenta, que nunca podemos dar nada por sentado para siempre.

¿Qué es el repositorio Packman?

Según las propias palabras del proyecto:

Nos dedicamos a agrupar el software en paquetes para facilitar la instalación y la desinstalación en un entorno linux. Con ello pretendemos sobre todo publicar los paquetes de software que o bien no están incluidos en las distribuciones o bien la versión incluida está ya desfasada.

Por principio, Packman, está abierto a todas las distribuciones. Pero la distribución para la cual ofrecemos paquetes depende en definitiva de la distribución que use o apoye cada uno de los miembros del equipo PackMan.

Actualmente los paquetes que ofrecemos son básicamente para SUSE Linux, pero también existen paquetes para Fedora.

Packman es un repositorio de software no oficial de openSUSE muy completo y de gran calidad, hasta tal punto que muchos de quienes utilizamos openSUSE lo consideramos casi oficial y la propia Comunidad de openSUSE lo recomienda. Hoy si no cambia la situación será algo que haya que cambiar.

Me permito traducir el correo, ya que al ser la fuente oficial encontraremos los motivos que han llevado a esta situación y un poco de historia al respecto.

Cómo empezó todo y quién lo hizo posible

La idea original de Packman surgió de Waldemar Brodkorb, quien co-inició el proyecto en ese momento. Pascal Bleser desarrolló entonces el sitio web (con Marc). Pascal también se ocupó de los patrocinadores y organizó servidores espejo antes de finalmente dar un paso atrás. Desde el principio, Marc creó y administró toda la gestión del repositorio, así como la infraestructura de correo electrónico.

A lo largo de todos estos años, pagó el alojamiento de su propio bolsillo (aparte de algunas donaciones e ingresos publicitarios) y se encargó del diseño técnico y el mantenimiento. En 2005, Stefan (Botter) se incorporó con un servidor de réplica y desde 2013 gestiona los servidores de compilación, de los que también es responsable financiera y técnicamente. Desde hace varios años, Stefan también es moderador de la lista de correo de Packman.

Pero – y queremos enfatizarlo explícitamente – Packman nunca fue solo nuestro proyecto. No habría sido posible sin los muchos empaquetadores trabajadores durante todos estos años. Gente que vino, mantuvo los paquetes y finalmente se fue de nuevo. Gente que se quedó años o décadas. Sin todos vosotros, Packman nunca habría llegado tan lejos. Queremos agradeceros muy sinceramente por ello.

Por qué lo dejamos

25 años es mucho tiempo. Y si somos sinceros: Packman alcanzó su cenit hace algún tiempo. Las distribuciones han evolucionado. Flatpak y otros mecanismos han reducido la necesidad de muchos paquetes clásicos de Packman. Ambos nos hemos dado cuenta de que ya no podemos reunir la energía ni el tiempo que Packman necesita. Preferimos terminarlo de forma consciente y transparente antes que dejar que se desvanezca lentamente, dejando a los usuarios con paquetes huérfanos al final.

En cuanto a la infraestructura

Cualquiera que desee continuar con Packman debe configurar su propia infraestructura. Estamos preparados para documentar nuestro conocimiento y ofrecer apoyo asesor durante la configuración. Además, estamos listos para entregar los scripts que gestionan la publicación y firma de paquetes. Marc continuará gestionando la gestión del dominio y la lista de correo, siempre que se encuentren sucesores para las demás áreas.

Se buscan sucesores

Buscamos a una persona o un equipo dispuesto a continuar con Packman: hosting, infraestructura de compilación, gestión de repositorios y coordinación comunitaria. Dividir estas tareas entre varias personas es absolutamente concebible.

También nos gustaría invitar a opiniones sobre modelos alternativos. Una pregunta obvia: ¿Podría Packman (o al menos partes de él) transferirse al OpenSUSE Build Service (OBS)? Sin embargo, hay una restricción importante: Packman solo existe porque el OBS oficial mantiene una lista negra de aplicaciones y no puede construir los códecs multimedia exactos que definen a Packman. No obstante, merece la pena plantearse la pregunta de nuevo y debatir qué modelos serían factibles hoy en día.

¿Qué pasa si no encuentran a nadie que desee continuar?

Si no se encuentra sucesor o alternativa antes del 31/12/2026, descontinuaremos el proyecto: las compilaciones, servidores de compilación y alojamiento de repositorios se desactivarán. Los repositorios dejarán de ser accesibles a partir de entonces.

Agradecimientos

Durante muchos años, Packman ha sido un proyecto muy cercano a nuestro corazón. Agradecemos a todos los que han contribuido a lo largo de los años: Waldemar por la idea original, Pascal por el trabajo inicial en la web, el proyecto openSUSE y especialmente el equipo de Open Build Service, patrocinadores y servidores de réplica, los empaquetadores que vinieron y se fueron, y quienes se quedaron. A los operadores de servidores de réplica, a los usuarios que reportaron errores y a todos los que nos apoyaron con comentarios constructivos.

Esperamos que se encuentre a alguien que continúe el proyecto. Si no, nos marchamos con la buena sensación de haber creado algo grandioso para la comunidad durante 25 años.

Gracias por todo. Un saludo cordial, Marc Schiffbauer y Stefan Botter

He omitido algunas secciones del correo original por ser muy técnicas, y mantener la esencia del anuncio, que es que Packman dejará de estar disponible con el comienzo de 2027… si nadie toma el relevo.

Personalmente tirándo un comando: zypper search -i -r ftp.gwdg.de-openSUSE_Tumbleweed

Me da información de los paquetes de mi sistemas instalados desde ese repositorio y que son unos cuantos. La mayoría software o librerías relacionadas con el audio, VLC, ffmpeg, etc…

Algunos se podrán sustituir por otros repositorios, como el propio para VLC, que incluirá sus códecs y con otros habrá que ver de qué manera solucionarlo.

Desde aquí mi gratitud a las personas que lo pusieron en marcha y han mantenido este importante recurso durante 25 años de historia. Han realizado un gran trabajo, que espero que siga adelante, pero que si no es así no ha desmerecido su dedicación y trabajo.

Enlaces de interés

• https://lists.links2linux.de/pipermail/packman/2026-August/018314.html
• https://forums.opensuse.org/t/packman-discontinued-from-jan-1st-2027-but-heres-your-chance/195731
• http://packman.links2linux.org/
• https://es.opensuse.org/Repositorios_comunitarios#Packman

The openQA test suite for openSUSE and SLE has a test module called tests/console/sudo.pm. It verifies that sudo works: passwords, shells, sudoers rules, environment isolation. Basic stuff. It runs tens of thousands of times per year and takes about 9 minutes each time. That adds up.

Where the time goes

There is no single bottleneck. The test uses expect to interact with password prompts. Every sudo call goes through credential cache reset, process spawn, password entry, and result verification. It does this 20 times because the test runs the full suite twice with slightly different sudoers configurations.

Gwenview, el visor de imágenes de la comunidad KDE, es una gran conocido por los usuarios. Pero ahora ya hay quien trata de sustituirlo por Photos un visor más moderno

Los usuarios de Plasma, llevamos utilizando el visor de imágenes Gewnview desde siempre, o eso parece, porque lleva con nosotros más de 25 años ¡casi nada!

Por cierto, allá por el 2021 publiqué en el blog un artículo del motivo de ese curioso nombre:

• https://victorhckinthefreeworld.com/2021/10/05/por-que-la-aplicacion-gwenview-de-kde-tiene-ese-extrano-nombre/

Pero ya hay quien propone pasarle el testigo del visor de imágenes de KDE a otro programa llamado Koko y que cambiaría su nombre a Photos.

El motivo es simple. Adaptar Gwenview a los nuevos estándares que tiene la comunidad de KDE con su software supondría el tener que reescribir buena parte del código, con lo que eso conlleva: Inestabilidad, depuración, etc.

Las nuevas personas que contribuyen con código ya no lo hacen en Gwenview por estar un poco desfasada.

Por eso, se ha promocionado a Koko, que nació en 2017 como una aplicación para móviles y que ha ido creciendo en funcionalidades para también dar el salto como aplicación de escritorio ofreciendo como mínimo lo mismo que Gwenview, pero con un código más moderno que atrae más a nuevos desarrolladores.

Vale, habrá cosas que eches en falta respecto a Gwenview, pero serán las mínimas y además Koko aka Photos trae nuevas funcionalidades en la gestión de tus imágenes en tu escritorio.

Puedes probar este software y empezar a hacer esa migración de una aplicación a otra o seguir utilizando Gwenview tal como estabas acostumbrado hasta ahora.

¿Ya has probado Photos? Yo la acabo de instalar en mi equipo desde los repositorios de openSUSE Tumbleweed y estoy empezando a conocerla.

Photos permite la edición de las imágenes con el editor de Spectacle, pudiendo recortar, redimensionar, voltear la imagen y también etiquetar imágenes, mostrar su información, poder compartirlas por diversos medios, etc…

Enlaces de interés

• https://apps.kde.org/es/koko/
• https://pointieststick.com/2026/09/06/photos-a-proposed-replacement-for-gwenview/
• https://apps.kde.org/es/gwenview/

Veamos cómo hacer que dos (o más) pestañas se sincronicen cuando hagamos «scroll» en una de ellas en el editor Kate de KDE

Editando un texto, tenía abierto el editor Kate de KDE con dos pestañas una al lado de la otra y necesitaba que al desplazar el texto, las dos se movieran a la vez, lo que me ahorraría tiempo.

Ya en un artículo anterior, vimos cómo poder hacer eso mismo en el editor Vim. Aquí tienes el enlace:

• https://victorhckinthefreeworld.com/2020/12/23/curso-de-vim-sincronizar-el-scroll-en-dos-ventanas-del-editor-vim/

Y para hacerlo en el editor Kate de KDE vamos a seguir los pasos siguientes.

Abrimos Kate con las dos pestañas divididas. Pueden ser el mismo documento en dos pestañas distintas, pueden ser distintos documentos, pueden ser más de dos pestañas.

Teniendo las pestañas divididas con los textos que queramos sincronizar al hacer «scroll» o desplazarlo en la pantalla, vamos a menú Ver → Vista dividida → Conmutar sincronización de desplazamiento.

Veremos que en la esquina superior derecha del documento aparece un icono como de una cadena. Situamos los dos documentos en las líneas que queremos sincronizar y pulsamos en los iconos de las pestañas a sincronizar, en las dos o en más si tuviéramos más.

Ahora al desplazar el texto veremos como ambas pestañas se desplazan a la vez pudiendo así revisar texto, compararlo, o lo que necesitemos hacer.

Si queremos dejar de sincronizar la pestaña, volvemos a pulsar sobre el icono y ya podremos desplazarnos libremente y pudiendo volver a utilizarlo cuando volvamos a necesitarlo.

A mí me ha resultado muy útil y resulta que ha hubo una persona de la comunidad de KDE que pensó en hacerlo. Bien por esa persona.

¿Te ha resultado útil? ¿Algún truco de Kate que quieras compartir?

Google Summer of Code is now over for openSUSE.

This summer, we had the privilege of mentoring eight contributors.

Mario Marín Hinojosa enhanced the openSUSE git workflow build results. He blogged about his progress and you can already see in it action on br.opensuse.org. See an example for devel:languages:python:Factory!

Akash Kumar wrote the foundation for an Uyuni on Kubernetes storage benchmark. This meant enhancing sumaform, the deployment tool used by the CI, to work with an existing Kubernetes cluster. He also wrote cucumber tests in the Uyuni test suite to benchmark the reposync and the download of packages from several minions. There are still other tests to add and he documented this all in the github mentoring issue. Akash will give a presentation at the openSUSE.Asia Summit in Yogyakarta in about a month; come and get to know him!

Digvijay Rawat worked on a AI agent to help with the root cause analysis of errors on Linux machines managed by Uyuni. He documented how it works, how to install it and what is left to be done in his repository. He also prepared a demo video to show how it off.

Geetansh Goyal added an MQTT publisher to Uyuni so its events can be used in automation. He also added Node Red nodes to use those events. His work is described in his repository. Tell us your use cases. Geetansh also presented at the openSUSE conference and would like to start buildin an openSUSE mirror and community in India. Find out how Geetansh described his Google Summer of Code experience.

Himanshu Jaiswal helped porting the Uyuni API docs to openAPI and Swagger. This was not just the matter of rewriting the doc from the current Javadoc to the new format, but also adding automation for it and fixing the many errors that came up. He documented the state of his project in a gist for the curious to take a look or help.

Jay Prakash added an mgrctl get command to wrap up the Uyuni API in a similar way to kubectl get. This only supports systems and system groups for now, but has been written with extensibility in mind to reduce the work needed for other Uyuni objects. He documented his work in a special git repository.

Surya Srinivasan worked on a native support of LDAP in Uyuni. With his work in, configuring the use of an LDAP server could be done from the Uyuni web interface! He described his work and what remains to be done in a gist.

Anuj Agrawal began the program this summer with us, but had to resign as he started working for Google. Congrats!! He started a chat bot project to help get started with openSUSE. The project uses a local SLM and RAG and was already nicely kicked out. To know more about the project, check out the code and documentation in his repository or read Anuj’s blog post about the openSUSE Assistant.

Many thanks to all eight of them for their involvement. We are looking forward to keep working with you all. Many thanks also to those who mentored them, gave time and patience to help them get started with contributing to openSUSE.