16 ノード・マネージャの設定

この章では、EDG推奨事項に従ってノード・マネージャを構成する方法について説明します。この章の内容は次のとおりです。

• 第16.1項「ノード・マネージャの設定について」

• 第16.2項「ノード・マネージャのログの場所の変更」

• 第16.3項「ノード・マネージャのホスト名検証証明書の有効化」

• 第16.4項「ノード・マネージャの起動」

16.1 ノード・マネージャの設定について

ノード・マネージャを使用すると、管理サーバーや管理対象サーバーを起動および停止できます。

手順

第1章「エンタープライズ・デプロイメント概要」で説明されているエンタープライズ・デプロイメント・トポロジの各種コンポーネントについて、この章に記載されている手順を実行する必要があります。表16-1に、そのトポロジとホストを示します。

表16-1 各トポロジのホスト

トポロジ	ホスト
OAM11g	IDMHOST1 IDMHOST2
OAM10g/OIM11g	IDMHOST1 IDMHOST2 OAMHOST1 OAMHOST2 OIMHOST1 OIMHOST2
OAM11g/OIM11g	IDMHOST1 IDMHOST2 OIMHOST1 OIMHOST2
OAAM11g	IDMHOST1 IDMHOST2 OAAMHOST1 OAAMHOST2
OIF11g	IDMHOST1 IDMHOST2 OIFHOST1 OIFHOST2

コンポーネント固有の章に記載されている情報を使用して、VPとIPのペアごとにこの章の手順を繰返し実行する必要があります。

推奨事項

エンタープライズ・デプロイメント・トポロジでのノード・マネージャの構成についての主要な推奨事項は、次の2つです。

1. ノード・マネージャのログ・ファイルをデフォルトの場所（ノード・マネージャが配置されているミドルウェア・ホーム）とは異なる場所に置くことをお薦めします。詳細は、第16.2項「ノード・マネージャのログの場所の変更」を参照してください。

2. また、ノード・マネージャとドメイン内のサーバー間の通信についてホスト名検証を使用することもお薦めします。これには、ドメインで使用される各種アドレスの証明書を使用する必要があります。この章では、ホスト名検証用にホストで証明書を構成する手順について説明します。詳細は、第16.3項「ノード・マネージャのホスト名検証証明書の有効化」を参照してください。

注意: このマニュアルで使用するパスワードは、あくまでも例にすぎません。本番環境ではセキュアなパスワードを使用してください。たとえば、大文字と小文字および数字が不規則に連なるパスワードを使用します。

16.2 ノード・マネージャのログの場所の変更

MW_HOME/wlserver_10.3/common/nodemanager/nodemanager.propertiesにあるノード・マネージャのプロパティ・ファイルを編集します。次の行を使用して、ログ・ファイルの新しい場所を追加します。

LogFile=ORACLE_BASE/admin/nodemanager.log

この場所はMW_HOMEディレクトリの外かつEDGのadminディレクトリの中に置くことをお薦めします。

変更を有効にするために、第19.1項「Oracle Identity Managementコンポーネントの起動と停止」の説明に従って、ノード・マネージャを再起動します。

16.3 ノード・マネージャのホスト名検証証明書の有効化

ノード・マネージャと管理サーバー間の通信にホスト名検証証明書を設定する手順は、次のとおりです。

• 手順1: utils.CertGenユーティリティを使用した自己署名証明書の作成

• 手順2: utils.ImportPrivateKeyユーティリティを使用したIDキー・ストアの作成

• 手順3: keytoolユーティリティを使用したトラスト・キーストアの作成

• 手順4: カスタム・キーストアを使用するためのノード・マネージャの構成

• 手順5: カスタム・キーストアを使用するための管理対象WLSサーバーの構成

• 手順6: 管理対象サーバーのホスト名検証設定の変更

16.3.1 utils.CertGenユーティリティを使用した自己署名証明書の作成

この章で（例として）追加される証明書は、ノード・マネージャが物理ホスト名（HOST.mycompany.com）でリッスンし、WLS管理対象サーバーが仮想ホスト名（VIP.mycompany.com）でリッスンする構成に対応します。サーバーが仮想ホスト名を使用している場合は、サーバーを1つのノードから別のノードに移行できることを意味します。したがって、キーストアとトラスト・キーストアを理想的に保持するディレクトリは、フェイルオーバーからアクセス可能な共有記憶域に配置する必要があります。追加のホスト名が同一ノードや異なるノードで使用される場合は、この例の手順に加えて次を実行します。

1. 証明書ストアに必要なホスト名を追加します（必要なホスト名がHOST.mycompany.comおよびVIP.mycompany.comと異なる場合）。

