text

Webサーバーの構築

Apacheの設定と活用


1.Webサーバーとは何だ

Webはインターネットへ情報を発信するための1つの手段であり、Webサービスを提供できるホストコンピュータをWebサーバと言う。

かつてインターネットを利用する人々というのは大学や研究機関の研究者くらいだったが、1995年のWindows95が登場して状況が一変した。それまで、パソコンをインターネットに接続するためには、高度な知識や繁雑な作業を伴うものだったがWindows95の登場以来その必要がなくなった。OS自体に標準で簡易にインターネットへと接続する機能を搭載していた。このことが一気にインターネットの普及を勧め現在に至る。このような背景もあり現在では自宅や会社のコンピュータからインターネットに接続する環境が比較的容易に構築できるようになった。

インターネットの利用用途の主たるものはWebから情報を検索し閲覧することにある。このことから、『インターネット = Web』という図式が成り立ている。Webで扱う情報は余所から情報を収集するだけではなく、自分が情報の発信源になることにある。双方向の情報の取り扱いがTVに代表される従来のメディアとの違いだ。

自分の持っている情報をインターネット上に公開したい場合は、どうすればよいだろうか。

Webサービスを提供するコンピュータの公開領域にデータを設置すればよい。
本章ではとくにことわりがない限り、インターネットでWebサービスを提供するホストコンピュータをWebサーバと呼び、そのうえで公開する情報をWebコンテンツと呼ぶこととする。

プロバイダやプロバイダに相当する組織(=大学や専門学校のRAS、・・・etc)への接続を経由してインターネット接続していると、Webサーバーをあえて意識しなくとも作成したWebコンテンツを所定の領域に置くことで情報のWeb公開が可能となる。
本章では、Webサーバの管理運用を行う人を対象とする。よって、HTMLや各種スクリプト言語の記述方法などに関しては取り扱わないものとする。
Webサーバ機能を提供するサーバプログラムは幾分か種類があるが、本章ではUNIX系OSで広く使われているApacheを題材としてWebサーバ構築について解説していくものとする。

1−1.Webサーバーの歴史

現在、インターネットというとWebコンテンツの閲覧を主に示す。ちなみに小生がコンピュータにはじめて触れた学生時代には、他大学の電算機センターにリモートログインをして処理速度の速いコンピュータで数値解析の計算をさせることが主だった。

あれから幾許かの年月が経ち時代は変わったものだ、と感慨に浸りつつ以下にWebの歴史を紹介していく。

インターネットの歴史というのは、意外と古い。インターネットの起源といわれるのは1950年代までさかのぼることはできる。世界初のコンピュータENIACと同様に軍事研究の一環として産声を上げた。近代、とりわけコンピュータ分野の画期的な技術というものは軍事利用派生ということがザラにある。

米ソ冷戦時代の1957年、アメリカはソビエトからの核攻撃を警戒していた。もし、核攻撃を受けて軍事用のコンピュータが破壊されたとしたら、軍事機能が大幅に低下してしまうということを懸念していた。そこで、コンピュータを各地に分散させてネットワーキングすることで各々のコンピュータのデータを共有すれば被害が最小限に抑えられる。分散型コンピュータネットワークが考案された。

1969年にARPA(Advanced research Projects Agency)が中心となり、遠隔地の研究機関や大学のコンピュータをネットワーク接続することに成功した。このネットワークがARPAnetと呼ばれ、インターネットの起源とされている。

ARPAnetが誕生した当時は、わずか4台のコンピュータをネットワークに接続しているだけだったが、1971年には全米15カ所にある23台のコンピュータをネットワークに接続し、のちに政府や軍、大学などの研究機関を中心に規模を拡大していった。一方で、ARPAnetとは別路線でUSENETやBITNETというネットワークがARPAnetに参加していない大学や研究機関が中心となって結成された。

1981年にNSF(National Science Foundertion - 全米科学財団 )がCSnet(Computer Science Research Network - コンピュータ科学研究ネットワーク)を設立し、翌1982年CS netとARPAnetが連結され巨大ネットワークが誕生した。さらに、1983年ARPAnetから軍事用との部分がMILNET(=Military Network)として分離したことにより、ARPAnetは研究用として機能するようになった。1984年NSFが新たにNSFnetを創設し、大学を中心にスーパーコンピュータのネットワーク化を始めた。

ネットワーク化の流れの中で、軍事用・研究用として稼働していたネットワークの利用形態に商用利用や一般企業の参加の要望が明確化し始めてきた。

1989年NSFnetがARPAnetを吸収し、ネットワークの商用利用と一般企業の参加が可能となり、後のインターネットへと成長していった。この背景には米ソ冷戦の終焉が大きく影響している、といわれている。

コンピュータネットワークの発展については上記で述べたとおりだが、当時のネットワーク利用について考察していこう。
1980年代末頃のネットワーク利用としては、電子メール、データの送受信などで、簡易なネットワーク上のデータを読むのが主だった。現在のように、画像や音声、文字のあるWebページを閲覧することのできるシステムがあったわけではない。

現在、URLを指定してWebページを読み出して閲覧するシステムはWWW(World Wide Web)と呼ばれている。この技術がネットワークの世界に登場したのは比較的新しい。1989年スイスにある欧州素粒子物理研究所(CERN)の研究者であった、ティム・バーナーズ・リーが、研究者同士で論文や文献を共有するために提唱したのが起源とされている。彼は、論文や文献、一覧をHTML化してマウスをクリックすることで瞬時に欲しい文献が表示できるような工夫をした。これがのちのWWWへと発展することになる。

なぜ、このようなことが必要になったかというと、CERNでは加速器を使って高エネルギー物理学の実験を行う施設が在り、その施設に世界中の大御所の博士達が集まって研究をしていたのだが、実験終了後に世界中に研究者が霧散して、文献の共有が難しくなったために、円滑な文献交換が行えるようにといった背景が在った。

その後、アメリカのNCSAにおいてCERNと同様に「分散した研究者の共同研究において効率良く情報交換をする」ための研究を行っていたチームがWWWに目をつけグラフィックの扱えるようになったWWWブラウザ「Mosaic」を開発するに至る。

