引用元: Vulnerability Found in timthumb.php | VaultPress Blog

この脆弱性により、第三者が任意のPHPコードをTimThumbキャッシュディレクトリにアップロードでき、そのコードを実行されてしまいます。

timthumb.php もしくは thumb.php が無くても動作するならこのファイルをサイトから削除するようおすすめします。もし使っていないテーマやプラグインの中にこのファイルがあったら、そのテーマやプラグインのディレクトリごと削除したほうがいいでしょう。

どうしてもこのライブラリを使いたい方は同ページに修正方法が載ってますので参照してください。

nginx.org 上のドキュメントは（たぶんほんとに）これだけです。あとは wiki (http://wiki.nginx.org/Main) で目についたところを訳していきます。

nginx/Windows の利用法
原文: nginx/Windows usage

既知の問題
予定している将来的な拡張

nginx/Windows はネイティブ Win32 API（Cygwin エミュレータレイヤーではなく）を利用しています。いまのところ通知メソッドとしては select メソッドのみが使われていますので、高い性能やスケーラビリティは期待しないでください。このことといくつかの既知の問題のため nginx/Windows はベータバージョンとみなしてください。Unix のバージョンと比べると、XSLT フィルター、画像フィルター、GeoIP モジュール、埋め込み Perl 言語以外でほぼフル機能を備えています。

nginx/Windows をインストールするには、最新の 1.0.4 開発版の zip ファイルをダウンロードしします。開発ブランチには特に Windows 関連のすべての既知の修正が含まれています。次にファイルを展開し、nginx-1.0.4 ディレクトリに行って nginx を起動します。次はドライブ C: ルートディレクトリでの例です:

cd c:\
unzip nginx-1.0.4.zip
cd nginx-1.0.4
start nginx

“tasklist” コマンドラインユーティリティを起動すると nginx のプロセスが見れます:

C:\nginx-1.0.4>tasklist /fi "imagename eq nginx.exe"

Image Name           PID Session Name     Session#    Mem Usage
=============== ======== ============== ========== ============
nginx.exe            652 Console                 0      2 780 K
nginx.exe           1332 Console                 0      3 112 K

プロセスの一つはマスタープロセスで、もうひとつはワーカープロセスです。もし nginx が起動していなければ “logs\error.log” ファイルを調べて原因を見つけてください。もしログファイルが生成されていなかったら、Windows イベントログに原因が記録されているはずです。期待していたページではなくエラーページが表示された場合もやはり “logs\error.log” を調べてエラーの原因を見つけてください。

nginx/Windows は、設定内での相対パス用に nginx/Windows が起動しているディレクトリをプリフィックスディレクトリとして使用します。例えば上の例では、“C:\nginx-1.0.4\” がプリフィックスディレクトリです。設定内でのパスはフォワードスラッシュを使用して Unix スタイルで設定します:

access_log   logs/site.log;
root         C:/web/html;

nginx/Windows はサービスとしてではなく標準的なコンソールアプリケーションとして動作していて、次のコマンドを利用して管理できます:

nginx -s stop	即時終了
nginx -s quit	正常な終了
nginx -s reload	設定を変更し、新しいワーカーを起動し、古いワーカーを正常終了させる
nginx -s reopen	ログファイルの再オープン

既知の問題

• 複数のワーカーを走らせることはできますが、実際はそのうち一つしか動作しません。
• ひとつのワーカーが扱える同時接続は 1024 までです。
• 共有メモリーのサポートが必要なキャッシュやその他のモジュールは Windows Vista 以降では動作しません。こうした Windows のバージョンではアドレス空間レイアウトのランダム化が有効になっているからです。

予定している将来的な拡張

• サービスとしての起動
• 通知メソッドとして I/O 完了ポートの利用
• ひとつのワーカープロセス内での複数のワーカースレッドの利用

文書作成: Igor Sysoev
編集: Brian Mercer
翻訳: DigitalCube Co. Ltd.
監訳:

基本的な HTTP 機能
他の HTTP 機能
メールプロキシサーバ機能
アーキテクチャとスケーラビリティ
テスト済み OS とプラットフォーム

nginx [えんじんえっくす] は Igor Sysoev によって作られた HTTP とリバースプロキシのサーバで、メールプロキシサーバでもあります。Rambler (RamblerMedia.com) を含むロシアの多くの高負荷サイトで５年以上も動いています。Netcraft によると、nginx は 2010 年 4 月時点で 4.70% の人気サイトでサーバーとしてもしくはプロキシとして利用されています。そうした成功例としてはFastMail.FM や WordPress.com があります。

ソースコードは BSD 風の 2 箇条ライセンスでライセンスされています。

基本的な HTTP 機能

• スタティックなインデックスファイルの提供、ファイルディスクリプタキャッシュをオープンする自動インデクシング
• キャッシングで高速化されたリバースプロキシ、シンプルなロードバランシング、フォールトトレランス
• リモートの FastCGI サーバのキャッシングによる高速化サポート、シンプルなロードバランシング、フォールトトレランス
• モジュールアーキテクチャ。フィルタにはgzip、バイトレンジ、チャンク化されたレスポンス、XSLT、SSI、画像リサイズフィルタが含まれます。FastCGI もしくはプロキシ化されたサーバなら、単一ページ内への複数 SSI 封入が並列で処理可能。
• SSL と TLS SNI サポート。

他の HTTP 機能

• 名前ベースと IP ベースの仮想サーバ
• キープアライブとパイプライン接続のサポート
• 柔軟な設定
• クライアント処理を中断させること無く再設定、オンラインアップグレード
• アクセスログフォーマット、バッファされたログ書き込み、素早いログローテーション
• 3xx-5xx エラーコードのリダイレクト
• rewrite モジュール
• クライアントの IP アドレスをベースにしたアクセスコントロールと HTTP ベーシック認証
• PUT、DELETE、MKCOL、COPY、MOVE メソッド
• FLV ストリーミング
• 速度制限
• 同一アドレスからの同時接続もしくは同時リクエストの制限
• 埋め込み perl

メールプロキシサーバ機能

• 外部の HTTP 認証サーバを利用した IMAP/POP3 バックエンドへのユーザリダイレクト
• 外部の HTTP 認証サーバと内部 SMTP バックエンドへの接続リダイレクトを利用したユーザ認証
• 認証メソッド:
  • POP3: USER/PASS, APOP, AUTH LOGIN/PLAIN/CRAM-MD5;
  • IMAP: LOGIN, AUTH LOGIN/PLAIN/CRAM-MD5;
  • SMTP: AUTH LOGIN/PLAIN/CRAM-MD5;
• SSL サポート
• STARTTLS と STLS のサポート

アーキテクチャとスケーラビリティ

• 一つのマスタープロセスと複数のワーカープロセス。ワーカーは非特権ユーザとして動く
• 通知メソッド: kqueue (FreeBSD 4.1+)、epoll (Linux 2.6+)、rt シグナルs (Linux 2.2.19+)、/dev/poll (Solaris 7 11/99+)、イベントポート (Solaris 10)、select、poll
• EV_CLEAR, EV_DISABLE (イベントを一時的に無効にする)、 NOTE_LOWAT, EV_EOF、利用可能なデータの数、エラーコードを含む様々な kqueue 機能のサポート
• sendfile (FreeBSD 3.1+, Linux 2.2+, Mac OS X 10.5)、sendfile64 (Linux 2.4.21+)、sendfilev (Solaris 8 7/01+) のサポート
• ファイル AIO (FreeBSD 4.3+, Linux 2.6.22+)
• Accept-filters (FreeBSD 4.1+) と TCP_DEFER_ACCEPT (Linux 2.4+) のサポート
• 1 万の使われていない HTTP キープアライブ接続は約 2.5M のメモリーを使用
• データコピーの実施は最小に保たれる

テスト済み OS とプラットフォーム

• FreeBSD 3  — 8 / i386; FreeBSD 5  — 8 / amd64;
• Linux 2.2  — 2.6 / i386; Linux 2.6 / amd64;
• Solaris 9 / i386, sun4u; Solaris 10 / i386, amd64, sun4v;
• MacOS X / ppc, i386;
• Windows XP, Windows Server 2003.

nginx.org 上のドキュメントはこれだけです。あとは wiki (http://wiki.nginx.org/Main) で目についたところを訳していきます。

メッセージ “‘sys_errlist’ は非推奨です。代わりに ‘strerror’ もしくは ‘strerror_r’ を使ってください”
原文: A message “ ‘sys_errlist’ is deprecated; use ‘strerror’ or ‘strerror_r’ instead ”

nginx のバージョン 0.7.66、0.8.35、もしくはそれ以上を Linux でビルド中、次の警告メッセージが出ます:

warning: `sys_errlist' is deprecated;
    use `strerror' or `strerror_r' instead
warning: `sys_nerr' is deprecated;
    use `strerror' or `strerror_r' instead

これは正常です。strerror() と strerror_r() 関数が非同期シグナルセーフではないので、nginx はシングルハンドラの中で非推奨の sys_errlist[] と sys_nerr を使う必要があります。

文書作成: Igor Sysoev
編集: Brian Mercer
翻訳: DigitalCube Co. Ltd.
監訳:

デバッギングログ
原文: A debugging log

デバッギングログを有効にするには、nginx をデバッグオプションを付けて設定する必要があります:

./configure --with-debug ...

次に “error_log” の “debug” レベルをセットします:

error_log  /path/to/log  debug;

nginx の Windows バイナリバージョンでは常にデバッグログモードがサポートされてビルドされているので、“debug” レベルをセットするだけです。

別のレベル、例えば server レベルでログを定義するとそのサーバでのデバッギングログが無効になりますので注意してください：

error_log  /path/to/log  debug;

http {
    server {
        error_log  /path/to/log;
        ...

このサーバログをコメントアウトするか “debug” フラグを追加してください:

error_log  /path/to/log  debug;

http {
    server {
        error_log  /path/to/log  debug;
        ...

また、特定のアドレスだけデバッギングログを有効にすることもできます:

error_log  /path/to/log;

events {
    debug_connection   192.168.1.1;
    debug_connection   192.168.10.0/24;
}

文書作成: Igor Sysoev
編集: Brian Mercer
翻訳: DigitalCube Co. Ltd.
監訳:

rewrite ルールのコンバート
原文: Converting rewrite rules

• メインサイトへのリダイレクト
• Mongrel ルールのコンバート

メインサイトへのリダイレクト

共有のホスティングで Apache の .htaccess ファイルですべてを設定してきたのなら、次のようにルールをコンバートします:

RewriteCond  %{HTTP_HOST}  nginx.org
RewriteRule  (.*)          http://www.nginx.org$1

上記は下記のようになります:

server {
    listen       80;
    server_name  www.nginx.org  nginx.org;
    if ($http_host = nginx.org) {
        rewrite  (.*)  http://www.nginx.org$1;
    }
    ...
}

これは間違っていて面倒で非効率的な方法です。正しい方法は nginx.org 用に別のサーバを定義します:

server {
    listen       80;
    server_name  nginx.org;
    rewrite   ^  http://www.nginx.org$request_uri?;
}

server {
    listen       80;
    server_name  www.nginx.org;
    ...
}

別の例として、後方ロジックの代わり、nginx.com 以外と www.nginx.com 以外のすべて です:

RewriteCond  %{HTTP_HOST}  !nginx.com
RewriteCond  %{HTTP_HOST}  !www.nginx.com
RewriteRule  (.*)          http://www.nginx.com$1

この場合、単に nginx.com、www.nginx.com、そしてそれ以外を定義します:

server {
    listen       80;
    server_name  nginx.com  www.nginx.com;
    ...
}

server {
    listen       80 default_server;
    server_name  _;
    rewrite   ^  http://nginx.com$request_uri?;
}

Mongrelルールのコンバート

典型的な Mongrel のルール:

DocumentRoot /var/www/myapp.com/current/public

RewriteCond %{DOCUMENT_ROOT}/system/maintenance.html -f
RewriteCond %{SCRIPT_FILENAME} !maintenance.html
RewriteRule ^.*$ %{DOCUMENT_ROOT}/system/maintenance.html [L]

RewriteCond %{REQUEST_FILENAME} -f
RewriteRule ^(.*)$ $1 [QSA,L]

RewriteCond %{REQUEST_FILENAME}/index.html -f
RewriteRule ^(.*)$ $1/index.html [QSA,L]

RewriteCond %{REQUEST_FILENAME}.html -f
RewriteRule ^(.*)$ $1/index.html [QSA,L]

RewriteRule ^/(.*)$ balancer://mongrel_cluster%{REQUEST_URI} [P,QSA,L]

上記は次のようにコンバートされます

location / {
    root       /var/www/myapp.com/current/public;

    try_files  /system/maintenance.html
               $uri  $uri/index.html $uri.html
               @mongrel;
}

location @mongrel {
    proxy_pass  http://mongrel;
}

文書作成: Igor Sysoev
編集: Brian Mercer
翻訳: DigitalCube Co. Ltd.
監訳:

オープンソース系の文書の訳って監訳してもらえることがあんまり無いんでこれは個人的にかなり嬉しいです。快く引き受けてくださったwokamotoさんに多謝！

で、で、nginx（Wikipediaの説明）のドキュメント訳の３回目は「Introduction to nginx（nginx 入門）」の「Configuring HTTPS servers（HTTPS サーバの設定）」です。

HTTPS サーバの設定
原文: Configuring HTTPS servers

• HTTPS サーバの最適化
• SSL 連鎖証明書
• 単一の HTTP/HTTPS サーバ
• 名前ベースの HTTPS サーバ
• 複数名の SSL 証明
• サーバ名指示（SNI）
• 互換性

HTTPS サーバを設定するには server ブロックで SSL プロトコルを有効にして、サーバ証明書ファイルと秘密鍵ファイルの場所を指定する必要があります:

server {
    listen               443;
    server_name          www.nginx.com;
    ssl                  on;
    ssl_certificate      www.nginx.com.crt;
    ssl_certificate_key  www.nginx.com.key;
    ssl_protocols        SSLv3 TLSv1;
    ssl_ciphers          HIGH:!ADH:!MD5;
    ...
}

サーバ証明書とはドメインの所有者情報や、送信情報の暗号化に必要な公開鍵を含む電子証明書です。そのサーバに接続するすべてのクライアントに送られます。秘密鍵はサーバ証明書に含まれる公開鍵で暗号化された情報を復号するために必要な鍵で、秘匿する必要が有ります。アクセスを制限したファイルに保存するようにしてください。ただし、nginx のマスタープロセスからは読めるようにする必要があります。もうひとつの方法として、秘密鍵は証明書と同じファイルに保存することもできます。

    ssl_certificate      www.nginx.com.cert;
    ssl_certificate_key  www.nginx.com.cert;

この場合もファイルのアクセス権は制限するようにします。証明書と秘密鍵がひとつのファイルに保存されていても、証明書だけがクライアントに送られます。

SSL プロトコルの強力なバージョンと暗号に接続を制限するには、ディレクティブ “ssl_protocols” と “ssl_ciphers” を使用します。バージョン 0.8.20 以降、nginx は “ssl_protocols SSLv3 TLSv1” と “ssl_ciphers HIGH:!ADH:!MD5” をデフォルトとして使用しているので、これより古い nginx のバージョンでのみ設定してください。

HTTPS サーバの最適化

SSL の工程は CPU リソースを余計に消費します。マルチプロセッサシステムでは（利用できる CPU コアの数よりも大きい数の）複数のワーカープロセスを走らせるといいでしょう。最も CPU に負荷がかかる工程は SSL ハンドシェイクです。クライアント毎のこの工程数を最小化するには２つの方法があります。最初の方法はキープアライブ接続を有効にして、ひとつの接続経由で複数のリクエストを送るようにする方法です。二つ目の方法は SSL セッションパラメータを再利用して、並行かつ順次接続のための SSL ハンドシェイクを避ける方法です。セッションはワーカー間で共有される SSL セッションキャッシュに保持され、“ssl_session_cache” ディレクティブで設定されています。１メガバイトのキャッシュには約４０００のセッションが含まれます。キャッシュのデフォルトタイムアウトは５分です。この値は “ssl_session_timeout” ディレクティブを使用して増やすことができます。次の例は１０Mの共有セッションキャッシュをもったクアッドコアシステムに最適化された設定例です:

worker_processes  4;

http {
    ssl_session_cache    shared:SSL:10m;
    ssl_session_timeout  10m;

    server {
        listen               443;
        server_name          www.nginx.com;
        keepalive_timeout    70;

        ssl                  on;
        ssl_certificate      www.nginx.com.crt;
        ssl_certificate_key  www.nginx.com.key;
        ssl_protocols        SSLv3 TLSv1;
        ssl_ciphers          HIGH:!ADH:!MD5;
        ...

SSL 連鎖証明書

ブラウザによっては有名な認証局によって署名された証明書にエラーをだすことがあります。その一方でその証明書を他のブラウザでは問題なく受け入れることもあります。これは発行している認証局が、有名で信用されている認証局の認証基盤には含まれない特定のブラウザで配布されている中間証明書を使ったサーバ証明書に署名しているからです。このケースでは、認証局は署名されたサーバ証明書に連結されているはずの連鎖証明書のバンドルを提供しています。サーバ証明書は、かならず結合されたファイル内の連鎖証明書に存在している必要があります:

$ cat www.nginx.com.crt bundle.crt > www.nginx.com.chained.crt

この結合されたファイルを “ssl_certificate” ディレクティブで使われるようにします:

server {
    listen               443;
    server_name          www.nginx.com;
    ssl                  on;
    ssl_certificate      www.nginx.com.chained.crt;
    ssl_certificate_key  www.nginx.com.key;
    ...
}

サーバ証明書とバンドルされたものが間違った順序で連結されていた場合、nginx は起動に失敗して次のエラーメッセージを表示します:

SSL_CTX_use_PrivateKey_file(" ... /www.nginx.com.key") failed
   (SSL: error:0B080074:x509 certificate routines:
    X509_check_private_key:key values mismatch)

これは、nginx がサーバ証明書ではなくバンドルされた最初の証明書で秘密鍵を使おうとするからです。

ブラウザは通常、信頼されている認証局によって署名されている受信した中間証明書を保存します。したがって、よく使われているブラウザは要求された中間証明書をすでに保持しているかもしれませんし、連鎖バンドルなしで送られた証明書にエラーを出すかもしれません。サーバに完全な連鎖証明書を送信させるには “openssl” コマンドラインユーティリティを使うといいでしょう。例えば:

$ openssl s_client -connect www.godaddy.com:443
...
Certificate chain
 0 s:/C=US/ST=Arizona/L=Scottsdale/1.3.6.1.4.1.311.60.2.1.3=US
     /1.3.6.1.4.1.311.60.2.1.2=AZ/O=GoDaddy.com, Inc
     /OU=MIS Department/CN=www.GoDaddy.com
     /serialNumber=0796928-7/2.5.4.15=V1.0, Clause 5.(b)
   i:/C=US/ST=Arizona/L=Scottsdale/O=GoDaddy.com, Inc.
     /OU=http://certificates.godaddy.com/repository
     /CN=Go Daddy Secure Certification Authority
     /serialNumber=07969287
 1 s:/C=US/ST=Arizona/L=Scottsdale/O=GoDaddy.com, Inc.
     /OU=http://certificates.godaddy.com/repository
     /CN=Go Daddy Secure Certification Authority
     /serialNumber=07969287
   i:/C=US/O=The Go Daddy Group, Inc.
     /OU=Go Daddy Class 2 Certification Authority
 2 s:/C=US/O=The Go Daddy Group, Inc.
     /OU=Go Daddy Class 2 Certification Authority
   i:/L=ValiCert Validation Network/O=ValiCert, Inc.
     /OU=ValiCert Class 2 Policy Validation Authority
     /CN=http://www.valicert.com//emailAddress=info@valicert.com
...

この例では、www.GoDaddy.com サーバ証明書 #0 の対象 (“s”) はそれ自身が証明書 #1 の対象である発行者 (“i”) によって署名されています。そして、証明書 #1はそれ自身が証明書 #2 の対象である発行者によって署名され、証明書 #2 は有名な発行者である ValiCert, Inc. によって署名されていて、ValiCert, Inc. の証明書はブラウザに組み込まれている証明書ベースに保持されています（こうして連鎖します）。

もし証明書バンドルを追加していなければ、サーバ証明書 #0 しか見れません。

単一の HTTP/HTTPS サーバ

最初の段階から HTTP と HTTPS プロトコル用にサーバを分けて設定するのは優れた実践です。現時点では両者の機能性としては等しいかもしれませんが、将来的に大きな変更があるかもしれず、統合されたサーバの使用が問題になるかもしれません。とはいえ、HTTP と HTTPS のサーバが等しく、将来のことを考えたくないのなら、ディレクティブ “ssl on” を削除して *:443 ポートに “ssl” パラメータを追加することによって HTTP と HTTPS リクエストの両者を扱う単一のサーバを設定することができます:

server {
    listen               80;
    listen               443  ssl;
    server_name          www.nginx.com;
    ssl_certificate      www.nginx.com.crt;
    ssl_certificate_key  www.nginx.com.key;
    ...
}

0.8.21 以前では、nginx は “default” パラメータで待ち受けているソケットに “ssl” パラメータをセットすることしかできませんでした:

listen  443  default  ssl;

名前ベースの HTTPS サーバ

単一の IP アドレスを２つ以上の HTTPS サーバで待ち受けるように設定するとよく発生する問題があります:

server {
    listen           443;
    server_name      www.nginx.com;
    ssl              on;
    ssl_certificate  www.nginx.com.crt;
    ...
}

server {
    listen           443;
    server_name      www.nginx.org;
    ssl              on;
    ssl_certificate  www.nginx.org.crt;
    ...
}

この設定では、ブラウザはリクエストされたサーバ名に関わらずデフォルトサーバ、すなわちここでは www.nginx.com の証明書を受信します。これは SSL プロトコルの作用によるものです。この SSL 接続はブラウザが HTTP リクエストを送る前に確立されるので、nginx にはリクエストされたサーバ名は分かりません。したがって、デフォルトサーバの証明書を送ることしかできません。

この問題を解決するもっとも古くてもっとも堅実な方法は、各 HTTPS サーバに別個の IP アドレスを割り当てることです:

server {
    listen           192.168.1.1:443;
    server_name      www.nginx.com;
    ssl              on;
    ssl_certificate  www.nginx.com.crt;
    ...
}

server {
    listen           192.168.1.2:443;
    server_name      www.nginx.org;
    ssl              on;
    ssl_certificate  www.nginx.org.crt;
    ...
}

複数サーバ名をもつ SSL 証明書

単一の IP アドレスを複数の HTTPS サーバ間で共有する方法は他にもありますが、どれも欠点があります。ひとつは、SubjectAltName フィールドに複数サーバ名（例えば、www.nginx.com と www.nginx.org）をもつ単一の証明書を使用する方法です。しかし、SubjectAltName の長さには制限があります。

もうひとつの方法は、例えば *.nginx.org のようにワイルドカード名を持った証明書を使用する方法です。この証明書は www.nginx.org にマッチしますが nginx.org や www.sub.nginx.org にはマッチしません。以上の二つの方法は組み合わせることもできます。証明書には、例えば nginx.org と *.nginx.org のように SubjectAltName フィールドに完全一致名とワイルドカード名を含ませることができます。

すべてのサーバでひとつのメモリーコピーを継承するためには、複数サーバ名を持つ証明書ファイルとその秘密鍵ファイルを設定の http レベルに置くとよいでしょう:

ssl_certificate      common.crt;
ssl_certificate_key  common.key;

server {
    listen           443;
    server_name      www.nginx.com;
    ssl              on;
    ...
}

server {
    listen           443;
    server_name      www.nginx.org;
    ssl              on;
    ...
}

サーバ名指示（Server Name Indication – SNI）

単一の IP アドレス上で複数の HTTPS サーバを動かすときのさらに包括的な解決方法として TLSv1.1 Server Name Indication extension（サーバ名指示拡張） (SNI, RFC3546) があります。これは、ブラウザが SSL ハンドシェイクの間にリクエストされたサーバ名を渡せるようにするもので、それによりサーバはその接続でどの証明書を使用するべきかが分かります。しかし、SNI は限られたブラウザしかサポートしていません。現時点では次のブラウザのバージョン以降のものがサポートされています。

• Opera 8.0
• MSIE 7.0 (Windows Vista 以降のみ)
• Firefox 2.0 および Mozilla Platform rv:1.8.1 を使用している他のブラウザ
• Safari 3.2.1 (Windows バージョンでは Vista 以降)
• Chrome (Windows バージョンでは Vista 以降)

nginx で SNI を使用するためには、nginx バイナリがビルドされたときの OpenSSL ライブラリとランタイムで動的にリンクされるライブラリの両方でサポートされていることが必要です。OpenSSL は設定オプション “–enable-tlsext” でビルドされていれば、バージョン 0.9.8f 以降で SNI をサポートしています。OpenSSL 0.9.8j 以降ではこのオプションはデフォルトで有効になっています。nginx が SNI サポート付きでビルドされていれば、 “-V” スイッチとともに起動すると nginx が次のように表示します:

$ nginx -V
...
TLS SNI support enabled
...

しかし、SNI が有効になっている nginx が SNI サポート無しの OpenSSL ライブラリに動的にリンクされている場合、nginx は次の警告を表示します:

nginx was built with SNI support, however, now it is linked
dynamically to an OpenSSL library which has no tlsext support,
therefore SNI is not available

互換性

• “-V” スイッチでの SNI サポートステータス表示は 0.8.21 以降と 0.7.62 でサポートされています。
• “listen” ディレクティブの “ssl” パラメータは 0.7.14 以降からサポートされています。
• SNI は 0.5.32 以降からサポートされています。
• 共有 SSL セッションキャッシュは 0.5.6 以降からサポートされています。

• バージョン 0.7.65 と 0.8.19 以降のデフォルトの SSL プロトコルは SSLv3 とTLSv1 です。
• バージョン 0.7.64 と 0.8.18 以前のデフォルトの SSL プロトコルは SSLv2、SSLv3、TLSv1 です。

• バージョン 0.7.65 と 0.8.20 以降のデフォルトの SSL 暗号は “HIGH:!ADH:!MD5” です。
• バージョン  0.8.19 のデフォルトの SSL 暗号は “ALL:!ADH:RC4+RSA:+HIGH:+MEDIUM” です。
• バージョン 0.7.64 と 0.8.18 以前のデフォルトの SSL 暗号は “ALL:!ADH:RC4+RSA:+HIGH:+MEDIUM:+LOW:+SSLv2:+EXP” です。

文書作成: Igor Sysoev
編集: Brian Mercer
翻訳: DigitalCube Co. Ltd.
監訳: wokamoto

今回は「Introduction to nginx（nginx 入門）」の「Server names（サーバ名）」です。

****

サーバ名
原文: Server names

• ワイルドカード名
• 正規表現名
• その他のサーバ名
• 最適化
• 互換性

サーバ名は “server_name” ディレクティブを使用して定義され、リクエストに対してどのサーバブロックが使われるかを決定します。「How nginx processes a request（nginx はどのようにリクエストを処理するか）」もお読みください。これらは完全一致名、ワイルドカード名、正規表現で定義されます:

server {
    listen       80;
    server_name  nginx.org  www.nginx.org;
    ...
}

server {
    listen       80;
    server_name  *.nginx.org;
    ...
}

server {
    listen       80;
    server_name  mail.*;
    ...
}

server {
    listen       80;
    server_name  ~^(?<user>.+)\.nginx\.net$;
    ...
}

サーバ名は次の順序で考査されます:

1. 完全一致名;
2. アスタリスクで始まるワイルドカード名: *.nginx.org;
3. アスタリスクで終わるワイルドカード名: mail.*;
4. 設定ファイル内の順序での正規表現

最初にマッチしたところで検索は終了します。

ワイルドカード名

ワイルドカード名にはそのサーバ名の最初か最後のみ、そしてドットに隣接したところのみにアスタリスクが含まれます。サーバ名 “www.*.nginx.org” や “w*.nginx.org” は無効です。しかし、これらのサーバ名は正規表現を使用して、例えば  “~^www\..+\.nginx\.org$” や “~^w.*\.nginx\.org$” として指定することができます。アスタリスクは複数部分にマッチさせることができます。“*.nginx.org” は www.nginx.org だけでなく www.sub.nginx.org にもマッチします。

特別なワイルドカードの形式 “.nginx.org” は、完全一致名 “nginx.org” とワイルドカード名 “*.nginx.org” の両方にマッチさせるように利用できます。

正規表現名

nginx で使用される正規表現は Perl プログラミング言語（PCRE）で使用されているものと互換性があります。正規表現を使用するには、サーバ名を必ずチルダで始めます:

server_name  ~^www\d+\.nginx\.net$;

チルダで始まっていないと完全一致名として、またはその正規表現にアスタリスクが含まれている場合はワイルドカード名として（そしてたいていの場合は無効なものとして）扱われてしまいます。“^” と “$” アンカーをセットし忘れないようにしてください。これらは構文的には必須ではありませんが論理的に必須です。また、ドメイン名のドットはバックスラッシュで必ずエスケープしてください。“{” と “}” 文字を含む正規表現は必ずダブルクォーテーション(“)で囲ってください:

server_name  "~^(?<name>\w\d{1,3}+)\.nginx\.net$";

さもないと、nginx は起動に失敗し次のエラーメッセージを表示します:

directive "server_name" is not terminated by ";" in ...

正規表現の名前付きキャプチャは変数としてその後で使用されます:

server {
    server_name   ~^(www\.)?(?<domain>.+)$;

    location / {
        root   /sites/$domain;
    }
}

PCRE ライブラリは次の構文を使用した名前付きキャプチャをサポートしています:

nginx が起動に失敗すると次のエラーメッセージを表示します:

pcre_compile() failed: unrecognized character after (?< in ...

これは PCRE ライブラリが古いので “?P” 構文を試すように、という意味です。このキャプチャは数字形式でも使用できます:

server {
    server_name   ~^(www\.)?(.+)$;

    location / {
        root   /sites/$2;
    }
}

とはいえ、数字形式は簡単に上書きすることができるため、このような使用法は（上記のような）単純なケースに限るべきです。

その他のサーバ名

デフォルトではないサーバブロックで “Host” ヘッダ無しのリクエストを処理させたい場合は、空のサーバ名を指定します:

server {
    listen       80;
    server_name  nginx.org  www.nginx.org  "";
    ...
}

“server_name” がサーバブロックで定義されていない場合は、nginx はサーバ名として空の名前を使用します。

nginx のバージョン 0.8.48 までは、このような場合はサーバ名としてホスト名を使用していました。

サーバ名ではなく IP アドレスを使用したリクエストが送られてきた場合、そのリクエストの “Host” ヘッダには IP アドレスが含まれているので、その IP アドレスをサーバ名として利用してそのリクエストを処理できます:

server {
    listen       80;
    server_name  nginx.org
                 www.nginx.org
                 ""
                 192.168.1.1
                 ;
    ...
}

In catch-all server examples you may see the strange name “_”:

すべてのサーバに適合させる例では奇妙なサーバ名 “_” を目にするかもしれません:

server {
    listen       80  default_server;
    server_name  _;
    return       444;
}

このサーバ名に特別なところはありません。単にどのサーバ名とも決してマッチしない無数の無効なドメイン名のひとつです。したがって、 “–”、“!@#” なども同様な結果を得られます。

nginx バージョン 0.6.25 までは特別なサーバ名 “*” をサポートしていて、これは誤ってすべてのサーバ名と一致するもの（キャッチオール名）として解釈されていました。この特別なサーバ名 “*” はキャッチオールまたはワイルドカードとして機能したことはありませんでした。代わりに、今は “server_name_in_redirect” ディレクティブによって提供されている機能の役を果たしていました。特別なサーバ名 “*” は今後廃止予定ですので、“server_name_in_redirect” ディレクティブを使うようにしてください。キャッチオール名を指定したり “server_name” ディレクティブを使用したデフォルトサーバを指定したりする方法はないことに注意してください。これは “listen” ディレクティブのプロパティであり、“server_name” ディレクティブのプロパティではありません。“How nginx processes a request（日本語訳）” も参照してください。

ポート *:80 と *:8080 で待ち受けているサーバを定義し、ひとつをポート *:8080 のデフォルトサーバへ、もうひとつをポート *:80 のデフォルトサーバへ振り向けることができます。

server {
    listen       80;
    listen       8080  default_server;
    server_name  nginx.net;
    ...
}

server {
    listen       80  default_server;
    listen       8080;
    server_name  nginx.org;
    ...
}

最適化

完全一致名とワイルドカード名はハッシュで保存されます。このハッシュは待ち受けポートに結び付けられ、各待ち受けポートは、完全一致名のハッシュ、アスタリスクで始まるワイルドカード名のハッシュ、アスタリスクで終わるワイルドカード名のハッシュの３つまでのハッシュを持つことができます。ハッシュのサイズは構成フェーズで最適化されるので、CPU キャッシュのミスは最低でもサーバ名を見つけることができます。最初に完全一致名のハッシュが検索されます。完全一致名のハッシュを使って見つからなければ、次にアスタリスクで始まるワイルドカード名のハッシュが検索されます。さらにまだ見つからなければ、アスタリスクで終わるワイルドカード名のハッシュが検索されます。ワイルドカード名のハッシュの検索は完全一致名のハッシュの検索よりも遅くなります。これはサーバ名の検索がドメイン部分によって検索されるからです。特別なワイルドカード形式の “.nginx.org” は完全一致名のハッシュではなくワイルドカード名のハッシュで保存されます。正規表現は順番に考査されるので、これがもっとも遅い方式ですし、非スケーラブルでもあります。

これらの理由から、可能な場合は完全一致名を利用するのがよいでしょう。例えば、もっとも頻繁にリクエストされるサーバ名が nginx.org と www.nginx.org だとすると、これらを明示的に定義するとより効率的です:

server {
    listen       80;
    server_name  nginx.org  www.nginx.org  *.nginx.org;
    ...
}

上記は次の単純化された形式を使用するよりも効率的です:

server {
    listen       80;
    server_name  .nginx.org;
    ...
}

たくさんの数のサーバ名を定義したり非常に長いサーバ名を定義したりする場合は、http レベルの “server_names_hash_max_size” と “server_names_hash_bucket_size” ディレクティブを調整する必要があるかもしれません。“server_names_hash_bucket_size” のデフォルト値は 32、もしくは 64、あるいはお使いの CPU キャッシュラインのサイズによってはその他の値になっているかもしれません。もしデフォルト値が 32 でサーバ名として“too.long.server.name.nginx.org” のような非常に長いサーバ名を定義している場合、nginx は起動に失敗し、次のエラーメッセージを表示させます:

could not build the server_names_hash,
you should increase server_names_hash_bucket_size: 32

この場合、このディレクティブの値を次の 2 の累乗にセットします:

http {
    server_names_hash_bucket_size  64;
    ...

非常にたくさんの数のサーバ名を定義した場合は次のエラーメッセージが表示されます:

could not build the server_names_hash,
you should increase either server_names_hash_max_size: 512
or server_names_hash_bucket_size: 32

まず最初に “server_names_hash_max_size” の値を、定義するサーバ名の数に近い数に設定して試します。この設定がうまくいかない時だけ、もしくは nginx の起動時間が許容できないほど長い場合だけ “server_names_hash_bucket_size” の値を増やしてみます。

待ち受けているポートがひとつだけでサーバもひとつだけの場合、nginx はサーバ名を考査しません（また、待ち受けポート用のハッシュも生成しません）。しかし一つ例外があります。“server_name” がキャプチャを伴った正規表現の場合、nginx はキャプチャを取得するためにこの正規表現を実行します。

互換性

• 0.8.48 以降、デフォルトのサーバ名の値は空の名前 “” です。
• 正規表現サーバ名の名前付きキャプチャのサポートは 0.8.25 からです。
• 正規表現サーバ名のキャプチャのサポートは 0.7.40 からです。
• 空のサーバ名 “” のサポートは 0.7.12 からです。
• ワイルドカードサーバ名と正規表現の最初のサーバ名としての使用は0.6.25 からサポートされています。
• 正規表現サーバ名のサポートは 0.6.7 からです。
• ワイルドカードの形式 nginx.* のサポートは 0.6.0 からです。
• 特別な形式 .nginx.org のサポートは 0.3.18 からです。
• ワイルドカードの形式 *.nginx.org のサポートは 0.1.13 からです。

文書作成: Igor Sysoev
編集: Brian Mercer
翻訳: DigitalCube Co. Ltd.
監訳: wokamoto

あと、nginx のドキュメントは wiki もありますが、表側はだいぶん訳されているようなのでこのドキュメントをまず訳してから、wikiを訳していこうと思います。

で、今回は「Introduction to nginx（nginx 入門）」の「How nginx processes a request（nginx はリクエストをどのように処理するか）」を訳しました。

***

nginx はどのようにリクエストを処理するか
原文: How nginx processes a request

• 名前ベースの仮想サーバ
• サーバー名未定義のリクエストの処理を防ぐ
• 名前ベースとIPベースをミックスした仮想サーバ
• 単純な PHP サイトの設定

名前ベースの仮想サーバ

nginx はまず最初にどのサーバがそのリクエストを処理すべきなのかを決定します。手はじめに、３つすべての仮想サーバが port *:80 で待ち受けている単純な設定から見てみましょう:

server {
    listen       80;
    server_name  nginx.org  www.nginx.org;
    ...
}

server {
    listen       80;
    server_name  nginx.net  www.nginx.net;
    ...
}

server {
    listen       80;
    server_name  nginx.com  www.nginx.com;
    ...
}

この設定では nginx は、（ブラウザからの）HTTP リクエストの “Host” ヘッダだけを考査して、そのリクエストをどのサーバに振り向けるべきかを決定します。もし “Host” ヘッダがどのサーバ名ともマッチしない場合、またはリクエストにこのフィールドがまったく含まれていない場合は、nginxはこのリクエストをデフォルトサーバに振り向けます。上記の設定ではデフォルトサーバは最初のもので、これは nginx の標準的なデフォルトの挙動です。設定内の最初のサーバをデフォルトサーバにしたくない場合は、“listen” ディレクティブに “default_server” パラメータを使って明示的に設定することができます:

server {
    listen       80  default_server;
    server_name  nginx.net  www.nginx.net;
    ...
}

この “default_server” パラメータはバージョン 0.8.21 以上で利用できます。それ以前のバージョンでは代わりに “default” パラメータを使用してください。
このデフォルトサーバは “listen” ディレクティブのプロパティで、”server_name” ディレクティブのプロパティではないことに注意してください。詳細は後述します。

サーバー名未定義のリクエストの処理を防ぐ

“Host” ヘッダが未定義のリクエストを処理させたくない場合は、リクエストを単にドロップさせるデフォルトサーバを設定できます:

server {
    listen       80  default_server;
    server_name  _;
    return       444;
}

ここでは存在しないドメイン名 “_” をサーバ名として選択し、接続を閉じる nginx の特別な標準外コード 444 を返します。このサーバ用にサーバ名を設定しなければならないことに注意してください。さもなければ nginx はホスト名を使用します。

名前ベースとIPベースをミックスした仮想サーバ

異なるアドレスで待ち受けている仮想サーバのより複雑な設定をみてみましょう:

server {
    listen       192.168.1.1:80;
    server_name  nginx.org  www.nginx.org;
    ...
}

server {
    listen       192.168.1.1:80;
    server_name  nginx.net  www.nginx.net;
    ...
}

server {
    listen       192.168.1.2:80;
    server_name  nginx.com  www.nginx.com;
    ...
}

この設定では、nginx はまず最初に “server” ブロックの “listen” ディレクティブに対してリクエストの IP アドレスとポートを考査します。次に、その IP アドレスとポートにマッチする “server” ブロックの “server_name” ディレクティブに対して、その HTTP リクエストの “Host” ヘッダを考査します。もしサーバ名が見つからなければ、そのリクエストはデフォルトサーバによって処理されます。例えば、 192.168.1.1:80 ポートで受信された www.nginx.com へのリクエストは 192.168.1.1:80 ポートのデフォルトサーバ、つまり最初のサーバで処理されます。これはこのポートでは www.nginx.com は定義されていないからです。

すでに述べたように、デフォルトサーバは “listen” ディレクティブのプロパティで、”listen” ディレクティブには別のデフォルトサーバが定義されています。

server {
    listen        192.168.1.1:80;
    server_name   nginx.org  www.nginx.org;
    ...
}

server {
    listen        192.168.1.1:80  default_server;
    server_name   nginx.net  www.nginx.net;
    ...
}

server {
    listen        192.168.1.2:80  default_server;
    server_name   nginx.com  www.nginx.com;
    ...
}

単純な PHP サイトの設定

では、典型的で単純な PHP サイトで nginx がどのようにロケーション（location）を選択してリクエストを処理するのかを見てみましょう:

server {
    listen        80;
    server_name   nginx.org  www.nginx.org;
    root          /data/www;

    location / {
        index     index.html  index.php;
    }

    location ~* \.(gif|jpg|png)$ {
        expires   30d;
    }

    location ~ \.php$ {
        fastcgi_pass   localhost:9000;
        fastcgi_param  SCRIPT_FILENAME
                       $document_root$fastcgi_script_name;
        include        fastcgi_params;
    }
}

nginx はまず最初に、リストの順序には関係なくリテラルな文字列によって指定されているもっとも限定されたロケーションを検索します。上記の設定では唯一のリテラルなロケーションは “/” であり、したがってどのリクエストでもマッチして最終的にこのロケーションが使われます。次に nginx は、設定ファイルにリストされている順番で正規表現によって指定されているロケーションをチェックします。最初にマッチした正規表現で検索はストップし、 nginx そのロケーションを使用します。もしどの正規表現もリクエストにマッチしない場合は、nginx はその前に見つかったもっとも限定されたリテラルなロケーションを使用します。

すべてのタイプのロケーションはクエリー部分を除いたリクエスト URI 部分のみを考査することに注意してください。これはクエリー文字列の引数がいろいろな方法で渡されることがあるためです。例えば:

/index.php?user=john&page=1
/index.php?page=1&user=john

さらに、クエリー文字列ではどのようなリクエストでも可能だからです:

/index.php?page=1&something+else&user=john

では、上記の設定ではどのようにリクエストが処理されるのかを見てみましょう:

• リクエスト “/logo.gif” はリテラルなロケーション “/” に最初にマッチし、次に正規表現 “\.(gif|jpg|png)$” にマッチするので、後者のロケーションによって処理されます。 このリクエストは “root /data/www” ディレクティブを使用してファイル “/data/www/logo.gif” にマップされ、このファイルがクライアントに送られます。
• リクエスト “/index.php” もまたリテラルなロケーション “/” に最初にマッチし、次に正規表現 “\.(php)$” にマッチします。したがって、このリクエストは後者のロケーションによって処理され、localhost:9000 で待ち受けている FastCGI サーバに渡されます。“fastcgi_param” ディレクティブは FastCGI のパラメータ SCRIPT_FILENAME を “/data/www/index.php” にセットし、この FastCGI サーバがこのファイルを実行します。変数 $document_root は “root” ディレクティブの値と同等で、変数 $fastcgi_script_name はリクエスト URI、例えば “/index.php” と同等です。
• リクエスト “/about.html” はリテラルなロケーション “/” のみにマッチします。したがってこのロケーションで処理されます。このリクエストは “root” ディレクティブのパラメータ “/data/www” を使い、ファイル “/data/www/about.html” にマップされ、クライアントに送られます。
• リクエスト “/” の処理はより複雑です。これはリテラルなロケーション “/” のみにマッチし、このロケーションで処理されます。ついで “index” ディレクティブがパラメータと “root” ディレクティブのパラメータ “/data/www” にしたがって index ファイルが存在するかどうかを考査します。もし “/data/www/index.php” ファイル存在すればこのディレクティブは “/index.php” への内部リダイレクトを実行し、nginx はまるでこのリクエストがクライアントに送られたかのようにこのロケーションを再び検索します。先に見たように、リダイレクトされたリクエストは最終的に FastCGI サーバで処理されます。

文書作成: Igor Sysoev
編集: Brian Mercer
翻訳: DigitalCube Co. Ltd.
監訳: wokamoto

まず最初はツールです。もちろん Git は必要です。また、Subversion 互換 diff を生成する Bash スクリプトの git-svn-diff も必要になります。

• Git
• git-svn-diff

次のように、git-svn-diff をダウンロードしてパスの通っている任意の場所に置き、実行可能にします:

curl -L http://rkj.me/a1 > /usr/local/bin/git-svn-diff
sudo chmod +x /usr/local/bin/git-svn-diff

次に、git-svn-diff ではなくgit svn-diff を使えるようにするため、~/.gitconfig を編集して次を追加します:

[alias]
svn-diff = !git-svn-diff

次のステップは少し時間がかかります（ひと晩くらいかかるかも）。WordPress の SVN 履歴を Git の SVN サポートを利用してプルダウンします。

git svn clone -t tags -b branches -T trunk http://core.svn.wordpress.org/

終了したら、Git マスターブランチに入ります。これは WordPress SVN の trunk に対応します。WordPress のブランチはremotes/{name}に有ります。

SVN からの最新の変更をプルするには git svn rebase を使います。重要なルール: SVN ブランチ（remotes/{name}）は決して修正しないこと。代わりに新しいトピックブランチを作成します。

例えば、trunk 向けのあるチケットの作業をするとします。次のようにremotes/trunk から新しいブランチを作ります:

git checkout -b ticket-12345 remotes/trunk

こうすると、SVN の trunk をベースにした ticket-12345 という名称の新しいローカルの Git ブランチが作成されますので、それをチェックアウト（言い換えれば、それにスウィッチ）します。

WordPress SVN ブランチで作業する場合は次のようになります:

git checkout -b ticket-12345 remotes/3.1

作成したブランチで作業します。必要なら、複数のローカル Git コミットを作成できます。こうすれば、自分にとって意味のあるより小さな「かたまり」に作業を分けることができます。

パッチを送る準備ができたら、git-svn-diff を使ってパッチを生成します。

git svn-diff > ~/12345.diff

もしコミットアクセス権があるのなら、このトピックブランチから Subversion にコミットできます。とはいえ、気をつけてください！最初に git svn rebase を実行して自分のパッチを最新にしてください。次に、自分のローカルの git コミットを潰しておいてください。さもないとすべての各コミットが SVN に個別にコミットされてしまうからです。次のようにして、自分の複数のコミットを一つのコミットに rebase してください:

git rebase -i remotes/trunk

最初のコミットには “reword” を使用します。それに続くコミットには “fixup” を使用します。こうすると複数のコミットを一つにまとめることができます。そして、統合したコミット用に修正したコミットメッセージを入力するよう指示されます。

準備できましたか？これで次のように SVN にコミットできます:

git svn dcommit

Git には、そのトピックブランチがいつチェックアウトされたのかによって、そのコミットがどの SVN ブランチから来たのかが分かります。そのコミットがどれにアタッチされているのかを確認するには次のようにします:

git svn info

いくつかヒント:

.gitignore ファイルを作成してください。ここには Git に無視させたいファイルやディレクトリをリストアップします。まず最初に、.gitignore ファイル自身を無視させます！次に、ローカルの wp-config.php を無視させます。最後に、追加のプラグイン、必ず使用するプラグイン、テーマ、アップロードファイルなどなど。git status を実行し、WordPress や 自分のパッチにコミットしたくないものをすべて追加します。