httpdの動作チェックのポイント

Apache は非常に多機能な サーバー アプリケーション ですから、設定も人によって様々です。

従って、お決まりのパターンで動作させることの多い ntpd や vsFTPd のように、「こういう部分はこうやってチェックすればOK。」という具合に簡単に動作チェックはできません。

このパートではApacheに不具合が起こったときのチェックのポイントを挙げてみましょう。

ログファイルは情報の宝庫です

書式チェックコマンド で "Syntax OK" と表示されるのに、 httpd を起動しようとするとエラーになってしまうケースがあります。

httpdの書式チェックコマンドはかなり細部にまで検査が及びますので、検査がパスしているのに起動できないというケースは非常に稀ですから、こういう場面に遭遇すると結構慌てるかもしれません。

一例としては、 構築中のLinuxサーバー の "/etc/sysconfig/netowork" に記述されている ホスト名 が、 DNSサーバー や hostsファイル で 名前解決 できない場合などが考えられます。

そういう具合になってしまうケースとしては、DNSサーバーの単純な設定ミスや、ホスト名を変更したときにどちらかの設定の修正を忘れていた、というようなことが考えられます。

httpdはこのような「外部に自分自身の動作を妨げる要因」があって起動できないときは、 プロンプト には原因を表示せず、ただ起動に失敗したというメッセージだけを表示します。

従って「httpdが何もメッセージを出さずに起動に失敗する」という場合、その原因は外部の設定にあると思って間違いありません。

こういう場合は、いたずらに "/etc/httpd/conf/httpd.conf" をいじくりまわすのは避け、まずは "ErrorLog" ディレクティブ で指定した ログ ファイルをチェックしましょう。

上の例のようなケースのエラーでも、起動できなかった理由がきちんと記述されています(もちろん英語です)。

「問題が発生したらまずログファイルをチェック。」これがエラー解消の早道です。

ホスト情報の表示　 　全ページリストへ　 　お便利用語リスト

キャッシュデータに惑わされないこと

Webブラウザ の大部分は、一度表示した コンテンツ データを クライアント機 上に蓄え、 キャッシュ として利用します。

このキャッシュデータは、 クライアント が同じ URL をリクエストしたときに Webサーバー 上のコンテンツデータと タイムスタンプ が比較され、Webサーバー側のデータが新しくなっていなければ代わりにWebブラウザに表示されます。

この仕組みは、更新されていないコンテンツデータを何度もWebサーバーから受け取るという無駄を省き、通信負荷を減らしながらクライアント側の表示速度を高めるというメリットをもたらします。

ただ、この仕組みはWebサーバーの設定においては邪魔になることがあります、

例えば "AddDefaultCharset" ディレクティブ などの、

「クライアント側の表示に関する設定を行うディレクティブ」

は、修正後に httpd の再起動 を行って設定の修正を反映させたつもりでも、このキャッシュ機能が原因で設定結果が反映されてないかのような振る舞いをすることがあります。

httpdの設定の変更を行っても、コンテンツデータのタイムスタンプが変更になっていなければWebブラウザはサーバー上のデータを読み込みませんから、サーバー上のデータを読み込むときに実現される設定は確認することができないわけです。

従って、httpdの設定を行い、Webブラウザで動作確認を行う際は、キャッシュデータを読み込みに行かないように操作しなければならないことがありますので注意してください。

ホスト情報の表示　 　全ページリストへ　 　お便利用語リスト

文字化けにはこだわらない

クライアント 側の Webブラウザ でしばしば見られる「文字化け」ですが、その原因のほとんどはドキュメントルート上の HTML ファイルの記述で使われている 文字セット と、Webブラウザが表示に用いようとしている文字セットが一致していないことが原因です。

Webブラウザが表示に用いる文字セットは、 "/etc/httpd/conf/httpd.conf" の "AddDefaultCharset" ディレクティブ で明示的に指定がない場合、htmlデータのヘッダ情報 に従います。

ただ、理由はよく解りませんが、httpdの設定やhtmlヘッダの記述に間違いがなくても、指定とは異なる文字セットでWebブラウザが動作して文字化け画面になってしまうケースが 時々 発生します。

もちろん設定や記述に誤りがあれば、ほぼ間違いなく文字化けを起こしますので、それが原因不明の文字化けなのか、設定や記述の誤りによるものなのかは容易に判定がつくはずです。

「コンピュータはデジタルデータを扱うのだから、きちんと指示すれば正確に動作するもの。」

という考え方は、このケースに関して言えば当てはまりませんから、

「動作がおかしいということは、きっと設定どこかに間違いがあるはず。」

と、杓子定規に考えて、余計なチェックに神経を使いすぎないようにしましょう。

ときたま起こる文字化けは、決して異常なことではありません。

ホスト情報の表示　 　全ページリストへ　 　お便利用語リスト

意外な落とし穴「パーミッション」

"/etc/httpd/conf/httpd.conf" の編集に「ハマって」しまうと、どうしてもそこばかりに目が行ってしまいがちになります。

きちんと設定しているはずなのに、 httpd がどうしても思ったとおりの動作をしてくれないときは、一度"/etc/httpd/conf/httpd.conf"を閉じて、周囲に目を配ってみてください。原因は意外に他の部分にあることが珍しくありません。

その「他の部分」の原因の筆頭は パーミッション です。

httpdはあくまで 構築中のLinuxサーバー 上で動作する アプリケーション に過ぎませんので、 OS である WBEL や CentOS のパーミッションを無視した動作を行うことはできません。

「httpdの設定ではきちんとアクセス許可を行っているのに、どういうわけかページが表示されない。」

