Chapter 11. Fixed issues

Improved installer stability during virtual network devices configuration

Previously, the installer could crash when creating a VLAN network device over an existing virtual network device (for example, Team or Bond) in the GUI. This occurred when the underlying device’s state changed during the configuration update to the user interface for the new device state.

IPsec ondemand connections no longer fail to establish

Previously, when an IPsec connection with the ondemand option was configured by using the TCP protocol, the connection failed to establish. With this update, the new Libreswan package makes sure that the initial IKE negotiation completes over TCP. As a result, Libreswan successfully establishes the connection even in TCP mode of IKE negotiation.

NSS now enforce EMS in FIPS mode

The Network Security Services (NSS) libraries now contain the TLS-REQUIRE-EMS keyword to require the Extended Master Secret (EMS) extension (RFC 7627) for all TLS 1.2 connections as mandated by the FIPS 140-3 standard. NSS use the new keyword when the system-wide cryptographic policies are set to FIPS.

shlibsign now works in FIPS mode

Before this update, the shlibsign program did not work in FIPS mode. Consequently, when you rebuilt an NSS library in FIPS mode, you had to leave FIPS mode to sign the library. The program has been fixed, and you can now use shlibsign in FIPS mode.

OpenSSL cipher suites no longer enable cipher suites with disabled hashes or MACs

Previously, applying custom cryptographic policies could leave certain TLS 1.3 cipher suites enabled even if their hashes or MACs were disabled, because the OpenSSL TLS 1.3-specific Ciphersuites option values were controlled only by the ciphers option of the cryptographic policy. With this update, crypto-policies takes more algorithms into account when deciding whether to enable a cipher suite. As a result, OpenSSL on systems with custom cryptographic policies might refuse to negotiate some of the previously enabled TLS 1.3 cipher suites in better accordance with the system configuration.

update-ca-trust extract no longer fails to extract certificates with long names

When extracting certificates from the trust store, the trust tool internally derives the file name from the certificates’ object label. For long enough labels, the resulting path might previously have exceeded the system’s maximum file name length. As a consequence, the trust tool failed to create a file with a name that exceeded the maximum file name length of a system. With this update, the derived name is always truncated to within 255 characters. As a result, file creation does not fail when the object label of a certificate is too long.

Binary tests for libcap are waived

The annocheck tool discovered binary packages in the libcap library function that were built without the required flags for RHEL 10 architectures. We examined the flags for potential problems and did not find any. After careful investigation, we have waived the results for libcap. As a result, all tests for libcap passed.

ReaR now interprets square brackets enclosing IPv6 addresses in URLs as expected

Previously, square brackets in OUTPUT_URL and BACKUP_URL were not interpreted correctly. Specifying an IPv6 address instead of a host name requires enclosing the address in square brackets, for example, [::1] for localhost. Since the brackets were not interpreted correctly, using an IPv6 address in a sshfs:// or nfs:// URL was not possible.

cups-filters project is now split into several projects

The cups-filters project is split into several projects . The notable packages are mentioned below :

NetworkManager can mitigate the impact of CVE-2024-3661 (TunnelVision) in VPN connection profiles

VPN connections rely on routes to redirect traffic through a tunnel. However, if a DHCP server uses the classless static route option (121) to add routes to a client’s routing table, and the routes propagated by the DHCP server overlap with the VPN, traffic can be transmitted through the physical interface instead of the VPN. CVE-2024-3661 describes this vulnerability, which is also know as TunnelVision. As a consequence, an attacker can access traffic that the user expects to be protected by the VPN.

RHEL 10 provides libnftnl version 1.2.8

The libnftnl library version 1.2.8 provides a few bug fixes. Notable changes include:

The GRUB2 net_del_dns command deletes the DNS server correctly

Previously, if you attempted to delete the DNS server by using the net_del_dns command, it added the DNS server back erroneously because of incorrect implementation, and returned an error. With this fix, the add command was replaced by the remove command in the net_del_dns implementation. As a result, you can delete the DNS server by using the net_del_dns command.

The Kickstart file now correctly sets the required device size for installation when using LVM partitioning with LUKS

Before this update, when you specified the --size=1 --grow --encrypted option in the Kickstart file for a new device, the installer failed to correctly expand the encrypted device to a valid size. Consequently, the automated installation stopped with an error message, for example:

multipathd no longer crashes because of errors encountered by the ontap prioritizer