当時、ウェブサーバとしては、CERNの作ったものとNCSAが作ったものがあった。NCSAの方は「CGI」や「SSI」などの機能を実装するなどマニア受けするさまざまな機能を搭載し、後発ながらCERNのWebサーバから着々とシェアを奪って行った。だが、急速にさまざまな機能を盛り込んだがためにNCSAのWebサーバは多くのバグが含まれており、堅実さのCERNと機能のNCSAという位置づけが徐々に定着していった。

そのシェアの多さからWebサーバーの標準となったNCSA HTTPD だが、バージョン1.30を最後に開発が打ちきりになった。その後、有史の人々が協力し合い、サポートと開発を継続するプロジェクトが Apache として立ち上がる。

現在のApacheはNCSA HTTPのソースコードを修正したものではなく、イチから書き直されたものである。

Hackerには軍事マニアが多く、コンピュータ用語にも軍事用語派生のものが多い。そのためApacheというのは米軍の迎撃ヘリからついたものと思われがちだが、実は違う。Apacheの設立時のメンバーはNCSA HTTPDに修正パッチを有史で提供していたメンバー達だったので、ソフトウェアパッチ(= patch)をもじってアメリカの先住民族の部族名 Apache とダブらせたのがその名称の由来と言うことになっている。

1−2.Webサーバーの必要性

日本のインターネット利用者数については複数の統計がある。そのため、インターネット利用者の定義や測定方法によって数値は異なるが,広く普及してきた事には相違がない。今回は総務省の「平成18年版情報通信白書」を参考に人々のインターネット利用について考察していく。
2005年末における6才以上のインターネット利用者は8,529万人(前年比7.3%増)となっている。その内訳は、パソコンからの利用者が6,601万人、携帯電話・PHSや携帯情報端末からの利用者が6,923万人、ゲーム機やテレビからの利用者が163万人。人口普及率としては66.8%となっている。また、総務省が定期的に公表している「ブロードバンドサービス等の契約数」によると,2006年12月末におけるブロードバンド契約数は2,575万件に達し、未だに増加を続けている。このことから、それだけの利用者に応じられるだけのWebサーバが必要であり、いうまでもなくインターネットに欠かせない存在と言及できる。
※JPドメイン名の累計登録数 (2007/04/01現在、総合計908329)

Webサーバを所有している対象の大半は企業だが、社外への情報発信手段としてWebは欠かせないものとなっている。とくに近年になって起業されたベンチャー企業(?)では、何はともあれWebサイトを立ち上げることが自社のアピールや信頼につながるとさえいわれているほどである。それを裏付けるかのように、中小規模の企業でもインターネット普及率は高水準になり、大企業では当たり前のごとく100%に達している。

すでにインターネットに接続して、自社内でサーバ(Web、Mail、DNS,・・・etc)を有する企業は軒並み回線速度やサーバを増強している次第だ。とりわけアクセス数の多いサイトでは複数のサーバをロードバランサー(=負荷分散機)でクラスター化して、外部からは1台のサーバコンピュータのように振る舞わせることも当たり前の状況となった。

このように、インターネット(特にWeb)に対する投資が重要なものとなれば、少なからずWebサーバ自体への投資も必要になることは自明のことだ。現在ではWebサーバの設置は常識であり、必要性をあえてこの紙面で語る必要性は乏しい。(・・・よって、述べることはしない!)

そうなると、Webサーバで発信する情報の質、つまり内容が重視されるのが必然の流れだろう。利用者が必要としない情報を並べ立てたところで、そんなサイトは見向きもされなくなるだけだ。そのうえ、利用者はスピーディに情報を獲得することを重要視しているから、高いレスポンスを確保しなくてはならない。

レスポンスが良く、内容が充実していて、必要としている情報を素早く取り出せる。そんなWebサイトを素早く構築し、低いコストで維持することが最も重要な課題とされていることであり、これからのWebサーバに求められる事と言及できる。

1−3.Webサーバーのしくみ

Webサーバとは、このWebページのようなHTMLファイルや付随する画像などのファイルをクライアントPCに配信するサーバーコンピュータであることはすでに述べた。

Webページを閲覧するときにはクライアントPC上ではInternet ExplorerやFire FoxのようなWebブラウザが動作しているはずだ。Webブラウザはサーバーから配信されるHTML文のファイルを解析し、他のファイルと組み合わせて画面上にWebページを表示する。

