10 エンタープライズ・デプロイメント用の初期インフラストラクチャ・ドメインの作成

次の各項では、エンタープライズ・デプロイメントの開始点として使用できる初期ドメインのインストールおよび構成方法について説明します。このガイドの後の章では、デプロイしようとしているエンタープライズ・トポロジを構成する各種製品およびコンポーネントを含めることで、この初期ドメインを拡張する方法について説明します。

インフラストラクチャ・ドメインの作成時に使用する変数

この章のタスクを実行する際には、この項にリストされているディレクトリ変数を参照します。

これらのディレクトリ変数については、「このガイドで使用するファイル・システムとディレクトリ変数」に定義されています。

  • ORACLE_HOME

  • ASERVER_HOME

  • MSERVER_HOME

  • APPLICATION_HOME

  • JAVA_HOME

  • NM_HOME

  • KEYSTORE_HOME

さらに、「エンタープライズ・トポロジで必要とされる物理IPアドレスと仮想IPアドレス」で定義されている次の仮想IP (VIP)アドレスとホスト名も参照します。

  • ADMINVHN

  • WCCHOST1

  • WCCHOST2

  • WCPHOST1

  • WCPHOST2

  • DBHOST1

  • DBHOST2

  • Oracle RACデータベースのSCANアドレス(DB-SCAN.example.com)

初期インフラストラクチャ・ドメインについて

初期インフラストラクチャ・ドメインの作成を開始する前に、次の重要な概念を確認してください。

インフラストラクチャ・ディストリビューションについて

エンタープライズ・デプロイメントの初期インフラストラクチャ・ドメインの作成には、Oracle Fusion Middleware Infrastructureディストリビューションを使用します。このディストリビューションには、Oracle WebLogic ServerソフトウェアとOracle JRFソフトウェアの両方が含まれています。

Oracle JRFソフトウェアは、Oracle Web Services Manager、Oracle Application Development Framework (Oracle ADF)、Oracle Enterprise Manager Fusion Middleware Control、リポジトリ作成ユーティリティ(RCU)およびOracle Fusion Middleware製品のサポートに必要なその他のライブラリおよびテクノロジで構成されています。

このガイドの後のほうでは、エンタープライズ・デプロイメントに必要なOracle Fusion Middleware製品をサポートするために、このドメインを拡張できます。

『Oracle Fusion Middlewareの理解』のOracle Fusion Middlewareの理解に関する項を参照してください。

ドメインの特徴

次の表に、作成するドメインの主な特徴を示します。これらの特徴を確認することで、ドメインの構成手順の目的やコンテキストに対する理解が深まります。

これらの特徴の多くについては、「標準的なエンタープライズ・デプロイメントの理解」で詳しく説明しています。

ドメインの特徴 詳細情報

管理サーバーに別個の仮想IP (VIP)アドレスを使用。

管理サーバーと管理対象サーバーのドメイン・ディレクトリの構成

ドメイン内の管理サーバーと管理対象サーバーに別個のドメイン・ディレクトリを使用。

管理サーバーと管理対象サーバーのドメイン・ディレクトリの構成

Oracle Web Services Managerの専用クラスタを含む。

アプリケーション層でのOracle Web Services Managerの使用

ホストごとのノード・マネージャ構成を使用します。

標準的なエンタープライズ・デプロイメントのノード・マネージャ構成について

別途インストールされたLDAPベースの認証プロバイダが必要。

OPSSおよび認証ストアと認可ストアへのリクエストの理解

WCCHOST1へのOracle Fusion Middleware Infrastructureのインストール

エンタープライズ・デプロイメント用の新規ドメインを構成する準備として、次の各項を参照してOracle Fusion Middleware Infrastructureソフトウェアをインストールします。

サポートされているJDKのインストール

Oracle Fusion Middlewareでは、動作保証されたJava Development Kit (JDK)がシステムにインストールされている必要があります。

JDKソフトウェアの検索とダウンロード

動作保証されているJDKを調べるには、Oracle Fusion Middlewareのサポートされるシステム構成ページで、ご使用のリリース向けの動作保証ドキュメントを参照してください。

現在のOracle Fusion MiddlewareリリースのOracle JDKを特定したら、Oracle Technology Networkの次の場所からOracle JDKをダウンロードできます。

https://www.oracle.com/java/technologies/downloads/

Java SE JDKのダウンロードに必ず移動してください。

JDKソフトウェアのインストール

アプリケーション層ホストの/u01/oracle/productsにマウントされている共有記憶域ボリュームVOL1とVOL2にJDKをインストールします。JDKをアップグレードする際に再構成の問題を回避するため、JDKのフォルダ名にはバージョン番号を含めないでください。たとえば、/u01/oracle/products/jdkです。

ノート:

推奨されるマウント・ポイントが複数製品の共有ボリュームを使用するため、複数のインストールが必要になる場合があります。

JDKソフトウェアの推奨場所の詳細は、「エンタープライズ・デプロイメント用の推奨ディレクトリ構造の理解」を参照してください。

次の例では、JDK 17.0の最新バージョンをインストールする方法について説明します。

  1. ディレクトリを、JDKアーカイブ・ファイルをダウンロードした場所に変更します。
    cd download_dir
  2. JDKホーム・ディレクトリにアーカイブを解凍してから、次のコマンドを実行します。
    tar -xzvf jdk-17.0.10+11_linux-x64_bin.tar.gz
    ここに記載されたJDKバージョンは、このドキュメントの発行時点のものです。サポートされている最新のJDKについては、Oracle Fusion Middlewareのシステム要件と仕様で現在のOracle Fusion Middlewareリリースを参照してください。
  3. JDKディレクトリを、ディレクトリ構造内の推奨される場所に移動します。
    たとえば:
    mv jdk-17.0.10 /u01/oracle/products/jdk
  4. ホスト・コンピュータでJavaを実行するためのJAVA_HOMEおよびPATH環境変数を定義します。
    たとえば:
    export JAVA_HOME=/u01/oracle/products/jdk
export PATH=$JAVA_HOME/bin:$PATH
  5. 次のコマンドを実行して、適切なjava実行可能ファイルがそのパスにあり、環境変数が適切に設定されていることを確認します。
    java -version
    出力のJavaバージョンは、17.0.10と表示されます。
  6. 適切なホスト上の一意の各製品共有ボリュームに対してステップ1から5を繰り返します。たとえば、WCCHOST1およびWCCHOST2です。

WCCHOST1でのインフラストラクチャ・インストーラの起動

インストール・プログラムを起動するには、次のステップを実行します。

  1. WCCHOST1にログインします。
  2. インストール・プログラムがダウンロードされたディレクトリに移動します。
  3. 次の例に示すように、システム上のJDKディレクトリからjava実行可能ファイルを実行して、インストール・プログラムを起動します。
    $JAVA_HOME/bin/java  -jar distribution_file_name.jar

    この例では、次のようになります。

    • JAVA_HOMEを、ご使用のシステムの環境変数または実際のJDKの場所に置き換えます。

    • distribution_file_nameを、ディストリビューションJARファイルの実際の名前に置き換えます。

      ディストリビューションをOracle Technology Network (OTN)からダウンロードする場合、通常、JARファイルはダウンロード可能な圧縮ファイル内にパッケージされています。

      初期インフラストラクチャ・ドメインに必要なソフトウェアをインストールする場合、インストールするディストリビューションはfmw_14.1.2.0.0_infrastructure.jarです。

      各ディストリビューションの実際のファイル名の詳細は、「エンタープライズ・デプロイメント用のソフトウェア・ダウンロードの特定と取得」を参照してください。

インストール・プログラムが表示されると、インストールを開始する準備ができています。各インストール・プログラム画面の説明については、「インストール画面のナビゲート」を参照してください。

Infrastructureインストール画面のナビゲート

インストール・プログラムでは次の表に記載された順番で一連の画面が表示されます。

インストール画面についての詳細情報が必要な場合は、画面名をクリックするか、画面上で「ヘルプ」ボタンをクリックしてください。

表10-1 Infrastructureインストール画面のナビゲート

画面 説明

インストール・インベントリの設定

UNIXオペレーティング・システムでは、このホストにOracle製品を初めてインストールする場合に、この画面が表示されます。中央インベントリを作成する場所を指定します。この画面で選択したオペレーティング・システムのグループ名に、中央インベントリの場所への書込み権限があることを確認します。

『Oracle Universal Installerによるソフトウェアのインストール』のOracleセントラル・インベントリに関する項を参照してください。

ノート:

製品の共有ボリューム上に、中央インベントリ・ディレクトリを構成することをお薦めします。例: /u01/oracle/products/oraInventory

インストーラが完了したら、oraInventoryからrootとしてcreateCentralinventory.shスクリプトを実行することが必要になる場合もあります。

ようこそ

製品のインストーラの紹介画面です。

自動更新

この画面を使用して、使用可能なパッチを「My Oracle Support」で自動的に検索するか、ユーザーの組織のためにすでにダウンロードされているパッチをローカル・ディレクトリで自動的に検索します。

インストール場所

この画面を使用してOracleホーム・ディレクトリの位置を指定します。

エンタープライズ・デプロイメントのためには、表7-2に示すORACLE_HOME変数の値を入力します。

インストール・タイプ

この画面を使用して、インストールのタイプと、それに従ってインストールされる製品および機能を選択します。

このトポロジの場合は、「Fusion Middleware Infrastructure」を選択します。

ノート:

このドキュメントのトポロジにサーバーの例は含まれません。例を本番環境にインストールしないことを強くお薦めします。

前提条件のチェック

この画面では、ご使用のシステムが最小要件を満たしていることを検証します。

警告またはエラー・メッセージが表示される場合、Oracle Technology Network (OTN)のOracle Fusion Middlewareシステム要件と仕様を参照してください。

セキュリティ更新

Oracle Supportアカウントをすでに所持している場合は、この画面を使用して、セキュリティ・アップデートの受取り方法を指定します。

アカウントを所持していないときに、このステップを省略してもかまわない場合は、チェック・ボックスをクリアして、その選択を後続のダイアログ・ボックスで確認します。

インストール・サマリー

この画面を使用して、選択したインストール・オプションを検証できます。これらのオプションをレスポンス・ファイルに保存する場合は、「レスポンス・ファイルの保存」をクリックし、レスポンス・ファイルの場所と名前を指定します。レスポンス・ファイルは、今後、サイレント・インストールを実行する場合に使用できます。

サイレント・インストールまたはコマンドライン・インストールの詳細は、『Oracle Universal Installerによるソフトウェアのインストール』の「サイレント・モードでのOracle Universal Installerの使用」を参照してください。

インストールの進行状況

この画面では、インストールの進行状況を参照できます。

インストール完了

インストールが完了すると、この画面が表示されます。この画面の情報を確認してから、「終了」をクリックしてインストーラを終了します。

他のホスト・コンピュータへのOracle Fusion Middleware Infrastructureのインストール

セカンダリ・ホストに別の共有記憶域ボリュームまたはパーティションを構成している場合は、それらのホストにもソフトウェアをインストールする必要があります。

「エンタープライズ・デプロイメントをインストールおよび構成する場合の共有記憶域の推奨事項」を参照してください。

トポロジ内の他のホスト・コンピュータにソフトウェアをインストールするには、各ホストにログインして、「WCCHOST1でのインフラストラクチャ・インストーラの起動」と「インフラストラクチャ・インストール画面のナビゲート」の手順に従って、適切な記憶域デバイスにOracleホームを作成します。

ノート:

以前のリリースでは、推奨エンタープライズ・トポロジに、同じ場所に配置された一連のOracle HTTP Serverインスタンスが含まれていました。これらのリリースでは、InfrastructureをWeb層ホスト(WEBHOST1およびWEBHOST2)にインストールする要件がありました。しかし、このリリースの場合、エンタープライズ・デプロイメント・トポロジでは、Webサーバーがスタンドアロン・モードでインストールおよび構成されると想定しているため、これらがアプリケーション層ドメインに含まれるとは考えられていません。「エンタープライズ・デプロイメント用のWeb層の構成」を参照してください

ディレクトリ構造のチェック

Oracle Fusion Middleware InfrastructureをインストールしてOracleホームを作成した後は、この項にリストされたディレクトリとサブディレクトリが表示されます。インストールの内容は、インストール中に選択したオプションによって異なります。

ディレクトリ構造をチェックするには:

  1. InfrastructureをインストールしたORACLE_HOMEディレクトリに移動します。
  2. 次のコマンドを入力します。
    ls --format=single-column $ORACLE_HOME
    システム上のディレクトリ構造は、次の例に示す構造と一致する必要があります。
    bin
cfgtoollogs
coherence
em
install
inventory
jlib
lib
OPatch
opmn
oracle_common
oraInst.loc
oui
wlserver
    Oracle Fusion Middlewareの理解のOracle Fusion Middlewareの主要なディレクトリに関する項を参照してください。

Derbyデータベースの無効化

組込みDerbyデータベースを無効化します。このデータベースは、ファイルベースのデータベースであり、Oracle WebLogic Serverにパッケージ化されています。Derbyデータベースは主に開発環境に使用されます。そのため、本番対応のエンタープライズ・デプロイメント環境を構成する場合は無効にする必要があります。そうしないと、管理対象サーバーの起動時にDerbyデータベース・プロセスが自動的に起動されます。
Derbyを無効にするには:
  1. Oracleホーム内の次のディレクトリに移動します。
    cd $WL_HOME/common/derby/lib
  2. Derbyライブラリjarファイルの名前を変更します。
    mv derby.jar disable_derby.jar
  3. 各ホストで別々のファイル・システムを使用する場合は、各ホストでステップ1から2を繰り返します。

データベース・スキーマの作成

Oracle Fusion Middlewareコンポーネントでは、Fusion Middleware Infrastructureドメインを構成する前に、データベースにスキーマが存在していることが必要になります。このトピックの動作保証されたデータベースにリストされているスキーマを、このリリースのOracle Fusion Middlewareと組み合せて使用するためにインストールします。

  • メタデータ・サービス(MDS)

  • 監査サービス(IAU)

  • 監査サービスへの追加(IAU_APPEND)

  • 監査サービス・ビューア(IAU_VIEWER)

  • OPSS (Oracle Platform Security Services)

  • ユーザー・メッセージング・サービス(UMS)

  • WebLogicサービス(WLS)

  • 共通インフラストラクチャ・サービス(STB)

リポジトリ作成ユーティリティ(RCU)を使用して、スキーマを作成します。このユーティリティは各Oracle Fusion Middleware製品のOracleホームにインストールされています。RCUの詳細とスキーマを作成してデータベースに格納する方法の詳細は、リポジトリ作成ユーティリティによるスキーマの作成でスキーマ作成の準備に関する項を参照してください。

