For many years, the syslog-ng project provided container images based on Debian. Most of our users run syslog-ng on RHEL & compatibles, and have asked for an RPM-based container. So, nightly containers based on Alma Linux are now also available.

A while ago, I prepared a small test project to run syslog-ng in an Alma Linux container: https://www.syslog-ng.com/community/b/blog/posts/experimental-syslog-ng-container-image-based-on-alma-linux However, that was only an experiment which I never updated. Fast forward to today: nightly syslog-ng containers based on the latest syslog-ng git snapshot package builds are now available on the Docker Hub!

Read more at https://www.syslog-ng.com/community/b/blog/posts/nightly-syslog-ng-containers-based-on-alma-linux

I am extremely excited to announce that I have been selected to participate in Google Summer of Code (GSoC) 2026! I will be contributing to the openSUSE Project.

The Project: Enhancing openSUSE Git Workflow

During the next 12 weeks, I will be working on improving the obs-status-service. Under the mentorship of Daniel García Moreno (dgarcia) and Doug, my main objectives include:

• Improving Visualizations: Extending the Go tool to generate better SVG images with new CSS styles and making them interactive with JavaScript.
• Gitea Bot Integration: Implementing a new bot for Gitea that provides useful build information directly inside Pull Requests.
• AI Integration (Stretch Goal): Exploring the use of AI through Log Detective to analyze and assist with PRs that fail to build.

Moving Forward

Given the dynamic nature of the GSoC program and software development itself, it’s very likely that these initial goals will adapt and change slightly as the weeks go by.

I’m ready to learn, face new challenges, and contribute to the open-source community. Stay tuned, as I will be posting my weekly progress right here!

Table of Contents

• 1) Introduction
• 2) Overview of the qSnapper D-Bus Service
• 3) Security Issues
  • 3.1) Weak Polkit Authentication Check is Subject to Race Condition (CVE-2026-41045)
  • 3.2) Path Traversal via configName Parameter (CVE-2026-41046)
  • 3.3) Information Leak via “diff” Methods (CVE-2026-41047)
  • 3.4) Caching of Authentication allows Authentication Bypass (CVE-2026-41048, CVE-2026-41049)
  • 3.5) Defense-in-Depth Issues when Restoring Arbitrary Files
  • 3.6) Other Issues
• 4) Upstream Bugfixes
• 5) Disclosure Process
• 6) Timeline
• 7) References

1) Introduction

qSnapper is a GUI frontend for the snapper utility for managing Btrfs filesystem snapshots. In April we received a review request for qSnapper, because it contains a privileged D-Bus service and Polkit policies.

Normally, Btrfs snapshots can only be managed with root privileges. qSnapper aims to provide more user-friendly and fine-grained access to snapshot management features, based on a privileged daemon which utilizes D-Bus and Polkit. Our review of the service uncovered various security issues, which led to a longer coordinated disclosure to allow upstream to develop bugfixes, which are part of upstream release 1.3.3.

The full details of the security issues will be covered in the sections below. The original review was performed on qSnapper release 1.1.3. Since bigger upstream changes appeared in the meantime this report is based on qSnapper release 1.3.2, however.

2) Overview of the qSnapper D-Bus Service

The qSnapper project contains a daemon named qsnapper-dbus-service, which runs with full root privileges. The daemon provides the D-Bus interface “com.presire.qsnapper.Operations” on the system bus; some of its methods are provided to arbitrary users in the system without authentication, while the majority of them is protected by Polkit authentication checks. The implementation of the various D-Bus methods offered by the service is found in snapshotoperations.cpp. All of the security issues outlined below are located in this compilation unit.

3) Security Issues

3.1) Weak Polkit Authentication Check is Subject to Race Condition (CVE-2026-41045)

The SnapshotOperations::checkAuthorization() function uses Polkit’s UnixProcess subject in an unsafe way to authenticate clients. The code obtains the client’s PID from the active D-Bus connection, which leads to a race condition. At the time the Polkit daemon (polkitd) checks the provided PID, the process in question can already have been replaced by another, privileged process. This is a well-known class of Polkit authentication bypasses which was assigned CVE-2013-4288.

In effect this means that clients may be able to bypass all Polkit authentication checks performed by qSnapper, although the attack is somewhat complex and might need multiple attempts to succeed. There is nothing stopping a local attacker from doing that, however. In combination with the configuration path traversal in D-Bus methods like WriteSnapperConfig() described below, this can be used to achieve a full local root exploit.

