6.13. Red Hat Enterprise Linux システムロール

ノード属性の鍵と値のペアの複数セットの実装が、他のクラスター設定コンポーネントと一致するようになりました

ha_cluster RHEL システムロールは、各設定項目の鍵と値のペアを 1 つだけサポートします。以前は、ノード属性のセットを複数設定すると、それらのセットが 1 セットにマージされていました。この更新により、ロールは定義した最初のセットのみを使用し、他のセットは無視するようになりました。この動作は、鍵と値のペア構造を使用する他の設定コンポーネントに対して、ロールが鍵と値のペアのセットを複数実装する方法と一致するようになりました。

NetworkManager サービスと NetworkManager プラグイン間のプロパティーの競合が発生しなくなる

以前は、特にワイヤレスインターフェイスの変更によりネットワークパッケージの更新が利用可能になったときに、NetworkManager サービスを再起動するためのユーザーの同意が network RHEL システムロールによって要求されませんでした。その結果、NetworkManager サービスと NetworkManager プラグインの間で競合が発生する可能性がありました。または、NetworkManager プラグインが正しく実行されませんでした。この問題は、NetworkManager サービスの再起動にユーザーが同意するかどうかを network RHEL システムロールに確認させることで修正されました。その結果、前述の状況で、NetworkManager サービスと NetworkManager プラグインの間にプロパティーの競合が発生しなくなりました。

RHEL 9 および RHEL 10 ベータ版 UEFI 管理ノード上の GRUB2 は、パスワードを正しく要求します。

以前は、UEFI セキュアブート機能を使用して RHEL 9 を実行する管理対象ノード上の /boot/efi/EFI/redhat/user.cfg ファイルに、bootloader RHEL システムロールによってパスワード情報が誤って配置されていました。正しい場所は /boot/grub2/user.cfg ファイルでした。その結果、管理対象ノードを再起動してブートローダーエントリーを変更したときに、GRUB2 がパスワードの入力を要求しませんでした。この更新により、ソースコード内で user.cfg のパスを /boot/grub2/ に設定することで問題が修正されました。UEFI セキュアブート管理対象ノードで OS を再起動してブートローダーエントリーを変更したときに、GRUB2 によってパスワードの入力が求められます。

imuxsock 入力タイプの 名前 パラメーターを設定することはできません

以前は、ログ記録 RHEL システムロールによって、imuxsock 入力タイプの名前パラメーターが誤って設定されていました。その結果、この入力タイプは name パラメーターをサポートしておらず、管理対象ノード上の rsyslog ユーティリティーは、次のエラーを出力しました …パラメーター 'name' が不明です - 設定ファイルにタイプミスがありますか?…。この更新により、RHEL システムロール のログ記録 が修正され、name パラメーターが imuxsock 入力タイプに関連付けられなくなります。

既存の Stratis プールを持つシステムで ストレージ RHEL システムロールを実行すると、期待どおりに動作します。

以前は、ストレージ RHEL システムロールは既存のデバイスとデバイスフォーマットを処理できませんでした。これにより、Stratis 形式が Playbook で指定された設定に準拠しているかどうかを確認するときに、既存の Stratis プールを持つシステムでロールが失敗しました。その結果、Playbook はエラーで失敗しましたが、Stratis プール自体は破損したり変更されたりしませんでした。この更新により、ストレージ RHEL システムロールが、ラベル付けをサポートしていない Stratis デバイスやその他の形式でも正しく動作するようになります。その結果、既存の Stratis プールを持つシステムで Playbook を実行しても失敗しなくなりました。

podman を使用して Quadlet 定義ネットワークを削除すると、カスタム NetworkName ディレクティブに関係なく機能します。

ネットワークを削除するときに、podman RHEL システムロールは、ネットワーク名に systemd- + Quadlet ファイルの名前構文を使用していました。その結果、Quadlet ファイルに異なる NetworkName ディレクティブが含まれている場合、削除は失敗します。この更新により、podman ソースコードが更新され、削除するネットワークの名前として Quadlet ファイル名 + そのファイルの NetworkName ディレクティブが使用されるようになりました。その結果、podman RHEL システムロールを使用して Quadlet ファイルで定義されたネットワークを削除することは、Quadlet ファイル内のカスタム NetworkName ディレクティブの有無にかかわらず機能します。

ストレージ RHEL システムロールは再びべき等性を持つ

ストレージ RHEL システムロールは、既存のデバイスのサイズを誤って計算する場合があります。その結果、同じ Playbook を変更せずに再度実行すると、ロールはエラーなしで通過するのではなく、すでに正しいサイズになっているデバイスのサイズ変更を試行するようになりました。この更新では、サイズの計算が修正されました。その結果、ロールはデバイスのサイズが Playbook で指定されているサイズにすでに設定されていることを正しく識別し、サイズを変更しなくなりました。

Quadlet ユニットファイル内のネットワークユニットが適切にクリーンアップされるようになりました

