このページではLinux上でApache/httpdを使ってWebサーバー構築するために必要なバーチャルホストの設定について解説します。
お便利サーバー.com+相互リンクサイト内をキーワードで検索
Webサーバーの構築

Webサーバーについて

Apacheの構成と設定の準備

全般的な動作環境の設定

コンテナディレクティブの形式

コンテナディレクティブの設定

ドキュメントルートの設定等

ユーザーディレクトリの設定

バーチャルホストの設定

CGIの実行許可の設定

ユーザー認証機能の設定

httpdのコントロール

httpdの動作チェック

ポートフォワーディングの設定


ネームバーチャルホストとは

Apache におけるバーチャルホストとは、ひとつの サーバー で複数の FQDN に対する コンテンツ を同時に配信する機能をいいます。

例えば現在構築中の Webサーバー は、 "ServerName" ディレクティブ ServerNameディレクティブについて で、 クライアント から

"http://www.obenri.com/"

でアクセスしてもらえるように設定を行っているはずです。

しかし実際の HTTP 接続は、 "www.obenri.com" の正引きの 名前解決 結果の IPアドレス である "192.168.100.11" を接続先の ノード 情報として行われます。

従って、同じ"192.168.100.11"に名前解決される 、

"obenri.com"
"web1.obenri.com"
"mail.obenri.com"

というそれぞれの FQDN ベースとした URL

"http://obenri.com/"
"http://web1.obenri.com/"
"http://mail.obenri.com/"

でアクセスを行っても、 コンテンツに配信に関する識別情報がIPアドレスのみであるとすれば 、Apacheはすべて "http://www.obenri.com/" と同じコンテンツをクライアントに送信することになります。

同じ理由から、例えば別の ドメイン名 "ugegege.com" も自分で運用していて、同じIPアドレス"192.168.100.11"へ名前解決されるFQDNが設定されていれば、

"http://www.ugegege.com/"

でも同じことになります。

しかし、ここで httpd の持つ バーチャルホスト 機能を用いると、同じIPアドレス宛のリクエストであっても、FQDNごとに異なるコンテンツを送信することが可能になります。

その仕組みは至って簡単です。

実際にクライアントがHTTPでWebサーバーにリクエストを行うときは、 Webブラウザ はhttpdに対して HTTPヘッダ と呼ばれる情報を送信します。

HTTPヘッダには、HTTPのバージョン情報や送受信形式、優先言語 MultiViewsオプションによる言語選択 などの情報の他に、接続先のFQDN情報も含まれています。

バーチャルホストの利用が有効になっているhttpdは、自分宛に送られてきたリクエストの中にFQDN情報が含まれている場合、例えば、

1.HTTPヘッダのFQDN情報が"www.obenri.com"ならば"/var/www/html"をドキュメントルートとしてコンテンツを送信する。

2.HTTPヘッダのFQDN情報が"obenri.com"ならば"/var/www/obenri"をドキュメントルートとしてコンテンツを送信する。

3.HTTPヘッダのFQDN情報と一致するドキュメントルートの設定が存在しない場合は、逆引きの名前解決結果か"ServerName" ディレクティブ ServerNameディレクティブの設定について の設定に基づいてURLを求め、該当するコンテンツを送信する。

という手順で、送信するコンテンツを振り分けることになります。

古いWebブラウザの一部ではHTTPヘッダにFQDN情報が添付されないものがありますので、こういうWebブラウザからは「ネームバーチャルホスト」を利用することはできません。しかし、そういったWebブラウザは現在ではほとんど使われていませんので、まず問題になることはないでしょう。

このように、「一つのIPアドレスを指し示す複数のFQDNからのリクエストに対して、異なるコンテンツを送信する。」というバーチャルホスト機能は、一般に 「名前ベースのバーチャルホスト」 、あるいは 「ネームバーチャルホスト」 と呼ばれます。

ネームバーチャルホストは、httpdが受け持つIPアドレス(ここでは192.168.100.11)に名前解決されるFQDNであれば、 ドメイン名 は何でもかまいませんから、 "*.obenri.com" だけではなく、その他の任意のドメイン名を用いたFQDNも一緒に運用することができます。

なお、バーチャルホストにはこれとは別に、 「IPアドレスベースのバーチャルホスト」 、あるいは 「IPバーチャルホスト」 と呼ばれる方法があります。

