Chapter 8. Fixed issues

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.

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.

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 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.

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.

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.

No property conflicts between the NetworkManager service and the NetworkManager plugin

Previously, 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 bootloader RHEL system role generates the missing /etc/default/grub configuration file if necessary

Previously, 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

Previously, 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

Previously, 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

Previously, 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 Beta and RHEL 9 UEFI managed nodes correctly prompts for a password

Previously, 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 Beta 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. Previously, 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 cockpit RHEL system role installs all cockpit-related packages that match a wildcard pattern

Previously, 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 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.