インフラストラクチャの設定

2 インフラストラクチャの設定

この章では、ライフサイクル管理機能の使用を開始する前に満たす必要のあるインフラストラクチャの要件について説明します。この章は、基本的にインフラストラクチャを作成する管理者または設計者向けです。この章で説明している要件を実行する必要があるのは一度のみです。

この章の内容は次のとおりです。

インフラストラクチャの設定の開始

この章では、インフラストラクチャの設定ステップを含むすべてのステップの概要を説明し、開始できるようにします。この項を、パッチ適用およびプロビジョニングを含むすべてのライフサイクル管理タスクを実行するためのインフラストラクチャを正常に設定するために、実行する必要のある一連のアクションを理解するためのドキュメント・マップとみなしてください。

図2-1は、インフラストラクチャを設定するために実行する一連のステップを図解したものです。

図2-1 インフラストラクチャ設定のワークフロー

各項の詳細は、表2-1のステップに記載されている参照先リンクをクリックしてください。

表2-1 インフラストラクチャの設定の開始

ステップ	説明	参照リンク
ステップ1	ソフトウェア・ライブラリの設定	Oracleソフトウェア・ライブラリの設定
ステップ2	資格証明の設定	資格証明の設定
ステップ3	Enterprise Managerユーザー・アカウントの作成	Enterprise Managerユーザー・アカウントの作成
ステップ4	My Oracle Support資格証明の設定	(オプション) My Oracle Supportの設定
ステップ5	追加/付加価値の設定(オプション) 自己更新の構成	(オプション)自己更新の構成
ステップ6	追加/付加価値の設定(オプション) 電子メール通知の設定	(オプション)電子メール通知の設定

ノート:

OMSが必要なレベルまで適切にパッチ適用済であることを確認してください。プロビジョニングとパッチの機能を使用するためにEnterprise Manager Cloud Control Management Server (OMS)に適用する必要があるパッチの詳細は、My Oracle Supportのノート427577.1を参照してください。

Oracleソフトウェア・ライブラリの設定

Oracleソフトウェア・ライブラリ(ソフトウェア・ライブラリ)は、Oracle Enterprise Manager Cloud Control(Cloud Control)が提供するコア機能の1つです。技術的には、ソフトウェア・パッチ、仮想アプライアンス・イメージ、参照ゴールド・イメージ、アプリケーション・ソフトウェアおよび関連するディレクティブのスクリプトなど、認証済ソフトウェア・エンティティを格納する記憶域の場所です。これらを格納する以外に、ソフトウェア・エンティティのバージョン、成熟度レベルおよび状態を管理することもできます。

Cloud Controlで「ソフトウェア・ライブラリ」コンソール・ページにアクセスするには、「エンタープライズ」メニューから「プロビジョニングとパッチ適用」を選択し、「ソフトウェア・ライブラリ」をクリックします。図2-2に示すように、「ソフトウェア・ライブラリ」ホームページには、Oracle所有のフォルダ(ロック記号が付いている)とユーザー所有のフォルダの2種類があります。

図2-2 「ソフトウェア・ライブラリ」コンソール

エンティティを作成または管理するためにソフトウェア・ライブラリの使用を開始するには、ソフトウェア・ライブラリの記憶域の場所が構成されている必要があります。システム管理者が、ソフトウェア・ライブラリの記憶域の場所を構成し、ソフトウェア・ライブラリを使用できるようにします。

Cloud Controlでは次のタイプの記憶域の場所が提供されます。

アップロード・ファイルの場所: エンティティの作成または更新の一環としてソフトウェア・ライブラリによってアップロードされたファイルを格納するために構成された場所です。アップロード・ファイルの場所は、2つの記憶域オプションをサポートしています。
1. OMS共有ファイル・システム
2. OMSエージェント・ファイル・システム
参照先ファイルの場所: ソフトウェアのバイナリやスクリプトを保護するために組織の既存のITインフラストラクチャ(ファイル・サーバー、Webサーバーまたは記憶域システムなど)を活用できる場所です。このような場所を使用すると、エンティティはソフトウェア・ライブラリ記憶域にファイルを明示的にアップロードしなくてもそのファイルを参照できます。参照先ファイルの場所は、3つの記憶域オプションをサポートしています。
1. HTTPの場所
2. NFSの場所
3. 管理エージェントの場所

管理コンソールから記憶域の場所を構成できます。これを行うには、Cloud Controlで、「設定」メニューから「プロビジョニングとパッチ適用」、「ソフトウェア・ライブラリ」の順に選択します。図2-3に示すように、「ソフトウェア・ライブラリ: 管理」ページが表示されます。

図2-3 ソフトウェア・ライブラリの管理

ソフトウェア・ライブラリを構成する方法の詳細は、『Oracle Enterprise Manager Cloud Control管理者ガイド』の「ソフトウェア・ライブラリの構成」を参照してください。

ノート:

Windowsホストでソフトウェア・ライブラリ・エンティティの実行(たとえば、ディレクティブ・スクリプト)を含むこのプロシージャを実行するには、(Windowsユーザー)に次の権限が付与されている必要があります。

オペレーティングシステムの一部として機能
プロセスのメモリクォータの増加
バッチ・ジョブとしてログオンする権限
プロセスレベルトークンの置き換え

そうではない場合、このプロシージャのディレクティブ・ステップの実行は失敗することがあります。

資格証明の設定

Enterprise Manager Cloud Controlでプロビジョニングおよびパッチ適用タスクを実行するには、オペレーティング・システムの通常ユーザー・アカウント(Oracle)用の名前付き資格証明と、特権ユーザー・アカウント(root)用の名前付き資格証明を設定する必要があります。

