Oracle HTTP Server スタンドアロン・デプロイの管理Apache 2.0ベース 10g(10.1.3.1.0) B31848-02 |
|
この付録では、Oracle HTTP Serverに関してよくある質問とそれに対する回答について説明します。
該当する場合は、Apache Software Foundationのマニュアルを参照しています。
Oracle HTTP Serverには、エラー処理用のデフォルトのコンテンツ・ハンドラが用意されています。ErrorDocument
ディレクティブを使用すると、デフォルトを上書きできます。
HTTPの場合、Oracle HTTP Serverでは名前ベースおよびIPベースという2種類の仮想ホストがサポートされます。HTTPSでサポートされるのは、IPベースの仮想ホストのみです。
HTTPにIPベースの仮想ホストを使用している場合、顧客の仮想サーバーは顧客別IPアドレスのポート80でリスニングしています。このような顧客にHTTPSを提供するには、同じ顧客別IPアドレスのポート4443でリスニングするユーザーごとに仮想ホストを追加し、mod_osslのディレクティブの使用などのSSLディレクティブを使用して顧客ごとのSSL特性を指定します。各顧客が専用ウォレットとサーバー証明書を使用できることに注意してください。
HTTPに名前ベースの仮想ホストを使用している場合、顧客の仮想サーバーは共有IPアドレスのポート80でリスニングしています。このような顧客にHTTPSを提供するには、共有IPアドレスのポート4443でリスニングする共有IPの仮想ホストを1つ追加します。すべての顧客は、ウォレットやISPのサーバー証明書などのSSL構成を共有します。
ProxyRequests
を「On」に設定し、CacheRoot
ディレクティブを設定することで、Oracle HTTP Serverをキャッシュとして使用できます。
Apacheサーバーの機能に与えられた汎用名であるMultiviewsを使用すると、リクエストに対するレスポンスで様々なバージョンの言語と文字固有のドキュメントを提供できます。
CacheディレクティブではなくProxyディレクティブを使用して、ファイアウォール間でプロキシ依存のリクエストを送信する必要があります。
mod_oc4j
は、Webサーバー(通常はOracle HTTP Server)と統合するモジュールであり、リクエストをバックエンドのOC4Jプロセスにルーティングします。OPMNモジュールにより、mod_oc4j
は様々なOC4Jプロセスのステータスを認識できるため、稼働中のプロセスに対してのみルーティングを行います。また、mod_oc4j
はOracle Application ServerのクラスタおよびOC4Jアイランドの概念も認識し、それに応じてルーティングすることで最大限の透過的フェイルオーバーを提供します。
mod_oc4j
は、IIS、Sun ONEおよびOracle HTTP Server以外のApacheサーバーなど、その他のWebサーバーをサポートしています。
mod_oc4j
とOC4Jプロセス間のAJP通信は、AJP/SSLを介して実行できます。これに対する妨害は以前からありませんでした。また、mod_oc4j
とOC4Jが通信するたびにSSLネゴシエーションが発生することはなく、パフォーマンスへの影響はより少なくなっています。
Oracle HTTP Serverは、Apacheバージョン1.3.31をベースとしています。
次の理由で、Oracle HTTP ServerにはApacheセキュリティ・パッチを適用できません。
openSSL
アラートなどのアラートは該当しません。
mod_gzip
など、この目的のためにプラグインできる他のフリーウェア・モジュールもありますが、その使用はサポートされていません。これらのモジュールを使用すると、EAPIに関してエラー・メッセージが表示されることがありますが、通常は無視できます。
リリース3(10.1.3)ではmod_php
が完全にサポートされています。
一般的に、1つの分散Webサイトのすべてのサーバーは、単一のURLネームスペースで一致している必要があります。すべてのサーバーがそのネームスペースの一部を処理し、処理対象ではないURLへのリクエストをそのURLにより近いサーバーへリダイレクトまたは送信できます。たとえば、次のようなネームスペースがあるとします。
/app1/login.html /app1/catalog.html /app1/dologin.jsp /app2/orderForm.html /apps/placeOrder.jsp
まず、app1
をserver1、app2
をserver2とすることで、このネームスペースを2つのWebサーバーにマップできます。server1の構成は次のようになります。
Redirect permanent /app2 http://server2/app2 Alias /app1 /myApps/application1 <Directory /myApps/application1> ... </Directory>
server2の構成は補足的なものです。コンテンツ・タイプ(server1はHTML、server2はJSP)でネームスペースを区切る場合、サーバー構成を変更してファイルを移動しますが、アプリケーション自体を変更する必要はありません。その結果、server1の構成は次のようになります。
RedirectMatch permanent (.*) ¥.jsp$ http://server2/$1.jsp AliasMatch ^/app(.*) ¥.html$ /myPages/application$1.html <DirectoryMatch "^/myPages/application¥d"> ... </DirectoryMatch>
実際のリダイレクションの量は、F5システムのBigIPなどのハードウェア・ロード・バランサを、リクエストをURLに基づいてserver1またはserver2に送信するように構成することで最小化できることに注意してください。
多数の攻撃があり、日々新たな攻撃が発生しています。次にサイトの保護に関する一般的なガイドラインを示します。サイトを完全に保護することはできませんが、安易なターゲットとなることは回避できます。
|
![]() Copyright © 2007 Oracle Corporation. All Rights Reserved. |
|