2. ノード・マネージャ（追加のホスト名がノード・マネージャで使用される場合）またはサーバー（追加のホスト名が管理対象サーバーで使用される場合）のアイデンティティ・ストアとトラスト・ストアの場所に関する情報を変更します。

次の手順に従って、HOSTに自己署名証明書を作成します。これらの証明書は、ネットワーク名または別名を使用して作成する必要があります。自己署名証明書の代わりに信頼できるCA証明書を使用する方法については、『Oracle Fusion Middleware Oracle WebLogic Serverの保護』のIDと信頼の構成に関する項を参照してください。次の例では、HOST.mycompany.comおよびVIP.mycompany.comの証明書を構成します。つまり、物理ホスト名（HOST）と仮想ホスト名（VIP）がHOSTで使用されていることを前提としています。また、HOST.mycompany.comはノード・マネージャで使用されるアドレスで、VIP.mycompany.comは管理対象サーバーまたは管理サーバーで使用されるアドレスであることを前提としています。これは、1台の管理サーバーと1つのFusion Middlewareコンポーネントをホストするノードにとって、または2台の管理対象サーバーが物理ホスト名でリスニングする1台のサーバーおよび仮想ホスト名を使用する1台のサーバーと共存するノード（移行サーバーを使用するサーバーの場合）にとっての一般的な状況です。

1. WL_HOME/server/bin/setWLSEnv.shスクリプトを実行して、環境を設定します。Bourneシェルで、次のコマンドを実行します。

   HOST> cd WL_HOME/server/bin
   HOST> ./setWLSEnv.sh
   

   CLASSPATH環境変数が設定されていることを確認します。

   HOST> echo $CLASSPATH
   

2. 証明書用のユーザー定義ディレクトリを作成します。たとえば、ORACLE_BASE/admin/domain_name/aserver/domain_nameディレクトリの下にcertsというディレクトリを作成します。証明書はWLSドメイン間で共有できることに注意してください。

   HOST> cd ORACLE_BASE/admin/domain_name/aserver/domain_name
   HOST> mkdir certs
   

   
   

   注意: サーバーが（手動またはサーバーの移行により）フェイルオーバーした際にフェイルオーバー・ノードから適切な証明書にアクセスできるように、キーストアおよびトラスト・キーストアを保持するディレクトリは、すべてのノードからアクセス可能な共有記憶域に存在している必要があります。各種目的（HTTPの起動用のSSL設定など）で使用される証明書には、中央ストアまたは共有ストアを使用することをお薦めします。

   
   

3. ディレクトリを今しがた作成したディレクトリに変更します。

   HOST> cd certs
   

4. ユーザー定義ディレクトリからutils.CertGenツールを実行して、HOST. mycompany.comおよびVIP. mycompany.comの両方に対する証明書を作成します。

   構文（すべて1行に記述）:

   java utils.CertGen Key_Passphrase Cert_File_Name Key_File_Name  [export | domestic] [Host_Name]
   

   次に例を示します。

   HOST> java utils.CertGen welcome1 HOST.mycompany.com_cert HOST.mycompany.com_key domestic HOST.mycompany.com
   
   HOST> java utils.CertGen welcome1 VIP.mycompany.com_cert VIP.mycompany.com_key domestic VIP.mycompany.com
   

16.3.2 utils.ImportPrivateKeyユーティリティを使用したIDキーストアの作成

次の手順に従って、HOSTにIDキーストアを作成します。

1. utils.ImportPrivateKeyユーティリティを使用してappIdentityKeyStoreという新しいIDキーストアを作成します。このキーストアは、証明書と同じディレクトリ（つまり、ORACLE_BASE/admin/domain_name/aserver/domain_name/certs）に作成します。

   
   

   注意: utils.ImportPrivateKeyユーティリティを使用して証明書およびそれに対応するキーをアイデンティティ・ストアにインポートすると、アイデンティティ・ストアが（存在しない場合は）作成されます。

   
   

2. 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]
   

   次に例を示します。

   HOST> java utils.ImportPrivateKey appIdentityKeyStore.jks welcome1 appIdentity1 welcome1 ORACLE_BASE/admin/domain_name/aserver/domain_name/certs/HOST.mycompany.com_cert.pem ORACLE_BASE/admin/domain_name/aserver/domain_name/certs/HOST.mycompany.com_key.pem
   
   HOST> java utils.ImportPrivateKey appIdentityKeyStore.jks welcome1 appIdentity2 welcome1 ORACLE_BASE/admin/domain_name/aserver/domain_name/certs/VIP.mycompany.com_cert.pem ORACLE_BASE/admin/domain_name/aserver/domain_name/certs/VIP.mycompany.com_key.pem
   