podman RHEL システムロールは、Quadlet ユニットファイルの [Network] セクションで定義されたネットワークユニットを正しく管理していませんでした。その結果、ネットワークユニットは停止および無効化されず、それらのユニットが適切にクリーンアップされないため、後続の実行は失敗します。この更新により、podman は 停止や削除など [Network] ユニットを管理するようになりました。その結果、Quadlet ユニットファイル内の [Network] ユニットが適切にクリーンアップされます。

podman RHEL システムロールは必要に応じて新しいシークレットを作成します

podman RHEL システムロールは、podman_secrets ロール変数の skip_existing: true オプションを使用した場合に、同じ名前のシークレットがすでに存在するかどうかを誤ってチェックしませんでした。その結果、そのオプションを使用した場合、ロールは新しいシークレットを作成しませんでした。この更新により、skip_existing: true を 使用する場合に既存のシークレットを確認するように podman RHEL システムロールが修正されます。その結果、ロールは、新しいシークレットが存在しない場合に適切に作成します。逆に、skip_existing: true を 使用すると、同じ名前のシークレットは作成されません。

適切なユーザーに対しては、リンガー機能をキャンセルできます

kube ファイルまたは Quadlet ファイルから設定項目の指示リストを処理するときに、podman RHEL システムロールはリスト全体に関連付けられたユーザー ID を誤って使用していました。リンガーファイル名をコンパイルするために、リスト項目に関連付けられたユーザー ID を使用しませんでした。その結果、linger ファイルが作成されなかったため、必要に応じて podman RHEL システムロールは実際のユーザーの linger 機能をキャンセルできませんでした。この更新により、podman は 正しいユーザー名を使用して linger ファイル名を作成します。その結果、適切なユーザーに対しては、残留機能をキャンセルできるようになります。

podman RHEL システムロールはホストディレクトリーの所有権を再度設定できます

以前は、podman RHEL システムロールは、ホストディレクトリーの所有権を設定するときに、ユーザーとともに become キーワードを使用していました。その結果、ロールは所有権を適切に設定できませんでした。この更新により、podman RHEL システムロールは、通常のユーザーでは become を使用しなくなります。代わりに、root ユーザーを使用します。その結果、podman は ホストディレクトリーの所有権を設定できます。

podman RHEL システムロールが subgid 値を正しく検索するようになる

従属グループ ID (subgid) は、非ルートユーザーに割り当てられるグループ ID 値の範囲です。これらの値を使用すると、ホストシステムと比較してコンテナー内で異なるグループ ID を持つプロセスを実行できます。以前は、podman RHEL システムロールは、ユーザー名ではなくグループ名を使用して サブギッド 値を誤って検索していました。その結果、ユーザー名とグループ名の違いにより、podman はサブギッド 値を検索できませんでした。この更新により、podman がサブギッド 値を正しく検索するように修正され、このシナリオで問題が発生しなくなります。

sshd RHEL システムロールは、2 番目の sshd サービスを正しく設定できます。

sshd RHEL システムロールを実行して管理対象ノード上の 2 番目の sshd サービスを設定すると、sshd_config_file ロール変数を指定しなかった場合、エラーが発生しました。その結果、Playbook は失敗し、sshd サービスが正しく設定されなくなります。この問題を解決するために、メイン設定ファイルの導出が改善されました。また、この問題を回避するために 、/usr/share/doc/rhel-system-roles/sshd/ ディレクトリー内のドキュメントリソースがより明確になりました。その結果、上記のシナリオで説明したように 2 番目の sshd サービスを設定すると、期待どおりに動作します。

ブートローダー RHEL システムロールは、必要に応じて不足している /etc/default/GRUB 設定ファイルを生成します。

以前は、ブートローダー RHEL システムロールでは、/etc/default/GRUB 設定ファイルが存在することが想定されていました。場合によっては、たとえば OSTtree システムでは、/etc/default/GRUB が 見つからないことがあります。その結果、そのロールは予期せず失敗しました。この更新により、ロールは必要に応じてデフォルトのパラメーターを使用して不足しているファイルを生成します。

Cockpit RHEL システムロールは、ワイルドカードパターンに一致するすべての Cockpit 関連パッケージをインストールします。

以前は、Cockpit RHEL システムロールを通じて使用される dnf モジュールは、Cockpit 関連のすべてのパッケージをインストールしませんでした。その結果、要求されたパッケージの一部はインストールされませんでした。この更新により、Cockpit RHEL システムロールのソースコードが変更され、アスタリスクワイルドカードパッケージ名と除外するパッケージのリストを使用して dnf モジュールを直接使用するようになりました。その結果、ロールはワイルドカードパターンに一致するすべての要求されたパッケージを正しくインストールします。

rhc_auth にアクティベーションキーが含まれている場合、rhc システムロールが登録済みシステムで失敗しなくなる

以前は、rhc_auth パラメーターで指定されたアクティベーションキーを使用して登録済みシステムで Playbook ファイルを実行すると、エラーが発生していました。この問題は解決されています。rhc_auth パラメーターにアクティベーションキーが提供されていても、すでに登録されているシステムで Playbook ファイルを実行できるようになりました。