Apache Webサーバをセットアップする前に、次の要件が満たされていることを確認してください。

SUSE Linux Enterprise Server上のApacheは、デフォルトではインストールされません。「そのまますぐに」実行できる標準の事前定義された設定を使用してインストールするには、次の手順を使用します。

このインストールには、apache2-prefork マルチプロセシングモジュール とPHP5モジュールが含まれています。モジュールの詳細については、30.4項 「モジュールのインストール、有効化および設定」を参照してください。

Apacheは、ブート時に自動的に起動することも、手動で起動することもできます。

SUSE Linux Enterprise Serverでのランレベルの詳細、およびYaSTランレベルエディタについては、9.2.3項 「YaSTを使用したSystem Services (Runlevel)の設定」を参照してください。

シェルを使用してApacheを手動で起動するには、rcapache2 startを実行します。

Webサーバの起動後は、ドキュメントを追加、必要に応じて設定を調整、およびモジュールをインストールして機能を追加することができます。

このセクションでは、Apache設定ファイルの概要を示します。環境設定にYaSTを使用する場合は、これらのファイルを操作する必要はありません。ただし、後で手動設定に切り替える場合に、この情報が役立つことがあります。

Apache設定ファイルは、次の2つの場所にあります。

/etc/apache2/
     |
     |- charset.conv 
     |- conf.d/
     |   |
     |   |- *.conf
     |
     |- default-server.conf
     |- errors.conf
     |- httpd.conf
     |- listen.conf
     |- magic
     |- mime.types
     |- mod_*.conf
     |- server-tuning.conf
     |- ssl.*
     |- ssl-global.conf
     |- sysconfig.d
     |   |
     |   |- global.conf
     |   |- include.conf
     |   |- loadmodule.conf . .
     |
     |- uid.conf
     |- vhosts.d
     |   |- *.conf

Apacheを手動設定するには、rootユーザとしてプレーンテキストの設定ファイルを編集する必要があります。

30.2.2.1. 仮想ホスト設定¶

仮想ホスト という用語は、同じ物理マシンから複数のURI (universal resource identifiers)のサービスを行えるApacheの機能を指しています。これは、たとえばwww.example.comやwww.example.netのような複数のドメインが、1台の物理コンピュータ上で動作する単一のWebサーバで処理されていることを表します。

管理の手間(1つのWebサーバを維持すればよい)とハードウェアの費用(ドメインごとの専用のサーバを必要としない)を省くために仮想ホストを使うことは、よく行われています。仮想ホストは名前ベース、IPベース、またはポートベースのいずれかになります。

すべての既存仮想ホストをリストするには、コマンドhttpd2 -Sを使用します。デフォルトサーバおよびすべての仮想ホストが、それらのIPアドレスおよびリスニングポートとともにリストに表示されます。リストには、各仮想ホストの設定ファイル内での位置を示すエントリも含まれています。

仮想ホストを設定するには、YaSTを使用するか(30.2.3.1.4項 「仮想ホスト」で説明)、または設定ファイルを手動で編集します。SUSE Linux Enterprise ServerのApacheは、デフォルトでは、/etc/apache2/vhosts.d/内の仮想ホストごとに1つの設定ファイルを使用するようになっています。このディレクトリ内で、拡張子が.confのファイルは、すべて自動的に設定に含まれます。仮想ホストの基本的なテンプレートはこのディレクトリ内に用意されています(vhost.template、またはSSLサポートのある仮想ホストの場合はvhost-ssl.template)。

	常に仮想ホスト設定を作成する
Webサーバに1つのドメインしか存在しない場合でも、常に仮想ホストの設定ファイルを作成することをお勧めします。そうすることによって、ドメイン固有の設定が1つのファイルにまとまるだけでなく、仮想ホストの設定ファイルを移動、削除、または名前変更することによって使用可能な基本設定に常時フォールバックできます。同じ理由で、仮想ホストごとに個別の設定ファイルも作成します。 名前ベースの仮想ホストを使用する際、ドメイン名が仮想ホスト設定と一致しない場合に使用されるデフォルト設定を設定することを推奨します。デフォルト仮想ホストは、その設定が最初にロードされるホストです。設定ファイルの順序は、ファイル名で決定されるので、デフォルト仮想ホスト設定のファイル名は、下線文字(_)で始めて (たとえば、_default_vhost.conf).、そのファイルが最初にロードされるようにします。

<VirtualHost></VirtualHost>ブロックには、特定のドメインに適用される情報を記述します。Apacheは、クライアントから定義済みの仮想ホストへの要求を受け取ると、このセクションに記述されているディレクティブを使用します。仮想ホストでは、ほぼすべてのディレクティブを使用できます。Apacheの設定ディレクティブの詳細については、http://httpd.apache.org/docs/2.2/mod/quickreference.htmlを参照してください。

30.2.2.1.1. 名前ベースの仮想ホスト¶

名前ベースの仮想ホストでは、1つのIPアドレスで複数のWebサイトを運用することができます。Apacheは、クライアントから送られたHTTPヘッダのホストフィールドを使用して、仮想ホスト宣言の1つの、一致するServerNameエントリに要求を接続します。一致するServerNameが見つからない場合には、指定されている最初の仮想ホストがデフォルトとして用いられます。

