11.12. Red Hat Enterprise Linux 系统角色

NetworkManager 服务和 NetworkManager 插件之间没有属性冲突

在此更新之前，当网络软件包有更新时，特别是由于无线接口更改了，network RHEL 系统角色不会请求用户同意重新启动 NetworkManager 服务。因此，这导致 NetworkManager 服务和 NetworkManager 插件之间潜在的冲突。或者，NetworkManager 插件无法正确运行。这个问题已通过让 network RHEL 系统角色要求用户同意重启 NetworkManager 服务而得到了解决。因此，在上述场景中，NetworkManager 服务和 NetworkManager 插件之间没有属性冲突。

现在，实施多组节点属性的键值对与其他集群配置组件保持一致

ha_cluster RHEL 系统角色只支持每个配置项一组键值对。在以前的版本中，当配置多个节点属性集合时，集合被合并成一个集合。有了此更新，该角色只使用您定义的第一个集合，而忽略其他集合。现在，这个行为与角色为使用键值对结构的其他配置组件如何实现多组键值对保持一致。

postgresql RHEL 系统角色不再无法设置 TLS 证书和私钥的路径

postgresql RHEL 系统角色的 postgresql_cert_name 变量在受管节点上定义没有后缀的 TLS 证书和私钥的基本路径。在此更新之前，角色没有为证书和私钥定义内部变量。因此，如果您设置了 postgresql_cert_name，Ansible 任务会失败，并显示以下错误消息：

如果需要，bootloader RHEL 系统角色会生成缺失的 /etc/default/grub 配置文件

在此更新之前，bootloader RHEL 系统角色预计 /etc/default/grub 配置文件存在。在某些情况下，例如在 OSTtree 系统上，可能会缺失 /etc/default/grub。因此，角色意外失败。有了此更新，如果需要，角色会使用默认参数生成缺失的文件。

podman RHEL 系统角色可以再次设置主机目录的所有权

在此更新之前，在设置主机目录的所有权时，podman RHEL 系统角色将 become 关键字与用户一起使用。因此，角色无法正确设置所有权。有了此更新，podman RHEL 系统角色不会将 become 与普通用户一起使用。相反，它使用 root 用户。因此，podman 可以设置主机目录的所有权。

可以对正确的用户取消 linger 功能

当处理 kube 文件或 Quadlet 文件中的配置项的说明列表时，podman RHEL 系统角色错误地使用了与整个列表关联的用户 ID。它没有使用与列表项目关联的用户 ID ，来编译 linger 文件名。因此，没有创建 linger 文件，因此 podman RHEL 系统角色无法取消实际用户的 linger 功能（如果需要的话）。有了此更新，podman 使用正确的用户名来构造 linger 文件名。因此，可以对正确的用户取消 linger 功能。

storage RHEL 系统角色再次是幂等的

在某些情况下，storage RHEL 系统角色会错误地计算现有设备的大小。因此，再次运行没有更改的同一 playbook 导致角色尝试调整已经有正确大小的设备的大小，而不是无错误地通过。有了此更新，大小计算已被修复。因此，角色现在可以正确地识别设备已有 playbook 指定的大小，且不会尝试调整它的大小。

在具有预先存在的 Stratis 池的系统上运行 storage RHEL 系统角色可以正常工作

在此更新之前，storage RHEL 系统角色不会处理现有的设备和设备格式。当检查 Stratis 格式是否符合 playbook 指定的配置时，这导致角色在具有预先存在的 Stratis 池的系统上失败。因此，playbook 失败并显示一个错误，但 Stratis 池本身没有损坏或更改。此更新使 storage RHEL 系统角色可以与 Stratis 设备和其他格式正常工作，而无需标记支持。因此，在具有预先存在的 Stratis 池的系统上运行 playbook 不再失败。

您不能为 imuxsock 输入类型设置 name 参数

