株式会社ロジステック株式会社ロジステック

By logistech

Virtual Host サポート

Virtual Host サポート

関連事項:
Non-IP based virtual hosts

バーチャルホストとは?

たとえばあるインターネットサービスプロバイダが、smallcobaygroup というそれぞれ異なった組織のためにWebスペースを供給する www.serve.com という名のマシンを持っていると仮定します。普通はこれらのグループには www.serve.com のWebツリー上の一部が割り当てられます。結果、smallcoのホームページは次のようなURLになるでしょうし

http://www.serve.com/smallco/

また、baygroupのホームページは次のようなURLになります。

http://www.serve.com/baygroup/

しかし、美的感覚からいえば、両組織とも自分達のホームページがサービスプロバイダの名前の後ろにくっついたかたちになって呼出されるより独自の名前で呼出される方がいいでしょう。;ところが彼ら組織は、インターネット接続やサーバのセットアップを自分達ではしたくありません。

バーチャルホストはこの問題への解決策です。smallco と baygroup は、それぞれ
www.smallco.comwww.baygroup.orgという独自の
インターネットに登録した名前を持っているとします。これらのホスト名は両方とも
サービスプロバイダのマシン(www.serve.com)に対応しています。
これで、smallcoのホームページは今、次のURLになり、

http://www.smallco.com/

そして、baygroupはのホームページは、次のURLになります。

http://www.baygroup.org/

必要なシステム

HTTP/1.0プロトコルの制限で、WEBサーバーは各々のバーチャルホストに対して唯一のIPアドレスを持たなければなりません。それには、マシンが複数の物理的なネットワークコネクションを持つか、または、いくつかのOS上で実現されている仮想インターフェース(virtual interface)を使用すれば可能です。

Apacheのセットアップのしかた

マルチホストをサポートするためにApacheを構成する方法は2つあります。
1つは各々のホスト用に別個のhttpdデーモンを走らせる方法、もう一つはすべてのバーチャルホストをサポートする1個のデーモンを走らせる方法です。

マルチデーモンを使うとき:

  • 異なるバーチャルホスト間では、httpdの構成がかなり違います。たとえば、
    ServerType,
    User,
    Group,
    TypesConfig または
    ServerRoot
    の値がそれぞれ違うというように。

  • マシンのリクエスト処理はあまり多くはありません。

シングルデーモンを使うとき:

  • バーチャルホスト間でhttpdの構成が共有されます。
  • マシンは多くのリクエストに対応することになり、そして、動作している個々のデーモンでのパフォーマンスのロスが重要になります。

マルチデーモンのセットアップ

各々のバーチャルホストごとに別個のhttpdをインストール。
個々のインストレーションでは、デーモンがどのIPアドレス(またはバーチャルホスト)に対しサービスするかを決めるためのバインドアドレス(BindAddress)指定をコンフィグレーションファイルの中で設定します。

例.

BindAddress www.smallco.com

このホスト名はまたIPアドレスの代わりにもなります。

シングルデーモンのセットアップ

このケースの場合、一つのhttpdがすべてのバーチャルホストのリクエストに応えます。
コンフィグレーションファイルの中でのバーチャルホスト(VirtualHost)の指定は、
ServerAdmin,
ServerName,
DocumentRoot,
ErrorLog
TransferLog 構成の値を個々のバーチャルホストに対応した値にセットするために使用されます。

例.


<VirtualHost www.smallco.com>
ServerAdmin webmaster@mail.smallco.com
DocumentRoot /groups/smallco/www
ServerName www.smallco.com
ErrorLog /groups/smallco/logs/error_log
TransferLog /groups/smallco/logs/access_log
</VirtualHost>

<VirtualHost www.baygroup.org>
ServerAdmin webmaster@mail.baygroup.org
DocumentRoot /groups/baygroup/www
ServerName www.baygroup.org
ErrorLog /groups/baygroup/logs/error_log
TransferLog /groups/baygroup/logs/access_log
</VirtualHost>

このバーチャルホスト名はまたIPアドレスの代わりにもなります。


ServerType,
User,
Group,
StartServers,
MaxSpareServers,
MinSpareServers,
MaxRequestsPerChild,
BindAddress,
PidFile,
TypesConfig
ServerRoot
を除いて、ほとんどのコンフィグレーション指定をバーチャルホスト設定欄に書けます。

セキュリティ: どこにログファイルを書くかを記述するときは、もしもApacheをスタートさせたユーザー以外のだれかが、それらが書かれたディレクトリへの書き込みアクセスを行ったときに表出するいくつかのセキュリティ上の危険に注意すべきです。
詳細はセキュリティ情報(security tips)を見てください。

ファイルハンドル/リソース制限:


多くの数のバーチャルホストを使用するとき、もし各々のバーチャルホストが異なったログファイル記述すればApacheは有効なファイルディスクリプタを使い果たします。Apacheで使用されるファイル記述子の総数は、それぞれ異なったエラーログファイルごとに1つとすべての他のログファイル指定のための1つに加え、プラス内部用に使用される10-20個です。Unixオペレーティングシステムはプロセスで使用されるであろうファイル記述子の数を制限しています。制限は通常64個、一般的にはその数を増やすのはハードによる制限にかかってくるでしょう。

Apacheは要求時に制限数を増やすことを試みますが、次の場合にはそのようには働きません。:

  1. あなたのシステムがsetrlimit()システムコールを備えていない場合。
  2. setrlimit(RLIMIT_NOFILE)コールがあなたのシステム上で機能しない場合(Solaris 2.3のように)
  3. ファイルディスクリプタの要求数がハードの制限を超えた場合。
  4. あなたのシステムがファイルディスクリプタ上の他の制限を設けた場合。たとえば、スタンダードI/O上でのファイルディスクリプタの使用を256個以下に制限した場合のように。

問題発生時への対処:

  • ログファイルの数を減少させる; メインログファイルのログを除いてバーチャルホストの欄にログファイルを記述しない。
  • もしあなたのシステムが上記の1または2に該当する場合は、Apacheをスタートさせる前にファイルディスクリプタの制限を大きくする。
    次のようなスクリプトを使って、


    #!/bin/sh
    ulimit -S -n 100
    exec httpd

Apacheがルートプロセス用に割り当てられたリソースを使い果たし始めるという報告があります。これは “unable to fork”のようにエラーログの中でそれ自身をエラーとして見せます。これを引き上げる方法が2つあります。:


  1. httpdのまわりのcshスクリプトラッパーで”rlimit” を 512のような大きい数にセットします。
  2. http_main.c を main()からsetrlimit()を呼出しするように修正します。rlimit構造体の間に

    struct rlimit rlp;

    rlp.rlim_cur = rlp.rlim_max = 512;
    if (setrlimit(RLIMIT_NPROC, &rlp)) {
    fprintf(stderr, “setrlimit(RLIMIT_NPROC) failed.\n”);
    exit(1);
    }


    (“Aaron Gifford <agifford@InfoWest.COM>” のパッチに感謝します。)

後者はおそらくApacheの今後のバージョンでクリアになるでしょう。


By logistech

Apache Virtual Host 訳文(かなり古いです)

Apache non-IP Virtual Hosts

See Also:
Virtual Host Support


バーチャルホストとは

“Virtual Host”とは、1つのマシン上で複数のサーバーを外見上のホスト名によって区別されたものとして管理することを言います。 たとえば、ユーザーが余分なディレクトリパスを知る必要がないwww.company1.comwww.company2.comのようなかたちでアクセスできる自社のドメインを持つために、1つのwebサーバーを複数の会社で共有することがしばしば望まれます。

Apacheはその苦境を脱して適切にバーチャルホストをサポートした最初のサーバーの1つです。
しかし、基本になるHTTP(HyperText Transport Protocol)基準が、サーバーがホスト名で指定された場合にホスト名を決定するどのような方法も許可していない以上 、Apacheのバーチャルホストサポートは各々のサーバーのために個別のIPアドレスが必要でした。この手法(依然としてうまく機能している)を使用する場合においての資料は入手可能です。

だが一方で、利用できるIPアドレス空間が小さくなってきていることやドメインの数が増え続けていることから、上記の文書に記述されているアプローチはもっともエレガントな解決策ではないし、いくつかのマシン上では実現が困難です。HTTP/1.1プロトコルはサーバーが自分自身が呼ばれる名前が何なのかを認識する方法を持っています。
Apache 1.1およびそれ以降のものは伝統的な”ホスト名ごとのIPアドレス”という方法と同様にうまくこの手法をサポートしています。

新しいバーチャルホストサポートを使う利点は事実上サーバーの数に制限がないこと、設定と使用の容易さ、ハードウェアーとソフトウェアの追加がいらないことです。 主な不都合点はユーザーのブラウザがプロトコルのこの部分をサポートしていなければならないことです。 多くのブラウザ(Netscape Navigator2.0 とそれ以降のものも含む)の最新バージョンでは対応していますが、逆に、特に古いブラウザの場合が多いのですが対応していないブラウザも多数あります。これは問題を引き起こしますが、1つの解決策を後述しています。

non-IP Virtual Hostsを使うには

新しいバーチャルホストを使用するのはきわめて簡単で、表面上は古い方法と同じように見えます。 単純にApacheファイルのコンフィグレーションファイル(たいていhttpd.confsrm.conf)の1つに次のようなコードを付け加えます。:

    <VirtualHost www.apache.org>
    ServerName www.apache.org
    DocumentRoot /usr/web/apache
    </VirtualHost>

