URLの切替には自作のプラグインを使っています。記事にした当時は stylesheet_uri と template_directory_uri の置き換えをするだけのものでしたが、今は WP_PLUGIN_URL も置換えて、プラグインが追加するスタイルや画像も CloudFront から配信しています。

ここまではわりと簡単に実装できていたのですが、メディアライブラリ(uploads ディレクトリ)に置いた画像ファイルは記事の中身を書き換える必要があるため、なかなか手を出せずに1年くらい放置していましたが、最近、WordPress Amazon S3 Plugin というものがあるのを知り、さっそく試してみました。

このプラグインのセットアップは簡単で、plugins ディレクトリに置いて有効化したあとで、Amazon S3 の認証情報と画像を置くバケツ名を指定するだけです。

設定が完了した後はしばらく待っていると、wp-cron の仕組みを使い、誰かがアクセスしてきた時にバックグラウンドで画像ファイルを Amazon S3 にアップロードしていきます。(アップロードする画像はキューに入れられ、順番に処理されていくようです。)

画像ファイル毎に Amazon S3 へのアップロード状況が記録され、正常に保存された画像ファイルの URL は次回に表示される時から Amazon S3 の URL に置換えられます。

非常に簡単に使えて効果の高いプラグインなのですが、このブログの環境ではいくつか問題がありました。

画像ファイルが完全URLで指定されている事が想定されている。

このプラグインでは画像ファイルへの URL が http:// から始まる完全 URL で書かれている事を想定しているのですが、当ブログでは、ある記事では完全 URL、別の記事ではルート相対URL、という感じで記事ごとに画像の URL の書き方がバラバラでした。
このため、画像への URL を探す正規表現にマッチしない画像がたくさん出てきてしまいました。

メディアライブラリから画像を「投稿に挿入」していれば、完全URLで書かれるので普通に使っていれば問題は無かったはずなんですが。。。

しかたがないので、これはプラグインのソースに手を入れてルート相対URLでも書き換えられるように修正しました。

CloudFront の URL に対応していない。

このプラグインは画像ファイルのURLを http://>バケツ名<.s3.amazonaws.com という場所に変更するのですが、私のデータは Amazon S3 の中でも北米東海岸のサーバに置かれているため、ファイルの送信にちょっと時間がかかります。どうせなら国内の CloudFront のサーバから配信したいので、以下のようにソースを修正しました。wp-cdn.bluegold.me はヂストリビューションに付けた CNAME です。