NameVirtualHostディレクティブは、HTTPヘッダ内のドメイン名を含むクライアントからの要求に関して、どのIPアドレス(オプションとして、どのポート)をリスンすべきかApatcheに指示しますこのオプションは、/etc/apache2/listen.conf設定ファイルで設定されます。

最初の引数には完全修飾ドメイン名を指定することができますが、IPアドレスを使用することをお勧めします。2番目の引数はポートで、オプションです。デフォルトでは、ポート80が使用され、 Listen ディレクティブで設定されます。

ワイルドカード*は、IPアドレスとポート番号の両方で使用することができます。その場合、すべてのインタフェースでの要求を受け取ります。IPv6のアドレスは、角カッコの中に記述する必要があります。

例30.1 名前ベースのVirtualHostエントリの応用例¶

# NameVirtualHost IP-address[:Port]
NameVirtualHost 192.168.3.100:80
NameVirtualHost 192.168.3.100
NameVirtualHost *:80
NameVirtualHost *
NameVirtualHost [2002:c0a8:364::]:80

VirtualHost開始タグには、名前ベースの仮想ホスト設定でNameVirtualHostを引数として使用して以前に宣言されたIPアドレス(または完全修飾ドメイン名)が採用されます。NameVirtualHostディレクティブで以前に宣言されたポート番号はオプションです。

ワイルドカード*をIPアドレスの代わりに使うこともできます。この構文は、ワイルドカードをNameVirtualHost *として組み合わせて使用する場合にのみ有効です。IPv6アドレスを使用する場合には、アドレスを角カッコの中に記述することが必要です。

例30.2 名前ベースのVirtualHostディレクティブ¶

<VirtualHost 192.168.3.100:80>
  ...
</VirtualHost>

<VirtualHost 192.168.3.100>
  ...
</VirtualHost>

<VirtualHost *:80>
  ...
</VirtualHost>

<VirtualHost *>
  ...
</VirtualHost>

<VirtualHost [2002:c0a8:364::]>
  ...
</VirtualHost>

30.2.2.1.2. IPベースの仮想ホスト¶

この仮想ホスト設定では、1つのコンピュータに対して複数のIPアドレスを設定する必要があります。Apacheの1つのインスタンスが、複数のドメインにホストとしてサービスを提供し、各ドメインに別のIPアドレスが割り当てられることになります。

物理サーバは、IPベースの仮想ホストごとに、1つのIPアドレスを持つ必要があります。マシンに複数のネットワークカードがない場合には、仮想ネットワークインタフェース(IPエイリアス)を使用することもできます。

次の例では、IP 192.168.3.100のマシンでApacheが実行されており、付加的なIP 192.168.3.101および192.168.3.102をホストしています。すべての仮想サーバについて、VirtualHostブロックが個別に必要です。

例30.3 IPベースのVirtualHostディレクティブ¶

<VirtualHost 192.168.3.101>
  ...
</VirtualHost>

<VirtualHost 192.168.3.102>
  ...
</VirtualHost>

ここでは、VirtualHostディレクティブは、192.168.3.100以外のインタフェースに対してのみ指定されています。Listenディレクティブが192.168.3.100に対しても設定される場合、このインタフェースへのHTTP要求に応答するために別のIPベースの仮想ホストを作成する必要があります。作成しない場合、デフォルトのサーバ設定(/etc/apache2/default-server.conf)内のディレクティブが適用されます。

30.2.2.1.3. 基本的な仮想ホスト設定¶

仮想ホストをセットアップするには、少なくとも次のディレクティブが各仮想ホスト設定に含まれている必要があります。オプションについては、/etc/apache2/vhosts.d/vhost.templateを参照してください。

ServerName

ホストに割り当てられている完全修飾ドメイン名。

DocumentRoot

Apacheがこのホストにファイルをサービスする際に使用されるディレクトリパス。セキュリティ上の理由から、ファイルシステム全体へのアクセスはデフォルトで禁じられているため、Directoryコンテナ内でこのディレクトリを明示的にロック解除する必要があります。

ServerAdmin

サーバ管理者の電子メールアドレス。このアドレスは、Apacheが作成するエラーページなどに表示されます。

ErrorLog

この仮想ホストに関するエラーログファイル。仮想ホストごとに個別のエラーログファイルを作成する必要はありませんが、エラーのデバッグが簡単にできるため、作成されるのが一般的です。/var/log/apache2/はApacheのログファイルのデフォルトディレクトリです。

CustomLog

この仮想ホストに関するアクセスログファイル。仮想ホストごとに個別のアクセスログファイルを作成する必要はありませんが、ホストごとのアクセス統計を個別に分析できるため、作成されるのが一般的です。/var/log/apache2/はApacheのログファイルのデフォルトディレクトリです。

セキュリティ上の理由から、ファイルシステム全体へのアクセスはデフォルトで禁じられています。したがって、DocumentRootなど、Apacheによりサービスされるファイルを保管したディレクトリを明示的にロック解除する必要があります。

<Directory "/srv/www/www.example.com/htdocs">
  Order allow,deny
  Allow from all
</Directory>

完全な設定ファイルは次のようになります。

例30.4 基本的な仮想ホスト設定¶