名前付き資格証明は、システムでのユーザーの認証情報を指定します。名前付き資格証明はオペレーティング・システムのログイン資格証明のようなユーザー名およびパスワードのペアで指定でき、Oracleホームの所有者の資格証明は主にジョブの実行、パッチ適用およびその他の管理タスクなどの操作を実行する場合に使用されます。

Enterprise Manager Cloud Controlを使用すると、システム資格証明を通常ユーザー(Oracle)の名前付き資格証明として登録できます。または、root権限がある場合には、rootアカウントの詳細を特権ユーザーの名前付き資格証明として登録することもできます。一度名前付き資格証明として登録されると、必要であればそれらを優先資格証明として保存できます。

資格証明を保存する利点は、次のとおりです。

資格証明の詳細をすべてのユーザーに公開する必要がありません。
それぞれのOracleホームまたはホスト・マシンに対し、ユーザー名およびパスワードを毎回指定する必要はなく、かわりに、保存された資格証明を使用する名前付きプロファイルを選択できるので、時間と手間が省けます。

名前付き資格証明の詳細は、『Oracle Enterprise Manager Cloud Controlセキュリティ・ガイド』を参照してください。

デプロイメント・プロシージャのほとんどのステップは通常ユーザーとして実行することができますが、一部のステップには特別な権限および特権が必要であり、Oracleアカウントの資格証明またはrootアカウントの資格証明では十分でない場合があります。このような状況では、認証ユーティリティを使用して、別のユーザーの権限でデプロイメント・プロシージャ内の一部のステップを実行します。Enterprise Manager Cloud Controlでサポートされる認証ユーティリティはSUDOおよびPowerBrokerです。このサポートはEnterprise Manager Cloud Controlで使用可能な権限委任メカニズムを使用して提供されます。

権限委任および権限委任がサポートする認証ツールの概念の概要は、『Oracle Enterprise Manager Cloud Controlセキュリティ・ガイド』を参照してください。

表2-2は、資格証明に関するユースケースをリストし、資格証明を設定してプロビジョニングを行うために実行するステップについて説明しています。ご自分の状況に最もよく一致するユースケースを選択して、提案されている手順に従います。

表2-2 Enterprise Manager資格証明の設定

ユース・ケース	実行するステップ
直接アクセスがないか、通常のオペレーティング・システム・ユーザー・アカウント(Oracle)に必要な資格証明がない場合、または直接アクセスがないか、特権アカウント(root)に必要な資格証明がない場合。	次の手順を実行します。次のように権限委任を設定します。 SUDOまたはPowerBrokerのいずれかに対する権限委任(PDP)テンプレートを作成します。これを行うには、Oracle Enterprise Manager Cloud Controlセキュリティ・ガイドの権限委任の作成に必要な権限を参照してください。作成したテンプレートをターゲット・ホストの管理エージェントに適用します。 SUDOまたはPowerBrokerとして実行する権限がある通常のオペレーティング・システム・ユーザー・アカウント(Oracle)の名前付き資格証明を作成します。詳細は、Oracle Enterprise Manager Cloud Controlセキュリティ・ガイドの名前付き資格証明の作成を参照してください。または SUDOまたはPowerBrokerとして実行する権限がある特権ユーザー・アカウント(root)の名前付き資格証明を作成します。詳細は、Oracle Enterprise Manager Cloud Controlセキュリティ・ガイドの特権資格証明の作成を参照してください。オペレーティング・システムの通常アカウントに対する名前付き資格証明または特権ユーザー・アカウントに対する名前付き資格証明を優先資格証明として保存します。これを行うには、『Oracle Enterprise Manager Cloud Controlセキュリティ・ガイド』.の「ホストおよびOracleホームの優先資格証明の保存」および「My Oracleサポートにアクセスするための優先資格証明の保存」を参照してください。
直接アクセスがあるか、通常のオペレーティング・システム・ユーザー・アカウント(Oracle)に必要な資格証明がある場合、または直接アクセスがあるか、特権アカウント(root)に必要な資格証明がある場合。	次の手順を実行します。通常のオペレーティング・システムユーザー・アカウント(Oracle)の名前付き資格証明を作成します。詳細は、Oracle Enterprise Manager Cloud Controlセキュリティ・ガイドの名前付き資格証明の作成を参照してください。または特権ユーザー・アカウント(root)資格証明の名前付き資格証明を作成します。詳細は、Oracle Enterprise Manager Cloud Controlセキュリティ・ガイドの特権資格証明の作成を参照してくださいオペレーティング・システムの通常アカウントに対する名前付き資格証明または特権ユーザー・アカウントに対する名前付き資格証明を優先資格証明として保存します。これを行うには、『Oracle Enterprise Manager Cloud Controlセキュリティ・ガイド』.の「ホストおよびOracleホームの優先資格証明の保存」および「My Oracleサポートにアクセスするための優先資格証明の保存」を参照してください。

ユース・ケース

実行するステップ

直接アクセスがないか、通常のオペレーティング・システム・ユーザー・アカウント(Oracle)に必要な資格証明がない場合、または直接アクセスがないか、特権アカウント(root)に必要な資格証明がない場合。

次の手順を実行します。