*** 212,218 ****
  if (file_exists ( $mediaInfo [ 'cache' ] ) === TRUE) {
          $fileContents = file_get_contents ( $mediaInfo [ 'cache' ] );
          if ($fileContents == 'done') {
!           $cdnUrl = "http://{$this->s3BucketName}.s3.amazonaws.com/" . $mediaInfo [ 'path' ];
            $the_content = str_replace ( $mediaInfo [ 'url' ], $cdnUrl, $the_content );
          }
  } else {
--- 214,221 ----
 if (file_exists ( $mediaInfo [ 'cache' ] ) === TRUE) {
         $fileContents = file_get_contents ( $mediaInfo [ 'cache' ] );
         if ($fileContents == 'done') {
! //       $cdnUrl = "http://{$this->s3BucketName}.s3.amazonaws.com/" . $mediaInfo [ 'path' ];
!           $cdnUrl = "http://wp-cdn.bluegold.me/" . $mediaInfo [ 'path' ];
             $the_content = str_replace ( $mediaInfo [ 'url' ], $cdnUrl, $the_content );
         }
 } else {

このプラグインは非常に簡単に使えるので、Amazon S3 のアカウントを持っている人にはお勧めできますね。

前回（と言っても1年半前か） までで nginx と PHP の fast-cgi のビルドと設定が終わったので、OS の起動時に自動的に起動するようにサービスとして登録を行います。

OpenSolaris ではサービスの管理に SMF という仕組みを使用しています。SMF はサービスの依存関係を記述できたり、サービスの起動を監視して自動的に再起動してくれたりと、Linux などで使われている /etc/init.d の rc スクリプトに比べるとメリットがありますが、コマンドが独自だったり、自分で SMF にサービスを登録するには manifest と呼ばれる XML ファイルを書く必要があるので、慣れるまではハードルがあります。（この辺は Mac OS X の launchd と似ている。）

以下が、私が nginx を管理するために作成した nginx.xml です。

<?xml version='1.0'?>
<!DOCTYPE service_bundle SYSTEM '/usr/share/lib/xml/dtd/service_bundle.dtd.1'>
<service_bundle type='manifest' name='export'>
  <service name='network/nginx' type='service' version='0'>
    <create_default_instance enabled='true'/>
    <single_instance/>
    <dependency name='fs' grouping='require_all' restart_on='none' type='service'>
      <service_fmri value='svc:/system/filesystem/local'/>
    </dependency>
    <dependency name='net' grouping='require_all' restart_on='none' type='service'>
      <service_fmri value='svc:/network/loopback'/>
    </dependency>
    <exec_method name='start' type='method' exec='/usr/local/sbin/nginx -c /usr/local/conf/nginx.conf' timeout_seconds='60'>
      <method_context working_directory='/usr/local/logs'>
        <method_credential user='root' group='root'/>
        <method_environment>
          <envvar name='PATH' value='/usr/bin:/bin:/usr/local/bin'/>
        </method_environment>
      </method_context>
    </exec_method>
    <exec_method name='stop' type='method' exec=':kill' timeout_seconds='60'>
      <method_context/>
    </exec_method>
  </service>
</service_bundle>

このファイルを以下のように SMF に登録します。

# svccfg -v import nginx.xml

同様に PHP の FastCGI のプロセスも SMF に登録します。

<?xml version="1.0"?>
<!DOCTYPE service_bundle SYSTEM "/usr/share/lib/xml/dtd/service_bundle.dtd.1">
<service_bundle type="manifest" name="php-fcgi">
 <service name="network/php-fcgi" type="service" version="0">
   <create_default_instance enabled="true"/>
   <single_instance/>

   <dependency name="net" grouping="require_all" restart_on="none" type="service">
     <service_fmri value="svc:/network/loopback"/>
   </dependency>

   <exec_method name="start" type="method" exec="/usr/local/sbin/php-fcgi.sh" timeout_seconds="60">
     <method_context working_directory="/usr/local/www">
      <method_credential user="php" group="webservd" privileges="basic,net_privaddr"/>
      <!--method_credential user="root" group="root" /-->
       <method_environment>
         <envvar name="PATH" value="/usr/php/5.2/bin:/usr/local/sbin:/usr/bin:/bin" />
       </method_environment>
     </method_context>
   </exec_method>

    <exec_method name='stop' type='method' exec=':kill' timeout_seconds='60'>
      <method_context/>
    </exec_method>

 </service>
</service_bundle> 

この xml も同じように svccfg コマンドで登録します。

起動用の shell スクリプトはこちらのサイトのものを、ほぼそのまま使っています。

#!/bin/bash

LC_ALL=ja_JP.UTF-8

#FastCGI Webserver path
FCGI_WEB_SERVER_ADDRS="127.0.0.1"

## ABSOLUTE path to the PHP binary
PHPFCGI="/usr/php/bin/php-cgi"

## tcp-port to bind on
FCGIPORT="9000"

## IP to bind on
FCGIADDR="127.0.0.1"

## number of PHP children to spawn
PHP_FCGI_CHILDREN=5

## number of request before php-process will be restarted
PHP_FCGI_MAX_REQUESTS=1000

# allowed environment variables sperated by spaces
ALLOWED_ENV="PATH"

## if this script is run as root switch to the following user
USERID=webservd

################## no config below this line

ALLOWED_ENV="$ALLOWED_ENV PHP_FCGI_CHILDREN"
ALLOWED_ENV="$ALLOWED_ENV PHP_FCGI_MAX_REQUESTS"
ALLOWED_ENV="$ALLOWED_ENV FCGI_WEB_SERVER_ADDRS"

if test x$UID = x0; then
  EX="/bin/su -m -c \"$PHPFCGI -q -b $FCGIADDR:$FCGIPORT\" $USERID"
else
  EX="$PHPFCGI -b $FCGIADDR:$FCGIPORT"
fi

echo $EX

# copy the allowed environment variables
E=

for i in $ALLOWED_ENV; do
  E="$E $i=${!i}"
done

# clean environment and set up a new one
nohup env - $E sh -c "$EX" &

サービスが SMF に登録できれば、svcadm コマンドで起動停止を切り替える事ができます。

起動

# svcadm enable nginx
# svcadm enable php-fastcgi

停止

# svcadm disable nginx
# svcadm disable php-fastcgi

正確には Redmine が原因なのかどうかは判明していませんが、OpenSolaris 上に構築した Redmine が起動後何時間かすると500 Internal Errorを返すようになってしまいました。

Redmine は以下のような環境で動かしています。

• Redmine 0.9.3
• OpenSolaris 2009.06
• Ruby 1.8.7-p249
• Rails 2.3.5
• Unicorn 0.97.0
• nginx 0.7.65

Ruby は /opt/sunstudio12.1/bin/cc(Sun Studio Express 12)でビルドしています。

#!/bin/sh

while `/bin/true`
do
    http_code=`curl --insecure -w "%{http_code}" -s -o /dev/null https://redmine/login`
    ts=`date +"%Y/%m/%d %H:%M:%S"`

    if [ $http_code -eq 200 ]; then
        echo $ts OK
        sleep 300
        continue
    fi

    cd /var/www/redmine
    pid=`cat tmp/pids/unicorn.pid`

    kill -USR2 $pid
    sleep 5
    kill $pid

    echo $ts unicorn $pid reloaded.
done

exit 0

Xenのディスクイメージファイルは以下のように固定ディスクをそのままファイルに移したような構造になっています。

# file test.img
test.img: x86 boot sector; partition 1: ID=0x83, active, starthead 1, startsector 63, 208782 sectors; partition 2: ID=0x82, starthead 0, startsector 208845, 2104515 sectors; partition 3: ID=0x83, starthead 0, startsector 2313360, 18651465 sectors, code offset 0x48

なので、基本的にはループバック・デバイスとしてマウントする事が可能です。
ただし、ディスクイメージはパーティションに区切ってあると思いますので、その分にひと手間ひつようです。

基本的な作業の流れは以下のとおり。

1. losetup コマンドでディスクイメージファイルをループバック・デバイスに割り当てる。
2. kpartx コマンドでディスクイメージ内の各パーティションにデバイスファイルを割り当てる。
3. 必要なパーティションのデバイスファイルを mount コマンドでマウントする。

losetup コマンドでディスクイメージファイルをループバック・デバイスに割り当てる。

losetup -fコマンドで空いているループバック・デバイスを探して、そのデバイスにイメージファイルを割り当てます。

# losetup -f
/dev/loop0
# losetup /dev/loop0 /var/lib/xen/images/test.img
# losetup -a
/dev/loop0: [0900]:153944114 (/var/lib/xen/images/test.img)

kpartx コマンドでディスクイメージ内の各パーティションにデバイスファイルを割り当てる。

ループバック・デバイスに割り当てた仮想ディスクにパーティションの状況をfdiskコマンドで調べます。

# fdisk /dev/loop0

このディスクのシリンダ数は 1305 に設定されています。
間違いではないのですが、1024 を超えているため、以下の場合
に問題を生じうる事を確認しましょう:
1) ブート時に実行するソフトウェア (例. バージョンが古い LILO)
2) 別の OS のブートやパーティション作成ソフト
   (例. DOS FDISK, OS/2 FDISK)