<VirtualHost 192.168.3.100>
  ServerName www.example.com
  DocumentRoot /srv/www/www.example.com/htdocs
  ServerAdmin webmaster@example.com
  ErrorLog /var/log/apache2/www.example.com_log
  CustomLog /var/log/apache2/www.example.com-access_log common
  <Directory "/srv/www/www.example.com/htdocs">
    Order allow,deny
    Allow from all
  </Directory>
</VirtualHost>

YaSTを使用してWebサーバを設定するには、YaSTを起動して、ネットワークサービス+HTTPサーバの順に選択します。このモジュールを初めて起動するときに、HTTPサーバウィザードが起動して、サーバ管理に関していくつかの基本的な事項を決定するように要求されます。このウィザードの完了後、HTTPサーバのモジュールを呼び出すたびに、HTTPサーバの環境設定ダイアログが起動します。詳細については、30.2.3.2項 「HTTPサーバの設定」を参照してください。

30.2.3.1. HTTP Server Wizard¶

HTTP Server Wizardには、5つのステップがあります。ダイアログの最後のステップでは、上級者用の設定モードに入って、さらに詳細な設定を行うかどうか選択できます。

30.2.3.1.1. Network Device Selection (ネットワークデバイスの選択)¶

ここでは、Apacheが着信リクエストをリスンするために使用する、ネットワークインタフェースとポートを指定します。既存のネットワークインタフェースとそれらに対応するIPアドレスから、任意のものを組み合わせて選択できます。他のサービスによって予約されていないものであれば、3つの範囲(ウェルノウンポート、レジスタードポート、ダイナミックまたはプライベートポート)のうちのどのポートでも使用できます。デフォルトの設定では、ポート80ですべてのネットワークインタフェース(IPアドレス)をリスンします。

ファイアウォールでWebサーバがリスンするポートを開くには、ファイアウォールでポートを開くをクリックします。これは、LAN、WAN、または公共のインターネットなど、ネットワーク上でWebサーバを利用可能にする場合には必須です。外部からのWebサーバへのアクセスが不要なテスト段階でのみ、ポートを閉じておくことは有用です。複数のネットワークインタフェースが存在する場合は、ファイアウォールの詳細...をクリックして、ポートを開くインタフェースを指定します。

次へ をクリックして設定を続けます。

30.2.3.1.2. モジュール¶

モジュール設定オプションによって、Webサーバでサポートされるスクリプト言語の有効化または無効化を設定できます。他のモジュールの有効化または無効化の詳細については、30.2.3.2.2項 「サーバモジュール」を参照してください。次へをクリックして次のダイアログに進みます。

30.2.3.1.3. Default Host (デフォルトのホスト)¶

このオプションは、デフォルトのWebサーバに関連しています。30.2.2.1項 「仮想ホスト設定」で説明されているように、Apacheは、1つの物理的マシンで複数の仮想ホストに使用することができます。設定ファイルで最初に宣言された仮想ホストは通常、デフォルトのホストと呼ばれます。各仮想ホストは、デフォルトホストの設定を継承します。

ホストの設定(ディレクティブ)を編集するには、テーブル内の適切なエントリを選択して、編集をクリックします。新しいディレクティブを追加するには、追加をクリックします。ディレクティブを削除するには、そのアカウントを選択し、削除をクリックします。

図30.1 HTTP Server Wizard:デフォルトホスト¶

これはサーバのデフォルト設定のリストです。

ドキュメントルート

Apacheがこのホストにファイルを送るときに使用されるディレクトリパス。/srv/www/htdocsはデフォルトの場所です。

別名

Aliasディレクティブを使えば、URLを物理的なファイルシステムの場所にマップすることができます。このことは、パスのURLエイリアスを行えば、ファイルシステムのDocument Rootの外にあるパスでもアクセスできることを意味しています。

デフォルトのSUSE Linux Enterprise Serverでは、Alias/iconsが/usr/share/apache2/iconsを指しています。ここには、ディレクトリのインデックス表示で使用されるApacheのアイコンがあります。

ScriptAlias

Aliasディレクティブと同様に、ScriptAliasディレクティブはURLをシステム内の場所にマップします。相違点は、ScriptAliasはターゲットディレクトリをCGIの場所として指定するということです。つまり、その場所にあるCGIスクリプトが実行されます。

ディレクトリ

［ディレクトリ］設定を使用して、指定したディレクトリにのみ適用される設定オプションのグループを含めることができます。

/srv/www/htdocs、/usr/share/apache2/icons、/srv/www/cgi-binディレクトリのアクセスおよび表示オプションをここで設定します。デフォルトを変更する必要はありません。

対象項目

インクルードにより、他の設定ファイルを指定できます。2つのインクルードディレクティブが設定済みです。/etc/apache2/conf.d/は外部モジュールに付属する設定ファイルを保持するディレクトリです。このディレクティブにより、このディレクトリ内の.confで終わるすべてのファイルが対象となります。もう1つのディレクティブでは、/etc/apache2/conf.d/apache2-manual.confというapache2-manual設定ファイルが対象となります。

サーバ名

クライアントがWebサーバとコンタクトするために使うデフォルトのURLを指定します。http://FQDN/にあるWebサーバへの接続用FQDN(完全修飾ドメイン名)か、またはそのIPアドレスを使用します。ここでは任意の名前は選択できません。サーバはこの名前で「認識」されなければなりません。

