さて、前回までのエントリでkusanagi 9で動いているwordpressに旧サーバの記事を放り込むことができ、また、新規のエントリを書くことが出来るようになりました。ですが、この時点でwordpressの管理画面を見るといろいろなエラーがでていて、しかも体感的にそう読込が早くないという状況でした。そして、プライム・ストラテジー社のページをみるとまだすべき作業が残っているように思えたのでその対応について説明します。これまでの記事は以下の通りです。
- kusanagi環境を求めて、さくらのクラウドからさくらのVPSへお引っ越しした話。その1： 前置き
- kusanagi環境を求めて、さくらのクラウドからさくらのVPSへお引っ越しした話。その2： さくらのVPSを契約する
- kusanagi環境を求めて、さくらのクラウドからさくらのVPSへお引っ越しした話。その3： Linuxの基本設定（ユーザ追加とSSH設定、そしてIPv6の有効化）
- kusanagi環境を求めて、さくらのクラウドからさくらのVPSへお引っ越しした話。その4： kusanagiのインストール
- kusanagi環境を求めて、さくらのクラウドからさくらのVPSへお引っ越しした話。その5： wordpressのバックアップとリストア
さくらのVPSの契約はこちらから可能です。
まずはおすすめされているセキュリティ対策から
プライム・ストラテジー社の以下のページに最初に実行すべき作業がありますので、淡々と対応します。
＄ su -
というコマンドが実行されていますが、これはrootになるための方法です。suはrootのパスワードを知っていなければなりませんが、sudoが許可されているユーザであれば以下のコマンドを実行することでそのユーザのパスワードでrootになれます。
sudo -s
またkusanagiをインストールした時点でいくつかの重要なフォルダのパーミッションが755になっていたりwp-config.phpが666になっていたりするのでそのあたりは修正して下さい。上記のページでもしっかり触れられていますので、対応しましょう。
また、上記ページ2節で触れられている管理画面へのアクセスIPアドレスを制限する方法はノマド的にカフェなどのいろいろなネットワークからアクセスする場合にはなじまないでしょう。google authenticatorを入れるなど、管理画面へのログインを制限するための別の方法を使うべきです。ただ、wordpressの管理者ログイン画面への攻撃はよく知られているので、必ず何らかの対策をして下さい。
まずはプラグイン周りの設定を変更する
さて、ここまで来ましたが、まだ管理画面のエラーが落ち着いていません。ひいらぎやが気になったのはこれです。小さくて済みません…。
上から見ていきます。
Your backup folder is NOT writable To correct this issue, make the folder /var/www/hiiragiya/wordpress/wp-content/backup-db writable Your backup folder MIGHT be visible to the public To correct this issue, move the file from /home/kusanagi/XXXX/DocumentRoot/wp-content/plugins/wp-dbmanager/htaccess.txt to /var/www/hiiragiya/wordpress/wp-content/backup-db/.htaccess To correct this issue, move the file from /home/kusanagi/XXXX/DocumentRoot/wp-content/plugins/wp-dbmanager/index.php to /var/www/hiiragiya/wordpress/wp-content/backup-db/index.php Click here to let WP-DBManager try to fix it /home/kusanagi/XXXX/DocumentRoot/wp-content is write-able. When finished installing the plugin, change the permission back to the default: chmod 755 /home/kusanagi/XXXX/DocumentRoot/wp-content. Permissions are currently 777. nginx.conf rules have been updated. Please restart nginx server to provide a consistent user experience. THe Page Cache add-in file advanced-cache.php is not a W3 Total Cache drop-in. It shoud be removed.
まずは最初の2行 + 4行です。とはいえ画面の横幅で見えている行数が違いそうですので、最初から、dbmanagerが云々といっていてClick hereといわれているところまでです。
これはひいらぎやがWP-DBManagerというバックアップ用プラグインをいれていてこのエラーです。で、ここで、/var/www/hiiragiya/…というフォルダが出てきていますが、これは実は旧サーバのディレクトリ構成です。kusanagiのデフォルトとは違うフォルダ構成を前提とした設定をそのまま流し込んでしまったからですね。
ここでClick hereといわれて直してやるといわれていますがこの罠にかかってはいけません。これを修正するにはWP-DBManagerの設定の方を改めましょう。単純にプラグインの設定から触れば良いです。
その次のはwp-contentのパーミッションが777になっているというエラーです。パーミッションについては以下のエントリで詳しく書きました。
さて、前回まででさくらのVPSの登録がおわり、kusanagi入りのCentOS Stream 8にログインすることが出来ました。そこまでの経緯は以下の通りです。 [sitecard subtitle=関連記事 url=https:/[…]
で、777になっているというのは玄関全開の状態なので良くないですね。そこはここでいわれているように755に変更しましょう。
$ sudo chmod 755 /home/kusanagi/XXXX/DocumentRoot/wp-content
でOKです。
その次のnginxといわれているのは設定ファイルが変更されているのでnginxを再起動してと言われているだけなので単純に再起動すれば良いです。
$ sudo systemctl restart nginx
最後のは有名なキャッシュプラグインのW3 Total Cacheが、設定ファイルはオレが作った物じゃない！消して良い？といっているわけですが、kusanagiをいれているのでキャッシュ周りはkusanagiに任せるとして、むしろW3 Total Cacheをプラグインから削除します。
これで、この画面は綺麗になりました。ただ、サイトヘルスをみると、プラグインの自動アップデートが無効になっているといいます。これも実はパーミッション問題です。kusanagiはセキュリティ上の問題からおそらく勝手にHTTPd（apacheとかNginx）を実行しているユーザの権限でファイルを書き換えられないようにしているのですが、これは運用上はめんどくさいので、ひいらぎやはwp-content、wp-include、wp-adminのグループをwwwに変更しました。
先ほど紹介した記事にも書きましたがkusanagiユーザはwwwというグループに入っているのでグループがwwwであり書込権限があればこのディレクトリのファイルの編集が可能です。なお、当然グループでの書込を許可しておきます。
ちゃんとユーザーグループとかを追いかけておくと正しい方法が書いてあるのかも知れませんが…。ただ、アップデートがあるというときに更新ボタンを気軽に押せないのはなかなかです。
$ cd /home/kusanagi/XXXX/DocumentRoot/ $ sudo chgrp -R www wp-content wp-include wp-admin $ sudo chmod -R g+w wp-content wp-include wp-admin
ここで chmod g+w という表現がでてきました、これはgroupにwrite権限を追加するという表現です。所有者（user）やその他の人（other）のパーミッションやグループでも読込権限などがどうなっているかを気にせずに設定できます。所有者に実行権限を与えたいときは u+r 、他のユーザの書込実行と実行権限を落としたいときはo-wxなどとします。
KUSANAGIの設定を入れる
これまでコマンドプロンプトからkusanagiの設定を入れてきたわけですが、よく見ると管理画面の左側メニューにKUSANAGIという文字が見えます。ここをクリックしてページキャッシュかーとみていると…。
なんだってー、です。キャッシュが有効になっていないのは悲しすぎます。なんのためのkusanagiだ！と思いここに書いてある通り実行します。
$ sudo kusanagi bcache on
Turning bcache on.
Failed. WP_CACHE constant is defined multiple times.
bcache completed.はい、実行できませんでした。エラーはWP_CACHEが複数回定義されているという内容なので、コンフィグファイルをいろいろと探したのですが、どこにもこの言葉が見つけられる、Google先生にお伺いを立てたところ、むしろWP_CACHEが宣言されていないことが問題のようです。
おそらくkusanagi入りのwordpressでwp-config.phpを作らせれば、自動で追記されるのでしょうが、他から持ってきたのでなかったという落ちですね。先ほどのセキュリティ対策で移動したwp-config.phpに追記します。
define('WP_CACHE', true);
どこでもいいのでこれが入れば良いです。
再度チャレンジすると、以下のように設定でき、管理画面からもエラーが消えました。
$ sudo kusanagi bcache on Turning bcache on. bcache completed. $
さて、実はこの時点でパフォーマンスが劇的に改善しました。bcacheの解説自体は別にまかせますが、テーマの読込が毎回おこなわれないので早いと言うことです。
実は有効化とともにMackerelからメッセージが飛んできました。
上から見て16:15や更にその前を見ていてもずっと5000msということでアクセスしてからの反応が5秒以上かかっていたのがbcacheをonにした瞬間に100msを切ってきました。ずっと遅いのは後から見直さないといけないなと思っていたのですが、やはりキャッシュ周りは強烈です。（グラフは時間切れで消えてしまいました…）
さて、一緒にfcacheもONにしておきます。
$ sudo kusanagi fcache on Turning fcache on. reload completed. fcache completed. $
fcacheはfast-cgiのキャッシュなのでreloadというのはおそらくnginxの事だと思います。
これで無事キャッシュも有効になり爆速の（いや、これ本当にびっくりしました）wordpressサーバが出来ました。