The openSUSE Project continues its Contribution Workshop series today with a new episode at 19:15 UTC on the project’s YouTube & X channels.

The new episode will take viewers on an insightful journey into the world of testing and breaking builds. The session focuses on the automation of repetitive tasks and will demonstrate how to leverage tools and techniques to automate build testing.

Episode 8: Testing and Breaking Builds - Offloading Repetitive Tasks to Computers, While You Have Fun Exploring

• Date: May 23
• Time: 19:15 UTC
• Where: openSUSE official YouTube & X channels

In the upcoming Episode 8, openQA engineer Santiago Zarate will do a live talk and explain how open-source contributors can maintain high standards of testing quality while reducing the manual workload.

These workshops offer a platform for learning and for contributors to ask questions and engage directly with developers, maintainers and experienced members of the openSUSE community.

The espisdoes for the Contribution Workshop go over a variety of topics including package maintenance, infrastructure, or understanding the overall project landscape. These following episodes are tailored to provide an overview and practical advice for open-source software developments and contributions.

The following episodes were already released:

• Episode 1: openSUSE Contribution Workshop: Basic use of OBS osc using a version bump as an example
• Episode 2: openSUSE Contribution Workshop: From 0 to an rpm package packaging GNU Hello
• Episode 3: openSUSE Contribution Workshop: openSUSE Leap 15.6 Beta Bug Day
• Episode 4: openSUSE Contribution Workshop: Packaging Rust in Open Build Service
• Episode 5: Contributing to openSUSE Leap - Project Structure, Feature Tracking, Package Updates for SLES Packages
• Episode 6: Host Your Own openSUSE Mirror
• Episode 7: openSUSE Contribution Workshop: Custom Leap Micro image spin in a few minutes

_{^{(Image made with DALL-E)}}

openSUSE.Asia Summit 2024 Logo Competition

We are pleased to announce the launch of our logo contest for the openSUSE.Asia Summit 2024! The logo plays a crucial role in representing the spirit and identity of the event. Each year, the distinct logos from previous Summits have beautifully reflected the diverse communities that host them. We invite you to participate in this year’s contest and design a remarkable logo for the 2024 summit.

The openSUSE.Asia Summit 2024 will be held in Tokyo, Japan, with more details coming soon. The competition is currently open and will close on July 21, 2024. To thank the winner, the organizers will present a special “Geeko Mystery Box” to the creator of the best logo.

Deadline: 21 July 2024

Announcement Winner: 29 July 2024

The Rules of the contest are as follows:

1. Licensing: The logo should be licensed under CC-BY-SA 4.0 and must allow everyone to use it without attribution if it is chosen as the logo for openSUSE.Asia Summit 2024. Note that attribution will be shown on the summit website.
2. Originality: The design must be original and should not include any third-party materials.
3. Formats: Both monochrome and color formats are essential for submission.
4. File Format: Submissions must be in SVG format.
5. Community Reflection: The design should reflect the openSUSE community in Asia.
6. Avoid: The logo should not include:
   • Brand names or trademarks of any kind.
   • Illustrations that may be considered inappropriate, offensive, hateful, tortuous, defamatory, slanderous, or libelous.
   • Sexually explicit or provocative images.
   • Violence or weapons imagery.
   • Alcohol, tobacco, or drug use imagery.
   • Discrimination based on race, gender, religion, nationality, disability, sexual orientation, or age.
   • Bigotry, racism, hatred, or harm against groups or individuals.
   • Religious, political, or nationalist imagery.
7. Guidelines: The logo should adhere to the openSUSE Project Trademark Guidelines.
8. Branding: The openSUSE branding guidelines will be helpful in designing your logo (optional).

Please submit your design to opensuseasia-summit@googlegroups.com with the following details:

1. Subject Line: openSUSE.Asia Summit 2024 Logo Design - [Your Name]
2. Contact Information: Your name and email address.
3. Design Philosophy: A document (in TXT or PDF format) explaining the philosophy behind your design.
4. Vector File: The design in SVG format ONLY.
5. Bitmap File: A bitmap image of the design as an attachment, with a minimum size of 256x256 pixels in PNG format.
6. File Size: Ensure the file size is less than 512 KB.

The openSUSE.Asia Summit Committee will review all submissions to ensure they meet the requirements. The final decision will be made by the committee and may not necessarily be the highest-scoring design. We recommend using Inkscape, a powerful, free, and open-source vector graphics tool, for your design work.

