| Oracle Application Serverリリース・ノート 10gリリース3（10.1.3.2.0） for Linux x86 E05050-04 |
|
 戻る |
 次へ |
この章では、Oracle HTTP Serverに関連する問題について説明します。内容は次のとおりです。
この項の内容は次のとおりです。
Oc4jMountディレクティブでは、宛先がインスタンスまたはクラスタの場合にのみ重み付けされたロード・バランシングが機能します。重み付けされたロード・バランシングは、AJP13の宛先に対しては機能しません。AJP13の宛先については、ラウンドロビン法により負荷が均等に分散されます。たとえば、mod_oc4j.confファイルに次の各行が含まれる場合、Host_AおよびHost_Bでは、Oc4jRoutingWeightディレクティブの設定にかかわらず同じ数のリクエストを受け取ります。
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>
PidFileディレクティブは、PIDファイルの場所を表します。Oracle HTTP Serverが起動されると、そのプロセスIDがPIDファイルに書き込まれます。
PidFileディレクティブを編集して、このPIDファイルの場所を変更した場合、同様の変更をORACLE_HOME/Apache/Apache/bin/apachectlファイルでも行う必要があります。
プロキシ・サーバーがURLパスに基づいてリクエストをルーティングしている場合、同一の仮想ホスト名とポートを使用して、2つの異なるOracle HTTP Serverを構成することはできません。また、これらを同じSSO構成にパートナーとして参加させることもできません。
たとえば、URLに基づいて、Oracle Single Sign-Onを使用するアプリケーションへのリクエストを適切な中間層にルーティングするように、Web層にロード・バランサ、またはOracle Webキャッシュを構成します。
http://wwww.mycompany.comへのリクエストを処理するように構成されたOracle HTTP Serverがあります。
http://www.mycompany.com/app1へのリクエストをmidtier1にルーティングするように構成されたOracle Web Cacheがあります。
http://www.mycompany.com/app2へのリクエストをmidtier2にルーティングするように構成されたOracle Web Cacheがあります。
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であるかがわかりません。成功URLはアプリケーション情報を持たないため、成功URLを正しくリダイレクトするように、ロード・バランサ、またはOracle Web Cacheを構成することはできません。
この問題について考えられるソリューションは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で指定したファイルは、ハッシュできません。1つのSSLCARevocationFileエントリだけが存在する必要があり、複数のエントリが存在すると、最後の1つが使用されます。SSLCARevocationFileは、SSLCARevocationPathのかわりに、またはSSLCARevocationPathに追加して（あるいはその両方の方法で）使用できます。
『Oracle HTTP Server管理者ガイド』の第10章「Oracle HTTP ServerでのSSLの有効化」に記載されているSSLCARevocationPathディレクティブの正しい説明は、次のとおりです。
PEMでエンコードされた証明書失効リスト（CRL）の格納先ディレクトリを指定します。これらのCRLは、証明書の取得元であるCA（認証局）から発行されます。クライアントがこれらのCRLの1つに含まれる証明書で自身を認証しようとすると、その証明書は取り消されます。この場合、クライアントはサーバーに対して自身を認証できません。
SSLCARevocationPathディレクトリのCRLファイルは、ハッシュする必要があります。CRLをハッシュする方法の詳細は、『Oracle Application Server管理者ガイド』の、証明書検証のためのハッシュ値によるCRL名の変更に関する項を参照してください。orapkiで作成されるファイルには、.rN拡張子が付きます。SSLCARevocationPathは、この拡張子では機能しないため、引き続き取り消された証明書によるアクセスが許可されます。Oracle HTTP Serverで機能させるには、拡張子を.rNから.r0に変更します。
SSLCARevocationPathは、SSLCARevocationFileのかわりに、または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プロキシ・プラグインに関する付録では、プロキシ定義ファイルの説明に、実際のファイル名が明記されていません。これは定義ファイルにはどのような名前でも付けられるからです。
Microsoft IISでOracle Application Serverプロキシ・プラグインを使用している場合、Windowsレジストリのserver_defsエントリに定義ファイルへのフルパスを指定します。レジストリの具体的な場所については、『Oracle HTTP Server管理者ガイド』のOracle Application Serverプロキシ・プラグインに関する付録を参照してください。
Oracle Application Serverプロキシ・プラグインと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
