CentOS 7 の自宅サーバーを消さずに AlmaLinux 9 へ

CentOS 7 のサポート切れが気になり続けていた自宅サーバーを、ディスクを消さずに AlmaLinux 9 まで上げた記録です。
クリーンインストールではなく ELevate（Leapp）によるインプレース上書きで、上げたあとに壊れたもの・要らなくなったものを直すところまで含みます。

ハードウェア

長く使ってきた構成そのものなので、スペックは書いておきます。

CPU: Intel Core i5-2400S（Sandy Bridge 世代）
メモリ: 4GB
ストレージ: SSD 480GB（ルート約 50GB + /home 約 392GB）
NIC: オンボード Gigabit Ethernet

「EOL 後も動いているが、上げるのが怖い 1 台」の典型、という感じです。

方針

いきなり OS を上げない
Web・メールなどは先に別の自宅サーバーへ寄せ、障害時の影響を小さくする。
到達版は AlmaLinux 9
公式どおり一度に飛ばせないので
CentOS 7 → AlmaLinux 8 → AlmaLinux 9 の二段。
（AlmaLinux 10 までは今回やらない）
上書き後の役割は絞る
残すのは基盤＋LAN DNS（Unbound）＋Samba。旧 Web / DB / メールは止める。
上げたあとが本番の一部
監視・PHP・管理 UI・メール通知・不要アプリの掃除まで含めて一区切りにする。

参考:

flowchart LR
  migrate[役割を他ホストへ] --> el8[ELevate 7→8]
  el8 --> el9[ELevate 8→9]
  el9 --> revive[必要なものを復活]
  revive --> cleanup[不要なものを削除]

上げる前にやったこと

自宅サーバーには、移行途中でもまだ色々残っていました。

Web / DB: httpd、PHP（Remi）、MariaDB、Redis、Memcached、Webmin
メール: Postfix、Dovecot
共有 / DNS: Samba、Unbound
監視: MRTG、snmpd、PCP
その他: Docker 系、FDclone、Nextcloud など

メールは別ホストに Dovecot + LAN 向け Postfix を新設し、Web も寄せました。
AWStats は移行後に古い UID 所有のまま残っていて更新に失敗していたので、Web サーバ実行ユーザーへ所有者を戻して復旧。「移したつもりでも、権限で静かに壊れる」典型例です。

DNS は、作業中に名前解決が死なないよう、クライアント側の参照先をあらかじめ薄くしておきました。
コンソール手段（物理ディスプレイ／KVM など）の確保も重要です。Leapp 再起動後は SSH が長時間落ちます。

上げる直前には、不要サービス停止、第三者リポジトリの disable、CentOS 公式 repo 終了に伴う C7 mirror 切替、yum upgrade と再起動、PermitRootLogin yes などを実施しました。

Leapp の衝突回避のため、この段階では Webmin や Remi 系パッケージも外しています（あとで戻す前提）。

Phase 1 -- CentOS 7 → AlmaLinux 8

概略は公式どおりです。

yum install -y http://repo.almalinux.org/elevate/elevate-release-latest-el$(rpm --eval %rhel).noarch.rpm
yum install -y leapp-upgrade leapp-data-almalinux

rmmod pata_acpi
leapp answer --section remove_pam_pkcs11_module_check.confirm=True

leapp preupgrade
# /var/log/leapp/leapp-report.txt を読んで inhibitors を解消
leapp upgrade
reboot

つまずきどころ

1. answerfile 未回答 remove_pam_pkcs11_module_check.confirm=True を入れないと inhibitor で止まります。

2. Remi の libzip5 衝突

file /usr/lib64/libzip.so.5 from install of libzip-... conflicts with
file from package libzip5-...el7.remi

Web 本体はすでに他ホストへ移していたので、Remi PHP スタック・MariaDB 公式・Webmin などを削除して再実行しました。
サードパーティ RPM は Leapp 最大の敵、という印象が強いです。

3. 古い CPU についての注意
レポートには Sandy Bridge 世代が「RHEL 8 ではメンテ対象外」といった旨も出ます。
今回は警告止まりで通過できましたが、ハードが古いことは頭に置いておく必要があります。

成功後:

OS: AlmaLinux 8.10
ネットワーク設定は維持
Unbound / Samba / SSH: 稼働

Phase 2 -- AlmaLinux 8 → AlmaLinux 9

「次のホップ」前に、Leapp が残した exclude を掃除します。

sed -i '/^exclude=/d' /etc/yum.conf /etc/dnf/dnf.conf
dnf remove -y leapp leapp-upgrade-el7toel8 python2-leapp snactor
dnf install -y leapp-upgrade leapp-data-almalinux