Server Administrator E-Mail

サーバ管理者の電子メールアドレス。このアドレスは、Apacheが作成するエラーページなどに表示されます。

デフォルトホストのステップを完了したら、次へをクリックして、設定を続けます。

30.2.3.1.4. 仮想ホスト¶

このステップでは、ウィザードはすでに設定されている仮想ホストのリストを表示します(30.2.2.1項 「仮想ホスト設定」を参照)。YaST HTTPウィザードを起動する前に手動で変更を行っていなければ、仮想ホストは表示されません。

ホストを追加するには、追加をクリックし、サーバ名、サーバのコンテンツルート(DocumentRoot)、管理者電子メールなどホストに関する基本情報を入力するためのダイアログを開きます。サーバ解像度は、ホストの識別方法を決めるために使用されます(名前ベースまたはIPベース)。仮想ホストIDの変更で名前またはIPアドレスを指定します。

次へをクリックして、仮想ホスト設定ダイアログの2番目の部分に進みます。

仮想ホスト設定のパート2では、CGIスクリプトを有効にするかどうか、およびこれらのスクリプトを使用するディレクトリを指定できます。また、SSLも有効にできます。SSLを有効化する場合は、証明書のパスも指定する必要があります。SSLおよび証明書の詳細については、30.6.2項 「SSLサポートのあるApacheの設定」を参照してください。ディレクトリインデックスオプションを使用して、クライアントがディレクトリを要求するときに表示するファイルを指定できます(デフォルトではindex.html)。ファイルを変更する場合は、1つ以上のファイル名(スペースで区切る)を追加します。公開HTMLを有効にするで、ユーザのパブリックディレクトリ(~user/public_html/)のコンテンツが、サーバのhttp://www.example.com/~userからアクセスできるようにします。

	仮想ホストの作成
仮想ホストを自由に追加することはできません。名前ベースの仮想ホストを使用する場合は、各ホスト名がネットワーク内で解決されている必要があります。IPベースの仮想ホストを使用する場合は、使用可能な各IPアドレスに対し1つのホストのみを割り当てることができます。

30.2.3.1.5. 概要¶

これはウィザードの最後のステップです。ここでは、Apacheサーバをいつ、どのようにして起動するか(ブート時に起動するか、手動で起動するか)を指定します。また、ここまで行った設定の簡単な要約を確認します。この設定でよければ、完了をクリックして、設定を完了します。変更する場合は、希望のダイアログまで戻るをクリックして戻ります。HTTPサーバのエキスパート環境設定をクリックして、30.2.3.2項 「HTTPサーバの設定」で説明しているダイアログを開きます。

図30.2 HTTP Server Wizard:概要¶

30.2.3.2. HTTPサーバの設定¶

HTTPサーバの設定ダイアログでは、ウィザード(Webサーバを最初に設定する場合にのみ実行)よりも詳細に設定を調整できます。このダイアログは、次で説明する4つのタブで構成されています。ここで変更する設定オプションは、すぐには適用されません。変更を適用するには、常に完了をクリックして変更を確認する必要があります。中止をクリックすると、設定モジュールを終了し、変更が破棄されます。

30.2.3.2.1. 待ち受けポートおよびアドレス¶

HTTPサービスで、Apacheを実行するか(有効にする)、または停止するか(無効)を選択します。Listen on Portsで、サーバが使用可能なアドレスおよびポートについて追加、編集、または削除を選択します。デフォルトでは、ポート80ですべてのインタフェースをリスンします。常にファイアウォールでポートを開くにチェックマークを入れておく必要があります。そうしないと、外部からWebサーバにアクセスできなくなります。外部からのWebサーバへのアクセスが不要なテスト段階でのみ、ポートを閉じておくことは有用です。複数のネットワークインタフェースが存在する場合は、ファイアウォールの詳細...をクリックして、ポートを開くインタフェースを指定します。

ログファイルで、アクセスログまたはエラーログのいずれかを確認します。これは、設定をテストする場合に便利です。ログファイルは別個のウィンドウに表示されますが、そこから、Webサーバを再起動または再ロードすることも可能です。詳細については、30.3項 「Apacheの起動および停止」を参照してください。これらのコマンドはすぐに有効になり、ログメッセージもすぐに表示されます。

図30.3 HTTP Server Configuration:設定:リッスンポートとアドレス¶

30.2.3.2.2. サーバモジュール¶

状態の変更をクリックして、Apache2モジュールのステータス(有効または無効)を変更できます。すでにインストールされているがリストに含まれていない新規モジュールを追加するには、Add Moduleをクリックします。モジュールの詳細については、30.4項 「モジュールのインストール、有効化および設定」を参照してください。

図30.4 HTTP Server Configuration:サーバモジュール¶

30.2.3.2.3. メインホストまたはホスト¶

これらのダイアログは、すでに説明したものと同じです。詳細については、30.2.3.1.3項 「Default Host (デフォルトのホスト)」および30.2.3.1.4項 「仮想ホスト」を参照してください。

30.1.2項 「インストール」で説明されているデフォルトインストールを行った場合は、すべての基本モジュールと拡張モジュール、マルチプロセシングモジュール、プリフォークMPM、および外部モジュールのmod_php5とmod_pythonがすでにインストールされています。

