
第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でアクセス |
まずポイントになるのは、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 |
●Portと書くところを Porにした場合
# ./apachectl configtest |
●設定範囲外のポート番号70000を指定した場合
# ./apachectl configtest |
●存在しないディレクトリをドキュメントルートにした場合
# ./apachectl configtest |
以上、幾つか例を示しておいたが、このように比較的きっちりとテストしてくれる。しかし、ユーザー側のケアレスミスは、やはり防ぎきれないところもある。こればかりは仕方のないことだから、いくらテストで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系列の新機能、インストール方法、国際化の現状を解説する |
|
|
ホワイトペーパー(TechTargetジャパン)
- natテーブルを利用したLinuxルータの作成・2 (2010/3/11)
IPパケットのディスティネーションアドレスを書き換える「DNAT」を使って、透過型プロキシを構築します - 一歩進んだ監視のカスタマイズ (2010/3/3)
スクリプトの実行結果などを取得できるユーザーパラメータを用いて、自分のニーズにぴったり合った監視を実現 - OSSライセンス順守の第一歩 (2010/2/18)
企業として、OSSライセンス違反を犯さないためには、どのような手順が必要か、いくつかアドバイスします - 無視できないフラグメンテーション問題への解答は? (2010/2/10)
今回は、メモリコンパクション、そしてメモリバリアを発行するシステムコールという2つのパッチについて深く紹介します
|
|
スキルアップ/キャリアアップ(JOB@IT)
スポンサーからのお知らせ
- - PR -
| 「いつかは壊れるサーバ」そんな故障に 迅速で安価に手軽に対応する方法とは? New! |
| 「特権ユーザー」の事件を防げ! 万能権限を持つユーザーの管理方法とは? New! |
| 仮想環境の構築とデータ保護の特効薬?! 実績と信頼性の高いパッケージで安心運用 |
| 仮想環境のバックアップもこれまでどおり 「まるごと取ってまるごと戻す」簡単運用 |
| おばかアプリ選手権、第4弾開催中!! ムダにカッコよくてくだらない作品求ム! |
| 社内ファイルサーバを“クラウド”に統合 VPN直結「クラウド型ストレージ」を紹介 |
| その数、なんと400台以上! グループ内 サーバの「統合管理」によるメリットは? |
| 美人!? まあまあ? 気になる いやし系!! PV急増で「美人時計」がとった手段とは? |
| 進化を続ける富士通ストレージETERNUS DX 製品開発者の自信を裏付けるものとは何か |
| 運用管理の課題を“2つの観点”から分析 ユーザー満足度の高い「仮想環境」とは? |
- - PR -
お勧め求人情報

**先週の人気講座ランキング**
〜CCNA編〜
| ◆ | 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台以上! グループ内 サーバの「統合管理」によるメリットは? |