To fix this, we suggested to use Polkit’s SystemBusName subject instead. With this subject, the D-Bus daemon obtains the client’s UID in a race-free fashion from the UNIX domain socket the client used to connect, and polkitd cannot be fooled by recycled PIDs.

3.2) Path Traversal via configName Parameter (CVE-2026-41046)

All the D-Bus methods accepting a configName parameter (that is nearly all of them) suffer from a path traversal vulnerability. This string parameter is directly passed to snapper::Snapper(), which is part of the libsnapper API, without checking its safety. libsnapper expects a basename here to look up a configuration file in /etc/snapper/configs. In the context of qSnapper this string can contain additional path components like ../../path/to/crafted.cfg. This allows clients to use arbitrary configuration files as input to libsnapper.

When looking at the writeSnapperConfig() D-Bus method, which requires admin authentication, this path traversal allows to write largely attacker-controlled data to arbitrary locations. Combined with the Polkit authentication bypass described earlier in section 3.1, this would allow for a full local root exploit.

In case of other D-Bus methods which use the “list-snapshots” Polkit action, the path traversal is also accessible to locally logged-in users without any authentication. Luckily the libsnapper configuration file format offers no features that lead to a trivial local root exploit in this context. The impact of the vulnerability can be any of the following, however:

• local Denial-of-Service (DoS): by pointing libsnapper to a special file like /dev/zero, the daemon will consume the maximum amount of memory and be killed by the kernel. By pointing libsnapper to a named FIFO special file, the daemon will block indefinitely.
• information leak from parsing of private files: by pointing libsnapper to a private file like /etc/shadow, libsnapper will parse the sensitive data from the file as configuration data. If any logging features are active and the logs can be accessed by unprivileged users, then private data from such a file might leak into the unprivileged context. We are not aware of such an information leak in default installations, however.
• by providing crafted configuration data further attacks can be carried out:
  • SUBVOLUME can be pointed to arbitrary mounts in the system. Luckily libsnapper is conservative in its file operations here, and quite strictly verifies the validity of this path; it verifies if it is really a mount point and is backed by the expected block device and file system etc.
  • ALLOW_USERS and ALLOW_GROUPS can be set to arbitrary users and groups, allowing them officially to control the Snapper configuration.
  • The SYNC_ACL setting causes libsnapper to apply ACL entries to the .snapshots directory of the volume path, granting the users and groups from ALLOW_USERS and ALLOW_GROUPS to access the snapshot data. Thus this is a major local information leak.

libsnapper is using different backends depending on the file system type. Different code is used for each backend, which means that the exploitability of some aspects of the vulnerability depends on which backend is used. On openSUSE only the Btrfs and LVM thin volume backends are compiled-in by default, which only offer little additional attack surface.

To fix the issue, we suggested to upstream to verify the configName parameter in all cases and reject it if any / or .. components are found in it.

3.3) Information Leak via “diff” Methods (CVE-2026-41047)

The Polkit action “list-snapshots” is allowed for locally logged-in users without authentication, and is used by multiple qSnapper D-Bus methods which are likely considered “read-only” operations not harmful to the system. In version 1.1.3 of qSnapper the following methods are relying on this Polkit action:

• ListSnapshots()
• GetFileChanges()
• GetFileDiffAndDetails()

In version 1.3.2 of qSnapper these additional methods are using the action:

• GetFileChangesBetween()
• GetFileDiffBetween()

These methods allow to obtain information about metadata changes of arbitrary files between snapshots or between snapshots and the live filesystem. The newer GetFileDiffBetween() method even offers full file content diff output. These are major local information leaks, since unprivileged users can get a diff e.g. of the /etc/shadow file between different system states, or changes from root’s home directory which could leak sensitive data like passwords or private keys.

To fix this, we suggested to upstream that all methods providing non-public information get restricted by auth_admin Polkit checks. Alternatively, a check could be implemented whether the files to be diffed are normally accessible to the caller by using checks similar to the access() system call; such an approach would likely be rather complex and error-prone, however.

3.4) Caching of Authentication allows Authentication Bypass (CVE-2026-41048, CVE-2026-41049)

In version 1.2.1 of qSnapper an m_authenticated flag was introduced to the daemon’s code, which caches authentication once a client has passed certain Polkit action authentication checks. This cached authentication is shared between the methods DeleteSnapshot(), RestoreFiles() and RestoreFilesDirect(). There are two issues with this approach:

