01発端：OpenSSL更新でvsftpdに再びログインできなくなった
⑨でひと通り動作確認まで終えていたvsftpdだったが、⑭MongoDBの作業中（PECL拡張用にlibssl-devを導入した際、依存関係でOpenSSL本体がセキュリティパッチ版に更新された）を境に、FileZilla・スマホアプリともFTPSでログインできなくなる事態が発生した。
サーバー側のログでは`PASS`まで正常に処理され「OK LOGIN」まで到達しているにもかかわらず、クライアント側では直後に接続が切断される、という食い違った状態だった。 vsftpd再起動・TLS 1.3無効化・暗号スイートの絞り込み（この過程で一度、証明書が実はECDSA証明書だったのをRSA用と誤認し、状況を悪化させる対応をしてしまった）などを試したが解決せず、 localhostからの接続でも同じ現象が再現することから、ネットワーク経路ではなくvsftpd（2015年が最終リリース）とOpenSSL 3.5系の組み合わせ自体の非互換という結論に至った。
最終的に、既に確立していたSSH鍵認証の仕組みをそのまま使えるSFTPへ切り替えることで実務上の問題を解消し、vsftpd自体の追及は保留にした。 これが、後述するPure-FTPdへの乗り換え検討の直接のきっかけになった。
02FTPサーバー再検討の発端
SFTPへ切り替えて解決したはずだったが、実運用の中でスマホのFTPクライアントアプリ2種類を使い分けていることが判明。 片方（高機能、SFTP鍵認証対応）はファイルが不規則に0バイトでコピーされる現象があり、もう片方（シンプル機能、この現象は未発生）はSFTP非対応でFTPSのみ対応、という状況だった。 SFTPを主運用としつつ、アプリ都合のフェールオーバーとしてFTPも検討することになった。
平文FTPも選択肢に上がったが、シンプルアプリがFTPS対応と判明したため、Pure-FTPdへの乗り換えで進める方針に。 既存のLet's Encrypt証明書、ufw・ConoHaセキュリティグループの設定（ポート21・パッシブレンジxxxxx-xxxxx）をそのまま流用できる見込み。 vsftpdとポートが競合するため、切り替え時はアンインストールしてから試す必要がある点を確認した。
実装は本題の移設シリーズから外れる発展的な話のため、SFTPが主運用として機能している間に、時間のある時に試す方針とし、今回は検討の経緯を記録するところまでとした。
03Let's Encrypt自動更新への切り替え
④で手動DNS-01チャレンジを選んだ理由（DNS未切替・サイト移行未完了）は解消されたため、通常のHTTP-01（webroot方式）へ切り替えた。
VirtualHostを自動書き換えする--apacheプラグインではなく、既存の作り込み（PHP-FPMソケット、mod_wsgiのProxyPass、.html内PHP実行の個別設定等）に触れないwebroot方式を選択。
つまずき①：mail.gwaw.jpの404
gwaw.jpのwebrootチャレンジで、mail.gwaw.jp分だけ404エラー。原因は、mail.gwaw.jpがメールサーバーのホスト名であって対応するWebサイト（VirtualHost）が存在しないことだった。
新規サイトを作る必要はなく、既存のgwaw.jp（80番）のVirtualHostにServerAliasとしてmail.gwaw.jpを追加するだけで解決した。
つまずき②：「キープ」か「リプレース」か
本番実行時、既存証明書を「キープ」するか「リプレース」するか尋ねられる。今回の目的は証明書の中身ではなく次回以降の自動更新方法（手動DNS-01→webroot）を切り替えることなので、「リプレース」を選ぶ必要があった。
/etc/letsencrypt/renewal/各ドメイン.confに記録される。「キープ」だとwebrootでの実行が事実上スキップされ、この設定ファイルが書き換わらない可能性があった。次回の自動更新で相変わらず手動DNS-01を試みて失敗する、という結果になりかねなかった。
つまずき③：CAA再チェックエラーとステージング環境の不調
appw.jpで「Rechecking CAA for "www.appw.jp"...failed」が発生。CAAレコード自体は未設定（誰でも発行可のはず）で、時間を置いて再試行したところ成功した。一時的な通信の不具合だったと考えられる。
続けてcertbot renew --dry-runが5サイトとも「Secondary validation RPC failed」で失敗。Let's Encryptコミュニティフォーラムで同一のエラーメッセージの実例を複数確認したところ、Let's Encrypt社員自身が「現在ステージング環境で問題が発生しており対応中」と回答している事例が見つかった。
本番の証明書発行自体は直前に正常完了していたこともあり、こちら側の設定ではなくLet's Encrypt側のステージング環境（--dry-run専用のインフラ）の一時的な不調と判断し、時間を置いての再確認とした。
自動更新タイマーの確認
--dry-runで最終確認する運びとした。
04移設全体を振り返って
ログイン時のメッセージで、ディスク使用量が旧サーバーの85.2%から新サーバーでは38.7%まで大きく減少していることを確認した。 Anacondaを持ち込まなかったこと、torchのGPU関連パッケージを除外したこと、gensim・MeCab辞書を必要な範囲だけにしたことなど、今回の見直し作業の成果がそのまま数字に表れた形になった。
空いた時間を使って6日間での完走。前回（2021年）からの記憶違いもいくつかあったが、SSLプロトコルの脆弱性、SPF/DKIMが丸ごと欠けていた3ドメイン、Dovecot 2.4の全面刷新、vsftpdとOpenSSLの相性問題、Node.js側で削除されたAPIなど、実際に手を動かさなければ見えてこなかった発見が数多くあった。 Ubuntu LTSの2年ごとのアップグレードサイクルに合わせて今後も移行していく上で、今回の記録がそのまま次回の見通しに繋がるはずである。