コマンド (m でヘルプ): p

Disk /dev/loop0: 10.7 GB, 10737418240 bytes
255 heads, 63 sectors/track, 1305 cylinders
Units = シリンダ数 of 16065 * 512 = 8225280 bytes

デバイス Boot      Start         End      Blocks   Id  System
/dev/loop0p1   *           1          13      104391   83  Linux
/dev/loop0p2              14         144     1052257+  82  Linux swap / Solaris
/dev/loop0p3             145        1305     9325732+  83  Linux

コマンド (m でヘルプ): q

3つのパーティションが存在することが確認できます。
kpartx -aでそれぞれのパーティションをデバイスファイルに割り当てます。
/dev/mapperディレクトリの下に新たなデバイスファイルが作成されます。

# kpartx -a /dev/loop0
# ls -l /dev/mapper/
合計 0
crw------- 1 root root  10, 62  2月 24 00:07 control
brw-r----- 1 root disk 253,  0  3月  5 22:07 loop0p1
brw-r----- 1 root disk 253,  1  3月  5 22:07 loop0p2
brw-r----- 1 root disk 253,  2  3月  5 22:07 loop0p3

仮想ディスクでLVMを使っているとここから先がめんどくさいので、私はXenの仮想ディスクではLVMは使いません。

必要なパーティションのデバイスファイルを mount コマンドでマウントする。

あとは通常のディスクと同じようにマウントするだけです。

# mount -t ext3 /dev/mapper/loop0p1 /mnt/tmp
# ls -l /mnt/tmp
-rw-r--r-- 1 root root  952782 11月  4 08:46 System.map-2.6.18-164.6.1.el5xen
drwxr-xr-x 2 root root    1024 11月  9 15:51 grub
-rw------- 1 root root 2383144 11月  9 15:51 initrd-2.6.18-164.6.1.el5xen.img
drwx------ 2 root root   12288  6月 17  2009 lost+found
-rw-r--r-- 1 root root   80032  3月 13  2009 message
-rw-r--r-- 1 root root  107413 11月  4 08:47 symvers-2.6.18-164.6.1.el5xen.gz
-rwxr-xr-x 1 root root  817164 11月  4 09:53 xen-syms-2.6.18-164.6.1.el5
-rw-r--r-- 1 root root  375762 11月  4 06:11 xen.gz-2.6.18-164.6.1.el5

使い終わった後の手順

必要なくなった仮想ディスクを開放するには、逆の手順で行います。

# umount /mnt/tmp
# kpartx -d /dev/loop0
# ls -l /dev/mapper/
合計 0
crw------- 1 root root 10, 62  2月 24 00:07 control
# losetup -d /dev/loop0
# losetup -a
# losetup -f
/dev/loop0

TLSやSSLを使ったウェブサーバーでは一般的には仮想ホストは使えない、という事になっています（何事にも例外はありますが。）仮想ホストは HTTP のリクエストヘッダの Host フィールドの値を元に振り分けられますが，HTTPのリクエストを出すよりも手前の TLS/SSL のハンドシェイク時にサーバ証明書の検証が行われるので，クライアントが接続しようとしているホスト名とサーバ証明書のホスト名が異なってしまい，不正な証明書と表示されてしまいます。

SNIは接続しようとしているホスト名を、クライアントからサーバに伝えるための仕様です。（ホスト名はハンドシェイク前に伝えないと行けないので、平文で送られる事になりますが。。。）これ自体は素晴らしいのですが，Windows XP の IE がサポートしていないので今ひとつ広まっていません。

まずは SNI を使わないで仮想ホストを設定する場合の例です。

ssl_certificate server_cert.pem;
ssl_certificate_key server_cer.key;
server {
    port 443;
    ssl on;
    server_name host1.example.com;
}
server {
    port 443;
    ssl on;
    server_name host2.example.co.jp;
}

