Tips

KUSANAGIのバージョン8⇒9のアップデートが地獄だった件

  /

KUSANAGIのバージョンを8から9にアップデートしました。単にバージョンアップするだけなら簡単でしょ、って思っていたのですが、罠でした。非常に大掛かりな作業となってしまい、色々と悪い意味でハマることが多かったので、対処法ととも行ったことをご説明します。

元々はPHPをバージョンアップしたいだけだった

当初は単純にPHPを7.3から最新付近までアップデートしたかっただけでした。WordPressさんの管理画面でいつも「PHPが古い！」って怒られるんですよね。また、WordPressプラグインも最新版には7.3には対応しないものも増えてきました。

私はサーバーにConoha VPS（バージョン2）を使っていて、イメージには「かんたんKUSANAGI」を使っていました。どうやってPHPをアップデートすればいいのか全くわかりませんでした。下手にアップデートをしてサイトが壊れてしまうのを恐れていました。

あまり期待はせずConohaのサポートに聞いてみましたが、「内部のソフトウェアについては関知しないので、書籍やインターネットで調べてみてください」とのこと。

仕方ないので、調べていくと、「KUSANAGIのPHPのバージョンはどうやってアップデートするか」という観点で調べるべきな気がしてきました。

調べているうちに、自分のサーバーではKUSANAGI8系を使っており、それだとPHP8.1までしか対応しておらず、PHP8.3などのより最新版を使いたい場合はKUSANAGIの9系を使う必要があることがわかりました。

PHP8.1にして満足するという選択肢もありますが、今後のことを考えるとKUSANAGI自体をアップデートしておいたほうがいいという判断をしました。

KUSANAGI 8のPHP 8モジュールについて

VPSにログインして kusangi status を実行すれば、現状どのバージョンが動いているかわかります。

KUSANAGIは8.4.3-2、MariaDBは10.1.41ということがわかりました。PHPは7系ということはわかりますが、詳細なバージョンがこれだとわかりません。なので、コマンドラインで以下を実行します。

7.3.8のようです。

ただ、コマンドラインで使われるPHPとWEBサーバーが使うPHPが必ずしも同じと限らないので、もっと確実に調べるなら、WordPressのダッシュボードの「サイトヘルス」の「情報」から「サーバー」という項目にPHPのバージョンが表示されています。

私の場合はこちらでも7.3.8でした。

サーバーをゼロから構築し直す必要性

ただ、最初は舐めていました。KUSANAGIといえど、ソフトウェア一つアップデートするなんて大したことないだろうと。コマンド一つでできるだろうと。

しかし、そんなことはなく、サーバーをゼロから構築し直す必要があるようです。

kusanagi 8から9への移行方法（KUSANAGIユーザーフォーラム便り）

マイナーバージョンアップであれば yum update などでワンコマンドでアップデートできます。

KUSANAGI バージョンアップ情報 8.7.12-1

しかし、8系から9系などのメジャーバージョンアップはサーバーを構築し直す必要があるというのは、明らかにKUSANAGIのデメリットですよね。

ここで、今後もバージョンアップのたびにこんなことをすることになるなら、もうKUSANAGI卒業して、Conoha Wingかロリポップみたいな手間がかからない（はずの）レンタルサーバーに移行しようかなとも考えました。

とはいえ、コスト面を考えるとVPSの方がだいぶ安く済みます。また、これを乗り越えれば次からは２度目の作業になるので、そんなに時間はかからないはずだ、という希望的観測により、KUSANAGI 8から9へのアップデートをすることにしました。

ちなみに、このタイミングでConoha VPSのバージョンを2.0から3.0へも上げることにしました。どうせVPSを構築し直すなら良い機会だろうと考えたからです。それについては以下で詳しく説明しています。

Conoha VPSのバージョン2.0から3.0へ移行での落とし穴Conoha VPSのバージョンを2.0から3.0へ移行しました。KUSANAGIでWordPressサイトを運用する用途です。公式の手...

この記事は以降でも言及するので【Conoha VPSバージョン2⇒3移行記事】と呼びます。

移行データ作成用のVPSを作る

次の公式の記事を参考にしました。

kusanagi migrateコマンドによる移行手順

公式でない記事も読みましたが、基本は同じやり方でした。

