LoginSignup
3
2

Red Hat Enterprise Linux V8.9からV9.3へのアップグレード検証

Posted at

はじめに

現在、Red Hat Enterprise Linux(以下、RHEL)の最新バージョンはV9.3がリリースされています。これまで、筆者の個人環境ではV8.9を使用していましたが、最新のV9.3を使用してみたくなりました。なお、下記リンク先のアップグレードパスを見ると、V8.9からはV9.3へ直接アップグレードすることが可能となっています。

※V7からV9へアップグレードする場合は、V7からV8、V8からV9と二段階のアップグレードが必要です。

新規インストールとは異なり、アップグレード時にのみ使用する専用のユーティリティー(後述のleapp)がありますので、当該ユーティリティーの使用感も検証してみたく、本日V8.9からV9.3へのアップグレードを実施しました。本記事では、実施したアップグレード作業、及び、作業を行う中で見つかった考慮点等をご紹介したいと思います。アップグレード作業においては、下記リンク先のRed Hat社のドキュメントを参考に実施しています。

なお、V8とV9において、必要な最小メモリ量と最小空きディスク要件は同じでしたので、特に気にする必要はありませんでした。

アップグレードの準備

現行システムの状態確認

最初に、下記のコマンドを実行して、更新されているパッケージが無いか否かを確認します。何も無ければ現行のシステムは最新状態となっています。

$ sudo dnf check-uprate

更新パッケージが見つかった場合には、「sudo dnf -y update」コマンドを実行して、事前にパッケージを最新化しておきます。

また、RHEL製品がアタッチされていること、サブスクリプション登録されていることを確認します。

$ sudo subscription-manager list --installed
+-------------------------------------------+
    インストール済み製品のステータス
+-------------------------------------------+
製品名:           Red Hat Enterprise Linux for x86_64
製品 ID:          479
バージョン:       8.9
アーキテクチャー: x86_64
状態:             サブスクライブ済み
状態の詳細:
開始:             2024年02月27日
終了:             2025年02月26日

アップグレード・ユーティリティーのインストール

下記コマンドを実行して、アップグレード作業に必要なleappユーティリティーをインストールします。

$ sudo dnf install leapp-upgrade

RHEL V8.9の場合、leappのバージョンは0.16.0、leapp-upgrade-el8toel9パッケージのバージョンは0.19.0であることが必要ですので、必要なバージョンになっていることを確認します。

$ sudo leapp --version
leapp version 0.16.0

$ sudo rpm -qa | grep leapp-upgrade*
leapp-upgrade-el8toel9-deps-0.19.0-4.el8_9.noarch
leapp-upgrade-el8toel9-0.19.0-4.el8_9.noarch

アップグレード可能性評価の実施

実際にアップグレードを行う前に、下記のコマンドを実行し、アップグレードが実施可能であるか否かをチェックします。

$ sudo leapp preupgrade

コマンド実行後、下記のようなチェックが次々と実施されていきます。

==> Processing phase `configuration_phase`
====> * ipu_workflow_config
        IPU workflow config actor
==> Processing phase `FactsCollection`
====> * scan_custom_repofile
        Scan the custom /etc/leapp/files/leapp_upgrade_repositories.repo repo file.
====> * scancryptopolicies
        Scan information about system wide set crypto policies including:
====> * scanmemory
        Scan Memory of the machine.
====> * scan_subscription_manager_info
        Scans the current system for subscription manager information
~ (略) ~

チェックが終わると、以下のようなレポートが出力されます。

==> Processing phase `Reports`
====> * verify_check_results
        Check all dialogs and notify that user needs to make some choices.
====> * verify_check_results
        Check all generated results messages and notify user about them.

Debug output written to /var/log/leapp/leapp-preupgrade.log

============================================================
                      REPORT OVERVIEW
============================================================

Upgrade has been inhibited due to the following problems:
    1. Detected RPMs with RSA/SHA1 signature
    2. Firewalld Configuration AllowZoneDrifting Is Unsupported

HIGH and MEDIUM severity reports:
    1. GRUB2 core will be automatically updated during the upgrade
    2. Packages not signed by Red Hat found on the system

Reports summary:
    Errors:                      0
    Inhibitors:                  2
    HIGH severity reports:       2
    MEDIUM severity reports:     0
    LOW severity reports:        1
    INFO severity reports:       4

Before continuing consult the full report:
    A report has been generated at /var/log/leapp/leapp-report.json
    A report has been generated at /var/log/leapp/leapp-report.txt

============================================================
                   END OF REPORT OVERVIEW
============================================================

Answerfile has been generated at /var/log/leapp/answerfile

