From: Yoshiki Hayashi Date: Fri, 28 Nov 2003 21:07:23 +0000 (+0000) Subject: Update Japanese translations. X-Git-Tag: pre_ajp_proxy~991 X-Git-Url: https://granicus.if.org/sourcecode?a=commitdiff_plain;h=ab298ae1e22dfce9292f075c02b9f9068ab55168;p=apache Update Japanese translations. Submitted by: Hiroaki KAWAI Reviewed by: Yoshiki Hayashi git-svn-id: https://svn.apache.org/repos/asf/httpd/httpd/trunk@101909 13f79535-47bb-0310-9956-ffa450edef68 --- diff --git a/docs/manual/bind.xml.ja b/docs/manual/bind.xml.ja index c6542b2f35..7434f4b8a8 100644 --- a/docs/manual/bind.xml.ja +++ b/docs/manual/bind.xml.ja @@ -1,7 +1,7 @@ - + @@ -92,21 +92,13 @@ これらのデフォルトで使用不可のプラットホームであっても、 特別な設定パラメータで Apache の挙動を変化させることができます。

-

IPv4 と IPv6 のコネクションを最小限のソケットで扱いたいのであれば、 +

一方で、Linux や Tru64 といったプラットホームで IPv4 と IPv6 + の両方を扱うには、マップトアドレスを使用する以外の方法はありません。 + IPv4 と IPv6 のコネクションを最小限のソケットで扱いたいのであれば、 IPv4 マップの IPv6 アドレスを使用する必要があり、 - --enable-v4-mapped configure オプションを指定して、単純に - Listen - ディレクティブで次のように設定します。

+ --enable-v4-mapped configure オプションを指定します。

- - Listen 80 - - -

--enable-v4-mapped では、Apache - の生成するデフォルトの設定ファイル中の - Listen - ディレクティブはこの形式を使用しています。 - --enable-v4-mapped は、 +

--enable-v4-mapped は、 FreeBSD, NetBSD, OpenBSD 以外の全てのプラットホームでのデフォルトです。 ですから、おそらくお手元の Apache はこの設定でビルドされているでしょう。

@@ -121,25 +113,15 @@ Listen 192.170.2.1:80 -

IPv4 と IPv6 のコネクションを個別のソケットで扱うようにしたい場合 +

条件を満たすプラットホームで、Apache が + IPv4 と IPv6 のコネクションを個別のソケットで扱うようにしたい場合 (つまり IPv4 マップのアドレスを無効にしたい場合) は、--disable-v4-mapped configure オプションを指定して、次のように個別指定の Listen - ディレクティブを使用してください。

- - - Listen [::]:80
- Listen 0.0.0.0:80 - - -

--disable-v4-mapped では、Apache - の生成するデフォルトの設定ファイル中の - Listen - ディレクティブはこの形式を使用しています。 + ディレクティブを使用してください。 --disable-v4-mapped は、 FreeBSD, NetBSD, OpenBSD プラットホームでのデフォルトです。

-
diff --git a/docs/manual/content-negotiation.xml.ja b/docs/manual/content-negotiation.xml.ja index 44c4492f70..f4f2518936 100644 --- a/docs/manual/content-negotiation.xml.ja +++ b/docs/manual/content-negotiation.xml.ja @@ -2,7 +2,7 @@ - + コンテントネゴシエーション @@ -18,8 +18,7 @@

コンテントネゴシエーションは mod_negotiation - モジュールによって - 提供されていて、デフォルトで組み込まれています。

+ モジュールによって提供されていて、デフォルトで組み込まれています。

コンテントネゴシエーションについて @@ -30,8 +29,8 @@ もっとも適した選択をする方法の一つには、インデックスページを ユーザに見せて、ユーザに選んでもらう方法があります。 しかし、サーバが自動的に選ぶことができる場合が多くあります。 - これは、ブラウザがリクエスト情報毎の情報の一部に、 - どの表現を嗜好するかを送ることで動作しています。 + これは、ブラウザがリクエスト毎に、 + どの表現を嗜好するかという情報を送ることで動作しています。 例えばブラウザは、可能ならフランス語で情報を見たい、 不可能ならその代わりに英語でもよいと、 自分の嗜好を知らせることができます。 @@ -58,7 +57,8 @@

