ヘッダーをスキップ
Oracle® Fusion Middleware Oracle WebCenter Portalエンタープライズ・デプロイメント・ガイド
11gリリース1 (11.1.1.9.0)
B55900-11
  ドキュメント・ライブラリへ移動
ライブラリ
製品リストへ移動
製品
目次へ移動
目次
索引へ移動
索引

前
 
次
 

11 エンタープライズ・デプロイメント用のノード・マネージャの設定

この章では、エンタープライズ・デプロイメントの推奨事項に従ってノード・マネージャを構成する方法を説明します。

この章には次のトピックが含まれます:

11.1 ノード・マネージャの概要

ノード・マネージャを使用すると、管理サーバーおよび各管理対象サーバーの起動と停止が可能です。

オラクル社では、ノード・マネージャと管理サーバー間の通信にホスト名を使用した検証を使用することを推奨しています。このホスト名検証には、管理サーバーと通信するそれぞれのアドレスに証明書を使用する必要があります。この章では、ホスト名検証に使用する証明書をSOAHOST1およびSOAHOST2に構成する手順を説明します。WCPHOST1とWCPHOST2についても同様の手順が必要です。その手順ではWCPHOST1とWCPHOST2に応じたホスト名の変更が必要ですが、一連の手順や構文はまったく同じです。

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

Oracle Fusion Middlewareデプロイメントのノード・マネージャのログ・ファイルは、デフォルト(ノード・マネージャが存在するMW_Home内)以外の場所に置くことをお薦めします。

ノード・マネージャのログの場所を変更するには、次のディレクトリにあるnodemanager.propertiesファイルを編集します。

MW_HOME/wlserver_10.3/common/nodemanager

このファイルは、MW_HOMEディレクトリでなく、デプロイメントのadminディレクトリ内に置くことをお薦めします。

nodemanager.propertiesに次の行を追加します。

LogFile=ORACLE_BASE/admin/nodemanager.log

ノード・マネージャを再起動して、変更を有効にします。

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

ホスト名検証はノード・マネージャと管理サーバー間の通信を可能にするものです。この検証では、管理サーバーと通信するそれぞれのアドレスに証明書を使用する必要があります。

この項には次のトピックが含まれます:

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

この項では、SOAHOST1.example.comの自己署名証明書を作成する手順を説明します。これらの証明書はネットワーク名/別名を使用して作成します。

キーストアおよびトラスト・キーストアを保持するディレクトリは、すべてのノードからアクセスできる共有記憶域に配置して、サーバーが(手動またはサーバー移行により)フェイルオーバーしたときにフェイルオーバー・ノードから適切な証明書にアクセスできるようにする必要があります。様々な目的に使用される証明書には、中央ストアまたは共有ストアを使用することをお薦めします(HTTP呼出しのSSL設定など)。この場合、SOAHOST2、WCPHOST1およびWCPHOST2では、SOAHOST1の証明書用に作成されたcertsディレクトリを使用します。

自己署名証明書のかわりに信頼できるCA証明書を使用するには、『Oracle Fusion Middleware Oracle WebLogic Serverの保護』でアイデンティティとトラストの構成に関する項を参照してください。

パスワードについて

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

自己署名証明書を作成する手順は次のとおりです。

  1. WL_HOME/server/bin/setWLSEnv.shスクリプトを実行して環境を設定します。

    Bourneシェルの場合、SOAHOST1上で次のコマンドを実行します。

    .WL_HOME/server/bin/setWLSEnv.sh
    

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

    echo $CLASSPATH
    
  2. 証明書用のユーザー定義ディレクトリを作成します。

    mkdir ORACLE_BASE/admin/domain-name/certs
    
  3. ディレクトリをユーザー定義ディレクトリに変更します。

    cd ORACLE_BASE/admin/domain-name/certs
    
  4. ユーザー定義ディレクトリからutils.CertGenツールを実行して、SOAHOST1、SOAHOST1VHN VIP、管理サーバーVIP、WCPHOST1および環境内のすべてのホストおよびVIPの証明書を作成します。

    構文:

    java utils.CertGen key_passphrase cert_file_name key_file_name [export | domestic] [host_name]

    コマンド例

    java utils.CertGen password SOAHOST1.example.com_cert SOAHOST1.example.com_key domestic SOAHOST1.example.com
    
    java utils.CertGen password SOAHOST1VHN1.example.com_cert SOAHOST1VHN1.example.com_key domestic SOAHOST1VHN1.example.com
    
    java utils.CertGen password SOAHOST2.example.com_cert SOAHOST2.example.com_key domestic SOAHOST2.example.com
    
    java utils.CertGen password SOAHOST2VHN1.example.com_cert SOAHOST1VHN2.example.com_key domestic SOAHOST1VHN2.example.com
    
    java utils.CertGen password ADMINVHN.example.com_cert ADMINVHN.example.com_key domestic ADMINVHN.example.com
    
    java utils.CertGen password WCPHOST1.example.com_cert WCPHOST1.example.com_key domestic WCPHOST1.example.com
    
    java utils.CertGen password WCPHOST2.example.com_cert WCPHOST2.example.com_key domestic WCPHOST2.example.com
    

