WordPress はユーザ数が多いだけに、必要なものはたいていプラグインとして用意されている非常に使いやすいCMSだと思いますが、毎回動的にしかページを作れないという点にはちょっと不満を持っていました。

nginx や Vernish などのプロキシサーバを別に立ててキャッシュさせる方法を試そうと思っていたのですが、はまりポイントが多いらしく躊躇していました。そんな時に Really Static というプラグインを見つけたときから、今回の話は始まります。

Really Static プラグインの問題点

Really Static プラグインは、ブログの記事の HTML を PHP の curl 関数でダウンロードして static フォルダの中に置いておき、それ以降は PHP で動的に HTML を作るのではなく、静的な HTML ファイルを返す、といった事をしてくれるプラグインです。ちょうど、Ruby on Rails のページキャッシュみたいなイメージですね。

インストールも設定も難しくなく、HTML のダウンロードも WP-cron で少しずつ行われるため、完全に WordPress 内に閉じた環境で実現できるすぐれたプラグインだと思いますが、（私にとっては）ひとつだけ大きな欠点がありました。

それは、Really Static プラグインがサイトの構造(URL)を変えてしまうことでした。
例えば、http://blog.bluegold.me/sample という URL の記事に対して、Really Static の導入後にアクセスすると http://blog.bluegold.me/static/sample.html に 301 redirect されてしまいます。
さらには他のページに書かれたリンクも静的ファイルの URL を直接さすように変更されてしまうので、一度導入してしまうと、後で使うのをやめるときに元に戻すのが難しくなってしまうのではないかと思いました。

最初は Really Static プラグインに手を入れて、リンクの URL を変更させないようにしようと思ったんですが、コードを読むと仕組みは意外と単純だったので、Wordpress に統合することを考えなければ、nginx の try_files だけで、似たようなことが出来ることに気がつきました。

nginx の機能を使う

nginx の try_files はリクエストを処理する際に実際のファイルを探す順番を記述する nginx に固有の設定項目で、Apache では mod_rewrite の複雑なルールを駆使して実現できるようなことをシンプルなルールで記述できるようにしたものです。

現在のこのブログの nginx.conf には以下のような記述がされています。

location {
  gzip_static on;
#  try_files /system/maintenance.html /static/$uri/index.html $uri /index.php?q=$uri&$args;
  try_files /system/maintenance.html /static/$uri/index.html$args $uri /index.php?q=$uri&$args;
}

具体的な設定は WordPress のパーマリンクの設定で変わります。
$uri にはリクエストされた URL のパスの部分が入っています。リクエストを処理する際は以下を順番に調べていって、最初に見つかったものを返します。

※ 2011/01/30 追記
静的HTML化した投稿を表す /static/$url/index.html には $args も付けておかないと、プレビューが出来ませんでしたので修正しました。

• メンテナンス画面(/system/maintenance.html)
• 今回追加した静的HTMLのキャッシュ
• css や画像などの静的ファイル
• それ以外は WordPress に処理を渡す

この設定だけで静的なHTMLファイルの配信は出来るようになります。

静的HTMLの作成

あとはブログの各記事を HTML としてダウンロードするだけです。

$ wget -r --follow-tags=a http://blog.bluegold.me

（あくまでも例なので、自分のサイト意外にはやらないでくださいね。）

静的HTMLに変換しておくことで、このくらい速くなりました。(それぞれ３回試行)

実はこのブログは WPtouch プラグインも使っているので、このままでは iPhone 用の画面が表示されません。
この対処法はまた次回。

前回（と言っても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

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も有効になっています

nginx のバージョン 0.7 系が stable になっていたので、サーバソフトウェアのアップデートを行いました。（久しぶりのブログの更新は OpenSolaris 2009.06 について書こうと思ってたんですが、これはまた後で。。。）

インストールしたのは nginx 0.7.59 です。リリースのアナウンスが 25 May 2009 なので、2週間くらい前に出たばかりだったようです。 0.6系と0.7系の間の変更点についてまとまっている資料を探したのですが、見つかりませんでした。

Change Log を見るとかなりの修正箇所があるようですが、大きくまとめると以下の機能が増えているようです。