YaSTを起動し、ソフトウェア+ソフトウェアの管理の順に選択して、その他の外部モジュールをインストールできます。フィルタ+検索の順に選択し、［apache］を検索します。他のパッケージの中で、使用可能な外部Apacheモジュールがすべて検索結果のリストに表示されます。

特定モジュールの有効化/無効化は、手動で行うか、YaSTを使用します。YaSTでは、30.2.3.1項 「HTTP Server Wizard」で説明されているモジュール設定を使用して、スクリプト言語モジュール(PHP5、Perl、およびPython)を有効または無効にする必要があります。その他のすべてのモジュールは、30.2.3.2.2項 「サーバモジュール」で説明しているように有効化または無効化できます。

手動でモジュールを有効化または無効化する場合は、a2enmod mod_fooまたはa2dismodmod_fooコマンドをそれぞれ使用します。a2enmod -lは、すべての現在アクティブなモジュールのリストを出力します。

	外部モジュール用の設定ファイルを含める
手動で外部モジュールを有効化した場合は、各設定ファイルがすべての仮想ホスト設定にロードされていることを確認します。外部モジュール用の設定ファイルは、/etc/apache2/conf.d/内に位置し、デフォルトではロードされません。各仮想ホスト上に同じモジュールが必要な場合は、このディレクトリ内の*.confを含めることができます。必要でない場合は、個々のファイルを含めます。その例として、「/etc/apache2/vhost.d/vhost.template」を参照してください。

すべての基本および拡張モジュールは、Apacheのマニュアルに詳しく説明されています。ここでは、主要なモジュールについて簡単に説明します。各モジュールの詳細については、http://httpd.apache.org/docs/2.2/mod/を参照してください。

SUSE Linux Enterprise Serverには、Apacheで使用するための2つの異なるMPM(マルチプロセシングモジュール)が用意されています。

30.4.4.1. プリフォークMPM¶

プリフォークMPMは、スレッド対応でない、プリフォークWebサーバを実装します。プリフォークMPMは、各要求を分離し、個々の子プロセスの分岐で処理するApacheバージョン 1.xと同じように、このWebサーバを動作させます。これにより、問題のあるリクエストが他のものに影響することがなくなるので、Webサーバのロックアップを避けられます。

プロセスベースのアプローチによって安定性がもたらされますが、プリフォークMPMは、もう一方のワーカーMPMよりも多くのシステムリソースを消費します。プリフォークMPMは、UnixベースのオペレーティングシステムでのデフォルトのMPMとみなされています。

	このドキュメントでのMPM
このドキュメントでは、ApacheがプリフォークMPMで使用されていることを仮定しています。

30.4.4.2. ワーカーMPM¶

ワーカーMPMは、マルチスレッド対応のWebサーバを提供します。スレッドとは、「軽い」形態のプロセスです。プロセスよりもスレッドが優れている点は、リソースの消費が少ないことです。ワーカーMPMは、子プロセスを分岐する代わりに、サーバプロセスでスレッドを使用することによってリクエストを処理します。プリフォークした子プロセスはマルチスレッドになります。このアプローチでは、プリフォークMPMの場合よりもシステムリソースの消費が少なくなるので、Apacheの性能が良くなります。

主な欠点としては、ワーカーMPMの安定性の問題が挙げられます。スレッドが壊れた場合、プロセスのすべてのスレッドに影響してしまいます。最悪の場合には、サーバがクラッシュすることがあります。特に、ApacheでCGI (Common Gateway Interface)を使用している場合、負荷が大きくなると、スレッドがシステムリソースと通信できなくなり、内部サーバエラーが生じることがあります。ワーカーMPMを使用すべきでないという意見の別の根拠は、利用できるApacheのモジュールのすべてがスレッドセーフになっているわけではなく、そのためワーカーMPMと組み合わせて使用することはできないという点です。

	MPMと組み合わせてPHPモジュールを使用する
利用可能なPHPモジュールのすべてがスレッドセーフになっているわけではありません。ワーカーMPMとmod_phpは併用しないでください。

ここでは、SUSE Linux Enterprise Serverに付属しているすべての外部モジュールのリストを示します。

上級ユーザは、カスタムのモジュールを記述してApacheを拡張することができます。Apache用のモジュールを開発したり、サードパーティのモジュールをコンパイルしたりするには、apache2-develパッケージ、および対応する開発ツールが必要です。apache2-develには、Apache用の追加モジュールのコンパイルに必要なapxs2ツールも含まれています。

apxs2は、ソースコードからモジュールをコンパイルし、インストールすることを可能にします(設定ファイルへの必要な変更も含みます)。これは、実行時にApacheにロードされる、ダイナミック共有オブジェクト (DSO)を作成します。

apxs2バイナリは、/usr/sbinの下層にあります

次のコマンドで、ソースコードからモジュールをインストールして、アクティブにします。

cd /path/to/module/source; apxs2 -cia
    mod_foo.c

ここで、-cはモジュールをコンパイルし、-iはモジュールをインストールし、-aはモジュールをアクティブにします。apxs2のその他のオプションについては、apxs2(1) manページを参照してください。

