いつの間にか、8.6はサポート切れとなっていた様で、AlmaLinux 8.8にアップデート。
安全のためGCPでディスクとVMのクローンを作って、テスト環境で作業を行います。何も考えずに何でもかんでもアップデートするのはアホのすることです。アホのヒトはよく覚えておくように。
※2023.11.22現在、バージョン指定しないと、8.9にアップグレードしてしまい、9系にアップグレードできなくなるので、「–releasever=8.8」を付けてアップグレードは8.8までにします。
# dnf update --releasever=8.8
# rebootApacheが2.4.37でサポート切れのままだったので、Apacheもアップグレードしたく、折角なので現状の最新版であるAlmaLinux 9.3にしよう思いましたが、途中でエラーとなりアップグレードに失敗したので、どうせ他の環境でも同じ様なことが起こるだろうと、忘れない様にメモしながら書いてます。賢いなオレ。
原因は良く分からないけど、前提条件として元はGCPのGCEのVMで、CentOS8をAlmaLinuxにアップグレードした環境だということ。恐らくGCEだってことはあまり関係ないはず。CentOSからのアップグレード製Almaだから？
ひとまず、経緯をメモ。
# dnf install -y http://repo.almalinux.org/elevate/elevate-release-latest-el$(rpm --eval %rhel).noarch.rpm
# dnf install -y leapp-upgrade leapp-data-almalinuxで、必要なパッケージの準備は整った様子。
firewalldを使っている場合、下記のコンフィグを変更しとかないと、エラーが出るらしい。
# vi /etc/firewalld/firewalld.conf# AllowZoneDrifting=yes
AllowZoneDrifting=no今回の環境では、元々設定項目が無かったのでスキップ。
# leapp preupgradeで、アップグレードテスト開始。
============================================================
UPGRADE INHIBITED
============================================================
2023-11-15 14:09:57.787 ERROR PID: 310386 leapp: Upgrade has been inhibited due to the following problems:
2023-11-15 14:09:57.789 ERROR PID: 310386 leapp: 1. Inhibitor: Newest installed kernel not in use
2023-11-15 14:09:57.791 ERROR PID: 310386 leapp: 2. Inhibitor: Detected RPMs with RSA/SHA1 signature
2023-11-15 14:09:57.792 INFO PID: 310386 leapp: Consult the pre-upgrade report for details and possible remediation.
2023-11-15 14:09:57.807 ERROR PID: 310386 leapp: Upgrade workflow failed, check log for details途中で、こんな感じでエラー。「Newest installed kernel not in use」とあるので、さっきAlmaLinux 8.8にアップデートしてから、再起動していなかったからと気付き、reboot！
再度、「leapp preupgrade」してみると、
：
：
====> * mariadb_check
Actor checking for presence of MariaDB installation.
====> * check_yum_plugins_enabled
Checks that the required yum plugins are enabled.
====> * check_skip_phase
Skip all the subsequent phases until the report phase.
==> 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.
2023-11-15 14:25:37.595 ERROR PID: 5680 leapp:
============================================================
UPGRADE INHIBITED
============================================================
2023-11-15 14:25:37.597 ERROR PID: 5680 leapp: Upgrade has been inhibited due to the following problems:
2023-11-15 14:25:37.598 ERROR PID: 5680 leapp: 1. Inhibitor: Detected RPMs with RSA/SHA1 signature
============================================================
UPGRADE INHIBITED
============================================================
Upgrade has been inhibited due to the following problems:
1. Inhibitor: Detected RPMs with RSA/SHA1 signature
Consult the pre-upgrade report for details and possible remediation.
============================================================
UPGRADE INHIBITED
============================================================
Debug output written to /var/log/leapp/leapp-upgrade.log
============================================================
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
============================================================
Answerfile has been generated at /var/log/leapp/answerfile
2023-11-15 14:25:37.620 ERROR PID: 5680 leapp: Upgrade workflow failed, check log for detailsと、また、エラー。
エラーレポートを見てみる
/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:
- MariaDB-server (DSA/SHA1, Tue 28 Jan 2020 06:49:01 AM JST, Key ID cbcb082a1bb943db)
- MariaDB-common (DSA/SHA1, Tue 28 Jan 2020 06:49:09 AM JST, Key ID cbcb082a1bb943db)
- MariaDB-client (DSA/SHA1, Tue 28 Jan 2020 06:49:21 AM JST, Key ID cbcb082a1bb943db)
Remediation: [hint] It is recommended that you contact your package vendor and ask them for new 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
Title: Leapp could not identify where GRUB core is located
Summary: We assume GRUB core is located on the same device as /boot. Leapp needs to update GRUB core as it is not done automatically on legacy (BIOS) systems.
Remediation: [hint] Please run "grub2-install <GRUB_DEVICE> command manually after upgrade
Key: ca7a1a66906a7df3da890aa538562708d3ea6ecd
----------------------------------------
Risk Factor: high
Title: Packages not signed by Red Hat found on the system
Summary: 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:
- ImageMagick-libs
- MariaDB-client
- MariaDB-common
- MariaDB-server
- elevate-release
- galera-4
- gce-disk-expand
- gd3php
- google-cloud-ops-agent
- google-cloud-sdk
- google-compute-engine
- google-compute-engine-oslogin
- google-guest-agent
- google-osconfig-agent
- gpg-pubkey
- leapp
- leapp-data-almalinux
- leapp-deps
- leapp-upgrade-el8toel9
- leapp-upgrade-el8toel9-deps
- libaom
- libavif
- libbsd
- libdav1d
- libimagequant
- liblzf
- libmd
- libopendkim
- libopendmarc
- libraqm
- libspf2
- oniguruma5php
- opendbx
- opendkim
- opendmarc
- php-cli
- php-common
- php-fpm
- php-gd
- php-json
- php-mbstring
- php-mysqlnd
- php-pdo
- php-xml
- php74-php-cli
- php74-php-common
- php74-php-devel
- php74-php-json
- php74-php-pecl-igbinary
- php74-php-pecl-msgpack
- php74-php-pecl-redis5
- php74-runtime
- python3-leapp
- remi-release
- svt-av1-libs
Key: 13f0791ae5f19f50e7d0d606fb6501f91b1efb2c
----------------------------------------
Risk Factor: low
Title: SElinux should be disabled based on the configuration file but it is enabled
Summary: This message is to inform user about non-standard SElinux configuration. Please check "/etc/selinux/config" to see whether the configuration is set as expected.
Key: 07b32401edb752f993c7f7067ad9b0765ee25bf4
----------------------------------------
Risk Factor: info
Title: LEAPP detected SELinux disabled in "/etc/selinux/config"
Summary: On RHEL 9, disabling SELinux in "/etc/selinux/config" is no longer possible. This way, the system starts with SELinux enabled but with no policy loaded. LEAPP will automatically disable SELinux using "SELINUX=0" kernel command line parameter. However, Red Hat strongly recommends to have SELinux enabled
Key: a32598d132c02dc20fd3daf631e85770623d3f8e
----------------------------------------
Risk Factor: info
Title: SElinux disabled
Summary: SElinux disabled, continuing...
Key: 4f25fea9b15b9d1d07d52cc1de02073f295dac3d
----------------------------------------色々とアップグレードじのリスクを表示してくれる。
致命的な問題は「Risk Factor: high (inhibitor)」の箇所で、今回で言えば当初MariaDBをインストールしたときに使ったリポジトリが古すぎて許可できない様です。色々試行錯誤しまし、GPTにも相談しましたが、一度MariaDBをアンインストールしてから、アップグレードしてから、最新版のMariaDBを新規インストールするしかない様です。超めんどーーーい。
そもそも、MariaDBだけで済むんかいなと思ったので、一旦MariaDBをアンインストールしてから、「leapp preupgrade」してみると、無事成功したようです。
では信じて「leapp upgrade」しましょう。
：
いつまで経っても、GCPのブラウザSSHの再接続ができません😢
SSH authentication has faild
GCPのシリアルコンソールで接続してみると、なんかまだアップグレードが走っている模様。15～20分程待って、「Login:」が表示されたので、再度GCPのブラウザSSH接続してみるも接続できず。
デフォの暗号化方式がRSA/SHA2に変更されたそうで、RSA/SHA1を有効化します。
# update-crypto-policies --set DEFAULT:SHA1
Setting system policy to DEFAULT:SHA1
Note: System-wide crypto policies are applied on application start-up.
It is recommended to restart the system for the change of policies
to fully take place.
# reboot
# update-crypto-policies --show
DEFAULT:SHA1変わらずダメ。何でかなーと思って気付きました。
さっきのエラーレポートにGCE関連やらゲストエージェントが含まれていたと。
- google-cloud-ops-agent
- google-cloud-sdk
- google-compute-engine
- google-compute-engine-oslogin
- google-guest-agent
- google-osconfig-agentシリアルコンソールから、サービスの死活チェック
# systemctl status google-guest-agent.service
Unit google-guest-agent.service could not be found.お亡くなり～。でした。
再インストールを試みましたが、なんか競合してる。
# dnf install google-compute-engine google-osconfig-agent
メタデータの期限切れの最終確認: 0:29:58 前の 2023年11月16日 13時15分26秒 に実施しました。
パッケージ google-osconfig-agent-1:20231010.00-g1.el8.x86_64 は既にインストールされています。
エラー:
問題: package google-compute-engine-1:20230801.00-g1.el8.noarch from google-compute-engine requires google-compute-engine-oslogin, but none of the providers can be installed
- 競合するリクエスト
- nothing provides libboost_regex.so.1.66.0()(64bit) needed by google-compute-engine-oslogin-1:20231004.00-g1.el8.x86_64 from google-compute-engine
- nothing provides libjson-c.so.4()(64bit) needed by google-compute-engine-oslogin-1:20231004.00-g1.el8.x86_64 from google-compute-engine
(インストール不可のパッケージをスキップするには、'--skip-broken' を追加してみてください または、'--nobest' を追加して、最適候補のパッケージのみを使用しないでください)えーと、えーと、行き詰ってきた感は否めない。と、天啓が。AlmaLinux9.3にしたってことは、Googleのリポジトリもel8では無く、el9にすればいけんじゃね？
repoulrl = https://packages.cloud.google.com/yum/repos/google-compute-engine-el8-x86_64-stable
となっていたので、「https://packages.cloud.google.com/yum/repos/」にアクセスしてみると、ちゃんと「https://packages.cloud.google.com/yum/repos/google-compute-engine-el9-x86_64-stable」があったので、下記の様に修正。このリポジトリの設定自体、かつて自分が設定したんだか、GCPのOSイメージにセットアップされていたんだか、今となっては記憶も記録も無しと。
# vi /etc/yum.repos.d/google-cloud.repo
[google-compute-engine]
name=Google Compute Engine
baseurl=https://packages.cloud.google.com/yum/repos/google-compute-engine-el9-x86_64-stable
enabled=1
gpgcheck=1
repo_gpgcheck=0
gpgkey=https://packages.cloud.google.com/yum/doc/yum-key.gpg
https://packages.cloud.google.com/yum/doc/rpm-package-key.gpg
[google-cloud-sdk]
name=Google Cloud SDK
baseurl=https://packages.cloud.google.com/yum/repos/cloud-sdk-el9-x86_64
enabled=1
gpgcheck=1
repo_gpgcheck=0
gpgkey=https://packages.cloud.google.com/yum/doc/yum-key.gpg
https://packages.cloud.google.com/yum/doc/rpm-package-key.gpg# dnf google-compute-engine google-osconfig-agent google-osconfig-agent
メタデータの期限切れの最終確認: 0:00:54 前の 2023年11月16日 13時52分57秒 に実施しました。
パッケージ google-osconfig-agent-1:20231010.00-g1.el8.x86_64 は既にインストールされています。
依存関係が解決しました。
==========================================================================================
パッケージ Arch バージョン リポジトリー サイズ
==========================================================================================
インストール:
google-compute-engine noarch 1:20230801.00-g1.el9 google-compute-engine 18 k
アップグレード:
google-osconfig-agent x86_64 1:20231010.00-g1.el9 google-compute-engine 4.9 M
依存関係のインストール:
google-compute-engine-oslogin x86_64 1:20231004.00-g1.el9 google-compute-engine 570 k
google-guest-agent x86_64 1:20231115.00-g1.el9 google-compute-engine 13 M
トランザクションの概要
==========================================================================================
インストール 3 パッケージ
アップグレード 1 パッケージ
ダウンロードサイズの合計: 18 M
パッケージのダウンロード:
(1/4): eef7e316a5c274f525bda8328daebf00036f0208 93 kB/s | 18 kB 00:00
(2/4): 68dc37ac9382ef68f02a0f676b1b106d55f58009 2.3 MB/s | 570 kB 00:00
(3/4): ffbe89731d2744cab84dac5db1e47b499c43fc10 33 MB/s | 4.9 MB 00:00
(4/4): 4cd9d7ccf11fbf0505555913c45e67424bc0a4c1 3.4 MB/s | 13 MB 00:03
--------------------------------------------------------------------------------
合計 4.9 MB/s | 18 MB 00:03
トランザクションの確認を実行中
トランザクションの確認に成功しました。
トランザクションのテストを実行中
トランザクションのテストに成功しました。
トランザクションを実行中
準備 : 1/1
インストール中 : google-guest-agent-1:20231115.00-g1.el9.x86_64 1/5
scriptletの実行中: google-guest-agent-1:20231115.00-g1.el9.x86_64 1/5
[68907.206959] systemd-rc-local-generator[99348]: /etc/rc.d/rc.local is not marked executable, skipping.
[68907.490726] systemd-rc-local-generator[99369]: /etc/rc.d/rc.local is not marked executable, skipping.
[68907.719278] systemd-rc-local-generator[99390]: /etc/rc.d/rc.local is not marked executable, skipping.
[68908.018276] systemd-rc-local-generator[99411]: /etc/rc.d/rc.local is not marked executable, skipping.
[68908.274609] systemd-rc-local-generator[99432]: /etc/rc.d/rc.local is not marked executable, skipping.
インストール中 : google-compute-engine-oslogin-1:20231004.00-g1.el9.x 2/5
scriptletの実行中: google-compute-engine-oslogin[68908.749514] systemd-rc-local-generator[99480]: /etc/rc.d/rc.local is not marked executable, skipping.
-1:20231004.00-g1.el9.x 2/5
[68909.064407] systemd-rc-local-generator[99508]: /etc/rc.d/rc.local is not marked executable, skipping.
[68929.001256] virtio_balloon virtio2: Out of puff! Can't get 1 pages
Installing SELinux module for OS Login.
scriptletの実行中: google-compute-engine-1:20230801.00-g1.el9.noarch 3/5
インストール中 : google-compute-engine-1:20230801.00-g1.el9.noarch 3/5
scriptletの実行中: google-compute-engine-1:20230801.00-g1.el9.noarch 3/5
[68929.930762] virtio_balloon virtio2: Out of puff! Can't get 1 pages
アップグレード中 : google-osconfig-agent-1:20231010.00-g1.el9.x86_64 4/5
scriptletの実行中: google-osconfig-agent-1:20231010.00-g1.el9.x86_64 4/5
scriptletの実行中: google-osconfig-agent-1:20231010.00-g1.el8.x86_64 5/5
整理 : google-osconfig-agent-1:20231010.00-g1.el8.x86_64 5/5
scriptletの実行中: google-osconfig-agent-1:20231010.00-g1.el8.x86_64 5/5
[68969.151193] systemd-rc-local-generator[106554]: /etc/rc.d/rc.local is not marked executable, skipping.
検証 : google-compute-engine-1:20230801.00-g1.el9.noarch 1/5
検証 : google-compute-engine-oslogin-1:20231004.00-g1.el9.x 2/5
検証 : google-guest-agent-1:20231115.00-g1.el9.x86_64 3/5
検証 : google-osconfig-agent-1:20231010.00-g1.el9.x86_64 4/5
検証 : google-osconfig-agent-1:20231010.00-g1.el8.x86_64 5/5
インストール済みの製品が更新されています。
アップグレード済み:
google-osconfig-agent-1:20231010.00-g1.el9.x86_64
インストール済み:
google-compute-engine-1:20230801.00-g1.el9.noarch
google-compute-engine-oslogin-1:20231004.00-g1.el9.x86_64
google-guest-agent-1:20231115.00-g1.el9.x86_64
完了しました!
# systemctl start google-guest-agent.service
# systemctl enable google-guest-agent.service
Unit /usr/lib/systemd/system/google-guest-agent.service is added as a dependency to a non-existent unit network.service.
Unit /usr/lib/systemd/system/google-guest-agent.service is added as a dependency to a non-existent unit networking.service.
Unit /usr/lib/systemd/system/google-guest-agent.service is added as a dependency to a non-existent unit systemd-networkd.service.
[69061.060373] systemd-rc-local-generator[106671]: /etc/rc.d/rc.local is not marked executable, skipping.
これで、無事GCPのブラウザSSHが繋がるようになりました。
暗号化方式は関係なかったので、元に戻しておきました。
# update-crypto-policies --set DEFAULT- google-cloud-ops-agent
- google-cloud-sdk残る「google-cloud-ops-agent」「google-cloud-sdk」はどうかと思って、dnf installしてみたら、インストールされているとのこと。「google-cloud-ops-agent」のアップグレードはできるようなので、アップグレードしておこう。
# dnf install google-cloud-ops-agent google-cloud-sdk
Google Cloud Ops Agent Repository 16 kB/s | 18 kB 00:01
パッケージ google-cloud-ops-agent-2.43.0-1.el8.x86_64 は既にインストールされています。
パッケージ google-cloud-sdk-455.0.0-1.x86_64 は既にインストールされています。
依存関係が解決しました。
=========================================================================================
パッケージ Arch バージョン リポジトリー サイズ
=========================================================================================
アップグレード:
google-cloud-ops-agent x86_64 2.43.0-1.el9 google-cloud-ops-agent 190 M
トランザクションの概要
=========================================================================================
アップグレード 1 パッケージ
目的だったApacheのバージョンは、2.4.57になってクリア！
# httpd -v
Server version: Apache/2.4.57 (AlmaLinux)
Server built: Jul 20 2023 00:00:00あとは、PHPか。ImageMagickとか使ってるから、ダメだろうな。
# php -v
PHP Warning: PHP Startup: Unable to load dynamic library 'igbinary' (tried: /usr/lib64/php/modules/igbinary (/usr/lib64/php/modules/igbinary: cannot open shared object file: No such file or directory), /usr/lib64/php/modules/igbinary.so (/usr/lib64/php/modules/igbinary.so: undefined symbol: _call_user_function_ex)) in Unknown on line 0
PHP Warning: PHP Startup: Unable to load dynamic library 'msgpack' (tried: /usr/lib64/php/modules/msgpack (/usr/lib64/php/modules/msgpack: cannot open shared object file: No such file or directory), /usr/lib64/php/modules/msgpack.so (/usr/lib64/php/modules/msgpack.so: undefined symbol: _call_user_function_ex)) in Unknown on line 0
PHP Warning: PHP Startup: Unable to load dynamic library 'redis' (tried: /usr/lib64/php/modules/redis (/usr/lib64/php/modules/redis: cannot open shared object file: No such file or directory), /usr/lib64/php/modules/redis.so (/usr/lib64/php/modules/redis.so: undefined symbol: igbinary_serialize)) in Unknown on line 0
PHP 8.0.30 (cli) (built: Aug 3 2023 17:13:08) ( NTS gcc x86_64 )
Copyright (c) The PHP Group
Zend Engine v4.0.30, Copyright (c) Zend Technologiesうんうん、案の定ね。バージョンは、8.0.30になったのね。あと、Redisもかー。忘れてた。
# redis-server -v
Redis server v=6.2.7 sha=00000000:0 malloc=jemalloc-5.1.0 bits=64 build=ec192bdd77ecd321Redisは5.0.3から6.2.7にアップグレードされたようだ。
折角だからPHPも8.0から8.2にアップグレードもしておくかー。PHPについては、長くなったので別記事で改めてまとめよう。
ひとまず、MariaDBをアンインストールすれば、AlmaLinux8.6→9.3は問題なくできました。というか、古いMariaDBのリポジトリでインストールしてそのまま使用していたというレアケースなので、世間様にはあまり参考にはならないかも知れない。あくまで個人的な忘備録だコレは。
DBは、この際だから、CloudSQLに移行するか、新規にMariaDBの新バージョンをインストールして、データを戻せば終わりだろう。そこは、好きにするさ。
Add comment