必要なスキーマをインストールするには、次のステップを実行します。

動作保証されたデータベースのインストールと構成

必ず動作保証されたデータベースをインストールおよび構成し、そのデータベースを確実に稼働させます。

「エンタープライズ・デプロイメント用のデータベースの準備」を参照してください。

リポジトリ作成ユーティリティ(RCU)の起動

リポジトリ作成ユーティリティ(RCU)を起動するには:

  1. 対象のシステムで、JAVA_HOME環境変数に、動作保証されたJDKの場所が設定されていることを確認します。この場所は、binディレクトリより上の階層にする必要があります。たとえば、JDKが/u01/oracle/products/jdkに存在する場合は、次のようになります。

    UNIXオペレーティング・システムの場合:

    export JAVA_HOME=/u01/oracle/products/jdk
  2. WCCHOST1上の次のディレクトリに移動します。
    cd $ORACLE_HOME/oracle_common/bin
  3. RCUを起動します。
    ./rcu

    ノート:

    データベースで透過的データ暗号化(TDE)が有効化されており、RCUによって作成された表領域を暗号化する場合は、RCUの起動時に-encryptTablespace trueオプションを指定します。

    これによって、RCUの実行中に追加の操作をすることなく、「表領域のマップ」画面で適切なRCU GUI「表領域の暗号化」チェック・ボックスが選択されるようにデフォルト指定されます。『リポジトリ作成ユーティリティによるスキーマの作成』の表領域の暗号化に関する項を参照してください。

スキーマ作成のためのRCU画面のナビゲート

Fusion Middleware Infrastructureドメインにスキーマを作成するには、この項の手順に従います。

タスク1   RCUの導入

「ようこそ」画面でRCUのバージョン番号を確認します。「次へ」をクリックして開始します。

タスク2   スキーマ作成の方法の選択

データベースでDBAアクティビティを実行するために必要な権限を持っている場合は、「リポジトリの作成」画面で「システム・ロードおよび製品ロード」を選択します。このドキュメントの手順では、必要な権限があることを想定しています。

データベースに対するDBAアクティビティの実行に必要なパーミッションまたは権限が付与されていない場合は、この画面で、「システム・ロードに対するスクリプトの準備」を選択する必要があります。このオプションでは、SQLスクリプトが生成され、それをデータベース管理者に提供できます。『リポジトリ作成ユーティリティによるスキーマの作成』のシステム・ロードと製品ロードの理解に関する項を参照してください。

「次」をクリックします。

ヒント:

この画面の選択内容の詳細は、リポジトリ作成ユーティリティによるスキーマの作成でリポジトリの作成に関する項を参照してください。

タスク3   データベース接続の詳細の指定

RCUがデータベースに接続できるようにするために、データベース接続の詳細を指定します。

  1. 「データベース・タイプ」として、「Oracle Database (エディションベース再定義対応)」を選択します。

    ノート:

    エディションベース再定義(EBR)に対応したOracle Databaseは、ゼロ・ダウンタイム・アップグレードをサポートするために推奨されます。詳細は、https://www.oracle.com/database/technologies/high-availability/ebr.html.を参照してください

  2. 「ホスト名」フィールドに、Oracle RACデータベースのSCANアドレスを入力します。

  3. RACデータベース・スキャン・リスナーのポート番号(1521など)を入力します。

  4. データベースのRAC「サービス名」を入力します。

  5. スキーマとスキーマ・オブジェクトを作成する権限を持つユーザーの「ユーザー名」、たとえば「SYS」などを入力します。

  6. ステップ4で指定した名前のユーザーの「パスワード」を入力します。

  7. SYSユーザーを選択した場合は、ロールを必ずSYSDBAに設定してください。

  8. 「次へ」をクリックして先に進み、データベースへの接続が成功したことを確認するダイアログ・ウィンドウで、「OK」をクリックします。

ヒント:

この画面の選択内容の詳細は、リポジトリ作成ユーティリティによるスキーマの作成でデータベース接続の詳細に関する項を参照してください。

タスク4   カスタム接頭辞の指定とスキーマの選択

  1. Oracle Fusion Middlewareスキーマの識別に使用するカスタム接頭辞を指定します。

    ノート:

    RCUの制限が12文字であっても、WebCenter Portalスキーマを含める際は、カスタム接頭辞を10文字にする必要があります。これは、WebCenter Portalスキーマのフルネームを検証する際にRCUエラーを回避するためです。スキーマ・ユーザー名の最大長は、合計30文字に制限されます。WebCenter Portalスキーマの接尾辞は、最大20文字まで使用します。

    カスタム接頭辞は、これらのスキーマをこのドメインで使用するために論理的にまとめてグループ化するために使用されます。このガイドでは、FMW1412_という接頭辞を使用します。

    ヒント:

    ここで入力したカスタム接頭辞をノートにとってください。これは後でドメインの作成時に必要になります。

    カスタム接頭辞の詳細は、『リポジトリ作成ユーティリティによるスキーマの作成』のカスタム接頭辞の理解に関する項を参照してください。

  2. 「AS共通スキーマ」を選択します。

    「AS共通スキーマ」を選択すると、このセクションのすべてのスキーマが自動的に選択されます。

    このセクションのスキーマが自動的に選択されない場合、必要なスキーマを選択してください。

デフォルトで選択される必須のスキーマが2つあります。「共通インフラストラクチャ・サービス」(STBスキーマ)と「WebLogicサービス」(WLSスキーマ)で、この2つの選択は解除できません。「共通インフラストラクチャ・サービス」スキーマを使用すると、ドメインの構成中にRCUから情報を取得できるようになります。『リポジトリ作成ユーティリティによるスキーマの作成』でサービス表スキーマの理解に関する項を参照してください。

ヒント:

マルチドメイン環境のスキーマを構成する方法の詳細は、『リポジトリ作成ユーティリティによるスキーマの作成』のスキーマの作成計画に関する項を参照してください。

「次へ」をクリックして先に進み、スキーマ作成の前提条件チェックが成功したことを確認するダイアログ・ウィンドウの「OK」をクリックします。

タスク5   スキーマのパスワードの指定

スキーマのパスワードをデータベースに設定する方法を指定してから、パスワードの指定と確認を行います。続行する前にパスワードの複雑さがデータベース・セキュリティ要件を満たしていることを確認します。パスワード・ポリシーを満たしていない場合でも、この時点でRCUでは処理が続行されます。このため、このチェックはRCU自体の外部で実行します。

「次」をクリックします。

ヒント:

この画面で設定するパスワードは、ノートにとっておく必要があります。このパスワードは、後述するドメイン作成のプロセスで必要になります。

タスク6   必須スキーマの表領域の検証

残りの画面のデフォルト設定を受け入れるか、RCUでのOracle Fusion Middlewareスキーマの作成方法および必要な表領域の使用方法をカスタマイズできます。

ノート:

構成ウィザードを使用して、JMSサーバーのJDBCストアおよびトランザクション・ログを使用するようにFusion Middlewareコンポーネントを構成できます。これらのJDBCストアは、Weblogicサービス・コンポーネント表領域に配置されています。現在の環境でトランザクションやJMSアクティビティのレベルが高くなると想定される場合には、環境負荷に応じて<PREFIX>_WLS表領域のデフォルト・サイズを大きくすることができます。

「次」をクリックして続行し、表領域作成の確認ダイアログで「OK」をクリックします。

RCUとその機能および概念の詳細は、『リポジトリ作成ユーティリティによるスキーマの作成』の「リポジトリ作成ユーティリティについて」を参照してください。

タスク7   スキーマの作成

ロードするスキーマのサマリーを確認し、「作成」をクリックするとスキーマの作成が完了します。

ノート:

障害が発生した場合、続行する前に、リストされたログ・ファイルをレビューして根本的原因を特定し、欠陥を解決してから、RCUを使用してスキーマを削除して再作成します。

タスク8 レビュー完了のサマリーとRCU実行の完了

「完了サマリー」画面まで進んだら、スキーマ作成がすべて正常に完了していることを確認し、「閉じる」をクリックしてRCUを閉じます。

スキーマ・アクセスの確認

RCUによって作成された新しいスキーマ・ユーザーとしてデータベースに接続することにより、スキーマのアクセスを確認します。SQL*Plusまたは別のユーティリティを使用して接続し、RCUに入力した適切なスキーマ名およびパスワードを入力します。

たとえば:

./sqlplus FMW1412_WLS/<WLS_schema_password>

SQL*Plus: Release 23.0.0.0.0 - for Oracle Cloud and Engineered Systems on Wed Sep 11 14:20:00 2024 Version 23.5.0.24.07
Copyright (c) 1982, 2024, Oracle. All rights reserved.


Connected to:
Oracle Database 23ai EE Extreme Perf Release 23.0.0.0.0 - for Oracle Cloud and Engineered Systems
Version 23.5.0.24.07

SQL>

インフラストラクチャ・ドメインの構成

次の各項では、Fusion Middleware構成ウィザードを使用してWebLogic Serverドメインを作成するための手順を示します。

ドメイン作成に使用可能なその他の方法の詳細は、『構成ウィザードによるWebLogicドメインの作成』のWebLogicドメインの作成、拡張および管理のための追加ツールに関する項を参照してください。

構成ウィザードの起動

ドメインの構成を開始するには、WCCHOST1のOracle Fusion Middleware Oracleホームで次のコマンドを実行します。 

$ORACLE_HOME/oracle_common/common/bin/config.sh

インフラストラクチャ・ドメインを構成するための構成ウィザード画面のナビゲート

次の項の手順に従って、トポロジのドメインを作成して構成します。

タスク1   ドメイン・タイプとドメイン・ホームの場所の選択

「構成タイプ」画面で、「新規ドメインの作成」を選択します。

「ドメインの場所」フィールドで、「このガイドで使用するファイル・システムとディレクトリ変数」の定義に従って、ASERVER_HOME変数の値を指定します。

ヒント:

構成ウィザードのこの画面に示されるその他のオプションの詳細は、『構成ウィザードによるWebLogicドメインの作成』の構成タイプに関する項を参照してください。

タスク2   構成テンプレートの選択

「テンプレート」画面では、「製品テンプレートを使用してドメインを作成」が選択されていることを確認し、次のテンプレートを選択します。

  • Oracle Enterprise Manager -[em]

    このテンプレートを選択すると、次の依存性が自動的に選択されます。

    • Oracle JRF -[oracle_common]

    • WebLogic Coherenceクラスタの拡張 - [wlserver]

  • Oracle WSM Policy Manager -[oracle_common]

ヒント:

この画面のオプションの詳細は、『構成ウィザードによるWebLogicドメインの作成』のテンプレートに関する項を参照してください。

タスク3   アプリケーション・ホームの場所の選択

「アプリケーションの場所」フィールドで、「このガイドで使用するファイル・システムとディレクトリ変数」の定義に従って、APPLICATION_HOME変数の値を指定します。

ヒント:

この画面に示されるオプションの詳細は、『構成ウィザードによるWebLogicドメインの作成』のアプリケーションの場所に関する項を参照してください。

タスク4   管理者アカウントの構成

「管理者アカウント」画面で、ドメインのデフォルトWebLogic管理者アカウントのユーザー名("WebLogic"とは別の名前を使用することをお薦めします)およびパスワードを指定します。

この画面で指定したユーザー名およびパスワードをノートにとっておいてください。これらの資格証明は後でドメインの管理サーバーを起動して接続する際に必要になります。

タスク5   ドメイン・モードとJDKの指定

「ドメイン・モードおよびJDK」画面では、次の操作を実行します。

  • 「ドメイン・モード」フィールドで、「本番」を選択します。

  • 「JDK」フィールドで「Oracle Hotspot JDK」を選択します。

  • 「ドメインのデフォルト・ポートの有効化または無効化」フィールドで、本番モードに指定されたデフォルト値を使用します:
    • 「リスニング・ポート(非SSLポート)の有効化」が選択されていないことを確認します。

    • 「SSLリスニング・ポートの有効化」が選択されていることを確認します。

    • 「管理ポート(SSLポート)の有効化」が選択されていることを確認します。

ヒント:

開発モードと本番モードの違いなど、この画面のオプションの詳細は、『構成ウィザードによるWebLogicドメインの作成』のドメイン・モードとJDKに関する項を参照してください。

タスク6   データベース構成タイプの指定

「データベース構成タイプ」画面で、次のようにします。

  • 「RCUデータ」を選択して、この画面に示されるフィールドをアクティブ化します。

    「RCUデータ」オプションによってデータベースおよびサービス表(STB)スキーマに接続し、ドメインの構成に必要なスキーマのスキーマ情報を自動的に受け取るように構成ウィザードで指定できます。

  • 「ベンダー」がOracle、「ドライバ」が*Oracle's Driver (Thin) for Service Connections; Versions: Anyであることを確認します。

  • 「接続パラメータ」が選択されていることを確認します。

ノート:

この画面の「手動構成」を選択した場合は、「JDBCコンポーネント・スキーマ」画面でスキーマのパラメータを手動で入力する必要があります。

「RCUデータ」を選択したら、次の表に示すフィールドに入力します。

フィールド 説明

ホスト名

Enterprise Deployment Workbookに入力したOracle RACデータベースのSingle Client Access Name (SCAN)アドレスを入力します。

エンタープライズ・デプロイメント・ワークブックの詳細は、「エンタープライズ・デプロイメント・ワークブックの使用」を参照してください。

DBMS/サービス

製品スキーマをインストールする、このドメインに適切なOracle RACデータベースのサービス名を入力します。たとえば:

wcpedg.example.com

「エンタープライズ・デプロイメント用のデータベースの準備」の項ですでに構成している値に基づいて、サービス名を指定します。

ポート

データベースがリスニングするポート番号を入力します。たとえば、1521などです。

スキーマ所有者

スキーマ・パスワード

データベースのサービス表スキーマに接続するためのユーザー名とパスワードを入力します。

これはRCUの「スキーマ・パスワード」 画面でサービス表コンポーネントに指定したスキーマ・ユーザー名およびパスワードです(「データベース・スキーマの作成」を参照)。

デフォルトのユーザー名はprefix_STBであり、この場合prefixはRCUで定義したカスタム接頭辞です。

データベース接続情報の指定を完了したら、「RCU構成の取得」をクリックします。「接続結果ログ」の次の出力は、操作が成功したことを示します。 

Connecting to the database server...OK
Retrieving schema data from database server...OK
Binding local schema components with retrieved data...OK

Successfully Done.

データベースへの接続に成功したら、「次へ」をクリックします。

ヒント:

「RCUデータ」オプションの詳細は、『リポジトリ作成ユーティリティを使用したスキーマの作成』のサービス表スキーマの理解に関する項を参照してください。

この画面のその他のオプションの詳細は、『構成ウィザードによるWebLogicドメインの作成』のデータ・ソース・デフォルトに関する項を参照してください

タスク7   JDBCコンポーネント・スキーマ情報の指定

「JDBCコンポーネント・スキーマ」画面に示される値が、すべてのスキーマに対して適切であることを確認します。

前の画面でRCUデータの取得を選択しているため、スキーマ表は移入済のはずです。その結果、構成ウィザードはこのドメインに必要なすべてのスキーマのデータベース接続値を見つけることができます。

この時点では、これらの値は単一インスタンスのデータベースに接続するように構成されています。ただし、エンタープライズ・デプロイメントの場合、「エンタープライズ・デプロイメント用のデータベースの準備」の説明のように、可用性の高いReal Application Clusters (RAC)データベースを使用する必要があります。

さらに、各コンポーネント・スキーマでアクティブなGridLinkデータ・ソースを使用することをお薦めします。GridLinkデータ・ソースを使用してRACデータベースに接続する利点の詳細は、 『高可用性ガイド』の「データベースに関する考慮事項」を参照してください。

データ・ソースをGridLinkに変換するには:

  1. スキーマ表の最初のヘッダー行にあるチェック・ボックスを選択することですべてのスキーマを選択します。

  2. 「GridLinkへ変換」をクリックし、「次へ」をクリックします。

タスク8   GridLink Oracle RACデータベース接続の詳細情報の指定

「GridLink Oracle RACコンポーネント・スキーマ」画面で、次の表に示すように、RACデータベースおよびコンポーネント・スキーマへの接続に必要な情報を入力します。

要素 説明と推奨値

「SCAN」、「ホスト名」および「ポート」

「SCAN」チェック・ボックスを選択します。

「ホスト名」フィールドには、Oracle RACデータベースのSingle Client Access Name (SCAN)アドレスを入力します。

「ポート」フィールドには、データベースのリスニング・ポートを入力します(1521など)

「ONSホスト」と「ポート」

ONSリストはデータベースからドライバに自動的に提供されるため、Oracle 12cデータベース以上のバージョンを使用している場合、これらの値は必要ありません。

FANの有効化

「FANの有効化」チェック・ボックスが選択され、データベースがFANイベントを受信および処理できることを確認します。

サービス名

Oracle RACデータベースのサービス名が適切であることを確認します。たとえば、wcpedg.example.comです。

この画面で情報を指定する方法および適切なSCANアドレスの特定方法の詳細は、『高可用性ガイド』のOracle RACでのアクティブなGridLinkデータ・ソースの構成に関する項を参照してください。

また、「ヘルプ」をクリックすると、画面の各フィールドの簡単な説明を表示できます。

タスク9   JDBC接続のテスト

「JDBCコンポーネント・スキーマ・テスト」画面を使用して、構成したデータソース接続をテストします。

「ステータス」列に示される緑色のチェック・マークは、テストが成功したことを表します。問題が発生した場合は、この画面の「接続結果ログ」セクションに示されるエラー・メッセージを確認し、問題を修正してから接続テストを再試行してください。

ヒント:

この画面のその他のオプションの詳細は、『構成ウィザードによるWebLogicドメインの作成』のコンポーネント・スキーマのテストに関する項を参照してください

タスク10   拡張構成の選択

目的のトポロジに応じたドメインの構成を完了するには、「拡張構成」画面で次のオプションを選択します。

  • 管理サーバー

    これは、管理サーバーのリスニング・アドレスを構成するために必要です。

  • ノード・マネージャ

    これは、ノード・マネージャを構成するために必要です。

  • トポロジ

    サーバー・テンプレート、管理対象サーバー、クラスタ、仮想ターゲットおよびCoherenceの設定の追加、削除または変更に必要です。

タスク11   管理サーバーのリスニング・アドレスの構成

「管理サーバー」画面で、次の手順を実行します。

  1. 「サーバー名」フィールドで、デフォルト値(「AdminServer」)を維持します。

  2. 「リスニング・アドレス」フィールドに、「エンタープライズ・デプロイメント用のリソースの取得」で取得して「エンタープライズ・デプロイメント用のホスト・コンピュータの準備」で有効化したADMINVHNのVIPに対応する仮想ホスト名を入力します。

    ADMINVHN仮想ホストを使用する理由の詳細は、「エンタープライズ・デプロイメント用の必須IPアドレスの予約」を参照してください。

  3. 「管理サーバー・ポートの構成」セクションで、次のステップを実行します:

    1. 「リスニング・ポートの有効化」フィールドは選択解除したままにします。「リスニング・ポート」の値はグレー表示で無効になります。

    2. 「SSLリスニング・ポートの有効化」フィールドが選択されていることを確認します。

    3. 「SSLリスニング・ポート」フィールドはデフォルト値の7002のままにします。

    4. 「管理ポート」はデフォルト値の9002のままにします。

  4. 「サーバー・グループ」では、デフォルト値を「未指定」のままにします。

タスク12   ノード・マネージャの構成

ノード・マネージャ・タイプとして「手動ノード・マネージャ・セットアップ」を選択します。

警告:

下部ペインの警告は無視できます。このガイドでは、手動ノード・マネージャ構成に必要なステップについて説明します。

ヒント:

この画面に示されるオプションの詳細は、『構成ウィザードによるWebLogicドメインの作成』のノード・マネージャに関する項を参照してください。

ドメインごとおよびホストごとのノード・マネージャの実装の詳細は、「標準的なエンタープライズ・デプロイメントのノード・マネージャ構成について」を参照してください。

ノード・マネージャの構成については、『Oracle WebLogic Serverノード・マネージャの管理』の複数マシンでのノード・マネージャの構成に関する項を参照してください。

タスク13   管理対象サーバーの構成

「管理対象サーバー」画面で、2台の管理対象サーバーを新規作成します。

  1. 「追加」ボタンをクリックして、1台の管理対象サーバーを新規作成します。

  2. 「サーバー名」列でWLS_WSM1を指定します。

  3. 「SSLリスニング・アドレス」列にWCCHOST1と入力します。WCCHOST1に対応するホスト名を必ず入力し、IPアドレスは使用しないでください。

  4. 「リスニングの有効化」が選択解除され、「リスニング・ポート」が「無効」(グレー表示)になっていることを確認します。

  5. すべてのサーバーで「SSLポートの有効化」が選択されていることを確認します。

  6. 「SSLリスニング・ポート」を7010に設定します。

  7. 「管理ポート」を9003に設定します。

  8. 「サーバー・グループ」ドロップダウン・リストで、JRF-MAN-SVRおよびWSMPM-MAN-SVRを選択します。

    これらのサーバー・グループによって、Oracle JRFとOracle Web Services Manager (OWSM)のサービスが、作成中の管理対象サーバーにターゲット設定されます。

    サーバー・グループは、定義されたアプリケーション・サービスのグループをそれぞれに定義されたサーバー・グループにマッピングすることで、Fusion Middlewareアプリケーションおよびサービスを1つ以上のサーバーにターゲット設定します。特定のサーバー・グループにマップされた任意のアプリケーション・サービスは、そのグループに割り当てられたすべてのサーバーに自動的にターゲット指定されます。『ドメイン・テンプレート・リファレンス』のアプリケーション・サービス・グループ、サーバー・グループおよびアプリケーション・サービス・マッピングに関する項を参照してください。

    ノート:

    Oracle Web ServicesのNonceキャッシュは、WSM-CACHE-SVRサーバー・グループによって自動的に初期化され、ほとんどのアプリケーションに適しています。この初期化は、SOA、OSB、およびJRFを実行してCoherenceクラスタを作成する他のFMWサーバーで自動的に実行されます。Nonceは、SOAPリクエストで1回のみ使用できる一意の番号で、リプレイ攻撃を防止するために使用されます。Nonceキャッシュは、Webサービス・アプリケーションを実行する管理対象サーバーの追加された台数にあわせて自然に変化します。

    拡張キャッシュ構成の詳細は、『Oracle Web Services ManagerによるWebサービスの保護とポリシーの管理』のOracle CoherenceでのNonceのキャッシュに関する項を参照してください。この項では、カスタムWLSサーバーでのNonceキャッシュとWSM-CACHE-SVRサーバー・グループの使用に関する追加のガイダンスを示します。

  9. このプロセスを繰り返して、WLS_WSM2という名前の2つ目の管理対象サーバーを作成します。

    表10-2 管理対象サーバー

    サーバー名 リスニング・アドレス リスニング・ポートの有効化 リスニング・ポート SSLポートの有効化 SSLリスニング・ポート 管理ポート サーバー・グループ

    WLS_WSM1

    WCCHOST1

    選択解除

    無効

    チェック・ボックスを選択

    7010

    9003

    JRF-MAN-SVRおよびWSMPM-MAN-SVR

    WLS_WSM2

    WCCHOST2

    選択解除

    無効

    チェック・ボックスを選択

    7010

    9003

    JRF-MAN-SVRおよびWSMPM-MAN-SVR

この手順で推奨する管理対象サーバー名(WLS_WSM1およびWLS_WSM2)はこのドキュメント全体で参照します。別の名前を選択した場合は、必要に応じてそれらの名前に置き換えてください。

ヒント:

この画面のオプションの詳細は、『構成ウィザードによるWebLogicドメインの作成』の管理対象サーバーに関する項を参照してください。

タスク14   クラスタの構成

「クラスタ」画面を使用して、新しいクラスタを作成します。

  1. 「追加」ボタンをクリックします。

  2. 「クラスタ名」フィールドで、WSM-PM_Clusterを指定します。

  3. 「動的サーバー・グループ」ドロップダウン・リストで、未指定を選択します。

  4. 「次」をクリックします。

ヒント:

この画面に示されるオプションの詳細は、『構成ウィザードによるWebLogicドメインの作成』のクラスタに関する項を参照してください。

タスク15   サーバー・テンプレートの割当て

「次」をクリックします。

タスク16 動的サーバーの構成

静的クラスタとして残そうとするクラスタに対して、動的サーバーのすべてのオプションが無効になっていることを確認します。

  1. この画面の「計算済リスニング・ポート」および「計算済マシン名」チェックボックスの選択が解除されていることを確認します。

  2. 「サーバー・テンプレート」の選択および「動的サーバー・グループ」が未指定であることを確認します。

  3. 「次」をクリックします。

タスク17   クラスタへの管理対象サーバーの割当て

「サーバーのクラスタへの割当」画面を使用して、WLS_WSM1およびWLS_WSM2を新規クラスタWSM-PM_Clusterに割り当てます。

  1. 「クラスタ」ペインで、サーバーを割り当てるクラスタ(ここではWSM-PM_Cluster)を選択します。

  2. 「サーバー」ペインで、次のいずれかの操作を実行して、WLS_WSM1をWSM-PM_Clusterに割り当てます。

    • 「WLS_WSM1」を1回クリックして選択し、右矢印をクリックして「クラスタ」ペインの選択されているクラスタ(WSM-PM_Cluster)の下に移動します。

      または

    • 「WLS_WSM1」をダブルクリックして、クラスタ・ペインの選択されているクラスタ(WSM-PM_Cluster)の下に移動します。

  3. これらのステップを繰り返して、WLS_WSM2管理対象サーバーをWSM-PM_Clusterに割り当てます。

ヒント:

この画面のオプションの詳細は、『構成ウィザードによるWebLogicドメインの作成』のクラスタへのサーバーの割当に関する項を参照してください。

タスク18   Coherenceクラスタの構成

「Coherenceクラスタ」画面を使用して、ドメインに自動的に追加されるCoherenceクラスタを構成します。

「クラスタ・リスニング・ポート」に9991と入力します。

ノート:

Coherenceライセンス情報については、『Oracle Fusion Middlewareライセンス情報ユーザー・マニュアル』のOracle Coherence製品に関する項を参照してください。

タスク19   マシンの作成

「マシン」画面を使用して、ドメイン内に新規マシンを作成します。マシンは、ノード・マネージャでサーバーを起動または停止できるようにするために必要です。

  1. 「Unixマシン」タブを選択します。

  2. 「追加」ボタンをクリックし、新しいUNIXマシンを作成します。

    表10-3の値を使用して、各マシンの名前およびノード・マネージャ・リスニング・アドレスを定義します。

  3. 「ノード・マネージャ・リスニング・ポート」フィールドのポート番号を確認します。

    この例に示されているポート番号5556は、このドキュメントの別の例でも引用されることがあります。このポート番号は、必要に応じて各自のポート番号に置換してください。

表10-3 Unixマシンの作成時に使用する値

名前 ノード・マネージャのリスニング・アドレス ノード・マネージャのリスニング・ポート ノード・マネージャ・タイプ

ADMINHOST

ADMINVHN変数の値を入力します。

5556

SSL

WCCHOST1

WCCHOST1ホスト名変数またはWCCHOST1別名の値。たとえば、WCCHOST1.example.comなどです。

5556

SSL

WCCHOST2

WCCHOST2ホスト名変数またはWCCHOST2別名の値。たとえば、WCCHOST2.example.comなどです。

5556

SSL

WCPHOST1

WCPHOST1ホスト名変数の値。たとえば、WCPHOST1.example.comとなります。

5556

SSL

WCPHOST2

WCPHOST2ホスト名変数の値。たとえば、WCPHOST2.example.comとなります。

5556

SSL

ヒント:

この画面のオプションの詳細は、『構成ウィザードによるWebLogicドメインの作成』のマシンに関する項を参照してください。

タスク20   マシンへのサーバーの割当て

「サーバーのマシンへの割当」画面を使用して、静的に定義された管理対象を適切なマシンに割り当てます。動的クラスタの一部であるサーバーは、計算済マシン名に自動的に割り当てられます。

「サーバーのマシンへの割当」画面は、管理対象サーバーのクラスタへの割当て画面に似ています。「マシン」列でターゲット・マシンを選択し、左の列でサーバー名を選択した後、右矢印をクリックしてそのサーバーを適切なマシンに割り当てます。

次のように、サーバーを割り当てます。

  • AdminServerをADMINHOSTマシンに割り当てます。

  • WLS-WSM1管理対象サーバーをWCCHOST1マシンに割り当てます。

  • WLS-WSM2管理対象サーバーをWCCHOST2マシンに割り当てます。

ヒント:

この画面に示されるオプションの詳細は、『構成ウィザードによるWebLogicドメインの作成』のサーバーのマシンへの割当てに関する項を参照してください。

タスク21   構成の仕様の確認とドメインの構成

