ほとんどのユーザ環境については、Red Hat Linux Secure Web Server のデフォルト設定で通用するはずです。Apache の設定ディレクティブを変更する必要はないはずです。デフォルトの設定オプションを変更したい場合には、いくつかのオプションの意味を理解し、それがどこにあるのかを知る必要が生じます。本章では、ユーザが利用することのできる設定オプションを取り扱います。
Red Hat Linux Secure Web Server をインストールした後で、Apache Web サーバのマニュアルを http://your_domain/manual/ から入手することができます。あるいは、Web http://www.apache.org/docs/ から入手可能な Apache のマニュアルを使用することができます。Apache Web サーバのマニュアルには、Apache のすべての設定オプションに関する完全な一覧と詳細な説明が含まれています。ユーザの便宜を考え、本マニュアルには Red Hat Linux Secure Web Server で使用される設定ディレクティブの簡潔な説明を記載します。
Web サーバの設定ファイルを詳しく調べる際には、セキュアでない Web サーバとセキュアな Web サーバの両方がデフォルト設定に含まれていることに注意してください。セキュアな Web サーバは仮想ホストとして動作します。その設定は httpd.conf 設定ファイルの中に含まれています。仮想ホストの詳細については、the section called 仮想ホストの使用 を参照してください。
注意:: FrontPage の拡張機能は組み込まれません。Microsoft (TM) のライセンスによって、サードパーティ製品にこの拡張機能を組み込むことは禁止されています。
Apache Web サーバの設定ファイルは /etc/httpd/conf/httpd.conf です。httpd.conf ファイルにはたくさんコメントが付いており、このファイルを読むだけでも多少のことは分かります。ほとんどの場合には Red Hat Linux Secure Web Server のデフォルト設定で通用します。したがって、httpd.conf のディレクティブを変更する必要はないでしょう。ただし、最も重要な設定オプションに慣れておくのも良いでしょう。
空の srm.conf ファイルと access.conf ファイルも、/etc/httpd/conf ディレクトリの中にあります。srm.conf ファイルと access.conf ファイルは、以前は httpd.conf と共に Apache の設定ファイルとして使用されていました。
Red Hat Linux Secure Web Server を設定する必要がある場合は、httpd.conf を編集した後で、Red Hat Linux Secure Web Server をリロードするか、または停止してから起動します。サーバのリロード、停止、および起動の方法については、the section called Apache の起動と停止 in Chapter 5 を参照してください。
httpd.conf ファイルを編集する前に、まずオリジナルのファイルを httpd.confold のようなファイル (または任意の名前) にコピーする必要があります。そうすれば、設定ファイルの編集中にミスをした場合でも、バックアップを使ってやり直すことができます。
ミスをして Red Hat Linux Secure Web Server が正常に機能しなくなった場合に、最初に調査すべき場所は、httpd.conf で最後に編集した場所です。入力ミスがなかったか否かを確認してください。次に調査すべき場所は、Red Hat Linux Secure Web Server のエラーログ (/var/log/httpd/error_log) です。エラーログを簡単に解釈できるか否かは、ユーザの経験のレベルによって異なります。ただし、問題の発生直後であれば、エラーログの最後のエントリの中に、発生したことがらに関する手がかりが見つかるはずです。
次のセクションでは、httpd.conf に含まれるディレクティブ群を、登場する順序で簡単に説明します。その説明は、完全なものではありません。詳細情報が必要な場合は、http://your_domain/manual/ に HTML 形式で提供されている Apache のマニュアル、または http://www.apache.org/docs/ の Apache グループのマニュアルを参照してください。mod_ssl ディレクティブの詳細については、http://your_domain/manual/mod/mod_ssl/ に含まれる HTML 形式のマニュアル、または http://www.modssl.org/docs/2.6/ の mod_ssl User Manual を参照してください。
ServerType として可能なのは、inetd または standalone です。デフォルトで、Red Hat Linux Secure Web Server は ServerType standalone と設定されます。
ServerType standalone は、サーバは一度だけ起動され、すべての接続がそのサーバによって処理されることを意味します。ServerType inetd は、HTTP 接続が確立されるたびに、新たにサーバのインスタンスが起動されることを意味します。サーバの各インスタンスが接続を処理し、接続が終了するとインスタンスも終了します。想像されるように、inetd を使用するとかなり能率が悪くなります。もう一つの問題は、Apache グループのために inetd が正しく動作しない可能性があることです。最後に、Red Hat Linux 7.0 は xinetd を使用しているため、xinetd にサーバを起動させるための追加の設定が必要になります。上記の理由のため、Red Hat Linux Secure Web Server の ServerType の設定を standalone のままにしておくと良いでしょう。
ServerRoot は、サーバのファイルを格納する最上位レベルのディレクトリです。セキュアサーバおよびセキュアでないサーバのどちらも、/etc/httpd という ServerRoot を使用するように設定されます。
LockFile により、Apache サーバを USE_FCNTL_SERIALIZED_ACCEPT または USE_FLOCK_SERIALIZED_ACCEPT によってコンパイルする際に使用するロックファイルへのパスを設定します。通常は、LockFile のデフォルト値を変更すべきではありません。
PidFile により、サーバがそのプロセス ID (pid) を記録する際の記録先ファイルを指定します。Red Hat Linux Secure Web Server は、自分の pid を /var/run/httpd.pid に記録するように設定されています。
ScoreBoardFile には内部サーバプロセス情報が保存されます。この情報は、親サーバプロセスと子サーバプロセスの間の通信のために使用されます。Red Hat Linux Secure Web Server の ScoreBoardFile は /var/run/httpd.scoreboard と設定されています。
ResourceConfig ディレクティブは、ResourceConfig の後ろのファイルからディレクティブ群を読み込むようにサーバに指示するものです。ResourceConfig ディレクティブはコメントアウトされています。なぜならば、Web サーバは設定ディレクティブに関して httpd.conf しか使用していないからです。
AccessConfig ディレクティブは、サーバに対して、ResourceConfig によって指定したファイルを読み込んだ後で、AccessConfig の後ろに指定したファイルからディレクティブ群を読み込むように指示するものです。AccessConfig ディレクティブはコメントアウトされています。なぜならば、Web サーバは設定ディレクティブに関して httpd.conf しか使用していないからです。
Timeout は、通信中にサーバが送受信を行うまで待機する時間の長さを秒単位で定義するものです。特に、Timeout によって、サーバが GET 要求の受信を待機する時間の長さ、POST または PUT に関して TCP パケットの受信を待機する長さ、および TCP パケットに対する応答である ACK から ACK までを待機する時間が定義されます。Timeout は 300 秒と設定されており、これはほとんどの状況に適しています。
KeepAlive により、サーバが永続的な接続 (つまり、一回の接続で複数の要求) を許可するか否かを設定します。KeepAlive を使用すれば、一つのクライアントによってサーバの資源が過度に消費されることを回避できます。デフォルトでは、KeepAlive は on と設定されます。これは、サーバが永続的な接続を許可することを意味します。これを off と設定することができます。そうすると、永続的な接続が無効になります。接続毎の要求数を制限する方法については、the section called MaxKeepAliveRequestsを参照してください。
このディレクティブにより、永続的な接続毎に許される要求の最大数を設定します。Apache グループは、サーバの性能を向上させるために、大きな数を設定することを推奨しています。MaxKeepAliveRequests はデフォルトで 100 と設定されています。ほとんどの状況ではこれで適切なはずです。
KeepAliveTimeout により、サーバがある要求に対してサービスを提供した後で、次の要求を待機する時間を秒単位で設定します。この時間が経過すると接続が終了します。何らかの要求を受信した後では、Timeout ディレクティブが適用されるようになります。
Apache Web サーバは、トラフィックに基づいて適当な数の予備サーバプロセスを維持しておくことにより、認識した負荷に対して動的に適応します。サーバは、要求を待機しているサーバの数をチェックし、その数が MaxSpareServers よりも多い場合は余分なサーバを停止し、MinSpareServers よりも少ない場合には足りない分を作成します。
デフォルトの MinSpareServers は 5 であり、デフォルトの MaxSpareServers は 20 です。ほとんどの場合には、これらのデフォルト設定で通用するはずです。MinSpareServers としてあまり大きな数を設定すべきではありません。大きな数を設定すると、トラフィックが軽い状況であっても、サーバに重い処理負荷がかかるからです。
StartServers により、スタートアップ時に作成するサーバプロセスの数を設定します。Web サーバは、トラフィック負荷に基づいて動的にサーバプロセスの停止と作成を行うため、このパラメータを変更する必要は生じないでしょう。Web サーバは、スタートアップ時に 8 個のサーバプロセスを起動するように設定されています。
MaxClients により、同時に動作することのできるサーバプロセス (つまり同時に接続するクライアント) の合計数に制限を加えます。同時接続するクライアントの数がここで指定する数に到達すると、その先は誰も接続を許可されなくなるため、MaxClients に大きな数を指定しておきたいでしょう (サーバのデフォルト値は 150 と設定されています)。ただし、Apache を再コンパイルしない限り、MaxClients に 256 よりも大きな数を設定することはできません。MaxClients がある主な理由は、暴走した Web サーバがオペレーティングシステムをクラッシュさせることのないようにするためです。
MaxRequestsPerChild により、子プロセスが消滅するまでに各子プロセスに処理させる要求の合計数を設定します。MaxRequestsPerChild を設定する主な理由は、長く生きるプロセスによってメモリリークが引き起こされるのを回避することです。サーバの MaxRequestsPerChild のデフォルト値は 100 です。
Listen コマンドにより、Red Hat Linux Secure Web Server が着信要求を受け付ける際に使用するポートを指定します。RHLAS; はセキュアでない Web 通信をポート 80 でリスニングし、(セキュアサーバを定義する仮想ホストタグでは) セキュアな Web 通信をポート 443 でリスニングするように設定されています。
1024 より下のポートでリスニングするように Apache を設定している場合は、httpd プロセスを root として起動する必要があります。1024 以上のポートの場合、httpd を通常のユーザとして起動することができます。
Listen を使用すれば、接続を受け付ける際にサーバに特定の IP アドレスを使用させるように指定することもできます。
BindAddress は、サーバによるリスニングの対象とする IP アドレスを指定する一つの方法です。ただし、その機能が必要な場合には、代わりに Listen ディレクティブを使用する必要があります。Web サーバは BindAddress を使用しません。つまり、httpd.conf のデフォルト設定ではコメントアウトされています。
LoadModule は、Dynamic Shared Object (DSO) モジュールをロードするために使用されます。LoadModule ディレクティブの正確な使用法を含む Red Hat Linux Secure Web Server の DSO サポートの詳細については、the section called サーバに対するモジュールの追加 を参照してください。モジュールの順序が重要なことに注意してください。したがって、順序を変更しないでください。
タグの <IfDefine> と </IfDefine> で挟まれた設定ディレクティブは、<IfDefine> タグの中に記述された「条件」が成立する場合に適用されます。条件が成立しない場合、それらの指示は無視されます。
<IfDefine> タグに挟まれる条件は、一つのパラメータ名です (例 HAVE_PERL)。そのパラメータが定義されている (つまりサーバのスタートアップコマンドの引数として指定されている) 場合、条件が成立します。この場合は Red Hat Linux Secure Web Server の起動時に条件が成立するので、IfDefine タグで挟まれるディレクティブ群が適用されます。
デフォルトでは、<IfDefine HAVE_SSL> タグによって、セキュアサーバ用の仮想ホストタグが挟まれています。<IfDefine HAVE_SSL> タグの間には、ssl_module 用の LoadModule ディレクティブと AddModule ディレクティブもあります。
ClearModuleList ディレクティブは、長い AddModule ディレクティブの一覧の直前に配置されます。ClearModuleList は、アクティブモジュールとしてサーバに組み込まれている一覧を消去します。ClearModuleList の直後に AddModule ディレクティブの一覧を配置することで、一覧を再作成します。
AddModule は、利用可能なモジュールの完全な一覧を作成するために使用されます。独自のモジュールを DSO としてアドインする場合に AddModule ディレクティブを使用します。DSO をサポートするための AddModule の使用法については、the section called サーバに対するモジュールの追加 を参照してください。
ExtendedStatus ディレクティブは、server-status ハンドラのコール時に、基本的なサーバステータス情報 (オフ) と詳細なサーバステータス情報 (オン)のどちらを Apache に生成させるのかを制御します。Server-status をコールする際には Location タグを使用します。server-status のコール方法については、the section called Location を参照してください。
通常は、Port によってサーバのリスニング対象とするポートを定義します。ただし、Listen ディレクティブも使用するため、Red Hat Linux Secure Web Server はデフォルトで複数のポートをリスニングします。Listen ディレクティブが有効な場合、サーバはそのようなポートのすべてに対してリスニングを行います。Listen の詳細については、Listen の説明を参照してください。
Port コマンドも、サーバの正規名を作成するためのポート番号を指定するために使用されます。サーバの正規名については、the section called UseCanonicalName を参照してください。
User ディレクティブにより、サーバが要求に対して応答する際に使用するユーザ ID を設定します。User の設定によってサーバのアクセス権が決まります。このユーザがアクセスできないファイルには、Web サイトの訪問者もアクセスできなくなります。User のデフォルト値は apache です。
User には、外部に閲覧させるつもりのファイルに対するアクセス権のみを与える必要があります。User は、サーバが生成する CGI プロセスの所有者でもあります。User に対して、HTTP 要求に対する応答を目的とするコード以外に、コードの実行権限を与えるべきではありません。
注意:: 自分が何をしているのかをはっきりと理解している場合を除き、User として root を設定しないでください。User として root を使用すると、Red Hat Linux Secure Web Server にぽっかりと大きなセキュリティの穴があくことになります。
親の httpd プロセスは、当初通常の動作中には root として動作しますが、即座に apache ユーザへと渡されます。1024 未満のポートとバインドする必要があるため、サーバは root として起動しなければなりません (セキュアな Web 通信のためのデフォルトのポートは 443 です。セキュアでない Web 通信のためのデフォルトのポートは 80 です)。1024 未満のポートは、システム用に予約されています。したがって、root 以外のユーザが使用することはできません。ただし、サーバが自分自身を自分自身のポートにアタッチすると、サーバが何らかの接続要求を受け入れる前に、プロセスを User に渡します。
Group 設定は User 設定と似ています。Group により、サーバが要求に応答する際に使用するグループを設定します。Group のデフォルト値も apache です。
ServerAdmin には、Red Hat Linux Secure Web Server の管理者の電子メールアドレスを設定する必要があります。この電子メールアドレスは、サーバが生成する Web ページ上に表示されるエラーメッセージの中に組み込まれます。したがって、ユーザはサーバの管理者に電子メールを送信することによって問題を報告することができます。デフォルトで、ServerAdmin は root@localhost と設定されます。
一般に、ServerAdmin を webmaster@your_domain.com と設定すると良いでしょう。この場合は、/etc/aliases において Web サーバ責任者のエイリアスとして webmaster を設定します。最後に、/usr/bin/newaliases を実行して新しいエイリアスを追加します。
ServerName を使用すれば、ホストの実際の名前とは異なる、サーバのホスト名を設定することができます。たとえば、サーバの実際の名前が foo.your_domain.com である場合に www.your_domain.com を使用することができます。ServerName は有効な Domain Name Service (DNS) 名であり、かつ貴組織はその使用権限を持たなければならないことに注意してください (ごまかしはしないでください)。
実際に ServerName を指定する場合には、その IP アドレスとサーバ名の組が /etc/hosts ファイルに組み込まれていることを確認してください。
DocumentRoot は、要求に対する応答として提供する HTML ファイルのほとんどを含むディレクトリです。Web サーバのデフォルトの DocumentRoot は、セキュアでない Web サーバでもセキュアな Web サーバでも、/var/www/html です。たとえば、サーバが以下の文書に対する要求を受信したとします。
http://your_domain/foo.html
この場合、サーバは以下のファイルをデフォルトのディレクトリの中で検索します。
/var/www/html/foo.html
セキュアな Web サーバとセキュアでない Web サーバの間で共有されないように DocumentRoot を変更したい場合は、the section called 仮想ホストの使用 を参照してください。
<Directory /path/to/directory> タグおよび </Directory> タグは、特定のディレクトリとそのすべてのサブディレクトリのみに適用する設定ディレクティブのグループを挟むために使用されます。<Directory> タグの中では、ディレクトリに対して一般に適用することのできる任意のディレクティブを使用することができます。同様に、特定ファイルに適用する場合には <File> を使用することができます。
デフォルトでは、Options ディレクティブ (the section called Options を参照) および AllowOverride ディレクティブ (the section called AllowOverride を参照) を使用することによって、ルートディレクトリに対して非常に制限の厳しいパラメータが適用されます。このように設定されている場合、システム上のディレクトリのうち、より制限の緩い設定を必要とするものについては、明示的に制限の緩い設定を行う必要があります。
Location タグを使用した場合、DocumentRoot ("/" と表します) は、制限の緩いパラメータを持つように定義されています。したがって、ここから HTTP 要求に対してサービスを提供することができます。
cgi-bin ディレクトリは、ExecCGI オプションによって、CGI スクリプトの実行を許可するようにセットアップされています。別のディレクトリに含まれる CGI スクリプトを実行する必要がある場合は、そのディレクトリについて ExecCGI を設定する必要があります。たとえば、cgi-bin が /var/www/cgi-bin である場合に、/home/my_cgi_directory の中にある CGI スクリプトを実行したい場合は、httpd.conf ファイルの Directory ディレクティブ群に対して以下のような ExecCGI ディレクティブを一つ追加します。
<Directory /home/my_cgi_directory> Options +ExecCGI </Directory>
/home/my_cgi_directory において CGI スクリプトの実行を許可するには、ExecCGI を設定する以外に、いくつかのステップを実行する必要があります。また、.cgi 拡張子を持つファイルが CGI スクリプトとして認識されるようにするために、AddHandler ディレクティブのコメント記号を削除する必要があります。AddHandler の設定方法については、the section called AddHandler を参照してください。CGI スクリプトに関する権限、およびスクリプトに対する全体のパスを 0755 と設定しなければなりません。最後に、スクリプトの所有者とディレクトリの所有者を同じユーザとしなければなりません。
<Location> タグおよび </Location> タグを使用すれば、URL に基づくアクセス制御を指定することができます。
最初の Location タグは、Options を設定し、DocumentRoot に関するその他の設定ガイドラインを指定するために使用されます。DocumentRoot 内に保存された文書へのアクセスを許可するためには、<Location "/"> と </Location> タグで挟まれた、これらのディレクティブ群が必要です。
Location タグの次の使用場所は、IfModule mod_perl.c タグの中にあります。これらの設定ディレクティブ群が効果を持つのは、mod_perl.so DSO がロードされている場合です。Apache にモジュールを追加する方法については、the section called サーバに対するモジュールの追加 を参照してください。
Location タグにより、/var/www/perl ディレクトリ (/perl の Alias) を、提供する Perl スクリプトを含むディレクトリとして指定します。パスに /perl を含む URL によって文書が要求された場合、Web サーバは適当な Perl スクリプトを /var/www/perl/ の中で検索することになります。
httpd.conf ファイルの中では、他にいくつかの <Location> オプションがコメントアウトされています。コメントアウトされた機能を有効化したい場合は、適当なディレクティブセクションのコメント記号を削除する必要があります。
httpd.conf ファイルの中には、以前に説明した Perl ディレクティブの直後に、HTTP PUT (たとえば、Web ページを Web サーバに対してポストする Netscape Gold の発行機能) を有効化するためのディレクティブセクションが含まれていますHTTP PUT の使用を許可したい場合は、このセクション全体を非コメント化する必要があります。
#LoadModule put_module modules/mod_put.so #AddModule mod_put.c # #Alias /upload /tmp #<Location /upload> # EnablePut On # AuthType Basic # AuthName Temporary # AuthUserFile /etc/httpd/conf/passwd # EnableDelete Off # umask 007 # <Limit PUT> # require valid-user # </Limit> #</Location>
貴組織のドメインから接続している人々にサーバステータスレポートの参照を許可する場合は、次のディレクティブセクションを非コメント化する必要があります。
#<Location /server-status> # SetHandler server-status # Order deny,allow # Deny from all # Allow from .your_domain.com #</Location>
.your_domain.com を第二レベルのドメイン名と置き換えなければなりません。
ドメイン内部からの要求に対してサーバ設定レポート (インストール済のモジュールおよび設定ディレクティブを含む) を提供したい場合には、以下の行のコメント記号を削除する必要があります。
#<Location /server-info> # SetHandler server-info # Order deny,allow # Deny from all # Allow from .your_domain.com #</Location>
ここでも、.your_domain.com の部分に適当な値を入力しなければなりません。
次のディレクティブセクションでは、/usr/share/doc に含まれる文書へのアクセスを許可するために Location タグを使用しています (たとえば、http://your_domain/doc/shatever.html などを使用)。 これらのディレクティブによって許可されるのは、localhost からの要求に対するアクセスのみです。
もう一つの Location タグの使用法は、Apache 1.1 以前の時代からの古いバグを悪用した Web サーバに対する攻撃を追跡することを目的とした、コメントアウトされたセクションの中に見つかります。そのような要求を追跡したい場合は、以下の行のコメント記号を削除します。
#<Location /cgi-bin/phf*> # Deny from all # ErrorDocument 403 http://phf.apache.org/phf_abuse_log.cgi #</Location>
これらの行からコメント記号を削除すると、Web サーバは /cgi-bin/phf* で終わる要求を、すべて Apache グループによって実行されるロギング CGI スクリプトに対してリダイレクトするようになります。
Options ディレクティブは、特定のディレクトリにおいてどのサーバ機能を使用可能にするのかを制御します。たとえば、ルートディレクトリに対して指定される制限の厳しいパラメータの場合、Options は FollowSymLinks のみに対して設定されます。ルートディレクトリに含まれるシンボリックリンクをたどることをサーバに許可することを除くと、どの機能も有効化されません。
デフォルトでは、DocumentRoot ディレクトリの中で、Options は Indexes、Includes および FollowSymLinks を組み込むように設定されています。Indexes は、DirectoryIndex (つまり、index.html、など) が指定されていない場合に、ディレクトリに関するディレクトリ一覧を生成することをサーバに許可します。Includes は、Server Side Include が許可されることを意味します。FollowSymLinks は、そのディレクトリに含まれるシンボリックリンクをたどることをサーバに許可します。
これらの Options を仮想ホストに認識させるためには、仮想ホストディレクティブに含まれるディレクトリについても Options 文を組み込む必要があります。
たとえば、Location "/" ディレクティブセクションの中に Options Includes という行があるため、すでに Server Side Include は /var/www/html ディレクトリ内で有効になっています。ただし、Server Side Include が /var/www/html の中で許可されていることを仮想ホストに認識させるためには、仮想ホストのタグの中に、以下のようなセクションを組み込む必要があります。
<Directory /var/www/html> Options Includes </Directory>
AllowOverride ディレクティブによって、.htaccess ファイルに含まれる宣言で Options を無効化しても良いか否かを設定します。デフォルトで、ルートディレクトリと DocumentRoot は .htaccess による無効化を許可しないように設定されています。
Order ディレクティブは、allow ディレクティブと deny ディレクティブの評価順序を制御するのみです。サーバは、DocumentRoot ディレクトリについて、deny ディレクティブの前に Allow ディレクティブを評価するように設定されています。
Allow により、所定のディレクトリに対するアクセス権限をどの要求元に与えるのかを指定します。要求元として、all、ドメイン名、IP アドレス、部分 IP アドレス、ネットワーク/ネットマスクの組、等を指定することができます。DocumentRoot ディレクトリは、all (つまり任意のユーザ) からの要求を Allow するように設定されています。
Deny の機能は allow と似ていますが、アクセスの拒否対象を指定する点が異なっています。DocumentRoot は、どこからの要求も deny しないように設定されています。
UserDir は各ユーザのホームディレクトリに含まれるサブディレクトリの名前であり、各ユーザは、Web サーバによって提供する個人的な HTML ファイルをこの場所に保存します。デフォルト設定の場合、サブディレクトリは public_html です。たとえば、サーバが以下の要求を受信したとします。
http://your_domain/~username/foo.html
この場合、サーバは以下のファイルを検索します。
/home/username/public_html/foo.html
上記の例で、/home/username がユーザのホームディレクトリです (システムによっては、ユーザのホームディレクトリへのデフォルトのパスが異なることがあることに注意してください)。
ユーザのホームディレクトリに関する権限が正しく設定されていることを確認してください。ユーザのホームディレクトリを 0755 と設定しなければなりません。ユーザの public_html ディレクトリについては読み込み (r) と実行 (x) のビットを設定しなければなりません (0755 でうまく行きます)。ユーザの public_html ディレクトリから提供するファイルについては、少なくとも 0644 を設定しなければなりません。
DirectoryIndex は、ユーザがディレクトリ名の最後にスラッシュ (/) を指定してディレクトリのインデックスを要求した場合に、サーバが提供するデフォルトのページです。
たとえば、ユーザの要求が http://your_domain/this_directory/ である場合、ユーザは DirectoryIndex が存在する場合はそのページ、またはサーバが生成するディレクトリ一覧を取得しようとします。DirectoryIndex のデフォルト値は、index.html index.htm index.shtml index.cgi です。サーバはこれら 4 つのファイルのいずれかを検索しようと試み、最初に見つけたものを返すことになります。どれも見つからず、かつこのディレクトリについて Options Indexes が設定されている場合、サーバは当該ディレクトリに含まれるサブディレクトリとファイルの一覧を HTML 形式で作成して返信します。
AccessFileName により、各ディレクトリに含まれるアクセス制御情報としてサーバに使用させるファイルを指定します。デフォルトでは、Web サーバは各ディレクトリに含まれるアクセス制御情報として、.htaccess が存在する場合にはそれを使用するように設定されています。
AccessFileName ディレクティブの直後にある Files タグ群によって、.ht で始まる任意のファイルに対するアクセス制御が適用されます。セキュリティ上の理由により、これらのディレクティブは .htaccess ファイル (または .ht で始まるファイル) に対する Web のアクセスを拒否します。
デフォルトで、Red Hat Linux Secure Web Server はプロキシサーバに対し、コンテントベースでネゴシエートされた文書をキャッシュしないように要求します (つまり、時間が経過するにしたがって、または要求元からの入力値にしたがって変化することがあります)。CacheNegotiatedDocs のコメント記号を削除するということは、この機能を無効化するということなので、プロキシサーバはそれ以降の文書のキャッシングを許可されることになります。
デフォルトで、UseCanonicalName は on と設定されます。UseCanonicalName が有効な場合、サーバは ServerName および Port を使用することによって、自分自身を参照する URL を作成することができます。クライアントからの要求への応答としてサーバが自分自身を参照する場合、サーバはこの URL を使用します。UseCanonicalName を off と設定した場合、サーバはクライアントからの要求に含まれる値を使用して自分自身を参照することになります。
TypesConfig により、MIME タイプのマッピングに関するデフォルトの一覧を設定するファイルを指定します (コンテントタイプに対するファイル名拡張子)。デフォルトの TypesConfig ファイルは /etc/mime.types です。/etc/mime.types を編集する代わりに、AddType ディレクティブを使用して MIME タイプのマッピングを追加することをお奨めします。
DefaultType により、MIME のタイプを判断することのできない文書について Web サーバに使用させる、デフォルトのコンテントタイプを設定します。Web サーバのデフォルト設定では、ファイルのコンテントタイプが不明である場合には平文テキストと見なすことになっています。
<IfModule> タグと </IfModule> タグは、条件付きのディレクティブを挟むものです。IfModule タグの間に挟まれるディレクティブは、以下の 2 つの条件のうちの 1 つが成立した場合に処理されます。ディレクティブが処理されるのは、起点の <IfModule> タグに含まれるモジュールがコンパイルされて Apache サーバに組み込まれる場合です。あるいは、モジュール名の前に 「!」 (感嘆符) を付けた場合、ディレクティブが処理されるのは、起点の <IfModule> タグに含まれるモジュールがコンパイルされない場合に限られます。
mod_mime_magic.c ファイルはこのような IfModule タグに挟まれています。mod_mime_magic モジュールは UNIX の file コマンドと比較することができます。このコマンドはファイルの内容の数バイトに注目し、「マジックナンバー」 およびその他のヒントを使用することでファイルの MIME タイプを調べます。
mod_mime_magic モジュールがコンパイルされて Apache に組み込まれる場合、これらの IfModule タグは mod_mime_magic モジュールに対して、ヒントを定義したファイルがどこにあるのかを通知します。この場合は share/magic です。
デフォルトでは、mod_mime_magic モジュールはコンパイルされません。このモジュールを使用したい場合は、サーバにモジュールを追加する方法について the section called サーバに対するモジュールの追加 を参照してください。
HostnameLookups の値として on または off を設定できます。HostnameLookups を許可する (on と設定) と、Web サーバに対して文書を要求する接続について、Web サーバは自動的に IP アドレスを解決するようになります。IP アドレスを解決するとは、特定 IP アドレスに対応するホスト名を検索するために、Web サーバが DNS と一つまたは複数の接続を行うことを言います。
一般には、DNS 要求によって Web サーバに負荷がかかり、処理速度が低下する可能性があるので、HostnameLookups の設定を off にしておく必要があります。サーバがビジーの場合、HostnameLookups の影響が極めて顕著になることがあります。
HostnameLookups はインターネット全体に関わる問題でもあります。各ホスト名をルックアップするための個々の接続がすべて加算されます。したがって、貴組織の Web サーバのためでもあり、インターネット全体のためでもあるため、HostnameLookups の設定を off にしておくべきです。
ErrorLog により、サーバのエラーを記録するファイルを指定します。このディレクティブを見て分かるように、Web サーバ用のエラーログファイルは /var/log/httpd/error_log です。
Web サーバで何らかのエラーが発生したりダウンしたりした時に、何が起きたのか分からない場合は、エラーログを参照すると参考になります。
LogLevel により、エラーログに記録するエラーメッセージの詳細さのレベルを設定します。LogLevel の値として (低い方から高い方に向かって) emerg、alert、crit、error、warn、notice、 info または debug を設定できます。Red Hat Linux Secure Web Server の LogLevel は warn (中間) と設定されています。
httpd.conf ファイルに含まれる LogFormat ディレクティブにより、アクセスログに記録されるメッセージのフォーマットを設定します。うまく行けば、このフォーマットによってアクセスログが読みやすくなります。
CustomLog により、ログファイルおよびログファイルのフォーマットを指定します。Red Hat Linux Secure Web Server のデフォルト設定では、Web サーバへのアクセスを記録する場所であるログファイルは、CustomLog によって定義されます: /var/log/httpd/access_log。Web サーバに関して、アクセスベースの性能統計情報を生成したい場合は、このファイルの場所を知る必要があります。
CustomLog はログファイルのフォーマットも共通に設定します。共通ログファイルのフォーマットは以下のようになります。
remotehost rfc931 authuser [date] "request" status bytes
リモートホスト名です。ホスト名を DNS から取得できない場合、または HostnameLookups が Off と設定されている場合、remotehost がリモートホストの IP アドレスとなります。
未使用。ログファイルの中の該当する箇所には - が表示されます。
認証を要求されていた場合、ユーザが自分自身の身元を申請した際に使用したのがこのユーザ名です。通常、これは使用されないので、該当する箇所には - が表示されます。
要求の日時。
ブラウザまたはクライアントから送信されたものとまったく同じ要求文字列。
ブラウザまたはクライアントに返された HTTP ステータスコード。
文書のサイズ。
CustomLog コマンドを使用すれば、参照者 (貴組織の Web サーバ上のページにリンクされた Web ページの URL) およびエージェント (貴組織の Web サーバから Web ページを取り出すために使用されたブラウザ) を記録するための特別なログファイルをセットアップすることができます。以下に示すように、CustomLog 関連の行はコメントアウトされていますが、これら 2 つのログファイルを使用したい場合には、コメント記号を削除する必要があります。
#CustomLog /var/log/httpd/referer_log referer #CustomLog /var/log/httpd/agent_log agent
別の手段として、以下の行のコメント記号を削除することにより、combined ログを使用するように CommonLog ディレクティブを設定することができます。
#CustomLog /var/log/httpd/access_log combined
combined は、参照者とエージェントのフィールドを共通ログファイルの末尾に追加します。combined ログを使用するためには、アクセスログを共通ログファイルフォーマットと設定している CustomLog ディレクティブをコメントアウトする必要があります。
ServerSignature ディレクティブは、サーバが生成する任意の文書 (たとえば、クライアントに返信したエラーメッセージ) に対して、Apache サーバのバージョンと、サービスを提供するホストの ServerName を含む行を追加します。デフォルトで、ServerSignature は on と設定されます。これを off と変更すれば、署名行は追加されなくなります。あるいは、Email と変更することもできます。Email は mailto:ServerAdmin HTML タグを署名行に追加します。
Alias を設定すれば、ディレクトリが DocumentRoot ディレクトリの外にあっても、なお Web サーバからのアクセスを可能とすることができます。末尾がエイリアスである URL はすべて自動的に解決され、エイリアスのパスに変換されます。デフォルトで、エイリアスが一つ設定されています。Web サーバは icons ディレクトリに対してアクセスできますが、このディレクトリは DocumentRoot に含まれていません。icons ディレクトリ、すなわちエイリアスは実際は /var/www/icons/ であって、/var/www/html/icons/ ではありません。
ScriptAlias 設定により、CGI スクリプト (またはその他のタイプのスクリプト) の見つかる場所が定義されます。一般には、CGI スクリプトを DocumentRoot の中に置いておきたくありません。CGI スクリプトが DocumentRoot の中にある場合、潜在的にそれらのスクリプトがテキスト文書として参照される可能性があります。CGI スクリプトを他人に見られる (使用される) ことが気にならないとしても、その機能が明らかになれば、ふとどきな人に対してスクリプトの中でセキュリティホールを見つけるチャンスが与えられ、サーバにとってのセキュリティリスクが発生することがあり得ます。デフォルトでは、cgi-bin ディレクトリは /cgi-bin/ の ScriptAlias であり、実際は /var/www/cgi-bin/ の中にあります。
/var/www/cgi-bin ディレクトリには Options ExecCGI が設定されているので、このディレクトリの中で CGI スクリプトの実行が許可されます。
cgi-bin 以外のディレクトリで CGI スクリプトを実行する方法については、the section called AddHandler および the section called Directory を参照してください。
Web ページを移動する場合は、Redirect を使用すれば古い URL を新しい URL にマッピングすることができます。フォーマットは以下の通りです。
Redirect /path/foo.html http://new_domain/path/foo.html
したがって、以前は http://your_domain/path/foo.html にあったページに関する HTTP 要求を受信すると、サーバはクライアントに対して新しい URL (http://new_domain/path/foo.html) を返信します。したがって、クライアントは新しい URL から文書を取り込もうとするはずです。
IndexOptions は、アイコンとファイルの説明を追加することによって、サーバが生成するディレクトリ一覧の外見を制御します。Options Indexes を設定すると (the section called Options を参照)、Web サーバが以下のような HTTP 要求を受信した際に、ディレクトリ一覧を生成することがあります。
http://your_domain/this_directory/
まず、Web サーバはそのディレクトリ内を検索して、DirectoryIndex ディレクティブの後ろの一覧にファイルが含まれるか否かを調べます (たとえば、index.html)。そのようなファイルが見つからなかった場合、Web サーバはそのディレクトリに含まれるサブディレクトリとファイルを含む HTML ディレクトリの一覧を作成します。httpd.conf の中で IndexOptions を含む一定のディレクティブを使用することで、このディレクトリ一覧の外見を修正することができます。
デフォルトの設定では FancyIndexing がオンになっています。FancyIndexing がオンの場合、ディレクトリ一覧内でカラムヘッダをクリックすると、そのヘッダによって表示順序がソートされます。同じヘッダをもう一度クリックすると、昇順と降順が切り替わって元に戻ります。FancyIndexing がオンの場合には、ファイル拡張子の種類にしたがって、ファイル毎に別々のアイコンが表示されます。AddDescription ディレクティブを使用しているときに FancyIndexing をオンにすると、サーバが生成するディレクトリ一覧にファイルの簡単な説明が組み込まれるようになります。
IndexOptions には他にもいくつかのパラメータがあり、それらを設定することで、サーバが生成するディレクトリの外見を制御することができます。パラメータには、サーバが生成する Web ページに含まれるアイコン用の HEIGHT タグと WIDTH タグをサーバに組み込むための IconHeight と IconWidth、ファイル名と共にアイコンを HTML リンクのアンカーとして機能させるための IconsAreLinks、その他が含まれます。
このディレクティブにより、サーバが生成するディレクトリ一覧において、MIME エンコードされたファイルの隣に表示するアイコンを指定します。たとえばデフォルトの場合、Web サーバはサーバが生成するディレクトリ一覧において、MIME エンコードされた x-compress ファイルおよび x-gzip ファイルの隣に compressed.gif アイコンを表示します。
このディレクティブにより、サーバが生成するディレクトリ一覧において、MIME タイプを持ったファイルの隣に表示するアイコンを指定します。たとえば、Web サーバはサーバが生成するディレクトリ一覧において、mime タイプが 「text」 であるファイルの隣に text.gif アイコンを表示するように設定されています。
AddIcon は、サーバが生成するディレクトリ一覧において、一定のファイルタイプまたは一定の拡張子を持つファイルについて、どのアイコンを表示するのかをサーバに対して通知します。たとえば、Web サーバは、拡張子が .bin または .exe であるファイルについて binary.gif アイコンを表示するように設定されています。
DefaultIcon により、サーバが生成するディレクトリ一覧において、アイコンの指定されていないファイルについて表示するアイコンを指定します。デフォルトでは、そのようなファイル用の DefaultIcon は unknown.gif です。
AddDescription を使用すれば、サーバが生成するディレクトリ一覧において、一定のファイルについて特定のテキストを表示することができます (IndexOptions として FancyIndexing を有効化する必要もあります)。特定のファイル名、ワイルドカード表記、または拡張子を指定することによって、このディレクティブの適用対象とするファイルを指定することができます。たとえば、以下の行を使用することができます。
AddDescription "A file that ends in .ni" .ni
サーバが生成するディレクトリ一覧において、.ni という拡張子を持つファイルのファイル名の後ろには、A file that ends in .ni という説明が付け加えられます。FancyIndexing もオンにする必要があることに注意してください。
ReadmeName により、サーバが生成するディレクトリ一覧の末尾に追加するファイル (ディレクトリ内に存在する場合) を指定します。Web サーバはまずそのファイルを HTML 文書として組み込むことを試み、次に平文テキストとして組み込むことを試みます。デフォルトでは、ReadmeName は README と設定されています。
HeaderName により、サーバが生成するディレクトリ一覧の先頭に追加するファイル (ディレクトリ内に存在する場合) を指定します。ReadmeName と同様に、可能であればサーバはそのファイルを HTML 文書として組み込むことを試み、不可能であれば平文テキストとして組み込むことを試みます。
IndexIgnore には、ファイル拡張子、部分ファイル名、ワイルドカード表記、または完全なファイル名を一覧形式で指定します。Web サーバは、そのようなパラメータと一致するファイルを、サーバが生成するディレクトリ一覧から除外します。
AddEncoding により、特定のエンコードタイプを指定する必要のあるファイル名拡張子を指定します。AddEncoding を使用すれば、ある種のブラウザ (すべてではありません) に対して、一定のファイルのダウンロード時にそれらのファイルを解凍するように指示することもできます。
AddLanguage により、ファイル名拡張子と特定のコンテント言語を関連付けます。一般にこのディレクティブは、クライアントのブラウザにおける言語設定に基づいて、サーバが複数の文書のいずれかを返す場合の、コンテントネゴシエーションに関して便利です。
LanguagePriority を使用すれば、ファイルを提供する際の、各言語の優先順位を設定することができます。この設定は、クライアントがブラウザで言語の優先順位を指定していない場合に有効となります。
MIME タイプとファイル拡張子の組を定義するには、AddType ディレクティブを使用します。たとえば、PHP4 を使用している場合、Web サーバは AddType ディレクティブを使用することによって、拡張子が PHP (.php4 .php3 .phtml .php) であるファイルを MIME タイプ PHP と認識します。
以下の AddType 行により、ファイル拡張子 .shtml (Server Side Include 用に) をサーバに認識させます。
AddType text/html .shtml
Server Side Include を許可する必要のある仮想ホストがある場合には、仮想ホストタグの間に上記の行を組み込む必要があります。
AddHandler は、ファイル拡張子を特定のハンドラとマッピングします。たとえば、cgi-script ハンドラを拡張子 .cgi と組み合わせることにより、.cgi で終わるファイルを自動的に CGI スクリプトとして処理することができます。ここで説明した指示にしたがう限り、このことは、ScriptAlias ディレクトリの外にあるファイルにも適用されます。
httpd.conf ファイルの中に CGI AddHandler の行があります。
AddHandler cgi-script .cgi
この行のコメント記号を削除する必要があります。その場合、Apache は .cgi で終わるファイルについては、ScriptAlias の外にある場合であっても CGI スクリプトを実行することになります。デフォルトでは、ScriptAlias は /cgi-bin/ ディレクトリを /var/www/cgi-bin/ の中で検索するように設定されています。
CGI スクリプトを含むディレクトリについては、Options として ExecCGI を設定する必要もあります。ディレクトリに関する ExecCGI の設定方法については、the section called Directory を参照してください。さらに、CGI スクリプト、および CGI スクリプトを含むディレクトリについて権限が正しく設定されていることを確認する必要があります。CGI スクリプト、およびスクリプトに対する全体のパスを 0755 と設定しなければなりません。最後に、ディレクトリの所有者とスクリプトの所有者を同じユーザとしなければなりません。
仮想ホストを使用し、ScriptAlias の外にある CGI スクリプトをその仮想ホストに認識させたい場合は、同じ AddHandler 行を VirtualHost セットアップに追加する必要があります。
CGI スクリプトだけではなく、Web サーバは AddHandler も使用することによって、サーバによって解析される HTML およびイメージマップファイルを処理します。
Action を使用すれば、MIME コンテントタイプと CGI スクリプトの組を指定することができます。したがって、当該メディアタイプが要求された場合には、かならず特定の CGI スクリプトが実行されることになります。
MetaDir により、Web サーバが文書を提供する際に、その文書に組み込むメタ情報 (特殊な HTTP ヘッダ) を含むファイルの検索場所とするディレクトリの名前を指定します。
MetaSuffix により、メタ情報 (特殊な HTTP ヘッダ) を含むファイルのファイル名接尾辞を指定します。メタ情報は MetaDir ディレクトリの中で見つかるはずです。
デフォルトでは、問題またはエラーが発生した場合に、Web サーバは要求元のクライアントに対して単純 (かつ通常は不可解) なエラーメッセージを返信します。デフォルト設定の代わりに ErrorDocument を使用して Web サーバを設定すれば、カスタマイズしたメッセージを出力するか、またはクライアントをローカル URL または外部 URL にリダイレクトすることができます。ErrorDocument は、単純に HTTP の応答コードと、クライアントに返信するメッセージまたは URL を関連付けるだけです。
BrowserMatch ディレクティブを使用すれば、サーバは環境変数を定義したり [User-Agent HTTP] フィールドに基づいて適切なアクションを実行したりすることができます。[User-Agent HTTP] フィールドを見ればクライアントのブラウザの種類が分かります。デフォルトでは、Web サーバは BrowserMatch を使用することによって、既知の問題を含む特定のブラウザからの接続を拒否したり、keepalive や HTTP ヘッダフラッシュに関して問題のあるブラウザについてそれらのアクションを無効化したりしています。
ProxyRequests その他を挟む IfModule タグのコメント記号を削除すると、Apache サーバはプロキシサーバとしても機能するようになります。mod_proxy モジュールもロード必要があります。モジュールをロードする方法については、the section called サーバに対するモジュールの追加 を参照してください。
ProxyVia コマンドにより、Apache プロキシサーバを通過する要求または応答と共に [HTTP Via:] ヘッダ行を送信するか否かを制御します。ProxyVia が on と設定されている場合には、[Via:] ヘッダにホスト名が表示されます。full の場合にはホスト名と Apache のバージョンが表示されます。off の場合には Via: 行は変更されずに渡され、block の場合には Via: 行が削除されます。
上述のプロキシ IfModule タグでは、多くのキャッシュディレクティブがコメントアウトされています。プロキシサーバの機能を使用しており、かつプロキシキャッシュも有効化したい場合には、説明するようにしてキャッシュディレクティブのコメント記号を削除する必要があります。ほとんどの場合では、キャッシュディレクティブに関するデフォルトの設定で十分なはずです。
CacheRoot により、キャッシュされたファイルの格納場所とするディレクトリの名前を設定します。デフォルトの CacheRoot は /var/cache/httpd です。
CacheSize により、キャッシュとして使用することのできる領域のサイズを KB 単位で設定します。デフォルトの CacheSize は 5 KB です。
CacheGcInterval により時間数を設定します。キャッシュが CacheSize によって許されるよりも多い領域を使用している場合には、その時間が経過するとキャッシュ内に格納されたファイルが削除されます。CacheGcInterval のデフォルト値は 4 時間です。
キャッシュされた HTML 文書は CacheMaxExpire で設定した最大時間の間はキャッシュ内に保持されます (元々そのファイルを含んでいた Web サーバからリロードされることはありません)。デフォルト値は 24 時間です。
CacheLastModifiedFactor は、元々その文書を含んでいたサーバから送信されてきた時点で、独自の有効期限が設定されていなかったような文書の有効期限を作成する際に影響を及ぼします。CacheLastModifiedFactor のデフォルト値は 0.1 と設定されています。つまり、そのような文書の有効期限は、その文書が最後に修正されてから経過した時間の長さの十分の一に等しくなります。
CacheDefaultExpire は、文書を受信した際に使用されたプロトコルが有効期限をサポートしていない場合の、時間単位の有効期限です。デフォルト値は 1 時間です。
NoCache で設定されたものと一致するホストまたはドメインから取り出した文書はキャッシングされません。キャッシングしたくない文書がどのホストまたはドメインから取り出されるものであるかが分かっている場合は、NoCache 行のコメント記号を削除し、その行にドメインまたはホスト名を設定します。
セットアップしようとしている名前ベースの仮想ホストの IP アドレス (および必要であればポート番号) については、NameVirtualHost ディレクティブを使用する必要があります。名前ベースの仮想ホストを設定するのは、ドメインごとに別々の仮想ホストをセットアップしたいものの、Web サーバによる文書の提供先であるすべてのドメイン名に対する別々の IP アドレスを持っていない (または使用したくない) 場合です。
注意:: セキュアサーバと名前ベースの仮想ホストを併用することはできません。セットアップした名前ベースの仮想ホストは、セキュアでない HTTP 接続の場合にのみ機能し、SSL 接続の場合には機能しません。
名前ベースの仮想ホストをセキュアサーバと併用できないのは、正しい名前ベースの仮想ホストを識別するための HTTP 要求の前に SSL ハンドシェークが (ブラウザがセキュアな Web サーバの認証証明書を受け付ける時に) 出現するためです。言い換えると、名前ベースの各仮想ホストが識別される前に認証が実行されるということです。セキュアサーバと仮想ホストを併用したい場合は、IP アドレスベースの仮想ホストを使用する必要があります。
名前ベースの仮想ホストを使用している場合は、NameVirtualHost 設定ディレクティブのコメント記号を削除し、NameVirtualHost の後ろにサーバの正しい IP アドレスを追加します。次に、各仮想ホストに関する ServerName を挟む Virtual Host タグ、および当該仮想ホストに対してのみ適用可能なその他の設定ディレクティブを使用することによって、各ドメインに関する詳細情報を追加します。
仮想ホストに対して適用する任意の設定ディレクティブを <VirtualHost> タグと </VirtualHost> タグで挟みます。仮想ホストタグの中では、ほとんどの設定ディレクティブを使用することができます。さらに、それらのディレクティブは特定の仮想ホストに対してのみ適用されます。
コメントアウトした一群の VirtualHost タグの間に、仮想ホストをセットアップするために入力する必要のある、設定ディレクティブ群のサンプル、および情報に対するプレースホルダがあります。仮想ホストの詳細については、the section called 仮想ホストの使用 を参照してください。
Apache 設定ディレクティブの SetEnvIf は、HTTP keepalive を無効化し、クライアントブラウザからのクローズ通知アラートなしで SSL が接続をクローズできるようにするために使用されます。SSL 接続のシャットダウンについて信頼できない種類のブラウザの場合にはこの設定が必要です。
サーバの httpd.conf ファイルに組み込まれている SSL ディレクティブは、SSL や TLS を使用したセキュアな Web 通信を有効化するためのものです。
SSL ディレクティブの詳細については、ブラウザで http://your_domain/manual/mod/mod_ssl/ にアクセスしてください。SSL の詳細は、Ralf Engelshall 氏による mod_ssl に関する Web 文書の章である http://www.modssl.org/docs/2.6/ssl_reference.html/ に含まれています。同じ文書、mod_ssl User Manual のアドレスは http://www.modssl.org/docs/2.6/ です。この文書は mod_ssl (当然) および Web における暗号一般に関して大いに役立つ情報源となっています。本マニュアルの Chapter 5 には Web サーバの保護に関する一般的な情報が含まれています。
注意:: 意味を理解しているという絶対的な自信がある場合を除き、SSL ディレクティブを修正しないでください。Red Hat Linux Secure Web Server の大部分については、インストールされた状態の SSL ディレクティブで十分です。