Apache は HTTP/1.1 規格で定義されている 'server driven' コンテントネゴシエーションをサポートしています。 - Accept, Accept-Language, Accept-Charset, Accept-Encoding + Accept, Accept-Language, + Accept-Charset, Accept-Encoding リクエストヘッダを完全にサポートしています。Apache は 'transparent' コンテントネゴシエーションもサポートしていますが、 これは RFC 2295 と RFC 2296 で定義されている試験的な @@ -103,7 +103,7 @@

タイプマップは type-map ハンドラ (もしくは、古い Apache - の設定と下位互換である mime タイプ + の設定と下位互換である MIME タイプ application/x-type-map) に関連付けられたドキュメントです。 この機能を使うためには、あるファイルの拡張子を @@ -111,7 +111,9 @@ として定義するようなハンドラを、 設定ファイル中に置く必要があることに注意してください。 これは

+ AddHandler type-map .var +

をサーバ設定ファイル中に書くことが一番良い方法です。

タイプマップファイルは記述するリソースと同じ名前を持っていて、 @@ -272,7 +274,7 @@ メディアタイプ - ブラウザは Accept + ブラウザは Accept ヘッダフィールドで優先傾向を指定します。 アイテムそれぞれは、関連した品質数値を持つことができます。 variant の説明も品質数値を持つことができます @@ -282,7 +284,7 @@ 言語 - ブラウザは Accept-Language + ブラウザは Accept-Language ヘッダフィールドで優先傾向を指定します。 要素それぞれに品質数値を持たせることができます。 variants は 0 か 1 つかそれ以上の言語と @@ -292,7 +294,7 @@ エンコーディング - ブラウザは Accept-Encoding + ブラウザは Accept-Encoding ヘッダフィールドで優先傾向を指定します。 要素それぞれに品質数値を持たせることができます。 @@ -300,7 +302,7 @@ 文字セット - ブラウザは Accept-Charset + ブラウザは Accept-Charset ヘッダフィールドで優先傾向を指定します。 要素それぞれに品質数値を持たせることができます。 variant はメディアタイプのパラメータとして文字セットを @@ -333,13 +335,13 @@ 複数 variant が残っていれば、次のテストに進みます。

    -
  1. variant のメディアタイプの品質数値と Accept +
  2. variant のメディアタイプの品質数値と Accept ヘッダの品質数値との積を計算して、最高値の variant を選びます。
  3. 言語品質数値が最高の variant を選びます。
    4. -
  4. (もしあれば) Accept-Language ヘッダの言語順か、 +
  5. (もしあれば) Accept-Language ヘッダの言語順か、 (もしあれば) LanguagePriority ディレクティブの言語順で最適な言語の variant を選びます。
    6. @@ -348,7 +350,7 @@ (text/html メディアタイプのバージョンを与えるために使われます) を持つ variant を選びます。 -
  6. Accept-Charset ヘッダ行で与えられている最高の文字セット +
  7. Accept-Charset ヘッダ行で与えられている最高の文字セット メディアパラメータを持つ variant を選びます。 明示的に除外されていない限り、ISO-8859-1 が許容されるようになっています。 @@ -382,7 +384,7 @@
  8. アルゴリズムを使って一つの「最適な」variant を選びましたので、 それを応答として返します。ネゴシエーションの次元を指定するために - HTTP レスポンスヘッダ Vary が設定されます + HTTP レスポンスヘッダ Vary が設定されます (リソースのキャッシュをする時に、 ブラウザやキャッシュはこの情報を使うことができます)。 以上で終わり。
    9. @@ -392,26 +394,26 @@ 406 ステータス ("No Acceptable representation" を意味する) が、利用可能な variant のリストのついた HTML ドキュメントとともに返されます。 - 相違の次元を示す HTTP Vary ヘッダも設定されます。 + 相違の次元を示す HTTP Vary ヘッダも設定されます。
品質の値を変える -

上記の Apaceh ネゴシエーションアルゴリズムの厳格な解釈で +

上記の Apache ネゴシエーションアルゴリズムの厳格な解釈で 得られるであろう値から、Apache は品質数値を時々変えます。 これは、このアルゴリズムで完全ではない、あるいは正確でない情報を送る ブラウザ向けによりよい結果を得るために行われます。 かなりポピュラーなブラウザで、もしないと間違った variant - を選択する結果になってしまうような Accept + を選択する結果になってしまうような Accept ヘッダ情報を送るものもあります。 ブラウザが完全で正しい情報を送っていれば、 この数値変化は適用されません。

メディアタイプとワイルドカード -

Accept: リクエストヘッダはメディアタイプの優先傾向を指定します。 +