「構成サマリー」画面には、これから作成するドメインに関する詳細な構成情報が表示されます。この画面に示された各項目の詳細を調べて、情報に間違いがないことを確認します。

変更が必要な場合は、「戻る」ボタンを使用するか、ナビゲーション・ペインで画面を選択することで、任意の画面に戻れます。

ドメイン作成は、「作成」をクリックするまでは開始されません。

終了したら、「構成の進行状況」画面で「次へ」をクリックします。

ヒント:

この画面のオプションの詳細は、『構成ウィザードによるWebLogicドメインの作成』の構成サマリーに関する項を参照してください。

タスク22   ドメイン・ホームと管理サーバーURLのメモ

「構成に成功しました」画面には、構成したばかりのドメインについて、次の項目が表示されます。

  • ドメインの場所

  • 管理サーバーURL

どちらの項目も後で必要になるため、ノートにとっておく必要があります。ドメインの場所は、管理サーバーの起動に使用するスクリプトへのアクセスで必要になります。

「終了」をクリックして、構成ウィザードを閉じます。

WebLogicリモート・コンソールのダウンロードおよび構成

この項では、WebLogicリモート・コンソールをダウンロードして構成する方法について説明します。

ノート:

このEDGで必要な初期構成ステップとして、AdminServerリスニング・アドレスおよび管理ポートにアクセスする必要があります。後で、フロントエンド・ロード・バランサからのアクセスを構成します。

WebLogicリモート・コンソールをダウンロードして構成するには、次のステップを実行します:

  1. コンピュータから以前のバージョンのWebLogicリモート・コンソールをアンインストールします。
  2. WebLogicリモート・コンソールをダウンロードします。https://github.com/oracle/weblogic-remote-console/releasesに移動し、使用しているオペレーティング・システムからインストーラをダウンロードします。
  3. インストーラを実行します。
  4. WebLogic ServerドメインにWebLogicリモート・コンソール拡張をインストールします。WebLogicリモート・コンソール拡張は、WebLogicリモート・コンソールを使用してWebLogicドメインを管理する場合に追加機能を提供します。

    ノート:

    このステップは省略可能です。
    1. ドメイン・ホームの下にmanagement-services-extディレクトリを作成します。
    2. 最新のWebLogicリモート・コンソール拡張console-rest-ext-<version>.warを、https://github.com/oracle/weblogic-remote-console/releasesからダウンロードし、前のステップで作成したmanagement-services-extディレクトリ内に保存します。以前のバージョンの拡張がすでにダウンロードされている場合は、その拡張を削除して最新バージョンに置き換えます。
    3. 管理サーバーがすでに実行されている場合は再起動します。
  5. WebLogicリモート・コンソール・アプリケーションを起動します。

    例:

    ./weblogic-remote-console

    次のステップでは、最初に管理サーバー・リスニング・アドレスを使用してEDGドメイン・プロバイダに接続する必要があります。

ドメインのSSL証明書の構成

この項では、ドメインのSSL証明書を構成する方法について説明します。

WebLogicドメインの証明書および証明書ストアの作成

エンタープライズ・デプロイメント・ガイドでは、アプリケーション層のすべてのWebLogic管理対象サーバー、WebLogic管理サーバーおよびノード・マネージャに対してSSLリスニング・アドレスを使用するドメインを構成するステップを提供します。これを実現するには、すべてのサーバー、マシンおよびNMリスニング・アドレスに必要な証明書を作成し、ドメインおよびノード・マネージャ構成から指し示す必要があります。

Oracle FMW 14.1.2.0では、Oracle WebLogicでドメインごとの認証局(CA)を使用できます。このモデルでは、CertGenおよびImportPrivateKeyユーティリティが拡張され、ドメインの秘密キーを使用してパスフレーズを暗号化し、それらをドメインのDemoCerts.propsファイルに格納するようになりました。自己署名デモCAがドメインに対して自動的に作成され、EDGで使用されるSSLリスニング・アドレスの署名証明書に使用されます。実際の本番システムでは、標準のCAを使用する必要がありますが、ドメインごとのCAモデルは、ドメイン固有のCAを使用してSSLシステムを実装します。このCAは、非SSL構成よりも高度な保護を提供します。独自のカスタム証明書を使用する場合は、「エンタープライズ・デプロイメントの共通の構成および管理タスク」の章のunresolvable-reference.html#GUID-12AA6B79-72D3-49D0-A6CB-F883FBBAB5D7を参照してください。

Oracleでは、異なるサーバーで異なるすべての証明書およびストアを見つけることができる(適切なスナップショットまたはファイル・バックアップ・ツールで保護された)共有記憶域の場所を使用することをお薦めします。ドメインごとのCAを使用してWebLogic ServerでSSLリスナーを有効にするために使用できるアイデンティティ・ストアおよびトラスト・ストアを生成するには、次のステップを実行します:

  1. maa githubリポジトリのgenerate_perdomainCACERTS.shスクリプトをダウンロードします。

    https://github.com/oracle-samples/maa/blob/main/1412EDG/generate_perdomainCACERTS.sh

  2. 次の引数を使用してスクリプトを実行します:

    • WLS_DOMAIN_DIRECTORY: 管理サーバーが使用するWebLogicドメインをホストするディレクトリ。
    • WL_HOME: Oracle WebLogic Serverソフトウェア・バイナリを格納するOracleホーム内のディレクトリ。通常は/u01/oracle/products/fmw/wlserverです。
    • KEYSTORE_HOME: appIdentityおよびappTrustストアが作成されるディレクトリ。
    • KEYPASS: WebLogic管理ユーザーに使用されるパスワード(証明書およびストアで再利用されます)。

    例:

    ./generate_perdomainCACERTS.sh $ASERVER_HOME $ORACLE_HOME/wlserver $KEYSTORE_HOME <keypass>

このスクリプトは、WLS_DOMAIN_DIRECTORY/config/config.xmlをトラバースしてドメインで使用されるすべてのリスニング・アドレスを検索し、それらすべての証明書を生成し、ドメインCAを含むトラスト・ストアを作成して、新しいアイデンティティ・ストアに証明書をインポートします。インポートで使用される別名は、リスニング・アドレスとして使用されるホスト名と同じです。トラスト・ストアとアイデンティティ・ストアは、両方ともKEYSTORE_HOMEディレクトリに配置されます。

次のコマンドを実行して、"domainca"エントリがtrustedCertEntryとして存在するかどうかを確認します: 

keytool -list -keystore $KEYSTORE_HOME/appTrustKeyStore.pkcs12

次のコマンドを実行して、各リスニング・アドレス(ADMINVHN、WCCHOST1およびWCCHOST2の値)にPrivateKeyEntryが存在するかどうかを確認します。 

keytool -list -keystore $KEYSTORE_HOME/appIdentityKeyStore.pkcs12

WebLogic Server起動スクリプトへの証明書ストアの場所の追加

アイデンティティ・ストアとトラスト・ストアがドメイン用に作成されたら、一部のJavaプロパティをWebLogic起動スクリプトに追加する必要があります。これらのプロパティは、$ASERVER_HOME/binのファイルsetUserOverridesLate.shに追加されます。このファイルに追加されたカスタマイズはドメインのアップグレード操作中に保存され、packおよびunpackコマンドを使用する際にリモート・サーバーに継承されます。

  • 「WebLogicドメインの証明書および証明書ストアの作成」の説明に従って、スクリプトgenerate_perdomainCACERTS.shを使用してアイデンティティ・ストアおよびトラスト・ストアを作成した場合は、$ASERVER_HOME/binのファイルsetUserOverridesLate.shにプロパティが自動的に追加されます。ファイルが存在し、EXTRA_JAVA_PROPERTIESが追加されていることを確認します。

  • 独自のカスタム証明書を使用している場合は、$ASERVER_HOME/binにファイルsetUserOverridesLate.shを手動で作成します。ファイルを編集し、変数EXTRA_JAVA_PROPERTIESを追加して、EDGシステムで使用される値でjavax.net.ssl.trustStoreおよびjavax.net.ssl.trustStorePasswordプロパティを設定します。たとえば: 

    
EXTRA_JAVA_PROPERTIES="${EXTRA_JAVA_PROPERTIES}
 -Djavax.net.ssl.trustStore=/u01/oracle/config/keystores/appTrustKeyStore.pkcs12
 -Djavax.net.ssl.trustStorePassword=mypassword"
export EXTRA_JAVA_PROPERTIES

ノート:

追加のJavaプロパティの順序には意味があります。同じプロパティが複数回定義されている場合、後の値が使用されます。カスタム値は、示されている例のように定義する必要があります。

リモート・コンソールを使用したサーバーのセキュリティ設定の更新

管理サーバーの仮想ホスト名をプロバイダとして使用したリモート・コンソールへの接続
次の手順では、これらのタスクを実行できるように、一時的に管理サーバーをデフォルトの起動スクリプトで起動します。これらのタスクを実行したら、この一時セッションを停止し、ノード・マネージャを使用して管理サーバーを起動できます。

ノート:

このリモート・コンソールによる管理サーバーへの初期アクセスでは、リモート・コンソールを実行するマシンが管理サーバーのリスニング・アドレスを解決してそれに接続できる必要があります。これを行うには、管理サーバーが実行されているノードでリモート・コンソールを直接起動するか、リモート・コンソールが実行されているノードからこのアドレスへのトンネルを作成します。
  1. 次のデフォルトの起動スクリプトを使用して、管理サーバーを起動します:
    1. ディレクトリを次のディレクトリに変更します。
      cd $ASERVER_HOME/bin
    2. 起動スクリプトを実行します。
      ./startWebLogic.sh

      次のメッセージが表示されるまでターミナルをモニターします:

      <Server state changed to RUNNING>

      また、適切なSSLリスナーが使用可能であることを確認する必要もありますが、これは出力に表示される次のようなメッセージで確認できます:

      <Server> <BEA-002613> <Channel "DefaultSecure" is now listening on XXXX:7002 for protocols iiops, t3s, ldaps, https.>
  2. 次のように、WebLogicリモート・コンソールで新しいプロバイダを作成します:
    1. ドメインの信頼キーストアを、WebLogicリモート・コンソールを実行しているホストまたはラップトップにダウンロードします。たとえば、前の項でドメインごとのCAのステップを使用した場合、これは$KEYSTORE_HOME/appTrustKeyStore.pkcs12にあります。
    2. リモート・コンソールを開き、リモート・コンソール設定にドメイン・トラスト・ストアを追加します。「ファイル」→「設定」をクリックし、次の値を入力します。

      1. トラスト・ストア・タイプ - jks

      2. トラスト・ストア・パス - リモート・コンソールが実行されているホスト内の信頼キーストア・ファイルへのパス。

      3. トラスト・ストア・キー - 証明書の作成のために前述のステップで指定したパスワードを入力します。

      4. 前述のステップの説明に従ってデモ証明書を使用している場合は、「ホスト名検証の無効化」を選択します。

    3. リモート・コンソールの「プロバイダ」ウィンドウを使用して、「管理サーバー接続プロバイダの追加」を選択して新しいプロバイダを作成します。

      1. プロバイダ名で、wcpedg_domain_asvipという名前を入力します。これにより、アクセスのタイプが識別されます。

      2. 構成ウィザードのユーザー名に指定されているWebLogicドメイン管理ユーザー名を入力します。

      3. ドメインの作成に使用するパスワードを入力します。

      4. アクセス用のURLとして構成ウィザードで使用されるhttpsプロトコルおよび管理サーバーのリスニング・アドレスを使用して、ポート9002を指定します。

        たとえば、https://ADMINVHN.example.com:9002です。

      5. 「セキュアでない接続の確立」チェック・ボックスを選択します。

        ノート:

        フロントエンドおよびWeb層の構成後は、このプロバイダを使用しないでください。

      ドメインのリモート・コンソールのホーム・ウィンドウが表示されます。

WebLogic Serverのセキュリティ設定の更新
WebLogic Serverのセキュリティ設定および管理ポートを更新するには、次のステップを実行します:
  1. リモート・コンソールでドメイン・プロバイダにアクセスし、管理サーバーおよびWebLogic Serverのセキュリティ設定を更新します:
    1. 「ツリーの編集」をクリックします。
    2. 「環境」→「サーバー」→「AdminServer」をクリックします。
    3. 「セキュリティ」タブをクリックします。
    4. キーストア・ドロップダウンを「カスタム・アイデンティティとカスタム信頼」に変更します。
    5. 「カスタム・アイデンティティ・キーストア」で、次のようにアイデンティティ・キーストアの完全修飾パスを入力します:
      KEYSTORE_HOME/appIdentityKeyStore.pkcs12

      表7-2の説明に従って、KEYSTORE_HOMEを、キーストアの格納に使用するフォルダの値に置き換えます。

    6. 「カスタム・アイデンティティ・キーストアのタイプ」を「JKS」に設定します。

      ノート:

      JKSまたはPKCS12の指定は、PKCS12ストアとJKSストアの両方で有効です。顧客キー・ストア・タイプが「JKS」に設定されている場合、両方のフォーマットを読み取って管理できます。
    7. 「カスタム・アイデンティティ・キーストアのパスフレーズ」で、証明書の生成ステップで指定したパスワードKeystore_Passwordを入力します。
    8. 「カスタム信頼キーストア」で、信頼キーストアの完全修飾パスを入力します。
      KEYSTORE_HOME/appTrustKeyStore.pkcs12

      表7-2の説明に従って、KEYSTORE_HOMEを、キーストアの格納に使用するフォルダの値に置き換えます。

    9. 「カスタム信頼キーストアのタイプ」を「JKS」に設定します。

      ノート:

      JKSまたはPKCS12の指定は、PKCS12ストアとJKSストアの両方で有効です。顧客キー・ストア・タイプが「JKS」に設定されている場合、両方のフォーマットを読み取って管理できます。
    10. 「カスタム信頼キーストアのパスフレーズ」で、証明書の生成ステップで<keypass>として指定したパスワードを入力します。
    11. 「保存」をクリックします。
    12. 「セキュリティ」の設定で、「SSL」タブに移動します。
    13. 「サーバーの秘密キーの別名」フィールドで、証明書の生成ステップで指定した別名を入力します。証明書の生成スクリプトを使用した場合、これはWLSサーバーに使用されるリスニング・アドレスと同じです。
    14. 「サーバーの秘密キーのパスフレーズ」フィールドで、証明書の生成ステップで指定したパスワードを入力します。証明書の生成スクリプトを使用した場合、これはキーストアのパスフレーズと同じです。
    15. 「保存」をクリックします。

      画面の右上にあるカートが、内部に黄色いバッグが入った状態で表示されます。

    16. 右上の「カート」アイコンをクリックし、「変更のコミット」を選択します。

    ドメイン内の管理対象サーバーごとに前述のステップを繰り返し、証明書に使用される別名と一致するように別名を変更します。

  2. 起動スクリプトで管理サーバーを起動したターミナル・ウィンドウに戻ります。
  3. [Ctrl]+[C]を押して、管理サーバーのプロセスを停止します。

    管理サーバーのプロセスが停止し、ターミナル・コマンド・プロンプトが表示されるのを待ちます。

  4. 次のスクリプトを使用して、管理サーバーを再度起動します:
    1. ディレクトリを次のディレクトリに変更します。
      cd $ASERVER_HOME/bin
    2. 起動スクリプトを実行します。
      ./startWebLogic.sh
    3. 次の出力が表示されるまでターミナルの出力をモニターします。
      <Server state changed to RUNNING>

