Oracle® Fusion Middleware Oracle WebLogic ServerにおけるWebサーバー・プラグインの使い方 11g リリース1(10.3.4) B61008-02 |
|
前 |
次 |
次の項では、Apache HTTP Serverプラグインをインストールして構成する方法を説明します。
Apache HTTP Serverプラグインを使用すると、Apache HTTP ServerからWebLogic Serverにリクエストをプロキシできます。このプラグインは、WebLogic Serverの動的な機能を必要とするリクエストをWebLogic Serverが処理できるようにすることによってApacheを拡張します。
このプラグインは、Apacheサーバーが静的ページを提供している環境で使用されることを想定しています。ドキュメント・ツリーの他の部分(HTTPサーブレットやJavaServer Pagesによって最も適切な状態で生成される動的ページ)は、(おそらくは別のホストの)別のプロセスで動作しているWebLogic Serverに委任されます。それでも、エンド・ユーザー(ブラウザ)には、WebLogic Serverに委任されるHTTPリクエストは同じソースから送られているものと認識されます。
HTTPトンネリング(企業のファイアウォールを経由したHTTPリクエストおよびレスポンスのアクセスを可能にする技術)もこのプラグインを介して動作するため、非ブラウザ・クライアントにWebLogic Serverサービスへのアクセスを提供できます。
Apache HTTP Serverプラグインは、Apache HTTP Server内でApacheモジュールとして機能します。Apacheモジュールは起動時にApacheサーバーによってロードされ、その後特定のHTTPリクエストがモジュールに委任されます。Apacheモジュールは、HTTPサーブレットと似ていますが、プラットフォームにネイティブなコードで記述されている点で異なります。
Apache HTTP Serverプラグインがサポートされる構成の詳細は、http://www.oracle.com/technology/software/products/ias/files/fusion_certification.html
を参照してください。
注意: Apache 2.0プラグインは、WebLogic Server 10.0のリリースで非推奨になりました。 |
Apache HTTP Serverプラグインのバージョン2.0は、WebLogic Serverとの接続の再利用可能なプールを使用してパフォーマンスを向上させます。このプラグインは、同じクライアントからの後続リクエストにプール内の同じ接続を再利用することで、WebLogic Serverとの間でHTTP 1.1キープアライブ接続を実装します。接続が20秒(またはユーザー定義の時間)を超えて非アクティブな場合、その接続は閉じられてプールから削除されます。この機能は、必要に応じて無効にできます。詳細は、表7-1の「KeepAliveEnabled」
を参照してください。
プラグインは、ユーザーが指定する構成に基づいてリクエストをWebLogic Serverにプロキシします。リクエストは、リクエストのURL(またはURLの一部)に基づいてプロキシできます。これを、パス
によるプロキシと呼びます。リクエスト対象のファイルのMIMEタイプ
に基づいてリクエストをプロキシすることもできます。または、これらの2つの方法を組み合せて使用することも可能です。リクエストが両方の基準に一致する場合、そのリクエストはパスによってプロキシされます。リクエストの種類ごとに、プラグインの追加の動作を定義する追加パラメータを指定することもできます。詳細は、「Apache HTTP Serverプラグインの構成」を参照してください。
Apache HTTP Serverプラグインは、Linux、Solaris、Windows、およびHPUX11の各プラットフォームでサポートされています。Apacheの特定のバージョンのサポートについては、http://www.oracle.com/technology/software/products/ias/files/fusion_certification.html
を参照してください。
Apache HTTP Serverプラグインには、WL_HOME/server/plugin
ディレクトリの下にWebLogic Serverが含まれます。
Apache HTTP Serverプラグインは、インストールされているApache HTTP ServerのApacheモジュールとしてインストールし、動的共有オブジェクト(DSO)としてリンクできます。
DSOは、実行時にサーバーに動的にロードされるライブラリとしてコンパイルされるので、Apacheを再コンパイルしなくてもインストールできます。
Apacheプラグインは、Solaris、Linux、AIX、Windows、およびHPUX11プラットフォーム用の共有オブジェクト(.so)として配布されます。
注意: WebLogic Serverバージョン10.3インストールにはApache HTTP Serverプラグインは含まれていません。Apache HTTP Serverプラグインは、Oracleダウンロードおよびサポート・サイトから、別個のzipファイルで入手できます。これらのプラグインには、次の場所に記述されているセキュリティ・アドバイザリに対応する修正が含まれています。http://www.oracle.com/technology/deploy/security/alerts/alert_cve2008-3257.html zipファイルをダウンロードしたら、ディスク上の任意のディレクトリに展開します。 |
表3-1は、各種プラットフォームの共有オブジェクト・ファイルを格納するディレクトリを示します。
表3-2には、各バージョンのApache HTTP Serverと暗号化強度に対応するWebLogic Server Apacheプラグイン・モジュールを示します。
表3-1 プラグインの共有オブジェクト・ファイルの場所
オペレーティング・システム | WL_HOME/server/pluginの下の共有オブジェクトの場所 |
---|---|
AIX |
aix/ppc |
Solaris |
solaris/sparc solaris/sparc/largefile脚注 1 solaris/x86 solaris/x86/largefile脚注 2 |
Linux |
linux/i686 linux/i686/largefile脚注 3 linux/ia64 linux/x86_64 |
Windows (Apache 2.0および2.2 (32ビット)) |
win\32 |
HPUX11 |
hpux11/IPF64 hpux11/PA_RISC 注意: HP-UX11上でApache 2.0.xサーバーを実行している場合、Apacheサーバーをビルドする前に次の環境変数を設定します。ビルド前に環境変数としてロード順序を事前に設定しておかないと、HP-UX上でリンク・ライブラリがロードされる順番に関する問題のため、コア・ダンプが生成される場合があります。Apacheの構成、作成、およびインストール手順( export EXTRA_LDFLAGS="-lstd -lstream -lCsup -lm -lcl -ldld -lpthread" |
脚注 1 「Apache 2.0におけるサイズの大きなファイルのサポート」を参照
脚注 2 「Apache 2.0におけるサイズの大きなファイルのサポート」を参照
脚注 3 「Apache 2.0におけるサイズの大きなファイルのサポート」を参照
次の表から適切なバージョンのプラグイン共有オブジェクトを選択します。
表3-2 Apacheプラグイン共有オブジェクト・ファイルのバージョン
Apacheのバージョン | 通常強度の暗号化 | 128ビットの暗号化 |
---|---|---|
標準のApacheバージョン2.0.x |
mod_wl_20.so |
mod_wl128_20.so |
標準のApacheバージョン2.2.x |
mod_wl_22.so |
mod_wl128_22.so |
Apache HTTP Serverプラグインを動的共有オブジェクトとしてインストールするには:
表3-1を参照して、プラットフォームの共有オブジェクトのディレクトリを検索します。
表3-2で、使用するバージョンのApacheに対応したプラグイン共有オブジェクト・ファイルを確認します。
WebLogic Server Apache HTTP Serverプラグインの mod_so.c モジュールが有効になっていることを確認します。
Apache HTTP Serverプラグインは、動的共有オブジェクト(DSO)としてApache HTTP Serverにインストールされます。ApacheのDSOサポートは、mod_wl_20.soをロードする前に有効にする必要のあるmod_so.cというモジュールに基づいています。Apacheで提供されるスクリプトを使用してApache HTTP Serverをインストールした場合、mod_so.cはすでに有効になっています。次のコマンドを実行して、mod_so.cが有効であることを確認します。
APACHE_HOME\bin\apachectl -l
(APACHE_HOME
は、Apache HTTP Serverをインストールしたディレクトリです。)
このコマンドでは、有効なすべてのモジュールのリストが表示されます。mod_so.cがリストにない場合は、次のオプションが構成されるように、Apache HTTP Serverを再構築する必要があります。
... --enable-module=so --enable-rule=SHARED_CORE ...
http://httpd.apache.org/docs/2.0/dso.html
のApache 2.0共有オブジェクト(DSO)のサポートを参照してください。
Apache 2.0.xのApache HTTP Serverプラグイン・モジュールをインストールするには、mod_wl_20.so
ファイルをAPACHE_HOME\modules
ディレクトリにコピーし、APACHE_HOME conf/httpd.conf
ファイルに次の行を手作業で追加します。
LoadModule weblogic_module modules/mod_wl_20.so
Apache HTTP Serverプラグインの追加パラメータを定義します。
Apache HTTP Serverプラグインは、「Webサーバー・プラグインの一般的なパラメータ」にリストされているパラメータを認識します。Apache HTTP Serverプラグインの動作を修正するには、次のパラメータを定義します。
Location
ブロック(パスによるプロキシに適用されるパラメータの場合)、または
IfModule
ブロック(MIMEタイプによるプロキシに適用されるパラメータの場合)。
次のコマンドで、APACHE_HOME\conf\httpd.conf
ファイルの構文を検証します。
APACHE_HOME\bin\apachectl -t
このコマンドの出力では、httpd.conf
ファイルのエラーが示されるか、次が戻されます。
Syntax OK
Weblogic Serverを再起動します。
Apache HTTP Serverを起動(構成を変更した場合は再起動)します。
プラグインをテストするには、ブラウザを開いて、URLにApacheサーバーのURLに加えて「/weblogic/」を設定します。このURLは、WebLogicサーバー上のデフォルトWebアプリケーションに定義されたデフォルトのWebLogic Server HTMLページ、welcomeファイル、またはデフォルト・サーブレットを表示する必要があります。例:
http://myApacheserver.com/weblogic/
SolarisやLinuxの一部のバージョンなど、オペレーティング・システムによっては、付属のApache 2.0が次のフラグを指定してコンパイルされている場合があります。
-D_LARGEFILE_SOURCE -D_FILE_OFFSET_BITS=64
これらのコンパイル・フラグにより、2GB以上のファイルのサポートが可能になります。このようなApache 2.0 Webサーバー上でWebLogic Webサーバー・プラグインを使用する場合は、同じコンパイル・フラグを指定してコンパイルされたプラグインを使用する必要があります。このようなプラグインは、使用しているオペレーティング・システムのlargefileサブディレクトリにあります。例:
C:\WL_HOME\server\plugin\solaris\sparc\largefile
注意: Apache 2.2では、2GB以上のサイズのファイルをサポートするのに特別なコンパイル・フラグは必要ありません。したがって、Apache 2.2を実行している場合は、特別にコンパイルされたWebサーバー・プラグインを使う必要はありません。 |
Apache HTTP Serverにプラグインをインストールしたら、WebLogic Server Apacheプラグインの構成と、プラグインを使用するためのサーバーの構成を行います。この項では、Apacheのhttpd.conf
ファイルを編集して、プラグイン用のWebLogic ServerライブラリをApacheモジュールとしてロードするようにApacheサーバーに通知し、そのモジュールで処理するアプリケーション・リクエストを指定する方法を説明します。
Apache HTTP Serverインストールのhttpd.conf
ファイルを編集し、Apache HTTP Serverプラグインを構成します。
この項では、httpd.conf
ファイルの検索と編集、WebLogic Server Apacheプラグインを使用するためのサーバーの構成、パスまたはMIMEタイプによるリクエストのプロキシ、HTTPトンネリングの有効化、その他のWebLogic Serverプラグインのパラメータを使用する方法について説明します。
httpd.conf
ファイルを開きます。
このファイルは、APACHE_HOME\conf\httpd.conf
(APACHE_HOME
はApache HTTP Serverをインストールした場所のルート・ディレクトリ)にあります。「境界認証の設定」のサンプルのhttpd.conf
ファイルを参照してください。
Apache 2.0.xのWebLogic Serverモジュールが含まれていることを確認し、httpd.conf
ファイルに次の行を手動で追加します。
LoadModule weblogic_module modules\mod_wl_20.so
次のいずれかを定義するIfModule
ブロックを追加します。
クラスタリングされていないWebLogic Serverの場合: WebLogicHost
およびWebLogicPort
パラメータ
WebLogic Serverのクラスタの場合: WebLogicCluster
パラメータ
例:
<IfModule mod_weblogic.c> WebLogicHost myweblogic.server.com WebLogicPort 7001 </IfModule>
MIMEタイプによってリクエストをプロキシするには、MatchExpression
行をIfModule
ブロックに追加します。MIMEタイプおよびパスによるプロキシの両方を有効にした場合、パスによるプロキシがMIMEタイプによるプロキシに優先することに注意してください。
たとえば、クラスタリングされていないWebLogic Serverに対する次のIfModule
ブロックでは、MIMEタイプが.jspであるすべてのファイルがプロキシされます。
<IfModule mod_weblogic.c> WebLogicHost myweblogic.server.com WebLogicPort 7001 MatchExpression *.jsp </IfModule>
次のように、複数のMatchExpressions
を使用することもできます。
<IfModule mod_weblogic.c> WebLogicHost myweblogic.server.com WebLogicPort 7001 MatchExpression *.jsp MatchExpression *.xyz </IfModule>
MIMEタイプによってWebLogic Serverのクラスタにリクエストをプロキシする場合は、WebLogicHost
およびWebLogicPort
パラメータのかわりにWebLogicCluster
パラメータを使用します。例:
<IfModule mod_weblogic.c> WebLogicCluster w1s1.com:7001,w1s2.com:7001,w1s3.com:7001 MatchExpression *.jsp MatchExpression *.xyz </IfModule>
パスによってリクエストをプロキシするには、Location
ブロックおよびSetHandler
文を使用します。SetHandler
は、Apache HTTP Serverプラグイン・モジュールのハンドラを指定します。たとえば、次のLocationブロックでは、URLに/weblogicが含まれるすべてのリクエストがプロキシされます。
<Location /weblogic> SetHandler weblogic-handler PathTrim /weblogic </Location>
PathTrim
パラメータには、WebLogic Serverインスタンスにリクエストを渡す前にURLの先頭から切り取る文字列を指定します(「Webサーバー・プラグインの一般的なパラメータ」を参照)。
必要に応じて、t3またはIIOPのHTTPトンネリングを有効にします。
t3プロトコルおよびweblogic.jar
を使用する場合にHTTPトンネリングを有効にするには、次のLocation
ブロックをhttpd.conf
ファイルに追加します。
<Location /bea_wls_internal/HTTPClnt> SetHandler weblogic-handler </Location>
IIOP (WebLogic Serverシン・クライアントのwlclient.jar
で使用される唯一のプロトコル)を使用する場合にHTTPトンネリングを有効にするには、次のLocation
ブロックをhttpd.conf
ファイルに追加します。
<Location /bea_wls_internal/iiop> SetHandler weblogic-handler </Location>
Apache HTTP Serverプラグインの追加パラメータを定義します。
Apache HTTP Serverプラグインは、「Webサーバー・プラグインの一般的なパラメータ」にリストされているパラメータを認識します。Apache HTTP Serverプラグインの動作を変更するには、次のいずれかでパラメータを定義します。
Location
ブロック(パスによるプロキシに適用されるパラメータの場合)、または
IfModule
ブロック(MIMEタイプによるプロキシに適用されるパラメータの場合)。
IfModuleを使用しない場合は、Location
またはVirtualHost
ブロック内にWebLogicプロパティを直接配置できます。次にLocation
およびVirtualHost
ブロックの例を示します。
<Location /weblogic> SetHandler weblogic-handler WebLogicHost myweblogic.server.com WebLogicPort 7001 </Location> <Location /weblogic> SetHandler weblogic-handler WebLogicCluster w1s1.com:7001,w1s2.com:7001,w1s3.com:7001 </Location> <VirtualHost apachehost:80> SetHandler weblogic-handler WebLogicServer weblogic.server.com WebLogicPort 7001 </VirtualHost>
別個の構成ファイルを複数用意する場合は、httpd.conf
ファイルのIfModule
ブロックのApache Includeディレクティブを使用して、weblogic.conf
という独立した構成ファイルでパラメータを定義できます。
<IfModule mod_weblogic.c> # Config file for WebLogic Server that defines the parameters Include conf/weblogic.conf </IfModule>
weblogic.conf
ファイルの構文は、httpd.conf
ファイルの構文と同じです。
この項では、weblogic.conf
ファイルの作成方法を説明し、サンプルのweblogic.conf
ファイルが含まれています。
weblogic.conf
ファイルを作成する際には、次の点に注意してください。
パラメータはそれぞれ独立した行に入力します。パラメータとその値の間に'='を挿入しないでください。例:
PARAM_1 value1 PARAM_2 value2 PARAM_3 value3
IfModule
ブロックのMatchExpression
で指定されたMIMEタイプとLocation
ブロックで指定されたパスの両方にリクエストが一致する場合は、Location
ブロックで指定された動作が優先されます。
Apache HTTP Serverの<VirtualHost>
ブロックを使用する場合は、<VirtualHost>
ブロック(http://httpd.apache.org/docs/vhosts/
のApache仮想ホスト・ドキュメントを参照)内の仮想ホストのすべての構成パラメータ(たとえば、MatchExpression
)を含める必要があります。
環境内に構成されているすべての仮想ホストのログ・ファイルを1つのみにしたい場合は、グローバル・プロパティを使用すれば実現できます。各仮想ホストでDebug
、WLLogFile
およびWLTempDir
プロパティを指定するかわりに、<IfModule>
タグで一度に指定できます。
httpd.conf
ファイルのサンプル:
<IfModule mod_weblogic.c> WebLogicCluster johndoe02:8005,johndoe:8006 Debug ON WLLogFile c:/tmp/global_proxy.log WLTempDir "c:/myTemp" DebugConfigInfo On KeepAliveEnabled ON KeepAliveSecs 15 </IfModule> <Location /jurl> SetHandler weblogic-handler WebLogicCluster agarwalp01:7001 </Location> <Location /web> SetHandler weblogic-handler PathTrim/web Debug OFF WLLogFile c:/tmp/web_log.log </Location> <Location /foo> SetHandler weblogic-handler PathTrim/foo Debug ERR WLLogFile c:/tmp/foo_proxy.log </Location>
/jurl/*に一致するすべてのリクエストではDebug LevelがALLに設定され、ログ・メッセージがc:/tmp/global_proxy.log
ファイルに記録されます。/web/*に一致するすべてのリクエストではDebug LevelがOFFに設定され、ログ・メッセージは記録されなくなります。/foo/*に一致するすべてのリクエストではDebug LevelがERRに設定され、ログ・メッセージはc:/tmp/foo_proxy.log
ファイルに記録されます。
<Files>
ブロックではなくMatchExpression
文を使用することをお薦めします。
次のweblogic.conf
ファイルの例をテンプレートとして使用して、ユーザーの環境およびサーバーに合うように変更できます。#で始まる行はコメントです。
例3-1 Weblogicクラスタを使用した例
# These parameters are common for all URLs which are # directed to the current module. If you want to override # these parameters for each URL, you can set them again in # the <Location> or <Files> blocks. (Except WebLogicHost, # WebLogicPort, WebLogicCluster, and CookieName.) <IfModule mod_weblogic.c> WebLogicCluster w1s1.com:7001,w1s2.com:7001,w1s3.com:7001 ErrorPage http://myerrorpage.mydomain.com MatchExpression *.jsp </IfModule> ####################################################
例3-2で、ファイル名のパターン、HTTPリクエストのトランスポート先となるWebLogic Serverホストおよびその他のパラメータを表すMatchExpression
パラメータの構文は次のとおりです。
MatchExpression [filename pattern] [WebLogicHost=host] | [paramName=value]
最初のMatchExpression
パラメータではファイル名パターン*.jspを指定してから、1つのWebLogicHost名を指定しています。パイプ記号の後に続くparamName=value
の組合せでWebLogic Serverが接続リクエストをリスニングするポートを指定し、さらにデバッグ・オプションを有効にするよう指定しています。2番目のMatchExpression
では、ファイル名パターン*.httpを指定し、WebLogicClusterホストおよびそのポートを特定しています。パイプ記号の後に続くparamName=value
の組合せでは、クラスタのエラー・ページを指定しています。
例3-2 複数のWebLogicクラスタを使用した例
# These parameters are common for all URLs which are # directed to the current module. If you want to override # these parameters for each URL, you can set them again in # the <Location> or <Files> blocks (Except WebLogicHost, # WebLogicPort, WebLogicCluster, and CookieName.) <IfModule mod_weblogic.c> MatchExpression *.jsp WebLogicHost=myHost|WebLogicPort=7001|Debug=ON MatchExpression *.html WebLogicCluster=myHost1:7282,myHost2:7283|ErrorPage= http://www.xyz.com/error.html </IfModule>
例3-3に、WebLogicクラスタを使用しない例を示します。
例3-3 WebLogicクラスタを使用しない例
# These parameters are common for all URLs which are # directed to the current module. If you want to override # these parameters for each URL, you can set them again in # the <Location> or <Files> blocks (Except WebLogicHost, # WebLogicPort, WebLogicCluster, and CookieName.) <IfModule mod_weblogic.c> WebLogicHost myweblogic.server.com WebLogicPort 7001 MatchExpression *.jsp </IfModule>
例3-4に、複数の名前ベースの仮想ホストを構成する例を示します。
例3-4 複数の名前ベースの仮想ホストを構成する例
# VirtualHost1 = localhost:80 <VirtualHost 127.0.0.1:80> DocumentRoot "C:/test/VirtualHost1" ServerName localhost:80 <IfModule mod_weblogic.c> #... WLS parameter ... WebLogicCluster localhost:7101,localhost:7201 # Example: MatchExpression *.jsp <some additional parameter> MatchExpression *.jsp PathPrepend=/test2 </IfModule> </VirtualHost> # VirtualHost2 = 127.0.0.2:80 <VirtualHost 127.0.0.2:80> DocumentRoot "C:/test/VirtualHost1" ServerName 127.0.0.2:80 <IfModule mod_weblogic.c> #... WLS parameter ... WebLogicCluster localhost:7101,localhost:7201 # Example: MatchExpression *.jsp <some additional parameter> MatchExpression *.jsp PathPrepend=/test2 #... WLS parameter ... </IfModule> </VirtualHost>
ServerName
には一意の値を定義する必要があります。一意でない場合、一部のプラグイン・パラメータが意図したとおりに機能しません。
この項では、httpd.conf
ファイルのサンプルを紹介します。このサンプルをテンプレートとして使用し、ユーザーの環境およびサーバーに合うように変更できます。#で始まる行はコメントです。
Apache HTTP Serverでは大文字と小文字は区別されません。
例3-5 Apache 2.0のhttpd.confファイルのサンプル
#################################################### APACHE-HOME/conf/httpd.conf file #################################################### LoadModule weblogic_module libexec/mod_wl_20.so <Location /weblogic> SetHandler weblogic-handler PathTrim /weblogic ErrorPage http://myerrorpage1.mydomain.com </Location> <Location /servletimages> SetHandler weblogic-handler PathTrim /something ErrorPage http://myerrorpage1.mydomain.com </Location> <IfModule mod_weblogic.c> MatchExpression *.jsp WebLogicCluster w1s1.com:7001,w1s2.com:7001,w1s3.com:7001 ErrorPage http://myerrorpage.mydomain.com </IfModule>
Apacheプラグインを介してアクセスされるWebLogic Serverアプリケーションを保護するには、境界認証を使用します。
WebLogic IDアサーション・プロバイダは、WebLogic Serverアプリケーションにアクセスする外部システム(Apache HTTP Serverプラグインを介してWebLogic Serverアプリケーションにアクセスするユーザーを含む)のトークンを認証します。プラグインを保護するIDアサーション・プロバイダを次のように作成します。
WebLogic ServerアプリケーションにカスタムIDアサーション・プロバイダを作成します。『Oracle WebLogic Serverセキュリティ・プロバイダの開発』のカスタムIDアサーション・プロバイダの開発方法に関する項を参照してください。
Certトークン・タイプをサポートするようにカスタムIDアサーション・プロバイダを構成し、Certをアクティブなトークン・タイプにします。『Oracle WebLogic Serverセキュリティ・プロバイダの開発』の新しいトークン・タイプの作成方法に関する項を参照してください。
Webアプリケーションのweb.xmlデプロイメント記述子ファイルで、clientCertProxy
をTrueに設定します。(クラスタを使用する場合、必要に応じて、管理コンソールの「クラスタ」-->「構成」-->「一般」タブで、クラスタ全体に対して「クライアント証明書プロキシの有効化」属性をtrueに設定します。clientCertProxy
属性は、サード・パーティ製のプロキシ・サーバー(ロード・バランサ、SSLアクセラレータなど)で双方向のSSL認証を有効にするために使用できます。clientCertProxy
属性の詳細は、『Oracle WebLogic Server Webアプリケーション、サーブレット、JSPの開発』のcontext-paramに関する項を参照してください。
clientCertProxy
を設定したら、接続フィルタを使用して、Apacheプラグインが動作しているマシンからの接続のみをWebLogic Serverが受け入れるようにします。『Oracle WebLogic Serverセキュリティのプログラミング』のネットワーク接続フィルタの使用方法に関する項を参照してください。
プラグインとWebLogic Serverの間でSSLを使用するには、Webサーバー・プラグインで信頼性のある認証局ファイルが必要になります。Sunのkeytoolユーティリティを使用して、WL_HOME/server/lib
にあるDemoTrust.jks
キーストア・ファイルから信頼性のある認証局ファイルをエクスポートします。
たとえば、wlsdemocaファイルを抽出するには次のようなコマンドを使用します。
keytool -export -file trustedcafile.der -keystore DemoTrust.jks -alias wlsdemoca
キーストアから別の信頼性のあるCAファイルを取得するには、別名を変更します。
キーストアの信頼されたCAファイルをすべて表示するには、次を使用します。
keytool -list -keystore DemoTrust.jks
パスワードを要求されたら「Enter」を押します。
認証局ファイルをpem形式に変換するには、コマンドjava utils.der2pem trustedcafile.derを使用します。
『Oracle WebLogic Serverセキュリティ・プロバイダの開発』のIDアサーション・プロバイダに関する項を参照してください。
Secure Sockets Layer (SSL)プロトコルを使用すると、Apache HTTP ServerプラグインとWebLogic Serverの間の接続を保護できます。SSLプロトコルによって、Apache HTTP ServerプラグインとWebLogic Serverの間でやり取りされるデータに機密性と整合性がもたらされます。
Apache HTTP Serverプラグインは、Apache HTTP ServerプラグインとWebLogic Serverの間の接続の保護にSSLプロトコルが使用されるかどうかを決定する際に、(通常はブラウザによって)HTTPリクエストに指定されるトランスポート・プロトコル(httpまたはhttps)を使用しません。
HTTPクライアントとApache HTTP Server間では相互SSLを使用できますが、Apache HTTP ServerとWebLogic Server間では一方向のSSLが使用されます。
Apache HTTP ServerプラグインとWebLogic Serverの間でSSLプロトコルを使用するには:
SSL向けにWebLogic Serverを構成します。詳細は、「SSLの構成」を参照してください。
WebLogic ServerのSSLリスニング・ポートを構成します。詳細は、「SSLの構成」を参照してください。
Apacheサーバーで、httpd.conf
ファイルのWebLogicPort
パラメータに、ステップ2で構成したWebLogic ServerのSSLリスニング・ポートを設定します。
Apacheサーバーで、httpd.conf
ファイルのSecureProxy
パラメータをONに設定します。
SSL接続の情報を定義する追加パラメータをhttpd.conf
ファイルで設定します。プラグインに構成可能なSSLパラメータのリストについては、「Webサーバー・プラグインのSSLパラメータ」を参照してください。
SSLを使用するためにApacheプラグインを構成する際に、次の既知の問題が発生します:
プラグイン構成を準備するには、Internet Explorerを使用してロックをクリックして証明書のパスに移動します。
ルートCA (最上部)を選択します。
ルートCAを表示します。
詳細を表示し、「Base 64 X509」オプションを使用してこの証明書を(エクスポート・ウィザードを使用して)ファイルにコピーします。
ファイルを保存します。たとえば、 MyWeblogicCAToTrust.cer(PEMファイルでもあります)に保存します。
PathTrim
パラメータ(「Webサーバー・プラグインのSSLパラメータ」を参照)を<Location>
タグ内に構成する必要があります。
次の構成は正しくありません:
<Location /weblogic> SetHandler weblogic-handler </Location> <IfModule mod_weblogic.c> WebLogicHost localhost WebLogicPort 7001 PathTrim /weblogic </IfModule>
次の構成は正しい設定です。
<Location /weblogic> SetHandler weblogic-handler PathTrim /weblogic </Location>
WebLogic Server Apacheプラグインの現在の実装では、Apache SSLに関して複数の証明書ファイルの使用はサポートされていません。
Apache HTTP Serverプラグインは、WebLogic Serverに接続しようとする際に、複数の構成パラメータを使用してWebLogic Serverホストへの接続の待機時間と、接続確立後のレスポンスの待機時間を決定します。接続できないか、またはレスポンスがない場合、プラグインはクラスタ内の別のWebLogic Serverインスタンスに接続してリクエストを送信しようとします。接続が失敗するか、またはクラスタ内のいずれのWebLogic Serverからもレスポンスがない場合は、エラー・メッセージが送信されます。
図3-1は、プラグインがどのようにフェイルオーバーを処理するかを示しています。
WebLogic Serverホストが接続リクエストに対するレスポンスに失敗した場合、次の問題が考えられます。
ホスト・マシンの物理的な問題
ネットワークの問題
その他のサーバーの障害
すべてのWebLogic Serverインスタンスがレスポンスに失敗した場合、次の問題が考えられます。
WebLogic Serverが実行中でないか、使用不可になっている
サーバーのハング
データベースの問題
アプリケーション固有の障害
負荷がかかっていると、ApacheプラグインはバックエンドのWebLogic ServerインスタンスからCONNECTION_REFUSEDエラーを受け取ることがあります。CONNECTION_REFUSEDエラーを減らすには、チューニングに関する次のヒントに従ってください。
WebLogic Serverドメインの構成のAcceptBackLog
設定を増やします。
Apache 2.0.xで、httpd.conf
ファイルのKeepAlive
ディレクティブをOnに設定します。例:
# KeepAlive: Whether or not to allow persistent connections (more than # one request per connection). Set to "Off" to deactivate. # KeepAlive On
http://httpd.apache.org/docs-project/
のApache HTTP Server 2.0ドキュメントを参照してください。
待機時間を短くします。この設定は、使用するオペレーティング・システムによって異なります。例:
Windows NTでは、プロキシおよびWebLogic ServerのTcpTimedWaitDelay
をより小さな値に設定します。HKEY_LOCAL_MACHINE配下のレジストリ・キーを編集して、Windows NTでのTIME_WAIT間隔を設定します。
SYSTEM\CurrentControlSet\Services\Tcpip\Parameters\TcpTimedWaitDelay
このキーが存在しない場合、DWORD値として作成します。数値は待機する秒数で、30と240の間の任意の値を設定できます。設定しない場合、Windows NTでは、デフォルトで240秒がTIME_WAITに設定されます。
Windows 2000では、HKEY_LOCAL_MACHINE配下のレジストリ・キーを編集してTcpTimedWaitDelay
の値を小さくします。
SYSTEM\CurrentControlSet\Services\Tcpip\Parameters
Solarisでは、(可能であれば、WebLogic ServerマシンとApacheマシンの両方で)tcp_time_wait_interval
の設定を1秒に減らします。
$ndd /dev/tcp param name to set - tcp_time_wait_interval value=1000
マシン上でオープン・ファイル記述子の制限値を増加します。この制限はオペレーティング・システムによって異なります。limit (.csh)またはulimit (.sh)ディレクティブを使用して、制限値を増やすスクリプトを作成できます。例:
#!/bin/sh ulimit -S -n 100 exec httpd
Solarisでは、WebLogic Serverマシンの次のチューニング可能項目の値を増やします。
tcp_conn_req_max_q tcp_conn_req_max_q0
WebLogic Serverインスタンスを1つだけ実行している場合、プラグインはWebLogicHostパラメータで定義されているサーバーに接続しようとします。その試行が失敗すると、HTTP 503エラー・メッセージが戻されます。プラグインは、ConnectTimeoutSecs
とConnectRetrySecs
の比によって規定される最大再試行回数に従って、WebLogic Serverインスタンスへの接続を試行します。
クラスタリングされたバックエンド・サーバーのリストにプロキシするため、またはクラスタリングされていない管理対象サーバー・インスタンスのロード・バランシングを実行するため、WebLogicCluster
パラメータが必要です。
クラスタリングされた管理対象サーバーにプロキシする場合、httpd.conf
またはweblogic.conf
ファイルでWebLogicCluster
パラメータを使用してWebLogic Serverのリストを指定すると、プラグインはクラスタ・メンバー間でのロード・バランシングの起点としてそのリストを使用します。最初のリクエストがそれらのサーバーの1つに転送された後に、クラスタ内のサーバーの更新されたリストを格納する動的サーバー・リストが戻されます。更新されたリストでは、クラスタ内の新しいサーバーが追加され、クラスタを離脱したサーバーやリクエストに応答できなかったサーバーは削除されます。このリストは、クラスタ内で変化が発生したときにHTTPレスポンスによって自動的に更新されます。
リクエストが、CookieやPOSTデータに格納されているかURLにエンコードされたセッション情報を含む場合、そのセッションIDには、セッションが最初に確立された特定のサーバー・インスタンス(プライマリ・サーバーと呼びます)への参照が含まれています。Cookieを含むリクエストは、プライマリ・サーバーに接続しようとします。その試行が失敗すると、プラグインはラウンド・ロビン方式でリストの次の使用可能なサーバーに接続しようとします。そのサーバーは元のセカンダリ・サーバーからセッションを取得し、その同じセッションのプライマリ・サーバーになります。詳細は、図3-1を参照してください。
注意: POSTデータが64Kを超える場合、プラグインは、セッションIDを取得するためのPOSTデータの解析を行いません。したがって、セッションIDをPOSTデータに格納した場合、プラグインはリクエストを正しいプライマリまたはセカンダリ・サーバーにルーティングできないので、セッション・データが失われるおそれがあります。 |
この図において、赤いループで許容される最大再試行回数は、ConnectTimeoutSecs/ConnectRetrySecs
の値に相当します。