| Oracle® Fusion Middleware Oracle Traffic Director構成ファイル・リファレンス 12c (12.2.1.3.0) E90198-02 |
|
 前 |
 次 |
Oracle Traffic Directorの構成および動作は、一連の構成ファイルによって決定されます。Oracle Fusion Middleware ControlおよびWebLogic Scripting Tool (WLST)を使用して、構成ファイル設定を変更できます。これらのファイルは手動で編集することもできます。
この章の内容は次のとおりです。
各サーバー・インスタンスには独自のディレクトリがあり、このドキュメントではそれをINSTANCE_HOMEと呼びます。INSTANCE_HOME/configディレクトリには、Oracle Traffic Directorコンポーネントの構成ファイルが含まれます。構成ファイルの正確な数と名前は、有効化されているか、またはサーバーにロードされているコンポーネントに応じて異なります。INSTANCE_HOMEのデフォルトの場所は、デフォルト・パスを参照してください。
次の項では、Oracle Traffic Directorの構成ファイルと関連情報について説明します。
server.xmlファイルには、Oracle Traffic Director構成が含まれます。server.xmlファイルの詳細は、server.xmlの構文および使用を参照してください。
certmap.confファイルには、issuerDNによって指定されたLDAPエントリに証明書をマップする方法が記述されています。
certmap name issuerDNname:property1 [value1] name:property2 [value2] ...
デフォルトの証明書はdefaultという名前で、デフォルトのissuerDNもdefaultという名前です。したがって、certmap.confファイルで定義する最初の行は、次のようにする必要があります。
certmap default default
コメントであることを示すには、行頭に#を使用します。
表1-1に、certmap.confファイルのプロパティを示します。
表1-1 certmap.confのプロパティ
| 属性 | 指定できる値 | デフォルト値 | 説明 |
|---|---|---|---|
説明を参照 |
コメント・アウト |
証明書をユーザー・エントリにマップする場合に、LDAP検索の実行用にベースDNを構成するために使用します。値は次のとおりです。
|
|
説明を参照 |
コメント・アウト |
証明書をユーザー・エントリにマップする場合に、LDAP検索の実行用にフィルタを構成するために使用します。値は次のとおりです。
|
|
|
|
証明書を検証するかどうかを指定します。 |
|
LDAP属性の名前 |
|
証明書のDNを含むLDAPデータベースの属性の名前を指定します。 |
|
共有 |
なし |
カスタム証明書マッピング・コードのライブラリ・パスを指定します。 |
|
初期化関数の名前 |
なし |
|
ウォレット・ファイルは、INSTANCE_HOME/configディレクトリに格納されます。
ewallet.p12 - PINを持つ編集可能なウォレット
cwallet.sso - 難読化したパスワードを持つ単一のサインオン・ウォレット(PINは不要)
NZウォレットには3つの操作モードがあります。3つのモードはすべてOTDコア・サーバーでサポートされますが、adminはすべてをサポートしていません。次に、各モードを示します。
ewallet.p12のみ - OTDがウォレットに読取り専用モードでアクセスする、またはadminが読取り書込みモードでウォレットにアクセスする、いずれの場合でも、PINが常に必要です。OTDにより、起動時にPINが求められます。PINは、server.xmlに格納されません。
cwallet.ssoのみ - orapkiでは、"自動ログインのみ"モードと呼ばれます。OTDがウォレットに読取り専用モードでアクセスする、またはadminが読取り書込みモードでウォレットにアクセスする、いずれの場合でも、PINは不要です。
ewallet.p12およびcwallet.sso - orapkiでは"自動ログイン"モードと呼ばれます。OTDが読取り専用モードでウォレットにアクセスするためにPINは不要ですが、adminが読取り書込みモードでウォレットにアクセスするためにはPINが必要です。ewallet.p12が編集されます。それぞれの編集の後、ewallet.p12はcwallet.ssoに変換されます。
Oracle orapkiコマンドライン・ユーティリティを使用して、ウォレットなどの公開鍵インフラストラクチャ(PKI)要素を管理します。詳細は、『Oracle Databaseセキュリティ・ガイド』の付録のorapkiユーティリティを使用したPKI要素の管理に関する項を参照してください
次に、Oracle Traffic Directorで使用されるデフォルト・パスを示します。表1-2に、デフォルト・パスおよびファイル名を示します。
表1-2 デフォルト・パス
| プレースホルダ | 説明 |
|---|---|
|
Oracle Traffic Directorがインストールされているディレクトリ。 |
|
Oracle Traffic Director管理サーバーおよびOracle Traffic Directorインスタンスに関連するファイルを含むディレクトリ。 |
この項では、Oracle Traffic Directorを最初にインストールしたときに作成されるディレクトリ構造について説明します。通常のOTDインストール環境では、admin-serverディレクトリとnet-server-idインスタンス・サブディレクトリを除き、すべてのディレクトリはORACLE_HOMEディレクトリに配置されます。admin-serverディレクトリとnet-server-idサブディレクトリは、INSTANCE_HOMEディレクトリに配置されます。管理サーバーまたは管理ノードを作成するには、configure-serverコマンドを実行する必要があります。OTDで管理ノードを作成する場合、管理サーバーが起動して実行されていることを確認してください。新しく作成された管理ノードは、管理サーバーに登録されます。インスタンスを作成する前に、configure-serverコマンドを実行して管理サーバーを作成します。その後、create-instanceコマンドを実行してOTDでインスタンスを作成します。CLIコマンドの詳細は、『Oracle Traffic Directorコマンドライン・リファレンス』を参照してください。これらのディレクトリに対応するデフォルトの場所の詳細は、デフォルト・パスを参照してください。次のディレクトリは、Oracle Traffic Directorのインストール・ディレクトリであるORACLE_HOMEの下にあります。
admin-serverディレクトリには次のサブディレクトリがあります。
bin - Oracle® Fusion Middlewareを起動、停止および再起動するために使用するバイナリ・ファイルが含まれます。UNIXシステムでは、このディレクトリにログのローテーションに必要なファイルも含まれます。
config - 管理サーバーのプライベート構成ファイルが含まれます。これらのファイルは内部で使用されます。
config-store - 管理サーバーがサーバー構成情報を追跡するために使用するファイルが含まれます。
注意:
このディレクトリのファイルは、により作成され、内部で使用されます。編集、スクリプト実行またはその他の方法でconfig-storeディレクトリのファイルにアクセスしないでください。
generated - JavaServer Pages (JSP)に対応するJavaクラス・ファイルなど、インスタンスによって生成されたファイルが含まれます。
logs - サーバー・インスタンスによって生成されたエラー・メッセージまたはアクセス・ログ・ファイルが含まれます。
A net-server-idディレクトリは、OTDでインスタンスを作成するたびに作成されます。このディレクトリには、次のサブディレクトリとファイルが含まれます。
bin - サーバーを起動、停止、再起動および再構成するためのコマンドが含まれます。また、ログ・ファイルをローテーションするためのコマンドも含まれます。
config - 次のインスタンス固有の構成ファイルが含まれます。
<C1>-obj.conf - 仮想サーバー固有のディレクトリ。
obj.conf - クライアントからのHTTPリクエストを処理するOracle® Fusion Middlewareディレクティブ。
pkcs11.txt - NSS PKCS #11モジュール・データベース。
server.xml - サーバー構成設定の大部分。
logs - このサーバー・インスタンスによって生成されたログ・ファイルが含まれます。
動的再構成によって、変更内容を有効化するために停止および再起動せずに、実行中のOracle Traffic Directorの構成を変更できます。
動的な構成は、次の場合に発生します。
サーバーを再起動せずにobj.confファイルの構成設定を動的に変更できます。また、server.xmlファイルのほとんどの設定もサーバーを再起動せずに変更できます。サーバーを再起動する必要がある場合は、構成をデプロイするかreconfigコマンドを実行する際に、サーバー・ログに警告メッセージが出現します。
server.xmlの次の構成パラメータは、動的に再構成できません。
user
temp-path
log (ログ・レベルを除く)
thread-pool
pkcs11
stats
dns
dns-cache
ssl-session-cache
access-log-buffer
reconfigコマンドを実行すると、新しい構成オブジェクトが作成され、その新しい構成オブジェクトに基づいてすべての新しい着信リクエストが処理されます。現在の構成オブジェクトは、そのオブジェクトを使用しているHTTPリクエストが存在しない場合、削除されます。
動的再構成中に間違った構成が行われると、サーバーにエラー・メッセージが表示されます。サーバーは、正常な最後の構成によって指定されているログ・ファイルにエラー・メッセージを記録します。
一部の間違った構成では、警告メッセージが表示されますが、その構成はサーバーに拒否されません。それ以外の間違ったな構成は、エラー・メッセージをトリガーし、その構成はサーバーに拒否されます。構成がサーバーの起動時に拒否されると、サーバーは起動しません。構成がサーバーの動的再構成時に拒否されると、サーバーは正常な最後の構成に戻ります。
