RHEL 7 から RHEL 8 へのアップグレード
Red Hat Enterprise Linux 7 から Red Hat Enterprise Linux 8 へのインプレースアップグレードの手順
概要
多様性を受け入れるオープンソースの強化
Red Hat では、コード、ドキュメント、Web プロパティーにおける配慮に欠ける用語の置き換えに取り組んでいます。まずは、マスター (master)、スレーブ (slave)、ブラックリスト (blacklist)、ホワイトリスト (whitelist) の 4 つの用語の置き換えから始めます。この取り組みは膨大な作業を要するため、今後の複数のリリースで段階的に用語の置き換えを実施して参ります。詳細は、弊社 の CTO、Chris Wright のメッセージ を参照してください。
Red Hat ドキュメントへのフィードバック (英語のみ)
ご意見ご要望をお聞かせください。ドキュメントの改善点はございませんか。改善点を報告する場合は、以下のように行います。
特定の文章に簡単なコメントを記入する場合は、以下の手順を行います。
- ドキュメントの表示が Multi-page HTML 形式になっていて、ドキュメントの右上端に Feedback ボタンがあることを確認してください。
- マウスカーソルで、コメントを追加する部分を強調表示します。
- そのテキストの下に表示される Add Feedback ポップアップをクリックします。
- 表示される手順に従ってください。
より詳細なフィードバックを行う場合は、Bugzilla のチケットを作成します。
- Bugzilla の Web サイトにアクセスします。
- Component で Documentation を選択します。
- Description フィールドに、ドキュメントの改善に関するご意見を記入してください。ドキュメントの該当部分へのリンクも記入してください。
- Submit Bug をクリックします。
主な移行の用語
以下の移行用語はソフトウェア業界で一般的に使用されますが、これらの定義は Red Hat Enterprise Linux (RHEL) に固有のものです。
Update
ソフトウェアパッチと呼ばれることもあります。更新は現行バージョン、オペレーティングシステム、または実行中のソフトウェアに追加されます。ソフトウェア更新は、問題またはバグに対応し、テクノロジーの操作が改善されます。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 への移行は移行です。ユーザーをラップトップから別のサーバーに移動するか、あるサーバーから別のサーバーに会社を移行することは移行です。ただし、ほとんどの移行ではアップグレードが関係し、相互に意味のある用語が使用されることがあります。
- RHEL への移行: 既存のオペレーティングシステムの RHEL への移行
- RHEL 間での移行: RHEL のあるバージョンから別のバージョンへのアップグレード
第1章 アップグレードの計画
インプレースアップグレードは、システムを RHEL の次のメジャーバージョンにアップグレードする方法です。この方法は、推奨され、サポートされています。
RHEL 8 にアップグレードする前に、以下の点を検討する必要があります。
オペレーティングシステム - オペレーティングシステムは、以下の条件下で、
Leappユーティリティーによりアップグレードされます。利用可能な最新の RHEL 7 バージョン の Server バリアントがインストールされている。現在は以下のとおりです。
- 64 ビット Intel、IBM POWER 8 (リトルエンディアン)、および 64 ビット IBM Z アーキテクチャーでのRHEL 7.9
- カーネルバージョン 4.14 を必要とする アーキテクチャー (BM POWER 9 (リトルエンディアン)、または 64 ビット IBM Z (Structure A)) での RHEL 7.6
64 ビット Intel アーキテクチャーの SAP HANA での RHEL 7.7
詳細は「Supported in-place upgrade paths for Red Hat Enterprise Linux」を参照してください。
- RHEL 8 の最小 ハードウェア要件 が満たされている。
- 提供される最新の RHEL 7.9 および RHEL 8.4 コンテンツへのアクセス。詳細は、「アップグレードに向けて RHEL 7 システムの準備アップグレードに向けて RHEL 7 システムの準備」の手順 1 を参照してください。
-
アプリケーション -
Leappを使用して、システムにインストールされているアプリケーションを移行できます。ただし、特定のケースでは、アップグレード時にLeappが実行するアクションを指定するカスタムアクターを作成する必要があります。たとえば、アプリケーションの再設定や特定のハードウェアドライバーのインストールなどです。詳細は、「Handling the migration of your custom and third-party applications」を参照してください。Red Hat は、カスタムアクターに対応していません。 Security - アップグレード前にこの要素を評価し、アップグレードプロセスの完了時に追加の手順を実行する必要があります。特に以下の点を考慮してください。
- アップグレードの前に、システムが準拠する必要のあるセキュリティー標準を定義し、「RHEL 8 のセキュリティー変更」を理解します。
-
Leappユーティリティーは、アップグレードプロセス時に SELinux モードを Permissive に設定します。 - FIPS モードでのシステムのインプレースアップグレードはサポートされていません。
- アップグレードが完了したら、セキュリティーポリシーを再評価し、再適用します。アップグレード中に無効になった、または RHEL 8 で新たに導入されたセキュリティーポリシーを適用する方法は、セキュリティーポリシーの適用 を参照してください。
- ストレージおよびファイルシステム - アップグレードする前に、必ずシステムのバックアップを作成してください。たとえば、ReaR (Relax-and-Recover) ユーティリティー、LVM スナップショット、RAID 分割、または仮想マシンのスナップショットを使用できます。
- ダウンタイム - アップグレードプロセスには数分から数時間かかる場合があります。
- Satellite: Satellite からホストを管理する場合は、Satellite Web UI を使用して RHEL 7 から RHEL 8 に複数のホストを同時にアップグレードできます。詳細は、「RHEL 7 から RHEL 8 へのホストのアップグレード」を参照してください。
- SAP HANA - SAP HANA を使用している場合は、「SAP 環境を RHEL 7 から RHEL 8 にインプレースアップグレードする方法」に従ってください。SAP HANA を使用した RHEL のアップグレードパスは異なる場合があることに注意してください。
- パブリッククラウド： インプレースアップグレードは、Amazon Web Services(AWS)および Red Hat Update Infrastructure(RHUI)を使用した Microsoft Azure のオンデマンドの Pay-As-You-Go(PAYG) インスタンスでサポートされます。インプレースアップグレードは、RHEL サブスクリプションに RHSM を使用するすべてのパブリッククラウドで 独自のサブスクリプションインスタンスを提供する場合にもサポートされています。
既知の制限 - 現在、
Leappの注目すべき既知の制限には以下が含まれます。- 現在、ディスク全体またはパーティションの暗号化、またはファイルシステムの暗号化は、インプレースアップグレードの対象となるシステムでは使用できません。
- ネットワークベースのマルチパスやネットワークストレージマウントは、システムパーティション (iSCSI、NFS など) として使用できません。
- 現在、インプレースアップグレードは、RHEL サブスクリプションに Red Hat Subscription Manager(RHSM)を使用する残りのパブリッククラウド（Huawei Cloud、Alibaba Cloud、Google Cloud）のオンデマンド PAYG インスタンスではサポートされません。
既知の問題 も参照してください。
Red Hat Insights を使用して、Insights に登録したどのシステムが RHEL 8 に対する対応アップグレードパスであるかを確認できます。これを行うには、Insights の該当する Advisor 推奨事項 に移動し、Actions ドロップダウンメニューで推奨事項を有効にして、Affected system の見出しにある一覧を確認します。Advisor 推奨は RHEL 7 マイナーバージョンのみを考慮し、システムのアップグレード前の評価は行わないことに注意してください。
第2章 アップグレードに向けて 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 が以下の条件を満たしていることを確認してください。
- Satellite は、フルサポートまたはメンテナンスサポートがあるバージョンです。詳細は、「Red Hat Satellite の製品ライフサイクル」を参照してください。
- Satellite には、RHEL 8 リポジトリーをインポートしたサブスクリプションマニフェストがあります。詳細は、Red Hat Satellite の特定のバージョン (バージョン 6.8 など) の『コンテンツ管理ガイド』の「サブスクリプションの管理」を参照してください。
以下のリポジトリーが有効になり、最新の更新と同期され、Satellite で公開されています。たとえば、延長アップデートサポート (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 8 (RPM)
rhel-8-for-x86_64-appstream-rpms
x86_64 8.4
Red Hat Enterprise Linux 8 for x86_64 - BaseOS (RPMs)
rhel-8-for-x86_64-baseos-rpms
x86_64 8.4
詳細は、Red Hat Satellite の特定バージョン (バージョン 6.8 など) の『コンテンツ管理ガイド』の「Red Hat コンテンツのインポート」の章を参照してください。
コンテンツホストは以下のいずれかに属します。
- 上記の RHEL 7 リポジトリーおよび RHEL 8 リポジトリーを含むコンテンツビュー。
デフォルトの組織ビューコンテンツビューとライブラリーのライフサイクル環境。
詳細は、Red Hat Satellite の特定のバージョン (バージョン 6.8 など) の『コンテンツ管理ガイド』の「コンテンツビューの管理」を参照してください。
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-rpmsLeappおよびその依存関係が利用可能な Extras リポジトリーを有効にします。# subscription-manager repos --enable rhel-7-server-extras-rpms注記Optional リポジトリーまたは Supplementary リポジトリーも有効にすることができます。RHEL7 リポジトリー の一覧をご覧ください。この場合、
Leappは、RHEL 8 CodeReady Linux Builder リポジトリーまたは RHEL 8 Supplementary リポジトリーをそれぞれ有効にします。
最新の RHEL 7 コンテンツを利用するように Red Hat Subscription Manager を設定します。
# subscription-manager release --unset- 必要に応じて、カスタムリポジトリーを使用する場合は、「Customizing your Red Hat Enterprise Linux in-place upgrade」の指示に従って設定します。
yum-plugin-versionlockプラグインを使用して、パッケージを特定バージョンにロックする場合は、次のコマンドを実行してロックを解除します。# yum versionlock clear詳細は「指定したバージョンのパッケージ (または指定したバージョン以前のパッケージ) だけをインストールまたはアップグレードできるように yum の使用を制限する方法」を参照してください。
システムロケールが
en_US.UTF-8に設定されていることを確認します。$ cat /etc/locale.confロケールが異なる場合は、「RHEL7 のシステムロケールを変更する」を参照してください。
パブリッククラウドで 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」を参照してください。
- 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システムを再起動します。
# rebootLeappユーティリティーをインストールします。# yum install leapp leapp-repository現在、バージョン 0.12.1 以降の
leappパッケージとバージョン 0.14.0 以降のleapp-repositoryパッケージが必要という点に注意してください。追加の必要なデータファイル (RPM パッケージの変更、RPM パッケージマッピング、サポート対象外のドライバー、およびサポート対象外の PCI) の最新バージョンにアクセスできることを確認します。
- アップグレードに RHSM を使用する場合で、システムが cloud.redhat.com にアクセスでき、必要なデータファイルの以前のバージョンをダウンロードしていない場合は、それ以上のアクションは必要ありません。データファイルは cloud.redhat.com から自動的にダウンロードされます。これは、開発者サブスクリプションにも適用されます。
ナレッジベースアーティクルの「RHEL 7 から RHEL 8 へのインプレースアップグレード時に Leapp ユーティリティーで必要なデータ」に添付されているデータファイルをダウンロードして、
/etc/leapp/files/ディレクトリーに置きます。これは、アップグレードを成功させるために必要です。現在、leapp-data14.tar.gzアーカイブまたはそれ以降のデータファイルが必要になることに注意してください。これは、以下のシナリオでアップグレードを成功させるために必要になります。- RHUI を使用してパブリッククラウドでアップグレードします。Red Hat サブスクリプションまたは Red Hat カスタマーポータルアカウントをお持ちでない場合は、ナレッジベースの記事にアクセスし、必要なデータパッケージをダウンロードできるように、無料の RHEL 開発者サブスクリプションを作成してください。詳細は「How do I get a no-cost Red Hat Enterprise Linux Developer Subscription or renew it?」を参照してください。
- お使いのシステムにインターネットアクセスがありません。
- アップグレードに RHSM を使用し、必要なデータファイルの古いバージョンを以前ダウンロードしたが、アップグレードを実行しませんでした (例: 自動化スクリプトの作成など)。古いバージョンのデータファイルを削除して、最新のファイルバージョンを自動的にダウンロードすることもできます。
- アップグレードの失敗を防ぐために一時的にウイルス対策ソフトウェアを無効にします。
- (Salt、Chef、Puppet、Ansible などの) 設定管理を無効にしているか、元の RHEL7 システムを復元しないように適切に再設定していることを確認します。
-
システムで、カーネル (
eth) が使用する接頭辞に基づいた名前で、複数の Network Interface Card (NIC) が使用されていないことを確認します。RHEL 8 へのインプレースアップグレードの前に別の命名スキームに移行する方法は「RHEL 7 でカーネルの NIC 名を使用している場合に RHEL 8 へのインプレースアップグレードを実行する方法 」を参照してください。 - システム全体のバックアップまたは仮想マシンのスナップショットが存在することを確認してください。これにより、ご利用の環境で、以下の標準の災害復旧手順に従って、システムをアップグレード前と同じ状態に戻せるようになります。たとえば、ReaR (Relax-and-Recover) ユーティリティーを使用できます。詳細は、ReaR のドキュメント および「Relax and Recover(ReaR) の概要」を参照してください。または、LVM スナップショット または RAID 分割 を使用することもできます。仮想マシンをアップグレードする場合は、仮想マシン全体のスナップショットを作成できます。
Red Hat Subscription Manager を使用してアップグレードし、yum または yum4 の
subscription-managerプラグインを無効にしている場合は、プラグインを再度有効にします。詳細は「yum プラグインの有効化、設定、および無効にする方法」を参照してください。yum で
subscription-managerプラグインが有効になっているかどうかを確認するには、以下のコマンドを実行します。# yum 2>&1 | head
ロードした
プラグインで生成されたリストを確認し、subscription-managerが含まれるかどうかを判断します。
第3章 アップグレード前のレポートの確認
システムのアップグレード可能性を評価するには、leapp preupgrade コマンドでアップグレード前のプロセスを開始します。このフェーズでは、Leapp ユーティリティーがシステムに関するデータを収集し、アップグレードの可能性を評価し、アップグレード前のレポートを生成します。
アップグレード前のレポートは、/var/log/leapp/leapp-report.txt ファイルと Web コンソールの両方で利用できます。レポートは潜在的な問題を要約し、推奨される解決策を提案します。このレポートは、アップグレードを進めることが可能かどうかの判断にも役立ちます。
特定の設定では、Leapp により true/false 質問が生成され、続行方法が決まります。質問はすべて、/var/log/leapp/answerfile と、Missing required answers in the answer file メッセージのプレアップグレードレポートに保存されます。すべての質問に回答しなかった場合には、Leapp によりアップグレードが行われません。
アップグレード前のフェーズでアップグレード可能性を評価するには、以下のオプションがあります。
-
生成された
leapp-report.txtファイルのアップグレード前レポートを確認し、コマンドラインインターフェースを使用して、報告された問題を手動で解決します。 - Web コンソールを使用してレポートを確認し、利用可能な場合は自動修復を適用し、推奨される修復ヒントを使用して残りの問題を修正します。
アップグレード前のフェーズでは、Leapp がインプレースアップグレードプロセス全体をシミュレートしたり、すべての RPM パッケージをダウンロードしません。
アップグレード前のレポートを確認すると、インプレースアップグレードプロセスなしで RHEL 8 システムを再デプロイする必要がある場合にも役立ちます。
たとえば、独自のカスタムスクリプトを使用してアップグレード前のレポートを処理し、異なる環境間にある複数のレポートの結果を比較できます。詳細は「Red Hat Enterprise Linux のアップグレード前のレポートワークフローの自動化」を参照してください。
3.1. コマンドラインからのアップグレード可能性の評価
コマンドラインインターフェースを使用して、アップグレード前のフェーズで潜在的なアップグレードの問題を特定します。
前提条件
- 「アップグレードに向けて RHEL 7 システムの準備」の手順が完了しました。
手順
RHEL 7 システムで、アップグレード前のフェーズを別途実行します。
# leapp preupgrade注記アップグレードに
/etc/yum.repos.d/ディレクトリーの カスタムリポジトリー を使用する場合は、以下のように選択したリポジトリーを有効にします。# leapp preupgrade --enablerepo repository_id1 --enablerepo repository_id2 ...
RHSM を使用しないアップグレード を行う場合や RHSM を使用する場合は、
--no-rhsmオプションを追加します。以下の方法のいずれかを使用して、
Leappが必要とする各質問に回答を提供します。leapp answerコマンドを実行して、応答している質問と、確認した質問を指定します。# leapp answer --section question_section.confirm=answer
たとえば、「PAM 設定で pam_pkcs11 モジュールを無効にするか？」という質問に
Trueを確定するには、以下のコマンドを実行します。# leapp answer --section remove_pam_krb5_module_check.confirm=True
-
/var/log/leapp/answerfileファイルを手動で編集し、#記号を削除してファイルのconfirm行のコメントを解除し、TrueまたはFalseとして回答を確定します。「Leapp answerfile」を参照してください。
-
/var/log/leapp/leapp-report.txtファイルのレポートを調べて、インプレースアップグレードに進む前に、報告されたすべての問題を手動で解決します。
3.2. Web コンソールでアップグレードの可能性の評価および自動修復の適用
アップグレード前のフェーズで潜在的な問題と、Web コンソールを使用して自動修復を適用する方法を特定します。
前提条件
- 「アップグレードに向けて RHEL 7 システムの準備」の手順が完了しました。
手順
cockpit-leappプラグインをインストールします。# yum install cockpit-leapp-
ブラウザーで Web コンソールに移動し、
rootまたは/etc/sudoersファイルで設定したユーザーとしてログインします。Web コンソールの詳細は、「RHEL 7 Web コンソールを使用したシステムの管理」を参照してください。 RHEL 7 システムで、コマンドラインインターフェースまたは Web コンソールの端末からアップグレード前のフェーズを実行します。
# leapp preupgrade注記アップグレードに
/etc/yum.repos.d/ディレクトリーの カスタムリポジトリー を使用する場合は、以下のように選択したリポジトリーを有効にします。# leapp preupgrade --enablerepo repository_id1 --enablerepo repository_id2 ...
RHSM を使用しないアップグレード を行う場合や RHSM を使用する場合は、
--no-rhsmオプションを追加します。Web コンソールで、左側のメニューから を選択します。
図3.1 Web コンソールのインプレースアップグレードレポート
レポートの表には、見つかった問題の概要、リスク評価、および修復 (利用可能な場合) が記載されています。
リスク要因:
- 高 - システム状態が悪化する可能性が非常に高い
- 中 - システムとアプリケーションの両方に影響を与える可能性がある
- 低 - システムに影響はないが、アプリケーションに影響を与える可能性がある
- 情報 - システムまたはアプリケーションへの影響がないと考えられる情報
- インヒビター - アップグレードプロセスを抑制 (ハードストップ) する。抑制しないと、システムが起動できず、アクセスできず、または機能しなくなる可能性があります。
修復 - 報告された問題に対する実行可能な解決策
- 修復コマンド - Web コンソールから直接実行可能
- 修復のヒント - 問題を手動で解決する方法の手順
レポートの内容を調べます。ヘッダーをクリックして、テーブルを並べ替えることができます。詳細ペインを開くには、選択した行をクリックします。
図3.2 詳細ペイン
詳細ペインには、次の追加情報が表示されます。
- 問題の概要と、問題を詳細に説明するナレッジベース記事へのリンク
- 修復 - 自動修復 (利用可能な場合) を実行またはスケジュールし、適用時にその結果を確認できます。
- 影響を受けるシステムリソース: パッケージ、リポジトリー、ファイル (構成、データ)、ディスク、ボリューム
必要に応じて、結果をフィルタリングします。レポートの左上隅にある ボタンをクリックし、設定に基づいてフィルターを適用します。フィルターカテゴリーは、相互に関連して適用されます。
図3.3 フィルター
自動修復を適用する問題を選択します。2 つのオプションがあります。
- 詳細ペインの ボタンをクリックして、個々の項目を選択します。また、詳細ペインで をクリックして、個々の修正を直接実行できます。
- レポートの右上隅にある ボタンをクリックして、修復が利用可能なすべての項目を選択します。
Web コンソールで
Leappで必要な質問を確認し、回答します。未回答の質問はそれぞれ、Upgrade Report でMissing required answers in the answer fileとして表示されます。質問に答えるタイトルを選択します。-
デフォルトの
Trueの応答を確認するには、 を選択して修復を後で実行するか、または を選択して修復を即座に実行します。 デフォルト以外の回答を選択するには、以下のいずれかを実行します。
leapp answerコマンドを実行して、応答している質問と、確認した質問を指定します。# leapp answer --section question_section.confirm=answer
たとえば、「PAM 設定で pam_pkcs11 モジュールを無効にするか？」という質問に
Falseを確定するには、以下のコマンドを実行します。# leapp answer --section remove_pam_krb5_module_check.confirm=False
/var/log/leapp/answerfileファイルを手動で編集し、#記号を削除してファイルのconfirm行のコメントを解除し、TrueまたはFalseとして回答を確定します。「Leapp answerfile example」を参照してください。図3.4 未回答の Leapp 質問がない
-
デフォルトの
レポートの右上隅にある リンクをクリックして、修復計画を開きます。修復計画には、実行した修復、または予定されている修復の一覧が示されます。
図3.5 修復計画
をクリックして、予定されている修復をすべて処理します。修復エントリーごとに次の情報が表示されます。
- 修復の一意の ID
- コマンドの終了ステータス
- 実行された修復の経過時間
- 標準出力
- 標準エラー
-
選択した修復を実行した後に、
leapp preupgradeコマンドを使用してアップグレード前のレポートを再生成し、新しいレポートを調べてから、必要に応じて追加の修復手順を実行します。
第4章 RHEL 7 から RHEL 8 へのアップグレードの実行
Leapp ユーティリティーを使用して RHEL 8 にアップグレードします。
前提条件
- フルシステムバックアップを含め、「アップグレードに向けて RHEL 7 システムの準備」の手順が完了しました。
- 「アップグレード前のレポートの確認」に記載されている手順が完了し、報告されたすべての問題が解決されました。
手順
RHEL 7 システムで、アップグレードプロセスを開始します。
# leapp upgrade注記アップグレードに
/etc/yum.repos.d/ディレクトリーの カスタムリポジトリー を使用する場合は、以下のように選択したリポジトリーを有効にします。# leapp upgrade --enablerepo repository_id1 --enablerepo repository_id2 ...
RHSM を使用しないアップグレード を行う場合や RHSM を使用する場合は、
--no-rhsmオプションを追加します。アップグレードプロセスの開始時に、
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 システムのアップグレード後の状態の確認」で説明されているように状態を確認します。
- 「アップグレード後のタスクの実行」で説明されているように、アップグレード後のタスクを完了します。特に、セキュリティポリシーを再評価して再適用します。
第5章 RHEL 8 システムのアップグレード後の状態の確認
この手順は、RHEL 8 へのインプレースアップグレード後に実行が推奨される検証手順を紹介します。
前提条件
- 「RHEL 7 から RHEL 8 へのアップグレードの実行」に記載されている手順に従ってシステムをアップグレードし、RHEL 8 にログインできる。
手順
アップグレードが完了したら、システムが必要な状態になっていることを確認します。少なくとも以下の確認を行います。
現在のオペレーティングシステムのバージョンが Red Hat Enterprise Linux 8 であることを確認します。
# cat /etc/redhat-release Red Hat Enterprise Linux release 8.4 (Ootpa)オペレーティングシステムのカーネルバージョンを確認します。
# uname -r 4.18.0-304.el8.x86_64.el8が重要です。Red Hat Subscription Manager を使用している場合:
正しい製品がインストールされていることを確認します。
# subscription-manager list --installed +-----------------------------------------+ Installed Product Status +-----------------------------------------+ Product Name: Red Hat Enterprise Linux for x86_64 Product ID: 479 Version: 8.4 Arch: x86_64 Status: Subscribedアップグレード直後にリリースバージョンが 8.4 に設定されていることを確認します。
# subscription-manager release Release: 8.4
- ネットワークサービスが機能していることを確認します。たとえば、SSH を使用してサーバーに接続します。
- アプリケーションのアップグレード後のステータスを確認します。場合によっては、移行や設定を手動で変更しないといけない場合があります。たとえば、データベースを移行するには、RHEL 8 データベースサーバーのドキュメント の説明に従ってください。
第6章 アップグレード後のタスクの実行
この手順は、RHEL 8 へのインプレースアップグレード後に実行が推奨される主要タスクを紹介します。
前提条件
- 「RHEL 7 から RHEL 8 へのアップグレードの実行」に記載されている手順に従ってシステムをアップグレードし、RHEL 8 にログインできる。
- 「RHEL 8 システムのアップグレード後のステータスの確認」で説明されている手順に従って、インプレースアップグレードのステータスを確認します。
手順
アップグレードが完了したら、以下のタスクを実行します。
残りの RHEL 7 パッケージを削除します。
残りの RHEL 7 パッケージを見つけます。
# rpm -qa | grep -e '\.el[67]' | grep -vE '^(gpg-pubkey|libmodulemd|katello-ca-consumer)' | sort
古いカーネルバージョンを確認します。
# 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
ブートローダーエントリーから古いカーネルを削除します。
# /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
AWS または Microsoft Azure で RHUI を使用してアップグレードし、ソフトウェア認定が後続のマイナーリリースバージョンで利用できない場合は、認定がサポートするマイナーリリースバージョンにシステムをロックします。
# echo '8.x' > /etc/yum/vars/releasever- セキュリティポリシーを再評価して再適用します。具体的には、SELinux モードを Enforcing に変更します。詳細は、「セキュリティーポリシーの適用」を参照してください。
第7章 セキュリティーポリシーの適用
インプレースアップグレードプロセスでは、特定のセキュリティーポリシーを無効にしたままにする必要があります。さらに、RHEL 8 ではシステム全体の暗号化ポリシーという概念が新たに導入され、セキュリティープロファイルにはメジャーリリース間の変更が含まれる可能性があります。本セクションでは、アップグレードした RHEL システムのセキュリティーを保護する方法を説明します。
7.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/configSELINUX=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
7.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 ページ。
7.3. セキュリティーベースラインへのシステムの修復
OpenSCAP スイートは、システムが PCI-DSS、OSPP、ACSC E8 などのセキュリティーベースラインに準拠する修正を提供します。以下の手順に従って、PCI-DSS プロファイルに準拠するようにシステム設定を変更します。
Red Hat は、セキュリティーを強化した修正で加えられた変更を元に戻す自動手段は提供していません。修正は、デフォルト設定の RHEL システムで対応しています。インストール後にシステムが変更した場合は、修正を実行しても、必要なセキュリティープロファイルに準拠しない場合があります。
前提条件
-
RHEL 8 システムに、
scap-security-guideパッケージがインストールされている。
手順
oscapコマンドに--remediateオプションを指定して使用します。# oscap xccdf eval --profile pci-dss --remediate /usr/share/xml/scap/ssg/content/ssg-rhel8-ds.xml前述の例の pci-dss は、シナリオに必要なプロファイルに置き換えることができます。
システムを再起動します。
# reboot
検証
そのシステムが PCI-DSS プロファイルにどのように準拠しているかを評価し、結果を pcidss_report.html ファイルに保存します。
$ oscap xccdf eval --report pcidss_report.html --profile pci-dss /usr/share/xml/scap/ssg/content/ssg-rhel8-ds.xml
関連情報
- セキュリティーコンプライアンスおよび脆弱性スキャンの開始
-
man ページの
scap-security-guide (8) -
oscap(8)man ページ
第8章 トラブルシューティング
RHEL 7 から RHEL 8 へのアップグレードのトラブルシューティングには、以下のヒントを参照してください。
8.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 のアップグレード前のレポートワークフローの自動化」を参照してください。
8.2. トラブルシューティングのヒント
以下のトラブルシューティングのヒントを参照してください。
アップグレード前のフェーズ
- アップグレードの計画に記載されている条件をすべて満たしていることを確認します。
-
Preparing a RHEL 7 system 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 コンソールを使用することも可能です。
例8.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/ディレクトリーにあるトランザクションデバッグデータを調べてください。
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」を参照してください。
8.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 システムが FCoE 論理ユニット番号 (LUN) にインストールされ、
bnx2fcドライバーを使用するネットワークカードに接続している場合、その LUN はアップグレード後に RHEL 8 で検出されません。したがって、アップグレードしたシステムは起動できません。(BZ#1718147) -
RHEL 7 システムで、Red Hat が提供しているにもかかわらず RHEL 8 で利用できないデバイスドライバーを使用している場合は、
Leappでアップグレードが行われません。ただし、RHEL 7 システムが、削除されたドライバーのリスト (/etc/leapp/repos.d/system_upgrade/el7toel8/actors/kernel/checkkerneldrivers/files/removed_drivers.txt) に含まれていないサードパーティーのデバイスドライバーを使用している場合、Leappはそのようなドライバーを検出しないため、アップグレードを続行します。したがって、アップグレード後にシステムが起動しない場合があります。
この時点では、Samba モジュールの
winbindおよびwinsが/etc/nsswitch.confファイルで使用されていると、インプレースアップグレードを実行できません。このシナリオでは、アップグレードトランザクションが失敗して次のエラーが表示され、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モジュールが含まれ、これらのモジュールに必要不可欠または必須の制御値がある場合は、インプレースアップグレードを実行すると、システムからロックアウトされる可能性があります。この問題を回避するには、アップグレードプロセスを開始する前に、RHEL 7 システムを再構成して、pam_krb5またはpam_pkcs11を使用しないようにします。
-
IBM Zシステムでは、
Leappでは、DASD ディスクが常に接続されていることが必要になります。したがって、/etc/dasd.confファイルが存在しない場合、インプレースアップグレードは失敗します。この問題を回避するには、touch > /etc/dasd.confコマンドを使用して、空のdasd.confファイルを作成します。(BZ#1783248) お使いのシステムに (Red Hat が署名していない) サードパーティーパッケージの名前が、Red Hat が提供するパッケージと同じ場合は、インプレースアップグレードに失敗します。この問題を回避するには、アップグレードする前に、以下のいずれかのオプションを選択します。
- サードパーティーパッケージの削除
- サードパーティーパッケージを、Red Hat が提供するパッケージに置き換えます。
-
インプレースアップグレード時に、
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)
セキュリティー上の理由から、RHEL 8 では、single-DES (DES) および triple-DES (3DES) の暗号化タイプに対応しなくなりました。ただし、RHEL 7 Identity Management (IdM) は引き続き 3DES 暗号化に対応しています。
RHEL 7 から RHEL 8 への IdM 環境を、RHEL 7 にアップグレードできます。これは、両方のバージョンが、デフォルトでより強力な AES 暗号化タイプを優先するためです。IdM のバージョン デフォルトの暗号化タイプ その他のサポートされる暗号化タイプ RHEL 7
aes256-ctsaes128-ctscamellia256-ctscamellia128-ctsdes3-hmacarcfour-hmacRHEL 8
aes256-ctsaes128-ctsaes256-sha2aes128-sha2camellia256-ctscamellia128-ctsarcfour-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)
- ReaR(Relax-and-Recover)ユーティリティーは、IBM Z アーキテクチャーでは利用できません。したがって、IBM Z システムは OpenSCAP スイートで完全に修正することはできず、セキュリティーベースラインに完全に準拠しない可能性があります。(BZ# 1958939)
8.4. サポートの利用
サポートケースを作成するには、製品で RHEL 8 を選択し、システムの sosreport を添付します。
-
システムで
sosreportを生成するには、次のコマンドを実行します。
# sosreportケース ID は空のままにできます。
sosreport を生成する方法は、ナレッジベースのソリューション「Red Hat Enterprise Linux 上での sosreport の役割と取得方法」を参照してください。
カスタマーポータルでサポートケースを作成し、管理する方法は、ナレッジベースのアーティクル「カスタマーポータルでサポートケースを作成および管理する」を参照してください。
付録A RHEL 7 リポジトリー
アップグレードの前に、「アップグレードに向けて RHEL 7 システムの準備」の手順 3 で説明されているように、適切なリポジトリーを有効になっていることを確認してください。
アップグレード時に 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」の指示に従って、カスタムリポジトリーを有効にします。