Last week I introduced you to my latest project: a syslog-ng container based on Alma Linux. This week I added a syslog-ng Prometheus exporter to the container, so you can also monitor syslog-ng, if you enable it.

With Microsoft ending support for Windows 10 in October 2025, millions of users are looking for alternatives that avoid costly hardware upgrades, additional upgrade costs to Windows 11 depending on the country a person is in or to mitigate security risks.

A compelling options for many are open-source operating systems. Linux distributions like openSUSE and others extend the life of hardware, enhance security and provide flexibility without additional expenses.

For those who reached this point, this Upgrade to Freedom guide will detail a beginner-friendly approach to transitioning from Windows to one of openSUSE’s distributions, which are known for being user-friendly, stable, and powerful.

Step 1: Prepare Your System

Before diving into the installation process, take the following steps to prepare:

1. Back Up Your Data
   Save important files to an external drive, cloud storage or another secure location. Transitioning to Linux distributions typically involves reformatting your hard drive, which will erase existing data.

2. Check Your Hardware Compatibility
   Most modern hardware works well with Linux, but it’s good practice to confirm compatibility. Visit the openSUSE wiki for more information.

3. Choose Your Version of openSUSE
   openSUSE offers two versions:

   • Leap: A stable release designed for extended reliability and maintenance.
   • Tumbleweed: A rolling release with the latest updates.

   Beginners often prefer Leap for its stability. Tumbleweed will have constant, almost daily updates. Tumbleweed is favored by enthusiasts and developers who prioritize access to the newest features, technologies, and software update

Step 2: Download openSUSE

1. Visit get.opensuse.org.
2. Select the version you prefer (Leap or Tumbleweed).
3. Download the ISO file to your computer.

Step 3: Create a Bootable USB

You’ll need a USB drive (at least 8GB) to install openSUSE.

1. Insert a USB Drive
   Plug the USB drive into your computer.

2. Create the Bootable USB
   Use software like:

   • Rufus (Windows)
   • Etcher (cross-platform)

   Select the downloaded openSUSE ISO file and follow the tool’s instructions to write the ISO to the USB drive.

Step 4: Boot Into the Installer

1. Restart Your Computer
   During the boot process, press the key to enter your BIOS or boot menu (typically F2, F10, F12, or Delete).

2. Select the USB Drive
   From the boot menu, choose your USB drive as the boot device. Then save and exit.

3. Start the Installation
   When the openSUSE installer loads, select “Install.”

Step 5: Install openSUSE

The openSUSE installer will guide you through the setup process.

1. Select Your Language and Region
   Choose your preferred language and time zone.

2. Partition Your Drive
   • Select automatic partitioning if you’re unsure.
   • For advanced users, manual partitioning allows custom setups.

3. Create a User Account
   Set up a username, password, and root (administrator) password.

4. Review and Confirm
   The installer will show a summary of your settings. Confirm to begin the installation.

There are options to select Desktop Environments (DE) during instalations. GNOME, KDE Plasma, Xfce and more. It’s a good idea to research these DEs beforehand to find one that matches your preferences. Many new users find GNOME reminiscent of macOS, while KDE Plasma and Xfce are often compared by new users to the traditional Windows desktop.

Step 6: Configure Your System

Once the installation is complete, restart your computer and remove the USB drive. openSUSE will boot up, and you can begin configuring your system.

1. Set Up Updates
   Run the following command in the terminal to update your system: Leap

   sudo zypper update
   

   Tumbleweed

   sudo zypper dup
   

   Congratulations on your Upgrade to Freedom!!!

Moving to Linux offers significant environmental benefits, as highlighted by Joanna Murzyn at the 2024 KDE Akademy conference, where she warned about the growing e-waste crisis and emphasized the importance of extending the lifespan of perfectly usable computers in her presentation, Only Hackers Will Survive.

This is part of a series on Upgrade to Freedom where we offer reasons to transition from Windows to Linux.

With Microsoft ending support for Windows 10 in October 2025, millions of users are looking for alternatives that avoid costly hardware upgrades, additional upgrade costs to Windows 11 depending on the country a person is in or to mitigate security risks.

A compelling options for many are open-source operating systems. Linux distributions like openSUSE and others extend the life of hardware, enhance security and provide flexibility without additional expenses.

For those who reached this point, this Upgrade to Freedom guide will detail a beginner-friendly approach to transitioning from Windows to one of openSUSE’s distributions, which are known for being user-friendly, stable, and powerful.