Accept: リクエストヘッダはメディアタイプの優先傾向を指定します。 これはまた、"image/*" や "*/*" といった「ワイルドカード」メディアタイプを含むことができます。 ここで * は任意の文字列にマッチします。 @@ -444,12 +446,12 @@ 明示的にリストされているタイプに合致する variant がない場合にのみ、 他のタイプが返されます。

-

もし Accept: ヘッダが q 値を全く含んでいなければ、 +

もし Accept: ヘッダが q 値を全く含んでいなければ、 望みの挙動をするために、 Apache は "*/*" があれば 0.01 の q 値を設定します。 また、"type/*" の形のワイルドカードには 0.02 の q 値を設定します (ですからこれらは "*/*" のマッチよりも優先されます)。 - もし Accept: ヘッダ中のメディアタイプのどれかが q + もし Accept: ヘッダ中のメディアタイプのどれかが q 値を含んでいれば、これらの特殊な値は適応されず、 正しい情報を送るブラウザからのリクエストは期待通りに 動作するようになります。

@@ -462,11 +464,11 @@ ネゴシエーションアルゴリズムが幾つか追加されました。

サーバのページをクライアントがリクエストしたけれども、 - ブラウザの送ってきた Accept-Language に合致するページが一つも + ブラウザの送ってきた Accept-Language に合致するページが一つも 見つからなかった場合に、サーバは "No Acceptable Variant" か "Multiple Choices" レスポンスをクライアントに返します。 これらのエラーメッセージを返さないように、 - このような場合には Apache が Accept-Language を無視して、 + このような場合には Apache が Accept-Language を無視して、 クライアントのリクエストに明示的には合致しないドキュメントを 提供するように設定できます。 ForceLanguagePriority @@ -527,7 +529,7 @@ に印を付けるために、新たに {encoding ..} 要素を variant リスト中に使っています。 リスト中のエンコードされた variant を認識し、 -Accept-Encoding リクエストヘッダに従って許容される +Accept-Encoding リクエストヘッダに従って許容される エンコードをもった variant は、どれでも候補 variant として使用するように、 RVSA/1.0 アルゴリズム (RFC 2296) の実装が拡張されました。 @@ -670,6 +672,15 @@ RVSA/1.0 の実装では、最適な variant が見つかるまで、 このディレクティブは、サーバ設定ファイルやバーチャルホストに書くことができ、 引数をとりません。 HTTP/1.1 クライアントからのリクエストには効力を持ちません。

+ +

HTTP/1.1 クライアントに対しては、レスポンスのネゴシエーション次元 + を示すために Vary HTTP レスポンスヘッダを送ります。 + キャッシュは、これを使って後続のリクエストに対してローカルコピーで応答できるか + どうかを決定できます。 + ネゴシエーション次元とは関係なしにローカルコピーの使用を優先するようにするには、 + force-no-vary 環境変数を + 設定します。

+
追加情報 diff --git a/docs/manual/install.xml.ja b/docs/manual/install.xml.ja index d5ef459d48..94392f624a 100644 --- a/docs/manual/install.xml.ja +++ b/docs/manual/install.xml.ja @@ -2,7 +2,7 @@ - + コンパイルとインストール @@ -23,6 +23,10 @@ するために libtool と autoconf を使うようになっています。

+

マイナーバージョンからその次のバージョンにアップグレードする + (2.0.50 から 2.0.51 へ等) 場合は、まず + アップグレードをご覧下さい。

+ Apacheの起動 @@ -35,8 +39,7 @@ ダウンロード - $ lynx - http://www.apache.org/dist/httpd/httpd-2_1_NN.tar.gz + $ lynx http://httpd.apache.org/download.cgi @@ -299,7 +302,7 @@
ヘッダファイルの探索ディレクトリ ("-Idir") 。
-
TARGET=... [デフォルト値: apache]
+
TARGET=... [デフォルト値: httpd]
ビルドする実行ファイルの名前。
@@ -602,4 +605,50 @@ $ PREFIX/bin/apachectl stop
+
アップグレード + +

アップグレードでまず行なうべきことは、リリースアナウンスと + ソースディストリビューションに入っている CHANGES を読んで、 + 自身のサイトに対して影響を及ぼす変更点を探すことです。 + メジャーリリース間の変更をする場合 (例えば 1.3 から 2.0 へ、2.0 から 2.2 へ) + は、コンパイル時や実行時の設定に大きな差異があるでしょうから、 + 手動の調整が必要になるでしょう。モジュールも全て、API + の変更に合わせるためにアップグレードが必要になるでしょう。

