Menu Close
Settings Close

Language and Page Formatting Options

RHEL 7 から RHEL 8 へのアップグレード

Red Hat Enterprise Linux 8

Red Hat Enterprise Linux 7 から Red Hat Enterprise Linux 8 へのインプレースアップグレードの手順

概要

本ガイドは、Leapp ユーティリティーを使用した、Red Hat Enterprise Linux 7 から Red Hat Enterprise Linux 8 へのインプレースアップグレードを実行する方法を説明します。既存の RHEL 7 オペレーティングシステムは、インプレースアップグレード時に RHEL 8 バージョンに置き換えられます。

多様性を受け入れるオープンソースの強化

Red Hat では、コード、ドキュメント、Web プロパティーにおける配慮に欠ける用語の置き換えに取り組んでいます。まずは、マスター (master)、スレーブ (slave)、ブラックリスト (blacklist)、ホワイトリスト (whitelist) の 4 つの用語の置き換えから始めます。この取り組みは膨大な作業を要するため、今後の複数のリリースで段階的に用語の置き換えを実施して参ります。詳細は、Red Hat CTO である Chris Wright のメッセージ を参照してください。

Red Hat ドキュメントへのフィードバック

当社のドキュメントに関するご意見やご感想をお寄せください。また、改善点があればお知らせください。

特定の文章に関するコメントの送信

  1. Multi-page HTML 形式でドキュメントを表示し、ページが完全にロードされてから右上隅に Feedback ボタンが表示されていることを確認します。
  2. カーソルを使用して、コメントを追加するテキスト部分を強調表示します。
  3. 強調表示されたテキストの近くに表示される Add Feedback ボタンをクリックします。
  4. フィードバックを追加し、Submit をクリックします。

Bugzilla からのフィードバック送信 (アカウントが必要)

  1. Bugzilla の Web サイトにログインします。
  2. Version メニューから正しいバージョンを選択します。
  3. Summary フィールドにわかりやすいタイトルを入力します。
  4. Description フィールドに、ドキュメントの改善に関するご意見を記入してください。ドキュメントの該当部分へのリンクも追加してください。
  5. 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 7 オペレーティングシステムを RHEL 8 バージョンに置き換えます。

現在、RHEL 7 から次の RHEL 8 マイナーバージョンへのインプレースアップグレードを実行できます。

表1.1 サポート対象のアップグレードパス

アーキテクチャーおよび製品バリアントソース OS バージョンターゲット OS バージョン

64 ビット Intel、IBM POWER 8(リトルエンディアン)、および 64 ビット IBM Z

RHEL 7.9

RHEL 8.4

RHEL 8.6(デフォルト)

IBM POWER 9(リトルエンディアン) および IBM Z(Structure A)

RHEL 7.6

RHEL 8.4

RHEL for SAP

RHEL 7.9

RHEL 8.2

RHEL 8.6(デフォルト)

サポート対象のアップグレードパスの詳細は、Supported in-place upgrade paths for Red Hat Enterprise Linux を参照してください。

第2章 アップグレードの計画

インプレースアップグレードは、システムを RHEL の次のメジャーバージョンにアップグレードする方法です。この方法は、推奨され、サポートされています。

