From: Yoshiki Hayashi Date: Thu, 6 Jun 2002 07:24:32 +0000 (+0000) Subject: New Japanese translation. X-Git-Url: https://granicus.if.org/sourcecode?a=commitdiff_plain;h=775296d54692291a8e560e03a69768358513696c;p=apache New Japanese translation. Submitted by: Hiroaki KAWAI Reviewed by: Yoshiki Hayashi git-svn-id: https://svn.apache.org/repos/asf/httpd/httpd/trunk@95544 13f79535-47bb-0310-9956-ffa450edef68 --- diff --git a/docs/manual/howto/auth.html b/docs/manual/howto/auth.html deleted file mode 100644 index 3ea56e4508..0000000000 --- a/docs/manual/howto/auth.html +++ /dev/null @@ -1,379 +0,0 @@ - - - - - - - Authentication - - - - - - - -

Authentication

- - - - - -
- - - - - - - -
Related Modules
-
- mod_auth
- mod_access
-
Related Directives
-
- Allow
- AuthGroupFile
- AuthName
- AuthType
- AuthUserFile
- Deny
- Options
- Require
-
- -

Authentication

- -

Authentication is any process by which you verify that - someone is who they claim they are. Authorization is any - process by which someone is allowed to be where they want to - go, or to have information that they want to have.

- -

Introduction

- -

If you have information on your web site that is sensitive - or intended for only a small group of people, the techniques in - this article will help you make sure that the people that see - those pages are the people that you wanted to see them.

- -

This article covers the "standard" way of protecting parts - of your web site that most of you are going to use.

- -

The - prerequisites

- -

The directives discussed in this article will need to go - either in your main server configuration file (typically in a - <Directory> section), or in per-directory configuration - files (.htaccess files).

- -

If you plan to use .htaccess files, you will - need to have a server configuration that permits putting - authentication directives in these files. This is done with the - AllowOverride - directive, which specifies which directives, if any, may be put - in per-directory configuration files.

- -

Since we're talking here about authentication, you will need - an AllowOverride directive like the following:

-
-    AllowOverride AuthConfig
-
- -

Or, if you are just going to put the directives directly in - your main server configuration file, you will of course need to - have write permission to that file.

- -

And you'll need to know a little bit about the directory - structure of your server, in order to know where some files are - kept. This should not be terribly difficult, and I'll try to - make this clear when we come to that point.

- -

Getting it working

- -

Here's the basics of password protecting a directory on your - server.

- -

You'll need to create a password file. This file should be - placed somewhere not accessible from the web. This is so that - folks cannot download the password file. For example, if your - documents are served out of - /usr/local/apache/htdocs you might want to put the - password file(s) in /usr/local/apache/passwd.

- -

To create the file, use the htpasswd utility that came - with Apache. This be located in the bin directory - of wherever you installed Apache. To create the file, type:

-
-        htpasswd -c /usr/local/apache/passwd/password rbowen
-
- -

htpasswd will ask you for the password, and - then ask you to type it again to confirm it:

-
-        # htpasswd -c /usr/local/apache/passwd/passwords rbowen
-        New password: mypassword
-        Re-type new password: mypassword
-        Adding password for user rbowen
-
- -

If htpasswd is not in your path, of course - you'll have to type the full path to the file to get it to run. - On my server, it's located at - /usr/local/apache/bin/htpasswd

- -

Next, you'll need to configure the server to request a - password and tell the server which users are allowed access. - You can do this either by editing the httpd.conf - file or using an .htaccess file. For example, if - you wish to protect the directory - /usr/local/apache/htdocs/secret, you can use the - following directives, either placed in the file - /usr/local/apache/htdocs/secret/.htaccess, or - placed in httpd.conf inside a <Directory - /usr/local/apache/apache/htdocs/secret> section.

-
-        AuthType Basic
-        AuthName "Restricted Files"
-        AuthUserFile /usr/local/apache/passwd/passwords
-        require user rbowen
-
- -

Let's examine each of those directives individually. The AuthType directive selects - that method that is used to authenticate the user. The most - common method is Basic, and this is the method - implemented by mod_auth. It - is important to be aware, however, that Basic authentication - sends the password from the client to the browser unencrypted. - This method should therefore not be used for highly sensitive - data. Apache supports one other authentication method: - AuthType Digest. This method is implemented by mod_auth_digest and is - much more secure. Only the most recent versions of clients are - known to support Digest authentication.

- -