11.3.2 utils.ImportPrivateKeyユーティリティを使用したアイデンティティ・キーストアの作成

前の項に示された手順で、アイデンティティ・キーストアが作成されました。SOAHOST1、SOAHOST1VHN1、ADMINVHNおよびWCPHOST1の証明書と秘密鍵をアイデンティティ・ストアにインポートします。インポートする証明書とキーの各組合せに対して異なる別名を使用してください。

次の手順に従って、SOAHOST1にアイデンティティ・キーストアを作成します。

  1. utils.ImportPrivateKeyユーティリティを使用して、appIdentityKeyStoreという名前の新しいアイデンティティ・キーストアを作成します。このキーストアは、証明書と同じディレクトリに作成します( ORACLE_BASE/admin/domain_name/certs)。


    注意:

    utils.ImportPrivateKeyユーティリティを使用して証明書および対応する鍵をアイデンティティ・ストアにインポートする際、アイデンティティ・ストアが1つも存在しない場合は、新しく作成されます。

  2. アイデンティティ・ストアに、SOAHOST1、SOAHOST1VHN1、SOAHOST2、SOAHOST2VHN1、ADMINVHN、WCPHOST1およびWCPHOST2の証明書と秘密鍵をインポートします。必ず、インポートする証明書と鍵のペアごとに異なる別名を使用してください。

    構文(すべてを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 password
    appidentitySOAHOST1 password
    ORACLE_BASE/admin/domain_name/certs/SOAHOST1.example.com_cert.pem
    ORACLE_BASE/admin/domain_name/certs/SOAHOST1.example.com_key.pem
    
    java utils.ImportPrivateKey appIdentityKeyStore.jks password
    appidentitySOAHOST1VHN1 password
    ORACLE_BASE/admin/domain_name/certs/SOAHOST1VHN1.example.com_cert.pem
    ORACLE_BASE/admin/domain_name/certs/SOAHOST1VHN1.example.com_key.pem
    
    java utils.ImportPrivateKey appIdentityKeyStore.jks password
    appidentitySOAHOST2 password
    ORACLE_BASE/admin/domain_name/certs/SOAHOST2.example.com_cert.pem
    ORACLE_BASE/admin/domain_name/certs/SOAHOST2.example.com_key.pem
    
    java utils.ImportPrivateKey appIdentityKeyStore.jks password
    appidentitySOAHOST2VHN1 password
    ORACLE_BASE/admin/domain_name/certs/SOAHOST2VHN1.example.com_cert.pem
    ORACLE_BASE/admin/domain_name/certs/SOAHOST2VHN1.example.com_key.pem
    
    java utils.ImportPrivateKey appIdentityKeyStore.jks password
    appidentityADMINVHN password
    ORACLE_BASE/admin/domain_name/certs/ADMINVHN.example.com_cert.pem 
    ORACLE_BASE/admin/domain_name/certs/ADMINVHN.example.com_key.pem
    
    java utils.ImportPrivateKey appIdentityKeyStore.jks password
    appidentityWCPHOST1 password
    ORACLE_BASE/admin/domain_name/certs/WCPHOST1.example.com_cert.pem
    ORACLE_BASE/admin/domain_name/certs/WCPHOST1.example.com_key.pem
    
    java utils.ImportPrivateKey appIdentityKeyStore.jks password
    appidentityWCPHOST1 password
    ORACLE_BASE/admin/domain_name/certs/WCPHOST1.example.com_cert.pem
    ORACLE_BASE/admin/domain_name/certs/WCPHOST1.example.com_key.pem
    
  3. keytoolを使用してキーストア内の新しい別名の一覧を表示します。次に例を示します。

    keytool -list -keystore ORACLE_BASE/admin/domain_name/certs/appIdentityKeyStore.jks -storepass password
    

11.3.3 Keytoolユーティリティを使用した信頼キーストアの作成

SOAHOST1.example.comに信頼キーストアを作成するには:

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

    cp WL_HOME/server/lib/cacerts
    ORACLE_BASE/admin/domain_name/certs/appTrustKeyStore.jks
    
  2. 標準のJavaキーストアのデフォルトのパスワードはchangeitです。デフォルトのパスワードは常に変更することをお薦めします。これを実行するにはHOST上でkeytoolユーティリティを使用します。構文は次のとおりです。

    keytool -storepass -new NewPassword -keystore TrustKeyStore -storepass Original_Password
    

    例:

    keytool -storepass -new password -keystore appTrustKeyStore.jks -storepass changeit
    
  3. CA証明書CertGenCA.derは、utils.CertGenツールによって生成されるすべての証明書の署名に使用され、WL_HOME/server/libディレクトリに置かれています。このCA証明書は、HOST上でkeytoolユーティリティを使用して、appTrustKeyStoreにインポートする必要があります。構文は次のとおりです。

    keytool -import -v -noprompt -trustcacerts -alias AliasName
     -file CAFileLocation -keystore KeyStoreLocation -storepass KeyStore_Password
    

    例:

    keytool -import -v -noprompt -trustcacerts -alias clientCACert -file
    WL_HOME/server/lib/CertGenCA.der -keystore appTrustKeyStore.jks -storepass password
    
  4. SOAHOST2、WCPHOST1およびWCPHOST2の各サーバーに、キーストアをレプリケートします。

    1. SOAHOST2に、証明書のためのユーザー定義ディレクトリを作成します。

      mkdir ORACLE_BASE/admin/domain_name/certs
      
    2. キーストアをSOAHOST1からSOAHOST2にコピーします。

      scp SOAHOST1:/ORACLE_BASE/admin/domain_name/certs/appTrustKeyStore.jks \
             /ORACLE_BASE/admin/domain_name/certs/appTrustKeyStore.jks
      scp SOAHOST1:/ORACLE_BASE/admin/domain_name/certs/appIdentityKeyStore.jks \
             /ORACLE_BASE/admin/domain_name/certs/appIdentityKeyStore.jks
      
    3. WCPHOST1およびWCPHOST2に手順1と2を繰り返します。

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

カスタム・キーストアを使用するようにノード・マネージャを構成するには、WL_HOME/common/nodemanagerディレクトリにあるnodemanager.propertiesファイルの最後に次の行を追加します。

KeyStores=CustomIdentityAndCustomTrust
CustomIdentityKeyStoreFileName=Identity KeyStore
CustomIdentityKeyStorePassPhrase=Identity KeyStore Passwd
CustomIdentityAlias=Identity Key Store Alias
CustomIdentityPrivateKeyPassPhrase=Private Key used when creating Certificate

各ノードに個々に割り当てられたカスタム・アイデンティティの別名が、各ノードのCustomIdentityAlias値に正しく使用されていることを確認します。たとえば、SOAHOST1では、第11.3.3項「keytoolユーティリティを使用した信頼キーストアの作成」の手順に従ってappIdentitySOAHOST1を使用します。

KeyStores=CustomIdentityAndCustomTrust
CustomIdentityKeyStoreFileName=ORACLE_BASE/admin/domain_name/certs/appIdentityKeyStore.jks
CustomIdentityKeyStorePassPhrase=password
CustomIdentityAlias=appIdentitySOAHOST1
CustomIdentityPrivateKeyPassPhrase=password

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

11.3.5 共通または共有記憶域インストールの使用

MW_HOMEの共通または共有記憶域のインストールを使用する場合、ノード・マネージャは、同じ基本構成(nodemanager.properties)を使用して、異なるノードから起動されます。第11.3.1項「utils.CertGenユーティリティを使用した自己署名証明書の生成」に記載されているように、新しいノードの証明書を作成し、appIdentityKeyStore.jksにそれをインポートすることで、バイナリを共有するすべてのノードの証明書をappIdentityKeyStore.jksアイデンティティ・ストアに追加します。ストアに証明書が用意されたら、各ノード・マネージャ・インスタンスは、管理サーバーに正しい証明書を送信するために、異なるアイデンティティ別名を指す必要があります。

次の例は、異なるノードでノード・マネージャを起動する前に異なる環境変数を設定する方法を示しています。

SOAHOST1> cd WL_HOME/server/bin
SOAHOST1> export JAVA_OPTIONS=-DCustomIdentityAlias=appIdentitySOAHOST1

SOAHOST2> cd WL_HOME/server/bin
SOAHOST2> export JAVA_OPTIONS=-DCustomIdentityAlias=appIdentitySOAHOST2

WCPHOST1> cd WL_HOME/server/bin
WCPHOST1> export JAVA_OPTIONS=-DCustomIdentityAlias=appIdentityWCPHOST1

WCPHOST2> cd WL_HOME/server/bin
WCPHOST2> export JAVA_OPTIONS=-DCustomIdentityAlias=appIdentityWCPHOST2

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

startNodeManager.shスクリプトを使用して、SOAHOST1、SOAHOST2、WCPHOST1およびWCPHOST2のノード・マネージャを起動します。


注意:

ノード・マネージャが未構成で、まだ起動もしていない場合は、第8.4.2項「SOAHOST1でのノード・マネージャの起動」の説明に従ってsetNMProps.shスクリプトを実行してください。これにより、SOAに必要な起動スクリプトを使用できるようになります。

  1. SOAHOST1でノード・マネージャを起動する手順は次のとおりです。

    cd WL_HOME/server/bin
    export JAVA_OPTIONS=-DCustomIdentityAlias=appIdentitySOAHOST1
    ./startNodeManager.sh
    

    注意:

    各ホストに専用に割り当てられたカスタム・アイデンティティ・別名を指定します(SOAHOST1はappIdentitySOAHOST11、SOAHOST2はappIdentitySOAHOST2など)。

  2. 同じ手順に従って、SOAHOST2、WCPHOST1およびWCPHOST2のノード・マネージャを起動します。

11.5 カスタム・キーストアを使用するためのWebLogic Serverの構成

Oracle WebLogic Server管理コンソールを使用して、カスタム・キーストアを使用するためにWebLogic Serverを構成します。この手順を、管理サーバーおよびすべての管理対象サーバーで完了します(WLS_WSMn、WLS_SOAn、WC_Spacesn、WC_Collaborationn、WC_UtilitiesnおよびWC_Portletn)。

この例は、第11.3項「ノード・マネージャに対するホスト名検証証明書の有効化」に記載された推奨のディレクトリ構造およびキーストアの場所に従っています。

アイデンティティ・キーストアおよび信頼キーストアを構成する手順は次のとおりです。

  1. 管理コンソールにログインして「ロックして編集」をクリックします。

  2. 左ペインで「環境」を開き、「サーバー」を選択します。

  3. アイデンティティ・キーストアおよび信頼キーストアを構成するサーバーの名前をクリックします。

  4. 「構成」を選択して、「キーストア」を選択します。

  5. 「キーストア」フィールドの横にある「変更」をクリックして、秘密鍵/デジタル証明書のペアおよび信頼できるCA証明書を格納し管理するための「カスタムIDとカスタム信頼」方法を選択します。

  6. 「ID」セクションで、アイデンティティ・キーストアの属性を定義します。

    1. カスタムIDキーストア: アイデンティティ・キーストアの完全修飾パスを入力します。

      ORACLE_BASE/admin/domain_name/certs/appIdentityKeyStore.jks
      
    2. カスタムIDキーストアのタイプ: このフィールドは空白のままにします(デフォルトのJKSになります)。

    3. カスタムIDキーストアのパスフレーズ: 第11.3.2項「utils.ImportPrivateKeyユーティリティを使用したアイデンティティ・キーストアの作成」で指定したパスワードKeystore_Passwordを入力します。

      この属性はオプションの場合も必須の場合もあります。どちらになるかはキーストアのタイプによって決まります。すべてのキーストアでは、キーストアへの書込みにパスフレーズが必要です。ただし、一部のキーストアでは、キーストアからの読取りにパスフレーズは不要です。WebLogic Serverはキーストアからの読取りのみを行うため、このプロパティを定義するかどうかは、キーストアの要件によって決まります。

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

    1. カスタム信頼キーストア: 信頼キーストアの完全修飾パスを入力します。

      ORACLE_BASE/admin/domain_name/certs/appTrustKeyStore.jks
      
    2. カスタム信頼キーストアのタイプ: このフィールドは空白のままにします(デフォルトのJKSになります)。

    3. カスタム信頼キーストアのパスフレーズ: 第11.3.3項「keytoolユーティリティを使用した信頼キーストアの作成」New_Passwordとして指定したパスワード

      前の手順で説明したとおり、この属性はオプションの場合も必須の場合もあり、どちらになるかはキーストアのタイプによって決まります。

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

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

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

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

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

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

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

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

  15. 変更を適用したサーバーを再起動します。

  16. これらの手順を、管理サーバーおよびすべての管理対象サーバー(WLS_WSMn、WLS_SOAn、WC_Spacesn、WC_Collaborationn、WC_UtilitiesnおよびWC_Portletn)に対して繰り返します。

  17. ホスト名検証を有効化して、ノード・マネージャ、管理サーバーおよび管理対象サーバー間の通信が正しいことを検証します。

    1. 各サーバーの管理コンソールで、「構成」「SSL」「詳細」「ホスト名の検証」「BEAホスト名の検証」を選択します。

    2. 管理コンソールを使用してサーバーを再起動します。