10.2. Apache HTTP サーバー 1.3 設定ファイルを移行する
このセクションは Apache HTTP サーバー 1.3 設定ファイルを Apache HTTP サーバー 2.0で使用するために移行する方を説明します。
Red Hat Enterprise Linux 2.1 からRed Hat Enterprise Linux 4にアップグレードする場合は、 Apache HTTP サーバー 2.0 パッケージ用の新しい設定ファイルが/etc/httpd/conf/httpd.conf.rpmnewとしてインストールされ、元のバージョン1.3 httpd.confは影響を受けません。もちろん、新しい設定ファイルを使用して古い設定を移行するか、既存のファイルをベースとして使用して変更を加えるかはユーザー次第です。ただし、ファイルの一部分は他より大きく変更してあり、ミックスした方法が一般的には最適です。 バージョン1.3 と 2.0 で提供されたいずれの設定ファイルも3つのセクションに別けられます。
/etc/httpd/conf/httpd.confファイルが、新しくインストールしたデフォルトの修正バージョンであり、元の設定ファイルを保存したコピーがある場合は、次の例のように、diffコマンドを起動するのが最も簡単でしょう(root としてログイン):
diff -u httpd.conf.orig httpd.conf | less |
このコマンドは変更が加えられた箇所すべてをハイライトします。 元のファイルのコピーがない場合、rpm2cpioとcpio コマンドを使って以下の例のようにRPMパッケージから抽出します。
rpm2cpio apache-<version-number>.i386.rpm | cpio -i --make |
上記のコマンドの<version-number>の部分はapacheパッケージのバージョン番号に 置き換えます。
最後に、Apache HTTP サーバーは設定エラーをチェックするテストモードがあるのを知っておくと便利です。 アクセスするには以下のコマンドを入力します。
apachectl configtest |
10.2.1. グローバル環境の設定
設定ファイルのグローバル環境のセクションには、処理できる多くの同時並行要求や各種ファイルの場所など、 Apache HTTP サーバー の全体的な動作に影響するディレクティブが含まれています。このセクションでは、かなり多くの変更が必要となり、Apache HTTP サーバー 2.0 設定ファイルを元にして古い設定をここに移行することが推奨されます。
10.2.1.1. インターフェースとポートのバインド
BindAddressとPortディレクティブは なくなりました。これらの機能はより柔軟性のあるListenディレクティブ で提供されるようになります。
Port 80が 1.3バージョンの設定ファイルで設定されていた場合、2.0 の設定ファイルでListen 80に変更します。Portが80 以外の値に設定されていた場合、ServerNameディレクティブのコンテンツにポート番号を追加します。
例えば、Apache HTTP サーバー 1.3 ディレクティブの例を以下に示します。
Port 123 ServerName www.example.com |
この設定をApache HTTP サーバー 2.0 に移行するには、以下の構成を使用します。
Listen 123 ServerName www.example.com:123 |
このテーマに関する詳細は、Apache Software Foundation のウェブサイトにある以下のドキュメントを参照してください。
10.2.1.2. サーバープールのサイズ規定
Apache HTTP サーバー が要求を受け付けると、それを処理するために子プロセスまたはスレッドをディスパッチします。この子プロセスまたはスレッドのグループはサーバープールとして知られています。Apache HTTP サーバー 2.0 の作動環境では、このサーバープールの作成と管理の責任は、マルチプロセッシングモジュール(MPM) と呼ばれるモジュールのグループに抽出されています。他のモジュールとは異なり、 MPM グループのうちの1つのモジュールのみが Apache HTTP サーバーによって読み込まれます。 2.0では、prefork、worker、perchildの3つの MPM モジュールが出荷されています。現在、preforkMPM とworkerMPM のみが利用可能です。perchildMPM は将来的には利用できるようになる可能性があります。
元の Apache HTTP サーバー 1.3 の動作はprefork MPM に移動しています。 prefork MPM はApache HTTP サーバー 1.3 と同じディレクティブを受けるので、以下のディレクティブが直接移行できるかもしれません。
StartServers
MinSpareServers
MaxSpareServers
MaxClients
MaxRequestsPerChild
worker MPM は、マルチプロセス、マルチスレッド対応のサーバーを実装しており、優れたスケーラビリティを提供します。この MPMを使用すると、要求がスレッドによって処理され、システムリソースを維持しながら効率的に大量の要求を処理できるようになります。worker MPM が受けるディレクティブのいくつかは、prefork MPM が受けるディレクティブと同じものですが、このディレクティブの値は Apache HTTP サーバー 1.3 インストールからそのまま転送しないでください。代わりに、ガイドとしてデフォルト値を使用するのが最もよく、どの値が最も機能するか試してから決定してください。
 | 重要 | |
