KUSANAGI8から9への移行がようやく終わりました。
地獄を見ました。
KUSANAGIでサイトを作って以来の地獄を見ました。
以下、その顛末を記します。
最初に記しておきます。
理由は人災の複合なので、そのまま他の方の参考になるケースは少ないかもしれません
ただ、WEXAL・SSL・DNSまわりでハマった記録として残しておきます。
地獄を見る前の状況説明
KUSANAGI8から9へ移行作業を始めました。
まずWEXALを実行していないサイト。
次いで同じくWEXALを実行していない、既に閉鎖していたサイト（本サイトのことです）。
さらにテストサーバー。
途中ブチはまりはしたものの、ここまでは順調でした。
新サーバーの設定を全て終え、残すは親サイトの移行。
親サイトを最後まで残していたのは、新サーバーの設定確認のためです。
やり残しがあったらまずいですから。
説明に従ってまずはWEXALをオフ。
# pst off
続けてWEXALの適用除外。
# pst remove
できない！ どうして！
当然、migrateコマンドを実行してもできません。
WEXALを解除する際には以前もトラブルがありました。
でもその後にアンインストールした時はうまくいったはずだし。
以前のトラブルのときは手動で.confファイルをWEXALの適用前のものに戻したら動いたはず。
WEXAL2と3でバージョン違うけど原理的には同じだろうし、やってみよう。
.conf.before.pst→.confに書き換えてNginx再起動。
# kusanagi nginx
nginxが再起動に失敗!?
青ざめました。
悪夢の始まりです。
思いつく限り調べた限りの対処をしてみる
とりあえずKUSANAGI premiumをアンインストールしてmigrate。
やっぱりPST適用のままじゃダメと出ます。
というか再起動しようとして、
どうしてサブドメインサイトのSSLがないって問題になるの？
出ていたメッセージは「https://wordpress.kimoota.net/～（略）」。
WEXAL適用してないどころか、閉鎖して301リダイレクト状態だったのに。
自動更新も移行する際に完全に停止したから問題ないはず。
幸い、バックアップファイルは揃っています。
移行する予定のサイトですから新サイトに手動で移して構築してもいいんですけど。
その場合はメディアライブラリの登録し直しなど面倒な作業が待っています。
できれば最終手段にしたい。
そもそもNginxが死んでる時点で異常です。
もちろんApacheも立ち上がりません。
幸いOSは生きているわけですからコマンドは打てます。
ファイルの書換えもできます。
私の浅い知識で思いつく限り。
調べながら片っ端からコマンドを打ち込みました。
……が、無理でした。
渋々新サーバーに手作業で移行することにしました。
www.kimoota.netのSSLが設定できない！
旧サーバーのIPアドレスに接続できないからとかなんとか。
しかたないので泣く泣く続行。
SSL回りに問題が起きているのは間違いないのでSSL関係のフォルダをローカルにバックアップ。
息抜き代わりに記事の更新しながら5日くらい悪戦苦闘しました。
この時点で激しい後悔に襲われます。
どうして私はVPS丸ごとバックアップしてから作業しなかったんだ
皆様は決してお忘れなきよう……。
格闘の果てに。
やけくそで親サイトのSSLの鍵ファイルを他のサイト全てに貼りつけてみました。
Nginx動いた！
やっと……やっとだよ。
私、トラブルシューティングでこれ程まで嬉しかったことありません。
これ程までに手こずったこともありませんけど。
SSLを復旧～migrateコマンドの実行成功
しかしこの状況でもなお、kusanagi migrateは実行できません。
環境を完全に元に戻す必要があります。
現在はhttpでもアクセスできる状況でSSLの301リダイレクトは飛んだ状況。
kusanagi ssl コマンドを実行してみます。
failedが出た！
kimoota.netのIPにアクセスできないと出ます。
新サーバーと同じ状況。
いったいどうすればいいんだ！
とりあえず旧サーバーはシャットダウン。
ここで休憩を数時間とりました。
そして頭を休めたのがよかったか、気づきます。
新サーバーと旧サーバーでエラーメッセージは同じじゃない！
新サーバーはwww.kimoota.netで旧サーバーはkimoota.netじゃなかった？
もしかして……案の定でした。
DNS設定が@とwwwで別々になってます。
他のサーバーではwwwを使ってないので気づかなかったのですが。
新サーバーでSSLを取得する際にwwwのIPアドレス変更を忘れていました。
しかしKUSANAGIはwwwも同時にSSLを取得しにいくのでエラーが出ていたわけです。
マスターの、完全なる人災です……
でも気づいてしまえば何の事はありません。
DNSでIPアドレスを揃えて再びkusanagi sslコマンド。
無事に復旧できました。
後はkusanagi premiumを再インストール。
pst initして、恐る恐る……
# pst remove
できた！
kusanagi migrateを実行。
新サーバーでkusanagi init→import。
今度はDNS設定も忘れずに両方とも変更した後、sslコマンドを実行。
各種設定後にWEXALの適用完了。
移行作業完了しました。
原因
原因を一言で言えば、人災の複合です。
- pst watch off を忘れていた可能性
- certbot delete –cert-name ドメイン の実行タイミングがまずかった可能性
- @ と www のDNS設定が揃っていなかったこと
特に最後のDNS設定忘れは、完全に人災でした。
原因の１つは、恐らくこのコマンドを忘れていたせい。
# pst watch off
removeできなかったのはこのためじゃないかと思います。
（復旧した後は確かinit直後にremoveを実行したので影響がなかったのでは？）
WEXALの起動はpst on だけで足りるのですが。
終了するときはpst offに加えてwatchもoffにしないといけないのを忘れていました。
WEXALを一旦起動して完全停止することは普通ありませんし。
ただ、Nginxが起動しなくなった直接の原因でもないような気がします。
本サイトは旧サーバーでWEXALを適用していませんでしたし、自動更新も止めていました。
新サーバーにも移行済みでしたし、基本的には関係ないはず。
どうして認証できないと怒られるのか。
もしかしたら、これがいけなかったのかもしれません。
# certbot delete --cert-name ドメイン
SSL証明書をファイルごと削除してしまうものでmigrateの後に実行するようメッセージが出ます。
しかしサイトを全て移転するまでは実行してはいけなかったのかも。
あるいはWEXALが半端に削除されてしまったのとあわせて問題が起きたのか。
ここはもう本当に推測です。
そしてドメインのDNS設定忘れ。
これは完全に人災です。
まとめ
とにかく最終的には移行できてよかったです。
SSL回りについても勉強できましたし。
そう思わないとやってられないのが本音ですけどね！
他の方はこんなミスしないと思いますが。
WEXAL環境で kusanagi migrate を使う場合は、pst の状態、SSL証明書、そして @ と www のDNS設定を先に確認しておくと安心です。
……と、地獄を見た私としては言っておきます♪
VPSは、もう「黒い画面」だけじゃない。
「VPSは難しそう」と諦めていませんか？ ConoHaのKUSANAGIなら、ブラウザ上の管理画面（KUSANAGI Manager）で、ドメイン設定からSSL発行まで直感的に操作可能です。
コマンド操作なしで世界最速級の環境を構築できる、今の時代の初心者にとっての最適解。私が長年愛用している理由がここにあります。
※当サイト経由で新規申し込みいただくと、特典として1000円分のクーポンをもらえます。