| Oracle Access Managerアップグレード・ガイド 10g（10.1.4.2.0） E05837-01 |
|
 戻る |
 次へ |
インストールにアクセス・システムのコンポーネントが含まれていない場合は、この章をスキップしてください。この章は、ディレクトリのスキーマおよびデータの管理と更新を担当するディレクトリ・サーバーの管理者を対象としています。
この章では、アクセス・システムのスキーマおよびデータのインプレース・アップグレードに必要な作業とその順序を示します。内容は次のとおりです。
|
注意: 停止時間ゼロのメソッドを使用している場合は、この章をスキップして第VI部を参照してください。アップグレード元のOracle Access Managerが6.1.1より前のリリースである場合は、アップグレードの前にOracleサポート・サービスにお問い合せください（http://www.oracle.com/support/contact.html）。 |
アイデンティティ・システムのスキーマおよびデータのアップグレード（マスター・アイデンティティ・サーバーの使用とマスターWebPassのアップグレードを含む）が終了したら、アクセス・システムのスキーマおよびデータをアップグレードできます。
図7-1は、アクセス・システムのスキーマおよびデータのアップグレード・タスクを示しています。この図からわかるように、このアップグレードを実行して検証する作業に加え、後でアクセス・システムのコンポーネントをアップグレードするための一時ディレクトリ・プロファイルの作成が必要です。図の後には説明が続きます。各自の計画の概要を参照し、付録Fの追跡の概要を使用して進捗状況を確認してください。
タスクの概要: アクセス・システムのスキーマおよびデータのアップグレード
第5章のスキーマとデータの準備タスクをすべて実行します。
新しく追加したマスターAccess Managerをアップグレードし、「マスターAccess Managerコンポーネントのスキーマおよびデータのアップグレード」の説明に従って、スキーマおよびデータの自動アップグレードを受け入れます。
アップグレードが成功した場合: 次にリストするアクティビティを順に実行します。
アクセス・システムをアップグレードするための一時ディレクトリ・プロファイルの作成。これにより、アクセス・サーバーにポリシー・データへの書込み権限が付与され、WebGatestatic.lstファイルの情報が必ず適切にディレクトリ・サーバーへ書き込まれます。
アップグレードが成功しなかった場合: 「アクセス・システムのスキーマまたはデータのアップグレードの失敗からのリカバリ」に進みます。
このタスクでは、この目的のために追加したマスターAccess Managerコンポーネント（現在はポリシー・マネージャと呼ばれる）のインスタンスをアップグレードし、次に、スキーマおよびデータの自動アップグレードを受け入れます。
図7-2は、プログラムによるアップグレード・プロセスと、このアップグレードにおいてユーザーが応答する必要があるポイントを示しています。
タスクの概要: アクセス・システムのスキーマおよびデータのアップグレード
マスターAccess Managerのアップグレードを開始する前に、表7-1のタスクをチェックし、これらが実行されていることを確認します。
前提条件が満たされていないと、アップグレードに悪影響が生じる場合があります。
表7-1 アクセス・システムのスキーマおよびデータのアップグレードの前提条件
| アクセス・システムのスキーマおよびデータのアップグレードの前提条件 |
|---|
|
第I部「概要」の内容をよく理解している。 |
|
第5章のスキーマとデータの準備に必要なステップをすべて実行しておく。
|
|
第6章の説明に従って、アイデンティティ・システムのスキーマおよびデータをアップグレードし、アップグレードされたデータをバックアップする。 |
使用する特定のWebサーバーのアップグレードを開始するには、ここでも10g（10.1.4.0.1）ポリシー・マネージャ・インストーラを使用します。ここで説明するアップグレード例は、リリース6.1.1からアップグレードする場合です。記載されているメッセージ、入力する応答、および一連のイベントの例は、GUIメソッドと自動モード（推奨）を使用した場合のものです。アップグレード元リリースや環境は同じでなくてもかまいません。
アクセス・システムのスキーマおよびデータのアップグレードを開始する手順（マスターAccess Manager）
「アクセス・システムのスキーマおよびデータのアップグレードの前提条件」にリストされている、このアップグレードの前提条件がすべて満たされていることを確認します。
スキーマおよびOracle Access Managerファイルをアップグレードできる管理者権限のあるユーザーとしてログインします。
マスターAccess ManagerのWebサーバーを停止します。
10g（10.1.4.0.1）のポリシー・マネージャ・インストーラを特定し、次のうち該当するメソッドで起動します。
WindowsのGUIメソッド:
Oracle_Access_Manager10_1_4_0_1_Win32_NSAPI_PolicyManager.exe
Solarisのコンソール・メソッド:
./Oracle_Access_Manager10_1_4_0_1_sparc-s2_NSAPI_PolicyManager
「ようこそ」画面が表示されます。
「ようこそ」画面を閉じます。
プラットフォーム固有の管理者確認画面に応答します。次に例を示します。
マスターAccess Managerコンポーネントと同じターゲット・ディレクトリを指定します。アップグレードを受け入れた場合は、ターゲット・ディレクトリが作成され、10g（10.1.4.0.1）ファイルがそのディレクトリに抽出されます。続いて、アップグレードする言語を選択するよう求められます。
Access Managerのターゲット・ディレクトリと言語を指定する手順
追加したインスタンスをインストールしたディレクトリを選択して、「次へ」をクリックします。
「はい」をクリックしてアップグレードに同意し、「次へ」をクリックします。
「英語」やその他のアップグレード対象の言語の横に必ずチェックマークを付け、「次へ」をクリックします。
リストされた言語を確認します。
タイムスタンプの付いたディレクトリ名を記録し、次に進みます。
必要なディスク領域量を記録して、ターゲット・ディレクトリへのファイルの抽出を開始します。
アップグレード・プロセスのモード（自動モードまたは確認モード）を指定するよう求められます。
コンソール・メソッドを使用している場合は、インストール・スクリプトが終了してトランスクリプトが表示されます。トランスクリプト内のコマンドを実行し、続いてステップ9に進みます。（UNIXの場合は、コマンドがファイル（start_migration）に出力され、このファイルを実行するよう指示するメッセージが出力されます。）
数字を選択し、表示されるメッセージを確認します。次に例を示します。
1
Creating orig folders ... ---------------------------------------------------- Copying general configuration files OK. ---------------------------------------------------- Updating parameter catalogs ... OK. ----------------------------------------------------
次の「アクセス・システムのスキーマとポリシー・データの更新」に進みます。
スキーマおよびデータの自動更新を受け入れることをお薦めします。アクセス・システムのスキーマおよびデータは次のようにアップグレードされます。
Oracle Access Managerのポリシー・データがユーザー・データおよび構成データと同じディレクトリに格納されている場合、スキーマはマスター・アイデンティティ・サーバーのアップグレード中に更新されています。したがって、この場合は、ポリシー・データのみがマスターAccess Managerのアップグレードで更新されます。
Oracle Access Managerのポリシー・データがユーザー・データおよび構成データとは別の場所に格納されている場合は、スキーマとポリシー・データの両方がマスターAccess Managerのアップグレード中にアップグレードされます。
最初の更新は自動的に検出されるため、Access Managerの残りのアップグレード処理において、スキーマやデータの更新について尋ねられることはありません。
リリース6.5以降、アクセス・システムは、ユーザー・データへのアクセスに対して、ディレクトリ・サーバー・プロファイルとデータベース・インスタンス・プロファイルの使用を開始しました。その結果、6.1.1から6.5への段階的アップグレード中に、ディレクトリ・サーバー・プロファイルが作成されたことを示すメッセージ（「DB Profiles created.」）が表示されます。このメッセージは、次の手順に例として含まれています。アップグレード元リリースが6.5以降の場合、このメッセージは表示されません。
アクセス・システムのスキーマとポリシー・データをアップグレードする手順
メッセージを確認し、ディレクトリ・パスが表示されたら記録します。
-------------------------------------
Starting migration 6.1.1 -> 6.5.0 )...
-------------------------------------
Oracle Access Manager schema migration....
Retrieving Policy configuration parameters...
OK.
-------------------------------------
Oracle Access Manager data migration....
Retrieving Policy configuration parameters...
OK.
Checking Access Policy version
Version not up to date. Performing Access Policy data migration
Updating Access Policy migration parameters..
The following directory server's schema will be updated:
Host:DNShostname.domain.com
Port: port#
Type:ns
NOTE: If you do not want to migrate schema at this time,
type 'SKIP'.
Please type 'yes' to proceed:
フルスペルでyesと入力し、ポリシー・データの更新（スキーマのアップグレードを伴うこともある）を行います。次に例を示します。
Yes
OK
続いて、トランスクリプトが表示されます。
------------------------------------- Converting Access Policy data. Please wait.. ..... OK Removing old Access Policy data. Please wait .. ........ OK Importing new Access Policy data. Please wait ... OK ----------------------------- Oracle Access Manager data migration has completed successfully. Press <ENTER> to continue :
データのアップグレードが完了したら[Enter]キーを押し、Oracle Access Managerの構成パラメータの取得とデータベース・プロファイルの作成に進みます（アップグレード元リリースが7.xの場合、「DB Profiles created.」というメッセージは表示されません）。
-------------------------------------
Retrieving Oracle configuration parameters...
DB Profiles created.
-----------------------------
この手順では、マスターAccess Managerのコンポーネントの構成をアップグレードします。これには、Webサーバー構成とポリシー・データの構成パラメータの更新が含まれます。
WebサーバーとAccess Managerの構成をアップグレードする手順
メッセージを確認し、環境についての質問に適切に応答します。
-------------------------------------
Updating web server configuration files...
Connecting to server ...Done.
OK.
-------------------------------------
Updating component-specific configuration files...
OK.
-------------------------------------
Starting migration ( 6.5.0 -> 7.0.0 )...
-------------------------------------
Oracle Access Manager schema migration....
Retrieving Policy configuration parameters...
OK.
-------------------------------------
Checking Access Policy version ...
Version not up to date. Performing Access Policy data migration ...
Updating Access Policy migration parameters...
The following directory server's schema will be updated:
Host:DNShostname.domain.com
Port: port#
Type:ns
NOTE: If you do not want to migrate schema at this time,
type 'SKIP'.
Please type 'yes' to proceed:
指示に従ってアップグレードを進めます。
yes
プロセスが続行され、次が表示されます。
Converting Access Policy data. Please wait... ..... OK. Removing old Access Polidy data. Please wait ... ..... OK. Cleaning up obsolete schema from the directory. Deleting Obsolete schema for policy. Please wait. Importing new Access Policy data. Please wait... OK. ----------------------------------------- Oracle Access Manager data migration has completed successfully. Press <ENTER> to continue :
データがアップグレードされたら応答し、次にWebサーバー構成とコンポーネント固有のアップグレードが行われることを確認します。
Enter
-------------------------------------
Updating web server configuration files...
OK.
-------------------------------------
Updating component-specific configuration files...
OK.
-------------------------------------
Starting migration ( 6.5.0 -> 7.0.0 )...
-------------------------------------
Oracle Access Manager schema migration....
Retrieving Policy configuration parameters...
OK.
-------------------------------------
Oracle Access Manager data migration....
Retrieving Policy configuration parameters...
OK.
-------------------------------------
Checking Access Policy version ...
Version not up to date. Performing Access Policy data migration ...
Updating Access Policy migration parameters...
The following directory server's schema will be updated:
Host:DNShostname.domain.com
Port: port#
Type:ns
NOTE: If you do not want to migrate schema at this time,
type 'SKIP'.
Please type 'yes' to proceed:
フルスペルで「yes」と入力して、次に進みます。
yes
OK.
Converting Access Policy data. Please wait...
OK.
Removing old Access Policy data. Please wait ...
OK.
Importing new Access Policy data. Please wait...
OK.
----------------------------------------
Oracle Access Manager data migration has completed successfully.
Press <ENTER> to continue :
リリース7.0から10g（10.1.4.0.1）へのアップグレードの場合は、必要に応じて、コンポーネント固有の構成に進みます。
Enter
Updating component-specific configuration files.
...
Converting Access Policy data. Please wait...
OK.
Removing old Access Policy data. Please wait ...
OK.
Importing new Access Policy data. Please wait...
OK.
----------------------------------------
Oracle Access Manager data migration has completed successfully.
Press <ENTER> to continue :
Directory permissions copied ... C:\NetPoint\WebComponent\access_20060223_180406\oblix)
C:\NetPoint\WebComponent\access\oblix)
---------------------------------------------------
Migration has completed successfully!
Press <ENTER> to continue.
このフェーズの完了後、画面の指示に従って作業を進め、「アクセス・システムのスキーマおよびデータのアップグレードの終了確認」に進みます。
次の手順に従って、マスターAccess Managerのアップグレードの終了の確認を行います。
アクセス・システムのスキーマおよびデータのアップグレードの終了を確認する手順
必要に応じて、Webサーバー構成ファイルの変更内容を反映します。
アップグレード済のAccess Manager Webサーバーを起動して、アップグレードが成功したかどうかを確認します。
Webサーバーが起動しない場合: 付録Gのトラブルシューティングのヒントを参照してください。
Access Managerの移行ログ・ファイルとエラーLDIFにエラーが記録されていないかどうかを確認します。「ログ・ファイルへのアクセス」を参照してください。
アップグレードが成功した場合: 「ディレクトリ・サーバーの索引ファイルのアップロード」に進み、アクセス・システムのスキーマおよびデータの属性を必ずすべて索引付けの対象とします（また、obpolicykeyword属性に手動で索引を追加します）。
アップグレードが成功しなかった場合: 「アクセス・システムのスキーマまたはデータのアップグレードの失敗からのリカバリ」に進みます。
|
注意: Access Managerコンポーネントの新しい製品名はポリシー・マネージャです。このマニュアルでは、これ以降ポリシー・マネージャと表記します。詳細は、「製品およびコンポーネントの名前の変更」を参照してください。 |
この手順は、アイデンティティ・システムのスキーマおよびデータをアップグレードした後に行った手順と同様です。
アクセス・システムのデータの場合、必ずobpolicykeyword属性に手動で索引を追加します。詳細は、「ディレクトリ・サーバーの索引ファイルのアップロード」を参照し、使用環境に応じたアクティビティを実行してください。
アクセス・システムへの索引ファイルのアップロードが終了したら、次の「アクセス・スキーマおよびデータのアップグレードの検証」に進みます。
この手順では、アクセス・システムのスキーマおよびデータのアップグレードを検証します。
アクセス・システムのスキーマおよびデータのアップグレードを検証する手順
ディレクトリ管理コンソールを使用して、スキーマに『Oracle Access Managerスキーマ詳細』に定義されているオブジェクト・クラスと属性がすべて含まれていることを確認します。
ディレクトリ管理コンソールを使用して、すべての索引が追加されていることを確認します。
様々なディレクトリ・サーバー・インスタンスがある場合: 次にリストする手順を実行して、スキーマも更新されたことを確認します。
構成ディレクトリ・サーバーの構成ノードを参照し、obver属性の値が10.1.4.0になっていることを確認します。
スキーマに、10g（10.1.4.0.1）の属性obPolicyEnabledとオブジェクト・クラスoblixLPMPolicyが含まれていることを確認します。
アップグレードが成功した場合: 次にリストする手順に進みます。
アップグレードが成功しなかった場合: 「アクセス・システムのスキーマまたはデータのアップグレードの失敗からのリカバリ」に進みます。
マスター・ポリシー・マネージャをアップグレードした後には、他のどのアクセス・システム・コンポーネントをアップグレードするよりも前に、マスター・アクセス管理者がアイデンティティ・システム・コンソールを使用して特定の一時ディレクトリ・サーバー・プロファイルを作成する必要があります。このプロファイルによって、アクセス・サーバーにポリシー・データへの書込み権限が付与されます。このポリシー・データはディレクトリ・サーバーに格納されていて、ポリシー・マネージャのアップグレード中に更新されたデータです。
WebGateのアップグレード中には、アクセス・サーバーにより、WebGatestatic.lstファイルに格納されている構成情報が収集され、アップグレードのために作成された一時ディレクトリ・プロファイルを使用してディレクトリ・サーバーが更新されます。アクセス・サーバーは、ディレクトリ・サーバーに情報を書き込むと、WebGateにステータス情報を返します。WebGateStatic.lstファイル内の不明なパラメータはすべてディレクトリ・サーバーに移動されます。
|
注意: このプロファイルを作成する前にアクセス・システムのいずれかのコンポーネントをアップグレードすると、アップグレードが失敗することがあります。ただし、これらのコンポーネントには、アクセス・システムのスキーマおよびデータとともにアップグレードしたマスター・ポリシー・マネージャは含まれません。 |
以前のリリースでは、WebGateの構成パラメータはWebGatestatic.lstファイルに格納されていました。一方、Oracle Access Manager 10g（10.1.4.0.1）では、WebGateの構成はアクセス・システム・コンソールを使用して行います。アクセス・システム・コンソールを使用してパラメータの値を変更したり新しいパラメータを追加できるようにするには、以前のWebGateの構成パラメータをアップグレード中に適切に移行しておく必要があります。WebGateを10g（10.1.4.0.1）にアップグレードした後には、システム・コンソールを使用したパラメータの調整が必要になります。アップグレード後には、WebGatestatic.lstファイルは使用できなくなります。
一時ディレクトリ・プロファイルを作成するには、次のようにします。
プロファイルにmigration_wgstatic_profileという名前を割り当てます。これ以外の名前は使用しないでください。
ポリシー・データが格納されているディレクトリ用にmigration_wgstatic_profileを作成します。ユーザー・データ、構成データおよびポリシー・データがすべて単一のディレクトリに格納されている場合は、そのディレクトリ用にこの新しいプロファイルを作成します。ただし、ポリシー・データと構成データのみが同じディレクトリに格納されている場合は、そのディレクトリ用にこの新しいプロファイルを作成します。
migration_wgstatic_profileに対してすべての操作を行う権限を割り当てます。
PolicyManager_install_dir/access/oblix/config/configInfo.xmlに格納されているポリシー・ベースと同じネームスペースを使用します。ldapPolicyBaseパラメータの値を使用する必要があります。たとえばobapp=PSC, o=Oblix, o=company,c=usのようになります。
ご使用のディレクトリ・サーバーでLDAP参照がサポートされている場合、この一時ディレクトリ・サーバー・プロファイルでLDAP参照を有効にします。参照を使用すると、クライアント・リクエストを別のサーバーにリダイレクトし、リクエストされた情報を別の場所で検索できます。詳細は、『Oracle Access Manager IDおよび共通管理ガイド』を参照してください。
ポリシー・データのディレクトリ・サーバーがSSL対応の場合は、ディレクトリに接続するために、アクセス・サーバーからCA証明書が要求されます。CA証明書は、AccessServer_install_dir/access/oblix/config/cert8.dbまたはcert7.dbの証明書ストアに手動で（certutilツールを使用して）追加する必要があります。ただし、アクセス・サーバーで使用される既存のポリシー・データ・ディレクトリがすでにSSLモードであり同じCA証明書を使用する場合は、この手順を実行する必要はありません。
|
重要: この手順は、追加のアクセス・システム・コンポーネントをアップグレードする前に実行する必要があります。ディレクトリ・サーバー・プロファイルの詳細は、『Oracle Access Manager IDおよび共通管理ガイド』を参照してください。 |
アクセス・サーバー用の一時ディレクトリ・サーバー・プロファイルを作成する手順
アイデンティティ・システム・コンソール（以前のCOREidシステム・コンソール）に移動します。次に例を示します。
http://hostname:port/identity/oblix/
アイデンティティ・システム・コンソールで、「システム構成」タブをクリックします。
「ディレクトリ・プロファイル」をクリックして「プロファイルの構成」ページを表示します。
「LDAPディレクトリ・サーバー・プロファイルの構成」セクションに移動して「追加」をクリックし、「ディレクトリ・サーバー・プロファイルの作成」ページを表示します。
この一時プロファイルに関する情報として、次の名前と使用環境のネームスペースを「名前」フィールドに入力します。
名前: migration_wgstatic_profile
ネームスペース: obapp=PSC,o=Oblix,o=company,c=us
このネームスペースは、PolicyManager_install_dir/oblix/config/configInfo.lst内のLDAP PolicyBaseパラメータの値です。
「すべての操作」ボタンを選択して、すべての操作を実行する権限をこのプロファイルに付与します。
「使用」フィールドで、「アクセス・サーバー」オプションを選択します。
次に、ポリシー・データが格納されたディレクトリ・サーバーを指定するためのデータベース・インスタンス・プロファイルを作成する必要があります。このように行う必要があるのは、ポリシー・データが独立したディレクトリ・サーバーに格納されている場合です。ユーザー・データ、構成データおよびポリシー・データがすべて1つのディレクトリ・サーバーにある場合は、そのディレクトリ・サーバー用に新しいデータベース・インスタンス・プロファイルを作成する必要があります。
「ディレクトリ・サーバー・プロファイルの作成」ページの「データベース・インスタンス」セクションで、「追加」をクリックします。
「データベース・インスタンスの作成」ページが表示されます。
次の情報を入力して、ポリシー・データのディレクトリ・サーバーに対しデータベース・インスタンス・プロファイルを構成します。
詳細は、『Oracle Access Manager IDおよび共通管理ガイド』を参照してください。
LDAP参照がディレクトリでサポートされていて環境に必要な場合は、「フラグ」フィールドでLDAP参照チェック・ボックスを選択します。
LDAP参照の構成の詳細は、『Oracle Access Manager IDおよび共通管理ガイド』を参照してください。
データベース・インスタンス・プロファイルと、関連するディレクトリ・サーバー・プロファイルを保存します。
ポリシーのディレクトリ・サーバーがSSLモードで動作している場合は、ディレクトリ・サーバーに接続するために、アクセス・サーバーからCA証明書が要求されます。
ポリシーのディレクトリ・サーバーでアクセス・サーバーと同じCA証明書を使用している場合は、追加の構成は不要です。同じでない場合には、次のディレクトリにある証明書ストアにCA証明書（cert8.dbまたはcert7.db）を追加する必要があります。
AccessServer_install_dir/oblix/config
AccessServer_install_dirは、アクセス・サーバーがインストールされたディレクトリです。詳細は、『Oracle Access Managerインストレーション・ガイド』にある、新しい証明書ストアの追加に関する付録を参照してください。
次の「アップグレードされたポリシー・データのバックアップ」に進みます。
前述のように、スキーマおよびデータのアップグレードの最後には、10g（10.1.4.0.1）のコンポーネント・ディレクトリとディレクトリ・サーバー・インスタンスをバックアップすることをお薦めします。これにより、アップグレード直後の環境にリストアする必要が生じたときに簡単にリストアできるようになります。
アップグレードされた10g（10.1.4.0.1）ポリシー・マネージャ・ディレクトリをバックアップし、新しい場所に格納します。
ディレクトリ・ベンダーのドキュメントを参照して、アップグレードされたディレクトリ・サーバー・インスタンスをバックアップします。
「Oracle Access Managerの構成データおよびポリシー・データのバックアップ」の説明に従って、アップグレードしたポリシー・データをバックアップします。
ベンダーのドキュメントを参照して、アップグレードしたWebサーバー構成ファイルをバックアップします。
Windows: 必要に応じて、「Windowsレジストリ・データのバックアップ」の説明に従ってWindowsレジストリ・データをバックアップします。
「他の章の内容」に進みます。
スキーマおよびデータのアップグレードが失敗した場合、次の手順を実行してこのアップグレードをロールバックし、アップグレードしなおすことができます。
アクセス・システムのスキーマおよびデータのアップグレードの失敗からリカバリする手順
バックアップから以前のスキーマおよびデータをリカバリするには、バックアップしたディレクトリ・インスタンスをアップグレードの前にリストアしてください。
アップグレードの前にバックアップした以前のコンポーネントのインストール・ディレクトリをリストア（以前の環境をリカバリ）してから、このディレクトリを再度バックアップします。以前のディレクトリの一方をバックアップ・コピーとして保存し、他方のディレクトリを使用してアップグレードを再開します。
ポリシー・マネージャのWebサーバー: 以前のWebサーバー構成ファイルをリストアします。
Windows: 必要に応じて、バックアップしておいたレジストリをリストアします。
以前のデータとコンポーネントのインストール・ディレクトリのバックアップ・コピーを使用し、「マスターAccess Managerコンポーネントのスキーマおよびデータのアップグレード」の説明に従い、アップグレードを再実行します。
