mod_includeを使えば、データをクライアントに送る前に、ファイルを処理することができます。典型的には、mod_includeはドキュメントにファイルをインクルードするために用いられます。それからこれらは、クライアントに届けられる前にHTMLとして解析されます。そのためこれは、サーバ側のインクルード(SSI)と呼ばれます。

SSIを使えば、書式設定されたSGMLコメントでトリガされる、特別なコマンドをサーバ側で実行できます。これらのSGMLコマンドの構文は次のとおりです。

<!--#element attribute=value --> 

elementおよびattribute値のリストは、http://httpd.apache.org/docs-2.0/mod/mod_include.htmlのmod_includeのドキュメントを参照してください。

SUSE Linuxでmod_includeを使用するには、/etc/sysconfig/apache2のAPACHE_MODULESにincludeを追加するか、モジュールで説明されているようにYaSTを使用してください。

	ティップ
Apacheに、SSIディレクティブ用にexecuteビットが設定されたファイルを解析させるには、XBitHackディレクティブ(http://httpd.apache.org/docs-2.0/mod/mod_include.html#xbithack)を使用します。 これは、SSI要素を持つものとしてマークするためにファイルの拡張子を変更する代わりに(上の例の.shtml、通常の.htmlファイルを使用して、chmod +x myfile.htmlを実行することを意味します。

mod_cgiを使えば、Apacheに、外部のCGI ("Common Gateway Interface")プログラムまたはスクリプトで作成されたコンテンツを配信させることができます。これは、物理マシンで利用可能なプログラミング言語と、Apach Webサーバの間の仲立ちとしての役割を果たします。CGIスクリプトは、理論的にはどのプログラム言語でも作成できます。通常は、PerlやCなどの言語が用いられます。 mod_cgiは、Webサイトに動的なコンテンツを含めるための、最も一般的な方法です。

CGIプログラミングは、HTMLの出力を生成するために、CGIプログラムやスクリプトがContent-type: text/html MIMEタイプを生成できるようになっている必要があるという点で、「通常の」プログラミングとは異なります。

#!/path/to/perl
print "Content-type:text/html\n\n";
print "Hello, World."; 

1つのプログラミング言語と明確に結び付けられたモジュール(mod_php5など)と、mod_cgiの間の違いは、mod_cgiはmod_suexec (項46.5.2.1. 「mod_suexecによってCGIを別ユーザとして実行する 」参照)と組み合わせることができる、という点にあります。このように組み合わせると、CGIスクリプトを特定のユーザIDで実行することができます。通常、mod_cgiだけ、またはmod_php5を使用するスクリプトは、Apacheユーザ(SUSE Linuxでのデフォルトは wwwrun)のユーザIDで実行されます。プログラミング言語用に設計されたモジュール(mod_php5やmod_rubyなど)は、スクリプトをApacheユーザのIDで実行するための、固定的なインタプリタをApacheに埋め込みます。

こうして、mod_suexecとCGIを組み合わせると、CGIプロセスを、Webサーバ自体の代わりに、個々のユーザに割り当てることができるので、管理がしやすくなります。また、この組み合わせによって、ファイルシステムのセキュリティも向上します。スクリプトは、ユーザのファイルシステムに対する権限だけを継承するからです。一方、モジュールの場合には、スクリプトはWebサーバユーザのファイルに対する権限を与えられるので、ファイルシステムのデータが意図しない仕方で見えてしまうことがあります。

CGIは、クライアントからWebサーバへのリクエストが終わると、終了します。これは、CGIが永続的なものではなく、終了後には占有していたすべてのリソースを解放することを意味しています。これは利点であり、特にプログラミングにエラーが含まれている場合にそう言えます。モジュールの場合は、インタプリタが固定なので、プログラミングエラーの影響が累積されます。そのため、データベース接続など、リソースを解放しないでしまうことがあり、Apacheの再起動が必要になることがあります。

SUSE Linuxでmod_cgiを使用するには、/etc/sysconfig/apache2のAPACHE_MODULESにcgiを追加するか、モジュールで説明されているようにYaSTを使用してください。SUSE LinuxでのCGIのデフォルトのディレクトリは、/srv/www/cgi-bin/です。

Apache設定ファイルを手動で編集する場合には、以下の例を、mod_cgiを設定するためのガイドラインとして用いてください。

# Global Environment
LoadModule cgi_module /path/to/mod_cgi.so

# Main Server and/or Virtual Host and/or
# Directory and/or .htaccess context
AddHandler cgi-script .cgi .pl

# Main Server and/or Virtual Host context
ScriptAlias /cgi-bin/ /srv/www/cgi-bin/

# Alternatively, explicitly allow CGI scripts in a directory
# Main Server and/or Virtual Host context
<Directory /srv/www/some/dir> 
	Options +ExecCGI
<Directory> 

mod_suexecとmod_cgi (項46.5.1.2. 「CGI (Common Gateway Interface)mod_cgi 」)を組み合わせれば、 CGIスクリプトを指定したユーザおよびグループとして実行できます。そのためには、/usr/sbin/suexec2の、suEXECプログラムを使います。これは、CGIスクリプトまたはプログラムが実行されるたびにApacheから呼び出されるラッパーです。それから、ラッパーとプログラムの両方が、設定されたユーザおよびグループIDを取得します。その結果、設定されたユーザまたはグループとして実行されます。

このアプローチは、ユーザが生成するCGIスクリプトに関連したセキュリティリスクをかなりの程度小さくしますが、以下のように、考慮しておくべき重要な点もあります。

mod_suexecによってエラーが生じた場合には、suexecのログファイル、/var/log/apache2/suexec.logを参照してください。

SUSE Linuxでmod_suexecを使用するには、/etc/sysconfig/apache2のAPACHE_MODULESにsuexecを追加するか、モジュールで説明されているようにYaSTを使用してください。suexecを実行するにはmod_cgiが必要であることに注意してください。

mod_suexecは、項46.4. 「仮想ホスト」で説明するように、仮想ホスト環境に適用した場合に最も役立ちます。CGIスクリプトを実行する特定のユーザまたはグループを指定するには、仮想ホストの宣言を含んでいるファイル内で(SUSE Linuxでのデフォルトは/etc/apache2/vhosts.d/*です)、以下の構文を使用してください。

<VirtualHost 192.168.0>
# ..
ScriptAlias /cgi-bin/ /srv/www/vhosts/www.example.com/cgi-bin/
SuexecUserGroup tux users
# ..
</VirtualHost> 

この例のSuexecUserGroup username groupという構文は、/srv/www/vhosts/www.example.com/cgi-bin/内のすべてのスクリプトに、tuxのユーザID、そしてusersのグループIDを割り当てます。

mod_sslは、クライアントとWebサーバ間のHTTP通信に、SSL (secure sockets layer)およびTLS (transport layer security)プロトコルを使用する、強力な暗号化を提供します。この目的で、サーバは、URLに対するリクエストに応答する前に、サーバの有効な識別情報を含むSSL証明書を送ります。これにより、サーバが唯一の正当な通信相手であることが保証されます。加えて、この証明書は、クライアントとサーバの間の暗号化された通信が、重要な内容がプレーンテキストとして見られる危険なしに、情報を転送できることを保証します。Apacheでmod_sslを使用する場合の最もはっきりした影響は、URLのプレフィックスがhttp://ではなくhttps://となることです。

Webサーバ側でのSSLおよびTLSリクエストのデフォルトのポートは443です。ポート80をリスンする「通常の」Apacheと、ポート443をリスンするSSL/TLS対応のApacheの間で競合が生じることはありません。実際、HTTPとHTTPSを同一のApacheインスタンスで実行することは可能です。通常、ポート80へのリクエストは1台の仮想ホスト(項46.4. 「仮想ホスト」参照)が処理し、ポート443へのリクエストは別の仮想サーバに送られます。

	名前ベースの仮想ホストとSSL
IPアドレスが1つだけの1台のサーバで、複数のSSL対応の仮想ホストを実行することはできません。そのような構成のサーバに接続するユーザは、URLを訪問するたびに、証明書がサーバ名と一致しないという警告メッセージを受け取ることになります。有効なSSL証明書に基づいて通信を行うには、SSL対応のドメインごとに、個別のIPアドレスまたはポートが必要です。 警告メッセージが出されても、有効なSSLサイトと同じレベルの暗号化を利用することはできます。このことは、警告メッセージを受け入れる限り、Webサーバとクライアントの間の通信はセキュアであることを意味しています。ただし、有効なSSL証明書によって保証される、サーバの実体を個別に識別するというコンセプトは、失われます。

SUSE Linuxでmod_sslを有効にするには、/etc/sysconfig/apache2のAPACHE_MODULESにsslを追加するか、モジュールで説明されているようにYaSTを使用してください。さらに、標準のHTTPSポート443をリスンするようにWebサーバを構成する必要もあります。 これは、/etc/apache2/listen.confで手動で行うか、YaSTの［‘Listen’］メニュー項目で行います(Network Device Selection (ネットワークデバイスの選択)参照)。

テスト用のSSL証明書は、rootとしてcd /usr/share/doc/packages/apache2; ./certificate.shを入力すれば、作成できます。画面に表示される指示に従って、SSL証明書を構築してください。作成された証明書ファイルは、/etc/apache2/ssl*ディレクトリに置かれます。

グローバルに有効な「実際の」証明書は、Thawte (http://www.thawte.com/)やVerisign (www.verisign.com)などのベンダーから入手できます。

Apache設定ファイルを手動で編集する場合には、以下の例を、mod_sslを設定するためのガイドラインとして用いてください。

# Global Environment
# listen on the standard SSL port
Listen 443
# load module only if rcapache2 start-ssl was issued
<IfDefine SSL>
LoadModule ssl_module /path/to/mod_ssl.so
</IfDefine>

# Main Server context
# include global (server-wide) SSL configuration
# that is not specific to any virtual host
# only if ssl_module was loaded
<IfModule mod_ssl.c>
Include /etc/apache2/ssl-global.conf
</IfModule> 

	ティップ
SSL対応のApache用に、ファイアウォールのポート443を開くのを忘れないでください。これは、YaSTの ‘[セキュリティとユーザ]’+‘[ファイアウォール]’+‘[Allowed Services]’で行えます。 to the list of ［‘Allowed Services’］のリストに［‘HTTPS Server’］を追加してください。

mod_perlは、Apacheに固定的なPerlインタプリタを埋め込みます。これにより、CGIに対するリクエストがあるたびに外部の実行可能ファイルを呼び出すmod_cgiによるオーバーヘッドを避けられます。 mod_perlはさらに、Apacheの機能の様々な面を、Perlプログラミング言語によって制御することを可能にします。

SUSE Linuxでmod_perlを使用するには、apache2-mod_perl RPMをインストールして、モジュールをYaST (モジュール)で、または/etc/sysconfig/apache2で手動で有効にします。インストールして有効にすると、個別の設定ファイル、mod_perl.confが/etc/apache2/conf.d/に置かれます。さらに、mod_perlの起動スクリプトがmod_perl-startup.plとしてインストールされます。モジュールの使用方法についての詳細は、mod_perlのWebサイト(http://perl.apache.org/)で入手できるドキュメントを参照してください。

PHPは、元々Webで使用するために開発された、人気のあるプログラミング言語です。PHP4とPHP5という、2つのバージョンがあります。PHP4は、PHPのクラシックなコンセプトとアプローチを示していますが、PHP5は、新しいオブジェクト指向のプログラミングの可能性と、他の多くの先進的な機能を導入しました。SUSE Linuxでは、mod_php4とmod_php5が両方とも使用できます。これらは、ApacheにPHPインタプリタを永続的なモジュールとして埋め込みます。

SUSE Linuxでmod_php4またはmod_php5を使用するには、それぞれのRPMを (apache2-mod_php4、apache2-mod_php5)インストールして、モジュールをYaST (モジュール)で、または/etc/sysconfig/apache2で手動で有効にします。

インストールして有効にすると、それぞれのモジュールに対応した個別の設定ファイル(php4.confまたはphp5.conf)が/etc/apache2/conf.d/に置かれます。PHPのWebサイト(http://www.php.net)は、ApacheとPHPを使用するための優れたリソースです。

mod_pythonは、ApacheにPythonインタプリタを埋め込みます。Pythonは、非常に明快で読みやすい構文を持つ、オブジェクト指向プログラミング言語です。一風変わった、しかし便利な特徴は、プログラムの構造が、beginやendのような通常の区切り要素の代わりに、ソースコードのインデントに基づいているというものです。

SUSE Linuxでmod_pythonを使用するには、apache2-mod_python RPMをインストールして、モジュールをYaST (モジュール)で、または/etc/sysconfig/apache2で手動で有効にします。モジュールの使用方法についての詳細は、mod_pythonのWebサイト(http://www.modpython.org/)で入手できるドキュメントを参照してください。

mod_rubyは、Apache WebサーバにRubyインタプリタを埋め込み、RubyのCGIスクリプトをネイティブに実行することを可能にします。Rubyは、比較的新しいオブジェクト指向の高レベルプログラミング言語で、PerlやPythonと似た側面を持っています。Pythonと同様、明快で透明性の高い構文を持ちます。一方、Rubyでは入力ファイルの最終行の番号を$.rで表すなどの省略記法が採用されており、この特徴はプログラマによって賛否両論です。Rubyの基本コンセプトは、Smalltalkに非常によく似ています。

SUSE Linuxでmod_rubyを使用するには、apache2-mod_ruby RPMをインストールして、モジュールをYaST (モジュール)で、または/etc/sysconfig/apache2で手動で有効にします。モジュールの使用方法についての詳細は、mod_rubyのWebサイト(http://www.modruby.net/en/index.rbx)で入手できるドキュメントを参照してください。

mod_davは、ApacheにWebDAV (Webベースの分散オーサリングおよびバージョニング)機能を追加します。WebDAVは、HTTPプロトコルの拡張で、ユーザがリモートのサーバ上のファイルを共同して編集し、管理することを可能にします。WebDAVの機能はFTPと似ていますが、主な違いは、サーバのアクセスの基礎となるプロトコルとしてHTTPが用いられるということです。mod_davは、事実上、Apache Webサーバを高度なリモートファイルシステムに変えます。

WebDAVでアクセスできるディレクトリを制限するのは、必要なことではありませんが、良い習慣です。最低限の注意事項は、WebDAVのリソース用にHTTPの基本的な認証をセットアップすることと、Locationディレクティブ内でLimit節を使用することです。

WebDAVのリソースにアクセスするには、クライアント側にWebDAV対応のソフトウェアが必要です。SUSE LinuxにはすでにWebDAV用の機能が備わっています。Konquerorでプレフィックスwebdav://またはwebdavs:// (SSL接続でのWebDAVの場合)を使用すれば、Apache WebDAVファイルシステムにアクセスできます。

mod_davはmod_dav_fsモジュールを必要とします。これは、WebDAV用に実際のファイルシステムへのアクセスを提供します。lSUSE Linuxでmod_davを使用するには、モジュールをYaST (モジュール)で、または/etc/sysconfig/apache2で手動で有効にします。mod_dav_fsについても同じようにします。モジュールの使用方法についての詳細は、mod_davのWebサイト(http://httpd.apache.org/docs-2.0/mod/mod_dav.html)で入手できるドキュメントを参照してください。

SUSE Linuxのmod_userdirは、デフォルトで、各ユーザの~/public_htmlフォルダの内容をパブリックなWebページとして公開します。これらのページにアクセスするためのURLは、http://www.example.com/~username/となります。

	ティップ
SUSE Linuxのmod_userdirは、rootユーザのホームディレクトリへのアクセスは、セキュリティ上の理由で禁止しています。加えて、以下の構文を使用すれば、特定のユーザのパブリックホームページへのアクセスだけを明示的に許可することができます。 # Main server context UserDir disabled UserDir enabled tux wilber

SUSE Linuxでmod_userdirを使用するには、モジュールをYaST (モジュール)で、または/etc/sysconfig/apache2で手動で有効にします。モジュールの使用方法についての詳細は、mod_userdirのWebサイト(http://httpd.apache.org/docs-2.0/mod/mod_userdir.html)で入手できるドキュメントを参照してください。

mod_rewriteはよく、「URL操作のスイスアーミーナイフ」に例えられます。これは、リクエストされたURLを、指定されたルールセットに従って、オンザフライで書き換えます。その結果、http://www.example.com/2/1/deがhttp://www.example.com/display.php?cat=2&article=1&lang=deのようになります。

URL Rewriting Guideでは、この強力ながら複雑なモジュールの長所と短所について説明しています。

「mod_rewriteについては、最初でつまづいて二度と使わないことにするか、そのパワーのために大いに気に入るかの、 どちらかになるでしょう。」

RewriteRuleは、メインサーバ、仮想ホスト、ディレクトリ、.htaccessファイルなどのために、設定コンテキストのどこででも設定できます。mod_rewriteでURLを書き換えるための良い出発点となるのは、 http://httpd.apache.org/docs-2.0/misc/rewriteguide.htmlのURL Rewriting Guideです。

SUSE Linuxでmod_rewriteを使用するには、モジュールをYaST (モジュール)で、または/etc/sysconfig/apache2で手動で有効にします。