Step 1: Prepare Your System

Before diving into the installation process, take the following steps to prepare:

1. Back Up Your Data
   Save important files to an external drive, cloud storage or another secure location. Transitioning to Linux distributions typically involves reformatting your hard drive, which will erase existing data.

2. Check Your Hardware Compatibility
   Most modern hardware works well with Linux, but it’s good practice to confirm compatibility. Visit the openSUSE wiki for more information.

3. Choose Your Version of openSUSE
   openSUSE offers two versions:

   • Leap: A stable release designed for extended reliability and maintenance.
   • Tumbleweed: A rolling release with the latest updates.

   Beginners often prefer Leap for its stability. Tumbleweed will have constant, almost daily updates. Tumbleweed is favored by enthusiasts and developers who prioritize access to the newest features, technologies, and software update

Step 2: Download openSUSE

1. Visit get.opensuse.org.
2. Select the version you prefer (Leap or Tumbleweed).
3. Download the ISO file to your computer.

Step 3: Create a Bootable USB

You’ll need a USB drive (at least 8GB) to install openSUSE.

1. Insert a USB Drive
   Plug the USB drive into your computer.

2. Create the Bootable USB
   Use software like:

   • Rufus (Windows)
   • Etcher (cross-platform)

   Select the downloaded openSUSE ISO file and follow the tool’s instructions to write the ISO to the USB drive.

Step 4: Boot Into the Installer

1. Restart Your Computer
   During the boot process, press the key to enter your BIOS or boot menu (typically F2, F10, F12, or Delete).

2. Select the USB Drive
   From the boot menu, choose your USB drive as the boot device. Then save and exit.

3. Start the Installation
   When the openSUSE installer loads, select “Install.”

Step 5: Install openSUSE

The openSUSE installer will guide you through the setup process.

1. Select Your Language and Region
   Choose your preferred language and time zone.

2. Partition Your Drive
   • Select automatic partitioning if you’re unsure.
   • For advanced users, manual partitioning allows custom setups.

3. Create a User Account
   Set up a username, password, and root (administrator) password.

4. Review and Confirm
   The installer will show a summary of your settings. Confirm to begin the installation.

There are options to select Desktop Environments (DE) during instalations. GNOME, KDE Plasma, Xfce and more. It’s a good idea to research these DEs beforehand to find one that matches your preferences. Many new users find GNOME reminiscent of macOS, while KDE Plasma and Xfce are often compared by new users to the traditional Windows desktop.

Step 6: Configure Your System

Once the installation is complete, restart your computer and remove the USB drive. openSUSE will boot up, and you can begin configuring your system.

1. Set Up Updates
   Run the following command in the terminal to update your system: Leap

   sudo zypper update
   

   Tumbleweed

   sudo zypper dup
   

   Congratulations on your Upgrade to Freedom!!!

Moving to Linux offers significant environmental benefits, as highlighted by Joanna Murzyn at the 2024 KDE Akademy conference, where she warned about the growing e-waste crisis and emphasized the importance of extending the lifespan of perfectly usable computers in her presentation, Only Hackers Will Survive.

This is part of a series on Upgrade to Freedom where we offer reasons to transition from Windows to Linux.Those who would like to order a laptop with Linux, can visit slimbook.com or other providers of Linux machines.

Table of Contents

• 1) Introduction
• 2) Problems in the instance_create D-Bus Method
  • 2a) Script Options Allow Local Root Exploit (CVE-2024-52336)
  • 2b) Instance Name can Contain Arbitrary Data (CVE-2024-52337)
  • Affectedness
• 3) Problems in the PowerProfiles Interface
  • 3a) Cookie in PowerProfiles API is Predictable
  • 3b) User Supplied Strings can Contain Arbitrary Data
  • Suggested Fix
• 4) Bugfixes
• 5) Timeline
• 6) References

1) Introduction

Tuned is a privileged daemon for Linux that supports automatic tuning of various hardware and kernel settings during runtime. The daemon offers a comprehensive D-Bus interface protected by Polkit authentication. We regularly perform reviews of newly introduced D-Bus system services and changes to them. Tuned sees frequent additions to its D-Bus interface and this is already the tenth review of it that we carried out since 2019. Usually the reviews are straightforward and we have no complaints, but this time was the exception.

During the review we checked the D-Bus methods matching the following Polkit actions:

com.redhat.tuned.instance_create        (auth_admin:auth_admin:yes)
com.redhat.tuned.instance_destroy       (auth_admin:auth_admin:yes)
net.hadess.PowerProfiles.HoldProfile    (no:no:yes)
net.hadess.PowerProfiles.ReleaseProfile (no:no:yes)

This report is based on tuned release v2.24.0.

2) Problems in the instance_create D-Bus Method

Calling the instance_create() D-Bus method is allowed without authentication for locally logged-in users (yes Polkit setting). The method call accepts various parameters, including an options dictionary, that are fully under attacker control.

2a) Script Options Allow Local Root Exploit (CVE-2024-52336)

The script_pre and script_post options allow to pass arbitrary scripts that will be executed by root. The parameters are extracted in daemon/controller.py:459, stored unmodified in a new Instance object and the only verification of the script path is performed in plugins/base.py:222:

    if not script.startswith("/"):
        log.error("Relative paths cannot be used in script_pre or script_post. " \
                + "Use ${i:PROFILE_DIR}.")
        return False

So the only requirement is that an absolute path is passed. Thus, scripts under control of an unprivileged user can be passed here. This allows for a local root exploit.

Reproducer

As a locally logged-in non-privileged user execute the following D-Bus call:

    $ gdbus call -y -d com.redhat.tuned -o /Tuned \
        -m com.redhat.tuned.control.instance_create cpu myinstance \
        '{"script_pre": "/path/to/myscript.sh", "devices": "*"}'

The path /path/to/myscript.sh needs to be replaced by a path to a user controlled executable script or program. It will be executed by tuned with root privileges.

2b) Instance Name can Contain Arbitrary Data (CVE-2024-52337)

The instance_name parameter of the instance_create() method is not sanitized. This string is later on used in logging and in the output of utilities like tuned-adm get_instances, or other third party programs that utilize tuned’s D-Bus interface to obtain instance names.

A local attacker can include arbitrary data in the instance name and can achieve log spoofing this way. By placing newline characters into the name, seemingly independent, legitimate-looking entries can be added to the tuned log. By adding terminal control sequences the terminal emulators of administrators or other users can be influenced. The following is a Proof-of-Concept for this:

    $ EVIL=`echo -e "this is\nevil\033[?1047h"`
    $ gdbus call -y -d com.redhat.tuned -o /Tuned -m com.redhat.tuned.control.instance_create cpu "$EVIL" '{"devices": "*"}'

When another user now calls tuned-adm get_instances then the terminal emulator will switch to the alternate screen upon output of the crafted instance name.

Affectedness

The instance_create() D-Bus method has been added via upstream commit cddcd233 and was first part of version tag v2.23.0. The initial version already contained support for the script option parameters and the instance_name parameter.

3) Problems in the PowerProfiles Interface

3a) Cookie in PowerProfiles API is Predictable

The new D-Bus methods HoldProfile() and ReleaseProfile() use a cookie to identify a profile hold. The cookie is simply a continuously increasing integer starting at zero. This means other users in the system can easily release the profile holds of other users.

3b) User Supplied Strings can Contain Arbitrary Data

The HoldProfile() call accepts reason and app_id strings which are used in logging and may also be returned as a dictionary via ProfileHold.as_dict(). These strings can again contain crafted data that could have side effects similar to the ones shown in section 2b).

Suggested Fix

A local DoS scenario using the cookie would only be an issue on multi-user systems, or if the Polkit settings are relaxed so that also non-local sessions can use these D-Bus methods. One way to make this more robust could be to hand out random cookie IDs instead, to make the attack less trivial.

4) Bugfixes

Upstream published release v2.24.1 that addresses the issues described in this report. Commit 90c24eea037 contains the cumulative fixes as follows:

• plugins are now only loaded from trusted locations (_safe_script_path() function).
• various user supplied strings are rejected if they contain disallowed characters (is_valid_name() function).
• upstream also tightened the tuned Polkit policy for instance_create and a number of other actions, that they also found to be problematic when accessed by local unprivileged users.

For issue 3a) no upstream fix is available at the moment. This is more of a hardening suggestion, though.

5) Timeline

6) References

• Tuned GitHub project
• Bugfix release v2.24.1
• Bugfix commit

Table of Contents

• 1) Introduction
• 2) Vulnerability Details
• 3) Review Summary
• 4) Timeline
• 5) References

1) Introduction

