Elastic Compute Service:Red Hat Enterprise Linux

アップグレードの前に、アップグレードが失敗した場合のデータ損失を防ぐために、スナップショットを作成してデータをバックアップします。詳細については、「スナップショットの作成」をご参照ください。

root ユーザーを使用して、RHEL システムを実行している ECS インスタンスにリモート接続します。

詳細については、「Workbench を使用した Linux インスタンスへの接続」をご参照ください。

次のコマンドを実行して、ご利用の RHEL インスタンスが Alibaba Cloud RHEL サブスクリプションを使用しているかどうかを確認します。

rpm -q client-rhel7

• 応答が返されない場合、ご利用のシステムは Alibaba Cloud RHEL サブスクリプションを使用していません。まずサブスクリプションを購入してから、アップグレードを実行してください。

• client-rhel7-3.0-1.el7_9.noarch のような応答が返された場合、ご利用のシステムは Alibaba Cloud RHEL サブスクリプションを使用しています。アップグレードを続行できます。

  

アップグレード環境を準備します。

1. 次のコマンドを実行して RHEL システムを最新バージョンにアップグレードし、システムを再起動して変更を有効にします。最新バージョンには通常、既知の脆弱性、エラー、セキュリティ問題の修正が含まれています。

   yum -y update
   reboot

2. 次のコマンドを実行して、RHEL システムに Leapp アップグレードツールをインストールします。

   yum -y install leapp leapp-rhui-alibaba --enablerepo="*"

3. 次のコマンドを実行して、Leapp がインストールされているかどうかを確認します。

   leapp --version

   leapp version xxx のような応答が返された場合、Leapp はインストールされています。

アップグレード前チェックを実行します。

システム構成は大きく異なる可能性があるため、アップグレードの前に Leapp ツールを使用してシステムのアップグレード前チェックを実行します。Leapp ツールからのチェック結果を表示し、ツールの提案に基づいて報告された問題を解決して、アップグレード要件を満たすことができます。

1. 次のコマンドを実行して、アップグレード前チェックを実行します。

   • RHEL 8 の最新バージョンへのアップグレード前チェック。

     leapp preupgrade  --no-rhsm

   • 特定のターゲットバージョンへのアップグレード前チェック。例えば、RHEL 7 を RHEL 8.8 にアップグレードする場合。

     leapp preupgrade --no-rhsm --target 8.8

     説明

     leapp preupgrade -h コマンドを実行して、現在のシステムがアップグレードをサポートするターゲットバージョンを表示できます。

2. アップグレード前チェックの結果を表示します。

   Leapp ツールからのアップグレード前チェックログは、次のログファイルに保存されます：

   • /var/log/leapp/leapp-preupgrade.log：Leapp ツールのログ

   • /var/log/leapp/leapp-report.txt：テキスト形式のアップグレード前チェックレポート

   • /var/log/leapp/leapp-report.json：JSON 形式のアップグレード前チェックレポート

   アップグレード前チェックが失敗した場合、次の図に示すように、失敗したチェック項目が表示されます。

   