Before this update, multipathd crashed when it was configured to use the ontap prioritizer on an unsupported path, because the prioritizer only works with NetApp storage arrays. This failure occurred due to a bug in the prioritizer’s error logging code, which caused it to overflow the error message buffer. With this update, the error logging code has been fixed, and multipathd no longer crashes because of errors encountered by the ontap prioritizer.

Native NVMe multipathing no longer causes a memory leak when enable_foreign is set to monitor natively multipathed NVMe devices

Before this update, enabling native NVMe multipathing caused a memory leak if the enable_foreign configuration parameter was set to monitor natively multipathed NVMe devices. With this update, the memory leak was fixed in multipathd monitoring code. As a result, multipathd can now monitor natively multipathed NVMe devices without increasing memory usage.

RHEL installer now discovers and uses iSCSI devices as boot devices on aarch64

Previously, the absence of the iscsi_ibft kernel module in RHEL installers running on aarch64 prevented the automatic discovery of iSCSI devices defined in firmware. As a result, these devices were not automatically visible nor selectable as boot devices in the installer during manual addition GUI.

fstrim enabled by default on LUKS2 root in ostree-based new installations done by Anaconda

Previously, installing ostree-based systems, such as Image Mode, by using ostreesetup or ostreecontainer Kickstart commands with LUKS2 encryption enabled on the / (root) mount point resulted in systems where fstrim was not enabled. This could cause issues such as unresponsive systems or broken file chooser dialogs. With this fix, fstrim (discards) is now enabled by default in the LUKS2 metadata on newly installed systems.

pcs validation of SBD options

Previously, when you enabled SBD with the pcs stonith sbd enable command and specified values for SBD options that are not valid, it resulted in SBD misconfiguration. The pcs command-line interface has been updated to validate the values for SBD options. When the values are not valid, pcs reports the error and does not create or update an SBD configuration.

Ability to remove Booth configuration from a Booth arbitrator node

Previously, running the pcs booth destroy command to remove Booth configuration from a Booth arbitrator node yielded an error. This happened because the command did not remove Booth configuration from nodes that are not part of the cluster. It is now possible to remove Booth configuration from Booth arbitrators.

pcsd processes now consistently stop correctly and promptly

Previously, the creation method for pcsd processes sometimes caused a deadlock during process termination. The processes were then terminated only after a systemd timeout. This fix changes the process creation method and there is no longer a deadlock when the processes are stopped. As a result, pcsd consistently stops correctly within a short time.

pcs no longer validates fencing topology with fencing levels greater than 9

The Pacemaker cluster resource manager ignores fencing topology levels greater than 9. Configuring levels greater than 9 may lead to failed fencing. With this update, you can configure fencing levels with values of only 1 to 9 in the pcs command-line interface and fencing topology works correctly.

The syntax for specifying a scorevalue is now consistent across all pcs constraint commands

Previously, some commands for creating constraints required you to specify a score value as score=value, whereas others expected just value without score=. With this update, all constraint commands accept a score value in the form score=value, with the exception of pcs constraint location prefers and pcs constraint location avoids, which expect node=score where score is the score value.

The CIB manager no longer increases in size indefinitely with each request from an asynchronous client

Previously, when the CIB manager received a request from an asynchronous client, it leaked a small amount of memory. This caused the CIB manager process gradually to grow in size. With this fix, the relevant memory is freed for asynchronous clients and the CIB manager process does not grow in size indefinitely.

Resource constraints with expired rules no longer display

Before this update, the pcs constraint location config resources command displayed resource constraints with expired rules in the output. With this update, the command no longer displays constraints with expired rules if you do not specify the --all option.

Cluster status of a disaster recovery site now displays correctly

Before this update, when you configured a disaster recovery site and ran the pcs dr status command to display the status of the local and remote cluster sites, the command displayed an error instead of the cluster status. With this update, the cluster status of the local and remote sites displays correctly when you execute this command.

Status of a cloned resource running with only one instance now displays properly

Before this update, when you queried the status of the instances of a cluster resource clone with only one running instance, the pcs status query command displayed an error message. With this update, the command reports the resource status properly.

Go applications no longer panic if OpenSSL is not installed

Previously, if the OpenSSL library was not installed, applications created with Go panicked even if the Federal Information Processing Standard (FIPS) mode was disabled. This update solves this problem. As a result, you can now run applications created with Go if OpenSSL is not installed.