|---|---|---|
worker MPM を使用するには、/etc/sysconfig/httpdファイルを作成し、以下のディレクティブを追加します:
|
MPM に関するテーマの詳細については、Apache Software Foundation のウェブサイトにある以下のドキュメントを参照してください。
10.2.1.3. Dynamic Shared Object (DSO) のサポート
ここでは多くの変更が必要になります。Apache HTTP サーバー 1.3 の設定をバージョン2.0 に合わせて変更しようとしている方は(変更をバージョン2.0 設定に移行するのではなく)、 提供されたApache HTTP サーバー 2.0設定ファイルからこのセクションをコピーすることを強くおすすめします。
提供された Apache HTTP サーバー 2.0設定からそのセクションをコピーしたくない方は、以下の点に注意してください。
AddModuleとClearModuleList ディレクティブはなくなりました。 このディレクティブは、正しい順序でモジュールが有効化されることを確認するのに使用 されていました。TTPD; 2.0 API では、モジュールがその順序を指定することができ、 この2つのディレクティブの必要性が解消されました。
LoadModule行の順番はほとんどの場合に意味が無くなって います。
多くのモジュールに追加、削除、名前の変更、分割、他モジュールと統合、 などが行なわれています。
自身のRPM (mod_ssl、php、 mod_perlなどの系列)にパッケージ化されているモジュールの LoadModule行は、/etc/httpd/conf.d/ ディレクトリ内の関連ファイルにあるため、必要性がなくなりました。
各種のHAVE_XXX 定義は定義されなくなります。
| 重要 | |
|---|---|---|
元のファイルを変更する場合は、httpd.confが以下のディレクティブを含むことが非常に重要なこととなりますので注意してください:
このディレクティブを省略すると、それらのRPM (mod_perl、 php、mod_sslなど)にパッケージ化されている すべてのモジュールで障害が起きる要因となります。 |
10.2.1.4. その他グローバル環境の変更
以下のディレクティブが Apache HTTP サーバー 2.0の設定から削除されています。
ServerType — Apache HTTP サーバー はServerType standaloneとしてのみ実行することができ、 このディレクティブは不適切になります。
AccessConfigと ResourceConfig — これらのディレクティブは、Includeディレクティブの機能を ミラーリングするので削除されています。AccessConfig とResourceConfigディレクティブが設定されると、 Includeディレクティブに置き換わります。
古いディレクティブで示される順序でファイルが読み込まれるようにするには、 Includeをhttpd.confの末尾に置く必要が
10.2.2. メインサーバーの設定
設定ファイルのメインサーバー設定セクションはメインサーバーを設定します。 これは、<VirtualHost>コンテナ内に定義された 仮想ホストによって処理されないすべての要求に応答します。 ここの値も定義されるすべての<VirtualHost> コンテナに対してデフォルトを提供します。
このセクションで使用されるディレクティブはApache HTTP サーバー 1.3 とバージョン 2.0 で 変更はありません。メインサーバーの設定が大幅にカスタマイズされる場合は、 既存の設定ファイルをApache HTTP サーバー 2.0に合わせて変更する方が簡単かもしれません。 メインサーバーのセクションを少ししかカスタマイズしないユーザーは 変更をデフォルトの2.0設定に移行してください。
10.2.2.1. UserDir マッピング
UserDirディレクティブは、 http://example.com/~bob/などのURLを有効にして /home/bob/public_html/などのユーザーbob のホームディレクトリ内のサブディレクトリにマップするために使用されます。 この機能の副作用で、潜在的な攻撃者によって特定ユーザー名がシステム上に存在するかどうか を確認できるようになってしまいます。 これは、Apache HTTP サーバー 2.0 のデフォルト設定がこのディレクティブを無効にするためです。
UserDirマッピングを有効にするには、 httpd.confの以下のディレクティブを
UserDir disable |
以下のディレクティブに変更します。
UserDir public_html |
このテーマに関する詳細は、Apache Software Foundation のウェブサイトにある以下のドキュメントを参照してください。
10.2.2.2. ロギング
以下のロギングディレクティブが削除されています。
AgentLog
RefererLog
RefererIgnore
ただし、agent ログ 及び referrer ログは、 CustomLogとLogFormatディレクティブを 使用して利用することができます。
このテーマに関する詳細は、Apache Software Foundation のウェブサイトにある以下のドキュメントを参照してください。
10.2.2.3. ディレクトリインデックス
古くなったFancyIndexingディレクティブは削除されています。 同じ機能がIndexOptionsディレクティブ内の FancyIndexing オプション を使って利用することができます。
IndexOptionsディレクティブへのVersionSortオプションで、ファイルがより自然な形でソートされたバージョン番号を含むようになります。例えば、ディレクトリインデックスページで、httpd-2.0.6.tarは、httpd-2.0.36.tarの前に現れます。
ReadmeNameとHeaderNameディレクティブ のデフォルトが、READMEとHEADERから README.htmlとHEADER.html に変更になっています。
このテーマに関する詳細は、Apache Software Foundation のウェブサイトにある以下のドキュメントを参照してください。
10.2.2.4. コンテントネゴシエーション
CacheNegotiatedDocs ディレクティブが引数の on または off をとるようになります。既存の CacheNegotiatedDocs のインスタンスは CacheNegotiatedDocs on に置き換えてください。
このテーマに関する詳細は、Apache Software Foundation のウェブサイトにある以下のドキュメントを参照してください。
10.2.2.5. エラードキュメント
ErrorDocumentディレクティブでハードコードされた メッセージを使用するには、Apache HTTP サーバー 1.3 で行なっていたように 1つの二重引用符
例えば、Apache HTTP サーバー 1.3 ディレクティブの例を以下に示します。
ErrorDocument 404 "The document was not found |
ErrorDocument設定をApache HTTP サーバー 2.0 に移行するには、 以下の構成を使用します。
ErrorDocument 404 "The document was not found" |
ErrorDocumentディレクティブの例で二重引用符を後に付けることに注意してください。
このテーマに関する詳細は、Apache Software Foundation のウェブサイトにある以下のドキュメントを参照してください。
10.2.3. 仮想ホスト設定
すべての<VirtualHost>コンテナのコンテンツは、 項10.2.2で説明しているメインサーバーのセクション と同じ方法で移行してください。
| 重要 |
|---|---|
SSL/TLS 仮想ホストの設定はメインサーバーの設定ファイルから /etc/httpd/conf.d/ssl.confに移動しているので注意してください。 |
このテーマに関する詳細は、Red Hat Enterprise Linux システム管理ガイドにある Apache HTTP セキュアサーバーの設定の章、及び 以下のURLにあるオンラインドキュメントを参照してください。
10.2.4. モジュールとApache HTTP サーバー 2.0
Apache HTTP サーバー 2.0 では、モジュールシステムが変更になり、 複数モジュールが新しい方法で連鎖または結合されるようになりました。 例えば、CGI(Common Gateway Interface)スクリプトはサーバー解析されたHTMLドキュメントを生成することができ、 このドキュメントはmod_includeで処理できます。 これにより、特定の目的を達成するためにモジュールを結合する方法に関して、 飛躍的な可能性をもたらすことになります。
これが機能する方法は、正確に1つのhandlerモジュール と0または複数のfilterモジュールを後に付けて各要求に応じます。
Apache HTTP サーバー 1.3 稼動環境では、例えば、Perl スクリプトはその中で Perl モジュール (mod_perl)によって処理されます。 Apache HTTP サーバー 2.0 では、要求が最初に核のモジュール— 静的ファイルを処理 — で処理されてから、mod_perl でフィルタされます。
正確にこれを使用する方法、及びその他すべての新しいApache HTTP サーバー 2.0の機能は、 このガイドの範疇を超えてしまいますが、PATH_INFOディレクティブ をフィルタとして実装されるようになったモジュールで処理するドキュメントに使用する場合、 それぞれが本当のファイル名の後に後続のパス情報を含むため、変更は複数に分岐します。 要求を最初に処理する核のモジュールは、デフォルトではPATH_INFOを 理解せず、このような情報を含む要求に対して404 Not Foundエラーを返します。別の方法として、AcceptPathInfo ディレクティブを使用して核のモジュールがPATH_INFOで 要求を受けるよう強制します。
以下にこのディレクティブの例を示します。
AcceptPathInfo on |
このテーマに関する詳細は、Apache Software Foundation のウェブサイトにある以下のドキュメントを参照してください。
10.2.4.1. suexecモジュール
Apache HTTP サーバー 2.0 では、mod_suexecモジュールは、仮想ホストの設定に UserとGroupディレクティブではなく、 SuexecUserGroupディレクティブを使用します。UserとGroupディレクティブは一般的にはまだ使用 されますが、仮想ホストの設定には無用となりました。
例えば、Apache HTTP サーバー 1.3 ディレクティブの例を以下に示します。
<VirtualHost vhost.example.com:80>
User someone
Group somegroup
</VirtualHost> |
この設定をApache HTTP サーバー 2.0 に移行するには、以下の構成を使用します。
<VirtualHost vhost.example.com:80>
SuexecUserGroup someone somegroup
</VirtualHost> |
10.2.4.2. mod_sslモジュール
mod_sslの設定はhttpd.confファイルから/etc/httpd/conf.d/ssl.confファイルに移動されています。このファイルがロードされ、mod_sslが機能するには、 項10.2.1.3で説明しているように、ステートメントのInclude conf.d/*.confが httpd.confファイルになければなりません。
SSL 仮想ホストのServerNameディレクティブは、 明示的にポート番号を指定する必要があります。
例えば、Apache HTTP サーバー 1.3 ディレクティブの例を以下に示します。
<VirtualHost _default_:443>
# General setup for the virtual host
ServerName ssl.example.name
...
</VirtualHost> |
この設定をApache HTTP サーバー 2.0 に移行するには、以下の構成を使用します。
<VirtualHost _default_:443>
# General setup for the virtual host
ServerName ssl.host.name:443
...
</VirtualHost> |
また、SSLLogとSSLLogLevel のいずれのディレクティブも削除されていることに十分注意してください。 mod_sslモジュールはErrorLogとLogLevelディレクティブに従うようになります。これらのディレクティブの詳細については、項10.5.35と項10.5.36を参照してください。
このテーマに関する詳細は、Apache Software Foundation のウェブサイトにある以下のドキュメントを参照してください。
10.2.4.3. mod_proxyモジュール
プロキシアクセス制御のステートメントは、<Directory proxy:>ではなく、<Proxy>ブロック内に配置されるようになります。
旧mod_proxyのキャッシュ機能は次の3つのモジュールに 分割されています。
mod_cache
mod_disk_cache
mod_mem_cache
これらは一般的にはmod_proxyモジュールの旧バージョンと 類似したディレクティブを使用しますが、キャッシュの設定を移行する前に、 各ディレクティブを確認するのが賢明です。
このテーマに関する詳細は、Apache Software Foundation のウェブサイトにある以下のドキュメントを参照してください。
10.2.4.4. mod_includeモジュール
mod_includeモジュールがフィルタとして実装されるようになったので、 有効にする方法が異なります。フィルタに関しての詳細は、項10.2.4を参照してください。
例えば、Apache HTTP サーバー 1.3 ディレクティブの例を以下に示します。
AddType text/html .shtml AddHandler server-parsed .shtml |
この設定をApache HTTP サーバー 2.0 に移行するには、以下の構成を使用します。
AddType text/html .shtml AddOutputFilter INCLUDES .shtml |
Options +Includesディレクティブは、従来通りに <Directory>コンテナまたは.htaccessファイルに必要となるので注意してください。
このテーマに関する詳細は、Apache Software Foundation のウェブサイトにある以下のドキュメントを参照してください。
10.2.4.5. mod_auth_dbmモジュールとmod_auth_dbモジュール
Apache HTTP サーバー 1.3 は2つの認証モジュール、mod_auth_dbとmod_auth_dbmをサポートしていました。これらはそれぞれ Berkeley データベースと DBM データベースを使用していました。 Apache HTTP サーバー 2.0では、 これらのモジュールが1つのモジュールに結合され、mod_auth_dbmという名前になり、いくつかの異なるデータベース形式にアクセスすることができます。mod_auth_dbから移行するには、AuthDBUserFileとAuthDBGroupFileをmod_auth_dbmに相当するAuthDBMUserFileと AuthDBMGroupFileに置き換えて、設定ファイルを調整する必要があります。また、ディレクティブAuthDBMType DBが、使用中のデータベースファイルのタイプを示すために追加されなければなりません。
以下の例では、Apache HTTP サーバー 1.3 のmod_auth_db設定の例を示します。
<Location /private/> AuthType Basic AuthName "My Private Files" AuthDBUserFile /var/www/authdb require valid-user </Location> |
この設定をApache HTTP サーバーのバージョン2.0 に移行するには、以下の構成を使用します。
<Location /private/> AuthType Basic AuthName "My Private Files" AuthDBMUserFile /var/www/authdb AuthDBMType DB require valid-user </Location> |
AuthDBMUserFileディレクティブも .htaccessファイルで使用することができるので注意してください。
Apache HTTP サーバー 2.0では、ユーザー名とパスワードデータベースを処理するのに使用される dbmmanagePerl スクリプトが、htdbmで 置き換えられています。htdbmプログラムは同等の機能を提供し、 mod_auth_dbmの様に、さまざまなデータベース形式を管理する ことができます; 使用する形式を指定するには、-Tオプションを コマンドラインで使用できます。
表10-1では、DBM形式のデータベースを dbmmanageを使用してhtdbm形式に 移行する方法を示しています。
| 動作 | dbmmanage コマンド (1.3) | 相当する htdbm コマンド (2.0) |
|---|---|---|
| ユーザーをデータベースに追加(特定パスワードを使用) | dbmmanage authdb add username password | htdbm -b -TDB authdb username password |
| ユーザーをデータベースに追加(パスワードを要求) | dbmmanage authdb adduser username | htdbm -TDB authdb username |
| データベースからユーザーを削除 | dbmmanage authdb delete username | htdbm -x -TDB authdb username |
| データベース内のユーザーの一覧 | dbmmanage authdb view | htdbm -l -TDB authdb |
| パスワードの確認 | dbmmanage authdb check username | htdbm -v -TDB authdb username |
表 10-1. dbmmanageからhtdbmに移行する
-mと-sオプションは、 dbmmanage、htdbmのいずれでも機能し、 パスワードのハッシュ用のMD5アルゴリズムの使用、 SHA1アルゴリズムの使用をそれぞれ有効にします。
htdbmで新しいデータベースを作成するときは、 -cオプションを使う必要があります。
このテーマに関する詳細は、Apache Software Foundation のウェブサイトにある以下のドキュメントを参照してください。
10.2.4.6. mod_perlモジュール
mod_perlの設定は、httpd.confから /etc/httpd/conf.d/perl.confファイルに移動しています。 このファイルが読み込まれ、mod_perlが機能するためには、 Include conf.d/*.confステートメントが 項10.2.1.3で示すように、 httpd.confに含まれている必要があります。
httpd.confにあるApache::のオカレンスが、 ModPerl::に置き換えられる必要があります。 さらに、ハンドラが登録される方法が変更になりました。
これはApache HTTP サーバー 1.3 mod_perl設定の例です。
<Directory /var/www/perl>
SetHandler perl-script
PerlHandler Apache::Registry
Options +ExecCGI
</Directory> |
これがApache HTTP サーバー 2.0 の相当するmod_perlです。
<Directory /var/www/perl>
SetHandler perl-script
PerlResponseHandler ModPerl::Registry
Options +ExecCGI
</Directory> |
mod_perl 1.x のモジュールはほとんど mod_perl 2.x で修正を行なわなくても機能するはずです。 XS モジュールは再コンパイルが必要で、マイナーなMakefileの修正が必要かもしれません。
10.2.4.7. mod_pythonモジュール
mod_pythonの設定は、httpd.confから /etc/httpd/conf.d/python.confファイルに移動しています。 このファイルがロードされ、mod_pythonが機能するには、 Include conf.d/*.confステートメントが、 項10.2.1.3で示すように、 httpd.confになければなりません。
10.2.4.8. PHP
PHPの設定は、httpd.confから /etc/httpd/conf.d/php.confファイルに移動しています。 このファイルがロードされるためには、Include conf.d/*.confステートメントが、項10.2.1.3で示すように、 httpd.confになければなりません。
 | 注記 |
|---|---|
Apache HTTP サーバー 1.3 で使用されていた PHP 設定ディレクティブは、Red Hat Enterprise Linux 4上で Apache HTTP サーバー 2.0 に移行する時に完全な互換性があります。 |
PHP バージョン4.2.0 及びそれ以降のバージョンでは、global scopeで利用可能な あらかじめ設定されたデフォルトの変数が変更しています。個別のインプットとサーバーの変数は、デフォルトでは global scopeに直接は置かれなくなります。 この変更によりスクリプトが壊れる可能性があります。/etc/php.iniファイル内でregister_globalsをOn に設定して旧動作に戻します。
このテーマについての詳細は、global scope の変更に関する詳細を 以下のURLで参照してください。
10.2.4.9. mod_authz_ldap モジュール
Red Hat Enterprise Linux は Apache HTTP サーバー 用の mod_authz_ldapモジュールを含んで 配送されます。このモジュールは1つの題目とクライアントSSL 証書の発行者の為の 識別名の短い形式を使用して、 LDAP ディレクトリ内の識別したユーザー名を決定します。 また、このモジュールはそのユーザーのLDAP ディレクトリのエントリを元にしてユーザー への認証を発行でき、資源のユーザーとグループ権限を元にして資源へのアクセスを 決定し、パスワードが満期になったユーザーのアクセスを拒否します。 mod_authz_ldap モジュールを使用する場合には、 mod_sslが必要となります。
| 重要 |
|---|---|
mod_authz_ldap モジュールは、暗号化したパスワードハッシュを使用するユーザーの LDAP ディレクトリへの認証はしません。この機能は実験的な mod_auth_ldap モジュールにより提供されています。このモジュールの状況の詳細はオンラインアドレスhttp://httpd.apache.org/docs-2.0 /mod/mod_auth_ldap.htmlのmod_auth_ldapモジュール ドキュメントを参照して下さい。 |
/etc/httpd/conf.d/authz_ldap.conf ファイルは mod_authz_ldap モジュールを設定します。
mod_authz_ldap サードパーティモジュールの設定に関する詳細は /usr/share/doc/mod_authz_ldap-<version>/index.html (<version> をパッケージのバージョン番号で入れ換え) 又は http://authzldap.othello.ch/で参照 して下さい。