もちろん、他の指定も<VirtualHost>のセクションに追加することができます(また追加すべきです)。この作業を行うために確認しておかなければならないことは、www.apache.orgのDNSのエントリーポイントがメインサーバーのIPアドレスと同一であるということだけです。任意に、簡単に<VirtualHost>エントリーの中にIPアドレスを使用できるでしょう。

さらに、多数のサーバーが1つ以上の名前でアクセス可能になってもよい。たとえば、Apacheのサーバーがapache.orgでもftp.apache.orgでもアクセスされるようにしてもよいし、複数のIPアドレスが同一のサーバを差すようにしてもよい。実際、apache.orgにあるすべてのアドレスがサーバーによってピックアップされるようになっています。これは<VirtualHost>セクションに置いたサーバーエイリアス(ServerAlias)の指定で可能です。たとえば:

    ServerAlias apache.org *.apache.org

注) ワイルドカードの *, ? が使用できます。

いつもはドメイン名を含まないローカルユーザーのサーバーになるときにも、同様にサーバーエイリアスを必要とするかもしれません。 たとえば、もし、ローカルユーザーが”www” または “www.physics”とタイプすることに慣れ親しんでいたら、ServerAlias www www.physics を追加する必要があるでしょう。サーバーはそれらの名前解決のためにクライアントが使用するドメインが何なのかを知ることは不可能です。
なぜならクライアントはリクエストの中にその情報を入れていませんから。

セキュリティに関する考察

Apacheはすべてのバーチャルホストが、Host:ヘッダー(すべてのIPインターフェースを通過した)経由でアクセス可能になることを許します。それらが異なったIPインターフェースを使用するために構成されている場合にでもです。
たとえば、もしwww.foo.comのための設定の中にwww.bar.comのためのバーチャルホスト項が含まれており、かつ、www.bar.comが別個のIPインターフェースであれば、このような場合non-Host:-header-supporting browsers(Host: ヘッダーをサポートしていないブラウザ)はApache 1.0以前の場合のようにそれを使えます。。もしwww.foo.comへのリクエストが作成され、そしてそのリクエストがヘッダーHost: www.bar.com を含んでいる場合には、www.bar.comからのページが送られるでしょう。

これは、もしファイアーウォールまたはルーターの内部からのようなIP-layerコントロールをもとにした特殊なサーバーへのアクセスをコントロールしている場合には、セキュリティ上心配です。仮に、上述した例のwww.bar.comprivate.foo.comと呼ばれているイントラネットサーバー の代わりだったとすると、
foo.com に使用されているルーターは内部のユーザーにprivate.foo.comだけをアクセスさせます。Host:private.foo.comヘッダーを送った場合には、明らかに、Host:ヘッダー機能は、www.foo.comにアクセスしただれかにprivate.foo.comを捕らまえることを許しています。もしIP layerで、この方針を構築するためだけにこの条件が存在するだけなら、Apacheによって使用されるすべてのセキュリティコントロール(すなわち, allow, deny from, etc.)が一貫して期待されということに注意するのは大切です。

古いブラウザとの互換性

最初に言及したように、大半のブラウザは新しいバーチャルホストが正しく機能するために必要としているデータを送りません。 これらのブラウザは、いつもサーバーのメインページへ送られるでしょう。 逃げ道(予備システム)はありますが、いささか扱いにくいです。:

www.apache.orgの例を続けるのに(注:Apacheのwebサーバーは実際この方法では機能していません)私たちは新しいServerPath指定をwww.apache.orgのバーチャルホスト内で使うでしょう、次の例のように:

    ServerPath /apache

これは何を意味するのでしょうか? これは”/apache“で始まるどんなファイルのためのリクエストでもApacheのドキュメントのなかで捜せるだろうという意味です。これはつまり、そのページがすべてのブラウザにとってhttp://www.apache.org/apache/としてアクセス可能ということです。けれども新しいブラウザはまたそれをhttp://www.apache.org/としてもアクセスできます。

この働きを作るために、あなたのメインサーバーのページ上にhttp://www.apache.org/apache/へのリンクを置き、(注意:http://www.apache.org/は使ってはいけません – これはエンドレスループを招きます)
それから、virtual hostのページの中で、完全に関連づけられたリンク(e.g. “file.html” または “../icons/image.gif“)を使うか、/apache/で始まるリンク(e.g. “http://www.apache.org/apache/file.html” or
/apache/docs/1.1/index.html“)を使うかを確定します。

これにはちょっとした訓練が必要です。しかし、これらのガイドラインを守ることはたいていの場面において全てのブラウザ(古くても新しくても)であなたのページがうまく動作するのを保証するでしょう。新しいブラウザがhttp://www.apache.org/を呼出したときには、それらは直接アパッチのページに接続されるでしょう。古いブラウザはメインサーバーからリンク上のクリックによって、http://www.apache.org/apache/へ飛び、そしてそのページにアクセスするでしょう。