さて、前回まででさくらのVPSの契約を行って、kusanagi 9 がはいったCentOS Stream 8のイメージをつかって環境を構築。そしてLinuxの初期設定を行った上で kusanagi 9 の初期設定を行いました。これでWebからwordpressのセットアップページが見えているので、一からwordpressの環境を作る人はこのまま進められるという状況まで持ってきました。とはいえ、ある程度修正をしておいた方が良さそうな点はあったりするのですが。これまでの各記事はこちらです。

• kusanagi環境を求めて、さくらのクラウドからさくらのVPSへお引っ越しした話。その1： 前置き</a
• kusanagi環境を求めて、さくらのクラウドからさくらのVPSへお引っ越しした話。その2： さくらのVPSを契約する
• kusanagi環境を求めて、さくらのクラウドからさくらのVPSへお引っ越しした話。その3： Linuxの基本設定（ユーザ追加とSSH設定、そしてIPv6の有効化）
• kusanagi環境を求めて、さくらのクラウドからさくらのVPSへお引っ越しした話。その4： kusanagiのインストール

今回はこの続きです。別のサーバで運用していたwordpressからデータをバックアップして、新しく構築したサーバに移す作業を行います。一から記事を書き始める人はこちらのページを参考にされると良いと思います。

旧サーバのwordpressのデータ保存する

まずは古いサーバからデータを持ってきます。wordpress的に持ってこないといけないデータは2種類です。

1. mysqlサーバの中のデータベース
2. wordpressの設定ファイルやプラグイン

です。それぞれ取り出しましょう。

まずはデータベースの保存

これは当然古いサーバでの作業になります。

[workuser@oldserver]~$ mysqldump -u root wordpressdb > ./wordpressdb.sql

これでmysqlのデータを wordpressdb.sql というファイルに取り出せました。-uで指定しているのがユーザ名、その後ろのwordpressdbというのが対象とするデータベース名です。

ユーザ名、データベース名はそれぞれの設定に依存するのでそれぞれに会うものを入れて下さい。

とりあえずrootのパスワード忘れたんだけど！という場合はwp-config.phpとかを覗いてもらうと以下のような記述があると思います。平文で保存されている時点でアレですが、これでいけるはずです。

define( 'DB_USER', 'XXX' );
define( 'DB_PASSWORD', 'YYY' );

DB_USERの後ろにあるXXXの部分がmysqlのユーザ名、DB_PASSWORDの後ろのYYYの部分がパスワードです。

保存先は「>」の先に書いてあるファイルです。何でもかまいません。このケースはコマンドプロンプトがに「~」とあり、保存先のファイルが 「./」から始まっているのでworkuserのホームディレクトリにwordpressdb.sqlという名前で保存しています。

wordpressの設定ファイルなどを保存する

次にwordpressの設定ファイルです。

[workuser@oldserver]~$ cd /var/www/hiiragiya/wordpress/wp-content
[workuser@oldserver]~$ sudo tar czf ~/wp-content-backup.tar.gz ./themes ./plugins ./uploads

旧サーバには手動でwordpressをインストールしたのですが、その時は/var/www/hiiragiya/wordpressというディレクトリに一式を格納しました。そのディレクトリの直下にある以下の3つのディレクトリを単純にコピーします。単純にコピーすると一ファイルずつ扱うのが面倒なのでtarコマンドを使って一つのファイルにまとめるとともについでに圧縮してファイルサイズを小さくしています。

これも保存先はworkuserのホームディレクトリです。このコマンドを実行するとしばらく時間がたってからコマンドプロンプトが帰ってきます。コマンド実行後ウンスンなのが怖い場合はオプションのczfをczvfにします。vを入れれば処理中のファイルを一覧で出してくれます。順不同ですがfは最後にしないとダメです。ただ、処理時間は長くなります。

Let’s Encrypt周りのファイルを保存する

wordpressと直接関係はないのですがもともとのサーバで使っていたSSL証明書も保存します。Let’s Encryptで証明書を発行してもらっていましたが、今後も同じサーバ名で運用をするので、そのままファイルをコピーします。