「Upgrade has been inhibited due to the following problems:」に記載されている項目は、アップグレード前に必ず対応するようにしてください。試しに、対応せずにアップグレードを開始してみましたが、アップグレードは実施されませんでしたので、ご注意ください。

アップグレード前の事前チェック結果の詳細レポートは、「/var/log/leapp/leapp-report.txt」で確認することができます。そこで、上記「Upgrade has been inhibited due to the following problems:」に記載の2つの項目に関して、詳細レポートを確認します。

/var/log/leapp/leapp-report.txt
Risk Factor: high (inhibitor)
Title: Detected RPMs with RSA/SHA1 signature
Summary: Digital signatures using SHA-1 hash algorithm are no longer considered secure and are not allowed to be used on RHEL 9 systems by default. This causes issues when using DNF/RPM to handle packages with RSA/SHA1 signatures as the signature cannot be checked with the default cryptographic policy. Any such packages cannot be installed, removed, or replaced unless the signature check is disabled in dnf/rpm or SHA-1 is enabled using non-default crypto-policies. For more information see the following documents:
  - Major changes in RHEL 9: https://red.ht/rhel-9-overview-major-changes
  - Security Considerations in adopting RHEL 9: https://red.ht/rhel-9-security-considerations
 The list of problematic packages: 
    - amazon-ssm-agent (RSA/SHA1, Sat 04 Feb 2023 07:40:08 AM JST, Key ID dd81a61756baa549)
    - postgresql14-libs (DSA/SHA1, Mon 20 Nov 2023 06:55:41 PM JST, Key ID 1f16d2e1442df0f8)
    - postgresql14 (DSA/SHA1, Mon 20 Nov 2023 06:55:41 PM JST, Key ID 1f16d2e1442df0f8)
    - python3-humanize (DSA/SHA1, Mon 19 Sep 2022 05:55:54 AM JST, Key ID 1f16d2e1442df0f8)
    - postgresql14-server (DSA/SHA1, Mon 20 Nov 2023 06:55:41 PM JST, Key ID 1f16d2e1442df0f8)
Remediation: [hint] It is recommended that you contact your package vendor and ask them for new builds signed with supported signatures and install the new packages before the upgrade. If this is not possible you may instead remove the incompatible packages.
Key: f16f40f49c2329a2691c0801b94d31b6b3d4f876
----------------------------------------
Risk Factor: high (inhibitor)
Title: Firewalld Configuration AllowZoneDrifting Is Unsupported
Summary: Firewalld has enabled configuration option "AllowZoneDrifiting" which has been removed in RHEL-9. New behavior is as if "AllowZoneDrifiting" was set to "no".
Remediation: [hint] Set AllowZoneDrifting=no in /etc/firewalld/firewalld.conf
[command] sed -i s/^AllowZoneDrifting=.*/AllowZoneDrifting=no/ /etc/firewalld/firewalld.conf
Key: 5b1cf050e1a877b0358b6e8c612277c591d40c13
  • Detected RPMs with RSA/SHA1 signature
    SHA1アルゴリズムを使用したデジタル署名はV9からはサポートされないということで、「The list of problematic packages:」の箇所に挙げられているパッケージを、アップグレード前に新しいパッケージをインストールする、もしくは、サポートされている署名方式でパッケージをビルドしてもらうようにベンダーに依頼するようにと書かれています。今回は、必要ならアップグレード後に再インストールすることにして、対象パッケージを削除することにしました。

  • Firewalld Configuration AllowZoneDrifting Is Unsupported
    V8までは、Firewalldの構成ファイルにおいて、AllowZoneDriftingというパラメータがサポートされていましたが、V9からはサポートされないようになるとあります。V9では、「AllowZoneDrifting = no」の扱いとなるため、/etc/firewalld/firewalld.confにおいて、「AllowZoneDrifting = no」を設定するようにとありますので、そのように設定しました。

「HIGH and MEDIUM severity reports:」の項目の内、「Packages not signed by Red Hat found on the system」と記載があります。詳細レポートの中身を見ると「The following packages have not been signed by Red Hat and may be removed during the upgrade process in case Red Hat-signed packages to be removed during the upgrade depend on them」と書かれていますので、Red Hat社に署名されていないパッケージについては、アップグレード中に削除されるようです。今回は事前に削除しておくことにしました。リストアップされたパッケージ名を見ると、azure-cliとかterraformとかだったので、個別にリポジトリを追加してインストールしていたものばかりでした。

一通り対応が終わったら、再度「sudo leapp preupgrade」コマンドを実行し、「Upgrade has been inhibited due to the following problems:」の項目が表示されなくなることを確認します。この項目が表示されなくなったことが確認できれば、アップグレードの実行は可能となります。表示された場合は、レポートを確認して対応した後、再度コマンドを実行してください。表示されなくなるまで、これを繰り返します。

