| Oracle Enterprise Manager Grid Controlアドバンスト・インストレーションおよび構成ガイド 11gリリース1（11.1.0.1.0） B61023-01 |
|
 戻る |
 次へ |
| Oracle Enterprise Manager Grid Controlアドバンスト・インストレーションおよび構成ガイド 11gリリース1（11.1.0.1.0） B61023-01 |
|
戻る |
次へ |
この章では次の項について説明します。
ホスト・コンピュータにOracle Management Agentをインストールすると、Enterprise Managerでは自動的にデフォルト・メトリック・セットの収集が開始されます。これは、そのホスト上の各ターゲットのパフォーマンスおよび可用性の監視に使用できます。これらのターゲット・メトリックの一部については、デフォルトのしきい値設定（メトリックにおける問題を通知する時期を決定）がEnterprise Managerに用意されています。
|
関連項目: Enterprise Managerのオンライン・ヘルプのアラートに関する項 |
選択したメトリックについて、デフォルトのしきい値をカスタマイズできます。このようなカスタマイズを実行すると、新規の設定がローカル・ディスク上のファイルに保存されます。これらの設定の保存について、次の項でより詳しく説明します。
Enterprise Managerでは、各ターゲットに対するデフォルトの収集基準が各Oracle Management Agentホストの次の場所に保存されます。
AGENT_HOME/sysman/admin/default_collection/
一部のターゲットについては、Oracle Enterprise Manager 10g Grid Controlコンソールを使用してデフォルトのメトリック収集設定を変更できます。たとえば、ホスト・ターゲットのデフォルトのしきい値を変更できます。このような変更を実行すると、新規のインスタンス収集ファイルが次のディレクトリに作成されます。
AGENT_HOME/sysman/emd/collection/
この収集ファイルは、sysman/admin/default_collectionディレクトリに保存されているデフォルトの収集情報を上書きします。
Oracleソフトウェア製品をホスト・コンピュータにインストールするたびに、Oracle Universal Installerによってソフトウェアのインストール情報がハード・ディスクに保存されます。このソフトウェア構成情報を含むディレクトリおよびファイルは、Oracle Universal Installerインベントリと呼ばれます。
|
関連項目: 『Oracle Universal InstallerおよびOpatchユーザーズ・ガイド』 |
Enterprise Managerを使用してOracleソフトウェアのインストールを監視する際、Universal Installerインベントリに保存されている情報が利用されます。
ホスト・コンピュータの構成に関する情報を収集する際、デフォルトでは、ホスト上に1つのOracle Universal Installerインベントリがあるものと想定されます。具体的には、Enterprise Managerはホスト上でOracle Universal Installerを実行する際に使用されるインベントリを認識します。
ただし、複数のインベントリがある場合もあります。たとえば、Oracleサポートに連絡をとり、Oracleソフトウェア・インストールのクローンを作成しているような場合です。このような場合は、次の手順を使用して、同一ホスト上の複数のインベントリのソフトウェア情報をEnterprise Managerで追跡および管理できるようにしてください。
|
注意: 複数のインベントリに対するサポートの有効化はオプションであり、Oracle Universal Installerインベントリのアーキテクチャを熟知し、以前に管理対象ホストで複数のインベントリを管理した経験を持つ上級ユーザーのみが使用できます。この手順は、通常のインストールが行われたホストについては不要です。 |
ホスト上の複数のインベントリを認識できるようにEnterprise Managerを設定するには、次の手順を実行します。
次のディレクトリにあるOUIinventories.addファイルを探します。
$ORACLE_HOMEsysman/config
この例で示した管理エージェントの状態は、Database Controlのインストールを表します。他のインストールに使用する管理エージェント状態の詳細は、「AGENT_HOMEディレクトリとAGENT_STATEディレクトリ」を参照してください。
テキスト・エディタを使用してOUIinventories.addを開きます。
ファイル内の指示には、Oracleホームのマッピングに関するその他の技法とともに、複数のインベントリの指定時に使用する書式が記述されています。
ファイル内の指示を注意して確認します。
管理対象ホスト上の各追加インベントリについて、エントリをファイルに追加します。
変更を保存してファイルを閉じます。
次のホスト構成情報の収集時に、通常Enterprise Managerで収集されるデフォルト・インベントリに加えて、OUIinventories.addファイルで指定したインベントリからもソフトウェア構成情報の収集が開始されます。
もう1つの方法として、次の定期収集スケジュールの前に追加インベントリから収集されるデータを確認するには、Grid Controlコンソールのホストのホームページにナビゲートして、「構成」タブをクリックし、ページ・タイムスタンプの横にある「データのリフレッシュ」アイコンをクリックします。
|
注意: デフォルト・インベントリの収集時にリカバリ不能な問題がある場合（インベントリ・ファイルまたはディレクトリの保護機能によってEnterprise Managerでインベントリの読取りができない場合など）は、OUIinventories.addファイルに列記されたインベントリも収集されません。Enterprise Managerでデフォルト・インベントリの読取りはできても、OUIinventories.addファイルに列記された追加インベントリの読取りに問題がある場合、これらのインベントリに対する収集警告が発行されます。しかし、他のインベントリに対する構成情報は収集されます。 |
管理エージェントは、主要な2つのディレクトリ構造を認識します。1つは、ソフトウェア・バイナリおよびすべての未変更メタデータが格納されるインストール・ディレクトリです。もう1つは、すべてのカスタマイズ内容および出力とログの内容の、格納または生成、あるいはその両方が行われる構成/状態ディレクトリです。標準の管理エージェント・インストールでは、この2つのディレクトリは同じです。ただし次の場合は、この2つのディレクトリが別になることもあります。
RACエージェント・インストール（$ORACLE_HOMEと$ORACLE_HOME/<hostname>）
Database Controlインストール（$ORACLE_HOMEと$ORACLE_HOME/<nodename>_<sid>）
（emctl deploy agentコマンドを使用する）状態のみの管理エージェント・デプロイ（$ORACLE_HOMEと$EMSTATE）
前述の各例では、同じバイナリ・インストールから管理エージェントの複数のインスタンスが実行されます。これらのインスタンスは個々の構成を保守するために別々の場所を持ちますが、同じバイナリ・セットを使用します。コマンドemctl status agentを使用すると、管理エージェントのバイナリおよび状態の場所の値がわかります。
Oracle Database 10gターゲットを最初に検出した際、監視資格証明をチェックして、DBSNMPデータベース・ユーザー・アカウントのパスワードがデータベース・ターゲット・プロパティで正しく設定されていることを確認します。
監視資格証明の設定以外に、Oracle Database 10gターゲットを監視するために必要な構成タスクはありません。
ただし、Oracle9iデータベースまたはOracle8iデータベースを監視するとき、Grid Controlコンソールを使用して特定のタイプのデータベース・パフォーマンス・メトリックを監視する場合には追加構成が必要です。
これらの追加パフォーマンス・メトリックを監視するには、Oracle Statspackおよびその他のEnterprise Managerパッケージが、監視中のデータベースにインストールされ構成されていることが必要です。
|
関連項目: Oracle9iドキュメント・ライブラリの『Oracle Databaseパフォーマンス・チューニング・ガイド』のStatspackの使用方法に関する項 |
これらの追加オブジェクトがデータベース内になく構成もされていない場合、Enterprise Managerは完全なパフォーマンス・メトリック・セット用のデータを収集することができません。また、「エラーSQL」や「上位SQLレポート」のような、通常ならデータベースのホームページから容易に入手できるような情報もEnterprise Managerでは収集できなくなります。
Grid Controlコンソールでデータベースの構成ウィザードを使用して必要なパッケージをデータベースにインストールするか、もしくは次の手動による手順を使用します。
|
関連項目: データベース・ターゲットを含む管理対象ターゲットの構成の詳細は、Enterprise Managerのオンライン・ヘルプのターゲット・プロパティ変更に関する項 |
Statspackおよびその他の必須データベース・オブジェクトを、Enterprise Managerで管理中のOracle9iデータベースに手動でインストールするには、SQL*Plusおよび次の手順を使用します。
データベース・ホーム・ディレクトリおよび管理エージェント・ホーム・ディレクトリへの書込み権限を持つアカウントを使用して、データベース・ホストにログインします。
この手順の各コマンドについて、AGENT_HOMEをOracle Management Agentホーム・ディレクトリの実際のパスに置き換え、ORACLE_HOMEをデータベース・ホーム・ディレクトリのパスに置き換えてください。
SQL*Plusを起動し、SYSDBA権限を持つSYSアカウントを使用してデータベースに接続します。
次に例を示します。
$PROMPT> ./sqlplus "connect / as sysdba"
次のコマンドを入力して、データベースのdbmonスクリプトを実行します。
SQL> @AGENT_HOME/sysman/admin/scripts/db/config/dbmon
次のプロンプトが表示されます。
Enter value for dbm_password:
プロンプトが表示されたら、DBSNMPアカウントのパスワードを入力します。
スクリプトで各種の構成変更が実行され、再びSQL*Plusプロンプトが表示されます。
次に例を示します。
SQL> connect DBSNMP
次のコマンドを入力します。
SQL> @AGENT_HOME/sysman/admin/scripts/db/config/response.plb SQL> grant EXECUTE on dbsnmp.mgmt_response to OEM_MONITOR;
|
注意: 前述のスクリプトは、リリース8.1.7以下のOracleデータベースでは実行しないでください。Oracleでは、8.1.7以下のデータベースのSQLレスポンス時間はサポートしていません。 |
SYSユーザーとして接続し、次のコマンドを入力してPERFSTATユーザーを作成します。
SQL> @ORACLE_HOME/rdbms/admin/spcreate
|
注意: spcreateスクリプトでは、PERFSTATユーザーに対するデフォルト表領域とデフォルト一時表領域が求められます。SYSTEM表領域は、PERFSTATユーザーに対するデフォルト表領域として指定しないでください。詳細は、『Oracle Databaseパフォーマンス・チューニング・ガイド』のStatspackの使用方法に関する項を参照してください。 |
PERFSTATユーザーとして接続します。
次に例を示します。
SQL> connect PERFSTAT;
PERFSTATユーザー・アカウントから次のコマンドを入力します。
SQL> define snap_level='6'; SQL> define cinterval='1'; SQL> define cjobno='-1'; SQL> @AGENT_HOME/sysman/admin/scripts/db/config/spset
SYSユーザーとして接続し、次のコマンドを入力します。
SQL> grant OEM_MONITOR to dbsnmp;
変更するデータベースがOracle8iデータベースの場合は、SYSユーザーとして次のコマンドも入力します。
grant select on sys.ts$ to OEM_MONITOR;grant select on sys.seg$ to OEM_MONITOR;grant select on sys.user$ to OEM_MONITOR;grant select on sys.obj$ to OEM_MONITOR;grant select on sys.sys_objects to OEM_MONITOR;grant select on sys.file$ to OEM_MONITOR;grant select on sys.attrcol$ to OEM_MONITOR;grant select on sys.clu$ to OEM_MONITOR;grant select on sys.col$ to OEM_MONITOR;grant select on sys.ind$ to OEM_MONITOR;grant select on sys.indpart$ to OEM_MONITOR;grant select on sys.indsubpart$ to OEM_MONITOR;grant select on sys.lob$ to OEM_MONITOR;grant select on sys.lobfrag$ to OEM_MONITOR;grant select on sys.partobj$ to OEM_MONITOR;grant select on sys.tab$ to OEM_MONITOR;grant select on sys.tabpart$ to OEM_MONITOR;grant select on sys.tabsubpart$ to OEM_MONITOR;grant select on sys.undo$ to OEM_MONITOR;
サポートされるすべてのデータベース・バージョンについて、SYSアカウントから次のコマンドを入力します。
SQL> show parameter job_queue_processes
show parameterコマンドの出力がゼロの場合は、次の手順を実行してjob_queue_processes初期化パラメータを変更します。
spfileを使用してデータベースを起動する場合は、次のコマンドを入力します。
SQL> alter system set job_queue_processes = 2 SCOPE=BOTH;
その他の場合は次の手順を実行します。
次のコマンドを入力します。
SQL> alter system set job_queue_processes = 2;
SQL*Plusを終了し、データベースがいつ再起動してもパラメータが適用されるように、init.oraデータベース構成ファイルを次のエントリで更新します。
job_queue_processes=2
SQL*Plusを終了し、ディレクトリを、データベースを監視している管理エージェントのホーム・ディレクトリ内の次のディレクトリに変更します。
AGENT_HOME/bin
次のコマンドを入力して管理エージェントをリロードします。
$PROMPT> ./emctl agent reload
Grid Controlコンソールを使用して、データベースのホームページに戻り、「エラーSQL」や「上位SQLレポート」などのメトリックが収集されているか確認します。
Grid Controlコンソールへの不正なアクセスを回避するため、事前定義された一定期間の間にアクティビティが発生しない場合、ユーザーはGrid Controlコンソールから自動的にログアウトします。たとえば、ユーザーがブラウザを起動したまま職場を離れた場合でも、このデフォルト機能により、Enterprise Managerの管理者アカウントを他の無認可のユーザーが使用することはできません。
デフォルトでは、システムが45分以上アクティブでない状態が続くと、Enterprise Managerの処理を実行しようとしても再度Grid Controlコンソールにログインすることを求められます。
|
注意: 前の段落で記述されているとおり、Grid Controlコンソールにログインする際のタイムアウト値は、無認可のログインからシステムを保護するために定義されています。ログインのタイムアウト値を変更する場合は、デフォルトのタイムアウト期間以外にもセッションをオープンにすることのセキュリティ上の問題を十分に考慮してください。 |
デフォルトのタイムアウト時間を延長または短縮するには、次のようにします。
ディレクトリを、管理サービスがデプロイされたFusion Middlewareホーム・ディレクトリの次の場所に変更します。
IAS_HOME/sysman/config/
テキスト・エディタを使用して、emoms.propertiesファイルを開き、次のエントリを追加します。
oracle.sysman.eml.maxInactiveTime=time_in_minutes
たとえば、デフォルトのタイムアウト時間を1時間に変更する場合は、次のエントリを追加します。
oracle.sysman.eml.maxInactiveTime=60
emoms.propertiesファイルを保存して閉じます。
管理サービスを再起動します。
|
注意: デフォルトのタイムアウト値は、WebサーバーまたはOracle Management Serviceの再起動の際には適用されません。これらのケースでは、デフォルトのタイムアウト値にかかわらずGrid Controlコンソールへログインすることを求められます。 |
この項では、クラスタ、クラスタ・データベース、および検出インスタンスの構成方法について説明します。
インストールされたが、インストール中にターゲットして自動的に検出されなかったクラスタ・ターゲットを追加するには、次の手順を実行します。
「ターゲット」ページから「すべてのターゲット」をクリックします。
「追加」メニューから「クラスタ」を選択し、「実行」をクリックします。「ターゲットの追加: クラスタ」ページが表示されます。
オプション: クラスタ名を指定し、（クラスタウェアがクラスタ上にインストールされている場合は）クラスタウェア・ホームのパスを指定します。
ホストをクラスタに追加するには、矢印ボタンを使用して「使用可能なホスト」から「選択したホスト」に項目を移動します。すでにクラスタに属しているホストを選択する必要があります。
「追加」をクリックして、選択したホストごとにクラスタ・ターゲットをtargets.xmlファイルに保存します。
|
関連項目: クラスタの構成方法の詳細は、Enterprise Managerのオンライン・ヘルプ |
クラスタ・ターゲットを追加した後は、「データベース」ページまたは「すべてのターゲット」ページからクラスタ・データベース・ターゲットを追加できます。
クラスタ・データベース・ターゲットを追加するには、次の手順を実行します。
Enterprise ManagerのGrid Controlコンソールで、次のいずれかの開始場所を選択します。
「データベース」ページから「追加」をクリックします。「データベース・インスタンス・ターゲットの追加: ホストの指定」ページが表示されます。
「すべてのターゲット」ページで、「追加」ドロップダウン・メニューから「データベース・インスタンス」を選択し、「実行」をクリックします。「データベース・インスタンス・ターゲットの追加: ホストの指定」ページが表示されます。
クラスタ・データベースが存在するクラスタ・ターゲットのホスト・メンバーを指定し、「続行」をクリックします。「データベースの追加: ソースの指定」ページが表示されます。
（クラスタ内のすべてのホストに対して）選択されているデフォルト・オプションを使用し、「続行」をクリックします。このオプションによって、クラスタ内のすべての管理エージェントに、検出を実行するためのリクエストが送信されます。
ターゲットの検出が完了すると、「クラスタでターゲットが検出されました: {0}」ページに、新しく検出されたRACデータベースが表示されます。データベースが表示されない場合は、後述の「トラブルシューティング」の項を参照してください。
「クラスタ・データベース」表に目的のターゲットが表示されない場合、または検出されたターゲットが適切に構成されていない場合は、「手動で追加」をクリックします。クラスタ・データベースの構成ウィザードの「プロパティ」ページが表示されます。
「プロパティ」表に必要な値を入力します。
「インスタンス」表には、少なくとも1つのインスタンスを指定する必要があります。この表にインスタンスが表示されない場合は、「追加」をクリックします。「プロパティ: インスタンスの追加」ページが表示されます。必要な値を入力し、「OK」をクリックします。クラスタ・データベースの構成ウィザードの「プロパティ」ページが再び表示されます。
「次へ」をクリックします。データベース・リリース10.1以上の場合、Enterprise Managerは「パッケージのインストール」、「資格証明」および「パラメータ」のステップを省略し、直接「確認」ページに進みます。
「OK」をクリックします。「クラスタでターゲットが検出されました」ページが再び表示され、新しく追加されたクラスタ・データベースおよびインスタンスが表示されます。
|
関連項目: クラスタ・データベースの構成方法の詳細は、Enterprise Managerのオンライン・ヘルプ |
追加のインスタンスを構成する必要がある場合、次の手順に従います。
Enterprise Managerで、「ターゲット」ページの「データベース」をクリックし、目的の「クラスタ・データベース」ホームページに移動します。
「関連リンク」セクションで「監視構成」をクリックします。クラスタ・データベースの構成ウィザードの「プロパティ」ページが表示されます。
ページの上部にある「プロパティ」表に必要な情報を入力します。
「インスタンス」表を調べます。1つ以上の追加のインスタンスが存在していても、「インスタンス」表に表示されていないことがあります。その場合は、「追加」をクリックしてクラスタ・データベース内のインスタンスを検出します。「プロパティ: インスタンスの追加」ページが表示されます。
必要な情報を入力し、「OK」をクリックします。ウィザードの「プロパティ」ページが再び表示され、追加されたインスタンスのビューが表示されます。
「接続のチェック」をクリックして、その接続が機能していることを確認します。
|
関連項目: クラスタ・データベースに追加されたインスタンスの検出方法の詳細は、Enterprise Managerのオンライン・ヘルプ |
構成の問題が発生した場合は、次の必要な条件をチェックして、自動検出が正常に機能することを確認してください。
管理エージェントを実行しているホスト・ユーザーが、Oracleホーム内のSRVCTLユーティリティを実行でき、データベース構成を取得できること
管理エージェントを実行しているホスト・ユーザーが、OS認証を使用してSQLPLUSを介してデータベースに接続できること
Oratab（UNIX）またはRegistry（Windows）にデータベースに関する情報が含まれていること
前述の条件を確認した後も自動検出で構成の問題が解決されない場合は、クラスタ・データベースを手動で構成できます（「クラスタ・データベースの構成」を参照）。
クライアントは、ホストおよびオペレーティング・システムのユーザーです。収集されるクライアント構成データには、次のものがあります。
クライアントのハードウェア。
クライアントのオペレーティング・システム（オペレーティング・システムのプロパティ、ファイル・システム、パッチなどの情報を含みます）。
オペレーティング・システムに登録されたソフトウェア。
ネットワーク・データ。これには次のものが含まれます。
Webサーバーに対する待機時間
Webサーバーに対する帯域幅
クライアント構成収集アプレットへのアクセスに使用されるブラウザの構成が記述されたクライアント固有のデータ項目。これには次のものが含まれます。
ブラウザ・タイプ（ベンダー）
ブラウザ・バージョン
（クライアント構成収集アプレットの実行に使用されるJVMの）JVMベンダー
（クライアント構成収集アプレットの実行に使用されるJVMの）JVMバージョン
プロキシ・サーバー（指定されている場合）
プロキシ・サーバー例外
ブラウザ・キャッシュ・サイズ（MB）
ブラウザ・キャッシュの更新頻度
サポートされているHTTPバージョン
その他のクライアント指向のデータ項目。これには次のものが含まれます。
クライアント構成収集アプレットの識別子（アプレット・コード内で定義されるバージョン）
（クライアント構成収集アプレットへのアクセスに使用された）アプリケーションURL
ブート・ドライブのシリアル番号（ディスクがないシステムでは使用不可）
（クライアント構成収集アプレットJSPからの）収集タイムスタンプ
収集期間（ミリ秒）
クライアントのIPアドレス
有効なクライアントIPアドレス: クライアントと、クライアント構成収集アプレットを提供するWebサーバーの間でネットワーク・プロキシ・サーバーが使用されている場合、有効なクライアントIPアドレスは、そのプロキシ・サーバーのIPアドレスになります。
クライアント・システム・アナライザ（CSA）を使用すると、Webサーバーの管理者はエンドユーザーのクライアント・データを収集および分析できます。クライアント・データはアプレットにより収集され、診断されてCSAアプリケーションに送り返されます。Oracle Management Agentは、このデータをEnterprise Managerの管理リポジトリにアップロードします。クライアント構成収集アプレットによりクライアント構成データが収集され、CSAアプレットで指定されたWebサーバー・ディレクトリに書き込まれた後、そのクライアント構成データはOracle Management Repositoryにアップロードされます。
クライアント・システム・アナライザは、Enterprise ManagerとともにプリインストールされているGrid Controlアプリケーションで使用できます。あるいは、CSAを別個にWebサーバーにデプロイすることもできます。
Grid Controlのクライアント・システム・アナライザ（CSA）のインスタンスは、Enterprise Managerとともにプリインストールされています。このオプションを使用すると、個別のWebサーバーを設定しなくてもクライアント・データを収集できます。プリインストールされたCSAアプリケーションをEnterprise Managerでアクティブにするには、「デプロイ」をクリックします。次に「Grid Controlのクライアント・システム・アナライザ」をクリックし、アプリケーションをアクティブにするためのボタンを使用します。CSAがアクティブになると、エンドユーザーは、CSAアプレットを実行するために提供されたURLを使用できるようになります。CSAアプレットは、クライアント・システムから基本クライアント構成情報を収集し、Oracle Collaboration Suiteクライアント・システムからOracle Collaboration Suiteクライアント情報を収集できます。
CSAアプレットをダウンロードし、アプレットにより基本クライアント構成情報を収集する場合、クライアントは、http[s]://management-service-host:port/em/public/ecm/csa/CSAという形式のクライアント・システム・アナライザURLを使用する必要があります。
CSAアプレットをダウンロードし、アプレットによりOracle Collaboration Suiteクライアント構成情報を収集する場合、クライアントは、http[s]://management-service-host:port/em/public/ecm/csa/CSA?application=OCSという形式のクライアント・システム・アナライザURLを使用する必要があります。
クライアント・システム・アナライザ・アプリケーションは、別個に任意のJ2EE対応Webサーバーにデプロイできます。「デプロイ」タブをクリックします。次に「クライアント・システム・アナライザの開始」をクリックし、「クライアント・システム・アナライザ・アプリケーションのデプロイ」をクリックします。次の手順に従ってCSAアプレットをデプロイし、クライアント構成データを収集します。
CSAアプリケーションをダウンロードします。
CSAアプリケーションには、CSAディレクトリと必要なJSPアプレット・ファイルが含まれています。CSAアプリケーションは、EARファイルとしてパッケージ化されています。このデフォルトEARファイルをダウンロードするには、「クライアント・システム・アナライザ・アプリケーションのダウンロード」をクリックします。デフォルトのCSA EARファイルをカスタマイズするには、次の要素を変更します。
ルール: このファイルには、クライアント・データの評価に使用されるデフォルトのルール・セットが含まれます。CSAのデプロイ前に、ルールのカスタマイズおよび追加を行うことができます。
コンテキスト・パラメータ: web.xmlファイル内のコンテキスト・パラメータをカスタマイズできます。
カスタム・クラス: 追加データの収集、アプレットの動作の変更、クライアントに対する特定の操作の実行といったタスクに使用できる、カスタマイズしたアプレット・クラスを指定できます。
CSAを任意のJ2EE Webサーバーにデプロイします。
CSAアプリケーションは、標準のJ2EEアプリケーションとしてアプリケーション・サーバー上にデプロイされます。CSAアプリケーションをデプロイした後は、他のWebアプリケーションと同様に、コンテキスト・パラメータを変更できます。
ユーザーをCSAにダイレクトします。
クライアント・データを収集するためには、ユーザーがCSAアプリケーションにアクセスする必要があります。ユーザーはCSA JSPページに直接アクセスするか、または別のアプリケーションからリンクを使用してアクセスできます。次の方法を使用すると、ユーザーをCSAに自動的にリダイレクトできます。
HTTPサーバー（Apacheのmod_rewrite）: このオプションを使用する場合、Webアプリケーションを変更する必要はありません。
サーブレット・フィルタ: サーブレット・フィルタは、サーバーを往来するリクエストをフィルタ処理するプログラムです。CSA_filter.jarファイルには、サーブレット・フィルタ・クラスが含まれています。サーブレット・フィルタおよびフィルタ・マッピングをWebアプリケーションに追加する必要があります。
CSAリダイレクションJSP: CSAリダイレクションJSP（CSARedirect.jsp）のページをWebアプリケーションに組み込むことができます。
Enterprise Managerを構成します。
収集されたクライアント・データは、Webサーバー上の受信ファイル・ディレクトリ内に記録されます。収集されたクライアント・データをEnterprise Managerにアップロードするには、次の操作を実行する必要があります。
CSAコレクタ・ターゲットをEnterprise Managerの管理エージェントに追加します。これを行うには、「コレクタの追加」をクリックし、リストからターゲットを選択します。
受信ファイル・ディレクトリの絶対パスを指定します。CSAアプリケーションのoutputDirパラメータで指定されているパスと同じパスを指定する必要があります。デフォルトでは、クライアント・データは、クライアント・システム・アナライザWebアプリケーションのコンテキスト・ルートの下の受信ファイル・ディレクトリcsa_resultsに格納されます。ただし、これはアプリケーションのoutputDirコンテキスト・パラメータを変更することで、構成可能です。
CSAデプロイをテストします。
CSAデプロイをテストするには、CSAページのURLをクリックし、クライアント・データが収集されていることを確認します。
クライアント・システム・アナライザ（CSA）を詳細に構成するには、CSAアプリケーションのWARファイル内のコンテキスト・パラメータを変更します。
表20-1 構成パラメータ
| パラメータ | 説明 | デフォルト値 |
|---|---|---|
|
alertWhenDone |
trueに設定した場合、アプレットの実行の完了を示すメッセージが表示されます。 |
false |
|
appletJAR |
JARファイルの名前。 |
CSA.jar |
|
application |
このCSAインスタンスに関連付けられたアプリケーションの名前。アプリケーション・パラメータ値を指定しない場合、「収集タグ」の値は「デフォルト」になります。 |
なし |
|
autoRedir |
JVMがJInitiatorに設定されているが、クライアントに適切なバージョンのJInitiatorがインストールされていない場合、このパラメータをtrueに設定すると、CSA JSPページは自動的にSun JVMを使用します。 |
false |
|
bwTestFile |
帯域幅テスト中にサーバーからダウンロードされるファイルの名前。 |
CSA.mb（CSAに付属） |
|
bwTestMsec |
アプレットが帯域幅テストの実行に必要とする時間。アプレットは、この時間中にダウンロード可能なバイト数をカウントすることで、帯域幅を計算します。 |
200ミリ秒 |
|
classid |
OBJECTタグのclassidフィールド。JVMをJInitiatorに設定した場合のみ、適用可能です。Sunのclassidは、clsid:8AD9C840-044E-11D1-B3E9-00805F499D93です。コードベース - OBJECTタグのcodebaseフィールド。JVMをJInitiatorに設定した場合のみ、適用可能です。 |
なし。JVMをJInitiatorに設定した場合は、このフィールドを設定する必要があります。それ以外の場合、このフィールドは無視されます。 |
|
codebase |
OBJECTタグのcodebaseフィールド。JVMをJInitiatorに設定した場合のみ、適用可能です。 |
Sunのデフォルトは、http://java.sun.com/products/plugin/autodl/jinstall-1_4_2-windows-i586.cab#Version=1,4,0,0です。 |
|
collectCookie |
収集されるCookieの名前のリスト。このパラメータは、Cookie名のカンマ区切りリストです。現行ブラウザでの現行OSユーザーのCookieのみが収集されます。管理者は、アスタリスク（*）を指定して、現行ブラウザの現行ユーザーのCookieすべてを収集できます。 |
このフィールドが存在しない場合、Cookieは収集されません。 |
|
cookieDomain |
CSA Cookieのドメイン。 |
Cookieのドメインまたはパスが設定されていない場合、Cookieは無効になります。 |
|
cookieMaxAge |
クライアント・マシン上のCookieの最大存続期間（秒）。 |
1年 |
|
cookiePath |
CSA Cookieのパス。 |
ドメインまたはパスが指定されていない場合、Cookieは無効になります。 |
|
customClass |
カスタム・データの収集に使用されるクラスの名前。 |
なし。デフォルトの動作では、カスタム・コードの実行はありません。 |
|
customKey1customKey2customKey3 |
3つのカスタム・キーの値。このデプロイメント・ディスクリプタを使用するCSA JSPページにより実行されるクライアント収集ではすべて、これらの値がカスタム・キーに対応しています。これらの値は、カスタム・コードで上書きできます。 |
カスタム・キーの値を指定しない場合、（カスタム・コードにより収集される場合を除き、）なにも収集されません。 |
|
descriptionFile |
「デプロイ」ページに表示される説明が入っているテキスト・ファイルのフルパス。このファイルの内容は、HTML形式のテキストである必要があります。 |
なし |
|
destURL |
宛先のURLを指定します。これは、CSA JSPページ上の「続行」ボタンのリンク先のURLです。 |
destURLを指定しない場合、ユーザーが「続行」ボタンを押すと、参照ページが表示されます。参照ページがない場合、「続行」ボタンは表示されません。 |
|
destURLResultsParam |
宛先URLに追加される、クライアントのコンプライアンス・レベルを示すURLパラメータの名前を指定します。たとえば、値がcomplianceであり、クライアントの全体的なコンプライアンス・レベルがcriticalである場合、パラメータcompliance=criticalが宛先URLに追加されます。 |
Sun |
|
JVM |
このパラメータは、使用されるJVMのタイプを決定します。値がSunの場合、JSPページはSun JVMを使用するようにブラウザを設定します。値がOracleの場合、JSPページはOracle Jinitiatorを使用するようにブラウザを設定します。値がanyの場合、JSPページは標準のappletタグを書き出すため、クライアントはブラウザにプラグインされている任意のJVMを使用することになります。 |
Sun |
|
maxExecInterval |
CSA Cookieペイロードに追加されるパラメータ。リダイレクション・ロジックによりCookieが読み取られるときに、Cookieのタイムスタンプと現在時刻との差がこの値よりも大きい場合、アプレットは再びデプロイされます。このパラメータは、リダイレクションJSPフィルタ内のcsa execIntervalコンテキスト・パラメータで上書きできます。 |
90日 |
|
maxFileSize |
1つのリクエストでレシーバにポストして戻せる最大データ量（KB）。この制限を超えるサイズのデータがポストされた場合、リクエストは拒否され、ハード・ドライブにすでに書き込まれたデータが削除されます。 |
100 |
|
maxOutputFiles |
XML OutputDirに存在できる出力ファイルの最大数。 |
100 |
|
outputDir |
CSA構成xmlファイルが書き込まれるディレクトリ。アプレット・ページとレシーバ・ページの両方がこのパラメータを読み取ります。このパラメータは両方のページで同じである必要があります。 |
デフォルトでは、出力ファイルはアプリケーション・ルート・ディレクトリのcsa_resultsサブディレクトリに書き込まれます（アプリケーション・ルート・ディレクトリが存在し、かつcsa_resultsサブディレクトリが存在しているか、作成可能な場合）。このパラメータにデフォルト値を使用することはお薦めしません。 |
|
outputEnabled |
出力XMLファイルの作成を有効または無効にします。アプレット・ページとレシーバ・ページの両方に適用可能です。 |
デフォルトでは、XMLファイルはXMLOutputDir内に作成および格納されます。 |
|
pluginspage |
Netscapeでは自動インストールがサポートされていないため、NetscapeのユーザーをJVMインストーラにダイレクトするために使用されます。JVMがJinitiatorの場合のみ、適用されます。Sunの場合、デフォルトは |
なし。JVMをJinitiatorに設定した場合は、このフィールドを設定する必要があります。それ以外の場合、このフィールドは無視されます。 |
|
receiver |
アプレットが収集済データをポストする宛先のURL。 注意: このパラメータを設定する際、管理者はレシーバのバージョンとアプレットのバージョンが同じであることを確認する必要があります。 |
デフォルトでは、CSA JSPページと同じパスでCSAr.jspが検索されます。 |
|
ruleFile |
評価するルールが含まれるファイルのサーバー上のパスを、Webアプリケーション・ルートを基準にして指定します。 |
rules.xml |
|
script |
管理者により提供されたスクリプトを指定します。このスクリプトを、エージェントによってアップロードのマークが付けられる前のCSA XMLファイルに対して実行できます。 |
なし。スクリプトを指定しない場合、どのスクリプトも実行されません。 |
|
type |
アプレットをデプロイするためにCSA JSPページによりレンダリングされるOBJECTタグのtypeフィールド。これは、JVMをJinitiatorに設定した場合のみ適用可能です。JVMをSunに設定した場合、typeは |
なし。JVMをJinitiatorに設定した場合は、このフィールドを設定する必要があります。それ以外の場合、このフィールドは無視されます。 |
|
viewData |
このパラメータをtrueに設定した場合、収集データがサーバーにポストされた後、エンド・ユーザーはそのデータを表示できます。 |
false |
これらのパラメータの他に、CSAリダイレクション・パラメータも構成可能です。リダイレクションを有効にするには、サーブレット・フィルタを使用するか、他のいくつかのページにCSAリダイレクションJSPファイルを追加します。リダイレクションが機能するためには、次のコンテキスト・パラメータが使用可能になっている必要があります。
表20-2 構成パラメータ
| パラメータ名 | 説明 | デフォルト値 |
|---|---|---|
|
csaURL |
ユーザーをリダイレクトする宛先CSA JSPページのURL。 |
デフォルトなし。この値を設定しないと、リダイレクションは機能しません。 |
|
execInterval |
CSAの実行間隔（秒）。Cookieの存続期間と現行サーバー時間の差がexecIntervalより大きい場合、ユーザーはリダイレクトされます。 |
なし。execIntervalを設定しない場合、CSA Cookieが存在する場合のみ、ユーザーはリダイレクトされます。 |
|
redirectURL |
CSAの実行完了後にユーザーをダイレクトする宛先のURL。 |
なし。 このパラメータを設定しない場合、ユーザーは、最初にリクエストしたページにダイレクトされます。 |
|
UIMode |
0: synchronous（現在のブラウザ・ウィンドウ） 1: asynchronous visible 2: asynchronous invisible |
synchronous |
異なるアプリケーションに対して、異なるパラメータ・セットが必要となる場合もあります。たとえば、異なるルール・セットおよびカスタム・コードを持つ2つの異なるアプリケーションがあり、管理者がそれらを異なるCSAコレクタ・ターゲットに関連付けるとします。このようなシナリオでは、管理者は、<application name> ruleFileや<application name> appletJarなどのコンテキスト・パラメータを使用して、特定のアプリケーションに対してruleFile、appletJar、scriptおよびoutputDirパラメータを指定することができます。コンテキスト・パラメータとして、またはURLを介してアプリケーションを指定すると、CSAはそのアプリケーションに固有のパラメータ値を使用して実行されます。アプリケーションを指定しない場合、またはアプリケーションのパラメータが1つも上書きされていない場合は、デフォルトのパラメータが使用されます。
システムが特定の制約条件を満たしているかどうかに関する即時のフィードバックをユーザーが受けられるように、CSAアプリケーションにカスタム・ルールを指定できます。例20-1にRULESファイルの例を示し、その後にファイル内に含まれる各タグについて説明します。
例20-1 RULESの例
<RULES> <RULE> <NAME>Client has sufficient memory</NAME> <DESCRIPTION>Checks to see if the client has enough memory to run the application</DESCRIPTION> <VIOLATION> //ROWSET[@TABLE='MGMT_ECM_HW']/ROW/AVAIL_MEMORY_SIZE_IN_MB[number() < $arg=SIZE$] </VIOLATION> <SEVERITY level="CRITICAL"> <PARAM id='SIZE'>100</PARAM> <MOREINFO> <TEXT>Application cannot run with less than 100 MB. </TEXT> </MOREINFO> </SEVERITY> <SEVERITY level="WARNING"> <PARAM id='SIZE'>150</PARAM> <MOREINFO> <TEXT>Approaching minimum memory level</TEXT> </MOREINFO> </SEVERITY> </RULE> </RULES>
例20-1は、クライアントにアプリケーションを実行するための十分なメモリーがあるかどうかをチェックするために使用可能なルールを示したものです。<VIOLATION>は、アプレットが、すべての収集済データが含まれたXMLファイルに対して評価するXPATH式です。この違反はXMLファイルに組み込まれたXPATH式であるため、XPATH内の<、>、&などの特定の文字は、実体に置き換える必要があります。XPATH式がNull以外のノード・セットを返す場合、ルールは失敗しています。この例では、クライアントの使用可能メモリーが特定量に満たない場合、ルールは失敗します。違反をトリガーする実際の量は、様々な重大度レベルを使用して構成できます。
表20-3では、アプレットは最初にVIOLATION式内の部分文字列$arg=SIZE$を100に置き換えてから、式を評価します。クライアントの使用可能メモリーが100MB未満の場合、ルールは失敗し、ステータスがクリティカルになります。アプレットは、「Application cannot run with less than 100 MB of memory」というメッセージとともにこのステータスを示します。ルールが正常に成功した場合、アプレットは$arg=SIZE$を150に置き換えて再試行します。このルールが失敗した場合、アプレットは「Approaching minimum memory level」というメッセージを表示します。アプレットがすべての指定の重大度レベルを通過したが、違反が検出されなかった場合、ルールは成功です。
表20-3 RULESファイル内のタグ
| タグ名 | 説明 |
|---|---|
|
RULES |
これは、XMLファイルの最上位レベルのタグです。 |
|
BUNDLE |
このタグは、変換に使用するリソース・バンドルを指定します。タグの値は、ファイル名またはJavaクラス名のどちらかです。ルール・エンジンはこの文字列を読み取り、最初にこの名前が含まれるアプレットJAR内でファイルを検索します。このファイルでは、リソースIDが各言語の文字列にマッピングされているとみなされます。そのようなファイルが存在しない場合、文字列はJavaリソース・バンドル・クラスとして扱われます。リソース・バンドル内の文字列は、構文 |
|
PRECONDITION |
このタグを使用して、ルールを評価するためにNullでないノード・セットを返す必要のあるXPATH式を指定します。id属性は、事前条件のIDを指定します。1つのルールで、評価する必要のある事前条件のリストを、そのIDを列記することにより指定できます。 |
|
RULE |
このタグは、評価する各ノードを表します。ルールの重大度は、<SEVERITY>タグを使用して指定します。1つのルールに対して少なくとも1つの重大度タグを指定する必要があります。このタグにはオプションのprecondition属性があります。カンマで区切った事前条件IDのリストを指定する場合は、この属性を使用します。ルールが評価される前に、すべての事前条件が満たされている必要があります。事前条件が満たされていない場合、ルールのステータスは「適用されません」になり、そのルールはクライアントのUIに表示されません。RULEタグの子は、NAME、DESCRIPTION、VIOLATION、SEVERITYおよびMOREINFOです。 |
|
NAME |
このタグはルールの名前を指定し、リポジトリ内のタグを識別します。 注意: このタグは値を含む必要があり、空白にはできません。 |
|
DESCRIPTION |
これはルールの説明です。 |
|
VIOLATION |
このタグは、指定されたルールに対してチェックする違反をリストします。違反は「CSA条件の言語」で指定します。 |
|
SEVERITY |
ルールには、INFO、WARNINGおよびCRITICALの3つの重大度レベルを指定できます。SEVERITYノードには、VIOLATIONノード内の式が使用できる引数と同数の子ARGが含まれている必要があります。ルール・エンジンは、ルールを評価する際、重大度の最も高いCRITICALから順に、重大度レベルで指定された引数セットごとにVIOLATION内の条件を評価します。失敗する条件が検出されるとすぐに、そのルールは失敗が宣言され、ルールの重大度レベルは原因となった引数の重大度レベルと同じになります。指定されたすべてのレベルに対する条件が満たされるている場合、ルールは成功します。 |
|
PARAM |
このタグは、式に代入される引数の値を指定します。このタグのid属性が、式の中の引数の1つの名前と一致している必要があります。 |
|
MOREINFO |
このタグは、失敗したルールの隣に表示される「詳細」ボタンをユーザーがクリックしたときに表示される情報を指定します。MOREINFOの子は、TEXTおよびARGです。 注意: MOREINFOノードは、重大度ノードの子（複数の重大度が指定されている場合）か、またはルール自体の子にすることができます。 |
|
TEXT |
このタグは、「詳細」ボタンをクリックしたときに表示されるテキストを指定します。resource属性は、リソース・バンドル内の文字列を指定します。この文字列が存在しない場合、かわりにノードの値が表示されます。（リソース・バンドルまたはノード自体の中の）テキストでは、{0}、{1}などを使用して挿入する引数の場所を指定できます。この場合、ARGノード内の式が評価され、指定した順序でテキスト内に挿入されます。文字列内に存在するスロット数よりも多くのARGノードが指定されている場合、超過分のノードは無視されます。 |
|
ARG |
このタグは、評価してMOREINFOテキストに挿入できる「CSA条件の言語」内の式を指定します。 |
|
関連項目: 「CSAの開始」ページの詳細は、Enterprise Managerのオンライン・ヘルプ |
管理者は、カスタム・プロパティを収集するためのカスタム・クラスを作成する他に、デプロイメント・ディスクリプタ内にカスタム・プロパティを指定することができます。カスタム・プロパティ名を指定するには、csa value_<name>という形式のコンテキスト・パラメータを含めます。コンテキスト・パラメータ名の<name>フィールドは、クライアント・システム・アナライザ（CSA）によってカスタム・プロパティ名として扱われ、パラメータの値はカスタム・プロパティ値として扱われます。同様に、管理者はパラメータcsa_type_<name>、csa_type_ui_<name>、csa_name_ui_<name>、csa_display_ui_<name>およびcsa_history_tracking_<name>を使用して、type、type_ui、name_ui、display_uiおよびhistory_trackingフィールドをそれぞれ指定できます。また、同じネーミング規則を使用して、CSAアプレットURLに対してカスタム・プロパティを指定することもできます。
次の各項では、クライアント構成のユースケースの例を概説します。
管理者は、2つの異なるWebアプリケーションを使用してユーザーの互換性をチェックできます。1つ目は、多数の各種プラグインを使用してコンテンツを配信するオンライン教育Webサイトです。これにより管理者は、すべてのユーザーが必要なプラグインをインストールしていることを確認できます。2つ目はソフトウェアのディストリビューション・ポータルです。これにより管理者は、ポータルからソフトウェアをダウンロードするすべてのユーザーが必要なハードウェアおよびオペレーティング・システムを使用していることを確認できます。この場合、両方のアプリケーションに固有のルール・セットが必要ですが、管理者は次のリストに示された収集タグを使用することで、両方のアプリケーションに対して1つのCSAインスタンスを使用できます。
teaching、distributionなど、アプリケーションごとに収集タグを選択します。
各アプリケーションに1つずつ、異なる2つのルール・ファイルを作成します。
例20-2に示すように、コンテキスト・パラメータを使用して、各ルール・ファイルを対応するアプリケーションにマップします。
各アプリケーションからCSAへの適切なリンクを作成します。問合せ文字列内で、teachingアプリケーションからのリンクにはapplication=teachingを、distributionアプリケーションからのリンクにはapplication=distributionを含める必要があります。これにより、各アプリケーションのユーザーはCSAの実行時に適切な収集タグを使用できます。
例20-2 ルール・ファイルを選択するための収集タグの使用
<context-param> <param-name>csa teaching ruleFile</param-name> <param-value>teaching_rules.xml</param-value> </context-param> <context-param> <param-name>csa distribution ruleFile</param-name> <param-value>distribution_rules.xml</param-value> </context-param>
例20-2は、ルール・ファイルを選択するための収集タグの使用のみを示しています。しかし、収集タグはどのCSAコンテキスト・パラメータに対しても使用できます。
また、収集タグは、クライアント構成がEnterprise Manager管理リポジトリに格納される方法にも影響を与えます。ユーザーが例20-2のteachingアプリケーションからのリンクを使用してCSAにアクセスした場合、CSAは収集タグteachingのルールを実行する他に、このタグをクライアント構成データとともに管理リポジトリに格納します。収集タグは、クライアント構成の一意の識別子の一部となります。このため、1つのクライアントが管理リポジトリ内に、それぞれ固有のタグを含む複数の構成を持つことが可能になります。クライアント・データへのアクセスを制限するために、収集タグをEnterprise Managerターゲットに関連付けることができます。この場合、Enterprise Managerユーザーがクライアント構成の収集タグに関連付けられたターゲットに対する表示権限を持つ場合に、そのクライアント構成の表示のみが可能です。
たとえば例20-2で、teachingアプリケーションのホスティングにホストH1、アプリケーション・サーバーA1およびデータベースD1が使用され、distributionアプリケーションにホストH2、アプリケーション・サーバーA2およびデータベースD2が使用されるとします。6つのターゲットはすべてEnterprise Managerにより監視されており、ユーザーXはA1、H1およびD1へのアクセス権を、ユーザーYはA2、H2およびD2へのアクセス権を持っています。2人のEnterprise Managerユーザーそれぞれが、アプリケーションの1つに使用されるリソースを監視しているため、各ユーザーがそのアプリケーションのクライアントも監視していると考えられます。その場合、Enterprise Managerのスーパーユーザーは、teachingタグをA1、D1またはH1に関連付け、distributionタグをA2、D2またはH2に関連付けます。これにより、ユーザーXはteachingタグを持つすべてのクライアント構成を表示でき、ユーザーYはdistributionタグを持つすべての構成を表示できます。
Enterprise Managerでクライアント・データへのアクセスを制限するには、収集タグを使用します。ユーザーが表示権限を持つターゲットにクライアント構成の収集タグが関連付けられている場合のみ、ユーザーはそのクライアント構成を表示できます。たとえば、収集タグCがターゲットT1と関連付けられている場合、ターゲットT1を表示できるユーザーのみが、タグXを持つクライアント構成を表示できます。例20-2では、ユーザーXはteachingタグに関連付けられたターゲットに対する表示権限を持つため、teachingタグを持つクライアント構成を表示できます。しかし、distributionタグは、ユーザーXが表示できるどのターゲットにも関連付けられていないため、ユーザーXはdistributionタグを持つクライアント構成を表示できません。スーパーユーザーは、「収集タグの関連付け」ページを使用して、収集タグをターゲットに関連付けることができます。このページには、「デプロイ」タブから、または「設定」ページの「Grid Controlのクライアント・システム・アナライザ」リンクからアクセスできます。スーパーユーザーは、収集タグの関連付けの内容に関係なく、すべてのクライアント構成を表示できます。
通常のCSAデータ以外に電子メール・クライアントのユーザー設定も行う必要のある管理者は、例20-3に示すように、カスタマイズAPIを使用することにより、このデータをCSAにより収集された他のデータに追加できます。
情報の収集に必要なJavaクラスを作成します。管理者はいくつでも必要な数のクラスを作成できますが、少なくとも、oracle.symsan.eml.ecm.csa.CSAResultInterfaceを実装する1つのクラスと、oracle.sysman.eml.ecm.csa.CSACustomIntefaceを実装する1つのクラスが必要です。どちらのクラスも、例20-3に示されています。前者はacme.csa.custom、後者はacme.csa.resultとしています。
CSA内のcustomClassパラメータの値をacme.csa.customに設定します。
例20-3 カスタマイズAPI
public interface CSACustomInterface {
/**
* requires: none
* effects: returns a CSAResultInterface object that may contain custom
* properties. Other effects are determined by the customActions method
* in the implementing class
* modifies: unknown - dependent on implementing class.
* @param inputData contains client config data collected by default, plus
* applet parameters, etc.None of the data in the inputData is guaranteed
* to be there as there could have been collection errors.
* @return a data structure that may contain custom properties
*/
CSAResultInterface customActions(CSAInputInterface inputData);
}
public interface CSAResultInterface {
/**
* requires: none
* effects: returns an array of custom properties
* modifies:none
* @return String[][7] where ...
*
* String[i][0] is a name
* String[i][1] is a value of the i-th row. (Type and name must be unique.)
* String[i][2] is a type/category of data (could be null),
* String[i][3] is the displayed value of the name of the property
* String[i][4] is the displayed value of the type of the property
* String[i][5] indicates data item (ie "Y") whose history should be computed
* String[i][6] indicates data item (ie "Y") should be displayed in default UI
*/
String[][] getResultsData();
}
public interface CSAInputInterface {
/**
* Get data value for given name
* requires: name is not null
* effects: returns the data value associated with the name
* modifies: none
* @param name the name of the key whose value is to be returned
* @return the value assocaited with name
*
*/
String getDataValue(String name);
/**
* Get table-formatted data.
* requires: name is not null
* effects: returns the table with this name
* modifies: none
* @param name the name of the table
* @return the rows of the child tables
*
*/
CSAInputInterface[] getDataTable(String name);
}
カスタム・コードにより収集された追加データは、表MGMT_ECM_CSA_CUSTOMに格納されます。カスタム・コードは、データをこの表に追加するために、CSAResultInterfaceを実装するオブジェクト内にデータを返します。また、アプレットによりcustomActionsメソッドに渡されるCSAInputInterfaceオブジェクトを変更することで、CSAによって収集された標準のデータを操作できます。
カスタム・コードはルールの評価前に実行されるため、管理者はカスタム・データに基づくルールを記述することもできます。たとえば、管理者が、適切なIMAPサーバーでユーザーの電子メール・クライアントが設定されていない場合にクリティカル・エラーが発生するようなルールを記述するとします。この場合、管理者は、IMAPサーバーの設定を取り出してMGMT_ECM_CSA_CUSTOM表に格納するカスタム・コードを記述してから、これらの値をチェックするルールを記述します。
CSAはユーザーのマシン上での管理エージェントの使用には関与しないため、管理リポジトリ内のデータを最新の状態に保つには、エンド・ユーザーがCSAを定期的に実行するしかありません。これを確実に行うために、ユーザーがCSAを最近実行したかどうかをチェックし、実行していなければCSAを再び実行するようユーザーに通知するという方法があります。このチェックは、Oracleが提供するCSAサーブレット・フィルタを使用して実施できます。
CSAサーブレット・フィルタは、ユーザーのブラウザが実行されるたびに、CSAで設定されたCookieをチェックします。このCookieのペイロードによりCSAの最後の実行時刻が示されます。このフィルタを使用するには、管理者が、頻繁にアクセスされるアプリケーション（従業員ポータルなど）の前にこのフィルタを配置します。次に、ユーザーがCSAを実行する時間間隔を設定します。ユーザーがポータル・アプリケーションへの接続を試行するたびに、フィルタがそのリクエストを遮断し、CSA Cookieをチェックします。Cookieが存在しない場合、またはその存続期間が管理者が指定した実行間隔を超過している場合、ユーザーはCSAページにダイレクトされます。それ以外の場合、ユーザーはアプリケーションへの接続を許可されます。
たとえば、Acme CorporationのCSAインスタンスがwww.acme.com/csa/CSA.jspにデプロイされているとします。また、この会社のポータルがwww.acme.com/portalにあり、従業員はこのポータルを使用して電子メールのチェック、個人情報へのアクセス、または会社に関連するニュースを表示できるとします。ポータルは従業員によって頻繁にアクセスされるため、Acmeの管理者は、CSAデータを最新の状態に保つためにこのポータルを使用することにします。この場合、管理者は次の手順を実行します。
CSAサーブレット・フィルタ・クラスをダウンロードします。これらのクラスはJARファイルのCSA_filter.jarに含まれています。このファイルは、Enterprise Manager Grid Controlコンソールの「クライアント・システム・アナライザ・アプリケーションのデプロイ」ページからダウンロードできます。
JARファイルを、フィルタを適用するアプリケーションのWEB-INF/libディレクトリ内に置きます。
フィルタのコンテキスト・パラメータを指定します。ここでは、管理者が30日に1回ユーザーにCSAを実行させ、CSAの完了後にユーザーをポータルのホームページに戻すとします。
<context-param> <param-name>csa csaURL</param-name> <param-value>www.acme.com/csa/CSA.jsp</param-value> </context-param> <context-param> <param-name>csa execInterval</param-name> <param-value>2592000</param-value> </context-param>
バックグラウンドの別個のブラウザ・ウィンドウ内でCSAを実行する方法もあります。これを設定するには、csa_uiModeパラメータを使用します。このパラメータを1に設定した場合、フィルタは最初のウィンドウと同じサイズの新しいブラウザ・ウィンドウを開き、CSAページに移動します。パラメータを2に設定した場合、CSAは不可視モードで実行されます。この場合、フィルタは新しいブラウザ・ウィンドウを開くとすぐに最小化し、CSAが完了すると同時にウィンドウを閉じます。
次のデプロイ例では、主要な3つの要素が登場します。1つ目は、CSAの設定を行うCSA管理者です。2つ目は、Enterprise Managerでクライアント・データを表示するEnterprise Managerユーザーです。3つ目はエンド・ユーザーです。エンド・ユーザーのデータはCSAにより収集されます。
この例では、CSA管理者はCSAを使用してヘルプデスクの業務をサポートしています。特定のアプリケーションの実行で問題が発生すると、エンド・ユーザーはカスタマ・サポートをコールできます。カスタマ・サポートの技術担当者は、必要に応じて、特定のURLにアクセスしてCSAを実行するようにユーザーに指示できます。Enterprise Managerユーザーは、CSAにより収集されたデータを使用してエンド・ユーザーをアシストするサポート担当者です。顧客の問題を診断するプロセスの時間を短縮するため、CSA管理者は、ヘルプデスク担当者が考えられる問題を素早く特定できるよう、rules.xmlというファイル内にいくつかのルールを作成します。最も単純な例として、1つのアプリケーションのサポートを行うヘルプデスクを設置するとします。アプリケーションはホストapplication.acme.com上のアプリケーション・サーバーで実行されています。このホストにはEnterprise Managerの管理エージェントがインストールされており、この管理エージェントが、oms.acme.com/emにある管理サービスにデータを戻します。クライアント・データを確認しようとするヘルプデスク担当者は、ユーザーhelpdeskとしてEnterprise Managerにログインできます。このユーザーにスーパーユーザー権限はありません。
CSA管理者は、CSA.earに含まれているCSA.warファイルにrules.xmlを追加します。
Application Services Controlコンソールを使用して、EARファイルをアプリケーション・サーバーにデプロイします。
Application Services Controlコンソールを使用して、ruleFileやoutputDirなどの必要なコンテキスト・パラメータを設定します。
オプションで、管理者は、applicationコンテキスト・パラメータの値を指定してCSAデータの収集タグを選択できます。タグを選択しない場合、タグDefaultが使用されます。
スーパーユーザー権限を持つEnterprise Managerユーザーは、application.acme.comにある管理エージェントにCSAコレクタ・ターゲットを追加し、その受信ファイル・ディレクトリを、CSAのoutputDirパラメータで指定されているディレクトリに設定します。
Enterprise Managerスーパーユーザーは、helpdeskユーザーにデータの参照を許可するために必要な収集タグの関連付けを作成します。たとえば、スーパーユーザーはタグDefaultをホストapplication.acme.comに関連付け、そのホストに対する表示権限をhelpdeskというEnterprise Managerユーザーに付与します。
前述の設定では、ユーザーがヘルプデスクをコールしてアプリケーションのサポートを依頼すると、ヘルプデスクの技術担当者は、application.acme.comにある適切なURLからCSAを実行するようにユーザーに指示できます。管理エージェントは、一定時間の経過後にデータを収集し、そのデータを管理リポジトリにロードします。ヘルプデスクの技術担当者は、helpdeskとしてEnterprise Managerにログインし、顧客のオペレーティング・システム・ユーザー名やホスト名などの識別フィールドを検索して顧客情報を見つけることができます。デフォルトでは、管理エージェントは2分ごとに出力ディレクトリの新しいデータをチェックします。ただし、$ORACLE_HOME/sysman/admin/default_collection/oracle_csa_collector.xmlファイルを編集することで、この時間間隔は短くできます。
例20-4では、システム管理者が、人事管理（HR）部と販売部の2つの部署の従業員が使用するハードウェアおよびソフトウェアを監視します。この管理者は、Enterprise Managerユーザーでもあり、CSA管理者でもあります。この例の設定は、サーブレット・フィルタの使用例で説明した設定と似ていますが、ここでは、各部署がそれぞれのポータル・アプリケーションをhr.acme.com/portalおよびsales.acme.com/portalに置いています。管理者はホストserver1.acme.com上にアプリケーション・サーバーを設定し、URL http://server1.acme.com/csa/CSA.jspを使用してCSAをデプロイします。server1.acme.comの管理エージェントは、データを収集し、それをoms.acme.com/emにある管理サーバーに送信します。管理者は30日に1回データを収集し、不可視モードでCSAを実行しようとしています。また、2つの異なる部署のデータを、hrおよびsalesという異なる収集タグを使用して区別しようとしています。管理者は、sysmanとしてEnterprise Managerにログインできるため、両方のタグを持つクライアントを表示できます。
管理者は、両方のアプリケーションにCSAサーブレット・フィルタをデプロイすることによって、ユーザーがCSAにダイレクトされるように調整します。2つのアプリケーションのフィルタ・コンテキスト・パラメータの大部分は同じです。ただし、各アプリケーションは別々のタグに対応しているため、csa csaURLパラメータの値は少し異なります。HRポータルの値はhttp://server1.acme.com/csa/CSA.jsp?application=hrであり、販売ポータルの値はhttp://server1.acme.com/csa/CSA.jsp?application=salesです。
例20-4 インベントリ・コード
<context-param> <param-name>csa csaURL</param-name> <param-value>www.acme.com/csa/CSA.jsp?application=sales</param-value> </context-param> <context-param> <param-name>csa execInterval</param-name> <param-value>2592000</param-value> </context-param> <context-param> <param-name>csa uiMode</param-name> <param-value>2</param-value> </context-param>
この設定では、HRポータルからCSAにダイレクトされるHR部のユーザーはタグhrを持ち、販売部のユーザーはタグsalesを持ちます。このため、管理者がHR部のマシン上のハードウェアのみの情報を表示しようとする場合には、Enterprise Managerで「クライアント構成」ページの「収集タグ」フィルタを使用し、単にこれをhrに設定します。
この例では、CSAを使用して、アプリケーションの実行中に発生する可能性のある問題をエンド・ユーザーに通知することが最終的な目標です。設定は例2で使用した設定と似ていますが、この例では、CSA管理者はアプリケーションごとにルールを作成します。また管理者は、エンド・ユーザーが可能性のある問題を確認できるように、最初のブラウザ・ウィンドウ内でCSAを実行することにしています。
例20-5は、販売ポータル上のCSAサーブレット・フィルタのコンテキスト・パラメータ値を示しています。
例20-5 CSAサーブレット・フィルタのコンテキスト・パラメータ値
<context-param> <param-name>csa csaURL</param-name> <param-value>www.acme.com/csa/CSA.jsp?application=sales</param-value> </context-param> <context-param> <param-name>csa execInterval</param-name> <param-value>2592000</param-value> </context-param> <context-param> <param-name>csa uiMode</param-name> <param-value>0</param-value> </context-param>
例20-6は、ルールを収集タグにマップするためのコンテキスト・パラメータ定義を示しています。
権限委譲プロバイダとは、別のユーザーの権限を使用してアクティビティを実行することをログイン・ユーザーに許可するプログラムのことです。通常、特定のユーザーに付与される権限は、集中管理されます。
Enterprise Managerの優先資格証明を使用すると、次の2つのタイプの権限委譲プロバイダを使用できます。
sudoの場合、許可されているユーザーは、sudoユーザー管理ファイル（sudoers）で指定されているsuperユーザーまたは他のユーザーとしてコマンドを実行できます。コマンド起動元のユーザーがrootである、またはターゲット・ユーザーがコマンド起動元のユーザーと同じ場合は、パスワードが不要です。そうでない場合はデフォルト時、ユーザーはパスワードを使用して自分自身の認証を実行する必要があります。
|
注意: デフォルト構成の場合、これは該当ユーザーのパスワードであり、rootのパスワードではありません。 |
sudoでは、ユーザーに権限が付与されているかどうかは、/etc/sudoersファイルをチェックして判断されます。ユーザーが認証されると、タイムスタンプが更新され、該当ユーザーはパスワードなしで短期間（sudoersファイル内で上書きされないかぎり5分間）sudoを使用することができます。
Symark PowerBrokerの場合、UNIXのシステム管理者は、root（または他の重要なアカウント）として特定のプログラムを他のユーザーが実行できる環境を指定できます。そのため、ユーザー・アカウントの追加やライン・プリンタ・キューの固定といったアクションの担当を、rootのパスワードを公開することなく、適切な要員に安全に割り当てることができます。その結果、rootの権限全体を、データベースやファイルの権限の変更、ディスクの消去といった誤用や乱用から保護することができます。
Symark PowerBrokerは、一般的なシステム管理タスクを実行する既存のプログラムや、その独自のユーティリティ・セットにアクセスすることができます。Symark PowerBroker上で動作するように開発されているユーティリティでは、パスワード、アカウント、バックアップ、ライン・プリンタ、ファイルの所有権や削除、再起動、ユーザーのログアウト、ユーザー・プログラムの中断、どのユーザーがどこからどこにログインが許可されているかのチェックなどを管理することができます。また、TCP/IP、ロード・バランサ、cron、NIS、NFS、FTP、rlogin、アカウンティング・サブシステムの管理も提供できます。ユーザーは、制限付きのシェルやエディタを使用し、rootとして特定のプログラムやファイルにアクセスすることができます。
sudoおよびPowerBrokerの詳細は、各製品のドキュメントを参照してください。
Enterprise Managerのコマンドライン・インタフェース（EMCLI）を使用すると、ユーザーはホストの権限委譲プロバイダ・プロパティの設定や編集を実行できます。詳細は、『Oracle Enterprise Managerコマンドライン・インタフェース』を参照してください。設定および構成の詳細は、権限委譲プロバイダに関するドキュメントを参照してください。
権限委譲設定は、EM CLIコマンドライン・インタフェースのcreate_privilege_delegation_setting動詞により作成できます。
また、権限委譲設定を使用したホストの構成、権限委譲設定テンプレートの適用、または権限委譲設定の構成解除を行うには、Enterprise Managerのホームページで「設定」をクリックし、左側のメニュー・パネルから「権限委任設定の管理」を選択します。
EMCLIのcreate_privilege_delegation_setting動詞を使用すると、sudo権限委譲設定を作成できます。明示的な構文および例については、EMCLIのコマンドライン・ヘルプまたは『Oracle Enterprise Managerコマンドライン・インタフェース』を参照してください。
変数
EMCLIを使用して権限委譲設定を設定する際は、次の変数を使用できます。変数では大文字と小文字が区別されます。
| 変数 | 定義 |
|---|---|
| %RUNAS% | コマンドを実行するユーザー。 |
| %USERNAME% | コマンドを実行するユーザーの名前。 |
| %COMMAND% | sudoコマンド |
構文
emcli create_privilege_delegation_setting -setting_name=sudo_setting_1 -setting_type=SUDO -settings="SETTINGS:<command to be used with all the options>"
次の例は、EMCLIを使用してsudo設定を作成する方法を示しています。この場合、sudoは/opt/sudo/binにインストールされています。
EM CLIのcreate_privilege_delegation_setting動詞を使用すると、PowerBroker権限委譲設定を作成できます。
変数
EMCLIを使用して権限委譲設定を設定する際は、次の変数を使用できます。変数では大文字と小文字が区別されます。
| 変数 | 定義 |
|---|---|
| %RUNAS% | コマンドを実行するユーザー。 |
| %USERNAME% | コマンドを実行するユーザーの名前。 |
| %COMMAND% | sudoコマンド |
| %PROFILE% | コマンドの実行に使用するプロファイル。 |
構文
>emcli create_privilege_delegation_setting -setting_name=powerbroker_setting_1 -setting_type=POWERBROKER -settings="SETTINGS:<command to be used with all the options>;[PASSWORD_PROMPT_STRING,<password prompt for PowerBroker>]"
例20-8 EMCLIを使用したsudo設定の作成
./emcli create_privilege_delegation_setting -setting_name=sudo_setting_1 -setting_type=SUDO -settings="SETTINGS: /opt/powerbroker/bin/pbrun –u %RUNAS% %command%"
|
注意: この例の場合、PowerBrokerは/opt/powerbrokerディレクトリにインストールされており、そのパスワード・プロンプトは"Password:"です。 |
権限委譲設定は、作成し終わったら、選択したターゲットに適用する必要があります。権限委譲設定の作成プロセスの場合と同様に、権限委譲設定はEMCLIを使用して、指定したターゲットに適用します。この設定は、1つまたは複数のホスト、あるいはコンポジット（グループ）ターゲット（グループには、ホスト・ターゲットが1つ以上含まれていること）に適用できます。
また、権限委譲設定を適用するには、Grid Controlコンソールを使用して、Enterprise Managerのホームページで「設定」をクリックし、左側のメニュー・パネルから「権限委任設定の管理」を選択します。
EMCLIのapply_privilege_delegation_setting動詞を使用すると、権限委譲設定をホスト・ターゲットに適用できます。
構文
emcli apply_privilege_delegation_setting -setting_name=<setting name> -target_type=host -target_names="host1;host2;..."-input_file="FILE:hosts.txt" -force="yes/no"
権限委譲プロパティを多数のホストに適用する場合は、次の例のように、-target_namesオプションのかわりに-input_fileオプションを使用して、すべてのホストが含まれるファイルを指定することができます。
EMCLIのapply_privilege_delegation_setting動詞を使用すると、権限委譲設定をコンポジット（グループ）ターゲットに適用できます。
構文
emcli apply_privilege_delegation_setting -setting_name=<setting name> -target_type=composite -target_names="group" -force="yes/no"
例20-10 EMCLIを使用したコンポジット・ターゲットへの権限委譲設定の適用
./emcli apply_privilege_delegation_setting -setting_name=<setting name> -target_type=composite -input_file="FILE: /mydirectory/file.txt" -force=yes
ホスト・ターゲットに対する権限委譲設定の適用に成功したら、EMCLIまたはGrid Controlコンソールを使用して、ホスト・ターゲットの優先資格証明を設定できます。
管理者は、ステータスが無効な新しい権限委譲設定を作成し、それをターゲットに適用すると、権限委譲設定を無効にすることができます。この無効な設定は、任意の権限委譲プロバイダ（sudo/PowerBroker）に適用できます。これにより、権限委譲設定をホストから削除できます。
新しい権限委譲設定を作成します。
./emcli create_privilege_delegation_setting -setting_name= disabled_setting -setting_type=SUDO –disabled=yes
新しい設定を1つまたは複数のターゲットに適用します。
./emcli apply_privilege_delegation_setting -setting_name= disabled_setting -target_type=host -target_names="host1;host2;..." -force=yes
Enterprise Managerで使用する信頼ベースのモデルでは、高度の粒度で職責を指定できます。管理者は、sudoまたはpbrunの構成エントリを設定し、Enterprise Managerの特定機能の権限をそのOSユーザーに割り当てることができます。管理エージェントには、nmosudoという新しい実行可能ファイルが導入されています。管理者は、sudo/pbrunを構成することにより、権限の低いユーザーが権限の高いユーザーとしてnmosudoを実行できないようにすることができます。
次の例で、管理者がユーザーjoeに任意のEnterprise Managerジョブをユーザーoracleとして実行させる場合、/etc/sudoersファイル内の対応するエントリは次のようになります。
(JOB_USERS) ALL : (RUNAS_USERS) AGENT_HOME /bin/nmosudo *
ここで、joeはJOB_BACKUP_USERSリストの中、oracleはRUNAS_USERSリストの中にあります。
Enterprise Managerにより、実行可能ファイルnmosudoは、OMSからエージェントを介したリモート操作実行要求のみを受け取ることが保証されます。nmosudoは、要求がエージェントからのものであることを検証できないと、該当するリモート操作を実行しません。そのため、前述の例で示したように、ユーザーjoeがnmosudoをコマンドラインから直接起動し、ユーザーoracleとしてPerlスクリプトを実行することはできません。
|
注意: システムのセキュリティを確保するために、管理者は実行可能ファイルnmosudoに対するフルパスを設定する必要があります。 |
Enterprise Manager Grid Controlコンソールでは、ユーザー・インタフェースにより提供される機能を介して、権限委譲プロバイダを構成できます。Grid Controlを使用すると、コマンドライン・インタフェースを使用しなくても、それと同等の機能を実行できます。
次の各項で、Grid Controlインタフェースを使用して実行できる機能について説明します。
Enterprise ManagerでGrid Controlコンソールを使用して、sudo設定を作成できます。権限委譲設定を作成するには、ホスト・ターゲットに設定を直接作成するか、または複数のホストに適用できるPDP設定テンプレートを作成します。
権限委譲sudo設定をホストに直接作成するには、次の手順を実行します。
「権限委任設定の管理」ページにナビゲートします。このページは、「設定」→「権限委任設定の管理」を選択すると表示されます。
この表に表示されているいずれかのホスト・ターゲットに対して、「編集」をクリックします。Enterprise Managerで「ホスト権限委任設定」ページが表示されます。
「sudo」権限委譲タイプを選択します。
使用する権限委譲コマンドを入力します。
「更新」をクリックして、設定をホストに適用します。
図20-1は、sudo設定を作成できる「ホスト権限委任設定」ウィンドウを示しています。
|
注意: ホストがsudoかPowerbrokerのいずれかの設定で構成されている場合、このページで「なし」を選択すると、設定が削除（無効化）されます。 |
権限委譲設定を作成するには、ホスト・ターゲットに設定を直接作成するか、または複数のホストに適用できるPDP設定テンプレートを作成します。
権限委譲PowerBroker設定をホストに直接作成するには、次の手順を実行します。
「権限委任設定の管理」ページにナビゲートします。このページは、「設定」→「権限委任設定の管理」を選択すると表示されます。
この表に表示されているいずれかのホスト・ターゲットに対して、「編集」をクリックします。Enterprise Managerで「ホスト権限委任設定」ページが表示されます。
「PowerBroker」権限委譲タイプを選択します。
使用する権限委譲コマンドと、オプションのパスワード・プロンプトを入力します。
「更新」をクリックして、設定をホストに適用します。
図20-2は、PowerBroker設定を作成できる「ホスト権限委任設定」ウィンドウを示しています。
|
注意: ホストがsudoかPowerbrokerのいずれかの設定で構成されている場合、このページで「なし」を選択すると、設定が削除（無効化）されます。 |
権限委譲設定テンプレートを使用して、権限委譲設定をターゲットに適用します。目的の権限委譲設定を持つテンプレートが存在しない場合は、まず、図20-3に示すような「権限委任設定テンプレートの管理」ページでテンプレートを作成する必要があります。
テンプレートを作成するには、次の手順を実行します。
「権限委任設定の管理」ページにナビゲートします。このページは、「設定」→「権限委任設定の管理」を選択すると表示されます。
「関連リンク」セクションで「権限委任設定テンプレートの管理」をクリックします。
権限委譲タイプ（「sudo」または「PowerBroker」）を選択し、「実行」をクリックします。
必要な権限委譲設定情報を入力します。
「保存」をクリックします。
目的の権限委譲設定テンプレートがすでに存在する場合は、そのテンプレートを目的のホストに適用するだけです。テンプレートをホストに適用するには、次の手順を実行します。
「権限委任設定の管理」ページにナビゲートします。このページは、「設定」→「権限委任設定の管理」を選択すると表示されます。
「適用」ドロップダウン・メニューから、目的の権限委譲設定テンプレートを選択します。
「実行」をクリックして、「設定の適用」ページにアクセスします。
権限委譲設定テンプレートを適用するターゲット（ホスト）を追加します。
「適用」をクリックします。Enterprise Managerで「前の適用操作」ページが表示されます。このページに、予定されている適用操作のキューと、予定されている操作または保留中の操作が表示されます。このページから、「停止」または「削除」の適用操作を実行できます。
また、図20-3に示すような「権限委任設定テンプレートの管理」ページからも権限委譲設定を適用できます。
Grid Controlコンソールを使用して、権限委譲設定を無効化できます。この方法を使用して権限委譲設定を無効化するには、次の手順を実行します。
「設定」をクリックして、「Enterprise Manager構成」ページにアクセスします。
左側のメニューから「権限委任設定の管理」をクリックします。
Grid Controlで、図20-4に示すような「権限委任設定の管理」ページが表示されます。
権限委譲設定をクリアするホストを選択します。
「クリア」をクリックします。Enterprise Managerで、権限設定無効化操作を続行するかどうか確認を求められます。
「はい」をクリックします。
WebLogic Serverには、短いホスト名（CN=<short hostname>）を参照するデモ用証明書が付属しています。本番環境用の適切な証明書を用意することをお薦めします。また、URLで完全なホスト名を使用している場合、URLのホスト名が証明書の短いホスト名と一致しないため、警告が表示されます。
自己署名付き証明書をインストールするには、次のコマンドを実行します。
DOMAIN_HOME/bin/secureWebLogic.sh -admin_host <hostname> -admin_port <port#> -admin_user <username> [-admin_pwd <pwd>]
Windowsプラットフォームの場合は、次のコマンドを使用します。
DOMAIN_HOME\bin\secureWebLogic.bat -admin_host <hostname> -admin_port <port#> -admin_user <username> [-admin_pwd <pwd>]
エージェントのセキュリティを有効化にするには、次のコマンドを実行します。
ORACLE_HOME/bin/emctl secure fmagent -admin_host <hostname> -admin_port <port#> -admin_user <username> [-admin_pwd <pwd>]
Windowsプラットフォームの場合は、次のコマンドを使用します。
ORACLE_HOME\bin\emctl.bat secure fmagent -admin_host <hostname> -admin_port <port#> -admin_user <username> [-admin_pwd <pwd>]