Prometheus is an open-source monitoring system that collects metrics from your hosts and applications, allowing you to visualize and alert on them. The syslog-ng Prometheus exporter allows you to export syslog-ng statistics, so that Prometheus can collect it.

While an implementation in Go has been available for years on GitHub (for more information, see this blog entry), that solution uses the old syslog-ng statistics interface. And while that Go-based implementation still works, syslog-ng 4.1 introduced a new interface that provides not just more information than the previous statistics interface, but does so in a Prometheus-friendly format. The information available through the new interface has been growing ever since.

The syslog-ng Prometheus exporter is implemented in Python. It also uses the new statistics interface, making new fields automatically available when added.

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

The schedule for openSUSE Conference 2024 is out and it is filled with several talks about open-source ecosystem and includes several breaks for networking opportunities.

Open-source enthusiasts, developers and contributors will meet at the Z-Bau from June 27 to June 29 to share, discuss and showcase the latest advancements in open-source technologies, projects and communities. The conference will feature a series of talks, workshops, meetups and keynote speakers providing valuable insights into current and future directions of open-source software.

Santiago Zarate, Oliver Kurz, and Livdywan are scheduled to kick off with a session on openQA - Current State and Moving Forward. The talk will highlight the evolution of openQA as a crucial tool for ensuring the stability of openSUSE’s systems and expanding its impact beyond openSUSE, Fedora and SUSE.

Marcus Meissner and Johannes Segitz will present The XZ Backdoor - Report from Our Side and provide a retrospective on a significant supply chain attack involving the xz compression library. They will discuss the attack’s impact, response measures and future security considerations.

Two keynotes will take place on the first day. SUSE’s CEO Dirk-Peter van Leeuwen will speak about the importance of community and fostering collaborative open-source environments.

Luca Di Maio will provide a keynote session on Developing on Aeon with Distrobox. The presentation will introduce Distrobox and demonstrate how it can be used as a development environment within Atomic and Transactional systems like Aeon.

The second day is scheduled to begin with Alfonso Hernandez’s Midori is Much More Than a Web Browser talk. Hernandez will explore the features and benefits of Midori, a lightweight, fast and secure browser, and its role in promoting user privacy and security.

Jsrain will provide a SUSE ALP: State of the Matters talk. The session will cover recent developments, upcoming releases and how the openSUSE project can build on SUSE’s ALP development.

Rick Spencer, General Manager at SUSE, will deliver another keynote. His talk Why openSUSE Matters will share his insights on the significance of openSUSE in the broader open-source ecosystem.

The final day will feature Dan Čermák’s The Tragedy of Community Enterprise Linux Distributions. Čermák will discuss the challenges faced by community variants of enterprise Linux distributions and propose potential solutions.

Markus Feilner will present Exchange Your Exchange: grommunio - An Open Source Drop-In and So Much More and highlight grommunio as a comprehensive open-source replacement for Microsoft Exchange, which offers groupware, video conferencing, chat, file sync and more.

A Fedora Hatch Meetup, led by Čermák, will provide an informal space for Fedora contributors and enthusiasts to discuss their experiences and network.

Tobias Görgens’ sdbootutil: Mastering the Art of Boot Management talk will introduce a tool designed to simplify bootloader management on openSUSE to make the process more intuitive and robust.

The openSUSE Conference 2024 is expected to be a great informative event for sharing, collaborating, learning and innovating.

For more information and to register, visit events.opensuse.org.

Table of Contents

• Introduction
• Review Motivation and Scope
• A) Unauthenticated Handover D-Bus Interface (CVE-2024-5148)
  • Local Private Key Leak
  • System Credentials Leak
  • The Socket Connection can be Obtained via TakeClient()
  • Bugfix and Affectedness
• B) find_cr_lf() Suffers from a one Byte Overread
  • Bugfix
• C) grdctl Utility Accepts Cleartext Password on the Command Line
  • Bugfix
• Timeline
• References

Introduction

gnome-remote-desktop offers access to the graphics system either via the VNC or the RDP (Microsoft remote desktop) network protocol. Before version 46, gnome-remote-desktop was only used in the context of existing graphical user sessions. Starting with version 46, one can also configure a system daemon, that allows to connect to the GNOME display manager (GDM), allowing to create graphical sessions remotely.

The system daemon runs as a dedicated “gnome-remote-desktop” user. It provides a D-Bus interface on the D-Bus system bus. The daemon also interacts with a newly introduced D-Bus interface provided by GDM, to create remote displays.