ドメインごとのCAを使用したKSSの構成

一貫性を維持し、ドメイン・アーティファクト全体で共通CAを使用するために、KSS (WebLogicインフラストラクチャ/JRFドメイン内のOPSSや他のコンポーネントで使用されるストア)でドメインごとのCAを使用できます。

KSSの信頼できるストアにドメインCA証明書をインポートするには、次のステップを実行します:

  1. maa githubリポジトリhttps://github.com/oracle-samples/maa/blob/main/1412EDG/import-domainca-into-kss.shのimport-domainca-into-kss.shスクリプトをダウンロードします。
  2. スクリプトを編集し、環境に応じて次の変数をカスタマイズします:

    DOMAIN_HOME: WebLogicドメインへのパス(このガイドではASERVER_HOME)。たとえば、/u01/oracle/config/domains/wcpedg_domainです。

    MW_HOME: FMWホームへのパス。たとえば、/u01/oracle/products/fmwです。

    ADMINVHN: 管理サーバーのリスニング・アドレス。たとえば、adminvhn.example.comです。

    ADMINPORT: 管理サーバーのリスニング・ポート。たとえば、9002です。

    DOMAINUSER: WLSドメインの管理者ユーザーの名前。たとえば、soaedgadminです。

    TRUSTSTOREFILE: SSLを介して管理サーバーに接続するために使用されるトラストストアの場所。たとえば、/u01/oracle/config/keystores/appTrustKeyStore.pkcs12です。

  3. 次の引数を使用してスクリプトを実行します:
    • DOMAINPASS: WLSドメイン管理者ユーザーのパスワード
    • KEYPASS: トラストストアのパスワード。

    例

    ./import-domainca-into-kss.sh adminpassword123 truststorepassword123

    このスクリプトは、ドメインごとのCA証明書をKSSにインポートし、JPSに割り当てます。

    JPS構成ファイルを検査して、更新が成功したことを確認できます。

    grep domainca $ASERVER_HOME/config/fmwconfig/jps-config.xml

    コマンドの結果は、次の例のようになる必要があります:

    <property name="ca.key.alias" value="domainca-new-24-05-07-16-44-52"/>
  4. 管理サーバーを再起動します。
    スクリプトを使用して管理サーバーを起動した場合は、次のステップを実行します:
    1. [Ctrl]+[C]を押して、管理サーバーのプロセスを停止します。
    2. $ASERVER_HOME/binディレクトリに移動して、次のコマンドを実行します:
      ./startWebLogic.sh

エンタープライズ・デプロイメントに対するホストごとのノード・マネージャの構成

エンタープライズ・デプロイメントによっては、デフォルトのドメインごとのノード・マネージャではなく、ホストごとのノード・マネージャを構成した方がよい場合があります。

ホストごとのノード・マネージャの利点の詳細は、「標準的なエンタープライズ・デプロイメントのノード・マネージャ構成について」を参照してください

ホストごとのノード・マネージャ構成の作成

ホストごとのノード・マネージャの構成のステップでは、構成ディレクトリおよび2つの新規ノード・マネージャ構成ファイルを作成します。デフォルトのstartNodeManager.shファイルを編集する必要もあります。

ホストごとのノード・マネージャ構成を作成するには、次のタスクをまずWCCHOST1で実行し、その後WCCHOST2で実行します。

  1. WCCHOST1にログインして、ノード・マネージャ構成ファイルのディレクトリを作成します。

    たとえば:

    mkdir -p /u02/oracle/config/nodemanager

    このディレクトリはホストに固有であるため、ローカル・ディスクに配置する必要があります。このディレクトリの場所はノード・マネージャ・ホームと呼ばれており、このガイドの各例ではNM_HOMEディレクトリ変数によって識別されます。

  2. ディレクトリをノード・マネージャ・ホーム・ディレクトリに変更します。
    cd $NM_HOME
  3. nodemanager.propertiesという新しいテキスト・ファイルを作成し、「例: nodemanager.propertiesファイルのコンテンツ」に示されている値をこの新しいファイルに追加します。

    構成するノードの関連するアイデンティティ別名を使用します。たとえば、WCCHOST1ではwcchost1.example.com、WCCHOST2ではwcchost2.example.comです。

    nodemanager.propertiesファイルに追加できるプロパティの詳細は、『Oracle WebLogic Serverノード・マネージャの管理』のノード・マネージャのプロパティに関する項を参照してください。

    nodemanager.propertiesファイルで、この構成の一部として、サーバーに対してクラッシュ・リカバリを有効にします。『Oracle WebLogic Serverノード・マネージャの管理』のノード・マネージャとシステム・クラッシュ・リカバリに関する項を参照してください。

    例: nodemanager.propertiesファイルのコンテンツ

    DomainsFile=/u02/oracle/config/nodemanager/nodemanager.domains
LogLimit=0
PropertiesVersion=14.1.2.0.0
AuthenticationEnabled=true
NodeManagerHome=/u02/oracle/config/nodemanager
#Include the specific JDK home
JavaHome=/u01/oracle/products/jdk
LogLevel=INFO
DomainsFileEnabled=true
StartScriptName=startWebLogic.sh
#Leave blank for listening on ANY
ListenAddress=
NativeVersionEnabled=true
ListenPort=5556
LogToStderr=true
SecureListener=true
LogCount=1
StopScriptEnabled=false
QuitEnabled=false
LogAppend=true
StateCheckInterval=500
CrashRecoveryEnabled=true
StartScriptEnabled=true
LogFile=/u02/oracle/config/nodemanager/nodemanager.log
LogFormatter=weblogic.nodemanager.server.LogFormatter
ListenBacklog=50
KeyStores=CustomIdentityAndCustomTrust 
CustomIdentityAlias=wcchost1.example.com
CustomIdentityKeyStoreFileName=/u01/oracle/config/keystores/appIdentityKeyStore.pkcs12
CustomIdentityKeyStorePassPhrase=password
CustomIdentityPrivateKeyPassPhrase=password

    CustomIdentityAliasの値に注意してください。generate_perdomainCACERTS.shスクリプトを使用した場合、これはノード・マネージャ・マシンの構成ウィザードでリスニング・アドレスとして使用されるホスト名です。証明書を1つずつ作成した場合、これはWCCHOST1の証明書インポートに割り当てた別名になります。前のステップで生成されたIdentityStoreの場所とそのパスワードも指定する必要があります。

  4. 次のディレクトリでstartNodeManager.shファイルを見つけます。
    $WL_HOME/server/bin
  5. startNodeManager.shファイルをノード・マネージャ・ホーム・ディレクトリにコピーします。
    cp $WL_HOME/server/bin/startNodeManager.sh $NM_HOME
  6. 新しいstartNodeManager.shファイルを編集し、NODEMGR_HOMEプロパティを次のように追加します。
    NODEMGR_HOME="NM_HOME"

    この例では、NM_HOMEをノード・マネージャ・ホームの実際のパスに置き換えます。

  7. WL_HOME/server/binディレクトリでstopNodeManager.shスクリプトを検索します。ノード・マネージャ・ホーム・ディレクトリにコピーします。コピーしたファイルを編集し、(startNodemanager.shファイルの場合と同様に)ノード・マネージャ・ホームを指すNODEMGR_HOMEプロパティを編集します:
    NODEMGR_HOME="NM_HOME"

    この例では、NM_HOMEをノード・マネージャ・ホームの実際のパスに置き換えます。

  8. ノード・マネージャ・ホーム・ディレクトリに、nodemanager.domainsという新しいファイルを作成します。

    nodemanager.domainsファイルではノード・マネージャ・クライアントのアクセスがファイル内に表示されたドメインに制限されるので、セキュリティがさらに強化されます。

  9. WCCHOST2でステップ1から8を実行します。
  10. 次のエントリを新しいnodemanager.domainsファイルに追加します。

    WCCHOST1で、管理サーバー・ドメイン・ホームと管理対象サーバー・ドメイン・ホームの両方の値を追加します。 

    wcpedg_domain=MSERVER_HOME;ASERVER_HOME

    ノート:

    最初に指定されたパス(MSERVER_HOME)は、primaryDomainPathとみなされ、管理対象サーバーはこの場所から実行されます。

    WCCHOST2で、管理対象サーバー・ドメイン・ホームのみの値を追加します。

    wcpedg_domain=MSERVER_HOME

    これらの例では、ASERVER_HOMEおよびMSERVER_HOMEを、「このガイドで使用するファイル・システムとディレクトリ変数」に示されているそれぞれの変数に置き換えます。

WCCHOST1でのノード・マネージャの起動

ホストごとのノード・マネージャ構成を使用するようノード・マネージャを手動で設定したら、startNodeManager.shスクリプトを使用してWCCHOST1でノード・マネージャを起動できます。
WCCHOST1でノード・マネージャを起動するには:
  1. ディレクトリをノード・マネージャ・ホーム・ディレクトリに変更します。
    cd $NM_HOME
  2. 次のコマンドを実行してノード・マネージャを起動し、コマンドの出力を現在のターミナル・シェルではなく出力ファイルに送信します。
    nohup ./startNodeManager.sh > ./nodemanager.out 2>&1 &
  3. nodemanager.outファイルを監視し、ノード・マネージャが正常に起動することを確認します。出力には最終的に次の文字列が含まれます:
    
<INFO> <Upgrade> <Encrypting NodeManager property: CustomIdentityKeyStorePassPhrase> 
<INFO> <Upgrade> <Encrypting NodeManager property: CustomIdentityPrivateKeyPassPhrase>
<Upgrade> <Saving upgraded NodeManager properties to '/u02/oracle/config/nodemanager/nodemanager.properties'>
<INFO> <Loading domains file: /u02/oracle/config/nodemanager/nodemanager.domains>
<INFO> <Loading identity key store: FileName=/u01/oracle/config/keystores/appIdentityKeyStore.pkcs12, Type=pkcs12, PassPhraseUsed=true>
<INFO> <Loaded NodeManager configuration properties from '/u02/oracle/config/nodemanager/nodemanager.properties'>
<INFO> <14.1.2.0.0>
<INFO> <Server Implementation Class: weblogic.nodemanager.server.NMServer$ClassicServer.>
<INFO> <Secure socket listener started on port 5556>

    nodemanager.propertiesのパスワードに使用されるプレーン・テキストが暗号化されていることを確認する必要があります: 

    
[oracle@wcchost1 keystores]$ cat /u02/oracle/config/nodemanager/nodemanager.properties 
#Tue Feb 06 11:53:10 GMT 2024
#Mon Feb 05 17:24:30 GMT 2024
DomainsFile=/u02/oracle/config/nodemanager/nodemanager.domains
LogLimit=0
PropertiesVersion=14.1.2.0.0
AuthenticationEnabled=true
NodeManagerHome=/u02/oracle/config/nodemanager
#Include the specific JDK home
JavaHome=/u01/oracle/products/jdk
LogLevel=INFO
DomainsFileEnabled=true
StartScriptName=startWebLogic.sh
#Leave blank for listening on ANY
ListenAddress=
NativeVersionEnabled=true
ListenPort=5556
LogToStderr=true
SecureListener=true
LogCount=1
StopScriptEnabled=false
QuitEnabled=false
LogAppend=true
StateCheckInterval=500
CrashRecoveryEnabled=true
StartScriptEnabled=true
LogFile=/u02/oracle/config/nodemanager/nodemanager.log
LogFormatter=weblogic.nodemanager.server.LogFormatter
ListenBacklog=50
KeyStores=CustomIdentityAndCustomTrust 
CustomIdentityAlias=wcchost1.example.com
CustomIdentityKeyStoreFileName=/u01/oracle/config/keystores/appIdentityKeyStore.pkcs12
CustomIdentityKeyStorePassPhrase={AES256}EMvPrOCRfN7fyv3d8JcEnttTLyneG9Su+UVK5DGEmqmqDwLkpLz9nQFZ+fL1Bidc
CustomIdentityPrivateKeyPassPhrase={AES256}O5cEJD8WVYP3aRLp9KAbFZ3CGLyxmmIWFX1YzVfJvPpl1dc5RbMksAcsBLquKcWW

ノード・マネージャ資格証明の構成

リモート・コンソールを使用してノード・マネージャ資格証明を設定するには、次のステップを実行します:

  1. リモート・コンソールでドメイン・プロバイダにアクセスします。
  2. 「ツリーの編集」をクリックします。
  3. 「環境」→「ドメイン」→「セキュリティ」をクリックします。
  4. 「拡張フィールドの表示」フィールドを選択します。
  5. 「ノード・マネージャ・ユーザー名」をWebLogic管理者と同じに設定します。このユーザー名は、このガイドで説明する他のタスクで使用されるためです。
  6. NMパスワードを変更します。「ノード・マネージャ・パスワード」がWebLogic管理者と同じに設定されていることを確認します。このパスワードは、このガイドで説明する他のタスクで使用されるためです。
  7. 「保存」をクリックします画面の右上にあるカートが、内部に黄色いバッグが入った状態で表示されます。
  8. 右上の「カート」アイコンをクリックし、「変更のコミット」を選択します。

NMへのドメインの登録

ノード・マネージャにドメインを登録するには、新しいターミナル・ウィンドウで次のステップを実行します。

ノート:

このステップを実行しないと、ノード・マネージャに接続し、それを使用してドメイン内のサーバーを起動できません。
  1. ディレクトリを次のディレクトリに変更します。
    cd $ORACLE_COMMON_HOME/common/bin
  2. WebLogic Server Scripting Tool (WLST)を起動します。適切なSSLハンドシェイク用に作成された証明書を使用するには、ストアの場所とそのパスワードをWLSTに提供する必要があります。次のコマンドを使用するか、簡単に起動できるスクリプトにこれらを追加します: 
    