sed -i 's/^AllowZoneDrifting=.*/AllowZoneDrifting=no/' /etc/firewalld/firewalld.conf
leapp answer --section check_vdo.confirm=True

leapp preupgrade
leapp upgrade
reboot

到達:

OS: AlmaLinux 9.8
kernel: 5.14.x.el9

Phase 3 -- 上書き直後の役割固定

OS が上がっても、旧スタックを全部生かし続けないのがポイントです。

残す予定	理由
SSH / firewalld / chronyd	基盤
Unbound	LAN DNS
Samba	共有がまだこのホスト前提のとき

いったん止める	理由
httpd / 旧 PHP	本体は他ホスト寄り
Dovecot / Postfix	メールは他ホスト
MariaDB / Redis / Memcached	依存アプリが無ければ不要
Webmin / PCP	必須ではない（後で要否を見直す）

Unbound が起動しない

AlmaLinux 9 直後、Unbound が chroot 配下で sd_notify に失敗して起動できませんでした。 chroot を空にしてログパスを直し、復旧。
「OS は上がったのに DNS だけ死んでいる」状態なので、受け入れ試験で最初に見ると安心です。

ここで一区切り、と思いきや、実際には「やっぱり要るもの」が続いて出てきました。

Phase 4 -- 事後処理

上書きそのものより、上げたあとに何を戻し、何を捨てるかの方が生活に効きます。

4-1. Webmin / FDclone を戻す

衝突回避で外していたもののうち、運用で必要なものはあとから戻しました。

Webmin
公式リポジトリを入れ直し、dnf install webmin で導入。
FDclone
AlmaLinux 9 / EPEL には dnf パッケージが無い。 /root/work を作業場にしてソースを取得・ビルドし、/usr/local/bin/fd を入れ直した。
（古いバイナリは libncurses.so.5 不足で動かなかったため、ncurses 6 向けに再ビルド）

4-2. MRTG を復活させる

MRTG 本体とグラフ用ディレクトリ、5 分ごとの cron は残っていました。壊れていたのは取得経路です。

ELevate 時に net-snmp / snmpd が消えていた
httpd も止まっていたので Web 公開も死んでいた
firewalld に snmp が無く、LAN からの SNMP も不通

対応:

net-snmp 再導入、旧 snmpd.conf を復元
firewalld に snmp を追加
httpd を再有効化（MRTG 用 vhost）
mrtg を手動実行してグラフ更新を確認

これで NIC / CPU / メモリ / ディスク / 温度 / Unbound / speedtest 系のページが再び見えるようになりました。

4-3. PHP が動かない

Remi PHP を消したまま、AlmaLinux 9 側に PHP が入っていませんでした。
httpd は mpm_event + proxy_fcgi なので、mod_php ではなく php-fpm が本筋です。

dnf module enable php:8.2
dnf install php php-cli php-fpm php-mbstring php-xml php-gd php-mysqlnd ...
systemctl enable --now php-fpm
systemctl reload httpd

PukiWiki など既存の PHP サイトが、再び X-Powered-By: PHP/8.2.x で応答するようになりました。

4-4. logwatch は動いていたが、届いていなかった

cron.daily の logwatch 自体は動いていました。
ただし Postfix が消えていたため、メールが送れない状態でした。

対応:

Postfix を再導入
relayhost を別ホストのメール受信側へ（IPv4 固定）
宛先は従来どおり運用用アドレス
テスト送信と logwatch 手動実行で status=sent を確認

4-5. 自動アップデートを入れる

AlmaLinux 9 では dnf-automatic が使えます。

項目	設定
タイマー	`dnf-automatic-install.timer`
適用	`apply_updates = yes`
通知	メール

毎日早朝帯（ランダム遅延つき）に更新が入る想定です。
「上げたはいいが、その後のパッチ運用が口伝」になりがちなのを防ぐ意味が大きいです。

4-6. `crontab -e` が壊れる（vim-minimal 問題）

crontab -e が /usr/bin/vi（vim-minimal）を開き、フル Vim 用の runtime（vim82）を読んで E319 連発、という状態になりました。

vim-enhanced は入っているので、既定エディタを vim にすれば解消します。

export EDITOR=vim
export VISUAL=vim
crontab -e

EDITOR は crontab 専用設定ではなく、エディタを開くツール全般向けの環境変数です。

4-7. 使っていないものを削る

上げたあと「止めたまま」「残骸のまま」を棚卸ししました。

削除したものの例:

PCP 一式（無効化したまま残っていた）
memcached
ELevate / Leapp 残骸
httpd-devel / php-ldap（導入時のおまけ・開発用）

補足: PCP 依存で sysstat も一緒に消えました。sar が必要なら別途戻します。

4-8. Nextcloud 残骸の撤去