While reviewing the new system service I found a number of local security issues and areas for security improvement. The more relevant issues are discussed in this report, while an upstream Gitlab issue contains a more detailed report and discussions also covering less severe aspects found during the review.

This report relates to gnome-remote-desktop release 46.0. Bugfixes for the issues described are found in release 46.2, except for item C) for which no fix is available yet.

Review Motivation and Scope

D-Bus system services require a review by the SUSE security team, before they can be added to openSUSE distributions and derived products. With the addition of the system daemon, a review of gnome-remote-desktop became necessary, before adding it to openSUSE Tumbleweed in the context of the larger GNOME 46 release.

The review was mainly concerned with the newly introduced system level gnome-remote-desktop daemon. The focus was furthermore on code paths related to the RDP protocol, which is the default and preferred over the VNC protocol.

Since the codebase of gnome-remote-desktop is rather large, I focused the review on the security of the D-Bus methods, the Polkit authentication and parts of the network processing. I also did not look closely into the FreeRDP library, which is used by gnome-remote-desktop for processing the majority of the RDP protocol.

A) Unauthenticated Handover D-Bus Interface (CVE-2024-5148)

Only the “org.gnome.RemoteDesktop.Rdp.Server” D-Bus interface is protected by Polkit. auth_admin authorization is required on this interface for all methods. The other two interfaces “Dispatcher” and “Handover” are not authorized and are accessible to all local users in the system. This leads to a number of local security issues described in the following subsections.

Local Private Key Leak

The system daemon keeps public SSL certificates and their corresponding private keys in “/var/lib/gnome-remote-desktop/.local/share/gnome-remote-desktop/certificates”. Access to the service’s home directory in “/var/lib/gnome-remote-desktop” is restricted to the service user “gnome-remote-desktop”, mode 0700.

Through the “org.gnome.RemoteDesktop.Rdp.Handover” D-Bus interface any local user can intercept the private SSL key, though. The private key is returned from the StartHandover D-Bus function. When a remote desktop client connects to the system daemon, then there is a rather long time window, during which any local user (even nobody) can call this method on the created session object. This is an example call to achieve this:

gdbus call -y -d org.gnome.RemoteDesktop -o /org/gnome/RemoteDesktop/Rdp/Handovers/sessionc11 \
    -m org.gnome.RemoteDesktop.Rdp.Handover.StartHandover someuser somepass

The username and password parameters are not important here, they will only be forwarded to the connecting client. Doing this, as another effect, also results in a denial-of-service, because the proper connection handover will be prevented.

A local attacker does not necessarily have to wait for somebody to connect to the system daemon, it can connect on its own via localhost, to achieve the same result. Valid credentials for RDP authentication are necessary to get to the handover stage, however.

The impact of this problem is a local information leak and local DoS. The information leak means that the integrity and privacy of RDP connections on the system are compromised. This simple Python script allows to reproduce the issue.

System Credentials Leak

If an RDP connection uses shared system credentials (see struct member GrdRemoteClient.use_system_credentials), then a local attacker with low privileges can obtain these credentials in cleartext in a similar fashion to the private key leak, by calling the unauthenticated GetSystemCredentials() D-Bus method of the Handover interface.

Using these system credentials, the attacker will be able to connect to the display manager via RDP. This should not directly grant access to a session, since a login on display manager level still has to happen. An exception would be if things like automatic login are enabled (I don’t know whether they apply to remote connections).

The Socket Connection can be Obtained via TakeClient()

The equally unauthenticated D-Bus method Handover.TakeClient() allows any local user in the system to obtain the file descriptor pertaining to the RDP client that is in handover state. This could allow a local user to perform a denial-of-service of the RDP connection or to setup a crafted RDP session.

Obtaining the socket via this call only works in certain system daemon states, most notably it seems the StartHandover() needs to have been performed for this to succeed. I did not fully investigate what the exact preconditions are.

Bugfix and Affectedness

This CVE only affects gnome-remote-desktop releases 46.0 and 46.1, since the system daemon was only introduced in these versions. The bugfix is available starting from version 46.2 and is found in commit 9fbaae1a.

With the bugfix applied, only the user for whom a new session has been created will be able to call the handover interface anymore. This still means that all users with RDP access share the same private key, which, according to upstream, is by protocol design.

B) find_cr_lf() Suffers from a one Byte Overread