で、２時間も３時間も設定ファイルをいじくり繰り回したあげく、実はドキュメントルートのディレクトリのパーミッションが "644" のままだった、というオチは珍しいことではありません。

ホスト情報の表示　 　全ページリストへ　 　お便利用語リスト

大文字小文字は「別の文字」

WindowsOS や MacintoshOS などの一般的な クライアント 向け OS では、フォルダ名やファイル名に使う英文字の大文字と小文字が区別されません。

例えば、 "photo.html" と "Photo.html" は同じファイル名として扱われます。

しかし、 LinuxOS などの UNIX 系OSは、大文字と小文字は「別の文字」と解釈されますので、これらは別のファイルとして扱われます。

つまり、 コンテンツ データを作成するとき、"Photo.html"に対するリンクを"photo.html"で記述した場合、作成中のWindowsOSやMacintoshOSなどの操作環境では問題なく参照できますが、これを FTPクライアント でそのまま サーバー に アップロード すると参照できなくなってしまうわけです。

これを良く理解していないと、サーバー上での不具合と勘違いしてしまうことになりかねません。

httpd に限らず、異なるOS間でデータの送受信を行う場合には、この点を良く理解して作業してください。

ホスト情報の表示　 　全ページリストへ　 　お便利用語リスト

CGIの憂鬱

「 CGI スクリプト が Webサーバー 上で動かない！。」

というのは、Webサーバーの構築で最も多いトラブルの一つでしょう。

CGIスクリプトは通常、 Perl などの 「本来Webサーバー上で使われる目的のものではない インタープリタ 」 を用いる関係で、エラーが発生してもその原因を Webサーバーとしての観点から 得ることができません。

従って動作しない原因が何処にあるのかが非常にわかり難いため、その都度原因となりそうな部分を手当たり次第探し回る羽目に陥りやすいわけです。

Webサーバー上で、Perlを用いるCGIが実行できる条件としては、

１．サーバーにPerlがインストールされていること。

２．CGIスクリプトの冒頭に記述するPerlのインストールパスが正しいこと。

３．CGIスクリプトの改行コードが UNIX 形式になっていること。

４．CGIスクリプトファイルの拡張子が、"AddHandler cgi-script" ディレクティブ で設定されているものと一致していること。

５．CGIスクリプトが、"ScriptAlias"ディレクティブ で指定されたディレクトリ、あるいは、"Options"ディレクティブで"ExecCGI"オプション が有効になっているディレクトリに配置されていること。

６．ドキュメントルートの場合、CGIスクリプトに、任意の アカウント に対する実行許可の パーミッション が設定されていること。

６'．ユーザーディレクトリの場合、CGIスクリプトの所有者がその ユーザーアカウント で、なおかつそのユーザーアカウントに対して 実行許可の パーミッション が設定されていること

を全て満たす必要があります。

４〜６(６')は、この コンテンツ の解説を参考にチェックすればOKです。

１．は、明示的にPerlを除外して WBEL や CentOS を インストール しない限りは、間違いなくインストールされているはずです。

２．は "/usr/bin/perl" がインタープリタの位置になりますから、CGIスクリプトファイルの先頭に "#!/usr/bin/perl" と記述されていることを確認するだけです。

問題は３．です。

実は、 テキスト ファイルの 改行コード は OS によってまちまちです。

例えば MacintoshOS では CR 、 WindowsOS では CR+LF 、 LinuxOS などの UNIX 系OSでは、 LF がそれぞれ改行コードとして使われています。

従って、MacintoshOS上やWindowsOS上で記述したCGIスクリプトをそのまま FTPクライアント で 構築中のLinuxサーバー に アップロード してしまうと、実行時にエラーになってしまうわけです。

これはアップロードのときに アスキー形式 を指定しておけばいずれも LF に変換されるはずですが、これがよく解らないままアップロードしてしまうと「何故か実行できない」という状態に陥ってしまいがちになります。

いずれにしても、動作確認の一番手っ取り早い方法は、

「確実に実行可能なCGIスクリプトをサーバー上に準備しておく。」

に限ります。これをCGIを設置したい場所にコピーして実行してみれば、問題点は直ぐにわかるようになります。

まず、 nanoエディタ を起動して、以下のテキストをタイプしてください。

nanoで"test.cgi"を作成

タイプが終わったら保存してnanoエディタを終了します。

次に、 プロンプト 上でこのCGIスクリプトを実行してみます。

このような結果が返ってくれば、"test.cgi"はCGIスクリプトとして、書式や改行コードには問題がないことが確認できたことになります。

最後に、この"test.cgi"に実行許可のパーミッションを設定します。

[tanaka@web1 ~]$ chmod 755 test.cgiEnter [tanaka@web1 ~]$ ls -lEnter 合計 4 -rwxr-xr-x　　1 tanaka　 tanaka　　　　128　2月 13 18:09 test.cgi [tanaka@web1 ~]$

作成が終わったら、例えば "ScriptAlias" を利用する場合は、ディレクティブの設定に従って "/var/www/cgi-bin/" に、この"test.cgi"をコピーします。

[tanaka@web1 ~]$ cp test.cgi /var/www/cgi-bin/Enter [tanaka@web1 ~]$

この"test.cgi"は、上に挙げたCGI実行条件の１〜３と６は既に満たしています。

従って、もしも クライアント の Webブラウザ から、

"http://www.obenri.com/cgi-bin/test.cgi"

にアクセスして、大きく "Hello!" と表示されない場合は、４または５のいずれかが原因、という具合に問題点の範囲を狭めることができるようになります。

という訳ですから、こういったテスト用CGIスクリプトは是非準備しておくことをお勧めします。

ホスト情報の表示　 　全ページリストへ　 　お便利用語リスト