昔運用していた Nextcloud の残骸が、かなり残っていました。

削除したもの:

アプリ本体（DocumentRoot 配下）
MySQL データディレクトリのうち Nextcloud スキーマだけ
Apache の cloud 用 vhost / 古い Alias 設定
ownCloud リポジトリ残骸
当該ホスト名の Let's Encrypt 証明書
古い ownCloud バックアップディレクトリ

movabletype や他スキーマの MySQL データ、phpMyAdmin 本体などは、まだ触っていません。
「OS を上げる」と「アプリを捨てる」は別作業ですが、上げた直後に棚卸しすると決断しやすいです。

実際の所要時間（ログから）

作業ログと Leapp / journal の差分から復元した 経過時間です。
マシンは上記の i5-2400S / 4GB / SSD です。

CentOS 7 → AlmaLinux 8

工程	経過時間
`leapp preupgrade`（回答修正後の成功回）	約 4 分
衝突パッケージ削除後の `preupgrade` 再実行	約 8 分
1 回目の `leapp upgrade`（`libzip5` 衝突で失敗）	約 15 分
Remi / MariaDB 公式などの削除	約 1 分
2 回目の `leapp upgrade`（再起動前まで成功）	約 10 分
再起動〜AlmaLinux 8 で SSH 復帰	約 15 分

失敗込みで、ELevate 着手〜Alma 8 復帰までだいたい 70 分前後。
うまくいったパスだけなら、成功した upgrade + 再起動で 約 25 分、その前のきれいな preupgrade を足しても 30〜40 分程度です。

AlmaLinux 8 → AlmaLinux 9

工程	経過時間
`leapp preupgrade`	約 3 分
`leapp upgrade`（再起動前まで）	約 12 分
再起動〜AlmaLinux 9 で SSH 復帰	約 14 分

8→9 は阻害が少なく、着手〜SSH 復帰までだいたい 35 分でした。

事後処理

こちらは阻害要因というより「棚卸しと復元」なので、実作業としてはだいたい 1〜2 時間見ておくと安心です。

見方	経過時間
成功パスだけ（7→8 + 8→9 の upgrade/再起動中心）	約 1 時間
7→8 の失敗リトライ込み	約 1 時間 45 分前後
当日の ELevate 作業の壁時計（待ち時間含む）	約 3 時間 40 分
その後の復活・掃除まで含めた体感	半日枠

壁時計が長い理由は、7→8 の衝突リトライに加え、Alma 8 到達から 8→9 着手までに空きがあったためです。マシンがずっとパッケージ変換していたわけではありません。

いまの姿

項目	状態
OS	AlmaLinux 9.8
ハード	i5-2400S / 4GB / SSD 480GB のまま
基盤	SSH / firewalld / chronyd
DNS / 共有	Unbound / Samba
監視	MRTG + snmpd + httpd
PHP	8.2 + php-fpm
管理	Webmin / FDclone
通知	Postfix（リレー）+ logwatch + dnf-automatic
捨てたもの	PCP、memcached、Leapp 残骸、Nextcloud 一式など

役割は「何でも屋」から、「共有・DNS・監視・必要最小の Web」へ寄った形です。

学び

上書きの成否は、サードパーティ RPM でほぼ決まる
Remi / 独自 MariaDB / Webmin は先に外すか、依存を切っておく。必要ならあとで戻す。
Leapp は preupgrade のレポートが本番
inhibitor を残したまま upgrade しても無駄撃ちになりやすい。
DNS とコンソールは保険
SSH だけだと、再起動後の長い沈黙で焦る。
先に役割を移すと、削除が怖くなくなる
Web/メールを他へ寄せてから Remi/MariaDB を消したので、衝突解消が現実的だった。
上がったあとが本番の一部
Unbound、MRTG、PHP、logwatch、自動更新、不要アプリの撤去まで含めて一仕事。
「止めた」と「消した」は違う
サービスを止めてもパッケージやデータ、vhost、証明書が残る。Nextcloud がその典型だった。
FDclone のような手元ツールは dnf に無いことがある
EL9 ではソースビルド前提で、作業ディレクトリを決めておくと楽。
vim-minimal と vim-enhanced の罠 crontab -e が vi を掴むと、上がった直後の小さなストレスになる。

まとめ

古い 1 台を捨てずに AlmaLinux 9 へ延命できました。
ただし成功の実感は、cat /etc/os-release が Alma になった瞬間ではなく、

グラフが見える
PHP が動く
ログメールが届く
自動更新が回る
使っていない雲の残骸が消える

あたりまで来てからでした。

同じ構成の人は、第三者リポジトリの棚卸しと、上げた翌日の事後処理リストだけは、どうか手を抜かないでください。