|
|
Webサーバーの構築
|
WebサーバーについてApacheの構成と設定の準備全般的な動作環境の設定コンテナディレクティブの形式コンテナディレクティブの設定ドキュメントルートの設定等ユーザーディレクトリの設定バーチャルホストの設定CGIの実行許可の設定ユーザー認証機能の設定httpdのコントロールhttpdの動作チェックポートフォワーディングの設定 |
全般的な動作環境の設定httpd は同時にいくつもの コンテンツ を公開したり、ひとつのコンテンツの中でも特定のディレクトリやファイルについてきめ細かい制御ができるようになっています。 しかしながらそういう個々の設定を行う前に、例えばhttpdの プロセス の制御など、全体的に決めておかなければならない事柄があります。 このパートではhttpdの主設定ファイル "/etc/httpd/conf/httpd.conf" の中から、そのような「httpdの動作全体に関係する部分」の設定を説明します。 もちろん、実際にhttpdを動作させるには、コンテンツ単位、あるいはディレクトリの範囲やファイルを指定した設定が必要となりますので、必ずこのパート以降もご一読ください。 ServerTokens〜クライアントに送り返す情報WBEL3 、 CentOS3 及び WBEL4、CentOS4では 43行目 あたり、CentOS5では 44行目 あたりに記述があります。 接続を要求してきた クライアント に対して、どの程度の サーバー 情報を回答するか、という ディレクティブ です。 通常この情報はクライアント側から直接見ることはできませんが、例えばサーバーエラーが発生したときなどに Webブラウザ に表示されることがあります。 デフォルトの、
では、以下のように表示されます。 構築中のLinuxサーバー の場合、具体的には(例:WBEL3)、 |
|||||||||||
|
|
ServerTokens Prod → Server : Apache ServerTokens Major → Server : Apache/2 ServerTokens Minor → Server : Apache/2.0 ServerTokens Min → Server : Apache/2.0.46 ServerTokens OS → Server : Apache/2.0.46 ("OSの名称") ServerTokens Full → Server : Apache/2.0.46 ("OSの名称") mod_perl/1.99_09 Perl/v5.8.0 ... となります。 一般的にいうと、この種の情報は第三者に知られても危険というわけではないので、デフォルトのままでも構いません。 とはいえ、こういう情報を外部に出したからといって、何かメリットがあるわけでもありません。 心配性の方は、
に設定を変更しておきましょう。 また、後ほど説明する "ServerSignature" ディレクティブを "Off" に設定することで、この"ServerTokens"ディレクティブの設定に関係なく、一切の情報表示を行わないようにすることもできます。 ServerRoot〜各種設定の基点ディレクトリWBEL3 、 CentOS3 及び WBEL4、CentOS4では 56行目 あたり、CentOS5では 57行目 あたりに記述があります。 httpd の設定ファイル、ログファイルなど、httpdが自分自身で参照したり、作成したりするディレクトリやファイルの基点となるディレクトリを設定する ディレクティブ です。 デフォルト は、
です。 従って、この"/etc/httpd/conf/httpd.conf"を含むhttpdの設定ファイルの中で、 相対パス で表記されているディレクトリやファイルは、ディレクトリ"/etc/httpd"が基点となります。 設定を変更する必要はありませんが、以後の設定に関係してきますから覚えておきましょう。 PidFile〜httpdのプロセスID記録ファイルの指定WBEL3 及び CentOS3 では 72行目 、WBEL4及びCentOS4では 62行目 、CentOS5では 63行目 あたりに記述があります。 WBELやCentOS上で動作するプログラムは、 OS がその動作を管理するためにID番号を割り振り、その番号をファイルとして記録します。 これを一般に Pidファイル と呼びますが、"PidFile"はそのファイルを具体的に指定する ディレクティブ です。 デフォルト は、
で、 相対パス になっています。 従って、 "ServerRoot" ディレクティブが"/etc/httpd"ですから、具体的には "/etc/httpd/run/httpd.pid" がPidファイルとして指定されていることになります。 ただし、ディレクトリ"/etc/httpd/run"は、 "/var/run" の シンボリックリンク ですから、実際のファイルの場所は "/var/run/httpd.pid" となります。 Timeout〜リクエストが返ってくるまでの待ち時間WBEL3 及び CentOS3 では 77行目 、WBEL4及びCentOS4では 67行目 、CentOS5では 68行目 あたりに記述があります。 |
|||||||||||
| これらのメソッドは、 HTML を テキスト で記述される方は良くご存知かもしれません。 |
一般に良く使われるのは、データをサーバーに送る "POST" と、その際にデータの置き換えを行う "PUT" 、そして取得に用いる "GET" などです。 これらのHTTPメソッドを利用する場合、データはクライアントから一度サーバーに送信され、その後にサーバーからクライアントに送信されることになりますが、通信が遅すぎて送受信に時間がかかりすぎたり、通信障害などによって途中で パケット が送られてこなくなってしまう場合があります。 もちろん httpd は、いつまで経っても受信が終わらない(あるいは永久に終わらないかもしれない)状態のまま待ち続けるわけにはいきませんから、適当なところで受信待ちをやめ、クライアントからのリクエストを失敗させてしまう必要があります。 "Timeout" は、この「待ち時間」を設定する ディレクティブ です。単位は「秒」です。 デフォルト では、WBEL3、CentOS3では、
WBEL4、CentOS4、CentOS5では
となっていますから、一つのHTTPメソッドが300秒、または120秒を経過すると無条件にリクエストを失敗させます。 この値を大きくすれば、httpdは我慢強く受信が終わるのを待ち続けることになります。 |
|||||||||||
|
|
しかし、このくらいの時間は、ほとんどのクライアントが既に「送信を諦めている」時間でもありますから、これより長い時間を設定してもまず意味がありません。 逆にこの値を小さくし過ぎると、速度が遅く接続が不安定な アナログ通信 のクライアントなどが不便を被ることになるかもしれません。 一般にこの"Timeout 300"あるいは"Timeout 120"という値は、お使いの ディストリビューション でのhttpdの運用上、過不足のない妥当な値とされていますので、特に変更する必要はないと思われます。 KeepAlive〜http接続の維持WBEL3 及び CentOS3 では 83行目 、WBEL4及びCentOS4では 73行目 、CentOS5では 74行目 あたりに記述があります。 一般に コンテンツ は、 Webサーバー 上の htmlファイル や、 サーバーサイドアプリケーション により出力されるデータ、及び多数の画像ファイルなどの組み合わせになってひとつのページが構成されています。 デフォルト の
では、それらのデータを一つ送信するごとに HTTP 接続を終了しますから、多量の画像ファイルが添付されているコンテンツの送信には時間がかかってしまいます。 そこでこの ディレクティブ は、一ヶ所の クライアント からのコンテンツ要求に対して、できるだけHTTP接続を維持できるように、 |
|||||||||||
| なぜデフォルトが "KeepAlive Off" になっているのかはよく解りませんが、古いHTTPの規格への対応とか、 httpd への動作負荷を減らすためとか、そういうことかもしれません。 |
に変更することをお勧めします。 また、このように設定を変更した場合には、次の"MaxKeepAliveRequests"ディレクティブが同時に有効になります。 MaxKeepAliveRequests〜KeepAliveの最大値WBEL3 及び CentOS3 では 90行目 、WBEL4及びCentOS4では 80行目 、CentOS5では 81行目 あたりに記述があります。 上記のKeepAlive ディレクティブ が "KeepAlive On" に設定されているとき、 クライアント からのコンテンツ要求に対して、 HTTP 接続を維持する最大リクエスト数を設定するディレクティブです。 デフォルト では、
になっていますが、普通はもっと大きな数値を設定したほうが良いとされています。もちろん数値が大きいほうがスムーズにデータを送信することができます。 この値を "0" にすると"無制限"になりますが、一般的に"無制限"という設定は、トラブルが発生したときの対処が難しくなることがありますので、一応の上限は定めておくべきでしょう。 無難なところでは、
くらいが良いと思われます。 KeepAliveTimeout〜HTTPを切断するまでの時間 |
|||||||||||
|
デーモン
を起動したときにメインとして稼動するプロセスを
「親プロセス」
、必要に応じて「親プロセス」が起動させるプロセスを
「子プロセス」
と呼ぶことがあります。
httpdの場合、個々のクライアントに対して接続を確立させるのはいうまでもなく「子プロセス」です。 |
WBEL3 及び CentOS3 では 96行目 、WBEL4及びCentOS4では 86行目 、CentOS5では 87行目 あたりに記述があります。 httpd は、接続を要求してくる クライアント に対して個々にhttpdのプロセスを起動して接続を確立させます。 クライアントは入れ替わり立ち代りやってきますから、接続をやめたクライアントとの接続プロセスは逐次終了しなければ、そのうち 構築中のLinuxサーバー は メモリ 不足に陥ってしまうでしょう。 ただ、だからといってあまり頻繁に接続を終了してしまうことは、例えば "http://www.obenri.com/" のサイトにとどまって、次々にページを開いてくれるような有難いクライアントにとっては、一ページごとに接続をやりなおすことになりますから逆にレスポンスの面でデメリットになります。 この、 「最後のリクエストに応えた後、接続プロセスを終了するまでにどのくらいの時間同じクライアントとの接続を維持しておくか。」 という値を設定するのが、"KeepAliveTimeout" ディレクティブ です。 デフォルト は以下のとおりで、単位は秒です。
この設定では大まかにいえば、クライアントが「15秒以内に次のページを開く」ような閲覧方法をとるような場合に、次々と小気味良くページが表示されることになります。 この値を大きくすれば、それだけクライアント側の快適さが向上しますが、大量のhttpdのプロセスを並行して稼動させなければならなくなりますので、 サーバー への負荷はかえって大きくなります。 |
|||||||||||
| 本当に誰もが見たがるホームページならば、わざわざそういう快適設定をしなくとも、ちゃんと見てくれるはずですね。本当のところは。 |
配信するコンテンツの内容にもよりますが、ホームページへのアクセスが少ない場合で、「コンテンツをじっくり見てもらいたい」場合でもおおよそ "60" 以下に設定します。それ以上長く設定しても「お客さんを捕まえておく」効果は変わりません。 |
|||||||||||
| データの配信速度が遅いと送信そのものに時間がかかりますから、その分 "KeepAliveTimeout" の値は小さくしなければならないというわけです。 |
サーバーの搭載メモリ
また、かなり良い ハードウェア 、通信環境であっても、毎日数千ページ以上のアクセスがあるような人気サイトを運営するような場合には、はやりデフォルトのままのほうが良いかもしれません。 Linten〜受け付けるIPアドレスとポート番号WBEL3 及び CentOS3 では 151行目 、WBEL4及びCentOS4では 133行目 、CentOS5では 134行目 あたりに記述があります。 httpd が扱う IPアドレス と ポート番号 を指定する ディレクティブ です。 httpdは コンテンツ を配置するディレクトリやファイルごとに同様のアクセス制御を行うのが一般的ですが、この"Listen"ディレクティブはその 最初の関門 で、ここで許可されないIPアドレスとポート番号は他のディレクティブで許可することはできません。 一般書式は、 Listen [接続を許可するIPアドレス]:[接続を許可するポート番号] です。 WBEL3やCentOS3の場合の デフォルト の設定は、 |
|||||||||||
| IPアドレス表記 "0.0.0.0" は、このディレクティブでは例外的に 「全てのIPアドレス」 という意味で使われるパラメータです。 |
一方WBEL4、CentOS4、CentOS5の場合のデフォルト設定は、 |
|||||||||||
|
すべてのIPアドレスからの接続を許可する場合は、このようにIPアドレスの表記を省略することができます。
じゃあWBEL3やCentOS3のデフォルト設定の "0.0.0.0:" って何なの?。という気もしますが、書式上の体裁の問題ではないかな、と思ったりします。よくわかりませんが。 |
となっています。パラメータの記述は違いますがどちらも内容は同じで、 「全てのIPアドレスからポート番号80で接続を許可する。」 という意味、つまり Webサーバー として最も一般的な動作を行うようになっています。 例えば、 HTTP の Well-Knownポート である80番以外のポート番号のみを利用したい場合は、
、両方とも利用したい場合は
のように記述します。 |
|||||||||||
|
|
ところで、ユーザー認証などを行う仕組みを導入するときに用いる セキュアWebサーバー の構築に関してですが、もしもこの"Listen"ディレクティブのルールに従えばポート番号 "443" を追加する必要があるはずですが、ここでは記述する必要はありません。 セキュアWebサーバーについては、実は WBEL や CentOS の インストール で SSL がインストールされると同時に、モジュールとして Apache に組み込まれています。 そしてその設定ファイルである、 "/etc/httpd/conf.d/ssl.conf" に記述され、設定が有効になっていますので、"/etc/httpd/conf/httpd.conf"に記述する必要はありません。
"ssl.conf"の"Listen"ディレクティブ(WBEL3,CentOS3)
"ssl.conf"の"Listen"ディレクティブ(WBEL4,CentOS4,CentOS5) ただ、今から初心者としてWebサーバーを構築してゆくわけですから、最初からWell-Known以外のポート番号を利用するような設定は必要ないと思います。 また、IPアドレスに対するアクセス制限については、別のディレクティブでディレクトリやファイル単位でのアクセス制御を行うことができますから、この"Listen"ディレクティブで設定を行う必要はないでしょう。 というわけですからWBELやCentOSの場合はデフォルトの設定のままで大丈夫です。 User,Group〜アクセスするアカウントの設定WBEL3 及び CentOS3 では 244〜245行目 、WBEL4及びCentOS4では 227〜228行目 、CentOS5では 231〜232行目 あたりに記述があります。 どのような プロトコル を用いる場合でも、 LinuxOS のシステムを一部でも利用する場合には、必ず アカウント が必要となります。 これらの ディレクティブ では、ホームページの閲覧にやってくるユーザー、つまり httpd に対して HTTP でアクセスを行う不特定多数の クライアント に対して、一時的に貸し出すアカウントを設定します。 デフォルト では、
となっていますから、 構築中のLinuxサーバー にとっては、HTTPでアクセスするユーザーはすべて、 "apache" というアカウントで接続することになります。 "apache"というアカウントは、 Apache が インストール されるときに自動的に作成される「HTTP接続専用の」 システムアカウント ですが、 構築中のLinuxサーバー に ログイン して操作することはできないようになっています。 ServerAdmin〜サーバー管理者の連絡先WBEL3 及び CentOS3 では 252行目 、WBEL4及びCentOS4では 235行目 、CentOS5では 251行目 あたりに記述があります。 httpd は、 クライアント がホームページを閲覧中にエラーが発生すると、クライアント側の Webブラウザ にエラーページを表示します。 この ディレクティブ では、そのエラーページに表示する サーバー 管理者の連絡先を設定します。
このディレクティブは
バーチャルホスト
の設定
この設定は、ホームページの利用者がその作成者に対して Webサーバー のエラーをリポートすることで、不具合の修正に役立てるという「助け合い精神」に基づくものに他なりません。 デフォルト では、
となっています。これを実際のメールアドレスに書き換えれば良いのですが、正直に、
と記述しても、 「あなたの コンテンツ を見ていたらエラーが出ました。修正したほうがいいですよ。」 のような親切なメールを送ってくれる人は 非常に稀 です。 メールがやってこないだけならばまだ良いのですが、残念なことに、現実には海外からのシステムソリューション関係のDMや、怪しげな出会い系サイトの勧誘のメールなどが次々と送られてくるのが普通です。 Apache の開発担当者もその現実は把握しているようで、実際にはこのディレクティブでメールアドレスを設定しても、後ほど説明する "ServerSignature" ディレクティブを デフォルトの "On" から "EMail に変更しなければ表示されないようになっています。 |
|||||||||||
|
|
もちろん余計なメールを受信したくなければ、デフォルトのまま変更する必要はありません。 もしも、「そういう怪しげなメールを受け取ってみたい」と思う場合には、この限りではありません。 記述するのは必ずしも"****@obenri.com"である必要はありません。受信可能な任意のメールアドレスあれば何でもOKです。 ただ、大量のスパムメールでメールボックスが溢れ、収拾がつかなくなる可能性がありますから、使えなくなっても構わないメールアドレスを記述することをお勧めします。 ServerName〜主となるFQDNとポート番号の設定WBEL3 及び CentOS3 では 266行目 、WBEL4及びCentOS4では 249行目 、CentOS5では 265行目 あたりに記述があります。 公開しようとする コンテンツ の FQDN と、受け付ける ポート番号 を設定する ディレクティブ です。
このディレクティブは
バーチャルホスト
の設定
デフォルトでは、
と、コメントアウトされたテンプレートになっていますから、コメント記号の"#"をはずして次のように設定します。
これで httpd は自分自身を 「ポート番号80番で HTTP 送受信を行う"www.obenri.com" 」 と解釈して動作します。
もちろん、
"www.obenri.com"
というFQDNは、
WAN
空間では
ダイナミックDNS
で自宅のWAN側の
グローバルIPアドレス
に
実をいうとこのディレクティブは、省略してもとりあえず動作はします。 httpdへのアクセスは、基本的に IPアドレス で行われますから、 構築中のLinuxサーバー に割り当てられているIPアドレスへ正引きの名前解決ができるFQDNから記述可能な URL であればどれでもOKです。 つまり、 "http://web1.obenri.com/" でも、 "http://mail.obenri.com/" でも、同じようにアクセス可能というわけです。 ただ、"ServerName"ディレクティブが設定されていない場合、httpdは自分自身のFQDNを逆引きの名前解決で得ようとします。
例えば、
"http://www.obenri.com/"
や
"http://mail.obenri.com/"
でアクセスが行われると、実際はその正引きの名前解決の結果である
"192.168.100.11"
でアクセスが行われますが、httpd内部ではその逆引きの名前解決結果である
"http://web1.obenri.com/"
もちろん、このことが直ちにhttpdの不具合に結びつく訳ではありませんが、そういった「複雑な内部事情」を発生させないためにも、もし Webサーバー に用いるFQDNを決めているのであれば、きちんと"ServerName"を設定することをおすすめします。 ポート番号については、前述の "Listen" ディレクティブで、HTTP用の "80" と、 HTTPS 用の "443" を許可していますので、メインのWebサーバーである "www.obenri.com" には明示的に、 "80" を指定しておきます。 なお、このディレクティブで具体的なFQDNの設定を行った場合は、次の"UseCanonicalName"ディレクティブを適切に設定する必要があります。 UseCanonicalName〜"ServerName"の利用の有無WBEL3 及び CentOS3 では 275行目 、WBEL4及びCentOS4では 258行目 、CentOS5では 274行目 あたりに記述があります。 "ServerName" ディレクティブ での設定を、利用するか否かを設定するディレクティブです。 デフォルト では、
になっており、 httpd はユーザーからリクエストされた FQDN 、 ホスト名 などをそのまま利用して URL を生成して動作します。 一方、このディレクティブを、 |
|||||||||||
| 説明は割愛しますが、 構築中のLinuxサーバー 上のhttpdを、FQDNだけではなく、 LAN 内だけで通用する ホスト名 ( WindowsOS の NetBIOS 名など )でも利用したい場合は、 "Off" に設定しておかなければならないかもしれません。 |
に設定すると、ユーザーからのリクエストに応えた後、 "ServerName" ディレクティブで設定されているFQDNを用いてURLを生成して動作します。 構築中のLinuxサーバー では、"ServerName"ディレクティブをhttpd自身の動作に利用しますから、 "UseCanonicalName On" に設定します。 DocumentRoot〜メインコンテンツの格納場所WBEL3 及び CentOS3 では 282行目 、WBEL4及びCentOS4では 265行目 、CentOS5では 281行目 あたりに記述があります。 この httpd の コンテンツ データの格納場所を指定する ディレクティブ です。
このディレクティブは
バーチャルホスト
の設定
デフォルト は、
|
|||||||||||
既に、
でテスト稼動をされた方には、あえて説明する必要はないと思います。
|
ですから、 構築中のLinuxサーバー 上の "/var/www/html" 以下がコンテンツの格納場所として指定されています。 従って、 クライアント から |
|||||||||||
| 通常アクセス時には "index.html" というファイル名は省略することができるように、次に説明する "DirectoryIndex" ディレクティブで設定されています。 |
"http://www.obenri.com/index.html" にアクセス要求があった場合は、 "/var/www/html/index.html" が送り返され、 "http://www.obenri.com/data/photo.html" |
|||||||||||
|
|
に要求があったときは、 "/var/www/html/data/photo.html" が送り返されることになります。 DirectoryIndex〜省略を許可するファイル名WBEL3 及び CentOS3 では 392行目 、WBEL4及びCentOS4では 375行目 、CentOS5では 391行目 あたりに記述があります。 コンテンツ の最初の見出しに使われるようなページの htmlファイル 名は、できれば省略してアクセスできたほうが何かと好都合です。 この ディレクティブ では、その上位のディレクトリ名だけで httpd にアクセスできるように、省略を許可するファイル名を指定します。 デフォルト では、
となっていますから、例えば クライアント から、 "http://www.obenri.com/" へのアクセスが行われた場合、"/var/www/html/"以下に"index.html"というファイルが存在すれば、自動的に、 "http://www.obenri.com/index.html" へ要求されたものとみなされます。 この設定は、コンテンツ内の全てのディレクトリが対象になりますので、"/var/www/html/data/index.html"というファイルも同様に、 "http://www.obenri.com/data/" でアクセス可能になります。 またこのディレクティブは、スペースで区切って複数のファイル名を記述することができます。例えば、
と記述しておけば、これらの全てのファイル名が省略対象になります。 アクセス要求のあったディレクトリの中に、該当するファイル名が複数存在する場合は、「"index.html"が見つからなければ"index.htm"、それも見つからなければ"index.cgi...」という具合に、設定されているファイル名が向かって左側から参照され、最初に一致したファイル名が有効になります。 このディレクティブによる設定は、httpdの動作にではなく、どちらかというとコンテンツの体裁に係わるものですから、とりあえずは、
に設定しておき、後からコンテンツを作成する際に適宜追加すればよいでしょう。 AccessFileName〜外部設定ファイルのファイル名WBEL3 及び CentOS3 では 392行目 、WBEL4及びCentOS4では 382行目 、CentOS5では 391行目 あたりに記述があります。
httpd
は、設定の一部を
"AllowOverride"
ディレクティブ
この "AccessFileName" では、その設定ファイル、通称 「アクセスファイル」 のファイル名を指定します。 デフォルト は、
ですが、できればこのまま使用することをお勧めします。変更する場合でも、ファイル名は必ず ".ht" で始まるファイル名を設定してください。 ErrorLog〜エラーログを出力するファイルの指定WBEL3 及び CentOS3 では 474行目 、WBEL4及びCentOS4では 456行目 、CentOS5では 472行目 あたりに記述があります。 クライアント からのアクセス時に発生したエラー ログ を記録するファイルを指定する ディレクティブ です。
このディレクティブは
バーチャルホスト
の設定
デフォルト では、
と、 相対パス 表記になっています。 従って、 "ServerRoot" ディレクティブが"/etc/httpd"ですから、具体的には "/etc/httpd/logs/error_log" がエラーログファイルとして指定されていることになります。 ただし、ディレクトリ"/etc/httpd/logs"は、 "/var/log/httpd" の シンボリックリンク ですから、実際のファイルの場所は "/var/log/httpd/error_log" となります。 |
|||||||||||
|
|
通常httpdのログファイルは、すべてこのディレクトリに出力されます。 CustomLog〜アクセスログを出力するファイルの指定WBEL3 及び CentOS3 では 500行目 、WBEL4及びCentOS4では 494行目 、CentOS5では 514行目 あたりに記述があります。 クライアント からのアクセス ログ を記録するファイルを指定する ディレクティブ です。
このディレクティブは
バーチャルホスト
の設定
デフォルト では、
と、 相対パス 表記になっています。 従って、 "ServerRoot" ディレクティブが"/etc/httpd"ですから、具体的には "/etc/httpd/logs/access_log" がアクセスログファイルとして指定されていることになります。 ただし、ディレクトリ"/etc/httpd/logs"は、 "/var/log/httpd" の シンボリックリンク ですから、実際のファイルの場所は "/var/log/httpd/access_log" となります。 末尾のオプションである "combined" は、アクセスログの出力形式の指定です。 この形式は、ログファイルを解析する アプリケーション を利用する場合に、そのアプリケーションの仕様に合わせて変更しなければならないことがあります。 ServerSignature〜サーバー情報の表示設定WBEL3 及び CentOS3 では 522行目 、WBEL4及びCentOS4では 504行目 、CentOS5では 524行目 あたりに記述があります。 httpd が クライアント にエラーメッセージなどを表示する際に、 サーバー に関する情報をどの程度まで掲載するかを決定する ディレクティブ です。 デフォルト では、
で、 "ServerTokens" ディレクティブで設定された内容だけがサーバー情報として追加表示されます。 これを、
と設定すると、"ServerTokens"ディレクティブで設定された内容に加えて、 "ServerAdmin" ディレクティブで設定した連絡先も掲載されるようになります。 セキュリティ を最優先に考える場合は、
と設定してください。エラーメッセージ以外の情報はクライアント側に表示されなくなります。 AddDefaultCharset〜標準で利用する文字セットWBEL3 及び CentOS3 では 769行目 、WBEL4及びCentOS4では 730行目 、CentOS5では 747行目 あたりに記述があります。 httpd が、 クライアント に コンテンツ データを送るとき、 Webブラウザ で利用させる 文字セット を設定する ディレクティブ です。 デフォルト では、
となっていますから、クライアント側のWebブラウザの文字セットは UTF-8 に選択されることになります。 つまり、このデフォルト設定のままhttpdを利用する場合には、コンテンツデータの文字セットをUTF-8で作成すればよいことになります。 しかしこれには大きな問題があります。 実はUTFは、まだ日本には充分に浸透しているとは言い難い文字セットで、それを取り扱う環境がまだ整っていません。 まず、 クライアント機 からコンテンツデータを Webサーバー に アップロード するための FTPクライアント の多くが、UTF-8への文字セット変換機能を持っていません。 例えば WindowsOS のスタンダードなFTPクライアントともいえる FFFTP の場合、 |
|||||||||||
| 元々WindowsOSは日本語を S-JIS で扱っていますので、S-JISでアップロードするときは 「無変換」 を選択します。 |
のように、アップロード時に変換可能な文字セットは EUC か JIS に限られます。 また、市販品やフリーウェアの CGI プログラムの多くもUTF-8形式の入出力に対応していないことが多く、やはりどうしてもEUCやS-JISでコンテンツデータを扱わなければならないケースは避けられないでしょう。 ところで、 htmlファイル は通常、ヘッダ部分に
という記述を入れることで、クライアント側の Webブラウザ の文字セットを指定して表示させることができるようになっています。 |
|||||||||||
| もちろん、コンテンツデータ自体はそのまま送信されますので、Webブラウザ側でエンコードを適切に選択すれば、きちんと表示することは可能です。とっても面倒ですが。 |
ところが、この"AddDefaultCharset"ディレクティブに具体的な文字セットを指定してしまうと、このヘッダ部分の命令は無視され、"AddDefaultCharset"の文字セットで強制的に表示してしまいます。 つまり、"AddDefaultCharset"で指定した文字セットと、htmlファイルの文字セットが異なっている場合には、Webブラウザでは間違いなく「文字化け」が起こってしまうことになります。 そこで、このディレクティブは、
のように設定そのものを無効にしてしまうか、または、
と明示的に無効にすることをお勧めします。 そうすると、コンテンツデータに任意の文字セットが利用できるようになります。 ただしその場合には前に示したように、コンテンツデータ自身に必ず文字セットの指定をいれなければなりません。 Alias〜仮想ディレクトリの設定WBEL3 及び CentOS3 では 537,551,893行目 、WBEL4及びCentOS4では 519,871行目 、CentOS5では 539,837行目 あたりに記述があります。 LinuxOS における、ディレクトリの シンボリックリンク に相当する機能の設定です。 例えば "DocumentRoot" ディレクティブが "/var/www/html" に設定されている場合に、
とAliasディレクティブを設定すると、 クライアント から "http://www.obenri.com/admin_only/" にアクセス要求があったときには "/var/www/html/admin_only/" ではなく、 "/var/www/admin/" というディレクトリから コンテンツ データが送信されるようになります。 この場合、 "/var/www/html/admin_only/" というディレクトリがなくてもエラーにはなりませんし、実際にそのディレクトリが存在していても無視されます。 "Alias"ディレクティブは、 httpd で設定するすべての URL に対して有効になりますから、例えば バーチャルホスト を使って複数のコンテンツを配信する場合でも、その中のディレクトリに対して個々に適用されます。 |
|||||||||||
|
|
さて、httpdは通常、バーチャルホストを含めて"DocumentRoot"ディレクティブで HTTP でのアクセスを許可するディレクトリを指定します。 しかしこの"Alias"ディレクティブを使用すると、上の例のように、本来HTTPではアクセスを受け付けないディレクトリをコンテンツの配置場所として利用できるようになります。 httpdになぜこのような仕組みが存在するかというと、 セキュリティ の確保された サーバー 管理領域を設置するためだと思ってください。 例えば、自分以外の第三者にホームページ配信のためのコンテンツスペースを貸し出すような場合で、httpdで配信するURLのすべてに、 "http://ホスト名( FQDN )/admin_only/" という 「自分だけが操作可能な」 サーバー管理領域を設けたいとします。 ところが、もしも"Alias"ディレクティブを使わないとしたら、その管理領域は"/var/www/html/admin_only/"などの 「コンテンツデータと同じ場所に実際に作成」 しなければなりません。 コンテンツデータの置き場所はいうまでもなく、自分以外の ユーザーアカウント で FTP によるコンテンツデータの アップロード が許可されているディレクトリですから、どうしてもセキュリティが甘くなってしまう領域です。 しかしその管理領域を、第三者がFTPでアクセス不可能なディレクトリに配置できれば、管理用 スクリプト の内容を覗き見られたりする危険がなくなるというわけです。 デフォルトで用いられている"Alias"ディレクティブは、アイコン、マニュアル、エラーを配信するために利用されているだけですから、これらの設定は修正する必要はありません。 |
|||||||||||
|
WBEL4及びCentOS4では、
"/manual"
に関する記述は
"/etc/httpd/conf.d/
manual.conf" にあります。 |
ただ、それぞれで設定されている仮想ディレクトリは、説明のように実際にはドキュメントルートで利用することはできません。 従って、 "icons" 、 "manual" 、 "error" の三つのディレクトリ名は、ドキュメントルート直下では使用できないことに注意してください。
|
|
|
Apacheの構成と設定の準備
<<Previous
|
Next>>
コンテナディレクティブの形式
|
| このサイトは既に更新を終了していますが、今のところ店じまいの予定はありません。 リンクフリー ですので、趣味や勉強のためでしたら、引用、転用、コピー、朗読、その他OKです。このサイトへのリンクについては こちら をご覧ください。 |
| ”Linux”は、Linus Torvalds 氏の各国における登録商標です。”Red Hat”及びRed Hatのロゴおよび Red Hat をベースとしたすべての商標とロゴは、各国におけるRed Hat, Inc. 社の商標または登録商標です。その他のプログラム名、システム名、製品名などは各メーカー、ベンダの各国における登録商標又は商標です。 |