本来であれば不測の事態に備えて、後述のアップグレードに進む前にシステムのバックアップを取得することをお奨めしますが、今回は個人検証環境につき割愛しています。

アップグレード実行

アップグレードの準備は終わったので、下記のコマンドを実行し、アップグレードを開始します。

$ sudo leapp upgrade

コマンド実行後、「システム・チェック」→「V9用のパッケージのインストール」の順にアップグレード処理が進んでいきます。

==> Processing phase `configuration_phase`
~(略)~
Transaction Summary
============================================================================================================================================
Install     257 Packages
Upgrade    1458 Packages
Remove      123 Packages
Downgrade    24 Packages

Total size: 1.9 G
DNF will only download packages, install gpg keys, and check the transaction.
Downloading Packages:
Running transaction check
Transaction check succeeded.
Running transaction test
Transaction test succeeded.
Complete!
====> * remove_upgrade_artifacts
        Removes artifacts left over by previous leapp runs
====> * add_upgrade_boot_entry
        Add new boot entry for Leapp provided initramfs.
A reboot is required to continue. Please reboot your system.


Debug output written to /var/log/leapp/leapp-upgrade.log

============================================================
                      REPORT OVERVIEW
============================================================

HIGH and MEDIUM severity reports:
    1. GRUB2 core will be automatically updated during the upgrade

Reports summary:
    Errors:                      0
    Inhibitors:                  0
    HIGH severity reports:       1
    MEDIUM severity reports:     0
    LOW severity reports:        2
    INFO severity reports:       4

Before continuing consult the full report:
    A report has been generated at /var/log/leapp/leapp-report.json
    A report has been generated at /var/log/leapp/leapp-report.txt

============================================================
                   END OF REPORT OVERVIEW
============================================================

Answerfile has been generated at /var/log/leapp/answerfile

上記出力において、「A reboot is required to continue. Please reboot your system.」が表示されていたら、システムを再起動します。再起動後、システムはRHEL9ベースの初期RAMディスクイメージinitramfsで起動してきます。起動後、アップグレード・ユーティリティー(leapp)により、全てのパッケージに対するアップグレード処理が行われ、自動的にシステムが再起動します。Linuxコンソールに、下記のログオン画面が表示されれば、アップグレード処理は成功です。

Red Hat Enterprise Linux 9.3 (Plow)
Kernel 5.14.0-362.24.1.el9_3.x86_64 on an x86_64

localhost login:

アップグレード後の確認

コンソールにログオン後、システムがV9.3になっていることを改めて確認します。

$ cat /etc/redhat-release
Red Hat Enterprise Linux release 9.3 (Plow)

$ uname -r
5.14.0-362.24.1.el9_3.x86_64

$ sudo subscription-manager list --installed
+-------------------------------------------+
    インストール済み製品のステータス
+-------------------------------------------+
製品名:           Red Hat Enterprise Linux for x86_64
製品 ID:          479
バージョン:       9.3
アーキテクチャー: x86_64
状態:             サブスクライブ済み
状態の詳細:
開始:             2024年02月27日
終了:             2025年02月26日

$ sudo subscription-manager release
リリース: 9.3

問題なくV9.3にアップグレードされており、サブスクリプション登録も問題ないことが確認できました。

アップグレード後の作業

SELinuxモードのEnforcingへの変更

アップグレード中、SELinuxのモードはleappにより「Permisive」に変更されています。

$ getenforce
Permissive

その為、アップグレード完了後は、SELinuxのモードを「enforcing」に変更する必要があります。具体的には、「/etc/selinux/config」構成ファイルにおいて「SELINUX=enforcing」に変更し、システムを再起動します。再起動後、getenforceコマンドで確認します。

$ getenforce
Enforcing

その他の後処理

下記リンク先の記載を参考に、不要なパッケージなどを削除します。

さいごに

今回は、RHELが提供しているアップグレード・ユーティリティー(leapp)を使用したV8.9からV9.3へのアップグレード作業の内容と、作業で生じた考慮点等をご紹介しました。
単純に新規インストールするのとは違い、実際にアップグレードを実行するまでには色々対応しないといけなかったり、考慮しないといけない点もありましたので、今回アップグレードを実施してみて良かったと思います。
今後、RHEL V8からV9への切り替えを目指されている方への参考になれば幸いです。

3
2
0

Register as a new user and use Qiita more conveniently

  1. You get articles that match your needs
  2. You can efficiently read back useful information
  3. You can use dark theme
What you can do with signing up
3
2