kusanagi migrateしようとWEXALを削除したらNginxすら立ち上がらなくなって地獄を見た

KUSANAGI8から9への移行がようやく終わりました。
地獄を見ました。
KUSANAGIでサイトを作って以来の地獄を見ました。

以下、その顛末を記します。

最初に記しておきます。

理由は人災の複合なので恐らく他の方の参考にはなりません
むしろ笑い話としてお読みいただければ……

天満川鈴 WRITTEN BY 天満川鈴

地獄を見る前の状況説明

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の適用完了。
移行作業完了しました。

原因

一言で、

人災の複合です

原因の1つは、恐らくこのコマンドを忘れていたせい。

# 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環境で移行するときはくれぐれも御注意ください

天満川 鈴のプロフィール画像
WRITTEN BY

天満川 鈴

未経験からWEB業界に入り、現在はWEBディレクターとして実務に従事。 要件整理・導線設計・コンテンツ構成などを学びながら、日々改善を重ねています。 AIを活用したコンテンツ制作・効率化を強みとし、プロンプト設計を含めた制作フローの最適化にも取り組んでいます。
本サイトでは、WordPressやサイト制作に関する試行錯誤・検証内容を中心に発信。 技術検証の一環として、KUSANAGI公式サイトにて記事を2回紹介いただきました。

RECOMMENDED INFRASTRUCTURE

私はConoHa以外を勧めない。

2016年からずっとConoHaを使い倒してきました。知人に「一番いいサーバーは?」と聞かれたら、迷わずここを教えます。

レンタルサーバーナンバーワンを誇る高速環境であることはもちろん。私が「黒い画面って何?」というド素人からサイト制作のプロになれたのは、傍らにずっとこのはちゃんがいてくれたから。

私がConoHaを使い続ける、嘘偽りない理由です。

公式サイトで詳細を見る
× 閉じる