簡単に言うと、KUSANAGI8の既存環境からデータをエクスポートし、それを新しく構築したKUSANAGI9の環境にインポートするという手順になります。 kusanagi migrate というkusanagi謹製の機能を使います。

ただ、移行元と移行先でPHPとMariaDBのバージョンを合わせる必要があります。これが厄介です。移行元でKUSANAGIのマイナーアップデートやそれらのソフトウェアのアップデートのために yum update を実施する必要があります。

yumというのはパッケージ管理システムです。MacでいうHomebrewもそうですが、パッケージ管理システムでソフトウェアをアップデートするのは慎重に行う必要があります。私はHomebrewで何度も開発環境が壊れるというトラブルにあってきました。

Homebrewの自動アップデートを止めよう!開発環境が壊れる前にMacのソフトウェアをHomebrewで管理していて起きる問題の、最も多い原因は自動アップデートによるものだと感じます。問題の事例とその...

本番環境が壊れてしまってサイトが見れなくなってしまっては損失が発生してしまいます。

なので、私は本番環境では移行データを作るのではなく、本番環境をコピーした環境を作って、そこで行う各種ソフトウェアのアップデートを行うことにしました。

幸いConoha VPSではVPSのスナップショットのイメージを簡単に保存でき、それを使って別のVPSを立ち上げることが簡単にできます。（他の会社のVPSもそうだと思いますが）

MariaDBのバージョンを何にそろえるか

作業に入る前に考えておく必要があるのが、移行元（KUSANAGI8）と移行先(KUSANAGI9)でPHPとMariaDBのバージョンを何に揃えるかということです。

結論は先ほど紹介した公式の記事の移行手順の通りなのですが、少し説明が少なかったので補足します。

より気をつける必要性が高いMariaDBについて先にお話しします。

そもそもなぜMariaDBのバージョンを揃える必要があるのでしょうか？移行元からエクスポートと言っても、どうせSQL文を出力するだけだと思うので、違うバージョンでもインポートできるでしょって思ってました。でも、試しにMariaDBからエクスポートしたファイルを開いてみてください（KUSANAGIのエクスポートじゃなくても良いので）。もちろんSQLもたくさん書かれているのですが、あまりみたことのないようなコードもたくさん書かれているんですよね。もしかしたら、この辺りがバージョンによって微妙に違っているのかもしれません。実際にバージョン違いできちんとインポートできなかった方の記事を見つけました。

【EC2】kusanagi8からkusanagi9へ移行する

それではどのバージョンに揃えるべきかをご説明していきます。

まずKUSANAGI8は以下のページによると、

upgrade mariadb {version} [--force]

  • 10.1
  • 10.3
  • 10.5

に対応しています。

それに対し、KUSANAGI9は以下ページによると、

upgrade mariadb

  • 10.3
  • 10.4
  • 10.5
  • 10.6
  • 10.7
  • 10.8
  • 10.9
  • 10.10
  • 10.11

に対応しているように見えます。

しかし、注意書きをよく読むと、10.7〜10.10はKUSANAGI9.4.6で廃止されており、10.3〜10.4はCentOS Stream 9/AlmaLinux OS 9では指定できません。

このように指定できなくなる理由は当該バージョンのMariaDB社によるサポートが終わるためのようです。サポートが終わると何が困るのか正確にはわかりませんが、不具合があった時のセキュリティパッチなどが出ないといったことのようです。個人的には不具合って直したらバージョンアップするんじゃないの？って思っていましたが、各バージョンの不具合はそのバージョンの中で対応してくれるということなのでしょうか。

またKUSANAGI側もMariaDB社のサポート状況に合わせて律儀に指定できなくしたりする必要あるのかよくわかりませんが、なるべく選択肢を減らした方が管理が楽なのかもしれませんね。

新しい環境を作るのに最新のOSを使わない理由はないので、私の場合、CentOS Stream 9になります。なので、実質指定できるMariaDBのバージョンは、

  • 10.5
  • 10.6
  • 10.11

となります。

なので、移行元と移行先をともに10.5に揃えるということになります。

PHPのバージョンを何に揃えるか

KUSANAGI8は以下の記事によると、

KUSANAGI 8のPHP 8モジュールについて

KUSANAGI バージョンアップ情報 8.7.0-1

  • 7.4
  • 8.1

が選べます。マニュアルによると5系も指定できるのですが、公式の記事が見当たりませんでした。おそらく5系の最新の5.6だと思います。