これは、「一台の ホスト機 に複数のIPアドレスを設定し、FQDNごとに違うIPアドレスを割り当ててそれぞれのコンテンツを送信する。」という方法です。もちろんhttpdはこれも扱うことが可能です。

ただこの方法を行うには、バーチャルホストとして利用したいFQDNの数だけIPアドレスが必要になります。

実質的にはいくつでも使用可能な プライベートIPアドレス ならばともかくとして、通常のインターネット接続契約では、自宅の WAN 空間側に割り当てられる グローバルIPアドレス は非固定または固定の一個にすぎませんから インターネット接続契約について 、現在構築中のネットワークシステムでIPバーチャルホストを運用しても、事実上は LAN 内でしかその恩恵を受けられないということになります。

これでは何の面白みもないでしょう。

従ってこのコンテンツでは、IPバーチャルホストについては説明を割愛しますのでご了承ください。

このページの先頭へ↑

名前解決環境の整備

バーチャルホスト は、 "/etc/httpd/conf/httpd.conf" に対して ディレクティブ を記述して設定を行いますが、その前に DNS の環境を整えておく必要があります。

WAN 空間に公開する コンテンツ でバーチャルホストを利用する場合、バーチャルホストに用いる FQDN ダイナミックDNS 名前解決 ができるように設定しておく必要があります。

LAN 内の名前解決を hostsファイル で賄っている場合は、各ホスト機に設置しているhostsファイルに対して名前解決を追加しておく必要があります。

構築中のLinuxサーバー BIND を稼動させ、LAN内のホスト機から DNSサーバー として利用しているときは named の正引きのゾーンファイルに ホスト名 を追加します。

以下、FQDNを追加設定する例として "info.obenri.com" を用いて設定の説明を行います。

ダイナミックDNSへのFQDNの追加

FQDN の追加の方法は ダイナミックDNS の運営サイトによって様々ですが、大抵は運営サイトの管理メニューから「 ホスト名 の変更、追加」 あるいは「 DNS 情報の変更」 などを選んで設定します。あまり難しい作業ではないはずです。

例えば、本サイトで利用させてもらっている 私的DynamicDNS(MyDNS.JP) DDNSの設定例について(WBEL3) DDNSの設定例について(CentOS3) DDNSの設定例について(WBEL4) DDNSの設定例について(CentOS4) DDNSの設定例について(CentOS5) の場合、 "DOMAIN INFO" メニューから該当する設定ページを開いて新しいホスト名を追加するだけです。

これらのコマンドを実行する ホスト機 の参照 DNSサーバー として 構築中のLinuxサーバー が指定されているときは、必ずWAN空間のDNSサーバー(自分が契約している ISP のDNSサーバーが適当です。) を指定してください。

設定を行ってから実際に WAN 空間に情報が反映されるまで通常は数分から数十分かかりますので、しばらく待ってから ping nslookup などの コマンド 名前解決 の動作をチェックしてみてください。

hostsファイルへのFQDNの追加

LAN 内での 構築中のLinuxサーバー に関する FQDN 情報を、各 ホスト機 への hostsファイル の設置で賄っている場合は、それぞれのホスト機のhostsファイルを開いて追加記述を行ってください。

例えば WindowsOS の場合は、以下のように設定することになります。

info.obenri.comをhostsファイルに追加(WindowsOS)
"info.obenri.com"をhostsファイルに追加(WindowsOS)

他の OS の場合も同様に、 hostsファイルの編集と設定について を参考にしてFQDNの追加設定を行ってください。

BINDへのFQDNの追加

LAN 内に自宅の サブネット 用の DNSサーバー 構築中のLinuxサーバー に設置し、稼動させている場合は DNSサーバーの構築について 、ゾーン名 "obenri.com" に対する正引きのゾーンファイル "/var/named/obenri.com.zone" obenri.com.zoneの設定について ホスト名 "info" を追加します。

$TTL 86400
@    IN   SOA   web1   tanaka (
        2005111401   ; Serial
        3H       ; Refresh
        15M       ; Retry
        1W       ; Expire
        1D )      ; Minimum

            IN   NS   web1
            IN   MX   10   mail
            IN   A    192.168.100.11