16.3.3 keytoolユーティリティを使用したトラスト・キーストアの作成

次の手順に従って、HOSTにトラスト・キーストアを作成します。

1. 標準のJavaキーストアをコピーし、新しいトラスト・キーストアを作成します。これは、必要なほとんどのルートCA証明書がこのJavaキーストアにすでに存在しているからです。標準のJavaトラスト・キーストアを直接変更しないでください。WL_HOME/server/libディレクトリにある標準のJavaキーストアCA証明書を証明書のあるディレクトリにコピーします。次に例を示します。

   HOST> cp WL_HOME/server/lib/cacerts ORACLE_BASE/admin/domain_name/aserver/domain_name/certs/appTrustKeyStore.jks
   

2. 標準のJavaキーストアのデフォルトのパスワードはchangeitです。常にデフォルトのパスワードを変更することをお薦めします。それには、keytoolユーティリティを使用します。次に構文を示します。

   HOST> keytool -storepasswd -new New_Password -keystore Trust_Keystore -storepass Original_Password
   

   次に例を示します。

   HOST> keytool -storepasswd -new welcome1 -keystore appTrustKeyStore.jks -storepass changeit
   

3. CA証明書CertGenCA.derは、utils.CertGenツールで生成されるすべての証明書の署名に使用されます。これは、WL_HOME/server/libディレクトリにあります。このCA証明書は、keytoolユーティリティを使用してappTrustKeyStoreにインポートする必要があります。次に構文を示します。

   HOST> keytool -import -v -noprompt -trustcacerts -alias Alias_Name -file CA_File_Location -keystore Keystore_Location -storepass Keystore_Password
   

   次に例を示します。

   HOST> keytool -import -v -noprompt -trustcacerts -alias clientCACert -file WL_HOME/server/lib/CertGenCA.der -keystore appTrustKeyStore.jks -storepass welcome1
   

16.3.4 カスタム・キーストアを使用するためのノード・マネージャの構成

カスタム・キーストアを使用するようにノード・マネージャを構成するには、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

KeyStores=CustomIdentityAndCustomTrust
CustomIdentityKeyStoreFileName=ORACLE_BASE/admin/domain_name/aserver/domain_name/certs/appIdentityKeyStore.jks
CustomIdentityKeyStorePassPhrase=welcome1
CustomIdentityPrivateKeyPassPhrase=welcome1

第16.4項「ノード・マネージャの起動」の説明に従ってノード・マネージャを起動すると、nodemanager.propertiesファイルにあるパスフレーズのエントリは暗号化されます。セキュリティ上の理由で、nodemanager.propertiesファイルのエントリが暗号化されていない時間を可能なかぎり短くする必要があります。ファイルを編集した後、できるだけ速やかにノード・マネージャを起動し、エントリを暗号化します。

共通記憶域または共有記憶域インストールをMW_HOMEに使用している場合は、ノード・マネージャは同じ基本構成（nodemanager.properties）を使用してそれぞれのノードから起動します。この場合、バイナリを共有するすべてのノード用の証明書をappIdentityKeyStore.jksアイデンティティ・ストアに追加する必要があります。これを行うには、新しいノードの証明書を作成し、第16.3.2項「utils.ImportPrivateKeyユーティリティを使用したIDキーストアの作成」のようにこの証明書をappIdentityKeyStore.jksにインポートします。証明書がこのストアで使用可能になった時点で、各ノード・マネージャはそれぞれのアイデンティティ別名を指定して、正しい証明書を管理サーバーに送信する必要があります。これを行うには、次のように該当の環境変数を設定して各ノードでノード・マネージャを起動します。

HOST> cd WL_HOME/server/bin
HOST> export JAVA_OPTIONS=-DCustomIdentityAlias=appIdentityX

注意: 各ホストに明確に割り当てられているカスタムのアイデンティティ別名を指定してください。したがって、...HOST1にはappIdentity1、...HOST2にはappIdentity2を指定します。

16.3.5 カスタム・キーストアを使用するための管理対象WLSサーバーの構成

次の手順に従って、WLS_SERVERのIDキーストアとトラスト・キーストアを構成します。

1. Oracle WebLogic Server管理コンソールにログインします。

2. 「ロックして編集」をクリックします。

3. 「ドメイン構造」ウィンドウで「環境」ノードを開きます。

4. 「サーバー」をクリックします。「サーバーのサマリー」ページが表示されます。

