| Oracle® Fusion Middleware Oracle WebCenter Contentエンタープライズ・デプロイメント・ガイド 11g リリース1 (11.1.1) B66703-02 |
|
 前 |
 次 |
| Oracle® Fusion Middleware Oracle WebCenter Contentエンタープライズ・デプロイメント・ガイド 11g リリース1 (11.1.1) B66703-02 |
|
前 |
次 |
この章では、EDGの推奨事項に従ってノード・マネージャを構成する方法を説明します。この章には次の項目があります。
ノード・マネージャによって、Oracle WebLogic Serverドメインの管理サーバーと管理対象サーバーの開始および停止ができます。表13-1では、設定手順を説明するほか、設定プロセスの概要、ノード・マネージャ・ログおよびホスト名検証の推奨場所について説明します。
表13-1 ノード・マネージャの設定手順
| 手順 | 説明 | 詳細 |
|---|---|---|
|
EDの管理ディレクトリ内でノード・マネージャ・ログの場所を指定します。 |
nodemanager.propertiesファイルにある |
|
|
ノード・マネージャと管理サーバー間のSSL通信を設定します。 |
自己署名付き証明書を生成し、トラスト・キーストアおよびアイデンティティ・キーストアを作成するほか、カスタム・キーストアを使用するためにノード・マネージャおよび管理対象サーバーを構成し、各管理対象サーバーのホスト名検証設定を変更します。 |
第13.3項「ノード・マネージャのホスト名検証証明書の有効化」 |
|
ノード・マネージャの起動 |
初めてノード・マネージャを起動する場合は、その前にsetNMProps.shを実行します。 |
|
プロセス
この章で説明される手順は、第2.1.1項「このガイドに記載されている参照用トポロジ」で概略を説明したエンタープライズ・デプロイメント・トポロジの各種コンポーネントで実行される必要があります。この章では、コンポーネント固有のアイテム間で識別するために変数を使用しています。
WLS_SERVER: エンタープライズ・デプロイメント・コンポーネントのWebLogic管理対象サーバー(例: WLS_SOA1)を示します。
HOST: エンタープライズ・デプロイメント・コンポーネントのホスト・コンピュータ(例: SOAHOST1)を示します。
VIP: エンタープライズ・デプロイメント・コンポーネントの仮想IP(例: SOAHOST1VHN1)を示します。
これらの変数に使用する値は、このEDGのコンポーネント関連の章に記載されています。この章に記載されている手順は、コンポーネント関連の章に記載されている情報を使用して、VIPとIPのペアごとに複数回にわたり実行する必要があります。
推奨事項
エンタープライズ・デプロイメント・トポロジのノード・マネージャの構成に関して、次の2つの推奨事項があります。
ノード・マネージャのログ・ファイルをデフォルトの場所(ノード・マネージャが配置されているミドルウェア・ホーム)とは異なる場所に置くことをお薦めします。詳細は、第13.2項「ノード・マネージャのログの場所の変更」を参照してください。
また、ドメインのサーバーとノード・マネージャとの間における通信ではホスト名検証を使用することをお薦めします。それには、ドメイン内で使用される複数のアドレスの証明書を使用する必要があります。この章では、ホスト名検証のために各ホストで証明書を構成する手順について説明します。詳細は、第13.3項「ノード・マネージャのホスト名検証証明書の有効化」を参照してください。
|
注意: このガイドで使用するパスワードはあくまでも一例にすぎません。本番環境ではセキュアなパスワードを使用してください。たとえば、大文字と小文字の両方および数字をランダムな順序で並べたパスワードを使用します。 |
MW_HOME/wlserver_10.3/common/nodemanager/nodemanager.propertiesにあるノード・マネージャのプロパティ・ファイルを編集します。ログ・ファイルの新しい場所を指定する次の行を追加します。
LogFile=ORACLE_BASE/admin/nodemanager.log
この場所はMW_HOMEディレクトリの外かつEDGのadminディレクトリの中に置くことをお薦めします。
ノード・マネージャを再起動して、変更を有効にします。
ノード・マネージャと管理サーバー間の通信にSSLを設定する手順は次のとおりです。
ステップ6: 管理対象サーバーのホスト名検証設定の変更
この章で(例として)追加される証明書は、ノード・マネージャが物理ホスト名(HOST.mycompany.com)でリッスンし、WLS管理対象サーバーが仮想ホスト名(VIP.mycompany.com)でリッスンする構成に対応します。サーバーが仮想ホスト名を使用している場合は、サーバーを1つのノードから別のノードに移行できることを意味します。したがって、キーストアおよびトラスト・キーストアを保持するディレクトリは、理想としては、フェイルオーバーが発生してもアクセス可能な共有記憶域に配置する必要があります。同じノードまたは別のノードで別のホスト名を使用する場合は、この例の手順は次のように拡張されます。
証明書ストアに必要なホスト名を追加します(必要なホスト名がHOST.mycompany.comおよびVIP.mycompany.comと異なる場合)。
ノード・マネージャ(追加のホスト名がノード・マネージャで使用される場合)またはサーバー(追加のホスト名が管理対象サーバーで使用される場合)のアイデンティティ・ストアとトラスト・ストアの場所に関する情報を変更します。
次の手順に従って、HOSTに自己署名証明書を作成します。これらの証明書はネットワーク名または別名を使用して作成する必要があります。自己署名証明書のかわりに信頼できるCA証明書を使用するには、『Oracle Fusion Middleware Oracle WebLogic Serverの保護』でアイデンティティとトラストの構成に関する項を参照してください。次の例は、HOST.mycompany.comおよびVIP.mycompany.comの証明書を構成しています。すなわち、物理ホスト名(HOST)と仮想ホスト名(VIP)の両方がHOSTで使用されることを想定しています。また、HOST.mycompany.comはノード・マネージャが使用するアドレスであり、VIP.mycompany.comは管理対象サーバーまたは管理サーバーが使用するアドレスであることを想定しています。これは、管理サーバーとFusion Middlewareコンポーネントをホストするノードや、共存する2つの管理対象サーバーの一方が物理ホスト名をリスニングし、もう一方が仮想ホスト名を使用(移行サーバーを使用するサーバーの場合)するノードで、よく見られる状況です。
WL_HOME/server/bin/setWLSEnv.shスクリプトを実行して環境を設定します。Bourneシェルの場合、HOST上で次のコマンドを実行します。
cd WL_HOME/server/bin
. ./setWLSEnv.sh
CLASSPATH環境変数が設定されていることを確認します。
echo $CLASSPATH
キーストアおよびトラスト・キーストアを保持するディレクトリは、すべてのノードからアクセスできる共有記憶域に配置して、サーバーが(手動またはサーバー移行により)フェイルオーバーしたときにフェイルオーバー・ノードから適切な証明書にアクセスできるようにする必要があります。各種目的(HTTPの起動用のSSL設定など)で使用される証明書には、中央ストアまたは共有ストアを使用することをお薦めします。この場合、SOAHOST2では、SOAHOST1の証明書用に作成されたcertディレクトリを使用します。証明書用のユーザー定義ディレクトリを作成します。
mkdir cert
ディレクトリを今しがた作成したディレクトリに変更します。
cd cert
HOST上でユーザー定義ディレクトリからutils.CertGenツールを実行して、HOST. mycompany.comおよびVIP. mycompany.comの両方に対する証明書を作成します。
構文:
java utils.CertGen Key_Passphrase Cert_File_Name Key_File_Name [export | domestic] [Host_Name]
例:
java utils.CertGen welcome1 HOST.mycompany.com_cert HOST.mycompany.com_key domestic HOST.mycompany.com java utils.CertGen welcome1 VIP.mycompany.com_cert VIP.mycompany.com_key domestic VIP.mycompany.com
次の手順に従って、HOSTにIDキーストアを作成します。
utils.ImportPrivateKeyユーティリティを使用して、appIdentityKeyStoreという名前で新しいアイデンティティ・キーストアを作成します。このキーストアの作成場所は、証明書と同じディレクトリ(ORACLE_BASE/admin/domain_name/cert)とします。
|
注意: utils.ImportPrivateKeyユーティリティを使用して証明書および対応する鍵をアイデンティティ・ストアにインポートする際、アイデンティティ・ストアが1つも存在しない場合は、新しく作成されます。 |
HOST上で、HOST.mycompany.comおよびVIP.mycompany.comの両方の証明書と秘密鍵をアイデンティティ・ストアにインポートします。必ず、インポートする証明書と鍵のペアごとに異なる別名を使用してください。
構文(すべてを1行で入力します):
java utils.ImportPrivateKey Keystore_File Keystore_Password
Certificate_Alias_to_Use Private_Key_Passphrase
Certificate_File
Private_Key_File
[Keystore_Type]
例:
java utils.ImportPrivateKey appIdentityKeyStore.jks welcome1 appIdentity1 welcome1 ORACLE_BASE/admin/domain_name/cert/HOST.mycompany.com_cert.pem ORACLE_BASE/admin/domain_name/cert/HOST.mycompany.com_key.pem java utils.ImportPrivateKey appIdentityKeyStore.jks welcome1 appIdentity2 welcome1 ORACLE_BASE/admin/domain_name/cert/VIP.mycompany.com_cert.pem ORACLE_BASE/admin/domain_name/cert/VIP.mycompany.com_key.pem
次の手順に従って、HOSTにトラスト・キーストアを作成します。
新しいトラスト・キーストアを作成するには、標準のJavaキーストアをコピーします。これは、必要なほとんどのルートCA証明書がこのJavaキーストアに存在するからです。標準のJavaトラスト・キーストアを直接変更することはお薦めしません。WL_HOME/server/libディレクトリの下にあるHOST上で標準JavaキーストアのCA証明書をその証明書と同じディレクトリにコピーします。たとえば、次のようになります。
cp WL_HOME/server/lib/cacerts ORACLE_BASE/admin/domain_name/cert/appTrustKeyStore.jks
標準のJavaキーストアのデフォルトのパスワードはchangeitです。デフォルトのパスワードは常に変更することをお薦めします。これを実行するには、HOST上でkeytoolユーティリティを使用します。構文は、次のとおりです。
keytool -storepasswd -new New_Password -keystore Trust_Keystore -storepass Original_Password
例:
keytool -storepasswd -new welcome1 -keystore appTrustKeyStore.jks -storepass changeit
このCA証明書(CertGenCA.der)は、utils.CertGenツールで生成するすべての証明書の署名に使用します。これは、WL_HOME/server/libディレクトリにあります。このCA証明書は、HOST上でkeytoolユーティリティを使用して、appTrustKeyStoreにインポートする必要があります。構文は、次のとおりです。
keytool -import -v -noprompt -trustcacerts -alias Alias_Name -file CA_File_Location -keystore Keystore_Location -storepass Keystore_Password
例:
keytool -import -v -noprompt -trustcacerts -alias clientCACert -file WL_HOME/server/lib/CertGenCA.der -keystore appTrustKeyStore.jks -storepass welcome1
カスタム・キーストアを使用するようにノード・マネージャを構成するには、WL_HOME/common/
nodemanagerディレクトリにあるnodemanager.propertiesファイルの最後に次の行を追加します。
KeyStores=CustomIdentityAndCustomTrust CustomIdentityKeyStoreFileName=Identity_Keystore CustomIdentityKeyStorePassPhrase=Identity_Keystore_Password CustomIdentityAlias=Identity_Keystore_Alias CustomIdentityPrivateKeyPassPhrase=Private_Key_Used_When_Creating_Certificate
各ノードのCustomIdentityAliasに正しい値が使用されていることを確認します。これは、各ノードに個々に割り当てられたカスタム・アイデンティティの別名(たとえば、...HOST2など)に当たります。
KeyStores=CustomIdentityAndCustomTrust CustomIdentityKeyStoreFileName=ORACLE_BASE/admin/domain_name/cert/appIdentityKeyStore.jks CustomIdentityKeyStorePassPhrase=welcome1 CustomIdentityAlias=appIdentity2 CustomIdentityPrivateKeyPassPhrase=welcome1
第13.4項「ノード・マネージャの起動」の説明に従ってノード・マネージャを起動すると、nodemanager.propertiesファイルにあるパスフレーズのエントリが暗号化されます。 セキュリティ上の理由から、nodemanager.propertiesファイル内のエントリが暗号化されていない時間を最小に抑える必要があります。ファイルを編集した後、できるだけ速やかにノード・マネージャを起動し、エントリを暗号化してください。
共通記憶域または共有記憶域のインストールをMW_HOMEに指定している場合、ノード・マネージャは同じ基本構成(nodemanager.properties)を使用してそれぞれのノードから起動します。この場合、バイナリを共有するすべてのノード用の証明書をappIdentityKeyStore.jksアイデンティティ・ストアに追加する必要があります。これを行うには、新しいノードの証明書を作成し、第13.3.2項「utils.ImportPrivateKeyユーティリティを使用したアイデンティティ・キーストアの作成」に従って、それをappIdentityKeyStore.jksにインポートします。ストア内で証明書が利用可能になると、各ノード・マネージャは異なるアイデンティティの別名を指定し、正しい証明書を管理サーバーに送信する必要があります。これを実行するためには、HOST上で異なる環境変数を設定し、各ノードでノード・マネージャを起動します。
cd WL_HOME/server/bin export JAVA_OPTIONS=-DCustomIdentityAlias=appIdentityX
|
注意: 各ホストに個々に割り当てられているカスタム・アイデンティティの別名を指定してください。つまり、...HOST1には |
次の手順に従って、WLS_SERVERのIDキーストアとトラスト・キーストアを構成します。
Oracle WebLogic Server管理コンソールにログインします。
「ロックして編集」をクリックします。
「ドメイン構造」ウィンドウの「環境」ノードを開きます。
「サーバー」をクリックします。
「サーバーのサマリー」ページで、アイデンティティ・キーストアとトラスト・キーストアを構成するサーバー名(WLS_SERVER)をクリックします。
選択されたサーバーの設定ページで、「構成」を選択し、「キーストア」を選択します。
「キーストア」フィールドの横にある「変更」をクリックして、秘密鍵/デジタル証明書のペアおよび信頼できるCA証明書を格納し管理するための「カスタムIDとカスタム信頼」方法を選択します。作業が終了したら、「保存」をクリックします。
「ID」セクションで、IDキーストアの次の属性を定義します。
カスタムIDキーストア: IDキーストアへの完全修飾パス。
ORACLE_BASE/admin/domain_name/cert/appIdentityKeyStore.jks
カスタムIDキーストアのタイプ: 空白のままにしてください。デフォルトでJKSに設定されます。
カスタムIDキーストアのパスフレーズ: 第13.3.3項「keytoolユーティリティを使用した信頼キーストアの作成」で指定したパスワード(Keystore_Password)。この属性は、キーストアのタイプに応じて、任意と必須のいずれかになります。すべてのキーストアでは、キーストアへの書込みにパスフレーズが必要です。ただし、一部のキーストアでは、キーストアからの読取りにパスフレーズは不要です。WebLogic Serverは、キーストアからの読取りのみを行うため、このプロパティを定義するかどうかは、キーストアの要件に応じて決まります。
「 信頼 」セクションで、トラスト・キーストアのプロパティを定義します。
カスタム信頼キーストア: トラスト・キーストアへの完全修飾パス。
ORACLE_BASE/admin/domain_name/cert/appTrustKeyStore.jks
カスタム信頼キーストアのタイプ: 空白のままにしてください。デフォルトでJKSに設定されます。
カスタム信頼キーストアのパスフレーズ: 第13.3.3項「keytoolユーティリティを使用した信頼キーストアの作成」で指定したパスワード(New_Password)。この属性は、キーストアのタイプに応じて、任意と必須のいずれかになります。すべてのキーストアでは、キーストアへの書込みにパスフレーズが必要です。ただし、一部のキーストアでは、キーストアからの読取りにパスフレーズは不要です。WebLogic Serverは、キーストアからの読取りのみを行うため、このプロパティを定義するかどうかは、キーストアの要件に応じて決まります。
「保存」をクリックします。
「管理コンソール」の「チェンジ・センター」で、「変更のアクティブ化」をクリックして、これらの変更を有効にします。
「構成」をクリックし、「SSL」をクリックします。
「ロックして編集」をクリックします。
「秘密鍵の別名」フィールドで、管理対象サーバーがリスニングを実行するホスト名に使用した別名を入力します。
「秘密鍵のパスフレーズ」フィールドと「秘密鍵のパスフレーズを確認」フィールドで、第13.3.2項「utils.ImportPrivateKeyユーティリティを使用したIDキーストアの作成」で作成したキーストアのパスワードを入力します。
「保存」をクリックします。
「管理コンソール」の「チェンジ・センター」で、「変更のアクティブ化」をクリックして、これらの変更を有効にします。
変更を適用したサーバーを再起動します。
前述の手順を実行したら、変更を反映した管理対象サーバーのホスト名検証をBea Host Name Verifierに設定する必要があります。これには次の手順を実行します。
WebLogic Server管理コンソールにログインします。
「ドメイン構造」ウィンドウの「環境」ノードを開きます。
「サーバー」をクリックします。
「サーバーのサマリー」ページで、表の「名前」列にある管理対象サーバーを選択します。
サーバーの設定ページで「SSL」タブを開きます。
表示されたページの「詳細」セクションを開きます。
「ロックして編集」をクリックします。
ホスト名検証をBea Host Name Verifierに設定します。
「保存」をクリックします。
変更を適用したサーバーを再起動します。
次のコマンドを実行して、HOSTでノード・マネージャを起動します。ノード・マネージャが未構成で、まだ一度も起動していない場合は、第8.4.3項「SOAHOST1でのノード・マネージャの起動」で指定したsetNMProps.shスクリプトを実行し、管理対象サーバーの起動スクリプトの使用を有効化します。
|
注意: 各ホストに個々に割り当てられているカスタム・アイデンティティの別名を指定してください。つまり、...HOST1には |
cd WL_HOME/server/bin export JAVA_OPTIONS=-DCustomIdentityAlias=appIdentityX ./startNodeManager.sh
