まだプログラマーですが何か?

プログラマーネタとアスリートネタ中心。たまに作成したウェブサービス関連の話も http://twitter.com/dotnsf

タグ:httpd

この記事の続きです:


IBM LinuxONE コミュニティクラウド上に作った仮想サーバーにいわゆる "LAMP"(=Linux + Apache HTTPD + MySQL + PHP) 環境を構築してみます。まずは上記記事を参考に仮想サーバーを作り、SSH でリモートログインします:
2017010403


ミドルウェアの導入作業を伴うため、ルート権限を持ったユーザーにスイッチしておきます:
$ sudo /bin/bash
#


LAMP 環境に必要なミドルウェアや言語環境をまとめて導入します(赤字はコメント):
# yum install httpd -y (Apache HTTP サーバー)
# yum install mysql-server mysql -y (MySQL)
# yum install php php-mbstring php-mysql php-gd php-pear php-xml php-devel -y (PHP)

また以下は LAMP 環境構築においては必須ではありませんが、使うことも多いというか、あると便利だと思うので必要に応じて導入しておいてください:
# yum install screen -y (screen)
# yum install git -y (git)
# yum install java-1.8.0-ibm-devel -y (JDK 1.8)

ミドルウェアを起動する前にファイアウォールの設定を行います。デフォルトの LinuxONE では iptables によるファイアウォールが有効になっており、このままでは http(s) によるアクセスができません。今回の環境では iptables を無効にしておきましょう:
# /etc/init.d/iptables stop
# chkconfig iptables off

あらためて各ミドルウェアを起動し、また自動起動設定をしておきます:
# /etc/init.d/httpd start
# /etc/init.d/httpd mysqld
# chkconfig httpd on
# chkconfig mysqld on
# exit
$

この時点で Apache HTTP サーバーが動いています。iptables の解除が成功していれば http://(IPアドレス)/ にアクセスすることができるようになっているはずです:
2017010601


さて、MySQL に関しては root のパスワードを設定しておきましょう。この例では P@ssw0rd というパスワードにしていますが、ここは必要に応じて変えてください:
$ mysql -u root

mysql> set password for root@localhost=PASSWORD('P@ssw0rd');
mysql> exit

これで LinuxONE 上でも LAMP の環境が作れました! ちなみに PHP のバージョンは 5.3.3 が導入できます:
$ php -v
PHP 5.3.3 (cli) (built: Dec 15 2015 04:50:47)
Copyright (c) 1997-2010 The PHP Group
Zend Engine v2.3.0, Copyright (c) 1998-2010 Zend Technologies

前回の続きです:
Bluemix のビルドパックを作る(1/3)


このシリーズは3回に分けて IBM Bluemix 用のビルドパックをゼロから作成する手順を説明するもので、今回はその2回目です:
(1) ビルドパックを作る上で知っておくべきこと
(2) ビルドパックを作るための準備作業      ←今回はここ
(3) ビルドパックを作成して、実際に動作確認


前回は、ビルドパックを作成する上で知っておくべき仕組みや制限事項についてをまとめました。おおまかには次のような仕組み/条件でビルドパックを作ります:
- ビルドパック自体は detect, compile, release の3つのスクリプトからなる。
- これら3つのスクリプトは一般ユーザー権限で実行される。su や sudo は使えない。
- 素の Ubuntu Linux に対して、これら3つのスクリプトが実行された後に必要な環境が整っているようにする。

今回と次回の2回に分けて、実際にビルドパックをゼロから作成します。正確には実際にビルドパックそのものを作る手順は次回紹介しますが、今回はそのための準備作業を紹介します。具体的には実際にビルドパックを作るスクリプトは一般ユーザー権限でしか実行できないため、ビルドなどの root 権限が必要な作業はあらかじめ(Ubuntu 環境下で)済ませておく必要があります。そのための作業の説明を今回のブログエントリの中で紹介します。