[workuser@oldserver]~$ cd /etc/letsencrypt
[workuser@oldserver]~$ sudo tar czf ~/letsencrypt.tar.gz *

新サーバにバックアップファイルをコピーする

バックアップが出来たら2つのファイルを新サーバにコピーします。一度手許のマシンにコピーしてきてもいいですし、直接旧サーバから新サーバにコピーしても問題ありません。ひいらぎやは旧サーバのSSHの公開鍵を新サーバのauthorized_keysに追加してそのままssh出来るようにしました。こうすればscpで直接コピーできます。

[workuser@oldserver]~$ scp wp-content-backup.tar.gz wordpressdb.sql letsencrypt.tar.gz workuser@newserver:~

とします。最後のworkuser@newserverというのが新サーバのユーザ名とサーバ名（もしくはIPアドレス）です。「:」の後でサーバ上の場所を指定していますが「~」を指定しているので、workuserのホームディレクトリに保存されます。まぁ省略すればホームディレクトリになるので「:」まででもこの場合は同じ事です。

新サーバでの作業

さて、ここまでで旧サーバのwordpressデータを新サーバにもってこれました。ここから、新サーバでの作業を行います。

新サーバのwordpressに接続する

このときブラウザから新サーバのIPアドレスを指定します。

http://XXX.XXX.XXX.XXX/

IPアドレスを指定するのがめんどくさいという人はDNSサーバで名前を決めてしまうか、hostsファイルを編集します。hosts自体はもともとBSD/Linuxの設定ファイルですが、BSDをベースにしているMacOSXにはそのままファイルがありますし、Windowsでもありますので、適当にぐぐって編集して下さい。

hostsを変更すると手許のマシンがそこで指定されたサーバ名をIPアドレスに変更してくれます。ですのでそのサーバだけで有効です。一方DNSサーバは世界に公開されているサービスですのでインターネット上全体でそのIPアドレスに名前が付きます。このサーバの場合はwww.hiiragiya.netというのが一つの例ですね。

で、www.hiiragiya.netというのは最終的に使いたい名前で、旧サーバに付いている名前なのでこれを上書きするとまだ設定中の新サーバに全世界からアクセスが来てしまうので都合が悪いです。最終的に新サーバをwwwという名前にしますが、テスト中は別の名前をつけておけばいいです。よくあるのがwww2とかですね。とはいえ、別に一つのIPアドレスに複数の名前が付いていても問題ないので、ひいらぎやはylangylangという名前をつけておきました。これでどこからでもylangylang.hiiragiya.netとすればこのサーバのwordpressにアクセス出来ます。

DNSサーバの設定の浸透には時間がかかるといろんなところに書いてあります、半分本当で半分嘘です。今回hiiragiya.netというドメインにはylangylangという名前が存在しませんでした。新規での登録についてはその場で名前が登録されますのであまり気にせずにすすめましょう。世の中に出回ってしまった名前とIPアドレスのセットをアップデートするのには時間がかかりますが、存在しなかったものについては出回ってしまったものがないので、その場であらたにDNSサーバに聞きに来られるので問題がないのです。

もう一点hostsを編集したときの注意点です。旧サーバにwwwという名前がついていますが、これをhostsで上書きすることが出来ます。手許のマシンからのアクセスについてDNSよりもhostsの設定の方が優先されるので、旧サーバにアクセスしたいときにはhostsの書き換えが必要になります。これが面倒でひいらぎやは別の名前をつけることにしたのでした。

さて、そんなこんなで、このIPアドレスもしくはサーバ名でアクセスして、ひいらぎやが最初に遭遇した画面がこちらです。

絶望しましたね（笑）

ほぼマニュアル通りにインストールしたらこの画面でした。

nginx の error.log には以下のような表示がありました。