SUSE Linux Enterprise Serverでは、CGIスクリプトの実行は、/srv/www/cgi-bin/ディレクトリでのみ許可されています。この場所は、すでにCGIスクリプトを実行するように設定されています。仮想ホスト設定を作成しておらず(30.2.2.1項 「仮想ホスト設定」を参照してください)、ホスト固有のディレクトリにスクリプトを配置する場合は、このディレクトリのロックを解除し、設定する必要があります。

ScriptAlias /cgi-bin/ "/srv/www/www.example.com/cgi-bin/"

<Directory "/srv/www/www.example.com/cgi-bin/">
 Options +ExecCGI
 AddHandler cgi-script .cgi .pl
 Order allow,deny
 Allow from all
</Directory>

CGIプログラミングは通常のプログラミングとは異なり、CGIプログラムとスクリプトの前にContent-type: text/htmlなどのMIMEタイプヘッダを記述する必要があります。このヘッダはクライアントに送信されるので、クライアントは、受信したコンテンツによってコンテンツの種類を識別します。次に、このスクリプトの出力は、通常、Webブラウザなどのクライアントが認識できる形式(たいていの場合はHTML、プレーンテキスト、画像など)でなければなりません。

Apacheパッケージの一部として、/usr/share/doc/packages/apache2/test-cgi内に簡単なテストスクリプトが含まれています。このスクリプトは、いくつかの環境変数の内容をプレーンテキストとして出力します。このスクリプトを/srv/www/cgi-bin/か、仮想ホストのスクリプトディレクトリ/srv/www/example.com_cgi-bin/のいずれかにコピーし、「test.cgi」という名前を付けます。

Webサーバがアクセスできるファイルは、rootユーザが所有している必要があります。詳細については、30.7項 「セキュリティ問題の回避」を参照してください。Webサーバは別のユーザ名で実行しているので、CGIスクリプトはworld-executableおよびworld-readableである必要があります。CGIディレクトリに移動し、chmod 755 test.cgiコマンドを使用して適切なパーミッションを適用します。

次に、http://localhost/cgi-bin/test.cgiまたはhttp://www.example.com/cgi-bin/test.cgiを呼び出します。「CGI/1.0 test script report」を参照してください。

テストプログラムの出力の代わりにエラーメッセージが表示される場合は、次を確認します。

SSL/TSLをWebサーバで使用するには、SSL証明書を作成する必要があります。この証明書は、両者が互いに相手を識別できるように、Webサーバとクライアント間の認証に必要です。証明書の整合性を確認するには、すべてのユーザが信用する者によって署名される必要があります。

3種類の証明書を作成することができます。テストの目的のみの「ダミー証明書」、あらかじめ定義されている信用する一部のユーザグループ用の自己署名付き証明書、および公的な独立団体のCA (Certificate Authority)によって署名される証明書です。

証明書の作成には、基本的に2つのステップで行うことができます。はじめに、CAの秘密鍵が生成され、次に、この鍵を使用してサーバ証明書が署名されます。

	詳細情報
SSL/TSLの概念および定義の詳細については、http://httpd.apache.org/docs/2.2/ssl/ssl_intro.htmlを参照してください。

30.6.1.1. ダミー「証明書の作成」¶

ダミー証明書の生成は簡単です。/usr/bin/gensslcertスクリプトを呼び出すだけです。次のファイルを作成または上書きします。gensslcertのオプションのスイッチを使用して、証明書を微調整します。詳細は、/usr/bin/gensslcert -hを呼び出してください。

• /etc/apache2/ssl.crt/ca.crt

• /etc/apache2/ssl.crt/server.crt

• /etc/apache2/ssl.key/server.key

• /etc/apache2/ssl.csr/server.csr

• /root/.mkcert.cfg

ca.crtのコピーは、ダウンロード用に/srv/www/htdocs/CA.crtにも配置されます。

	テスト専用
ダミー証明書は、実働システム上では使用しないでください。テストの目的のみで使用してください。

30.6.1.2. 自己署名付き証明書の作成¶

イントラネットまたは定義されている一部のユーザグループ用にセキュアWebサーバをセットアップするとき、独自のCA (Certificate Authority)を通じて証明書に署名するので\'8f\'5c分な場合があります。

自己署名付き証明書の作成手順は、対話形式の9つのステップで構成されています。/usr/share/doc/packages/apache2ディレクトリに移動し、次のコマンドを実行します。/mkcert.sh make --no-print-directory /usr/bin/openssl /usr/sbin/ customこのディレクトリ以外からこのコマンドを実行しないでください。プログラムは、一連のプロンプトを表示します。この一部には、ユーザ入力が必要なものもあります。

手順30.4 mkcert.shを使用した自己署名付き証明書の作成¶

1. 証明書を使用してシグネチャアルゴリズムを決定します

   一部の古いブラウザでDSAを使用すると問題があるため、RSA (デフォルトのR)を選択します。

2. CA用RSA秘密鍵を生成(1024ビット)

   操作の必要はありません。

3. CAへのX.509証明書署名要求を生成

   ここで、CAの識別名を作成します。このとき、国名または組織名など、いくつかの質問に答える必要があります。ここで入力した内容が証明書に含まれるため、有効なデータを入力します。すべての質問に答える必要はありません。該当しない、または空白のままにする場合は、「.」を使用します。一般名は、CA自体の名前です。My company CAなど、意味のある名前を選択します。

   	CAの一般名
   CAの一般名はサーバの一般名と異なる名前にする必要があるため、この手順では完全修飾ホスト名は選択しないでください。

