5.4. バグ修正

カーネル起動パラメーター version または inst.version を指定しても、インストールプログラムが停止しなくなります。

以前では、version または inst.version のブートパラメーターを指定してカーネルコマンドラインからインストールプログラムを起動すると、バージョン (例: anaconda 30.25.6) が表示され、インストールプログラムが停止していました。

インストーラーにおける s390x のセキュアブートのサポート

以前は、RHEL 8.1 は、セキュアブートの使用を強制する IBM Z 環境で使用するためにブートディスクの準備をサポートしていました。インストール時に使用されるサーバーおよびハイパーバイザーの機能により、そのオンディスクフォーマットにセキュアブートのサポートが含まれるかを判断していました。インストール時にオンディスク形式に影響を与える方法はありませんでした。したがって、セキュアブートに対応している環境で RHEL 8.1 をインストールした場合、セキュアブートに対応していない環境に移行すると、一部のフェイルオーバーシナリオで起動したようにシステムを起動することはできませんでした。

セキュアブート機能が利用できるようになりました。

以前は、secure= ブートオプションのデフォルト値が auto に設定されていなかったため、セキュアブート機能が利用できませんでした。今回の更新で、事前設定されていない限り、デフォルト値が auto に設定され、セキュアブート機能が利用できるようになりました。

/etc/sysconfig/kernel ファイルが new-kernel-pkg スクリプトを参照しなくなりました。

以前は、/etc/sysconfig/kernel ファイルが new-kernel-pkg スクリプトを参照していました。ただし、 new-kernel-pkg スクリプトは RHEL 8 システムに含まれていません。今回の更新で、new-kernel-pkg スクリプトの参照が /etc/sysconfig/kernel ファイルから削除されました。

インストールで、許容される最大値を超える数のデバイスを boot-device NVRAM 変数に設定しません。

以前は、RHEL 8 のインストールプログラムが、許容される最大値を超える数のデバイスを boot-device NVRAM 変数に設定していました。これにより、デバイスが最大数を超えるシステムでインストールが失敗していました。今回の更新で、RHEL 8 インストールプログラムが、最大デバイス設定を確認し、許可された数のデバイスしか追加しないようになりました。

インストールが、ネットワーク上にないキックスタートファイルの URL コマンドで指定されたイメージの場所に対して機能します。

以前は、イメージのリモートの場所によってトリガーされるネットワークアクティベーションが、ネットワーク上にないキックスタートファイルの URL コマンドで指定されていた場合、インストールがプロセスの初期段階で失敗していました。今回の更新で問題が修正され、CD-ROM やローカルブロックデバイスなど、ネットワーク上にないキックスタートファイルの URL コマンドを使用してイメージの場所を提供するインストールが期待どおりに機能するようになりました。

RHEL 8 インストールプログラムは、未フォーマットのデバイスの ECKD DASD のみを確認します。

以前は、未フォーマットのデバイスを確認する際に、インストールプログラムがすべての DASD デバイスを確認していました。しかし、インストールプログラムが確認する必要があるのは、ECKD DASD デバイスのみでした。これにより、SWAPGEN のある FBA DASD デバイスが使用されると、インストールはトレースバックで失敗していました。今回の更新で、インストールプログラムが FBA DASD デバイスを確認しなくなり、インストールが正常に実行されるようになりました。

yum repolist が、利用できない最初のリポジトリーで終了しないようになりました。

以前は、リポジトリー設定オプション skip_if_unavailable はデフォルトで以下のように設定されていました。

ReaR が更新されました。

RHEL 8.2 では、ReaR (Relax-and-Recover) ユーティリティーに多くの更新が導入されました。

mlocate パッケージのインストール時に mlocate-updatedb.timer が有効化されるようになりました。