+ +

マイナーバージョンから次のバージョンにアップグレードする場合 + (例えば 2.0.55 から 2.0.57 へ) は、もっと簡単です。 + make install を実行しても今あるドキュメント、 + ログファイル、設定ファイルは上書きされません。 + さらに、マイナーバージョン間では configure オプション、 + 実行時の設定、モジュール API に不整合が起こらないように、 + 開発者は最大限の努力をしています。 + 大抵の場合、同一の configure コマンドライン、 + 同一の設定ファイル、モジュール全てが正常に動作するはずです。 + (2.0.41 以降ではそのようになっています。それ以前のバージョンには + 不整合が存在します。)

+ +

前回のインストール時のソースツリーが残されているのであれば、 + アップグレードはさらに簡単です。古いソースツリーのルートに存在する + config.nice ファイルには、前回ソースツリーを設定した時の + configure コマンドラインが入っています。 + 次のバージョンにアップグレードする場合は、config.nice + ファイルを新しいバージョンのソースツリーにコピーし、 + それを編集し必要な変更を行なって、次のように実行します。

+ + + $ ./config.nice
+ $ make
+ $ make install
+ $ PREFIX/bin/apachectl stop
+ $ PREFIX/bin/apachectl start
+ + + 新しいバージョンを使用する場合は、 + 実際に運用を始める前に、必ず自分用の環境でテストすべきです。 + 最終的にアップグレードする前に、非互換性がないかをテストするために、 + 例えば、異なる --prefix と異なるポート (Listen ディレクティブで設定します) + を使用することで、古いバージョンに影響を与えずに新しいバージョンを + インストールし、実行できます。 +
diff --git a/docs/manual/sections.xml.ja b/docs/manual/sections.xml.ja index a4cf1400cb..b25b7baadd 100644 --- a/docs/manual/sections.xml.ja +++ b/docs/manual/sections.xml.ja @@ -1,7 +1,7 @@ - + @@ -200,7 +200,7 @@ shell スタイルのワイルドカードキャラクタが使用できます。 "/" 文字はどのワイルドカードでもマッチされません。 明示的に指定する必要があります。

-

これより柔軟なマッチングが必要な場合は、これらのコンテナの正規表現 +

これより柔軟なマッチングが必要な場合は、これらのコンテナに正規表現 (regex) 版である DirectoryMatch, FilesMatch, @@ -280,8 +280,7 @@ Deny from all
ですからできる限りファイルシステムコンテナを使用してください。 しかしながら一つだけ例外があります。 <Location /> セクションはどんな URL -にも関わらず適用されるので、そこにアクセスを制限するディレクティブを -居れることは完全に安全です。

+にも関わらず適用されるので、完全に安全です。

@@ -299,11 +298,11 @@ Deny from all

Proxy と ProxyMatch -コンテナは、mod_proxy -プロクシサーバを経由してアクセスされる特定の URL にマッチするサイトに -対してのみ適用される -設定ディレクティブを格納します。例えば次の設定は、プロキシサーバが -cnn.com ウェブサイトをアクセスするためには使えないようにします。

+コンテナは、特定の URL にマッチする mod_proxy +プロクシサーバを経由してアクセスしたサイトに対してのみ適用される +設定ディレクティブを格納します。例えば次の設定は、cnn.com +ウェブサイトにアクセスするために用いられるプロクシサーバを +制限します。

