RHEL 7 から RHEL 8 へのアップグレード
Red Hat Enterprise Linux 7 から Red Hat Enterprise Linux 8 へのインプレースアップグレードの手順
概要
多様性を受け入れるオープンソースの強化
Red Hat では、コード、ドキュメント、Web プロパティーにおける配慮に欠ける用語の置き換えに取り組んでいます。まずは、マスター (master)、スレーブ (slave)、ブラックリスト (blacklist)、ホワイトリスト (whitelist) の 4 つの用語の置き換えから始めます。この取り組みは膨大な作業を要するため、今後の複数のリリースで段階的に用語の置き換えを実施して参ります。詳細は、Red Hat CTO である Chris Wright のメッセージ を参照してください。
Red Hat ドキュメントへのフィードバック (英語のみ)
Red Hat ドキュメントに関するご意見やご感想をお寄せください。また、改善点があればお知らせください。
特定の文章に関するコメントの送信
- Multi-page HTML 形式でドキュメントを表示し、ページが完全にロードされてから右上隅に Feedback ボタンが表示されていることを確認します。
- カーソルを使用して、コメントを追加するテキスト部分を強調表示します。
- 強調表示されたテキストの近くに表示される Add Feedback ボタンをクリックします。
- フィードバックを追加し、Submit をクリックします。
Bugzilla からのフィードバック送信 (アカウントが必要)
- Bugzilla の Web サイトにログインします。
- Version メニューから正しいバージョンを選択します。
- Summary フィールドにわかりやすいタイトルを入力します。
- Description フィールドに、ドキュメントの改善に関するご意見を記入してください。ドキュメントの該当部分へのリンクも追加してください。
- Submit Bug をクリックします。
主な移行の用語
以下の移行用語はソフトウェア業界で一般的に使用されますが、これらの定義は Red Hat Enterprise Linux (RHEL) に固有のものです。
更新
ソフトウェアパッチと呼ばれることもあります。更新は現行バージョン、オペレーティングシステム、または実行中のソフトウェアに追加されます。ソフトウェア更新は、問題またはバグに対応し、テクノロジーの操作が改善されます。RHEL では、更新は、RHEL 8.1 から 8.2 への更新といったマイナーリリースに関連します。
アップグレード
アップグレードは、現在実行しているアプリケーション、オペレーティングシステム、またはソフトウェアを置き換える場合です。通常、まず Red Hat の指示に従い、データをバックアップします。RHEL をアップグレードすると、以下の 2 つのオプションがあります。
- In-place upgrade: インプレースアップグレードの場合は、以前のバージョンを削除せずに、以前のバージョンを新しいバージョンに置き換えます。設定や設定と共にインストールされたアプリケーションとユーティリティーは、新規バージョンに組み込まれています。
- clean install: clean install は、以前にインストールされたオペレーティングシステム、システムデータ、設定、およびアプリケーションのすべてのトレースを削除し、最新バージョンのオペレーティングシステムをインストールします。システムに以前のデータまたはアプリケーションが必要ない場合や、以前のビルドに依存しない新規プロジェクトを開発する場合は、クリーンインストールに適しています。
オペレーティングシステムへの変換
変換は、オペレーティングシステムを別の Linux ディストリビューションから Red Hat Enterprise Linux に変換する際に使用されます。通常、まず Red Hat の指示に従い、データをバックアップします。
マイグレーション
通常、マイグレーションとは、ソフトウェアやハードウェアといったプラットフォームの変更を示しています。Windows から Linux への移行はマイグレーションです。ユーザーがあるラップトップから別のラップトップに移動したり、企業があるサーバーから別のサーバーに移動することもマイグレーションです。ただし、ほとんどのマイグレーションにはアップグレードも含まれており、この2つの用語が同様の意味で使用されることがあります。
- RHEL へのマイグレーション: 既存のオペレーティングシステムを RHEL に変換すること。
- RHEL 間でのマイグレーション: RHEL のあるバージョンから別のバージョンへのアップグレード。
第1章 サポート対象のアップグレードパス
インプレースアップグレードは、システムの RHEL 7 オペレーティングシステム (OS) を RHEL 8 バージョンに置き換えます。
現在、RHEL 7 から次の RHEL 8 マイナーバージョンへのインプレースアップグレードを実行できます。
表1.1 サポート対象のアップグレードパス
アーキテクチャーおよびシステム設定 | ソース OS バージョン | ターゲット OS バージョン |
---|---|---|
64 ビット Intel、IBM POWER 8(リトルエンディアン)、および 64 ビット IBM Z | RHEL 7.9 | RHEL 8.6 |
RHEL 8.8 (デフォルト) | ||
IBM POWER 9 (リトルエンディアン) および IBM Z (Structure A) | RHEL 7.6 | RHEL 8.4 |
RHEL with SAP HANA | RHEL 7.9 | RHEL 8.2 |
RHEL 8.6(デフォルト) |
サポート対象のアップグレードパスの詳細は、Supported in-place upgrade paths for Red Hat Enterprise Linux を参照してください。
第2章 アップグレードの計画
インプレースアップグレードは、システムを RHEL の次のメジャーバージョンにアップグレードする方法です。この方法は、推奨され、サポートされています。
RHEL 8 にアップグレードする前に、次の点を考慮してください。
オペレーティングシステム - オペレーティングシステムは、以下の条件下で、
Leapp
ユーティリティーによりアップグレードされます。Server バリアントの 最新の RHEL 7 バージョン がインストールされている。現在は、以下が最新です。
- 64 ビット Intel アーキテクチャー、IBM POWER 8(リトルエンディアン)、64 ビット IBM Z アーキテクチャー上の RHEL 7.9、64 ビット Intel アーキテクチャーで SAP HANA を使用している場合
カーネルバージョン 4.14 を必要とする アーキテクチャー (BM POWER 9 (リトルエンディアン)、または 64 ビット IBM Z (Structure A)) での RHEL 7.6
注記IBM POWER 9(リトルエンディアン) と 64 ビット IBM Z(Structure A) のアーキテクチャーは、ライフサイクルを終えました。これらのアーキテクチャーの最後のアップグレードパスは、RHEL 7.6 から RHEL 8.4 までです。新しいアップグレードパス、機能、バグ修正など、インプレースアップグレードの以降のリリースには、これらのアーキテクチャーは含まれません。
詳細は Supported in-place upgrade paths for Red Hat Enterprise Linux を参照してください。
- RHEL 8 の最小 ハードウェア要件 が満たされている。
- 最新の RHEL 7.9 およびターゲットオペレーティングシステム (OS) バージョン (RHEL 8.6 など) のコンテンツにアクセスできます。詳細は、アップグレードに向けて RHEL 7 システムの準備 を参照してください。
-
アプリケーション -
Leapp
を使用して、システムにインストールされているアプリケーションを移行できます。ただし、特定のケースでは、アップグレード時にLeapp
が実行するアクションを指定するカスタムアクターを作成する必要があります。たとえば、アプリケーションの再設定や特定のハードウェアドライバーのインストールなどです。詳細は、Handling the migration of your custom and third-party applications を参照してください。Red Hat はカスタムアクターをサポートしていないことに注意してください。 セキュリティー - アップグレード前にこの要素を評価し、アップグレードプロセスの完了時に追加の手順を実行する必要があります。特に以下の点を考慮してください。
- アップグレードの前に、システムが準拠する必要のあるセキュリティー標準を定義し、RHEL 8 のセキュリティー変更 を理解します。
-
Leapp
ユーティリティーは、アップグレードプロセス時に SELinux モードを Permissive に設定します。 Federal Information Processing Standard (FIPS) モードでのシステムのインプレースアップグレードは、
Leapp
で完全に自動化することはできません。FIPS モード で実行されている RHEL 7 システムをアップグレードする必要がある場合は、次のことを行う必要があります。重要すべての暗号化キーを FIPS 140-2 標準に準拠したものにするには、すでにデプロイされているシステムのインプレースアップグレードを実行する代わりに、FIPS モードで新しいインストール を開始します。次の手順は、会社のセキュリティーポリシーでこの代替アップグレードプロセスが許可されている場合、およびアップグレードしたシステムですべての暗号化キーの再生成と再評価を確実に実行できる場合にのみ使用してください。
- RHEL 7 で FIPS モードを無効にします。
-
Leapp
を使用してシステムをアップグレードします。他のインプレースアップグレードと同様に、アップグレード前、アップグレード、およびアップグレード後の手順に従う必要があります。 - RHEL 8 で FIPS モードを有効にします。詳細は、RHEL 8 セキュリティーの強化ドキュメントの FIPS モードへのシステムの切り替え を参照してください。
- システムで暗号化キーを再生成します。詳細は、付録C RHEL 8 の暗号化キーの場所 を参照してください。
- アップグレードが完了したら、セキュリティーポリシーを再評価し、再適用します。アップグレード中に無効になった、または RHEL 8 で新たに導入されたセキュリティーポリシーを適用する方法は、セキュリティーポリシーの適用 を参照してください。
ストレージとファイルシステム - アップグレードの前に必ずシステムをバックアップしてください。たとえば、Relax-and-Recover (ReaR) ユーティリティー、LVM スナップショット、RAID 分割、または仮想マシンスナップショットを使用できます。
注記ファイルシステム形式はそのままです。その結果、ファイルシステムには、最初に作成されたときと同じ制限があります。
- 高可用性 - 高可用性アドオンを使用している場合は、ナレッジベース記事 Recommended Practices for Applying Software Updates to a RHEL High Availability or Resilient Storage Cluster に従ってください。
- ダウンタイム - アップグレードプロセスには数分から数時間かかる場合があります。
- Satellite - Satellite を介してホストを管理する場合は、Satellite Web UI を使用して、RHEL 7 から RHEL 8 に複数のホストを同時にアップグレードできます。詳細は、次の Red Hat Enterprise Linux リリースへのホストのアップグレード を参照してください。
- SAP HANA - SAP HANA を使用している場合は、SAP 環境を RHEL 7 から RHEL 8 にインプレースアップグレードする方法 に従ってください。SAP HANA を使用した RHEL のアップグレードパスは異なる場合があることに注意してください。
- パブリッククラウド: インプレースアップグレードは、Red Hat Update Infrastructure (RHUI) を使用して Amazon Web Services (AWS)、Microsoft Azure、Google Cloud Platform のオンデマンドインスタンスでサポートされます。インプレースアップグレードは、RHEL サブスクリプションに Red Hat Subscription Manager (RHSM) を使用するすべてのパブリッククラウドの Bring Your Own Subscription インスタンスでもサポートされます。
-
言語: すべての
Leapp
のレポート、ログ、その他の生成されたドキュメントは、言語設定に関わらず、英語で表示されます。 - ブートローダー - RHEL 7 または RHEL 8 でブートローダーを BIOS から UEFI に切り替えることはできません。RHEL 7 システムが BIOS を使用し、RHEL 8 システムで UEFI を使用する場合は、インプレースアップグレードの代わりに RHEL 8 の新規インストールを実行します。詳細は、Is it possible to switch the BIOS boot to UEFI boot on preinstalled Red Hat Enterprise Linux machine? を参照してください。
既知の制限 - 現在、
Leapp
の注目すべき既知の制限には以下が含まれます。- 現在、ディスク全体またはパーティションの暗号化、またはファイルシステムの暗号化は、インプレースアップグレードの対象となるシステムでは使用できません。
- ネットワークベースのマルチパスやネットワークストレージマウントは、システムパーティション (iSCSI、NFS など) として使用できません。
- 現在、インプレースアップグレードは、RHEL サブスクリプションに Red Hat Update Infrastructure を使用して RHSM を使用しない、残りのパブリッククラウド (Huawei Cloud、Alibaba Cloud) のオンデマンドインスタンスではサポートされません。
- Ansible Tower がインストールされているシステムでは、インプレースアップグレードはサポートされていません。代わりに、ナレッジベースソリューション How do I migrate my Ansible Tower installation from RHEL7 to RHEL8 を参照してください。
既知の問題 も参照してください。
Red Hat Insights を使用して、Insights に登録したどのシステムが RHEL 8 に対する対応アップグレードパスであるかを確認できます。これを行うには、Insights でそれぞれの Advisor の推奨事項 に移動し、Actions ドロップダウンメニューで推奨事項を有効にして、影響を受けるシステム 見出しの下のリストを調べます。Advisor 推奨は RHEL 7 マイナーバージョンのみを考慮し、システムのアップグレード前の評価は行わないことに注意してください。Advisor-service recommendations overview も参照してください。
第3章 アップグレードの準備
アップグレード後に問題を回避し、システムを RHEL の次のメジャーバージョンにアップグレードできることを確認するには、アップグレード前に必要なすべての準備手順を完了してください。
すべてのシステムで、Preparing a RHEL 7 system for the upgrade で説明されている準備手順を実施する必要があります。さらに、Satellite Server に登録されているシステムでは、Satellite に登録されたシステムのアップグレードの準備 で説明されている準備手順も実行する必要があります。
3.1. アップグレードに向けて RHEL 7 システムの準備
この手順では、Leapp
ユーティリティーを使用して、RHEL 8 へのインプレースアップグレードを実行する前に必要な手順を説明します。
アップグレードプロセス中に Red Hat Subscription Manager を使用する予定がない場合は、Upgrading to RHEL 8 without Red Hat Subscription Manager を参照してください。
前提条件
- システムは、アップグレードの計画 に記載されている条件を満たしている。
手順
- Red Hat Subscription Manager を使用して、システムが Red Hat コンテンツ配信ネットワーク (CDN) または Red Hat Satellite に正常に登録されていることを確認します。
- システムが Satellite Server に登録されている場合は、アップグレードに向けた Satellite 登録システムの準備 の手順を実行して、システムがアップグレードの要件を満たしていることを確認します。
Red Hat Enterprise Linux Server サーバーのサブスクリプション が割り当てられていることを確認します。
# subscription-manager list --installed +-------------------------------------------+ Installed Product Status +-------------------------------------------+ Product Name: Red Hat Enterprise Linux Server Product ID: 69 Version: 7.9 Arch: x86_64 Status: Subscribed
製品名に Server が表示され、ステータスとして サブスクライブされ ているはずです。
適切なリポジトリーが有効になっていることを確認します。次のコマンドは、64 ビット Intel アーキテクチャーのリポジトリーの一覧を示します。他のアーキテクチャーについては、RHEL 7 リポジトリー を参照してください。
Base リポジトリーを有効にします。
# subscription-manager repos --enable rhel-7-server-rpms
Leapp
およびその依存関係が利用可能な Extras リポジトリーを有効にします。# subscription-manager repos --enable rhel-7-server-extras-rpms
注記必要に応じて、オプション (CodeReady Linux Builder とも呼ばれる) または補助リポジトリーを有効にすることができます。リポジトリー ID の詳細は、RHEL 7 リポジトリー のオプションおよび補足リポジトリーのリストを参照してください。これらのリポジトリーの内容の詳細は、CodeReady Linux Builder リポジトリー および 補足リポジトリー を参照してください。
最新の RHEL 7 コンテンツを使用するように Red Hat Subscription Manager を設定します。
# subscription-manager release --unset
- オプション: カスタムリポジトリーを使用するには、ナレッジベースの記事 Configuring custom repositories を参照してください。
yum-plugin-versionlock
プラグインを使用して、パッケージを特定バージョンにロックする場合は、次のコマンドを実行してロックを解除します。# yum versionlock clear
詳細は 指定したバージョンのパッケージ (または指定したバージョン以前のパッケージ) だけをインストールまたはアップグレードできるように yum の使用を制限する方法 を参照してください。
パブリッククラウドで Red Hat Update Infrastructure(RHUI) を使用してアップグレードする場合は、必要な RHUI リポジトリーを有効にして、必要な RHUI パッケージをインストールし、システムをアップグレードする準備ができていることを確認します。
AWS の場合:
# yum-config-manager --enable rhui-client-config-server-7 # yum-config-manager --enable rhel-7-server-rhui-extras-rpms # yum -y install rh-amazon-rhui-client leapp-rhui-aws
For Microsoft Azure:
# yum-config-manager --enable rhui-microsoft-azure-rhel7 # yum-config-manager --enable rhui-rhel-7-server-rhui-extras-rpms # yum -y install rhui-azure-rhel7 leapp-rhui-azure
注記Azure 仮想マシンをマイナーリリースにロックした場合は、バージョンロックを削除します。詳細は、Switch a RHEL 7.x VM back to non-EUS を参照してください。
- Google Cloud Platform の場合は、ナレッジベース記事 Leapp RHUI packages for Google Cloud Platform (GCP) に従います。
- Docker でコンテナーを管理する場合は、Podman を使用して適切なコンテナーイメージでコンテナーを再作成し、使用中のボリュームを割り当てます。詳細は、How do I migrate my Docker containers to Podman prior to moving from Red Hat Enterprise Linux 7 to Red Hat Enterprise Linux 8? を参照してください。
すべてのパッケージを最新の RHEL 7 バージョンに更新します。
# yum update
システムを再起動します。
# reboot
Leapp
ユーティリティーをインストールします。# yum install leapp-upgrade
現在、
leapp
パッケージのバージョン 0.15.1 以降と、leapp-upgrade-el7toel8
RPM パッケージを含むバージョン 0.18.0 以降のjumpp-repository
パッケージが必要であることに注意してください。注記システムにインターネットアクセスがない場合は、Red Hat カスタマーポータル から以下のパッケージをダウンロードします。
-
leapp
-
leapp-deps
-
python2-leapp
-
leapp-upgrade-el7toel8
-
leapp-upgrade-el7toel8-deps
-
RPM パッケージの変更、RPM リポジトリーマッピング、サポート対象外のドライバーやデバイスなど、必要な追加データファイルの最新バージョンにアクセスできることを確認してください。
重要IBM POWER 9 (リトルエンディアン) または IBM Z (構造 A) アーキテクチャーに RHEL 7.6 を使用している場合は、代わりに Leapp data snapshots for an in-place upgrade ナレッジベース記事に従ってください。
- アップグレードに RHSM を使用する場合で、システムが cloud.redhat.com にアクセスでき、必要なデータファイルの以前のバージョンをダウンロードしていない場合は、それ以上のアクションは必要ありません。データファイルは cloud.redhat.com から自動的にダウンロードされます。
-
プロキシーサーバーを使用して Red Hat CDN にアクセスしている場合は、
$LEAPP_PROXY_HOST
環境変数を定義して、必要なデータファイルの最新バージョンにアクセスします。 必要に応じて、ナレッジベースアーティクル Leapp utility metadata in-place upgrades of RHEL for disconnected upgrades に添付されているデータファイルをダウンロードし、これを
/etc/leapp/files/
ディレクトリーに置きます。これは、以下のシナリオでアップグレードを成功させるために必要になります。- RHUI を使用してパブリッククラウドでアップグレードします。Red Hat サブスクリプションまたは Red Hat カスタマーポータルアカウントをお持ちでない場合は、ナレッジベースの記事にアクセスし、必要なデータパッケージをダウンロードできるように、無料の RHEL 開発者サブスクリプションを作成してください。詳細は How do I get a no-cost Red Hat Enterprise Linux Developer Subscription or renew it? を参照してください。
- お使いのシステムにインターネットアクセスがありません。
- アップグレードに RHSM を使用し、必要なデータファイルの古いバージョンを以前ダウンロードしたが、アップグレードを実行しませんでした (例: 自動化スクリプトの作成など)。古いバージョンのデータファイルを削除して、最新のファイルバージョンを自動的にダウンロードすることもできます。
- アップグレードの失敗を防ぐために一時的にウイルス対策ソフトウェアを無効にします。
設定管理システムがインプレースアップグレードプロセスに干渉しないことを確認します。
-
Puppet、Salt、Chef などのクライアントサーバーアーキテクチャーで設定管理システムを使用する場合は、
leapp preupgrade
コマンドを実行する前にシステムを無効にします。アップグレード時に問題が発生するのを防ぐために、アップグレードが完了するまで設定管理システムを有効にしないでください。 Ansible などのエージェントレスアーキテクチャーで設定管理システムを使用する場合は、Performing the upgrade from RHEL 7 to RHEL 8 で説明されているように、インプレースアップグレード中に Ansible Playbook などの設定およびデプロイメントファイルを実行しないでください。
設定管理システムを使用したアップグレード前およびアップグレードプロセスの自動化は、Red Hat ではサポートされていません。詳細は、Using configuration management systems to automate parts of the Leapp pre-upgrade and upgrade process on Red Hat Enterprise Linux を参照してください。
-
Puppet、Salt、Chef などのクライアントサーバーアーキテクチャーで設定管理システムを使用する場合は、
-
システムで、カーネル (
eth
) が使用する接頭辞に基づいた名前で、複数の Network Interface Card (NIC) が使用されていないことを確認します。RHEL 8 へのインプレースアップグレードの前に別の命名スキームに移行する方法は RHEL 7 でカーネルの NIC 名を使用している場合に RHEL 8 へのインプレースアップグレードを実行する方法 を参照してください。 -
ISO イメージを使用してアップグレードする場合は、ISO イメージにターゲット OS バージョン (RHEL 8.8 など) が含まれていること、およびアップグレードプロセス全体を通じて
Leapp
ユーティリティーがイメージにアクセスできるように永続的なローカルマウントポイントに保存されていることを確認してください。 - システム全体のバックアップまたは仮想マシンのスナップショットが存在することを確認してください。これにより、ご利用の環境で、以下の標準の災害復旧手順に従って、システムをアップグレード前と同じ状態に戻せるようになります。たとえば、ReaR (Relax-and-Recover) ユーティリティーを使用できます。詳細は、ReaR のドキュメント および Relax and Recover(ReaR) の概要 を参照してください。あるいは、LVM スナップショット または RAID 分割 を使用することもできます。仮想マシンをアップグレードする場合は、仮想マシン全体のスナップショットを作成できます。
3.2. アップグレードのための Satellite 登録システムの準備
この手順では、RHEL 8 へのアップグレード用に Satellite に登録されているシステムを準備するために必要な手順を説明します。
注記 Satellite システム自体をアップグレードする場合は、Upgrading Satellite or Capsule to Red Hat Enterprise Linux 8 In-Place Using Leapp で説明されている手順に従います。
Satellite システムのユーザーは、この手順と Preparing a RHEL 7 system for the upgrade で説明されている準備手順を完了する必要があります。
前提条件
- Satellite Server の管理者権限がある。
手順
- Satellite は、フルサポートまたはメンテナーンスサポートがあるバージョンです。詳細は、Red Hat Satellite の製品ライフサイクル を参照してください。
- RHEL 8 リポジトリーを使用したサブスクリプションマニフェストを Satellite Server にインポートします。詳細は、Red Hat Satellite の特定のバージョン (バージョン 6.12 など) のコンテンツ管理ガイドの Red Hat サブスクリプションの管理の章を参照してください。
Satellite Server で必要なすべての RHEL 7 および RHEL 8 リポジトリーを有効にし、RHEL 7.9 およびターゲット OS バージョン (RHEL 8.6 など) の最新の更新と同期します。必要なリポジトリーはコンテンツビューで利用可能であり、関連付けられたアクティベーションキーで有効になっている必要があります。
注記RHEL 8 リポジトリーの場合は、各リポジトリーのターゲット OS バージョン (8.6 など) を有効にします。RHEL 8 バージョンのリポジトリーのみを有効にした場合は、インプレースアップグレードは行われません。
たとえば、延長更新サポート (EUS) サブスクリプションがない Intel アーキテクチャーの場合は、少なくとも以下のリポジトリーを有効にします。
Red Hat Enterprise Linux 7 Server (RPM)
rhel-7-server-rpms
x86_64 7Server または x86_64 7.9
Red Hat Enterprise Linux 7 Server - Extras (RPM)
rhel-7-server-extras-rpms
x86_64
Red Hat Enterprise Linux 8 for x86_64 - AppStream (RPMs)
rhel-8-for-x86_64-appstream-rpms
x86_64 <target_os_version>
Red Hat Enterprise Linux 8 for x86_64 - BaseOS (RPMs)
rhel-8-for-x86_64-baseos-rpms
x86_64 <target_os_version>
target_os_version は、ターゲットの OS バージョン (例: 8.6) に置き換えます。
その他のアーキテクチャーは、RHEL 7 リポジトリー および RHEL 8 リポジトリー を参照してください。
詳細は、Red Hat Satellite の特定のバージョン (バージョン 6.12 など) の コンテンツ管理ガイド の コンテンツのインポート の章を参照してください。
必要な RHEL 7 リポジトリーおよび RHEL 8 リポジトリーを含むコンテンツビューにコンテンツホストを割り当てます。
詳細は、Red Hat Satellite の特定のバージョン (バージョン 6.12 など) の コンテンツ管理ガイド の コンテンツビューの管理 の章を参照してください。
検証
正しい RHEL 7 リポジトリーおよび RHEL 8 リポジトリーが Satellite Server の正しいコンテンツビューに追加されていることを確認します。
- Satellite Web UI で、Content > Lifecycle > Content Views に移動して、コンテンツビューの名前をクリックします。
Repositories タブをクリックして、リポジトリーが正しく表示されることを確認します。
注記以下のコマンドを使用して、リポジトリーがコンテンツビューに追加されていることを確認することもできます。
# hammer repository list --search 'content_label ~ rhel-7' --content-view <content_view_name> --organization <organization> --lifecycle-environment <lifecycle_environment> # hammer repository list --search 'content_label ~ rhel-8' --content-view <content_view_name> --organization <organization> --lifecycle-environment <lifecycle_environment>
<content_view_name> をコンテンツビューの名前に、<organization> を組織に、<lifecycle_environment> をライフサイクル環境の名前に置き換えます。
コンテンツビューに関連付けられたアクティベーションキーで、正しい RHEL 8 リポジトリーが有効になっていることを確認します。
- Satellite Web UI で、Content > Lifecycle > Activation Keys に移動し、アクティベーションキーの名前をクリックします。
-
Repository Sets タブをクリックし、必要なリポジトリーのステータスが
Enabled
であることを確認します。
第4章 アップグレード前のレポートの確認
システムのアップグレード可能性を評価するには、leapp preupgrade
コマンドでアップグレード前のプロセスを開始します。このフェーズでは、Leapp
ユーティリティーがシステムに関するデータを収集し、アップグレードの可能性を評価し、アップグレード前のレポートを生成します。アップグレード前のレポートは、潜在的な問題についてまとめ、推奨される解決策を提案します。このレポートは、アップグレードを進めることが可能かどうかの判断にも役立ちます。
レポートでアップグレードの阻害要因が見つからない場合でも、必ずアップグレード前レポート全体を確認してください。アップグレード前のレポートには、アップグレードされたシステムが正しく機能することを確認するために、アップグレード前に完了する推奨アクションが含まれています。
インプレースアップグレードプロセスではなく、RHEL 8 システムの新規インストールを実行する場合も、アップグレード前のレポートを確認すると有用です。
次のいずれかの方法を使用して、アップグレード前の段階でアップグレード可能性を評価できます。
-
生成された
leapp-report.txt
ファイルのアップグレード前レポートを確認し、コマンドラインインターフェイスを使用して、報告された問題を手動で解決します。 - Web コンソールを使用してレポートを確認し、利用可能な場合は自動修復を適用し、推奨される修復ヒントを使用して残りの問題を修正します。
たとえば、独自のカスタムスクリプトを使用してアップグレード前のレポートを処理し、異なる環境間にある複数のレポートの結果を比較できます。詳細は Red Hat Enterprise Linux のアップグレード前のレポートワークフローの自動化 を参照してください。
アップグレード前のレポートでは、インプレースアップグレードプロセス全体をシミュレートできないため、システムの阻害要因となる問題をすべて特定することはできません。その結果、レポート内のすべての問題を確認して修正した後でも、インプレースアップグレードが終了する可能性があります。たとえば、アップグレード前のレポートでは、壊れたパッケージのダウンロードに関連する問題は検出できません。
4.1. コマンドラインからのアップグレード可能性の評価
コマンドラインインターフェイスを使用して、アップグレード前のフェーズで潜在的なアップグレードの問題を特定します。
前提条件
- Preparing for the upgrade に記載されている手順が完了しました。
手順
RHEL 7 システムで、アップグレード前のフェーズを別途実行します。
# leapp preupgrade --target <target_os_version>
<target_os_version> は、ターゲットの OS バージョン (例: 8.6) に置き換えます。ターゲット OS バージョンが定義されていない場合、
Leapp
は表 1.1 で指定されたデフォルトのターゲット OS バージョンを使用します (サポートされるアップグレードパス)。アップグレードに
/etc/yum.repos.d/
ディレクトリーの カスタムリポジトリー を使用する場合は、以下のように選択したリポジトリーを有効にします。# leapp preupgrade --enablerepo <repository_id1> --enablerepo <repository_id2> ...
-
RHSM なしでアップグレード する場合、または RHUI を使用する場合は、
--no-rhsm
オプションを追加します。 -
Extended Upgrade Support (EUS)、Advanced Update Support (AUS)、または Update Services for SAP Solutions (E4S) のサブスクリプションがある場合は、
--channel <channel>
オプションを追加します。<channel> はチャネル名 (例:eus
、aus
、e4s)
に置き換えます。SAP HANA を利用している場合はHow to in-place upgrade SAP environments from RHEL 7 to RHEL 8 ガイドを使用してインプレースアップグレードを実行する必要があることに注意してください。
/var/log/leapp/leapp-report.txt
ファイル内のレポートを調べて、報告されたすべての問題を手動で解決します。報告された問題の中には、修正の提案が含まれているものもあります。阻害 要因の問題があると、それを解決するまでアップグレードできません。レポートには次のリスク因子レベルが含まれます。
- High
- システム状態が悪化する可能性が非常に高い
- Medium
- システムとアプリケーションの両方に影響を与える可能性がある
- Low
- システムに影響はないが、アプリケーションに影響を与える可能性がある
- Info
- システムまたはアプリケーションへの影響がないと考えられる情報
特定のシステム設定では、
Leapp
ユーティリティーは手動で回答する必要がある True/false の質問表を生成します。アップグレード前のレポートに Missing required answers in the answer file のメッセージが含まれる場合は、次の手順を実行します。-
/var/log/leapp/answerfile
ファイルを開き、true または false の質問を確認します。 /var/log/leapp/answerfile
ファイルを手動で編集し、#
記号を削除してファイルの確認行のコメントを解除し、True
またはFalse
として回答を確定します。詳細は、Leapp 回答ファイル を参照してください。注記または、以下のコマンドを実行して、True/false の質問に回答できます。
# leapp answer --section <question_section>.<field_name>=<answer>
たとえば、PAM 設定で pam_pkcs11 モジュールを無効にするか ?という質問に
False
を確定するには、以下のコマンドを実行します。# leapp answer --section remove_pam_pkcs11_module_check.confirm=False
-
- 前の手順を繰り返してアップグレード前レポートを再実行し、すべての重要な問題が解決されたことを確認します。
4.2. Web コンソールを介したアップグレードの可能性の評価および自動修復の適用
アップグレード前のフェーズで潜在的な問題と、Web コンソールを使用して自動修復を適用する方法を特定します。
前提条件
- アップグレードの準備 に記載されている手順を完了している。
手順
cockpit-leapp
プラグインをインストールします。# dnf install cockpit-leapp
root
として、またはsudo
で管理コマンドを入力するパーミッションがあるユーザーとして Web コンソールにログインします。Web コンソールの詳細は、RHEL 7 Web コンソールを使用したシステムの管理 を参照してください。RHEL 7 システムで、コマンドラインインターフェイスまたは Web コンソールの端末からアップグレード前のフェーズを実行します。
# leapp preupgrade --target <target_os_version>
<target_os_version> は、ターゲットの OS バージョン (例: 8.6) に置き換えます。ターゲット OS バージョンが定義されていない場合、
Leapp
は表 1.1 で指定されたデフォルトのターゲット OS バージョンを使用します (サポートされるアップグレードパス)。アップグレードに
/etc/yum.repos.d/
ディレクトリーの カスタムリポジトリー を使用する場合は、以下のように選択したリポジトリーを有効にします。# leapp preupgrade --enablerepo <repository_id1> --enablerepo <repository_id2> ...
-
RHSM なしでアップグレード する場合、または RHUI を使用する場合は、
--no-rhsm
オプションを追加します。 -
Extended Upgrade Support (EUS)、Advanced Update Support (AUS)、または Update Services for SAP Solutions (E4S) のサブスクリプションがある場合は、
--channel <channel>
オプションを追加します。<channel> はチャネル名 (例:eus
、aus
、e4s)
に置き換えます。SAP HANA のお客様は、ナレッジベースの記事 How to in-place upgrade SAP environments from RHEL 7 to RHEL 8 を使用してインプレースアップグレードを実行する必要があります。
Web コンソールで、ナビゲーションメニューから Upgrade Report を選択し、報告されたすべての問題を確認します。阻害 要因の問題があると、それを解決するまでアップグレードできません。問題を詳細に表示するには、行を選択して詳細ペインを開きます。
図4.1 Web コンソールのインプレースアップグレードレポート
レポートには次のリスク因子レベルが含まれます。
- High
- システム状態が悪化する可能性が非常に高い
- Medium
- システムとアプリケーションの両方に影響を与える可能性がある
- Low
- システムに影響はないが、アプリケーションに影響を与える可能性がある
- Info
- システムまたはアプリケーションへの影響がないと考えられる情報
特定の設定では、
Leapp
ユーティリティーは手動で回答する必要がある True/false の質問表を生成します。アップグレードレポートの 回答ファイルで必須の回答が抜けている 行が含まれている場合は、次の手順を実行します。- 回答ファイルで必須の回答が抜けている 行を選択し、Detail ペインを開きます。デフォルトの回答は修復コマンドの最後に記載されています。
- デフォルトの応答を確定するには、Add to Remediation Plan を選択して修復を後で実行するか、または Run Remediation を選択して修復をすぐに実行します。
代わりにデフォルト以外の回答を選択するには、回答する質問と確認済みの回答を指定して、ターミナルで
Leapp Answer
コマンドを実行します。# leapp answer --section <question_section>.<field_name>=<answer>
たとえば、PAM 設定で pam_pkcs11 モジュールを無効にするか ?という質問に
False
を確定するには、以下のコマンドを実行します。# leapp answer --section remove_pam_pkcs11_module_check.confirm=False
注記/var/log/leapp/answerfile
ファイルを手動で編集し、#
記号を削除してファイルの confirm 行のコメントを解除し、True
またはFalse
として回答を確定します。詳細は、Leapp 回答ファイルの例 を参照してください。
一部の問題には、問題を自動的に解決するために実行できる修復コマンドがあります。修復コマンドは個別に実行することも、修復コマンドでまとめて実行することもできます。
- 単一の修復コマンドを実行するには、問題の Detail ペインを開き、Run Remediation をクリックします。
修復コマンドを修復計画に追加するには、問題の Detail ペインを開き、Add to Remediation Plan をクリックします。
図4.2 詳細ペイン
- 追加されたすべての修復コマンドを含む修復計画を実行するには、レポートの右上隅にある Remediation plan リンクをクリックします。Execute Remediation Plan をクリックして、一覧表示されたすべてのコマンドを実行します。
- レポートを確認し、報告されたすべての問題を解決したら、手順 3 ~ 7 を繰り返してレポートを再実行し、すべての重要な問題が解決されたことを確認します。
第5章 RHEL 7 から RHEL 8 へのアップグレードの実行
Leapp
ユーティリティーを使用して RHEL 8 にアップグレードします。
前提条件
- フルシステムバックアップを含め、Preparing for the upgrade の手順が完了しました。
- アップグレード前のレポートの確認 に記載されている手順が完了し、報告されたすべての問題が解決されました。
手順
RHEL 7 システムで、アップグレードプロセスを開始します。
# leapp upgrade --target <target_os_version>
<target_os_version> は、ターゲットのオペレーティングシステム (OS) バージョン (例: 8.6) に置き換えます。ターゲット OS バージョンが定義されていない場合、
Leapp
は表 1.1 で指定されたデフォルトのターゲット OS バージョンを使用します (サポートされるアップグレードパス)。注記アップグレードに
/etc/yum.repos.d/
ディレクトリーの カスタムリポジトリー を使用する場合は、以下のように選択したリポジトリーを有効にします。# leapp upgrade --enablerepo <repository_id1> --enablerepo <repository_id2> …
RHSM なしでアップグレード する場合、または RHUI を使用する場合は、
--no-rhsm
オプションを追加します。ISO イメージを使用してアップグレードする場合は、
--no-rhsm
および--iso <file_path>
オプションを追加します。<file_path> は、保存された ISO イメージへのファイルパス (/home/rhel8.iso
など) に置き換えます。Extended Upgrade Support (EUS)、Advanced Update Support (AUS)、または Update Services for SAP Solutions (E4S) のサブスクリプションがある場合は、
--channel <channel>
オプションを追加します。<channel> はleapp preupgrade
コマンドで使用した値 (eus
、aus
、e4s
など) に置き換えます。leapp preupgrade
およびleapp upgrade
コマンドの両方で、--channel
オプションで同じ値を使用する必要があります。アップグレードプロセスの開始時に、
Leapp
は、アップグレード前のレポートの確認 で説明されているアップグレード前のフェーズを実行します。システムをアップグレードできる場合は、
Leapp
が必要なデータをダウンロードし、アップグレード用の RPM トランザクションを作成します。システムで、信頼できるアップグレードの設定要因が満たされていない場合は、
Leapp
がアップグレードプロセスを中止し、問題を説明する記録と、推奨される解決策を/var/log/leapp/leapp-report.txt
ファイルに出力します。詳細は、トラブルシューティング を参照してください。システムを手動で再起動します。
# reboot
このフェーズでは、システムが RHEL 8 ベースの初期 RAM ディスクイメージ initramfs で起動します。
Leapp
は、すべてのパッケージをアップグレードして、自動的に RHEL 8 システムを再起動します。または、
--reboot
オプションを指定してleapp upgrade
コマンドを入力し、この手動の手順を省略することもできます。失敗した場合は、トラブルシューティング の説明に従ってログを調べてください。
- RHEL 8 システムにログインし、RHEL 8 システムのアップグレード後の状態の確認 で説明されているように状態を確認します。
- アップグレードレポートおよびアップグレード後のタスク の実行で説明されているすべてのアップグレード後のタスクを 実行します。特に、セキュリティーポリシーを再評価して再適用します。
- FIPS モード で実行されているシステムをアップグレードする場合は、RHEL 7 カーネルをすべて削除します。次に、暗号化キーの再生成などを行い、すべての暗号化キーの FIPS 準拠を確認します。詳細は、RHEL 8 の暗号化キーの場所 を参照してください。
第6章 RHEL 8 システムのアップグレード後の状態の確認
この手順は、RHEL 8 へのインプレースアップグレード後に実行が推奨される検証手順を紹介します。
前提条件
- RHEL 7 から RHEL 8 へのアップグレードの実行 に記載されている手順に従ってシステムをアップグレードし、RHEL 8 にログインできる。
手順
アップグレードが完了したら、システムが必要な状態になっていることを確認します。少なくとも以下の確認を行います。
現在のオペレーティングシステムのバージョンが Red Hat Enterprise Linux 8 であることを確認します。
# cat /etc/redhat-release Red Hat Enterprise Linux release <target_os_version> (Ootpa)
target_os_version は、ターゲットの OS バージョン (例: 8.6) に置き換えます。
オペレーティングシステムのカーネルバージョンを確認します。
# uname -r 4.18.0-305.el<target_os>.x86_64
target_os は、
8
またはターゲットの OS バージョンのいずれかである必要があります (例:8_6
)。.el8
は重要であるため、このバージョンは 4.18.0-305 よりも前のバージョンにはならないことに注意してください。Red Hat Subscription Manager を使用している場合:
正しい製品がインストールされていることを確認します。
# subscription-manager list --installed +-----------------------------------------+ Installed Product Status +-----------------------------------------+ Product Name: Red Hat Enterprise Linux for x86_64 Product ID: 479 Version: <target_os_version> Arch: x86_64 Status: Subscribed
target_os_version は、ターゲットの OS バージョン (例: 8.6) に置き換えます。
アップグレード直後にリリースバージョンがターゲットの OS バージョンに設定されていることを確認します。
# subscription-manager release Release: <target_os_version>
target_os_version は、ターゲットの OS バージョン (例: 8.6) に置き換えます。
- ネットワークサービスが機能していることを確認します。たとえば、SSH を使用してサーバーに接続します。
- アプリケーションのアップグレード後のステータスを確認します。場合によっては、移行や設定を手動で変更しないといけない場合があります。たとえば、データベースを移行するには、RHEL 8 データベースサーバーのドキュメント の説明に従ってください。
第7章 アップグレード後のタスクの実行
RHEL 8 へのインプレースアップグレード後に、次の主要なタスクが推奨されます。
前提条件
- RHEL 7 から RHEL 8 へのアップグレード の実行で説明されている手順に従ってシステムをアップグレードし、RHEL 8 にログインできる。
- RHEL 8 システムのアップグレード後のステータスの確認 で説明されている手順に従って、インプレースアップグレードのステータスを確認している。
手順
アップグレードが完了したら、以下のタスクを実行します。
snactor
パッケージを含む、/etc/dnf/dnf.conf
設定ファイルの exclude 一覧から残りのLeapp
パッケージを削除します。インプレースアップグレード中に、Leapp
ユーティリティーでインストールされたLeapp
パッケージが exclude リストに自動的に追加され、重要なファイルが削除または更新されないようにします。インプレースアップグレードの後、これらのLeapp
パッケージをシステムから削除する前に、除外リストから削除する必要があります。-
exclude 一覧からパッケージを手動で削除するには、
/etc/dnf/dnf.conf
設定ファイルを編集し、除外
一覧から必要なLeapp
パッケージを削除します。 除外
一覧からすべてのパッケージを削除するには、次のコマンドを実行します。# yum config-manager --save --setopt exclude=''
-
exclude 一覧からパッケージを手動で削除するには、
残りの
Leapp
パッケージを含む残りの RHEL 7 パッケージを削除します。以前のカーネルバージョンを確認します。
# cd /lib/modules && ls -d *.el7*
以前のカーネルから弱いモジュールを削除します。以前のカーネルが複数ある場合は、カーネルごとに次の手順を繰り返します。
# [ -x /usr/sbin/weak-modules ] && /usr/sbin/weak-modules --remove-kernel <version>
<version> を、前の手順で確認したカーネルバージョンに置き換えます。以下に例を示します。
# [ -x /usr/sbin/weak-modules ] && /usr/sbin/weak-modules --remove-kernel 3.10.0-1160.25.1.el7.x86_64
注記以下のエラーメッセージは無視してください。これは、カーネルパッケージが過去に削除されている場合に生成されます。
/usr/sbin/weak-modules: line 1081: cd: /lib/modules/<version>/weak-updates: No such file or directory
古いカーネルをブートローダーエントリーから削除します。以前のカーネルが複数ある場合は、カーネルごとにこの手順を繰り返します。
# /bin/kernel-install remove <version> /lib/modules/<version>/vmlinuz
version を、前の手順で確認したカーネルバージョンに置き換えます。以下に例を示します。
# /bin/kernel-install remove 3.10.0-1160.25.1.el7.x86_64 /lib/modules/3.10.0-1160.25.1.el7.x86_64/vmlinuz
残りの RHEL 7 パッケージを見つけます。
# rpm -qa | grep -e '\.el[67]' | grep -vE '^(gpg-pubkey|libmodulemd|katello-ca-consumer)' | sort
-
RHEL 8 システムから、古いカーネルパッケージなど、残りの RHEL 7 パッケージと
kernel-workaround
パッケージを削除します。 残りの
Leapp
依存関係パッケージを削除します。# yum remove leapp-deps-el8 leapp-repository-deps-el8
残りの空のディレクトリーを削除します。
# rm -r /lib/modules/*el7*
オプション: 残っているすべてのアップグレード関連データをシステムから削除します。
# rm -rf /var/log/leapp /root/tmp_leapp_py3 /var/lib/leapp
重要このデータを削除すると、Red Hat サポートによるアップグレード後の問題の調査とトラブルシューティングが制限される可能性があります。
RHEL 8 でパッケージをインストールまたは使用できない YUM リポジトリーを無効にします。RHSM によって管理されるリポジトリーは自動的に処理されます。これらのリポジトリーを無効にするには、以下を実行します。
# yum config-manager --set-disabled <repository_id>
<repository_id> はリポジトリー ID に置き換えます。
古いレスキューカーネルと初期 RAM ディスクを現在のカーネルとディスクに置き換えます。
既存のレスキューカーネルと初期 RAM ディスクを削除します。
# rm /boot/vmlinuz-*rescue* /boot/initramfs-*rescue*
現在のカーネルを再インストールして、レスキューカーネルと関連する初期 RAM ディスクを回復します。
# dnf reinstall -y kernel-core-$(uname -r)
注記リアルタイムシステムなど、システムのカーネルパッケージの名前が異なる場合は、
kernel-core
を正しいパッケージ名に置き換えます。
- セキュリティーポリシーを再評価して再適用します。具体的には、SELinux モードを Enforcing に変更します。詳細は、セキュリティーポリシーの適用 を参照してください。
検証手順
古いカーネルがブートローダーエントリーから削除されていることを確認します。
# grubby --info=ALL | grep "\.el7" || echo "Old kernels are not present in the bootloader."
以前に削除したレスキューカーネルとレスキュー初期 RAM ディスクファイルが現在のカーネル用に作成されていることを確認します。
# ls /boot/vmlinuz-*rescue* /boot/initramfs-*rescue* # lsinitrd /boot/initramfs-*rescue*.img | grep -qm1 "$(uname -r)/kernel/" && echo "OK" || echo "FAIL"
レスキューブートエントリーが既存のレスキューファイルを参照していることを確認します。grubby の出力を参照してください。
# grubby --info $(ls /boot/vmlinuz-*rescue*)
第8章 セキュリティーポリシーの適用
インプレースアップグレードプロセスでは、特定のセキュリティーポリシーを無効にしたままにする必要があります。さらに、RHEL 8 ではシステム全体の暗号化ポリシーという概念が新たに導入され、セキュリティープロファイルにはメジャーリリース間の変更が含まれる可能性があります。本セクションでは、アップグレードした RHEL システムのセキュリティーを保護する方法を説明します。
8.1. SELinux モードの Enforcing への変更
Leapp
ユーティリティーは、インプレースアップグレードプロセス時に SELinux モードを Permissive に設定します。システムが正常にアップグレードされたら、手動で SELinux モードを Enforcing に変更する必要があります。
前提条件
- システムがアップグレードされ、RHEL 8 システムのアップグレード後の状態の確認 で説明されている検証手順を実行している。
手順
ausearch
ユーティリティーなどを使用して、SELinux 拒否がないことを確認します。# ausearch -m AVC,USER_AVC -ts boot
前述の手順では、最も一般的なシナリオのみが扱われることに注意してください。可能な SELinux 拒否をすべて確認するには、完全な手順を説明する SELinux の使用の SELinux 拒否の特定 セクションを参照してください。
任意のテキストエディターで
/etc/selinux/config
ファイルを開きます。以下に例を示します。# vi /etc/selinux/config
SELINUX=enforcing
オプションを設定します。# This file controls the state of SELinux on the system. # SELINUX= can take one of these three values: # enforcing - SELinux security policy is enforced. # permissive - SELinux prints warnings instead of enforcing. # disabled - No SELinux policy is loaded. SELINUX=enforcing # SELINUXTYPE= can take one of these two values: # targeted - Targeted processes are protected, # mls - Multi Level Security protection. SELINUXTYPE=targeted
変更を保存して、システムを再起動します。
# reboot
検証
システムの再起動後に、
getenforce
コマンドがEnforcing
を返すことを確認します。$ getenforce Enforcing
8.2. システム全体の暗号化ポリシーの設定
システム全体の暗号化ポリシーは、コア暗号化サブシステムを設定するシステムコンポーネントで、TLS、IPSec、SSH、DNSSec、および Kerberos の各プロトコルに対応します。
インストールまたはインプレースアップグレードプロセスに成功すると、システム全体の暗号化ポリシーは自動的に DEFAULT
に設定されます。DEFAULT
のシステム全体の暗号化ポリシーレベルで、現在の脅威モデルに対して安全なものです。
現在のシステム全体の暗号化ポリシーを表示または変更するには、update-crypto-policies tool ツールを使用します。
$ update-crypto-policies --show
DEFAULT
たとえば、以下のコマンドは、システム全体の暗号化ポリシーレベルを FUTURE
に切り替えます。これで、近い将来の攻撃に耐えられるはずです。
# update-crypto-policies --set FUTURE
Setting system policy to FUTURE
システム全体の暗号化ポリシーをカスタマイズすることもできます。詳細は、ポリシー修飾子を使用したシステム全体の暗号化ポリシーのカスタマイズ および システム全体のカスタム暗号化ポリシーの作成および設定 を参照してください。
関連情報
- システム全体の暗号化ポリシーの使用
-
update-crypto-policies(8)
の man ページ。
8.3. セキュリティーベースラインが強化されたシステムのアップグレード
正常に RHEL 8 へアップグレードした後に、システムを完全に強化するには、OpenSCAP スイートが提供する自動修復を使用できます。OpenSCAP 修復は、PCI-DSS、OSPP、または ACSC Essential Eight などのセキュリティーベースラインに、お使いのシステムを合わせます。設定コンプライアンスに関する推奨事項は、セキュリティーオファリングが進化したため、Red Hat Enterprise Linux のメジャーバージョン間で異なります。
強化された RHEL 7 システムをアップグレードする場合、Leapp
ツールは完全な強化を保持する直接的な手段を 提供しません。コンポーネント設定の変更によっては、アップグレード中に RHEL 8 の推奨環境とは異なる場合があります。
RHEL 7 および RHEL 8 のスキャンに同じ SCAP コンテンツを使用することはできません。システムのコンプライアンスが Red Hat Satellite や Red Hat Insights などのツールで管理されている場合は、管理プラットフォームを更新します。
自動修復の代わりに、OpenSCAP で生成されたレポートに従って、手動で変更を行うことができます。コンプライアンスレポートの生成に関する情報は、Scanning the system for security compliance and vulnerabilities を参照してください。
以下の手順に従って、PCI-DSS プロファイルでシステムを自動的に強化します。
自動修復は、デフォルト設定の RHEL システムで対応しています。インストール後にシステムのアップグレードが変更されたため、修復を実行しても、必要なセキュリティープロファイルに完全に準拠しない場合があります。一部の要件を手動で修正する必要がある場合があります。
前提条件
-
RHEL 8 システムに、
scap-security-guide
パッケージがインストールされている。
手順
適切なセキュリティーコンプライアンスデータストリームの
.xml
ファイルを見つけます。$ ls /usr/share/xml/scap/ssg/content/ ssg-firefox-cpe-dictionary.xml ssg-rhel6-ocil.xml ssg-firefox-cpe-oval.xml ssg-rhel6-oval.xml ... ssg-rhel6-ds-1.2.xml ssg-rhel8-oval.xml ssg-rhel8-ds.xml ssg-rhel8-xccdf.xml ...
詳細は、コンプライアンスプロファイルの表示 を参照してください。
適切なデータストリームから選択したプロファイルに従って、システムを修正します。
# oscap xccdf eval --profile pci-dss --remediate /usr/share/xml/scap/ssg/content/ssg-rhel8-ds.xml
--profile
引数のpci-dss
値は、システムを強化するプロファイルの ID に置き換えることができます。RHEL 8 でサポートされるプロファイルの完全なリストについては、SCAP security profiles supported in RHEL を参照してください。警告Remediate オプションを有効にしてシステム評価を実行した場合、慎重に行わないと、システムが機能不全に陥る場合があります。Red Hat は、セキュリティーを強化した修復で加えられた変更を元に戻す自動手段は提供していません。修復は、デフォルト設定の RHEL システムで対応しています。インストール後にシステムが変更した場合は、修復を実行しても、必要なセキュリティープロファイルに準拠しない場合があります。
システムを再起動します。
# reboot
検証
システムがプロファイルに準拠していることを確認し、結果を HTML ファイルに保存します。
$ oscap xccdf eval --report pcidss_report.html --profile pci-dss /usr/share/xml/scap/ssg/content/ssg-rhel8-ds.xml
関連情報
-
scap-security-guide(8)
およびoscap(8)`
の man ページ - セキュリティーコンプライアンスおよび脆弱性スキャンの開始
- Red Hat Insights セキュリティーポリシーのドキュメント
- Red Hat Satellite セキュリティーポリシーのドキュメント
第9章 トラブルシューティング
RHEL 7 から RHEL 8 へのアップグレードのトラブルシューティングには、以下のヒントを参照してください。
9.1. トラブルシューティングのリソース
以下のトラブルシューティングリソースを参照してください。
コンソールの出力
デフォルトでは、Leapp
ユーティリティーにより、エラーおよび重要なログレベルメッセージのみがコンソールに出力されます。ログレベルを変更するには、leapp upgrade
コマンドで --verbose
オプションまたは --debug
オプションを使用します。
-
verbose モードでは、
Leapp
により情報、警告、エラー、および重要なメッセージが出力されます。 -
debug モードでは、
Leapp
によりデバッグ、情報、警告、エラー、および重要なメッセージを出力します。
ログ
-
/var/log/leapp/leapp-upgrade.log
ファイルには、initramfs フェーズで見つかった問題が記載されます。 -
/var/log/leapp/dnf-debugdata/
ディレクトリーには、トランザクションのデバッグデータが含まれます。このディレクトリーは、leapp upgrade
コマンドに--debug
オプションを使用して実行した場合に限り表示されます。 -
/var/log/leapp/answerfile
には、Leapp
による回答が必要な質問が含まれています。 -
journalctl
ユーティリティーでは、すべてのログが出力されます。
レポート
-
/var/log/leapp/leapp-report.txt
ファイルには、アップグレード前のフェーズで見つかった問題が記載されます。レポートは、Web コンソールでも利用できます。アップグレードの可能性と、Web コンソールで自動修復の適用 を参照してください。 -
/var/log/leapp/leapp-report.json
ファイルには、マシンが判読可能な形式でアップグレード前のフェーズで見つかった問題が記載され、カスタムスクリプトを使用してレポートを処理することができます。詳細は Red Hat Enterprise Linux のアップグレード前のレポートワークフローの自動化 を参照してください。
9.2. トラブルシューティングのヒント
以下のトラブルシューティングのヒントを参照してください。
アップグレード前のフェーズ
- アップグレードの計画 に記載されている条件をすべて満たしていることを確認します。
-
Preparing for the upgrade に記載されているすべての手順を行ってください。たとえば、システムで、カーネル (
eth
) が使用する接頭辞に基づいた名前を持つ NIC (Network Interface Card) を複数使用しないようにします。 /var/log/leapp/answerfile
ファイルで、Leapp
に必要な質問をすべて回答している。回答が見つからない場合は、Leapp
によりアップグレードが行われません。質問例:- PAM 設定で pam_pkcs11 モジュールを無効にするか ?
- PAM 設定で pam_krb5 モジュールを無効にするか ?
- 以下の authselect コールで PAM および nsswitch.conf を設定しますか ?
-
アップグレード前のレポートで特定されたすべての問題は、
/var/log/leapp/leapp-report.txt
にあることを確認してください。これを行うには、Web コンソールでアップグレードの可能性の評価および自動修復の適用 で説明されているように、Web コンソールを使用することも可能です。
例9.1 Leapp answerfile
以下は、編集されていない /var/log/leapp/answerfile
ファイルの例です。
[remove_pam_pkcs11_module_check] # Title: None # Reason: Confirmation # =================== remove_pam_pkcs11_module_check.confirm ================== # Label: Disable pam_pkcs11 module in PAM configuration? If no, the upgrade process will be interrupted. # Description: PAM module pam_pkcs11 is no longer available in RHEL-8 since it was replaced by SSSD. # Type: bool # Default: None # Available choices: True/False # Unanswered question. Uncomment the following line with your answer # confirm =
Label
フィールドは、回答が必要な質問を指定します。この例の質問は、PAM 設定の pam_pkcs11 モジュールを無効にしますか ?です。
この質問に回答するには、confirm
行のコメントを解除して True
または False
の回答を入力します。この例では、選択した回答は True
です。
[remove_pam_pkcs11_module_check]
...
# Available choices: True/False
# Unanswered question. Uncomment the following line with your answer
confirm = True
ダウンロードフェーズ
RPM パッケージのダウンロード中に問題が発生した場合は、
/var/log/leapp/dnf-debugdata/
ディレクトリーにあるトランザクションデバッグデータを調べてください。注記/var/log/leapp/dnf-debugdata/
ディレクトリーは空であるか、トランザクションデバッグデータが生成されていない場合は存在しません。これは、必要なリポジトリーが利用できない場合に発生する可能性があります。
initramfs フェーズ
このフェーズでは、潜在的な失敗により Dracut シェルにリダイレクトされます。ジャーナルを確認してください。
# journalctl
あるいは、
reboot
コマンドを実行して、Dracut シェルからシステムを再起動し、/var/log/leapp/leapp-upgrade.log
ファイルを確認します。
アップグレード後のフェーズ
- 一見、システムが正常にアップグレードしていても、古い RHEL 7 カーネルでシステムが起動する場合は、システムを再起動して、GRUB でデフォルトエントリーのカーネルバージョンを確認します。
- RHEL 8 システムのアップグレード後の状態の確認 の推奨手順を行ってください。
SELinux を Enforcing モードに切り替えてから、アプリケーションやサービスが停止したり、適切に動作しなかったりした場合は、ausearch、journalctl、dmesg のいずれかのユーティリティーで、サービスの拒否を検索します。
# ausearch -m AVC,USER_AVC -ts boot # journalctl -t setroubleshoot # dmesg | grep -i -e selinux -e type=1400
最も一般的な問題は、ラベルが間違っていることにより発生します。詳細は Troubleshooting problems related to SELinux を参照してください。
9.3. 既知の問題
以下は、RHEL 7 から RHEL 8 にアップグレードする際に発生する可能性のある既知の問題です。
- 現在、ネットワークチーミングは、Network Manager を無効にするかインストールしていない場合にインプレースアップグレードを実行すると動作しません。
-
HTTP プロキシーを使用する場合は、Red Hat Subscription Manager がこのようなプロキシーを使用するように設定するか、
--proxy <hostname>
オプションでsubscription-manager
コマンドを実行する必要があります。そうでない場合は、subscription-manager
コマンドの実行に失敗します。設定変更の代わりに--proxy
オプションを使用する場合は、Leapp
がプロキシーを検出できないため、アップグレードプロセスが失敗します。この問題が発生しないようにするには、Red Hat Subscription Management に HTTP プロキシーを設定する の説明に従ってrhsm.conf
ファイルを手動で編集します。(BZ#1689294)
-
RHEL 7 システムで、Red Hat が提供しているにもかかわらず RHEL 8 で利用できないデバイスドライバーを使用している場合は、
Leapp
でアップグレードが行われません。ただし、RHEL 7 システムが、Leapp
が/etc/leapp/files/device_driver_deprecation_data.json
ファイルにデータを持たないサードパーティーのデバイスドライバーを使用している場合、Leapp
はそのようなドライバーを検出せず、アップグレードを続行します。したがって、アップグレード後にシステムが起動しない場合があります。
/etc/nsswitch.conf
ファイルでwinbind
およびwins
Samba モジュールが使用されている場合は、インプレースアップグレードを実行できません。このシナリオでは、アップグレードトランザクションが失敗して次のエラーが表示され、Leapp
により更新が行われません。upgrade[469]: STDERR: upgrade[469]: Error in PREIN scriptlet in rpm package unbound-libs upgrade[469]: Error: Transaction failed upgrade[469]: Container el8userspace failed with error code 1. unbound-libs has a PREIN failure
この問題を回避するには、更新時に、データベース
user
、groups
、およびhosts
にのみローカルプロバイダーを使用できるようにシステムを設定します。-
システムの設定ファイル
/etc/nsswitch.conf
を開き、winbind
文字列またはwins
文字列を含むエントリーを検索します。 -
そのようなエントリーを確認するには、
/etc/nsswitch.conf
のバックアップを作成します。 -
/etc/nsswitch.conf
を編集し、winbind
またはwins
を含むエントリーからそれらを削除します。 - インプレースアップグレードを実行します。
アップグレード後、システム設定要件に基づいて、
winbind
およびwins
文字列を/etc/nsswitch.conf
のエントリーに追加します。(BZ#1410154)
-
システムの設定ファイル
Leapp
ユーティリティーは、アップグレードプロセス時にカスタマイズされた認証設定を変更しません。非推奨のauthconfig
ユーティリティーを使用して RHEL 7 システムで認証を設定した場合は、RHEL 8 での認証が正しく機能しない場合があります。RHEL 8 システムでカスタム設定が正しく機能するようにするには、authselect
ユーティリティーを使用して RHEL 8 システムを再設定します。重要インプレースアップグレード中に、非推奨のプラグ可能認証モジュール (PAM) の
pam_krb5
またはpam_pkcs11
が削除されます。その結果、RHEL 7 システムの PAM 設定にpam_krb5
またはpam_pkcs11
モジュールが含まれており、これらのモジュールにrequired
またはrequisite
の制御値がある場合、インプレースアップグレードを実行すると、システムからロックアウトされる可能性があります。この問題を回避するには、アップグレードプロセスを開始する前に、RHEL 7 システムを再設定して、pam_krb5
またはpam_pkcs11
を使用しないようにします。
お使いのシステムに (Red Hat が署名していない) サードパーティーパッケージの名前が、Red Hat が提供するパッケージの名前と同じ場合は、インプレースアップグレードに失敗します。この問題を回避するには、アップグレードの前に次のいずれかのオプションを選択してください。
- サードパーティーパッケージの削除
- サードパーティーパッケージを、Red Hat が提供するパッケージに置き換えます。
セキュリティー上の理由から、シングル DES (DES) およびトリプル DES (3DES) 暗号化タイプのサポートは RHEL 8 から削除されました。ただし、RHEL 7 Identity Management (IdM) は引き続き 3DES 暗号化に対応しています。
IdM クライアントのアップグレードまたは IdM 環境全体の RHEL 7 から RHEL 8 への移行は可能です。これは、RHEL の両方のバージョンがデフォルトでより強力な AES 暗号化タイプを優先するためです。IdM のバージョン デフォルトの暗号化タイプ その他のサポートされる暗号化タイプ RHEL 7
aes256-cts
aes128-cts
camellia256-cts
camellia128-cts
des3-hmac
arcfour-hmac
RHEL 8
aes256-cts
aes128-cts
aes256-sha2
aes128-sha2
camellia256-cts
camellia128-cts
arcfour-hmac
[a][a] RC4 暗号化は、新しい暗号化タイプ AES-128 および AES-256 よりも安全ではないと見なされるため、RHEL 8 ではデフォルトで非推奨となり、無効にされています。古い Active Directory 環境との互換性のために RC4 サポートを有効にする方法は、AD および RHEL で一般的な暗号化タイプに対応 を参照してください。IdM 以外の Kerberos Distribution Center (KDC)、サービス、またはユーザーが DES または 3DES の暗号化 のみ を使用するように手動で設定した場合、RHEL 8 の最新の Kerberos パッケージに更新した後に、以下のようなサービス中断が発生する可能性があります。
- Kerberos 認証エラー
-
unknown enctype
暗号化エラー -
DES で暗号化されたデータベースマスターキー (
K/M
) を使用する KDC が起動に失敗する
Red Hat では、お使いの環境で DES または 3DES 暗号化を使用しないことを推奨します。Kerberos プリンシパルが強力な暗号化タイプを使用するように設定する方法の詳細は、MIT Kerberos ドキュメントの Retiring DES を参照してください。
- RAID (Redundant array of independent disks) を備えたシステムでは、インプレースアップグレードに失敗します。(BZ#1957192)
- Puppet を使用するシステムなど、無効な GRUB ブートローダー仕様のシステムは、新しいカーネル用に新しい initramfs を作成できません。この問題を回避するには、第 6 章 アップグレード後のタスクの実行 で説明されているように、ブートローダーエントリーからパッケージと古いカーネルを手動で削除します。(BZ#1955099)
- Relax-and-Recover(ReaR) ユーティリティーは、IBM Z アーキテクチャーでは利用できません。そのため、IBM Z システムは OpenSCAP スイートで完全に修正することはできず、セキュリティーベースラインに完全に準拠しない場合があります。(BZ#1958939)
Leapp
ユーティリティーは、インプレースアップグレード時に、通常 RHEL 7 から RHEL 8 の間にネットワークインターフェイスコントローラー (NIC) 名を保持します。ただし、ネットワークボンディングを備えたシステムなどの一部のシステムでは、RHEL 7 と RHEL 8 の間で NIC 名を更新する必要があります。これらのシステムで、以下の手順を実行します。-
Leapp
ユーティリティーが元の RHEL 7 の NIC 名を誤って保持しないように、LEAPP_NO_NETWORK_RENAMING=1
環境変数を設定します。 - インプレースアップグレードを実行します。
ネットワークが正常に機能していることを確認します。必要に応じて、ネットワーク設定を手動で更新します。
(BZ#1919382)
-
Leapp
ユーティリティーが使用可能なディスク領域が十分にないことを誤って検出するため、インプレースアップグレードが禁止される場合があります。ftype 属性のない XFS ファイルシステムでフォーマットされたパーティションがシステムに含まれている場合は、LEAPP_OVL_SIZE
環境変数のデフォルトサイズを変更して、コンテナー内の指定された不足ディスク容量を最低限考慮することで、この問題を回避することが可能です。エラーメッセージが繰り返されないように、指定された不足ディスク容量よりもデフォルトのサイズを大きくすることをお勧めします。たとえば、400 MB が追加で必要であることをLeapp
ユーティリティーが検知した場合は、デフォルトのサイズを 2048 MB から少なくとも 2500 MB に増やします。注記この回避策では、
/var
パーティションに多くの空き領域が必要になる場合があります。この回避策が問題を解決しない場合、またはシステムに ftype 属性のないこれらのパーティションが含まれていない場合は、Red Hat サポートにお問い合わせください。
(BZ#1832730)
BIOS を使用してシステムを起動する場合は、コアイメージのインストールに十分な領域が、ブートディスクの埋め込み領域に含まれていないと、GRUB2 ブートローダーをアップグレードするときにインプレースアップグレードが失敗します。これによりシステムが破損し、RHEL 6
fdisk
ユーティリティーなどを使用してディスクが手動でパーティション分割された場合に発生する可能性があります。この問題がユーザーに影響するかどうかを確認するには、以下の手順を実行します。インストールされたブートローダーを使用してディスク上の最初のパーティションを開始するセクターを決定します。
# fdisk -l
コアイメージに十分なスペースを確保する標準のパーティショニングは、セクター 2048 から始まります。
開始セクターに十分なスペースがあるかどうかを判断します。RHEL 8 コアイメージには少なくとも 32 KiB が必要です。たとえば、セクターサイズが標準の 512 バイトの場合、セクター 66 以下から開始すると十分なスペースが得られません。
注記RHEL 8 コアイメージは 32 KiB より大きい場合があり、開始セクターの値を高く指定しなければいけない可能性があります。現在の RHEL 8 コアに必要な領域を常に確認してください。
埋め込み領域に十分なストレージ領域が含まれていない場合は、インプレースアップグレードを実行する代わりに、RHEL 8 システムの新規インストールを実行します。
(BZ#2181380)
9.4. IBM POWER 9(リトルエンディアン) および IBM Z (Structure A) の既知の問題
IBM POWER 9(リトルエンディアン) と 64 ビット IBM Z(Structure A) のアーキテクチャーは、ライフサイクルを終えました。これらのアーキテクチャーの最後のアップグレードパスは、RHEL 7.6 から RHEL 8.4 までです。インプレースアップグレードの以降のリリースには、これらのアーキテクチャーは含まれていません。したがって、既知の問題はインプレースアップグレードの今後のリリースで解決されますが、これらのアーキテクチャーでは解決されません。
以下の既知の問題は、IBM POWER 9(リトルエンディアン) および 64 ビット IBM-Z(Structure A) アーキテクチャーにのみ影響します。
-
インプレースアップグレード時に、
docker
パッケージは警告なしに削除されます。RHEL でコンテナーを使用する場合は、RHEL 8 にアップグレードする前に Podman に移行してください。手順は、How do I migrate my Docker containers to Podman prior to moving from Red Hat Enterprise Linux 7 to Red Hat Enterprise Linux 8? を参照してください。(BZ#1858711) アップグレード前のプロセス中、ユーザーはアップグレードを続行する前に、真または偽の質問に答える必要がある場合があります。
Leapp
の最新バージョンがリリースされる前にアップグレード前レポートが実行された場合、レポートは、すべての正誤問題に回答済みであり、アップグレードを続行しても安全であると誤って報告する可能性があります。2021 年 11 月 9 日より前にアップグレード前のレポートを実行する場合には、以下の手順を実行して、アップグレードに関する深刻な問題を防ぎます。-
すべての
Leapp
関連のパッケージを更新します。 /var/log/leapp/answerfile
ファイルおよび/var/log/leapp/answerfile.userchoices
ファイルを削除します。# rm -f /var/log/leapp/answerfile /var/log/leapp/answerfile.userchoices
jumpp preupgrade
コマンドを実行し、真または偽の質問に再度回答します。(BZ#2014015)
-
すべての
NFS サーバーで実行している NSFD サービスがあるシステムでは、インプレースアップグレード中に存在しない NFS パーティションが誤って検出され、アップグレードが妨げられる可能性があります。この問題を防ぐには、インプレースアップグレードを実行する前に NFSD サービスを停止します。
# systemctl stop /proc/fs/nfsd
(BZ#2036069)
9.5. サポートの利用
サポートケースを作成するには、製品で RHEL 7 を選択し、システムの sosreport
を添付します。
-
システムで
sosreport
を生成するには、次のコマンドを実行します。
# sosreport
ケース ID は空のままにできます。
sosreport を生成する方法は、ナレッジベースのソリューション Red Hat Enterprise Linux 上での sosreport のロールと取得方法 を参照してください。
カスタマーポータルでサポートケースを作成し、管理する方法は、ナレッジベースのアーティクル カスタマーポータルでサポートケースを作成および管理する を参照してください。
第10章 関連情報
以下の説明情報を参照できます。
- Red Hat Enterprise Linux technology capabilities and limits
- Supported in-place upgrade paths for Red Hat Enterprise Linux
- RHEL 8 の導入における検討事項
- Customizing your Red Hat Enterprise Linux in-place upgrade
- Red Hat Enterprise Linux のアップグレード前のレポートワークフローの自動化
- Using configuration management systems to automate parts of the Leapp pre-upgrade and upgrade process on Red Hat Enterprise Linux
- 非接続アップグレードのための RHEL の Leapp ユーティリティーメタデータのインプレースアップグレード
- RHEL 6 から RHEL 7 へのアップグレード
- RHEL 6 から RHEL 8 へのアップグレード
- RPM ベースの Linux ディストリビューションから RHEL への変換
- Red Hat Satellite での RHEL 7 から RHEL 8 へのホストのアップグレード
- SAP 環境を RHEL 7 から RHEL 8 にインプレースアップグレードする方法
- Red Hat Insights ドキュメント
付録A RHEL 7 リポジトリー
アップグレードの前に、Preparing a RHEL 7 system for the upgrade の手順 4 で説明されているように、適切なリポジトリーを有効になっていることを確認してください。
アップグレード時に Red Hat Subscription Manager を使用する予定がある場合には、subscription-manager repos --enable repository_id
コマンドを使用して、アップグレードの前に以下のリポジトリーを 有効にする必要があります。
アーキテクチャー | リポジトリー | リポジトリー ID |
---|---|---|
64 ビット Intel | Base |
|
Extras |
| |
IBM POWER8 (リトルエンディアン) | Base |
|
Extras |
| |
IBM POWER9 (リトルエンディアン) | Base |
|
Extras |
| |
IBM Z | Base |
|
Extras |
| |
IBM Z (Structure A) | Base |
|
Extras |
|
次のリポジトリーは、アップグレード前に subscription-manager repos --enable repository_id
コマンドを使用して 有効にできます。
アーキテクチャー | リポジトリー | リポジトリー ID |
---|---|---|
64 ビット Intel | 任意 |
|
Supplementary |
| |
IBM POWER8 (リトルエンディアン) | 任意 |
|
Supplementary |
| |
IBM POWER9 (リトルエンディアン) | 任意 |
|
Supplementary |
| |
IBM Z | 任意 |
|
Supplementary |
| |
IBM Z (Structure A) | 任意 |
|
Supplementary | 該当なし |
インプレースアップグレードの前に RHEL 7 Optional または RHEL 7 Supplementary リポジトリーを有効にすると、Leapp
は、RHEL 8 CodeReady Linux Builder リポジトリーまたは RHEL 8 Supplementary リポジトリーをそれぞれ有効にします。
カスタムリポジトリーを使用する場合は、Configuring custom repositories の指示に従って、カスタムリポジトリーを有効にします。
付録B RHEL 8 リポジトリー
Red Hat Subscription Manager(RHSM) を使用して Red Hat コンテンツ配信ネットワーク (CDN) に登録されている場合は、インプレースアップグレード時に RHEL 8 リポジトリーが自動的に有効になります。ただし、RHSM を使用して Red Hat Satellite に登録したシステムでは、アップグレード前のレポートを実行する前に、RHEL 7 と RHEL 8 の両方のリポジトリーを手動で有効化して同期する必要があります。
各リポジトリーのターゲットオペレーティングシステム (OS) バージョン (RHEL 8.6 など) を必ず有効にしてください。リポジトリーの RHEL 8 バージョンのみを有効にすると、インプレースアップグレードは抑制されます。
アップグレード時に Red Hat Satellite を使用する予定の場合には、Satellite Web UI または hammer repository-set enable
コマンドおよび hammer product synchronize
コマンドを使用して、アップグレードの前に以下の RHEL 8 リポジトリーを有効にして同期する必要 があります。
<target_os_version> は、ターゲットのオペレーティングシステム (OS) バージョン (例: 8.6) に置き換えます。
表B.1 RHEL 8 リポジトリー
アーキテクチャー | リポジトリー | リポジトリー ID | リポジトリー名 | リリースバージョン |
---|---|---|---|---|
64 ビット Intel | BaseOS |
| Red Hat Enterprise Linux 8 for x86_64 - BaseOS (RPMs) | x86_64 <target_os_version> |
AppStream |
| Red Hat Enterprise Linux 8 for x86_64 - AppStream (RPMs) | x86_64 <target_os_version> | |
IBM Power8 (リトルエンディアン) | BaseOS |
| Red Hat Enterprise Linux 8 for Power, little endian - BaseOS (RPMs) | ppc64le <target_os_version> |
AppStream |
| Red Hat Enterprise Linux 8 for Power, little endian - AppStream (RPMs) | ppc64le <target_os_version> | |
IBM Z | BaseOS |
| Red Hat Enterprise Linux 8 for IBM z Systems - BaseOS (RPMs) | s390x <target_os_version> |
AppStream |
| Red Hat Enterprise Linux 8 for IBM z Systems - AppStream (RPMs) | s390x <target_os_version> |
付録C RHEL 8 の暗号化キーの場所
Federal Information Processing Standard (FIPS) モードで実行されているシステムをアップグレードした後は、暗号化キーの再生成などを行い、すべての暗号化キーの FIPS 準拠を確認する必要があります。よく知られた暗号化キーの場所を次の表に示します。リストは完全ではないことに注意してください。他の場所も確認してください。
表C.1 RHEL 8 の暗号化キーの場所
アプリケーション | キーの場所 | 注記 |
---|---|---|
Apache mod_ssl |
|
|
Bind9 RNDC |
|
|
Cyrus IMAPd |
|
|
dnssec-trigger |
|
|
Dovecot |
|
|
OpenPegasus |
|
|
OpenSSH |
|
Ed25519 および DSA キーは FIPS に準拠していません。 |
postfix |
|
|
RHEL Web コンソール |
|
Web コンソールは |
Sendmail |
|
|
サードパーティー製アプリケーションの暗号化キーが FIPS に準拠していることを確認するには、それぞれのアプリケーションの対応するドキュメントを参照してください。また、以下に注意してください。
ポートを開くサービスが、TLS 証明書を使用する場合があります。
- すべてのサービスが暗号化キーを自動的に生成するわけではありませんが、自動的に起動する多くのサービスはデフォルトで自動生成します。
- NSS、GnuTLS、OpenSSL、libgcrypt などの暗号化ライブラリーを使用するサービスにも注意してください。
- バックアップ、ディスク暗号化、ファイル暗号化、および同様のアプリケーションも確認してください。
RHEL 8 の FIPS モードは DSA キー、DH パラメーター、1024 ビットより短い RSA キー、およびその他のいくつかの暗号を制限するため、古い暗号化キーは RHEL 7 からのアップグレード後に機能しなくなります。詳細は、「RHEL 8 の導入における検討事項」ドキュメントの コア暗号化コンポーネントの変更点 セクションと、RHEL 8「セキュリティーの強化」ドキュメントの システム全体の暗号化ポリシーの使用 の章を参照してください。
関連情報
- RHEL 8 セキュリティーの強化ドキュメントの FIPS モードへのシステムの切り替え
-
update-crypto-policies (8)
およびfips-mode-setup (8)
man ページ