The AuthName - directive sets the Realm to be used in the - authentication. The realm serves two major functions. First, - the client often presents this information to the user as part - of the password dialog box. Second, it is used by the client to - determine what password to send for a given authenticated area. - So, for example, once a client has authenticated in the - "Restricted Files" area, it will automatically - retry the same password for any area on the same server that is - marked with the "Restricted Files" Realm. - Therefore, you can prevent a user from being prompted more than - once for a password by letting multiple restricted areas share - the same realm. Of course, for security reasons, the client - will always need to ask again for the password whenever the - hostname of the server changes.

- -

The AuthUserFile - directive sets the path to the password file that we just - created with htpasswd. If you have a large number - of users, it can be quite slow to search through a plain text - file to authenticate the user on each request. Apache also has - the ability to store user information in fast database files. - The mod_auth_dbm module - provides the AuthDBMUserFile - directive. These files can be created and - manipulated with the dbmmanage program. Many - other types of authentication options are available from third - party modules in the Apache Modules - Database.

- -

Finally, the require - directive provides the authorization part of the process by - setting the user that is allowed to access this region of the - server. In the next section, we discuss various ways to use the - require directive.

- -

Letting more than one - person in

- -

The directives above only let one person (specifically - someone with a username of rbowen) into the - directory. In most cases, you'll want to let more than one - person in. This is where the AuthGroupFile - comes in.

- -

If you want to let more than one person in, you'll need to - create a group file that associates group names with a list of - users in that group. The format of this file is pretty simple, - and you can create it with your favorite editor. The contents - of the file will look like this:

-
-        GroupName: rbowen dpitts sungo rshersey
-
- -

That's just a list of the members of the group in a long - line separated by spaces.

- -

To add a user to your already existing password file, - type:

-
-        htpasswd /usr/local/apache/passwd/password dpitts
-
- -

You'll get the same response as before, but it will be - appended to the existing file, rather than creating a new file. - (It's the -c that makes it create a new password - file).

- -

Now, you need to modify your .htaccess file to - look like the following:

-
-        AuthType Basic
-        AuthName "By Invitation Only"
-        AuthUserFile /usr/local/apache/passwd/passwords
-        AuthGroupFile /usr/local/apache/passwd/groups
-        require group GroupName
-
- -

Now, anyone that is listed in the group - GroupName, and has an entry in the - password file, will be let in, if they type the - correct password.

- -

There's another way to let multiple users in that is less - specific. Rather than creating a group file, you can just use - the following directive:

-
-        require valid-user
-
- -

Using that rather than the require user rbowen - line will allow anyone in that is listed in the password file, - and who correctly enters their password. You can even emulate - the group behavior here, by just keeping a separate password - file for each group. The advantage of this approach is that - Apache only has to check one file, rather than two. The - disadvantage is that you have to maintain a bunch of password - files, and remember to reference th right one in the - AuthUserFile directive.

- -

Possible - problems

- -

Because of the way that Basic authentication is specified, - your username and password must be verified every time you - request a document from the server. This is even if you're - reloading the same page, and for every image on the page (if - they come from a protected directory). As you can imagine, this - slows things down a little. The amount that it slows things - down is proportional to the size of the password file, because - it has to open up that file, and go down the list of users - until it gets to your name. And it has to do this every time a - page is loaded.

- -

A consequence of this is that there's a practical limit to - how many users you can put in one password file. This limit - will vary depending on the performance of your particular - server machine, but you can expect to see slowdowns once you - get above a few hundred entries, and may wish to consider a - different authentication method at that time.

- -

What other neat stuff can - I do?

- -

Authentication by username and password is only part of the - story. Frequently you want to let people in based on something - other than who they are. Something such as where they are - coming from.

- -

The allow and deny directives let - you allow and deny access based on the host name, or host - address, of the machine requesting a document. The - order directive goes hand-in-hand with these two, - and tells Apache in which order to apply the filters.

- -

The usage of these directives is:

-
-        allow from address
-
- -

where address is an IP address (or a partial IP - address) or a fully qualified domain name (or a partial domain - name); you may provide multiple addresses or domain names, if - desired.

- -

For example, if you have someone spamming your message - board, and you want to keep them out, you could do the - following:

-
-        deny from 205.252.46.165
-
- -

Visitors coming from that address will not be able to see - the content covered by this directive. If, instead, you have a - machine name, rather than an IP address, you can use that.

-
-        deny from host.example.com
-
- -

And, if you'd like to block access from an entire domain, - you can specify just part of an address or domain name:

-
-        deny from 192.101.205
-        deny from cyberthugs.com moreidiots.com
-        deny from ke
-
- -

Using order will let you be sure that you are - actually restricting things to the group that you want to let - in, by combining a deny and an allow - directive:

-
-        order deny,allow
-        deny from all
-        allow from dev.example.com
-
- -

Listing just the allow directive would not do - what you want, because it will let folks from that host in, in - addition to letting everyone in. What you want is to let - only those folks in.

- -

More - information

- -

You should also read the documentation for mod_auth and mod_access which - contain some more information about how this all works.

- - - diff --git a/docs/manual/howto/auth.html.ja.jis b/docs/manual/howto/auth.html.ja.jis new file mode 100644 index 0000000000..c5c2ee10cd --- /dev/null +++ b/docs/manual/howto/auth.html.ja.jis @@ -0,0 +1,398 @@ + + + + + + 認証 + + + + + + + + +

認証

+ + + + + +
+ + + + + + + +
関連モジュール
+
+ mod_auth
+ mod_access
+
関連ディレクティブ
+
+ Allow
+ AuthGroupFile
+ AuthName
+ AuthType
+ AuthUserFile
+ Deny
+ Options
+ Require
+
+ +

認証

+ +

「認証」とは、誰かが自分は誰であるかを主張した場合に、 + それを確認するための全ての過程を指します。「承認」とは、 + 誰かが行きたい場所に行けるように、あるいは欲しい情報を + 得ることができるようにするための全ての過程を指します。

+ +

はじめに

+ +

もし機密の情報や、ごくごく少数グループの人向けの情報を + ウェブサイトに置くのであれば、この文書に書かれている + テクニックを使うことによって、そのページを見ている人たちが + 望みの人たちであることを確実にできるでしょう。

+ +

この文書では、多くの人が採用するであろう、 + ウェブサイトの一部分を保護する「一般的な」 + 方法についてカバーします。

+ +

+ 準備

+ +

この文書で取り扱われるディレクティブは、 + メインサーバ設定ファイル (普通は <Directory> + セクション中) か、あるいはディレクトリ毎の設定ファイル + (.htaccess ファイル) かで用います。

+ +

.htaccess ファイルを用いるのであれば、 + これらのファイルに認証用のディレクティブを置けるように + サーバの設定をしないといけないでしょう。これは + AllowOverride + ディレクティブで可能になります。このディレクティブは、 + ディレクトリ毎の設定ファイル中に置くことのできる + ディレクティブを、もしあれば、指定します。

+ +

認証について話を進めているので、次のような + AllowOverride + ディレクティブが必要になるでしょう:

+
+    AllowOverride AuthConfig
+
+ +

そうでなく、メインサーバ設定ファイルの中にディレクティブを + 直接置こうというのであれば、当然ながらそのファイルへの書き込み + 権限を持っていなければならないでしょう。

+ +

その上、どのファイルがどこに保存されているか知るために、 + サーバのディレクトリ構造について少し知っておく + 必要があるでしょう。 + これはそんなに難しくないはずで、 + ディレクトリ構造が必要な場面ではそれが明らかになるようにしています。

+ +

動作させる

+ +

では、サーバ上のあるディレクトリをパスワードで保護する + 基本を示します。

+ +

パスワードファイルを作る必要があります。 + このファイルは、ウェブからアクセスできる場所に + 置くべきではありません。これは、他の人がパスワードファイルを + ダウンロードできないようにするためです。例えば、 + /usr/local/apache/htdocs でドキュメントを + 提供しているのであれば、パスワードファイルは + /usr/local/apache/passwd + などに置いた方が良いでしょう。

+ +

ファイルを作るためには、Apache 付属の htpasswd + を使います。これは Apache をどこにインストールしようとも、 + インストールディレクトリの bin + ディレクトリに置かれます。ファイルを作るには、次のように + タイプしてください:

+
+        htpasswd -c /usr/local/apache/passwd/password rbowen
+
+ +

htpasswd は、パスワードを要求し、その後 + 確認のためにもう一度入力するように要求してきます。

+
+        # htpasswd -c /usr/local/apache/passwd/passwords rbowen
+        New password: mypassword
+        Re-type new password: mypassword
+        Adding password for user rbowen
+
+ +

もし htpasswd がパスの中に入っていない場合は、 + もちろん、実行するためにプログラムまでのフルパスを + タイプする必要があります。私のサーバであれば、 + /usr/local/apache/bin/htpasswd + にプログラムが置かれています。