Go now uses ld.bfd as the default linker on the 64-bit ARM platform

In previous RHEL versions, Go used the ld.gold linker only on 64-bit ARM platforms and ld.bfd on other platforms. Because ld.gold is deprecated in the binutils project, Go now also uses ld.bfd on 64-bit ARM platforms.

The ipa idrange-add command now warns that Directory Server must be restarted on all IdM servers

Previously, the ipa idrange-add command did not warn the administrator that they must restart the Directory Server (DS) service on all IdM servers after creating a new range. As a consequence, the administrator sometimes created a new user or group with a UID or GID belonging to the new range without restarting the DS service. The addition resulted in the new user or group not having an SID assigned. With this update, a warning that DS needs to be restarted on all IdM servers is added to the command output.

The ipa-replica-manage command no longer resets the nsslapd-ignore-time-skew setting during forced replication

Previously, the ipa-replica-manage force-sync command reset the nsslapd-ignore-time-skew setting to off, regardless of the configured value. With this update, the nsslapd-ignore-time-skew setting is no longer overwritten during forced replication.

certmonger now correctly renews KDC certificates on hidden replicas

Previously, when the certificate was about to expire, certmonger failed to renew the KDC certificate on hidden replicas. This happened because the renewal process only considered non-hidden replicas as active KDCs. With this update, the hidden replicas are treated as active KDCs, and certmonger renews the KDC certificate successfully on these servers.

Bypassing two-factor authentication using an expired token is no longer possible

Previously, it was possible to bypass two-factor authentication by creating an OTP token with a specific end-validity period.

The Account Policy plug-in now uses a proper flag for an update in a replication topology

Before this update, the Account Policy plugin did not use the proper flag for an update. As a result, in a replication topology, the Account Policy plugin updated the login history, but this update failed on a consumer server logging the following error message:

TLS 1.3 can now be used to connect to an LDAP server running in FIPS mode

Before this update, when you tried to explicitly set TLS 1.3 when connecting to an LDAP server in FIPS mode, the used TLS version still remained 1.2. As a result, an attempt to connect to the LDAP server by using TLS 1.3 failed. With this update, the upper limit of the TLS version in FIPS mode was changed to 1.3, and the attempt to connect to an LDAP server with TLS 1.3 no longer fails.

A race condition with paged result searches no longer closes the connection with a T3 error code

Before this update, Directory Server did not use the proper thread protection when checking the connection’s paged result data for a timeout event. As a consequence, the paged result timeout value changed unexpectedly and triggered a false timeout when a new operation arrived. This caused a time out error and the connection was closed with the following T3 error code:

ldapsearch now respects the NETWORK_TIMEOUT setting as expected

Before this update, an ldapsearch command ignored the timeout when the server was unreachable and, as a consequence, the search hung indefinitely instead of timing out. With this update, the logic error in TLS handling was fixed by adjusting connection retries and socket options.

OpenLDAP library no longer fails when trying to free resources

Before this update, the OpenLDAP library tried to release memory by using the SSL_CTX_free() function in its destructor when an application had already cleaned up these resources by invoking the OPENSSL_cleanup() function, either directly or via the atexit() function. As a consequence, users experienced failures or undefined behavior when the invalid SSL_CTX_free() call tried to release already-cleaned-up SSL context resources.

Reindexing no longer fails when an entry RDN has the same value as the suffix DN

Before this update, if an entry’s relative distinguished name (RDN) had the same value as the suffix distinguished name (DN) in the directory, then the entryrdn index got broken. As a result, Directory Server could perform slow search requests, get invalid results, and write alarming messages in the error log.

sssd-polkit-rules package content moved to sssd-common

Previously, if you needed to enable smart card support when the system security services daemon (SSSD) did not run as root, you had to install the sssd-polkit-rules package. The package provided polkit integration with SSSD. To resolve this issue, the sssd-common package now includes the content of the sssd-polkit-rules package and installation of a separate package is no longer required.

No property conflicts between the NetworkManager service and the NetworkManager plugin

Before this update, the network RHEL system role did not request user consent to restart the NetworkManager service when updates were available to networking packages, particularly, due to wireless interface changes. Consequently, this led to potential conflicts between the NetworkManager service and the NetworkManager plugin. Alternatively, the NetworkManager plugin was failing to run correctly. The problem has been fixed by making the network RHEL system role ask user for their consent to restart the NetworkManager service. As a result, there are no property conflicts between the NetworkManager service and the NetworkManager plugin in the described scenario.