次のように権限委任を設定します。
1. SUDOまたはPowerBrokerのいずれかに対する権限委任(PDP)テンプレートを作成します。これを行うには、Oracle Enterprise Manager Cloud Controlセキュリティ・ガイドの権限委任の作成に必要な権限を参照してください。
2. 作成したテンプレートをターゲット・ホストの管理エージェントに適用します。
SUDOまたはPowerBrokerとして実行する権限がある通常のオペレーティング・システム・ユーザー・アカウント(Oracle)の名前付き資格証明を作成します。詳細は、Oracle Enterprise Manager Cloud Controlセキュリティ・ガイドの名前付き資格証明の作成を参照してください。
または
SUDOまたはPowerBrokerとして実行する権限がある特権ユーザー・アカウント(root)の名前付き資格証明を作成します。詳細は、Oracle Enterprise Manager Cloud Controlセキュリティ・ガイドの特権資格証明の作成を参照してください。
オペレーティング・システムの通常アカウントに対する名前付き資格証明または特権ユーザー・アカウントに対する名前付き資格証明を優先資格証明として保存します。これを行うには、『Oracle Enterprise Manager Cloud Controlセキュリティ・ガイド』.の「ホストおよびOracleホームの優先資格証明の保存」および「My Oracleサポートにアクセスするための優先資格証明の保存」を参照してください。

直接アクセスがあるか、通常のオペレーティング・システム・ユーザー・アカウント(Oracle)に必要な資格証明がある場合、または直接アクセスがあるか、特権アカウント(root)に必要な資格証明がある場合。

次の手順を実行します。

通常のオペレーティング・システムユーザー・アカウント(Oracle)の名前付き資格証明を作成します。詳細は、Oracle Enterprise Manager Cloud Controlセキュリティ・ガイドの名前付き資格証明の作成を参照してください。
または
特権ユーザー・アカウント(root)資格証明の名前付き資格証明を作成します。詳細は、Oracle Enterprise Manager Cloud Controlセキュリティ・ガイドの特権資格証明の作成を参照してください
オペレーティング・システムの通常アカウントに対する名前付き資格証明または特権ユーザー・アカウントに対する名前付き資格証明を優先資格証明として保存します。これを行うには、『Oracle Enterprise Manager Cloud Controlセキュリティ・ガイド』.の「ホストおよびOracleホームの優先資格証明の保存」および「My Oracleサポートにアクセスするための優先資格証明の保存」を参照してください。

Enterprise Managerユーザー・アカウントの作成

ここでは、以下の項目について説明します。

ユーザー・アカウントの概要

Cloud Controlから、新規のEnterprise Manager管理者アカウントを作成して管理できます。管理者アカウントには、それぞれ独自のログイン資格証明や、アカウントに割り当てられた一連のロールおよび権限が含まれています。前述のロールを管理する主要な3つの管理者アカウント(デザイナ、オペレータおよびスーパー管理者)があります。

アクセス権に基づき、ユーザーは次のように分類できます。

スーパー管理者
デザイナ(EM_ALL_DESIGNER)
オペレータ(EM_ALL_OPERATOR)

スーパー管理者

スーパー管理者はすべてのターゲットに対する完全なアクセス権限のある強力なCloud Control管理者です。Cloud Control環境でアカウントの作成および管理を担当します。たとえば、スーパー管理者はデザイナおよびオペレータ・ロールを作成し、そのロールを企業内の様々なユーザーおよびグループに付与します。

デザイナ

デザイナはデプロイメント・プロシージャおよびソフトウェア・ライブラリでの権限が高められた管理者のリーダーです。Cloud Control以降では、デザイナはロック・ダウン機能を使用してデプロイメント・プロシージャ・テンプレートを作成し、これらのテンプレートを保存して、標準化を実行し、整合性を保つことができます。オペレータの権限はこれらのテンプレートに付与されて、オペレータとしてログインした管理者がこれらのテンプレートを起動し、デプロイメント・プロシージャを正常に実行できるようにします。これを行うことで、プロシージャにエラーが発生しにくくなり、整合性が高まります。ロック・ダウンを使用したデプロイメント・プロシージャの保存の詳細は、「ロック・ダウンを使用したデプロイメント・プロシージャの保存と起動」を参照してください。

デザイナは、次のようなすべての設計時アクティビティの実行を担当します。

ソフトウェア・ライブラリでのプロビジョニング・プロファイルの作成。
コンポーネント、ディレクティブおよびイメージの作成、Oracle Software Libraryへの格納。
組織の必要性に応じたデフォルトのデプロイメント・プロシージャのカスタマイズ。
パッチ計画とパッチ・テンプレートの作成。

事前定義済のデザイナ用のOracleロールはEM_ALL_DESIGNERで、このロールは次にプロビジョニング・タスク用にEM_PROVISIONING_DESIGNERを、パッチ適用タスク用にEM_PATCH_DESIGNERを、特別に設定できる詳細なロールを含みます。デザイナに付与される権限の詳細は、「ロールと権限の管理者への付与」を参照してください。

オペレータ

オペレータはデプロイメント・プロシージャおよびソフトウェア・ライブラリでの権限が制限された管理者です。通常、オペレータはデプロイメント・プロシージャを表示および発行できます。また、デザイナ・ユーザーがオペレータにターゲットまたはエンティティに対する必要な権限を付与することもできます。

オペレータは、デザイナが作成したインフラストラクチャを使用して、次のような実行時アクティビティを実行します。

プロシージャのプロビジョニングのためのソフトウェア・ライブラリにあるプロビジョニング・プロファイルへのアクセス。
選択したターゲットにソフトウェアをプロビジョニングするためのソフトウェア・デプロイメントの起動。
パッチ計画とパッチ・テンプレートを使用したソフトウェア・デプロイメントのパッチ適用。