また、今回作成するビルドパックの内容は「比較的緩めな日本語対応 PHP アプリケーションサーバーを作る」こととします。具体的には以下の様なスペック PHP アプリケーションサーバーのビルドパックを作ります:
・ PHP 5.6.14
・ Apache HTTPD 2.4.16
・ PHP の MySQL モジュールと Postgresql モジュールを追加
・ PHP の設定は日本語 UTF-8 ベースで、エラー発生時のエラー内容を出力、ファイルアップロードは1ファイル10MB まで許可、・・・などなど php.ini を緩めに設定
・ Apache HTTPD も .htaccess での設定上書きを許可するなど、ゆるゆるにする

簡単にいえば「php.ini と httpd.conf を緩めに設定するような環境で PHP のビルドパックを作成する」ということです。


では本エントリでの作業に入ります。まずは 64bit の Ubuntu Linux 14.02 環境を用意します。デスクトップ環境は必須ではありません。SSH 等でログインしてターミナル上での操作ができれば大丈夫です:
2015100900



この Ubuntu の中に PHP と Apache HTTPD 環境を構築していきます。といっても、ただインストールすればいいというわけではありません。インストールだけなら "sudo apt-get install php5 apache2 libapache2-mod-php5" とかを実行すればいいのですが、これは sudo が使える前提での話です。上記のようにビルドパック作成時の権限は sudo の使えないユーザー権限なので、この apt-get による簡単なインストール方法は使えないのです。

ではどうするか? その答は (2) まず Ubuntu 内で必要なモジュールを、ソースからのコンパイルなど全て手作業で作り、 (3) 作ったモジュールを tar などでまとめておき、ビルドパック作成時は一般ユーザーが展開してコピーすればよい、という状態にしておく 必要があるのでした。要は root 権限が必要な部分((2))と、不要な部分((3))に作業を分断し、ビルドパック作成時は root がなくてもできる作業だけを行います。そしてそのような作業だけで済むように、root 権限が必要な作業は(ビルドパック作成作業の前)あらかじめ済ませてまとめておく、という作業を行うようにします。これが全体作業でいうところの (2) と (3) を分けた理由でもあります。

では、あらためて今回行う作業の内容をまとめておきます:
(2-1) Apache HTTPD 2.4.16 をソースからビルドして /app/apache/ 以下にインストール
(2-2) PHP 5.6.14 をソースからビルドして /app/php/ 以下にインストール
(2-3) 出来上がった Apache HTTPD 2.4.16 および PHP 5.6.14 のモジュールを /app/apache/ および /app/php/ 以下からそれぞれ取り出してアーカイブ

こうして出来上がったアーカイブファイルは、Ubuntu 環境の /app/apache/ & /app/php/ 以下であれば動くように作られているので、同じ状態を作り出すようにビルドパックを構成(次回)すればよい、ということになります。今回はそのための準備を行います。


では具体的な作業手順の説明です。まずは Ubuntu 14.02(64bit) のターミナル環境に SSH 等でログインします:
2015100901


まずは作業ディレクトリを作成します。今回は /tmp/build を作業ディレクトリとします:
$ mkdir -p /tmp/build
$ cd /tmp/build


(2-1) Apache HTTPD 2.4.16 のソースコード一式をダウンロードし、作業ディレクトリ内に展開します:
$ curl -L http://www.carfab.com/apachesoftware/httpd/httpd-2.4.16.tar.gz | tar xzf -


Apache HTTP のビルドに必要な apr-1.5.2 および apr-util-1.5.2 をそれぞれダウンロードし、作業ディレクトリ内の srclib/ ディレクトリ内に展開します:
$ cd httpd-2.4.16/srclib
$ curl http://www.us.apache.org/dist/apr/apr-1.5.2.tar.gz | tar xzf -
$ mv apr-1.5.2 apr
$ curl http://www.us.apache.org/dist/apr/apr-util-1.5.4.tar.gz | tar xzf -
$ mv apr-util-1.5.4 apr-util
$ cd ..


Apache HTTP のビルドに必要なライブラリ(libpcre3, libpcre3-dev)を apt-get で入手します:
$ sudo apt-get install libpcre3 libpcre3-dev