在此更新之前，logging RHEL 系统角色错误地为 imuxsock 输入类型设置了 name 参数。因此，这个输入类型不支持 name 参数，受管节点上的 rsyslog 工具会打印此错误 …​parameter 'name' not known — typo in config file?…​。这个更新修复了 logging RHEL 系统角色，来确保 name 参数没有与 imuxsock 输入类型关联。

RHEL 10 和 RHEL 9 UEFI 受管节点上的 GRUB2 正确地提示输入密码

在此更新之前，bootloader RHEL 系统角色错误地将密码信息放在运行带有 UEFI 安全引导功能的 RHEL 10 和 RHEL 9 的受管节点上的 /boot/efi/EFI/redhat/user.cfg 文件中。正确的位置是 /boot/grub2/user.cfg 文件。因此，当重启受管节点来修改任何引导装载程序条目时，GRUB2 不提示您输入密码。此更新通过在源代码中将 user.cfg 的路径设置为 /boot/grub2/ 解决了这个问题。当您在 UEFI 安全引导受管节点上重新引导操作系统以修改任何引导装载程序条目时，GRUB2 会提示您输入您的密码。

使用 podman 删除 Quadlet 定义网络可以正常工作，无论自定义 NetworkName 指令如何

删除网络时，podman RHEL 系统角色对网络名称使用 "systemd- + name of the Quadlet file" 语法。因此，如果 Quadlet 文件中存在不同的 NetworkName 指令，则删除将失败。有了此更新，podman 源代码已被更新，以使用 "Qadlet 文件名 +该文件中的 NetworkName 指令"作为要删除的网络的名称。因此，使用 podman RHEL 系统角色删除 Quadlet 文件定义的网络可以和没有 Quadlet 文件中的自定义 NetworkName 指令一起工作。

如果需要，podman RHEL 系统角色会创建新的 secret

如果您使用 podman_secrets 角色变量的 skip_existing: true 选项，则 podman RHEL 系统角色会错误地检查具有相同名称的 secret 是否已存在。因此，如果使用该选项，角色不会创建任何新 secret。此更新修复了 podman RHEL 系统角色，以在使用 skip_existing: true 时检查现有的 secret。因此，如果 secret 不存在，角色会正确地创建新的 secret。相反，如果您使用 skip_existing: true，则不会创建同名的 secret。

Quadlet 单元文件中的网络单元现在可以被正确地清理

podman RHEL 系统角色不能正确管理 Quadlet 单元文件中 [Network] 部分下定义的网络单元。因此，网络单元不会被停止和禁用，后续运行因为这些单元没有被正确清理而失败。有了此更新，podman 管理 [Network] 单元，包括停止和删除。因此，Qadlet 单元文件中的 [Network] 单元被正确地清理。

podman RHEL 系统角色现在可以正确地搜索 subgid 值

从属组 ID (subgid)是一个分配给非 root 用户的组 ID 值的范围。通过使用这些值，您可以在容器中使用与主机系统不同的组 ID 运行进程。在此次更新之前，podman RHEL 系统角色使用组名称而不是使用用户名在 subgid 值中错误地搜索。因此，用户名和组名称之间的区别使 podman 无法查找 subgid 值。此更新修复了 podman ，以便正确地搜索 subgid 值，在这种情况下问题不再发生。

当签发的证书缺少私钥时，certificate RHEL 系统角色可以正确地报告错误

删除证书的私钥时，受管节点上的 certmonger 工具进入死循环。因此，当重新暂停已删除了私钥的证书时，控制节点上的 certificate RHEL 系统角色变得无响应。有了此更新，certificate RHEL 系统角色停止处理，并提供一条带有补救指令的错误消息。因此，在上述场景中，certificate 不再变得无响应。

在有更改被应用时，firewall RHEL 系统角色报告 changed: True

在 playbook 处理过程中，当在受管节点上使用 playbook 中的 interface 变量和预先存在的网络接口时，firewall RHEL 系统角色中的 firewall_lib.py 模块会使用 False 替换 changed 消息。因此，即使已完成了更改，firewall 也会报告 changed: False 消息，并且 forward_port 变量中的内容没有被保存为永久。有了此更新，firewall RHEL 系统角色确保 changed 的值没有被重置为 False。因此，当有更改时，角色会报告 changed: True，forward_port 内容会被保存为持久的。