4. CAによる署名用のX.509証明書を生成

   証明書バージョン3を選択します(デフォルト)。

5. SERVER用のRSA秘密鍵を生成(1024ビット)

   操作の必要はありません。

6. SERVERへのX.509証明書署名要求を生成

   ここで、サーバの鍵の識別名を作成します。質問は、CAの識別名で答えたものとほぼ同じです。ここで入力するデータがWebサーバに適用されますが、CAのデータと同一である必要はありません(サーバが別の場所に位置する場合など)。

   	一般名の選択
   ここで入力する一般名は、セキュアサーバの完全修飾ホスト名(www.example.comなど)である必要があります。完全修飾ホスト名でない場合、Webサーバへのアクセス時、証明書がサーバと一致していないという警告がブラウザに表示されます。

7. 独自のCAによる署名付きX.509証明書を生成

   証明書バージョン3を選択します(デフォルト)。

8. セキュリティ用パスフレーズのあるCAのRSA秘密鍵の暗号化

   CAの秘密鍵をパスワードで暗号化することをお勧めします。そのため、Yを選択し、パスワードを入力します。

9. セキュリティ用パスフレーズのあるSERVERのRSA秘密鍵の暗号化

   秘密鍵をパスワードで暗号化すると、Webサーバを起動するたびにこのパスワードを入力するよう求められます。このため、Webサーバのブートおよび再起動時にサーバを自動的に起動するのが難しくなります。したがって、一般的に、この質問にはNと答えます。パスワードで暗号化しないと鍵は保護されないため、この鍵へのアクセスは許可されたユーザのみに限定する必要があることに注意してください。

   	サーバ鍵の暗号化
   サーバ鍵をパスワードで暗号化する場合は、/etc/sysconfig/apache2のAPACHE_TIMEOUTの値を増やします。値を増やさないと、サーバを起動しようとする試みが停止する前に、パスフレーズを入力するのに十分な時間がなくなります。

スクリプトの結果ページに、生成された鍵と証明書のリストが表示されます。スクリプトの出力とは異なり、ファイルはローカルディレクトリのconf内ではなく、適切な場所である、/etc/apache2/内に生成されます。

最後のステップとして、Webブラウザ内の認識および信用されたCAのリストに含まれるように、ユーザがアクセスできる場所に/etc/apache2/ssl.crt/ca.crtからCA証明書ファイルをコピーします。コピーしない場合、ブラウザは、この証明書が不明な認証局から発行されたものであると見なします。証明書は1年間有効です。

	自己署名付き証明書
自己署名付き証明書は、CA (Certificate Authority)として認識および信用するユーザによってアクセスされるWebサーバ上でのみ使用します。自己署名付き証明書をパブリックショップなどで使用することはお勧めしません。

Webサーバ側のSSLとTLS要求用のデフォルトのポートは 443です。ポート 80をリスンする「通常」のApacheと、ポート 443をリスンするSSL/TL対応のApacheとの間に競合は生じません。通常、ポート80とポート443への要求はそれぞれ別の仮想ホストが処理し、別の仮想サーバに送られます。

	ファイアウォール設定
ポート443でSSL対応のApache用のファイアウォールを開くことを忘れないでください。ファイアウォールは、項 「Configuring the Firewall with YaST」 (第15章 Masquerading and Firewalls, ↑Security Guide (セキュリティガイド))で説明されているように、YaSTを使用して設定できます。

SSLモジュールはグローバルサーバ設定でデフォルトで有効になっています。ホストで無効にされている場合は、コマンドa2enmod sslで有効にします。最終的にSSLを有効にするには、サーバをフラグ「SSL」で起動する必要があります。このためには、a2enflag SSLを呼び出します。サーバ証明書をパスワードで暗号化している場合は、/etc/sysconfig/apache2でAPACHE_TIMEOUTの値を増やし、Apacheの起動時にパスフレーズを入力するのに十分な時間が与えられるようにします。これらの変更を適用するため、サーバを再起動します。再ロードでは不十分です。

仮想ホスト設定ディレクトリには、SSL固有ディレクティブが詳細に記述されている/etc/apache2/vhosts.d/vhost-ssl.templateテンプレートが含まれています。一般的な仮想ホスト設定については、30.2.2.1項 「仮想ホスト設定」を参照してください。

始めるには、テンプレートを/etc/apache2/vhosts.d/mySSL-host.confにコピーして編集します。次のディレクティブの値を調整するだけです。

30.6.2.1. 名前ベースの仮想ホストとSSL¶

IPアドレスが1つだけのサーバで、複数のSSL対応の仮想ホストを実行することはできません。名前ベースの仮想ホスティングでは、要求されたサーバ名をApacheが知っている必要があります。SSL接続の問題は、SSL接続が(デフォルトの仮想ホストの使用により)確立された後でのみ、そのような要求の読み込みが可能なことです。その結果、証明書がサーバ名に一致しないという警告メッセージが表示されます。

SUSE Linux Enterprise Serverは、SNI (Server Name Indication)と呼ばれるSSLプロトコルの拡張を組み込んでおり、仮想ドメインの名前をSSLネゴシエーションの一部として送信することで、この問題を解決します。これにより、サーバが正しい仮想ドメインに早く「切り替わり」、ブラウザに正しい証明書を提示することが可能になります。