3. (条件付き) アップグレード前エラーを処理します。

   ログファイル /var/log/leapp/leapp-report.txt でアップグレード前エラーメッセージを確認し、Leapp ツールの提案に基づいてエラーを解決します。次のセクションでは、リスクレベル別に一般的なアップグレード前チェックエラーとその解決策をリストします。

   • 高 (阻害要因)：高リスク (アップグレードを阻害)。この種の問題はアップグレードプロセスを直接ブロックするため、続行する前に解決する必要があります。

     • ケース 1：システムに複数のカーネルバージョンがインストールされている。

       Risk Factor: high (inhibitor)
       Title: Multiple devel kernels installed
       Summary: DNF cannot produce a valid upgrade transaction when multiple kernel-devel packages are installed.
       Remediation: [hint] Remove all but one kernel-devel packages before running Leapp again.
       [command] yum -y remove kernel-devel-3.10.0-1160.11.1.el7

       解決策：古いカーネルパッケージをアンインストールします。Leapp ツールが提案するコマンドを実行して古いカーネルをアンインストールします。この場合は、例えば yum -y remove kernel-devel-3.10.0-1160.11.1.el7 です。

     • ケース 2：RHEL 8 でサポートされていないカーネルモジュールがシステムにロードされている。

       Risk Factor: high (inhibitor)                                                                                                                                                                                         
       Title: Leapp detected loaded kernel drivers which have been removed in RHEL 8. Upgrade cannot proceed.                                                                                                                
       Summary: Support for the following RHEL 7 device drivers has been removed in RHEL 8:                                                                                                                                  
            - floppy

       解決策：この例の floppy モジュールなど、一部のモジュールは RHEL 8 でサポートされていません。次のコマンドを実行してアンインストールします。

       rmmod floppy

     • ケース 3：非標準の sshd_config 構成

       Risk Factor: high (inhibitor)
       Title: Possible problems with remote login using root account
       Summary: OpenSSH configuration file does not explicitly state the option PermitRootLogin in sshd_config file, which will default in RHEL8 to "prohibit-password".
       Remediation: [hint] If you depend on remote root logins using passwords, consider setting up a different user for remote administration or adding "PermitRootLogin yes" to sshd_config. 
       If this change is ok for you, add explicit "PermitRootLogin prohibit-password" to your sshd_config to ignore this inhibitor

       解決策：

       1. /etc/ssh/sshd_config 構成ファイルで、PermitRootLogin のデフォルト値を yes に設定します。

          説明

          PermitRootLogin のデフォルト値は RHEL 7 と RHEL 8 で異なります：

          • RHEL 7：デフォルト値は yes で、root ユーザーがパスワードまたはキーを使用してログインできることを示します。

          • RHEL 8：デフォルト値は prohibit-password で、パスワードベースのログインが禁止されていることを示します。

       2. 次のコマンドを実行して sshd サービスを再起動します。

          systemctl restart sshd

     • ケース 4：確認ファイルが編集・確認されていない。

       Risk Factor: high (inhibitor)
       Title: Missing required answers in the answer file
       Summary: One or more sections in answerfile are missing user choices: remove_pam_pkcs11_module_check.confirm
       For more information consult https://leapp.readthedocs.io/en/latest/dialogs.html
       Remediation: [hint] Please register user choices with leapp answer cli command or by manually editing the answerfile.
       [command] leapp answer --section remove_pam_pkcs11_module_check.confirm=True

       解決策：この場合、RHEL 8 でサポートされていない pam モジュールを削除する必要があります。この操作は /var/log/leapp/answerfile ファイルでの確認が必要です。次のコマンドを実行して confirm を True に設定します。

       leapp answer --section remove_pam_pkcs11_module_check.confirm=True

       

   • 高：高リスク。この種の問題はアップグレードを直接ブロックしませんが、アップグレード後の問題を避けるために、アップグレード前または後に解決する必要があります。

     • ケース 1：一部のパッケージがインストールできない。

       Risk Factor: high
       Title: Packages from unknown repositories may not be installed
       Summary: 3 packages may not be installed or upgraded due to repositories unknown to leapp:
       - python3-pyxattr (repoid: rhel8-CRB)
       - rpcgen (repoid: rhel8-CRB)
       - ustr (repoid: rhel8-CRB)
       Remediation: [hint] In case the listed repositories are mirrors of official repositories for RHEL (provided by Red Hat on CDN) and their repositories IDs has been customized, you can change the configuration to use the official IDs instead of fixing the problem. You can also review the projected DNF upgrade transaction result in the logs to see what is going to happen, as this does not necessarily mean that the listed packages will not be upgraded. You can also install any missing packages after the in-place upgrade manually.

       解決策：アップグレード後に不足しているパッケージを手動でインストールします。

     • ケース 2：一部の RHEL 7 パッケージがアップグレードされない。

       Risk Factor: high
       Title: Some RHEL 7 packages have not been upgraded
       Summary: Following RHEL 7 packages have not been upgraded:
       leapp-upgrade-el7toel8-0.18.0-1.el7_9
       kernel-3.10.0-1160.92.1.el7
       leapp-rhui-alibaba-1.0.0-1.el7_9
       Please remove these packages to keep your system in supported state.

       解決策：yum remove leapp-upgrade-el7toel8-0.18.0-1.el7_9 kernel-3.10.0-1160.92.1.el7 leapp-rhui-alibaba-1.0.0-1.el7_9 コマンドを実行してこれらのパッケージを削除します。

   • 中：中リスク。この種の問題はアップグレードを直接ブロックしませんが、アップグレード後の潜在的な問題を避けるために、アップグレード前または後に解決する必要があります。

     ケース：PAM 構成の pam_pkcs11 モジュールが削除される。

     Title: Module pam_pkcs11 will be removed from PAM configuration
     Summary: Module pam_pkcs11 was surpassed by SSSD and therefore it was removed from RHEL-8. Keeping it in PAM configuration may lock out the system thus it will be automatically removed from PAM configuration before upgrading to RHEL-8. Please switch to SSSD to recover the functionality of pam_pkcs11.
     Remediation: [hint] Configure SSSD to replace pam_pkcs11

     解決策：アップグレード後にシステムの認証機能が正しく機能するように、SSSD を構成して pam_pkcs11 の機能を置き換えます。

   • 低：低リスク。この種の問題はアップグレードプロセスやシステム操作に軽微な影響を与えますが、安定したシステム操作を確保するために、アップグレード前または後に解決する必要があります。

     ケース：SELinux が permissive モードに設定される。

     Risk Factor: low 
     Title: SElinux will be set to permissive mode
     Summary: SElinux will be set to permissive mode. Current mode: enforcing. This action is required by the upgrade process to make sure the upgraded system can boot without beinig blocked by SElinux rules.
     Remediation: [hint] Make sure there are no SElinux related warnings after the upgrade and enable SElinux manually afterwards. Notice: You can ignore the "/root/tmp_leapp_py3" SElinux warnings.

     解決策：アップグレード後、SELinux 関連の警告がないことを確認し、その後 SELinux を enforcing モードにリセットして、システムのセキュリティとコンプライアンスを確保します。

   • 情報：情報。この種の問題は通常、情報メッセージであり、アップグレードプロセスやシステム操作には影響しません。レポートで特定のメッセージを表示して、アップグレードプロセス中に発生する変更を理解できます。

     ケース：/etc/dnf/vars/releasever のリリースバージョンが現在のターゲットバージョンに設定される。

     Risk Factor: info 
     Title: Release version in /etc/dnf/vars/releasever will be set to the current target release
     Summary: On this system, Leapp detected "releasever" variable is either configured through DNF/YUM configuration file and/or the system is using RHUI infrastructure. To avoid issues with repofile URLs (when --release option is not provided) in cases where there is the previous major.minor version value in the configuration, release version will be set to the target release version (8.8). This will also ensure the system stays on the expected target version after the upgrade

     解決策：操作は不要です。