RHEL 8 にアップグレードする前に、以下の点を検討する必要があります。

  • オペレーティングシステム - オペレーティングシステムは、以下の条件下で、Leapp ユーティリティーによりアップグレードされます。

    • 利用可能な最新の RHEL 7 バージョン の Server バリアントがインストールされている。現在は以下のとおりです。

      • 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 など)へのアクセス。詳細は、Preparing a RHEL 7 system for the upgrade の手順 1 を参照してください。
  • アプリケーション - Leapp を使用して、システムにインストールされているアプリケーションを移行できます。ただし、特定のケースでは、アップグレード時に Leapp が実行するアクションを指定するカスタムアクターを作成する必要があります。たとえば、アプリケーションの再設定や特定のハードウェアドライバーのインストールなどです。詳細は、Handling the migration of your custom and third-party applications を参照してください。Red Hat は、カスタムアクターに対応していません。
  • Security - アップグレード前にこの要素を評価し、アップグレードプロセスの完了時に追加の手順を実行する必要があります。特に以下の点を考慮してください。

    • アップグレードの前に、システムが準拠する必要のあるセキュリティー標準を定義し、RHEL 8 のセキュリティー変更 を理解してください。
    • Leapp ユーティリティーは、アップグレードプロセス時に SELinux モードを Permissive に設定します。
    • FIPS モードでのシステムのインプレースアップグレードはサポートされていません。

      注記

      FIPS をオフにし、RHEL 7 から 8 にアップグレードすると、Red Hat では FIPS をオンにすることはサポートされません。FIPS に準拠するには、すべての暗号化キーは FIPS で検証された暗号モジュールでのみ使用する必要があります。したがって、アップグレード後に FIPS をオンにすることは、暗号化キーを再生成せずにサポートすることはできません。Red Hat は作成された暗号鍵をすべて追跡するわけではないため、このタスクを自動化できないことに注意してください。

    • アップグレードが完了したら、セキュリティーポリシーを再評価し、再適用します。アップグレード中に無効になった、または RHEL 8 で新たに導入されたセキュリティーポリシーを適用する方法は、セキュリティーポリシーの適用 を参照してください。
  • ストレージおよびファイルシステム - アップグレードする前に、必ずシステムのバックアップを作成してください。たとえば、Relax-and-Recover (ReaR) ユーティリティーLVM スナップショットRAID 分割、または仮想マシンのスナップショットを使用できます。

    注記

    ファイルシステム形式はそのままです。つまり、ファイルシステムには最初に作成されたときと同じ制限があります。

  • 高可用性: High Availability アドオンを使用したシステムのアップグレードはサポートされていません。
  • ダウンタイム - アップグレードプロセスには数分から数時間かかる場合があります。
  • Satellite: Satellite からホストを管理する場合は、Satellite Web UI を使用して RHEL 7 から RHEL 8 に複数のホストを同時にアップグレードできます。詳細は、Upgrading Hosts from RHEL 7 to RHEL 8 を参照してください。
  • 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 サブスクリプションに RHSM を使用するすべてのパブリッククラウドの Bring Your Own Subscription インスタンスでもサポートされます。
  • 言語: すべての Leapp のレポート、ログ、その他の生成されたドキュメントは、言語設定に関わらず、英語で表示されます。
  • Bootloader: 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 を使用して Red Hat Subscription Manager (RHSM) を使用しない、残りのパブリッククラウド (Huawei Cloud、Alibaba Cloud) のオンデマンドインスタンスではサポートされません。

既知の問題 も参照してください。

Red Hat Insights を使用して、Insights に登録したどのシステムが RHEL 8 に対する対応アップグレードパスであるかを確認できます。これを行うには、Insights の該当する Advisor 推奨事項 に移動し、Actions ドロップダウンメニューで推奨事項を有効にして、Affected systems の見出しにある一覧を確認します。Advisor 推奨は RHEL 7 マイナーバージョンのみを考慮し、システムのアップグレード前の評価は行わないことに注意してください。Advisor サービスの推奨事項 も参照してください。

第3章 アップグレードの準備

アップグレード後に問題を回避し、システムを RHEL の次のメジャーバージョンにアップグレードできることを確認するには、アップグレード前に必要なすべての準備手順を完了してください。

すべてのシステムで、Preparing a RHEL 7 system for the upgrade で説明されている準備手順を実施する必要があります。さらに、Satellite Server に登録されているシステムでは、Preparing a Satellite system for the upgrade で説明されている準備手順も実行する必要があります。

3.1. アップグレードに向けて RHEL 7 システムの準備

この手順では、Leapp ユーティリティーを使用して RHEL 8 へのインプレースアップグレードを実行する前に必要な手順を説明します。

アップグレードプロセス中に Red Hat Subscription Manager を使用する予定がない場合は、Upgrading to RHEL 8 without Red Hat Subscription Manager を参照してください。

前提条件