以前のバージョンでは、 mlocate パッケージのインストール後に mlocate-updatedb.timer が無効になるため、ファイルデータベースの再インデックスは自動的に実行されませんでした。今回の更新で、mlocate-updatedb.timer タイマーが 90-default.preset ファイルに含まれるようになり、mlocate パッケージのインストール後にデフォルトで有効になります。その結果、ファイルデータベースが自動的に更新されます。

dnsmasq が非再帰 DNS クエリーを正しく処理するようになりました。

以前は、dnsmasq は、非再帰クエリーをすべてアップストリームサーバーに転送し、その結果、さまざまな応答が発生していました。今回の更新で、DHCP ホストリース名や /etc/hosts ファイルから読み込まれたホストなど、ローカルで既知の名前に対する非再帰的クエリーが dnsmasq で処理されるようになり、アップストリームサーバーに転送されなくなりました。その結果、既知の名前への再帰クエリーと同じ応答が返されます。

dhclient が、システム時間の変更後に IP アドレスの更新に失敗しなくなりました。

以前は、システム時間を変更すると、カーネルによる削除の影響で、割り当てられた IP アドレスがシステムで失われる可能性がありました。今回の更新で、dhclient が巻き戻しジャンプ検出にモノトニックタイマーを使用し、システム時刻で連続しないジャンプがあった場合のリース拡張に DHCPREQUEST メッセージを発行するようになりました。その結果、上述のシナリオでシステムが IP アドレスを失わなくなりました。

ipcalc が、/31 ネットワークの正しいブロードキャストアドレスを返すようになりました。

今回の更新で、ipcalc ユーティリティーが正しく RFC 3021 規格に従うように修正されています。これにより、インターフェイスで /31 接頭辞を使用すると、ipcalc は正しいブロードキャストアドレスを返します。

/etc/services に適切な NRPE ポート定義が含まれるようになりました。

今回の更新で、適切な Nagios Remote Plug-in Executor (NRPE) サービスポート定義が /etc/services ファイルに追加されました。

postfix DNS リゾルバーコードは、res_query ではなく、res_search を使用するようになりました。

DNS リゾルバーコードは、postfix の前回の更新後、 res_search 関数ではなく、res_query 関数を使用していました。これにより、以下の postfix 設定を使用する場合は、DNS リゾルバーで、現在のドメインおよび親ドメインのホスト名が検索されませんでした。

Postfix で PCRE、CDB、および SQLite が使用できるようになりました。

RHEL 8 では、postfix パッケージは複数のサブパッケージに分けられており、各サブパッケージが特定のデータベースのプラグインを提供しています。以前は、postfix-pcre プラグイン、postfix-cdb プラグイン、postfix-sqlite プラグインを含む RPM パッケージは提供されていませんでした。したがって、Postfix では、これらのプラグインを使用するデータベースを使用できませんでした。今回の更新で、PCRE、CDB、および SQLite プラグインを含む RPM パッケージが AppStream リポジトリーに追加されました。そのため、適切な RPM パッケージのインストール後、これらのプラグインを使用できます。

fapolicyd が RHEL の更新を阻止しなくなりました。

更新で実行中のアプリケーションのバイナリーが置き換えられると、カーネルにより、接尾辞 " (deleted) が追加されて、メモリー内のアプリケーションのバイナリーパスが変更されます。以前のバージョンでは、fapolicyd ファイルアクセスポリシーデーモンは、信頼できないアプリケーションなどのように処理し、他のファイルを開き、実行できませんでした。そのため、更新の適用後にシステムを起動できないことがありました。

openssl-pkcs11 が、複数のデバイスへのログイン試行によるデバイスのロックをしなくなりました。

以前は、openssl-pkcs11 エンジンは、PKCS #11 URI が提供する最初の検索結果へのログインを試みていました。この際、最初の検索結果が目的のデバイスではなく、PIN が別のデバイスに適合するものだったとしても、提供された PIN を使用していました。これらの認証試行の失敗により、デバイスはロックされていました。

rpmverifyfile を使用する OpenSCAP オフラインスキャンが正常に動作するようになりました。