次のコマンドを実行してアップグレードを実行します。

• RHEL 8 の最新バージョンにアップグレードします。

  leapp upgrade  --no-rhsm

• 特定のターゲットバージョンにアップグレードします。例えば、RHEL 7 を RHEL 8.8 にアップグレードする場合。

  leapp upgrade  --no-rhsm --target 8.8

次の図は、アップグレードが成功したことを示しています。

次のコマンドを実行してインスタンスを再起動し、新しいシステムで起動します。

reboot

アップグレード結果を検証します。

• cat /etc/redhat-release コマンドを実行して、システムバージョンが更新されているかどうかを確認します。

• アップグレード実行ログまたはレポートでエラーがないか確認します。

• アプリケーションが RHEL 8 システムで正しく実行されるかどうかを観察します。

(条件付き) 次のコマンドを実行して RHEL ソースを構成します。

Leapp アップグレードツールを使用してアップグレードを完了すると、/etc/dnf/vars/releasever ファイルがデフォルトで変更され、システムが RHEL の特定のマイナーバージョンにロックされます。例えば、RHEL 8.8 の場合、リポジトリソースは https://xxxx/8.8/xxx を指すため、RHEL 8.8 バージョンのパッケージにしかアクセスできません。最新の RHEL 8 バージョンのパッケージに自動的にアクセスして最新のセキュリティパッチと機能更新を取得したい場合は、releasever 構成ファイルを削除してメタデータキャッシュを再構築できます。

rm -f /etc/dnf/vars/releasever
dnf clean all && dnf makecache

コマンドを実行すると、RHEL 8 のリポジトリソースが https://xxxx/8/xxx に更新されます。これにより、システムは RHEL 8 の最新のセキュリティパッチと機能更新を自動的に取得でき、システムが最新の状態に保たれます。

アップグレードの前に、アップグレードが失敗した場合のデータ損失を防ぐために、スナップショットを作成してデータをバックアップします。詳細については、「スナップショットの作成」をご参照ください。

root ユーザーを使用して、RHEL システムを実行している ECS インスタンスにリモート接続します。

詳細については、「Workbench を使用した Linux インスタンスへの接続」をご参照ください。

次のコマンドを実行して、ご利用の RHEL インスタンスが Alibaba Cloud RHEL サブスクリプションを使用しているかどうかを確認します。

rpm -qa |grep aliyun

• 応答が返されない場合、ご利用のシステムは Alibaba Cloud RHEL サブスクリプションを使用していません。まずサブスクリプションを購入してから、アップグレードを実行してください。

