【3/18〜】Amazon、VMwareが語る『クラウドの未来』 スラッシュドット    はてなブックマーク  Yahoo!ブックマークに登録  印刷

第5回 絶対外せない基本設定とサーバの動作

一志 達也<ichishi@pochi.tis.co.jp>
TIS株式会社
2001/6/1

Apacheの設定

Webサーバホスト名の変更

 まずは「ServerNameディレクティブ」を変更しよう。この作業は最初に行うべき、重要な設定変更である。その理由を話せば長くなるのだが、Webサーバの動作原理として、ぜひ知っておいてほしい内容だから、少しばかりお付き合いいただきたい。

 ホスト名(ServerNameディレクティブ)はポート番号やドキュメントルートと異なり、適当な設定をしても(あるいは「何も設定しなくても」)Apacheが動作しなくなることはない。また、ごく普通にURLを入力してアクセスする分には設定の影響を受けない。

 問題は、サーバの仮想ディレクトリにアクセスする際、「/」(スラッシュ)を省略したときに発生する。あまり知られていないが、最後のスラッシュを省略するとWebサーバはそれをファイルへのアクセスだと認識する。しかし、正しく設定されたApacheならばスラッシュを省略してもちゃんとアクセスできる。それはなぜか?

 それを理解するには、実際にサーバが返している答えをのぞき見して、何が起きているか確認するのが手っ取り早い。telnetでApacheの動作を見てみることにしよう。ちなみに、この例ではServerNameディレクティブの役目を見るため、実際のホスト名がcinderella、IPアドレスが192.168.1.2のサーバに、あえて

ServerName hogehoge

という設定を行っている。

# telnet localhost 80 ←自分自身の80番ポートにtelnetでアクセス
Trying 127.0.0.1...
Connected to localhost.localdomain
Escape character is '^]'.
GET /manual HTTP/1.0  ←Apacheに最後のスラッシュを省略したリクエストを送る
                      ←ここから返された答え
HTTP/1.1 301 Moved Permanently ←301番のエラーが発生している
Date: Fri, 25 May 2001 19:16:49 GMT
Server: Apache/1.3.19 (Unix) mod_ssl/2.8.2 OpenSSL/0.9.6
Location http://hogehoge/manual/ ←manualがディレクトリであることを判断し転送先を返している
Connection: close
....以下省略.... ←301番のエラー用HTMLが返されている

 まずポイントになるのは、Apacheから301番のHTTPエラーが返されているところだ。Apacheは、manualというファイルが存在しないことを確認しているので、本来ならば404番を返すはずである。しかし、manualというディレクトリなら存在することを検出したので301番を返している。

 その後、URLの最後にスラッシュを付けてディレクトリへのアクセスを試みている。上記では省略したが、エラーページを表示するHTMLの中にも、最後にスラッシュを付けてアクセスするようメッセージとリンクが書き込まれている。

 ところが、Webブラウザはこのエラーページを表示しない。その代わりに、サーバが指定したURLに再度アクセスを試みるのである。ここに第2のポイントがある。注意深く見ると、Apacheが指定したURLには、ServerNameディレクティブに設定されたホスト名が使われている。つまり、「http://cinderella/manual」ではなく「http://hogehoge/manual/」にアクセスするようにとしているのだ。このURLにWebブラウザがアクセスするとどうなるのか。当然ながらそのホスト名は名前解決できないから、Webブラウザはアクセスできない。ややこしい説明になってしまったが、サーバが返すメッセージのすべてにServerNameディレクティブに指定されたホスト名が使われるということである。

 DNSやWINS、HOSTSファイルなどで名前解決できるならホスト名、名前解決できなくても、固定IPアドレスを使うサーバであればサーバのIPアドレス。確実にアクセス可能なものを、ServerNameディレクティブに設定しなければならない。

ServerName www.atmarkit.co.jp
例:ホスト名をwww.atmarkit.co.jpに指定

 あるいは、

ServerName 192.168.33.2
例:ホスト名の代わりにIPアドレスを指定

