このところのVPSの低料金化で、重ったらしい共用サーバからVPSに乗り換えてWordPressを稼働させている方も多いかと思います。かくいう私もVPS（『さくらのVPS512』）に乗り換えて、当サイト含め3つのサイトを稼働させています。

PHPアクセラレータによる高速化

さて、せっかくVPSでWordPressを稼働させるのであれば、さまざまなワザを使って高速化を図りたいもの。その一つとして人気が高い（というか定番）のが、PHPアクセラレータを導入するという手法です。私が導入しているPHPアクセラレータ『APC』のサイトにはこう書かれています。

Alternative PHP Cache (APC) は、PHP の実行コードをキャッシュする仕組みで、 フリーかつオープンに使用できます。PHP の中間コードのキャッシュ・最適化を行うための、 フリーでオープンかつ堅牢なフレームワークを提供するということを目標としています。

意訳すると、PHPスクリプト（WordPressでいうとコアファイルやテーマファイル、プラグインなど *.php という名のファイル群）を、サーバがより高速に処理できる状態（バイトコードという）に変換し、メモリ上に蓄えておく仕組み。以降、同じPHPスクリプトを実行するときには変換後のバイトコードを使いまわすため、高速化が図れるというわけです。

で、何が起きた？

このメリットが実は落とし穴でした。WordPressのテーマディレクトリにある functions.php をいくらいじってもサイトに反映されないのです。

WordPressの利点として「PHPスクリプトをトライアンドエラーで修正しながらサイトを構築できる」があると思います。某CMSのように「再構築」という面倒きわまりない手順を踏まなくても、PHPスクリプトをちょっと書いて実行して、また修正して……が簡単にできる。すばらしい。

ところが、PHPアクセラレータを使っていると、PHPスクリプトの修正がすぐには反映されません。コンパイルされたバイトコードがメモリ上に残っていると、PHPスクリプトを修正しようが中身がからっぽになろうが、ゾンビのようにバイトコードが実行されてしまうのです。

例えば、当方の環境（Ubuntu 10.04 i386）におけるAPCの設定ファイル /etc/php5/apache2/conf.d/apc.ini にはこんな記述があります。

apc.gc_ttl=3600

これは、PHPスクリプトが変更されても3600秒間は変更前の古いバージョンでコンパイルしたバイトコードを使い続けるという設定です。なので functions.php をいくらいじってもサイトに反映されなかったというわけ（1時間待てば反映されるんですけどね…… ）

前振りが長くなりましたが対処法

APCを導入していて、かつ、テーマのテンプレートファイルや functions.php を変更する必要が出てきたら、一時的にAPCを停止させるのがいいでしょう。

/etc/php5/apache2/conf.d/apc.ini をエディタで開き

-apc.enabled=1
+apc.enabled=0

と変更して、ウェブサーバ（当方の環境ではApache2）を再起動。

sudo service apache2 restart

こうすることで、PHPスクリプトの変更が即座にサイトに反映されるという、WordPress本来のメリット（？）にあずかれるようになります。

修正が終わったら、再度 apc.ini の書き換えとウェブサーバの再起動をお忘れなく。

ということで、

• ホストOS……Windows XP Professional SP3
• ゲストOS……Ubuntu 10.04.1 LTS

の環境を『VMWare Player』3.1.4（Windows版）で作ってみたので紹介します。いつものとおり「ご利用は計画的に」の技術情報ですのでご了承のほど

インストールした直後の『VMWare Player』を起動した状態。「新規仮想マシンの作成」をクリックするとウィザードが立ち上がります。

「後でOSをインストール」を選び、次へ。「インストーラディスクイメージファイル」でUbuntuの .iso ファイルを選んでしまうと、日本語版Remix CDの .iso ファイルであっても英語版がインストールされてしまうので。

ゲストOSとしてLinuxを選び、バージョンを「Ubuntu」に。

仮想マシン名やディスクイメージの格納場所はご随意に。

ディスクイメージの最大サイズもご随意にどうぞ。

ディスクイメージを作る準備ができました。メモリサイズなどのカスタマイズをしたいときは「ハードウェアをカスタマイズ」をクリックします。

ここでも、好みに合わせてカスタマイズしましょう。メモリサイズ以外は特に設定しなくてもいいのかなあと思います。

ディスクイメージができたのでメニューが追加されました。
「仮想マシンの再生」をクリックしてUbuntuをインストールしていくわけですが、その前にディスクイメージがあるフォルダにある .vmx ファイルをテキストエディタで開きます。Ubuntu 日本語版Remix CDの .iso イメージを読み込むように以下の箇所を修正しましょう。