2021/11/16 15:55:15 [error] 1642#0: *1 FastCGI sent in stderr: "PHP message: PHP
Fatal error:  Uncaught TypeError: array_merge(): Argument #2 must be of type ar
ray, bool given in /home/kusanagi/XXXX/DocumentRoot/wp-content/mu-plugins/kusanagi-core/modules/misc.php:44
Stack trace:
#0 /home/kusanagi/XXXX/DocumentRoot/wp-content/mu-plugins/kusanagi-core/modules/misc.php(44): array_merge(Array, false)
#1 /home/kusanagi/XXXX/DocumentRoot/wp-content/mu-plugins/kusanagi-core/modules/misc.php(465): KUSANAGI_Misc->__construct()
#2 /home/kusanagi/XXXX/DocumentRoot/wp-content/mu-plugins/kusanagi-core/core.php(82): include_once('/home/kusanagi/...')
#3 /home/kusanagi/XXXX/DocumentRoot/wp-content/mu-plugins/kusanagi-core/core.php(40): WP_KUSANAGI->load_modules()
#4 /home/kusanagi/XXXX/DocumentRoot/wp-content/mu-plugins/wp-kusanagi.php(14): WP_KUSANAGI->__construct('cache-clear.php')
#5 /home/kusanagi/XXXX/DocumentRoot/wp-settings.php(340): include_once('/home/kusanagi/...')
#6 /home/kusanagi/XXXX/Docum" while reading response header from upstream, client: XXX.XXX.XXX.XXX, server: ylangylang.hiiragiya.net, request: "GET /wp-admin/setup-config.php HTTP/1.1", upstream: "fastcgi://127.0.0.1:9000", host: "ylangylang.hiiragiya.net"

どうみてもkusanagiのモジュール内の問題だなとさくらインターネット社にも問合せをしてみたのですが、VPSはサーバの引き渡し以降はユーザの責任とのこと。たしかにどんな設定になっているかもわからないので気持ちはわかります。

そして、よく見るとさくらのVPSからリンクが張られている設定についてのページはプライム・ストラテジー社のサイトです。責任の切り分けもめんどくさそうだなぁと思い、サポートはあきらめたのでした。

ある程度調べたところ、これは既にお知らせしましたがkusanagiの設定の際に –php80 を設定した副作用でした。–php74 に変更することで解消しました。 新しいものが使えるならと思った程度でPHP8に特に愛は無かったのでPHP74で動かすことで解消しています。

正しくはこのようなページが見えます。

1から設定をする場合にはここから指定していきます。

ひいらぎやはwordpressが動いていることが確認できれば十分だったのでここでブラウザを閉じ、先ほどとったバックアップを投入していきます。

バックアップファイルをインポートする

書き出すときもそれぞれほぼ1コマンドで終わっていますが、戻すのもそう難しくありません。

サクッとまとめてやります。

[workuser@newserver]~$ mysql -u kusanagi_db -p kusanagi_db < /tmp/wordpressdb.sql
[workuser@newserver]~$ cd /home/kusanagi/XXXX/DOCUMENTROOT/wp-content
[workuser@newserver]~$ sudo tar zxvpf ~/wp-content.tar.gz -C .
[workuser@newserver]~$ sudo chown -R kusanagi:kusanagi ./themes ./plugins ./uploads
[workuser@newserver]~$ cd /etc/letsencrypt
[workuser@newserver]~$ sudo tar zxvpf ~/letsencrypt.tar.gz 

それぞれ旧サーバと同じ場所にもどしていきます。

/home/kusanagi/XXXX はkusanagiのデフォルトのwordpressのコンテンツが置かれる場所です。XXXXはkusangi initを実行したときに指定したプロファイル名です。この下に自動的にwordpressがインストールされており、ここにバックアップしたファイルを流し込んでいます。

chownコマンドを実行しているのはこのディレクトリの所有者はすべてkusanagi:kusanagiになっていたのでこれにあわせました。バックアップを取ってきたサーバとはユーザID等が違うはずなので必ずサーバ間でファイルをコピーするときは所有権を変更します。面倒なのでユーザIDをサーバ間で統一するという運用もあります。letsencrypt関連のファイルはどちらにせよrootの持ち物（=ユーザID1）なのでそのままにしています。