ポート番号の変更

 次に行うべき設定は、ポート番号の変更である。本連載の第2回でも説明したように、TCP/IPを使った通信にはポート番号という概念が必要になる。そこで、いま設定しているApacheを何番のポートで通信させるのか設定しなければならない。

 この設定には、複数のIPアドレスを設定しているサーバではどうするのか、バーチャルホスト機能を使う場合はどうするのかといった複雑な話も関係するのだが、そういったことについては、また別の機会を設けて紹介する。ここでは、サーバに割り当てられたIPアドレスは1つでバーチャルホスト機能は使わず、単一のホスト名(www.atmarkit.co.jpなど)でのみアクセスされるサーバを想定する。

 ポート番号の設定は、「Portディレクティブ」で変更する。このほかに「Listenディレクティブ」や「VirtualHostディレクティブ」など、まぎらわしいディレクティブもあるが、この段階では無視して構わない(デフォルトではコメントアウトされている)。

Port 80
例:Apacheのポートを80に指定

 その内容だが、Apache 1.3.19であれば「8080」と設定されているはずだ。この数字を変更してApacheを再起動すれば、通信するポートの番号も変更される。ただし、1023よりも小さい番号に設定する場合は、rootユーザーでApacheを起動しなくてはならない。これはLinuxの権限の問題で、1023よりも小さなポートで稼働するアプリケーションは、rootユーザーで起動するというルールになっているためだ。

 HTTPで通信するWebサーバは「80」、HTTPS(SSL)で通信するWebサーバは「443」とすることになっているが、必ずしもこのポート番号にする必要はない。外部には公開しないサーバの場合や、一部のユーザーにだけ公開する場合には、あえて違うポートにしておく方が都合がいいからだ。80や443を使うメリットは、サイトの利用者がURLを指定する際にポート番号を指定しなくて済む程度である*編注

編注:外部に公開する場合は「80」、社内限定などの場合は「8080」を使うケースが多い。

 80や443以外のポートに設定する場合は、ほかのプログラムと競合しないように注意しなくてはならない。サーバ上にはtelnetやftpなどの一般的なものだけでなく、データベースのような追加プログラムを導入している可能性もある。だれかが追加している可能性があるなら、念のために競合しないことを確認しておきたい。

 こうした競合を防ぐために、/etc/servicesファイルに使っているポートを記入しておくことを勧める。このファイルには、予約されているポートのほか、自分で追加インストールしたプログラムが使うポートを記入しておく。こうすれば、新たにポートの確保が必要になっても、間違って競合させるのを防げるわけだ。

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

 このままでは、Apacheにあらかじめ用意されたページ(画面1)が表示されてしまうから、自分が作ったページと置き換える。ここで関係してくるのが「ドキュメントルート」である。

画面1 Apacheのデフォルトページの一例

 ドキュメントルートとは、Webサーバ上のルートディレクトリのことである。つまり「www.atmarkit.co.jp/index.html」というURLが与えられたときに、「index.html」というファイルがサーバ上のどこにあるかを設定するのだ。インストール直後の状態であれば、ドキュメントルートは「/usr/local/apache/htdocs」(Apacheのインストール先によっては変化する)になっているはずだ*編注

編注:ディストリビューションによっては、/home/httpd/htmlになっている。

 作成したコンテンツ(HTMLファイルやイメージなど)を、このディレクトリのままで発信するというのであれば設定を変更する必要はない。しかし、コンテンツ登録手順や運用面のことを考慮すると、設定を変更した方が何かと都合がよいだろう。筆者のお勧めは、コンテンツ管理専用のユーザーを作成し、そのユーザーのホームディレクトリをドキュメントルートに設定することだ。こうしておけばコンテンツをアップする人の操作が楽になるし、セキュリティ上の問題も軽減される。

 ドキュメントルートの設定は、「DocumentRootディレクティブ」で行う。

DocumentRoot /home/webadmin/web
例:webadminユーザーのwebディレクトリをドキュメントルートに指定

エラードキュメントの設定

 ここまでくればかなりサイトらしくなってきたと思うが、いざというときの備えもしておきたいところだ。その1つが「エラードキュメント」の設定である。

 デフォルトでは、サーバ上に存在しないファイルへのアクセスがあれば、画面2のようなエラー画面がWebブラウザに表示される。