Authentik is a popular open source identity provider that can be self-hosted. SUSE IT is considering to use this software internally in the future and thus we have been asked to have a look at its security.

The Authentik version we examined was 2024.8.3. Beyond the finding in this report, we also discovered the possibility to access SSL private keys without authentication, but this was independently discovered and fixed in parallel by upstream before we had a chance to report it. The only CVE-worthy finding that was left is discussed in the next section. Some general insights into the security of Authentik are given in section 3).

2) Vulnerability Details

The MetricsView, reachable via URL “/-/metrics/”, implements HTTP basic auth in authentik/root/monitoring.py:27. The expected username is hard-coded to be monitor. The expected password is the constant settings.SECRET_KEY, which is the same as the AUTHENTIK_SECRET_KEY, generated when setting up Authentik. According to documentation it is used for cookie signing and in older versions also for “unique user IDs”.

To verify the password, the implementation uses the regular Python “==” string comparison operator. This operator will optimize the string comparison, making it likely possible to employ timing attacks to guess the correct SECRET_KEY. Security research has repeatedly shown that timing attacks are a realistic danger, even over the network.

Exploiting this vulnerability is likely complex, but a determined attacker might be able to develop a successful approach. We did not look in more detail into how to exploit the issue.

Upstream published a security advisory and provides fixes for this issue in versions 2024.10.3 and 2024.8.5. It is also possible to employ a workaround by making the affected API endpoint inaccessible for remote users.

3) Review Summary

Authentik is a big project consisting of about 10,000 lines of Golang code and nearly 100,000 lines of Python code. It uses various web frameworks and a rather complex set of abstractions. Reviewing this in full with our limited resources is impossible. Thus we concentrated on inspecting the accessible REST API endpoints and tried to get a general feel for the robustness of the software.

The web frameworks and development style used in Authentik result in pretty robust REST API endpoints. Even when issues are found, the upstream project shows that it is well organized and manages to fix them quickly and transparently.

The sheer amount of features supported by Authentik in terms of network protocols, authentication mechanisms etc. is big and results in a level of complexity that is hard to manage. Keeping track of the interactions of all these features with client and third party systems is a challenge. Authentik also implements a complex permission framework of over 500 different privileges for controlling access to the system. We suggest to train administrators of such systems well to avoid that issues are introduced through bad configuration of the system.

A bit of a problematic area that we identified in Authentik is its deployment. It only offers Docker-Compose or Kubernetes based installation. No official bare-metal installation support exists. The minimum setup requires four containers that are connected via an isolated network. One container is running the Postgres database, one is running the Redis in-memory key/value store, another one is running the actual Authentik server components and an “Authentik Worker” container is running the celeryd task scheduler. We looked into the containers and noted the following aspects:

• Two of the containers (Postgres and Redis) are based on Alpine Linux and the other two (Authentik Server and Worker) are based on Debian Linux.
• The local security within some of these containers is not fully maintained, e.g. in the Authentik Server container there exist globally accessible IPC sockets and unsafe temporary file permissions in /dev/shm. This means that the local security is only based on the container isolation. As soon as an attacker is able to run code in this container, there is little defense-in-depth.
• The file system hierarchy standard is violated in some of the containers, the / directory is cluttered with proprietary Authentik directories. A custom Python installation is placed there, for example.

Consequently, one must not only consider the security of Authentik itself, but also the security of at least four different Linux containers running two different Linux distributions and the customized Python stacks involved etc. Users have to rely on Authentik upstream to properly maintain the security of these components.

Offering a bare-metal installation could address the concerns in this area. Individual services on modern Linux can still benefit from isolation features (e.g. via protection settings in systemd service units), while the system packages and distribution security are transparent and under full control of the Admin. Of course this likely makes things more complex for the upstream developers, when they no longer have full control of the Linux environment that Authentik is running in.

4) Timeline

5) References

• Authentik GitHub project
• Advisory about insufficient authorization of API endpoints
• Advisory about the remote timing attack

Dear Tumbleweed users and hackers,

As there was hackweek this week, attention on the Stagings might have been a bit distracted, although it does not look like anything was stuck longer than usual. We have released 5 snapshots during this week (1114, 1115, 1117, 1118, and 1119).

The most relevant changes this week are:

• Linux kernel 6.11.8
• gnutls 3.8.8
• PostgreSQL 17.1
• Mozilla Firefox 132.0.2
• Plymouth 22.02.122+180 ( more recent git snapshot)
• Python 3.13 modules enabled; Python 3.11 is – for now – still the default (plans to change that are emerging)

