名前も知らないSEでしょう

この木なんの木気になる樹

wordpress

カゴヤのVPSでwordpressの設定をするときのハマりポイント

更新日:

最近、自分のではないんですけど新規にwordpressを設定するお手伝いをすることがあって、カゴヤ・クラウドのVPSを利用してwordpressを構築する際にハマった箇所を備忘録的にメモ。

カゴヤ・クラウド

インスタンスの作成

会員登録的なところはすっ飛ばして、インスタンス作成。
インスタンスタイプは、今回はお試しなのでSSDで一番安価なタイプA-SSD、アプリケーションパックはWordPressパック (CentOS 6 64bit)を利用。nginx、mysql、wordpressなど、必要な環境が一通り揃っているテンプレートの模様。
ログイン用の認証キーを指定してボタンをぽちぽちするだけで、簡単にインスタンスを作ることができました。

WordPressを動かすだけであれば、これくらいのものが入っていれば十分なので、GUIで選択するだけでまっさらな環境が立ち上がるのは便利でいいですね。

SSHの設定を変更

初期状態だと、ローカル環境からsshでログインするとき、インスタンス作成時に生成した認証鍵を使うものの、sshdの設定がrootでパスワード不要でログイン可能、とかそんな感じなので、sshdの設定を変更します。wordpressとは全然関係ないですけど、よくあるやつです。
/etc/ssh/sshd_configをエディタで開き、Portを22番から任意の番号に、PermitRootLoginをnoに変更します。sshのポート変更に伴い、/etc/sysconfig/iptablesもエディタで開き、22番となっているファイアウォールの設定をsshに合わせて変更します。

変更を終えたら、sshdとiptablesを再起動しましょう。

# service iptables restart
# service sshd restart

これで、sshのセキュリティを最低限ではありますが設定をしました。真面目にやるならばまだまだやることはありますが、今回の本筋ではないのでこれくらいにして次に進みます。
最低限、公開鍵の設定はしておきましょうね。

この調子なら、さくさくっと設定が終わるだろう。そう思っていた時期が私にもありました。。。

プラグインを入れていくとメモリが足りない

WordPressといえば、便利なプラグインが色々とあるのでまずはそれらをインストールしていきます。プラグインの内容はここでは触れませんが、使いたいものをインストールして有効化したところ、ブラウザ上の管理画面がシステムエラーっぽい画面に。管理者に問い合わせろって、んな馬鹿な。

仕方がないので、nginxのエラーログ(/var/log/nginx/error.log)を確認すると、

Allowed memory size of 33554432 bytes exhausted

とか言われちゃってます。
PHPのメモリが足りていないと思われるので、php.iniのmemory_limitの値を大きくすれば良いのです。php.iniは、この環境の場合は/etc/php.iniにあるので、エディタでサクッと編集して256Mに変更し、nginxを再起動します。

・・・

 

 

 

 

 

 

なおらんやないかーい!!!

ここで少々ハマって1時間弱ほど無駄な時間を使いました。
実はわたくし、nginxを初めて使った情弱なもので、各設定がどうなっているかを把握するのに少々手間取りました。どうやら、nginxを使う場合は、php-fpmとやらが何やらいい感じに働いているんですね。ちゃんと調べていないのでよくわかっていませんが、

FPM ( FastCGI Process Manager ) は PHP の FastCGI 実装のひとつで、 主に高負荷のサイトで有用な追加機能を用意しています。

なのですってね。
とりあえず、/etc/php-fpm.d/www.confをエディタで開き、php_admin_value[memory_limit]の値を32Mから256Mに変更し、php-fpmを再起動することで解決しました。

プラグインを6、7個くらい有効にした時点でメモリ足りなくなったので、VPSのテンプレートの初期値をもう少し高めにしておいてもらいたい気はしなくもない。

色々とプラグインが動いたので、諸々ページをカスタマイズするけどそこは本題じゃないので省略。

Jetpackと連携する

投稿をするときにTwitterと連携するプラグインとしてJetpackを設定しようとすると、設定画面で403エラーが出ました。やっぱりnginxのエラーログを確認すると、

access forbidden by rule, client: xxx.xxx.xxx.xxx, server: _, request: "POST /xmlrpc.php?for=jetpack

ということで、xmlrpc.phpにアクセスできないことが原因の模様。むしろこれは、テンプレートの時点で外部からの攻撃を受けないための設定が施されているということで良い点ですね。

余談ですが、実は、このブログの構築をしたときにxmlrpc.phpのアクセス制御をしていなかったため、DDOS攻撃の踏み台になっていたことがありました。さくらインターネットから、「お前んとこから不特定多数に大量のアクセスしてるからすぐに初期化しやがれ」的なメールが来て気づいて対策をしたのですが、このあたりの初心者がハマりそうなところをカバーしてくれているのであれば、色々とありがたい。

話を本題に戻しますが、これを解決するためには、xmlrpc.phpへのアクセス制御を一時的に解除する必要があります。これは、/etc/nginx/conf.d/wordpress.confに設定されているため、該当の箇所をコメントアウトしてnginxを再起動する必要があります。僕の環境では、21行目から25行目でした。

追記:2016/01/09
コメントアウトではなくて、jetpackからのアクセス許可の方が良いですね。
その後のnginxのエラーログにjetpackとの連携エラーがいっぱい吐き出されているみたいなので。。

コメントアウト修正する箇所

location = /xmlrpc.php {
    allow 192.0.64.0/18;
    deny all;
    access_log off;
    log_not_found off;
}

Jetpackの設定、Twitterとの連携が完了したら、忘れずにコメントアウトを元に戻してnginxを再起動するようにしてください。ホントにいっぱい攻撃がきます。
冒頭でsshの設定も、最低限でいいのでやっておいたほうがいいですよ。ログを見てると、いっぱい変なアクセスきてますから。


 

特にハマりそうだったところはこんなところでしょうか。
同じことでハマっている人や未来の自分の参考になれば良い。こんなの絶対忘れる。

336x280

336x280

-wordpress
-,

Copyright© この木なんの木気になる樹 , 2017 AllRights Reserved.