この章では、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>
PidFile
ディレクティブはPIDファイルの位置を指定します。 Oracle HTTP Serverは、起動時にそのプロセスIDをPIDファイルに書き込みます。
PidFile
ディレクティブを編集してPIDファイルの位置を変更した場合、対応する変更をORACLE_HOME/Apache/Apache/bin/apachectl
ファイルに加える必要があります。
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