今回の更新以前は、OpenSCAP スキャナーは、オフラインモードで現在の作業ディレクトリーを正しく変更せず、fchdir 関数を、OpenSCAP rpmverifyfile プローブの正しい引数で呼び出していませんでした。OpenSCAP スキャナーが、オフラインモードで現在の作業ディレクトリーを正しく変更するように修正され、また、fchdir 関数が rpmverifyfile で正しい引数を使用するように修正されました。その結果、OVAL rpmverifyfile を含む SCAP コンテンツを、OpenSCAP で任意のファイルシステムのスキャンに使用できるようになりました。

PKCS #11 デバイスに保存された公開鍵とは一致しない ECDSA 秘密鍵を使用する場合でも、httpd が正常に起動するようになりました。

RSA 鍵とは異なり、ECDSA 秘密鍵には、公開鍵情報が含まれているとは限りません。この場合、ECDSA 秘密鍵から公開鍵を取得することはできません。このため、PKCS #11 デバイスは、公開鍵オブジェクトまたは証明書オブジェクトのいずれであっても、別のオブジェクトに公開鍵情報を格納します。OpenSSL は、秘密鍵に公開鍵情報を含めるために、エンジンが提供する EVP_PKEY 構造を想定していました。OpenSSL に提供する EVP_PKEY 構造を満たす場合、openssl-pkcs11 パッケージのエンジンは、一致する公開鍵オブジェクトのみから公開鍵情報を取得し、現在の証明書オブジェクトを無視していました。

Audit ルールの scap-security-guide PCI-DSS 修正が適切に動作するようになりました。

以前は、scap-security-guide パッケージには、修正の組み合わせと、以下のいずれかのシナリオで生じるチェックが含まれていました。

OpenSCAP が、仮想マシンおよびコンテナーのオフラインスキャンを提供するようになりました。

以前は、OpenSCAP のコードベースをリファクターリングすると、特定の RPM プローブがオフラインモードで仮想マシンおよびコンテナーのファイルシステムをスキャンするのに失敗していました。このため、次のツール (oscap-vm および oscap-chroot) を openscap-utils パッケージに含めることができませんでした。さらに、openscap-containers パッケージは、RHEL 8 から完全に削除されました。今回の更新で、プローブの問題が修正されました。

OpenSCAP rpmverifypackage が正常に動作するようになりました。

以前は、rpmverifypackage プローブにより、システムコール chdir および chroot が 2 回呼び出されていました。これにより、カスタムの OVAL (Open Vulnerability and Assessment Language) コンテンツを使用した OpenSCAP をスキャンする際にこのプルーブを使用していると、エラーが発生していました。rpmverifypackage プローブが、システムコール chdir および chroot を正常に使用するように修正されました。その結果、rpmverifypackage が正常に動作するようになりました。

qdisc_run 関数におけるロックによって、カーネルのクラッシュが発生しないようになりました。

以前は、pfifo_fast キュー規律がトラフィックのデキュー中にリセットされる場合の競合状態が、開放後のパケット転送につながっていました。これにより、カーネルが突然終了することがありました。今回の更新で、qdisc_run 関数のロックが改善されました。これにより、上述のシナリオでカーネルがクラッシュしなくなりました。

org.fedoraproject.FirewallD1.config.service の DBus API が期待どおりに動作するようになりました。

以前は、org.fedoraproject.FirewallD1 内の DBus API getIncludes、setIncludes、および queryIncludes 関数が、間違ったインデックスのために org.fedoraproject.FirewallD1.Exception: list index out of range というエラーメッセージを返していました。今回の更新で、DBus API 関数 getIncludes、setIncludes、および queryIncludes が期待どおりに動作するようになりました。

RHEL で、ipvs モジュールのアンロード時にカーネル警告をログに記録しなくなりました。

