Apacheの最近のブログ記事

Apacheのベーシック認証において、ユーザ名、パスワードの入力ミス等で認証に失敗すると、以下のエラーメッセージが表示される。

401 Authorization Required
Authorization Required

This server could not verify that you are authorized to access the document requested. Either you supplied the wrong credentials (e.g., bad password), or your browser doesn't understand how to supply the credentials required.
Apache/2.2.3 (CentOS) Server at nobuneko.com Port 80

正しいユーザ名、パスワードを入力すればエラーは解消され、閲覧したいページが見えるはず。
※入力の際には、大文字と小文字、半角と全角も区別されるので注意が必要。

正しいユーザ名、パスワードを入力していても表示できない場合は、以下の原因があるかもしれない。
・パスワードファイルがない、またはパスワードファイルの設置場所が間違っている。
・サーバに設定したユーザ名、パスワードとは異なるユーザ名、パスワードをサーバ管理者がユーザに間違って通知してしまった。

多くの場合がユーザの入力ミスが原因で認証エラーになっているだけだと思うが・・・。

Apacheのhttpd.confの記述に問題がないはずであるのに、Apacheが起動できない時がある。

httpd.confに問題がない場合は、Apacheの設定が間違っているのではなく、別の問題でApacheが起動できない可能性がある。

例えば、Windowsのイベントログのアプリケーションログに、以下のエラーが記載されいてる場合。

The Apache service named  reported the following error:
>>> Unable to open logs

このエラーメッセージを最初に見た時、

「Unable to open logsというのは、Apacheのログを開くことができない、ってことかな。ということは、Apacheのログファイルを保存しているフォルダの中身をApacheのプログラムからは参照できない権限設定になっているのかなぁ。ログなんだから、参照権限だけではダメで、書き込みもできないといけないよなぁ。何をどう設定したらよいのだろう…。よし、とりあえず、ログフォルダの権限をEveryoneユーザでフルコントロールにしてみよう。あれ、でも、Apacheの設定でログフォルダの権限設定など一度もやったことがないけど、何故、今回は必要なんだろう???」

…と思って、そうやってみたのだが、全く解決しない。

ふと、コマンドプロンプトを開き、netstatを見てみると、何故か80番ポートが使用中。

今、Apacheを設定しようとしているOSは、Windows Server 2003ということを思い出し、大事なことを思い出した。Windows Server 2003で80番ポートを使用するサービス…それは、IISだ。

Windowsの「サービス」を開き、「World Wide Web Publishing Service」(IIS)の項目を見てみると、「開始」になっていた。これを「停止」すると、あっさりApacheの起動に成功。

何故、停止していたIISが起動してしまったのかは、別次元の問題で考えないといけないのだが、それよりも、Apacheのエラーメッセージ「Unable to open logs」に惑わされて、ログフォルダの権限設定などをしてしまったのが悔しい。普段、ログフォルダの権限設定などしないのだから、そこに問題がある可能性は低い、ということをさっさと見切って、別の原因にすぐに気づくことができるレベルに到達しなくては…。

Linux(例:CentOS 5)でApacheをソースからインストールするためにconfigureを実行すると、