手順

  1. Red Hat Subscription Manager を使用して、システムが Red Hat コンテンツ配信ネットワーク (CDN) または Red Hat Satellite に正常に登録されていることを確認します。
  2. システムが Satellite Server に登録されている場合は、Preparing a Satellite system for the upgrade の手順を実行して、システムがアップグレードの要件を満たしていることを確認します。
  3. 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 が表示され、ステータスとして サブスクライブされ ているはずです。

  4. 適切なリポジトリーが有効になっていることを確認します。以下のコマンドは、64 ビット Intel アーキテクチャーのリポジトリーを一覧表示します。他のアーキテクチャーについては、RHEL 7 リポジトリー を参照してください。

    1. Base リポジトリーを有効にします。

      # subscription-manager repos --enable rhel-7-server-rpms
    2. Leapp およびその依存関係が利用可能な Extras リポジトリーを有効にします。

      # subscription-manager repos --enable rhel-7-server-extras-rpms
      注記

      Optional リポジトリーまたは Supplementary リポジトリーも有効にすることができます。RHEL 7 リポジトリー の一覧を参照してください。この場合、Leapp は、RHEL 8 CodeReady Linux Builder リポジトリーまたは RHEL 8 Supplementary リポジトリーをそれぞれ有効にします。

  5. 最新の RHEL 7 コンテンツを利用するように Red Hat Subscription Manager を設定します。

    # subscription-manager release --unset
  6. 必要に応じて、カスタムリポジトリーを使用する場合は、Customizing your Red Hat Enterprise Linux in-place upgrade の指示に従って設定します。
  7. yum-plugin-versionlock プラグインを使用して、パッケージを特定バージョンにロックする場合は、次のコマンドを実行してロックを解除します。

    # yum versionlock clear

    詳細は 指定したバージョンのパッケージ (または指定したバージョン以前のパッケージ) だけをインストールまたはアップグレードできるように yum の使用を制限する方法 を参照してください。

  8. パブリッククラウドで Red Hat Update Infrastructure(RHUI) を使用してアップグレードする場合は、必要な RHUI リポジトリーを有効にして、必要な RHUI パッケージをインストールし、システムをアップグレードする準備ができていることを確認します。

    1. 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
    2. 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 を参照してください。

    3. Google Cloud Platform の場合は、ナレッジベース記事 Leapp RHUI packages for Google Cloud Platform (GCP) に従います。
  9. 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? を参照してください。
  10. すべてのパッケージを最新の RHEL 7 バージョンに更新します。

    # yum update
  11. システムを再起動します。

    # reboot
  12. Leapp ユーティリティーをインストールします。

    # yum install leapp-upgrade

    現在、leapp パッケージのバージョン 0.15.0 以降と、 leapp -upgrade-el7toel8 RPM パッケージを含むバージョン 0.17.0 以降の leapp-repository パッケージが必要であることに注意してください。

    注記

    システムにインターネットアクセスがない場合は、Red Hat カスタマーポータル から以下のパッケージをダウンロードします。

    • leapp
    • leapp-deps
    • python2-leapp
    • leapp-upgrade-el7toel8
    • leapp-upgrade-el7toel8-deps
  13. RPM パッケージの変更、RPM リポジトリーマッピング、サポート対象外のドライバーやデバイスなど、必要な追加データファイルの最新バージョンにアクセスできることを確認してください。

    重要

    RHEL 7.6 for IBM POWER 9 (little endian)または IBM Z (structure A)アーキテクチャーを使用している場合は、代わりに インプレースアップグレードの Leapp データスナップショット を参照してください。

    1. アップグレードに RHSM を使用する場合で、システムが cloud.redhat.com にアクセスでき、必要なデータファイルの以前のバージョンをダウンロードしていない場合は、それ以上のアクションは必要ありません。データファイルは cloud.redhat.com から自動的にダウンロードされます。これは、開発者サブスクリプションにも適用されます。
    2. ナレッジベースアーティクル Leapp utility metadata in-place upgrades of RHEL for disconnected upgrades に添付されているデータファイルをダウンロードし、これを /etc/leapp/files/ ディレクトリーに置きます。現在、leapp-data19.tar.gz アーカイブまたはそれ以降のデータファイルが必要になることに注意してください。これは、以下のシナリオでアップグレードを成功させるために必要になります。

      1. RHUI を使用してパブリッククラウドでアップグレードします。Red Hat サブスクリプションまたは Red Hat カスタマーポータルアカウントをお持ちでない場合は、ナレッジベースの記事にアクセスし、必要なデータパッケージをダウンロードできるように、無料の RHEL 開発者サブスクリプションを作成してください。詳細は How do I get a no-cost Red Hat Enterprise Linux Developer Subscription or renew it? を参照してください。
      2. お使いのシステムにインターネットアクセスがありません。
      3. アップグレードに RHSM を使用し、必要なデータファイルの古いバージョンを以前ダウンロードしたが、アップグレードを実行しませんでした (例: 自動化スクリプトの作成など)。古いバージョンのデータファイルを削除して、最新のファイルバージョンを自動的にダウンロードすることもできます。
  14. アップグレードの失敗を防ぐために一時的にウイルス対策ソフトウェアを無効にします。
  15. 設定管理システムがインプレースアップグレードプロセスに干渉しないことを確認します。

  16. システムで、カーネル (eth) が使用する接頭辞に基づいた名前で、複数の Network Interface Card (NIC) が使用されていないことを確認します。RHEL 8 へのインプレースアップグレードの前に別の命名スキームに移行する方法は RHEL 7 でカーネルの NIC 名を使用している場合に RHEL 8 へのインプレースアップグレードを実行する方法 を参照してください。
  17. システム全体のバックアップまたは仮想マシンのスナップショットが存在することを確認してください。これにより、ご利用の環境で、以下の標準の災害復旧手順に従って、システムをアップグレード前と同じ状態に戻せるようになります。たとえば、ReaR (Relax-and-Recover) ユーティリティーを使用できます。詳細は、ReaR のドキュメント および Relax and Recover(ReaR) の概要 を参照してください。または、LVM スナップショット または RAID 分割 を使用することもできます。仮想マシンをアップグレードする場合は、仮想マシン全体のスナップショットを作成できます。