以前は、IP 仮想サーバー (ipvs) モジュールが誤った参照カウントを使用していたため、モジュールのアンロード時に競合状態が発生していました。これにより、RHEL がカーネル警告をログ記録していました。今回の更新で競合状態が修正されています。その結果、ipvs モジュールのアンロード時に、カーネルが警告をログ記録しなくなりました。

nft ユーティリティーが、最初のオプション以外の引数の後に、引数をコマンドラインオプションとして解釈することがなくなりました。

以前は、nft ユーティリティーは nft コマンド内のどの場所でもオプションを受け入れていました。たとえば、管理者はオプション以外の引数の間や、またはその後に、オプションを使用することができました。これにより、ダッシュ記号のために、nft は負の優先順位の値をオプションとして解釈し、コマンドに失敗していました。nft ユーティリティーのコマンドラインパーサーが、最初のオプション以外の引数を一度読み込んだ後は、ダッシュ記号で始まる引数を解釈しないよう更新されました。その結果、管理者が、負の優先順位の値を nft に渡すための回避策をとる必要がなくなりました。

/etc/hosts.allow および /etc/hosts.deny ファイルに、削除された tcp_wrappers への古い参照が含まれなくなりました。

以前では、/etc/hosts.allow ファイルおよび /etc/hosts.deny ファイルには tcp_wrappers パッケージに関する古い情報が含まれていました。これは、削除された tcp_wrappers に必要なくなったため、RHEL 8 ではファイルが削除されました。

ゾーンのドリフトを無効にする設定パラメーターを firewalld に追加されました

以前のリリースでは、firewalld サービスに、ゾーンのドリフトとして知られる、文書化されていない動作が含まれていました。RHEL 8.0 では、セキュリティーに悪影響を及ぼす可能性があるという理由から、この動作が削除されました。その結果、この動作を使用して汎用ゾーンまたはフォールバックゾーンを設定するホストでは、以前許可されていた接続を firewalld が拒否するようになりました。今回の更新で、ゾーンのドリフト動作が設定可能な機能として再度追加されました。これにより、ゾーンのドリフトを使用するか、動作を無効化してよりセキュアなファイアウォール設定を使用するかを、ユーザーが決定できるようになりました。

サブセクションのメモリーホットプラグが完全にサポートされるようになりました。

以前のリリースでは、デュアルインラインモジュール (DIMM) やインターリーブなど、調整された物理メモリー領域が 64MiB メモリー境界に設定されているものがありました。ただし、Linux ホットプラグサブシステムは 128MiB のメモリーサイズを使用するため、新しいデバイスをホットプラグすると、複数のメモリー領域が 1 つのホットプラグメモリーウィンドウに重なっていました。そのため、以下または同様の呼び出しトレースの、利用可能な永続メモリー名前空間をリスト表示できませんでした。

データの破損の場合、WARN メッセージではなく BUG がトリガーされるようになりました。

今回の機能強化により、lib/list_debug.c でリストが破損すると、BUG がトリガーされ、vmcore でレポートが生成されるようになりました。以前は、データの破損に遭遇すると、単純な WARN が生成されていましたが、これは見過ごされやすいものでした。CONFIG_BUG_ON_DATA_CORRUPTION を設定することで、カーネルがデータ破損に反応して、クラッシュを作成し、BUG をトリガーするようになりました。これにより、さらなる損傷が回避され、セキュリティーリスクが低減されます。kdump が vmcore を生成するようになり、データ破損のバグレポートが改善されました。

Intel Carlsville カードのサポートが追加されましたが、RHEL 8.2 で検証されていません。

Intel Carlsville カードのサポートを利用できるようになりましたが、Red Hat Enterprise Linux 8.2 でテストされていません。

RPS および XPS は、分離された CPU にジョブを配置しなくなりました