Staging projects are still crowded, testing these parts:

• ICU 76.1 (part of snapshot 1121)
• Linux kernel 6.12.0
• Debugedit 5.1
• cmake 3.31.0
• Python setuptools 75.6
• systemd 257
• Mesa 24.3.0

It's the time for a new Hack Week. The Hack Week 24 was from November 18th to November 22th, and I've decided to join the New openSUSE-welcome project this time.

The idea of this project is to revisit the existing openSUSE welcome app, and I've been trying to help here, specifically for the GNOME desktop installation.

openSUSE-welcome

Right now after installing any openSUSE distribution with a graphical desktop, the user is welcomed on first login with a custom welcome app.

This custom application is a Qt/QML with some basic information and useful links.

The same generic application is used for all desktops, and for popular desktops right now exists upstream applications for this purpose, so we were talking on Monday morning about it and decided to use specific apps for desktops.

So for GNOME, we can use the GNOME Tour application.

gnome-tour

GNOME Tour is a simple rust/gtk4 application with some fancy images in a slideshow.

This application is generic and just shows information about GNOME desktop, so I created a fork for openSUSE to do some openSUSE specific customization and use this application as openSUSE welcome in GNOME desktop for Tumbleweed and Leap.

Desktop patterns, the welcome workflow

After some testing and investigation about the current workflow for the welcome app:

1. x11_enhanced pattern recommends opensuse-welcome app.
2. We can add a Recommends: gnome-tour to the gnome pattern
3. The application run using xdg autostart, so gnome-tour package should put the file in /etc/xdg/autostart and set to hidden on close.
4. In the case of having a system with multiple desktops, we can choose the specific welcome app using the OnlyShowIn/NotShowIn config in desktop file

So I've created a draft PR to do not show the openSUSE-welcome app in GNOME, and I've also the gnome-tour fork in my home OBS project.

I've been testing this configuration in Tumbleweed with GNOME, KDE and XFCE installed and it works as expected. The openSUSE-welcome is shown in KDE and XFCE and the gnome-tour app is only shown in GNOME.

Next steps

The next steps to have the GNOME Tour app as default welcome for openSUSE GNOME installation are:

1. Send forked gnome-tour package to GNOME:Next project in OBS.
2. Add the Recommends: gnome-tour to patterns-gnome to GNOME:Next project in OBS.
3. Make sure that any other welcome application is not shown in GNOME.
4. Review openQA tests that expect opensuse-welcome and adapt for the new application.

The State at the Beginning

Earlier I had made progress on my server to serve different websites from inside containers, including refreshing SSL certificates. But the server started to be aging, and for both learning and future proofing purposes I started looking at migrating to something newer. And, I never really finished all the old work anyway. Instead I have a new container in use that has SSH running inside, that should be migrated as well.

OS / Software Upgrades

First of all I updated the OS, to have the latest or at least newer Podman available, as I tend to prefer the distro version to any special repositories. I encountered a few problems with disk space running out a few times, but managed to sort out those issues without rendering the server unusable.

From Docker to Podman

The main topic was switching from Docker to Podman. That involved reading about docker-compose vs podman-compose, the different formats for those two, quadlets, pods… so many options, and interestingly many of those have been in varying states of development for the past years, so I’m glad I haven’t been too fast on making this switch.

I have liked docker compose. Creating pods from CLI is certainly not interesting for me so not worth the effort. Quadlets would be elegant, but I yearn for something more automatically created from a single definition for quadlets like the podlets, which however are not to be merged into podman upstream. Lots of interesting discussion on which ones of these are deprecated, no longer hot etc.

I checked that indeed it seemed I can use podman as a drop-in replacement for Docker, using the docker-compose format. However, the idea to move to native podman-compose format was hindered by comments like ”compose is no longer the way to go with Podman” 🤔

Reality Check

At this point I decided to actually test this ”drop-in replacement” I mentioned seemed working, and while the container was indeed running without a hitch, I found out that .. well, the services didn’t work. So before I got too excited about rewriting everything in something new, I went towards actually figuring out what are the problems currently.

That took quite a bit of time, but eventually I was back to the status before starting. I spent a bit too much time assuming the problem was with podman configuration, while at the end I needed correct firewall routings to the podman network interface, something that wasn’t explicitly required before with docker and earlier OS version.