在使用 run_as_user 变量时，podman RHEL 系统角色不再无法处理 secret

在此更新之前，podman RHEL 系统角色因为缺少用户信息，无法处理使用 run_as_user 变量为特定用户指定的 secret。这导致在尝试处理设置了 run_as_user 的 secret 时出现错误。这个问题已被解决，podman RHEL 系统角色可以正确地处理使用 run_as_user 变量为特定用户指定的 secret。

cockpit RHEL 系统角色安装所有与通配符模式匹配的与 cockpit 相关的软件包

在此更新之前，通过 cockpit RHEL 系统角色使用的 dnf 模块没有安装所有与 cockpit 相关的软件包。因此，一些请求的软件包没有被安装。有了此更新，cockpit RHEL 系统角色的源代码被修改为使用带有星号通配符的软件包名称和要排除的软件包的列表来直接使用 dnf 模块。因此，角色可以正确地安装与通配符模式匹配的所有请求的软件包。

sshd RHEL 系统角色可以正确地配置第二个 sshd 服务

如果您没有指定 sshd_config_file 角色变量，则运行 sshd RHEL 系统角色来在受管节点上配置第二个 sshd 服务会导致一个错误。因此，您的 playbook 将失败，并且 sshd 服务无法被正确配置。要解决这个问题，主配置文件的派生已得到了改进。另外，以使 /usr/share/doc/rhel-system-roles/sshd/ 目录中的文档资源更加清晰，以避免此问题。因此，按上述场景中所述配置第二个 sshd 服务可以按预期工作。

network RHEL 系统角色优先考虑永久 MAC 地址匹配

当以下所有条件都满足时：

新的 sshd_allow_restart 变量使 sshd 服务在需要时重启

在此更新之前，sshd RHEL 系统角色在需要不能在受管节点上重启 sshd 服务。因此，一些与 '/etc/sysconfig/' 目录中的配置文件和环境文件相关的更改没有被应用。要解决这个问题，引入了 sshd_allow_restart（布尔值，默认为 true）变量，来在需要时在受管节点上重启 sshd 服务。因此，sshd RHEL 系统角色现在可以正确地应用所有更改，并确保 sshd 服务实际使用这些更改。

ansible-doc 命令再次为 redhat.rhel_system_roles 集合提供了文档

在此更新之前，vpn RHEL 系统角色不包括内部 Ansible 过滤器 vpn_ipaddr 的文档。因此，使用 ansible-doc 命令列出 redhat.rhel_system_roles 集合的文档将触发一个错误。有了此更新，vpn RHEL 系统角色包括 vpn_ipaddr 过滤器的正确格式的正确文档。因此，ansible-doc 不会触发任何错误，并提供了正确的文档。

storage RHEL 系统角色可以正确地重新调整逻辑卷大小

当使用 storage RHEL 系统角色中的 grow_to_fill 功能，在调整底层虚拟磁盘的大小后自动调整 LVM 物理卷大小时，物理卷不会被调整到其最大大小。因此，在调整现有逻辑卷大小或者创建新额外的逻辑卷时，并不是所有的存储可用空间都可用；storage RHEL 系统角色会失败。此更新修复了源代码中的问题，来确保角色始终可以使用 grow_to_fill 将物理卷调整到其最大大小。

storage RHEL 系统角色现在在带有 VDO 的 RHEL 10 受管节点上按预期运行

在此次更新之前，blivet 模块需要使用 Virtual Data Optimizer (VDO)在 RHEL 10 受管节点上需要 kmod-kvdo 软件包。但是，kmod-kvdo 无法安装，因此甚至导致 storage RHEL 系统角色失败。对这个问题的修复确保 kmod-kvdo 不是 RHEL 10 受管节点所需的软件包。因此，当带有 RHEL 10 受管节点使用 VDO 时，storage 角色不再失败。