Debian 9 Stretchで運用してきたこのサーバーをまだ当分この状態で運用したいので、この機会にDebian 10 Busterにアップグレードすることにした。
まずはDebian 9 Stretchにアップグレードした時に放置していたネットワークインターフェースの名称変更を実施。Debian 8までは伝統的なeth*というインターフェース名が使われていたが、10ではこれがデバイスのハードウェア的な接続場所に応じた固定的な名前しか使えなくなる。だから、移行措置期間の9のうちにインターフェース名を変えておく必要がある。
公式のリリースノートに従って新しい名前を調べ、/etc/network/interfacesにあるインターフェース名を変更し、新しい名前を有効にしてinitramfsを再構築させたが、実際は起動したら全然違うインターフェース名だった。どうやらUSB接続されているインターフェースの命名規則はMACアドレスを使う命名法になるので、リリースノートの手順では正しい名前が得られないらしい。というわけで、冷静に/sbin/ifconfig -aで新しいインターフェース名を一覧から取得し、これで設定しなおして無事にインターフェース名の変更が終了。
あとはパッケージリポジトリをStretchからBusterに変更してインストール済みパッケージをroot権限になって更新する。
apt update
apt-get upgrade
apt full-upgrade
途中、コンソールのLANGをen_US.UTF-8に戻しておくのを忘れてコンソールのメッセージが全く読めなくて焦ったが、9から10へのアップグレードは予想以上に何も聞いてこなかったので助かった。エラーもなく全パッケージのアップデートが完了したので再起動。最初、ネットワークインターフェースが上がらなくて起動しないトラブルが起きたが、一度電源を切ってから再起動したら問題なく起動したので良しとする。
バージョンが確かに10に上がってることを確認したのちに、サーバーのサービスがちゃんと動いているか調べたところ、WordPressだけが正しく動いていなかった。調べてみると、php7.0とphp7.3が重複インストールされた状態になっていたので、php7.0をアンインストール。それにともなってapache2のphp7.3モジュールがアンロードされた状態になっていたので、a2enmodコマンドで明示的に有効化。これで大丈夫と思ったらアクセスしても何も表示されなくて焦ったが、単にブラウザのキャッシュの問題だったので、リロードしたら無事に表示された。
最後にobsoleteになったパッケージを以下のコマンドでチェック。
aptitude search ‘~o’
ほとんどのパッケージが移行のためのダミーパッケージか、もっと新しいバージョンがすでにインストールされているかなので問題なく削除できるのだが、phpmyadminがobsoleteになってしまったのは困った。これは非常に多くのphpやmariaDBがらみのパッケージが依存関係で入っているので、普通にremoveするとおそらくWordPressに必要なパッケージまでautoremoveされてしまう。そこで、この記事を参照してBuster環境でWordPressを手動でインストールするときに推奨されているパッケージを手動でインストールして、パッケージをautoremoveされないように「手動でインストールしました」フラグを立てておいた。その後、phpadminが依存関係で自動的に入れた状態になっているパッケージをphpadminごとautoremoveで取り除いた。
で、その状態でもWordPressが正しく動いているのを確認できたので、無事にBusterにサーバーのアップグレードを完了。
唯一心残りだったのが、Debian 10に至っても内蔵のRTL8111Gのドライバがおかしくてネットワークが使えないことか。結局、USB2-Gigabitという情けないアダプターをこれからも使い続けることに。
Debian Busterにアップグレードしてからブートにやけに時間がかかるようになったなと思ってdmesgでどこに時間がかかってるのか確認したら、randomのエントロピープールの十分な確保に1分以上の時間がかかってることが判明。このエントロピープールはsshの安全性確保に必要なのでこれのおかげでsshdの起動がその分待たされている様だ。
しかし、この変更はDebianが安全性をきちんと担保するために必要だから行った変更なので、ここはぐっと毎回1分間余分に待つことにする。