3.2. アップグレードに向けた Satellite システムの準備

この手順では、RHEL 8 へのアップグレード用に Satellite に登録されているシステムを準備するために必要な手順を説明します。

重要

Satellite システムのユーザーは、この手順と Preparing a RHEL 7 system for the upgrade で説明されている準備手順を完了する必要があります。

前提条件

  • Satellite Server の管理者権限がある。

手順

  1. Satellite は、フルサポートまたはメンテナーンスサポートがあるバージョンです。詳細は、Red Hat Satellite の製品ライフサイクル を参照してください。
  2. RHEL 8 リポジトリーを使用したサブスクリプションマニフェストを Satellite Server にインポートします。詳細は、Red Hat Satellite の特定のバージョン (version 6.10 など) の Content Management Guide の Managing Subscriptions を参照してください。
  3. 必要な 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 8 (RPM)

      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 の特定バージョン (version 6.10 など) の Content Management GuideImporting Content の章を参照してください。

  4. 必要な RHEL 7 リポジトリーおよび RHEL 8 リポジトリーを含むコンテンツビューにコンテンツホストを割り当てます。

    詳細は、Red Hat Satellite の特定のバージョン (version 6.10 など) の Content Management GuideManaging Content Views を参照してください。

検証

  • 最新の RHEL 8 リポジトリーが Satellite Server で有効になっていることを確認します。たとえば、ライブラリーライフサイクル環境のリポジトリーを確認するには、以下を実行します。

    hammer repository list --search 'content_label ~ rhel-8' --content-view <content_view_name> --organization <organization> --lifecycle-environment Library

    content_view_name はコンテンツビュー名に置き換え、organization は組織に置き換えます。

第4章 アップグレード前のレポートの確認

システムのアップグレード可能性を評価するには、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 によりアップグレードが行われません。

アップグレード前のフェーズでアップグレード可能性を評価するには、以下のオプションがあります。

  1. 生成された leapp-report.txt ファイルのアップグレード前レポートを確認し、コマンドラインインターフェイスを使用して、報告された問題を手動で解決します。
  2. Web コンソールを使用してレポートを確認し、利用可能な場合は自動修復を適用し、推奨される修復ヒントを使用して残りの問題を修正します。
重要

アップグレード前のフェーズでは、Leapp がインプレースアップグレードプロセス全体をシミュレートしたり、すべての RPM パッケージをダウンロードしません。

アップグレード前のレポートを確認すると、インプレースアップグレードプロセスなしで RHEL 8 システムを再デプロイする必要がある場合にも役立ちます。

注記

たとえば、独自のカスタムスクリプトを使用してアップグレード前のレポートを処理し、異なる環境間にある複数のレポートの結果を比較できます。詳細は Red Hat Enterprise Linux のアップグレード前のレポートワークフローの自動化 を参照してください。

4.1. コマンドラインからのアップグレード可能性の評価

コマンドラインインターフェイスを使用して、アップグレード前のフェーズで潜在的なアップグレードの問題を特定します。

手順

  1. 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 を使用しないアップグレード を行う場合や RHSM を使用する場合は、--no-rhsm オプションを追加します。

    Extended Upgrade Support(EUS)、Advanced Update Support(AUS)、または Update Services for SAP Solutions(E4S) のサブスクリプションがある場合は、--channel channel オプションを追加します。channel を、eusaus、または e4s などのチャネルに置き換えます。SAP HANA のお客様は、ナレッジベースの記事 How to in-place upgrade SAP environments from RHEL 7 to RHEL 8 を使用してインプレースアップグレードを実行する必要があります。

  2. 以下の方法のいずれかを使用して、Leapp が必要とする各質問に回答を提供します。

    1. leapp answer コマンドを実行して、応答している質問と、確認した質問を指定します。

      # leapp answer --section question_section.confirm=answer

      たとえば、PAM 設定で pam_pkcs11 モジュールを無効にするか ?という質問に True を確定するには、以下のコマンドを実行します。

      # leapp answer --section remove_pam_pkcs11_module_check.confirm=True
    2. /var/log/leapp/answerfile ファイルを手動で編集し、# 記号を削除してファイルの confirm 行のコメントを解除し、True または False として回答を確定します。トラブルシューティングのヒント セクションの Leapp answerfile を参照してください。
  3. /var/log/leapp/leapp-report.txt ファイルのレポートを調べて、インプレースアップグレードに進む前に、報告されたすべての問題を手動で解決します。

4.2. Web コンソールを介したアップグレードの可能性の評価および自動修復の適用

アップグレード前のフェーズで潜在的な問題と、Web コンソールを使用して自動修復を適用する方法を特定します。