以前は、Receive Packet Steering (RPS) ソフトウェアキューメカニズムと Transmit Packet Steering (XPS) 送信キュー選択メカニズムが、分離された CPU を含むすべての CPU セットにジョブを割り当てていました。その結果、遅延の影響を受けやすいワークロードが RPS または XPS ジョブが実行されているのと同じ CPU を使用していた場合は、リアルタイム環境で予期しない遅延スパイクが発生する可能性がありました。今回の更新により、store_rps_map() 関数には、RPS 設定の目的で分離された CPU が含まれなくなりました。同様に、XPS 設定に使用されるカーネルドライバーは、CPU 分離を考慮しています。その結果、RPS および XPS は、説明されているシナリオで分離された CPU にジョブを配置しなくなりました。/sys/devices/pci*/net/dev/queues/rx-*/rps_cpus ファイルで分離された CPU を設定すると、次のエラーが表示されます。

SCSI ドライバーがメモリーを過剰に使用しなくなりました。

以前は、SCSI ドライバーの中には、RHEL 7 よりも大容量のメモリーを使用しているものがありました。ファイバーチャネルホストバスアダプター (HBA) での vPort 作成など、特定のケースでは、システム設定によってはメモリー使用量が過剰になっていました。

UDS が再構築を終了する前に VDO を一時停止できるようになりました。

以前のリリースでは、UDS インデックスの再構築中に VDO ボリュームを一時停止しようとすると、dmsetup suspend コマンドが応答しなくなりました。このコマンドは、再構築後にのみ終了します。

mod_cgid ロギングの問題が修正されました。

今回の更新以前は、mod_cgid Apache httpd モジュールをスレッド化マルチプロセッシングモジュール (MPM) で使用する場合、以下のロギング問題が発生していました。

dlopen の失敗時に、未配置で初期化されていない共有オブジェクトが失敗することがなくなりました。

以前は、dlopen 呼び出しに失敗すると、glibc 動的リンカーは、エラー報告前に NODELETE マークの付いた共有オブジェクトを削除しませんでした。そのため、未配置で初期化されていない共有オブジェクトがプロセスイメージに残され、最終的にはアサーションの失敗またはクラッシュにつながっていました。今回の更新で、動的ローダーは dlopen 失敗時に、保留中の NODELETE 状態を使用して共有オブジェクトを削除した後で、それらを永続的に NODELETE としてマークするようになりました。その結果、再配置されていないオブジェクトがプロセスに取り残されることはありません。また、ELF コンストラクターおよびデストラクターの実行中に遅延結合が失敗すると、プロセスが終了するようになりました。

64 ビット ARM アーキテクチャーの Advanced SIMD 関数は遅延解決時に誤ってコンパイルしなくなりました。

以前のリリースでは、Advanced SIMD の新しいベクトルプロシージャーコール標準 (PCS) で、Advanced SIMD 機能の遅延解決時に、特定の呼出先退避レジスターが正しく保存、復元されませんでした。そのため、ランタイム時にバイナリーが誤作動する可能性がありました。今回の更新では、シンボルテーブルの Advanced SIMD と SVE ベクトル関数は .variant_pcs とマーク付されたので、動的なリンカーはこのような関数を初期にバインドするようになります。

sudo ラッパースクリプトはオプションを解析するようになりました。

以前のリリースでは、/opt/redhat/devtoolset*/root/usr/bin/sudo ラッパースクリプトは sudo オプションを正しく解析しませんでした。そのため、一部の sudo オプション (sudo -i など) を実行できませんでした。今回の更新で、sudo オプションが正しく解析され、sudo ラッパースクリプトが /usr/bin/sudo と同様に動作するようになりました。

glibc での TLS 変数の調整が修正されました。

以前のリリースでは、特定の条件下で、調整されたスレッドローカルストレージ (TLS) データは、想定の調整なしにインスタンス化される可能性がありました。今回の更新で、POSIX Thread Library libpthread が拡張され、どのような条件下でも正しい調整を行うようになりました。これにより、調整された TLS データは、正しく調整されすべてのスレッドに対して適切にインスタンス化されるようになりました。

EINTR または EAGAIN エラーの発生後に pututxline 呼び出しを繰り返しても、utmp ファイルが破損しなくなりました。