-ide1:0.autodetect = "TRUE"
+ide1:0.fileName = "ubuntu-ja-10.04-desktop-i386-20100512.iso"

日本語版Remix CDを .vmx ファイルやディスクイメージ（.vmdk ファイル）と同じ階層に置いて仮想マシンを起動するとインストーラーがスタートします。

再起動してログインするとウィンドウ下部に『VMWare Tools』のインストールを促すメッセージが出てくるので「仮想マシン」メニューより「VMWare Toolsのインストールを選択」。仮想マシン内のUbuntuのメニューではなくて、Windowsのメニュー（＝ブルーの枠のウィンドウ）から選ぶのでご注意を。

仮想マシンのデスクトップに『VMWare Tools』のアイコンが現われるのでダブルクリック。

圧縮ファイル（.tar.gz）のアイコンをダブルクリック。

圧縮ファイルの展開中。

デスクトップに『VMWare Tools』のフォルダが出てきました。さらにダブルクリックしましょう。

インストーラーは『vmware-install.pl』というスクリプトなので、アイコンをダブルクリック。

「実行する」をクリックしてサクサク進めていきましょう。

インストールが終わった状態。何も変化がないように見えますが、デスクトップからDVDのアイコンが消えていれば大丈夫。仮想マシン（Ubuntu）の [システム] – [設定] – [モニタ] より画面解像度が設定できるかを確認してみましょう。

これでも結果オーライだからまあいいのですけれど、別解として skin.js を修正した後、自分でカスタム shadowbox.js を作る方法も紹介します。

なお、カスタム shadowbox.js を作るには

• Ruby
• Rake（Rubyによるビルドツール）

が必要なのでご了承のほど。ここでは、Ubuntuを使ってのビルド（作成）方法について紹介していきます。

まずは ruby と rake を apt か aptitude でインストール。

sudo apt-get install ruby rake

GitHubからダウンロードした Shadowbox.js のソースディレクトリに移動し設定ファイル build.yml を開きます。

---
 
# May be the name of any adapter in source/adapters
adapter: base
 
# May be any language code in source/languages
language: en
 
# An array of names of players found in source/players
players: [flv, html, iframe, img, qt, swf, wmp]
 
# YES to include support for CSS selectors, NO to decline
css_support: YES
 
# YES to compress the code, NO to use the source code
compress: NO
 
# The directory to output the build to
target: build

日本語環境で使うなら

-language: en
+language: ja

あとはお好みで、ライブラリとしてjQueryを使いたいなら

-adapter: base
+adapter: jquery

可読性よりもファイルサイズ・実行速度重視なら

-compress: NO
+compress: YES

と変更すればよいでしょう。

それではおもむろに Rake でビルド。build.yml のあるディレクトリでコマンドを実行します。同じディレクトリにある Rakefile が自動的に build.yml の設定内容を読みにいってくれるので、rakeコマンドは引数なしでオッケイです。

rake

すると、同じ階層に build というディレクトリが新たにできます。build ディレクトリの中身は例えばこんな感じですね。

LICENSE
README
close.png
expressInstall.swf
loading.gif
next.png
pause.png
play.png
player.swf
previous.png
shadowbox.css
shadowbox.js

これでビルドは完了。ディレクトリ名を Shadowbox などに適宜変えて、いつもどおりウェブサーバ上にディレクトリごとアップロードしてください。

echo "XAMPP for Linux started:"
/opt/lampp/lampp start

XAMPPのヴァージョンもずいぶん古くなってしまったので、この際ピュアな（？）LAMP環境に作り替えてしまおうか……

ということで、例によって「ご利用は計画的に 」の設定メモです。

インストールはapt-get（もしくはaptitude）で一発。

sudo apt-get install postfix

で、設定ファイルである /etc/postfix/main.cf をこのように書きました。

mynetworks = 127.0.0.1
inet_interfaces = localhost
alias_maps = hash:/etc/aliases
 
mydomain = hostname.sakura.ne.jp #hostnameはVPSのホスト名
myhostname = hostname.sakura.ne.jp #hostnameはVPSのホスト名
myorigin = $mydomain
 
mydestination = $myhostname, localhost.$mydomain, localhost, $mydomain
relay_domains = $mydestination
 
mynetworks_style = host
 
message_size_limit = 0
mailbox_size_limit = 0