KUSANAGI8で厄介なのが、メジャーバージョンしか指定できないことです。（--php7、--php8、--php5というように）yumのリポジトリがどうなっているかによるということです。なので、yumの調整をしておけば、7.3や8.0も選べるのかもしれません。

KUSANAGI9では以下記事によると、マイナーバージョン番号まで指定でき、

php

  • 7.4
  • 8.0
  • 8.1
  • 8.2
  • 8.3

なので、KUSANAGI8とKUSANAGI9で共通するのは7.4、8.1になります。なので揃えるならこの２つのどちらかということになります。

ただ、MariaDBと違って、PHPについては、そこまで気にする必要はないかなと思います。移行元は7.4か8.1になっていた方がいいと思います。でも、移行先の方は移行先と同じかより新しければどれでも大丈夫だと考えています。というのは、PHPのファイルはMariaDBのファイルと違ってインポートできないということはないためです。もちろん、バージョン違いのための、不具合は発生する可能性はあります。しかし、移行先へ切り替えはドメインの付け替えにするのか、バーチャルIPの付け替えにするのかは環境によると思いますが、移行先にインポート後にすぐに切り替えるわけではありません。デバッグをしてから切り替えをすればいいのです。

それでは、実際の移行手順をご説明していきます。上でご紹介した公式記事を元にした kusanagi migrate というコマンドを使う方法（公式の方法）と、それを使わない方法（非公式の方法）の２種類をご紹介します。共通する部分があるので、それは基本的に前者で説明しており、後者では違う部分だけ説明しています。

公式記事を元にしたといっても、記事通りスムースにはいかずにつまづいた部分が多かったので、この記事で詳しく解決した方法やそれに至った考え方をご説明しています。

公式の方法（kusanagi migrateを使う方法）

移行元での作業

移行データ作成環境作成（本番環境のコピー）

お使いのサービスによってやり方は違うと思いますが、まるっとイメージを保存してそのイメージでVPSを構築することが大抵できるはずです。

Conoha VPSの場合は【Conoha VPSバージョン2⇒3移行記事】で詳しく説明しています。

ホストネーム変更

作成した移行データ作成環境にログインしたらまずホストネームを変更します。というのは、本番環境と同じホストネームになっており、コマンドラインのプロンプトに表示されるので、間違いが起きないように変更します。

以下で確認できます。

ただ、プロンプトに反映させるには、sshログインし直す必要があります。

SSLの更新は止めなくていいのか？

本番環境のコピー環境を作るにあたり、一つ心配がありました。SSLつまりLet's Encryptの更新の定期処理が走っているはずです。コピー環境でも動いてしまったら、本番環境の証明書はどうなるのだろうというのが心配でした。ドメイン切り替え前なので、おそらく失敗して終わりだろうと思うのですが、どんな仕組みになっているかわかりません。別のIPから更新のためのアクセスが走ったら本番環境の方の証明書の扱いはどうなってしまうのだろうと心配になってしまいます。仕組みを調べるのも面倒なので、コピー環境の方でSSLを止めてしまおうかと思いましたが、この処理も本番環境にどのような影響を与えるかよくわかりません。

仕組みを調べるのも面倒なので、定期処理はどのように行われているのかcronを見てみることにしました。

4行目がSSLの更新の処理ということがわかりました。このタイミングを示す 07 03 * * 0 に注目します。以下の記事によると、毎週日曜日の3:07に実行されているということがわかりました。Let'ts Encryptのログを見ても、その時間に処理が動いていました。

cron を使用した時間指定

なので、毎週日曜日の3:07にこのVPSをシャットダウンしておけば、処理は走ることはありません。この移行作業中にそこだけ注意しておけば大丈夫だと判断しました。

あと、IPでアクセスしてサイトを表示できる状態なので、検索エンジンに登録されてしまったら重複コンテンツとしてペナルティを受けてしまったら大変です。なので、作業をしていない時は、このVPSはシャットダウンしておく方が良いです。検索エンジンのクローラーを遮断する方法などもあるかもしれませんが、面倒なのでやめておきました。

yumの.repoファイルの情報が古いので更新

仕組みは全然わかってないのですが、yumが動くときに使われる.repoファイルの情報が古く、yum updateをそのままやるとエラーが起きてしまいます。

