From: Yoshiki Hayashi Date: Mon, 30 Sep 2002 08:12:22 +0000 (+0000) Subject: New XML. X-Git-Url: https://granicus.if.org/sourcecode?a=commitdiff_plain;h=0a3ac35a3a6c5e46fc6cc72c58a56f7c8b8d4a63;p=apache New XML. git-svn-id: https://svn.apache.org/repos/asf/httpd/httpd/trunk@97018 13f79535-47bb-0310-9956-ffa450edef68 --- diff --git a/docs/manual/custom-error.xml.ja b/docs/manual/custom-error.xml.ja new file mode 100644 index 0000000000..0c4abbe8e7 --- /dev/null +++ b/docs/manual/custom-error.xml.ja @@ -0,0 +1,170 @@ + + + + + + + + + カスタムエラーレスポンス + + +

ウェブマスターが何らかのエラーや問題に対する + Apache の反応を設定できるようにする追加機能を提供します。

+ +

サーバがエラーや問題を発見した場合の反応を、 + カスタマイズして定義することができます。

+ +

スクリプトの実行が失敗して "500 Server Error" + を発生させたとします。この場合の反応を、より好ましいテキストや、別の + URL (内部及び外部) へのリダイレクションに置き換えることができます。 +

+ + +
+ 動作 + +
+ 古い動作 + +

NCSA httpd 1.3 は、古くて退屈なエラー/問題メッセージを + 返していました。それはしばしばユーザには無意味であり、 + またそれを発生させた原因を記録する方法も提供していませんでした。

+
+ +
+ 新しい動作 + +
    +
  1. NCSA のハードコードされたメッセージの代わりに + 他のテキストを表示
    2. + +
  2. ローカルの URL にリダイレクト
    3. + +
  3. 外部の URL にリダイレクト
    4. +
+ +

するようにサーバを設定できます。

+ +

別の URL にリダイレクトすることは役に立ちますが、 + それは説明をしたり、より明確に誤り/問題を記録したりするために + 何か情報を伝えられるときに限ります。

+ +

これを実現するために、 Apache は新しく CGI のような環境変数を + 定義します:

+ + + REDIRECT_HTTP_ACCEPT=*/*, image/gif, + image/x-xbitmap, image/jpeg
+ REDIRECT_HTTP_USER_AGENT=Mozilla/1.1b2 (X11; I; HP-UX + A.09.05 9000/712)
+ REDIRECT_PATH=.:/bin:/usr/local/bin:/etc
+ REDIRECT_QUERY_STRING=
+ REDIRECT_REMOTE_ADDR=121.345.78.123
+ REDIRECT_REMOTE_HOST=ooh.ahhh.com
+ REDIRECT_SERVER_NAME=crash.bang.edu
+ REDIRECT_SERVER_PORT=80
+ REDIRECT_SERVER_SOFTWARE=Apache/0.8.15
+ REDIRECT_URL=/cgi-bin/buggy.pl + + +

頭に付く REDIRECT_ に注目してください。

+ +

少なくとも REDIRECT_URL と + REDIRECT_QUERY_STRING は新しい URL (CGI スクリプトか + CGI インクルードであると仮定されます) に渡されます。 + 他の変数は、エラーや問題が起きる前に存在した場合にだけ存在します。 + もしあなたの設定した ErrorDocument が 外部リダイレクト + (すなわち、http: + のような体系名から始まるすべてのもの。たとえ同じホストを指していても) + ならば、これらはまったく設定されません。

+
+
+ +
+ 設定 + +

AllowOverride が適切に設定されていれば、 + .htaccess ファイルで ErrorDocument + を使用することができます。

+ +

ここに、いくつかの例を挙げます。

+ + + ErrorDocument 500 /cgi-bin/crash-recover
+ ErrorDocument 500 "Sorry, our script crashed. Oh dear"
+ ErrorDocument 500 http://xxx/
+ ErrorDocument 404 /Lame_excuses/not_found.html
+ ErrorDocument 401 /Subscription/how_to_subscribe.html + + +

構文

+ + + ErrorDocument <3-digit-code> <action> + + +

action (動作) は、

+ +
    +
  1. 表示されるべきテキスト。テキストには引用符 (") をつけます。 + 引用符の後に続くものが何でも表示されます。 + 注意 : (") は表示されません
    2. + +
  2. リダイレクト先の外部 URL
    3. + +
  3. リダイレクト先のローカル URL
    4. +
+
+ +
+ カスタムエラーレスポンスとリダイレクト + +

スクリプト/SSI に追加の環境変数が利用可能になるように、 + リダイレクトされた URL に対する Apache の動作が変更されました。

+ +
+ 古い動作 + +

リダイレクトされたスクリプトは標準の CGI + 環境変数を利用可能でした。しかし、どこからリダイレクト + されたかの情報は提供されていませんでした。

+
+ +
+ 新しい動作 + +

リダイレクトされた先のスクリプトが使用可能なように、 + 新しいたくさんの環境変数が初期化されます。新しい変数は、それぞれ + REDIRECT_ で始まります。 + REDIRECT_ で始まる環境変数はリダイレクトされる前に存在していた + CGI 環境変数の頭に REDIRECT_ を付けて作成されます。 + すなわち、HTTP_USER_AGENT は + REDIRECT_HTTP_USER_AGENT になります。 + これらの新しい変数に加えて、Apache は、 + スクリプトがリダイレクト元のトレースを助けるために + REDIRECT_URL と REDIRECT_STATUS + を定義します。アクセスログには元の URL とリダイレクトされた URL + の両方が記録されます。

+ +

ErrorDocument が CGI スクリプトへのローカルリダイレクトを + 指定している場合は、それを起動することになったエラーの状態を + クライアントまで確実に伝えるために "Status:" + ヘッダを含むべきです。例えば、ErrorDocument 用の Perl + スクリプトは以下のようなものを含むかもしれません。 +

+ + + ...
+ print "Content-type: text/html\n";
+ printf "Status: %s Condition Intercepted\n", $ENV{"REDIRECT_STATUS"};
+ ... + + +

スクリプトが 404 Not Found のような + 特定のエラーコンディションを扱うためだけに使われる場合は、 + 代わりに特定のコードとエラーテキストを使用することができます。

+
+
+ diff --git a/docs/manual/logs.xml.ja b/docs/manual/logs.xml.ja new file mode 100644 index 0000000000..9f2b1ad953 --- /dev/null +++ b/docs/manual/logs.xml.ja @@ -0,0 +1,580 @@ + + + + + + + + + ログファイル + + +

ウェブサーバを効果的に管理するためには、サーバの活動やパフォーマンス、 + 今発生しているかもしれない問題に関するフィードバックを得ることが必要です。 + Apache HTTP サーバには非常に包括的で柔軟なロギング機能があります。 + この文書はロギング機能の設定の仕方と、ログに何が書かれているかを + 理解するための方法を説明します。

+ + +
+ セキュリティに関する警告 + +

Apache がログファイルを書いているディレクトリに書き込める人は、 + ほぼ確実にサーバが起動された uid へのアクセスを手に入れることができます。 + そして、それは通常は root ユーザです。 + ちゃんと結果を考えることなく、そのディレクトリへの + 書き込み権限を与えないでください。詳しくは + セキュリティのこつの文書を + 読んでください。

+ +

加えて、ログファイルにはクライアントからの情報がそのまま、 + エスケープされることなく書かれています。ですから、悪意のある + クライアントがログファイルに制御文字を挿入することができます。 + 生のログを扱うときは注意してください。

+
+ +
+ エラーログ + + + ErrorLog + LogLevel + + + +

ErrorLog ディレクティブにより + 名前と場所が決まるサーバのエラーログは、一番重要なログファイルです。 + Apache の診断情報はここに送られ、リクエストを処理しているときに + 発生したエラーはすべてここに記録されます。サーバを起動したときや、 + サーバの動作に問題が起こったときは、一番最初に調べるべき + ところです。間違いの詳細や修正方法がそこに書かれていることが + よくあります。

+ +

エラーログは普通はファイルに書かれます (通常 unix システムでは + error_log、Windows と OS/2 では error.log)。 + Unix システムではエラーを syslog や + パイプでプログラムに送る ことができます。

+ +

エラーログの書式は比較的自由度の高いもので、説明的に書かれています。 + ただし、いくつかの情報はほとんどのエラーログのエントリにあります。 + 例えば、代表的なものに次のようなメッセージがあります。

+ + + [Wed Oct 11 14:32:52 2000] [error] [client 127.0.0.1] + client denied by server configuration: + /export/home/live/ap/htdocs/test + + +

ログエントリの最初の項目はメッセージの日付と時刻です。 + 二つめの項目は報告されているエラーの重要度です。 + LogLevel で重要度のレベルを + 制限することによりエラーログに送られるエラーの種類を制御することが + できます。三つ目の項目はエラーを発生させたクライアントの IP アドレス + です。残りはメッセージで、この場合はサーバがクライアントのアクセスを + 拒否するように設定されている、ということを示しています。 + サーバはリクエストされた文書の (ウェブのパスではなく) ファイルシステムの + パスを報告します。

+ +

非常に広範囲のメッセージがエラーログに現れます。たいていのものは + 上の例のような感じです。エラーログには CGI スクリプトのデバッグ + 出力も書かれます。CGI スクリプトが stderr に書いた + すべての情報は直接エラーログにコピーされます。

+ +

情報を追加したり削除したりしてエラーログをカスタマイズすることは + できません。しかし、リクエストに対するエラーログのエントリは、 + 対応するエントリがアクセスログにあります。 + 例えば、上の例のエントリはアクセスログのステータスコード 403 の + エントリに対応します。アクセスログはカスタマイズ可能ですので、 + そちらを使うことによりエラーの状況に関する情報をより多く + 手に入れることができます。

+ +

テストの最中は、問題が発生しているかどうかを見るために、 + 常にエラーログを監視するのが役に立つ場合がよくあります。 + Unix システムでは、次のものを使うことができます。

+ + + tail -f error_log + +
+ +
+ アクセスログ + + + + mod_log_config + mod_setenvif + + + CustomLog + LogFormat + SetEnvIf + + + +

サーバアクセスログはサーバが処理をしたすべてのリクエストを + 記録します。アクセスログの場所と内容は CustomLog + ディレクティブにより決まります。ログの内容の選択を簡潔にするために + LogFormat + ディレクティブを使用することができます。このセクションはアクセスログに + 情報を記録するためのサーバの設定方法を説明します。

+ +

もちろん、アクセスログに情報を蓄積することはログ管理の + 始まりに過ぎません。次の段階は有用な統計を取るためにこの情報を + 解析することです。一般的なログ解析はこの文書の範囲外で、 + ウェブサーバ自身の仕事というわけでもありません。この話や、 + ログ解析を行なうアプリケーションの情報を得るには、 + Open Directory や + Yahoo を調べてください。

+ +

いろんなバージョンの Apache httpd が mod_log_config, + mod_log_agent, TransferLog ディレクティブといった、 + 他のモジュールやディレクティブを使ってアクセスのロギングを + 制御してきました。今では、CustomLog がすべての古い + ディレクティブの機能を含むようになっています。

+ +

アクセスログの書式は非常に柔軟な設定が可能です。 + 書式は C の printf(1) フォーマット文字列に非常に似た + フォーマット文字列 + により指定されます。いくつか次の節で例を示します。 + フォーマット文字列に使用できる内容の一覧は mod_log_config の文書 + を見てください。

+ +
+ Common Log Format + +

アクセスログのよくある設定に以下のものがあります。

+ + + LogFormat "%h %l %u %t \"%r\" %>s %b" common
+ CustomLog logs/access_log common + + +

これは、ニックネーム common を定義し、 + ログのフォーマット文字列の一つと関連付けます。フォーマット文字列は + パーセントディレクティブからなり、それぞれのパーセントディレクティブは + サーバにどの情報をロギングするかを指示します。フォーマット文字列に + 文字をそのまま入れることもでき、それらはログの出力に直接コピーされます。 + そこに引用文字 (") を書くときは、 + フォーマット文字列の最後として解釈 + されることを防ぐためにバックスラッシュでエスケープする必要があります。 + フォーマット文字列には改行用の "\n"、タブ用の + "\t" という特別な制御文字も含めることができます。

+ +

CustomLog ディレクティブは + 既に定義された + ニックネーム を使って新しいログファイルを設定します。 + アクセスログのファイル名はスラッシュで始まらない限り、 + ServerRoot からの相対パスとして + 扱われます。

+ +

上の設定は Common Log Format (CLF) と呼ばれる形式で + ログエントリを書きます。この標準の形式は異なるウェブサーバの多くが + 生成することができ、多くのログ解析プログラムが読みこむことができます。 + CLF により生成されたログファイルのエントリは以下のようになります:

+ + + 127.0.0.1 - frank [10/Oct/2000:13:55:36 -0700] "GET + /apache_pb.gif HTTP/1.0" 200 2326 + + +

このログエントリのそれぞれの部分の意味は以下で説明します。

+ +
+
127.0.0.1 (%h)
+ +
これはサーバへリクエストをしたクライアント (リモートホスト) + の IP アドレスです。HostnameLookups が + On の場合は、サーバはホスト名を調べて、 + IP アドレスが書かれているところに記録します。しかし、この設定は + サーバをかなり遅くするので、あまりお勧めできません。 + そうではなく、logresolve の + ようなログの後処理を行なうプログラムでホスト名を調べるのが良いでしょう。 + ここに報告される IP アドレスは必ずしもユーザが使っているマシンの + ものであるとは限りません。ユーザとサーバの間にプロキシサーバが + あれば、このアドレスは元のマシンのものではなく、プロキシの + アドレスになります。
+ +
- (%l)
+ +
出力中の「ハイフン」は要求された情報が手に入らなかったということを + 意味します。この場合、取得できなかった情報はクライアントのマシンの + identd により決まる RFC 1413 のクライアントの + アイデンティティです。この情報はあまり信用することができず、 + しっかりと管理された内部ネットワークを除いては使うべきではありません。 + Apache は IdentityCheck が + On になっていない限り、この情報を得ようとすらしません。
+ +
frank (%u)
+ +
これは HTTP 認証による、ドキュメントをリクエストした人の + ユーザ ID です。CGI スクリプトには通常同じ値が REMOTE_USER + 環境変数として与えられます。リクエストのステータスコード + (以下を参照) が 401 であった場合は、ユーザは認証に失敗しているので、 + この値は信用できません。ドキュメントがパスワードで保護されていない + 場合は、このエントリは前のものと同じように "-" に + なります。
+ +
[10/Oct/2000:13:55:36 -0700] + (%t)
+ +
+ サーバがリクエストの処理を終えた時刻です。書式は: + +

+ [day/month/year:hour:minute:second zone]
+ day = 2*digit
+ month = 3*letter
+ year = 4*digit
+ hour = 2*digit
+ minute = 2*digit
+ second = 2*digit
+ zone = (`+' | `-') 4*digit +

+ ログのフォーマット文字列に %{format}t を + 指定することで、別の形式で時刻を表示させることもできます。 + このとき、format は C の標準ライブラリの + strftime(3) の形式になります。 +
+ +
"GET /apache_pb.gif HTTP/1.0" + (\"%r\")
+ +
クライアントからのリクエストが二重引用符の中に示されています。 + リクエストには多くの有用な情報があります。まず、この場合クライアントが + 使ったメソッドは GET です。次に、クライアントは + リソース /apache_pb.gif を要求しました。そして、 + クライアントはプロトコル HTTP/1.0 を使用しました。 + リクエストの各部分を独立にログ収集することもできます。例えば、 + フォーマット文字列 "%m %U%q %H" は + メソッド、パス、クエリ文字列、プロトコルをログ収集し、 + 結局 "%r" とまったく同じ出力になります。
+ +
200 (%>s)
+ +
サーバがクライアントに送り返すステータスコードです。 + この情報は、リクエストが成功応答 (2 で始まるコード) であったか、 + リダイレクション (3 で始まるコード) であったか、クライアントによる + エラー (4 で始まるコード) であったか、サーバのエラー (5 で始まるコード) + であったか、を現すので、非常に大切です。ステータスコードの + 完全なリストは HTTP + 規格 (RFC2616 第 10 節) にあります。
+ +
2326 (%b)
+ +
この最後のエントリはクライアントに送信されたオブジェクトの、 + 応答ヘッダを除いたサイズを現します。コンテントがクライアントに送られなかった + 場合は、この値は "-" になります。コンテントが無い場合に + "0" をログ収集するには、%b ではなく + %B を使ってください。
+ +
+
+ +
+ Combined Log Format + +

もう一つのよく使われる書式は Combined Log Format と呼ばれています。 + 以下のようにして使うことができます。

+ + + LogFormat "%h %l %u %t \"%r\" %>s %b \"%{Referer}i\" + \"%{User-agent}i\"" combined
+ CustomLog log/acces_log combined + + +

この書式の最初の方は Common Log Format とまったく同じで、最後に + 二つ追加のエントリがあります。追加のエントリはパーセントディレクティブ + %{header}i を使っています。ここで + header は HTTP のリクエストヘッダのどれかです。この書式による + アクセスログは以下のような感じになります:

+ + + 127.0.0.1 - frank [10/Oct/2000:13:55:36 -0700] "GET + /apache_pb.gif HTTP/1.0" 200 2326 + "http://www.example.com/start.html" "Mozilla/4.08 [en] + (Win98; I ;Nav)" + + +

追加のエントリは:

+ +
+
"http://www.example.com/start.html" + (\"%{Referer}i\")
+ +
"Referer" (意図的な綴り間違い) HTTP リクエストヘッダです。 + これはクライアントが報告してくる参照元のサイトを表します。 + (この場合は、/apache_pb.gif にリンクしているか、 + それを含んでいるページです)。
+ +
"Mozilla/4.08 [en] (Win98; I ;Nav)" + (\"%{User-agent}i\")
+ +
User-Agent HTTP リクエストヘッダです。これはクライアントのブラウザが + 自分自身のことを報告してくる情報です。
+
+
+ +
+ 複数のアクセスログ + +

複数のアクセスログは単に設定ファイルに複数の CustomLog + ディレクティブを書くことで作成されます。例えば、以下のディレクティブは + 三つのアクセスログを作ります。最初のものは基本的な CLF の情報で、 + 二つ目と三つ目は referer とブラウザの情報です。最後二つの + CustomLog は + ReferLog ディレクティブと + AgentLog ディレクティブの効果をまねる方法を示しています。

+ + + LogFormat "%h %l %u %t \"%r\" %>s %b" common
+ CustomLog logs/access_log common
+ CustomLog logs/referer_log "%{Referer}i -> %U"
+ CustomLog logs/agent_log "%{User-agent}i" + + +

この例は LogFormat で + ニックネームを定義する必要がない、 + ということも示しています。ニックネームの代わりに、 + CustomLog ディレクティブに + 直接ログの書式を指定することができます。

+
+ +
+ 条件付きログ + +

クライアントのリクエストの特徴に基づいてアクセスログにエントリの + 一部をロギングしない方が便利なことがあります。これは 環境変数 の補助により簡単に実現できます。まず、 + リクエストが何らかの条件に合うということを現すために環境変数が + 設定される必要があります。これは通常は SetEnvIf により + 行なわれます。そして、CustomLog ディレクティブの + env= 節を使って環境変数が設定されているリクエストを + 含めたり排除したりすることができます。いくつか例を挙げます:

+ + + # Mark requests from the loop-back interface
+ SetEnvIf Remote_Addr "127\.0\.0\.1" dontlog
+ # Mark requests for the robots.txt file
+ SetEnvIf Request_URI "^/robots\.txt$" dontlog
+ # Log what remains
+ CustomLog logs/access_log common env=!dontlog + + +

他の例として、英語を話す人からのリクエストとそれ以外の人からのリクエストを + 分けたい、という場合を考えてみてください。

+ + + SetEnvIf Accept-Language "en" english
+ CustomLog logs/english_log common env=english
+ CustomLog logs/non_english_log common env=!english + + +

ここまででは条件付きロギングが非常に強力で柔軟であることを示してきましたが、 + それがログの内容を制御する唯一の方法というわけではありません。ログファイルは + サーバの活動の完全な記録である方がより役に立ちます。単純にログファイルを + 後処理して、考慮したくないログを削除する方が簡単であることがよくあります。

+
+
+ +
+ ログの交替 + +

普通の負荷のサーバでさえ、ログファイルに保存される情報の量は + 膨大になります。アクセスログのファイルは普通 10,000 リクエスト毎に + 1 MB 以上増えます。ですから、既存のログを移動したり、削除したりして、 + 定期的にログを交替させることが必要になります。これはサーバの実行中には + 行なえません。というのは、Apache はファイルが open されている間は + ずっと古いログファイルに書き続けるからです。 + 新しいログファイルを open できるように、ログファイルが移動されたり + 削除された後に、サーバを再起動する + 必要があります。

+ +

優雅な 再起動を行なうことで、サーバは既存のコネクションや + 処理待ちのコネクションを失うことなく新しいログファイルを open させる + ことができます。しかし、これを実現するために、サーバは古いリクエストを + 扱っている間は古いログファイルに書き続ける必要があります。 + ですから、再起動の後ではログファイルの処理を始める前に、しばらく待たなければ + なりません。単にログを交替させて、ディスクの節約のために古いログを + 圧縮する普通のシナリオは:

+ + + mv access_log access_log.old
+ mv error_log error_log.old
+ apachectl graceful
+ sleep 600
+ gzip access_log.old error_log.old + + +

ログの交替をするもう一つの方法はパイプ経由のログを使うもので、次の節で説明されています。

+
+ +
+ パイプ経由のログ + +

Apache httpd はエラーログとアクセスログをファイルに直接書く代わりに、 + パイプを通して別のプログラムに書き出すことができます。 + この機能により、主サーバにコードを追加することなく + ロギングの柔軟性が非常に高まっています。パイプにログを書くためには、 + 単にファイル名をパイプ文字 "|" に置き換え、その続きに + 標準入力からログのエントリを受けとる実行プログラムの名前を書くだけです。 + Apache はパイプ経由のログ用のプロセスをサーバの起動時に実行し、 + サーバの実行中にそのプログラムがクラッシュしたときはそれを再び + 実行します。(この最後の機能がこの技術が「信頼性のあるパイプ経由のロギング」 + と呼ばれている理由です。)

+ +

パイプ経由のログ用のプロセスは Apache httpd の親プロセスから起動され、 + そのプロセスのユーザ ID を継承します。これは、これは、パイプ経由のログ用の + プログラムは普通 root として実行されることを意味します。 + ですから、プログラムを簡単で安全に保つことが非常に重要です。

+ +

パイプ経由のログを使う簡単な例は:

+ + + # compressed logs
+ CustomLog "|/usr/bin/gzip -c >> + /var/log/access_log.gz" common
+ # almost-real-time name resolution
+ CustomLog "|/usr/local/apache/bin/logresolve >> + /var/log/access_log" common + + +

パイプの先で呼ばれるコマンド全体が引用符で囲まれていることに注目して + ください。この例はアクセスログを使っていますが、エラーログにも同じ技術を + 使うことができます。

+ +

パイプ経由のログの重要な利用法は、ログの交替をサーバの再起動なしで + するものです。Apache HTTP サーバにはこのための rotatelogs と呼ばれる簡単な + プログラムが付属しています。たとえば、24 時間毎にログを交替させるには、 + 以下のものを使うことができます:

+ + + CustomLog "|/usr/local/apache/bin/rotatelogs + /var/log/access_log 86400" common + + +

似ているけれど、よりずっと柔軟な + cronolog というログ交替用の + プログラムが外部のサイトにあります。

+ +

条件付きロギングと同様、パイプ経由のログは非常に強力な + 道具ですが、オフラインの後処理のような、より簡単な解決方法があるときは + 使わない方が良いでしょう。

+
+ +
+ バーチャルホスト + +

多くの バーチャルホスト のあるサーバを実行している + ときは、ログファイルの扱い方にいくつかの方法があります。 + まず、単独のホストのみのサーバとまったく同じようにログを使うことができます。 + ロギングディレクティブを主サーバのコンテキストの + VirtualHost セクションの外に置くことで、 + すべてのログを同じアクセスログとエラーログにログ収集することができます。 + この手法では個々のバーチャルホストの統計を簡単にとることはできません。

+ +

>CustomLog や + ErrorLog ディレクティブが + VirtualHost の中に + 置かれた場合は、そのバーチャル + ホストへのすべてのリクエストやエラーがそこで指定されたファイルにのみ + ログ収集されます。ロギングディレクティブのないバーチャルホストは + 依然としてリクエストが主サーバのログに送られます。この手法は少ない + バーチャルホストに対しては非常に有用ですが、ホストの数が非常に多くなると + 管理が大変になります。さらに、ファイル記述子の限界の問題を起こすことが + あります。

+ +

アクセスログには、非常に良い妥協案があります。バーチャルホストの + 情報をログのフォーマット文字列に加えることで、すべてのホストへの + リクエストを同じログにログ収集して、後でログを個々のファイルに分割することが + できます。たとえば、以下のディレクティブを見てください。

+ + + LogFormat "%v %l %u %t \"%r\" %>s %b" + comonvhost
+ CustomLog logs/access_log comonvhost + + +

%v がリクエストを扱っているバーチャルホストの名前を + ログ収集するために使われています。そして、split-logfile のようなプログラムを + 使ってアクセスログを後処理することで、 + バーチャルホスト毎のファイルにログを分割することができます。

+ +

残念ながら、エラーログには同様の手法はありません。ですから、 + すべてのバーチャルホストを同じエラーログの中に混ぜるか、 + バーチャルホスト毎にエラーログを使うかを選ばなければなりません。

+
+ +
+ 他のログファイル + + + + mod_cgi + mod_rewrite + + + PidFile + RewriteLog + RewriteLogLevel + ScriptLog + ScriptLogBuffer + ScriptLogLength + + + +
+ PID ファイル + +

起動時に、Apache は親 httpd プロセスのプロセス ID を + logs/httpd.pid に保存します。この + ファイル名は PidFile ディレクティブを使って + 変更することができます。プロセス ID は管理者が親プロセスに + シグナルを送ることでデーモンを再起動したり終了させたりするときに + 使用します。Windows では、代わりに -k コマンドオプションを + 使ってください。詳しい情報は 終了と + 再起動 のページを見てください。

+
+ +
+ スクリプトログ + +

デバッグの補助のために、ScriptLog ディレクティブは + CGI スクリプトの入力と出力を記録するようにできます。 + これはテスト用にのみ使用して、通常のサーバでは使用しないでください。 + 詳しい情報は mod_cgi の文書 にあります。

+
+ +
+ リライトログ + +

mod_rewrite の強力で + 複雑な機能を + 使っているときは、ほぼいつもデバッグを簡単にするために + RewriteLog の使用が + 必要でしょう。このログファイルにはリライトエンジンがリクエストを + 書き換える方法の詳細な解析が出力されます。詳しさの度合は RewriteLogLevel + で制御できます。

+
+
+ diff --git a/docs/manual/server-wide.xml.ja b/docs/manual/server-wide.xml.ja new file mode 100644 index 0000000000..7c08b13bc9 --- /dev/null +++ b/docs/manual/server-wide.xml.ja @@ -0,0 +1,101 @@ + + + + + + + + サーバ全体の設定 + + +

このドキュメントではcore +サーバのディレクティブの中で、 +基本動作を設定するためのものを説明します。

+ + +
+ サーバ ID + + + + ServerName + ServerAdmin + ServerSignature + ServerTokens + UseCanonicalName + + + +

ServerAdmin ディレクティブと + ServerTokens + ディレクティブは、エラーメッセージなどのサーバが作るドキュメントに、 + どのようなサーバの情報を表示するかを制御します。 + ServerTokens ディレクティブは、Server HTTP + レスポンスヘッダフィールドの値を設定します。

+ +

ServerName ディレクティブと + UseCanonicalName + ディレクティブは、サーバが自分自身を参照する URL + を作るときに使われます。 + たとえば、クライアントがディレクトリを要求して、 + そのディレクトリ名の最後にスラッシュが付いていないような場合には、 + ドキュメントの相対的な参照を正しく解決できるようにするために、 + Apache は最後のスラッシュを含んだ完全なパスにクライアントを + リダイレクトさせる必要があります。

+
+ +
+ ファイルの位置 + + + + CoreDumpDirectory + DocumentRoot + ErrorLog + LockFile + PidFile + ScoreBoardFile + ServerRoot + + + +

これらのディレクティブは Apache + が適切な動作をするために必要な各種ファイルの位置を制御します。 + パスがスラッシュ (/) で始まっていないときは、ファイルは + ServerRoot からの相対パスとして + 探されます。root + 以外のユーザが書き込み可能なパスにファイルを置く場合は注意が必要です。 + 詳細は「セキュリティ情報」 + を参照してください。

+
+ +
+ リソースの制限 + + + + LimitRequestBody + LimitRequestFields + LimitRequestFieldsize + LimitRequestLine + RLimitCPU + RLimitMEM + RLimitNPROC + ThreadStackSize + + + +

LimitRequest* ディレクティブは Apache + がクライアントからのリクエスト読み込みで使う + リソースを制限するために使われます。これらの値を制限することで、 + いくつかのサービス拒否攻撃は影響を和らげることができます。

+ +

RLimit* ディレクティブは、Apache の子プロセスから + fork されたプロセスが使用するリソースを制限するために使われます。 + 特に、これは CGI スクリプトと SSI exec + コマンドで使われるリソースを制御します。

+ +

ThreadStackSize は Netware + でのみ、スタックの大きさを制御するために使われます。

+
+ diff --git a/docs/manual/stopping.xml.ja b/docs/manual/stopping.xml.ja new file mode 100644 index 0000000000..6cb5c79c5f --- /dev/null +++ b/docs/manual/stopping.xml.ja @@ -0,0 +1,209 @@ + + + + + + + + 停止と再起動 + + +

この文書では Unix に類似したシステムでの + Apache の停止と再起動について扱っています。Windows + ユーザ (Windows で Apache を使う場合) は、実行中の Apache + にシグナルを送るもご覧下さい。

+ + +
イントロダクション +

たくさんの実行形式 httpd がシステム上で + 実行されているのに気が付くでしょうが、シグナルを送るのは + 親プロセスだけで、それ以外の個々のプロセスには + シグナルを送らないで下さい。その親プロセスの pid は + PidFile + に書かれています。これはつまり、親以外のプロセスに + シグナルを送る必要すらない、ということです。 + 親プロセスに送ることができる 3 種類のシグナルがあります: + TERM, HUP, USR1 + です。これらの説明については続きをご覧下さい。

+ +

親プロセスにシグナルを送るには、 + 次のようなコマンドを発行して下さい:

+ +kill -TERM `cat /usr/local/apache/logs/httpd.pid` + +

これの実行状況は次のコマンドで読むことができます:

+ +tail -f /usr/local/apache/logs/error_log +

ここに挙げた例は、各自の + ServerRoot + と + PidFile + の設定に適合するように適宜修正して下さい。

+ +

apachectl + と呼ばれるシェルスクリプトで、Apache にシグナルを送る手順を + 自動化することができます。このスクリプトの詳細に関しては、 + Apache の起動の文書をご覧下さい。

+
+ +
急な停止 + +
シグナル: TERM
+
apachectl stop
+
+ +

TERM シグナルを親プロセスに送ると、 + 即座に子プロセス全てを kill しようとします。 + 子プロセスを完全に kill し終わるまでに数秒かかるかもしれません。 + その後、親プロセス自身が終了します。 + 処理中のリクエストは全て停止され、もはやリクエストに対する + 応答はされません。

+
+ +
緩やかな再起動 + +
シグナル: USR1
+
apachectl graceful
+
+ +

親プロセスは USR1 シグナルを受け取ると、 + 子プロセスに現在のリクエストの処理の後に終了する + (あるいは何もしていなければすぐに終了する) + ように助言します。 + 親プロセスは設定ファイルを再読込して、ログファイルを開き直します。 + 子プロセスが徐々になくなるに従って、 + 新しい世代の設定による子プロセスに置き換えていきます。 + そして、これらが新たなリクエストに即座に応答し始めます。

+ 特定のプラットホームでは USR1 を緩やかな再起動のために + 使うことができませんが、代わりのシグナル + (例えば WINCH) が使用できるでしょう。 + apachectl graceful + というコマンドはプラットホームに合ったシグナルを送ります。 + +

このコードは常に + MPM のプロセス制御ディレクティブの設定を重視しますので、 + クライアントのリクエストを扱うプロセスとスレッドの数を再起動の処理中も + 適切な値に維持されます。。また、次のようにして + StartServers + を守ります: + 少なくとも 1 秒後に StartServers 個の新しい子プロセスが + 生成されていなければ、その数になるように適宜プロセスを生成します。 + この挙動は現在の負荷に対して適切な子プロセスの数と + StartServers パラメータでの + 希望の数の両方を維持しようとしています。

+ +

mod_status を + 使用している場合は、USR1 シグナルが送られた際に + サーバ統計がゼロに設定されないことに + 注意してください。 + サーバが新しいリクエストに応答不能な時間を最小にするように + (リクエストは OS によってキューに追加されるので絶対に紛失はしません)、 + また同時に、希望のチューニングパラメータを守るように + コードは書かれています。 + このようにするために、世代をまたがった全子プロセスの追跡に使われている + スコアボードを維持しなければなりません。

+ +

status モジュールは、緩やかな再起動以前から開始して + リクエストに応答し続けている子プロセスを特定するために、 + G を使うこともします。

+ +

現在、USR1 を使うログ移動スクリプトでは、 + 再起動前の子プロセスがログを書き終わったことを確証する方法が + ありません。古いログに対して何かする前に、 + USR1 シグナルを送った後いくらか適当な時間待つことを + 提案します。例えば、帯域の狭い通信路のユーザのリクエストのほとんどが 10 + 分以下で完了しているということが分かっていれば、 + 古いログに何かする前に 15 分待つということです。

+ + 再起動時に設定ファイルに誤りがあると、 + 親プロセスは再起動せずにエラーとともに終了します。 + 緩やかな再起動の場合は、親プロセスが終了した後でも子プロセスが + 実行されたまま放置されたりもします。 + (最後のリクエストを処理した後「緩やかに終了」する + 子プロセスとなります。) + サーバを再起動する際に、これが問題になるかもしれません + -- サーバは listen するポートにバインドできないかもしれません。 + 再起動する前に、設定ファイルの構文を -t + コマンドライン引数 + (httpd をご覧下さい) + を使って検証することができます。 + 設定ファイルの意味的な内容を構文と同様に検証したい場合は、 + 非 root ユーザで httpd を起動しようとすればわかります。 + もしエラーがなければ、ソケットやログを開こうとして + root でないため + (もしくは httpd が既に必要なポートにバインドしているため) + に失敗するでしょう。 + これ以外の理由で起動に失敗したのであれば、 + それは設定ファイルのエラーで、 + 緩やかな再起動を行う前にその誤りを修正しなければなりません。 +
+ +
急な再起動 + +
シグナル: HUP
+
apachectl restart
+
+ +

HUP シグナルを親プロセスに送ると、 + TERM と同様に子プロセスを kill しますが、 + 親プロセスは終了しません。 + 設定ファイルを再読込して、ログファイル全てを開き直します。 + その後、新しい子プロセスを起動して応答を続けます。

+ +

mod_status + を使っている場合は、HUP が送られた場合に + サーバ統計がゼロに設定されることに注意してください。

+ + 再起動時に設定ファイルに誤りがあると、 + 親プロセスは再起動せずにエラーとともに終了します。 + これを避けるには次の方法をご覧下さい。 +
+ +
付録: シグナルと競合状態 + +

Apache 1.2b9 以前は、再起動や停止のシグナルを含む競合状態 + (競合状態を簡単に説明すると: タイミンにグよる問題で、 + 具合の悪い時間帯にちょうど何かが起こると予想外の動作をする + ようなことを指します) がありました。 + 「正しい」機能を持っているアーキテクチャでは、できるだけ + このようなことが起こらないようにしています。 + しかし、ある種のアーキテクチャでは競合状態は未だ確実に起こりえる + ということに注意してください。

+ +

ディスク上で + ScoreBoardFile + を使用しているアーキテクチャでは、 + 潜在的にスコアボードが壊れる可能性があります。 + スコアボードが壊れた場合は、 + "bind: Address already in use" (HUP 後) や + "long lost child came home!" (USR1 後) + といった結果になります。 + 前者は致命的なエラーですが、 + 後者はスコアボードスロットを失うだけです。 + ですから緩やかな再起動は、たまに確実な再起動 (HUP) + も併用して使った方が良いでしょう。 + これらの問題を克服するのは非常に難しいのですが、 + 幸いなことに大部分のアーキテクチャではスコアボードのファイルは必要ありません。 + これを使用するアーキテクチャは、 + ScoreBoardFile + をご覧下さい。

+ +

全てのアーキテクチャにおいて、個々の子プロセスで + 継続的な HTTP コネクション (KeepAlive) + に関する小さな競合状態が起こりえます。 + リクエスト行を読んだ後、そしてリクエストヘッダを読む前に + 子プロセスは終了するかも知れません。 + これに対する修正がありますが 1.2 で修正するには発見が遅すぎました。 + 理論的には、これは問題ではありません。 + なぜなら KeepAlive のクライアントは、ネットワーク遅延や + サーバのタイムアウトなどに備えていなければならないからです。 + 実際にも何か影響があるようには見えません + -- テストケースでサーバを 1 秒間に 20 回再起動しても + クライアントは壊れた画像や空のドキュメントを受け取ることなく + 正常に閲覧できています。

+
+ + diff --git a/docs/manual/suexec.xml.ja b/docs/manual/suexec.xml.ja new file mode 100644 index 0000000000..7d7fe35360 --- /dev/null +++ b/docs/manual/suexec.xml.ja @@ -0,0 +1,559 @@ + + + + + + + + + suEXEC サポート + + +

suEXEC + 機能により、Apache ユーザは Web サーバを実行しているユーザ ID とは + 異なるユーザ ID で CGI プログラムや SSI + プログラムを実行することができます。CGI プログラムまたは SSI + プログラムを実行する場合、通常は web サーバと同じユーザで実行されます。 +

+ +

適切に使用すると、この機能によりユーザが個別の CGI + や SSI プログラムを開発し実行することで生じるセキュリティ上の危険を、 + かなり減らすことができます。しかし、suEXEC の設定が不適切だと、 + 多くの問題が生じ、あなたのコンピュータに新しいセキュリティホールを + 作ってしまう可能性があります。あなたが root に setuid + されたプログラムと、それらから生じるセキュリティ上の問題の管理に + 詳しくないようなら、suEXEC の使用を検討しないように強く推奨します。 +

+ + +
始める前に + +

この文書の先頭に飛ぶ前に、Apache + グループとこの文書での仮定を知っておくべきでしょう。 +

+ +

第 1 に、あなたが setuid と + setgid 操作が可能な UNIX + 由来のオペレーティングシステムを使っていることを想定しています。 + これは、すべてのコマンド例にあてはまります。 + その他のプラットホームでは、もし suEXEC + がサポートされていたとしても設定は異なるかもしれません。

+ +

第 2 に、あなたが使用中のコンピュータの + セキュリティに関する基本的な概念と、それらの管理について詳しいことを + 想定しています。これは、setuid/setgid + 操作、あなたのシステム上でのその操作による様々な効果、 + セキュリティレベルについてあなたが理解しているということを含みます。 +

+ +

第 3 に、改造されていない suEXEC + コードの使用を想定しています。suEXEC のコードは、 + 多くのベータテスタだけでなく、開発者によっても注意深く精査され + テストされています。それらの注意により、簡潔で信頼できる安全な + コードの基盤が保証されます。このコードを改変することで、 + 予期されない問題や新しいセキュリティ上の危険が生じることがあります。 + セキュリティプログラミングの詳細に通じていて、 + 今後の検討のために成果を Apache + グループと共有しようと思うのでなければ、suEXEC + コードは変えないことを 強く推奨します。

+ +

第 4 に、これが最後ですが、suEXEC を Apache + のデフォルトインストールには含めないことが + Apache グループで決定されています。これは、suEXEC + の設定には管理者の詳細にわたる慎重な注意が必要だからです。 + suEXEC の様々な設定について検討が終われば、管理者は suEXEC + を通常のインストール方法でインストールすることができます。 + これらの設定値は、suEXEC + 機能の使用中にシステムセキュリティを適切に保つために、 + 管理者によって慎重に決定され指定されることが必要です。 + この詳細な手順により、Apache グループは、suEXEC + のインストールについて、注意深く十分に検討してそれを使用することを + 決定した場合に限っていただきたいと考えています。 +

+ +

それでも進みますか? よろしい。では、先へ進みましょう!

+
+ +
suEXEC セキュリティモデル + +

suEXEC の設定とインストールを始める前に、 + まず実装しようとしているセキュリティモデルについて論じておきます。 + それには、suEXEC の内部で行なわれていること、 + システムのセキュリティを保証するために警告されることを + よく理解しておいた方がよいでしょう。

+ +

suEXEC は、Apache web + サーバから呼び出される setuid された "wrapper" + プログラムが基本となっています。設計した CGI、または SSI + プログラムへの HTTP リクエストがあると、この wrapper + が呼び出されます。このようなリクエストがあると、Apache + はそのプログラムが実行される際のプログラム名とユーザ ID とグループ + ID を指定して suEXEC wrapper を実行します。 +

+ +

それから、wrapper は成功または失敗を決定するため + 以下の処理を行ないます。これらの状態のうち一つでも失敗した場合、 + プログラムは失敗をログに記録してエラーで終了します。 + そうでなければ、後の処理が続けられます。

+ +
    +
  1. + wrapper が適切な数の引数で呼び出されたか? + + +

    + wrapper は適切な数の引数が与えられた場合にのみ実行されます。 + 適切な引数のフォーマットは Apache Web サーバに解釈されます。 + 適切な数の引数を受け取らなければ、攻撃をされたか + あなたの Apache バイナリの suEXEC の部分が + どこかおかしい可能性があります。 +

    +
    2. + + +
  2. + wrapper + を実行しているユーザはこのシステムの正当なユーザか? + +

    + これは、wrapper を実行しているユーザが + 本当にシステムの利用者であることを保証するためです。 +

    +
    3. + +
  3. + この正当なユーザは wrapper + の実行を許可されているか? + +

    + このユーザは wrapper 実行を許可されたユーザですか? + ただ一人のユーザ (Apache ユーザ) だけが、 + このプログラムの実行を許可されます。 +

    +
    4. + +
  4. + 対象のプログラムが安全でない階層の参照をしているか? + + +

    + 対象のプログラムが '/' から始まる、または + '..' による参照を行なっていますか? これらは許可されません。 + 対象のプログラムは Apache の web 空間内になければなりません。 +

    +
    5. + +
  5. + 対象となるユーザ名は正当なものか? + +

    + 対象となるユーザ名は存在していますか? +

    +
    6. + +
  6. + 対象となるグループ名は正当なものか? + +

    + 対象となるグループ名は存在していますか? +

    +
    7. + +
  7. + 目的のユーザはスーパーユーザではないか? + + +

    + 今のところ、suEXEC は 'root' による CGI/SSI + プログラムの実行を許可していません。 +

    +
    8. + +
  8. + 対象となるユーザ ID は、最小の ID + 番号よりも大きいか? + +

    + 最小ユーザ ID 番号は設定時に指定されます。これは、 + CGI/SSI プログラム実行を許可されるユーザ ID + のとりうる最小値です。これは + "system" 用のアカウントを閉め出すのに有効です。 +

    +
    9. + +
  9. + 対象となるグループはスーパーユーザのグループでは + ないか? + +

    + 今のところ、suEXEC は 'root' グループによる CGI/SSI + プログラムの実行を許可していません。 +

    +
    10. + +
  10. + 対象となるグループ ID は最小の ID + 番号よりも大きいか? + +

    + 最小グループ ID 番号は設定時に指定されます。これは、 + CGI/SSI プログラム実行を許可されるグループ + ID のとりうる最小値です。 + これは "system" 用のグループを閉め出すのに有効です。 +

    +
    11. + +
  11. + wrapper が正常に対象となるユーザとグループになれるか? + + +

    + ここで、setuid と setgid + の起動によりプログラムは対象となるユーザとグループになります。 + グループアクセスリストは、 + ユーザが属しているすべてのグループで初期化されます。 +

    +
    12. + +
  12. + プログラムが置かれるディレクトリは存在しているか? + + +

    + ディレクトリが存在しないなら、そのファイルも存在しないかもしれません。 +

    +
    13. + +
  13. + ディレクトリが Apache のドキュメントツリー内にあるか? + + +

    + リクエストがサーバ内のものであれば、 + 要求されたディレクトリがサーバのドキュメントルート配下にありますか? + リクエストが UserDir のものであれば、 + 要求されたディレクトリがユーザのドキュメントルート配下にありますか? +

    +
    14. + +
  14. + ディレクトリを他のユーザが書き込めるようになって + いないか? + +

    + ディレクトリを他ユーザに開放しないようにします。 + 所有ユーザだけがこのディレクトリの内容を改変できるようにします。 +

    +
    15. + + +
  15. + 対象となるプログラムは存在するか? + +

    + 存在しなければ実行できません。 +

    +
    16. + +
  16. + 対象となるプログラムファイルが他アカウントから + 書き込めるようになっていないか? + +

    + 所有者以外にはプログラムを変更する権限は与えられません。 +

    +
    17. + + +
  17. + 対象となるプログラムが setuid または setgid + されていないか? + +

    + UID/GID を再度変更してのプログラム実行はしません +

    +
    18. + + +
  18. + 対象となるユーザ/グループがプログラムの + ユーザ/グループと同じか? + +

    + ユーザがそのファイルの所有者ですか? +

    +
    19. + +
  19. + 安全な動作を保証するための環境変数クリアが可能か? + + +

    + suEXEC は、安全な環境変数のリスト + (これらは設定時に作成されます) 内の変数として渡される安全な + PATH 変数 (設定時に指定されます) を設定することで、 + プロセスの環境変数をクリアします。 +

    +
    20. + + +
  20. + 対象となるプログラムを exec して実行できるか? + + +

    + ここで suEXEC が終了し、対象となるプログラムが開始されます。 +

    +
    21. +
+ +

ここまでが suEXEC の wrapper + におけるセキュリティモデルの標準的な動作です。もう少し厳重に + CGI/SSI 設計についての新しい制限や規定を取り入れることもできますが、 + suEXEC はセキュリティに注意して慎重に少しずつ開発されてきました。 +

+ +

このセキュリティモデルを用いて + サーバ設定時にどのように許すことを制限するか、また、suEXEC + を適切に設定するとどのようなセキュリティ上の危険を避けられるかに + 関するより詳しい情報については、"とかげに注意" + (Beware the Jabberwock) の章を参照してください。 +

+
+ +
suEXEC + の設定とインストール + +

ここから楽しくなります。

+ +

suEXEC + 設定オプション
+

+ +
+
--enable-suexec
+ +
このオプションは、デフォルトではインストールされず、 + 有効にはならない suEXEC 機能を有効にします。 + suEXEC を使うように APACI に要求するには、--enable-suexec + オプションにあわせて少なくとも一つは --with-suexec-xxxxx + オプションが指定されなければなりません。
+ +
--with-suexec-bin=PATH
+ +
セキュリティ上の理由により、suexec バイナリのパスはサーバに + ハードコードされている必要があります。デフォルトのパスを + 変えたいときはこのオプションを使ってください。例えば、 + --with-suexec-bin=/usr/sbin/suexec のように。
+ +
--with-suexec-caller=UID
+ +
Apache を通常動作させるユーザ名を指定します。 + このユーザだけが suexec の実行を許可されたユーザになります。
+ +
--with-suexec-userdir=DIR
+ +
suEXEC がアクセスを許されるユーザホームディレクトリ配下の + サブディレクトリを指定します。 + このディレクトリ以下の全実行ファイルは、"安全な"プログラムになるよう、 + suEXEC がそのユーザとして実行できるようにします。 + "単純な" UserDir ディレクティブを使っている場合 + (すなわち "*" を含まないもの)、これと同じ値を設定すべきです。 + Userdir ディレクティブがそのユーザのパスワードファイル内の + ホームディレクトリと同じ場所を指していなければ、 + suEXEC は適切に動作しません。デフォルトは "public_html" です。 +
+ 各 UserDir が異なった仮想ホストを設定している場合、 + それらを全て一つの親ディレクトリに含めて、 + その親ディレクトリの名前をここで指定する必要があります。 + このように指定されなければ "~userdir" cgi + へのリクエストが動作しません。
+ +
--with-suexec-docroot=DIR
+ +
Apache のドキュメントルートを設定します。これが suEXEC + の動作で使用する唯一のディレクトリ階層になります (UserDir + の指定は別)。デフォルトでは --datedir に "/htdocs" + というサフィックスをつけたものです。 + "--datadir=/home/apache" として設定すると、 + suEXEC wrapper にとって "/home/apache/htdocs" + がドキュメントルートとして使われます。
+ +
--with-suexec-uidmin=UID
+ +
suEXEC の対象ユーザとして許される UID の最小値を指定します。 + 大抵のシステムでは 500 か 100 が一般的です。 + デフォルト値は 100 です。
+ +
--with-suexec-gidmin=GID
+ +
suEXEC の対象グループとして許される GID + の最小値を指定します。大抵のシステムでは 100 が一般的なので、 + デフォルト値としても 100 が使われています。
+ +
--with-suexec-logfile=FILE
+ +
suEXEC の処理とエラーが記録されるファイル名を指定します。 + (監査やデバッグ目的に有用) + デフォルトではログファイルは "suexec_log" という名前で、 + 標準のログファイルディレクトリ (--logfiledir) に置かれます。 +
+ +
--with-suexec-safepath=PATH
+ +
CGI 実行ファイルに渡される安全な PATH 環境変数です。 + デフォルト値は "/usr/local/bin:/usr/bin:/bin" です。 +
+
+ +

suEXEC 設定の確認 +
+ suEXEC wrapper をコンパイルしてインストールする前に、設定内容を + --layout オプションで確認できます。
+ 出力例:

+ + suEXEC setup:
+ suexec binary: /usr/local/apache/sbin/suexec
+ document root: /usr/local/apache/share/htdocs
+ userdir suffix: public_html
+ logfile: /usr/local/apache/var/log/suexec_log
+ safe path: /usr/local/bin:/usr/bin:/bin
+ caller ID: www
+ minimum user ID: 100
+ minimum group ID: 100
+ + +

suEXEC wrapper + のコンパイルとインストール
+ --enable-suexec オプションで suEXEC 機能を有効にすると、 + "make" コマンドを実行した時に suEXEC のバイナリ (Apache 自体も) + が自動的に作成されます。 +
+ すべての構成要素が作成されると、それらのインストールには + "make install" コマンドが実行できます。バイナリイメージの "suexec" + は --sbindir オプションで指定されたディレクトリにインストールされます。 + デフォルトの場所は "/usr/local/apache/sbin/suexec" です。
+ インストール時には root + 権限が必要なので注意してください。wrapper がユーザ ID + を設定するために、所有者 root + でのセットユーザ ID + ビットをそのファイルのモードに設定しなければなりません。 +

+
+ +
suEXEC + の有効化と無効化 + +

起動時に、Apache は "sbin" ディレクトリで + "suexec" を探します + (デフォルトは "/usr/local/apache/sbin/suexec") 。 + 適切に設定された suEXEC がみつかると、 + エラーログに以下のメッセージが出力されます。

+ + [notice] suEXEC mechanism enabled (wrapper: /path/to/suexec) + + +

サーバ起動時にこのメッセージが出ない場合、 + 大抵はサーバが想定した場所で wrapper プログラムが見つからなかったか、 + setuid root としてインストールされていないかです。

+ +

suEXEC の仕組みを使用するのが初めてで、Apache が既に動作中であれば、 + Apache を kill して、再起動しなければなりません。HUP シグナルや + USR1 シグナルによる単純な再起動では不十分です。

+

suEXEC を無効にする場合は、"suexec" ファイルを削除してから + Apache を kill して再起動します。 +

+
+ +
suEXEC の使用 + +

仮想ホスト:
+ suEXEC wrapper の使い方として、 + VirtualHost 設定での + SuexecUserGroup + ディレクティブを通したものがあります。 + このディレクティブをメインサーバのユーザ ID + と異なるものにすると、CGI リソースへのすべてのリクエストは、その + VirtualHost で指定された User と + Group として実行されます。VirtualHost + でこのディレクティブが指定されていない場合、 + メインサーバのユーザ ID が想定されます。

+ +

ユーザディレクトリ:
+ suEXEC wrapper は、リクエスト先のユーザとして CGI + を実行するためにも使えます。これは期待する実行権限のユーザ ID + の前に、"~" + 文字を置くことで実現されます。 + この機能を動作させるために必要なことは、CGI + をそのユーザで実行できること、そのスクリプトが上記のセキュリティ検査をパスできることです。 +

+
+ +
suEXEC のデバッグ + +

suEXEC wrapper は、上記で述べた --with-suexec-logfile + オプションで指定されたファイルにログ情報を記録します。 + wrapper を適切に設定、インストールできていると思う場合、 + どこで迷っているか見ようとするならこのログとサーバの + エラーログを見るとよいでしょう。

+
+ +
とかげに注意: 警告と事例 + +

注意! + この章は完全ではありません。この章の最新改訂版については、 + Apache グループの + オンラインドキュメント版を参照してください。 +

+ +

サーバの設定に制限をもうける wrapper について、 + いくつか興味深い点があります。suEXEC に関する "バグ" + を報告する前にこれらを確認してください。

+ +
    +
  • suEXEC の興味深い点
    • + +
  • 階層構造の制限 + + +

    + セキュリティと効率の理由から、suEXEC の全てのリクエストは + 仮想ホストへのリクエストにおける最上位のドキュメントルート内か、 + ユーザディレクトリへのリクエストにおける個々のユーザの最上位の + ドキュメントルート内に残らなければなりません。 + 例えば、四つの仮想ホストを設定している場合、 + 仮想ホストの suEXEC に有利なように、メインの Apache + ドキュメント階層の外側に全ての仮想ホストのドキュメントルートを + 構築する必要があります。(例は後日記載) +

    +
    • + +
  • suEXEC の PATH 環境変数 + + +

    + これを変更するのは危険です。この指定に含まれる各パスが + 信頼できる + ディレクトリであることを確認してください。 + 世界からのアクセスにより、誰かがホスト上でトロイの木馬 + を実行できるようにはしたくないでしょう。 +

    +
    • + +
  • suEXEC コードの改造 + + +

    + 繰り返しますが、何をやろうとしているか把握せずにこれをやると + 大きな問題を引き起こしかねません。 + 可能な限り避けてください。 +

    +
    • +
+
+ +