<Proxy http://cnn.com/*>
@@ -353,7 +352,7 @@ Deny from all
  1. Directory (正規表現無し) と - .htaccess を同時に (.htaccess が許可されていれば、それが + .htaccess を同時に (.htaccess が許可されていれば、それが Directory を上書きします)
    2. @@ -388,6 +387,12 @@ Deny from all
    後に適用されます。これによりバーチャルホストが メインのサーバ設定を上書きできるようなります。

    +

    mod_proxy でリクエストが処理される場合は、 + 処理順番のうち、Directory コンテナの部分が + Proxy + コンテナに取って代わられます。

    +

    後のセクションのディレクティブが前のセクションのものを上書きします。

    @@ -435,7 +440,7 @@ A
    セクションに設置されたアクセス制限に関わらず、 Location セクションが最後に評価されて、サーバへのアクセスは制限されません。 -つまり、マージの順番は重要ですので、注意して使用してください!

    +言い換えれば、マージの順番は重要で、注意して使用してください!

    <Location />
    diff --git a/docs/manual/sitemap.xml.ja b/docs/manual/sitemap.xml.ja index f858a21c72..cc25518545 100644 --- a/docs/manual/sitemap.xml.ja +++ b/docs/manual/sitemap.xml.ja @@ -1,5 +1,5 @@ - + ] > @@ -115,6 +115,7 @@ Apache その他 概略 CGI 環境の PATH_INFO の変更 +関連する標準規格 diff --git a/docs/manual/suexec.xml.ja b/docs/manual/suexec.xml.ja index 358c755d37..2e6168fe8b 100644 --- a/docs/manual/suexec.xml.ja +++ b/docs/manual/suexec.xml.ja @@ -1,7 +1,7 @@ - + @@ -19,7 +19,7 @@ や SSI プログラムを開発し実行することで生じるセキュリティ上の危険を、 かなり減らすことができます。しかし、suEXEC の設定が不適切だと、 多くの問題が生じ、あなたのコンピュータに新しいセキュリティホールを - 作ってしまう可能性があります。あなたが root に setuid + 作ってしまう可能性があります。あなたが setuid root されたプログラムと、それらから生じるセキュリティ上の問題の管理に 詳しくないようなら、suEXEC の使用を検討しないように強く推奨します。

    @@ -97,6 +97,17 @@
    1. + wrapper + を実行しているユーザはこのシステムの正当なユーザか? + +

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

      +
      2. + + +
    2. wrapper が適切な数の引数で呼び出されたか? @@ -109,17 +120,6 @@

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

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

      -
      4. -
    4. この正当なユーザは wrapper の実行を許可されているか? @@ -132,13 +132,15 @@
    5. - 対象のプログラムが安全でない階層の参照をしているか? + 対象の CGI, SSI プログラムが安全でない階層の参照をしているか?

      - 対象のプログラムが '/' から始まる、または + 対象の CGI, SSI プログラムが '/' から始まる、または '..' による参照を行なっていますか? これらは許可されません。 - 対象のプログラムは Apache の web 空間内になければなりません。 + 対象のプログラムは suEXEC のドキュメントルート + (下記の --with-suexec-docroot=DIR を参照) + 内に存在しなければなりません。

      6. @@ -163,7 +165,7 @@

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

      @@ -215,11 +217,12 @@
    6. - プログラムが置かれるディレクトリは存在しているか? - + CGI/SSI プログラムが置かれているディレクトリに移動 + (change directory) できるか?

      ディレクトリが存在しないなら、そのファイルも存在しないかもしれません。 + ディレクトリに移動できないのであれば、おそらく存在もしないでしょう。

      7. @@ -229,9 +232,10 @@

      リクエストがサーバ内のものであれば、 - 要求されたディレクトリがサーバのドキュメントルート配下にありますか? - リクエストが UserDir のものであれば、 - 要求されたディレクトリがユーザのドキュメントルート配下にありますか? + 要求されたディレクトリが suEXEC のドキュメントルート配下にありますか? + リクエストが UserDir のものであれば、要求されたディレクトリが suEXEC + のユーザのドキュメントルート配下にありますか? + (suEXEC 設定オプション 参照)

      @@ -247,7 +251,7 @@
    7. - 対象となるプログラムは存在するか? + 対象となる CGI/SSI プログラムは存在するか?

      存在しなければ実行できません。 @@ -255,17 +259,17 @@

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

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

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

      @@ -297,7 +301,7 @@

    10. - 対象となるプログラムを exec して実行できるか? + 対象となる CGI/SSI プログラムを exec して実行できるか?

      @@ -334,13 +338,13 @@

      このオプションは、デフォルトではインストールされず、 有効にはならない suEXEC 機能を有効にします。 - suEXEC を使うように APACI に要求するには、--enable-suexec - オプションにあわせて少なくとも一つは --with-suexec-xxxxx + suEXEC を使うように APACI に要求するには、--enable-suexec + オプションにあわせて少なくとも一つは --with-suexec-xxxxx オプションが指定されなければなりません。
      --with-suexec-bin=PATH
      -
      セキュリティ上の理由により、suexec バイナリのパスはサーバに +
      セキュリティ上の理由により、suexec バイナリのパスはサーバに ハードコードされている必要があります。デフォルトのパスを 変えたいときはこのオプションを使ってください。例えば、 --with-suexec-bin=/usr/sbin/suexec のように。
      @@ -373,7 +377,7 @@
      Apache のドキュメントルートを設定します。これが suEXEC の動作で使用する唯一のディレクトリ階層になります (UserDir - の指定は別)。デフォルトでは --datedir に "/htdocs" + の指定は別)。デフォルトでは --datedir に "/htdocs" というサフィックスをつけたものです。 "--datadir=/home/apache" として設定すると、 suEXEC wrapper にとって "/home/apache/htdocs" @@ -396,7 +400,7 @@
      suEXEC の処理とエラーが記録されるファイル名を指定します。 (監査やデバッグ目的に有用) デフォルトではログファイルは "suexec_log" という名前で、 - 標準のログファイルディレクトリ (--logfiledir) に置かれます。 + 標準のログファイルディレクトリ (--logfiledir) に置かれます。
      --with-suexec-safepath=PATH
      @@ -409,14 +413,14 @@

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

      suEXEC setup:
      - suexec binary: /usr/local/apache/sbin/suexec
      - document root: /usr/local/apache/share/htdocs
      + suexec binary: /usr/local/apache2/sbin/suexec
      + document root: /usr/local/apache2/share/htdocs
      userdir suffix: public_html
      - logfile: /usr/local/apache/var/log/suexec_log
      + logfile: /usr/local/apache2/var/log/suexec_log
      safe path: /usr/local/bin:/usr/bin:/bin
      caller ID: www
      minimum user ID: 100
      @@ -425,13 +429,13 @@

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

      + +

      安全なパーミッションを設定する
      + suEXEC ラッパーは、--with-suexec-caller configure + オプションで指定した正しいユーザで起動されていることを確認しますが、 + システム上でこのチェックが行なわれる前に、 + suEXEC が呼ぶシステムやライブラリが脆弱である可能性は残ります。対抗策として、 + 一般に良い習慣ともされいますが、 + ファイルシステムパーミッションを使って + Apache の実行時のグループのみが suEXEC を実行できるように + するのが良いでしょう。

      + +

      たとえば、次のようにサーバが設定されていたとします。

      + + + User www
      + Group webgroup
      +       + +

      suexec が "/usr/local/apache2/sbin/suexec" + にインストールされていた場合、次のように設定する必要があります。

      + + + chgrp webgroup /usr/local/apache2/bin/suexec
      + chmod 4750 /usr/local/apache2/bin/suexec
      +       + +

      これで Apache が実行されるグループのみが + suEXEC ラッパーを実行できるということを + 確証します。

      suEXEC の有効化と無効化 -

      起動時に、Apache は "sbin" ディレクトリで - "suexec" を探します +

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

      + [notice] suEXEC mechanism enabled (wrapper: /path/to/suexec) @@ -460,7 +495,7 @@

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

      -

      suEXEC を無効にする場合は、"suexec" ファイルを削除してから +

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

      @@ -494,7 +529,7 @@
      suEXEC のデバッグ -

      suEXEC wrapper は、上記で述べた --with-suexec-logfile +

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

      - セキュリティと効率の理由から、suEXEC の全てのリクエストは + セキュリティと効率の理由から、suEXEC の全てのリクエストは 仮想ホストへのリクエストにおける最上位のドキュメントルート内か、 ユーザディレクトリへのリクエストにおける個々のユーザの最上位の ドキュメントルート内に残らなければなりません。 diff --git a/docs/manual/urlmapping.xml.ja b/docs/manual/urlmapping.xml.ja index 06c12938b8..3e475f9c83 100644 --- a/docs/manual/urlmapping.xml.ja +++ b/docs/manual/urlmapping.xml.ja @@ -1,7 +1,7 @@ - + @@ -97,7 +97,7 @@ を使って強力な正規表現に基づいたマッチと置換を行なうことができます。 たとえば、

      -ScriptAliasMatch ^/~([a-zA-Z0-9]*)/cgi-bin/(.*) +ScriptAliasMatch ^/~([a-zA-Z0-9]+)/cgi-bin/(.+) /home/$1/cgi-bin/$2

      は http://example.com/~user/cgi-bin/script.cgi への @@ -140,7 +140,7 @@ /home/user/public_html/file.html にマップされるようにするには、 以下のように AliasMatch ディレクティブを使います:

      -AliasMatch ^/upages/([a-zA-Z0-9]*)/?(.*) +AliasMatch ^/upages/([a-zA-Z0-9]+)/?(.*) /home/$1/public_html/$2