export WLST_PROPERTIES="-Dweblogic.security.TrustKeyStore=CustomTrust -Dweblogic.security.CustomTrustKeyStoreFileName=/u01/oracle/config/keystores/appTrustKeyStore.pkcs12 -Dweblogic.security.CustomTrustKeyStorePassPhrase=storepassword"
./wlst.sh

    ノート:

    スクリプトにパスワードを含めることは避けてください。
  3. 次のWLSTコマンドを使用して管理サーバーに接続します。
    connect('admin_user','admin_password','admin_url')

    たとえば:

    connect('weblogic','<password>','t3s://ADMINVHN:9002')
  4. nmEnrollコマンドを使用して、ノード・マネージャが指定したWebLogicドメイン内のサーバーを管理できるようにします。
    nmEnroll('ASERVER_HOME')

    たとえば:

    nmEnroll('/u01/oracle/config/domains/wcpedg_domain')
  5. 次のWLSTコマンドを使用して、管理サーバーの起動プロパティを生成します:
    nmGenBootStartupProps('AdminServer')

    次のディレクトリに、startup.propertiesおよびboot.propertiesファイルが作成されます: 

    $ASERVER_HOME/servers/AdminServer/data/nodemanager/

ノード・マネージャへのトラストストア構成の追加

異なるWebLogic Serverリスナーとのノード・マネージャ通信に対応するトラストストア構成を追加する必要があります。これを行うには、$NM_HOMEにあるノード・マネージャの起動スクリプトstartNodeManager.shを編集し、変数JAVA_OPTIONSを追加して、EDGシステムで使用される値でjavax.net.ssl.trustStoreおよびjavax.net.ssl.trustStorePasswordプロパティを設定します。たとえば: 

export JAVA_OPTIONS="${JAVA_OPTIONS} -Djavax.net.ssl.trustStore=/u01/oracle/config/keystores/appTrustKeyStore.pkcs12 -Djavax.net.ssl.trustStorePassword=mypassword"

ノート:

generate_perdomainCACERTS.shスクリプトを使用して証明書およびストアを生成した場合、trustStorePasswordはスクリプトに"KEYPASS"パラメータとして指定されたパスワードです。

WCCHOST1でのドメイン・ディレクトリの構成とサーバーの起動

ドメインを作成してノード・マネージャを構成したら、WCCHOST1で追加のドメイン・ディレクトリを構成し、管理サーバーおよび管理対象サーバーを起動できます。

ノード・マネージャを使用した管理サーバーの起動

ドメインを構成し、ノード・マネージャを構成したら、ノード・マネージャを使用して管理サーバーを起動できます。エンタープライズ・デプロイメントでは、ドメイン内の管理サーバーおよびすべての管理対象サーバーの起動および停止にノード・マネージャが使用されます。

ノード・マネージャを使用して管理サーバーを起動するには:

  1. WLSTプロパティを設定します。
    export WLST_PROPERTIES="
-Dweblogic.security.TrustKeyStore=CustomTrust
-Dweblogic.security.CustomTrustKeyStoreFileName=/u01/oracle/config/keystores/appTrustKeyStore.pkcs12
Dweblogic.security.CustomTrustKeyStorePassPhrase=password"
  2. WebLogic Scripting Tool(WLST)を起動します。

    ノート:

    generateCertifcatesスクリプトが提供したものとしてデモ証明書を使用する場合は、weblogic.security.SSL.ignoreHostnameVerification=trueが必要です。正式なCAおよび証明書がある環境では、このフラグは使用しないでください。 
    cd ORACLE_COMMON_HOME/common/bin
./wlst.sh
  3. ノード・マネージャ資格証明を使用してノード・マネージャに接続します。
    nmConnect('nodemanager_username','nodemanager_password','ADMINVHN','5556','domain_name','ASERVER_HOME','SSL')

    ノート:

    このユーザー名とパスワードは、ノード・マネージャとクライアントの間の接続の認証にのみ使用されます。これらは、サーバー管理者IDおよびパスワードとは無関係であり、次のディレクトリにあるnm_password.propertiesファイルに格納されます。 

    ASERVER_HOME/config/nodemanager
  4. 管理サーバーを起動します。
    nmStart('AdminServer')

    ノート:

    管理サーバーを起動すると、WebServicesポリシーのためにOracle Web Services Managerに接続しようとします。WSM-PM管理対象サーバーはまだ起動されていないと予想されるため、管理サーバー・ログには次のメッセージが表示されます。

    <Warning><oracle.wsm.resources.policymanager>
<WSM-02141><Unable to connect to the policy access service due to Oracle WSM policy manager host server being down.>
  5. WLSTを終了します。
    exit()

管理サーバーの検証

構成ステップに進む前に、管理サーバーが正常に起動して実行されていることを検証するために、管理サーバーにインストールおよび構成されているOracle WebLogicリモート・コンソールおよびOracle Enterprise Manager Fusion Middleware Controlへのアクセス権があることを確認します。

Fusion Middleware Controlに移動するには、次のURLを入力し、Oracle WebLogic Server管理者の資格証明を使用してログインします。

https://ADMINVHN:9002/em

WCCHOST1での管理対象サーバーの個別ドメイン・ディレクトリの作成

エンタープライズ・デプロイメント用にドメインを初期作成すると、ドメイン・ディレクトリは共有ディスクにあります。このデフォルト・ドメイン・ディレクトリは、管理サーバーの実行に使用されます。次は、WCCHOST1とWCCHOST2の両方のローカル記憶域に、このドメインのコピーを作成できます。ローカル(またはプライベート)記憶域上のドメイン・ディレクトリは、管理対象サーバーの実行に使用されます。

サーバーが共有記憶域にログを書き込むことによって発生する潜在的な競合とオーバーヘッドを排除するために、MSERVER_HOMEをローカル記憶域に配置することをお薦めします。また、必要なクラスおよびjarをドメイン・ディレクトリからロードするほうが高速であるため、管理対象サーバーがドメイン・ディレクトリから使用する一時データまたはキャッシュ・データのほうがより迅速に処理されます。

「エンタープライズ・デプロイメント用のファイル・システムの準備」の説明のように、管理サーバー・ドメイン・ホームのパスはASERVER_HOME変数によって表され、管理対象サーバー・ドメイン・ホームのパスはMSERVER_HOME変数によって表されます。

管理対象サーバーのドメイン・ディレクトリを作成するには:

  1. WCCHOST1にサインインし、次のようにpackコマンドを実行してテンプレートを作成します。
    cd $ORACLE_COMMON_HOME/common/bin
 
./pack.sh -managed=true \ 
          -domain=ASERVER_HOME \ 
          -template=/full_path/create_domain.jar \ 
          -template_name=wcp_domain_template \
	  -log_priority=DEBUG \ 
          -log=/tmp/pack.log

    この例では、次のようになります。

    • ASERVER_HOMEを、共有記憶域デバイスに作成したドメイン・ディレクトリの実際のパスに置き換えます。

    • full_pathを、ドメイン・テンプレートjarファイルを作成する場所の完全なパスに置き換えます。ドメイン・テンプレートJARファイルをコピーまたは解凍する際に、この場所を参照する必要があります。ORACLE_HOME以外の共有ボリュームを選択するか、/tmp/に書き込み、そのファイルをサーバー間で手動でコピーすることをお薦めします。

      テンプレートJARファイルの完全なパスを、packコマンドの-template引数の一部として指定する必要があります。 

      SHARED_CONFIG_DIR/domains/template_filename.jar

    • create_domain.jarファイルは作成するJARファイルのサンプル名であり、これにはドメイン構成ファイルが含まれます。

    • wcp_domain_templateラベルは、テンプレート・ファイルに格納されるテンプレート・データに割り当てられるラベルです。

  2. packコマンドで作成したばかりのcreate_domain.jarファイルの場所をノートにとります。

    ヒント:

    packおよびunpackコマンドの詳細は、『PackおよびUnpackコマンドによるテンプレートとドメインの作成』の「PackおよびUnpackコマンドの概要」を参照してください。

  3. まだ作成していない場合は、WCCHOST1のローカル記憶域デバイスに管理対象サーバー・ドメインの推奨ディレクトリ構造を作成します。
  4. 次のようにunpackコマンドを実行して、ドメイン・ディレクトリ内のテンプレートをローカル記憶域に解凍します。
    cd $ORACLE_COMMON_HOME/common/bin

./unpack.sh -domain=MSERVER_HOME \
            -overwrite_domain=true \
            -template=/full_path/create_domain.jar \
	    -log_priority=DEBUG \
            -log=/tmp/unpack.log \
            -app_dir=APPLICATION_HOME

    ノート:

    unpackコマンドで-overwrite_domainオプションを使用すると、管理対象サーバーのテンプレートを、既存のドメインおよび既存のアプリケーション・ディレクトリに解凍できます。上書きされるファイルがあれば、上書き前のファイルのバックアップ・コピーが作成されます。管理対象サーバーのドメイン・ディレクトリにある起動スクリプトおよびearファイルになんらかの変更が適用されていた場合には、この解凍処理の後に起動スクリプトおよびearファイルをリストアする必要があります。

    また、ドメイン内のすべてのサーバーに適用するサーバー起動パラメータをカスタマイズするために、setUserOverridesLate.shというファイルを作成して、WebLogic Serverのクラスパスへのカスタム・ライブラリの追加、サーバーを実行するための追加のjavaコマンド行オプションの指定、追加の環境変数の指定などを行うよう構成できます。このファイルに追加されたカスタマイズは、ドメインのアップグレード操作中も保持され、packおよびunpackコマンドの使用時にはリモート・サーバーに継承されます。

    この例では、次のようになります。

    • MSERVER_HOMEを、ローカル記憶域ディスクに作成するドメイン・ホームの完全なパスに置き換えます。これは、ドメインのコピーの解凍先となる場所です。

    • /full_path/create_domain.jarを、packコマンドを実行して共有記憶域デバイス上のドメインを圧縮したときに作成したドメイン・テンプレートJARファイルの完全なパスとファイル名に置き換えます。

    • APPLICATION_HOMEを、共有記憶域上のそのドメインのアプリケーション・ディレクトリの完全なパスに置き換えます。「このガイドで使用するファイル・システムとディレクトリ変数」を参照してください。

    ヒント:

    packおよびunpackコマンドの詳細は、『PackおよびUnpackコマンドによるテンプレートとドメインの作成』の「PackおよびUnpackコマンドの概要」を参照してください。

  5. ディレクトリを、新しく作成した管理対象サーバー・ディレクトリに変更して、ドメイン構成ファイルがWCCHOST1のローカル記憶域デバイスの適切な場所にコピーされていることを確認します。

WCCHOST1でのWLS_WSM1管理対象サーバーの起動と検証

ノード・マネージャを構成して管理対象サーバー・ドメイン・ディレクトリを作成したら、Oracle Enterprise Manager Fusion Middleware Controlを使用してWCCHOST1でWLS_WSM1管理対象サーバーを起動できます。

  1. ブラウザに次のURLを入力し、Fusion Middleware Controlログイン画面を表示します。
    https://ADMINVHN:9002/em

    この例では、次のようになります。

  2. 管理者のアカウントを使用してFusion Middleware Controlにサインインします。たとえば、weblogicを使用します。
  3. 「サーバー」ペインを選択して、ドメイン内の管理対象サーバーを表示します。
  4. WLS_WSM1管理対象サーバーのみを選択し、割り当てられたポート番号を書き留めてください。
  5. ツールバーで「制御」→「起動」をクリックし、選択したWLS_WSM1管理対象サーバーを起動します。
  6. 管理対象サーバーが正しく機能していることを検証するには、ブラウザを開き、次のURLを入力します。
    https://WCCHOST1:7010/wsm-pm/

    要求に従って、ドメイン管理ユーザー名とパスワードを入力します。

Webサービス・マネージャの構成

この項では、Webサービス・マネージャを構成する方法について説明します。

WebServicesドメイン構成の更新

  1. 管理者のアカウントを使用してFusion Middleware Controlにログインします。
  2. 「WebLogicドメイン」ドロップダウン・メニューで、「WebServices」→「WSMドメイン構成」を選択します。
  3. 「ポリシー・アクセス」タブをクリックします。
  4. 「自動検出」および「SSLのみ使用」チェック・ボックスを選択します。
  5. 「SSL設定」セクションで、「一方向」を選択します。
  6. 「キーストア・タイプ」で、「JKS (Javaキーストア)」を選択します。

    ノート:

    前のステップで作成した証明書およびストアを使用する場合は、JKSを選択する必要があります。

  7. 「トラストストア・パス」で、前の項で使用したトラストストアの場所を次のように入力します:
    /u01/oracle/config/keystores/appTrustKeyStore.pkcs12
  8. 「キー」フィールドで、トラストストアに使用されるパスワードを一意に識別する名前を入力します。
  9. 「パスワード」フィールドで、前の項でトラストストアに使用したパスワードを入力します(ドメイン管理者と同じ)。
  10. 「適用」をクリックします。

WSMのブートストラップ

新しいターミナル・ウィンドウで、次のステップを実行してWSMPMをブートストラップします。

ノート:

このタスクが実行されない場合、WSMPMは正しく動作しません。
  1. ディレクトリを次のディレクトリに変更します:
    cd $ORACLE_COMMON_HOME/common/bin
  2. WebLogic Server Scripting Tool (WLST)を起動します。適切なSSLハンドシェイク用に作成された証明書を使用するには、ストアの場所とそのパスワードをWLSTに提供する必要があります。次のコマンドを使用するか、簡単に起動できるスクリプトにこれらを追加します(スクリプトにパスワードを含めることは避けてください):
    
export WLST_PROPERTIES="-Dweblogic.security.TrustKeyStore=CustomTrust
-Dweblogic.security.CustomTrustKeyStoreFileName=/u01/oracle/config/keystores/appTrustKeyStore.pkcs12
-Dweblogic.security.CustomTrustKeyStorePassPhrase=storepassword"
./wlst.sh
  3. 次のWLSTコマンドを使用して管理サーバーに接続します。
    connect('admin_user','admin_password','admin_url')

    たとえば:

    connect('weblogic','<password>','t3s://ADMINVHN:9002')
  4. setWSMBootstrapConfigを使用して、WSM pm.urlを有効にします。
    setWSMBootstrapConfig('domain_name','domainpath','ConfigManager','pm.url','auto-ssl')

    たとえば:

    setWSMBootstrapConfig('wcpedg_domain','/u01/oracle/config/domains/wcpedg_domain','ConfigManager','pm.url','auto-ssl')

    ドメインの$ASERVER_HOME/config/fmwconfig/wsm-config.xmlに適切なエントリが作成されていることを確認します。たとえば: 

    