rootあてのメールを hoge@tecking.org へ転送するため /etc/aliases に

postmaster:root
webmaster:root
root:hoge@tecking.org

と書いて

sudo newaliases
sudo /etc/init.d/postfix reload

という感じで稼働させます。

留意点として、本契約後に送られてくる住所確認はがきの「お知らせ番号」を入力するまでは

• 外向きの25番ポートが閉じられた状態
• 転送量制限（2Mbps）

になっているので、以前のエントリーで書いたように relayhost を設定して稼働テストをする必要が出てくるかもしれませんね。

ここでは先日契約したVPS（Ubuntu 10.04 i386）に対して、ローカルサーバ（Ubuntu 8.04 i386）からファイルを送り込む方法を紹介します。レンタルサーバの場合も基本的には同じ方法です。いつものとおり、無保証の技術情報ですのでご利用は計画的に

送り込むファイル（ディレクトリ）はこのように作ります。

• ファイル（ディレクトリ）はパスワード付きでZIP圧縮
• 公開鍵認証でVPSにSSH接続

ではスクリプトを。

#!/bin/sh
 
zip -P hoge /tmp/fuga.zip -ru /home/foo
 
rsync -e "ssh -i /home/foo/id_rsa -p 56789" -auz /tmp/fuga.zip bar@hostname.sakura.ne.jp:/home/bar
 
echo ''
echo 'rsync (remote backup) completed.'
echo ''

上記の場合

• ZIP圧縮するディレクトリ…… /home/foo
• 圧縮ファイル名…… /tmp/fuga.zip
• 圧縮パスワード…… hoge
• 秘密鍵ファイル（ローカル側）…… /home/foo/id_rsa
• リモート側のSSHポート……56789
• 公開鍵ファイル（リモート側）…… /home/bar/.ssh/authorized_keys
• バックアップファイルの格納先（リモート側）…… /home/bar

の設定です。上記シェルスクリプトを rsync-remote というような名前にして /etc/cron.daily に入れておけばオッケイでしょう。

wp-config.php

自動アップグレード機能を使う際にFTP情報を尋ねてくるのがうっとうしかったので、以下の定数を追記しました。本来、適切なパーミッションやユーザ・グループ設定がしてあれば不必要なはずなので、おそらくどこかで適切でない設定をしているのでしょう

define( 'FS_METHOD', 'direct' );

投稿・ページの記事を書いている際のバックアップファイル数を減らすために以下の定数も追記。

define( 'WP_POST_REVISIONS', 3 );

『Twitter Tools』を使うためにPHPのcURLモジュール導入

Twitterのツイートをサイドバーに表示できるWordPressのプラグイン『Twitter Tools』。これを使うには、PHPのcURLというモジュールが必要になります。モジュールが有効になってないと『Twitter Tools』の設定画面が真っ白になってコトが進みません。

sudo apt-get install php5-curl
sudo /etc/init.d/apache2 restart

テーマやメディアファイルのバックアップ

データベースのバックアップに『WP-DB-Backup』や『WP-DB Manager』を使うケースは多いと思いますが、wp-content ディレクトリ内のテーマやアップロードしたメディアファイルなどがバックアップされない難点があります。

そこで wp-content ディレクトリをアーカイブしたファイルを uuenview でエンコード→メールで送ってバックアップ、というシェルスクリプトを作りました。

まずは uuenview をインストール。uuenview は uudeview というパッケージに含まれています。

sudo apt-get install uudeview

シェルスクリプトはこんな感じで。/etc/cron.d/weekly に wp-backup.sh みたいなファイル名で保存しておきます。

#!/bin/sh
 
DATE=`date "+%Y/%m/%d %T"`
 
cd /path/to/wordpress
tar czf - wp-content | (cd /tmp; split -b 15m - backup.tgz.)
 
cd /tmp
for FILE in backup.tgz.*
do
uuenview -b -m hoge@tecking.org\
 -s "WP backup [$DATE]" $FILE
done
 
rm -f backup.tgz.*

サーバの時刻合わせ

NTPサーバとの同期をとれるよう ntpdate をインストール（最初から入ってたかも）。

sudo apt-get install ntpdate

1時間に1回、NTPサーバに問い合わせてシステム時刻合わせ＋ハードウェア時刻合わせをするよう /etc/cron.hourly/ntpdate に以下のように記述します。

#!/bin/sh
 
ntpdate ntp.nict.jp
hwclock -w
 
