| Oracle Application Serverリリース・ノート 10gリリース2（10.1.2）for Solaris Operating System (SPARC) B15829-14 |
|
 戻る |
 次へ |
| Oracle Application Serverリリース・ノート 10gリリース2（10.1.2）for Solaris Operating System (SPARC) B15829-14 |
|
戻る |
次へ |
この章では、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>
オラクル社では、Oracle9iASリリース1（1.0.2.2.x）で提供されるOracle HTTP Serverを、Oracle Application Server 10gリリース2（10.1.2）で提供されるOC4Jへのフロントエンドとして使用することはサポートしていません。これら2つのコンポーネント間でデータをルーティングするときは、mod_proxyを使用しないでください。
Oracle Application Server 10g（10.1.2）で提供されるOC4Jとの間でデータをルーティングする場合は、必ずmod_oc4jを使用します。Oracle9iASリリース1（1.0.2.2.x）で提供されるOracle HTTP Serverコンポーネントと、Oracle9iASリリース1（1.0.2.2.x）で提供されるOC4Jとの間でデータをルーティングする場合は、mod_proxyを使用します。
mod_oc4jからmod_ossoをコールする操作時に（ログインやログアウトなど）、Oracle HTTPサーバー・ログに次のエラー・メッセージが出力されます。
[Mon Jun 27 23:57:07 2005] [error] [client 139.185.173.23] [ecid: 90258476571,1] MOD_OC4J_0376: Request initial processing failed in ac worker with HTTP status code 1. This status will be passed back to the listener for error handling.
このエラー・メッセージは害がないため、無視してかまいません。将来のリリースでは削除される予定です。
付録Cの「一般的なApacheとOracle Application Serverの統合」に「一般的なApacheとは、Apacheバージョン1.3.xxです。Apacheバージョン2.0ではありません。」とありますが、これは「一般的なApacheとは、Apacheバージョン1.3.xxまたはApacheバージョン2.0です。」の誤りです。
付録Cの注意項目「mod_oc4jは、Apacheバージョン1.3.xでのみサポートされます。Apacheバージョン2.0.xではサポートされません。」は無視してください。
この項では、構成に関する問題とその対処方法について説明します。この項の内容は次のとおりです。
第8.2.2項「mod_oc4jでポート・トンネリングまたはSSLを有効にした後、Oracle HTTP Serverが起動しない」
第8.2.3項「OracleAS Web Cacheがオフになっている場合または無効になっている場合のリダイレクトの中断」
ほとんどのプラットフォームでは、FastCGIで使用されるソケットのパスは108文字に制限されています。次のようなエラーが発生した場合は、FastCgiIpcDirディレクティブを使用して、108文字よりもかなり短いパス名（/tmpなど）を指定します。
Thu Oct 16 12:55:06 2003] [error] [client 148.87.9.44] [ecid: 82608810576,1] FastCGI: failed to connect to (dynamic) server "/opt/oracle/inst/Apache/Apache/fcgi-bin/echo": path "/opt/oracle/inst/Apache/Apache/logs/fastcgi/dymanic/aac1cec5416b961cf002c5526b4159" is too long for a Domain socket
mod_oc4jでポート・トンネリング（iASPT）またはSSLが有効になるように構成を変更すると、Oracle HTTP Serverが起動しない場合があります。この問題は、次のように解決できます。
推奨される解決策: mod_perlが不要な場合は、httpd.confのLoadModule perl_module libexec/libperl.so行をコメントアウトして無効にします。
mod_perlが必要な場合は、Sun社が提供する最新のパッチ・セットを実行していることを確認し、httpd.confでmod_oc4j.confをインクルードした後に、mod_perlのLoadModule行を追加します。
デフォルトでは、Oracle HTTP ServerはリダイレクトをOracleAS Web Cacheのリスニング・ポートに送信します。OracleAS Web Cacheが実行されていない場合または無効になっている場合、Oracle HTTP Server（およびOracle HTTP Serverの背後で実行されるOC4Jアプリケーション）からのリダイレクトは機能しません。OracleAS Web Cacheを実行しない場合は、httpd.confおよびssl.confを編集して、OracleAS Web Cacheのリスニング・ポートではなくListenディレクティブと一致するようにPortディレクティブを変更します。
OC4Jへクライアント証明書を渡すには、mod_oc4j.confファイルのOc4jCERTCHAINIndicatorディレクティブを使用します。このディレクティブは、環境に設定された証明連鎖を示します。たとえば、mod_oc4j.confファイルに次の行があるとします。
Oc4jCERTCHAINIndicator SSL_CLIENT_CERT_CHAIN
この場合、証明連鎖は環境変数SSL_CLIENT_CERT_CHAINn（nは0より大きい）を使用して定義できます。証明の順序は、次のようになります。
SSL_CLIENT_CERT_CHAIN0は最上位の中間CA証明書で、ルートCA証明書で認証されます。
SSL_CLIENT_CERT_CHAINnは最下位の中間CA証明書で、クライアント証明書を認証します。
Oc4jCERTCHAINIndicatorディレクティブを使用するには、Oc4JExtractSSLディレクティブをOnに設定する必要があります。次の行は、ディレクティブを設定する方法を示しています。
Oc4jExtractSSL On
Oc4jCertChainIndicator CERT_CHAIN_INDICATOR
次にディレクティブの例を示します。
Oc4jExtractSSL On Oc4jCertChainIndicator SSL_CLIENT_CERT
この項では、インストールおよびアップグレードに関するドキュメントの記載内容の誤りについて説明します。この項の内容は次のとおりです。
『Oracle HTTP Server管理者ガイド』の第11章「Oracle HTTP ServerでのSSLの有効化」に、SSLCARevocationFileディレクティブの説明がありますが、正しくは次のようになります。
証明書を発行したCA（認証局）からの証明書失効リスト（CRL）をまとめるファイルを指定します。ファイルは、クライアント認証に使用されます。このファイルは、PEMでエンコードされた様々なCRLファイルを優先順位の順に連結したものです。CRLファイルの発行者は単一である必要があります。SSLCARevocationFileで指定されたファイルはハッシュしないでください。SSLCARevocationFileのエントリは1つのみとします。エントリが複数ある場合は、最後のエントリが使用されます。SSLCARevocationFileは、SSLCARevocationPathのかわりに使用したり追加として使用できます。
『Oracle HTTP Server管理者ガイド』の第11章「Oracle HTTP ServerでのSSLの有効化」に、SSLCARevocationPathディレクティブの説明がありますが、正しくは次のようになります。
PEMでエンコードされている証明書失効リスト（CRL）が格納されるディレクトリを指定します。CRLは、証明書の発行元のCA（認証局）から届きます。CRLのいずれかに記載されている証明書を使用してクライアントが自身を認証しようとすると、証明書は取り消され、そのクライアントはサーバーに対して自身を認証できなくなります。
SSLCARevocationPathディレクトリ内のCRLファイルは、ハッシュする必要があります。CRLをハッシュする手順については、『Oracle Application Server管理者ガイド』の第15.2.5.2.1項「証明書検証のためのハッシュ値によるCRL名の変更」を参照してください。orapkiを使用すると、拡張子「.rN」のファイルが作成されます。SSLCARevocationPathは、この拡張子があると機能せず、取り消された証明書でまだアクセスできます。Oracle HTTP Serverで機能するようにするには、拡張子を「.rN」から「.r0」に変更します。
SSLCARevocationPathは、SSLCARevocationFileのかわりに使用したり追加として使用できます。
mod_php拡張機能に関する追加情報を記載したWebサイトに誤りがありました。正しいWebサイトは次のとおりです。
『Oracle HTTP Server管理者ガイド』の表10-1「SSL暗号スイートのタグ」には、40ビットおよび56ビットの輸出暗号としてエイリアスが一覧表示されていますが、これは誤りです。
40ビットの輸出暗号にはEXP40を使用しないでください。かわりにEXPORT40を使用してください。
56ビットの輸出暗号にはEXP56を使用しないでください。かわりにEXPORT56を使用してください。