Problem solved! Except that now SSH to container worked, but some SSH features did not work… again, some time was spent until I found out that Podman has dropped AUDIT_WRITE capability from default settings at some point, mostly needed by SSH. Problem Solved! Except that even though there was a change in error messages, it still didn’t work. AUDIT_CONTROL or a workaround is needed too, for obvious-to-anyone reasons (a nice read, plot thickens etc).

At this point I thought that rewriting anything more would just complicate things, and it’d be better to make the current solution to ”actually work”. So far I had played with the single container that was already in use, but I knew there’d be a bigger effort to combine that with the containerized nginx proxy and let’s encrypt that were not yet running in a container by default, running on host instead, and having all of those work together.

At the End

For my use on this single server case, I found that actually podman-compose with the compatible docker format is not too bad thing to use. I have a more recent platform in use, Podman even in rootful mode is somewhat more secure than Docker, and I have solved issues in integrating this migrated container and some of the other services working in another migrated container too. Most importantly, at the end I had not created more problems than I solved, I have version controlled configuration, improved Ansible scripts and functional backups for re-deployment. Given the time restrictions I have for working on things like these, it’s better to have something that a) works, b) is re-deployable than something that is using another technology but is more hackish.

While I could move from podman-compose to quadlets, that would actually make things more complex at least in the current state of things in case I’d like to move to kubernetes. compose -> quadlets and compose -> kubernetes seem quite straightforward, but quadlets -> kubernetes is a bit different topic. Not that I’d really have any use for kubernetes, but for learning purposes it could be nice to keep the option. Maybe using .kube files with quadlets could be ok though.

A separate project would be also to switch to native Podman compose YAML format to strive towards rootless containers.

It's the time for a new Hack Week. The Hack Week 24 was from November 18th to November 22th, and I've decided to join the New openSUSE-welcome project this time.

The idea of this project is to revisit the existing openSUSE welcome app, and I've been trying to help here, specifically for the GNOME desktop installation.

openSUSE-welcome

Right now after installing any openSUSE distribution with a graphical desktop, the user is welcomed on first login with a custom welcome app.

This custom application is a Qt/QML with some basic information and useful links.

The same generic application is used for all desktops, and for popular desktops right now exists upstream applications for this purpose, so we were talking on Monday morning about it and decided to use specific apps for desktops.

So for GNOME, we can use the GNOME Tour application.

gnome-tour

GNOME Tour is a simple rust/gtk4 application with some fancy images in a slideshow.

This application is generic and just shows information about GNOME desktop, so I created a fork for openSUSE to do some openSUSE specific customization and use this application as openSUSE welcome in GNOME desktop for Tumbleweed and Leap.

Desktop patterns, the welcome workflow

After some testing and investigation about the current workflow for the welcome app:

1. x11_enhanced pattern recommends opensuse-welcome app.
2. We can add a Recommends: gnome-tour to the gnome pattern
3. The application run using xdg autostart, so gnome-tour package should put the file in /etc/xdg/autostart and set to hidden on close.
4. In the case of having a system with multiple desktops, we can choose the specific welcome app using the OnlyShowIn/NotShowIn config in desktop file

So I've created a draft PR to do not show the openSUSE-welcome app in GNOME, and I've also the gnome-tour fork in my home OBS project.

I've been testing this configuration in Tumbleweed with GNOME, KDE and XFCE installed and it works as expected. The openSUSE-welcome is shown in KDE and XFCE and the gnome-tour app is only shown in GNOME.

Next steps

The next steps to have the GNOME Tour app as default welcome for openSUSE GNOME installation are:

1. Send forked gnome-tour package to GNOME:Next project in OBS.
2. Add the Recommends: gnome-tour to patterns-gnome to GNOME:Next project in OBS.
3. Make sure that any other welcome application is not shown in GNOME.
4. Review openQA tests that expect opensuse-welcome and adapt for the new application.

The official syslog-ng container image is based on Debian Stable. However, we’ve been getting requests for an RPM-based image for many years. So, I made an initial version available based on Alma Linux and now I need your feedback about it! This image uses the “init” variant of Alma Linux 9 containers as a base image. What does this mean? Well, it uses systemd service management inside, making it possible to run multiple services from a single container. While only syslog-ng is included right now, I also plan to add the syslog-ng Prometheus exporter to the image. Note that while the example command lines show Docker, I also tested it using Podman.

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