| Oracle Application Serverリリース・ノート 10g リリース3（10.1.3.1.0）for Microsoft Windows B31912-06 |
|
 戻る |
 次へ |
この章では、Oracle HTTP Serverに関する問題について説明します。内容は次のとおりです。
この項の内容は次のとおりです。
Oc4jMountディレクティブでは、宛先がインスタンスまたはクラスタである場合のみ、重み付けされたロード・バランシングが機能します。重み付けされたロード・バランシングは、AJP13の宛先に対しては機能しません。AJP13の宛先では、ロードはラウンドロビン方式で均等に分散されます。たとえば、mod_oc4j.confファイルに次の行が含まれている場合、Oc4jRoutingWeightディレクティブでの設定に関係なく、Host_AおよびHost_Bは同数のリクエストを受け取ります。
Oc4jSelectMethod roundrobin:weighted Oc4jRoutingWeight Host_A 1 Oc4jRoutingWeight Host_B 25 Oc4jMount /j2ee ajp13://Host_A:<AJP Port>,Host_B:<AJP Port> Oc4jMount /j2ee/* ajp13://Host_A:<AJP Port>,Host_B:<AJP Port> # Instance weighted routing work as expected #Oc4jMount /j2ee instance://Host_A:home,Host_B:home #Oc4jMount /j2ee/* instance://Host_A:home,Host_B:home
AJP13の宛先に対し重み付けされたロード・バランシングを実行するための可能な対処方法は、Oc4jMountディレクティブで同じホストを複数回指定することです。次に、Host_Bを2回指定した例を示します。
Oc4jMount /j2ee ajp13://Host_A:<AJP Port>,Host_B:<AJP Port>,Host_B:<AJP Port>
2つの別々のOracle HTTP Serverを同じ仮想ホスト名とポートを使用して構成し、プロキシ・サーバーによりURLパスに基づいてリクエストをルーティングしたり、同じSSO構成のパートナとして参加させることはできません。
例: ロード・バランサまたはOracle Web CacheをWeb層に構成し、Oracle Single Sign-Onを使用するアプリケーションに対するリクエストをURLに基づいて該当する中間層にルーティングする場合です。
Oracle HTTP Serverがhttp://wwww.mycompany.comに対するリクエストを処理するように構成されています。
Oracle Web Cacheがhttp://www.mycompany.com/app1に対するリクエストをmidtier1にルーティングするように構成されています。
Oracle Web Cacheがhttp://www.mycompany.com/app2に対するリクエストをmidtier2にルーティングするように構成されています。
app1およびapp2はOracle Single Sign-Onを使用するアプリケーションです。
ユーザーが/app1に対してリクエストを発行すると、そのリクエストはmidtier1にリダイレクトされます。midtier1上のmod_ossoがそのリクエストを認証のためにSSOサーバーにリダイレクトします。 認証後、SSOサーバーは成功URLをコールします。これはリクエストの対象となるアプリケーションに関係なく常にwww.mycompany.com/osso_login_successで、この成功URLはwww.mycompany.comのOracle HTTP Serverにより処理されます。 成功URLにはリクエストの対象となるアプリケーションが指定されていないため、www.mycompany.comのOracle HTTP Serverにはリクエストをリダイレクトする宛先（midtier1またはmidtier2）がわかりません。 ロード・バランサまたはOracle Web Cacheは、成功URLにアプリケーション情報がないため成功URLを正しくリダイレクトするように構成できません。
この問題に対して考えられる解決策は、MetaLinkノート390358.1に説明されています。これは、Oracleカスタマ・サービスからサービス・リクエストを介して入手できます。
この項では、ドキュメントの記載内容の誤りについて説明します。内容は次のとおりです。
Oracle HTTP Serverは、バージョン1.3.34のApacheに基づいています
『Oracle HTTP Server管理者ガイド』の「Single Sign-On用のIISリスナーの構成」の項では、有効なログ・レベルは、debug、inform、error、およびemergencyであるという誤った記述があります。
有効なログ・レベルは、debug、inform、error、およびemergです。
『Oracle HTTP Server管理者ガイド』の第10章「Oracle HTTP ServerでのSSLの有効化」に記載されているSSLCARevocationFileディレクティブの説明は、次のように訂正する必要があります。
証明書を発行したCA（認証局）からの証明書失効リスト（CRL）をまとめるファイルを指定します。このリストは、クライアント認証に使用されます。このファイルは、PEMでエンコードされた様々なCRLファイルを優先順位の順に連結したものです。CRLファイルの発行者は単一である必要があります。SSLCARevocationFileで指定されたファイルはハッシュしないでください。SSLCARevocationFileエントリは1つのみ存在する必要があり、複数のエントリが存在する場合は、最後のエントリを使用します。SSLCARevocationFileは、SSLCARevocationPathの代替または補助用、あるいはその両方に使用できます。
『Oracle HTTP Server管理者ガイド』の第10章「Oracle HTTP ServerでのSSLの有効化」に記載されているSSLCARevocationPathディレクティブの説明は、次のように訂正する必要があります。
PEMでエンコードされている証明書失効リスト（CRL）が格納されるディレクトリを指定します。CRLは、証明書の発行元のCA（認証局）から届きます。CRLのいずれかに記載されている証明書を使用してクライアントが自身を認証しようとすると、証明書は取り消され、そのクライアントはサーバーに対して自身を認証できなくなります。
SSLCARevocationPathディレクトリ内のCRLファイルは、ハッシュする必要があります。CRLのハッシュの手順は、『Oracle Application Server管理者ガイド』の第11.2.5.2.1項「証明書検証のためのハッシュ値によるCRL名の変更」を参照してください。orapkiにより.rN拡張子を持つファイルが作成されることに注意してください。SSLCARevocationPathはこの拡張子に対して機能せず、取り消された証明書へのアクセスが可能なままとなります。これをOracle HTTP Serverで機能するようにするには、拡張子を.rNから.r0に変更します。
SSLCARevocationPathは、SSLCARevocationFileの代替または補助用、あるいはその両方に使用できます。
『Oracle HTTP Server管理者ガイド』の表10-1「SSL暗号スイートのタグ」では、40ビットおよび56ビット輸出暗号の別名が誤って表示されています。
40ビット輸出暗号にEXP40は使用しません。かわりに、EXPORT40を使用します。
56ビット輸出暗号にEXP56は使用しません。かわりに、EXPORT56を使用します。
mod_php拡張の追加情報に関して提供されているWebサイトの表示に誤りがあります。正しいWebサイトは次のとおりです。
『Oracle HTTP Server管理者ガイド』の付録「Oracle Application Server Proxy Plug-Inの使用」では、実際のファイル名を記載せずにプロキシ定義ファイルについて記述されています。 これは、定義ファイルが任意の名前をとる可能性があるためです。
Oracle Application Server Proxy Plug-InをMicrosoft IISで使用している場合は、Windowsレジストリのserver_defsエントリに定義ファイルへのフルパスを指定します。 レジストリ内の特定の位置については、『Oracle HTTP Server管理者ガイド』の付録「Oracle Application Server Proxy Plug-Inの使用」を参照してください。
Oracle Application Server Proxy Plug-InをSun Java Systemリスナーで使用している場合は、magnus.conf（または、使用しているSun Java Systemリスナーのバージョンによってはobj.conf）構成ファイルのInit行のserver_defsパラメータを使用して定義ファイルへのフルパスを指定します。 次の例では、/oracle/proxyplugin/proxydefsが定義ファイルです。
Init fn="op_init" server_defs="/oracle/proxyplugin/proxydefs" log_file="/oracle/proxyplugin/oproxy.log" log_level=error