手順

  1. cockpit-leapp プラグインをインストールします。

    # yum install cockpit-leapp
  2. ブラウザーで Web コンソールに移動し、root または /etc/sudoers ファイルで設定したユーザーとしてログインします。Web コンソールの詳細は、RHEL 7 Web コンソールを使用したシステムの管理 を参照してください。
  3. 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 を使用しないアップグレード を行う場合や RHSM を使用する場合は、--no-rhsm オプションを追加します。

    Extended Upgrade Support(EUS)、Advanced Update Support(AUS)、または Update Services for SAP Solutions(E4S) のサブスクリプションがある場合は、--channel channel オプションを追加します。channel を、eusaus、または e4s などのチャネルに置き換えます。SAP HANA のお客様は、ナレッジベースの記事 How to in-place upgrade SAP environments from RHEL 7 to RHEL 8 を使用してインプレースアップグレードを実行する必要があります。

  4. Web コンソールで、左側のメニューから インプレースアップグレードレポート を選択します。

    図4.1 Web コンソールのインプレースアップグレードレポート

    Web コンソールのインプレースアップグレードレポート

    レポートの表には、見つかった問題の概要、リスク評価、および修復 (利用可能な場合) が記載されています。

    • リスク要因:

      • 高 - システム状態が悪化する可能性が非常に高い
      • 中 - システムとアプリケーションの両方に影響を与える可能性がある
      • 低 - システムに影響はないが、アプリケーションに影響を与える可能性がある
      • 情報 - システムまたはアプリケーションへの影響がないと考えられる情報
    • インヒビター - アップグレードプロセスを抑制 (ハードストップ) する。抑制しないと、システムが起動できず、アクセスできず、または機能しなくなる可能性があります。
    • 修復 - 報告された問題に対する実行可能な解決策

      • 修復コマンド - Web コンソールから直接実行可能
      • 修復のヒント - 問題を手動で解決する方法の手順
  5. レポートの内容を調べます。ヘッダーをクリックして、テーブルを並べ替えることができます。詳細ペインを開くには、選択した行をクリックします。

    図4.2 詳細ペイン

    詳細ペイン

    詳細ペインには、次の追加情報が表示されます。

    • 問題の概要と、問題を詳細に説明するナレッジベース記事へのリンク
    • 修復 - 自動修復 (利用可能な場合) を実行またはスケジュールし、適用時にその結果を確認できます。
    • 影響を受けるシステムリソース: パッケージ、リポジトリー、ファイル (設定、データ)、ディスク、ボリューム
  6. 必要に応じて、結果をフィルターリングします。レポートの左上隅にある フィルター ボタンをクリックし、設定に基づいてフィルターを適用します。フィルターカテゴリーは、相互に関連して適用されます。

    図4.3 フィルター

    フィルター
  7. 自動修復を適用する問題を選択します。2 つのオプションがあります。

    1. 詳細ペインの Add to Remediation Plan ボタンをクリックして、個々の項目を選択します。また、詳細ペインで Run Remediation をクリックして、個々の修復を直接実行できます。
    2. レポートの右上隅にある Add all remediations to plan ボタンをクリックして、修復が利用可能なすべての項目を選択します。
  8. Web コンソールで Leapp で必要な質問を確認し、回答します。未回答の質問はそれぞれ、Upgrade Report で Missing required answers in the answer file として表示されます。質問に答えるタイトルを選択します。

    1. デフォルトの True の応答を確認するには、Add to Remediation Plan を選択して修復を後で実行するか、または Run Remediation を選択して修復を即座に実行します。
    2. デフォルト以外の回答を選択するには、以下のいずれかを実行します。

      1. leapp answer コマンドを実行して、応答している質問と、確認した質問を指定します。

        # leapp answer --section question_section.confirm=answer

        たとえば、PAM 設定で pam_pkcs11 モジュールを無効にするか ?という質問に False を確定するには、以下のコマンドを実行します。

        # leapp answer --section remove_pam_pkcs11_module_check.confirm=False
      2. /var/log/leapp/answerfile ファイルを手動で編集し、# 記号を削除してファイルの confirm 行のコメントを解除し、True または False として回答を確定します。トラブルシューティングのヒントセクションの Leapp answerfile の例 を参照してください。

        図4.4 未回答の Leapp 質問がない

        未回答の Leapp の質問
  9. レポートの右上隅にある Remediation plan リンクをクリックして、修復計画を開きます。修復計画には、実行した修復、または予定されている修復の一覧が示されます。

    図4.5 修復計画

    修復計画
  10. Execute Remediation Plan をクリックして、予定されている修復をすべて処理します。修復エントリーごとに次の情報が表示されます。

    • 修復の一意の ID
    • コマンドの終了ステータス
    • 実行された修復の経過時間
    • 標準出力
    • 標準エラー
  11. 選択した修復を実行した後に、leapp preupgrade コマンドを使用してアップグレード前のレポートを再生成し、新しいレポートを調べてから、必要に応じて追加の修復手順を実行します。