サーバ証明書は1枚しか指定できないので，server_cert.pem には host1.example.com と host2.exacmple.co.jp の双方が記述されている必要があります。ホストが同一のドメインに存在する場合はワイルドカード証明書を使う方法もありますが，例のようにドメインが異なる場合は双方のホスト名をCNもしくはsubjectAltNameに記述します。この方法では仮想ホストが増える場合は証明書を発行し直す必要があります。

次に SNI を使う場合の例です。

server {
    port 443;
    ssl on;
    ssl_certificate host1.example.com.pem;
    ssl_certificate_key host1.example.com.key;
    server_name host1.example.com;
}
server {
    port 443;
    ssl on;
    server_name host2.example.co.jp;
    ssl_certificate host2.example.co.jp.pem;
    ssl_certificate_key host2.example.co.jp.key;
}

仮想ホスト毎に証明書が指定する事ができるようになります。

実際に SNI をサポートしている Firefox などのブラウザでアクセスすると、それぞれ異なる証明書を持つ事が確認できます。

ただ、現在の nginx に固有の問題かもしれませんが，仮想ホスト毎にクライアント証明書による認証の有無を切り替えるのは出来ないみたいです。ssl_verify_client off;な設定の仮想ホストが１つでもあると，クライアント認証を行う仮想ホストに対してもクライアント証明書が送られません。

クライアント認証が必要ない仮想ホストに対してもssl_verify_client optional;を指定すると大丈夫なようですが。（Nginx の Wikiの説明ではoptional ではなく、askになっているので注意が必要です。）

CVS（やSubversion）をバージョン管理システムに使っていた頃はリポジトリの情報を見るのにViewVCを使っていましたが、ViewVCはMercurialをサポートしていません。Mercurial にはウェブ用の管理画面(hgweb/hgwebdir)が付属しているので、別のツールを使うニーズが少ないんでしょうね。

Mercurial のリポジトリ毎に対応する Redmine のプロジェクトが存在するので、そちらを見ればおおよその事は分かるのですが、Redmineのリポジトリブラウザはブランチを意識して作られていないので不便といえば不便です。

hgwebの事は Mercurial への移行を検討していたときにも調べていたんですが、Django, flup, setuptools, ez_setup.py, easy_install, .. とPythonに不慣れな人間にはなじみのない単語が続々と出てきたので、ちょっと敬遠していましたが、ちょっと時間が取れたのでチャレンジしてみました。

hgwebdir のセットアップをする前に必要なソフトウェアのインストールを行います。環境は OpenSolaris 2009.06 で、可能な限り pkg を使ってインストールしていきます。インストールしたのは以下のパッケージです。

SUNWPython26
SUNWPython26-extra
SUNWpython26-setuptools

OpenSolaris 2009.06 のパッケージ管理システムにも Mercurial はありますが、バージョンが 1.1.2 と古く、クライアントの環境と合わないので、最新バージョンを easy_install からインストールします。

$ pfexec easy_install Mercurial
$ hg --version
Mercurial Distributed SCM (version 1.4.2)

Copyright (C) 2005-2009 Matt Mackall <mpm@selenic.com> and others
This is free software; see the source for copying conditions. There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.

次に flup が必要だそうなのでインストールします。

$ pfexec easy_install flup

hgwebdir を FastCGI で動作させるのにはいろいろな方法があるらしいのですが、Python特有のやり方はよく分からないので、lighttpd の spawn-fcgiを使いました。インストールは以下の通り簡単です。

$ wget http://www.lighttpd.net/download/spawn-fcgi-1.6.3.tar.gz
$ gzip -dc spawn-fcgi-1.6.3.tar.gz | tar xvf -
$ cd pawn-fcgi-1.6.3
$ ./configure
$ make
$ pfexec make install

ここまででようやく下準備がおわりました。
hgwebdir.fcgi は /usr/demo/mercurial/hgwebdir.fcgi をコピーして使っています。
UTF-8 で表示するために、HGENCODING の設定を行う部分のコメントをはずしています。

os.environ["HGENCODING"] = "UTF-8"

hgweb.config は単純です。