Implementation of multiple sets of key-value pairs of node attributes is now consistent with other cluster configuration components

The ha_cluster RHEL system role supports only one set of key-value pairs for each configuration item. Previously, when you configured multiple sets of node attributes, the sets were merged into a single set. With this update, the role uses only the first set you define and ignores the other sets. This behavior is now consistent with how the role implements multiple sets of key-value pairs for other configuration components that use a key-value pair structure.

The postgresql RHEL system role no longer fails to set the paths to a TLS certificate and private key

The postgresql_cert_name variable of the postgresql RHEL system role defines the base path to the TLS certificate and private key without suffix on the managed node. Before this update, the role did not define internal variables for the certificate and private key. As a consequence, if you set postgresql_cert_name, the Ansible task failed with the following error message:

The bootloader RHEL system role generates the missing /etc/default/grub configuration file if necessary

Before this update, the bootloader RHEL system role expected the /etc/default/grub configuration file to be present. In some cases, for example on OSTtree systems, /etc/default/grub can be missing. As a consequence, the role failed unexpectedly. With this update, the role generates the missing file with default parameters if necessary.

The podman RHEL system role can set the ownership of the host directory again

Before this update, the podman RHEL system role was using the become keyword with the user when setting the ownership of the host directory. As a consequence, the role could not properly set the ownership. With this update, the podman RHEL system role does not use become with the ordinary user. Instead, it uses the root user. As a result, podman can set the ownership of the host directory.

The linger feature can be canceled for the correct users

When processing the instruction list of configuration items from kube files or Quadlet files, the podman RHEL system role was incorrectly using the user ID associated with the entire list. It did not use the user ID associated with the list item to compile the linger file name. Consequently, the linger file was not created and therefore the podman RHEL system role could not cancel the linger feature for the actual user if necessary. With this update, podman uses the correct username to construct the linger file name. As a result, the linger feature can be canceled for the correct users.

The storage RHEL system role is idempotent again

The storage RHEL system role in some cases incorrectly calculated sizes of existing devices. Consequently, running the same playbook again without changes caused the role to attempt resizing the device that already had the correct size, instead of passing without errors. With this update, the size calculation was fixed. As a result, the role now correctly identifies that the device already has the size specified by the playbook and does not try to resize it.

Running the storage RHEL system role on a system with a pre-existing Stratis pool works as expected

Before this update, the storage RHEL system role could not process the existing devices and device formats. This caused the role to fail on systems with a pre-existing Stratis pool, when checking if Stratis format conformed to the configuration specified by the playbook. Consequently, the playbook failed with an error, however the Stratis pool itself was not damaged or changed. This update makes the storage RHEL system role work correctly with Stratis devices and other formats without labelling support. As a result, running a playbook on a system with a pre-existing Stratis pool no longer fails.

You cannot set the name parameter for the imuxsock input type

Before this update, the logging RHEL system role incorrectly set a name parameter for the imuxsock input type. As a consequence, this input type did not support the name parameter and the rsyslog utility on the managed node printed this error …​parameter 'name' not known — typo in config file?…​. This update fixes the logging RHEL system role to ensure that the name parameter is not associated with the imuxsock input type.

GRUB2 on RHEL 10 and RHEL 9 UEFI managed nodes correctly prompts for a password

Before this update, the bootloader RHEL system role incorrectly placed the password information in the /boot/efi/EFI/redhat/user.cfg file on managed nodes that ran RHEL 10 and RHEL 9 with UEFI Secure Boot feature. The correct location was the /boot/grub2/user.cfg file. Consequently, when you rebooted the managed node to modify any boot loader entry, GRUB2 did not prompt you for a password. This update fixes the problem by setting the path for user.cfg to /boot/grub2/ in the source code. When you reboot the OS on a UEFI Secure Boot managed node to modify any boot loader entry, GRUB2 prompts you to input your password.

Removing Quadlet-defined networks using podman works irrespective of a custom NetworkName directive

When removing networks, the podman RHEL system role was using the "systemd- + name of the Quadlet file" syntax for the network name. Consequently, if the Quadlet file had a different NetworkName directive in it, the removal would fail. With this update, the podman source code has been updated to use "the Quadlet file name + the NetworkName directive from that file" as a name of the network to remove. As a result, removal of networks defined by Quadlet files using the podman RHEL system role works both with and without a custom NetworkName directive in the Quadlet file.

