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 がパスワードを正しく要求する

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

imuxsock 入力タイプの name パラメーターを設定できない

以前は、logging RHEL システムロールによって、imuxsock 入力タイプの名前パラメーターが誤って設定されていました。その結果、この入力タイプは name パラメーターをサポートしておらず、マネージドノード上の rsyslog ユーティリティーは、…​parameter 'name' not known — typo in config file?…​ というエラーを出力しました。この更新により、logging RHEL システムロールが修正され、name パラメーターが imuxsock 入力タイプに関連付けられなくなります。

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

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

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

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

storage RHEL システムロールが再びべき等性を持つようになる

storage 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 を使用すると、同じ名前のシークレットは作成されません。

適切なユーザーに対しては、linger 機能をキャンセルできる

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

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

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

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

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

sshd RHEL システムロールが 2 番目の sshd サービスを正しく設定できる

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

bootloader RHEL システムロールが必要に応じて不足している /etc/default/grub 設定ファイルを生成する

以前は、bootloader 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 ファイルを実行できるようになりました。