8.14. Red Hat Enterprise Linux システムロール
SBD の delay-start 値が高い場合に、クラスターの起動がタイムアウトしなくなりました
以前は、ユーザーが ha_cluster システムロールを使用してクラスターで SBD フェンシングを設定し、delay-start オプションを 90 秒に近い値または 90 秒を超える値に設定すると、クラスターの起動がタイムアウトしていました。これは、デフォルトの systemd 起動タイムアウトが 90 秒であり、システムが SBD の起動遅延値より前にこの起動タイムアウトに達していたためです。この修正により、ha_cluster システムロールが、systemd の sbd.service 起動タイムアウトを、delay-start よりも高い値でオーバーライドするようになりました。これにより、delay-start オプションの値が高い場合でも、システムを正常に起動できるようになります。
Jira:RHEL-18026[1]
network ロールが、0.0.0.0/0 または ::/0 のルーティングルールを検証する
以前は、ルーティングルールで from: または to: 設定が 0.0.0.0/0 または ::/0 アドレスに設定されていた場合、network RHEL システムロールはルーティングルールを設定できず、設定を無効として拒否していました。この更新により、network ロールでは、ルーティングルールの検証で from: と to: に 0.0.0.0/0 と ::/0 が許可されるようになりました。その結果、ロールは検証エラーを発生させることなくルーティングルールを正常に設定します。
読み取りスケールクラスターの実行と mssql-server-ha のインストールに特定の変数が不要になる
以前は、mssql RHEL システムロールを使用して、特定の変数 (mssql_ha_virtual_ip、mssql_ha_login、mssql_ha_login_password、および mssql_ha_cluster_run_role) なしで読み取りスケールクラスターを設定すると、ロールは失敗し、“Variable not defined” というエラーメッセージが表示されました。ただし、これらの変数は読み取りスケールクラスターを実行するために必要ではありません。このロールは、読み取りスケールクラスターに必要のない mssql-server-ha のインストールも試みました。この修正により、これらの変数の要件は削除されました。その結果、読み取りスケールクラスターは、エラーメッセージなしで正常に実行されます。
kexec_crash_size ファイルがビジー状態のときでも、Kdump システムロールが正常に動作する
/sys/kernel/kexec_crash_size ファイルは、クラッシュカーネルメモリーに割り当てられたメモリーリージョンのサイズを提供します。
以前は、/sys/kernel/kexec_crash_size ファイルがビジー状態のときに Kdump システムロールが失敗していました。この更新により、システムロールはファイルが利用可能になるとファイルの読み取りを再試行します。その結果、ファイルがビジー状態のときにシステムロールが失敗しなくなりました。
selinux ロールが item ループ変数を使用しなくなりました
以前は、selinux RHEL システムロールは item ループ変数を使用していました。これにより、別のロールから selinux ロールを呼び出したときに、次の警告メッセージが表示される場合があります。
[WARNING]: TASK: fedora.linux_system_roles.selinux : Restore SELinux labels on filesystem tree: The loop variable 'item' is already in use. You should set the `loop_var` value in the `loop_control` option for the task to something else to avoid variable collisions and unexpected behavior.
このリリースでは、selinux ロールは __selinux_item をループ変数として使用します。その結果、別のロールから selinux ロールを呼び出しても、item 変数がすでに使用されているという警告が表示されなくなりました。
ha_cluster システムロールが qnetd ホスト上のファイアウォールを正しく設定するようになりました
以前は、ユーザーが qnetd ホストを設定し、ha_cluster システムロールを使用して ha_cluster_manage_firewall 変数を true に設定しても、そのロールによってファイアウォールの高可用性サービスが有効になりませんでした。この修正により、ha_cluster システムロールは qnetd ホスト上のファイアウォールを正しく設定するようになりました。
postgresql RHEL システムロールが、正しいバージョンの PostgreSQL をインストールするようになりました
以前は、RHEL マネージドノードで postgresql_version: "15" 変数を定義して postgresql RHEL システムロールを実行しようとすると、PostgreSQL バージョン 15 ではなくバージョン 13 がインストールされていました。このバグは修正され、postgresql ロールは変数に設定されたバージョンをインストールするようになりました。
keylime_server ロールが registrar サービスのステータスを正しく報告する
以前は、keylime_server ロール Playbook が誤った情報を提供すると、ロールは誤って開始が成功したと報告していました。この更新により、ロールは誤った情報が提供された場合に失敗を正しく報告するようになり、開いているポートを待機する際のタイムアウトが約 300 秒から約 30 秒に短縮されました。
podman RHEL システムロールが、ルートレスコンテナーに対して linger を適切に設定およびキャンセルできるようになりました
以前は、podman RHEL システムロールは、ルートレスコンテナーに対して linger を適切に設定およびキャンセルしていませんでした。その結果、ルートレスユーザーのシークレットまたはコンテナーをデプロイすると、場合によってはエラーが発生し、場合によってはリソースを削除するときに linger をキャンセルできませんでした。この更新により、podman RHEL システムロールは、シークレットまたはコンテナーリソースの管理を行う前にルートレスユーザーに対して linger が有効になっていることを確認するようになりました。また、管理するシークレットまたはコンテナーリソースがなくなったときにルートレスユーザーに対して linger をキャンセルするようになりました。その結果、このロールはルートレスユーザーの残留を正しく管理します。
nbde_server ロールがソケットオーバーライドで動作するようになる
以前は、nbde_server RHEL システムロールは、tangd ソケットオーバーライドディレクトリー内のファイルがカスタムポート用の override.conf ファイルだけであると想定していました。その結果、ポートのカスタマイズがないと、ロールは他のファイルをチェックせずにディレクトリーを削除し、システムはその後の実行でディレクトリーを再作成しました。
このリリースでは、ポートオーバーライドファイルの属性の変更や他のファイルがある場合のディレクトリーの削除を防止するためにロールが修正されました。その結果、tangd ソケットオーバーライドファイルがロールの外部でも管理されていると、ロールは正しく機能します。
ボリューム quadlet サービス名が失敗しなくなる
以前は、ボリュームサービス名を開始すると、"Could not find the requested service NAME.volume: host" のようなエラーが発生しました。この更新により、ボリューム quadlet サービス名が basename-volume.service に変更されました。その結果、ボリュームサービスはエラーなしで開始されます。
詳細は、ボリュームユニット の man ページを参照してください。
Ansible はシークレットで使用するために JSON 文字列を保存するようになる
以前は、値がループで使用され、data: "{{ value }}" に類似した文字列である場合、Ansible は JSON 文字列を対応する JSON オブジェクトに変換していました。その結果、JSON 文字列をシークレットとして渡して値を保持できませんでした。この更新により、podman_secret モジュールに渡すときに、データ値が文字列にキャストされます。その結果、JSON 文字列はシークレットで使用するためにそのまま保存されます。
rhc_auth にアクティベーションキーが含まれている場合、rhc システムロールが登録済みシステムで失敗しなくなる
以前は、rhc_auth パラメーターで指定されたアクティベーションキーを使用して登録済みシステムで Playbook ファイルを実行すると、エラーが発生していました。この問題は解決されています。rhc_auth パラメーターにアクティベーションキーが提供されていても、すでに登録されているシステムで Playbook ファイルを実行できるようになりました。