5. IDキーストアとトラスト・キーストアを構成するサーバー名（WLS_SERVER）をクリックします。選択したサーバーの設定ページが表示されます。

6. 「構成」をクリックし、「キーストア」をクリックします。

7. 「キーストア」フィールドで、秘密鍵とデジタル証明書のペアおよび信頼性のあるCA証明書の格納と管理のために「カスタムIDとカスタム信頼」メソッドを選択します。

8. 「ID」セクションで、IDキーストアの次の属性を定義します。

   • カスタムIDキーストア: IDキーストアへの完全修飾パス。

     ORACLE_BASE/admin/domain_name/aserver/domain_name/certs/appIdentityKeyStore.jks
     

   • カスタムIDキーストアのタイプ: 空白のままにしてください。デフォルトでJKSに設定されます。

   • カスタムIDキーストアのパスフレーズ: 第16.3.3項「keytoolユーティリティを使用したトラスト・キーストアの作成」で指定したパスワード（Keystore_Password）。この属性は、キーストアのタイプに応じてオプションまたは必須になります。キーストアに書き込むには、すべてのキーストアにパスフレーズが必要です。ただし、キーストアからの読込みではパスフレーズが不要なキーストアもあります。WebLogic Serverはキーストアからの読込みのみを行います。したがって、このプロパティを定義するかどうかは、キーストアの要件に応じて異なります。

9. 「信頼」セクションで、トラスト・キーストアの次のプロパティを定義します。

   • カスタム信頼キーストア: トラスト・キーストアへの完全修飾パス。

     ORACLE_BASE/admin/domain_name/aserver/domain_name/certs/appTrustKeyStore.jks
     

   • カスタム信頼キーストアのタイプ: 空白のままにしてください。デフォルトでJKSに設定されます。

   • カスタム信頼キーストアのパスフレーズ: 第16.3.3項「keytoolユーティリティを使用したトラスト・キーストアの作成」でNew_Passwordとして指定したパスワード。この属性は、キーストアのタイプに応じてオプションまたは必須になります。キーストアに書き込むには、すべてのキーストアにパスフレーズが必要です。ただし、キーストアからの読込みではパスフレーズが不要なキーストアもあります。WebLogic Serverはキーストアからの読込みのみを行います。したがって、このプロパティを定義するかどうかは、キーストアの要件に応じて異なります。

10. 「保存」をクリックします。

11. 「管理コンソール」の「チェンジ・センター」で、「変更のアクティブ化」をクリックして、これらの変更を有効にします。

12. 「構成」をクリックし、「SSL」をクリックします。

13. 「ロックして編集」をクリックします。

14. 「秘密鍵の別名」フィールドで、管理対象サーバーがリスニングを実行するホスト名に使用した別名を入力します。

    「秘密鍵のパスフレーズ」フィールドと「秘密鍵のパスフレーズを確認」フィールドで、第16.3.2項「utils.ImportPrivateKeyユーティリティを使用したIDキーストアの作成」で作成したキーストアのパスワードを入力します。

15. 「保存」をクリックします。

16. 「管理コンソール」の「チェンジ・センター」で、「変更のアクティブ化」をクリックして、これらの変更を有効にします。

17. 第19.1項「Oracle Identity Managementコンポーネントの起動と停止」の説明に従って、変更を適用したサーバーを再起動します。

16.3.6 管理対象サーバーのホスト名検証設定の変更

前述の手順を実行したら、影響を受けた管理対象サーバーのホスト名検証をBea Hostname Verifierに設定する必要があります。このためには、次の手順を実行します。

1. Oracle WebLogic Server管理コンソールにログインします。

2. 「チェンジ・センター」で「ロックして編集」を選択します。

3. 「ドメイン構造」ウィンドウで「環境」ノードを開きます。

4. 「サーバー」をクリックします。「サーバーのサマリー」ページが表示されます。

5. 表の「名前」列で管理対象サーバーを選択します。選択したサーバーの設定ページが表示されます。

6. 「SSL」タブを開きます。

7. このページの「詳細」セクションを展開します。

8. ホスト名検証をBea Host Name Verifierに設定します。

9. 「保存」をクリックします。

10. 「変更のアクティブ化」をクリックします。

16.4 ノード・マネージャの起動

次のコマンドを実行して、HOSTでノード・マネージャを起動します。

注意: ノード・マネージャが未構成で、まだ起動もしていない場合は、第19.14項の説明に従ってsetNMProps.shスクリプトを実行してください。これにより、管理対象サーバーの起動スクリプトを使用できるようになります。

cd MW_HOME/oracle_common/common/bin
./setNMProps.sh