echo ''
echo 'system clock is...'
date
echo ''
echo 'hardware clock is...'
hwclock
echo ''

ファイルに実行権を与えておくのをお忘れなく。

/etc/php5/apache2/php.ini

HTTPレスポンスヘッダに X-Powered-By を含まないようにするために

-expose_php = On
+expose_php = Off

と書いてApache2をリロード。デフォルトがOffだといいのにね。

現サーバ（さくらのレンタルサーバ スタンダード）から新サーバ（さくらのVPS）へデータを移すため

• 現サーバ内の /wp-content 以下の全ファイルを新サーバにコピー
• データベースの内容をエクスポート→新サーバにてインポート

という作業を行います。

当初は

1. phpMyAdminでデータベースを新規作成
2. 現サーバのWordPressインストールディレクトリ以下の全ファイルを新サーバにコピー（/home/hoge/www/fuga にインストールするとします）
3. 現サーバのデータベースの内容をエクスポート→新サーバのデータベースにインポート（phpMyAdmin利用がお手軽）
4. 新サーバ内の wp-config.php を適宜修正

という手順でなんとかなると思ったのですがなんともなりませんでした。
（今思えば .htaccess の設定がまずかったような気がする）

そういうわけで、新サーバにいったんWordPressをインストール。/wp-content 以下の全ファイルを現サーバからコピーした後、新サーバのphpMyAdminにてインポートする方法で移行を行いました。

インポートファイルの上限がデフォルトでは2MBになっているはずです。エクスポートファイルが大きい場合このままではphpMyAdminでインポートできないので /etc/php5/apache2/php.ini をこんな感じで書き換えてApache2をリロードしましょう。

-upload_max_filesize = 2M
+upload_max_filesize = 16M
-post_max_size = 16M
+post_max_size = 32M

受け売りですが設定する数値は
upload_max_filesize < post_max_size < memory_limit
でないとダメよ、ということらしいです。

さて、現状では www.tecking.org にアクセスしても現サーバを読みに行く状態なので（DNSの設定が現サーバを向いている） http://VPSのホスト名/~hoge/fuga で表示されるはずですが……されません

なぜなら、現サーバからインポートした options テーブルのうち

• siteurl
• home

に www.tecking.org と書かれているからでした。

そこでphpMyAdminから options テーブルを覗いてこのように変更。

• siteurl

  http://VPSのホスト名/~hoge/fuga

• home

  http://VPSのホスト名/~hoge

表示されたでしょうか？　おそらくプラグインが全部無効になっているはずなので、管理パネルから適宜有効化してください。

なお、私のようにsiteurlとhomeが異なっている〔＝管理パネルの「一般設定」にある「WordPress のアドレス (URL)」と「サイトのアドレス (URL)」が異なっている）場合は、Codex日本語版の『WordPress を専用ディレクトリに配置する』の項もぜひ参考にしてください）

無事に表示されることが確認できたらいよいよ新サーバへ切り替えです。もう一度phpMyAdminから options テーブルを覗き

• siteurl

  http://www.tecking.org/fuga

• home

  http://www.tecking.org

さらに /home/hoge/www/.htaccess を開き以下のようにします。

# BEGIN WordPress
 
RewriteEngine On
-RewriteBase /~hoge/
+RewriteBase /
RewriteRule ^index\.php$ - [L]
RewriteCond %{REQUEST_FILENAME} !-f
RewriteCond %{REQUEST_FILENAME} !-d
-RewriteRule . /~hoge/index.php [L]
+RewriteRule . /index.php [L]
 
# END WordPress

この時点で http://VPSのホスト名/~hoge でのアクセスはできなくなります（404エラーが出るはず）。受け側の体制はこれでオッケイなので、『ムームーDNS』のコントロールパネルに行き、Aレコードを新サーバのIPアドレスに書き換えましょう。

というような手順を踏んで、ようやく快適環境を手に入れることができたのでした。今まで何度かレンタルサーバの乗り換えをしたことはあるものの、VPSとはいえ専用サーバへの移行は初めてだったのでいい経験になりました。

• ドメイン管理……ムームードメイン
• DNSサーバ……さくらインターネットのDNSサーバ（ns1.dns.ne.jp, ns2.dns.ne.jp）

となっているところを『ムームーDNS』に変更、あわせてGoogle Appsでメールサーバを運用する設定をしていきます。

DNSサーバやメールサーバを外部にもたせたのは

VPSサーバのメンテナンスを簡潔にできるように

