Oracle HTTP Server 管理者ガイド
10g(10.1.3.1.0) B31847-01 |
|
この付録では、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特性を指定します。各顧客が専用Walletとサーバー証明書を使用できることに注意してください。
HTTPに名前ベースの仮想ホストを使用している場合、顧客の仮想サーバーは共有IPアドレスのポート80でリスニングしています。このような顧客にHTTPSを提供するには、共有IPアドレスのポート4443でリスニングする共有IPの仮想ホストを1つ追加します。すべての顧客は、Walletや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 Serverなど、他の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に関してエラー・メッセージが表示されることがありますが、通常は無視できます。
mod_php
は、リリース3(10.1.3)で完全にサポートされています。
一般的には、1つの分散Webサイトの全サーバーは、単一のURLネームスペースで一致する必要があります。すべてのサーバーではネームスペースの一部を処理し、処理しないURLに対するリクエストをそのURLにより近いサーバーにリダイレクトまたはプロキシできます。たとえば、次のようなネームスペースがあるとします。
/app1/login.html /app1/catalog.html /app1/dologin.jsp /app2/orderForm.html /apps/placeOrder.jsp
最初に、server1にapp1
、server2にapp2
を置いて、このネームスペースを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 © 2006 Oracle Corporation. All Rights Reserved. |
|