事前定義済のオペレータ用のOracleロールはEM_ALL_OPERATORで、このロールは次にプロビジョニング・タスク用にEM_PROVISIONING_OPERATORを、パッチ適用タスク用にEM_PATCH_OPERATORを、特別に設定できる詳細なロールを含みます。オペレータに付与される権限の詳細は、「ロールと権限の管理者への付与」を参照してください。

ノート:

デザイナは設計時および実行時アクティビティの両方を選択する選択ができますが、オペレータは実行時アクティビティのみを実行できます。

デザイナ・ユーザー・アカウントの作成

デザイナ・ユーザー・アカウントを作成するには、次のステップに従います。

Cloud Controlで、「設定」メニューから「セキュリティ」、「管理者」の順に選択します。
「管理者」ページで「作成」をクリックします。
管理者の作成ウィザードで次を実行します。
1. 「プロパティ」ページで、名前に「デザイナ」を指定し、パスワードを入力します。他のフィールドは空白のままにして、「次へ」をクリックします。
2. 「ロール」ページでEM_ALL_DESIGNERを選択して、「次へ」をクリックします。
  
  ノート:
  
  または、デザイナのアクセスをプロビジョニングまたはパッチ適用ドメインのいずれかに制限できます。明示的にプロビジョニングの権限を付与するために、EM_PROVISION_DESIGNERロールを選択します。同様に、明示的にパッチ適用の権限をデザイナに付与するために、EM_PATCH_DESIGNERロールを選択します。
3. 「ターゲット権限」ページで、デザイナ・ユーザー・アカウントに付与する必要のあるターゲット権限を選択します。デザイナ・ロールを持つ管理者の使用可能なターゲット権限の詳細は、「デプロイメント・プロシージャで管理者にロールおよび権限を付与する」を参照してください。
4. 「リソース権限」ページで、各リソース・タイプに対し明示的に付与される権限を選択します。
5. 「確認」画面で、このユーザー・アカウントに対し入力した情報を確認して、「終了」をクリックします。

オペレータ・ユーザー・アカウントの作成

オペレータ・ユーザー・アカウントを作成するには、次のステップに従います。

Cloud Controlで、「設定」メニューから「セキュリティ」、「管理者」の順に選択します。
「管理者」ページで「作成」をクリックします。
管理者の作成ウィザードで次を実行します。
1. 「プロパティ」ページで、名前に「オペレータ」を指定し、パスワードを入力します。他のフィールドは空白のままにして、「次へ」をクリックします。
2. 「ロール」ページでEM_ALL_OPERATORを選択して、「次へ」をクリックします。
  
  ノート:
  
  または、オペレータのアクセスをプロビジョニングまたはパッチ適用ドメインのいずれかに制限できます。明示的にプロビジョニングの権限を付与するために、EM_PROVISION_OPERATORロールを選択します。同様に、明示的にパッチ適用のデザイナ権限を付与するために、EM_PATCH_OPERATORロールを選択します。
3. 「ターゲット権限」ページで、オペレータ・ユーザー・アカウントに付与する必要のあるターゲット権限を選択します。オペレータ・ロールを持つ管理者の使用可能なターゲット権限の詳細は、「デプロイメント・プロシージャで管理者にロールおよび権限を付与する」を参照してください。
4. 「リソース権限」ページで、各リソース・タイプに対し明示的に付与される権限を選択します。
5. 「確認」画面で、このユーザー・アカウントに対し入力した情報を確認して、「終了」をクリックします。

OCIリソースへのエージェントのデプロイ

Enterprise Managerを使用すると、オンプレミス・データ・センターの組合せで実行しているデータベース・アセットも、Oracle Cloud Infrastructure (OCI)で実行しているデータベース・アセットも、同じユーザー・インタフェースから管理できます。「プラガブル・データベースのプロビジョニング」は、あらゆるプラットフォームでプラガブル・データベースを管理するための統合された操作性を提供するようになりました。OCIのPDBだけでなくオンプレミスのPDBの操作(作成、クローニング、リフレッシュ可能クローン、再配置など)も実行します。

OCIリソースにエージェントをデプロイするための前提条件

開始する前に、次の前提条件を確認してください。これは、Enterprise Managerで検出する前に、OCIで実行する必要があります。

Compute仮想マシンまたはデータベース・システムをプロビジョニングして、ターゲットの検出とモニタリングのために、同じネットワークVCNとサブネットにエージェントをデプロイします。エージェントは、エージェントのデプロイ時のCompute仮想マシンまたはデータベース・システムのプロビジョニングに使用したものと同じSSHキーを使用する必要があります。
1. VCNセキュリティ・リストでポート3872を開いて接続を許可します。
  
  図2-4 セキュリティ・ルールの追加

エージェントのデプロイ先ノードにログインして、ファイアウォール・ポート3872を開きます。

データベース・システムには、次のファイアウォール・ルールを使用します。

sudo iptables -I INPUT -p tcp -m state --state NEW -m tcp -s 10.0.1.0/25 --dport 3872 -m comment --comment "Required foraccess to Agent Listener" -j ACCEPT
sudo iptables -I INPUT -p tcp -m tcp --dport 3872 -j ACCEPT
sudo service iptables save
sudo service iptables reload

RHEL 7.7以降には、次のコマンドを使用します。

firewall-cmd --zone=public --add-port=3872/tcp --permanent
firewall-cmd --reload
iptables-save | grep 3872