pututxline 関数がロックを取得しようとして、時間内に成功しなかった場合には、関数は EINTR または EAGAIN のエラーコードを返します。以前のリリースでは、は、pututxline がすぐに呼び出されて、ロックを取得するように管理できた場合に、utmp ファイルにすでに割り当てられている対応のスロットを使用せず、別のエントリーを追加していました。そのため、このような未使用のエントリーにより、utmp ファイルのサイズが大幅に増大していました。今回の更新で問題が修正され、エントリーが utmp ファイルに正しく追加されるようになりました。

内部障害が発生しても mtrace がハングしなくなりました。

以前のリリースでは、mtrace ツールの実装に不具合が原因で、メモリートレースがハングする可能性がありました。この問題を修正するために、mtrace メモリートレースの実装が堅牢化され、内部障害の発生時にもハングが発生しなくなりました。その結果、mtrace を呼び出しても、ハングしなくなり、制限時間内に完了するようになりました。

fork 関数は pthread_atfork を使用すると発生する特定のデッドロックを回避するようになりました。

以前のリリースは、プログラムが atfork ハンドラーを登録し、非同期署名ハンドラーから fork を呼び出すと、内部実装依存ロックの不具合により、プログラムがフリーズする可能性がありました。今回の更新で、フォーク とその atfork ハンドラーの実装を調整し、シングルスレッドプログラムでデッドロックを回避できるようになりました。

strstr は、省略されたパターンに対して、正しい一致内容を返すようになりました。

一部の IBM Z プラットフォーム (z15、以前は arch13) では、strstr 関数は、ページの境界をまたぐ検索パターンを処理する場合に CPU レジスターが適切に更新されませんでした。これにより、strstr は誤った一致内容を返していました。今回の更新でこの問題が修正され、上記のシナリオで strstr が期待どおりに動作するようになりました。

glibc における C.UTF-8 ロケールソースの省略表現が修正されました。

以前は、C.UTF-8 ソースロケールに不具合があると、U+10000 を超えるすべての Unicode コードポイントに照合の重み付けが欠けていました。これにより、U+10000 を超えるすべてのコードポイントが期待どおりに照合されませんでした。C.UTF-8 ソースロケールが修正され、新たにコンパイルされたバイナリーロケールでは、すべての Unicode コードポイントが照合の重み付けを持つようになりました。コンパイルされた C.UTF-8 ロケールは、この修正により 5.3MiB 大きくなります。

setpwent() を呼び出しせずに getpwent() が呼び出されても glibc が失敗しなくなりました。

/etc/nsswitch.conf ファイルが Berkeley DB (db) パスワードプロバイダーを参照する場合は、最初に setpwent() を 1 度のみ呼び出すことなく、getpwent() 関数を使用してデータを要求できます。endpwent() 関数を呼び出すとき、最初に setpwent() を呼び出さずに getpwent() に呼び出しを行うと、glibc が失敗していました。これは、endpwent() が新しいクエリーを許可するように内部をリセットできなかったためです。今回の更新でこの問題が修正されています。その結果、endpwent() で 1 つのクエリーを終了すると、setpwent() を呼び出さなくても、getpwent() への呼び出しがさらに新しいクエリーを開始します。

ltrace は、強化されたバイナリーでのシステムコールを追跡できるようになりました。

以前のリリースでは、ltrace を使用して、AMD および Intel 64 ビットアーキテクチャー上のシステムバイナリーなど、特定の強化されたバイナリーで結果が生成されませんでした。今回の更新で、ltrace が、強化されたバイナリーでのシステムコールを追跡できるようになりました。

Intel の JCC の不具合により、GCC コンパイラーでパフォーマンスが大幅に低下することがなくなりました。

