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

今回から、いよいよApacheの設定編に突入する。Apacheの設定ファイルは、長大で複雑怪奇に見えるが、実際には単純な項目の羅列にすぎない。まずは最も基本的な設定を行って、Webサーバとしての体裁を整えよう。

　今回からはApacheの設定に話を進めよう。すでにApache 2.0がベータ版になっている（特集：Apache 2.0の新機能とその実力参照）が、筆者が調べた範囲では基本的な設定に変化はない。可能な限り、Apache 2.0で変更された部分についてもフォローし、逐次補足していくつもりだ。

　今回は、設定の基本中の基本として、インストール直後に行うべき設定を紹介する。

サイト計画の重要性

　まず初めに、サイト計画の重要性について話しておこう。

　一般的にサイト計画といえば、次のような要素について討議決定することを意味する。

• サイトの目的（そのサイトで何を公開したいのか）
• サイトの対象者
• サイトマップ
• システム計画（どういう技術で作成するのか）
• 運用計画・業務計画
• 基本デザインの立案

　こうした作業を経て計画された結果をもとに、技術者はWebサーバを設定することになる。そこでは、システム計画に基づいたコンポーネント（SSLやPHPなど）のインストールと設定も含まれるだろう。そして、サイトマップをもとに、どういう設定を行うべきか考えるのだ。

　しかし、すべてのサイトがこうした手順どおりに作成されるわけでもない。そういった場合には、とりあえず最低限の設定を行う、ということも少なくない。従って、筆者は仮説を立てながら設定を紹介するが、これらは最低限必要な設定項目のガイドラインともいえる。

　顧客に対して設定項目の決定を求めるのであれば、これらの項目について空白を埋めるようにしてもらえばいい。

設定の基本知識

■Apacheの設定ファイル

　Apacheの設定においては、まず設定対象となるファイルを知らなくては意味がない。ここではApache 1.3.19を対象に説明するが、これよりも古いバージョン（例えば Apache 1.2.x）の場合は、設定ファイルが異なる可能性もある。その際は適宜読み替えるようにしていただきたい。Apache 1.3.xであれば、おそらく何の問題もないだろう。

　Apacheの設定ファイルは、Apacheをインストールしたディレクトリ下の「conf」ディレクトリ（通常は /usr/local/apache/conf*編注）の中にまとめられている。このディレクトリを見ると多くのファイルが存在していると思うが、これらの大半は過去バージョンの名残であって意味をなさない。いま対象としなくてはならないのは「httpd.conf」ファイルで、そのほかは無視して構わない。

　httpd.confファイルはテキストファイルなので、その編集にはテキストエディタを利用する。viエディタを使ってもよいし、GNOMEのgEditのようなGUIエディタでもよい。WindowsクライアントにFTPでファイル転送し、使い慣れたWindows用のエディタを使うのもいい。

■設定ファイルの内容

　設定ファイルには、「#」で始まる行が多く含まれている。これらは、設定を説明するコメント、もしくはコメントアウトされたディレクティブだ。それらが邪魔であれば、不必要な部分を削っても構わないが、慣れればそう気になるものでもない。そもそも、設定を説明するコメントを全部削ったところで、まだまだ多くのディレクティブが残ってしまうのだ。

　このディレクティブは、Apacheを設定するコマンドを意味する用語である。Apacheは起動時に設定ファイルの内容を読み込み、各種ディレクティブの指示に従う。このことから、コマンドという表現が使われているのだが、要するに「設定項目」のことだと思えばよいだろう。

　例えば、「ServerNameディレクティブの内容を変更する」とあれば、ServerName（Webサーバのホスト名）の設定を変更するのだな、と思えばいいわけだ。設定ファイルでは、左側にディレクティブ、右側に設定値という具合になっているから、変更するディレクティブを見つけるのも簡単だ。エディタの検索コマンドを使って、ディレクティブ名から探し出せば手っ取り早いが、上から順に見ていっても比較的容易に見つけられる。

Apacheの設定

■Webサーバホスト名の変更

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

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

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

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

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

　まずポイントになるのは、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ディレクティブに設定しなければならない。

　あるいは、

■ポート番号の変更

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

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

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

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

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

　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のインストール先によっては変化する）になっているはずだ*編注。

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

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

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

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

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

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

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

のように、エラー番号とそれに対応する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）を参照してほしい。もちろん、すべてのエラー番号に対応するページを作成する必要はない。

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

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

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

●正常の場合

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

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

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

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

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

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

◆

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

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