CentOS 7 から 8 へのアップグレード
目次
CentOS 7 から 8 へは、公式のアップグレード手段が用意されていません。公式見解としては、データをバックアップ → CentOS 8 を新規インストール → データを復元、という手順を取るべきとのことです。
詳しくは以下のページを参照して下さい。
- HowTos/MigrationGuide – CentOS Wiki
- FAQ/CentOS8 – CentOS Wiki
- CentOS 7 to CentOS 8 upgrade script – CentOS
本記事では、公式にはサポートされていない CentOS 7 から 8 へのアップグレードのやり方を紹介します。サポートされていない方法ですので、参考にする場合には自己責任でお願いいたします。
目次
背景
CentOS 8 へ移行したい理由
CentOS 7 は2024年6月までサポートされるのに対して、CentOS 8 は2021年末までなので、それだけだとアップグレードする理由にはならないのですが、その後 Rocky Linux 8.4 か AlmaLinux 8.4 にアップグレード（？）する予定です。
Rocky Linux か AlmaLinux にする理由としては、どちらも2029年5月31日までサポートされるというのが一つ、そろそろ RHEL 8系になれておきたいというのがもう一つです。
CentOS 8 の新規インストールではなくアップグレードする理由
冒頭に書いた通り、CentOS 7 から 8 へのアップグレードは、公式にはサポートされておらず、新規インストールが推奨されています。
物理マシンであればパーティションを分割して、あるいは AWS などであればディスク（EBS）を増設し、その後に /home や /var/lib/mysql 、/var/www/html などをそちらに移して、最後はルートパーティションに CentOS 8 を新規インストールするという方法を取ったと思います。
ただ、今回 CentOS 7 が稼働している環境は VPS なので、CentOS を新規インストールするとデータが全て消えてしまいます。もちろん、別マシンに scp などでバックアップを取って後で復元すれば良いんですが、結構データ量が多いので面倒くさいなぁという思いがありました。
参考にしたページ
“centos 7 to 8” などと検索すると、以下のページがトップで出てきます。
How to Upgrade CentOS 7 to CentOS 8
日本語では、Qiita の以下の記事が一番上に来ます。内容としては、上の英語のページと同じなので、上のページの内容をそのまま実行しただけと思われます。
CentOS 7からCentOS 8へのアップグレードは大変です💦 – Qiita
本記事では、この2つのページで紹介されている方法をベースに、
- やっていて詰まったところ
- 作業内容の説明
などを適宜補足していきます。
具体的な手順とその解説
EPEL、ツール類のインストール
まずは以下のコマンドを実行します。
sudo yum install epel-release
sudo yum install yum-utils
sudo yum install rpmconf
EPEL は Extra Packages for Enterprise Linux の略で、RHEL やそのクローンである CentOS に標準では含まれていないパッケージを集めたレポジトリーです。
最初に epel-release パッケージをインストールして EPEL を使えるようにし、その後に yum-utils と rpmconf をインストールします。
参考サイトでは rpmconf のインストールは手順には含まれていませんが、環境によっては rpmconf がインストールされていない場合もあるので、その場合はインストールしましょう。
設定の更新（rpmconf）
次にこちらのコマンドを実行します。
sudo rpmconf -a
これにはどういう意味があるのでしょうか。
*.rpmsave , *.rpmnewファイル
CentOS などを使っていると、*.rpmsave や *.rpmnew といったファイル名を見かけたことがあるかもしれません。これらのファイルは、主に以下のような流れで作成されます。
- あるパッケージ（例えば
httpd）をインストールする - そのパッケージでインストールされた設定ファイル（例えば
/etc/httpd/conf/httpd.conf）を手動で変更する - そのパッケージをアップグレードすると、パッケージによって以下のどちらかの挙動となる
- 2で更新されたファイルはそのまま残しておき、アップグレード後のパッケージに含まれる設定ファイルが
*.rpmnewといった名前（ 例えば/etc/httpd/conf/httpd.conf.rpmnew）で保存される - 2で更新されたファイルは
*.rpmsaveという名前で保存し、新しい設定ファイルがインストールされる
- 2で更新されたファイルはそのまま残しておき、アップグレード後のパッケージに含まれる設定ファイルが
これらのファイルについての説明は、英語ですが以下のページが詳しいです。
Dealing with .rpmnew and .rpmsave files – Linux.com
日本語の情報であれば、以下のページが参考になります。ただし、こちらのページの「設定ファイルの統合手順」は、もっと良い方法があります。
CentOS7でパッケージアップデート後にrpmnew、rpmsaveファイルができたときは | 4thsight.xyz
設定ファイルのマージに使うのが rpmconf コマンド
本題に戻りますが、rpmconf コマンドというのが、そうした *.rpmnew, *.rpmsave ファイルを探して統合するために使えます。具体的には、 rpmconf コマンドは以下のような事をします。
- rpmnew, rpmsave などを探してくる
- それらに対してどういう対応すべきかを聞いてくる
- パッケージに付属の設定ファイルを使う
- 手動で修正したファイルを使う
- それらのファイルの違いを表示する
- 2つのファイルの変更点をマージする
- その内容に沿って、ファイルのマージや不要なファイルの削除を行う
結局、なぜ実行するのか
*.rpmnew や *.rpmsave ファイルがあるということは、現在の設定ファイルに最新のパッケージに必要な設定項目が含まれていない、あるいは手動で設定した設定項目が含まれていない、という可能性がありますので、OS のアップグレードの前に対応しておくというのが、この手順の意味だと思います。
不要なパッケージの削除
sudo package-cleanup --leaves
sudo package-cleanup --orphans
package-cleanup コマンドは、インストールされているけど不要なパッケージを削除するコマンドです。詳細は man package-cleanup で確認して下さい。
dnf のインストール、yum のアンインストール
sudo yum install dnf
sudo dnf -y remove yum yum-metadata-parser
sudo rm -Rf /etc/yum
dnf は、CentOS 8 でのデフォルトのパッケージマネージャーです。CentOS 8 に上げる前にインストールしておきます。
yum は、ご存知 CentOS 7 までのデフォルトのパッケージマネージャーですが、正直、削除する必要性はよく分かりません。参考にした英語ページには “You also need to remove the yum package manager using the command.” としか書かれていません。
yum が入っていても問題無さそうな気もしますが、とりあえず消しました。
パッケージのアップデート
この辺りから、徐々に一筋縄ではいかなくなります。
sudo dnf upgrade
このコマンドは、インストールされているパッケージを最新のものにするのですが、依存性の問題とかで上手くいかない場合があるので、一つ一つ対処します。
こちらの環境ででたエラー
以下のエラーが出ました。エラーメッセージにある通り、問題のある処理（oniguruma, EPEL のインストール）はスキップしたとのことなので無視しました。oniguruma は PHP 7.2 に必要とされていますが、PHP は 別途7.3にバージョンアップする予定です。
問題: cannot install both oniguruma-6.8.2-1.el7.x86_64 and oniguruma-5.9.5-3.el7.x86_64
- package php72u-mbstring-7.2.20-1.el7.ius.x86_64 requires libonig.so.2()(64bit), but none of the providers can be installed
- cannot install the best update candidate for package oniguruma-5.9.5-3.el7.x86_64
- problem with installed package php72u-mbstring-7.2.20-1.el7.ius.x86_64
==========================================================================================================================================================
パッケージ アーキテクチャー バージョン リポジトリ サイズ
==========================================================================================================================================================
競合するパッケージをスキップします:
(アップグレードを強制するにはコマンドラインに '--best --allowerasing' を追加します):
oniguruma x86_64 6.8.2-1.el7 epel 181 k
トランザクションの概要
==========================================================================================================================================================
スキップ 1 パッケージ
行うべきことはありません。
完了しました!
CentOS 8 用レポジトリ等のインストール
英語の参考ページには以下のコマンドを実行すると書いています。3つのパッケージをインストールするのですが、2021年6月29日時点だと、2つ目のパッケージが404でエラーとなります。
# パッケージのバージョンが少し古くて、404 になる
sudo dnf install \
http://mirror.centos.org/centos/8/BaseOS/x86_64/os/Packages/centos-linux-repos-8-2.el8.noarch.rpm \
http://mirror.centos.org/centos/8/BaseOS/x86_64/os/Packages/centos-linux-release-8.3-1.2011.el8.noarch.rpm \
http://mirror.centos.org/centos/8/BaseOS/x86_64/os/Packages/centos-gpg-keys-8-2.el8.noarch.rpm
以下の通り、最新のものに変更すれば大丈夫です。
# これで OK
sudo dnf install \
http://mirror.centos.org/centos/8/BaseOS/x86_64/os/Packages/centos-linux-repos-8-2.el8.noarch.rpm \
http://mirror.centos.org/centos/8/BaseOS/x86_64/os/Packages/centos-linux-release-8.4-1.2105.el8.noarch.rpm \
http://mirror.centos.org/centos/8/BaseOS/x86_64/os/Packages/centos-gpg-keys-8-2.el8.noarch.rpm
また、EPEL も最新のものにアップグレードし、一時ファイルを消して綺麗な状態にします。
sudo dnf -y upgrade https://dl.fedoraproject.org/pub/epel/epel-release-latest-8.noarch.rpm
sudo dnf clean all
こちらの環境で出たエラー
EPEL のアップグレードの際にエラーが出ました。CentOS 7 に新しめの PHP をインストールするときに IUS を使ったのですが、それが EPEL 7 に依存しているためです。この時点では一旦無視して次に進みました。
問題: problem with installed package ius-release-2-1.el7.ius.noarch
- package ius-release-2-1.el7.ius.noarch requires epel-release = 7, but none of the providers can be installed
- cannot install both epel-release-8-11.el8.noarch and epel-release-7-13.noarch
- cannot install the best update candidate for package epel-release-7-13.noarch
==========================================================================================================================================================
パッケージ アーキテクチャー バージョン リポジトリ サイズ
==========================================================================================================================================================
競合するパッケージをスキップします:
(アップグレードを強制するにはコマンドラインに '--best --allowerasing' を追加します):
epel-release noarch 8-11.el8 @commandline 23 k
トランザクションの概要
==========================================================================================================================================================
スキップ 1 パッケージ
行うべきことはありません。
完了しました!
CentOS 7 のカーネルと sysvinit-tools の削除
ここからはもう後戻りできないので、慎重にやる必要があります。
sudo rpm -e `rpm -q kernel`
sudo rpm -e --nodeps sysvinit-tools
まず、現在のカーネルを削除する意味はよく分かりませんでした。OS をバージョンアップとは関係無しにカーネルのアップグレードを行う事は普通ですが、その際に古いカーネルは残しておいて何かあったら古いカーネルで起動できるようにするので、残しておいて良いような気もします。
とは言え、アップグレードの障害となるのかもしれないので、とりあえず消しましたが。
次に sysvinit-tools を削除するのですが、参考ページでは「be sure to remove conflicting packages」と書いてあるので、アップグレードする際に CentOS 8 の他のパッケージとコンフリクトするのでしょう。
sysvinit-tools にどんなのファイルが含まれているのか確認しましたが、そこまで重要なものも無いので削除で問題無いでしょう。
sysvinit-tools-2.88-14.dsf.el7.x86_64.rpm CentOS 7 Download
こちらの環境で出たエラー
カーネルの削除時にエラーが出ました。
エラー: 依存性の欠如:
kernel >= 3.10.0-1133.el7 は (インストール済み)kmod-kvdo-6.1.3.23-5.el7.x86_64 に必要とされています
kernel(PDE_DATA) = 0x44f0d59d は (インストール済み)kmod-kvdo-6.1.3.23-5.el7.x86_64 に必要とされています
（めっちゃ長いので省略。全エラーは以下の Gist に貼り付けてあります。）
CentOS 7 -> 8 で古いカーネルを削除しようとしたときにでた依存関係のエラー
vdo というのが古いカーネルに依存しているようです。調べてみたところ、カーネルモジュールですが、無くても大丈夫なようなので、とりあえず削除しちゃいました。その後、カーネルを削除したら問題無く終わりました。
sudo rpm -e kmod-kvdo vdo
sudo rpm -e `rpm -q kernel`
CentOS 8 へのアップグレード
sudo dnf -y --releasever=8 --allowerasing --setopt=deltarpm=false distro-sync
sudo dnf -y install kernel-core
sudo dnf -y groupupdate "Core" "Minimal Install"
1つ目のコマンドは、インストールされているパッケージを、バージョン8の最新、つまり 8.4 の最新版に更新するというものです。これで大抵のパッケージは更新されます。
この手順では色々エラーが出たので、下の方でまとめて説明しています。
2つ目のコマンドですが、カーネルは上の方の手順で削除済みなので、dnf コマンドで新たにインストールするという意図だと思います。が、実際には不要です。理由としては、1つ目のコマンド実行時点で、カーネルに依存するパッケージのアップグレードの際にカーネルもインストールされているためです。メッセージとしては以下の通りです。
メタデータの期限切れの最終確認: 0:11:18 時間前の 2021年06月29日 03時53分14秒 に実施しました。
パッケージ kernel-core-4.18.0-305.3.1.el8.x86_64 は既にインストールされています。
依存関係が解決しました。
行うべきことはありません。
完了しました!
3つ目のコマンドは、CentOS などを新規インストールした方であれば分かると思いますが、”Core” と “Minimal Install” グループに属するパッケージをインストールします。
CentOS 7 がインストールされている段階で、”Core” と “Minimal Install” グループに属するパッケージはインストールされていて、1つ目のコマンドでそれらのパッケージが CentOS 8.4 の最新版のものになっているのですが、CentOS 8 になって新たに追加されたパッケージとかもあるので、それらをインストールしています。
こちらの環境で出たエラー1 (MariaDB)
ここもすんなりいきませんでした。1つ目のコマンドで以下のエラーが出ました。
(mariadb >= 3:10.3.27 if mariadb) は mariadb-connector-c-3.1.11-2.el8_3.x86_64 に必要とされています
(mariadb-connector-c-config = 3.1.11-2.el8_3 if mariadb-connector-c-config) は mariadb-connector-c-3.1.11-2.el8_3.x86_64 に必要とされています
rpmlib(RichDependencies) <= 4.12.0-1 は mariadb-connector-c-3.1.11-2.el8_3.x86_64 に必要とされています
(mariadb-devel >= 3:10.3.27 if mariadb-devel) は mariadb-connector-c-devel-3.1.11-2.el8_3.x86_64 に必要とされています
rpmlib(RichDependencies) <= 4.12.0-1 は mariadb-connector-c-devel-3.1.11-2.el8_3.x86_64 に必要とされています
(NetworkManager >= 1.20 or dhclient) は dracut-network-049-135.git20210121.el8.x86_64 に必要とされています
rpmlib(RichDependencies) <= 4.12.0-1 は dracut-network-049-135.git20210121.el8.x86_64 に必要とされています
問題を診断するには実行してみてください: 'rpm -Va --nofiles --nodigest'.
RPMDB を破損させたかもしれませんが、'rpm --rebuilddb' を実行することでこの問題を解決できる可能性があります。
ダウンロード済みのパッケージは、次の正常なトランザクションまでキャッシュに保存されました。
'dnf clean packages' を実行することでキャッシュパッケージを削除できます。
MariaDB と dracut-network が何か問題となっています。
MariaDB は、後から再インストールすることにして削除します。
# service mariadb stop
Redirecting to /bin/systemctl stop mariadb.service
# cd /var/lib
# cp -a mysql{,.20210629}
# rpm -e $(rpm -qa 'mariadb*') perl-DBD-MySQL postfix
警告: /var/log/mariadb/mariadb.log は /var/log/mariadb/mariadb.log.rpmsave として保存されました。
警告: /etc/my.cnf は /etc/my.cnf.rpmsave として保存されました。
こちらの環境で出たエラー2 (dracut-network)
次に、dracut です。dracut というのも初耳だったのですが、調べてみると起動プロセスに関係あるもののようです。
削除しない方が良さそうなので、消さずに済む方法を調べました。すると、参考ページのコメント欄に AppStream レポジトリを無効にして distro-sync、その後 AppStream レポジトリを有効にして再度 distro-sync で解決した、という情報があったので試してみます。
# dnf config-manager --disable appstream
そのようなコマンドはありません: config-manager. /usr/bin/dnf --help を使用してください。
DNF プラグインコマンドかもしれません。"dnf install 'dnf-command(config-manager)'" を試してください
dnf config-manager なんてコマンドは無いと怒られました。yum の場合は /etc/yum.repos.d/ ディレクトリのしたのファイルを手動でいじれば良いのですが、dnf の場合はどうすれば良いのか分かりません。
なので、メッセージにある通り dnf install 'dnf-command(config-manager)' を試してみたのですが、エラーが出ました（エラーメッセージは保存し忘れたようです）。仕方ないので、必要なパッケージファイルをダウンロードして、手動でインストールしました。
wget http://mirror.centos.org/centos/7/extras/x86_64/Packages/dnf-plugins-core-4.0.2.2-3.el7_6.noarch.rpm
wget http://mirror.centos.org/centos/7/extras/x86_64/Packages/python2-dnf-plugins-core-4.0.2.2-3.el7_6.noarch.rpm
wget http://mirror.centos.org/centos/7/os/x86_64/Packages/python-dateutil-1.5-7.el7.noarch.rpm
sudo rpm -i *.rpm
これで AppStream を無効化できますので、再度 distro-sync をします。
sudo dnf config-manager --disable appstream
sudo dnf -y --releasever=8 --allowerasing --setopt=deltarpm=false distro-sync
まだ同じエラーが出ました。結局、以下のコマンドを実行したところ、 dracut-network といくつかのパッケージが削除されました。
sudo dnf upgrade dracut-network --allowerasing --best
コマンドの結果はこちら。
CentOS 7 -> 8 のログ: dracut-network
こちらの環境で出たエラー3 (vim)
再度 distro-sync をすると、今度は以下のエラーです。
(略)
合計 5.1 GB/s | 435 MB 00:00
トランザクションの確認を実行中
トランザクションの確認に成功しました。
トランザクションのテストを実行中
ダウンロード済みのパッケージは、次の正常なトランザクションまでキャッシュに保存されました。
'dnf clean packages' を実行することでキャッシュパッケージを削除できます。
エラー: トランザクションの確認時にエラー:
ファイル /usr/share/man/man1/rvi.1.gz (パッケージ vim-minimal-2:8.0.1763-15.el8.x86_64 から) は、パッケージ vim-common-2:7.4.629-8.el7_9.x86_64 からのフ
イルと競合しています。
ファイル /usr/share/man/man1/vi.1.gz (パッケージ vim-minimal-2:8.0.1763-15.el8.x86_64 から) は、パッケージ vim-common-2:7.4.629-8.el7_9.x86_64 からのフ
イルと競合しています。
エラーの概要
-------------
解決方法は、vim を削除することです。
「vim がなければ nano を使えば良いじゃない」by マリーアントワネット
sudo rpm -e vim-common vim-enhanced
その後、distro-sync でようやく成功。その後、AppStream を有効化してもう一度 distro-sync です。
sudo dnf -y --releasever=8 --allowerasing --setopt=deltarpm=false distro-sync
sudo dnf config-manager --enable appstream
sudo dnf -y --releasever=8 --allowerasing --setopt=deltarpm=false distro-sync
こちらの環境で出たエラー4 (systemd)
AppStream を有効にした後の distro-sync で以下のエラーが出ました。
CentOS Linux 8 - AppStream 15 kB/s | 4.3 kB 00:00
エラー:
問題: 操作は結果的に以下の保護されたパッケージを削除します: systemd
(インストール不可のパッケージをスキップするには、'--skip-broken' を追加してみてください または、'--nobest' を追加して、最適候補のパッケージのみを使用しな
いでください)
日本語のメッセージで検索しても情報が少なそうなので、LANG=C にしてコマンドを実行すると、以下の英語のメッセージが出ました。
Last metadata expiration check: 0:00:17 ago on Tue Jun 29 03:53:14 2021.
Error:
Problem: The operation would result in removing the following protected packages: systemd
(try to add '--skip-broken' to skip uninstallable packages or '--nobest' to use not only best candidate packages)
以下の通り、--skip-broken をつけたら成功しました。
sudo dnf -y --releasever=8 --allowerasing --setopt=deltarpm=false --skip-broken --nobest distro-sync
再度 dnf update
ここで、再度パッケージのアップグレードを試みて、何かあれば解決します。
sudo dnf update
こちらの環境で出たエラー1 (ius-release)
CentOS Linux 8 - BaseOS 15 kB/s | 3.9 kB 00:00
エラー:
問題 1: cannot install the best update candidate for package libidn2-2.2.0-1.el8.x86_64
- nothing provides libunistring.so.0()(64bit) needed by libidn2-2.3.1-1.el7.x86_64
問題 2: package ius-release-2-1.el7.ius.noarch requires epel-release = 7, but none of the providers can be installed
- cannot install both epel-release-8-8.el8.noarch and epel-release-7-13.noarch
- cannot install both epel-release-7-13.noarch and epel-release-8-8.el8.noarch
- cannot install the best update candidate for package ius-release-2-1.el7.ius.noarch
- cannot install the best update candidate for package epel-release-7-13.noarch
(競合するパッケージを置き換えるには、コマンドラインに '--allowerasing' を追加してみてください または、'--skip-broken' を追加して、インストール不可のパッケ
ジをスキップしてください または、'--nobest' を追加して、最適候補のパッケージのみを使用しないでください)
前述の通り、CentOS 7 に新しめの PHP をインストールするために ICS を使っていましたが、こちらは不要なので削除します。
sudo rpm -e ius-release
この後、 dnf update を再度実行します。
こちらの環境で出たエラー2 (libidn2)
メタデータの期限切れの最終確認: 0:05:08 時間前の 2021年06月29日 04時06分51秒 に実施しました。
エラー:
問題: cannot install the best update candidate for package libidn2-2.2.0-1.el8.x86_64
- nothing provides libunistring.so.0()(64bit) needed by libidn2-2.3.1-1.el7.x86_64
(インストール不可のパッケージをスキップするには、'--skip-broken' を追加してみてください または、'--nobest' を追加して、最適候補のパッケージのみを使用しな
でください)
この頃にはかなり眠くてうろ覚えですが、手元のメモを見る限り EPEL の最新版をインストールしたら直ったようです。
sudo yum install https://dl.fedoraproject.org/pub/epel/epel-release-latest-8.noarch.rpm
以下、ログです。
# yum install https://dl.fedoraproject.org/pub/epel/epel-release-latest-8.noarch.rpm
メタデータの期限切れの最終確認: 0:08:04 時間前の 2021年06月29日 04時06分51秒 に実施しました。
epel-release-latest-8.noarch.rpm 28 kB/s | 23 kB 00:00
依存関係が解決しました。
==========================================================================================================================================================
パッケージ アーキテクチャー バージョン リポジトリー サイズ
==========================================================================================================================================================
アップグレード:
epel-release noarch 8-11.el8 @commandline 23 k
トランザクションの概要
==========================================================================================================================================================
アップグレード 1 パッケージ
合計サイズ: 23 k
これでよろしいですか? [y/N]: y
パッケージのダウンロード:
トランザクションの確認を実行中
トランザクションの確認に成功しました。
トランザクションのテストを実行中
トランザクションのテストに成功しました。
トランザクションを実行中
準備 : 1/1
scriptletの実行中: epel-release-8-11.el8.noarch 1/1
アップグレード中 : epel-release-8-11.el8.noarch 1/2
整理 : epel-release-7-13.noarch 2/2
scriptletの実行中: epel-release-7-13.noarch 2/2
検証 : epel-release-8-11.el8.noarch 1/2
検証 : epel-release-7-13.noarch 2/2
アップグレード済み:
epel-release-8-11.el8.noarch
完了しました!
後始末
後は、細かい点を1つ1つ対応していきます。
依存関係の問題 (Perl)
エラーログがこちら。
# dnf check --dependencies
モジュラーの依存に関する問題:
問題 1: conflicting requests
- nothing provides module(perl:5.26) needed by module perl-DBD-MySQL:4.046:8010020191114030811:073fa5fe-0.x86_64
問題 2: conflicting requests
- nothing provides module(perl:5.26) needed by module perl-DBI:1.641:8010020191113222731:16b3ab4d-0.x86_64
問題 3: conflicting requests
- nothing provides module(perl:5.26) needed by module perl-IO-Socket-SSL:2.066:8030020201222215140:1e4bbb35-0.x86_64
問題 4: conflicting requests
- nothing provides module(perl:5.26) needed by module perl-libwww-perl:6.34:8030020201223164340:b967a9a2-0.x86_64
解決方法はこちら。
# dnf module enable -y perl
メタデータの期限切れの最終確認: 0:07:04 時間前の 2021年06月29日 04時15分22秒 に実施しました。
依存関係が解決しました。
==========================================================================================================================================================
パッケージ アーキテクチャー バージョン リポジトリー サイズ
==========================================================================================================================================================
モジュールストリームの有効化中:
perl 5.26
トランザクションの概要
==========================================================================================================================================================
完了しました!
Apache、PHP、MariaDB のインストール
以前は PHP 7.2 のインストールに IUS を使っていましたが、今回は Remi に変更。その他、インストールするパッケージは以下の通り。
- Apache 2.4
- MariaDB 10.3
- PHP 7.3 (Remi)
- Certbot
コマンドだけ以下に記載。
sudo dnf install mariadb-server
sudo dnf install httpd mod-ssl
sudo dnf install -y https://rpms.remirepo.net/enterprise/remi-release-8.rpm
sudo dnf module enable php:remi-7.3 -y
sudo dnf install php php-cli php-common
sudo dnf install php-mysql php-zip php-gd php-intl
# Certbot を snap でインストール
sudo yum install snapd
sudo service snapd start
sudo snap install core; sudo snap refresh core
# → エラー
sudo systemctl enable --now snapd.socket
sudo ln -s /var/lib/snapd/snap /snap
sudo snap install core; sudo snap refresh core
# → 再度エラー
sudo shutdown -r now
sudo snap install core; sudo snap refresh core # 成功
sudo snap install --classic certbot
sudo ln -s /snap/bin/certbot /usr/bin/certbot
sudo certbot --apache
詳細なログは以下に記載しました。
まとめ
大変だったが、労力に見合うかは微妙
手順として書いてみるとそこまで大変では無いようにも見えますが、実際には4時間ちょいかかりました。
では、それ位の時間で、公式に推奨されている
- バックアップ
- mysqldump で DB のバックアップ
- scp でファイル（DB ダンプファイルを含む）をどっかに退避させる
- CentOS 8 を新規インストール
- 必要なソフトウェアのインストール・設定
- 設定・データの復元
- ファイル
- DB
といった作業が終わるかと言われると、ギリギリな気もします。
今回のサーバーは、CentOS 7 をインストールした後で、別途ソフトウェアのインストール・設定を行っているので、全部で4時間で終わらない可能性もあります。
RHEL 系はパッケージのバージョンが古い
今回のアップグレードで詰まったところは大抵パッケージ関連なので、システムのアップグレードの事まで考えると、システム構築の際には標準のパッケージだけで済むのであればそれが一番楽だという事を再認識しました。
そう考えると、ディストリビューション標準のパッケージだと PHP 等のバージョンが古いという欠点がある RHEL 系のディストリビューションは、頻繁にバージョンアップが行われるソフトウェアを使ったシステム構築には向かないと言えそうです。
その点でも、Ubuntu が人気となっているのも納得が出来ます。
OS のインストール・アップグレードの機会が減っているが、しばらくは必要そう
そもそも、最近はコンテナ技術が浸透してきているので、新規の Web 開発などでは OS を入れたりアップグレードすること自体が減ってきています。
とは言え、7〜8年位前のシステムを改修して使っている場合で、Linux 上で直接 Apache、nginx、MySQL などを動かしている場面も結構あると思いますので、こうした技術を知っているとあと5〜10年くらいは役に立ちそうです。
コメントを残す