とのねらいからです。特にメールサーバは、外部からのメール送信を受け付ける設定にすると踏み台にされるリスクがあるので、運用を外部に任せてしまった方が安心です。HDDが20GB割り当てられてるとはいえ、メールボックスで圧迫してしまうのもどうかと思いましたし。

では今日もいつものお約束。「無保証の技術情報につきご利用は計画的に 」

まずは『ムームーDNS』の設定へ。『ムームードメイン』コントロールパネルから「ムームーDNSセットアップ」に行きカスタム設定を選択。この時点ではAレコードに現在稼働中のサーバ（共用サーバ）のIPアドレスを書いておきます。現サーバから新サーバ（VPS）へのデータ移設が終わったことを確認してからAレコードのIPアドレスを更新する、というわけです。

レコードの設定をしたら、さくらから『ムームーDNS』へとDNSサーバを変更。

設定が完了しました。

DNSの情報が浸透したところでGoogle Appsの設定画面へ。Google Appsには機能制限付きの無料版と、メールボックス増量や高い動作保証率が確保されている有料版がありますが、あくまで個人ブログなので無料版を選択。

Google Apps はグループによるコミュニティ形成を支援します – Google Apps
http://www.google.com/apps/intl/ja/group/

ウィザードに沿っていくと、ドメインの所有者であることを確認するためにCNAMEレコードの追記を求められます。『ムームーDNS』の設定画面にて追記し、Google Appsのウィザードを進めます。こんどはメールの配信設定です。

ページにMXレコードの設定値が書かれているので『ムームーDNS』のコントロールパネルに転記します（なお、画像の「MXサーバアドレス」の最後にあるピリオドは『ムームーDNS』では不要でした）。

また、迷惑メール防止のためのSPFレコードを、Google Apps ヘルプの「SPF レコードの作成」を参考に以下のように記述します。

v=spf1 include:_spf.google.com ~all

これにてDNSサーバとGoogle Appsのセッティングは完了。

• www.tecking.orgへのアクセス……現サーバ（さくらのレンタルサーバ）
• hoge@tecking.orgへのメール……Google Apps

へと振り分けられることになりました。

では今回もお約束の一言。「無保証の技術情報につきご利用は計画的に 」

この後、当サイト以外にもいくつかのサイトをVPSに同居させる予定ですが、基本的には以下の手順で進めることになります。あくまで自分流のやり方なのでご参考までに。

1. サイトごとにユーザディレクトリを作成
2. 1.の中に www と log ディレクトリを作成（.ssh ディレクトリと併せ /etc/skel にひな形を入れておくとあとあと便利）
3. /etc/apache2/sites-available に設定ファイルを作る
4. sudo a2ensite を実行
5. Apacheを再起動

以下、ポイントを絞ってメモを置いておきます。

今回の環境下でのApache2は

• ユーザ……www-data
• グループ……www-data

で稼働しているので 2. と 3. の間で

• 新規ユーザを www-data グループに登録（sudo usermod -G www-data hoge）
• www ディレクトリと log ディレクトリのグループを www-data にする
• www ディレクトリと log ディレクトリのパーミッションを再帰的に2775とする

ことが必要になります。

以上が終わったと仮定して 3. の手順に進みましょう。バーチャルホストの設定ファイルは /etc/apache2/sites-available 内に作ります。ファイル名は default 以外なら何でもオッケイですが、ここでは 001-tecking.org としました。

/etc/apache2/sites-available/001-tecking.org

<VirtualHost *:80>
        ServerAdmin webmaster@tecking.org
        ServerName www.tecking.org
        ServerAlias tecking.org
 
        DocumentRoot /home/hoge/www
        <Directory />
                Options FollowSymLinks
                AllowOverride None
        </Directory>
        <Directory /home/hoge/www>
                Options -Indexes FollowSymLinks ExecCGI
                AllowOverride All
                Order allow,deny
                allow from all
                AddHandler cgi-script .cgi .pl
        </Directory>
 
        ErrorLog /home/hoge/log/error.log
        LogLevel warn
 
        CustomLog /home/hoge/log/access.log combined
 
        UserDir disabled
</VirtualHost>

ファイルができたら

sudo a2ensite 001-tecking.org
sudo /etc/init.d/apache2 reload

で、ひとまず待機（この時点ではまだ www.tecking.org の行き先は旧サーバです）。

では次回、いよいよDNSの設定書き換えに進みます。まずはメールサーバの移行から。