特定の Intel CPU は、マシン命令が誤って実行される原因となるジャンプ条件コード (JCC) バグの影響を受けます。したがって、影響を受けた CPU は、プログラムを適切に実行しない可能性があります。完全な修正には、脆弱な CPU のマイクロコードの更新が含まれており、パフォーマンス低下につながる可能性があります。今回の更新で、パフォーマンスの低下を軽減するのに役立つアセンブラーでの回避策が可能になりました。回避策は、デフォルトでは有効になっていません。

並行ビルド中に make の速度が低下することがなくなりました。

以前のバージョンでは、並行ビルドの実行中に、シーケンスの実行を待機すると、make サブプロセスが一時的に応答しなくなる可能性がありました。その結果、-j の値が高いビルドは遅延するか、効果的な -j の値が低いで実行されました。今回の更新では、make のジョブ制御ロジックがブロックされなくなりました。その結果、-j の値が高いビルドが完全な -j の速度で実行されます。

ltrace ツールが関数呼び出しを正しく報告するようになりました。

すべての RHEL コンポーネントに適用されるバイナリー強化を改善したことが原因で、以前は、ltrace ツールで RHEL コンポーネントからのバイナリーファイルの関数呼び出しを検出できませんでした。これにより、ltrace の出力では、このようなバイナリーファイルで使用されたときに検出される呼び出しが報告されず、空になっていました。今回の更新で、ltrace が関数呼び出しを処理する方法が修正され、上記の問題が発生しなくなりました。

dsctl ユーティリティーが、名前にハイフンが付いたインスタンスの管理に失敗しなくなりました。

以前は、dsctl ユーティリティーは Directory Server インスタンス名のハイフンを正しく解析しませんでした。そのため、管理者は dsctl を使用して名前にハイフンを含むインスタンスを管理することができませんでした。今回の更新でこの問題が修正され、上記のシナリオで dsctl が期待どおりに動作するようになりました。

Directory Server インスタンス名が、最大 103 文字になりました。

LDAP クライアントが Directory Server への接続を確立すると、サーバーはクライアントアドレスに関連する情報をローカルバッファーに保存します。以前は、このバッファーのサイズが小さすぎて、46 文字を超える LDAPI パス名を格納できませんでした。たとえば、Directory Server インスタンスの名前が長すぎる場合などがこれに該当します。これにより、バッファーオーバーフローが原因で、サーバーが突然終了していました。今回の更新で、Netscape Portable Runtime (NSPR) ライブラリーがパス名用にサポートするバッファーサイズが最大サイズに増えます。その結果、上述のシナリオで Directory Server がクラッシュしなくなりました。

pkidestroy ユーティリティーが正しいインスタンスを選択するようになりました。

以前のリリースでは、半分削除されたインスタンスで pkidestroy --force コマンドを実行すると、 -i instance でインスタンス名を指定しても、デフォルトで pki-tomcat インスタンスが選択されていました。

sssd-ldap の man ページで ldap_user_authorized_service の説明が更新されました。

RHEL 8 では、プラグ可能な認証モジュール (PAM) スタックが変更されました。たとえば、systemd ユーザーセッションは、PAM サービス systemd-user を使用して PAM 対話を開始するようになりました。このサービスは、PAM サービスの system-auth を再帰的に追加します。ここには、pam_sss.so インターフェイスが含まれる場合もあります。これは、SSSD アクセス制御が常に呼び出されることを意味します。

IdM で AD 信頼のサポートを有効にすると、必要な DNS レコードに関する情報が表示されるようになりました。

以前のリリースでは、外部 DNS 管理を使用した Red Hat Enterprise Linux Identity Management (IdM) インストールで Active Directory (AD) 信頼のサポートを有効にすると、必要な DNS レコードに関する情報が表示されません。IdM で必要とされる全 DNS レコードのリストを取得するには、ipa dns-update-system-records --dry-run コマンドを手動で入力する必要がありました。

再帰 DNS クエリーは、統合 DNS を備えた IdM サーバーでデフォルトで無効になりました。