configure: error: in `/var/tmp/httpd-2.2.17/srclib/apr':
configure: error: no acceptable C compiler found in $PATH

というエラーが出てconfigureに失敗することがある。

《例》
[root@nobuneko local]# cd /var/tmp/httpd-2.2.17
[root@nobuneko httpd-2.2.17]# ./configure --prefix=/usr/local/apache2 --enable-so
checking for chosen layout... Apache
checking for working mkdir -p... yes
checking build system type... x86_64-unknown-linux-gnu
checking host system type... x86_64-unknown-linux-gnu
checking target system type... x86_64-unknown-linux-gnu

Configuring Apache Portable Runtime library ...

checking for APR... reconfig
configuring package in srclib/apr now
checking build system type... x86_64-unknown-linux-gnu
checking host system type... x86_64-unknown-linux-gnu
checking target system type... x86_64-unknown-linux-gnu
Configuring APR library
Platform: x86_64-unknown-linux-gnu
checking for working mkdir -p... yes
APR Version: 1.4.2
checking for chosen layout... apr
checking for gcc... no
checking for cc... no
checking for cl.exe... no
configure: error: in `/var/tmp/httpd-2.2.17/srclib/apr':
configure: error: no acceptable C compiler found in $PATH
See `config.log' for more details.
configure failed for srclib/apr

「no acceptable C compiler found」というエラーメッセージより、Cコンパイラが見つからない、ということが分かるので、yumなどでCコンパイラをインストールする。

[root@nobuneko httpd-2.2.17]# yum install gcc
Loaded plugins: fastestmirror
Loading mirror speeds from cached hostfile
 * base: www.ftp.ne.jp
 * extras: www.ftp.ne.jp
 * updates: www.ftp.ne.jp
base                                                                                       | 2.1 kB     00:00    
extras                                                                                     | 2.1 kB     00:00    
updates                                                                                    | 1.9 kB     00:00    
Setting up Install Process
Resolving Dependencies
--> Running transaction check
---> Package gcc.x86_64 0:4.1.2-50.el5 set to be updated
--> Processing Dependency: glibc-devel >= 2.2.90-12 for package: gcc
--> Running transaction check
---> Package glibc-devel.x86_64 0:2.5-58.el5_6.4 set to be updated
--> Processing Dependency: glibc-headers = 2.5-58.el5_6.4 for package: glibc-devel
--> Processing Dependency: glibc = 2.5-58.el5_6.4 for package: glibc-devel
--> Processing Dependency: glibc-headers for package: glibc-devel
--> Running transaction check
--> Processing Dependency: glibc = 2.5-58.el5_6.3 for package: nscd
---> Package glibc.i686 0:2.5-58.el5_6.4 set to be updated
--> Processing Dependency: glibc-common = 2.5-58.el5_6.4 for package: glibc
---> Package glibc.x86_64 0:2.5-58.el5_6.4 set to be updated
---> Package glibc-headers.x86_64 0:2.5-58.el5_6.4 set to be updated
--> Processing Dependency: kernel-headers >= 2.2.1 for package: glibc-headers
--> Processing Dependency: kernel-headers for package: glibc-headers
--> Running transaction check
---> Package glibc-common.x86_64 0:2.5-58.el5_6.4 set to be updated
---> Package kernel-headers.x86_64 0:2.6.18-238.12.1.el5 set to be updated
---> Package nscd.x86_64 0:2.5-58.el5_6.4 set to be updated
--> Finished Dependency Resolution

Dependencies Resolved

==================================================================================================================
 Package                      Arch                 Version                            Repository             Size
==================================================================================================================
Installing:
 gcc                          x86_64               4.1.2-50.el5                       base                  5.3 M
Installing for dependencies:
 glibc-devel                  x86_64               2.5-58.el5_6.4                     updates               2.4 M
 glibc-headers                x86_64               2.5-58.el5_6.4                     updates               594 k
 kernel-headers               x86_64               2.6.18-238.12.1.el5                updates               1.2 M
Updating for dependencies:
 glibc                        i686                 2.5-58.el5_6.4                     updates               5.3 M
 glibc                        x86_64               2.5-58.el5_6.4                     updates               4.8 M
 glibc-common                 x86_64               2.5-58.el5_6.4                     updates                16 M
 nscd                         x86_64               2.5-58.el5_6.4                     updates               167 k

Transaction Summary
==================================================================================================================
Install       4 Package(s)
Upgrade       4 Package(s)

Total download size: 36 M
Is this ok [y/N]: y
Downloading Packages:
(1/8): nscd-2.5-58.el5_6.4.x86_64.rpm                                                      | 167 kB     00:00    
(2/8): glibc-headers-2.5-58.el5_6.4.x86_64.rpm                                             | 594 kB     00:00    
(3/8): kernel-headers-2.6.18-238.12.1.el5.x86_64.rpm                                       | 1.2 MB     00:00    
(4/8): glibc-devel-2.5-58.el5_6.4.x86_64.rpm                                               | 2.4 MB     00:01    
(5/8): glibc-2.5-58.el5_6.4.x86_64.rpm                                                     | 4.8 MB     00:02    
(6/8): gcc-4.1.2-50.el5.x86_64.rpm                                                         | 5.3 MB     00:03    
(7/8): glibc-2.5-58.el5_6.4.i686.rpm                                                       | 5.3 MB     00:03    
(8/8): glibc-common-2.5-58.el5_6.4.x86_64.rpm                                              |  16 MB     00:09    
------------------------------------------------------------------------------------------------------------------
Total                                                                             1.6 MB/s |  36 MB     00:23    
Running rpm_check_debug
Running Transaction Test
Finished Transaction Test
Transaction Test Succeeded
Running Transaction
  Updating       : glibc-common                                                                              1/12
  Updating       : glibc                                                                                     2/12
  Installing     : kernel-headers                                                                            3/12
  Updating       : glibc                                                                                     4/12
  Updating       : nscd                                                                                      5/12
  Installing     : glibc-headers                                                                             6/12
  Installing     : glibc-devel                                                                               7/12
  Installing     : gcc                                                                                       8/12
  Cleanup        : glibc-common                                                                              9/12
  Cleanup        : glibc                                                                                    10/12
  Cleanup        : glibc                                                                                    11/12
  Cleanup        : nscd                                                                                     12/12

Installed:
  gcc.x86_64 0:4.1.2-50.el5                                                                                      

Dependency Installed:
  glibc-devel.x86_64 0:2.5-58.el5_6.4                        glibc-headers.x86_64 0:2.5-58.el5_6.4              
  kernel-headers.x86_64 0:2.6.18-238.12.1.el5              

Dependency Updated:
  glibc.i686 0:2.5-58.el5_6.4       glibc.x86_64 0:2.5-58.el5_6.4      glibc-common.x86_64 0:2.5-58.el5_6.4    
  nscd.x86_64 0:2.5-58.el5_6.4    

Complete!

これで、Cのコンパイラのインストールが完了。

この後、再度configureを実行すると、エラーにならず、configureに成功した。

Apacheの設定ファイル(httpd.conf)を修正してApacheを再起動すると、「DocumentRoot must be a directory」というエラーメッセージが表示されてApacheの再起動に失敗し、Apacheが停止してしまった。

《例》
[root@nobuneko conf]# /etc/rc.d/init.d/httpd restart
httpd を停止中:                                            [失敗]
httpd を起動中: Syntax error on line 283 of /etc/httpd/conf/httpd.conf:
DocumentRoot must be a directory
                                                           [失敗]

エラーメッセージ「DocumentRoot must be a directory」は、直訳すると「ドキュメントルートは、ディレクトリにする必要がある」ということなので、httpd.confでのDocumentRootの設定に誤りがあるのだろう。

/etc/httpd/conf/httpd.confの238行目を見ると
DocumentRoot "/var/www/html"
となっていた。

確認をすると、wwwディレクトリもhtmlディレクトリも作っていなかった。

httpd.confでドキュメントルートとして指定したディレクトリが存在しなかったので、「DocumentRoot must be a directory」というエラーメッセージが出ていたことが分かった。

ディレクトリを作成すると、Apacheの起動に成功した。

Windows版Apacheの起動を試みた際に

Error
The requested operation has failed!

といったエラーダイアログだけが出て、何故起動に失敗したのかが分からなくて困る時がある。

まず、httpd.confの記述に間違いがあるかどうかを調べるべきなので、Linuxの「apachectl configtest」コマンドのようにhttpd.confの記述をチェックする機能を使用してみることにする。

LinuxだろうとWindowsだろうとApacheなのだから、たぶん、できるはずだ。

[スタート]→[すべてのプログラム]→[Apache HTTP Server 2.2]→[Configure Apache Server]→[Test Configuration]で、httpd.confのチェックができそうだったので試してみた。

しかし、一瞬、コマンドプロンプトっぽい画面が表示されて、すぐ消えてしまうので、何が何だか分からない。

コマンドプロンプトが一瞬で消えなければよいので、[Test Configuration]を右クリック→[プロパティ]で、「Test Configurationのプロパティ」の[ショートカット]タブを見ると、リンク先に以下の記述があることを確認した。

C:\Apache2.2\bin\httpd.exe -w -t -f "C:\Apache2.2\conf\httpd.conf" -d "C:\Apache2.2\."

※「C:\Apache2.2」の部分は、インストール時に指定できるので、インストール状況により異なる。

Windows版Apacheでのconfigtestの方法は、上記のコマンドをコマンドプロンプトで実行する、ということで良さそうだ。

よし、このショートカットのリンク先をコマンドプロンプトで実行すれば、実行結果が一瞬で消えることなくゆっくりと見ることができそうだ。

《コマンドプロンプトでの実行結果例》
Microsoft Windows [Version 6.1.7601]
Copyright (c) 2009 Microsoft Corporation.  All rights reserved.

C:\Users\NEKO>C:\Apache2.2\bin\httpd.exe -w -t -f "C:\Apache2.2\conf\httpd.conf" -d "C:\Apache2.2\."
Warning: DocumentRoot [C:/Apache2.2/docs/dummy-host.demo] does not exist
Warning: DocumentRoot [C:/Apache2.2/docs/dummy-host2.demo] does not exist
httpd.exe: Could not reliably determine the server's fully qualified domain name, using 192.168.11.177 for ServerName
Syntax OK

コマンドプロンプトに表示されたメッセージに基づき、httpd.confの設定を修正すれば良いことが分かる。

さて、このメッセージに基づき、ダメな部分は全て修正した・・・が、修正する前から、エラーメッセージの末尾にでている「Syntax OK」というメッセージを見て、修正してもApacheの起動には失敗するな、ということが分かってしまった。

Syntax OK」が出ていれば、httpd.confの文法上の間違いはない、ということになる。

だから、Apacheが起動できない原因は、他にあることになる。

イベントビューアを見ると、以下のエラーを確認できた。

エラー 2012/02/09 3:42:50 Apache Service 3299 なし

ログの名前:Application
ソース:Apache Service
日付:2012/02/09 3:42:50
イベント ID:3299
タスクのカテゴリ:なし
レベル:エラー
キーワード:クラシック
ユーザー:N/A
コンピューター:NEKO
説明:
The Apache service named  reported the following error:
>>> (OS 10048)通常、各ソケット アドレスに対してプロトコル、ネットワーク アドレス、またはポートのどれか 1 つのみを使用できます。: make_sock: could not bind to address 0.0.0.0:80

さらに、他に3つのエラーが出ていた。(以下に、エラーメッセージのみ記載する。)

The Apache service named  reported the following error:
>>> no listening sockets available, shutting down   

The Apache service named  reported the following error:
>>> Unable to open logs    

Apache2.2 サービスは、サービス固有エラー ファンクションが間違っています。 で終了しました。

1つ目のエラーメッセージ「通常、各ソケット アドレスに対してプロトコル、ネットワーク アドレス、またはポートのどれか 1 つのみを使用できます。: make_sock: could not bind to address 0.0.0.0:80」と2つ目のエラーメッセージ「no listening sockets available, shutting down」で、原因が分かった。

Apacheが使用しようとしている80番ポートが既に、何らかのアプリケーションで使用されている、ということだ。

以前、IISが起動していて、Apacheが起動できない、という問題があった。(参照「Windows版Apacheのエラー「Unable to open logs」の原因の1つと解決方法」)

しかし、前回と異なり、今回はIISなど入っていないWindows 7だ。

そこで思い出したのが、Skypeだ。このSkypeが80番ポートを使っている、ということを思い出した。

何故思い出したかというと、実は、以前、SkypeのせいでApacheが起動できない、ということで困ったことがあったからだ。その困ったことを忘れていた・・・。

Skypeを終了したら、Apacheの起動に成功した。

過去に悩んだことと同じことで、数時間もハマるのは、アホらしいなぁ・・・と悔しい思いをしつつも、風邪っぽい症状で夜9時から寝たが午前2時頃に目覚めて頭が痛くて眠れないため、Apacheでも触って少し起きようと思ったのが、間違っているんだ、こんな状況だとまともに頭が働かないから仕方がないとか、言い訳を考えてみたり、Windows版Apacheでのconfigtestの方法をたまたま知る良いきっかけにもなったので、良しとするか、と前向きに考えながら・・・再び寝ることにする。今は熱は36.0度になったが、まだ頭痛が続いているから、寝ないといけないなぁ・・・。

今さらだが、先ほど、当ウェブサイトの404ページの設定を行った。

.htaccessファイルでの404ページの設定方法は、以下となる。

(1)ウェブサービスがApacheで提供されていることを確認する。

.htaccessファイルを使用するには、ウェブサービスがApacheで提供されている必要がある。

(2)Apacheの設定が、.htaccessが使用できる設定になっているかを確認する。

ウェブサイトをホスティングしているサーバ(レンタルサーバ、自社サーバ、自宅サーバ等)のApacheの設定が、.htaccessが使用できる設定になっているかを確認する。

レンタルサーバなどは、ヘルプページ、FAQページなどに、.htaccessが使用できるかどうかを掲載している場合があるので、よく分からない場合は、そのようなページを確認すると良いと思う。

(3).htaccessファイルを作成する。

ファイル名が

.htaccess

(ドットエイチーティーアクセス)

となるテキストファイルを作成する。

Windows PCのデスクトップ等で「.htaccess」というファイル名で作成しようとすると、

「ファイル名を入力してください」

という警告ダイアログが出て作成できないので、そのような場合は、Windowsの「メモ帳」を開き、

ファイル>名前を付けて保存>ファイルの種類>すべてのファイル

と選択し、「ファイル名」欄で「.htaccess」と入力して保存すれば、「.htaccess」というファイル名のファイルを作成することができる。

(4).htaccessファイルで404ページとして表示したいページを指定する。

《書式》
ErrorDocument 404 /表示させたいファイルへのパス

《例》
ErrorDocument 404 /error404.html

(5).htaccessファイルをウェブサイトにFTP等でアップロードする。

以上で終わりとなる。

※.htaccessでの設定となるため、設定はすぐに反映される。Apacheの再起動は不要。

さて、話が前後するが、404ページとは、ウェブサイトで存在しないページ(URL)を開こうとした時に表示されるページのことだ。

例えば、当ウェブサイトでは、

http://nobuneko.com/blog/

というURLは存在するが、

http://nobuneko.com/blog/nekonekoneko/

というURLは存在しない。

このような存在しないURLを開こうとした時、Internet Explorer 9だと

Web ページが見つかりません
 HTTP 404

可能性のある原因:

  • アドレスに入力の間違いがある可能性がある。
  • リンクをクリックした場合には、リンクが古い場合があります。

対処方法:
 アドレスを再入力する。
 前のページに戻る。
 メインのサイトに移動して必要な情報を探す。

といったエラーページが表示される。

このエラーページは、ウェブサービスを提供するミドルウェアの設定を変更することで、ウェブサイト提供側で内容を変更することができる。

当ホームページでは、404エラーページの設定をこれまで行っていなかったので、Internet Explorer等のブラウザが用意したエラーページを表示させていたのだが、本日より、私が用意したエラーページを表示させるようにしてみた。

何で今さら……とも思うが、たまには、そういったウェブサイトのメンテナンスらしきことも気分転換がてらやってみたい時もある。

当ウェブサイトは、現在、XREAというレンタルサーバを使用しているので、ウェブサービスを提供しているミドルウェアは、Apacheだ。

Apacheの設定を変更することで、404ページの設定を変更できるが、XREAは共用サーバであり、私にはApacheの設定を好き勝手に変更できるような権限は与えられていない。

その代わり、

.htaccess

というテキストファイルで、当ウェブサイト内(自ドメイン内)に限定してApacheの設定を変更できる。

レンタルサーバのApacheの設定によっては.htaccessが使用できない場合もあるが、XREAは.htaccessが使用できる。

.htaccessは大変便利だ。

.htaccessの場合、設定の反映のために、Apacheの再起動をする必要もない。

FTPソフトで、.htaccessをサーバにアップロードしたら、その時からすぐに設定が反映される。

便利な反面、サーバ内に.htaccessファイルを色々なディレクトリに設置し、設置したことも忘れてしまい、サーバ管理がよく分からないことになる……といったことにもなるだろうけれど、個人的にレンタルサーバで使う分には、大変便利だと思う。

同一のHTMLファイルをブラウザで閲覧しているにもかかわらず、閲覧するブラウザの種類によっては、以下のような生のHTMLソースが表示されてしまうことがある。

<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN"
    "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
<html xmlns="http://www.w3.org/1999/xhtml" id="sixapart-standard">
<head>
    <meta http-equiv="Content-Type" content="text/html; charset=euc-jp" />
<meta name="generator" content="Movable Type Pro 4.25" />
<link rel="stylesheet" href="http://nobuneko.com/blog/styles-site.css" type="text/css" />
<link rel="start" href="http://nobuneko.com/blog/" title="Home" />
<link rel="alternate" type="application/atom+xml" title="Recent Entries" href="http://nobuneko.com/blog/atom.xml" />
<script type="text/javascript" src="http://nobuneko.com/blog/mt-site.js"></script>


    <link rel="EditURI" type="application/rsd+xml" title="RSD" href="http://nobuneko.com/blog/rsd.xml" />
    <title>r_nobuホームページ</title>
</head>

〜〜〜(以下略)〜〜〜

このように、HTMLファイルがブラウザによってHTMLページとして処理されず、まるでテキストファイルのように生の情報がそのまま表示される場合、Webサーバ側の設定でHTMLファイルをどのように処理するのか、という設定がきちんとできていないことを疑う必要がある。

Webサーバで使用しているWebサービスのソフトウェアがApacheの場合、以下の設定を確認し、対応していくことになる。

(1)MIME typeの設定

MIME typeは、mime.typesというファイルで設定する。

mime.typesファイルは、Windows版のApach 2.2の場合はApacheのインストールフォルダ配下のconfフォルダ直下、(Linuxの)CentOS 5でパッケージインストールをしたものであれば、/etcディレクトリ直下にある。

mime.typesファイルを(catコマンド、viコマンド等で)確認し、

text/html                       html htm

となっていれば、問題ない。

※左側の「text/html」が「Content-Type」(コンテントタイプ)で、右側の「html htm」がファイルの拡張子を表す。上記の記述になっている場合、.html拡張子、.htm拡張子のファイルをコンテントタイプ「text/html」としてApacheが扱うことを意味している。

上記の設定になっていなければ、まずは、何故、上記のようになっていないかの理由を確認した上で、上記の設定にする。(理由を確認できない場合は、このファイルでの修正は見送り、.htaccessで修正対応をする、といったことを検討した方が良い場合もある。)

※設定を変更した場合は、Apacheを再起動して設定を反映する必要がある。

(2).htaccessの設定

もし、.htaccessファイル内に

RemoveType .html .htm

といった記述があった場合、Apacheの設定ファイル「mime.types」 で記述されている、.html拡張子、.htm拡張子のファイルの「Content-Type」(コンテントタイプ)の定義が削除されていることを意味する。

RemoveTypeは、何らかの理由で、拡張子に関連付いている「Content-Type」(コンテントタイプ)を削除したい場合に使うことがある。

例えば、上位ディレクトリに設置した.htaccessで、

AddType application/x-httpd-php .html .htm .php

と記述し、.html、.htm、.phpといった拡張子のファイルに「application/x-httpd-php」という「Content-Type」を設定していた場合、これらのファイルは、PHPとして動作させることができる。

しかし、下位ディレクトリにおいては、.html、.htm拡張子のファイルは、PHPとして動作させたくない、つまり、「application/x-httpd-php」という「Content-Type」を削除したい場合がある。そのような時に、PHPとして動作させたくないディレクトリに.htaccessファイルを設置し、同ファイル内でRemoveTypeの記述を行って対処することがある。

この時に見落としがちなのが、

RemoveType .html .htm

とすると、上位ディレクトリの.htaccessファイルで定義されている「Content-Type」だけを削除するのではなく、Apacheの設定ファイル「mime.types」 で記述されている

text/html html htm

といった標準の「Content-Type」も削除されてしまうことだ。

そのため、.html拡張子、.htm拡張子のファイルは、ApacheではHTMLファイルとして扱われず、.txt拡張子のファイルと同じ、つまり、「Content-Type」が「text/plain」として処理されるため、ブラウザでHTMLファイルを開いた時にHTMLソースが丸見えになってしまう。

この問題を解決するには、

RemoveType .html .htm

の記述の後で、

AddType text/html .html .htm

として、.html拡張子、.htm拡張子のファイルの「Content-Type」を「text/html」と再定義すれば良い。

そうすれば、HTMLファイルとして処理されるようになるので、HTMLソース丸見えの問題は解決する。

※.htaccessファイルの修正を行った場合は、Apacheの設定ファイルとは異なり、Apacheの再起動は不要。

Apacheでウェブサービスを運用している時に、シンボリックリンクを設定したディレクトリやファイルを利用したい時がある。

その時に、Apacheのコンフィグファイルであるhttpd.conf、あるいは、.htaccessファイルでの設定が不適切な場合、シンボリックリンクのページへのアクセスができず、

Symbolic link not allowed or link target not accessible: /home/nobuneko

といったエラーが発生することがある。

このようなエラーが発生してしまった場合、まずは、

1)シンボリックリンクの設定に誤りがないかどうか

2)リンク先が閲覧できないようなパーミッションになっていないかどうか

を確認する。

上記2点どちらも問題ない場合は、

3)httpd.fonfファイル、あるいは、.htaccessファイルで「Options」という設定項目に「FollowSymLinks」の記載があるかどうか

を確認する。

FollowSymLinksとは、読んで字のごとくかもしれないが、「シンボリックリンクを許可する」という意味の設定項目だ。

Options項目に、この「FollowSymLinks」の記述がある場合はシンボリックリンクを許可し、記述がないバイは、シンボリックリンクを許可しないことが分かる。

したがって、Options項目に「FollowSymLinks」の記述がない場合は、「FollowSymLinks」を追記することで、Symbolic link not allowed or link target not accessible: /home/nobunekoというエラーを解消できる。

《例》
Options -Indexes

Options -Indexes FollowSymLinks

※httpd.confファイルを修正した場合は、Apacheの再起動が必要。.htaccessファイルを修正した場合は、Apacheの再起動は不要。

Webサイトから何らかのファイルをダウンロードしようと思って、Linuxコンソールで

wget http://nobuneko.com/blog/index.html

というコマンドを実行すると、 

「failed: ホストへの経路がありません」

あるいは

「エラー 502: Cannot Connect」

といったエラーになり、wgetに失敗する場合がある。

そのような場合は、なんと、そのWebサイトはブラウザでの閲覧すらできない(ことがほとんどだと思う)。

接続不可の原因を確認するためには、

1)ネットワーク内のファイアウォールで80番ポートでの通信(HTTP接続)が許可されているかどうか

2)Webサイトをホスティングしているサーバのファイアウォールの設定を確認し、80番ポートでの通信(HTTP接続)が許可されているかどうか

を確認する。

1)に問題がなければ、2)の確認になる。

2)は、サーバのOSごとに確認方法が異なる。

Windowsのファイアウォール機能は、「コントロールパネル」などから探して確認する。サードパーティのセキュリティソフトがインストールされている場合は、そちらの設定も問題がないかどうかを確認する必要がある。

Linuxのファイアウォール機能は、iptablesが有効になっていないかどうかを確認すると手っ取り早い。

iptablesの機能が有効になっているかどうかは、「/etc/rc.d/init.d/iptables status」というコマンドで確認できる。

《CentOS 6.2でのiptablesの実行状況確認例》
<iptablesの機能が有効の場合の例>
[root@nobuneko home]# /etc/rc.d/init.d/iptables status
テーブル: filter
Chain INPUT (policy ACCEPT)
num  target     prot opt source               destination
1    ACCEPT     all  --  0.0.0.0/0            0.0.0.0/0           state RELATED,ESTABLISHED
2    ACCEPT     icmp --  0.0.0.0/0            0.0.0.0/0
3    ACCEPT     all  --  0.0.0.0/0            0.0.0.0/0
4    ACCEPT     tcp  --  0.0.0.0/0            0.0.0.0/0           state NEW tcp dpt:22
5    REJECT     all  --  0.0.0.0/0            0.0.0.0/0           reject-with icmp-host-prohibited

Chain FORWARD (policy ACCEPT)
num  target     prot opt source               destination
1    REJECT     all  --  0.0.0.0/0            0.0.0.0/0           reject-with icmp-host-prohibited

Chain OUTPUT (policy ACCEPT)
num  target     prot opt source               destination

<iptablesの機能が無効の場合の例>
[root@nobuneko home]# /etc/rc.d/init.d/iptables status
iptables: ファイアウォールが稼働していません。

iptablesの設定がよく分からない場合、iptablesの設定によりwgetが失敗しているかどうかを切り分けたいだけであれば、

/etc/rc.d/init.d/iptables stop

とコマンドを叩いてiptablesを無効化した上で、wgetを再度試してうまくいくかどうかを確認すると良いかもしれない。

CentOS 6.2インストール後のデフォルト状態では、iptables機能は有効になっており、外部からのHTTP接続は遮断されているようなので、CentOS 6.2でApacheを運用する場合は、iptablesの機能を無効にして運用するか、

/etc/sysconfig/iptablesを編集して、

-A INPUT -m state --state NEW -m tcp -p tcp --dport 80 -j ACCEPT

という行を追記して80番ポートでの接続(HTTPでの接続)を許可する設定とし、

/etc/rc.d/init.d/iptables restart

とコマンドを叩いてiptables機能を再起動する、といった方法をとることになる。

2012年5月

    1 2 3 4 5
6 7 8 9 10 11 12
13 14 15 16 17 18 19
20 21 22 23 24 25 26
27 28 29 30 31    

アーカイブ

カテゴリー