router         IN   A    192.168.100.1
web1          IN   A    192.168.100.11
mail          IN   A    192.168.100.11
www           IN   A    192.168.100.11
info          IN   A    192.168.100.11

設定を追加したら、忘れずに named の再起動 namedのコントロール を行ってください。

このページの先頭へ↑

"NameVirtualHost"〜利用の宣言

これから以降の説明は、 "/etc/httpd/conf/httpd.conf" に対する設定を記述することになります。

この ディレクティブ WBEL3 及び CentOS3 では 1024行目 、WBEL4及びCentOS4では 1003行目 、CentOS5では 972行目 あたりに記述があります。

httpd でネーム バーチャルホスト を利用するには、 "NameVirtualHost" ディレクティブ で、その利用宣言を記述する必要があります。

デフォルト では、

#NameVirtualHost *:80

と、一般書式でコメントアウトされています。

これを以下のように書き換えます。

NameVirtualHost 192.168.100.11:80

この記述により、

IPアドレス "192.168.100.11"の ポート番号 80番へのリクエストに対して、ネームバーチャルホストとして動作する。」

と宣言されることになります。

ポート番号については、 "Listen" ディレクティブ Listenディレクティブの設定について で許可されているものだけが使用できます。

通常 WBEL CentOS 上のhttpdには セキュアWebサーバー 用に SSL のモジュールが組み込まれていて、 https Well-Knownポート である 443 番も受信可能になっていますから、間違いのないようにポート番号80はきちんと記述しておきましょう。

個々のバーチャルホストの設定は、この宣言の後に行っていくわけですが、ひとつ大きな注意点があります。

それは、この"NameVirtualHost"ディレクティブを有効にして、実際にバーチャルホストの設定を一つでも行うと、元々 "DocumentRoot" ディレクティブ DocumentRootディレクティブについて で設定されているディレクトリは、 クライアント からの HTTP リクエストからの応答を受け付けなくなるということです。

つまり、現在のドキュメントルートのから送信されている コンテンツ をそのまま生かそうと思う場合には、

「メインコンテンツもバーチャルホストの一つとして動作させる。」

という設定が必要になることを覚えておいてください。

このページの先頭へ↑

バーチャルホストコンテナの設定

バーチャルホスト は、コンテナ形式の ディレクティブ コンテナ形式ディレクティブについて で記述します。

バーチャルホスト形式のコンテナの一般書式は、 WBEL3 及び CentOS3 では 1032行目〜 、WBEL4及びCentOS4では 1016行目〜 、CentOS5では 985行目 あたりに記述があります。内容は、

#<VirtualHost *>
#  ServerAdmin webmaster@dummy-host.example.com
#  DocumentRoot /www/docs/dummy-host.example.com
#  ServerName dummy-host.example.com
#  ErrorLog logs/dummy-host.example.com-error_log
#  CustomLog logs/dummy-host.example.com-access_log common
#</VirtualHost>

のとおりです。

バーチャルホストコンテナは、設置するバーチャルホストの数だけ記述する必要がありますので、このテンプレートを直接書き換えてしまうよりも、このテンプレートは残したまま新たにコンテナごと書き加えるほうが良いでしょう。

以下に、 "http://www.obenri.com/ "http://info.obenri.com/ を同時にネームバーチャルホストで運用する場合の設定例を示します。

#www.obenri.com #info.obenri.com は、説明用に見出しとして勝手に付けたコメントです。不要なら書かなくても構いません。
#www.obenri.com
<VirtualHost 192.168.100.11>
  ServerAdmin tanaka@obenri.com
  DocumentRoot /var/www/html
  ServerName www.obenri.com
  ErrorLog logs/www.obenri.com-error_log
  CustomLog logs/www.obenri.com-access_log combined
</VirtualHost>

#info.obenri.com
<VirtualHost 192.168.100.11>
  ServerAdmin suzuki@obenri.com
  DocumentRoot /home/suzuki/public_html
  ServerName info.obenri.com
  ErrorLog logs/info.obenri.com-error_log
  CustomLog logs/info.obenri.com-access_log combined
</VirtualHost>

以下に、バーチャルホストコンテナと、その中に記述するディレクティブについて説明します。

<VirtualHost ...>〜応答するIPアドレスの指定

単純に、

