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 specify 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 署名は、GnuTLS セキュアな通信ライブラリーにより、セキュアでないものとして拒否されます。したがって、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-rules
GSettings キーを使用して、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
コマンドを実行します。