+ +

次に、サーバがパスワードを要求するように設定して、 + どのユーザがアクセスを許されているかをサーバに知らせなければ + なりません。 httpd.conf を編集するか + .htaccess ファイルを使用するかでこれを + 行います。例えば、ディレクトリ + /usr/local/apache/htdocs/secret + を保護したい場合は、 + /usr/local/apache/htdocs/secret/.htaccess + か httpd.conf 中の <Directory + /usr/local/apache/apache/htdocs/secret> セクションに + 配置した、次のディレクティブを使うことができます。

+
+        AuthType Basic
+        AuthName "Restricted Files"
+        AuthUserFile /usr/local/apache/passwd/passwords
+        require user rbowen
+
+ +

これら個々のディレクティブについて見てみましょう。 + AuthType + ディレクティブはどういう方法でユーザの認証を行うかを + 選択します。最も一般的な方法は Basic + で、これは mod_auth + において実装されています。しかしながら、 + これは気を付けるべき重要なことなのですが、 + Basic 認証はクライアントからブラウザへ、 + パスワードを暗号化せずに送ります。ですから、 + この方法は特に機密性の高いデータに対しては用いるべきでは + ありません。 Apache ではもう一つ別の認証方法: + AuthType Digest をサポートしています。 + この方法は mod_auth_digest + で実装されていて、もっと安全です。 + ごく最近のクライアントのみが Digest 認証をサポートしている + ことが知られています。

+ +

AuthName + ディレクティブでは、認証に使う Realm (訳注: 領域) + を設定します。Realm は大きく分けて二つの機能を提供します。 + 一つ目は、クライアントがパスワードダイアログボックスの + 一部としてユーザにこの情報をよく提示する、というものです。 + 二つ目には、クライアントが与えられた認証領域に対してどのパスワードを + 送信すれば良いのかを決定するために使われる、という機能があります。 + ですから例えば、"Restricted Files" 領域中で + 一度認証されれば、同一サーバ上で "Restricted Files" + realm としてマークされたどんな領域でも、クライアントは + 自動的に同じパスワードを使おうと試みます。 + ですから、複数の制限領域に同じ realm を共有させて、 + ユーザがパスワードを何度も要求される事態を + 防ぐことができます。もちろん、セキュリティ上の理由から、 + サーバのホスト名が変わればいつでも必ず、 + クライアントは再びパスワードを尋ねる必要があります。

+ +

AuthUserFile + ディレクティブは htpasswd で作った + パスワードファイルへのパスを設定します。 + ユーザ数が多い場合は、リクエスト毎のユーザの認証のための + プレーンテキストの探索が非常に遅くなることがあります。 + Apache ではユーザ情報を高速なデータベースファイルに + 保管することもできます。 + mod_auth_dbm + モジュールがAuthDBMUserFile + ディレクティブを提供します。これらのファイルは dbmmanage + プログラムで作成したり操作したりできます。 + Apache + モジュールデータベース中にあるサードパーティー製の + モジュールで、その他多くのタイプの認証オプションが + 利用可能です。

+ +

最後に、require + ディレクティブが、サーバのこの領域にアクセスできるユーザを + 指定することによって、プロセスの承認部分を提供します。 + 次のセクションでは、require ディレクティブの + 様々な用法について述べます。

+ +

+ 複数の人が入れるようにする

+ +

上記のディレクティブは、ただ一人 (具体的にはユーザ名 + rbowen の誰か) がディレクトリに + 入れるようにします。多くの場合は、複数の人が + 入れるようにしたいでしょう。ここでAuthGroupFile + の登場です。

+ +

もし複数の人が入れるようにしたいのであれば、 + グループに属するユーザの一覧の入っている、グループ名のついた + グループファイルを作る必要があります。このファイルの + 書式はきわめて単純で、お好みのエディタで生成できます。 + ファイルの中身は次のようなものです:

+
+        GroupName: rbowen dpitts sungo rshersey
+
+ +

一行にスペース区切りで、グループに所属するメンバーの + 一覧をならべるだけです。

+ +

既に存在するパスワードファイルにユーザを加える場合は、 + 次のようにタイプしてください:

+
+        htpasswd /usr/local/apache/passwd/password dpitts
+
+ +

依然と同じ応答が返されますが、新しいファイルを + 作るのではなく、既にあるファイルに追加されています。 + (新しいパスワードファイルを作るには -c + を使います。)