MariaDBとCentOSに関して発生しています。

なので、いろいろ調べたところ、それらの.repoファイルが古いのが原因でした。

MariaDBは元々はこんな感じでした。

これを以下のように修正します。念のためバックアップをとっておきましょう。

以下の記事を参考にしました。

http://yum.mariadb.org/10.1/centos7-amd64/repodata/repomd.xml: [Errno 14] HTTP Error 404 - Not Found

CentOSは元々はこんな感じでした。

これを以下のように修正します。念のためバックアップをとっておきましょう。とはいえ、そもそも私は本番環境のイメージからVPSを作成しているのでデータは本番環境にもイメージにも残っているので、そこまで心配する必要はないのですが。

以下の記事を参考にしました。

CentOS7：yumが使えなくなっているので、延命処置をしてみる

ようやくyum update

これで準備は整いました。念のため、MariaDBも更新されるのでバックアップはとっておいた方がいいかもしれません。

１行目は必要かどうかわかりませんが、多くの記事でやっていたのでやっておきます。

出力の表示は省略していますが、2行目の後にたくさん出力が表示されます。yesかnoかみたいな入力が求められたりしますが、yesで大丈夫です。完了まで５〜10分かかります。

KUSANAGIのバージョンが8.4.3-2から8.7.13-1に上がりました。

MariaDBのバージョンが10.1.48から10.1.41に上がりました。

PHPのバージョンは7.3.8から7.4.33に上がりました。

MariaDBを10.5にする

この作業の重要なのがMariaDBを10.5にすることです。

これを実行すると、2回yesかnoかを聞かれるプロンプトが表示されます。

これについてはyを押します。バックアップはとっている前提です。

これについてはよく意味がわからないので、数秒悩んでいると、何も入力しなくても進んでしまいました。何のためのプロンプトでしょうか。

とはいえ、数秒待っていると完了しました。

kusanagi status で確認するとMariaDBは10.5.26になっていました。

以下のSwitchHostを使うなどの方法で、このVPSのIPに当該ドメインであなたの端末から限定でアクセスできるようにし実験できます。動作に問題ないか確認してもいいかもしれません。

