5.7. 既知の問題
このパートでは Red Hat Enterprise Linux 8.2 の既知の問題を説明します。
5.7.1. インストーラーおよびイメージの作成
キックスタートコマンドの auth および authconfig で AppStream リポジトリーが必要になる
インストール中に、キックスタートコマンドの auth および authconfig で authselect-compat パッケージが必要になります。auth または authconfig を使用したときに、このパッケージがないとインストールに失敗します。ただし、設計上、 authselect-compat パッケージは AppStream リポジトリーでしか利用できません。
この問題を回避するには、BaseOS リポジトリーおよび AppStream リポジトリーがインストーラーで利用できることを確認するか、インストール中にキックスタートコマンドの authselect コマンドを使用します。
(BZ#1640697)
reboot --kexec コマンドおよび inst.kexec コマンドが、予測可能なシステム状態を提供しない
キックスタートコマンド reboot --kexec またはカーネル起動パラメーター inst.kexec で RHEL インストールを実行しても、システムの状態が完全な再起動と同じになるわけではありません。これにより、システムを再起動せずにインストール済みのシステムに切り替えると、予期しない結果が発生することがあります。
kexec 機能は非推奨になり、Red Hat Enterprise Linux の今後のリリースで削除されることに注意してください。
(BZ#1697896)
Anaconda インストールに、最小リソース設定要件の低い制限が含まれています。
Anaconda は最小限のリソース設定を必要とするシステムでインストールを開始し、インストールを成功させるのに必要なリソースに関する以前のメッセージ警告を提供しません。その結果、インストールが失敗し、出力エラーでデバッグや復元の可能性を明確に示すメッセージが提供されない場合があります。この問題を回避するには、システムに、インストールに必要な最小リソース設定 (PPC64 (LE) の場合は 2GB メモリー、x86_64 の場合は 1GB) があることを確認します。これにより、インストールを成功できます。
(BZ#1696609)
reboot --kexec コマンドを使用するとインストールが失敗します。
reboot --kexec コマンドを含むキックスタートファイルを使用すると、RHEL 8 のインストールに失敗します。この問題を回避するには、キックスタートファイルで reboot --kexec の代わりに reboot コマンドを使用します。
SSH から RHEL 8 初期セットアップを実行できません
現在、SSH を使用してシステムにログインする際に、RHEL 8 の初期セットアップインターフェイスは表示されません。これにより、SSH を介して管理される RHEL 8 マシンの初期設定を実行できません。この問題を回避するには、メインのシステムコンソール (ttyS0) で初期設定を行ってから、SSH を使用してログインします。
インストールプログラムでは、ネットワークアクセスがデフォルトで有効になっていません。
一部のインストール機能、たとえば、コンテンツ配信ネットワーク (CDN) を使用したシステムの登録、NTP サーバーサポート、およびネットワークインストールソースなどには、ネットワークアクセスが必要です。ただし、ネットワークアクセスはデフォルトでは有効になっていません。そのためこの機能は、ネットワークアクセスが有効になるまで使用できません。
この問題を回避するには、インストールの開始時にネットワークアクセスを有効にする起動オプション ip=dhcp を追加します。オプションで、起動オプションを使用して、ネットワーク上にあるキックスタートファイルまたはリポジトリーを渡しても、問題が解決されます。結果として、ネットワークベースのインストール機能を使用できます。
(BZ#1757877)
複数の組織に属するユーザーアカウントの登録に失敗していました
現在、複数の組織に属するユーザーアカウントでシステムを登録しようとすると、登録プロセスが失敗し、You must specifiy an organization for new units (新しいユニットの組織を指定する必要があります)。というメッセージが表示されます。
この問題を回避するには、以下のいずれかを行います。
- 複数の組織に属さない別のユーザーアカウントを使用します。
- GUI および Kickstart インストールの Connect to Red Hat 機能で利用できる アクティベーションキー 認証方法を使用します。
- Connect to Red Hat の登録手順を省略し、Subscription Manager を使用してインストール後にシステムを登録します。
Binary DVD ISO イメージを使用した GUI インストールを、CDN 登録なしで続行できないことがありました。
Binary DVD ISO イメージファイルを使用して GUI インストールを実行する場合は、Red Hat 機能への接続機能を使用してシステムを登録するまで、インストーラーの競合状態によりインストールが続行できなくなることがあります。この問題を回避するには、以下の手順を実施します。
- GUI インストールのインストール インストール概要 画面から インストールソース を選択します。
- 自動検出したインストールメディア が選択されていることを確認します。
- 完了 をクリックして選択を確定し、インストール概要 画面に戻ります。
- インストール 概要 画面に、ローカルメディア が インストールソース ステータスとして表示されることを確認します。
これにより、Red Hat への接続機能を使用してシステムを登録しなくてもインストールに進むことができます。
(BZ#1823578)
Binary DVD.iso ファイルのコンテンツをパーティションにコピーしても、.treeinfo ファイルおよび .discinfo ファイルはコピーされません。
ローカルインストールで、RHEL 8 Binary DVD.iso イメージファイルの内容をパーティションにコピーする際に、cp <path>/\* <mounted partition>/dir コマンドの * で、.treeinfo ファイルおよび .discinfo ファイルがコピーされません。インストールを成功させるには、このファイルが必要です。これにより、BaseOS リポジトリーおよび AppStream のリポジトリーが読み込まれず、anaconda.log ファイルのデバッグ関連のログメッセージでしか問題を確認できません。
この問題を回避するには、不足している .treeinfo ファイルおよび .discinfo ファイルをパーティションにコピーします。
(BZ#1687747)
Kickstart インストールでは、自己署名 HTTPS サーバーを使用できません。
現在では、インストールソースが Kickstart ファイルで指定され、--noverifyssl オプションが指定されると、インストーラーは自己署名の https サーバーからのインストールに失敗します。
url --url=https://SERVER/PATH --noverifyssl
この問題を回避するには、Kickstart インストールの開始時に、inst.noverifyssl パラメーターをカーネルコマンドラインに追加します。
以下に例を示します。
inst.ks=<URL> inst.noverifyssl
(BZ#1745064)
リポジトリーの更新が完了する前に CDN を使用した登録解除を試みると、GUI インストールが失敗することがあります。
RHEL 8.2 では、システムを登録し、コンテンツ配信ネットワーク (CDN) を使用してサブスクリプションを割り当てると、GUI インストールプログラムにより、リポジトリーメタデータの更新が開始されます。更新プロセスは、登録およびサブスクリプションプロセスの一部ではないため、Red Hat への接続 ウィンドウで 登録解除 ボタンが有効になります。ネットワーク接続によっては、更新プロセスが完了するのに 1 分以上かかることがあります。更新プロセスが完了する前に 登録解除 ボタンをクリックすると、登録解除プロセスで、インストールプログラムが CDN との通信に必要とする証明書と CDN リポジトリーファイルが削除されるため、GUI インストールが失敗する可能性があります。
この問題を回避するには、Red Hat への接続 ウィンドウで 登録 ボタンをクリックした後に、GUI インストールで次の手順を実行します。
- Red Hat への接続 画面から 完了 をクリックして、インストールの概要 画面に戻ります。
- インストールの概要 ウィンドウで、インストールソース および ソフトウェアの選択 の斜体のステータスメッセージに処理情報が表示されていないことを確認します。
- インストールソースとソフトウェアの選択のカテゴリーが準備できたら、Red Hat への接続 をクリックします。
- 登録解除 ボタンをクリックします。
これらの手順を完了したら、GUI のインストール時にシステムの登録を安全に解除できます。
(BZ#1821192)
5.7.2. サブスクリプション管理
syspurpose addons は subscription-manager attach --auto 出力に影響しません。
Red Hat Enterprise Linux 8 では、syspurpose コマンドラインツールの 4 つの属性 (role、usage、service_level_agreement、および addons) が追加されました。現在、role、usage、および service_level_agreement のみが、subscription-manager attach --auto コマンドの実行の出力に影響します。addons 引数に値を設定しても、自動登録されたサブスクリプションには影響がありません。
キックスタートファイルを使用して RHEL をインストールすると、マルチパスストレージデバイスのデータが失われる
キックスタートファイルを使用して RHEL をインストールすると、ホストに接続されているマルチパスストレージデバイスのデータが失われます。この問題は、ignoredisk --drives コマンドを使用して指定したマルチパスストレージデバイスをインストーラーが無視できないため発生します。その結果、デバイス上のデータが失われます。
この問題を回避するには、インストール前にデバイスを切り離すか、ignoredisk --only-use コマンドを使用してインストールするデバイスを指定します。
(BZ#1862131)
5.7.3. シェルおよびコマンドラインツール
Wayland プロトコルを使用するアプリケーションは、リモートのディスプレイサーバーに転送できません。
Red Hat Enterprise Linux 8 では、ほとんどのアプリケーションは、X11 プロトコルの代わりに、デフォルトで Wayland プロトコルを使用します。したがって、ssh サーバーは、リモートディスプレイサーバーに対し、Wayland プロトコルを使用するアプリケーションを転送できませんが、X11 プロトコルを使用するアプリケーションを転送することは可能です。
この問題を回避するには、アプリケーションを起動する前に環境変数 gdk_BACKEND=x11 を設定します。その結果、アプリケーションはリモートディスプレイサーバーへ転送できます。
systemd-resolved.service がシステム起動時の起動に失敗します。
systemd-resolved サービスが起動時に起動できない場合があります。この場合は、以下のコマンドを実行して、システムの起動完了後に手動でサービスを再起動します。
# systemctl start systemd-resolved
ただし、システムの起動時に systemd-resolved が失敗しても、その他のサービスは影響を受けません。
(BZ#1640802)
5.7.4. セキュリティー
Audit の実行可能な監視機能がシンボリックリンクで機能しない
-w オプションによって提供されるファイルモニタリングでは、パスを直接追跡できません。デバイスと inode へのパスを解決して、実行したプログラムとの比較を行う必要があります。実行可能なシンボリックリンクを監視する監視機能は、メモリーで実行されるプログラムではなく、デバイスとシンボリックリンク自体の inode を監視します。これは、シンボリックリンクの解決から確認できます。監視機能がシンボリックリンクを解決して作成される実行プログラムを取得する場合でも、ルールは別のシンボリックリンクから呼び出されるマルチコールバイナリーでトリガーされます。これにより、誤検出でログがいっぱいになります。したがって、Audit の実行可能な監視機能は、シンボリックリンクでは機能しません。
この問題を回避するには、プログラム実行可能ファイルの解決されたパスに対して監視を設定し、comm= や proctitle= フィールドに記載されている最後のコンポーネントを使用して、生成されるログメッセージをフィルターします。
(BZ#1846345)
/etc/selinux/config の SELINUX=disabled が正常に動作しません。
/etc/selinux/config で SELINUX=disabled オプションを使用して SELinux を無効にすると、カーネルが SELinux を有効にして起動し、その後のブートプロセスで無効化モードに切り替わります。これにより、メモリーリークが生じる可能性があります。
この問題を回避するには、SELinux を完全に無効にする必要がある場合に SELinux の使用 の システムの起動時に SELinux モードの変更 で説明されているように、selinux=0 パラメーターをカーネルコマンドラインに追加して SELinux を無効にすることが推奨されます。
(JIRA:RHELPLAN-34199)
libselinux-python は、そのモジュールからのみ利用可能
libselinux-python パッケージには、SELinux アプリケーション開発用の Python 2 バインディングのみが含まれ、後方互換性に使用されます。このため、libselinux-python コマンドを使用して、デフォルトの RHEL 8 リポジトリーで dnf install libselinux-python コマンドが利用できなくなりました。
この問題を回避するには、libselinux-python モジュールおよび python27 モジュールの両方を有効にし、以下のコマンドで libselinux-python パッケージとその依存関係をインストールします。
# dnf module enable libselinux-python # dnf install libselinux-python
または、1 つのコマンドでインストールプロファイルを使用して libselinux-python をインストールします。
# dnf module install libselinux-python:2.8/common
これにより、各モジュールを使用して libselinux-python をインストールできます。
(BZ#1666328)
udica は、--env container=podman で開始したときにのみ UBI 8 コンテナーを処理します。
Red Hat Universal Base Image 8 (UBI 8) コンテナーは、podman の値ではなく、コンテナー 環境変数を oci 値に設定します。これにより、udica ツールがコンテナー JavaScript Object Notation (JSON) ファイルを分析しなくなります。
この問題を回避するには、--env container=podman パラメーターを指定して、podman コマンドで UBI 8 コンテナーを起動します。そのため、udica は、上記の回避策を使用している場合に限り、UBI 8 コンテナーの SELinux ポリシーを生成することができます。
rpm-plugin-selinux パッケージを削除すると、システムからすべての selinux-policy パッケージが削除されます。
rpm-plugin-selinux パッケージを削除すると、マシン上で SELinux が無効になります。また、システムからすべての selinux-policy パッケージも削除されます。rpm-plugin-selinux パッケージを繰り返しインストールしてから、selinux-policy-targeted ポリシーが以前に存在していても、selinux-policy-minimum SELinux ポリシーをインストールします。ただし、繰り返しインストールしても、ポリシーの変更のために SELinux 設定ファイルが更新されることはありません。このため、rpm-plugin-selinux パッケージを再インストールしても、SELinux が無効になります。
この問題を回避するには、以下を実行します。
-
umount /sys/fs/selinux/コマンドを実行します。 -
足りない
selinux-policy-targetedパッケージを手動でインストールします。 -
ポリシーが
SELINUX=enforcingと同等になるように/etc/selinux/configファイルを編集します。 -
コマンド
load_policy -iを実行します。
これにより、SELinux が有効になり、以前と同じポリシーが実行されている状態になります。
(BZ#1641631)
SELinux により、systemd-journal-gatewayd corosync が、corosync によって作成される共有メモリーファイル上で newfstatat() を呼び出さなくなります。
SELinux ポリシーには、systemd-journal-gatewayd が corosync サービスによって作成されるファイルにアクセスできるルールが含まれません。その結果、SELinux は、systemd-journal-gatewayd による、corosync で作成された共有メモリーファイルの newfstatat() 関数を呼び出しを拒否します。
この問題を回避するには、このシナリオを実現する許可ルールでローカルポリシーモジュールを作成します。SELinux ポリシーの allow および dontaudit ルールの生成の詳細は、man ページの audit2allow(1) を参照してください。以前の回避策により、systemd-journal-gatewayd は、Enforcing モードで SELinux により corosync で作成した共有メモリーファイルの関数を呼び出すことができます。
(BZ#1746398)
SELinux が原因で auditd によるシステムの停止や電源オフができません。
SELinux ポリシーには、Audit デーモンが power_unit_file_t systemd ユニットを起動できるようにするルールがありません。したがって、Logging ディスクパーティションに領域が残っていない場合など、auditd がシステムを停止したり、電源をオフにしたりできるように設定した場合でも、システムの停止や電源オフができません。
この問題を回避するには、カスタムの SELinux ポリシーモジュールを作成します。こうすることで、auditd は回避策を適用している場合に限り、システムを正常に停止したり、電源をオフにしたりできます。
ユーザーは、ロックされたユーザーとして sudo コマンドを実行できます。
ALL キーワードで sudoers パーミッションが定義されているシステムでは、パーミッションを持つ sudo ユーザーは、アカウントがロックされているユーザーとして sudo コマンドを実行できます。そのため、ロックされたアカウントと期限切れのアカウントを使用して、コマンドを実行し続けることができます。
この問題を回避するには、/etc/shells 内の有効なシェルの適切な設定と併せて、新たに実装した runas_check_shell オプションを有効にします。これにより、攻撃者が bin などのシステムアカウントでコマンドを実行するのを防ぎます。
(BZ#1786990)
デフォルトのロギング設定がパフォーマンスに与える悪影響
デフォルトのログ環境設定は、メモリーを 4 GB 以上使用する可能性があり、rsyslog で systemd-journald を実行している場合は、速度制限値の調整が複雑になります。
詳細は、ナレッジベースの記事 Negative effects of the RHEL default logging setup on performance and their mitigations を参照してください。
(JIRA:RHELPLAN-10431)
config.enabled による rsyslog 出力の Parameter not known エラー。
rsyslog の出力では、config.enabled ディレクティブを使用すると、設定処理エラーで予期しないバグが発生します。これにより、include() ステートメントを除き、config.enabled ディレクティブを使用すると、parameter not known エラーが表示されます。
この問題を回避するには、config.enabled=on を設定するか、include() ステートメントを使用します。
(BZ#1659383)
特定の rsyslog 優先度の文字列が正常に動作しません。
imtcp に GnuTLS 優先度文字列を設定して、完成していない暗号化をきめ細かく制御できるようになりました。したがって、rsyslog では、以下の優先文字列が正常に動作しません。
NONE:+VERS-ALL:-VERS-TLS1.3:+MAC-ALL:+DHE-RSA:+AES-256-GCM:+SIGN-RSA-SHA384:+COMP-ALL:+GROUP-ALL
この問題を回避するには、正しく機能する優先度文字列のみを使用します。
NONE:+VERS-ALL:-VERS-TLS1.3:+MAC-ALL:+ECDHE-RSA:+AES-128-CBC:+SIGN-RSA-SHA1:+COMP-ALL:+GROUP-ALL
したがって、現在の設定は、正しく機能する文字列に限定する必要があります。
SHA-1 署名を使用するサーバーへの接続が GnuTLS で動作しません。
証明書の SHA-1 署名は、GuTLS セキュアな通信ライブラリーにより、セキュアでないものとして拒否されます。したがって、TLS のバックエンドとして GnuTLS を使用するアプリケーションは、このような証明書を提供するピアへの TLS 接続を確立することができません。この動作は、その他のシステム暗号化ライブラリーと一貫性がありません。この問題を回避するには、サーバーをアップグレードして、SHA-256 または強力なハッシュを使用して署名した証明書を使用するか、LEGACY ポリシーに切り替えます。
(BZ#1628553)
TLS 1.3 は、FIPS モードの NSS で動作しません。
TLS 1.3 は、FIPS モードで動作しているシステムでは対応していません。その結果、相互運用性に TLS 1.3 を必要とする接続が、FIPS モードで動作しているシステムで機能しません。
その接続を有効にするには、システムの FIPS モードを無効にするか、ピアで TLS 1.2 のサポートを有効にします。
OpenSSL が、生の RSA または RSA-PSS の署名に対応していない PKCS #11 トークンを誤って処理します。
OpenSSL ライブラリーは、PKCS #11 トークンの鍵関連の機能を検出しません。したがって、生の RSA または RSA-PSS の署名に対応しないトークンで署名が作成されると、TLS 接続の確立に失敗します。
この問題を回避するには、/etc/pki/tls/openssl.cnf ファイルの crypto_policy セクションの末尾にある .include 行の後に、以下の行を追加します。
SignatureAlgorithms = RSA+SHA256:RSA+SHA512:RSA+SHA384:ECDSA+SHA256:ECDSA+SHA512:ECDSA+SHA384 MaxProtocol = TLSv1.2
これにより、このシナリオで TLS 接続を確立できます。
OpenSSL が、TLS 1.3 の CertificateRequest メッセージに、不正な status_request 拡張を生成します。
OpenSSL サーバーは、status_request 拡張とクライアント証明書ベースの認証サポートが有効な場合に、CertificateRequest メッセージに正しくない status_request 拡張を送信します。この場合、OpenSSL は RFC 8446 プロトコルに準拠する実装と同時には動作しません。その結果、CertificateRequest メッセージの拡張を適切に検証するクライアントは OpenSSL サーバーとの接続を中止します。この問題を回避するには、接続のいずれかで TLS 1.3 プロトコルのサポートを無効にするか、OpenSSL サーバーの status_request のサポートを無効にします。これにより、サーバーが不正なメッセージを送信しなくなります。
ssh-keyscan が、FIPS モードでサーバーの RSA 鍵を取得できません。
FIPS モードで RSA 署名の SHA-1 アルゴリズムが無効になっています。これにより、ssh-keyscan ユーティリティーがそのモードで稼働しているサーバーの RSA 鍵を取得できなくなります。
この問題を回避するには、代わりに ECDSA 鍵を使用するか、サーバーの /etc/ssh/ssh_host_rsa_key.pub ファイルから鍵をローカルに取得します。
Libreswan が、すべての設定において seccomp=enabled で正常に動作しません。
Libreswan SECCOMP サポート実装で許可された syscall のセットは現在、完全ではありません。したがって、SECCOMP が ipsec.conf ファイルで有効となっている場合、syscall のフィルタリングは、pluto デーモンの正常な機能に必要な syscall まで拒否します。つまり、デーモンは強制終了され、ipsec サービスが再起動されます。
この問題を回避するには、seccomp= オプションを設定して、disabled 状態に戻します。SECCOMP サポートは、ipsec を正常に実行するため、無効のままにしておく必要があります。
SSG における相互依存ルールの特定のセットが失敗する可能性があります。
ルールとその依存関係の順序付けを定義しないため、ベンチマークの SCAP Security Guide (SSG) ルールの修正が失敗する可能性があります。たとえば、特定の順番で複数のルールを実行する必要がある場合、あるルールがコンポーネントをインストールし、別のルールが同じコンポーネントを設定した場合すると、それらは正しくない順序で実行される可能性があり、修正によってエラーが報告されます。この問題を回避するには、修正を回実行して、番目の実行で依存ルールを修正します。
SCAP Workbench が、カスタムプロファイルから結果ベースの修正を生成できません。
SCAP Workbench ツールを使用してカスタムプロファイルから結果ベースの修正ロールを生成しようとすると、次のエラーが発生します。
Error generating remediation role .../remediation.sh: Exit code of oscap was 1: [output truncated]
この問題を回避するには、oscap コマンドを、--tailoring-file オプションとともに使用します。
(BZ#1640715)
RHEL 8 のキックスタートが、com_redhat_oscap の代わりに org_fedora_oscap を使用
キックスタートは、com_redhat_oscap ではなく、org_fedora_oscap として Open Security Content Automation Protocol (OSCAP) Anaconda アドオンを参照します。これが、混乱を招く可能性があります。これは、Red Hat Enterprise Linux 7 との後方互換性を維持するために行われます。
(BZ#1665082)
OSCAP Anaconda Addon がすべてのパッケージをテキストモードでインストールしません。
OSCAP Anaconda Addon プラグインは、インストールがテキストモードで実行している場合、システムインストーラーによってインストールに選択されているパッケージのリストを変更することはできません。これにより、キックスタートを使用してセキュリティーポリシープロファイルが指定され、インストールがテキストモードで実行している場合に、インストール中にセキュリティーポリシーに必要な追加パッケージがインストールされません。
この問題を回避するには、グラフィカルモードでインストールを実行するか、キックスタートファイルの %packages セクションにあるセキュリティーポリシーで、セキュリティーポリシープロファイルに必要なパッケージをすべて指定します。
これにより、セキュリティーポリシープロファイルで必要となるパッケージは、上記の回避策のいずれかを行わなければ RHEL インストールインストール時にインストールされません。また、インストール後のシステムは、指定のセキュリティーポリシープロファイルと互換性がありません。
oscap Anaconda Addon がカスタムプロファイルを正しく処理しません。
OSCAP Anaconda Addon プラグインは、個別のファイルでカスタマイズを使用したセキュリティープロファイルを適切に処理しません。これにより、対応する Kickstart セクションで適切に指定しても、RHEL グラフィカルインストールでカスタマイズしたプロファイルは利用できません。
この問題を回避するには、ナレッジベースの記事 Creating a single SCAP data stream from an original DS and a tailoring file を参照してください。この回避策により、RHEL グラフィカルインストールでカスタマイズした SCAP プロファイルを使用できます。
(BZ#1691305)
GnuTLS が NSS サーバーとの現行セッションを再開できません。
TLS (Transport Layer Security) 1.3 セッションを再開するとき、GnuTLS クライアントは 60 ミリ秒に加えて、サーバーがセッション再開データを送信するために推定されるラウンドトリップタイムの分だけ待機します。サーバーがこの時間内に再開データを送信しないと、クライアントは現行セッションを再開せずに新しいセッションを作成します。これは、通常のセッションネゴシエーションのパフォーマンスに若干影響することを除いて、深刻な悪影響を与えることはありません。
リモートシステムを --sudo でスキャンすると、oscap-ssh ユーティリティーが失敗します。
oscap-ssh ツールで --sudo オプションを使用してリモートシステムの Security Content Automation Protocol (SCAP) スキャンを実行すると、リモートシステムの oscap ツールが、root ユーザーとして、スキャン結果ファイルとレポートファイルを一時ディレクトリーに保存します。リモートマシンの umask 設定を変更した場合は、oscap-ssh がこれらのファイルにアクセスできない可能性があります。この問題を回避するには、ソリューション "oscap-ssh --sudo" fails to retrieve the result files with "scp: …: Permission denied" error で説明されているように、oscap-ssh ツールを変更します。これにより、oscap はターゲットユーザーとしてファイルを保存し、oscap-ssh は普通にファイルにアクセスします。
OpenSCAP が、YAML マルチライン文字列から空の行を削除することにより、誤検出が生成されます。
OpenSCAP がデータストリームから Ansible 修正を生成すると、YAML マルチライン文字列から空の行が削除されます。一部の Ansible 修正にはリテラル設定のファイルコンテンツが含まれているため、空の行を削除すると、対応する修正に影響します。空の行に何の効果もないとしても、これにより openscap ユーティリティーが、対応する Open Vulnerability and Assessment Language (OVAL) チェックに失敗します。この問題を回避するには、ルールの説明を確認し、空の行がないために失敗したスキャン結果をスキップします。または、Bash の修正ではこれらの誤検出が発生しないので、Ansible の修正の代わりに Bash の修正を使用します。
OSPP ベースのプロファイルに、GUI パッケージグループとの互換性がありません。
Server with GUI パッケージグループでインストールされる GNOME パッケージには、Operating System Protection Profile (OSPP) に準拠しない nfs-utils パッケージが必要です。これにより、OSPP または OSPP ベースのプロファイル (Security Technical Implementation Guide (STIG) など) を使用したシステムのインストール時にServer with GUIパッケージグループを選択すると、インストールが中断されます。OSPP ベースのプロファイルがインストール後に適用される場合、システムは起動できません。この問題を回避するには、Server with GUIパッケージグループや、または OSPP プロファイルと OSPP ベースのプロファイルを使用する際に GUI をインストールするその他のグループをインストールしないでください。代わりにServerまたはMinimal Installパッケージグループを使用すると、システムは問題なくインストールされ、正常に機能します。
RHEL 8 システムに Server with GUI パッケージグループが含まれる場合には e8 プロファイルを使用して修復できません。
OpenSCAP Anaconda Add-on を使用して、Verify Integrity with RPM グループからルールを選択するプロファイルが含まれる Server With GUI パッケージグループでシステムを強化すると、システム上のメモリーを過剰に必要とします。この問題は、OpenSCAP スキャナーが原因で発生します。詳細は、Scanning large numbers of files with OpenSCAP causes systems to run out of memory を参照してください。このため、RHEL8 Essential Eight (e8) プロファイルを使用してシステムを正常に強化できません。この問題を回避するには、サーバーなどの小規模なパッケージグループを選択して、インストール後に必要な追加パッケージをインストールします。その結果、システムにはパッケージ数が少なくなり、スキャンに必要なメモリーが少なくなるため、システムを自動的に強化できます。
(BZ#1816199)
OpenSCAP で多数のファイルをスキャンすると、システムがメモリーを使い切ってしまいます。
OpenSCAP スキャナーは、スキャンが完了するまで、収集したすべての結果をメモリーに保存します。そのため、たとえば、GUI および Workstation を使用する大規模なパッケージグループから、大量のファイルをスキャンする場合、RAM が少ないシステムでメモリーが不足する可能性があります。この問題を回避するには、RAM が少ないシステムで、より小さいパッケージグループ (例: Server および Minimal Install) を使用します。大規模なパッケージグループを使用する必要がある場合は、システムで仮想環境またはステージング環境に十分なメモリーがあるかどうかをテストしてください。または、スキャンプロファイルを調整して、/ ファイルシステム全体の再帰を行う、以下のルールの選択を解除することができます。
-
rpm_verify_hashes -
rpm_verify_permissions -
rpm_verify_ownership -
file_permissions_unauthorized_world_writable -
no_files_unowned_by_user -
dir_perms_world_writable_system_owned -
file_permissions_unauthorized_suid -
file_permissions_unauthorized_sgid -
file_permissions_ungroupowned -
dir_perms_world_writable_sticky_bits
選択を外すことで、OpenSCAP スキャンで、システムがメモリー不足になるのを防ぎます。
5.7.5. ネットワーク
GRO が無効になっていると、IPsec オフロード中に IPsec ネットワークトラフィックが失敗します。
デバイスで汎用受信オフロード (GRO) が無効になっていると、IPSec オフロードは機能しません。IPsec オフロードがネットワークインターフェイスで設定され、GRO がそのデバイスで無効になっていると、IPsec ネットワークトラフィックに失敗します。
この問題を回避するには、デバイスで GRO を有効にしたままにします。
(BZ#1649647)
iptables では、指定のチェーンタイプが不明な場合に、モジュールがチェーン更新コマンドを読み込むように要求されません。
注記: この問題は、サービスのデフォルト設定を使用している場合は、iptables systemd サービスを停止すると、機能的な影響のない偽のエラーが発生します。
iptables-nft でチェーンのポリシーを設定すると、関連付けられたカーネルモジュールがすでにロードされていない場合には、作成される更新チェーンコマンドのカーネルへの送信に失敗します。この問題を回避するには、以下のコマンドを使用してモジュールを読み込みます。
+
# iptables -t nat -n -L # iptables -t mangle -n -L
(BZ#1812666)
nft_compat モジュールによる、アドレスファミリー固有の LOG バックエンドモジュールの自動読み込みがハングする可能性があります。
nft_compat モジュールが、ネットワークの名前空間 (netns) で並行して操作が実行されている時に、アドレスファミリー固有の LOG ターゲットバックエンドを読み込むと、ロックの競合が発生する可能性があります。そのため、アドレスファミリー固有の LOG ターゲットバックエンドを読み込むとハングする可能性があります。この問題を回避するには、iptables-restore ユーティリティーを実行する前に、関連する LOG ターゲットバックエンド (nf_log_ipv4.ko、nf_log_ipv6.ko など) を手動で読み込みます。こうすることで、LOG ターゲットバックエンドの読み込みが停止しなくなります。ただし、システムの起動時に問題が発生した場合は、回避策はありません。
libvirtd などの他のサービスは、iptables コマンドも実行するため、問題が発生する可能性があることに注意してください。
(BZ#1757933)
5.7.6. カーネル
誤ってパッチが削除されると、huge_page_setup_helper.py でエラーが表示されます。
huge_page_setup_helper.py スクリプトを更新するパッチが誤って削除されました。これにより、huge_page_setup_helper.py の実行後に、以下のエラーメッセージが表示されます。
SyntaxError: Missing parentheses in call to 'print'
この問題を回避するには、RHEL 8.1 から huge_page_setup_helper.py スクリプトをコピーし、これを /usr/bin/ ディレクトリーにインストールします。
-
RHEL-8.1.0 のインストールメディアまたは Red Hat カスタマーポータル から、
libhugetlbfs-utils-2.21-3.el8.x86_64.rpmパッケージをダウンロードします。 rpm2cpioコマンドを実行します。# rpm2cpio libhugetlbfs-utils-2.21-3.el8.x86_64.rpm | cpio -D / -iduv '*/huge_page_setup_helper.py'
このコマンドは、RHEL 8.1 RPM から
huge_page_setup_helper.pyスクリプトをデプロイメントして、/usr/bin/ディレクトリーに保存します。
これにより、huge_page_setup_helper.py スクリプトが正しく動作するようになります。
(BZ#1823398)
永続メモリーのサイズが大きくなると、システムの起動プロセス時に遅延が発生します。
メモリーの初期化がシリアル化されるため、永続メモリーのサイズが大きいシステムは起動に時間がかかります。したがって、/etc/fstab ファイルに永続メモリーのファイルシステムがあると、デバイスが利用できるようになるまで待つ際に、システムがタイムアウトする場合があります。この問題を回避するには、/etc/systemd/system.conf ファイルの DefaultTimeoutStartSec オプションを十分に大きな値に設定します。
(BZ#1666538)
KSM が、NUMA メモリーポリシーを無視することがあります。
merge_across_nodes=1 パラメーターで、カーネル共有メモリー (KSM) 機能を有効にすると、KSM は、mbind() 関数が設定したメモリーポリシーを無視し、一部のメモリーから、ポリシーに一致しない NUMA (Non-Uniform Memory Access) ノードにページをマージできない場合があります。
この問題を回避するには、KSM を無効にするか、QEMU で NUMA メモリーバインディングを使用する場合は merge_across_nodes パラメーターを 0 に設定します。これにより、KVM 仮想マシンに設定した NUMA メモリーポリシーが期待どおりに機能します。
(BZ#1153521)
RHEL 8 で、デバッグカーネルがクラッシュキャプチャー環境で起動に失敗します。
デバッグカーネルのメモリー要求の性質により、デバッグカーネルが使用中で、カーネルパニックが発生すると、問題が発生します。その結果、デバッグカーネルはキャプチャーカーネルとして起動できず、代わりにスタックトレースが生成されます。この問題を回避するには、クラッシュカーネルメモリーを適宜増やします。これにより、デバッグカーネルが、クラッシュキャプチャー環境で正常に起動します。
(BZ#1659609)
zlib は、一部の圧縮機能で vmcore キャプチャーの速度を低下させる可能性があります。
kdump 設定ファイルはデフォルトで、lzo 圧縮形式 (makedumpfile -l) を使用します。zlib 圧縮形式 (makedumpfile -c) を使用して設定ファイルを変更すると、vmcore のキャプチャープロセスの速度を低下させる代わりに、圧縮の因子が改善される可能性が高くなっています。これにより、lzo と比較して、kdump が zlib で vmcore をキャプチャーするのに最大 4 倍の時間がかかります。
このように、Red Hat は、速度が主要な要因である場合に、デフォルトの lzo を使用することを推奨します。ただし、ターゲットマシンで利用可能な領域が少ない場合は、zlib の方が適しています。
(BZ#1790635)
vmcore キャプチャーはメモリーのホットプラグまたはアンプラグの操作を実行した後に失敗します。
メモリーのホットプラグまたはホットアンプラグ操作の実行後に、メモリーのレイアウト情報を含むデバイスツリーを更新するとイベントが発生します。これにより、makedumpfile ユーティリティーは存在しない物理アドレスにアクセスしようとします。以下の条件を満たすと問題が発生します。
- IBM Power System (little endian) で RHEL 8 を実行する。
-
システムで
kdumpサービスまたはfadumpサービスが有効になっている。
このような場合に、メモリーホットプラグまたはホットアンプラグの操作後にカーネルクラッシュが発生すると、カーネルのキャプチャーで vmcore の保存に失敗します。
この問題を回避するには、ホットプラグまたはホットアンプラグ後に kdump サービスを再起動します。
# systemctl restart kdump.service
これにより、上記のシナリオで vmcore が正常に保存されます。
(BZ#1793389)
fadump ダンピングメカニズムが、ネットワークインターフェイスの名前を kdump-<interface-name> に変更します。
ファームウェア支援ダンプ (fadump) を使用して vmcore を取得し、SSH または NFS プロトコルを使用してこれをリモートマシンに保存すると、ネットワークインターフェイスの名前が kdump-<interface-name> に変更されます。名前変更は、<interface-name> が、*eth# や net# などのように一般的な場合に起こります。この問題は、初期 RAM ディスク (initrd) の vmcore 取得スクリプトが、ネットワークインターフェイス名に接頭辞 kdump- を追加して、永続的な名前付けを保護するために発生します。同じ initrd が通常の起動にも使用されるため、実稼働環境のカーネルのインターフェイス名も変更されます。
(BZ#1745507)
fadump が有効な場合、システムが起動時に緊急モードに切り替わります。
fadump (kdump) または dracut squash モジュールが initramfs スキームで有効化されると、システムが緊急モードに切り替わります。これは、systemd マネージャーがマウント情報の取得とマウントする LV パーティションの設定に失敗するためです。この問題を回避するには、以下のカーネルコマンドラインパラメーター rd.lvm.lv=<vg>/<LV> を追加し、失敗した LV パーティションを適切に検出してマウントします。これにより、上述のシナリオでシステムが正常に起動するようになります。
(BZ#1750278)
irqpoll を使用すると vmcore の生成に失敗します。
Amazon Web Services (AWS) クラウドプラットフォームで実行している 64 ビット ARM アーキテクチャー上には nvme ドライバーの既存の問題があります。この問題により、最初のカーネルに irqpoll カーネルコマンドラインパラメーターを指定すると vmcore の生成に失敗します。したがって、カーネルクラッシュ後に vmcore が /var/crash/ ディレクトリーにダンプされません。この問題を回避するには、以下を実行します。
-
/
/etc/sysconfig/kdumpファイルのKDUMP_COMMANDLINE_REMOVEキーにirqpollを追加します。 -
systemctl restart kdumpコマンドを実行して、kdumpサービスを再起動します。
その結果、最初のカーネルが正常に起動し、カーネルクラッシュ時に vmcore がキャプチャーされることが予想されます。
kdump サービスは、大量のクラッシュカーネルメモリーを使用して vmcore ファイルをダンプできることに注意してください。キャプチャーカーネルには、kdump サービス用のメモリーが十分あることを確認します。
(BZ#1654962)
ダンプターゲットとして vPMEM メモリーを使用すると、カーネルクラッシュキャプチャープロセスが遅延します。
仮想永続メモリー (vPEM) 名前空間を kdump または fadump ターゲットとして使用する場合には、 papr_scm モジュールは強制的に、vPMEM がサポートするメモリーのマッピングを解除して再マッピングし、メモリーをリニアマップに再追加します。したがって、この動作により、ハイパーバイザーコール (HCall) が POWER Hypervisor にトリガーされ、カーネルブートのキャプチャーにかかる合計時間が大幅に長くなります。そのため、kdump または fadump のダンプターゲットとして vPMEM 名前空間を使用しないことが推奨されます。
vPMEM を使用する場合に、この問題を回避するには、以下のコマンドを実行します。
/etc/dracut.conf.d/99-pmem-workaround.confファイルを作成し、以下を追加します。add_drivers+="nd_pmem nd_btt libnvdimm papr_scm"
初期 RAM ディスク (initrd) のファイルシステムを再構築します。
# touch /etc/kdump.conf # systemctl restart kdump.service
(BZ#1792125)
HP NMI ウォッチドッグが常にクラッシュダンプを生成しない
特定に場合において、HP NMI ウォッチドッグの hpwdt ドライバーは、マスク不可割り込み (NMI) が perfmon ドライバーにより使用されたため、HPE ウォッチドッグタイマーが生成した NMI を要求できません。
欠落している NMI は、以下の 2 つの条件のいずれかによって開始されます。
- Integrated Lights-Out (iLO) サーバー管理ソフトウェアの NMI 生成 ボタン。このボタンはユーザーがトリガーします。
-
hpwdtウォッチドッグ。デフォルトでは、有効期限により NMI がサーバーに送信されます。
通常、両方のシーケンスは、システムが応答しない場合に発生します。通常、これらの状況の NMI ハンドラーは kernel panic() 関数を呼び出します。また、設定されていれば、kdump サービスが vmcore ファイルを生成します。
ただし、NMI が見つからないため、kernel panic() は呼び出されず、vmcore が収集されません。
最初のケース (1.) でシステムが応答しない場合は、その状態のままになります。このシナリオを回避するには、仮想 電源 ボタンを使用してサーバーをリセットするか、電源を切って入れ直します。
2 つ目のケース (2.) では、欠落している NMI が Automated System Recovery (ASR) からのリセットの後 9 秒後に続きます。
HPE Gen9 Server ラインでは、1 桁台の割合でこの問題が発生します。Gen10 の周波数がさらに小さくなる。
(BZ#1602962)
tuned-adm profile powersave コマンドを使用すると、システムが応答しなくなります。
tuned-adm profile powersave コマンドを実行すると、古い Thunderx (CN88xx) プロセッサーを持つ Penguin Valkyrie 2000 2 ソケットシステムが応答しなくなります。これにより、作業を再開するためシステムを再起動することになります。この問題を回避するには、システムが上記の仕様と一致する場合には powersave プロファイルの使用を避けてください。
(BZ#1609288)
cxgb4 ドライバーにより kdump カーネルでクラッシュします。
vmcore ファイルに情報を保存しようとすると、kdump カーネルがクラッシュします。そのため、cxgb4 ドライバーにより、kdump カーネルが、後で分析するためにコアを保存できなくなります。この問題を回避するには、kdump カーネルコマンドラインに novmcoredd パラメーターを追加して、コアファイルを保存できるようにします。
(BZ#1708456)
ICE ドライバー NIC ポートをモード 5 (balance-tlb) ボンディングマスターインターフェイスに追加しようとすると失敗する場合があります。
ICE ドライバー NIC ポートをモード 5 (balance-tlb) ボンディングマスターインターフェイスに追加しようとすると、Master 'bond0', Slave 'ens1f0': Error: Enslave failed のエラーで失敗する可能性があります。そのため、NIC ポートをボンディングマスターインターフェイスに NICE ポートを追加するときに断続的に問題が発生します。この問題を回避するには、インターフェイスの追加をもう一度試してください。
(BZ#1791664)
type='hostdev' の仮想マシンへの Virtual Function のアタッチに失敗する場合があります。
Assignment with <interface type='hostdev'> メソッドに従って、.XML ファイルを使用して仮想マシンに Virtual Function (VF) をアタッチすると、失敗する場合があります。Assignment with <interface type='hostdev'> メソッドを使用すると、仮想マシンに渡す VF NIC に仮想マシンをアタッチできなくなります。この問題を回避するには、Assignment with <hostdev> メソッドを使用する、.XML ファイルで、仮想マシンに VF をアタッチしてください。こうすることで、virsh attach-device コマンドがエラーなしで成功します。Assignment with <hostdev> と Assignment with <interface type='hostdev'> (SRIOV デバイスのみ) の相違点については、PCI Passthrough of host network devices を参照してください。
(BZ#1792691)
5.7.7. ファイルシステムおよびストレージ
/boot ファイルシステムを LVM に配置することができません。
/boot ファイルシステムを LVM 論理ボリュームに配置することはできません。この制限は、以下の理由により存在します。
-
EFI システムでは、EFI システムパーティション が従来の
/bootファイルシステムとして機能します。uEFI 標準では、特定の GPT パーティションタイプと、このパーティションの特定のファイルシステムタイプが必要です。 -
RHEL 8 は、システムブートエントリーに Boot Loader Specification (BLS) を使用します。この仕様では、プラットフォームのファームウェアが
/bootファイルシステムを読み込める必要があります。EFI システムでは、プラットフォームファームウェアは uEFI 標準で定義された/boot設定のみを読み取ることができます。 - GRUB 2 ブートローダーでの LVM 論理ボリュームに対するサポートは完全ではありません。Red Hat は、uEFI や BLS などの標準があるので、この機能のユースケース数が減少しているため、サポートを改善する予定はありません。
Red Hat では、LVM での /boot のサポートを提供する予定はありません。代わりに、Red Hat は、/boot ファイルシステムを LVM 論理ボリュームに配置する必要がないシステムスナップショットおよびロールバックを管理するツールを提供します。
(BZ#1496229)
LVM で、複数のブロックサイズを持つボリュームグループが作成できない
vgcreate または vgextend などの LVM ユーティリティーでは、物理ボリューム (PV) の論理ブロックサイズが異なるボリュームグループ (VG) を作成できなくなりました。別のブロックサイズの PV で基礎となる論理ボリューム (LV) を拡張するとファイルシステムがマウントに失敗するため、LVM はこの変更を採用しました。
ブロックサイズが混在する VG の作成を再度有効にするには、lvm.conf ファイルの allow_mixed_block_sizes=1 オプションを設定します。
接続されている LUN が過剰にあると、DM Multipath の起動に失敗する可能性があります。
システムに接続されている論理ユニット (LUN) が多過ぎると、multipathd サービスがタイムアウトし、起動に失敗する可能性があります。問題を引き起こす LUN の正確な数は、デバイスの数、ストレージアレイの応答時間、メモリーおよび CPU の設定、システムの負荷など、複数の要素によって異なります。
この問題を回避するには、multipathd ユニットファイルのタイムアウトの値を増やします。
ユニットエディターで
multipathdユニットを開きます。# systemctl edit multipathd
以下の設定を入力し、タイムアウト値を上書きします。
[Service] TimeoutSec=300
Red Hat は、デフォルト値の 90 から 300 に値を増やすことを推奨しますが、90 を超える値をテストすることもできます。
- エディターでファイルを保存します。
systemdユニットを再度読み込んで、変更を適用します。# systemctl daemon-reload
結果、multipathd は、多数の LUN を使用して正常に起動できるようになりました。
(BZ#1797660)
LVM writecache の制限
writecache LVM キャッシュメソッドには以下の制限がありますが、cache メソッドには存在しません。
-
論理ボリュームが
writecacheを使用している場合には、論理ボリュームのスナップショットを取得できません。 -
論理ボリュームがアクティブな場合には、
writecacheの割り当てまたは割り当て解除ができません。 アクティブではない論理ボリュームに
writecacheを割り当てる場合は、既存のファイルシステムのブロックサイズに一致するwritecacheブロックサイズを使用する必要があります。詳細は、man ページの
lvmcache(7)を参照してください。-
writecacheがアタッチされている間は、論理ボリュームのサイズを変更することはできません。 -
writecacheを使用するデバイスでは、pvmoveコマンドは使用できません。 -
writecacheを指定した論理ボリュームは、シンプールまたは VDO と組み合わせて使用できません。
(JIRA:RHELPLAN-27987, BZ#1798631, BZ#1808012)
LUKS ボリュームを格納する LVM mirror デバイスが応答しなくなることがあります。
セグメントタイプが mirror のミラーリング LVM デバイスで LUKS ボリュームを格納すると、特定の条件下で応答しなくなる可能性があります。デバイスが応答しなくなると、すべての I/O 操作を拒否します。
耐障害性のソフトウェア定義ストレージに、LUKS ボリュームをスタックする必要がある場合に、この問題を回避するには、Red Hat は セグメントタイプが mirror ではなく raid1 の LVM RAID 1 デバイスを使用することを推奨します。
raid1 のセグメントタイプは、デフォルトの RAID 設定タイプで、mirror の代わりに、推奨のソリューションとしてこのタイプが使用されます。
mirror デバイスを raid1 に変換するには、ミラーリングされた LVM デバイスの RAID1 デバイスへの変換 を参照してください。
(BZ#1730502)
NFS 4.0 パッチにより、オープンな高ワークロードでパフォーマンスが低下する可能性があります。
以前、場合によっては NFS のオープン操作で、サーバー上のファイルが削除されたり、名前が変更されたりするという事実を見落とすというバグが修正されています。ただし、この修正により、多くのオープンな操作が必要とるするワークロードのパフォーマンスが遅くなる可能性があります。この問題を回避するには、NFS バージョン 4.1 以降を使用します。これは、多くの場合においてクライアントに委譲を付与するように改善されています。このため、クライアントがローカルに素早く安全にオープン操作を実行できます。
(BZ#1748451)
5.7.8. 動的プログラミング言語、Web サーバー、およびデータベースサーバー
32 ビットアプリケーションで呼び出されると getpwnam() が失敗する場合がある
NIS のユーザーが getpwnam() 関数を呼び出す 32 ビットアプリケーションを使用する場合は、nss_nis.i686 パッケージがないと呼び出しに失敗します。この問題を回避するには、yum install nss_nis.i686 コマンドを使用して、不足しているパッケージを手動でインストールします。
nginx がハードウェアセキュリティートークンからサーバー証明書をロードできません。
nginx の Web サーバーは、PKCS#11 モジュールを利用してハードウェアセキュリティートークンから直接 TLS 秘密鍵を読み込むようになりました。ただし、現在では、PKCS#11 URI を使用してハードウェアのセキュリティートークンからサーバー証明書を読み込むことはできません。この問題を回避するには、ファイルシステム上にサーバー証明書を保存します。
php-opcache が PHP 7.2 とともにインストールされると、PHP 7.2 で php-fpm により、SELinux AVC 拒否が発生します。
php-opcache パッケージがインストールされると、FastCGI Process Manager (php-fpm) により SELinux AVC 拒否が生じます。この問題を回避するには、/etc/php.d/10-opcache.ini ファイルのデフォルト設定を以下のように変更します。
opcache.huge_code_pages=0
この問題は、php: 7.3 ではなく、php:7.2 ストリームにのみ影響することに注意してください。
mod_wsgi パッケージが依存関係としてインストールされると、このパッケージ名が欠落します。
BZ#1779705 に記載されているように、mod_wsgi のインストールが変更され、python3-mod_wsgi パッケージにより mod_wsgi 名が提供されなくなりました。mod_wsgi モジュールのインストール時に、完全なパッケージ名を指定する必要があります。今回の変更により、サードパーティーパッケージの依存関係で問題が発生します。
mod_wsgi という名前の依存関係が必要なサードパーティーのパッケージをインストールしようとすると、以下のようなエラーが返されます。
Error: Problem: conflicting requests - nothing provides mod_wsgi needed by package-requires-mod_wsgi.el8.noarch
この問題を回避するには、以下のいずれかを実行します。
-
python3-mod_wsgiの完全なパッケージ名が必要なパッケージをリビルドします (または、サードパーティーベンダーに新しいビルドをリクエストしてください)。 mod_wsgi のパッケージ名でメタパッケージを作成します。
-
mod_wsgiの名前を渡す空のメタパッケージをご自身で構築します。 -
このメタパッケージを含むリポジトリーの
.repo設定ファイルにmodule_hotfixes=Trueの行を追加します。 -
python3-mod_wsgiを手作業でインストールします。
-
5.7.9. コンパイラーおよび開発ツール
GCC により生成された合成関数により SystemTap が混乱する
GCC の最適化により、その他の関数を部分的にインラインにコピーした合成関数を生成する場合があります。SystemTap や GDB などのツールは、これらの合成関数と実関数を区別できません。これにより、SystemTap は、合成関数と実関数の両方のエントリーポイントにプローブを置くため、1 つの実関数呼び出しに対して、複数のプローブを登録します。
この問題を回避するには、SystemTap スクリプトを変更して再帰を検出し、インライン化された部分関数に関連するプローブの配置を防ぎます。
このサンプルスクリプト
probe kernel.function("can_nice").call { }は、以下のように変更できます。
global in_can_nice%
probe kernel.function("can_nice").call {
in_can_nice[tid()] ++;
if (in_can_nice[tid()] > 1) { next }
/* code for real probe handler */
}
probe kernel.function("can_nice").return {
in_can_nice[tid()] --;
}このスクリプト例では、不明な kprobes や kretprobes、または、真の意図的な再帰など、考えられるすべてのシナリオが考慮されているわけではありません。
(BZ#1169184)
5.7.10. ID 管理
/etc/nsswitch.conf を変更するには、手動によるシステムの再起動が必要です。
authselect select profile_id コマンドの実行など、/etc/nsswitch.conf ファイルを変更した場合は、関連するすべてのプロセスで、更新バージョンの /etc/nsswitch.conf ファイルが使用されるように、システムを再起動する必要があります。システムを再起動できない場合は、システムを Active Directory (System Security Services Daemon (SSSD) または winbind) に追加するサービスを再起動します。
files ドメインが有効である場合は、SSSD が、ローカルユーザーの LDAP グループメンバーシップを誤って返します。
System Security Services Daemon (SSSD) が、ローカルファイルからユーザーを提供し、sssd.conf ファイルの [domain/LDAP] セクションの ldap_rfc2307_fallback_to_local_users 属性が True に設定されている場合は、ファイルのプロバイダーには他のドメインのグループメンバーシップが含まれません。これにより、ローカルユーザーが LDAP グループのメンバーである場合、id local_user コマンドはユーザーの LDAP グループメンバーシップを返しません。この問題を回避するには、暗示の files ドメインを無効にするため、次の
enable_files_domain=False
を /etc/sssd/sssd.conf ファイルの [sssd] セクションに追加します。
これにより、id local_user が、ローカルユーザーの正しい LDAP グループメンバーシップを返します。
SSSD が同じ優先順位を持つ複数の証明書一致ルールを正しく処理しません。
指定した証明書が、優先順位が同じ複数の証明書の一致ルールに一致する場合、System Security Services Daemon (SSSD) は、いずれか一方のみを使用します。これを回避するには、| (or) 演算子で連結した個々のルールのフィルターで設定される LDAP フィルターを持つ 1 つの証明書一致ルールを使用します。証明書一致ルールの例は、man ページの sss-certamp (5) を参照してください。
(BZ#1447945)
複数のドメインが定義されている場合は、プライベートグループを auto_private_group = hybrid で作成できません。
複数のドメインが定義され、最初のドメイン以外のドメインによってハイブリッドオプションが使用されると、プライベートグループは、auto_private_group = hybrid オプションでの作成に失敗します。暗黙的なファイルドメインが sssd.conf ファイルの AD または LDAP ドメインとともに定義され、MPG_HYBRID としてマークされていない場合、SSSD は uid=gid のユーザーに対してプライベートグループを作成し、この gid を持つグループは AD または LDAP に存在しません。
sssd_nss レスポンダーは、最初のドメインの auto_private_groups オプションの値のみを確認します。これにより、RHEL 8 でデフォルトのセットアップを含む、複数のドメインが設定されているセットアップでは、auto_private_group オプションを指定しても効果が得られません。
この問題を回避するには、sssd.conf の sssd セクションで enable_files_domain = false を設定します。その結果、enable_files_domain オプションが false に設定されていると、sssd は、アクティブなドメインリストの開始に id_provider=files とともにドメインを追加しないため、このバグは発生しません。
(BZ#1754871)
python-ply は FIPS との互換性がありません。
python-ply パッケージの YACC モジュールは、MD5 ハッシュアルゴリズムを使用して YACC 署名のフィンガープリントを生成します。ただし、FIPS モードは、セキュリティー以外のコンテキストでのみ許可される MD5 の使用をブロックします。そのため、python-ply は FIPS と互換性がありません。FIPS モードのシステムでは、ply.yacc() への呼び出しに失敗し、次のエラーメッセージが表示されます。
UnboundLocalError: local variable 'sig' referenced before assignment
この問題は python-pycparser および python-cffi のいくつかのユースケースに影響します。この問題を回避するには、/usr/lib/python3.6/site-packages/ply/yacc.py ファイルの 2966 行目を変更し、sig = md5() を sig = md5(usedforsecurity=Fals) に置き換えます。これにより、python-ply を FIPS モードで使用できます。
FreeRADIUS が 249 文字を超える Tunnel-Passwords を断りなく切り捨てます。
Tunnel-Password が 249 文字を超える場合、FreeRADIUS サービスはそのパスワードを断りなく切り捨てます。これにより、他のシステムと矛盾する想定外のパスワードになる可能性があります。
この問題を回避するには、249 文字以下のパスワードを選択します。
すべての KRA メンバーが非表示レプリカの場合は、KRA のインストールに失敗します。
最初の KRA インスタンスが非表示レプリカにインストールされている場合、Key Recovery Authority (KRA) がすでに存在するクラスターでは ipa-kra-install ユーティリティーで問題が発生します。そのため、これ以上、追加の KRA インスタンスをクラスターに追加することはできません。
この問題を回避するには、新しい KRA インスタンスを追加する前に、KRA ロールが割り当てられた非表示レプリカを解除します。Ipa-kra-install が正常に終了してから、レプリカを再度非表示にできます。
Directory Server は、検索フィルターで使用されている属性がスキーマに欠如している場合に警告します。
nsslapd-verify-filter-schema パラメーターを warn-invalid に設定している場合、Directory Server は、スキーマで定義されていない属性で検索操作を処理し、警告を記録します。この設定では、属性がスキーマに定義されているかどうかにかかわらず、Directory Server は検索結果で要求された属性を返します。
Directory Server の今後のバージョンでは、nsslapd-verify-filter-schema のデフォルト設定が厳格なチェックを実施するように変更されます。新しいデフォルトでは、スキーマで欠如している属性について警告し、リクエストを拒否するか、部分的な結果のみを返します。
ipa-healthcheck-0.4 は古いバージョンの ipa-healthcheck を廃止しません
Healthcheck ツールは、ipa-healthcheck と ipa-healthcheck-core 2 つのサブパッケージに分割されました。ただし、ipa-healthcheck-core サブパッケージのみが古いバージョンの ipa-healthcheck に正しく設定されています。その結果、Healthcheck を更新すると ipa-healthcheck-core のみがインストールされ、更新後に ipa-healthcheck コマンドが機能しなくなります。
この問題を回避するには、yum install ipa-healthcheck-0.4 を使用して ipa-healthcheck-0.4 サブパッケージを手動でインストールします。
ldap_id_use_start_tls オプションのデフォルト値を使用する場合の潜在的なリスク
ID ルックアップに TLS を使用せずに ldap:// を使用すると、攻撃ベクトルのリスクが生じる可能性があります。特に、中間者 (MITM) 攻撃は、攻撃者が、たとえば、LDAP 検索で返されたオブジェクトの UID または GID を変更することによってユーザーになりすますことを可能にする可能性があります。
現在、TLS を強制する SSSD 設定オプション ldap_id_use_start_tls は、デフォルトで false に設定されています。セットアップが信頼できる環境で動作していることを確認し、id_provider = ldap に暗号化されていない通信を使用しても安全かどうかを判断してください。注記: id_provider = ad および id_provider = ipa は、SASL および GSSAPI によって保護された暗号化接続を使用するため、影響を受けません。
暗号化されていない通信を使用することが安全ではない場合は、/etc/sssd/sssd.conf ファイルで ldap_id_use_start_tls オプションを true に設定して TLS を強制します。デフォルトの動作は、RHEL の将来のリリースで変更される予定です。
(JIRA:RHELPLAN-155168)
5.7.11. デスクトップ
Wayland セッションの制限
Red Hat Enterprise Linux 8 では、GNOME 環境および GNOME Display Manager (GDM) のデフォルトのセッションタイプとして、以前の RHEL メジャーバージョンで使用されていた X11 セッションに代わり、Wayland が使用されます。
以下の機能は、Wayland の下では現在利用できないか、期待どおりに動作しません。
-
xrandrなどの X11 設定ユーティリティーは、ハンドリング、解像度、ローテーション、レイアウトのアプローチが異なるため、Wayland では動作しません。ディスプレイ機能は、GNOME 設定を使用して設定できます。 - 画面の録画とリモートデスクトップでは、アプリケーションが Wayland のポータル API をサポートする必要があります。特定のレガシーアプリケーションはポータル API をサポートしません。
- Wayland では、ポインターのアクセシビリティーは利用できません。
- クリップボードマネージャーは利用できません。
Wayland 上の GNOME Shell は、ほとんどのレガシー X11 アプリケーションで発行されたキーボードグラブを無視します。
/org/gnome/mutter/wayland/xwayland-grab-access-rulesGSettings キーを使用して、X11 アプリケーションがキーボードグラブを発行するようにできます。デフォルトでは、Wayland 上の GNOME Shell により、以下のアプリケーションがキーボードグラブを発行できます。- GNOME Boxes
- Vinagre
- Xephyr
-
virt-manager、virt-viewer、およびremote-viewer -
vncviewer
- ゲスト仮想マシン (VM) 内のWayland には安定性とパフォーマンスの問題があります。RHEL は、仮想マシンで実行している場合に X11 セッションに自動的にフォールバックします。
X11 GNOME セッションを使用していた RHEL 7 システムから RHEL 8 にアップグレードすると、システムでは引き続き X11 が使用されます。また、次のグラフィックドライバーが使用されている場合は、自動的に X11 にフォールバックします。
- プロプライエタリー NVIDIA ドライバー
-
cirrusドライバー -
mgaドライバー -
aspeedドライバー
Wayland の使用は手動で無効にできます。
-
GDM の Wayland を無効にするには、
/etc/gdm/custom.confファイルにWaylandEnable=falseオプションを設定します。 - GNOME セッションで Wayland を無効にするには、ログイン名を入力してから、ログイン画面の歯車メニューでレガシーの X11 オプションを選択します。
Wayland の詳細は https://wayland.freedesktop.org/ を参照してください。
ドラッグアンドドロップが、デスクトップとアプリケーション間で機能しません。
gnome-shell-extensions パッケージのバグにより、ドラッグアンドドロップ機能は現在、デスクトップとアプリケーションの間では機能しません。この機能のサポートは、今後のリリースで追加される予定です。
ソフトウェアリポジトリーからの flatpak リポジトリーの無効化ができません。
現時点で、GNOME Software ユーティリティーの Software Repositories ツールで flatpak リポジトリーを無効化または削除することはできません。
Generation 2 の RHEL 8 仮想マシンが Hyper-V Server 2016 ホストで起動できない場合があります。
Microsoft Hyper-V Server 2016 ホストで実行している仮想マシンで RHEL 8 をゲストオペレーティングシステムとして使用すると、仮想マシンが起動しなくなり、GRUB ブートメニューに戻る場合があります。さらに、以下のエラーが Hyper-V イベントログに記録されます。
The guest operating system reported that it failed with the following error code: 0x1E
このエラーは、Hyper-V ホストの UEFI ファームウェアバグが原因で発生します。この問題を回避するには、Hyper-V Server 2019 をホストとして使用します。
(BZ#1583445)
システムクラッシュにより、fadump 設定が失われることがあります。
この問題は、ファームウェア支援ダンプ (fadump) が有効になっているシステムで確認されています。また、ブートパーティションは XFS などのジャーナリングファイルシステムにあります。システムクラッシュにより、ダンプサポートが有効でない古い initrd をブートローダーがロードする可能性があります。したがって、復元後、システムは vmcore ファイルをキャプチャーせず、fadump 設定が失われる可能性があります。
この問題を回避するには、以下を実行します。
/bootが別のパーティションの場合は、以下を実行します。- kdump サービスを再起動します。
root ユーザーで以下のコマンドを実行するか、CAP_SYS_ADMIN 権限を持つユーザーアカウントを使用します。
# fsfreeze -f # fsfreeze -u
-
/bootが別のパーティションではない場合は、システムを再起動します。
(BZ#1723501)
5.7.12. グラフィックインフラストラクチャー
sudo コマンドを使用してグラフィカルアプリケーションを実行できません。
権限が昇格されたユーザーで、グラフィカルアプリケーションを実行しようとすると、エラーメッセージが表示され、アプリケーションを開くことができません。この障害は、 Xauthority ファイルで、通常ユーザーの認証情報を使用して認証するように、Xwayland に制限が加えられているため発生します。
この問題を回避するには、sudo -E コマンドを使用して、root ユーザーとしてグラフィカルアプリケーションを実行します。
radeon がハードウェアを適切なハードウェアリセットに失敗します。
現在、radeon カーネルドライバーは、kexec コンテキストでハードウェアを正しくリセットしません。代わりに radeon がフェイルオーバーします。これにより、kdump サービスの残りの部分が失敗します。
この問題を回避するには、/etc/kdump.conf ファイルに以下の行を追加して、kdump で radeon をブラックリストに指定します。
dracut_args --omit-drivers "radeon" force_rebuild 1
マシンと kdump を再起動します。kdumpの起動後、設定ファイルから force_rebuild 1 行が削除される可能性があります。
このシナリオでは、kdump 中にグラフィックは利用できませんが、kdump は正常に動作します。
(BZ#1694705)
1 つの MST トポロジーで複数の HDR ディスプレイを使用すると、電源が入らないことがあります。
nouveau ドライバーの NVIDIA Turing GPUs を使用するシステムで、DisplayPort ハブ (ラップトップのドックなど) を使用して HDR プラグインのサポートがあるモニターを複数接続すると、以前の RHEL リリースではできていたにも拘らず、すべてのディスプレイの電源が入らないことがあります。これは、全ディスプレイをサポートする帯域幅がハブ上にないと、システムが誤って判断してしまうことが原因で発生します。
(BZ#1812577)
5.7.13. Web コンソール
非特権ユーザーがサブスクリプションページにアクセスできます。
管理者以外のユーザーが Web コンソールの サブスクリプションページ に移動すると、Web コンソールでは、Cockpit had an unexpected internal error (Cockpit に予期しない内部エラーが発生しました) という一般的なエラーメッセージが表示されます。
この問題を回避するには、権限のあるユーザーで Web コンソールにサインインし、Reuse my password for privileged tasks チェックボックスをチェックします。
5.7.14. 仮想化
Windows Server 2019 ホストの RHEL 8 仮想マシンで GUI ディスプレイのパフォーマンスが下がります。
Windows Server 2019 ホストのグラフィカルモードで RHEL 8 をゲストオペレーティングシステムとして使用すると、GUI ディスプレイのパフォーマンスが下がり、ゲストのコンソール出力に現在必要なよりも長い時間がかかります。
これは、Windows 2019 ホストで既知の問題で、Microsoft が修正を保留しています。この問題を回避するには、SSH を使用してゲストに接続するか、ホストとして Windows Server 2016 を使用します。
(BZ#1706541)
QXL で、Wayland を使用する仮想マシンの複数のモニターを表示できません。
remote-viewer ユーティリティーを使用して、Wayland ディスプレイサーバーを使用している仮想マシンのモニターを複数表示すると、仮想マシンが応答しなくなり、Waiting for display というステータスメッセージが永久に表示されます。
この問題を回避するには、Wayland を使用する仮想マシンの GPU デバイスとして qxl の代わりに virtio-gpu を使用します。
(BZ#1642887)
virsh iface-\* コマンドが一貫して動作しません。
現在、virsh iface-* コマンド (virsh iface-start、virsh iface-destroy など) は、設定の依存関係が原因で頻繁に失敗します。したがって、ホストネットワーク接続の設定および管理には virsh iface-\* コマンドを使用しないことが推奨されます。代わりに、NetworkManager プログラムとその関連管理アプリケーションを使用します。
(BZ#1664592)
RHEL 8 仮想マシンが、Witherspoon ホストで起動できないことがあります。
RHEL 8 仮想マシン (VM) で pseries -rhel7.6.0-sxxm マシンタイプを使用すると、DD 2.2 または DD2.3 CPU を使用する Power9 S922LC for HPC ホストで起動できない場合があります。
代わりに仮想マシンを起動しようとすると、以下のエラーメッセージが出力されます。
qemu-kvm: Requested safe indirect branch capability level not supported by kvm
この問題を回避するには、仮想マシンの XML 設定を次のように設定します。
<domain type='qemu' xmlns:qemu='http://libvirt.org/schemas/domain/qemu/1.0'>
<qemu:commandline>
<qemu:arg value='-machine'/>
<qemu:arg value='cap-ibs=workaround'/>
</qemu:commandline>IBM POWER 仮想マシンが、空の NUMA ノードで正常に動作しません。
現在、RHEL 8 ホストで実行している IBM POWER 仮想マシン (VM) が、メモリーを使用せず (memory='0')、CPU も使用しない NUMA ノードで設定されていると、仮想マシンが起動しません。したがって、Red Hat は、RHEL 8 では、そういった空の NUMA ノードを持つ IBM POWER 仮想マシンを使用しないことを強く推奨しています。
(BZ#1651474)
AMD EPYC でホストパススルーモードを使用する際に、SMT CPU トポロジーが仮想マシンで検出されません。
AMD EPYC ホストで行われた CPU ホストパススルーモードで仮想マシンを起動すると、TOPOEXT 機能フラグは存在しません。したがって、仮想マシンは、コアごとに複数のスレッドを持つ仮想 CPU トポロジーを検出できません。この問題を回避するには、ホストパススルーの代わりに EPYC CPU モデルを使用して仮想マシンを起動します。
RHEL 8.2 仮想マシンのディスク識別子は、仮想マシンの再起動で変わる可能性があります。
Hyper-V ハイパーバイザーのゲストオペレーティングシステムとして RHEL 8.2 で仮想マシン (VM) を使用する場合は、仮想マシンの再起動時に仮想マシンの仮想ディスクのデバイス識別子が変わることがあります。たとえば、最初は /dev/sda として識別されていたディスクが、dev/sdb になる場合があります。これにより、仮想マシンが起動に失敗し、仮想マシンのディスクを参照するスクリプトが動作しなくなる可能性があります。
この問題を回避するには、Red Hat は、仮想マシンのディスクに永続的な名前を設定することを強く推奨します。詳細は、Microsoft Azure のドキュメント (https://docs.microsoft.com/en-us/azure/virtual-machines/troubleshooting/troubleshoot-device-names-problems) を参照してください。
(BZ#1777283)
多数の virtio-blk ディスクを使用すると、仮想マシンが起動しないことがあります。
多数の virtio-blk デバイスを仮想マシンに追加すると、プラットフォームで利用可能な割り込みベクトルの数が使い切られる可能性があります。これが発生すると、仮想マシンのゲスト OS は起動できず、dracut-initqueue[392]: Warning: Could not boot エラーが表示されます。
virtio-blk を使用して仮想マシンに LUN デバイスを割り当てると機能しません。
q35 マシンタイプは、移行用の virtio 1.0 デバイスをサポートしないため、RHEL 8 では virtio 1.0 で非推奨となった機能はサポートされません。特に、RHEL 8 ホストで virtio-blk デバイスから SCSI コマンドを送信することはできません。したがって、virtio-blk コントローラーを使用する場合は、物理ディスクを LUN デバイスとして仮想マシンに割り当てると失敗します。
物理ディスクをゲストオペレーティングシステムを通して渡すことは引き続き可能ですが、device='lun' オプションではなく、device='disk' オプションで設定する必要があることに留意してください。
(BZ#1777138)
RHEL 7-ALT ホストから RHEL 8 への POWER9 ゲストの移行に失敗する
現在のリリースでは、RHEL 7-ALT ホストシステムから RHEL 8 に POWER9 仮想マシンを移行すると、Migration status: active のステータスで応答がなくなります。
この問題を回避するには、RHEL 7-ALT ホストで Transparent Huge Pages (THP) を無効にすることで、移行が正常に完了します。
(BZ#1741436)
5.7.15. サポート関連
redhat-support-tool が FUTURE 暗号化ポリシーを使用すると機能しません。
カスタマーポータル API の証明書が使用する暗号化キーは FUTURE のシステム全体の暗号化ポリシーが定義する要件を満たさないので、現時点で redhat-support-tool ユーティリティーは、このポリシーレベルでは機能しません。
この問題を回避するには、カスタマーポータル API への接続中に DEFAULT 暗号化ポリシーを使用します。
5.7.16. コンテナー
UDICA が 1.0 の安定したストリームと連携するように想定されていません。
UDICA (コンテナーの SELinux ポリシーを生成するツール ) は、container-tools:1.0 モジュールストリームの podman 1.0.x で実行されるコンテナーで機能するように想定されていません。
(JIRA:RHELPLAN-25571)
Podman での FIPS サポートに関する注意事項
Federal Information Processing Standard (FIPS) を使用するには、認定済みモジュールを使用する必要があります。以前のバージョンでは、Podman は起動時に適切なフラグを有効にして、コンテナーに認定モジュールを正しくインストールしていました。ただし、本リリースでは、Podman は FIPS システム全体の crypto-policy の形式でシステムによって提供される追加アプリケーションヘルパーを適切に設定しません。認定モジュールでは、システム全体の crypto-policy を設定する必要はありませんが、適切な方法で暗号化モジュールを使用するアプリケーションが強化されます。この問題を回避するには、他のアプリケーションコードを実行する前に、コンテナーを変更して update-crypto-policies --set FIPS コマンドを実行します。