<VirtualHost [応答する IPアドレス ]:[ ポート番号 ]>

と、

</VirtualHost>

で記述します。

[応答するIPアドレス]には、 構築中のLinuxサーバー のIPアドレスを記述します。ポート番号の部分は既に "NameVirtualHost" ディレクティブ で、

NameVirtualHost 192.168.100.11:80

と、 80 番の使用が宣言されていますので、ここでは省略して構いません。

ServerAdmin〜サーバー管理者の連絡先

「全体的な動作環境の設定」で行った "ServerAdmin" ディレクティブ ServerAdminディレクティブについて と、意味は全く同じです。

この記述を実際に クライアント Webブラウザ に表示するかどうかは、メインコンテンツに行った同じ設定と同様に、 "ServerSignature" ディレクティブ ServerSignatureディレクティブについて の設定に依存します。

DocumentRoot〜コンテンツの格納場所

「全体的な動作環境の設定」で行った "DocumentRoot" ディレクティブ DocumentRootディレクティブについて と、意味は全く同じです。

"#www.obenri.com" の設定は、元のドキュメントルートをそのまま引き継ぎますから、指定するディレクトリは同じく "/var/www/html" と設定します。

一方の "#info.obenri.com" の設定には、 ユーザーディレクトリの設定 ユーザーディレクトリの設定 で、 コンテンツ スペースを割り当てた ユーザーアカウント "suzuki" の公開ディレクトリである、 "/home/suzuki/public_html" をドキュメントルートとして指定しています。

これによって、クライアントから

"http://www.obenri.com/~suzuki/"

とリクエストされた場合と全く同じコンテンツが、

"http://info.obenri.com/"

でというリクエストで送信可能になる訳です( URL の指定は次の "SeverName" ディレクティブで行います)。

バーチャルホストの動作はユーザーディレクトリの公開設定とは無関係ですから、ユーザーディレクトリの使用を無効に設定して、

"http://www.obenri.com/~suzuki/"

によるアクセスができなくなっても、

"http://info.obenri.com/"

では問題なくコンテンツが表示されます。

ServerName〜リクエストに応えるFQDN

クライアント から送られてくる HTTPヘッダ に対応する FQDN を記述します。

この記述によって、 "#www.obenri.com" 及び "#info.obenri.com" は、それぞれ、

"http://www.obenri.com/"

"http://info.obenri.com/"

というリクエストに応えて動作するようになります。

ErrorLog〜エラーログのファイル名

「全体的な動作環境の設定」で行った "ErrorLog" ディレクティブ ErrorLogディレクティブについて と、意味は全く同じです。

"NameVirtualHost" ディレクティブでネーム バーチャルホスト の利用を宣言すると、"DocumentRoot"ディレクティブと同様に、「全体的な動作環境の設定」で行った"ErrorLog"ディレクティブの設定は無効になりますので、ここで改めて指定することになります。

エラーログファイル名の名前のつけ方には特に決まりはありませんが、後々バーチャルホストを増やしてゆく可能性を見越して、「どのバーチャルホストのエラーログなのか」ということがわかり易いように名前を付けましょう。

CustomLog〜アクセスログのファイル名

「全体的な動作環境の設定」で行った "CustomLog" ディレクティブ CustomLogディレクティブについて と、意味は全く同じです。

"NameVirtualHost" ディレクティブでネーム バーチャルホスト の利用を宣言すると、"DocumentRoot"ディレクティブと同様に、「全体的な動作環境の設定」で行った"CustomLog"ディレクティブの設定は無効になりますので、ここで改めて指定することになります。

アクセスログファイル名の名前のつけ方には特に決まりはありませんが、後々バーチャルホストを増やしてゆく可能性を見越して、「どのバーチャルホストのアクセスログなのか」ということがわかり易いように名前を付けましょう。

また、ログファイルの出力形式は、テンプレートでは"common"になっていますが、これは CustomLogディレクティブについて を参考に適宜設定してください。

このページの先頭へ↑

バーチャルホストに用いるディレクトリの設定

コンテンツ の配信が バーチャルホスト で行われる場合でも、アクセス制御などに関する設定は、該当するコンテナ式ディレクティブ コンテナ式ディレクティブについて の設定に従います。