Apache HTTP ビルド後のインストールディレクトリを /app/apache/ とする前提でビルド(configure して make して make install )します:
$ ./configure --prefix=/app/apache --with-included-apr --enable-rewrite
$ sudo mkdir -p /app/apache
$ sudo chmod -R 777 /app/
$ make && make install


(2-2) PHP インストール先のディレクトリ(/app/php/)を用意します:
$ sudo mkdir -p /app/php


(2-1) の作業でビルドしたモジュールの一部を PHP のライブラリとしてコピーします:
$ sudo mkdir -p /app/php/ext
$ sudo chmod -R 777 /app/php
$ cp /app/apache/lib/libapr-1.so.0 /app/php/ext
$ cp /app/apache/lib/libaprutil-1.so.0 /app/php/ext
$ cd /app/php/ext
$ ln -s libapr-1.so.0 libapr-1.so
$ ln -s libaprutil-1.so.0 libaprutil-1.so


PHP のビルドに必要なライブラリ(libxml2, libxml2-dev, libssl-dev, ...)を apt-get で入手します。平行して PostgreSQL をサポートするために必要な環境を整えます:
$ cd /tmp/build
$ sudo echo “deb http://apt.postgresql.org/pub/repos/apt/ trusty-pgdg main”> /etc/apt/sources.list.d/pgdg.lis
$ wget --quiet -O - https://www.postgresql.org/media/keys/ACCC4CF8.asc |  sudo apt-key add -OK
$ sudo apt-get update
$ sudo apt-get install libxml2 libxml2-dev libssl-dev libvpx-dev libjpeg-dev libpng12-dev libXpm-dev libbz2-dev libmcrypt-dev libcurl4-openssl-dev libfreetype6-dev postgresql-server-dev-9.4


PHP のソースコード一式をダウンロードし、作業ディレクトリ内に展開します:
$ curl -L http://php.net/get/php-5.6.14.tar.gz/from/us1.php.net/mirror | tar xzf -


PHP ビルド後のインストールディレクトリを /app/php/ とする前提でビルド(configure して make して make install )します:
$ cd php-5.6.14
$ ./configure --prefix=/app/php --with-apxs2=/app/apache/bin/apxs --with-mysqli --with-pdo-mysql --with-pgsql --with-pdo-pgsql --with-iconv --with-gd --with-curl=/usr/lib --with-config-file-path=/app/php --enable-soap=shared --enable-libxml --enable-simplexml --enable-session --with-xmlrpc --with-openssl --enable-mbstring --with-bz2 --with-zlib --with-gd --with-freetype-dir=/usr/lib --with-jpeg-dir=/usr/lib --with-png-dir=/usr/lib --with-xpm-dir=/usr/lib
$ make && make install


MySQL クライアントライブラリを apt-get で入手して、PHP / Apache のライブラリとしてコピーします:
$ sudo apt-get install libmysqlclient-dev
$ cd /app/php/ext
$ cp /usr/lib/x86_64-linux-gnu/libmysqlclient.so.18.0.0 ./
$ ln libmysqlclient.so.18.0.0 libmysqlclient.so.18
$ ln libmysqlclient.so.18.0.0 libmysqlclient.so
$ cp /tmp/build/php-5.6.14/.libs/libphp5.so /app/apache/modules/


(2-3) コンパイルが終了した Apache HTTP のモジュールをアーカイブします:
$ cd /app
$ echo '2.4.16' > apache/VERSION
$ tar -zcvf apache-2.4.16.tar.gz apache


コンパイルが終了した PHP のモジュールをアーカイブします:
$ echo '5.6.14' > php/VERSION
$ tar -zcvf php-5.6.14.tar.gz php




これで (2) の作業が完了して、ビルドパックを作るための作業準備が整いました。今回の作業で出来上がった apache-2.4.16.tar.gz および php-5.6.14.tar.gz はどちらも /app/ 以下にコピーすれば正しく動く前提で作られているので、これらのモジュールを使い、この条件でビルドパックを作ってあげればよい、ということになります。