Macでhosts書き換えするならSwitchHostsがおすすめMacでWebの開発をしているとhostsの書き換えをする機会が多くなります。そこで便利なのがSwitchHostsです。(Window...

移行データをexportする

これでようやく移行データをexportできます。

生成されたproggy.jp-2024-11-12.tar.gzというファイルをFTPなどでダウンロードします。

移行先での作業

移行先VPSの状態確認

さてここから移行先のVPSでの作業です。

私の場合Conoha VPSのバージョン3.0でかんたんKUSANAGIというイメージでVPSを作成しました。このイメージで作成すると kusanagi init が済んだ状態で起動します。なので、私は kusanagi init をしていないのですが、皆さんはご自身の環境に合わせて行なってください。

このようなバージョンになっています。KUSANGIは9系になっていますね。MariaDBが10.5.27で、移行元は10.5.26だったので少しずれがあるのが気になります。ただ、移行元でいくら yum update しても10.5.27にはならないんですよね。ここは目を瞑ることにします。

ちなみに、現状PHPは7.4になっていますが、どの時点でも変更できます。まずは移行元に近い7.4で移行してみてというのもありですし、ここで執筆時点で最新の8.3にしてしまうのもありです。MariaDBと違ってPHPのバージョンは戻すことも簡単にできます。

移行データのインポート

先ほどダウンロードしておいたファイルをこちらのVPSにアップロードします。そして、以下でインポートします。

あっけなくインポートできてしまいます。

7、9行目から分かるように、SSL関連のファイルもこの移行データの中に含まれています。なので、httpsでアクセスできることになります。この時点ではドメインが切り替わっていませんが、先ほど紹介したSwitchHostを使うなどの方法で、このVPSのIPに当該ドメインであなたの端末から限定でアクセスできるように実験すると、httpsでアクセスできます。私もやってみたところアクセスできました。

Chromeですぐに切り替わらない場合は、以下を行います。

Chromeでhostsの変更が反映されない時の対処法hostsの書き換えをしてもChrome上で反映されないことがあり、その対処法がわかったのでご説明します。 chrome://net-...

この時点でhttpsでアクセスできるとはいえ、11行目で分かるように、 kusanagi ssl コマンドをドメインが切り替わった後に実行する必要があります。このコマンドによってSSLの認証のCRONが設定されると思われます。なぜ切り替わった後でないとダメかというと、Let's Encryptのサーバーからの認証のためのアクセスがドメインを使って行われるからです。

Let's Encrypt 動作の仕組み

KUSANAGIのmigrate機能でexportしたファイルにはSSL関連のファイルが含まれるのはとてもありがたいことだと思います。というのは、別の方法(WordPressのプラグインなど)でExportした場合などはSSLの関連ファイルが含まれていませんが、そうなると、ドメインが切り替わってから kusanagi sslを実行するまでの間、httpsでアクセスできないことになります。検索エンジンなどにはhttpsのURLで表示されるはずなので、そこからのアクセスを取り逃すことになります。その時間を最小限にするためには、切り替わったことをすぐに察知して kusanagi sslを実行する必要があります。しかし、ドメインの切り替え（DNSの浸透）にかかる時間は読めない部分があるので、その間ずっと自分で手動でアクセスしたりして確認しなければなりません。

SSL関連のファイルも別で移行する、という方法もあるかもしれませんが、どのファイルをどのように移行するべきかを考えたり、それがKUSANAGIの作法に適合しているかを確認するのも非常に骨が折れるでしょう。

ちなみに、コマンドライン作業中、以下のようなワーニングが表示されることがあります。これはPHP7.4が有効になっている時のみ起こるようで、あまり気にする必要がないようです。importした時、7.4に切り替えた時などに表示されます。他のバージョンが有効なときは表示されません。どうせ今後7.4を使っていくことはないはずなので、対応しないで良いと思います。

WordPressのログイン画面でBasic認証が求められる

SwitchHostで作業端末からだけドメインを切り替えた状態と仮定します。そこで、WordPressのログイン画面を開くとBasic認証が求められます。以下記事で詳細が説明されています。

KUSANAGI 9 バージョンアップ情報 9.6.0-1

ユーザーは kusanagi 、パスワードはkusanagiユーザーのものを入力すればログインできます。このパスワードはConoha VPSの場合、KUSANAGI Managerやsshログインした時に表示されます。

なお、WordPressのログイン画面で、セキュリティ系のプラグインのせいでログインできない場合があります。通常ログインしないと、プラグインって無効化できないので、悩みますよね。その場合は、以下のようにプラグインのディレクトリ名を変更して無効化してしまいます。

DBの値を変えることで無効化するのは難易度が高いそうです。

wp-config.phpの修正

インポートが完了したからといってもまだまだやることがあります。

管理画面からプラグインやテーマの追加、削除、編集などを行うと以下のような画面が表示されます。これはwp-config.phpで設定される FTP_PASS の値が間違っているためです。

接続情報

要求されたアクションを実行するには、WordPressがWeb サーバーにアクセスする必要があります。次に進むにはFTPまたはSSHの認証情報を入力してください。認証情報が思い出せない場合は、ホスティング担当者に問い合わせてください。

ちなみに、この値はkusanagiユーザーのパスワードを設定すればいいのですが、あえて同じにしていない限り、変わってしまっているので、移行先のものに変更しましょう。

wp-config.phpのパーミッションが正しければ、読み込み専用になっているので、以下のようにパーミッションを変えてから変更します。

以下の部分です。

ここはインポート時に自動的に書き換えてくれればいいのに、と思いますね。

あと、移行元のでPHPの7系を使っていて移行先で8系にしている場合は、 FS_METHOD という値も変更する必要があります。

を

に修正します。これは以下の公式のFAQの「Q1. WordPressの管理画面からテーマやプラグインの更新が行えません。」に記載されています。

公式FAQ

wp-config.phpの編集をする必要がなくなったので、パーミッションを戻しておきます。

KUSANAGI 専用プラグインの更新

上記を行なっても、おそらくプラグインやテーマの追加、削除、編集を正常に行えないことがあります。ファイルやディレクトリのパーミッションが間違っているからです。

ちなみに、WordPressのダッシュボードに表示される「セキュリティ状況」ですが、これがグリーンになって問題ないように見えても、実はパーミッションが間違っていることがあります。

というのは、この判定基準は実はKUSANAGI専用のプラグインが決めています。このプラグインが最新ではないことがあります。プラグインの「必須」というところで確認できます。

何が最新かをネットで確認してもいいですが、コマンドラインで最新化してしまった方が早いかもしれません。

最新化してから「セキュリティ状況」を見るとグリーンだった項目がレッドになっています。

wp-content/ permission is 755. Recommend permission is 775.

Administrator of wp-content/ is kusanagi.kusanagi. Recommend administrator is kusanagi.www.

パーミッションをコマンドラインから直していきましょう。

直すとグリーンになります。

wp-contentのパーミッションを主に変えましたが、一つ思ったのは、WordPress自体のアップデートの時はそれ以外も操作対象になるので、DocumentRootディレククトリからパーミッションを変えてもいいかもしれません。

なお、移行データのファイルやディレクトリのパーミッションは移行元のまま展開されていました。

ちなみに、このKUSANAGI推奨のパーミッションですが、かなりシレっと変えられます。

wp-contentの推奨パーミッションが変更されている

公式のリリースを見てもはっきりわからないような書き方になっていてかなり不親切です。

KUSANAGI 9 バージョンアップ情報 9.2.19-1

KUSANAGI専用プラグインを定期的にアップデートしていて、表示されるセキュリティ状況に合わせてきちんとパーミッションを変えているという方には不要なことでしたが、おそらくそんなプラグインのことを知っている人自体が少数派だと思いますので、ここで説明させて頂きました。

WP Cerber SecurityからSiteGuard WP Pluginへ変更

KUSANAGI8からKUANAGI9に移行するにあたって、個人的に変更した点があります。これまでログイン画面のURLの変更やreCAPTCHA（ログイン画面で画像の認識を求めたりしてロボット判定する機能）のために、以下で紹介したWP Cerber Securityを使っていました。

WordPressのログインURL変更ならWP Cerber SecurityWordPressのサイトを立ち上げたらまず最初にしたいのがセキュリティ対策。特にハッカーにログインされないための工夫が必要です。 デ...

しかし、このプラグインが最近セキュリティ脆弱性のためか、WordPress公式のストアからアップデートできなくなっていました。開発自体は続いており、プラグインのサイトからファイルをダウンロードして利用することはできます。

開発者によると、脆弱性の指摘に関して不満があるようです。

why is there no wordpress download anymore?

私もWordPressプラグインを開発して公式のレビューを通したことがあり、脆弱性の指摘も受けたことがあります。その指摘は細かくて誰がそんな悪用する？みたいなものでしたが、確かに理論的には悪用できなくもないな、と思って修正したところ、無事承認されました。なので、開発者が対応していないというのが私的にはしっくりきません。セキュリティに関するプラグインなのに脆弱性の指摘を受けているというのが残念過ぎます。なので、この際利用をやめることにしました。

替わりになるプラグインとして、以前も使っていたSiteGuard WP Pluginがあります。これはログイン画面のURL変更機能も機能としてはあります。ただ、この機能、Apacheでしか使えなくて、Nginxでは動きません。とはいえ、ログイン画面のURLは、前述したように幸いKUSANAGI9の標準機能としてBasic認証で守られているので、別に変更しなくてもいいと判断しました。

reCAPTCHAには対応していないのですが、ひらがななどの画像を読ませてロボット判定を行う機能があります。この機能があるため、SiteGuard WP Pluginを使うことにしました。

とはいえ、複数人がログインする可能性がある場合は、全員にkusanagiユーザーのパスワードを知らせてしまうのは、流石にセキュリティ的によろしくないので、何かしら対策を考えるべきです。

ドメインの切り替え

ここで準備ができたのでドメインの切り替えを行います。ここはご利用のドメインレジストラやDNSサービスで違うので、割愛します。

構成にもよりますが、数分から数時間かかると思われます。

Chromeなどの「検証」機能のNetworkタブで、見ているサイトがどのIPアドレスを利用しているかわかるので、切り替わったか確認できます。

興味深いことに、携帯の4Gの回線で見るのかや、自宅の回線から見るのかで、切り替わるタイミングが違いました。なるべくしっかり切り替わったタイミングで次の作業に移りたいですね。

SSLの設定

ここでようやくSSLの設定ができます。上述したように、移行データに証明書のデータも入っていたので、httpsでアクセスできる状態ではありました。しかし、定期的に証明書を更新するようにするために以下を行う必要があります。

以下によると、HSTS設定というオプションもあります。

ssl

ただ、httpでアクセスされなくなるというのと、HSTS対応したことをどこかに登録しなければならないそうで、少し怖かったので今回は対応しませんでした。なので、http⇒httpsのリダイレクトだけ設定しておきました。

また、 --auto という自動更新するかどうかというオプションもありますが、これは指定しなくてもデフォルトでONになるようです。

ちなみに、このコマンドDNSでwwwのサブドメインをAレコードに登録しているとエラーになります。

最初同じコマンドを実行したところ、上記のようなエラーが発生しました。3、6行目を見るとわかるように、なぜか、www.proggy.jpに対しても認証をリクエストしていました。特にコマンドでそうしているわけではありません。ログを見ると、DNS情報を取得してきているようでした。

実は、今回、この機会にwwwのサブドメインをAレコードに登録し、wwwから本ドメインにリダイレクトを設定しようとしていました。その情報をDNSから取得し、両ドメインともに認証をリクエストしていたということです。サーバー側、つまりKUSANAGIではwwwサブドメインでアクセスできるような設定をしていないので、Let's Encryptからアクセスできずにエラーになったようです。

DNSからwwwのAレコードを削除したところ、数分でこのコマンドでエラーは出ずに正常に認証することができました。

とここまで書いておいて気がついたのですが、KUSANAGIさんその辺り対応済みはずなんですよね。なんで、私の場合、Aレコードに両方入っていて、Whoisにも登録されているのにエラーになったのだろう。

KUSANAGI バージョンアップ情報 8.0.0-2

kusanagi provision のオプションにも --with-www というのがありますしね。

provision

もしかしたら、以下の記事のように手動で設定ファイルを修正する必要があるのかもしれません。時間ができたら検証したいと思います。

KUSANAGIでwww有り無しをリダイレクト！Nginx環境のリダイレクトを徹底解説します！

旧本番環境のお掃除

これで既存の本番環境は不要になります。1サイトしか運営していない場合は、VPSをシャットダウンして削除してしまえば終わりです。

ただ、複数サイト運営している場合は、移行したものだけ削除する必要があります。

基本的にはこれで終わりです。yesかnoを聞かれますが、ひたすらyです。

ただ、なぜかSSLの証明書が残っています。

たぶん大丈夫なのですが、仕組みがわからないので、更新処理などが走ったら嫌だなと思ったので、以下も行います。これもひたすらyです。

これで先ほどの証明書は消えました。ちなみにこのコマンドのオプション、certbotのバージョンによって違うようです。最初 kusanagi migrate --export 時に表示される通り以下でやったのですが、ダメでした。

全サイトを移行したらVPSを削除しましょう。

非公式な方法（kusanagi migrateを使わない方法）

私は複数サイト同じVPSで運営していたのですが、 kusanagi migrate を使わない移行もしました。それには事情があります。

ランダムな文字列のプロファイル名が嫌だ

私は一つのVPSで複数のサイトを運営しています。ただ、Conoha VPSの都合で一部のプロファイルが 6723218321be1ac8243d1bf7 のようなランダムな文字列になっていることに最近気がつきました。詳しくは【Conoha VPSバージョン2⇒3移行記事】をご覧ください。

プロファイル名がランダムの文字列だと、ディレクトリ名や設定ファイルの名前にもそれが入ってきます。コマンドラインの作業をしているとこれが非常に可読性が悪いです。なので、どうにかプロファイル名をFQDNに合わせて変更できないか調べたところ、それがかなり難しいのです。

プロファイル名は後から変更できますか？

一部のプロファイルはFQDNとProfileの文字列を同じでした。その頃に作ったプロファイルは kusanagi migrate で移行しました。

kusanagi migrate を使うとランダムなプロファイル名もそのまま持っていってしまいます。なので、この移行のタイミングで、コマンドラインでプロファイルを作り直して、データは別の方法で移行することにしました。

移行元からエクスポート

移行元はもちろんMariaDBなどのバージョンを上げるのは前のやり方と同じなので、参照してください。

エクスポートの仕方が違います。なんでも良いのですが、私の場合は、BackWPupというプラグインを使いました。詳しくは検索してください。

移行先でプロファイルを新規作成

コマンドラインで以下を行います。DB周りの値は旧環境と同じものを使ってもいい気はします。もちろんプロファイル名はランダムな値ではなく、ドメイン名にします。

移行元が動いているこの時点でSSLの自動更新を有効化したらおかしなことになりそうなので --noemail を付けます。

SSLの設定についてはドメイン切り替え後に行います。

移行データの展開

この後、通常、ログイン画面を開いて画面からサイト名を決めたりしがちですが、それはしません。DocumentRootを念の為バックアップをとり、新しいのを作ります。

そしてFTPなどで転送した移行データを展開します。tarの中身のディレクトリ構成が想定通りか tar tvf などで確認してからの方がいいかもしれません。

そして、次はDBです。移行データの中にSQLファイルがあるはずです。

不要なデータを削除します。

wp-config.phpの修正

wp-config.phpは移行データにあるものではなく、新規プロファイル作成時に生成されたものを使います。

変更内容は上述した公式の方法と大体同じです。以下の ***** をkusanagiユーザーのパスワードに置き換えます。前と違うのはコメントアウトされているのを解除することです。つまり # を削除します。自分はパスワードだけ置き換えておきならがらこれを忘れていて数時間無駄にしました。

次に動作確認をするための修正をします。この段階でSwitchHostで作業端末から見えるドメインを切り替えてみて、まだSSLが有効化できていない状態なのでhttpでブラウザからアクセスすると一応サイトは表示されます。しかし、一部画像が見えなかったり崩れていると思います。それは、外部ファイルのURLがhttpsのURLを向いてしまっているからです。なので、きちんと動作確認するために、一時的に「WordPress アドレス」と「サイトアドレス」の値を変えます。

大事なのはhttpsではなくhttpだということです。正式にドメインを切り替える前に動作確認をするために、この２行を追加するということです。

ただ、wp-config.phpの修正ではダメで、やはりDB内のこれらの値を変えないと反映されないケースが以前ありました。そういう場合は以下を参考にしてください。

WordPressのURL変更はDBから行おう！wp-config.phpはダメWordPressのURLを変更する場合、「WordPress アドレス」というのと「サイトアドレス」という値を変更する必要があります。...

動作確認完了後はこれらを戻すのを忘れないようにしましょう。つまりwp-config.phpの場合は上の２行の削除。DBの場合は、値を元に戻しておくということです。終わったらwp-config.phpのパーミッションを戻しておくのをお忘れなきよう。

パーミッションを調整

続いてパーミッションがKUSANAGIの推奨と異なっているはずなので、調整していきます。

その前に、KUSANAGI専用のプラグインを、公式の方法と同じように更新します。

ここで、WordPressのダッシュボードにログインして、「セキュリティ状況」を見てみましょう。すると、パーミッションがおかしいことがわかります。

コマンドラインからパーミッションを調整していきます。

ただ、ここで、公式の方法の時になかった問題を発見します。以下はDocumentRootのファイル一覧（一部省略）です。

ハイライトされている行はディレクトリなのですが、それの所有者とグループがrootになっているのですファイルは移行元にあった時の所有者とグループを維持していましたが、ディレクトリは全てがこうなっていました。まぁ、tar展開時、rootで作業してたので、当然といえば当然なのですが。公式の方法だと、ディレクトリの所有者とグループも移行元のものを維持してくれていました。やはり賢い感じがしますね。

ちなみに、手動で作成した一つ上のディレクトリのDocumentRootもそうでした。これは気持ち悪いですね。なので、以下のようにDocumentRootごと調整することにしました。

以上が非公式の方法です。あとは、同じように、ドメインの切り替え、SSLの設定、旧本番環境の掃除をします。

ドメイン切り替え⇒SSLの設定のタイミングでの注意点が一つあります。非公式の方法だと、移行データにSSLの証明書が含まれていないので、ドメインが切り替わったらhttpsでアクセスできないことになります。切り替わってすぐにSSLの設定ができればいいですが、切り替わりに気づくのが遅れた場合でも、その間にユーザーがアクセスしてくる可能性があります。すると、httpにリダイレクトもされず、サイトが表示されないのではないかと推察します。なので、なるべくすぐに気づけるようにしましょう。

さいごに

PHPのバージョンを上げたいだけだったところから始まったこの作業ですが、かなりの一大プロジェクトになってしまいました。

同じことをやろうとしている人の助けに少しでもなればと思います。

KUSANAGI PHP SiteGuard WP WordPress
あわせて読みたい