• DeleteSnapshot() uses the “delete-snapshot” action, while the other methods use the “rollback-snapshot” action. If a caller can authenticate for “delete-snapshot” then it is also implicitly authenticated for “rollback-snapshot” and vice versa. This is not how Polkit is intended to be used. If a system administrator decides to relax the authentication requirement for “delete-snapshot”, then this automatically implies the “rollback-snapshot” action now, which are two very different impacts to the system. We assigned CVE-2026-41048 for this aspect of the issue.
• The implementation of the caching logic assumes that a single interactive client is talking to the daemon. In fact, arbitrary users can invoke these methods. If a legitimate client is authenticated for one of the affected actions once, then arbitrary other users like nobody are now also considered authenticated and Polkit will not be invoked anymore. This authentication bypass allows for a full local root exploit in the context of the RestoreFiles() methods, as outlined below in section 3.6. We assigned CVE-2026-41049 for this aspect of the issue.

We suggested to upstream to drop this form of authentication caching, or alternatively implement an authentication cache tied to each user and each Polkit action in question to avoid the issues.

3.5) Defense-in-Depth Issues when Restoring Arbitrary Files

This section discusses Defense-in-Depth issues which remain once all the more tangible issues discussed above are fixed. The restoreFiles() D-Bus method accepts arbitrary filePaths as parameter to be restored from a version found in a snapshot. Clients need to authenticate as an administrator to do this, so there is no direct attack surface. Let’s consider the path /var/lib/colord/mapping.db to be restored, however:

# On openSUSE Tumbleweed this directory is owned and writable by `colord`
$ ls -lh /var/lib/colord
drwxr-xr-x 3 colord colord 4.0K Mar 6 2024 .

At the time the qSnapper service performs the chown() system call, the colord service user can stage a symlink attack in the colord directory and cause arbitrary files in the system to receive colord ownership, allowing a colord to root exploit. A similar issue affects the copyRegularFile() function, where a file on the live file system is newly created.

This issue is hard to fix, given the many different file system situations that the restore operation can end up in. The basic algorithm to address the problem would need to use low-level system calls like openat(), fchown() and fstatat() to safely traverse file system paths and inspect any symbolic links on the way. Given the complexity of the bugfix and limited impact, we agreed with the upstream author that this fix does not need to be prepared during the coordinated disclosure period but can be developed in the open afterwards.

Given the amount of front-line security issues already found in qSnapper in the course of this review, we refrained from assigning a dedicated CVE for these Defense-in-Depth issues in this case.

3.6) Other Issues

This section covers a number of other issues that are not fully-fledged security issues, but still represent weaknesses or possible hardenings for the qSnapper implementation.

• the D-Bus method RestoreFiles() implements complex file operations to rollback changes of a file path to the state found in a snapshot. These file operations allow authenticated clients to achieve nearly arbitrary file operations:
  • recursive deletion of arbitrary paths
  • copy of arbitrary files to arbitrary locations
  • change of ownership of files to arbitrary users
  • change of the file mode to arbitrary values

  This is because the method is not verifying whether the claimed file exists in the snapshot in the first place and whether the filePaths contain any ../ directory components to escape the snapshot directory. While this method is protected by Polkit’s auth_admin setting, any D-Bus method should be written conservatively and in such a way that the intended purpose of the method cannot be bypassed. The very similar method RestoreFilesDirect() has the same issues and also contains a lot of duplicate code which should be merged with the other method’s code.

• the Quit() method can be called by anyone in the system without authentication. This is kind of a local DoS against an active qSnapper daemon in use by other users in the system.
• the logfile created in /var/log/qSnapper will be world-readable, which could leak sensitive information. For hardening purposes it could be made private to root.

4) Upstream Bugfixes

The upstream author closely followed our suggestions to fix the security issues described in this report. Version 1.3.3 of qSnapper contains the following bugfixes:

• commit a6caf538 addresses the following issues:
  • the Polkit UnixProcess subject is replaced by the SystemBusName subject to avoid the race condition during authentication (issue 3.1).
  • the configName parameter in all D-Bus methods is now carefully verified and rejected if it allows path traversal (issue 3.2).
  • the authentication caching is removed (issue 3.4).
  • the RestoreFiles methods reject path traversal attempts (see section 3.6).