[paths]
/ = /path/to/repos/*

これを以下のようなスクリプトで起動しています。

#!/bin/sh

LANG=ja_JP.UTF-8
export LANG

FCGI=/opt/local/bin/spawn-fcgi
exec $FCGI -s /tmp/.fcgi_hgwebdir -G webserved -M 0660 ./hgwebdir.fcgi

nginx の設定ファイルは以下のようになりました。
初めて try_files を使ってみましたが、設定がとてもシンプルになりますね。
hgwebdir は PATH_INFO を利用してブラウズするリポジトリを探すようなので、その部分の置き換えにちょっと手を入れています。

server {
    listen       80;
    server_name  hg.example.com;
    root   /path/to/public;
    index  index.html;

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

    location / {
        try_files $uri @hgweb;
    }

    location @hgweb {
        fastcgi_pass   unix:/tmp/.fcgi_hgwebdir;
        fastcgi_read_timeout    5m;
        set $path_info "";
        if ($fastcgi_script_name ~ "^/(.*)$") {
            set $path_info $1;
        }
        fastcgi_param PATH_INFO $path_info;
    }
}

nginxの新しいバージョン(0.7.65)がリリースされていたので，バージョンアップしてみました。

しばらく前に見つかっていたSSLの脆弱製の実験をやろうと、久しぶりに SSL を有効にしたバイナリを作ろうとしたのですが，オプションの設定の仕方を忘れていて苦労しました。また、忘れても大丈夫なようにメモ。

OpenSolaris 2009.06 に含まれるOpenSSLは 0.9.8a と古いので、現時点での最新バージョンであるopenssl-0.9.8lをダウンロードしてきて使いました。今回はSNI(Server Name Indication)を有効にしたいのでenable-tlsextオプションを渡しています。

./config --prefix=/usr/local no-shared enable-tlsext
make
pfexec make install

これだけでもビルドは出来るのですが，OpenSolaris 2009.06 のデフォルトの GCC 3.2.3 ではなく新しい /usr/bin/gcc-4.3.2 を使いたいので，少し手を入れています。

export CC=/usr/bin/gcc-4.3.2
export CFLAGS='-DOPENSSL_THREADS -D_REENTRANT -DDSO_DLFCN -DHAVE_DLFCN_H -m64 -march=native -O3 -Wall -DL_ENDIAN -DMD32_REG_T=int -DOPENSSL_BN_ASM_MONT -DSHA1_ASM -DSHA256_ASM -DSHA512_ASM -DMD5_ASM -DAES_ASM' 
./Configure --prefix=/usr/local no-shared enable-tlsext solaris64-x86_64-gcc
make
pfexec make install

export CC=/usr/bin/gcc-4.3.2した後にconfigスクリプトを実行すると，solaris64-x86_64-gcc-4.3.2 みたいな os:compiler になってエラーになってしまうんですよね。回避方法を探すのに手間取ってしまいました。

次に nginx のビルドですが，普通に configure を実行すると 32bit のバイナリが出来てしまいますので、gcc に渡すオプションも configure に渡します。

./configure --prefix=/usr/local --with-http_stub_status_module --with-http_gzip_static_module --with-http_ssl_module --with-cc=/usr/bin/gcc-4.3.2 --with-cc-opt='-m64 -march=native -O3 -I/usr/local/include ' --with-cpu-opt=amd64 --with-ld-opt='-m64 -L/usr/local/lib -L/usr/lib/amd64'
make
pfexec make install

ビルドした内容を確認

$ file /usr/local/sbin/nginx
/usr/local/sbin/nginx:  ELF 64-bit LSB executable AMD64 Version 1, dynamically linked, stripped

$ /usr/local/sbin/nginx -V
nginx version: nginx/0.7.65
built by gcc 4.3.2 (GCC) 
TLS SNI support enabled
configure arguments: --prefix=/opt/local --with-http_stub_status_module --with-http_gzip_static_module --with-http_ssl_module --with-cc=/usr/bin/gcc-4.3.2 --with-cc-opt='-m64 -march=native -O3 -I/usr/local/include' --with-cpu-opt=amd64 --with-ld-opt='-m64 -L/usr/local/lib -L/usr/lib/amd64'

SNIも有効になっています

3ヶ月ほど前に、10年以上使い続けたCVSからMercurialにソース管理を移行しました。（Subversion は手になじまなかった。）

移行して不便に感じるのはViewVCが使えなくなった事くらいで、普段はあまり違いは感じていませんが、１つだけ直感的にやり方が分からなくて困る事があります。

ワーキングディレクトリで作業中に誤って必要なファイルを削除してしまった場合、例えば

$ ls -l
total 8
-rw-r--r--  1 user  staff  1345 Jan 16 22:33 Makefile
drwxr-xr-x  5 user  staff   170 Jan 16 22:45 help/
drwxr-xr-x  5 user  staff   170 Jan 16 22:33 tutorial/
$ rm Makefile

としてしまった場合、必要なファイルが存在しない事は hg status コマンドで調べる事ができます。

$ hg status
! Makefile

CVS(やSubversion)では、誤って削除したファイルはcvs update(svn up)で元に戻すことができますが、Mercurial ではそうはいきません。

$ hg update
ファイル状態: 更新数 0、マージ数 0、削除数 0、衝突未解決数 0
$ ls -l
total 0
drwxr-xr-x  5 user  staff  170 Jan 16 22:45 help/
drwxr-xr-x  5 user  staff  170 Jan 16 22:33 tutorial/

このように削除されたファイルはそのままです。

Mercurial では update コマンドはワーキングディレクトリのリビジョンを変更するコマンドなので、この動きで正しいらしいのですが、CVS等から乗り換えてくるとちょっとビックリします。

このような場合はhg revertを使うのが正しいらしいです。

$ hg revert Makefile
$ ls -l
total 8
-rw-r--r--  1 user  staff  1345 Feb  2 02:41 Makefile
drwxr-xr-x  5 user  staff   170 Jan 16 22:45 help/
drwxr-xr-x  5 user  staff   170 Jan 16 22:33 tutorial/

WireSharkを使ってダンプを解析するためのキャプチャファイルをtcpdumpで保存するためのオプションを毎回忘れてしまうのでメモ。

tcpdump -n -i en0 -s 0 -w dumpfile.cap [filter]

tcpdump -w filenameだけでも、キャプチャファイルは作れるが、デフォルトではキャプチャ用のバッファ(snaplen)が 68バイトと小さく（TCP のヘッダー分のサイズらしい）、あふれたデータを取りこぼしてしまいます。tcpdump で見ている分には必要の無いデータですが、WireShark で「Follow TCP Stream」を見ようとした時に壊れていたりします。

そこでオプション ‘-s’ を指定して snaplen のサイズを大きく設定しています。（0は無制限、と言っても65535バイトくらいしか見た事ない）

(Open)Solarisの場合は悩む事無く、以下のように普通にファイルに保存するだけで大丈夫です。

snoop -r -d bge0 -o dumpfile.cap [filter]

仕事のほうも、しばらくは自宅で開発作業を行うので、今までよりはブログに時間をかけられるんじゃないかなぁ。

自宅に仕事の環境を整えるために、年末年始は４台のＰＣ（ＰＣサーバ２台を含む）のセットアップを行っていました。４台といっても中身は Xen, Solaris Zone, VirtualBox で仮想化してるので時間はかかりました。

OpenSolaris でファイルサーバを作ったので、MacBook の開発環境のバックアップも定期的にそちらに残そうとcrontab -eで編集して保存したところ、意外なエラーが帰ってきました。

crontab: temp file must be edited in place

これまでも Mac で crontab の編集は行っていましたが、エラーになったのは初めてです。

メッセージからすると、vi で編集後のファイルの i-node が変わっているのが原因っぽいですが、.vimrc はもう３年くらいずっと使っているもので大きく変えたりはしていません。Google に聞いてみると以下の設定を追加すれば大丈夫だとの記述を発見しました。

set nowritebackup

が、私の環境ではこの方法ではダメでした。

次に見つけたこのサイトを参考にしたところ、crontab の編集ができるようになりました。

set backupskip=/tmp/*,/private/tmp/*

/private/tmp があるので、この人も Mac を使っているんでしょうね。

このブログは今のところ自宅に置いてあるサーバで運用しています。
手直にあるので管理は簡単なのですが、自宅の回線はアップストリームの帯域幅が大きくないので、ページを表示するさいの画像読み込みの遅延が以前から気になっていました。

このサイトでは以下のように nginx を設定することで、可能な限り静的なコンテンツの使用する帯域幅を小さくしようとしていますが、それでもファイル転送量のほとんどは画像ファイルになっています。

location / {
    if (-f $request_filename) {
        expires 30d;
        break;
    }
}
location ~* ^.+\.(html|css|txt|tar|bmp|rtf|js)$ {
    gzip_static on;
    expires 30d;
}

以前から画像を外部のサイトに置いて転送負荷を減らそうと考え、一部の画像をflickrに置いたりしていますが、これはという解決策がありませんでした。

最近、仕事関係で Amazon のウェブサービスについて調べていてAmazon CloudFrontというサービスがあるのを知り、WordPress のテーマの画像を置いてみたらどうなるのかを調べてみました。

Amazon CloudFront は Amazon の提供するウェブサービスの１つで、いわゆるCDNです。Amazon S3に保存したファイルをインターネット上に分散配置されたキャッシュサーバに置く事で、静的なコンテンツを高速に配信する事ができるようになっています。

有料のサービスなので利用には Amazon Web Service のアカウントが必要になりますが、以下のように安価な価格設定になっているので費用対効果は高いと思います。

United States

$0.170 per GB – first 10 TB / month data transfer out

$0.010 per 10,000 GET Requests

Japan

$0.221 per GB – first 10 TB / month data transfer out

$0.013 per 10,000 GET Requests

Amazon S3 の使い方はいろんな場所で説明されているので省きます。使用しているテーマのディレクトリから画像や css, js ファイルを CloudFront に配備してください。
S3 に置いたファイル（オブジェクト）に対して Everyone の Read 権限を与える必要がある点だけ注意してください。
Firefox のプラグイン S3OrganizerはCloudFront にも対応しているのでお勧めです。

CloudFrontに置いたファイルをWordPressから参照する方法はテーマファイル次第ですが、私のサイトで作ってもらったテーマでは bloginfo(‘template_directory’); と bloginfo(‘stylesheet_url’); の２つの値を変更するだけで大丈夫そうでした。
私はWordPressもPHPも詳しくなく、この二つの値を変更する「正しい方法」が分からなかったため適当にプラグインを書いてみました。
（こうやって野良プラグインが増えていくんだろうな）

プラグインのソースは以下の通りです。

<?php
/*
 * Plugin Name: CloudFront
 * Plugin URI: http://blog.bluegold.me/cloudfront
 * CloudFront plugin is a plugin designed to help you drastically speed up your blog's load time by loading content onto Amazon CloudFront.
 * Version: 0.1
 * Author: Blog Bluegold.me
 * Author URI: http://blog.bluegold.me
 * */