• rhel8.6 のようなマイナーバージョンを含む応答を受け取った場合は、まずチケットを送信して最新の RPM パッケージを取得してインストールし、その後アップグレードを実行してください。

  

  説明

  Alibaba Cloud で RHEL を実行すると、システムは Alibaba Cloud の Red Hat Update Infrastructure (RHUI) サービスを介して Red Hat ソフトウェアリポジトリにアクセスします。aliyun_rhel8.6-2.0-1.noarch のような特定のマイナーバージョンのパッケージがインストールされている場合、システムが RHUI に接続できないことがあります。この障害により、ソフトウェア更新プログラムの取得や新しいバージョンへのアップグレードができなくなります。

• aliyun_rhui_rhel8-2.0-3.x86_64 のようなサブスクリプションパッケージの応答が返された場合、ご利用のシステムは Alibaba Cloud RHEL サブスクリプションを使用しています。アップグレードを続行できます。

  

アップグレード環境を準備します。

1. 次のコマンドを実行して RHEL システムを最新バージョンにアップグレードし、システムを再起動して変更を有効にします。最新バージョンには通常、既知の脆弱性、エラー、セキュリティ問題の修正が含まれています。

   yum -y update
   reboot

2. 次のコマンドを実行して、RHEL システムに Leapp アップグレードツールをインストールします。

   yum -y install leapp leapp-rhui-alibaba --enablerepo="*"

3. 次のコマンドを実行して、Leapp がインストールされているかどうかを確認します。

   leapp --version

   leapp version xxx のような応答が返された場合、Leapp はインストールされています。

アップグレード前チェックを実行します。

システム構成は大きく異なる可能性があるため、アップグレードの前に Leapp ツールを使用してシステムのアップグレード前チェックを実行します。Leapp ツールからのチェック結果を表示し、ツールの提案に基づいて報告された問題を解決して、アップグレード要件を満たすことができます。

1. 次のコマンドを実行して、アップグレード前チェックを実行します。

   • systemctl stop systemd-resolved
     systemctl disable  systemd-resolved

   • RHEL 9 の最新バージョンへの事前アップグレード。

     leapp preupgrade  --no-rhsm

   • 特定のターゲットバージョンへのアップグレード前チェック。例えば、RHEL 8 を RHEL 9.4 にアップグレードする場合。

     leapp preupgrade --no-rhsm --target 9.4

     説明

     leapp preupgrade -h コマンドを実行して、現在のシステムがアップグレードをサポートするターゲットバージョンを表示できます。

2. アップグレード前チェックの結果を表示します。

   Leapp ツールからのアップグレード前チェックログは、次のログファイルに保存されます：

   • /var/log/leapp/leapp-preupgrade.log：Leapp ツールのログ

   • /var/log/leapp/leapp-report.txt：テキスト形式のアップグレード前チェックレポート

   • /var/log/leapp/leapp-report.json：JSON 形式のアップグレード前チェックレポート

   アップグレード前チェックが失敗した場合、次の図に示すように、失敗したチェック項目が表示されます。

   