The podman RHEL system role creates new secrets if necessary

The podman RHEL system role incorrectly did not check whether a secret with the same name already existed if you used the skip_existing: true option of the podman_secrets role variable. Consequently, the role did not create any new secret if using that option. This update fixes the podman RHEL system role to check for existing secrets if you use skip_existing: true. As a result, the role properly creates new secrets if they do not exist. Conversely, it does not create a secret of the same name if you use skip_existing: true.

The network units in the Quadlet unit files are now properly cleaned up

The podman RHEL system role was not correctly managing the network units defined under the [Network] section in the Quadlet unit files. Consequently, the network units were not stopped and disabled and subsequent runs would fail due to those units not being cleaned up properly. With this update, podman manages the [Network] units, including stopping and removing. As a result, the [Network] units in the Quadlet unit files are properly cleaned up.

The podman RHEL system role now correctly searches for subgid values

Subordinate group IDs (subgid) is a range of group ID values assigned to non-root users. By using these values, you can run processes with different group IDs inside a container compared to the host system. Before this update, the podman RHEL system role was incorrectly searching in the subgid values using the group name instead of using the user name. Consequently, the difference between the user name and the group name made podman fail to look up the subgid values. This update fixes podman to correctly search for subgid values and the problem no longer appears in this scenario.

The certificate RHEL system role correctly reports an error when an issued certificate is missing the private key

When the private key of a certificate was removed, the certmonger utility on a managed node entered an infinite loop. Consequently, the certificate RHEL system role on the control node became unresponsive when re-issuing a certificate that had the private key deleted. With this update, the certificate RHEL system role stops processing and provides an error message with instructions for remedy. As a result, certificate no longer becomes unresponsive in the described scenario.

The firewall RHEL system role reports changed: True when there were changes applied

During playbook processing, the firewall_lib.py module from the firewall RHEL system role was replacing the changed message with False when using the interface variable in the playbook and a pre-existing networking interface on the managed node. As a consequence, firewall reported the changed: False message even when there had been changes done, and the contents from the forward_port variable were not saved as permanent. With this update, the firewall RHEL system role ensures the changed value is not reset to False. As a result, the role reports changed: True when there are changes, and forward_port contents are saved as persistent.

The podman RHEL system role no longer fails to process secrets when using the run_as_user variable

Before this update, the podman RHEL system role failed to process secrets that were specified for a particular user using the run_as_user variable due to missing user information. This caused errors when attempting to process secrets which have run_as_user set. The issue has been fixed, and the podman RHEL system role correctly handles secrets which are specified for a particular user using the run_as_user variable.

The cockpit RHEL system role installs all cockpit-related packages that match a wildcard pattern

Before this update, the dnf module used through the cockpit RHEL system role did not install all cockpit-related packages. As a consequence, some requested packages were not installed. With this update, the source code of the cockpit RHEL system role was changed to use the dnf module directly with an asterisk wildcard package name and a list of packages to exclude. As a result, the role correctly installs all requested packages that match the wildcard pattern.

The sshd RHEL system role can configure the second sshd service correctly

Running the sshd RHEL system role to configure the second sshd service on your managed nodes caused an error if you did not specify the sshd_config_file role variable. Consequently, your playbook would fail and the sshd service would not be configured correctly. To fix the problem, deriving of the main configuration file has been improved. Also, the documentation resources in the /usr/share/doc/rhel-system-roles/sshd/ directory have been made clearer to avoid this problem. As a result, configuring the second sshd service as described in the above scenario works as expected.

The network RHEL system role prioritizes permanent MAC address matching

When all of the following conditions were met:

The new sshd_allow_restart variable enables the sshd service to be restarted when needed

Before this update, the sshd RHEL system role was not restarting the sshd service on a managed node when required. As a consequence, some changes related to configuration files from the`/etc/sysconfig/` directory and environment files were not applied. To fix the problem, the sshd_allow_restart (boolean, defaults to true) variable has been introduced to restart the sshd service on the managed node when necessary. As a result, the sshd RHEL system role now correctly applies all changes and ensures the sshd service actually uses those changes.

The ansible-doc command provides the documentation again for the redhat.rhel_system_roles collection