次回はいよいよ実際にビルドパックを作って、動作確認までしてみます。ゴールは目前!


(注 2015/Oct/16 追記)
続きはこちら

 

ウェブサービスを開発・公開する上で、URL のリライトの問題があります。

例えば、アプリケーションとしては
 http://xxx.myserver.com/abc.php?country=Japan&pref=Chiba&city=Funabashi
というパラメータを受け取って処理するようなページやサービスがあったとします。

単に動かすだけなら、このパラメータ処理でいいのですが、SEO 対策や、単に長くて見難いという理由から、これを
 http://xxx.myserver.com/abc.php/Japan/Chiba/Funabashi
のような URL パターンで受け取りたいことが出てきます。

この例であれば、
 http://xxx.myserver.com/abc.php/AAA/BBB/CCC
という URL パターンを有効な URL として認識し、実際に処理する際には
 http://xxx.myserver.com/abc.php?country=AAA&pref=BBB&city=CCC
と内部的に書き直し(ReWrite)してから処理をする、ということになります。これが URL リライトです。

HTTP サーバーに Apache HTTPD を使っている場合は、この URL リライト機能が標準モジュールになっていて、mod_rewrite モジュールを有効にして、httpd.conf や .htaccess に変換ルールを記述するだけで URL リライトが実現できます。 ではウェブサーバーに Apache Tomcat など Apache HTTPD を経由しない Java アプリケーションサーバーを使っている場合のリライト処理はどうすればいいでしょう??


その答の1つが UrlRewriteFilter です。jar ファイル1つをプロジェクトに組み込み、専用の XML ファイルに変換ルールを記述することで、Java アプリケーションサーバーでも mod_rewrite のようなリライト処理を実現できるようになります:
urlrewritefilter00


実際に使ってみたサンプルを紹介します。まずは公式ページから urlrewritefilter-4.0.3.jar ファイルと、サンプルの urlrewrite.xml ファイルをダウンロードして保存します。
urlrewritefilter01


Java アプリケーションのプロジェクト内にこれらのファイルを配置します。まず urlrewritefilter-4.0.3.jar は WEB-INF/lib/ に、urlrewrite.xml は WEB-INF にそれぞれ保存します。次に web.xml を編集します:
urlrewritefilter02