$cdn_base = "__EDIT_HERE__";

function    filter_cdn_css($url) {
    global $cdn_base;
    return $cdn_base . "/style.css";
}

function    filter_cdn_template_dirctory($url) {
    global $cdn_base;
    return $cdn_base;
}

add_filter('stylesheet_uri','filter_cdn_css');
add_filter('template_directory_uri','filter_cdn_template_dirctory');
?>

これを WordPress の wp-content/plugins/cloudfront/cloudfront.php という名前で保存するだけです。

ただ、このままだとGmailが「迷惑メール」と判断したメールがMail.appでは未読メールとして表示されたり、Mail.appでメールを削除した際にGmailのゴミ箱に移動されずに「Deleted Messages」ラベルが付けられる、などの問題が発生します。そこで、Gmail側の「迷惑メール」フォルダなどにMail.appで「メールボックスの用途」を設定しました。これでメール管理をMail.app側に統合化する事ができ、便利に使えるようになりました。

POP3でメールを読んでいた頃はPOPFileを利用して、迷惑メールのフィルタやメールの振り分けを行っていました。Gmailには迷惑メールのフィルタ機能が元から備わっていますが、メールの振り分けをPOPFileほどは柔軟に設定できません。たとえば、会社のメールアドレスには誰かが全員用のエイリアス用に購読したNikkei BPやキーマンズネットのニュースがたくさん送られてくるのですが、単純なルールでこれらをまとめて「ニュース」フォルダに振り分けるのは（ほぼ）不可能です。