Compute VMまたはデータベース・システムのプロビジョニング時に指定したSSHキーでEnterprise Managerの名前付き資格証明を作成します。Enterprise Managerで実行する場合は、「設定」→「セキュリティ」に移動して「名前付き資格証明」をクリックします。
1. 資格証明名: OCI_SSH_Key
2. 資格証明のタイプ: SSH Key Credentials
3. 有効範囲: Global
4. ユーザー名: opc
5. 実行権限: sudo
6. 別名実行: oracle
権限委任を設定します。「設定」→「セキュリティ」→「権限委任」に移動します。インストールしたエージェントを選択して、そのエージェントに「権限委任」が設定されていることを確認します。

図2-5 権限委任設定
単一ノード・デプロイメントの場合は、Enterprise Managerホスト・ファイルにエージェント・ホストIPとホスト名を追加して、エージェント・マシン・ホスト・ファイルでEnterprise Managerの詳細を追加します。

ノート:
このステップは、すべての通信がロードバランサを経由するマルチノード環境では不要です。
1. 次に、単一ノード環境のOMSホストに必要な設定の例を示します。
```
[opc@oms1 ~]$ cat/etc/hosts
10.0.1.3 <oms node 1>
10.0.1.4 <oms node 2>
10.0.1.6 <db host 1>
10.0.1.7 <db host 2>
```
2. 次に、単一ノード環境のCompute VMにデプロイされたエージェントに必要な設定の例を示します。
```
[opc@dbhostt1 ~]$ cat/etc/hosts
10.0.1.6 dbhost1.sample.com dbhost1
192.168.16.18 dbhost1-priv.sample.com dbhost1-priv
10.0.1.8 dbhost1-vip.sample.com dbhost1-vip
10.0.1.7 dbhost2.sample.com  dbhost2
192.168.16.19 dbhost2-priv.sample.com  dbhost2-priv
10.0.1.9 dbhost2-vip.sample.com  dbhost2-vip
10.0.1.3 omsnode1
10.0.1.4 omsnode2
```

Enterprise ManagementのエージェントをOCIリソースにデプロイするには、次のステップを実行します。

グラフィカル・インタフェースを使用してエージェントを追加するには、「設定」→「ターゲットの追加」→「ターゲットの手動追加」→「ホスト・ターゲットの追加」の順に移動します。「ホストにエージェントをインストール」をクリックして、インストール・ディレクトリ、インスタンス・ディレクトリおよび資格証明を入力します。

図2-6 ホスト・ターゲットの追加: インストールの詳細
エージェントのデプロイ後、そのエージェントがEnterprise Managerの「すべてのターゲット」ページに表示されていることを確認します。
前述のステップを完了したら、ターゲット検出を実行して、OCIリソースをEnterprise Managerに統合します。詳細は、『Oracle Enterprise Manager Cloud Control管理者ガイド』のデータベース・ターゲットの検出と追加に関する項を参照してください。

OCIデータベース・ターゲットが検出されると、特定のデータベース操作を管理できるようになります。詳細は、「Enterprise Managerを使用したプラガブル・データベースの管理」を参照してください。

OCI PDBでは、次の管理操作を実行できます。

(オプション) My Oracle Supportの設定

エージェントへのパッチ適用、その他のターゲットへのパッチ適用、MOS関連タスク、および自己更新タスクのためにCloud ControlでMy Oracle Supportに接続するには、確実にプロキシ・サーバーが設定され詳細が登録されている必要があります。これを実行するには、「My Oracle Support用のプロキシ詳細の登録」の手順に従います。

ノート:

Enterprise Manager Cloud Control 12cリリース3 (12.1.0.3)以降、My Oracle Suppotは直接support.oracle.comにアクセスします。これは、このURLへのネットワーク・アクセスを提供するか、My Oracle SupportにアクセスするクライアントからこのURLにプロキシ・アクセスを付与する必要があることを意味します。

(オプション)自己更新の構成

自己更新機能により、Cloud Controlコンポーネントの更新に関する情報を取得できます。「自己更新」ホームページを使用して、新規の更新に関する情報を入手し、更新の確認、ダウンロードおよび適用を行うための共通ワークフローを提供できます。「自己更新」コンソールにより、インストールに適用可能な新しい更新がOracleにより使用可能になると、自動的に通知されます。

プロビジョニングおよびパッチ適用に使用できるソフトウェア・ライブラリ・コンポーネントおよびディレクティブはプロビジョニング・エンティティと呼ばれます。プロビジョニング・バンドルは、データベース・プロビジョニングまたはFMWプロビジョニングなど、特定のプロビジョニングまたはパッチ適用エリアを参照します。これを経由してCloud Controlは顧客に更新を配信します。

ノート:

ユーザーにVIEW_ANY_SELFUPDATE権限があることを確認してください。

Oracleが提供する更新をプロビジョニング・エンティティに適用するには、次のステップに従います。

Cloud Controlで、「設定」メニューから「拡張性」、「自己更新」の順に選択します。
プロビジョニング・バンドルのダウンロードをスケジュールします。自己更新フレームワークが、バンドルを既知の場所にダウンロードします。自己更新の詳細は、『Oracle Enterprise Manager Cloud Control管理者ガイド』を参照してください。
「アクション」メニューで「サブスクライブ」を選択し、プロビジョニング・バンドルをダウンロードできるようになったとき必ず通知を受信するようにします。
更新ホーム・ページで、「プロビジョニング・バンドル」タイプの更新を選択し、「アクション」メニューから「開く」を選択します。
プロビジョニング・バンドルの更新を手動で適用します。選択したプロビジョニング・バンドルの指示に従って、更新を手動で適用します。
更新ホーム・ページで情報を確認し、更新が適用されたことを確認します。

(オプション)電子メール通知の設定