3. (条件付き) アップグレード前エラーを処理します。

   ログファイル /var/log/leapp/leapp-report.txt でアップグレード前エラーメッセージを確認し、Leapp ツールの提案に基づいてエラーを解決します。次のセクションでは、リスクレベル別に一般的なアップグレード前チェックエラーとその解決策をリストします。

   • 高：高リスク。この種の問題はアップグレードを直接ブロックしませんが、アップグレード後の問題を避けるために、アップグレード前または後に解決する必要があります。

     • ケース 1：カスタムの Leapp アクターまたはファイルが検出された。

       Risk Factor: high 
       Title: Detected custom leapp actors or files.
       Summary: We have detected installed custom actors or files on the system. These can be provided e.g. by third party vendors, Red Hat consultants, or can be created by users to customize the upgrade (e.g. to migrate custom applications). This is allowed and appreciated. However Red Hat is not responsible for any issues caused by these custom leapp actors. Note that upgrade tooling is under agile development which could require more frequent update of custom actors.
       The list of custom leapp actors and files:
           - /usr/share/leapp-repository/repositories/system_upgrade/common/files/rhui/alibaba/content.crt
           - /usr/share/leapp-repository/repositories/system_upgrade/common/files/rhui/alibaba/key.pem
           - /usr/share/leapp-repository/repositories/system_upgrade/common/files/rhui/alibaba/leapp-alibaba.repo
       Related links:
           - Customizing your Red Hat Enterprise Linux in-place upgrade: https://red.ht/customize-rhel-upgrade
       Remediation: [hint] In case of any issues connected to custom or third party actors, contact vendor of such actors. Also we suggest to ensure the installed custom leapp actors are up to date, compatible with the installed packages.

       解決策：カスタムアクターが最新であり、Leapp ツールおよびシステム環境と互換性があることを確認してください。アップグレード後、システムが正しく実行されることを確認し、カスタムアクターによって引き起こされた問題を迅速に解決してください。カスタムアクターの管理方法の詳細については、「Customizing your Red Hat Enterprise Linux in-place upgrade」をご参照ください。

     • ケース 2：GRUB2 構成はアップグレード中に自動的に更新される。

       Risk Factor: high 
       Title: GRUB2 core will be automatically updated during the upgrade
       Summary: On legacy (BIOS) systems, GRUB2 core (located in the gap between the MBR and the first partition) cannot be updated during the rpm transaction and Leapp has to initiate the update running "grub2-install" after the transaction. No action is needed before the upgrade. After the upgrade, it is recommended to check the GRUB configuration.

       解決策：アップグレード後、GRand Unified Bootloader (GRUB) 構成をチェックして、システムが正しく起動することを確認してください。

   • 低：低リスク。この種の問題はアップグレードプロセスやシステム操作に軽微な影響を与えますが、安定したシステム操作を確保するために、アップグレード前または後に解決する必要があります。

     ケース：SELinux が permissive モードに設定される。

     Risk Factor: low 
     Title: SElinux will be set to permissive mode
     Summary: SElinux will be set to permissive mode. Current mode: enforcing. This action is required by the upgrade process to make sure the upgraded system can boot without beinig blocked by SElinux rules.
     Remediation: [hint] Make sure there are no SElinux related warnings after the upgrade and enable SElinux manually afterwards. Notice: You can ignore the "/root/tmp_leapp_py3" SElinux warnings.

     解決策：アップグレード後、SELinux 関連の警告がないことを確認し、その後 SELinux を enforcing モードにリセットして、システムのセキュリティとコンプライアンスを確保します。

   • 情報：情報。この種の問題は通常、情報メッセージであり、アップグレードプロセスやシステム操作には影響しません。レポートで特定のメッセージを表示して、アップグレードプロセス中に発生する変更を理解できます。

     ケース：一部のターゲットシステムリポジトリが除外される。

     Risk Factor: info 
     Title: Excluded target system repositories
     Summary: The following repositories are not supported by Red Hat and are excluded from the list of repositories used during the upgrade.
     - rhui-codeready-builder-for-rhel-9-aarch64-rhui-rpms
     - codeready-builder-for-rhel-9-aarch64-rpms
     - codeready-builder-for-rhel-9-s390x-rpms
     - codeready-builder-beta-for-rhel-9-ppc64le-rpms
     - codeready-builder-for-rhel-9-x86_64-rpms
     Remediation: [hint] If some of excluded repositories are still required to be used during the upgrade, execute leapp with the --enablerepo option with the repoid of the repository required to be enabled as an argument (the option can be used multiple times).

     解決策：アップグレードプロセス中に除外されたリポジトリの一部を有効にする必要がある場合は、--enablerepo オプションを使用して有効にします。

次のコマンドを実行してアップグレードを実行します。

• RHEL 9 の最新バージョンにアップグレードします。

  leapp upgrade  --no-rhsm

• 特定のターゲットバージョンにアップグレードします。例えば、RHEL 8 を RHEL 9.4 にアップグレードする場合。

  leapp upgrade  --no-rhsm --target 9.4

次の図は、アップグレードが成功したことを示しています。

次のコマンドを実行してインスタンスを再起動し、新しいシステムで起動します。

reboot

アップグレード結果を検証します。

• cat /etc/redhat-release コマンドを実行して、システムバージョンが更新されているかどうかを確認します。

• アップグレード実行ログまたはレポートでエラーがないか確認します。

• アプリケーションが RHEL 9 システムで正しく実行されるかどうかを観察します。

(条件付き) 次のコマンドを実行して RHEL ソースを構成します。

Leapp アップグレードツールを使用してアップグレードを完了すると、/etc/dnf/vars/releasever ファイルがデフォルトで変更され、システムが RHEL の特定のマイナーバージョンにロックされます。例えば、RHEL 9.4 の場合、リポジトリソースは https://xxxx/9.4/xxx を指すため、RHEL 9.4 バージョンのパッケージにしかアクセスできません。最新の RHEL 9 バージョンのパッケージに自動的にアクセスして最新のセキュリティパッチと機能更新を取得したい場合は、releasever 構成ファイルを削除してメタデータキャッシュを再構築できます。

rm -f /etc/dnf/vars/releasever
dnf clean all && dnf makecache

コマンドを実行すると、RHEL 9 のリポジトリソースが https://xxxx/9/xxx に更新されます。これにより、システムは RHEL 9 の最新のセキュリティパッチと機能更新を自動的に取得でき、システムが最新の状態に保たれます。