37 Apache HTTPサーバ #

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

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

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

Apacheをターゲットmulti-user.targetおよびgraphical.targetでブート時に自動的に起動するには、次のコマンドを実行します。

tux > sudo systemctl enable apache2

SUSE Linux Enterprise Serverのsystemdターゲットの詳細、およびYaSTサービスマネージャの詳細については、15.4項 「YaSTを使用したサービスの管理」を参照してください。

シェルを使用してApacheを手動で起動するには、systemctl start apache2コマンドを実行します。

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ユーザとしてプレーンテキストの設定ファイルを編集する必要があります。

37.2.2.1 仮想ホスト設定 #

 

仮想ホストという用語は、同じ物理マシンから複数のURI (universal resource identifiers)のサービスを行えるApacheの機能を指しています。これは、www.example.comとwww.example.netのような複数のドメインを、1台の物理マシン上の単一のWebサーバで保持できることを意味しています。

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

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

仮想ホストを設定するには、YaSTを使用するか(37.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.4/mod/quickreference.htmlを参照してください。

37.2.2.1.1 名前ベースの仮想ホスト #

 

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

最初のステップは、サービスを提供する、名前ベースの異なるホストそれぞれに対して<VirtualHost>ブロックを作成することです。各<VirtualHost>ブロック内には、少なくとも、サービスの提供対象ホストを指定するServerNameディレクティブと、ファイルシステム内でそのホストのコンテンツが存在する場所を示すDocumentRootディレクティブが必要です。

例 37.1: 名前ベースのVirtualHostエントリの基本例 #

 

<VirtualHost *:80>
# This first-listed virtual host is also the default for *:80
ServerName www.example.com
ServerAlias example.com
DocumentRoot /srv/www/htdocs/domain
</VirtualHost>

<VirtualHost *:80>
ServerName other.example.com
DocumentRoot /srv/www/htdocs/otherdomain
</VirtualHost>

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

ワイルドカード*をIPアドレスの代わりに使用することもできます。IPv6アドレスを使用する場合には、アドレスを角括弧の中に記述することが必要です。

例 37.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>

37.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で2つのドメインをホストしています。すべての仮想サーバについて、VirtualHostブロックが個別に必要です。

例 37.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)内のディレクティブが適用されます。

37.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">
  Require all granted
</Directory>

注記: Require all granted

Apacheの以前のバージョンでは、Require all granted文を次のように表記していました。

Order allow,deny
Allow from all

この古い構文は、現在もmod_access_compatモジュールでサポートされています。

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

例 37.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">
  Require all granted
  </Directory>
</VirtualHost>

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

37.2.3.1 HTTP Server Wizard #

 

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

37.2.3.1.1 Network Device Selection (ネットワークデバイスの選択) #

 

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

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

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

37.2.3.1.2 モジュール #

 

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

37.2.3.1.3 Default Host (デフォルトのホスト) #

 

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

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

図 37.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が作成するエラーページなどに表示されます。

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

37.2.3.1.4 仮想ホスト #

 

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

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

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

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

重要: 仮想ホストの作成

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

37.2.3.1.5 概要 #

 

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

図 37.2: HTTP Server Wizard:概要 #

 

37.2.3.2 HTTPサーバの設定 #

 

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

37.2.3.2.1 待ち受けポートおよびアドレス #

 

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

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

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

 

37.2.3.2.2 サーバモジュール #

 

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

図 37.4: HTTP Server Configuration:サーバモジュール #

 

37.2.3.2.3 メインホストまたはホスト #

 

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

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

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

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

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

重要: 外部モジュール用の設定ファイルを含める

手動で外部モジュールを有効化した場合は、各設定ファイルがすべての仮想ホスト設定にロードされていることを確認します。外部モジュール用の設定ファイルは、/etc/apache2/conf.d/内に存在し、デフォルトで/etc/apache2/default-server.confにロードされます。より詳細に制御するには、外部モジュール用の設定ファイルがインクルードされないよう/etc/apache2/default-server.confでコメントアウトして、特定の仮想ホストに対してのみファイルを追加することができます。その例として、/etc/apache2/vhosts.d/vhost.templateを参照してください。

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

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

37.4.4.1 プリフォークMPM #

 

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

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

重要: このドキュメントでのMPM

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

37.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の下層にあります

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

tux > sudo cd /path/to/module/source
tux > sudo apxs2 -cia MODULE.c

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

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

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

<Directory "/srv/www/www.example.com/cgi-bin/">
 Options +ExecCGI2
 AddHandler cgi-script .cgi .pl3
 Require all granted4
</Directory>

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

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

Webサーバがアクセスできるファイルは、rootユーザが所有している必要があります。詳細については、37.8項 「セキュリティ問題の回避」を参照してください。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」を参照してください。

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

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

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

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

ヒント: 詳細情報

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

37.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

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

重要: テスト専用

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

37.6.1.2 自己署名付き証明書の作成 #

 

イントラネットまたは定義されている一部のユーザグループ用にセキュアWebサーバをセットアップするときは、多くの場合、独自の認証局(CA)を通じて証明書に署名すれば十分です。Webブラウザは自己署名付き証明書を認識できないため、このようなサイトの訪問者には「これは信頼できないサイトです」という警告が表示されます。

重要: 自己署名付き証明書

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