+ +

ここで次のようにして .htaccess ファイルを + 修正する必要があります:

+
+        AuthType Basic
+        AuthName "By Invitation Only"
+        AuthUserFile /usr/local/apache/passwd/passwords
+        AuthGroupFile /usr/local/apache/passwd/groups
+        require group GroupName
+
+ +

これで、グループ GroupName にリストされていて、 + password ファイルにエントリがある人は、 + 正しいパスワードをタイプすれば入ることができるでしょう。

+ +

もっと特定せずに複数のユーザが入れるようにする、 + もう一つの方法があります。グループファイルを作るのではなく、 + 次のディレクティブを使えばできます。

+
+        require valid-user
+
+ +

require user rbowen 行でなく、上記を使うと、 + パスワードファイルにリストされている人であれば誰でも + 許可されます。 + 単にパスワードファイルをグループ毎に分けておくことで、 + グループのような振る舞いをさせることもできます。 + このアプローチの利点は、Apache は二つではなく、 + ただ一つのファイルだけを検査すればよいという点です。 + 欠点は、たくさんのパスワードファイルを管理して、 + その中から AuthUserFile ディレクティブに正しいファイルへの + 参照をさせなければならない点です。

+ +

+ 起こりえる問題

+ +

Basic 認証が指定されている場合は、 + サーバにドキュメントをリクエストする度に + ユーザ名とパスワードを検査しなければなりません。 + これは同じページ、ページにある全ての画像を + リロードする場合であっても該当します + (もし画像も保護されたディレクトリから来るのであれば) 。 + 予想される通り、これは動作を多少遅くします。 + 遅くなる程度はパスワードファイルの大きさと比例しますが、 + これは、ファイルを開いてあなたの名前を発見するまで + ユーザ名のリストを読まなければならないからです。 + そして、ページがロードされる度にこれを行わなければ + なりません。

+ +

結論としては、一つのパスワードファイルに置くことのできる + ユーザ数には実質的な限界があります。 + この限界はサーバマシンの性能に依存して変わりますが、 + 数百のエントリを越えたあたりから速度低下が見られると予期されています。 + その時は他の認証方法を考慮に入れた方が良いでしょう。

+ +

+ もっと巧みに制御できない?

+ +

ユーザ名とパスワードによる認証は認証の一つの方法に過ぎません。 + しばしば誰であるかということとは違う何かに基づいて、 + 入れるようにしたくなることもあるでしょう。例えばその人がどこから来ているか + といったことです。

+ +

allowdeny + ディレクティブを使って、ドキュメントを要求してきたマシンの + ホスト名やホストアドレスに基づいて許可不許可を制御できます。 + order ディレクティブはこの二つと連携して + 動作し、Apache にどの順番でフィルタを適用するかを + 知らせます。

+ +

これらのディレクティブの使い方は:

+
+        allow from address
+
+ +

ここで、address は IP アドレス + (または IP アドレスの一部)、あるいは完全修飾ドメイン名 + (またはドメイン名の一部) です。 + 必要であれば複数のアドレスやドメイン名を指定できます。

+ +

例えば、もし誰かが掲示板を攻撃していて、 + その人を閉め出したいのであれば、 + 次のようにすることができます:

+
+        deny from 205.252.46.165
+
+ +

このアドレスから来る人は、このディレクティブの範囲内の + コンテンツを見ることができないません。もし IP + アドレスの代わりにマシン名があれば、それを使えます。

+
+        deny from host.example.com
+
+ +

ドメイン全体からのアクセスを防ぎたければ、 + 単にアドレスやドメイン名の一部を指定することができます:

+
+        deny from 192.101.205
+        deny from cyberthugs.com moreidiots.com
+        deny from ke
+
+ +

order を使うことで、 + denyallow の組み合わせで + 入っても良いグループが本当に確実に限定できているようにできます:

+
+        order deny,allow
+        deny from all
+        allow from dev.example.com
+
+ +

allow ディレクティブを単純に列挙するのでは + 望みの動作をしないでしょう。 + なぜなら、全ての人が入れるということに加えて、 + 指定したホストからの人が入れるようにするからです。 + やりたいことは、指定した人たちだけが入れるように + することです。

+ +

+ 追加情報

+ +

これら全てがどのように動作するかについて + もっと多くの情報が書かれている mod_authmod_access + の文書も読むとよいでしょう。