This function processes untrusted pre-authentication RDP protocol network data (the routing token) and looks for a terminating \r\n sequence. The size calculation in the function’s for loop is wrong: if the final byte of the buffer is 0x0D, then the logic will access the next byte out of bounds. This buffer is not null terminated.

The impact should be negligible in most cases. This is the output of Valgrind I obtained after sending a crafted packet to the daemon:

==31119== Invalid read of size 1
==31119==    at 0x15A1EF: UnknownInlinedFun (grd-rdp-routing-token.c:65)
==31119==    by 0x15A1EF: UnknownInlinedFun (grd-rdp-routing-token.c:159)
==31119==    by 0x15A1EF: UnknownInlinedFun (grd-rdp-routing-token.c:239)
==31119==    by 0x15A1EF: peek_routing_token_in_thread (grd-rdp-routing-token.c:281)
<snip>

Bugfix

The bugfix is found starting in release 46.2 in commit 663ad63172.

C) grdctl Utility Accepts Cleartext Password on the Command Line

The text-based grdctl configuration utility, which is used for both, system and session context RDP setups, accepts cleartext passwords in the following invocation styles:

grdctl [--system] rdp set-credentials <username> <password>
grdctl [--system] vnc set-password <username> <password>

This means that the cleartext password will leak via the /proc file system and will be visible in the process task list via ps, when configured this way. Other users can thus get access to the authentication data.

Bugfix

Upstream declined assignment of a CVE for this issue. They consider the shared credentials to be of rather low sensitivity and state that other ways exist for users to set the credentials, that don’t leak information to other users (GNOME Control Center, the D-Bus API, writing the credentials file directly). A feature request to allow reading the password via stdin has been added to an existing Gitlab issue.

Timeline

References

• GNOME remote desktop project
• GNOME remote desktop Gitlab issue corresponding to this report

Python 3.13 beta 1 is out, and I've been working on the openSUSE Tumbleweed package to get it ready for the release.

Installing python 3.13 beta 1 in Tumbleweed

If you are adventurous enough to want to test the python 3.13 and you are using openSUSE Tumbleweed, you can give it a try and install the current devel package:

# zypper addrepo -p 1000 https://download.opensuse.org/repositories/devel:languages:python:Factory/openSUSE_Tumbleweed/devel:languages:python:Factory.repo
# zypper refresh
# zypper install python313

What's new in Python 3.13

Python interpreter is pretty stable nowadays and it doesn't change too much to keep code compatible between versions, so if you are writing modern Python, your code should continue working whit this new version. But it's actively developed and new versions have cool new functionalities.

1. New and improved interactive interpreter, colorized prompts, multiline editing with history preservation, interactive help with F1, history browsing with F2, paste mode with F3.
2. A set of performance improvements.
3. Removal of many deprecated modules: aifc, audioop, chunk, cgi, cgitb, crypt, imghdr, mailcap, msilib, nis, nntplib, ossaudiodev, pipes, sndhdr, spwd, sunau, telnetlib, uu, xdrlib, lib2to3.

Enabling Experimental JIT Compiler

The python 3.13 version will arrive with an experimental functionality to improve performance. We're building with the --enable-experimental-jit=yes-off so it's disabled by default but it can be enabled with a virtualenv before launching:

$ PYTHON_JIT=1 python3.13

Free-threaded CPython

The python 3.13 has another build option to disable the Global Interpreter Lock (--disable-gil), but we're not enabling it because in this case it's not possible to keep the same behavior. Building with disabled-gil will break compatibility.

In any case, maybe it's interesting to be able to provide another version of the interpreter with the GIL disabled, for specific cases where the performance is something critical, but that's something to evaluate.

We can think about having a python313-nogil package, but it's not something trivial to be able to have python313 and python313-nogil at the same time in the same system installation, so I'm not planning to work on that for now.

Dear Tumbleweed users and hackers,

Last week, there was a public holiday on Thursday in some parts of the world (Ascension Day). Unsurprisingly, many devs, including myself and Ana, took Friday off to enjoy a longer weekend (and I can tell you: the weather was fantastic). As a result, I have to span two weeks of changes to Tumbleweed here once again. We have published 12 snapshots since my last review (0502…0515, snapshots 0504 and 0513 were not built due to weekends)

The most relevant changes delivered as part of those snapshots were:

• Mozilla Firefox 125.0.3
• LibreOffice 24.2.3.2
• GNOME 46.1
• GIMP 2.10.38
• LLVM 18.1.5
• GCC 14.1
• KDE Frameworks 6.2.0
• PHP 8.3.7
• PostgreSQL 16.3
• Systemd 255.5 & 255.6
• Linux kernel 6.8.9 (with linux-glibc-devel already prepared at 6.9)
• Ruby 3.3.1
• QEmu 8.2.3
• util-linux 2.40.1

Snapshot 0515 contained an openssh update, that mistakenly recommended installation of the subpackage openssh-server-config-rootlogin; this package has existed since the default configuration of openSSH was changed to not permit root login anymore, so admins could easily switch it back on. Due to an error, this had been triggered for automatic installation. This has since been corrected and a version of openssh-server was published to the update channel, which is NOT recommended. Please check your installation and remove the package again, should it be installed and you don’t need it (we can’t auto-remove it without breaking users that explicitly wanted it)

The following things are known to be worked on at the moment and are reaching you in some upcoming snapshot:

• chkstat package being renamed to permctl
• Rust 1.78
• Mesa 24.0.7
• Linux kernel 6.9.1
• Ninja 1.12
• dbus-broker: some networking issue after upgrades left to work out
• GCC 14: phase 2: use gcc14 as the default compiler – lots of help needed: https://build.opensuse.org/project/show/openSUSE:Factory:Staging:Gcc7

The YaST Team is back with more news about Agama. On our previous post we exposed the first two steps of our roadmap for 2024: a more powerful user interface for the storage setup and a new Cockpit-free architecture with a better API for external callers. Now we are proud to announce Agama 8, delivering initial versions of both features.

The great architectural change​

As explained at the mentioned blog post and detailed at this Github discussion, we got powerful reasons to rethink Agama's architecture, getting rid of Cockpit and switching from D-Bus to HTTP as main communication protocol between the different Agama components.

The changes are useful to integrate Agama into bigger solutions and are obviously beneficial for remote or unattended installations. But turns out they also improved dramatically Agama's start-up time and general speed. Some parts, like the ones related to storage setup, still rely internally on components of the previous architecture and have not benefited yet from the speedup. But you can expect improvements in the mid term.

You may miss some features compared to previous releases of Agama, like the integrated terminal or the management of DASD and zFCP devices. We sacrified those features in favor of the "release early, release often" motto. But all the important features will be reintroduced on the following months.

A more powerful user interface to setup storage​

The removal of the mentioned features may not be the most exciting news about Agama's user-facing functionality, but we have something to offer in exchange. A new interface to configure the storage setup that, although is still a bit rough around the edges, makes it possible to squeeze all the juice from the traditional YaST storage proposal (also known as the YaST Guided Setup).

The new interface aims to be understandable to newcomers. But, since we know (open)SUSE users have big expectations in terms of customizing their setups, it offers many possibilities in order to specify where to place every new partition or LVM logical volume, including the possibility to mount previous file systems or format existing devices. The new interface also makes it possible to configure several aspects regarding booting and encryption and to select which partitions should be resized or deleted.

Other changes​

But the storage screen is not the only part of Agama that got some love for this release. The YaST team worked on some areas like:

• A new interface for selecting the software patterns, more aligned with the rest of Agama.
• Better guidance for configuring TPM-based full disk encryption.
• A mostly rewritten network stack.
• Visual and usability fixes on several widgets.

Even more important, we also got several improvements contributed by volunteer developers out of the regular YaST Team at SUSE. On the one hand, Nagender Rao improved the form to edit a file system. On the other hand, Balsa Asanovic continues growing his already impressive contribution to Agama with better visualization of the installation issues and enhancements in the interface to create a user.

See it in action​

We couldn't be more grateful to Balsa, Nagender and all other supporters out there, like the translators that make it possible to use Agama in more than 10 languages. Of course, coding or translating is not the only way to contribute to the project. You can also test Agama 8 and give us feedback. Moreover, that is the best way to get a glimpse of all the possibilities regarding the new interface to configure the storage setup and all the other changes mentioned above.

The easiest way to get your hands on Agama 8 is to download one of the Agama Live ISO testing images and boot it on a virtual or bare-metal machine. Bear in mind this is one of the most experimental pre-releases of Agama ever, since we wanted it to be tested at as many scenarios as possible after the big architectural change. Do not hesitate to report any misbehavior that is still not tracked.

See you soon​