• commit f375b74c addresses the following issues:
  • a new view-diff Polkit action is introduced to generate file diffs which requires auth_admin authentication to prevent information leaks (issue 3.3).
  • the unauthenticated Quit D-Bus method was dropped (see section 3.6).
  • log files are now created without world-readable bit (see section 3.6).

The more complex defense-in-depth issues outlined in section 3.5 will be addressed by upstream in the open at a later time.

5) Disclosure Process

Once we established contact with the upstream author, we had a very constructive discussion of the coordinated disclosure process. Upstream quickly acknowledged the issues, opted for coordinated disclosure and communicated a time schedule when bugfixes were expected to be available for review and when a bugfix release of qSnapper would be published. When we agreed on the final bugfixes in the middle of May, we agreed on choosing an earlier publication date than originally intended.

We want to thank the upstream author for handling this report in a very professional fashion and for greatly improving the security and robustness of qSnapper.

6) Timeline

7) References

• qSnapper GitHub repository
• qSnapper 1.3.3 bugfix release
• openSUSE review bug for qSnapper

Breaking New Ground: Mobile Linux Hackday #1 in České Budějovice Outperforms Prague! If you’ve been following the Mobile Linux journey in Czechia, you know we’ve built a fantastic routine in Prague. We have a really successful series behind us consisting of 7 monthly hackdays, always hosted at the Prague SUSE office. But when the stars […]

The post MobileLinux Hackday #1 in České Budějovice Outperforms Prague! appeared first on SUSE Communities.

Dear Tumbleweed users and hackers,

This week is quite difficult for me to estimate how busy it was in Tumbleweed, as I was spending the whole week at a conference and, right now, I am on the train on my way back home. Nevertheless, I want to try to summarize for you what has happened during the last week, and what snapshots you have received.

Last week I had already mentioned the upcoming integration of AppArmore 5.0 and the fact that we have observed a new curl profile causing some hiccups. Sadly, beyond that, more profiles were added/improved, which hit quite a few wifi users (wpa_supplicant profile), and we did not catch that in openQA. The main tests on openQA are geared towards the default installation, which is based on SELinux by now. There are a few additional tests intentionally added for AppArmor (which is how we found out about the cURL profile). Secondly, it only appears in combination with WiFi/wpa_supplicant, which we do test in openQA (there mainly for wpa2-enterprise integration) – but as you can imagine, the combination AppArmor/WiFi is missing. Thanks to all the users who reported the issue, and special thanks to Christian for fixing the issue as fast as he did!

Besides that, of course, more has happened. A total of 6 snapshots (0514, 0515, 0516, 0518, 0519, and 0520) were built, tested, and published, shipping these changes:

• AppArmor 5.0.0
• KDE Plasma 6.6.5
• fwupd 2.1.3
• GStreamer 1.28.3
• Linux kernel 7.0.6, 7.0.7 & 7.0.9
• Ruby 4.0.4
• Apache 2.4.67
• gpg 2.5.20
• pipewire 1.6.5
• librsvg 2.62.2
• PostgreSQL 18.4

The pipeline currently contains these changes/updates:

• Poppler 26.05.0
• Agama 21 (see blog post by the Agama developers)
• Rework of python3 packaging (as a meta package instead of a provides of the default compiler)
• gcc 16 as the system default compiler

Managing System Extensions on openSUSE MicroOS with sysextmgrcli

If you are running openSUSE MicroOS, you already know the drill: the root filesystem is read-only, and transactional updates are the law of the land.

But what happens when you need to add software or system extensions without rebooting or messing with your base OS layers?

E.g. You need strace or gdb to debug a running application, but a reboot to install this tools would change the situation.

Enter System Extensions (sysext images) and the utility designed to make them manageable: sysextmgrcli.

What is sysextmgrcli?

At its core, sysextmgrcli is a command-line client for managing systemd-sysext images and has been written by Thorsten Kukuk. It is designed specifically to play nice with the atomic nature of MicroOS.

Instead of forcing you to use sudo for every query, it talks to a background daemon (sysextmgrd) via Varlink. This architecture allows unprivileged users to list existing system extension images without needing root permissions, while the daemon handles the heavy lifting of downloads and verification via systemd-pull. For security reasons, root provileges are still required for installing or updating sysext images.

The Architecture: Smart Snapshots

One of the cleverest things about sysextmgrcli is how it handles storage to be efficient and “rollback-safe”:

• /var/lib/sysext-store: This is where the actual image files live. Since /var is a separate subvolume shared across all Btrfs snapshots, you only store the image once, saving disk space. If you have no network available, that’s the location for storing offline or even own build sysext images via e.g. an USB device.

• /etc/extensions: This directory contains symlinks to the images in the store. Because /etc is part of your root snapshot, the extensions are tied to your current system state.

Why does this matter? If you perform a system rollback, your symlinks roll back too. This ensures the active sysext images always match the OS version you are currently booted into.

Essential Commands

Getting started is straightforward. Here are the primary commands you’ll use to manage your extensions:

1. Listing and Checking Images

Want to see what’s available or if your images are compatible with your current OS version?

# List all images and report compatibility
sysextmgrcli list

# Check for updates and verify compatibility
sysextmgrcli check

2. Installing New Extensions

You can install by providing a name and a source URL. The tool automatically handles SHA256 verification and checks if it fits your OS.

# --url is optional (default: https://download.opensuse.org/tumbleweed/appliances/ )
sysextmgrcli install [NAME] --url [https://your-image-repo.com](https://your-image-repo.com)

3. Maintenance and Updates

Updates are handled by comparing local files against remote manifests. If a newer version matches your current snapshot, it gets pulled down and symlinked.

# Update existing images to the latest compatible versions
sysextmgrcli update

# Clean up: Remove images in the store that are no longer referenced by any snapshot
sysextmgrcli cleanup

The “Activation” Catch

It is important to note that sysextmgrcli is a manager, not an activator. It handles the logistics: downloading, version checking, and symlinking. To actually “plug in” the extensions to your running system, you still use standard systemd-sysext commands:

• Manual activation: systemd-sysext merge

• Manual deactivation: systemd-sysext unmerge

• Enable at boot: systemctl enable systemd-sysext.service

Available default system extention (sysext) images:

• debug (babeltrace, gdb, ltrace, strace, traceroute)
• gcc (cpp, gcc, make, patch)
• git (git, git-core)

Summary

You need git on your openSUSE MicroOS ?

Just call sysextmgrcli install git ; systemd-sysext merge and use it…

You do not need ‘git’ anymore on your system ?

Just call systemd-sysext unmerge and it is not available anymore…

sysextmgrcli bridges the gap between static immutable infrastructure and the need for flexible system additions. By leveraging the Btrfs directory structure of MicroOS, it ensures your system remains clean, version-synced, and easy to manage.

We know, we know. We skipped a blog post for version 20 and you may be wondering what happened. The truth is that we were heads-down working on several significant improvements and decided to focus on shipping rather than writing. But don't worry - this release announcement covers the most relevant changes introduced in both versions 20 and 21.

In exchange for the delay we offer you an extensive list of impressive enhancements, covering several aspects of the installation experience and including some long-awaited features. Let's go through the most visible novelties.

Shedding some light on the desktops​

And few things are more visible in a GNU/Linux system than its desktop environment. During installation, most openSUSE distributions provide a wide range of desktops to select from. But openSUSE does not endorse any of those environments as the default option. As a consequence, the user needs to make a conscious decision during installation.

That was not obvious enough in previous versions of Agama. As a result, it was too easy to end up installing a system with no graphical interface at all. The resulting text-based system could be daunting for many users, especially newbies to openSUSE or GNU/Linux in general.

Now the situation is more clearly presented in the main summary screen of the installer and in the software selection section.

We took the opportunity to rethink several aspects of the form used to select patterns. Now it works in a way that is more consistent with the rest of the Agama interface and it presents the information in a more useful way.

In addition to all that, a reminder about the potentially missing desktop was added in the confirmation dialog for some distributions like openSUSE Tumbleweed, Slowroll or Leap 16.1.

Better network management in the web UI​

Usability improvements go beyond the software management. The user interface for configuring the network also received some serious attention in these releases. The most visible result is a completely redesigned form to create and modify network connections.

With the new form, we are now in the position to enrich the web interface with the ability to configure more types of connections, in addition to Ethernet and Wi-Fi. In previous releases, it was necessary to use the JSON-based Agama configuration format in order to setup a network bonding, a bridge or a VLAN connection. With Agama 21 it is now possible to configure a bonding or bridge connection directly from the user interface. As usual, Agama offers reasonable default settings for each kind of connection but it also allows to setup several advanced aspects manually.

Support for VLAN connections is on its way and will be included in the upcoming version of the Agama web interface. Hopefully these new features will fulfill the wishes of those users who have been requesting a more powerful user interface to configure the network.

Install on an existing LVM setup​

But if there is a feature that has been long awaited by some users, that is the ability to reuse existing LVM volume groups and logical volumes. If you had an existing LVM setup on your system, previous versions of Agama couldn't take advantage of it. Now it is possible thanks to a new feature that, as usual, is built at two levels.

On the one hand, the JSON configuration format was expanded to support all kind of operations with existing volume groups and logical volumes. That includes expanding the volume groups with new physical volumes and also mounting, formatting and resizing all kind of logical volumes. It is even possible to create new thin volumes in a reused thin pool.

On the other hand, the web user interface now allows to select an existing volume group as destination for the installation and also as additional device to create or reuse more logical volumes.

The user interface also makes it possible to define what to do with the current logical volumes in the same way that it can be done for the current partitions of a disk.

Support for Systemd-boot​

So far, Agama has always installed Grub2 as boot loader for all distributions. At least, that was the idea, although Systemd-boot slipped through the cracks in some openSUSE Tumbleweed installations due to changes introduced in the internals shared between YaST and Agama.

But in EFI environments, it seems there is a trend among many Linux distributions to adopt the UAPI Boot Loader Specification. And we do not want Agama to fall behind.

Although Grub2 is still used unconditionally in many scenarios, now every distribution ("product" in Agama's jargon) can define which boot loader to install in some supported EFI systems. Products can choose between Grub2, Systemd-boot or openSUSE's Grub2-BLS. In the latter two cases, Agama will adhere to the mentioned UAPI Boot Loader Specification.

Based on the chosen boot loader, Agama automatically adapts the partitioning and uses the corresponding methodology and tools to configure the TPM to automatically unlock encrypted devices, if the user decided to do so.

For products that still rely on Grub2, like the beta versions of openSUSE Leap 16.1 and SUSE Enterprise Linux Server 16.1, the user can force the usage of Systemd-boot where possible by starting the installation with the boot argument inst.systemd_boot_preview=1.

NTP configuration​

As most of our readers surely know, the Network Time Protocol (NTP) is typically used to set the date and time of computers through the network connection. That normally works out of the box if the network offers access to the Internet or if the address of a local NTP server is provided as part of the automatic network configuration (eg. using DHCP). But sometimes some manual configuration is needed.

Agama now allows to explicitly set the list of NTP sources (pools, servers and peers) using the JSON format. It also supports automatic conversion from the corresponding ntp-client section of an AutoYaST profile. Last but not least, the web interface now offers a new "System" section accommodating the configuration of both the hostname and the NTP sources.

But there is an important aspect to consider. In order to establish secure network connections, the date and time must be aligned with the date and time of the other system and all the involved certificates. For network-based installations, in which secure connections may be needed already in order to fetch the installation media, that implies the NTP configuration must happen at a very early stage of the booting process. For that, the installation media now supports the special boot argument rd.ntp that allows to setup the NTP sources.

Agama will take care to persist to the installed system any setting configured through Agama itself or by using the rd.ntp boot option.

Restrict network access to the installer​

Speaking of installations and network, you already know that by default Agama allows to control the installation process over the network from another computer or mobile device. But that is a feature that could come with security implications in some scenarios.

Now it is possible to disable the remote access with the inst.remote=0 boot option. When used, the installer can be accessed only locally from the machine being installed.

Usability improvements in the command-line tools​

Apart from all the mentioned new installer features, the command-line interface also received several enhancements to make it more useful for tracking the current state of the installation process. Whether you are automating installations or just prefer working from the terminal, the improved CLI tools provide better visibility into what Agama is doing at any given moment. These improvements make it easier to monitor installations, debug issues and integrate Agama into your existing automation workflows.

More to come​

As you can see, we have not been idle lately. After these two feature-packed releases we are planning to shift our focus a bit more toward stabilization and polish. That doesn't mean development is slowing down, though! We still plan to release Agama 22 in about a month, and it will include some cool new features alongside the stability improvements.

As always, we appreciate your feedback and contributions. You can reach the YaST team at the YaST Development mailing list, our #yast channel at Libera.chat or the Agama project at GitHub.

Have a lot of fun!

How can you learn syslog-ng? There are many possibilities, depending on your time and budget. Possibilities range from tutorial series through reading the documentation to instructor-led training. Find out which one is for you!

Read more at https://www.syslog-ng.com/community/b/blog/posts/learning-syslog-ng