Elastic Compute Service:Red Hat Enterprise Linux operating system

アップグレードの前に、アップグレードのリスクを理解し、「スナップショットの作成」でデータをバックアップすることをお勧めします。これにより、アップグレードが失敗した場合にデータを迅速に回復できます。

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 ツールの提案に基づいてエラーを解決します。次のセクションでは、一般的なアップグレード前チェックのエラーとその解決策をリスクレベル別に示します。

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

     • ケース 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

       

   • high: 高リスク。このタイプの問題はアップグレードを直接ブロックしませんが、アップグレード後の問題を回避するために、アップグレードの前または後に解決することをお勧めします。

     • ケース 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 コマンドを実行してこれらのパッケージを削除します。

   • medium: 中リスク。このタイプの問題はアップグレードを直接ブロックしませんが、アップグレード後の潜在的な問題を回避するために、アップグレードの前または後に解決することをお勧めします。

     ケース: 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 の機能を置き換える必要があります。

   • low: 低リスク。このタイプの問題は、アップグレードプロセスやシステムの動作に軽微な影響を与えますが、安定したシステムの動作を確保するために、アップグレードの前または後に解決することをお勧めします。

     ケース: 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 モードにリセットして、システムのセキュリティとコンプライアンスを確保します。

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

     ケース: /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 構成ファイルを削除して DNF キャッシュを再構築できます。

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 ツールの提案に基づいてエラーを解決します。次のセクションでは、一般的なアップグレード前チェックのエラーとその解決策をリスクレベル別に示します。

   • high: 高リスク。このタイプの問題はアップグレードを直接ブロックしませんが、アップグレード後の問題を回避するために、アップグレードの前または後に解決することをお勧めします。

     • ケース 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 ツールおよびシステム環境と互換性があることを確認してください。アップグレード後、システムが正しく動作することを確認し、カスタムアクターによって引き起こされた問題を速やかに解決してください。カスタムアクターの管理方法の詳細については、「Red Hat Enterprise Linux のインプレースアップグレードのカスタマイズ」をご参照ください。

     • ケース 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.

       解決策: アップグレード後、GRUB 構成を確認して、システムが正しく起動することを確認してください。

   • low: 低リスク。このタイプの問題は、アップグレードプロセスやシステムの動作に軽微な影響を与えますが、安定したシステムの動作を確保するために、アップグレードの前または後に解決することをお勧めします。

     ケース: 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 モードにリセットして、システムのセキュリティとコンプライアンスを確保します。

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

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

     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 構成ファイルを削除して DNF キャッシュを再構築できます。

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

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