11.13. Red Hat Enterprise Linux システムロール
複数のユーザーを指定しても、リソースが間違ったユーザーに関連付けられることがなくなりました
以前は、2 つの異なるユーザーのリソースを管理する場合、__podman_user 変数と __podman_user_home_dir 変数を設定するために、vars と set_fact の両方が使用されていました。これにより、最初のユーザーの古い値が、2 番目のユーザーに対して使用されていました。そのため、予期しない未定義の動作が発生し、2 番目のユーザーの設定が最初のユーザーのデータを誤って参照していました。
この修正により、ロールが set_fact のみを使用して podman_user 変数を設定し、vars のみを使用して __podman_user_home_dir 変数を設定するようになりました。また、ロールが vars を使用できる場合は、__podman_user ではなく __podman_handle_user を使用するようにコードがリファクタリングされました。その結果、複数のユーザーのデータが個別に保持され、設定の一貫性が確保されます。
postfix RHEL システムロールが、IPv6 インターフェイスが無効かどうかを自動検出します
デフォルトの postfix 設定は、inet_interfaces = localhost 設定を使用します。この設定は、IPv4 と IPv6 の両方のインターフェイスを含む、localhost に解決されるすべてのインターフェイスを待ち受けるよう postfix に指示します。この更新前は、ホスト上で IPv6 が無効になっていると問題が発生していました。その場合、postfix ロールと、postconf などのコマンドラインツールがエラーを返していました。また、ロール全体が失敗していました。このリリースでは、ロールによって IPv6 が無効かどうかが確認されます。無効な場合は、postfix が IPv4 インターフェイスのみを使用するように、ロールによって inet_protocols = ipv4 が設定されます。その結果、IPv6 が無効な場合でも postfix ロールが機能するようになりました。
selinux ロールが、Ansible チェックモードの未定義の tempdir パスに起因するエラーを生成しなくなりました
この更新前は、Ansible チェックモードで tempdir パスが定義されておらず、__selinux_item.path が未定義になることがありました。その結果、チェックモードの実行中、selinux RHEL システムロールで、さまざまな変数が未定義であるというエラーが発生していました。この更新により、tempdir.path を定義する必要があるタスクをロールがスキップするようになり、変数が未定義のケースを処理できるようになりました。その結果、ロールはチェックモードで正しく動作するようになりました。
rhel-system-roles の値を持つカーネルオプションの削除が改善されました
以前は、ユーザーがキーのみを指定した場合、key=value 形式で指定されたカーネルブートオプションを削除できず、不要なブートパラメーターが永続化され、カーネルオプションの名前による管理が一貫性を欠いた状態になっていました。この更新により、mod_boot_args 関数の正規表現が更新され、カーネルオプションと値を正しくマッチさせて削除するようになりました。また、正しい動作を確認するための自動テストが追加されました。
その結果、カーネルオプションは、key=value 形式で設定されている場合でも、名前によって確実に削除できるようになりました。これにより、正確な設定が確保され、システム管理が向上します。
ha_cluster RHEL システムロールが必要とする際に、/var/lib/pcsd ディレクトリーが利用可能であることが確認されます
この更新前は、pcs のインストール中に /var/lib/pcsd ディレクトリーが作成されていました。しかし、最近のバージョンでは、pcsd サービスの起動時に systemd サービスによってこのディレクトリーが作成されます。そのため、ロールがディレクトリーにアクセスしようとしたときにディレクトリーが存在しない場合があり、実行時にエラーが発生したり失敗したりすることがありました。
この更新により、ロールが /var/lib/pcsd ディレクトリーを使用する前に、そのディレクトリーが存在することを明示的に確認するようになりました。その結果、ディレクトリーの欠落による実行時の問題が防止され、ロール実行の信頼性が向上します。
Jira:RHEL-100819[1]
LVM RAID が暗号化されたデバイスとパーティションが設定されたデバイスをサポートするようになりました
この更新前は、LVM RAID のコードで、raid_disks に指定されたディスクがすべての LVM RAID 構成において PV の親デバイスであると想定されていました。この想定は、暗号化されたデバイスやパーティションが設定されたデバイスには当てはまりませんでした。その結果、暗号化された LUKS レイヤーによって追加のストレージレイヤーが追加されたとき、または親デバイスなしで直接パーティションが使用されたときにエラーが発生していました。このリリースでは、LVM RAID の PV の解決処理が改善され、暗号化されたデバイスとパーティションが設定されたデバイスがサポートされるようになりました。その結果、基礎となるディスクの代わりに PV パーティションを指定できるようになりました。
また、この修正により、見つからない、または無効な RAID ディスクエントリーに対するエラー処理も追加され、安定性を確保するための関連するテストも導入されています。
RAID が無効な設定やサポートされていない設定に対して明確なエラーを報告するようになりました
この更新前は、無効な RAID レベルや不十分なディスクを指定しても、明確なエラーが発生しませんでした。そのため、アレイの作成が失敗するか、作成の一貫性が失われていました。その結果、エラーメッセージが不明瞭になり、RAID セットアップの信頼性が低下していました。このリリースでは、アレイの作成前に RAID パラメーターが検証され、最小ディスク数が適用されます。その結果、明確なエラーが発生し、不十分なディスクで RAID を作成しようとすると、作成がブロックされます。
この修正により、非推奨の process_device_numbers ヘルパーも削除され、代わりに unify_raid_level が使用されるようになりました。さらに、RAID レベルが無効な場合やディスクが不十分な場合に対する障害テストも追加されました。
encryption_key がマスクされなくなりました
この更新前は、encryption_key パラメーターが誤って no_log とマークされていました。これにより、鍵ファイルのパスがプレースホルダー文字列に置き換えられ、ディスクの暗号化が機能しなくなっていました。この更新により、encryption_key パラメーターに no_log フラグが付かなくなり、鍵ファイルを使用してディスク暗号化を正常に実行できるようになりました。
selinux ロールがカーネルの SELinux パラメーターを永続的に設定します
この更新前は、selinux RHEL システムロールが、SELinux の状態を無効に、または無効から変更するときに、カーネル SELinux パラメーターを設定していませんでした。その結果、SELinux の状態の変更が再起動後も保持されませんでした。この更新により、ロールが SELinux の状態を無効に、または無効から変更するときに、カーネル SELinux パラメーターが正しく設定されるようになりました。そのため、SELinux の状態を無効に、または無効から変更した場合に、変更が再起動後も維持されます。
systemd ロールが宛先へのパスを作成する際にファイルのベース名を使用します
この更新前は、ユーザーがネストされたディレクトリー内のファイルまたはテンプレートソースを指定すると、systemd RHEL システムロールが、宛先ファイルのベース名ではなく、パス全体を使用していました。その結果、ファイルとテンプレートが同じディレクトリー構造で宛先に配置されていました。しかし、この配置方法は systemd によってサポートされていません。このリリースでは、ロールはネストされたディレクトリー内の宛先ファイルにベース名を使用します。その結果、ユーザーはロールを使用してネストされたディレクトリーを使用できるようになりました。
Jira:RHEL-88774[1]
timesync RHEL システムロールが、/etc/sysconfig/chronyd からデフォルト設定 OPTIONS="-F 2" を削除しなくなりました
この更新前は、timesync システムロールによって、chronyd サービスのデフォルトの OPTIONS= 設定が "" に置き換えられていました。その結果、デフォルトの OPTIONS="-F 2" 設定が削除され、chronyd のセキュリティーが低下していました。このリリースでは、OPTIONS のデフォルト設定として -F 2 が追加され、ユーザーがこの設定をオーバーライドまたは拡張できるようになりました。その結果、timesync ロールは、ユーザーによるカスタマイズを許可しながら、正しいセキュリティー設定を適用するようになりました。
network RHEL システムロールのルーティングルールの検証が正しくないことによるエラーが表示されなくなりました
この更新前は、network RHEL システムロールの検証部分で、NM.IPRoutingRule クラスではなく、最上位の NM モジュールでルーティングルール属性が誤ってチェックされていました。これにより検証が失敗し、ロールにエラーが表示されていました。この更新により、ロールが API を正しく使用するようになり、誤った検証エラーが表示されなくなりました。
Jira:RHEL-88286[1]
network RHEL システムロールが、より堅牢なインターフェイス識別方法を使用するようになりました
この更新前は、ネットワークインターフェイスにインターフェイス名と MAC アドレスの両方が指定されている場合、検証プロセスでインターフェイス名を使用した検索と MAC アドレスを使用した検索の 2 つの個別の検索が実行されていました。そのため、検証が失敗することがありました。MAC アドレスによる検索は、永続的なハードウェア MAC アドレスではなく、インターフェイスの現在の MAC アドレスとマッチする可能性があるためです。
この更新により、検証ロジックが改善されました。network ロールは、ネットワークデバイスを検索する際に、インターフェイス名だけを識別子として使用します。その後、そのインターフェイスに関連付けられた MAC アドレスを取得し、検証のためにユーザーが指定した MAC アドレスと比較します。この方式により、信頼性が向上します。インターフェイス名は一意のカーネル識別子であり、一時的な MAC アドレスの変更による不一致を防ぐことができるためです。
Jira:RHEL-88263[1]
証明書の変更後、qdevice デーモンが自動的に再起動するようになりました
以前は、クォーラムデバイスデーモン (qnetd) とクラスターノード (qdevice) 間の通信に使用される TLS 証明書を更新した後、qdevice デーモンが自動的に再起動しませんでした。デーモンは古い証明書を引き続き使用するため、クォーラムデバイスとの通信が失敗していました。
この更新により、証明書が変更された後、クラスターノード上の qdevice デーモンが自動的に再起動するようになりました。これにより、新しい証明書がすぐに読み込まれ、クォーラムデバイスとの通信が維持されます。
ブール値が TOML ファイルで正しくレンダリングされます
この更新前は、TOML ファイル内のブール値の形式が間違っていたため、ブールオプションが適切に処理されませんでした。その結果、設定上の問題がユーザーに発生していました。このリリースでは、TOML ファイル内のブールオプションの形式が修正されました。その結果、エンドユーザーが TOML ファイルでブールオプションを正しく設定できるようになりました。
Jira:RHEL-85704[1]
ブール値が TOML ファイルで正しくレンダリングされます
この更新前は、Jinja2 テンプレートのブール値変換が正しくなかったため、True が "True" と書き込まれていました。その結果、設定ファイルの形式が正しくないことによるエラーがユーザーに表示され、コンテナーサービスの障害が発生していました。このリリースでは、Jinja2 テンプレートでの不適切なブール値変換が修正されました。その結果、Podman 設定が Jinja2 テンプレート内のブール値を正しく変換するようになりました。
Jira:RHEL-84942[1]
podman RHEL システムロールが、リソースを削除するときに UNREACHABLE エラーで失敗しなくなりました
この更新前は、非 root ユーザーの linger を無効にすると、ユーザーの状態が closing に遷移するまで、システムが十分に待機していませんでした。その結果、systemd-logind サービスが早期に再起動され、linger 状態が強制的にキャンセルされていました。一部のシステムでは、これによりタイマーがトリガーされ、アクティブな sshd 接続を含む root セッションが終了していました。このため、Ansible Playbook が UNREACHABLE エラーで失敗していました。このリリースでは、linger が適切にキャンセルされるまでシステムが待機する時間が大幅に長くなり、systemd-logind は絶対に必要な場合にのみ再起動されます。その結果、リソースを削除するときにロールが UNREACHABLE エラーで失敗することはなくなりました。
Jira:RHEL-84912[1]
ha_cluster RHEL システムロールが、システム全体の HTTP プロキシーが設定されている場合に機能するようになりました
以前は、システム全体の HTTP プロキシーが設定されている場合、ha_cluster RHEL システムロールは、unix ソケットを介した pcsd デーモンとのローカル通信にプロキシーを誤って使用しようとしていました。これにより、ロールが失敗していました。
このリリースでは、pcsd とのローカル通信でプロキシーの使用を明示的に無効にするようにロールが変更されました。
その結果、システム全体の HTTP プロキシーが定義されているシステムで、ha_cluster RHEL システムロールが期待どおりに動作するようになりました。
GSSAPIIndicators が sshd ロールに追加されました
Generic Security Services Application Programming Interface (GSS-API) を設定するための新しい設定オプション GSSAPIIndicators が RHEL 10 に追加されました。この更新により、GSSAPIIndicators 設定オプションが sshd RHEL システムロールに追加されます。その結果、RHEL システムロールを使用して RHEL 10 システムで GSSAPIIndicators を設定できるようになりました。
bootloader ロールがブール型または null 型の値を拒否します
この更新前は、ユーザーは value: on や value: yes などの値が文字列 "on" または "yes" に変換されることを想定して、値を指定することができました。ただし、YAML はこれらを YAML bool 型 として扱い、文字列 "True" として書き込みます。そのため、YAML ブール型の処理を知らないユーザーは、"on" や "off" などの値を設定できませんでした。この更新により、bootloader RHEL システムロールが、ブール型または null 型の値を拒否するようになりました。そのため、ユーザーは、このような YAML ブール型の値を、引用符で囲んだ文字列の形で入力し、ブートローダー設定に書き込む必要があります。また、この情報で Readme が更新されました。
sudo ロールがエイリアス値を解析する際にハングしなくなりました
この更新前は、Cmnd_Alias などのエイリアス値では等号 = の両側にスペースを入れる必要がないことが、sudo RHEL システムロールの正規表現で考慮されていませんでした。その結果、正規表現の処理が終了しなくなり、ロールがハングしたように見えていました。この更新により、sudoers ファイルの仕様にあるフィールドの eBNF 定義に正規表現が準拠していることをロールが確認するようになりました。その結果、= の前後にスペースがあってもなくても、エイリアス値が正しく解析されるようになりました。
Jira:RHEL-106261[1]
podman RHEL システムロールが、認証ファイルや設定ファイルの管理時に changed: true を報告しません
この更新前は、podman RHEL システムロールは、認証ファイルと設定ファイルの両方を管理する場合、実行のたびに親パスのモードを変更していました。これは、さまざまな設定ファイルと認証ファイルの共通の親パスに、2 つの異なるモードを使用していたためです。
この修正により、ロールは親パスに対して一貫したモードを使用するようになったため、不必要に changed: true を報告しなくなりました。
Jira:RHEL-84922[1]
systemd ロールが、1 回の実行でユニットをマスク解除して起動します
この更新前は、ユニットがマスクされている場合、systemd RHEL システムロールがサービスの有効化と起動に失敗していました。これは、ロールがユニットのマスクを先に解除できなかったためです。その結果、ユーザーはロールを 2 回実行する必要がありました。このリリースでは、systemd ロールがサービスを正しくマスク解除して起動するため、2 回実行する必要がなくなりました。
Jira:RHEL-88760[1]
ボリュームのわずかなサイズの不一致が、ロールによる誤った報告を引き起こすことがなくなりました
この更新前は、ボリュームを作成またはサイズ変更するときに、要求されたサイズと実際のサイズの間の差が最大 2% まで許容されていました。この調整は、ボリュームをプールの使用可能な空き領域に収めるためのものでした。その結果、ロールを再度実行したときにサイズが一致せず、ロールは何か変更があったと誤って想定していました。このリリースでは、サイズがわずかに違う場合に、変更があったと誤解されることがなくなりました。その結果、ロールが正しい状態を報告するようになりました。
Jira:RHEL-90216[1]