画面2 デフォルトの404エラー画面

 これを画面3のように、独自のエラーページに置き換えたい場合は「ErrorDocumentディレクティブ」を使って設定を変更する。この設定は非常に簡単で、

ErrorDocument 404 /error/404.html

のように、エラー番号とそれに対応するURLを指定するだけでよい。

画面3 404エラー画面のカスタマイズ例

 エラー番号は、正式には「Status-Code」と呼ばれるもので、Webサーバとクライアント(Webブラウザ)の間で内部的にやりとりしている情報である。RFCでは多数のコードが規定されているが、ここでは主なものだけを表にまとめておいた。全Status-Codeを知りたい方は、HTTP/1.0について定めたRFC 1945(http://www.ietf.org/rfc/rfc1945.txt)およびHTTP/1.1のRFC 2068(http://www.ietf.org/rfc/rfc2068.txt)を参照してほしい。もちろん、すべてのエラー番号に対応するページを作成する必要はない。

  Status-Code
内容
意味
 
401
Unauthorized ユーザー認証が必要なページで認証に失敗した(ID、パスワードのタイプミスなど)
 
403
Forbidden 指定されたリソースへのアクセスを拒否した(許可されていないディレクトリにアクセスしようとしたなど)
 
404
Not Found 指定されたリソース(ファイル)が存在しない(URLタイプミスなど)
 
500
Internal Server Error サーバがリクエスト実行できない(CGIのバグなど)
 
501
Not Implemented リクエストを処理できる機能がサーバにない
  RFC 2068からごく一部を抜粋

httpd.conf編集後の確認とApache再起動

 設定が終わったら、Apacheを再起動する。httpd.confファイルを編集しても、即座に変更が反映されるわけではないのだ。しかし、本番稼働中のサーバであれば、何の確認もせずに再起動というわけにはいかない。

 まずは設定にミスがないことを確認しよう。前回紹介した「apachectl」には、configtestというオプションがある。このオプションを使えば、設定の中でスペルミスなどがないか確認してくれるのだ。

正常の場合

# ./apachectl configtest
Syntax OK ←このように表示されれば問題なし

Portと書くところを Porにした場合

# ./apachectl configtest
Syntax error on line 236 of /usr/local/apache/conf/httpd.conf: ←行番号やファイル名を示している
Invalid command 'Por', perhaps mis-spelled or defined by a module not included in the server configuration

設定範囲外のポート番号70000を指定した場合

# ./apachectl configtest
Syntax error on line 236 of /usr/local/apache/conf/httpd.conf: ←行番号やファイル名を示している
The port number "70000" is outside the appropriate range (i.e., 1..65535).

存在しないディレクトリをドキュメントルートにした場合

# ./apachectl configtest
Syntax error on line 294 of /usr/local/apache/conf/httpd.conf: ←行番号やファイル名を示している
DocumentRoot must be a directory

 以上、幾つか例を示しておいたが、このように比較的きっちりとテストしてくれる。しかし、ユーザー側のケアレスミスは、やはり防ぎきれないところもある。こればかりは仕方のないことだから、いくらテストでOKであっても、最後にもう一度自分でチェックする余裕を持ってほしい。

 チェックでOKが出て、自分でも確認したら、Apacheを再起動する。再起動は、いったん停止(stop)してから起動(start)すればいいのだが、それではユーザーへのサービスが一時的とはいえ停止することになる。こんなときのために、停止することなく再起動できるという便利なオプションがある。それが「graceful」だ。

 gracefulオプションを指定すると、ApacheにはSIGUSR1という種類のシグナルが送信される。このシグナルはプログラムごとに定義できるもので、Apacheの場合は「接続が終了次第再起動」するように定義されている。つまり、利用者と通信中のプロセスが存在する場合は、その通信が終了するまで再起動を待つということだ。本番稼働中のサーバに対して何らかの設定変更が必要になった場合は、gracefulを活用しよう。

 Apacheをひとまず稼働させる分には、これだけ設定しておけばよいだろう。後は、もう少しサイトの設計ができあがってから徐々に行っていけばいい。

 今回は長くなったのでこれまでにするが、次回は基本設定の続きとして、もう少し細かく設定していくことにしよう。

2/2

Index
ApacheによるWebサーバ構築
  サイト計画の重要性
  設定の基礎知識
 Apacheの設定ファイル
 設定ファイルの内容
Apacheの設定
 Webサーバホスト名の変更
 ポート番号の変更
 ドキュメントルートの設定
 エラードキュメントの設定
  httpd.conf編集後の確認とApache再起動

連載 ApacheによるWebサーバ構築


 Linux Squareフォーラム サーバ構築・運用関連記事
連載:Heartbeatでかんたんクラスタリング(連載中)
オープンソースソフトウェアの「Heartbeat」を使ってHAクラスタを実現し、サービスを「落とさない」仕組みを実現します
特集:Apache 2.2でWebサイトをパフォーマンスアップ!
最新安定版Apache 2.2は、何が変わったのか? 最新のApacheを新機能の使い方とともに解説する
連載:実用 Apache 2.0運用・管理術(全8回)
本連載では、Apache 2.0の運用や管理方法を解説する。まず必須設定と基本的なセキュリティ対策を行い今後の運用に備える
連載:実用 BIND 9で作るDNSサーバ(全15回)
本連載では、BIND 9の構築/運用方法を解説していく。実際に役立つことを目的に、セキュリティや大規模運用などのテーマを取り上げていく
連載:実用qmailサーバ運用・管理術(全14回)
本連載を通して、qmailによるメールサーバの高度な構築・運用・管理術を紹介。SPAM対策やML管理からサーバでのウイルスチェックなどまで
特集:Samba 3.0の全貌 改訂版
Samba 3.0リリースから8カ月。ここであらためて、Samba 3.0系列の新機能、インストール方法、国際化の現状を解説する

MONOist組み込み開発フォーラムの中から、Linux関連記事を紹介します

ホワイトペーパーTechTargetジャパン

Linux Square フォーラム 新着記事

@ITメールマガジン 新着情報やスタッフのコラムがメールで届きます(無料)

RSSフィード

スキルアップ/キャリアアップ(JOB@IT)



- PR -
- PR -

お勧め求人情報

キャリアアップ 〜JOB@IT
@IT Special -PR-
  TomcatやJBossなどAPサーバ環境に関する
情報を集約! “業務”用APサーバ大百科

New!
  一気に解説! 最新のクラスタストレージ
「RAIDを超えたストレージ基準」……など

New!
  クラウド的ユーザー体験の変化は脅威か?
仮想化技術を使いこなす運用管理術を紹介

New!

  上司や部下、部署内メンバーとの情報共有
を“ガラッ”と変えるコラボツールとは?

New!
  おばかアプリ選手権、第4弾開催中!!
ムダにカッコよくてくだらない作品求ム!

  社内ファイルサーバを“クラウド”に統合
VPN直結「クラウド型ストレージ」を紹介

  Twitterのアカウントはなぜ突破された?
メールによる新手の攻撃手法とその対策

  もう仮想化のお試しフェイズは終わりだ!
Hyper-V 2.0が基幹システムも仮想化

  美人!? まあまあ? 気になる いやし系!!
PV急増で「美人時計」がとった手段とは?

  クライアント企業から求められる人材
⇒IT技術と経営戦略を併せ持つ「戦略家」

  .NET編集長が実践する「技術情報検索術」
サンプル・コードを簡単に探す“技”は?

  業務効率と情報セキュリティ対策を両立!
手間なく確実に機密情報を守る方法とは?

  進化を続ける富士通ストレージETERNUS DX
製品開発者の自信を裏付けるものとは何か

  運用管理の課題を“2つの観点”から分析
ユーザー満足度の高い「仮想環境」とは?

  【CTC事例】約30の基幹システムを統合!
膨大なバッジジョブを制御した方法は?

  仮想化すればコストは削減できるか?
仮想化に必要な「3つの視点」を解説する

  その数、なんと400台以上! グループ内
サーバの「統合管理」によるメリットは?