Cloud Controlはデプロイメント・プロシージャを実行するたびに電子メール通知を送信できます。ただし、デフォルトではデプロイメント・プロシージャのこの機能は有効ではありません。電子メール通知を送信するように構成するには、デプロイメント・プロシージャをカスタマイズする必要があります。

デプロイメント・プロシージャのカスタマイズおよび電子メール通知の設定の詳細は、デプロイメント・プロシージャのカスタマイズを参照してください。

(オプション)ルート・コンポーネントの制限付きアクセスの設定

この項では、制限付きアクセスを使用してEnterprise Managerのプロビジョニングやパッチ適用などの特定のライフサイクル管理タスクを実行する方法について説明します。いくつかのルート・コマンドを実行するには、ユーザー(通常は管理エージェント・ユーザー)のルート・アクセスを制限するか、ルート・アクセスを必要とするコマンドを手動で実行する必要があります。

この項の主な内容は次のとおりです:

パッチ適用のルート・コンポーネント

この項の内容は次のとおりです。

パッチ適用のための手動によるルート・コンポーネントのステージング

ルート・コンポーネントは、デフォルトで、(%emd_emstagedir%によって定義される場所で)自動的にターゲット・ホストにステージングされます。ルート・コンポーネントを手動でステージングする前に、次の重要な事項について考慮する必要があります。

リリース更新(RU)またはプラグインのリリースを選択したら、ルート・スクリプト・コンポーネントを一時的な場所にステージングして、事前にステージングしたファイルと同じように操作する必要があります。
バージョン間の変更を確認して、新しいファイルのセットでステージング前の場所を更新します。
RUまたはプラグインは、その更新に付属する最新のファイルでのみ機能する点に注意してください。変更内容を検証して受け入れるか、内部プロセスによって問題が解決されるまでRUまたはプラグインの取込みを延期します。
RUまたはプラグインの更新を受け入れたら、新しいルート・スクリプトとステージング前のファイルに、以前のバージョンに加えていたカスタムの変更を取り込みます。
本番環境で使用するためにルート・スクリプトを事前ステージングして、通常の手動によるステージング・ステップを進めます。

パッチ適用プロセスの開始前に、カスタムの場所でルート・コンポーネントを手動でステージング(事前ステージング)する場合は、次のステップを実行します。

「エンタープライズ」メニューから、「プロビジョニングとパッチ適用」、「ソフトウェア・ライブラリ」の順に選択します。
「パッチ適用とプロビジョニング」、「コンポーネント」の順に移動します。
「ルート・ディスパッチャ」を選択して「表示」をクリックします。
「ステージ」をクリックします。
ホスト(ルート・ディスパッチャをステージングする場所)、およびディスパッチャの場所、つまり、ルート・ディスパッチャのステージング先として指定したホストの場所を指定します。「発行」をクリックして、ルート・ディスパッチャを手動でステージングします。
「パッチ適用とプロビジョニング」、「コンポーネント」の順に移動します。
「rootスクリプト」を選択して「表示」をクリックします。
「ステージ」をクリックします。
ホスト(ルート・コンポーネントをステージングする場所)、およびディスパッチャの場所、つまり、ルート・コンポーネントのステージング先として指定したホストの場所を指定します。「発行」をクリックして、ルート・コンポーネントを手動でステージングします。

ノート:
カスタムの場所でのルート・コンポーネントのステージングを手動で行う前に、ディスパッチャの場所およびroot_dispatcher.shに対する読取りおよび実行権限がユーザーに付与されていることを確認します。
前のステップでステージングしたファイルを解凍します。

ノート:

ルート・コンポーネントを手動でステージングした後、必要なOracleパッチを適用するために作成するパッチ計画にこれを指定する必要があります。作成したパッチ計画の「デプロイ・オプション」ページにアクセスします。「ステージングの場所」セクションで、「ルート・コンポーネントのステージング」に「いいえ(ステージ済)」を選択し、ルート・コンポーネントを手動でステージングしたディスパッチャの場所を指定します。ディスパッチャが共有の場所である場合、「共有のディスパッチャの場所」を選択します。

rootユーザーのアクセス権限の制限

Oracle Databaseおよびミドルウェア・ターゲットにパッチを適用するには、管理エージェント・ユーザーは、rootユーザーとして、perl、root_dispatcher.shおよびidエンティティを実行できる必要があります。これらのエンティティは、パッチを適用するルート・コンポーネントの一部を構成しています。

制限付きのrootアクセス権限を管理エージェント・ユーザーに与え、このユーザーがperl, root_dispatcher.shおよびidエンティティのみをrootユーザーとして実行できるようにするには、/etc/sudoersファイルを編集して次の内容を含めます。

Cmnd_Alias <command_alias> = \
      <agent_home>/sbin/nmosudo DEFAULT_PLUGIN DEFAULT_FUNCTIONALITY DEFAULT_SUBACTION DEFAULT_ACTION perl *, \
      <agent_home>/sbin/nmosudo DEFAULT_PLUGIN DEFAULT_FUNCTIONALITY DEFAULT_SUBACTION DEFAULT_ACTION id, \
      <agent_home>/sbin/nmosudo DEFAULT_PLUGIN DEFAULT_FUNCTIONALITY DEFAULT_SUBACTION DEFAULT_ACTION <dispatcher_loc>/root_dispatcher.sh *
 
aime ALL=(root) <command_alias>

<agent_home>は、管理エージェントのホームを表します。

ノート:

EMパッチ計画ウィザードからの特権資格証明の検証が必要ない場合は、次の操作を行います。