cat /u01/oracle/config/domains/wcpedg_domain/config/fmwconfig/wsm-config.xml
<?xml version="1.0" encoding="UTF-8"?>
<orares:properties xmlns:orares="http://xmlns.oracle.com/wsm/resources" xmlns:wsp15="http://www.w3.org/ns/ws-policy" xmlns:orawsp="http://schemas.oracle.com/ws/2006/01/policy" orares:type="CONFIGURATION" orares:resource="/">
   <orares:property orares:category="ConfigManager" orares:name="pm.url">
      <orares:value>auto-ssl</orares:value>
   </orares:property>
</orares:properties>

WCCHOST2でのドメインの伝播とサーバーの起動

WCCHOST1で管理サーバーとWLS_WSM1管理対象サーバーを起動して検証したら、WCCHOST2で次のタスクを実行できます。

WCCHOST2でのドメイン構成の解凍

WCCHOST1で管理サーバーと1つ目のWLS_WSM1管理対象サーバーを実行したので、WCCHOST2でドメインを構成できます。

  1. WCCHOST2にログインします。
  2. まだ作成していない場合は、WCCHOST2の記憶域デバイスに管理対象サーバー・ドメインの推奨ディレクトリ構造を作成します。
  3. create_domain.jarが、WCCHOST2からアクセス可能になっていることを確認します。
    たとえば、WCCHOST2のために別の共有記憶域ボリュームまたはパーティションを使用している場合は、WCCHOST2にマウントされているボリュームまたはパーティションにテンプレートをコピーします。
  4. 次のようにunpackコマンドを実行して、ドメイン・ディレクトリ内のテンプレートをローカル記憶域に解凍します。
    cd $ORACLE_COMMON_HOME/common/bin

./unpack.sh -domain=MSERVER_HOME \
            -overwrite_domain=true \
            -template=/full_path/create_domain.jar \
            -log_priority=DEBUG \
            -log=/tmp/unpack.log \
            -app_dir=APPLICATION_HOME

    この例では、次のようになります。

    • MSERVER_HOMEを、ローカル記憶域ディスクに作成するドメイン・ホームの完全なパスに置き換えます。これは、ドメインのコピーの解凍先となる場所です。

    • full_pathを、packコマンドを実行して共有記憶域デバイス上のドメインを圧縮したときに作成したドメイン・テンプレートJARファイルの完全なパスとファイル名に置き換えます。

    • APPLICATION_HOMEを、共有記憶域上のそのドメインのアプリケーション・ディレクトリの完全なパスに置き換えます。「このガイドで使用するファイル・システムとディレクトリ変数」を参照してください。

    ヒント:

    packおよびunpackコマンドの詳細は、『PackおよびUnpackコマンドによるテンプレートとドメインの作成』の「PackおよびUnpackコマンドの概要」を参照してください。

  5. ディレクトリを、新しく作成したMSERVER_HOMEディレクトリに変更して、ドメイン構成ファイルがWCCHOST2のローカル記憶域デバイスの適切な場所にコピーされていることを確認します。

WCCHOST2でのノード・マネージャの起動

ホストごとのノード・マネージャ構成を使用するようにノード・マネージャを手動で設定したら、WCCHOST2で次のコマンドを使用してノード・マネージャを起動できます。

  1. ディレクトリをノード・マネージャ・ホーム・ディレクトリに変更します。
    cd $NM_HOME
  2. 次のコマンドを実行してノード・マネージャを起動し、コマンドの出力を現在のターミナル・シェルではなく出力ファイルに送信します。
    nohup ./startNodeManager.sh > nodemanager.out 2>&1 &

WCCHOST2でのWLS_WSM2管理対象サーバーの起動と検証

「WCCHOST1でのWLS_WSM1管理対象サーバーの起動と検証」の手順を使用して、WCCHOST2上のWLS_WSM2管理対象サーバーを起動して検証します。

uploadおよびstageディレクトリの絶対パスへの変更

ドメインを構成し、すべてのホスト上の管理対象サーバー・ドメイン・ディレクトリにそのドメインを解凍した後、新しいクラスタ内の管理対象サーバーのuploadディレクトリとstageディレクトリを検証および更新します。「エンタープライズ・デプロイメントでのuploadおよびstageディレクトリの絶対パスへの変更」を参照してください。

新しいLDAPオーセンティケータの作成とエンタープライズ・デプロイメント・ユーザーおよびグループのプロビジョニング

Oracle Fusion Middlewareドメインを構成すると、このドメインはデフォルトでWebLogic Server認証プロバイダ(DefaultAuthenticator)を使用するよう構成されます。ただし、エンタープライズ・デプロイメントの場合は、専用の集中管理型のLDAP準拠の認証プロバイダを使用することをお薦めします。

次の各項では、Oracle WebLogicリモート・コンソールを使用してエンタープライズ・デプロイメント・ドメイン用の新しい認証プロバイダを作成する方法を説明します。この手順では、サポートされているLDAPディレクトリ(Oracle Unified DirectoryやOracle Internet Directoryなど)をすでにインストールおよび構成していることを想定しています。

サポートされている認証プロバイダについて

Oracle Fusion Middlewareでは、様々なLDAP認証プロバイダをサポートしています。『Oracle Platform Security Servicesによるアプリケーションの保護』のアイデンティティ・ストア・タイプおよびWebLogicオーセンティケータに関する項を参照してください。

このガイドの手順では、次のいずれかのプロバイダを使用していることを想定しています。

  • Oracle Unified Directory

  • Oracle Internet Directory

  • Microsoft Active Directory

ノート:

ここに示す手順では、デフォルトで、暗号化されていない接続を使用して、単一のLDAPアイデンティティ・ストアに対する問合せをサポートするようにアイデンティティ・サービス・インスタンスを構成する方法を説明します。

アイデンティティ・プロバイダへの接続をSSLで保護する必要がある場合、正しく機能するには、Enterprise Manager Fusion Middleware Controlでのロール管理に追加のキーストーン構成が必要です。構成の詳細は、support.oracle.comでDoc ID 1670789.1を参照してください。

また、LibOVDを使用して、複数のLDAPアイデンティティ・ストアに問合せを行う仮想アイデンティティ・ストアをサポートするようにサービスを構成できます。

複数LDAP参照に関する詳細は、Oracle Platform Security Servicesによるアプリケーションの保護のアイデンティティ・ストア・サービスの構成に関する項を参照してください。

エンタープライズ・デプロイメントのユーザーおよびグループについて

次の各項では、エンタープライズ・デプロイメント管理ユーザーおよびグループの用途と特性に関する重要な情報を提供します。

各ドメインで一意の管理ユーザーの使用について

集中LDAPユーザー・ストアを使用すると、複数のOracle WebLogic Serverドメインで使用するユーザーおよびグループをプロビジョニングできます。その結果、あるWebLogic管理ユーザーがエンタープライズ内のすべてのドメインにアクセスできてしまうことにもなります。

Oracle Fusion Middlewareドメインの管理用にプロビジョニングするユーザーおよびグループにディレクトリ・ツリー内で一意の識別名(DN)を作成して割り当てる方法をお薦めします。

たとえば、Oracle WebCenter Portalエンタープライズ・デプロイメント・ドメインをインストールおよび構成する場合は、weblogic_wcpというユーザーとWCPAdministratorsという管理グループを作成します。

ドメイン・コネクタ・ユーザーについて

LDAPディレクトリで個別のドメイン・コネクタ・ユーザー(たとえばwcpLDAP)を作成することをお薦めします。このユーザーを使用して、ドメインがユーザー認証の目的でLDAPディレクトリに接続できます。このユーザーは管理ユーザー以外にすることをお薦めします。

標準的なOracle Identity and Access Managementデプロイメントでは、このユーザーはsystemidsコンテナで作成します。このコンテナは、通常ユーザーには表示されないシステム・ユーザーに使用されます。このユーザーをsystemidsコンテナに配置することで、Oracle Identity Governanceを所有する顧客がこのユーザーをリコンサイルしないようにします。

集中管理型LDAPディレクトリへのユーザーの追加について

集中LDAPディレクトリをエンタープライズ・ドメインのオーセンティケータとして構成した後は、すべての新規ユーザーをデフォルトのWebLogic Serverオーセンティケータではなく新しいオーセンティケータに追加する必要があります。

集中LDAPディレクトリに新規ユーザーを追加する際、WebLogicリモート・コンソールは使用できません。かわりに、ldapbrowserやJXplorerなどの適切なLDAP変更ツールを使用する必要があります。

複数のオーセンティケータを使用している場合(エンタープライズ・デプロイメントの要件)、ログインや認証は実行できますが、ロール取得は実行できません。ロールは、最初のオーセンティケータからのみ取得できます。他のオーセンティケータを使用してロールを取得する場合は、ドメインの仮想化を有効にする必要があります。

仮想化を有効にするには:

  1. Fusion Middleware Controlに移動して、管理資格証明を使用してログインします。

    https://ADMINVHN:9002/em

  2. 「WebLogicドメイン」→「セキュリティ」→「セキュリティ・プロバイダ構成」に移動します。

  3. 「セキュリティ・ストア・プロバイダ」を開きます。

  4. 「アイデンティティ・ストア・プロバイダ」を開きます。

  5. 「構成」をクリックします。

  6. カスタム・プロパティを追加します。

  7. 次のプロパティを設定します。

    • virtualize (値true)

    • optimize_search (値true)

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

  9. もう一度「OK」をクリックすると、変更が確定します。

  10. 管理サーバーとすべての管理対象サーバーを再起動します。

仮想化プロパティの詳細は、『Oracle Platform Security Servicesによるアプリケーションの保護』のOPSSシステムおよび構成プロパティに関する項を参照してください。

Oracle WebCenter Portalの製品固有のロールとグループについて

Oracle Fusion Middleware製品ごとに、管理および監視のために事前定義された独自のロールおよびグループが実装されます。

その結果、ドメインを拡張して他の製品を追加するときに、これらの製品固有のロールをWCPAdministratorsグループに追加できます。ロールがWCPAdministratorsグループに追加されると、各製品管理者ユーザーは管理タスクを実行するための同じ権限セットを使用してドメインを管理できます。

WCPAdministratorsグループに他のロールを追加する手順については、「エンタープライズ・デプロイメントの共通の構成および管理タスク」を参照してください。

このガイドで使用するサンプル・ユーザーとサンプル・グループ

このガイドで使用するサンプルでは、下に示すDNを持つ次の管理ユーザーおよび管理グループをプロビジョニングすることを想定しています。

  • 管理ユーザーDN:

    cn=weblogic_wcp,cn=users,dc=example,dc=com

  • 管理グループDN:

    cn=WCPAdministrators,cn=groups,dc=example,dc=com
  • 製品固有のLDAPコネクタ・ユーザー:
    cn=wcpLDAP,cn=systemids,dc=example,dc=com
    これは、WebLogic管理対象サーバーをLDAP認証プロバイダに接続するときに使用するユーザーです。このユーザーには、ディレクトリに対する読取り権限および書込み権限が必要です。
    cn=users,dc=example,dc=com
cn=groups,dc=example,dc=com

新しい認証プロバイダの作成と新しいユーザーおよびグループのプロビジョニングの前提条件

認証プロバイダの作成とユーザーおよびグループのプロビジョニングに必要な前提条件をすべて実行します。関連するバックアップ・ファイルをバックアップし、認証プロバイダを有効にします。

構成のバックアップ

新しいLDAP認証プロバイダを作成する前に、関連する構成ファイルをバックアップする必要があります。

$ASERVER_HOME/config/config.xml
$ASERVER_HOME/config/fmwconfig/jps-config.xml
$ASERVER_HOME/config/fmwconfig/system-jazn-data.xml

さらに、次のディレクトリにある管理サーバーのboot.propertiesファイルをバックアップする必要があります。 

$ASERVER_HOME/servers/AdminServer/security

LDAPディレクトリでのドメイン・コネクタ・ユーザーのプロビジョニング

この例では、集中管理型LDAPディレクトリにwcpLDAPというユーザーを作成する方法を示します。

LDAPプロバイダでユーザーをプロビジョニングするには:

  1. 次に示す内容を指定してdomain_user.ldifという名前のLDIFファイルを作成し、保存します。 

    dn: cn=wcpLDAP,cn=systemids,dc=example,dc=com
changetype: add
orclsamaccountname: wcpLDAP
userpassword: password
objectclass: top
objectclass: person
objectclass: organizationalPerson
objectclass: inetorgperson
objectclass: orcluser
objectclass: orcluserV2
mail: wcpLDAP@example.com
givenname: wcpLDAP
sn: wcpLDAP
cn: wcpLDAP
uid: wcpLDAP

  2. LDAPディレクトリでユーザーをプロビジョニングします。

    たとえば、Oracle Unified Directory LDAPプロバイダの場合は次のように記述します。

    OUD_INSTANCE_HOME/bin/ldapmodify -a \
                                 -h idstore.example.com
                                 -D "cn=oudadmin" \
                                 -w password \
                                 -p 1389 \
                                 -f domain_user.ldif

    Oracle Internet Directoryの場合:

    OID_ORACLE_HOME/bin/ldapadd -h idstore.example.com \
                             -p 3060 \
                             -D cn="orcladmin" \
                             -w password \
                             -c \
                             -v \
                             -f domain_user.ldif

新しい認証プロバイダの作成

