Tue, Mar 5th, 2024
Installation guide for warewulf4
Warewulf
Preface
In High Performance Computing (HPC) computing tasks are usually distributed among many compute threads which are spread across multiples cores, sockets and machines. These threads are thightly coupled together. For this compute clusters consist of a number of largely identical machines that need to be managed to maintain a well defined and identical setup across all nodes. Once clusters scale up there are many scalability factors to overcome. Warewulf is there to address this ‘administrative scaling’.
Warewulf is an operating system agnostic installation and management system
for HPC clusters.
It is quick and easy to learn aud use as many settings are pre-configured
to sensible defaults. It still provides the flexibility allowing to finely
tune the configuration to local needs.
It is released under the BSD license. Its source code is available at
https://github.com/warewulf/warewulf. This is where the development happens
as well.
Installing warewulf4
Compute clusters consist of at least one management or head node which is usually multi-homed connecting both to an external network and to a cluster private network as well as multiple compute nodes which reside solely on the private network. Other private networks dedicated to high speed task like RDMA and storage access may exist as well. Warewulf gets installed to one of the management nodes to manage and oversee the installation and management of the compute nodes. To install Warewulf on a cluster is running SUSE Linux Enterprise HPC 15 SP5, openSUSE Leap 15.5 or openSUSE Tumbleweed, simpy run:
zypper install warewul4
on this management node to install the SUSE-provided Warewulf package. This package seamlessly integrates into a SUSE system and should therefore be preferred over packages provided on Github.
During the installation the actual network configuration is written to the
/etc/warewulf/warewulf.conf
. These settings should be verified, as for
multi homed hosts a sensible pre-configuration is not always possible.
Check /etc/warewulf/warewulf.conf
for the following values:
ipaddr: 172.16.16.250
netmask: 255.255.255.0
network: 172.16.16.0
where ipaddr
should be the ip address of this host management host.
Also check the values of netmask
and network
- these should match
this network.
Additionally, you should configure the ip addresse range for dynamic/unknown hosts:
dhcp:
range start: 172.16.26.21
range end: 172.16.26.50
If the ISC dhcpd server is used (default on SUSE) make sure the value of
DHCPD_INTERFACE
in the file /etc/sysconfig/dhcpd
has been set to the
right value.
You are now ready to start the warewulfd
service itself which delivers the
images to the nodes:
systemctl enable --now warewulfd.service
Now wwctl
can be used to configure the the remaining services needed by
warewulf. Run
wwctl configure --all
which will configure all warewulf related services.
Adding nodes and profiles to warewulf
Warewulf uses the concept of profiles which hold the generalized settings
of the individual nodes. It comes with a predefined profile default
, to
which all new node will be assigned, if not set otherwise. You may obtain
the values of the default profile with:
wwctl profile list default
Now, a node can be added with the command assigning it an IP address:
wwctl node add node01 -I 172.16.16.101
the mac address is known for this node, you can specify this as well:
wwctl node add node01 -I 172.16.16.101 -H cc:aa:ff:ff:ee
For adding several nodes at once you may also use a node range which results e.g.
wwctl node add node[01-10] -I 172.16.16.101
this will add the nodes with ip addresses starting at the specified address and incremented by warewulf.
Importing a container
Warewulf uses a special 1 container as the base system to build OS images for the compute nodes. This is self contained and independent of the operating system installed on the warewulf host.
To import an openSUSE Leap 15.5 container use the command
wwctl container import docker://registry.opensuse.org/science/warewulf/leap-15.5/containers/kernel:latest leap15.5 --setdefault
This will import the specified container for the default profile.
Alternative container sources
Alternative containers are available from the openSUSE registry under the science project at
https://registry.opensuse.org/cgi-bin/cooverview?srch_term=project%3D%5Escience%3A
or from the upstream warewulf community repository
https://github.com/orgs/warewulf/packages?repo_name=warewulf-node-images
It is also possible to import an image from a chroot
by using the path to
chroot
as argument for wwctl import
.
Booting nodes
As a final preparation you should rebuild the container image by running
wwctl container build leap15.5
as well as all the configuration overlays with the command
wwctl overlay build
just in case the build of the image may have failed earlier due to an error. If you didn’t assign a hardware address to a node before you should set the node into the discoverable state before powering it on. This is done with
wwctl node set node01 --discoverable
Now the node(s) can be powered on and will boot into assigned container.
For a convenient experience you should now log out of and back into the warewulf host, as this way an ssh key for password-less login to the compute nodes will be created on the warewulf host. Note, that this key is not pass-phrase protected. If you require a pass phrase, it is probably a good idea to set one now:
ssh-keygen -p -f $HOME/.ssh/cluster
Also you should run
wwctl configure hostlist
to add the new nodes to the file /etc/hosts
.
Additional configuration
The configuration files for the nodes are managed as Golang text templates. The resulting files are overlayed over the node images. There are two ways of transport for the overlays to the compute node, the
- system overlay
- runtime overlay
where the system overlay is baked into the boot image of the compute node
while the runtime overlay is updated on the nodes on a regular base
(1 minute per default) via the
wwclient
service.
In the default configuration the overlay called wwinit
is used as system
overlay. You can list the files in this overlays with the command:
wwctl overlay list wwinit -a
which will show a list of all the files in the overlays. Files ending with the
suffix .ww
are interpreted as template by warewulf and the suffix is removed
in the rendered overlay.
The content of the overlay can be shown using the command
wwctl overlay show wwinit /etc/issue.ww
To render the template using the values for node01 use:
wwctl overlay show wwinit /etc/issue.ww -r node01
The overlay template itself may be edited using the command
wwctl overlay edit wwinit /etc/issue.ww
Please note that after editing templates the overlays aren’t updated automatically and should be rebuild with the command
wwctl overlay build
The variables available in a template can be listed with
wwctl overlay show debug /warewulf/template-variables.md.ww
Modifying the container
The node container is a self contained operating system image. You can open a shell in the image with the command
wwctl container shell leap15.5
After you have opend a shell in the image additional software can be installed
with zypper
.
The shell command provides the option --bind
which allows to mount arbitrary
host directories into the container during the shell session.
Please note that if a command exits with a status other than zero the image won’t be rebuilt automatically. So its also advised to rebuild the container with
wwctl conainer build leap15.5
after any change.
Network configuration
Warewulf allows to configure multiple network interfaces for the compute nodes. You can add another network interface for example for infiniband using the command
wwctl node set node01 --netname infininet -I 172.16.17.101 --netdev ib0 --mtu 9000 --type infiniband
This will add the infiniband interface ib0
to the node node01
. You can now
list the network interfaces of the node:
wwctl node list -n
As changes in the settings are not propagated to all configuration files, the node overlays should be rebuilt after this change running the command:
wwctl overlay build
After a reboot these changes will be present on the nodes, in the avove case the Infiniband interface will be active on the node.
A more elegant way to get same result is to create a profile to hold the values
which are the same for all interfaces. In this case these are mtu
and the
netdev
.
A new profile for an Infiniband network is created using the command
wwctl profile add infiniband-nodes --netname infininet --netdev ib0 --mtu 9000 --type infiniband
Once this has been created, you may add this profile to a node and remove the node specific settings which are now part of the common profile by executing:
wwctl node set node01 --netname infininet --netdev UNDEF --mtu UNDEF --type UNDEF --profiles default,infiniband-nodes
You may list the data in a profile using this command:
wwctl profile list -A infiniband-nodes
Secure Boot
Switch to grub boot
Per default warewulf boots nodes via iPXE, which isn’t signed by SUSE and
can’t be used when secure boot is enabled. In order to switch to grub as boot
method you will have add/change following value in /etc/warewulf/warewulf.conf
warewulf:
grubboot: true
After this change you will have to reconfigure dhcpd
and tftp
executing
wwctl configure dhcp
wwctl configure tftp
and rebuild the overlays with the command
wwctl overlay build
Also make sure that the packages shim
and grub2-x86_64-efi
for x86-64
or grub2-arm64-efi
for arm are installed in the container. shim
is
required by secure boot.
Cross product secure boot
If secure boot is enabled on the compute nodes and you want to boot different
products make sure that the compute nodes boot with the so called ‘http’ boot
method: For secure boot the signed shim
needs to match the signature of the
other pieces of the boot chain - including the kernel. The ‘http’ method is
handled by warewulfd
which will look up the image to boot and pick the shim
from the image to deploy to this node. Otherwise, the initial shim
for PXE
boot, which is the default boot method, is extracted from the host running the
warewulfd server. Make sure, the node container contains the shim
package.
The host system shim
will also be used for nodes which are in discoverable
state and subsequently have no hardware address assigned yet.
Disk management
It is possible to manage the disks of the compute nodes with warewulf. Here,
warewulf itself doesn’t manage the disks, but creates a configuration and
service files for ignition
to do this job.
Prepare container
As ignition
and its dependencies aren’t installed in most of the containers
you should install the packages ignition
and gptfdisk
in the container
wwctl container exec <container_name> zypper -n in -y ignition gptdisk
Add disk to configuration
For storage devices all the necessary structures must be configured which are
- physical storage device(s) to be used
- partition(s) on the disks
- filesystem(s) to be used
Disks
The path to the device e.g. /dev/sda
must be used As diskname
.
The only valid configuration for disks is diskwipe
which should be
self explanatory.
Partitions
The partname
is the name to the partition whick iginition uses as the path
for the device files, e.g. /dev/disk/by-partlabel/$PARTNAME
.
Additionally the size and number of the partition need be specified for all but the last partition (the one with the highest number) in which case this partition will be extended to the maximal size possible.
You should also set the boolean variable --partcreate
so that a parition
is created if it doesn’t exist.
Filesystems
Filesystems are defined by the partition which contains them, so the
name should have the format /dev/disk/by-partlabel/$PARTNAME
. A filesystem
needs to have a path if it is to be mounted, but its not mandatory.
Ignition will fail, if there no filesystem type is defined.
Examples
You can add a scratch partition with
wwctl node set node01 \
--diskname /dev/vda --diskwipe \
--partname scratch --partcreate \
--fsname scratch --fsformat btrfs --fspath /scratch --fswipe
This will be the only (and last) partition, therefore it does not require a size. To add another partition as swap partition, you many run:
wwctl node set n01 \
--diskname /dev/vda \
--partname swap --partsize=1024 --partnumber 1 \
--fsname swap --fsformat swap --fspath swap
This adds the partition number 1 which will be placed before
the scratch
partition.
-
This container is special only in that it is bootable, ie it contains a kernel and an init-implementation (systemd). ↩
Dedicated Windows XML eventlog parser in syslog-ng
Version 4.6 of syslog-ng introduced windows-eventlog-xml-parser(), a dedicated parser for XML-formatted event logs from Windows. It makes the EventData portion of log messages more useful, as it combines two arrays into a list of name-value pairs.
https://www.syslog-ng.com/community/b/blog/posts/dedicated-windows-xml-eventlog-parser-in-syslog-ng
Aggregating messages in syslog-ng using grouping-by()
Sometimes you have many log messages from an app, but none of them have the exact content you need. This is where the grouping-by() parser of syslog-ng can help. It allows you to aggregate information from multiple log messages into a single message.
In this blog, I will show you how to parse sshd logs using the patterndb parser of syslog-ng, and then create an aggregate message from the opening and closing log message using grouping-by.
https://www.syslog-ng.com/community/b/blog/posts/aggregating-messages-in-syslog-ng-using-grouping-by
New systemd-boot Integration in openSUSE
There are several changes happening in openSUSE’s rolling release Tumbleweed on a daily basis and integrating systemd-boot into has been evolving.
A shift from the traditional GRUB boot loader is promising better system boot performance and security.
An all-systems-go presentation by Ludwig Nussel sheds some light on the motivations, challenges and future direction of systemd-boot integration in openSUSE.
The primary motivation behind adopting systemd-boot lies in its simplicity and efficiency, especially when handling full-disk encryption. Traditional boot loaders like GRUB require embedding decryption code and key derivation functions that can complicate the boot loader code and the boot process; this could slow down the system at startup. With systemd-boot, these responsibilities are delegated to the Linux Kernel and user space, which helps to streamline the boot process.
MicroOS and Tumbleweed’s use of Btrfs and its snapshotting capabilities adds complexity to the boot process; this is being addressed by integrating systemd-boot with the snapshot management system to ensure each snapshot boots successfully and that kernel updates are handled gracefully within this dynamic environment.
To facilitate this integration, new packaging scripts and tools like sdbootutil
were introduced to manage kernel versions, snapshots and boot entries. This tool plays a crucial role in making systemd-boot a practical choice for openSUSE users, as the way that the snapshots are managed are different in MicroOS than in Tumbleweed.
Using sdbootutil
, the system will create new Type #1 boot entries in the EFI System Partition (ESP) to represent all the avaliable boot options, which will copy from the snapshot the new installed kernels into this partition. It will also generate good initrd
for those snapshots.
When using full disk encryption, sdbootutil
will also call the different commands that will update the policies required to automatically unlock the new snapshots using the internal Trusted Platform Module 2.0 (TPM2) device of the system.
Ideally, in the future, some if not all of this functionallity will be exported into systemd
itself or other systems components in the distribution. These changes make this tools a good place to experiment, validate or discard the different approaches that openSUSE is leading with systemd-boot.
At this point, systemd-boot support in openSUSE is still considered experimental. Both Tumbleweed and MicroOS yast installers offer systemd-boot as an alternative to grub for the brave. There are also ready-made appliances for qemu that use systemd-boot and full-disk encryption by default.
Mon, Mar 4th, 2024
KDE ISO Image Writer | USB Drive Writing Tool
dnf5daemon-server: Local root Exploit and Local Denial-of-Service in dnf5 D-Bus Components
1) Introduction
The dnf5daemon-server component offers a collection of D-Bus interfaces to interact with the dnf5 package manager on the system. An openSUSE community packager wanted to add the additional D-Bus component to the openSUSE Tumbleweed distribution. New D-Bus system services require a review by the SUSE security team. In the course of this review I found the issues described in this report.
The version of dnf5 I reviewed for this is 5.1.9, and any source code references below are based on the corresponding version tag in the upstream Git repository.
2) D-Bus Interface Design
The dnf5daemon-server offers a main interface “org.rpm.dnf.v0.SessionManager” on which clients can create a new session, which results in a new dynamically allocated D-Bus object being registered on the bus. This session object provides a set of additional D-Bus interfaces for modifying package manager configuration, for installing or removing packages or for inspecting metadata about packages and repositories on the system.
The dnf5daemon-server is running as root and can be autostarted via the D-Bus system bus if it is not already running. Any other users with access to the D-Bus system bus may talk to it.
For certain privileged operations the D-Bus service implements Polkit authentication. Only three operations are protected by Polkit:
org.rpm.dnf.v0.rpm.RepoConf.write
org.rpm.dnf.v0.rpm.execute_transaction
org.rpm.dnf.v0.rpm.Repo.confirm_key
These relate to changing the repository configuration, executing transactions or importing new trusted signing keys. Transactions cover all kinds of changes introduced through the package manager.
All of these operations require auth_admin
privileges on Polkit level. The
integration of the Polkit authorization logic is correct as far as I can tell.
The per-session D-Bus interface provided by dnf5daemon-server is rather large and many calls take additional key/value maps to tune the behaviour of the package manager logic contained in libdnf5. In summary, the libdnf5 library is attached very closely to the D-Bus system bus via dnf5daemon-server.
3) Local Root Exploit via Configuration Dictionary (CVE-2024-1929)
While the privileged operations mentioned above are correctly protected by Polkit, there are issues with the D-Bus interface long before Polkit is even invoked.
The org.rpm.dnf.v0.SessionManager.open_session
method takes a key/value map
of configuration entries. A sub-entry in this map, placed under the “config”
key, is another key/value map. The configuration values found in it will be
forwarded as configuration overrides to the libdnf5::Base
configuration. The
spot where this happens is found in session.cpp:63.
Practically all libdnf5 configuration aspects can be influenced here, as can be
seen in the ConfigMain class in config_main.hpp
.
Already when opening the session via D-Bus, the libdnf5 will be initialized
using these override configuration values. There is no sanity checking of the
content of this “config” map, which is untrusted data.
There are surely a lot of different ways to exploit this possibility to influence the libdnf5 configuration. The simplest approach to get full root privileges I found is to trick the library into loading a plug-in shared library under control of the unprivileged user.
To do this, the “pluginpath” and “pluginconfpath” configuration entries need to
be supplied and need to point to a user-controlled path. There the
unprivileged user can place a configuration file that in turn points towards a
user controlled shared library. The library will then dlopen()
this user
controlled shared library, which will lead to full code execution in the
context of the root user.
3.1) Proof of Concept
A proof of concept I wrote shows this vulnerability in
action. I successfully tested this exploit also on Fedora 39 using
dnf5daemon-server version 5.1.10. The only precondition for this exploit is
that the dnf5daemon-server package is installed on the system. Any local
user, even nobody
, can obtain root privileges this way.
3.2) Bugfix
To fix this, I suggested to enforce a whitelist of configuration parameters that are allowed to be overridden. Only a very small subset of values should be allowed for unprivileged clients.
In upstream commit e51bf2f0d such a whitelist enforcement has been implemented for dnf5daemon-server.
3.3) CVE Assignment
Red Hat Product Security assigned CVE-2024-1929 for this issue.
4) No Limit on Number of Open Sessions / Bad Session Close Behaviour (CVE-2024-1930)
There is no limit on how many sessions D-Bus clients may create using the
open_session()
D-Bus method. In my tests I was able to quickly create about
4,500 sessions and keep them open. For each session a thread is created in
dnf5daemon-server. This spends a couple of hundred megabytes of memory in the
process. Further connections will become impossible, likely because no more
threads can be spawned by the D-Bus service.
In some cases I even managed to cause the D-Bus service to abort()
as a
result of hitting resource limits. If the service continues running and the
client disconnects, then the cleanup code found in
SessionManager::on_name_owner_changed()
runs for each session that has been
created. Each Session holds a ThreadsManager
, where the thread associated
with each session originates from. It is a thread that is busy-waiting to join
other threads, the code for this is found in
threads_manager.cpp:33
. Since there is a sleep of
one second in this thread’s loop it takes about ~4,500 seconds for all the
threads from the 4,500 sessions to be joined one by one. The service will be
unreachable for more than an hour.
4.1) Bugfix
To fix this, I suggested to limit the number of sessions for each unprivileged
user in the system to a sensible value. Also the busy-wait loop in
ThreadsManager
seems ill-devised. Maybe using a condition variable to inform
the cleanup thread of new work would be more efficient. Having a dedicated
ThreadsManager
and join-thread for each session seems a bit overkill, too.
In upstream commit c090ffeb79 the maximum number of sessions is limited to three sessions. The problematic thread joining behaviour has not been addressed as of now.
4.2) CVE Assignment
Red Hat Product Security assigned CVE-2024-1930 for this issue.
5) Untrusted locale
Setting for each Session
Another part of the per-session setup is the use of an untrusted locale
setting in session.cpp:54
. This string is passed
to the C library’s newlocale()
function in
threads_manager.cpp:92
. A danger here is
that arbitrary user controlled files or symlinks could be processed by the C
library, which could lead to various issues like information leaks, denial of
service or even code execution. I looked into the GNU glibc implementation of
newlocale()
, and luckily it already implements a very careful locale lookup
algorithm, that prevents that arbitrary paths are accessed if crafted locale
strings are passed to it. This outcome might change if a different C library
is used.
Whether anything bad could happen, apart from file system issues, when exotic locales are selected for a thread running in dnf5daemon-server is another question that I did not investigate more closely.
For hardening purposes I suggested that dnf5daemon-server performs a sanity
check of the locale
string to prevent a string that contains e.g. a slash
character /
from being used. I don’t know of any upstream commits that
address this yet, but upstream stated that they intend to work on this in the
future.
6) dnfdaemon-client Demands Full Root
Although the D-Bus service implements Polkit for privileged operations, the dnf5daemon-client refuses to perform privileged operations for non-root users. For example:
user$ dnf5daemon-client distro-sync
This command has to be run with superuser privileges (under the root user on most systems).
The code for this is found in various sub-command implementations:
$ grep -r 'throw UnprivilegedUserError' -C 1
dnf5daemon-client/commands/downgrade/downgrade.cpp- if (!libdnf5::utils::am_i_root()) {
dnf5daemon-client/commands/downgrade/downgrade.cpp: throw UnprivilegedUserError();
dnf5daemon-client/commands/downgrade/downgrade.cpp- }
--
dnf5daemon-client/commands/distro-sync/distro-sync.cpp- if (!libdnf5::utils::am_i_root()) {
dnf5daemon-client/commands/distro-sync/distro-sync.cpp: throw UnprivilegedUserError();
dnf5daemon-client/commands/distro-sync/distro-sync.cpp- }
--
dnf5daemon-client/commands/install/install.cpp- if (!libdnf5::utils::am_i_root()) {
dnf5daemon-client/commands/install/install.cpp: throw UnprivilegedUserError();
dnf5daemon-client/commands/install/install.cpp- }
--
dnf5daemon-client/commands/remove/remove.cpp- if (!libdnf5::utils::am_i_root()) {
dnf5daemon-client/commands/remove/remove.cpp: throw UnprivilegedUserError();
dnf5daemon-client/commands/remove/remove.cpp- }
--
dnf5daemon-client/commands/upgrade/upgrade.cpp- if (!libdnf5::utils::am_i_root()) {
dnf5daemon-client/commands/upgrade/upgrade.cpp: throw UnprivilegedUserError();
dnf5daemon-client/commands/upgrade/upgrade.cpp- }
--
dnf5daemon-client/commands/reinstall/reinstall.cpp- if (!libdnf5::utils::am_i_root()) {
dnf5daemon-client/commands/reinstall/reinstall.cpp: throw UnprivilegedUserError();
dnf5daemon-client/commands/reinstall/reinstall.cpp- }
It doesn’t make sense that the client forces users to run as root (and thereby increase the attack surface by running also the client code as root) when the service could authenticate the user via Polkit.
I suggested to drop this root-check code in the client, and rely on the authentication logic in the service side code. If authentication fails, then the client code can still hint at the possibility to run the program as root. I am not aware on any upstream commits that address this yet, but upstream stated that they intend to work on this in the future.
7) General Review Summary
In summary my impression is that the libdnf5 library is too closely connected to the D-Bus system bus. The library itself is unaware of the fact that it is running with partially untrusted input. The dnf5daemon-server code needs to carefully filter untrusted input before it is passed to the generic library code.
8) Timeline
2024-01-10 | I reported the findings to secalert@redhat.com offering coordinated disclosure. |
2024-01-16 | We received a reply that the issue would affect Fedora only and it was suggested that I create a bug in their Bugzilla for direct communication with the dnf5 developers. |
2024-01-18 | I created a private Bugzilla bug as suggested. |
2024-01-24 | The bug did not receive any attention, so I asked Red Hat Product Security once more about the procedures going forward, as the offer for coordinated disclosure has not been accepted or denied yet. |
2024-01-25 | We received a reply that bugfixes are being worked on, but they would likely need the full 90 days maximum embargo period for publishing updates. |
2024-02-26 | From the openSUSE packager for dnf5 I learned that a bugfix for issue 3) was already public. So I contacted Red Hat Product Security once more to learn about the publication status of the issues. |
2024-02-27 | We received a reply with the two CVE assignments mentioned in this report and have been asked what our wishes are regarding a publication date. |
9) References
Sat, Mar 2nd, 2024
Distrobox with BoxBuddy on openSUSE
Fri, Mar 1st, 2024
openSUSE Tumbleweed – Review of the week 2024/09
Dear Tumbleweed users and hackers,
This week was truly crazy for the staging masters — apologies to Ana for flooding you with requests. Many contributors have been busy preparing our packages for RPM 4.20 (which is still at least half a year out – but we preferred to fix things now rather than being under pressure then). When the effort started on Feb 20, we had 2066 spec files that would have failed to build with RPM 4.20. Today, just 10 days later, we have less than 700 – and many requests in the queue to address those.
Of course, that’s not everything that happened this week. We have again delivered six snapshots (0223, 0225, 0226, 0227, 0228, and 0229) with the following changes:
- libjxl 0.10.0 & 0.10.1 (this time the update went without fallout)
- Samba 4.19.5
- Linux kernel 6.7.6
- mdadm 4.3: stricter on naming devices posix compliant
- Mozilla Firefox 123.0
- chrony 4.5
- openSSH 9.6p1
- fwupd 1.9.14
- exiv2 0.28.2
- Ruby 3.2 has been removed: this includes all the ruby gems AND the ruby 3.2 interpreter
The staging lists and backlog are largely filled with the same old topics:
- ImageMagick 7.1.1.29
- Python 3.x fixes for CVE-2023-6597 (TmpDir cleaning)
- openblas 0.3.26: breaks python-networkx, and python-scikit-learn
- openjpeg 2.5.1: breaks ghostscript
- KDE Frameworks and Plasma 6: Staging turns out to be messy
- KDE Gear 24.02.0 – Requires KDE Frameworks 6
- Systemd 255.3
- python 3.9 deprecation: we decided to postpone this a little but, due to the still large fallout from Python 3.12 addition. Removing a Python flavor will require us to rebuild all the Python packages for the new builds to drop the python39 flavor. Too many packages fail to build at this moment.
- dbus-broker: a big step forward; upgrades seem to be an issue that needs to be addressed
- libxml 2.12.x: slow/no progress
- GCC 14: phase 2: use gcc14 as the default compiler
Wed, Feb 28th, 2024
openSUSE Tumbleweed Monthly Update - February
Welcome to the monthly update for openSUSE Tumbleweed for February 2024. This month we get one more day in February because of Leap year, but here is what we have for the month. This blog aims to provide readers with an overview of the key changes, improvements and issues addressed in openSUSE Tumbleweed snapshots throughout the month. Should readers desire a more frequent amount of information about openSUSE Tumbleweed snapshots, readers are advised to subscribe to the openSUSE Factory mailing list.
New Features and Enhancements
-
Linux Kernel: February brought updates to the Linux kernel, progressing through versions 6.7.2 to 6.7.6. These updates focus on enhancing memory management, addressing some security vulnerabilities, and introducing support for new hardware models, ensuring improved compatibility and performance across various systems.
- Fixes for various issues, including null-pointer dereference in powerpc/mm, incorrect node setting for arm64 irq, and build errors in powerpc architecture.
- Correcting the node assignment for VMAP stack in the
arm64
irq module. - Fix for a null-pointer dereference in
pgtable_cache_add
in the powerpc/mm module. - Fixes for various issues in filesystems like ext4 and JFS.
- Ensuring proper handling of NMIs during very early boot in the
x86/boot
module. - New hardware support or models:
- Colorful X15 AT 23 Laptop
-
KDE Frameworks: Update for version 5.115.0.
- xtra CMake Modules: The ECMUninstallTarget now ports generated code away from deprecated exec_program, enhancing compatibility and maintainability.
- KHolidays: Adds St Brigid’s Day.
- KIO: Once again KDirModel, allows expanding network directories in file picker.
- prison : Enables exceptions for videoscannerworker.cpp.
-
Mesa: Updates to 23.3.6
- zink: Addresses flickering artifacts in Selaco, broken colors/dual-source blending on PinePhone Pro, and fixes sparse bo placement.
- panfrost: Resolves graphical artifacts on T604 (T600), fixes intermittent compiler failures when building valhall tests, and pads compute jobs with zeros on v4.
- radeonsi: Fixes unsynchronized flips/tearing with KMS DRM rendering on 780M and addresses heavy corruption in Amnesia: The Dark Descent.
- VK: Various fixes for flaky tests, fullscreen “banding” artifacts in Age of Empires IV, and failures in dEQP-VK pipeline tests.
-
systemd: Updates to version 254.9.
- vconsole-setup: Resolved issue where vconsole-setup would fail if the only found vc is already used by plymouth.
- systemd-testsuite: Dependency updated to “qemu” instead of “qemu-kvm”, the latter being obsolete.
- test/test-shutdown.py: Option added to display test I/Os in a dedicated log file.
- man pages: Documentation update to include ranges for distributions config files and local config files.
- libbpf: Version of libbpf dlopened by systemd updated (weak dependency).
-
glibc: Updated from version 2.38 to 2.39,
- PLT Rewrite: Introduction of a new tunable,
glibc.cpu.plt_rewrite
, allows for enabling PLT rewrite on x86-64 architectures. - Sync with Linux Kernel 6.6: Synchronization with Linux kernel 6.6 shadow stack interface.
- New Functions: Addition of new functions on Linux, including
posix_spawnattr_getcgroup_np
,posix_spawnattr_setcgroup_np
,pidfd_spawn
,pidfd_spawp
, andpidfd_getpid
. - scanf-family functions: Support for the wN format length modifiers for arguments pointing to specific types.
- Memory Allocation Tunable: Introduction of a new tunable,
glibc.mem.decorate_maps
, for adding additional information on underlying memory allocated by glibc. - ISO C2X: Inclusion of the
<stdbit.h>
header from ISO C2X. - AArch64: Addition of new symbols to libmvec on AArch64.
- ldconfig Enhancements: ldconfig now skips file names containing specific characters and patterns.
- Dynamic Linker Improvements: The dynamic linker calls the
malloc
andfree
functions in more cases during TLS access if a shared object with dynamic TLS is loaded and unloaded.
- PLT Rewrite: Introduction of a new tunable,
-
Cups-Filters: Updates to version 1.28.17
- Improved Printer Capability Discovery: Enhancements to more reliably discover all printer capabilities from driverless printers, particularly borderless printing. This includes preferring Apple Raster over PWG Raster or PCLM formats.
- PPD Generator Optimization: The PPD generator now creates only one *cupsFilter2 line for raster, utilizing the most desirable/reliable format, usually Apple Raster.
- Media Database Handling: Enhancements in handling media-col-database and media-col-ready IPP attributes separately if needed, revealing important functionality like borderless printing.
- Margin Alternatives Consideration: Consideration of all margin alternatives when generating PPD files for driverless printers, ensuring the discovery of borderless functionality for many printers.
- Image Printing Enhancements: Images are now printed in their original size with “print-scaling=none”, and deprecated data types for reading TIFF images have been replaced with modern equivalents.
-
openvpn: Updates to version 2.6.9
- Enhanced Logging: SSL alerts are now logged more prominently, improving visibility into SSL-related issues.
- Documentation Improvements: Clarifications and additions to documentation, including the documentation of the
tls-exit
option as a primarily test option. - Code Cleanup: Removal of unused function prototypes and redundant code, ensuring cleaner codebase and improved maintainability.
- Error Handling: Addition of missing error checks and enhancements to error messages for better debugging and troubleshooting.
- Security Enhancements: Implementation of the
--tls-export-cert
feature and addition of checks for TLS 1.0 PRF availability, improving security measures. - Configuration Clarifications: Clarifications regarding the
tls-crypt-v2-verify
option and removal of redundant options like--tls-export-cert
. - Library Compatibility: Support added for newer versions of dependencies like mbedtls 3.x.y, with TLS 1.3 support disabled.
Security Updates
This month’s updates include critical security patches and bug fixes for glibc, GStreamer, Salt, Xen and many other packages.
Bug Fixes
- glibc: Had a few Common Vulnerabilities and Exposures fixed. CVE-2023-6246, CVE-2023-6779, which was a buffer overflow, CVE-2023-6780, which was an integer overflow, both that lead to an incorrect calculation of the buffer size.
- GStreamer: CVE-2024-0444 made it possible for a malicious third party to trigger a crash in the application.
- Salt: CVE-2024-22231 was vulnerable to a directory traversal attack and CVE-2024-22232, with a specially crafted url, could lead to a directory traversal in the salt file server.
- Xen: CVE-2023-46839 had a high complexity and required high privileges.
- dnsmasq: Both CVE-2023-50387 and CVE-2023-50868 could allow for remote attackers to cause a denial of service.
- qemu: CVE-2023-6693 could allow a hacker to steal data via a network device.
- bind: CVE-2023-50387 was associated with a “KeyTrap” DNS flaw lets attackers overload servers remotely. The other three were CVE-2023-4408, CVE-2023-5679 and CVE-2023-6516.
-
Node.js: Multiple CVEs were fixed. These were CVE-2024-21892, which let unprivileged users gain elevated rights, CVE-2024-22019, which was a flaw that let attackers crash servers with malformed requests, and CVE-2024-22017, which was a path traversal bug via Buffer manipulation in an experimental feature. There was also CVE-2024-21896, CVE-2023-46809, CVE-2024-21891, CVE-2024-21890, CVE-2024-22025 and CVE-2024-24758, which kept
Proxy-Authentication
headers after redirects; upgrade as needed.
Conclusion
February 2024 for openSUSE Tumbleweed showcases a diverse range of updates and improvements across essential components. There were critical security patches for software like glibc, GStreamer and Salt. The kernel updated from 6.7.2 at the beginning of the month to 6.7.6. There were updates for KDE Frameworks, Mesa, systemd, Cups-Filters and other core components. Other significant upgrades during the month included fwupd 1.9.13, PostgreSQL 16.2, Pulseaudio 17.0, GTK 4.12.5, Python 3.11.8, RPM 4.19.1.1, Mozilla Firefox 122.0.1, PHP 8.2.16, Poppler 24.02.0, Shadow 4.14.5, binutils 2.42, Qemu 8.2.1 and, Python 3.12. Next month should see systemd 255.3 arrive in the rolling release as the package is currently in staging.. The openSUSE team encourages users to continue participating through bug reports, feature suggestions and discussions.
Contributing to openSUSE Tumbleweed
Your contributions and feedback make openSUSE Tumbleweed better with every update. Whether reporting bugs, suggesting features, or participating in community discussions, your involvement is highly valued.
Tue, Feb 27th, 2024
Working with multi-line logs in syslog-ng
Most log messages fit on a single line. However, Windows and some developer tools and services, like Tomcat, write multi-line log messages. These can come in various formats. For example, new log messages start with a date in a specific format. You use the multi-line-prefix() of the syslog-ng file() source to send multi-line messages as single messages instead of line by line.
I must admit that I have never seen multi-line logs in production. I am not a developer, do not run Tomcat or Windows. However, recently I tested a software on Windows, which produced multi-line log messages.
You can read more at https://www.syslog-ng.com/community/b/blog/posts/working-with-multi-line-logs-in-syslog-ng