まず、証明書署名要求(CSR)を生成する必要があります。opensslと、証明書の書式としてPEMを使用します。このステップでは、パスフレーズを入力し、いくつかの質問に回答するよう求められます。入力したパスフレーズは後で必要になるため、覚えておいてください。

tux > sudo openssl req -new > new.cert.csr
Generating a 1024 bit RSA private key
..++++++
.........++++++
writing new private key to 'privkey.pem'
Enter PEM pass phrase:1
Verifying - Enter PEM pass phrase:2
-----
You are about to be asked to enter information that will be incorporated
into your certificate request.
What you are about to enter is what is called a Distinguished Name or a DN.
There are quite a few fields but you can leave some blank
For some fields there will be a default value,
If you enter '.', the field will be left blank.
-----
Country Name (2 letter code) [AU]:3
State or Province Name (full name) [Some-State]:4
Locality Name (eg, city) []:5
Organization Name (eg, company) [Internet Widgits Pty Ltd]:6
Organizational Unit Name (eg, section) []:7
Common Name (for example server FQDN, or YOUR name) []:8
Email Address []:9

Please enter the following 'extra' attributes
to be sent with your certificate request
A challenge password []:10
An optional company name []:11

1	パスフレーズを入力し、
2	...もう一度入力します(パスフレーズを覚えてください)。
3	2文字の国コードを入力します(GBやCZなど)。
4	住所のある都道府県の名前を入力します。
5	都市名を入力します(Pragueなど)。
6	勤務先の組織の名前を入力します。
7	組織部門を入力します。組織部門がない場合は空白のままにします。
8	サーバのドメイン名または自分の氏名を入力します。
9	勤務先の電子メールアドレスを入力します。
10	チャレンジパスワードは空白のままにします。入力した場合は、Apache Webサーバを再起動するたびにチャレンジパスワードを入力する必要があります。
11	オプションの会社名を入力するか、空白のままにします。

これで証明書を生成できます。もう一度opensslを使用します。証明書の形式はデフォルトのPEMです。

手順 37.3: 証明書を生成する #

 

1. 鍵の秘密部分をnew.cert.keyにエクスポートします。証明書署名要求(CSR)の作成時に入力したパスフレーズを入力するようプロンプトが表示されます。

   tux > sudo openssl rsa -in privkey.pem -out new.cert.key

2. 署名要求に入力した情報に従って、証明書の公開部分を生成します。-daysオプションで、証明書が期限切れになるまでの期間を指定します。証明書を取り消すことも、期限切れになる前に置き換えることもできます。

   tux > sudo openssl x509 -in new.cert.csr -out new.cert.cert -req \
   -signkey new.cert.key -days 365

3. 関連するディレクトリに証明書ファイルをコピーし、Apacheサーバが読み込めるようにします。秘密鍵/etc/apache2/ssl.key/server.keyを全ユーザに対して読み込み可能にせずに、公開PEM証明書を/etc/apache2/ssl.crt/server.crt全ユーザに対して読み込み可能にします。

   tux > sudo cp new.cert.cert /etc/apache2/ssl.crt/server.crt
   tux > sudo cp new.cert.key /etc/apache2/ssl.key/server.key

ヒント: パブリック証明書の場所

最後のステップとして、パブリック証明書ファイルを/etc/apache2/ssl.crt/server.crtからユーザがアクセスできる場所にコピーして、Webブラウザの、既知の信頼されたCAのリストにそのファイルを組み込めるようにします。コピーしない場合、ブラウザは、この証明書が不明な認証局から発行されたものであると見なします。

tux > openssl req -new -newkey rsa:2048 -nodes -keyout newkey.pem -out newreq.pem

Webサーバ側のTLS/SSL要求のデフォルトのポートは、443です。ポート80での「通常の」Apacheリスニングと、ポート443でのTLS/SSL対応のApacheリスニングとの間に競合は発生しません。実際、HTTPとHTTPSは同じApacheインスタンスで実行できます。通常、ポート80とポート443への要求はそれぞれ別の仮想ホストが処理し、別の仮想サーバに送られます。

重要: ファイアウォール設定

ポート443でSSL対応のApacheのファイアウォールを開くことを忘れないでください。これは、Section 23.4.3, “Configuring the Firewall on the Command Line”で説明されているようにfirewalldを使用して行うことができます。

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

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

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

37.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で使用できるようにするには、37.2.2.1.1項 「名前ベースの仮想ホスト」で説明しているようにサーバを設定します(ただし、SSLでは、ポート80ではなく、ポート443を使用)。

重要: SNIブラウザのサポート

SNIは、クライアント側でもサポートされる必要があります。ただし、SNIは、一部の旧式のブラウザを除き、ほとんどのブラウザでサポートされています。詳細については、https://en.wikipedia.org/wiki/Server_Name_Indication#Supportを参照してください。

SNI非対応ブラウザの処理を設定するには、ディレクティブSSLStrictSNIVHostCheckを使用します。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が読み込む必要のあるすべてのディレクトリに対するアクセスは有効にしてください。詳細については、37.2.2.1.3項 「基本的な仮想ホスト設定」を参照してください。このためには、パスワードまたはシステム設定ファイルなど重要なファイルは外部から読み取ることができないことを確認します。

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.4の新機能のリストについては、http://httpd.apache.org/docs/2.4/new_features_2_4.htmlを参照してください。バージョン2.2から2.4へのアップグレード情報もhttp://httpd.apache.org/docs-2.4/upgrading.htmlで参照できます。

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

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

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