そこで、POPFileをIMAP4の環境で使用する方法について調べてみました。

POPFileのIMAPモジュールはPOPモジュールと異なりプロキシではありません。そのため、POPFileを利用するのにメールクライアントの設定を変更する必要はありません。これは良いことですが欠点もあります。プロキシとして動作しない為に、サブジェクトを変更したりX-Text-Classificationヘッダを付加する事ができません。

IMAPモジュールはメールクライアントの動作とは無関係に定期的にIMAPサーバに接続し、メールの本文の内容を判断して適切なフォルダ（Gmailの場合はラベル）に振り分けます。IMAPモジュールはいったん設定を行うと後は自動的に処理を続けるロボットのようなプログラムなので、クライアントPCで動作させるよりは常時稼働しているサーバの上で動かした方が良いのかもしれません。

IMAPモジュールの使い方は公式サイトの説明にある通りですが、Leopard(Mac OS X)で使用するには注意する点がいくつかあります。（POPFile v1.1.0 を使用しています。）

imap.gmail.com

POPFile コントロールセンターの「設定」ページの「IMAPサーバー ホスト名」にGmailのIMAPサーバ名、imap.gmail.com を入力しても接続できずに、以下のエラーがログに残ります。

2008/12/25 23:48:08 10142: IMAP-Client: 136: IO::Socket::SSL error: IO::Socket::SSL: bind: Address family not supported by protocol family
2008/12/25 23:48:08 10142: imap: 1624: Could not CONNECT to server.
2008/12/25 23:48:08 10142: imap: 1493: Could not connect to server.

エラーメッセージをGoogleで検索すると、IPv6が関係しているエラーのようです。Leopard に固有の問題のようですが、「imap.google.com の AAAA レコードが見つかる為に IO::Socket::SSL がサポートしていない IPv6 で接続しようとしている」ためにエラーになっているらしい。将来のバージョンで修正されると思いますが、それまでのワークアラウンドを考えます。

要は、imap.gmail.com　の AAAA レコードが見つかることが原因なので、たとえば、imap.gmail.com の(IPv4の)IPアドレスを調べて、それをIMAPサーバーのホスト名に設定したり、そのIPアドレスを逆引きして得られる実サーバのホスト名を設定すれば、とりあえず使用できるようになります。（今、私の環境から調べるとrv-in-f111.google.comです。）ただ、imap.gmail.comを構成する多数のサーバの中の１台にしか接続できなくなるため、そのうち接続出来なくなるかもしれません。

日本語のIMAPフォルダ名

IMAPモジュールではPOPFileのバケツ毎に振り分けるIMAPのフォルダを設定する必要があります。この設定はPOPFile コントロールセンターの「設定」ページから行いますが、このページは日本語の IMAPフォルダ名に対応していません。たとえば、「迷惑メール」フォルダは「&j,dg0TDhMPww6w-」と表示されます。これは modified UTF-7 というエンコーディングだそうですが、このままでは振り分けるべきフォルダがどれなのかが分かりません。

これも将来のバージョンで修正されると思いますが、当面は以下のような方法で調べるしかないようです。

$ irb -rnet/imap
irb(main):001:0> %w(迷惑メール 下書き 送信済みメール ゴミ箱).each {|key| puts "#{key} -> [Gmail]/#{Net::IMAP.encode_utf7(key)}"}
迷惑メール -> [Gmail]/&j,dg0TDhMPww6w-
下書き 　　-> [Gmail]/&Tgtm+DBN-
送信済みメール -> [Gmail]/&kAFP4W4IMH8w4TD8MOs-
ゴミ箱 　　-> [Gmail]/&MLQw33ux-

クラッシュした時のメッセージを良く読んでみたら、原因が書いてありました。

アプリケーション Mail は予期せず終了しました。この問題は GPGMail プラグインが原因である可能性があります。

GPGMailは Mail.app用の GnuPG のフロントエンドで、会社でやり取りするメールの暗号化に使っています。アップデートを探しに開発元のSen:TEのサイトを見てみた所、