第5章 RHEL 7 から RHEL 8 へのアップグレードの実行

Leapp ユーティリティーを使用して RHEL 8 にアップグレードします。

前提条件

手順

  1. 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 を使用しないアップグレード を行う場合や RHSM を使用する場合は、--no-rhsm オプションを追加します。

    Extended Upgrade Support(EUS)、Advanced Update Support(AUS)、または Update Services for SAP Solutions(E4S) のサブスクリプションがある場合は、--channel channel オプションを追加します。channel を、eusaus、または e4s などの leapp preupgrade コマンドで使用した値に置き換えます。leapp preupgrade および leapp upgrade コマンドの両方で、--channel オプションで同じ値を使用する必要があります。

    アップグレードプロセスの開始時に、Leapp は、アップグレード前の レポートの確認 で説明されているアップグレード前の フェーズを実行します。

    システムをアップグレードできる場合は、Leapp が必要なデータをダウンロードし、アップグレード用の RPM トランザクションを作成します。

    システムで、信頼できるアップグレードの設定要因が満たされていない場合は、Leapp がアップグレードプロセスを中止し、問題を説明する記録と、推奨される解決策を /var/log/leapp/leapp-report.txt ファイルに出力します。詳細は、トラブルシューティング を参照してください。

  2. システムを手動で再起動します。

    # reboot

    このフェーズでは、システムが RHEL 8 ベースの初期 RAM ディスクイメージ initramfs で起動します。Leapp は、すべてのパッケージをアップグレードして、自動的に RHEL 8 システムを再起動します。

    または、--reboot オプションを指定して leapp upgrade コマンドを実行し、この手動の手順を省略することもできます。

    失敗した場合は、トラブルシューティング の 説明に従ってログを調べてください。

  3. RHEL 8 システムにログインし、RHEL 8 システムの アップグレード後の状態の確認 で説明されているように状態を 確認します。
  4. アップグレード後のタスク の実行 で説明されているように、アップグレード後のタスク を完了します。特に、セキュリティーポリシーを再評価して再適用します。

第6章 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 へのインプレースアップグレード後に実行が推奨される主要タスクを紹介します。

手順

アップグレードが完了したら、以下のタスクを実行します。

  1. snactor パッケージを含む、/etc/dnf/dnf.conf 設定ファイルの exclude 一覧から残りの Leapp パッケージを削除します。インプレースアップグレード中に、Leapp ユーティリティーでインストールされた Leapp パッケージが exclude リストに自動的に追加され、重要なファイルが削除または更新されないようにします。インプレースアップグレード後、システムから削除する前に、これらの Leapp パッケージを exclude 一覧から削除する必要があります。

    • exclude 一覧からパッケージを手動で削除するには、/etc/dnf/dnf.conf 設定ファイルを編集し、除外 一覧から必要な Leapp パッケージを削除します。
    • 除外 一覧からすべてのパッケージを削除するには、次のコマンドを実行します。

      # dnf config-manager --save --setopt exclude=''
  2. 残りの Leapp パッケージを含む残りの RHEL 7 パッケージを削除します。

    1. 以前のカーネルバージョンを確認します。

      # cd /lib/modules && ls -d *.el7*
    2. 以前のカーネルから弱いモジュールを削除します。以前のカーネルが複数ある場合は、カーネルごとにこの手順を繰り返します。

      # [ -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
    3. ブートローダーエントリーから古いカーネルを削除します。以前のカーネルが複数ある場合は、カーネルごとにこの手順を繰り返します。

      # /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
    4. 残りの RHEL 7 パッケージを見つけます。

      # rpm -qa | grep -e '\.el[67]' | grep -vE '^(gpg-pubkey|libmodulemd|katello-ca-consumer)' | sort
    5. RHEL 8 システムから、古いカーネルパッケージなど、残りの RHEL 7 パッケージと kernel-workaround パッケージを削除します。
    6. 残りの Leapp 依存関係パッケージを削除します。

      # dnf remove leapp-deps-el8 leapp-repository-deps-el8
    7. 残りの空のディレクトリーを削除します。

      # rm -r /lib/modules/*el7*
  3. インプレースアップグレード後も、システムがサポートされていることを確認してください。RHEL 8.7 の一般提供により、システムが RHEL 8.7 または RHEL 8.6 Extended Update Support (EUS)のいずれかに更新されていることを確認します。

    1. システムを RHEL 8.7 に更新します。

      1. 最新の RHEL 8.7 コンテンツを利用するように Red Hat Subscription Manager の設定を解除します。

        # subscription-manager release --unset
      2. システムを最新の RHEL 8.7 バージョンに更新します。

        # yum update
    2. システムが RHEL 8.6 EUS に更新されていることを確認します。

      インプレースアップグレード中に --channel オプションを使用して EUS チャンネルを設定している場合は、追加の手順を行う必要はありません。それ以外の場合は、システムを RHEL 8.6 EUS に更新します。

      1. RHEL 8 EUS リポジトリーを有効にします。

        # subscription-manager repos --enable repository_id1 --enable repository_id2 …

        repository_id* を、サブスクリプションで利用可能な EUS リポジトリーの ID に置き換えます。

        BaseOS リポジトリーおよび AppStream リポジトリーを少なくとも有効にします。たとえば、Intel 64 アーキテクチャーでは以下を行います。

        # subscription-manager repos --enable  rhel-8-for-x86_64-baseos-eus-rpms --enable rhel-8-for-x86_64-appstream-eus-rpms
      2. システムを最新の RHEL 8.6 EUS バージョンに更新します。

        # yum update
  4. セキュリティーポリシーを再評価して再適用します。具体的には、SELinux モードを Enforcing に変更します。詳細は、セキュリティーポリシーの適用 を 参照してください。