SUSE Linux Enterprise Serverでは、デフォルトでSNIが有効になっています。名前ベースの仮想ホストをSSLで使用可能にするには、30.2.2.1.1項 「名前ベースの仮想ホスト」で説明されているようにサーバを設定します (ただし、SSLでは、ポート80ではなく、ポート443を使用)。

SNIブラウザのサポート

SNIは、クライアント側でもサポートされる必要があります。SNIは、ほとんどのブラウザでサポートされていますが、モバイルハードウェアの一部のブラウザやWindows* XP上のInternet ExplorerとSafariにはSNIのサポートがありません。詳細については、http://en.wikipedia.org/wiki/Server_Name_Indicationを参照してください。 ディレクティブSSLStrictSNIVHostCheckを使用して、SNIに非対応のブラウザを処理する方法を設定しますSNI非対応ブラウザは、サーバ設定でonに設定されると、すべての仮想ホストに関して拒否されます。VirtualHostディレクティブ内でonに設定されると、この特定のホストへのアクセスが拒否されます。 サーバ設定でoffに設定されると、サーバはSNIサポートがないかのように動作します。SSL要求は、(ポート443に対して)定義された最初の仮想ホストによって処理されます。

Apacheソフトウェアに脆弱性が見つかると、SUSEからセキュリティ上の勧告が出されます。これには、脆弱性を修正するための指示が含まれているので、可能な限り早期の適用が必要です。SUSEセキュリティ通知は、次の場所から入手できます。

SUSE Linux Enterprise Serverのデフォルトでは、DocumentRootディレクトリの/srv/www/htdocsおよびCGIディレクトリの/srv/www/cgi-binは、ユーザおよびグループrootに属します。これらのパーミッションは変更しないでください。ディレクトリにすべてのユーザが書き込み可能な場合、どのユーザもそれらのディレクトリにファイルを格納できます。その後これらのファイルは、Apacheによりwwwrunのパーミッションで実行されます。その結果、意図しない仕方で、ユーザがファイルシステムのリソースにアクセスできるようになる可能性があります。/srv/wwwのサブディレクトリを使用して仮想ホストのDocumentRootおよびCGIディレクトリを配置し、このユーザおよびグループのrootがディレクトリとファイルの所有者であることを確認します。

デフォルトでは、ファイルシステム全体へのアクセスは、/etc/apache2/httpd.confで定義されています。これらのディレクティブは決して上書きしないでください。ただし、Apacheが読み込む必要のあるすべてのディレクトリに対するアクセスは有効にしてください。詳細については、30.2.2.1.3項 「基本的な仮想ホスト設定」を参照してください。このためには、パスワードまたはシステム設定ファイルなど重要なファイルは外部から読み取ることができないことを確認します。

Perl、PHP、SSIまたは他のプログラミング言語によるインタラクティブなスクリプトは、事実上、任意のコマンドを実行できるため、一般的なセキュリティの問題が存在します。サーバから実行されるスクリプトは、サーバの管理者が信用するソースからのみインストールされる必要があります。一般的には、ユーザが独自のスクリプトを実行できる環境は適切ではありません。また、すべてのスクリプトに対してセキュリティ監査を行うこともお勧めします。

スクリプトの管理をできるだけ簡単にするため、CGIスクリプトの実行をグローバルに許可するのではなく、通常、特定のディレクトリに制限されています。設定には、ディレクティブのScriptAliasおよびOption ExecCGIが使用されます。SUSE Linux Enterprise Serverのデフォルト設定では、任意の場所からのCGIスクリプトの実行は許可されません。

すべてのCGIスクリプトは同一のユーザとして実行するため、異なるスクリプトが互いに競合する可能性があります。suEXECモジュールは、CGIスクリプトを別のユーザとグループで実行できるようにします。

ユーザディレクトリを(mod_userdirまたはmod_rewriteを使用して)有効化する場合は、 .htaccessファイルを許可しないことをお勧めします。これらのファイルは、ユーザによるセキュリティ設定の上書きを可能にするからです。AllowOverRideディレクティブを使用して、少なくとも、ユーザの操作を制限する必要があります。SUSE Linux Enterprise Serverでは、.htaccessファイルはデフォルトで有効化されていますが、ユーザはmod_userdirの使用時にいずれのOptionディレクティブも上書きできません(詳細は、/etc/apache2/mod_userdir.conf 設定ファイル参照)。

Apache 2.2の新機能のリストは、http://httpd.apache.org/docs/2.2/new_features_2_2.htmlを参照してください。バージョン2.0から2.2へのアップグレード情報もhttp://httpd.apache.org/docs-2.2/upgrading.htmlで参照できます。

30.4.5項 「外部モジュール」で簡単に説明されている外部Apacheモジュールの詳細は、次の場所で入手できます。

Apacheモジュールの開発、またはApache Webサーバプロジェクトへの参加に関する情報については、次を参照してください。

SUSE Linux Enterprise ServerのApacheに固有な問題が発生した場合は、Technical Information Search (http://www.novell.com/support)を参照してください。Apacheの沿革は、http://httpd.apache.org/ABOUT_APACHE.htmlで参照できます。このページでは、Apacheというサーバ名の由来についても説明しています。