ユーザーは閲覧したいWebページの情報をURL(=http://www.criterion.sc/)で指定する。URLには情報を取得するサーバーと、そのサーバーから配信してもらうファイル(例:index.html)の指定が含まれる。URLのリクエストを受信したサーバーは、自分の保存しているファイルの中から指定されたファイルを取り出し、クライアントコンピュータに配信する。このとき、クライアントコンピュータとサーバコンピュータの間では、HTTPやHTTPSと呼ばれるプロトコルが使われるので、URLの先頭は必ず、『http:』や『https:』がつく。

この話の中で注意しておきたいのは、サーバーを用意しただけではWebサービスを提供できない。該当のサーバーにWebサーバーソフトを実装して適切な設定を施す必要がある。本章で取り扱うApacheとは数多あるWebサーバーの1つということをあえて言及しておく。

1−4.なぜ、Apacheを使うのか?

本稿ではWebサーバーとしてApacheを題材に用いる。
WebサーバーソフトにはApache以外にもIIS(Microsoft)やiPlanet(Sun)、WebSTAR(StarNine)、Zeus (Zeus)、・・・など複数ある。それにも関わらず、世間ではWebサーバーソフトとしてApacheを導入しているケースが多いのだろうか。本章ではApacheの特徴を踏まえて考察していこう。

■無料で使える

Apacheは、オープンソースのソフトウェアとして公開されているため商用・非商用問目的問わず、無償での使用できる。1990年代後半のLinuxの普及によって、ライセンスフリーのソフトウェアは珍しくないが、どのような会社でもできるだけコストを掛けたくない、というのが原則だ。そのような側面でUNIX系OSとApacheを使えば、ハードウェアと人件費だけでWebサーバを構築できるのは非常にありがたい。

Apacheに次いで導入件数の多いMicrosoft IISは、ライセンスフリーではない。OSのパッケージに含まれているのでIIS自体は無償で入手できるが、Windows NT ServeryやWindows 2000 Server(=Windows2003 Server)を購入しなければ利用できない。どちらかといえば、Windows NT Serverのライセンス料に含まれているとも考えられる。

■無保証・無対応

オープンソースで無償で使えるというのは、何もメリットだけではない。無料で使える代わりに、Apacheの品質について保証する団体もなければ、問題を解決する義務を持つ組織もない。疑問点があったとしても、それに対して責任を持って回答してくれる機関もない。これはApacheに限ったはなしではなく、オープンソースのソフトウェアすべてに言えることなのだ。
だが、無保証・無対応ということはさほど問題ではない。ApacheのソースコードはLinuxと同じく、多くのボランティアによって日々メンテナンスされている。疑問や問題点があれば、Apacheのコミュニティに相談すれば、メンテナンスに関わっている世界各国のメンバから素早く確実な回答と対応が得られるだろう。

こうした対応の早さや蓄積された多くのノウハウは、世界的な大手のベンダでもかなわないほどだ。貴殿がもし、それでも心配でちゃんとしたサポートを得たい、と言うのであれば、有料でサポートサービスを提供している企業に相談してみたらいかがだろうか。すでに、日本でもいくつかの企業がApacheの有償サポートサービスを提供している。

■高い信頼性

既に多くのWebサイトで導入されている実績から、その信頼性は疑いようがない。もしかしたら、有償で提供されているソフトウェアよりも信頼でき、圧倒的に便利だと感じることの方が多いかもしれない。

Apacheがいかに優れたソフトウェアで高い信頼性を誇っているのかは、6割(2007年の2月時のApacheのシェアは60.17%、Netcraft調査)を超えるといわれる圧倒的なシェアが一番の証拠になるだろう。もちろん、多くの文献やWebで公開された資料を見ても、その信頼性の高さを裏付けるものが主だ。
仮に、頻繁にリブートしているとしても、それだけでは一概にソフトウェアの問題とは言及できないが、いくつかの有名なサイトについて調べてみれば傾向が見えてくる。その結論は自分自身で導き出していただきたい。小生は学生時代からのUNIXユーザーのため、ここではApacheが高い信頼性を持ち、連続稼働に耐え得るソフトであると主張しておきたい。

■高い安定性と軽快な動作

一般的なソフトウェアのように、Apacheには推奨CPUやメモリ量の提示はないものの、非常に軽量なソフトウェアであることは疑いようがない。OSが起動した状態で、多少なりともマシンの資源に余力があれば、間違いなく起動してくれるほどだ。

しかし、それだけで安心してはならない。起動したからと、安定した動作をするとは限らない。Webサーバというものは、外部から大量のアクセスを受けるのが前提だ。大量のアクセスがあっても軽快に動作するように作られてはいるが、それでも限度がある。大量のアクセスを受ければ、それだけCPUパワーやメモリを必要とする事を忘れてはならない。

高い安定性と軽快な動作。この2大要素がApacheがWebサーバーの代名詞たる所以なのである。これだけ豊富な実績を作れたのも、高い安定性がその根底にあるからなのである。これら2つの特徴に関しては、簡単に実証できないためここで説明するのは難しい。実際に導入をしてみて、その軽快さと安定性を実感してみてただきたい。

■豊富な機能

オープンソースのフリーウェアだからと、侮ってはいけない。Apacheの機能については今後機会があれば紹介するが、その機能は実に豊富で決して商用ソフトに劣らない。それどころか、Microsoft IISやiPlanet Web Server(旧Netscape)のような、商用の製品をも凌駕するほど高機能なのである。

その1例を挙げると、Webサーバーの機能にSSL接続という機能がある。SSLが稼働するWebサーバーのことを一般的にSSLサーバーというが、かつてSSLサーバーはMicrosoftのIISが50%超の一人勝ち状態であったが、Apache44.0%、IIS43.8%とApacheに逆転されてしまっている(2006/4/26 NetCraft調査)。

■多彩な動作環境

Apacheは、LinuxやUNIXプラットフォームはもちろんのこと、MacやWindows NT、OS/2でも動作する。
イントラネットのように、限られた人数で使うのであれば少々無理のあるサーバでも構わないだろう。しかし、インターネット上に公開し、一般からのアクセスを受け入れるのであれば、できる限り余裕のある構成をとっておくべきだ。
動作環境を選ばないという特徴は、動作させるサーバー環境が変わっても設定や動作の違いを意識する必要がなくなるため、メリットは大きい。

例えば、Windows NT環境で動作させていたサイトが、アクセスの増加で限界に達してしまったとしよう。このとき考えられるのは、ハードウェアを交換するか、上記で述べたように負荷分散機を使ってハードウェアを増設するかだ。このときに、WebサーバーソフトをIISからApacheへとリプレースしてしまっても、どちらの手段であってもWebサイトに与える影響は微々たるもので済む。ディレクトリの表現手法の違いなど、ごくわずかな修正にだけ気をつければよい。もし、LinuxからSolaris、Linux(PC)からLinux(UNIX)への移行であれば、修正などはまったく必要ない、といえる。

また、もう1つのメリットとして、ノウハウを共有できることも挙げられる。イントラネット用(社内)のWebサーバはIIS、インターネット用(社外)のサーバはUNIXという場合であっても、どちらかで蓄えた知識がそのまま通用する。このことは、多数の顧客と契約し、それぞれの環境でサイトを構築しなければならないSI業者にとっても大きなメリットになるはずだ。

2.Webサーバー構築の目的 ? いつでも・どこでも・・・

自ら情報を発信するというスタンスは非常に重要なこと。ただ情報を他者から得るだけでは消費にしかならず意味がない。新しい知識を作り出して発信することが生産性であり、創造的な仕事だといえる。エンジニアリングの仕事とは創造的的あるべきだ、と常々考える。

ネットワークエンジニアを名乗るのならば、Webページは必須のツールとなる。
前提条件として、貴殿はフリーランスのネットワークエンジニアで現在顧客募集中でプロモーションを行っているとする。

まず、自宅にネットワークを構築してサーバーを運用していると仮定してみる。この事は会社ではなくとも自宅でも簡単な検証実験から、会社では制約が多くてできない新しい技術の実験を行うことができる。日々切磋琢磨して技術の修練に励んでいることを示している。
また、規模は小さくともイチからネットワークを構築してサーバーを運用しているという事で、最低限ネットワークの管理やサーバーの運用ができるだけの技術があることを相手に知らせることができる。

ネットワークエンジニアにとってどの技術に対してどのような情報を持っているのか、ということは重要なファクターとなる。いつでも・どこでも、必要なときに欲しい情報を取り出して業務に活用するというKnowledge Management が専門職としての力量を推し量ることを可能とする。

書籍を調べたりWebで調べればすぐに情報を取り出すことは可能だ。だが、必要な情報が記述されている本をいつでも手元にあるとは限らない。分厚い書籍を何冊も持ち歩くのは質量の関係から体力的に非常に大変だ。また、書籍の中の記述に欲しい情報があったとしてもどこにあるのかを見つけ出すのに非常に時間が掛かる。状況によっては見落としてしまうかもしれない。非常に非効率でリスキーだ。

情報は電子化して保有しておくべきだ!

貴殿が良識と知性ある人物であるのならば、Webで掲載されている情報はWeb検索で調べればよいと、タカをくくるのは控えた方がよい。Googleに代表されるWeb検索は時間が経過するにつれて検索結果表示の優先順位が変わってしまう。そのため、以前はこのキーワードで出てきた、と同じ検索条件で検索しても次回も同じ検索結果になるとは限らない。

では、該当の情報が記述されているWebページをBookmarkに登録しておけばいかがだろうか。

これは、素人が犯す典型的な失敗事例だ。
インターネット上に数多と点在するWebページは案外動的に変化するモノだ。Webページの管理者が遠隔地に引っ越してプロバイダを変えてしまったり、Webページをホスティングしていたプロバイダが倒産してしまったら、Bookmarkに登録していたリンクは意味のないモノになってしまう。

では、どうすればよいか?

答えは簡単!
気になる新聞記事をスクラップブックに収めるように気になる情報が収められているWebページがあったらそのWebページのハードコピーを保存しておけばよい。ただし、自宅や会社のPCでは手元になければ意味がない。Webサーバーのアクセス認証できるスペースに保存しておくと良い。こうすればインターネットにさえアクセスできれば、いつでも・どこでも、欲しいときにその情報を引き出すことができる。さらに全文検索エンジン(例:Namazu)を実装して記事をキーワードで検索できるようにしておけば、デジタル化した情報の付加価値が高まる。
また、時間に余裕があれば自身が今までに集めた情報を用いてどのようなKnow How(=知識)を得たか、自分なりにアレンジしてオリジナルの技術として情報を公開していくと、自分の技術力を世間にアピールすることができる。

いかがだろうか。上記で紹介した方法はITを有効利用したエンジニアリングではないか。業務のIT化とは業務の効率化が主たる目的ということを忘れてはならない。ITを有用に使いこなせる技術とアイデアを持つネットワークエンジニアに依頼すれば自社の業務の効率化の実現を図ることができる、と信頼を得ることができるだろう。

ネットワークエンジニアが自分のWebページを持つことの意義をご理解いただけた、と思う。

UNIX系OS + Apacheというシステム構成はWebアプリケーションサーバーを構築する際の基礎となる。
本章には併せてCGIの実行許可やアクセス制限などを習得する。

3.サーバー構築の手順

(1)Apacheのインストール

上記までに述べたように、本稿ではWebサーバーとしてApacheを題材として取り上げる。本稿の環境としてはOSにOpenBSDを用いる。OpenBSDにはバージョン3.0以降標準でApache 1.3.xxが搭載されるようになった。OpenBSD用にカスタマイズされており、通常のApacheとは設定が異なる、かなりクセのあるApacheだ。他の環境でも使用できる技術の構築を目指すと言うこともあるが、後にWebDav(=Apache2.0以降から正式対応)を構築する必要があるので、ここではApache2.2.xを導入する。

■ソースコードの入手

メンテナンス性からPortsパッケージを使用したいのだが、あいにくApacheのパッケージは用意されていない。
そこで、The Apache Software FoundationからApacheの最新版(安定版)を入手する。

(作業方法)

# wget http://www.meisei-u.ac.jp/mirror/apache/httpd/httpd-2.2.4.tar.gz

上記の例では、明星大学のサーバーがミラーサイトとなっているので、それを利用して最新版の2.2.4(=本稿執筆時の最新版)を入手した。

■Apacheのインストール。

Apacheに限らず、ソースコードを入手して実装する場合は、アーカイブの解凍、configure、Compile、installの手順を踏む。

『Webサーバーの運用運用とセキュリティ対策』でも触れるが、サーバーのセキュリティ対策としてSSLよく利用する。
ApacheでもSSLは使用するので、あらかじめSSLのライブラリのパスは確認しておくことをオススメする。
本環境でのSSLのパスは /usr/local/ssl/lib (OpenBSD標準)

ソースコードのインストールの前に

上記でも述べたように、Apacheは非常に互換性が優れている、そのためとくにソースコードを改変する必要もなく、エラーが1つも出ることなく、コンパイルからインストールまでスムーズに進む。
しかし、Apacheの標準インストールではWebDav、SSL、Digest認証は無効になっている。

これら3つは本稿以外でも今後必要となってくるので、該当モジュールを読み込んでコンパイルするようにソースコードのコンパイル時にオプションを指定する。

# tar xvzf httpd-2.2.4.tar.gz
# cd httpd-2.2.4

./configure --enable-shared=yes --enable-modules="so ssl dav auth_digest" --with-ssl=/usr/lib
SSL / WebDav / Digest認証を有効にする設定でMakefileの作成を指示

# make
ソースコードのコンパイル

# make install
ソースコードのコンパイル

(2)Apacheの基本設定

[設定ファイル]
 /usr/local/apache2/conf の編集。

作業前には初期の設定ファイルのバックアップを取っておくこと。

# cp -p httpd.conf httpd.conf.20070416


・DocumentRootの設定
・UserDir(ユーザーhtmlホーム)の設定
・tcp 80ポートの開放

(3)サービスの起動と停止

 起動スクリプトの利用

(4)Webページの公開

(5)CGIの実行許可

 (手順)
 ・CGI設置ディレクトリの作成
 ・ユーザーによるCGI実行制限

(6)アクセス制限

 ・ディレクトリの制限
 ・.htaccessの使用

4.Apacheの基本設定

■はじめに

Apacheに限らず、多くのサーバーアプリは稼動する汎用性を持たせるためにプログラム本体とサーバーアプリの設定情報を記述した『設定ファイル』からなる。このように分けておくことでサーバー環境の移行やバージョンアップなどによる大規模な変更があったとしても以前の設定情報がそのまま流用できる。また、同じ設定で新たにWebサーバーを設置する際にも同様の利点がある。サーバーマシンやOSのリプレースの際にその都度イチイチ設定を手入力で行っていたら1台や2台ならともかく、それ以上ともなれば大変だ。管理者の負担は増える。移行前と同じ設定でも手入力などしていたら、タイプミスをやりかねない。

NW障害やサーバー接続の障害が発生した折に、最初に確認するのが設定ファイルだ。
明らかに設定ファイルへのミスタイプがなかったとしても設定ファイルの記述ミスというのは起こり得る。そんな設定ファイルでも、サーバー稼動直後は問題なく動いているので最初は問題がないのかもしれない。ただし、何日、何ヶ月か経過してある日突然、サーバー障害が発生したときに記述ミスに気がつく、ということは往々にしてある。

■httpd.confの編集

Apache Ver.2.xまでは設定ファイルはhttpd.confの1つにまとめられていた。Ver.2.2.xからは設定ファイルの増大を防ぎ、メンテナンスを行いやすくするために、基本設定はhttpd.confだが、それ以外の拡張設定は /usr/local/apache2/conf/extra 以下の.confファイルに記述するようになったので、注意すること。

最近のApacheは良くできており、初期状態の設定ファイルのままでもApacheは稼働するように記述されている。Webサーバーに特別なことなことをさせないのなら、初期設定から変更することは少ない。

まずは、カレントユーザーをrootに変更し、設定ファイルの置いてあるディレクトリに移動する。

# cd /usr/local/apache2/conf

オリジナルの内容をファイル名の末尾に作業日の日付をつけて保存する。

# cp -p httpd.conf httpd.conf.20070416
# vi httpd.conf

設定ファイルの先頭が、#から始まる行はコメントアウト行で設定には影響しない。 Apacheの基本的な設定項目は、ほとんどがデフォルトの設定値のままでも動作する。基本的な部分を踏まえ必要部分を変更していくようにすること。

かつて、Apacheのhttpd.confの設定は基本的に以下の3つのセクション(Global Environment / Main' server configuration / Virtual Hostst)に分けられていたが、上記の理由で全体設定のみになった。それ以外の定はすべて拡張設定として /usr/local/apache2/conf/extra 以下の.confファイルに記述するようになった。

■サーバールートの設定

Apacheの設定ファイルのルートとなるディレクトリを設定

ServerRoot "/usr/local/apache2"

■Listenポートの設定

Listen 80

と記述されている行は、ApacheがTCPポートの80番を使用することを意味している。
通常の公開WebサーバーはTCPポートの80番が標準となっている。
通常、

http://10.0.1.100/

にBrowserなどでアクセスした場合、以下のようにポート番号を指定した場合と同じ意味。

http://10.0.1.100:80

上記のListenで80番以外のポート(xx)を指定していれば、上記のように:xx(xxは任意の数字)とhttpでサーバーにアクセスするポート番号を明示的に指定すれば可能となる。

(ex)
http://10.0.1.100:8080

本稿では、WebサーバーのローカルIPを10.0.1.100とします。

■サーバー名の設定

Webサーバーに名称を定義する。
サーバー名を有効にするためには、DNSへの登録を反映させる必要がある。

(変更前)

#ServerName www.example.com:80

(変更後)

ServerName www.criterion.sc:80

■管理者のメールアドレスの設定

Apacheが稼動しているLinuxサーバーの管理者ではなく、Apacheの管理者とする。そのため、携帯のメールであろうが、Webメールであろうが、かまわない。

 基本設定ではワザワザ管理者のメールアドレスを設定する必要はない。
 もし、指定する場合は下記の太字部分のように変更するとよい。

(変更前)

ServerAdmin root@localhost

(変更後)

ServerAdmin webmaster@criterion.sc

Webサーバーの管理者であるならばどのメールアドレスでもかまわない。

■トップページのファイル名

これはブラウザからサイト名だけ指定されたとき、無条件で表示されるトップページのHTMLファイル名。通常は、index.htmlだけに設定するが、必要な場合はindex.shtml、index.cgi、index.php、index.jsp、index.swfなど必要なものを追加しておく。


ときどき、index.htmとファイル名末尾が.htmになっているものを見かけるが、これはMicrosoft社製のHTMLエディタに準拠したものと見受けられる。WindowsOSは拡張子を3文字で識別するために起こる事象。ユーザーが混乱しないように、出来るだけ拡張子はそろえた方がよい。

DirectoryIndex index.html

変更する場合は・・・

DirectoryIndex index.html index.shtml index.cgi index.php index.jsp index.swf

と記述する。

■ドキュメントルート

index.htmlをはじめとした、そのサイトのWebコンテンツを収めたディレクトリの指定を行う。
本稿の環境(OpenBSD)では

DocumentRoot "/usr/local/apache2/htdocs"

となっており、
http://www.criterion.sc/
http://www.criterion.sc/index.html
にてWebページにアクセスできる。

上記のDocumentRootの""の中を書き換えれば、ドキュメントルートは変更できる。
Webサーバーを立ててコンテンツを見せるだけならば、あえて変更する必要はない。

■UserDir(ユーザーhtmlホーム)の設定

Apache 2.2.x では、設定ファイルのメンテナンス工場を目標にスリム化された。その為、UserDirの設定自体は httpd.conf 内の記述にない。
ここで注意したいのは、 httpd.conf 内に

# User home directories
Include conf/extra/httpd-userdir.conf

という記述があることを確認し、 /usr/local/apache2/conf/extra/httpd-userdir.conf の設定を行う。
以下に httpd-userdir.conf の基本的な記述を掲載しておく。

# Settings for user home directories
#
# Required module: mod_userdir

#
# UserDir: The name of the directory that is appended onto a user's home
# directory if a ~user request is received. Note that you must also set
# the default access control for these directories, as in the example below.
#
UserDir public_html

#
# Control access to UserDir directories. The following is an example
# for a site where these directories are restricted to read-only.
#
<Directory /home/*/public_html>

#AllowOverride FileInfo AuthConfig Limit Indexes
AllowOverride None
AddHandler cgi-script .cgi
#Options MultiViews Indexes SymLinksIfOwnerMatch IncludesNoExec
Options ExecCGI
<Limit GET POST OPTIONS>
Order allow,deny
Allow from all
</Limit>
<LimitExcept GET POST OPTIONS>
Order deny,allow
Deny from all
</LimitExcept>
</Directory>

■Webサーバーのアクセスログ

Webサーバーのアクセスログファイルの指定。
Apacheの初期設定ままでログ取得はされる。ログファイルの設置場所やログアイルのタイプを任意に変更したい場合のみ変更する。

ErrorLog logs/error_log

CustomLog logs/access_log common

上記の記述はApacheの初期状態のものだ。ログファイルはそれぞれ、

/usr/local/apache2/logs/access_log
/usr/local/apache2/logs/error_log

に格納される。
エラーログに関しては問題はないが、通常のアクセスログはアクセス解析した際のログの内容がやや少なすぎるので以下のように書き換える。

(変更前)

CustomLog logs/access_log common

(変更後)

CustomLog logs/access_log combined

■ポートの開放

標準ではファイアウォールのTCP 80番ポートは閉じられているので開放する。

# vi /etc/pf.conf

(/etc/pf.confの内容を以下のように書き換える)
pass in quick on fxp0 inet proto tcp from any to 10.0.1.100 port 80 keep state

(設定ファイルを読み込み直させて、新しい設定を反映させる)
# pfctl -f /etc/pf.conf

設定変更が反映されたことを確認する。
# pfctl -s rules

pass in quick on fxp0 inet proto tcp from any to 10.0.1.100 port = www keep state
このように表示されていれば、正常に設定変更をされている。

5.Apacheの起動・停止・再起動

ここでは、Apacheの起動・停止・再起動のオペレーションについて解説する。

■httpd.confの構文チェック

Apacheの設定ファイルを変種後、以下のコマンドを実行。

# /usr/local/apache2/bin/httpd -t
Syntax OK

設定ファイルの構文に問題がなければ、Apacheは問題なく起動して稼働する。 いよいよApacheの起動だ、以下の項目を

■既に起動しているApacheの確認

ここまでで、Web表示をさせるためのApacheの設定は完了した。あとは、デーモン(=httpd)を起動するのみ。 httpd.confの内容を変更しただけでは、Apacheの動作に変化はない。必ず、httpdの起動または再起動をする必要がある。
まずは、現在稼働中のデーモンの状態を確認してみよう。

# ps -awx | grep httpd

これで、httpdが動いていたら、それはOSに標準で実装されていた、1.3.xx系のApacheなので実行を止めるべきだ。
稼働中のApacheを止めるときは、以下のようにコマンドをタイプする。

# /usr/sbin/apachectl stop

■デーモンの起動/停止

Apache2は以下のようにしてデーモン起動するようになる。

デーモンの起動
# /usr/local/apache2/bin/apachectl start
デーモンの停止
# /usr/local/apache2/bin/apachectl stop

Apacheの正常起動が確認できただろうか。

■旧バージョンのApacheの無効化

もう、2度と旧バージョンのApacheは稼動させる必要はないのならば、以下のように旧バージョンのApacheを無効化してしまおう!

# mv /usr/sbin/apachectl /usr/sbin/apachectl.OFF
# chmod -x /usr/sbin/apachectl.OFF

# mv /usr/bin/dbmmanage /usr/bin/dbmmanage.OFF
# chmod -x /usr/bin/dbmmanage.OFF

# mv /usr/sbin/rotatelogs /usr/sbin/rotatelogs.OFF
# chmod -x /usr/sbin/rotatelogs.OFF

# mv /usr/bin/apxs apxs /usr/bin/apxs apxs.OLD
# chmod -x /usr/bin/apxs apxs.OLD

# mv /usr/bin/checkgid /usr/bin/checkgid.OLD
# chmod -x /usr/bin/checkgid.OLD

# mv /usr/bin/htdigest /usr/bin/htdigest.OLD
# chmod -x /usr/bin/htdigest.OLD

# mv /usr/bin/htpasswd /usr/bin/htpasswd.OLD
# chmod -x /usr/bin/htpasswd.OLD

# mv /usr/bin/httpd /usr/bin/httpd.OLD
# chmod -x /usr/bin/httpd.OLD

# mv /usr/bin/logresolve /usr/bin/logresolve.OLD
# chmod -x /usr/bin/logresolve.OLD

■デーモンの初期起動設定

このままの状態では、サーバー起動後httpdは自動起動する設定にはなっていない。サーバー起動/再起動時にそのつどコマンドを入力しなければならない。そこで、OS起動後にhttpdが自動起動するように設定する必要がある。

サーバー起動時に自動的にApacheが起動するようにするには、/etc/rc.localを以下のように記述を書き加える必要がある。

## Apache 2.2.4 Boot ##

if [ -x /usr/local/apache2/bin/httpd ]; then
echo -n ' httpd'; /usr/local/apache2/bin/httpd
fi

### Apache (fin) #####

試しに、serverの再起動して試してみる。
Webサーバーが正常にあがっていることが確認できたら、サンプルページではなくオリジナルのコンテンツを表示させてみる。
ドキュメントルートが/usr/local/apache2/htdocsとなっているためこのパスのディレクトリにコンテンツのファイルを入れればよい。

6.Webページの公開

すでにApacheの設定から起動までの作業は行った。本節では、 Apache稼動後の設定について解説をしていくこととする。

■Webページ表示の確認

httpd.confで設定したドキュメントルートのディレクトリ(/usr/local/apache2/htdoc)にindex.htmlファイルを作成して表示されることを確認する。

■ユーザディレクトリの設定

httpd.confとhttpd-userdir.confにて、ユーザーディレクトリの公開の設定をすでに行った。
とりわけ、httpd-userdir.confでは”<Directory /home/*/public_html>”という記述がある。
ユーザーディレクトリをWebで公開するためには、ユーザーのカレントディレクトリにpublic_htmlというフォルダを作成する必要があることを示す。
以下では、ユーザーディレクトリの作成を行う。

$cd /home/hoge <- ユーザーのホームディレクトリ(/home/hoge)に移動

$ mkdir public_html <- (http://10.0.1.100/~hoge/)を作成

$vi public_html/index.html

紙面ではユーザー名をhogeとしたが、ご自身の環境にあったものをご使用いただきたい。

■パーミションの設定

広く普及されているLinuxディストリビューションを例に挙げると、Fedora Coreではユーザーディレクトリは755、公開ディレクトリは775のパーミッションが初期状態で与えられていて、初期状態で公開できるパーミションが設定されている。だが、一般的なUNIX及びクローンOSでは公開用ディレクトリやファイルのパーミッション設定が必要となる。

下記のようにしてディレクトリやファイルのパーミション設定及び確認を行う。

$ls -l ~ <- ホームディレクトリのパーミッションの確認

$ls -l public_html <- 公開ディレクトリのパーミッションの確認

Webサーバーとして公開することを前提とするならば、ユーザーのホームディレクトリは711、公開用ディレクトリは755のパーミッションに設定しておく必要がある。

$chmod 711 ~ <- ホームディレクトリのパーミッション711の設定

$chmod 755 public_html <- 公開ディレクトリののパーミッション755の設定

パーミッションは8進数表示で000〜777までの8進数で表現する。
パーミッションの数字の100の位、10の位、1の位にはそれぞれ意味がある。

100の位・・・ファイルやディレクトリ所有者の読み/書き/実行の権限を意味する。
10の位・・・ファイルやディレクトリ所有者グループの読み/書き/実行の権限を意味する。
10の位・・・その他のユーザーの読み/書き/実行の権限を意味する。

各位の数字にもそれぞれ意味がある。

4・・・ファイルやディレクトリの読み込み権限を与える。
2・・・ファイルやディレクトリの書き込み権限を意味する。
1・・・ファイルやディレクトリの実行権限を意味する。

これらの数字を各位ごとに足して0〜7で権限を設定する。
例 : 755 = 400+200+100 + 40+10 + 4+1 -> ファイルの所有者は読み/書き/実行の権限を持つ。ファイル及びディレクトリに対して所有者グループのユーザーは読み/実行の権限を持つ。それ以外のユーザーは読み/実行の権限を持つ。

■ファイルの所有者の変更

他のユーザーが作ったファイルやディレクトリを譲り受けた際にパーミッションの変更が必要になることもある。作業はroot権限で実施できる。

(作業例)

#chown ownner:group file

上記の例では"ownner"にファイル所有者名、"group"に所有権を持たせたいグループ、"file"には該当ファイル名を指定する。
該当のディレクトリ以下のファイルやフォルダすべてを一括で同じ所有者にしたい場合は以下のようにコマンドをタイプすればよい。

#chown -R ownner:group directory

6−1.CGIの実行

かつてCGIというとWebページの演出技法という位置づけで、個々人の趣味に任せるようなスタンスのためサーバー管理技術としては考慮されていなかった。どちらかというと、スクリプトのコーディングミスがサーバーへの付加増大やセキュリティホールへと発展することが懸念されたために、積極的にCGI機能を実装はされなかった。むしろ、出来るだけ実装しないのがサーバー運用の定石だった。近年では、管理者用ツールがPerl/CGI形式で配布される用になってきたこともあり、サーバー管理に使用するようになってきた。 ただし、サーバー側で実行されるため、セキュリティ面への配慮は重要である。

■ドキュメントルートのCGI

実は、単に公開用ディレクトリにcgiスクリプト記述したファイル(.cgi)を設置しただけでは、apacheはCGIプログラムを実行できない。

CGIを実行するためには・・・

 ・apacheの設定ファイル(httpd.conf)の変更
 ・***.cgiファイルへの実行権限設定

の2点が必要。

■httpd.confの変更

既にご存知のとおり、Apache の設定は /usr/local/apache2/conf/httpd.conf というファイルによって行う。この設定によって、ユーザが CGI を使えるかどうか、 SSI を使えるかどうかが決定する。httpd.conf には下記のような記述がある。

<Directory />
Options FollowSymLinks
AllowOverride None
</Directory>

<Directory /usr/local/apache/htdocs>
Options Indexes FollowSymLinks
AllowOverride None
</Directory>

<Directory /usr/local/apache/cgi-bin>
Options None
AllowOverride None
</Directory>

<Directory />〜</Directory> の間は、ディレクトリ / 以下、つまり全てのコンテンツに関する設定を決定している。同様に、<Directory /usr/local/apache/htdocs/>〜</Directory> の間は、/usr/local/apache2/htdocs/ 以下のコンテンツに関する設定を決定している。

Options は、各種の動作の設定を決める命令で、以下の設定することができる。

* Indexes
* Includes (IncludesNoExec)
* FollowSymLinks (FollowSymLinksIfOwnerMatch)
* ExecCGI
* MultiViews

例えば、

Options +FollowSymlinks +Includes -ExecCGI

とすると、FollowSymlinks Includes を ON にし、ExecCGI を OFF すなわち、CGIを実行しないようにする。この Options で記述しなかった Indexes や MultiViews は変更しない (Indexes/Multiviews は管理者の行った設定がそのまま反映される)。

(1)Indexes

この命令はファイル一覧表示を許可するか否かを決定する。普通、 http://www.criterion.sc/ などにアクセスすると、 http://www.criterion.sc/~hoge/index.html や http://www.criterion.sc/~hoge/index.htm が表示されるが、 index.html や index.htm が存在しないと、該当ディレクトリの下にあるファイル一覧が表示されてしまう。

実際にこのようなサイトというのは見栄えは悪いし、セキュリティ上の弱点をさらしているので好ましくない。そこで、以下のように記述しておくと、index.htmlやindex.htmのないディレクトリの一覧表示を防ぐことが出来る。

Options -Indexes

(2)Includes

SSI を許可するかどうかを決定する。Options +Includes とした場合は、以下のものが有効になる。
IncludesNoExec もついでに参照すること。

* <!--#exec cmd="..."-->
* <!--#exec cgi="..."-->
* <!--#include file="..."-->

(3)IncludesNoExec

SSI (Exec 以外) を許可するかどうかを決定する。Options +IncludesNoExec と記述した場合は、以下の記述が有効になる。

* <!--#include file="..."-->

だが、Includes の場合とは異なり、下記のような exec 系は使えない。

* <!--#exec cmd="..."-->
* <!--#exec cgi="..."-->

SSI を使って他のファイルを include したいが、プログラムを実行した結果を取り込む必要はない、という場合に使う。

(4)FollowSymLinks

シンボリックリンクを許可するかどうかシンボリックリンクをたどるかどうかを設定する。なお、シンボリックリンク自体は OS の機能のため、いつでも使える。ここでは Web 経由でシンボリックリンクを辿るかどうかを決めるわけなので、CGI プログラムの中ではいつでもシンボリックリンクを使うことができなければならない。

このセクションで説明したことを踏まえると、以下のようにhttpd.confを書き換えることが好ましい。

<Directory />
Options FollowSymLinks
AllowOverride None
Order deny,allow
Deny from all
</Directory>


<Directory "/usr/local/apache2/htdocs">
Options -Indexes
Options FollowSymLinks


AllowOverride None

Order allow,deny
Allow from all

</Directory>


<Directory "/usr/local/apache2/cgi-bin">
AllowOverride None
Options None
Order allow,deny
Allow from all
</Directory>

ここまで編集したら、<IfModule alias_module>という記述の最後尾に

ScriptAlias /cgi-bin/ "/usr/local/apache2/cgi-bin/"

と書き加えることで、CGIの実行が出来るようになる。

■CGIスクリプトの作成例

#vi /usr/local/apache2/cgi-bin/sample.cgi

(以下のように記述してみよう)

#!/usr/bin/perl
print "Content-type: text/plain \n\n";
print "Hello, CGI!";

■CGIスクリプトに実行権限を与える

CGI実行のためのサーバー設定をし、CGIスクリプトも書き上げた。
あとは、CGIスクリプトに実行権限をつけつだけだ。

# chmod o+x sample.cgi

# /usr/local/apache2/bin/apachectl stop
# /usr/local/apache2/bin/apachectl stop

これで、作業は完了。
実行結果確認として、http://10.0.1.100/cgi-bin/sample.cgi (=当サイトではsample.cgiは設置しておりません。)にアクセスしてみよう。

ブラウザにCGIスクリプトの実行結果が表示されればOK!

■ユーザー単位のCGIスクリプトの実行

ユーザーの公開用ディレクトリ下でCGIスクリプトを実行したい場合はまず、Web公開用ディレクトリ下に cgi-bin ディレクトリを作成する

$ cd public_html
$ mkdir cgi-bin

CGIディレクトリ名は本当は何でもよい。だが、一般的なWebサイトでは慣習的にCGIスクリプトの設置ディレクトリをcgi-binとするようにしている。
/public_html/cgi-bin/下にcgiスクリプトを設置して /usr/local/apache2/conf/extra/httpd-userdir.conf に設定を書き込んだ後にCGIスクリプトファイルに実行権限を与えればユーザー単位のCGI実行が出来る。

Apache 2.0 まではhttpd.confの変更だったが、Apache2.2以降からは /usr/local/apache2/conf/extra/httpd-userdir.conf に変更を加えることになったことに注意をしておこう。

ユーザー単位CGI実行のためには /usr/local/apache2/conf/extra/httpd-userdir.confの <Directory /home/*/public_html>と <Limit GET POST OPTIONS> の間にに以下の記述を新たに追加する。

AllowOverride None
AddHandler cgi-script .cgi
Options ExecCGI

Fedora Core 4.0 のようなバグはなく、上記の記述変更ですんなりとユーザー単位のCGIが動くようになる。
"AddHandler cgi-script .cgi"の記述では"cgi-script"と".cgi"の間に半角スペースを入れなければ記述ミスとみなされるのでよく注意が必要だ。記述ミス防止のため予め半角スペースを2つ入れおくのもよいだろう。
ただし、全角スペースを入れると場合も記述ミスとシステム上みなされるので注意が必要。

■.htaccessの設置

.htaccesファイルをcgi-binディレクトリ(/home/hoge/public_html/cgi-bin/)に設置する。

$ vi ~/public_html/cgi-bin/.htaccess
(.htaccessファイルの作成例)
Options ExecCGI
AddType application/x-httpd-cgi .cgi
(ファイル保存後Apacheを再起動)
# /usr/local/apache2/bin/apachectl stop
# /usr/local/apache2/bin/apachectl start

http://10.0.1.100/~hoge/cgi-bin/test.cgiにアクセス(=当サイトではtest.cgiは設置しておりません)。
ブラウザにCGIスクリプトの実行結果が表示されればOK!