*) caching of proxied and FastCGI servers;
*) "try_files" directive;
*) the "location" and "server_name" directives support captures in regular expressions;
*) XLST and image filters;
*) a preliminary IPv6 support;
*) nginx/Windows.

WindowsサポートとIPv6、あまり関係なさそう。。。

try_filesはファイルを探す順番を指定するディレクティブで、例えば「あるファイルが存在する場合はメンテナンス画面を表示する」ような場合、今までは if 文をいくつか書いて条件分岐させていたのをすっきりと記述することが出来るようです。設定例を見るといろいろな応用が出来るようです。

インストールはいつもの通り

./configure --with-http_stub_status_module
                   --with-http_gzip_static_module
                   --with-cc-opt='-O3' 
make
make install

だけで大丈夫でした。

ただ、私の環境ではなぜか configure が途中で失敗していて、しばらくはまりました。結局は .bash_profile で環境変数 CC と CFLAGS を指定していたのが原因でした。nginx の configure スクリプトは autoconf で作られたものでは無いので、予想もつかないところが問題になるなぁ。

nginx 0.6 系で使用していた nginx.conf で起動させたところ、2点ほど問題がありました。

1. gzip_types に text/html を設定していると警告が出る。

   gzip_types text/plain text/html text/css application/x-javascript text/xml application/xml application/xml+rss text/javascript;
   

   0.6系では上のような設定で問題ありませんでしたが、0.7 では以下の警告が出ます。

   duplicate MIME type “text/html” in /etc/nginx/nginx.conf

   text/html は暗黙的に設定されているようなので、以下のように修正。

   gzip_types text/plain text/css application/x-javascript text/xml application/xml application/xml+rss text/javascript;
   

2. 特定のPHPファイルだけ BASIC認証させていたが、PHPとして実行されなくなった。

   WordPress のログインページを BASIC 認証をさせるために、以下のような設定をしていました。

       location /wordpress/wp-login.php {
           auth_basic "secret";
           auth_basic_user_file htpasswd;
       }
   

   nginx 0.6 系では BASIC 認証後に wp-login.php が実行されていましたが、0.7系では BASIC認証はされるものの、PHPファイルが実行されずにソースファイルがそのまま転送されてきました。

   どのように修正すべきか分からなかったので、以下のように fastcgi の設定を入れて ad hoc に修正しました。

       location /wordpress/wp-login.php {
           auth_basic "secret";
           auth_basic_user_file htpasswd;
   
           fastcgi_pass   127.0.0.1:9000;
           fastcgi_index  index.php;
           fastcgi_param  SCRIPT_FILENAME  $fastcgi_script_name;
           include        fastcgi_params;
       }
   

   こういうケースでは今後は try_files ディレクティブを使えって事なんでしょうね。

nginxからphpを利用するには、FastCGIを有効にしてphpをビルドしておく必要があります。
php-5.2.6 を以下のようにビルドしました。

./configure  
    --with-curl=/usr --enable-fastcgi 
    --enable-mbstring --enable-zend-multibyte 
    --enable-mbregex --with-mysql 
    --with-mcrypt --with-mhash 
    --with-openssl --with-gd 
    --enable-gd-native-ttf --enable-gd-jis-conv 
    --with-jpeg-dir=/usr --with-xpm-dir=/usr 
    --with-freetype-dir=/usr
make
make install

メールで記事を投稿する為に openssl と gd の関係のオプションを追加してます。
openssl は gmail に対して POP で接続する為に、gd はKtai Entryで画像を添付したメールを処理するのに必要でした。

FastCGIのプロセスを以下のように起動します。

/usr/local/bin/php-cgi -q -b 127.0.0.1:9000

127.0.0.1:9000 は FastCGI の接続を待ち受ける IPアドレスとポート番号です。
この値は環境に合わせて別の物に変更する事が可能です。

続いて nginx 側の設定ファイルを作成します。

前回の記事で基本的な設定は nginx.conf に書いてあるので、ここでは VirtualHost の設定だけを記述します。

phpをFastCGIで実行するのに最低限必要な設定はこれだけです。

server {
    listen       80;
    server_name  bluegold.me blog.bluegold.me;
    root   /var/www/blog;
    index  index.php index.html index.htm;
<p>    location ~ \.php$ {
        fastcgi_pass   127.0.0.1:9000;
        fastcgi_index  index.php;
        fastcgi_param  SCRIPT_FILENAME  /var/www/blog/$fastcgi_script_name;
        include        fastcgi_params;
    }
}