IMPORTANT: You need at least GPGMail d55 since MacOS X 10.5.6; previous versions of GPGMail will crash Mail.

と、とっくに対応されていました。

最新の GPGMail に入れ替えたところ、Mail.app が正常に起動するようになりました。

PHPアクセラレータにはeAcceleratorやAPCなどいろいろとあるようですが、今回は使った事のないXCacheを使ってみます。XCacheはバイトコードのキャッシュの他にPHPの変数をキャッシュする機能があるので、この機能をWordPressで使うように設定も行います。

XCacheのビルドは以下の通り簡単に行うことができます。

wget http://xcache.lighttpd.net/pub/Releases/1.2.2/xcache-1.2.2.tar.gz
gzip -dc xcache-1.2.2.tar.gz | tar xvf -
cd xcache-1.2.2
./configure --enable-xcache
make
make install

php.ini ファイルにXCacheの設定を記述します。
ソースに付属しているサンプルの xcache.ini からあまり変えていません。

[xcache-common]
zend_extension = /usr/local/lib/php/extensions/no-debug-non-zts-20060613/xcache.so

[xcache]
xcache.shm_scheme =        "mmap"
xcache.size  =               22M
xcache.count =                 1
xcache.slots =                8K
xcache.ttl   =             86400
xcache.gc_interval =         600

xcache.var_size  =            2M
xcache.var_count =             1
xcache.var_slots =            8K
xcache.var_ttl   =             0
xcache.var_maxttl   =          0
xcache.var_gc_interval =     300

xcache.test =                Off
xcache.readonly_protection = Off
xcache.mmap_path =    "/dev/zero"
xcache.coredump_directory =   ""
xcache.cacher =               On
xcache.stat   =               On
xcache.optimizer =            On

xcache.size は使用するアプリケーションの種類によって調整した方がよいと思います。XCacheはeAcceleratorなどと違い、キャッシュは全てメモリ上に持つようなので大きめに設定しておいた方が良いかもしれません。

バイトコードのキャッシュは以上の設定でphpのFastCGIを再起動するだけで使用出来ますが、変数のキャッシュを利用するにはアプリケーション側で対応する必要があります。WordPressにはXCache for WordPressというプラグインがあるようですが、最近のバージョンのWordPressでは動作しないようなので、XCache Object Cache Plugin for WordPress 2.5+を使用する事にしました。

インストールは簡単ですが、XCache Object Cache Plugin for WordPressは通常のWordPressのプラグインとはインストールするパスが異なるので注意が必要です。プラグインのファイルは object-cache.php １つだけで、これをWordPressのコンテントディレクトリ（通常は xp-content ディレクトリ）に置きます。私も最初は説明を読まずに他のプラグインと同じように xp-content/plugins ディレクトリに置いて、しばらく悩みました。

このようにバイトコードと変数の双方がキャッシュされている事を確認出来ます。これだけで体感出来る程度には速度が向上するので、導入する価値はあると思います。

暗号化とかは後で考えるとして、とりあえず下のようなスクリプトを書いてみました。

#!/bin/sh

AFIO=/usr/local/bin/afio
MYSQLHOTCOPY=/usr/bin/mysqlhotcopy
SENDMAIL=/usr/sbin/sendmail

WORKDIR=/var/tmp
WWWDIR=/var/www
LOGDIR=/var/log

if [ -f /etc/wp_backup ]; then
    . /etc/wp_backup
fi

if [ ${MYSQL_USER:-nothing} = "nothing" ]; then
    exit 1
fi
if [ ${MAIL_FROM:-nothing} = "nothing" ]; then
    exit 1
fi

function cleanup() {
    rm -rf $WORKDIR/mysql
    rm -f $WORKDIR/$name.afz
    rm -f $WORKDIR/mysql_$name.afz
}
trap "cleanup" EXIT

name=${1:-blog}

if [ ! -d $WORKDIR/mysql ]; then
    mkdir $WORKDIR/mysql
fi

(
echo "BACKUP START: `date`"

# backup mysql
$MYSQLHOTCOPY -u $MYSQL_USER -p $MYSQL_PASSWORD $name $WORKDIR/mysql

cd $WORKDIR/mysql
find $name | $AFIO -ovz -Z -U $WORKDIR/mysql_$name.afz

# backup wordpress
cd $WWWDIR
find $name | $AFIO -ovz -Z -U $WORKDIR/$name.afz

echo "BACKUP FINISHED: `date`"
) >> $LOGDIR/wp_backup.log 2>&1

# send the backup files
(
cat <<__END__
From: $MAIL_FROM
To: $MAIL_TO
Subject: $name backup `date`

blog name: $name
date: `date`

`uuencode $name.afz < $WORKDIR/$name.afz`

`uuencode mysql_$name.afz < $WORKDIR/mysql_$name.afz`

__END__
) | $SENDMAIL -f $MAIL_FROM -t $MAIL_TO

exit 0

バックアップを Gmail に送信する事はできたので問題は解決したかと思ったんですが、Gmail は uuencode の添付ファイルを認識しないんですねぇ。手元の Apple Mail でも認識していないので単に時代遅れなだけか。

もう少し考えねば