EMリポジトリのmgmt_patching_properties表でcheck_privileged_sudo_credentialsの値にfalseを設定します。

/etc/sudoersには次の内容のみを含めることができます。

Cmnd_Alias <command_alias> = \
		<agent_home>/sbin/nmosudo DEFAULT_PLUGIN DEFAULT_FUNCTIONALITY DEFAULT_SUBACTION DEFAULT_ACTION <dispatcher_loc>/root_dispatcher.sh *
aime ALL=(root) <command_alias>

ノート:

<dispatcher_loc>は、ルート・コンポーネントがステージングされるルート・ディスパッチャの場所を表します。デフォルトでは、ルート・コンポーネントは、自動的に%emd_emstagedir%にステージングされます。自動ステージングのためにカスタムの場所を選択するか、ルート・コンポーネントを手動でカスタムの場所でステージングする場合は、その場所を<dispatcher_loc>に指定してください。それ以外の場合は、デフォルトの場所、つまり%emd_emstagedir%を指定します。

ノート:

RACおよびGrid Infrastructureデータベースにパッチ適用するためにrootとして実行されるコマンドの詳細は、Oracle Grid InfrastructureとOracle RAC構成のサポートを参照してください。

プロビジョニングのルート・コンポーネント

内容は次のとおりです。

プロビジョニングのための手動によるルート・コンポーネントのステージング

リリース更新(RU)またはプラグインのリリースを選択したら、ルート・スクリプト・コンポーネントを一時的な場所にステージングして、事前にステージングしたファイルと同じように操作する必要があります。
バージョン間の変更を確認して、新しいファイルのセットでステージング前の場所を更新します。
RUまたはプラグインは、その更新に付属する最新のファイルでのみ機能する点に注意してください。変更内容を検証して受け入れるか、内部プロセスによって問題が解決されるまでRUまたはプラグインの取込みを延期します。
RUまたはプラグインの更新を受け入れたら、新しいルート・スクリプトとステージング前のファイルに、以前のバージョンに加えていたカスタムの変更を取り込みます。
本番環境で使用するためにルート・スクリプトを事前ステージングして、通常の手動によるステージング・ステップを進めます。

「エンタープライズ」メニューから、「プロビジョニングとパッチ適用」、「ソフトウェア・ライブラリ」の順に選択します。
「パッチ適用とプロビジョニング」、「コンポーネント」の順に移動します。
「ルート・ディスパッチャ」を選択して「表示」をクリックします。
「ステージ」をクリックします。
ホスト(ルート・ディスパッチャをステージングする場所)、およびディスパッチャの場所、つまり、ルート・ディスパッチャのステージング先として指定したホストの場所を指定します。「発行」をクリックして、ルート・ディスパッチャを手動でステージングします。
「パッチ適用とプロビジョニング」、「コンポーネント」の順に移動します。
「rootスクリプト」を選択して「表示」をクリックします。
「ステージ」をクリックします。
ホスト(ルート・コンポーネントをステージングする場所)、およびディスパッチャの場所、つまり、ルート・コンポーネントのステージング先として指定したホストの場所を指定します。「発行」をクリックして、ルート・コンポーネントを手動でステージングします。

ノート:

カスタムの場所でのルート・コンポーネントのステージングを手動で行う前に、ディスパッチャの場所およびroot_dispatcher.shに対する読取りおよび実行権限がユーザーに付与されていることを確認します。
前のステップでステージングしたファイルを解凍します。

ノート:

ルート・コンポーネントを手動でステージングした後、Oracleデータベースのプロビジョニング・ウィザードから「ソフトウェアの場所の選択」ページにアクセスする必要があります。 wizard.「ルート・ディスパッチャの場所」で、ルート・コンポーネントを手動でステージングした場所と同じディスパッチャの場所を指定し、「このオプションは、すべてのルート・スクリプトがROOT_DISPATCH_LOCにすでにステージングされている場合に選択します」を選択します。

ルート・スクリプト・コンポーネントを手動でステージングしていない場合、データベース・プロビジョニング・ワークフローを使用して詳細を指定できます。Oracleデータベースのプロビジョニング・ウィザードの「ソフトウェアの場所の選択」ページに、ルート・スクリプトをステージングする場所を入力します。場所の詳細を指定しない場合、Enterprise Managerの標準のステージングの場所を使用してルート・コンポーネントをステージングします。

rootユーザーのアクセス権限の制限

Enterprise Manager Cloud Controlでは、管理エージェント・ユーザーがrootとしてすべてのコマンドを実行するのではなく、特定のコマンドのみを実行できるように、管理エージェント・ユーザーのrootアクセス権限を制限できます。これを実行するには、/etc/sudoersポリシー・ファイルを編集します。プロビジョニングは管理エージェントを使用してターゲット・ホスト上のすべてのコマンドを呼出すため、nmosudoを実行可能なコマンドのセットと共にsudoersファイルに含める必要があります。制限付きのrootアクセス権限を管理エージェント・ユーザーに与えるには、/etc/sudoersファイルを編集して、次の内容を含めます。

Cmnd_Alias SR_PATCH_DISPATCHER = \       
/u01/app/oracle/agent/agent_13.4.0.0.0/sbin/nmosudo *, \       
/u01/app/oracle/agent/agent_13.4.0.0.0/sbin/nmosudo  DEFAULT_PLUGIN DEFAULT_FUNCTIONALITY DEFAULT_SUBACTION DEFAULT_ACTION  perl *, \       
/u01/app/oracle/agent/agent_13.4.0.0.0/sbin/nmosudo  DEFAULT_PLUGIN DEFAULT_FUNCTIONALITY DEFAULT_SUBACTION DEFAULT_ACTION  id, \       
/u01/app/oracle/agent/agent_13.4.0.0.0/sbin/nmosudo  DEFAULT_PLUGIN DEFAULT_FUNCTIONALITY DEFAULT_SUBACTION DEFAULT_ACTION
/tmp/fleet/dispatchLoc/root_dispatcher.sh *
oracle ALL=(root)NOPASSWD:SR_PATCH_DISPATCHER 
grid ALL=(root)NOPASSWD:SR_PATCH_DISPATCHER