以前は、統合 DNS を備えた Identity Management (IdM) サーバーを使用する場合、再帰クエリーがデフォルトで有効になっていました。その結果、サーバーが DNS 増幅攻撃に使用される可能性がありました。今回の更新により、再帰 DNS クエリーがデフォルトで無効になり、サーバーを DNS 増幅攻撃に使用できなくなりました。

Wayland 上の GNOME Shell でソフトウェアレンダラーを使用しても、動作が遅くならなくなりました。

以前は、GNOME Shell の Wayland バックエンドは、ソフトウェアレンダラーの使用時にキャッシュ可能なフレームバッファーを使用していませんでした。そのため、Wayland 上のソフトウェアレンダリングされた GNOME Shell は、X.org バックエンド上のソフトウェアレンダリングされた GNOME Shell と比較して遅くなっていました。

第 10 世代の Intel Core プロセッサーにおける仮想マシンの起動に失敗しなくなりました。

以前は、第 10 世代 Intel Core プロセッサーを使用するホストモデル (Icelake-Server ともいう) では、仮想マシン (VM) の起動に失敗していました。今回の更新で、libvirt が QEMU でサポートされていない pconfig CPU 機能の無効化を試みなくなりました。その結果、第 10 世代 Intel プロセッサーを実行するホストモデルでの仮想マシンの起動に失敗しなくなりました。

cloud-init を使用した Microsoft Azure での仮想マシンのプロビジョニングが正しく機能するようになりました。

以前のリリースでは、cloud-init ユーティリティーを使用して、Microsoft Azure プラットフォームで RHEL 8 仮想マシンをプロビジョニングすることができませんでした。今回の更新で、Azure エンドポイントの cloud-init 処理が修正され、Azure での RHEL 8 仮想マシンのプロビジョニングが期待通りに実行されるようになりました。

RHEL 7 ホスト上の RHEL 8 仮想マシンが、1920x1200 を超える解像度で確実に表示できます。

以前は、RHEL 7 ホストシステムで RHEL 8 仮想マシンを実行している場合は、kiosk モードでアプリケーションを実行するなど、仮想マシンのグラフィカル出力を表示する方法によっては、1920x1200 を超える解像度を表示することはできませんでした。そのため、ホストハードウェアがより高い解像度に対応している場合でも、この方法での仮想マシンを表示できる解像度は最大 1920x1200 のみでした。今回の更新で、上述の問題が発生しないように DRM ドライバーおよび QXL ドライバーが調整されています。

cloud-init を使用する ESXi 仮想マシンのカスタマイゼーションと、仮想マシンの再起動が正常に動作するようになりました。

以前は、cloud-init サービスを使用して VMware ESXi ハイパーバイザーで実行している仮想マシンを修正し、静的 IP を使用して仮想マシンをクローンすると、新しいクローンの仮想マシンを再起動するのにかかる時間が非常に長くなる場合がありました。今回の更新で、cloud-init が仮想マシンの静的 IP を DHCP に書き直さないように修正され、上記の問題が発生しなくなりました。

quay.io レジストリーからイメージをプルする場合に、意図しないイメージが生じなくなりました。

以前のリリースでは、/etc/containers/registries.conf 内のデフォルトのレジストリー検索リストに quay.io コンテナーイメージレジストリーを記載した場合に、短縮名を使用すると、スプーフィングされたイメージをプルできていました。この問題を修正するため、quay.io コンテナーイメージレジストリーが、 /etc/containers/registries.conf のデフォルトのレジストリー検索リストから削除されました。その結果、quay.io レジストリーからイメージをプルする場合、ユーザーは完全なリポジトリー名 (quay.io/myorg/myimage など) を指定することが必要になりました。Quay.io レジストリーは、/etc/containers/registries.conf のデフォルトのレジストリー検索リストに再び追加し、短縮名を使用したコンテナーイメージのプルを有効化し直すことができますが、セキュリティーリスクが生じる可能性があるため、これは推奨されません。