WEB-INF/web.xml の </web-app> の直前に次の内容を追加して、このウェブアプリケーション内の全ての URL パターン(/*)に UrlRewriteFilter フィルターを適用することを宣言します:
  :
  :
<filter>
  <filter-name>UrlRewriteFilter</filter-name>
  <filter-class>org.tuckey.web.filters.urlrewrite.UrlRewriteFilter</filter-class>
</filter>
<filter-mapping>
  <filter-name>UrlRewriteFilter</filter-name>
  <url-pattern>/*</url-pattern>
  <dispatcher>REQUEST</dispatcher>
  <dispatcher>FORWARD</dispatcher>
</filter-mapping>

</webapp>

実際の変換パターンは WEB-INF/urlrewrite.xml ファイルの <urlrewrite> 要素内に記述します。以下の例では2つの変換パターンを記載しています:
<urlrewrite>
  :
  :
  <rule>
    <from>/urlrewrite/(.*)/(.*)/(.*)</from>
    <to>/urlrewrite?x=$1&y=$2&z=$3</to>
  </rule>
  <rule>
    <from>/urlrewrite/(.*)/(.*)</from>
    <to>/urlrewrite?a=$1&b=$2</to>
  </rule>
</urlrewrite>

前者では /urlrewrite/ 以下に / をセパレータとして3つのパラメータを受け取る、つまり
 /urlrewrite/XXX/YYY/ZZZ 
のような URL 指定があった場合に、内部的に
 /urlrewrite?x=XXX&y=YYY&z=ZZZ
のようにリライトして処理する、という変換パターンを記載しています。

後者では同様に2つのパラメータを受け取った時、つまり
 /urlrewrite/AAA/BBB
のような URL 指定があった場合に、内部的に 
 /urlrewrite?a=AAA&b=BBB
のようにリライトして処理する、という変換パターンを記載しています。

#上記例ではパラメータが2つの時と3つの時とで、異なるパラメータ変数に渡すようにしています。
 もちろんこの部分は定義次第です。


後はこれらのパラメータ(リライト後のパラメータ)に対応して処理するような /urlrewrite を(サーブレットなどで)実装すればよい、ということになりますね。




 

ウェブサーバー(HTTP サーバー)を使う場合、なんらかのアクセスログを残すことになります。例えば Apache HTTPD の場合、デフォルトでアクセスログは /var/log/httpd/access_log に残ります。そのフォーマットは /etc/httpd/conf/httpd.conf 内で設定/カスタマイズできます。
2015012200


デフォルトの httpd.conf では、以下の様なログフォーマットが指定されています:
LogFormat "%h %l %u %t \"%r\" %>s %b common

暗号のような記述ですが、左から順にこのような意味があります:
 %h : 接続元のリモートホスト名(IPアドレス)
 %l : クライアント識別子(取得できない場合は - )
 %u : 認証時のユーザー名(取得できない場合は - )
 %t : 時刻
 %r : リクエストの最初の行の値
 %s : レスポンスステータス
 %b : 送信バイト数(0バイトの場合は - )

このログフォーマットであれば、以下の様なログが取得できることになります:
192.168.1.101 - - [20/Jan/2015:11:32:29 +0900] "GET / HTTP/1.1" 200 -


最初の値がアクセス元のホストになります。つまりこれで(プロクシが使われている場合はプロクシのアドレスになりますが)どこからのアクセスがあったのか、という情報が分かります。


ところが、このアクセス元ホストが分からなくなる場合があります。それは HTTP サーバーがロードバランサ経由で使われていた場合です。サーバーの負荷軽減などの目的で、サーバーを複数台構成にしてロードバランサ経由で利用する、というケースは珍しくないと思います(クラウド環境によっては1台構成でもロードバランサ経由になることもあります)。ただその場合、この設定だとアクセス元ホストは必ずロードバランサの IP アドレスになってしまい、結果として常に同じホストからのアクセスがあったとログに記録されることになります。

これを避けるには httpd.conf をカスタマイズする必要があります。具体的にはこんな感じに:
LogFormat "%{X-Forwarded-For}i %l %u %t \"%r\" %>s %b common


%h の代わりに %{X-Forwarded-For}i という記述に変えました。この意味ですが、まず %{XXX}i という記述は「リクエストヘッダに含まれるヘッダー名 XXX の値」です。つまりこの記述は「リクエストヘッダに含まれる X-Forwarded-For ヘッダの値」をログに書き出すよう指示していることになります。

そしてリクエストヘッダの X-Forwarded-For ですが、これはプロクシやロードバランサなどのキャッシングサーバーに接続するクライアントの送信元 IP アドレスです。つまりキャッシングサーバーから見た時の %h の値がこのヘッダ値に入ってくるので、その値を取り出してログに記録すればよい、ということになるわけです。 そこで上記のような設定をすることでロードバランサ経由であっても、元のクライアントの IP アドレスを記録できるようになるのでした。

なお、この方法は HTTP プロトコルに限って有効です。HTTPS では暗号化によって HTTP ヘッダに送信元 IP アドレスが記録できるかどうか、ロードバランサによって変わってきてしまいます。お使いのロードバランサが HTTPS をサポートしているか、サポートしていない場合の対応方法などはお使いのクラウド業者に問い合わせる必要があると思っています。



 

Apache HTTPD でバーチャルホストを使う設定手順の紹介です。一応 CentOS 6 環境を前提としますが、多くのケースで他の環境にも応用できる情報だと思っています。


バーチャルホストは、1つのウェブサーバー(Apache HTTPD)で複数のウェブサイトを運用するものです。 「複数のウェブサイト」の考え方ですが、例えば以下の例のようにディレクトリ単位で分けるのであればバーチャルホストを使わなくても1つのウェブサーバーで(ドキュメントルート以下のディレクトリを分けるだけで)運用できます:
 http://www.xxxxxx.com/host1/  (ホスト1)
 http://www.xxxxxx.com/host2/  (ホスト2)
 http://www.xxxxxx.com/host3/  (ホスト3)

でも以下のような、ディレクトリの違いではなく、ホスト名やサブドメインの違いによる複数のウェブサイトを1台のウェブサーバーで運用するにはバーチャルホストの設定が必要です:
 http://www1.xxxxxx.com/  (ホスト1)
 http://www2.xxxxxx.com/  (ホスト2)
 http://www3.xxxxxx.com/  (ホスト3)

上記のようなケースでのバーチャルホストの設定方法を紹介します。なお、前提条件として以下のような条件とします:
(1) DNS は設定済み(www1.xxxxxx.com, www2.xxxxxx.com, www3.xxxxxx.com いずれにも同じ IP アドレスが設定されていて、これらの名前全てでバーチャルホストを設定するマシンが参照できる)
(2) ユーザーが http://www1.xxxxxx.com/ にアクセスしてきたらドキュメントルート1(/var/www/html/vh1/)以下に誘導する
(3) ユーザーが http://www2.xxxxxx.com/ にアクセスしてきたらドキュメントルート2(/var/www/html/vh2/)以下に誘導する
(4) ユーザーが http://www3.xxxxxx.com/ にアクセスしてきたらドキュメントルート3(/var/www/html/vh3/)以下に誘導する
(5) ユーザーが IP アドレスなど上記以外の名前で http アクセスを行ってきたらエラーとする(ホスト名でしか参照できなくする)


まず最初に (1) の名前解決についての設定をしておきます。本当にドメイン(ここでは xxxxxx.com としますが、他のドメインの場合は読み替えてください)やグローバルIPアドレスを取得していて、www1.xxxxxx.com / www2.xxxxxx.com / www3.xxxxxx.com いずれも世界中から参照できる IP アドレスに結びつけることができるよう DNS 設定が可能な場合はそのように設定しておいてください。 一方、実際にはドメインを取得しておらず(或いは取得しているドメインは使わず)あくまでテスト目的でバーチャルホスト環境を構築するのであれば、/etc/hosts ファイルを編集して以下の赤字部分を追記します:
127.0.0.1      localhost localhost.localdomain www1.xxxxxx.com www2.xxxxxx.com www3.xxxxxx.com

この赤字部分を追記することで、とりあえずこのマシン上からは www1.xxxxxx.com / www2.xxxxxx.com / www3.xxxxxx.com いずれの名前でも 127.0.0.1 に結びつきました。つまり、このマシン上からは www1.xxxxxx.com / www2.xxxxxx.com / www3.xxxxxx.com の名前でアクセスできる環境が整いました。このマシン以外からの動作確認を行う場合は 127.0.0.1 ではなく、実際の IP アドレスに紐付けるように hosts ファイルを編集してください。


名前解決の準備ができたら Apache HTTPD サーバーをインストールします。CentOS であれば以下のコマンドでインストールできます:
# yum install httpd

ではここからバーチャルホストの設定を行います。まずは3つの運用ホストそれぞれに対応するドキュメントルートディレクトリを作成しておきましょう:
# mkdir /var/www/html/vh1
# mkdir /var/www/html/vh2
# mkdir /var/www/html/vh3

次に Apache HTTPD サーバーの設定ファイルをカスタマイズします。/etc/httpd/conf/httpd.conf を編集して、サーバー名の指定があればコメントし、またバーチャルホストの有効化を指定します:
  :
#ServerName xxxxxx.com:80  ←ServerName をコメント
  :
  :
  :
NameVirtualHost *:80  ←NameVirtualHost のコメントを外してバーチャルホスト有効化
  :

そして各ホストや設定内容に合わせた設定ファイルを追加していきます。上記の設定 (2) を実現するための設定ファイルを /etc/httpd/conf.d/virtualhost-vh1.xxxxxx.com.conf として作成(新規追加)します。内容は以下のようにします:
(/etc/httpd/conf.d/virtualhost-vh1.xxxxxx.com.conf)
<VirtualHost *:80%>
  ServerName www1.xxxxxx.com
  DocumentRoot /var/www/html/vh1
  ErrorLog logs/vh1-error_log
  CustomLog logs/vh1-access_log combined env=!no_log
</VirtualHost>

この中で http://www1.xxxxxx.com/ でアクセスがあった場合のドキュメントルートが /var/www/html/vh1 であることや、HTTPD のエラーログ/アクセスログのファイル名を指定しています。

同様にして、上記設定 (3), (4) のための設定ファイルを /etc/httpd/conf.d/virtualhost-vh2.xxxxxx.com.conf と /etc/httpd/conf.d/virtualhost-vh3.xxxxxx.com.conf をそれぞれ以下の内容で新規に作成します:

(/etc/httpd/conf.d/virtualhost-vh2.xxxxxx.com.conf)
<VirtualHost *:80%>
  ServerName www2.xxxxxx.com
  DocumentRoot /var/www/html/vh2
  ErrorLog logs/vh2-error_log
  CustomLog logs/vh2-access_log combined env=!no_log
</VirtualHost>
(/etc/httpd/conf.d/virtualhost-vh3.xxxxxx.com.conf)
<VirtualHost *:80%>
  ServerName www3.xxxxxx.com
  DocumentRoot /var/www/html/vh3
  ErrorLog logs/vh3-error_log
  CustomLog logs/vh3-access_log combined env=!no_log
</VirtualHost>

最後に上記設定 (5) のための設定ファイルを追加します。ここではサーバー名でのアクセスがあった場合のみ適合するドキュメントルートを参照させていますが、IP アドレスを指定してアクセスがあった場合はエラーとするように決めています。その内容を設定するために以下の内容で /etc/httpd/conf.d/virtualhost-00.conf ファイルを新規に作成します:
(/etc/httpd/conf.d/virtualhost-00.conf)
<VirtualHost *:80%>
  ServerName any
  <Location>
    Order deny,all
    Deny from all
  </Location>
</VirtualHost>

これで設定準備そのものは完了です。最後の準備として動作確認用に3つのドキュメントルートそれぞれに簡単な index.html ファイルを作成して、バーチャルホストが有効になっていることががテスト時に分かるようにします:
# echo "VirtualHost 1" > /var/www/html/vh1/index.html

# echo "VirtualHost 2" > /var/www/html/vh2/index.html

# echo "VirtualHost 3" > /var/www/html/vh3/index.html

これで目的のバーチャルホストを実現するための準備は完了です。最後に Apache HTTPD を再起動して、この準備内容を反映させます:
# /etc/init.d/httpd restart

動作確認は(ホスト名で区別するので) www1.xxxxxx.com / www2.xxxxxx.com / www3.xxxxxx.com の名前でこのホストの IP アドレスが引ける環境から行う必要があります。上記のように /etc/hosts の 127.0.0.1 で設定したのであれば Apache HTTPD サーバーと同じマシンからブラウザを起動して行います。

まずは http://www1.xxxxxx.com/ の場合。ちゃんと期待通りの内容が表示できてます:
2014120901


同様にして http://www2.xxxxxx.com/ や http://www3.xxxxxx.com/ の場合もそれぞれ正しいドキュメントルートを参照できているはずです:
2014120902

2014120903


最後に http://localhost/ (或いはhttp://IPアドレス) でアクセスしてみます。localhost で HTTPD サーバーが動いていることは間違いないのですが、ホスト名で指定されていないので(上記 (5) の設定が有効になっているので)エラー扱いとなるはずです:
2014120904


バーチャルホスト(とDNS)をうまく使うと、負荷やリソースとの兼ね合いもありますが、1台のサーバーで複数の HTTP ホストを運用できて便利です。


 

このページのトップヘ