| Oracle® Exalogic Elastic Cloud Oracle Identity and Access Managementエンタープライズ・デプロイメント・ガイド リリースEL X2-2、X3-2、X4-2およびX5-2 E51446-03 |
|
 前 |
 次 |
| Oracle® Exalogic Elastic Cloud Oracle Identity and Access Managementエンタープライズ・デプロイメント・ガイド リリースEL X2-2、X3-2、X4-2およびX5-2 E51446-03 |
|
前 |
次 |
この章では、Oracleベスト・プラクティスによる推奨事項に従って、ノード・マネージャを構成する方法について説明します。
この章は次の項で構成されています:
ノード・マネージャを使用すると、管理サーバーおよび管理対象サーバーを起動および停止できます。
プロセス
この章で説明する手順は、第2章で概説されているエンタープライズ・デプロイメント・トポロジの様々なコンポーネントに対してIDMHOST1およびIDMHOST2で実行する必要があります。
この章の手順は、コンポーネント固有の章の情報を使用して、それぞれのVIPとIPのペアに対して複数回実行する必要があります。
推奨事項
Oracleは、エンタープライズ・デプロイメント・トポロジにおけるノード・マネージャ構成について次の2点をお薦めしています。
ノード・マネージャのログ・ファイルは、デフォルト(ノード・マネージャが常駐するミドルウェア・ホーム内)以外の場所に保管することをお薦めします。詳細は、第13.2項「ノード・マネージャの設定」を参照してください。
また、ドメイン内のノード・マネージャとサーバー間の通信に対してホスト名検証を使用することもお薦めします。これには、ドメイン内で使用される異なるアドレスに対し、証明書を使用する必要があります。この章では、ホスト名検証のためにホストに証明書を構成する手順を説明します。詳細は、第13.3項「ノード・マネージャのホスト名検証証明書の有効化」を参照してください。
|
注意: このガイドに記載されているパスワードは、例として使用しているだけです。本番環境では、セキュア・パスワードを使用してください。たとえば、大文字と小文字の両方および数字をランダムに並べたパスワードを使用してください。 |
この項では、エンタープライズ・デプロイメントのノード・マネージャを設定する方法について説明します。
この項の内容は次のとおりです。
ノード・マネージャの構成ファイルとログ・ファイルの新しいディレクトリをMW_HOMEディレクトリ以外に作成し、ノード・マネージャのすべての構成タスクをこのディレクトリから実行してください。
新しいディレクトリを作成する手順は次のとおりです。
次のコマンドを実行して、IDMHOST1およびIDMHOST2上で実行中のノード・マネージャを停止します。
ps -ef | grep NodeManager
IDMHOST1とIDMHOST2で次のコマンドを実行します。
mkdir -p /u02/private/oracle/config/nodemanager
次のディレクトリにあるnodemanager.propertiesファイルをコピーします。
/u01/oracle/products/access/wlserver_10.3/common/nodemanager
コピー先はIDMHOST1とIDMHOST2に作成した新しいnodemanagerフォルダです。
次のディレクトリにあるstartNodeManager.shファイルをコピーします。
/u01/oracle/products/access/wlserver_10.3/server/bin
また、次のフォルダにあるnodemanager.domainsファイルもコピーします。
/u01/oracle/products/access/wlserver_10.3/common/nodemanager
コピー先はIDMHOST1とIDMHOST2に作成した新しいnodemanagerフォルダです。
IDMHOST1とIDMHOST2の新しいnodemanagerフォルダにあるIDMHOST1とIDMHOST2のstartNodeManager.shをテキスト・エディタで開いて、次のように変更します。
IDMHOST1とIDMHOST2で、次のように変更します。
NODEMGR_HOME="/u02/private/oracle/config/nodemanager"
IDMHOST1のIDMHOST2の次のディレクトリにあるnodemanager.propertiesファイルを更新します。
/u02/private/oracle/config/nodemanager
IDMHOST1で、ファイルを次のように編集します。
NodeManagerHome=/u02/private/oracle/config/nodemanager ListenAddress=192.168.10.200 LogFile= /u02/private/oracle/config/nodemanager/nodemanager.log Properties Value SecureListener=false StartScriptEnabled=true StopScriptEnabled=true StopScriptName=stopWebLogic.sh Specify a name for the stop script, for example stopWebLogic.sh. DomainsFile=/u02/private/oracle/config/nodemanager/nodemanager.domains
IDMHOST2:
NodeManagerHome=/u02/private/oracle/config/nodemanager ListenAddress= 192.168.10.101 LogFile= /u02/private/oracle/config/nodemanager/nodemanager.log Properties Value SecureListener=false StartScriptEnabled=true StopScriptEnabled=true StopScriptName=stopWebLogic.sh Specify a name for the stop script, for example stopWebLogic.sh. DomainsFile=/u02/private/oracle/config/nodemanager/nodemanager.domains
次のディレクトリにあるstartNodeManager.shを使用して、IDMHOST1とIDMHOST2でノード・マネージャを起動します。
/u02/private/oracle/config/nodemanager
たとえば、IDMHOST1とIDMHOST2で次のコマンドを実行します。
./startNodeManager.sh
この項では、ノード・マネージャと管理サーバー間の通信のホスト名検証証明書を設定する方法について説明します。これは、次の手順で構成されています。
この章で追加された証明書は、(例として)物理ホスト名(HOST.mycompany.com)でリスニングするノード・マネージャと仮想ホスト名(VIP.mycompany.com)でリスニングするWebLogic管理対象サーバーの構成に対応しています。サーバーが仮想ホスト名を使用している場合、そのサーバーはノード間の移行が可能であることを意味します。その結果として、キーストアおよび信頼キーストアが適切に保持されているデイレクトリは、フェイルオーバーからアクセス可能な共有記憶域に存在する必要があります。追加のホスト名が同一ノードまたは異なるノードで使用されている場合は、この例の手順を次のように拡張する必要があります。
必要なホスト名を証明書ストアに追加します(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つの管理対象サーバーが物理ホスト名をリスニングしている1つのサーバーおよび仮想ホスト名を使用している1つのサーバー(移行サーバーを使用しているサーバーの場合)と共存しているノードでは、一般的な状況です。
WL_HOME/server/bin/setWLSEnv.shスクリプトを実行して環境を設定します。Bourneシェルで、次のコマンドを実行します。
cd WL_HOME/server/bin
. ./setWLSEnv.sh
CLASSPATH環境変数が設定されていることを確認します。
echo $CLASSPATH
証明書のためのユーザー定義ディレクトリを作成します。たとえば、ASERVER_HOME/domain_nameディレクトリの下にcertsというディレクトリを作成します。証明書はWebLogicドメイン間で共有できます。
cd ASERVER_HOME/domain_name mkdir certs
|
注意: キーストアおよび信頼キーストアが保持されているデイレクトリは、サーバーの(手動またはサーバー移行による)フェイルオーバー時にフェイルオーバー・ノードから適切な証明書にアクセスできるよう、すべてのノードからアクセス可能な共有記憶域に存在する必要があります。様々な目的(HTTP呼出しのためのSSL設定など)で使用される証明書には、中央ストアまたは共有ストアを使用することをお薦めします。 |
ディレクトリを作成したばかりのディレクトリに変更します。
cd certs
ユーザー定義ディレクトリからutils.CertGenツールを実行して、HOST.mycompany.comとVIP.mycompany.comの両方の証明書を作成します。
構文(すべてを1行で記述する):
java utils.CertGen Key_Passphrase Cert_File_Name Key_File_Name
[export | domestic] [Host_Name]
例:
java utils.CertGen Key_Passphrase IDMHOST1.mycompany.com_cert IDMHOST1.mycompany.com_key domestic IDMHOST1.mycompany.com java utils.CertGen Key_Passphrase IDMHOST2.mycompany.com_cert IDMHOST2.mycompany.com_key domestic IDMHOST2.mycompany.com java utils.CertGen Key_Passphrase ADMINVHN.mycompany.com_cert ADMINVHN.mycompany.com_key domestic ADMINVHN.mycompany.com java utils.CertGen Key_Passphrase OUDADMINVHN.mycompany.com_cert OUDADMINVHN.mycompany.com_key domestic OUDADMINVHN.mycompany.com
次の手順に従って、IDMHOST1にアイデンティティ・キーストアを作成します。
utils.ImportPrivateKeyユーティリティを使用して、appIdentityKeyStoreという新しいアイデンティティ・キーストアを作成します。このキーストアを、証明書と同じディレクトリ(つまりASERVER_HOME/certs)の下に作成します。
|
注意:
|
IDMHOST1.mycompany.com、IDMHOST2.mycompany.comおよびADMINVHN.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 Key_Passphrase appIdentityIDMHOST1 Key_Passphrase ASERVER_HOME/certs/IDMHOST1.mycompany.com_cert.pem ASERVER_HOME/certs/IDMHOST1.mycompany.com_key.pem java utils.ImportPrivateKey appIdentityKeyStore.jks Key_Passphrase appIdentityIDMHOST2 Key_Passphrase ASERVER_HOME/certs/IDMHOST2.mycompany.com_cert.pem ASERVER_HOME/certs/IDMHOST2.mycompany.com_key.pem java utils.ImportPrivateKey appIdentityKeyStore.jks Key_Passphrase appIdentityADMVHN Key_Passphrase ASERVER_HOME/certs/ADMINVHN.mycompany.com_cert.pem ASERVER_HOME/certs/ADMINVHN.mycompany.com_key.pem
次の手順に従って、IDMHOST1とIDMHOST2の各ホストに信頼キーストアを作成します。
標準Javaキーストアには必要なルートCA証明書のほとんどが含まれているため、新しい信頼キーストアを作成するためにはこのキーストアをコピーします。標準Java信頼キーストアを直接修正することはお薦めしません。WL_HOME/server/libデイレクトリの下にある標準JavaキーストアのCA証明書を、証明書と同じディレクトリにコピーします。次に例を示します。
cp WL_HOME/server/lib/cacerts ASERVER_HOME/certs/appTrustKeyStoreIDMHOST1.jks
標準Javaキーストアのデフォルト・パスワードはchangeitです。デフォルト・パスワードは変更することをお薦めします。これを行うには、keytoolユーティリティを使用します。構文は次のとおりです。
keytool -storepasswd -new New_Password -keystore Trust_Keystore -storepass Original_Password
次に例を示します。
keytool -storepasswd -new Key_Passphrase -keystore appTrustKeyStoreIDMHOST1.jks -storepass changeit
CA証明書CertGenCA.derは、utils.CertGenツールで生成されるすべての証明書の署名に使用されます。これは、WL_HOME/server/libディレクトリにあります。CA証明書は、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 appTrustKeyStoreIDMHOST1.jks -storepass Key_Passphrase
カスタム・キーストアを使用するためには、IDMHOST1およびIDMHOST2の次のディレクトリにあるnodemanager.propertiesファイルを編集して、ノード・マネージャを構成します。
/u02/private/oracle/config/nodemanager_directory
次の行を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=ASERVER_HOME/certs/appIdentityKeyStore.jks CustomIdentityKeyStorePassPhrase=Key_Passphrase CustomIdentityAlias=appIdentityIDMHOST1 CustomIdentityPrivateKeyPassPhrase=Key_Passphrase
第16.1項「Oracle Identity Managementコンポーネントの起動と停止」で説明しているように、nodemanager.propertiesファイルのパスフレーズ・エントリはノード・マネージャの起動時に暗号化されます。セキュリティ上の理由から、nodemanager.propertiesファイル内のエントリが暗号化されていない時間を最小限にしてください。ファイルの編集が終了したら、エントリを暗号化させるために即座にノード・マネージャを起動してください。
MW_HOMEに共通または共有記憶域のインストールを使用する場合、ノード・マネージャは同じ基本構成(nodemanager.properties)を使用する異なるノードから起動されます。第13.3.1項「utils.CertGenユーティリティを使用した自己署名証明書の生成」の説明に従って、新しいノードに証明書を作成してappIdentityKeyStore.jksにインポートすることで、バイナリを共有するすべてのノードの証明書をappIdentityKeyStore.jksアイデンティティ・ストアに追加します。ストア内で証明書を使用できるようになると、管理サーバーに正しい証明書を送信するため、各ノード・マネージャが異なるアイデンティティの別名を指すようにする必要があります。
異なるノードでノード・マネージャを起動する前に異なる環境編集を設定する手順は、次のとおりです。
cd WL_HOME/server/bin export JAVA_OPTIONS=-DCustomIdentityAlias=appIdentityIDMHOST1 cd WL_HOME/server/bin export JAVA_OPTIONS=-DCustomIdentityAlias=appIdentityIDMHOST2
|
注意: 各ホストに割り当てられたカスタム・アイデンティティの別名を指定します。たとえば...HOST1には |
次の手順に従って、WLS_SERVERのアイデンティティ・キーストアおよび信頼キーストアを構成します。
第16.2項「アイデンティティ管理コンソールのURLについて」にリストされているURLから、Oracle WebLogic Server管理コンソールにログインします。
「ロックして編集」をクリックします。
「ドメイン構造」ウィンドウの「環境」ノードを開きます。
「サーバー」をクリックします。「サーバーのサマリー」ページが表示されます。
アイデンティティ・キーストアおよび信頼キーストアを構成するサーバーの名前(WLS_SERVER)をクリックします。選択したサーバーの設定ページが表示されます。
「構成」→「キーストア」の順に選択します。
「キーストア」フィールドで、秘密鍵/デジタル証明のペアと信頼できるCA証明書を格納および管理する「カスタムIDとカスタム信頼」メソッドを選択します。
「ID」セクションで、アイデンティティ・キーストアの属性を定義します。
カスタムIDキーストア: アイデンティティ・キーストアへの完全修飾パスです。
ASERVER_HOME/certs/appIdentityKeyStore.jks
カスタムIDキーストアのタイプ: 空白のままにします。デフォルトはJKSです。
カスタムIDキーストアのパスフレーズ: 第13.3.3項「Keytoolユーティリティを使用した信頼キーストアの作成」で指定したパスワード(Keystore_Password)です。この属性はキーストアのタイプに応じてオプションまたは必須になります。すべてのキーストアは、そのキーストアに書き込むためのパスフレーズが必要です。ただし、一部のキーストアは、そのキーストアから読み取るためのパスフレーズが不要です。WebLogic Serverはキーストアから読み取るだけなので、このプロパティを定義するかどうかはそのキーストアの要件によって異なります。
「信頼」セクションで、信頼キーストアのプロパティを定義します。
カスタム信頼キーストア: 信頼キーストアへの完全修飾パスです。
ASERVER_HOME/certs/appTrustKeyStoreIDMHOST1.jks
カスタム信頼キーストアのタイプ: 空白のままにします。デフォルトはJKSです。
カスタム信頼キーストアのパスフレーズ: 第13.3.3項「Keytoolユーティリティを使用した信頼キーストアの作成」で指定したパスワード(New_Password)です。この属性はキーストアのタイプに応じてオプションまたは必須になります。すべてのキーストアは、そのキーストアに書き込むためのパスフレーズが必要です。ただし、一部のキーストアは、そのキーストアから読み取るためのパスフレーズが不要です。WebLogic Serverはキーストアから読み取るだけなので、このプロパティを定義するかどうかはそのキーストアの要件によって異なります。
「保存」をクリックします。
管理コンソールのチェンジ・センターで「変更のアクティブ化」をクリックして、変更をアクティブ化します。
「構成」→「SSL」の順に選択します。
「ロックして編集」をクリックします。
「秘密鍵の別名」フィールドで、管理対象サーバーがリスニングするホスト名の別名を入力します。次に例を示します。
WLS_OAM1の場合は、appIdentityIDMHOST1を使用します。
WLS_OAM2の場合は、appIdentityIDMHOST2を使用します。
ADMINSERVERの場合は、appIdentityADMINVHNを使用します。
「秘密鍵のパスフレーズ」フィールドおよび「秘密鍵のパスフレーズを確認」フィールドに、第13.3.2項「utils.ImportPrivateKeyユーティリティを使用したアイデンティティ・キーストアの作成」で作成したキーストアのパスワードを入力します。
「保存」をクリックします。
管理コンソールのチェンジ・センターで「変更のアクティブ化」をクリックして、変更をアクティブ化します。
第16.1項「Oracle Identity Managementコンポーネントの起動と停止」の説明に従って、変更を適用したサーバーを再起動します。
前述の手順を実行した後、Bea Hostname Verifierに影響を受ける管理対象サーバーのホスト名検証を設定します。そのための手順は次のとおりです。
Oracle WebLogic Server管理コンソールにログインします。
チェンジ・センターで「ロックして編集」を選択します。
「ドメイン構造」ウィンドウの「環境」ノードを開きます。
「サーバー」をクリックします。「サーバーのサマリー」ページが表示されます。
表の「名前」列で、管理対象サーバーを選択します。サーバーの設定ページが表示されます。
「SSL」タブを開きます。
ページの「詳細」セクションを開きます。
ホスト名検証をBEA Hostname Verifierに設定します。
「保存」をクリックします。
「変更のアクティブ化」をクリックします。
次のディレクトリにあるstartNodeManager.shを実行して、IDMHOST1とIDMHOST2でノード・マネージャを起動します。
/u02/private/oracle/config/nodemanager
ノード・マネージャを起動するには、IDMHOST1とIDMHOST2で次のコマンドを実行します。
./startNodeManager.sh
|
注意: ノード・マネージャを構成しておらず、まだ一度も起動していない場合、第9.5.3項「IDMHOST1およびIDMHOST2でのノード・マネージャの起動」で指定した |
|
注意: ノード・マネージャの出力で、ノード・マネージャが適切なストアと別名を使用していることを確認してください。ノード・マネージャの起動時に、次を確認してください。 <Loading identity key store: FileName=ASERVER_HOME/certs/appIdentityKeyStore.jks, Type=jks, PassPhraseUsed=true> ホスト名検証は、テスト構成の変更をサーバーに適用し、ノード・マネージャからSSLエラーの報告がなく成功した場合に動作します。 |