つまり現時点では、バーチャルホスト "#www.obenri.com" については、 "/var/www/html" に関するディレクトリコンテナの設定 ディレクトリ/var/www/htmlに関するコンテナ設定 が適用されます。

また同様に "#info.obenri.com" については、ユーザーディレクトリに関するディレクトリコンテナの設定 ユーザーディレクトリに関するコンテナ設定 が適用されます。

もちろん、それぞれに設定上問題がなければそのままでも構いませんが、バーチャルホストのコンテナに関する記述と、それに該当するディレクトリコンテナの記述が "/etc/httpd/conf/httpd.conf" 上の離れた位置にあると、設定が解りにくくなってしまいます。

そこで、バーチャルホストを設置する場合は、例えば、

#www.obenri.com
<VirtualHost 192.168.100.11>
  ServerAdmin tanaka@obenri.com
  DocumentRoot /var/www/html
  ServerName www.obenri.com
  ErrorLog logs/www.obenri.com-error_log
  CustomLog logs/www.obenri.com-access_log combined
</VirtualHost>
<Directory /var/www/html>
  Options FollowSymLinks
  AllowOverride None
  Order allow,deny
  Allow from all
</Directory>

#info.obenri.com
<VirtualHost 192.168.100.11>
  ServerAdmin tanaka@obenri.com
  DocumentRoot /home/suzuki/public_html
  ServerName info.obenri.com
  ErrorLog logs/info.obenri.com-error_log
  CustomLog logs/info.obenri.com-access_log combined
</VirtualHost>
<Directory /home/suzuki/public_html>
  AllowOverride None
  Options SymLinksIfOwnerMatch
  <Limit GET POST OPTIONS>
    Order allow,deny
    Allow from all
  </Limit>
  <LimitExcept GET POST OPTIONS>
    Order deny,allow
    Deny from all
  </LimitExcept>
</Directory>

のようにまとめて記述してしまうことをお勧めします。

また、 "obenri.com" 以外の ドメイン名 を利用する場合も記述方法に変わりはありません。例えば、

#www.ugegege.com
<VirtualHost 192.168.100.11>
  ServerAdmin tanaka@obenri.com
  DocumentRoot /home/yamada/public_html
  ServerName www.ugegege.com
  ErrorLog logs/www.ugegege.com-error_log
  CustomLog logs/www.ugegege.com-access_log combined
</VirtualHost>
<Directory /home/yamada/public_html>
  AllowOverride None
  Options SymLinksIfOwnerMatch
  <Limit GET POST OPTIONS>
    Order allow,deny
    Allow from all
  </Limit>
  <LimitExcept GET POST OPTIONS>
    Order deny,allow
    Deny from all
  </LimitExcept>
</Directory>

と追加記述すれば、 "/home/yamada/public_html" 以下のコンテンツは "http://www.ugegege.com/" でアクセスしたときに配信されるようになります。

通常バーチャルホストは"/etc/httpd/conf/httpd.conf"の一番最後に記述しますから、前に記述されている元々のディレクトリコンテナの設定は無視されます コンテナ式ディレクティブの参照優先順位について 。従って、元の設定はそのまま残しておいても構いません。

バーチャルホストというと、普通は「一つのホスト上に仮想的に複数のホストを実現する手段。」のように解説されますから、「なんとなく意味が解らないし、ちょっと難しそう。」という印象を受けがちです。

しかしながらここで説明したとおり、 名前解決 の仕組みさえ理解できていれば案外簡単に設置できますし、管理はむしろ易しくなります。またバーチャルホストの設置によって普遍的に サーバー の動作負荷が増えるということもありません。

というわけですから、「バーチャルホストは難しそうだから」と敬遠せずに、むしろ積極的に利用することをお勧めします。

このサイトは リンクフリー です。趣味や勉強のためでしたら、引用、転用、コピー、朗読、その他OKです。このサイトへのリンクについては こちら をご覧ください。今のところ更新予定はありませんのでご了承ください。
”Linux”は、Linus Torvalds 氏の各国における登録商標です。”Red Hat”及びRed Hatのロゴおよび Red Hat をベースとしたすべての商標とロゴは、各国におけるRed Hat, Inc. 社の商標または登録商標です。その他のプログラム名、システム名、製品名などは各メーカー、ベンダの各国における登録商標又は商標です。