巷を大騒ぎさせたPHPセキュリティ問題、多分に漏れずこのサーバーでもPHPが古いバージョンだったため、急遽対応を余儀なくされた。そこで、前々から考えていたラズパイを利用したサービス単位のマイクロサーバーのクラスター構成へと移行することにし、ラズパイのDebian Trixie上に最新のPHPを含むLAMP環境を構築し、その上にWordPress環境を再構築して旧サーバーのコンテンツをインポートした。
問題なく再構築できたと確信したので、外部公開するサーバーを変更することにした。といってもルーターでPort 80の静的NATの振り向け先を旧サーバーから新サーバーに変更するだけなのだが。実際、外部からアクセスしても何の問題もなく表示されるので無事サーバーの更新は完了したと思ったのだが、WordPressのメジャーバージョンが上がった時に行わなくてはならないサイトネットワークのアップグレード操作がConnection timed outのエラーを表示して失敗してしまうことが判明した。
ネットでConnection timed outのエラーが出たときの対処方法を調べると、PHPの割り当てメモリを増やすだとかPHPの実行時のTimeout時間を増やすといった対処法が出てくるが、実際に設定してみても最初のサイトのデータベースを更新しようとしたタイミングで相変わらず同じエラーで失敗する。どうやらこのエラーはPHPの実行が遅すぎて起きているわけではないらしい。
と、そこでこの環境の特殊性からピンときた。WordPressはもともとFQDNで直接アクセスできる環境であることを前提に設計されており、WordPressの表示される内容の応答もすべてFQDNを含むURLでしか返ってこない。そのため、FQDNからリゾルブされるIPアドレスが直接インターフェースに割り当てられている環境なら何の問題もないのだが、NAT内にサーバーを設置するような環境ではNAT内のアクセスではhosts等でFQDNからNAT内のプライベートアドレスにリゾルブされるようにしておかないとうまく表示できない。もし、サイトネットワークのアップグレードのルーチンがFQDNを使ってWordPress内の別のルーチンを叩いていたとしたら、そりゃリゾルブしたアドレスには直接接続できないのでうまくいかないよな。
というわけで、新サーバーのhostsファイルにFQDNに対して127.0.0.1を返すように設定する。これでもしWordPress内のルーチンがFQDNで他のルーチンを呼び出そうとした時もちゃんとlocalhostに接続してくれるようになるはずだ。
で、実際この状態でサイトネットワークのアップグレードを実行してみると、すんなりとすべてのサイトのアップグレードが完了した。やはり原因はFQDNでローカルにアクセスできない問題であった。
というわけでWordPressを運用しているサーバーがFQDNからリゾルブされるIPアドレスを割り当てられていない場合は、FQDNをリゾルブすると127.0.0.1が返ってくるようにhostsファイルを設定しようという教訓でした。