+ + + diff --git a/docs/manual/mod/mod_userdir.xml.ja b/docs/manual/mod/mod_userdir.xml.ja new file mode 100644 index 0000000000..6a1c9fd3a9 --- /dev/null +++ b/docs/manual/mod/mod_userdir.xml.ja @@ -0,0 +1,126 @@ + + + + + + +mod_userdir +ユーザ専用のディレクトリを提供します + +Base +mod_userdir.c +userdir_module + + +このモジュールは、 +http://example.com/~user/ +構文を使ってユーザ専用ディレクトリにアクセスできるようにします。 + + +URL から +ファイルシステムへのマッピング + + + +UserDir +ユーザ専用ディレクトリの位置 +UserDir directory-filename +UserDir public_html +サーバ設定ファイル +バーチャルホスト + + + +

UserDir ディレクティブは、 + ユーザのドキュメントへのリクエストを受けた時に使う + ユーザのホームディレクトリ中の、実際のディレクトリを + 設定します。 + directory-filename には次のどれかを指定します:

+ +
    +
  • ディレクトリ名か下に示すようなパターン。
  • + +
  • disabled キーワード。 + enabled キーワード (下記参照) で明示的に + 指定されたユーザ以外の + 全てのユーザ名-ディレクトリ変換を + しないようにします。
  • + +
  • disabled キーワードと、スペース区切りのユーザ名リスト。 + このリスト中に含まれるユーザ名に対しては、たとえ + enabled 節にあったとしても、 + 決してディレクトリ変換は行われません。
  • + +
  • enebled キーワードとスペース区切りのユーザ名リスト。 + 全体では変換が無効になっていたといたとしても、 + これらのユーザ名にはディレクトリ変換が行われます。 + ただし、disabled 節にもあれば変換はされません。 +
  • +
+ +

もし enableddisabled + キーワードも UserDir に現われていなければ、 + 引数はファイル名パターンとして扱われ、 + 名前からディレクトリへの変換の指定を行なう時に使われます。 + http://www.foo.com/~bob/one/two.html + へのリクエストは次のように変換されます:

+ + + + + + + +
UserDir ディレクティブ変換後のパス
UserDir public_html~bob/public_html/one/two.html
UserDir /usr/web/usr/web/bob/one/two.html
UserDir /home/*/www/home/bob/www/one/two.html
+ +

次のディレクティブはクライアントに対してリダイレクトを + 送信します:

+ + + + + + + +
UserDir ディレクティブ変換後のパス
UserDir http://www.foo.com/usershttp://www.foo.com/users/bob/one/two.html
UserDir +http://www.foo.com/*/usrhttp://www.foo.com/bob/usr/one/two.html
UserDir +http://www.foo.com/~*/http://www.foo.com/~bob/one/two.html
+ + + このディレクティブを使うときは注意してください; + "UserDir ./" は + "/~root" から "/" へマップしますが、 + これは望ましい動作ではないでしょう。 + "UserDir disabled root" 宣言を + 設定の中に含めておくことを強くお薦めします。 + 追加情報に Directory + ディレクティブや + セキュリティ + Tips のページもご覧下さい。 + + +

追加の例:

+ +

少数のユーザのみが UserDir +ディレクトリを利用し、それ以外には利用させたくない場合は +次を使いましょう:

+ + +UserDir disabled
+UserDir enabled user1 user2 user3 +
+ +

大部分のユーザは UserDir ディレクトリを利用するけれど、 +少数の人は不許可にしたい場合は、次を使いましょう:

+ + +UserDir enabled
+UserDir disabled user4 user5 user6 +
+ +
+ +
+
+ + diff --git a/docs/manual/mod/mpm_winnt.xml.ja b/docs/manual/mod/mpm_winnt.xml.ja new file mode 100644 index 0000000000..060738d438 --- /dev/null +++ b/docs/manual/mod/mpm_winnt.xml.ja @@ -0,0 +1,36 @@ + + + + + +mpm_winnt +このマルチプロセッシングモジュールは Windows NT +向けに最適化されています。 +MPM +mpm_winnt.c +mpm_winnt_module + + +

このマルチプロセッシングモジュール (MPM) + は Windows NT でのデフォルトになります。 + 一つの制御用プロセスを用い、これが一つの子プロセスを起動し、 + そして子プロセスがリクエストを取り扱うためにスレッドを + 起動します。

+
+ +CoreDumpDirectory + +PidFile + +Listen + +ListenBacklog + +MaxRequestsPerChild + +SendBufferSize + +ThreadsPerChild + + +