We are already working on Agama 9, that should be released in one month from now. The focus will be on improving the support for unattended installations and the compatibility with AutoYaST. We also expect to acomplish a rather significative reorganization of the web interface and to bring back some of the features that were left behind in the switch to the new architehocture.

If everything goes as expected, that's the version you will see in action at the two sessions the YaST Team will hold at openSUSE Conference 2024. If you will not be there or simply don't want to wait, you can always reach us at the YaST Development mailing list, our #yast channel at Libera.chat or the Agama project at GitHub.

Have a lot of fun!

The YaST Team is back with more news about Agama. On our previous post we exposed the first two steps of our roadmap for 2024: a more powerful user interface for the storage setup and a new Cockpit-free architecture with a better API for external callers. Now we are proud to announce Agama 8, delivering initial versions of both features.

The Great Architectural Change

As explained at the mentioned blog post and detailed at this Github discussion, we got powerful reasons to rethink Agama’s architecture, getting rid of Cockpit and switching from D-Bus to HTTP as main communication protocol between the different Agama components.

The changes are useful to integrate Agama into bigger solutions and are obviously beneficial for remote or unattended installations. But turns out they also improved dramatically Agama’s start-up time and general speed. Some parts, like the ones related to storage setup, still rely internally on components of the previous architecture and have not benefited yet from the speedup. But you can expect improvements in the mid term.

You may miss some features compared to previous releases of Agama, like the integrated terminal or the management of DASD and zFCP devices. We sacrified those features in favor of the “release early, release often” motto. But all the important features will be reintroduced on the following months.

A More Powerful User Interface to Setup Storage

The removal of the mentioned features may not be the most exciting news about Agama’s user-facing functionality, but we have something to offer in exchange. A new interface to configure the storage setup that, although is still a bit rough around the edges, makes it possible to squeeze all the juice from the traditional YaST storage proposal (also known as the YaST Guided Setup).

The new interface aims to be understandable to newcomers. But, since we know (open)SUSE users have big expectations in terms of customizing their setups, it offers many possibilities in order to specify where to place every new partition or LVM logical volume, including the possibility to mount previous file systems or format existing devices. The new interface also makes it possible to configure several aspects regarding booting and encryption and to select which partitions should be resized or deleted.

Other Changes

But the storage screen is not the only part of Agama that got some love for this release. The YaST team worked on some areas like:

• A new interface for selecting the software patterns, more aligned with the rest of Agama.
• Better guidance for configuring TPM-based full disk encryption.
• A mostly rewritten network stack.
• Visual and usability fixes on several widgets.

Even more important, we also got several improvements contributed by volunteer developers out of the regular YaST Team at SUSE. On the one hand, Nagender Rao improved the form to edit a file system. On the other hand, Balsa Asanovic continues growing his already impressive contribution to Agama with better visualization of the installation issues and enhancements in the interface to create a user.

See it in Action

We couldn’t be more grateful to Balsa, Nagender and all other supporters out there, like the translators that make it possible to use Agama in more than 10 languages. Of course, coding or translating is not the only way to contribute to the project. You can also test Agama 8 and give us feedback. Moreover, that is the best way to get a glimpse of all the possibilities regarding the new interface to configure the storage setup and all the other changes mentioned above.

The easiest way to get your hands on Agama 8 is to download one of the Agama Live ISO testing images and boot it on a virtual or bare-metal machine. Bear in mind this is one of the most experimental pre-releases of Agama ever, since we wanted it to be tested at as many scenarios as possible after the big architectural change. Do not hesitate to report any misbehavior that is still not tracked.

See You Soon

We are already working on Agama 9, that should be released in one month from now. The focus will be on improving the support for unattended installations and the compatibility with AutoYaST. We also expect to acomplish a rather significative reorganization of the web interface and to bring back some of the features that were left behind in the switch to the new architehocture.

If everything goes as expected, that’s the version you will see in action at the two sessions the YaST Team will hold at openSUSE Conference 2024. If you will not be there or simply don’t want to wait, you can always reach us at the YaST Development mailing list, our #yast channel at Libera.chat or the Agama project at GitHub.

Have a lot of fun!

Last year, I received many requests about syslog-ng for Amazon Linux 2023, but I could not find an easy way to create syslog-ng packages. Recently, however, I found that Fedora Copr supports building packages for Amazon Linux 2023. So, with a little bit of experimentation, I got a cut down version of syslog-ng compiled.

Read more at https://www.syslog-ng.com/community/b/blog/posts/experimental-syslog-ng-packages-for-amazon-linux-2023