IRCへ質問あるいはメーリングリストへ質問を送信する前に、このFAQ全体を調べてください。
一般的に、全てのブランチ(開発あるいはそれ以外)は完全に安定しています。このサイトは常に最新の開発バージョンを実行しています。多くのNGINXユーザは"early adapter"集団を代表します。つまり、どの時点においても大部分が最前線のバージョンを使っています。開発バージョンについて主要で最も重要なポイントはサードパーティのモジュールに関して時折APIを破壊するかも知れないということです(APIは時々開発ブランチの中で変更されます)。それ以外に、全ての緊急ではないバグ修正を最初に取得します。
つまり、もし安定性が重要でれば出開発リリースの後にデプロイを少し遅らせます; 致命的なバグは最初の数日内に現れやすいです(しばしばすぐあとに他のリリースがされる結果となります)。もし数日以内に新しいリリースがされなければ、おそらく誰も致命的なバグを発見できませんでした。あなたがバグを見つけた場合は、デバッグログをキャプチャーし説明のバグレポートをサブミットしてください。
Linux(および他のPosix): .htpasswdという名前のパスワードファイルを生成するために、V3Ry, SEcRe7, V3RySEcRe7 と SEcRe7PwDのパスワードを持つ John, Mary, Jane と Jim というユーザを仮定すると、以下のようにして発行することができるでしょう:
printf "John:$(openssl passwd -crypt V3Ry)\n" >> .htpasswd # この例ではcrypt符号化を使います
printf "Mary:$(openssl passwd -apr1 SEcRe7)\n" >> .htpasswd # この例はapr1 (Apache MD5) 符号化を使います
printf "Jane:$(openssl passwd -1 V3RySEcRe7)\n" >> .htpasswd # この例は MD5符号化を使います
(PASSWORD="SEcRe7PwD";SALT="$(openssl rand -base64 3)";SHA1=$(printf "$PASSWORD$SALT" | openssl dgst -binary -sha1 | xxd -ps | sed 's#$#'"`echo -n $SALT | xxd -ps`"'#' | xxd -r -ps | base64);printf "Jim:{SSHA}$SHA1\n" >> .htpasswd) # this example uses SSHA encryption
あるいは、以下のcrypt.pl Perlスクリプトを使うことができます。それを(例えばf) crypt.plとして保存し、実行できるようにchmod 700 crypt.pl します。
#!/usr/bin/perl
use strict;
chomp(my $filename=$ARGV[0]);
chomp(my $username=$ARGV[1]);
chomp(my $password=$ARGV[2]);
if (!$filename || !$username || !$password) {
print "USAGE: ./crypt.pl filename username password\n\n";
} else {
open my $fh, ">>", $filename or die $!;
print $fh $username . ":" . crypt($password, $username) . "\n";
close $fh or die $!;
}
あるいは、htpasswd.py python スクリプトを使うことができます。
ありえそうな問題の原因を調査することで始める。デバッグを精査し、注意深く エラーログを1行1行見る。
テスト、実験、ネットの調査などを通じて問題の原因を決定できなかった場合は、全ての関係する詳細を集め そしてIRCまたはメーリングリストへの注記に問題を明確に説明してください。(FOSSサポートコミュニティとやり取りをするのが初めてであれ、以下を読んでください: How To Ask Questions The Smart Way。)
ほとんどの人がこの文脈の中で"similar"によって意味するものは: "軽量" あるいは ”Apacheではない”です。Googleを使って多くの比較を見つけることができますが、ほとんどのwebサーバは2つの分類に収まります: プロセスベース(forkあるいはスレッド) と 非同期です。NGINX と Lighttpd はおそらく最もよく知られた2つの非同期サーバで、Apacheは間違いないもっとも良く知られたプロセスベースのサーバです。Cherokee は若干知名度が低いプロセスベースのサーバです(しかし、とても高いパフォーマンスを持ちます)。
非同期のやり方の主要な利点はスケーラビリティです。プロセスベースサーバでは、それぞれの同時に起こる接続は大きなオーバーヘッドを負うスレッドを必要とします。一方で、非同期サーバはイベント駆動であり、一つ(あるいは少なくとも2,3)のスレッドでリクエストを処理します。
プロセスベースのサーバは軽い負荷においてしばしば非同期サーバと同等の実行をすることができますが、重い負荷においてそれらはたいていあまりにおおくのRAMを消費します。これはパフォーマンスを酷く悪くします。また、それらのパフォーマンスはあまりパワーの無いハードウェア上、あるいはVPSのようなリソースに制限のある環境においては低下します。
何も見えない状態から具体的な数値を出してみると: 同時に10,000の接続を捌くには、NGIXはおそらく数メガバイトのRAMのみを必要とし、一方でApacheはおそらく数100メガバイトを消費するでしょう。 (if it could do it at all).
現時点では不明です。その変更無し/まで、同OSレベルの機能(例えば、BSD Jails、Linux上でproxyarpを使ったOpenVZ など)を使って同じ-あるいはより良い- 効果を得ることができます。
mod_suexecはNGINXが持たない問題への解決方法です。Apacheのようなサーバを実行する場合は、各インスタンは大量のRAMを消費します。ですので、全てを1つで処理するモノシリックのインスタンスだけを持つことが重要になります。NGINXを使うと、メモリとCPUの利用が低く、大量のインスタンスを実行しても問題ではありません。
Apache + mod_suexec に比較できるNGINXの恒星は、NGINXの個々のインスタンスをCGIスクリプトユーザ(つまり、Apache下でsuexecユーザとして指定されたユーザ)として実行することです。メインのNGINXインスタンスをプロキシします。
別のやり方として、PHPは単純にFastCGIを使って実行されることができます。これはCGIスクリプトユーザアカウント下で実行されます。
注意
mod_php (suexecが通常使われるモジュール)はNGINXにはありません。
@location は名前付きのlocationです。Named locations preserve $uri as it was before entering said location. それらは 0.6.6 で導入され、error_page, post_action (0.6.26) およびtry_files (0.7.27から。0.6.36にバックポートされました) を経由してのみ到達されます。
NGINX は(Squidのような)キャッシングプロキシとしてではなく、リバースプロキシとして一般的に配備されます。NGINXの主要な利点は、高負荷時の極めてわずかなRAMとCPUの利用です。Squidは動的なコンテンツを自分自身でキャッシュできないアプリケーションのためにとても良く適用されます。
ngx_http_proxy_module はupstreamサーバのキャッシュのための設定を提供します。
両方ともとても頻繁に聞かれる質問です。
現在のところ、唯一の解決策はサードパーティモジュールのNGINX アップロード進捗モジュールです。
(この機能はNGINXの将来のリリースで計画されています。)
IMAP プロキシの例から設定を始めます。
異なる設定パラメータについての詳細な情報は、ngx_mail_core_moduleページを見てください。
関連するリソース:
まず、以下のようにメール部分を宣言します:
mail {
server_name mail.somedomain.com;
auth_http localhost:8008/auth-smtppass.php;
server {
listen 212.104.99.24:25;
protocol smtp;
timeout 5s;
proxy on;
xclient off;
smtp_auth none;
}
}
見て分かるように、例は非認証のe-mailですが、認証が必要であればどうやるかについての情報をngx_mail_core_moduleを調べてください。デフォルトではPostfixはXCLIENTをサポートしません。ですので例のようにoffにしました。
次に、バックエンドの認証を設定する必要があります。1つのアドレスについて何らかのパススルーモードが必要であれば、以下のコードを使って行うことができます:
http {
log_format main
'$remote_addr - $remote_user [$time_local] '
'"$request" $status $bytes_sent '
'"$http_referer" "$http_user_agent" '
'"$gzip_ratio"';
server {
listen 127.0.0.1:8008;
server_name localhost;
access_log /var/log/nginx/localhost.access_log main;
error_log /var/log/nginx/localhost.error_log info;
root /var/www/localhost/htdocs;
location ~ .php$ {
add_header Auth-Server 127.0.0.1;
add_header Auth-Port 25;
return 200;
}
}
}
基本的に接続を受け付け、.phpファイルへのリクエストについてはコード200と(この場合)Postfixのバックエンド (ここでは 127.0.0.1:25) を返します。
現在のところ、NGINXはラウンドロビン、リースとコネクション、およびipハッシュアルゴリズム(全て重み付けがあります)があります。
ロードバランシングのための多くのサードパーティモジュールもあります。
注意
多くのユーザがロードバランサにバックエンドあたりのリクエスト数を制限する機能をNGINXに実装するように求めてきました(通常は1)。これのサポートは計画されていますが、この機能の要求はプロキシ"される"アプリケーション側の間違った挙動に根差していることを言っておいたほうが良いでしょう (Ruby on Rails はその例の一つと思われます)。これはNGINXの問題ではありません。理想的には、この特殊な修正リクエストはバックエンドアプリケーションと同時接続リクエストの処理(低)能力へと向けられるべきでしょう。