さて、tarコマンドは出力するディレクトリもコマンドラインで指定できるのですが、これミスったときのダメージが大きすぎるので、このディレクトリの下に伸張していいかを明確に確認してから行っています。ちなみに中に入っているファイルを確認してから実行するとなお良いです。

こんな感じです。tzfではファイルは実際に展開されませんが入っているファイルの一覧が見えます。

[workuser@newserver]~$ cd /home/kusanagi/XXXX/DOCUMENTROOT/wp-content
[workuser@newserver]~$ tar tzf ~/wp-content.tar.gz
[workuser@newserver]~$ sudo tar zxvpf ~/wp-content.tar.gz -C .

この後先ほど、設定ファイルが見えていたWebサイトにアクセスすれば元々動いていたwordpressの公開ページが見えるはずです。wp-adminなどにアクセスすれば管理ページなども見えるはずです。

さて、Let’s Encrypt関連のファイルを流し込んだので、手動でLet’s Encryptの設定をします。

Let’s Encryptの設定

とはいえ、Let’s Encryptのすべては/etc/letsencryptにおいてあるのでこれ自体の設定は必要ありません。nginxの設定をします。

kusanagi 9 （さくらのVPSの標準イメージ）の場合、nginxの設定は以下にあります。

/etc/opt/kusanagi/nginx/conf.d/’プロファイル名’.conf

このファイルを編集し以下の記述を見つけます。

server {
    listen 443 ssl http2;
    server_name www.hiiragiya.net;
    set $do_not_cache 1; ## page cache
    set $expire_days 90;
    ssl_certificate     /etc/pki/tls/certs/localhost.crt;
    ssl_certificate_key /etc/pki/tls/private/localhost.key;
    ssl_ct off;
    ssl_ct_static_scts /etc/opt/kusanagi/nginx;

server_nameはkusanagiの設定の際に指定したサーバ名ですね。

ssl_certificateとssl_certificate_keyの値を書き換え、更に2行追記します。てか、旧サーバのnginx.confから持ってくればいいですね。

    ssl_certificate /etc/letsencrypt/live/www.hiiragiya.net/fullchain.pem; # managed by Certbot
    ssl_certificate_key /etc/letsencrypt/live/www.hiiragiya.net/privkey.pem; # managed by Certbot
    include /etc/letsencrypt/options-ssl-nginx.conf; # managed by Certbot
    ssl_dhparam /etc/letsencrypt/ssl-dhparams.pem; # managed by Certbot

www.hiiragiya.net用に発行した鍵がありますので、これをそのままつかいます。一応ファイルがあるかは確認しておいて下さい。これでHTTPSでアクセスできるはずですが、正しくDNS的にwww.hiiragiya.netという名前に変えるまではエラーが出るはずです。

また証明書の更新についてもkusanagiをつかってlet’s encryptを制御しようとしたときと同じ理由でエラーが出ます。これも先ほどと同じでDNSの名前がwwwになれば解消するはずです。

再掲にはなりますがこのあたりの詳細は以前の記事に。

関連記事

kusanagi環境を求めて、さくらのクラウドからさくらのVPSへお引っ越しした話。その4： kusanagiのインストール

さてやっとkusanagiの設定です。これまでに、さくらのVPSを契約し、kusanagi on CentOS Stream 8 のテンプレートイメージを導入、Linuxの初期設定を実施しました。これまでの記事は以下に。 [sitec[…]

少し長くなってしまいましたが、これで証明書のエラーなどはあるもののwordpressで作られたページと管理画面が見えるはずです。第一歩は終了ですね。

ただし、この時点でさっぱり早くありません（笑）

そして管理画面でもエラーがたくさん出ていると思います。このあたりの修正は次の記事で…。ただ、エラーは出ているもののセキュリティ強化のためのkusanagiのポリシな気もしています。とはいえ、使い勝手が低いのもこまるのでこのあたりをある程度修正していきます。