検証手順

  • 古いカーネルがブートローダーエントリーから削除されていることを確認します。

    # grubby --info=ALL | grep "\.el7" || echo “Old kernels are not present in the bootloader.”

第8章 セキュリティーポリシーの適用

インプレースアップグレードプロセスでは、特定のセキュリティーポリシーを無効にしたままにする必要があります。さらに、RHEL 8 ではシステム全体の暗号化ポリシーという概念が新たに導入され、セキュリティープロファイルにはメジャーリリース間の変更が含まれる可能性があります。本セクションでは、アップグレードした RHEL システムのセキュリティーを保護する方法を説明します。

8.1. SELinux モードの Enforcing への変更

Leapp ユーティリティーは、インプレースアップグレードプロセス時に SELinux モードを Permissive に設定します。システムが正常にアップグレードされたら、手動で SELinux モードを Enforcing に変更する必要があります。

前提条件

手順

  1. ausearch ユーティリティーなどを使用して、SELinux 拒否がないことを確認します。

    # ausearch -m AVC,USER_AVC -ts boot

    前述の手順では、最も一般的なシナリオのみが扱われることに注意してください。可能な SELinux 拒否をすべて確認するには、完全な手順を説明する SELinux の使用の SELinux 拒否の特定 セクションを参照してください。

  2. 任意のテキストエディターで /etc/selinux/config ファイルを開きます。以下に例を示します。

    # vi /etc/selinux/config
  3. 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
  4. 変更を保存して、システムを再起動します。

    # reboot

検証

  1. システムの再起動後に、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

システム全体の暗号化ポリシーをカスタマイズすることもできます。詳細は、ポリシー修飾子を使用したシステム全体の暗号化ポリシーのカスタマイズ および システム全体のカスタム暗号化ポリシーの作成および設定 を参照してください。

関連情報

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 パッケージがインストールされている。

手順

  1. 適切なセキュリティーコンプライアンスデータストリームの .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
    ...

    詳細は、コンプライアンスプロファイルの表示 を参照してください。

  2. 適切なデータストリームから選択したプロファイルに従って、システムを修正します。

    # 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 システムで対応しています。インストール後にシステムが変更した場合は、修復を実行しても、必要なセキュリティープロファイルに準拠しない場合があります。

  3. システムを再起動します。

    # reboot

検証

  1. システムがプロファイルに準拠していることを確認し、結果を HTML ファイルに保存します。

    $ oscap xccdf eval --report pcidss_report.html --profile pci-dss /usr/share/xml/scap/ssg/content/ssg-rhel8-ds.xml

第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 ユーティリティーでは、すべてのログが出力されます。

レポート

9.2. トラブルシューティングのヒント

以下のトラブルシューティングのヒントを参照してください。

アップグレード前のフェーズ