127.0.0.1:9000 の部分は FastCGI のプロセスのオプションと同じ値を設定します。

前回紹介したnginx.conf についてもう少し掘り下げて説明します。

ログフォーマット

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

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

nginx は良い所のたくさんあるソフトウェアですが、新しいだけに nginx のデフォルトのログフォーマットのままではAWStatsなどのログ解析ソフトに読み込ませる事ができません。そこで Apache の combind フォーマットと同じになるように設定しています。

この設定はGoogleで検索して見つけたのですが、nginx のバージョンが違うのかそのままでは AWStats や Webalizer でエラーになった為、多少変更しています。$request と $status をダブルクォーテーションで囲む必要がありました。

VirtualHost設定

nginxの設定はとても簡単で、単純な VirtualHost の設定は以下のような少ない記述だけで十分です。

    # error catch
    server {
        listen       80;
        server_name _;
        root   /var/www/temp;

        index  index.html;

        access_log  /var/log/nginx/temp-access.log  main;
    }

root を DocumentRoot, index を DirectoryIndex と読み替えれば、Apacheの設定ができる人にはほぼ説明がいらないくらいだと思います。”server_name _;”は全てのリクエストを受け付けるVirtualHostで Host: ヘッダの指定されていないリクエストなどの他の VirtualHost が処理しないリクエストがこの VirtualHost に回ってきます。当然、サービスを提供する VirtualHost には適切な server_name を設定しておきます。

脆弱製のあるサーバを探しているスキャナの多くは IP アドレスを手がかりにサーバに接続してくるので、このような設定にしておく事で、スキャナのリクエストを「何も無い VirtualHost」に閉じ込めてしまう事ができます。実際にこのホストにも phpMyAdmin や xampp の管理画面を探すリクエストが来ています。

この設定は、codered が流行した頃に大量のアタックのログを本来のサービスのログから分離する為に始めたんですが、あまり一般的じゃないのかな。

せっかく自宅にサーバを構築するので、会社では触らないソフトを使用してみる企画。

第一回はWebサーバとしてnginx を取り上げます。

nginx（えんじん えっくす）はロシアの人が作っているWebサーバで、軽量高速が特徴らしい。 WordPressの本家 でも使っているようなので、相性も良いだろうと言う事で。

nginx をビルドする

tarball を取ってきて普通に configure, make, make install だけです。

tar zxvf  nginx-0.6.32.tar.gz
cd  nginx-0.6.32
./configure --with-openssl=/usr --with-http_stub_status_module
make
sudo paco -D make install

nginx の設定

nginx.conf というファイルを編集します。nginx には Apache の .htaccess に相当する設定ファイルは無いようなので、基本的には全ての設定はこのファイルに書く事になります。シンプルと言えばシンプルですが、複数の Virtual Host の設定を１つのファイルに記述すると見通しが悪くなるので、設定ファイルを複数のファイルに分けて　nginx.conf から include する事もできるようになっています。

試行錯誤した結果、このサイトの現在の nginx.conf は下のようになっています。

user  nobody;
worker_processes  3;

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

pid        /var/run/nginx.pid;


events {
    worker_connections  1024;
    use epoll;
}


http {
    include       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" "$gzip_ratio"';

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

    gzip on;
    gzip_http_version 1.0;
    gzip_comp_level 2;
    gzip_proxied any;
    gzip_min_length 1100;
    gzip_buffers 4 8K;
    gzip_types text/plain text/html text/css application/x-javascript text/xml application/xml application/xml+rss text/javascript;

    sendfile       on;
    tcp_nopush     on;
    tcp_nodelay    off;

    keepalive_timeout  65;

    client_max_body_size 10M;

    # error catch
    server {
        listen       80;
        server_name _;
        root   /var/www/temp;

        index  index.html;

        auth_basic "secret";
        auth_basic_user_file /var/www/htpasswd;

        access_log  /var/log/nginx/temp-access.log  main;
    }

    # load the virtual server settings
    include /usr/local/nginx/conf.d/*.conf;
}

細かい設定の話は次回