<command_alias>は、rootとしてoracleまたはgridで実行できるエンティティを記述する別名を表します。

<agent_home>は、管理エージェントのホームを表します。

フリート・メンテナンスのルート・コンポーネント

この項の内容は次のとおりです。

フリート・メンテナンスのための手動によるルート・コンポーネントのステージング

リリース更新(RU)またはプラグインのリリースを選択したら、ルート・スクリプト・コンポーネントを一時的な場所にステージングして、事前にステージングしたファイルと同じように操作する必要があります。
バージョン間の変更を確認して、新しいファイルのセットでステージング前の場所を更新します。
RUまたはプラグインは、その更新に付属する最新のファイルでのみ機能する点に注意してください。変更内容を検証して受け入れるか、内部プロセスによって問題が解決されるまでRUまたはプラグインの取込みを延期します。
RUまたはプラグインの更新を受け入れたら、新しいルート・スクリプトとステージング前のファイルに、以前のバージョンに加えていたカスタムの変更を取り込みます。
本番環境で使用するためにルート・スクリプトを事前ステージングして、通常の手動によるステージング・ステップを進めます。

「エンタープライズ」メニューから、「プロビジョニングとパッチ適用」→「ソフトウェア・ライブラリ」を選択します。
「パッチ適用とプロビジョニング」、「コンポーネント」の順に移動します
「ルート・ディスパッチャ」を選択して「表示」をクリックします
「ステージ」をクリックします。
ホスト(ルート・ディスパッチャをステージングする場所)、およびディスパッチャの場所、つまり、ルート・ディスパッチャのステージング先として指定したホストの場所を指定します。「発行」をクリックして、ルート・ディスパッチャを手動でステージングします。
「rootスクリプト」を選択して「表示」をクリックします
「ステージ」をクリックします。
ホスト(ルート・コンポーネントをステージングする場所)、およびディスパッチャの場所、つまり、ルート・コンポーネントのステージング先として指定したホストの場所を指定します。「発行」をクリックして、ルート・コンポーネントを手動でステージングします。

ノート:

カスタムの場所でのルート・コンポーネントのステージングを手動で行う前に、ディスパッチャの場所およびroot_dispatcher.shに対する読取りおよび実行権限がユーザーに付与されていることを確認します
前のステップでステージングしたファイルを解凍します。
共通ルートを選択して、「表示」をクリックします。
「ステージ」をクリックします。

フリート・メンテナンスのために事前ステージングされたルート・ディスパッチャのオプションが構成されました。詳細は、「フリート管理ソフトウェア」を参照してください。

ノート:

フリート・メンテナンスでのrootユーザーによるアクセスの制限

Enterprise Manager Cloud Controlでは、管理エージェント・ユーザーがroot,としてすべてのコマンドを実行するのではなく、特定のコマンドのみを実行できるように、管理エージェント・ユーザーのrootアクセス権限を制限できます。これを実行するには、/etc/sudoersポリシー・ファイルを編集します。プロビジョニングでは管理エージェントを使用してターゲット・ホスト上のすべてのコマンドを呼出すため、nmosudoを実行可能なコマンドのセットとともにsudoersファイルに含める必要があります。制限付きのrootアクセス権限を管理エージェント・ユーザーに与えるには、/etc/sudoersファイルを編集して、次の内容を含めます。

Cmnd_Alias <command_alias> = \
      <agent_home>/sbin/nmosudo DEFAULT_PLUGIN DEFAULT_FUNCTIONALITY DEFAULT_SUBACTION DEFAULT_ACTION perl *, \
      <agent_home>/sbin/nmosudo DEFAULT_PLUGIN DEFAULT_FUNCTIONALITY DEFAULT_SUBACTION DEFAULT_ACTION <dispatcher_loc>/root_dispatcher.sh *,\
      <agent_home>/sbin/nmosudo DEFAULT_PLUGIN DEFAULT_FUNCTIONALITY DEFAULT_SUBACTION DEFAULT_ACTION id
 
aime ALL=(root) PROVISIONING_DISPATCHER

<command_alias>は、aimeをrootとして実行できるエンティティを説明するエイリアスを表します。

<agent_home>は、管理エージェントのホームを表します。

input_file内にdispatchLocフラグを設定することで、ルート・アクセスを制限することもできます。このパラメータは、既存の読取り専用の場所を使用してディスパッチャの場所をステージングして使用し、事前ステージングされているディスパッチャおよびフリート・スクリプトを使用する操作のために追加されています。

フリート・メンテナンス操作を使用すると、ルートが所有するタイプのスクリプトのための読取り専用のマウント・ポイントの場所を作成できます。input_file内にdispatchLocフラグを設定することで、rootのみにアクセスを制限できます。必要に応じて、この場所にある必要なすべてのファイルを事前ステージングすることもできます。事前ステージングする場合は、dispatchLocにルート・ディスパッチャ、解凍したルート・スクリプトおよび共通ルートを含める必要があります。

input_fileの詳細は、「フリート管理ソフトウェア」を参照してください