例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 モードに切り替えてから、アプリケーションやサービスが停止したり、適切に動作しなかったりした場合は、ausearchjournalctldmesg のいずれかのユーティリティーで、サービスの拒否を検索します。

    # 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 はそのようなドライバーを検出せず、アップグレードを続行します。したがって、アップグレード後にシステムが起動しない場合があります。
  • この時点では、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

    この問題を回避するには、更新時に、データベース usergroups、および hosts にのみローカルプロバイダーを使用できるようにシステムを設定します。

    1. システムの設定ファイル /etc/nsswitch.conf を開き、winbind 文字列または wins 文字列を含むエントリーを検索します。
    2. そのようなエントリーを確認するには、/etc/nsswitch.conf のバックアップを作成します。
    3. /etc/nsswitch.conf を編集し、winbind または wins を含むエントリーからそれらを削除します。
    4. インプレースアップグレードを実行します。
    5. アップグレードを行ったら、システムの設定要件に従って、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 を使用しないようにします。

  • お使いのシステムに (Red Hat が署名していない) サードパーティーパッケージの名前が、Red Hat が提供するパッケージの名前と同じ場合は、インプレースアップグレードに失敗します。この問題を回避するには、アップグレードする前に、以下のいずれかのオプションを選択します。

    1. サードパーティーパッケージの削除
    2. サードパーティーパッケージを、Red Hat が提供するパッケージに置き換えます。
  • セキュリティー上の理由から、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-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 を作成できません。この問題を回避するには、アップグレード後のタスクの実行 で説明されているように、ブートローダーエントリーからパッケージと古いカーネルを手動で削除します。(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_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)

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)
  • アップグレード前のプロセスで、アップグレードを進める前に、ユーザーが true/false の質問に回答しないといけない場合があります。アップグレード前のレポートが最新バージョンの Leapp リリースよりも前に実行された場合、レポートは、すべての true/false の質問は応答済みで、アップグレードを安全に続行できるという誤った報告をしている可能性があります。2021 年 11 月 9 日より前にアップグレード前のレポートを実行する場合には、以下の手順を実行して、アップグレードに関する深刻な問題を防ぎます。

    1. すべての Leapp 関連のパッケージを更新します。
    2. /var/log/leapp/answerfile ファイルおよび /var/log/leapp/answerfile.userchoices ファイルを削除します。

      # rm -f /var/log/leapp/answerfile /var/log/leapp/answerfile.userchoices
    3. leapp preupgrade コマンドを実行して、true/false の質問に回答します。

      (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 のロールと取得方法 を参照してください。

カスタマーポータルでサポートケースを作成し、管理する方法は、ナレッジベースのアーティクル カスタマーポータルでサポートケースを作成および管理する を参照してください。

付録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

rhel-7-server-rpms

Extras

rhel-7-server-extras-rpms

IBM POWER8 (リトルエンディアン)

Base

rhel-7-for-power-le-rpms

Extras

rhel-7-for-power-le-extras-rpms

IBM POWER9 (リトルエンディアン)

Base

rhel-7-for-power-9-rpms

Extras

rhel-7-for-power-9-extras-rpms

IBM Z

Base

rhel-7-for-system-z-rpms

Extras

rhel-7-for-system-z-extras-rpms

IBM Z (Structure A)

Base

rhel-7-for-system-z-a-rpms

Extras

rhel-7-for-system-z-a-extras-rpms

次のリポジトリーは、アップグレード前に subscription-manager repos --enable repository_id コマンドを使用して 有効にできます

アーキテクチャーリポジトリーリポジトリー ID

64 ビット Intel

任意

rhel-7-server-optional-rpms

Supplementary

rhel-7-server-supplementary-rpms

IBM POWER8 (リトルエンディアン)

任意

rhel-7-for-power-le-optional-rpms

Supplementary

rhel-7-for-power-le-supplementary-rpms

IBM POWER9 (リトルエンディアン)

任意

rhel-7-for-power-9-optional-rpms

Supplementary

rhel-7-for-power-9-supplementary-rpms

IBM Z

任意

rhel-7-for-system-z-optional-rpms

Supplementary

rhel-7-for-system-z-supplementary-rpms

IBM Z (Structure A)

任意

rhel-7-for-system-z-a-optional-rpms

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

rhel-8-for-x86_64-baseos-rpms

Red Hat Enterprise Linux 8 for x86_64 - BaseOS (RPMs)

x86_64 <target_os_version>

Appstream

rhel-8-for-x86_64-appstream-rpms

Red Hat Enterprise Linux 8 for x86_64 - AppStream (RPMs)

x86_64 <target_os_version>

IBM Power8(リトルエンディアン)/IBM Power9(リトルエンディアン)

BaseOS

rhel-8-for-ppc64le-baseos-rpms

Red Hat Enterprise Linux 8 for Power, little endian - BaseOS (RPMs)

ppc64le <target_os_version>

Appstream

rhel-8-for-ppc64le-appstream-rpms

Red Hat Enterprise Linux 8 for Power, little endian - AppStream (RPMs)

ppc64le <target_os_version>

IBM Z/IBM Z (Structure A)

BaseOS

rhel-8-for-s390x-baseos-rpms

Red Hat Enterprise Linux 8 for IBM z Systems - BaseOS (RPMs)

s390x <target_os_version>

Appstream

rhel-8-for-s390x-appstream-rpms

Red Hat Enterprise Linux 8 for IBM z Systems - AppStream (RPMs)

s390x <target_os_version>