新しいLDAPベースの認証プロバイダを構成するには:

  1. WebLogicリモート・コンソールにログインします。

  2. 「ツリーの編集」をクリックします。

  3. 左側のナビゲーション・バーで、「セキュリティ」→「レルム」→「myrealm」→「認証プロバイダ」をクリックします。

    ノート:

    このレルムに対してDefaultAuthenticatorプロバイダが構成されています。これは、デフォルトのWebLogic Server認証プロバイダです。

  4. 「新規」ボタンをクリックします。

  5. プロバイダの名前を入力します。

    資格証明ストアとして使用する予定のLDAPディレクトリ・サービスに基づいて、次のいずれかの名前を使用します。

    • OUDAuthenticator (Oracle Unified Directoryの場合)

    • OIDAuthenticator (Oracle Internet Directoryの場合)

  6. 「タイプ」ドロップダウン・リストでオーセンティケータ・タイプを選択します。

    資格証明ストアとして使用する予定のLDAPディレクトリ・サービスに基づいて、次のいずれかのタイプを選択します。

    • OracleUnifiedDirectoryAuthenticator (Oracle Unified Directoryの場合)

    • OracleInternetDirectoryAuthenticator (Oracle Internet Directoryの場合)

  7. 新しく作成したオーセンティケータ・プロバイダの「制御フラグ」ドロップダウン・メニューから「SUFFICIENT」を選択します。

    制御フラグをSUFFICIENTに設定すると、そのオーセンティケータがユーザーを正常に認証できる場合はその認証を受け入れ、それ以上のオーセンティケータを起動しません。

    認証に失敗した場合、そのユーザーは、チェーンにある次の順番の認証プロバイダに引き継がれます。以降のすべてのオーセンティケータの制御フラグもSUFFICIENTに設定されていることを確認してください。特にDefaultAuthenticatorをチェックして、その制御フラグがSUFFICIENTに設定されていることを確認します。

  8. 「作成」をクリックします。

  9. 「オーセンティケータ・パラメータ」タブをクリックし、次の表に示すようにLDAPサーバーに固有の詳細を入力します。

    この手順では、必須フィールドのみを説明しています。このページのすべてのフィールドの詳細は、次のリソースを参照してください。

    パラメータ サンプル値 値の説明

    ホスト

    たとえば: idstore.example.com

    LDAPサーバーのサーバーID。

    ポート

    たとえば: 1389

    LDAPサーバーのポート番号。

    プリンシパル

    たとえば: cn=wcpLDAP, cn=systemids,dc=example,dc=com

    LDAPサーバーへの接続に使用されるLDAPユーザーのDN。

    資格証明

    LDAPパスワードを入力します。

    LDAPサーバーへの接続に使用されるパスワード。

    SSLの有効化

    未選択(クリア)

    LDAPサーバーに接続するときにSSLプロトコルを使用するかどうかを指定します。

    ユーザー・ベースDN

    たとえば: cn=users,dc=example,dc=com

    ユーザーが開始時に使用するDNを指定します。

    すべてのユーザーのフィルタ

    (&(uid=*)(objectclass=person))

    すべてのユーザーのフィルタのデフォルトの検索条件のかわりにuid値に基づいてすべてのユーザーを検索します。

    LDAPディレクトリ構造のユーザー・オブジェクト・クラスの「ユーザー名属性」がuid以外のタイプである場合は、「名前指定によるユーザー・フィルタ」フィールドでそのタイプを変更します。

    たとえば、「ユーザー名属性」のタイプがcnである場合は、このフィールドを次のように設定する必要があります。 

    (&(cn=*)(objectclass=person)))

    名前指定によるユーザー・フィルタ

    たとえば:

    (&(uid=%u)(objectclass=person))

    LDAPディレクトリ構造のユーザー・オブジェクト・クラスの「ユーザー名属性」がuid以外のタイプである場合は、「名前指定によるユーザー・フィルタ」の設定で、そのタイプを変更します。

    たとえば、「ユーザー名属性」のタイプがcnである場合は、このフィールドを次のように設定する必要があります。

    (&(cn=%u)(objectclass=person)))

    ユーザー名属性

    たとえば: uid

    グループの名前を指定するLDAPユーザー・オブジェクトの属性。

    取得したユーザー名をプリンシパルとして使用する

    チェック・ボックスを選択

    オンにする必要があります。

    グループ・ベースDN

    たとえば: cn=groups,dc=example,dc=com

    グループ・ノードを指すDNを指定します。

    GUID属性

    entryuuid

    OUDにOracleUnifiedDirectoryAuthenticatorが使用される場合、この値にはentryuuidが事前に移入されます。認証プロバイダとしてOracle Unified Directoryを使用している場合はこの値を入力します。

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

  11. ショッピング・カートの変更をコミットします。

  12. 「セキュリティ」→「レルム」→「myrealm」の下の「オーセンティケータ・プロバイダ」に移動します。

  13. 作成したオーセンティケータ・プロバイダを確認し、最初の位置まで上に移動します。

  14. 「認証プロバイダ」画面で、DefaultAuthenticatorをクリックします。

  15. 「制御フラグ」ドロップダウンから、SUFFICIENTを選択します。

  16. 「保存」をクリックしてDefaultAuthenticatorの設定を更新します。

  17. ショッピング・カートの変更をコミットします。

  18. 管理サーバーとすべての管理対象サーバーを再起動します。

    管理対象サーバーを停止するには、Fusion Middleware Controlにサインインし、ターゲットのナビゲータで管理対象サーバーを選択して、ツールバーで「停止」をクリックします。

    ノード・マネージャを使用して管理サーバーを停止および起動するには:

    1. WLSTを起動します。
      export WLST_PROPERTIES="
-Dweblogic.security.TrustKeyStore=CustomTrust 
-Dweblogic.security.CustomTrustKeyStoreFileName=/u01/oracle/config/keystores/appTrustKeyStore.pkcs12 
-Dweblogic.security.CustomTrustKeyStorePassPhrase=password"
cd $ORACLE_COMMON_HOME/common/bin
./wlst.sh

    2. 構成ウィザードでドメインを作成したときに定義した、次のノード・マネージャ資格証明を使用してノード・マネージャに接続します:

      wls:/offline>nmConnect('nodemanager_username','nodemanager_password',
            'ADMINVHN','5556','domain_name',
            'ASERVER_HOME','SSL')

    3. 管理サーバーを停止します。

      nmKill('AdminServer')

    4. 管理サーバーを起動します。

      nmStart('AdminServer')

    5. WLSTを終了します。

      exit()

      管理対象サーバーを起動するには、Fusion Middleware Controlにログインし、管理対象サーバーを選択して、ツールバーで「起動」をクリックします。

      ノート:

      中央のLDAPユーザー・メールを使用してただちにシステムにログインする予定の場合は、新しいエンタープライズ・デプロイメント管理グループに管理ロールを割り当てるまで、再起動をスキップすることができます。詳細は、「新しい管理グループへの管理ロールの追加」を参照してください。

  19. 再起動後に、次のログ・ファイルの内容を確認します。

    ASERVER_HOME/servers/AdminServer/logs/AdminServer.log

    LDAP接続エラーが発生していないことを確認します。たとえば、次のようなエラーを探します。

    The LDAP authentication provider named "OUDAuthenticator" failed to make connection to ldap server at ...

    ログ・ファイルでこのようなエラーが見つかった場合は、認可プロバイダ接続の詳細をチェックして、それらが適切であることを確認し、管理サーバーの保存と再起動をもう一度試みます。

  20. 再起動後、LDAP接続エラーがログ・ファイルに記述されていないことを確認し、LDAPプロバイダ内に存在するユーザーとグループの参照を試みます。

    1. リモート・コンソールで、セキュリティ・ツリーに移動します。

    2. 「レルム」→「myrealm」→「認証プロバイダ」に移動します。

    3. 新しい認証プロバイダを開きます。

    4. 「ユーザー」をクリックし、次に「グループ」をクリックします。

      LDAPプロバイダ構造内に存在するすべてのユーザーおよびグループを表示できるようになります。

エンタープライズ・デプロイメント管理ユーザーおよび管理グループのプロビジョニング

この例では、weblogic_wcpというユーザーとWCPAdministratorsというグループを作成する方法を示します。

LDAPプロバイダで管理ユーザーおよび管理グループをプロビジョニングするには:

  1. 次に示す内容を指定してadmin_user.ldifという名前のLDIFファイルを作成し、保存します。 

    dn: cn=weblogic_wcp,cn=users,dc=example,dc=com
changetype: add
orclsamaccountname: weblogic_wcp
userpassword: password
objectclass: top
objectclass: person
objectclass: organizationalPerson
objectclass: inetorgperson
objectclass: orcluser
objectclass: orcluserV2
mail: weblogic_wcp@example.com
givenname: weblogic_wcp
sn: weblogic_wcp
cn: weblogic_wcp
uid: weblogic_wcp

  2. LDAPディレクトリでユーザーをプロビジョニングします。

    たとえば、Oracle Unified Directory LDAPプロバイダの場合は次のように記述します。

    OUD_INSTANCE_HOME/bin/ldapmodify -a \
                                 -h idstore.example.com
                                 -D "cn=oudadmin" \
                                 -w password \
                                 -p 1389 \
                                 -f admin_user.ldif

    Oracle Internet Directoryの場合:

    OID_ORACLE_HOME/bin/ldapadd -h idstore.example.com \
                             -p 3060 \
                             -D cn="orcladmin" \
                             -w password \
                             -c \
                             -v \
                             -f admin_user.ldif

  3. 次に示す内容を指定してadmin_group.ldifという名前のLDIFファイルを作成し、保存します。 

    dn: cn=WCPAdministrators,cn=Groups,dc=example,dc=com
changetype: add
objectclass: top
objectclass: groupOfUniqueNames
objectclass: orclGroup
uniquemember: cn=weblogic_wcp,cn=users,dc=example,dc=com
cn: WCPAdministrators
displayname: WCPAdministrators
description: Administrators Group for the Oracle WebCenter Portal Domain

  4. LDAPディレクトリでグループをプロビジョニングします。

    Oracle Unified Directoryの場合:

    OUD_INSTANCE_HOME/bin/ldapmodify -a \
                                 -D "cn=oudadmin" \
                                 -h oudhost.example.com \
                                 -w password \
                                 -p 1380 \
                                 -f admin_group.ldif

    Oracle Internet Directoryの場合:

    OID_ORACLE_HOME/bin/ldapadd -h oidhost.example.com \
                            -p 3060 \
                            -D cn="orcladmin" \
                            -w password \
                            -c \
                            -v \
                            -f admin_group.ldif

  5. 変更が正常に行われたことを確認します。

    1. リモート・コンソールで、セキュリティ・ツリーに移動します。

    2. 「レルム」→「myrealm」→「認証プロバイダ」に移動します。

    3. 新しい「認証プロバイダ」を開きます。

    4. 「ユーザー」をクリックし、プロビジョニングした管理者ユーザーがリストされているかどうかを確認します。

    5. 「グループ」をクリックし、プロビジョニングした管理者グループがリストされているかどうかを確認します。

新しい管理グループへの管理ロールの追加

Oracle Internet Directoryにユーザーおよびグループを追加したら、WebLogicドメインのセキュリティ・レルム内でそのグループに管理ロールを割り当てる必要があります。これにより、このグループに属するすべてのユーザーがそのドメインの管理者になることができます。

管理ロールを新しいエンタープライズ・デプロイメント管理グループに割り当てるには:

  1. 構成ウィザードで指定した管理資格証明を使用してWebLogicリモート・コンソールにログインします。

    新しい認証プロバイダ用に作成して提供した管理ユーザーの資格証明は使用しないでください。

  2. 「セキュリティ・データ・ツリー」をクリックします。
  3. 「レルム」→「myrealm」→「ロール・マッパー」→「XACMLRoleMapper」→「グローバル」→「ロール」をクリックします。
  4. 「管理」ロールをクリックします。
  5. 「条件の追加」をクリックします。
  6. 「述部リスト」ドロップダウン・メニューで「グループ」を選択し、「次へ」をクリックします。
  7. 「グループ引数名」フィールドにWCPAdministratorsと入力して、「追加」をクリックします。

    WCPAdministratorsが引数のリスト・ボックスに追加されます。

  8. 「保存」をクリックして、WCPAdministratorsグループへの「管理」ロールの追加を終了します。
  9. 新しいweblogic_wcpユーザー資格証明を使用して、WebLogicリモート・コンソールおよびFusion Middleware Controlにログインして、変更が行われていることを確認します。

    新しい認証プロバイダでプロビジョニングした新しい管理ユーザーの資格証明を使用してOracle WebLogicリモート・コンソールとFusion Middleware Controlにログインできる場合は、プロバイダは正常に構成されています。

このガイドで使用するサンプル・ユーザーとサンプル・グループ

このガイドで使用するサンプルでは、下に示すDNを持つ次の管理ユーザーおよび管理グループをプロビジョニングすることを想定しています。

  • 管理ユーザーDN:

    cn=weblogic_wcp,cn=users,dc=example,dc=com

  • 管理グループDN:

    cn=WCPAdministrators,cn=groups,dc=example,dc=com
  • 製品固有のLDAPコネクタ・ユーザー:
    cn=wcpLDAP,cn=systemids,dc=example,dc=com
    これは、WebLogic管理対象サーバーをLDAP認証プロバイダに接続するときに使用するユーザーです。このユーザーには、ディレクトリに対する読取り権限および書込み権限が必要です。
    cn=users,dc=example,dc=com
cn=groups,dc=example,dc=com

Administratorsグループへのwsm-pmロールの追加

新しいLDAPベースの認可プロバイダを構成して管理サーバーを再起動したら、エンタープライズ・デプロイメント管理LDAPグループ(WCPAdministrators)をメンバーとしてwsm-pmアプリケーション・ストライプのpolicy.Updaterロールに追加します。

  1. 管理者のアカウントを使用してFusion Middleware Controlにサインインします。たとえば: weblogic_wcp
  2. 「WebLogicドメイン」メニューから、「セキュリティ」→「アプリケーション・ロール」を選択します。
  3. 「アプリケーション・ストライプ」ドロップダウン・メニューからwsm-pmアプリケーション・ストライプを選択します。
  4. ロール名テキスト・ボックスの隣にある三角形のアイコンをクリックし、wsm-pmアプリケーション・ストライプのロール名をすべて検索します。
  5. 編集するpolicy.Updater の行を選択します。
  6. アプリケーション・ロールの「編集」アイコンをクリックして、ロールを編集します。
  7. 「アプリケーション・ロールの編集」ページで、アプリケーション・ロールの「追加」アイコンをクリックします。
  8. 「プリンシパルの追加」ダイアログ・ボックスで、「タイプ」ドロップダウン・メニューから「グループ」を選択します。
  9. エンタープライズ・デプロイメントの管理者グループを検索するには、「プリンシパル名」の「次で始まる」フィールドにグループ名WCPAdministratorsを入力し、右矢印をクリックして検索を開始します。
  10. 検索結果で適切な管理者グループを選択し、「OK」をクリックします。
  11. 「アプリケーション・ロールの編集」ページで、「OK」をクリックします。

構成のバックアップ

ベスト・プラクティスとして、ドメインの拡張が正常に完了した後や別の論理ポイントでバックアップを作成することをお薦めします。ここまでのインストールが正常に行われたことを確認したら、バックアップを作成します。これは、後のステップで問題が発生した場合に即座にリストアするための迅速なバックアップになります。

バックアップ先はローカル・ディスクです。エンタープライズ・デプロイメント設定が完了すると、このバックアップは破棄できます。エンタープライズ・デプロイメント設定が完了したら、バックアップとリカバリの通常のデプロイメント固有プロセスを開始できます。

構成をバックアップする方法の詳細は、「エンタープライズ・デプロイメントのバックアップとリカバリの実行」を参照してください。

管理サーバーの手動フェイルオーバーの確認

ドメインを構成したら、「管理サーバーの手動フェイルオーバーの検証」のステップに従ってフェイルオーバーをテストします。