Before this update, the vpn RHEL system role did not include documentation for the internal Ansible filter vpn_ipaddr. Consequently, using the ansible-doc command to list documentation for the redhat.rhel_system_roles collection would trigger an error. With this update the vpn RHEL system role includes the correct documentation in the correct format for the vpn_ipaddr filter. As a result, ansible-doc does not trigger any error and provides the correct documentation.

The storage RHEL system role correctly resizes logical volumes

The physical volume was not resized to its maximum size when using the grow_to_fill feature in the storage RHEL system role to automatically resize LVM physical volumes after resizing the underlying virtual disks. Consequently, not all of the storage free space was available when resizing existing or creating new additional logical volumes; and the storage RHEL system role failed. This update fixes the problem in the source code to ensure the role always resizes the physical volumes to their maximum size when using grow_to_fill.

The storage RHEL system role now runs as expected on RHEL 10 managed nodes with VDO

Before this update, the blivet module required the kmod-kvdo package on RHEL 10 managed nodes using Virtual Data Optimizer (VDO). However, kmod-kvdo failed to install, and as a consequence caused even the storage RHEL system role to fail. The fix to this problem ensures that kmod-kvdo is not a required package for managed nodes with RHEL 10. As a result, storage no longer fails when managed nodes with RHEL 10 use VDO.

vGPU live migration no longer reports excessive amount of dirty pages

Previously, when performing virtual machine (VM) live migration with an attached NVIDIA vGPU, an excessive amount of dirty pages could have been incorrectly reported during the migration. This problem could have increased the required VM downtime during the migration and the migration could have potentially failed.

QEMU no longer prevents using SEV-SNP

Previously, when attempting to start a virtual machine (VM) with AMD SEV-SNP enabled, QEMU checked the incorrect capability of KVM, and the guest failed to start. As a consequence, running VMs with AMD SEV-SNP configured was not possible with RHEL10. This problem has been fixed, and running VMs with SEV-SNP works as expected now.

Network boot for VMs now works correctly without an RNG device

Previously, when a virtual machine (VM) did not have an RNG device configured and its CPU model did not support the RDRAND feature, it was not possible to boot the VM from the network. With this update, the problem has been fixed, and VMs that do not support RDRAND can boot from the network even without an RNG device configured.

RHEL 10 guests no longer crash on restart in GCP and Alibaba

When using a RHEL 10.0 instance on Google Cloud Platform or the Alibaba Cloud, restarting the instance previously caused a kernel panic in the guest operating system if the virtio-net driver was in use. This issue has been fixed and RHEL 10 guests no longer crash in the described scenario.

The mana driver with Azure Accelerated Networking assigns a correct IP address to a VM

Previously, when launching a Red Hat Enterprise Linux VM on the Azure platform with Accelerated Networking enabled, the NetworkManager-wait-online.service service might failed to start on boot. Consequently, the VM might failed to acquire IP address from a DHCP server when using Azure Accelerated Networking with the mana driver. With this fix, you need to install the latest version of the WALinuxAgent-udev package. As a result, Azure VMs with Accelerated Networking along with the mana driver will be assigned with a correct IP address at boot time.

The sos now obfuscates proxy passwords in several places

Previously, the sos utility did not obfuscate passwords from proxy links. For example HTTP_PROXY and HTTPS_PROXY in the /etc/environment file. As a consequence, the sos utility could collect sosreports with customer proxy passwords unless cleaned up before submitting. This may pose a security concern. Several of those places were discovered and fixed to obfuscate the passwords.

The sos clean on an existing archive no longer fails

Previously, an existing archive could not be cleaned by running sos clean due to a regression in the sos code that incorrectly detected the root directory of a tarball and prevented it from cleaning data. As a consequence, sos clean running on an existing sosreport tarball does not clean anything within the tarball. This update adds an implementation of a proper detection of the root directory in the reordered tarball content. As a result, sos clean performs sensitive data obfuscation on an existing sosreport tarball correctly.

The sos stops collecting user’s .ssh configuration

Previously, the sos utility collected the .ssh configuration by default from a user. As a consequence, this action caused a broken system for users that are mounted by using automount utility. With this update, the sos utility no longer collects the .ssh configuration.

Netavark no longer fails resolving DNS TCP queries

Previously, when you ran a container in a Podman network, some domain names would not resolve even though they worked on the host system or in a container not using the Podman network. With this update, Netavark supports TCP DNS queries and the problem is fixed.