| Oracle Access Managerアップグレード・ガイド 10g（10.1.4.2.0） E05837-01 |
|
 戻る |
 次へ |
この章は、ディレクトリのスキーマおよびデータの更新を担当するディレクトリ・サーバーの管理者を対象としています。Oracle Access Manager（以前のOblix NetPointまたはOracle COREid）の、インプレース・メソッドを使用したアイデンティティ・システムのスキーマおよびデータのアップグレードを中心に説明します。内容は次のとおりです。
|
注意: 停止時間ゼロのメソッドを使用している場合は、この章をスキップして第VI部を参照してください。アップグレード元のOracle Access Managerが6.1.1より前のリリースである場合は、アップグレードの前にOracleサポート・サービスにお問い合せください（http://www.oracle.com/support/contact.html）。 |
図6-1は、アイデンティティ・システムのスキーマおよびデータのアップグレードを完了するために必要なタスクを示しています。図の後には説明が続きます。また、アイデンティティ・サーバー（以前のNetPointまたはCOREidサーバー）へのリファレンスも付いています。各自の計画の概要を参照し、付録Fの追跡の概要を使用して進捗状況を確認してください。
タスクの概要: アイデンティティ・システムのスキーマおよびデータのアップグレード
「マスター・アイデンティティ・システムのスキーマおよびデータのアップグレードの前提条件」に記載されているすべての前提タスクを完了します。
新しく追加したマスター・アイデンティティ・サーバーをアップグレードし、説明に従ってスキーマおよびデータの自動アップグレードを受け入れます。
「マスターWebPassのアップグレード」の説明に従い、追加したマスターWebPassをアップグレードします。
「アイデンティティ・システムのスキーマおよびデータのアップグレードの検証」の説明に従い、アップグレードが成功したことを確認します。
アップグレードが成功した場合: 次の残りのアクティビティをこの順序で実行します。
アップグレードが失敗した場合: 「アイデンティティ・システムのスキーマまたはデータのアップグレードの失敗からのリカバリ」に進みます。
使用環境におけるアップグレード・タスクの実行の追跡に役立つ概要が付録Fにあります。
このタスクでは、10g（10.1.4.0.1）アイデンティティ・サーバー・インストーラを使用し、この目的のためにマスターとして追加した以前のCOREidサーバー・インスタンスをアップグレードします。10g（10.1.4.0.1）アイデンティティ・サーバー・インストーラを起動した後は、応答が必要な一連のイベントや質問がプログラムにより生成されます。
図6-2は、プログラムによるプロセスと、続行するために応答するよう求められる意思決定ポイントを示しています。この図のそれぞれのボックスは、各手順を説明している項と同名になっています。正常なアップグレードのためには、すべての手順を完了する必要があります。
タスクの概要: マスター・アイデンティティ・サーバーでのスキーマおよびデータのアップグレード
「マスター・アイデンティティ・サーバーのアップグレードの開始」では、選択したメソッド（GUIまたはコンソール）でのアップグレードの開始方法について説明しています。
「ターゲット・ディレクトリおよび言語の指定」では、既存のコンポーネントがインストールされているディレクトリや、アップグレードする言語の指定方法について説明しています。
「アイデンティティ・システムのスキーマおよびデータの更新」では、スキーマおよびデータの自動アップグレード方法について説明しています。
マスター・アイデンティティ・サーバーでは、スキーマおよびデータの自動アップグレードを受け入れることをお薦めします。
|
注意: ADAMを使用していた場合は、スキーマを手動でアップグレードする必要があります。データは自動アップグレードが可能です。詳細は、「Active Directoryアプリケーション・モードの検討と準備」を参照してください。 |
後で残りのCOREidサーバーをアップグレードする際、アップグレードされたスキーマおよびデータは自動的に検出され、関連するメッセージとイベントは抑止されます。
「マルチ言語機能の有効化」では、リリース6.1.1のマスターCOREidサーバーをアップグレードする場合にかぎって使用される自動化プロセスについて説明しています。
|
注意: マルチ言語機能の有効化は、リリース6.5または7.xからアップグレードを開始する場合は、自動的にスキップされます。 |
「アイデンティティ・サーバー構成ファイルのアップグレード」では、コンポーネント固有の構成ファイルへの変更の反映方法について説明しています。
「Software Developer Kit（SDK）構成のアップグレード」では、SDK構成の変更の受入れおよび拒否の方法について示しています。
|
注意: このマスターCOREidサーバーにキャッシングが構成されていない場合は、SDK構成の自動アップグレードを拒否できます。 |
「マスターCOREidサーバーのアップグレードの終了確認」では、アップグレードの成功を確認するための重要なアクションについて説明しています。
マスター・アイデンティティ・サーバーのスキーマおよびデータのアップグレードを開始する前に、表6-1のタスクを完了していることを確認してください。前提条件が満たされていないと、アップグレードに悪影響が生じる場合があります。
| スキーマおよびデータのアップグレードの前提条件 |
|---|
|
第5章のスキーマとデータの準備に必要なステップをすべて実行しておく。
|
|
第I部の各章の内容をよく理解している。 |
このマニュアルでは、一連のイベント、レスポンス例、メッセージの一部を示すために、GUIメソッドと自動モードを使用します。相違点はこのマニュアル内に記載してあります。自動モードであっても、スキーマおよびデータのアップグレードに関する質問には回答する必要があります。
使用環境に関係しないステップは、無視してください。たとえば、Windows環境の場合には、次のUNIXのステップを無視できます（また、UNIX環境の場合には、Windowsのステップを無視できます）。
Windows: 管理者権限でログインしている場合には、「次へ」をクリックします。
UNIX: コンポーネントで使用されるユーザー名とグループを指定してから初めて、「次へ」をクリックします。
次の手順で説明されているアップグレードの例では、リリース6.1.1インストールをアップグレード元としており、マルチ言語環境の有効化も行っています。
マスター・アイデンティティ・サーバーのアップグレードを開始する手順
「マスター・アイデンティティ・システムのスキーマおよびデータのアップグレードの前提条件」の説明に従い、すべての前提条件が満たされていることを確認します。
マスターCOREidサーバーのサービスとログを停止し、必要な管理者権限のあるユーザーとしてログインして、スキーマとOracle Access Managerファイルを更新します。
10g（10.1.4.0.1）アイデンティティ・サーバー・インストーラを通常の方法で起動します。次に例を示します。
WindowsのGUIメソッド: Oracle_Access_Manager10_1_4_0_1_win32_Identity_Server.exe
Solarisのコンソール・メソッド: ./Oracle_Access_Manager10_1_4_0_1_sparc-s2_Identity_Server
「ようこそ」画面が表示されます。
「次へ」をクリックして、「ようこそ」画面を閉じます。
プラットフォーム固有の管理者確認画面に応答します。次に例を示します。
Windows: 管理者権限でログインしている場合は、「次へ」をクリックします（管理者権限でログインしていない場合は、「取消」をクリックして、管理者権限を持つユーザーとしてログインしてからインストールを再開します）。
UNIX: アイデンティティ・サーバーが使用するユーザー名およびグループを指定してから、「次へ」をクリックします。通常、デフォルトはnobodyです。
次の「ターゲット・ディレクトリおよび言語の指定」に進みます。
ここでは、インストールしたマスターCOREidサーバーと同じターゲット・ディレクトリをアップグレードに対しても指定する必要があります。以前のコンポーネントが検出されると、アップグレードするかどうかの確認を求められます。アップグレードを受け入れた場合は、ターゲット・ディレクトリが作成され、10g（10.1.4.0.1）ファイルがそのディレクトリに抽出されます。
ターゲット・ディレクトリが作成された後、アップグレードする言語の選択を求められます。10g（10.1.4.0.1）言語パックが10g（10.1.4.0.1）アイデンティティ・サーバー・インストーラと同じディレクトリに格納されていないかぎり、アップグレードされるのは英語のみです。各言語は、『Oracle Access Managerインストレーション・ガイド』の手順に従ってアップグレード後にインストールできます。インストールした言語が使用されるようOracle Access Managerを構成します。詳細は、『Oracle Access Manager IDおよび共通管理ガイド』を参照してください。
次の手順の各ステップでは、特に記述がないかぎり、応答するよう求められる質問は、選択したインストール・メソッド（GUIまたはコンソール）やモード（自動または確認済）に共通となります。
インストールおよび設定したマスターCOREidサーバーと同じインストール・ディレクトリを選択し、「次へ」をクリックします。
「はい」をクリックしてアップグレードに同意し、「次へ」をクリックします。
「英語」やその他のアップグレード対象の言語の横にチェックマークが付いているかどうかを尋ねられたら、確認の後、「次へ」をクリックします。
アップグレードされる言語のリストが表示されます。
「次へ」をクリックして、選択した言語を確定します。
次の画面には、既存のインストールが保存されたというメッセージが表示されます。以前のインストールのすべてのファイルを含むソース・ディレクトリは、名前が変更され、タイムスタンプが付けられます。そのディレクトリの名前も表示されます。
タイムスタンプの付いたディレクトリ名を記録し、指示に従ってアップグレードを続行します。
新規画面に、10g（10.1.4.0.1）用のインストール・ディレクトリとインストールに必要な領域が確認用に表示されます。
ターゲット・ディレクトリへのファイルの抽出を開始します。
ファイル抽出の進行状況がステータス・バーに表示されます。
[Enter]を押して次に進みます。
Enter
アップグレード・プロセスのモード（自動モードまたは確認モード）を指定するよう求められます。
|
注意: コンソール・メソッドを使用してアップグレードしている場合は、トランスクリプトに表示されたコマンドを実行するよう求められます。UNIXの場合は、コマンドがファイル（start_migration）に出力され、このファイルを実行するよう指示するメッセージが出力されます。 |
-------------------------------------
Please specify the mode for migration:
'1' - Automatic (recommended)
Each step is performed automatically.
No interaction from the user is required.
'2' - Confirmed
Each step needs confirmation from the user.
Enter choice ( '1' or '2' ) : 1
--------------------------------------------
目的のアップグレード・モードに対応する数字を入力します。具体的には次のとおりです。
自動（推奨）: 数字の1を入力します。プロセスが自動的に進行するのを監視し、必要に応じていくつかの質問に応答します。
確認: 2を入力します。各アクティビティの前にプロンプトが表示され、応答するよう求められます。
このマニュアルに記載されている宣言メッセージは、自動モードに基づいています。自動モードでは、フォルダの作成時、ファイルのコピー時およびカタログのアップグレード時にメッセージが表示されます。次に例を示します。
Creating original folders ... ---------------------------------------------------- Copying general configuration files OK. ---------------------------------------------------- Updating parameter catalogs ... OK. ----------------------------------------------------
アップグレード・プログラムがディレクトリ・サーバーと接続されると、次に示すようなトランスクリプトが表示されます。
Starting migration (6.1.1 -> 6.5.0) ---------------------------------------------------- Oracle Access Manager schema migration ... ----------------------------------------------------
選択したモードを問わず、次の「アイデンティティ・システムのスキーマおよびデータの更新」に進みます。
スキーマとデータは、自動的にアップグレードすることをお薦めします。アップグレード・トランスクリプトは、特定のディレクトリ・サーバーに関する指示を除いては、アップグレード元およびアップグレード先のバージョンや、ディレクトリ・サーバー・タイプにかかわらず同じになります。
Oracle Access Manager 7.0以外からのアップグレードの場合は、コンポーネント固有のアップグレードの工程で、トランスクリプトの一部が繰り返されます。たとえば、リリース6.1.1からのアップグレードの場合、リリース6.5へのアップグレードにおいて表示されたトランスクリプトのダイアログの一部が、次のリリース7へのアップグレードでも表示され、その次のリリース10g（10.1.4.0.1）へのアップグレードでも再度表示されます。
|
注意: スキーマ変更は、すべてマスターの読取り/書込みディレクトリ・インスタンスにのみ反映できます（読取り専用レプリカには反映できません）。詳細は、「レプリケートされた環境でのアップグレード計画」を参照してください。 |
次の手順では、自動モードが選択されたものと想定しています。その場合でも、一部の問いに答えるよう求められます。
アップグレード元とアップグレード先のバージョンに注意し、スキーマのアップグレードについての情報を確認します。次に例を示します。
Oracle Access Manager schema migration ...
Retrieving Oracle configuration parameters ...
OK.
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:
|
注意: スキーマを移行（アップグレード）するかどうかの確認を求められます。このアクティビティはスキップしないでください。ADAMでは、自動スキーマ更新はサポートされていません。「Active Directoryアプリケーション・モードの検討と準備」を参照してください。 |
プロンプトで、yesとフルスペルで入力し、スキーマをロードします。
yes
プログラムによってスキーマが更新され、この間、トランスクリプトにより進行状況が表示されます。
Updating schema. Please wait ...
OK.
-------------------------------------------------
このステップ内で、構成データの取得、パラメータのアップグレードも実行され、トランスクリプトにより通知されます。
|
注意: データを移行（アップグレード）するかどうかの確認を求められます。このアクティビティはスキップしないでください。 |
プロンプトで、yesとフルスペルで入力し、データをロードします。
yes
プログラムは、構成データの変換、不要な古い構成データの削除、新規の構成パラメータのインポートなどを行います。この間、それらの作業の過程がトランスクリプトにより表示されます。
指示に従って作業を進め、「マルチ言語機能の有効化」へと進みます。
リリース6.5以降からアップグレードを開始する場合は、このプロセスは不要のためスキップできます。リリース6.5および7.xでは、マルチ言語環境が自動的にサポートされます。そのため、リリース6.5または7.xからアップグレードを開始する場合、このイベントは自動的にスキップされます。
マルチ言語機能の有効化は、スキーマと構成データの、リリース6.1.1からリリース6.5への段階的アップグレードでのみ必要となります。このフェーズでは、\langディレクトリ構造がアップグレード後の環境に追加され、\en-usサブディレクトリが生成されます。アップグレードする各言語用の追加の言語サブディレクトリも生成されます。詳細は、付録Aを参照してください。
次のサンプルは、マルチ言語の有効化で示される進行状況を通知するメッセージと、実行が必要なアクションを示しています。自動モードで必要なユーザー入力は、イベントの確認のみです。
言語のアップグレードに関するメッセージを確認します。
次に例を示します。
-------------------------------------
Oracle Access Manager language migration....
Retrieving Oracle configuration parameters...
OK.
Support for multiple languages is not enabled.
Performing language migration...
Updating language migration parameters...
OK.
The following directory server's data will be updated to
support multiple languages:
Host:DNShostname.domain.com
Port: port#
Type:ns
The default language (detected from your existing installation) is: en-us
Press <Enter> to continue
[Enter]を押して次に進みます。
ENTER
ここで、トランスクリプトに、マルチ言語を有効化するためにデータが変換され、新規の言語移行データのインポートが進行中であることが示されます。
言語の移行が成功した後に表示されるプロンプトで、[Enter]キーを押して次に進みます。
ENTER
各コンポーネントのアップグレードには、コンポーネントの構成ファイルをアップグレードする一連のイベントが含まれます。アップグレード元のリリースに応じて、以前のリリースが段階的に10g（10.1.4.0.1）に到達するまで、一連の手順が繰り返されます。たとえば、アップグレード元のリリースが6.1.1の場合は、6.1.1のスキーマおよびデータがリリース6.5のコンポーネント構成データにアップグレードされます。コンポーネントの次の手順では、この6.5のスキーマおよびデータをリリース7.0にアップグレードしてから、さらに10g（10.1.4.0.1）へとアップグレードします。
自動モードにおいて、イベントの各工程でアップグレードを続行するかどうか確認を求められたときは、必ずyesとフルスペルで入力するか、[Enter]キーを押してください。
|
注意: これらは環境によって異なります。途中でスキーマおよびデータのアップグレードについてのメッセージが表示された場合は、応答して次に進みます。イベントはスキップしないでください。ただし、途中でスキーマのアップグレードについてのメッセージが表示されない場合は、ステップ5へと進んでください。 |
アイデンティティ・サーバー構成ファイルの変更を受け入れる手順
コンポーネントのアップグレードに関するメッセージを確認します。次に例を示します。
Updating component-specific configuration ... OK.
Starting migration ( 6.5.0 -> 7.0.0 )...
-------------------------------------
Oracle Access Manager schema migration....
Retrieving Oracle configuration parameters...
OK.
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とフルスペルで入力し、次の一連のメッセージを確認して、ステップ3に進みます。
yes
Updating schema. Please wait...
OK.
Retrieving User configuration parameters...
OK.
-------------------------------------
Oracle Access Manager data migration....
Retrieving Oracle configuration parameters...
OK.
Could not detect the language for your installation!
Checking product version...
Version not up to date. Performing Configuration data migration...
Updating Oracle 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:
続行するよう答え、メッセージを確認してプロセスを追跡します。次に例を示します。
OK.
Converting Configuration data. Please wait...
..........................
OK.
Removing old Configuration data. Please wait...
..........................
.......................... ............
OK.
Cleaning up obsolete schema from the directory.
Deleting obsolete schema for osd. Please wait...
Importing new Configuration data. Please wait ...
OK.
-------------------------------------
Oracle Access Manager data migration has completed successfully!
Press <ENTER> to continue :
Enter
Updating component-specific configuration files.
リリース7.xから10g（10.1.4.0.1）へのアップグレードに関するメッセージを確認します。次に例を示します。
Starting migration ( 7.0.0 -> 10.1.4 )...
-------------------------------------
Oracle Access Manager schema migration....
Retrieving Oracle configuration parameters...
OK.
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
リリース7.xから10g（10.1.4.0.1）へのアップグレードの最後の工程を次に示します。ここでも、続行するかの確認を求められたら、yesとフルスペルで入力するか[Enter]キーを押します。次に例を示します。
Updating schema. Please wait...
OK.
Retrieving User configuration parameters...
OK.
-------------------------------------
Oracle Access Manager data migration....
Retrieving Oracle configuration parameters...
OK.
Could not detect the language for your installation!
Checking product version...
Version not up to date. Performing Configuration data migration...
Updating Oracle 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
プロセスの進行状況をメッセージで確認します。次に例を示します。
OK.
Converting Configuration data. Please wait...
..........................
OK.
Removing old Configuration data. Please wait...
..........................
..........................
OK.
Importing new Configuration data. Please wait ...
OK.
-------------------------------------
Oracle Access Manager data migration has completed successfully!
Press <ENTER> to continue :
確認を求められたら続行し、最後のメッセージを確認します。次に例を示します。
Enter
Updating component-specific configuration files...
OK.
Migration has completed successfully!
Press <ENTER> to continue :
-----------------------+++++++++++++--------------
SDKを使用するように構成されていないマスターCOREidサーバーをアップグレードする場合は、このイベントをスキップしてください。しかし、このCOREidサーバーにSDKが構成されている場合は、現在の設定を保持するために、ここで構成をアップグレードすることをお薦めします。
|
注意: 現在のSDK構成設定は、アップグレードしない場合は保持されないため、後でconfigureAccessGateツールを使用して再構成する必要があります。『Oracle Access Manager IDおよび共通管理ガイド』を参照してください。 |
マスターCOREidサーバー・インスタンスのSDKのアップグレードをスキップする手順
使用環境のインスタンスによって異なる、SDKの移行に関する質問に応答するため、該当する数値を入力します。
This component has the Access Server SDK installed
Would you like to automatically migrate the SDK at this time?
Note: If you do not want to migrate the SDK at this time, you will
need to reconfigure the SDK after migration has finished
by running the 'configureAccessGate' program
'1' - Yes
'2' - No
Enter choice ( '1' or '2' ) :
2
続行するかの確認を求められたら、[Enter]を押します。次に例を示します。
Enter
この手順を実行することで、マスターCOREidサーバーとアイデンティティ・システムのスキーマおよびデータのアップグレードを終了します。
マスターCOREidサーバーのアップグレードの終了を確認する手順
COREidサーバーのサービスが起動することを確認するため、それを起動します（起動後、その名前が最初に割り当てられた名前から変わっていないことに注意してください）。
COREidサーバーのサービスが起動しない場合: 付録Gのトラブルシューティングのヒントを参照してください。
スキーマおよびデータのアップグレード中に報告されたエラーがないか、移行ログ・ファイルを確認します。「ログ・ファイルへのアクセス」を参照してください。
アップグレードが失敗した場合: 「アイデンティティ・システムのスキーマまたはデータのアップグレードの失敗からのリカバリ」に進みます。
アップグレードが成功した場合: 次の「マスターWebPassのアップグレード」に進みます。
|
注意: COREidサーバーの新しい製品名はアイデンティティ・サーバーです。このマニュアルでは、今後アイデンティティ・サーバーと表記します。詳細は、「製品およびコンポーネントの名前の変更」を参照してください。 |
マスター・アイデンティティ・サーバーのアップグレード後は、マスターWebPassインスタンスをアップグレードする必要があります。WebPassにはディレクトリ・サーバーへの接続はありません。そのため、WebPassのアップグレードでは、スキーマやデータのアップグレードはありません。
WebPass（およびその他のOracle Access Manager Webコンポーネント）をアップグレードする際、コンポーネント固有のアップグレードには、WebコンポーネントとWebサーバーの構成ファイルの更新が両方含まれます。ここで説明するマスターWebPassのアップグレードと、後続のWebPassインスタンスのアップグレードとの間には、差異はありません。
図6-3は、プログラムによるWebPassアップグレード・プロセスと、特定の入力やイベントの承認が必要となるポイントを示しています。図の後には説明が続きます。
タスクの概要: マスターWebPassのアップグレード
ここでも同様に、リリース7以外からのアップグレードでは、10g（10.1.4.0.1）にアップグレードするまで、メジャー・リリースごとにいくつかのプロセスが自動的に繰り返されます。
マスターWebPassインスタンスのアップグレードを開始する前に、表6-2のタスクをすべて完了してください。前提条件が満たされていないと、アップグレードに悪影響が生じる場合があります。
| WebPassのアップグレードの前提条件 |
|---|
|
「マスター・アイデンティティ・サーバーでのスキーマおよびデータのインプレース・アップグレード」の説明に従って、マスター・アイデンティティ・サーバーがアップグレードされている。 |
|
このWebPassインスタンスについて第8章のコンポーネントの準備アクティビティがすべて完了している。
|
ここで説明するアップグレード例は、GUIメソッドと自動モードを使用して、リリース6.1.1から始まります。プログラムにより指示される一連のイベントとメッセージでは、ユーザーからの入力はほとんど要求されません。この工程は、マスター・アイデンティティ・サーバーのアップグレードの場合とほぼ同じです。10g（10.1.4.0.1）マスターWebPassのアップグレードのターゲット・ディレクトリは、以前のコンポーネントのものと同じである必要があります。
「マスターWebPassのアップグレードの前提条件」の説明に従い、すべての前提条件が満たされていることを確認します。
WebPassのWebサーバー・インスタンスを停止します。
管理者権限のあるユーザーとしてログインし、WebPassおよびWebサーバー構成を更新します。
ご使用のWebサーバーの10g（10.1.4.0.1）WebPassインストーラを選択し、起動します。次に例を示します。
WindowsのGUIメソッド: Oracle_Access_Manager10_1_4_0_1_win32_NSAPI_WebPass.exe
Solarisのコンソール・メソッド: ./Oracle_Access_Manager10_1_4_0_1_sparc-s2_NSAPI_WebPass
「ようこそ」画面が表示されます。
「ようこそ」画面を閉じます。次に、管理者権限に関する質問に回答します。
以前のWebPassインスタンスが含まれているディレクトリを選択します。
アップグレードするかどうかの確認に同意します。
「英語」やその他のアップグレード対象の言語の横に必ずチェックマークを付け、次へ進みます。
アップグレードまたは追加される言語のリストが表示されます。
「次へ」をクリックし、リストされている言語を確定します。
タイムスタンプの付いたディレクトリ名を記録し、次に進みます。
ファイルの抽出を開始します。
ファイル抽出の進行状況がステータス・バーに表示されます。
GUIメソッドを使用している場合は、新規ウィンドウが表示され、アップグレードに対して自動モードと確認モードのいずれを指定するかの確認を求められます。コンソール・メソッドを使用している場合は、トランスクリプトに表示されたコマンドを実行するよう求められます。実行の開始後は、指示に従って処理を進めます。
使用するモードをここで指定します（自動モードをお薦めします）。簡潔にするため、各ステップには短い説明しか付いていません。
WebPass構成とWebサーバー構成をアップグレードする手順
該当するモードに対応する数字を入力し、画面上のダイアログに従います。次に例を示します。
1
Creating orig folders ... ---------------------------------------------------- Copying general configuration files ... OK. ---------------------------------------------------- Updating parameter catalogs ... OK. ---------------------------------------------------- Starting migration (6.1.1 -> 6.5.0) ------------------------------------- Updating component-specific configuration files... OK. ------------------------------------- Starting migration ( 6.5.0 -> 7.0.0 )... ------------------------------------- Updating web server configuration files... OK. ------------------------------------- Updating component-specific configuration files... OK. ------------------------------------- Starting migration (7.0.0 -> 10.1.4) ------------------------------------- Updating web server configuration files... OK. ------------------------------------- Updating component-specific configuration files... OK. ------------------------------------- Migration has completed successfully! Press <ENTER> to continue :
[Enter]キーを押します。
Enter
If the Access System is also configured, you need to create a DB Profile
manually after first WebPass component upgrade is completed and before
upgrading the first Policy Manager. The profile gives the Access Server write
permission to Policy data in the directory server and will be used while
upgrading the WebGate component. The profile can be deleted after all
the WebGates are successfully upgraded.
Directory permissions copied ... C:\NetPoint\WebComponent\identity_20060223_180406\oblix)
C:\NetPoint\WebComponent\identity\oblix)
---------------------------------------------------
Migration has completed successfully!
Press <ENTER> to continue.
マスターWebPassのアップグレードを終了し、次の「マスターWebPassのアップグレードの終了確認」に進みます。
|
注意: アクセス・システムを含む混合デプロイを使用している場合は、この章のすべてのアクティビティを実行し、アクセス・システムのスキーマおよびデータをマスターAccess Managerコンポーネントとともにアップグレードした後で、一時ディレクトリ・プロファイルを作成します。詳細は、次の章を参照してください。 |
次の手順に従って、このマスターWebPassのアップグレードの終了の確認を行います。
必要に応じてWebサーバーの変更内容を反映します。
アイデンティティ・サーバー・サービスを停止して再起動します。
WebPassのWebサーバー・インスタンスを開始します。
Webサーバーが起動しない場合: 付録Gのトラブルシューティングのヒントを参照してください。
マスターWebPassのアップグレード中に報告されたエラーがないか、移行ログ・ファイルを確認します。「ログ・ファイルへのアクセス」を参照してください。
アップグレードが成功した場合: 次の「アイデンティティ・システムのスキーマおよびデータのアップグレードの検証」に進みます。
アップグレードが失敗した場合: 「アイデンティティ・システムのスキーマまたはデータのアップグレードの失敗からのリカバリ」に進みます。
アイデンティティ・システムのアップグレードが成功したことを確認するためのタスクです。
スキーマに、10g（10.1.4.0.1）の属性obPolicyEnabledとオブジェクト・クラスoblixLPMPolicyが含まれていることを確認します。
構成ディレクトリ・サーバーの構成ノードを参照し、obver属性の値が10.1.4.0になっていることを確認します。
アップグレードが成功した場合: 次の箇条書きに記載されたタスクを実行します。
アップグレードが失敗した場合: 「アイデンティティ・システムのスキーマまたはデータのアップグレードの失敗からのリカバリ」に進みます。
マスター・アイデンティティ・サーバー（およびアクセス・システムがインストールされている場合は、マスターAccess Manager）のアップグレードにおいて、既存のスキーマのアップグレードには、1つのリリースと次のリリースの間の変更点のみを含むスキーマ・ファイルが使用されます。そのため、製品のメジャー・リリースへのアップグレードごとに（たとえば、リリース6.1.1からリリース6.5、リリース6.5からリリース7.x、リリース7.xからリリース10g（10.1.4.0.1）など）、スキーマおよびデータのアップグレードが繰り返されます。
多くのディレクトリ・サーバーにおいては、スキーマおよびデータのアップグレード時に索引も自動的に更新されます。しかし、Oracle Access ManagerのデプロイにSun（以前のiPlanet）のディレクトリ、Novell eDirectory（NDS）、およびOracle Internet Directoryが含まれる場合は、マスター・アイデンティティ・サーバー（およびマスター・ポリシー・マネージャ）のアップグレード後に、ディレクトリの索引ファイルを手動で更新する必要があります。このタスクを実行するためのファイルは、次の場所に格納されています。
IdentityServer_install_dir/identity/oblix/data.ldap/common
PolicyManager_install_dir/access/oblix/data.ldap/common
Sun（以前のiPlanet）ディレクトリ、Novell eDirectory（NDS）、Oracle Internet Directoryの各ディレクトリ・サーバーのアップグレードごとに、2つの索引ファイルが提供されます。一方のファイルには、ユーザー・データの索引の10g（10.1.4.0.1）属性の完全なセットが含まれています。他方のファイルには、Oracle Access Manager構成データおよびポリシー・データの索引の、10g（10.1.4.0.1）属性の完全なセットが含まれています。それぞれのファイルは次のとおりです。
iPlanet5_user_index_add.ldifおよびiPlanet5_oblix_index_add.ldif
NDS_user_index_add.ldifおよびNDS_oblix_index_add.ldif
OID_user_index_add.ldifおよびOID_oblix_schema_index_add.ldif
ポリシー・データとユーザー・データが同じディレクトリ・インスタンスに格納されている場合、_oblix_index_add.ldifは、最初のアイデンティティ・サーバーのアップグレードの後に1回だけ追加されます。しかし、ポリシー・データが別のディレクトリ・インスタンスに格納されている場合は、最初の（マスター）アイデンティティ・サーバーのアップグレード後と、最初の（マスター）ポリシー・マネージャのアップグレード後の両方に、oblix_index_add.ldifファイルをアップロードする必要があります。
|
注意: 前述の、各ディレクトリ・サーバーに対する索引ファイルのアップロード以外に必要な作業として、マスター・ポリシー・マネージャ（以前のAccess Managerコンポーネント）のアップグレード後に行うobpolicykeyword属性に対する手動での索引の追加があります（アクセス・システムが構成されている場合）。obpolicykeyword属性は、現在は10g（10.1.4.0.1）索引のldifファイルに含まれなくなったため、マスター・ポリシー・マネージャのアップグレード時に自動的に追加できなくなりました。 |
表6-3は、スキーマおよびデータのアップグレード後に手動で索引付けする必要のある属性のリストです。これらの属性は、Oracle Internet Directory以外のすべてのディレクトリ・サーバーに共通です。前述のように、ほとんどのディレクトリ・サーバーにおいては、スキーマおよびデータのアップグレード時に索引も自動的に更新されます。ただし、Sun、Novell eDirectory、Oracle Internet Directoryについては、この章の説明に従い、ディレクトリ索引ファイルを手動でアップロードする必要があります。
表6-3 Oracle Internet Directory以外のディレクトリにおいて索引付け対象となる属性
| 属性 |
|---|
|
obactionname |
|
obactordn |
|
obapp |
|
obattr |
|
obclass |
|
obdatecreated |
|
obdateprocessed |
|
obdirectreports |
|
obentrycondition |
|
obgroupadministrator |
|
obgroupcreator |
|
obgroupdynamicfilter |
|
obgroupexpandeddynamic |
|
obgrouppuredynamic |
|
obgroupsubscribemessage |
|
obgroupsubscribenotification |
|
obgroupsubscriptionfilter |
|
obgroupsubscriptiontype |
|
obgroupunsubscribemessage |
|
obid |
|
obindirectmanager |
|
oblocationdn |
|
oblocationname |
|
oblocationtitle |
|
oblockedby |
|
obname |
|
obobjectclass |
|
obpaneltype |
|
obparentlocationdn |
|
obparentstep |
|
obparentworkflow |
|
obparticipant |
|
obpasswordpolicyid |
|
obpolicyconditiongroupStr |
|
obpolicyconditionuidStr |
|
obready |
|
obrectangle |
|
obresourceattribute |
|
obresourceoperation |
|
obresourcetype |
|
obresourceuidStr |
|
obretrycount |
|
obtargetdn |
|
obuniquememberStr |
|
obuseraccountcontrol |
|
obwfinstanceid |
|
obwfstatus |
|
obwfstepid |
|
obwfstepinstid |
|
obwftypename |
|
obworkflowname |
|
obworkflowtype |
|
obwftargetlabel |
|
obworkflowdn |
|
obworkflowstepdn |
|
obisworkflowprovisioned |
|
obdynamicparticipantsset |
|
obLPMName |
|
oburlprefix |
|
obSiteDomainID |
|
obHostContext |
|
obdescription |
|
obpolicyKeyword |
索引の更新のために実行が必要なステップは、次に示すように、ディレクトリ・サーバー・タイプ別になっています。
|
注意: iPlanetディレクトリおよびNDSディレクトリは、索引をアップロードしなくても稼働します。ただし、検索のパフォーマンスが影響を受け、低下します。Oracle Internet Directoryの索引をアップロードしないと、ユーザーがログインできなくなります。 |
ここでの目標は、以前の索引があればそれらをすべて無視して、10g（10.1.4.0.1）属性に付けられる新たな索引を作成することです。エラーが表示される場合は、以前のリリースに属する索引が使用環境に元々存在していた可能性があります。続行モード・オプションを使用すると、以前のリリースに索引付け対象となる属性が1つ以上存在する場合に、続けて新しい10g（10.1.4.0.1）属性を追加できます。
Sun（以前のiPlanet）またはOracle Internet Directoryの索引ファイルをアップロードする手順
Oracle Internet Directory: ディレクトリ固有のコマンドまたはディレクトリ管理者インタフェースを手動で実行し、索引が追加されたことを『Oracle Access Managerスキーマ詳細』の情報を参照して確認します。
Sun（以前のiPlanet）: ディレクトリ固有のコマンドまたはディレクトリ管理者インタフェースを手動で実行し、索引が追加されたことを表6-3を参照して確認します。
ディレクトリ・サーバーに合ったファイルを選択します。次に例を示します。
ldapmodifyコマンド（または、ディレクトリ・ベンダーの提供するインポート・ツール）を実行します。以前の索引付き属性が見つかった場合にエラーが発生しないよう、続行モード・オプションを使用します。次に例を示します。
\IdentityServer_install_dir\identity\oblix\tools\ldap_tools\ldapmodify
run ldapmodify.exe –h DS_hostname -p DS_port_number -D bind_dn -w password
-f OID_user_index_add.ldif -a -e reject_filename -c
使用ディレクトリに対応したdirectory_oblix_schema_index_add.ldifを使用し、ステップ2を繰り返します。
終了後、「アップグレードされたアイデンティティ・データのバックアップ」に進みます。
ここでの目標は、Novell eDirectoryを使用している場合に、以前の索引があればそれらをすべて無視して、10g（10.1.4.0.1）属性に付けられる新たな索引を作成することです。ただし、この場合は、続行モード・オプションは使用できません。
Novell eDirectoryの索引を確認または更新する手順
NDS固有のコマンドまたはNDS管理者インタフェースを手動で実行し、索引が追加されたことを表6-3を参照して確認します。
索引をアップロードする必要がある場合は、NDS固有のコマンドまたはNDS管理者インタフェースを手動で実行します。
適切なNDS固有のコマンドまたはNDS管理者インタフェースを使用し、obpolicykeyword属性に手動で索引付けします。
終了後、「アップグレードされたアイデンティティ・データのバックアップ」に進みます。
7.0より前のリリースからスキーマおよびデータをアップグレードした後、このタスクを実行して監査ファイルのパス名を修正する必要があります。リリース7.xからアップグレードした場合、このアクティビティはスキップできます。
700より前のリリースからマスター・アイデンティティ・サーバーおよびスキーマとデータをアップグレードする場合、監査ファイル名はそのマスター・アイデンティティ・サーバーのパスに接頭辞を付けることで変更されます。
デプロイに複数のアイデンティティ・サーバーが含まれる場合、それぞれの監査ファイル名は、データのアップグレードが行われるアイデンティティ・サーバーと同じインストール・ディレクトリ・パスに接頭辞が付けられたものになります。この結果、アイデンティティ・サーバーのアップグレード中に元の構成が失われます。たとえば、リリース611のアイデンティティ・サーバー・インスタンスが2つあり、監査ファイルが次のように格納されているとします。
ここで示すサンプル・パス名の監査ファイルは、異なるディレクトリ・パスに格納できます。
ただし、アップグレード後、どちらの監査ファイルもスキーマとデータのアップグレードで使用されたアイデンティティ・サーバーのディレクトリ・パスに格納されます。次に例を示します。
複数のアイデンティティ・サーバーのアップグレード後に監査ファイルをリカバリするには、次のタスクを実行して特定のアイデンティティ・サーバー・インスタンスの適切なパスを反映するように監査ファイルのパスを変更する必要があります。停止時間ゼロのアップグレードを実行している場合、クローンに対してのみこのタスクを実行します。
アイデンティティ・サーバーのアップグレード後に元の監査ファイル名をリカバリする手順
スキーマおよびデータをアップグレードしたら、アイデンティティ・システム・コンソールにアクセスして通常どおりにログインします。
http://hostname:port/identity/oblix
ここで、hostnameはWebサーバーをホストするコンピュータ、portはWebPassのWebサーバー・インスタンスのHTTPポート番号をそれぞれ指し、/identity/oblixはアイデンティティ・システム・コンソールに接続します。
アイデンティティ・システム・コンソールで「システム構成」→「アイデンティティ・サーバー」をクリックします。
アイデンティティ・サーバーの名前を選択して、このインスタンスの情報を表示します。
「監査ファイル名」フィールドでパス名が正しいかどうかを確認します。
パス名が正しい場合は、「取消」をクリックしてステップ3と4を繰り返し、別のインスタンスの監査ファイルのパス名を確認します。パス名が正しくない場合、ステップ5に進みます。
ページの下部にある「変更」ボタンをクリックします。
「変更」ページの「監査ファイル名」フィールドで、パス名をこのインスタンスの正しいパスに変更し、「保存」をクリックします。次に例を示します。
詳細が更新されたアイデンティティ・サーバーを再起動します（実行している場合）。
アイデンティティ・サーバー・インスタンスごとに、この手順のすべてのステップを繰り返します。
スキーマおよびデータのアップグレードの終了後に、10g（10.1.4.0.1）コンポーネント・ディレクトリとディレクトリ・サーバー・インスタンスをバックアップすることをお薦めします。これにより、アップグレード直後の環境にリストアする必要が生じたときに簡単にリストアできるようになります。
10g（10.1.4.0.1）のアイデンティティ・サーバー・ディレクトリをバックアップし、新しい場所に格納します。
ディレクトリ・ベンダーのドキュメントを参照して、アップグレードされたディレクトリ・サーバー・インスタンスをバックアップします。
「既存のOracle Access Managerデータのバックアップ」の説明に従い、アイデンティティ・システムのデータをバックアップします。
Windows: 「Windowsレジストリ・データのバックアップ」の説明に従って、該当するコンポーネントのアップグレードされたレジストリをバックアップします。
WebPass Webサーバー: ベンダーのドキュメントを参照して、アップグレードされたWebサーバー構成ファイルをバックアップします。
「他の章の内容」に進みます。
この章の他のアクティビティがすべて終了したら、インプレース・アップグレードの場合のみフェーズ2を実行します。アップグレード前にフェーズ1を実行しなかった場合はフェーズ2の実行をスキップしてください。ただし、ロールバック操作では、移行されたユーザー・データを元に戻すことはできません。詳細は、第5章を参照してください。
|
注意: 停止時間ゼロのメソッドを使用してアップグレードを実行している場合、このアクティビティはスキップしてください。 |
この項では、最初のログイン時のユーザー・データ（ロスト・パスワード管理の場合のみ、チャレンジ属性とレスポンス属性には複数の値が存在する）の即時（オンザフライとも呼ばれる）移行を停止する手順のフェーズ2の実行に必要な情報を示します。
|
注意: フェーズ2は、アイデンティティ・システムとアクセス・システムの混合デプロイの場合でも、スキーマとデータをアップグレードした後、管理者またはユーザーがログインする前に実行する必要があります。 |
フェーズ1では、スキーマとデータをアップグレードする前に、マスター管理者エントリのobVer属性を設定しました。詳細は第5章を参照してください。フェーズ2では、構成ベースのobVer値を7.0.4にリセットして、「チャレンジ」セマンティク型と「レスポンス」セマンティク型を、タブ・レベルとオブジェクト・クラス・レベルの両方で削除する必要があります。
このフェーズ2の手順が終了したら、次のアクションの処理または実行を中止して、ユーザー・データが下位互換性を確保しているかどうかを確認することをお薦めします。
スキーマおよびデータのアップグレード後、構成ベースのobVerの値を次のように7.0.4に変更します。
ldapmodify.exe -h <Host> \
-p <Port>
-D <Bind DN>
-w <Bind Password> \
-f <ldif file containing attribute to be modified>
構成データのバインドDN（構成DNとも呼ばれる）は、ユーザー・データの検索ベースのようなものです。構成バインドDNは、アイデンティティ・システムおよびアクセス・システムについてOracle Access Managerのスキーマとすべての構成データが格納されているDITのノードを特定するために指定する必要があります。
作成されるLDIFファイルの形式は次のとおりです。これはNetscape Directory Serverの場合の例です。
dn: o=oblix,<configuration DN>
changetype: modify
replace: obver
obver: 7.0.4
マスター・アイデンティティ・サーバーを再起動します。
使用環境のURLを指定してアイデンティティ・システム・コンソールにアクセスし、マスター管理者としてログインします。次に例を示します。
http://hostname:port/identity/oblix
このURLの例では、hostnameはWebPassのWebサーバーをホストするコンピュータ、portはWebPassのWebサーバー・インスタンスのHTTPポート番号をそれぞれ指し、/identity/oblixはアイデンティティ・システム・コンソール（以前のCOREidシステム・コンソール）に接続します。
タブ・レベル: 「チャレンジ」セマンティク型と「レスポンス」セマンティク型を、次のようにタブ・レベルで無効にします。
アイデンティティ・システム・コンソールをクリックして、「ユーザー・マネージャ構成」→「タブ」をクリックします。
ページにリストされている「既存のタブ」で「従業員」を選択し、「タブの表示」ページでこのPersonクラス・タブに関する情報を表示します。
|
注意: 「タブの表示」ページのオブジェクト・クラスには、OblixOrgPersonの他にgensiteorgpersonなどが含まれる場合があります。obVer属性は、OblixOrgPersonクラスのみのメンバーです。その他のオブジェクト・クラスに影響はありません。 |
「タブの表示」ページで、「属性の変更」をクリックして「属性の変更」ページを開きます。
「属性」リストから「チャレンジ」が「セマンティク型」で構成されている属性を選択し、「セマンティク型」を「なし」に設定して「保存」をクリックします。
「属性」リストから「レスポンス」が「セマンティク型」で構成されている属性を選択し、「セマンティク型」を「なし」に設定して「保存」をクリックします。
「完了」をクリックします。
オブジェクト・クラス・レベル: 「チャレンジ」セマンティク型と「レスポンス」セマンティク型を、次のようにオブジェクト・クラス・レベルで削除します。
アイデンティティ・システム・コンソールをクリックして、「共通構成」→「オブジェクト・クラス」をクリックします。
リストから人オブジェクト・クラスを選択し、「属性の変更」をクリックして「属性の変更」ページを開きます。
「属性」リストから「チャレンジ」が「セマンティク型」で構成されている属性を選択し、「セマンティク型」を「なし」に設定して「保存」をクリックします。
「属性」リストから「レスポンス」が「セマンティク型」で構成されている属性を選択し、「セマンティク型」を「なし」に設定して「保存」をクリックします。
「完了」をクリックします。
「他の章の内容」に進みます。
デプロイのアップグレードの成功を確認した後にユーザー・データ移行を再実行するには、「インプレース・アップグレードのユーザー・データのオンザフライ移行の再実行」を参照してください。
スキーマおよびデータのアップグレードが失敗した場合、次の手順を実行してこのアップグレードをロールバックし、アップグレードしなおすことができます。
|
注意: ステップ4はWebPass専用です。マスターWebPassのアップグレードのみが失敗した場合、次の手順でステップ1をスキップして、ステップ4を実行してください。 |
スキーマおよびデータのアップグレードの失敗からリカバリする手順
バックアップから以前のスキーマおよびデータをリカバリするには、バックアップしたディレクトリ・インスタンスをアップグレードの前にリストアしてください。
アップグレードの前にバックアップした以前のコンポーネントのインストール・ディレクトリをリストア（以前の環境をリカバリ）してから、このディレクトリを再度バックアップします。以前のディレクトリの一方をバックアップ・コピーとして保存し、他方のディレクトリを使用してアップグレードを再開します。
Windows: バックアップされたこのコンポーネントのレジストリをリストアします。
WebPass Webサーバー: バックアップされたWebサーバー構成ファイルをリストアします。
以前の情報およびコンポーネント・インストール・ディレクトリのバックアップ・コピーを使用し、「マスター・アイデンティティ・サーバーでのスキーマおよびデータのインプレース・アップグレード」の説明に従って、アップグレードを再実行します。
アップグレードされたアイデンティティ・システム・コンポーネントでは、UTF-8エンコーディングでデータが送受信されます。以前のコンポーネントでは、Latin-1エンコーディングでデータが送受信されます。このため、10g（10.1.4.0.1）のアイデンティティ・システムは以前のアクセス・システムと連動しません。
以前のアイデンティティ・システム・コンポーネントがすべて正常にアップグレードされたら、以前のインストールに応じて必要な手順に進みます。具体的には次のとおりです。
アイデンティティ・システムのみ: 以前のインストールにアクセス・システムが含まれていない場合は、次に記載された手順に従ってアクティビティを行ってください。
アイデンティティ・システムとアクセス・システムの混合: 以前のインストールにアクセス・システムが含まれている場合、次に記載された手順に従ってアクティビティを行う必要があります。
第12章「アイデンティティ・システムのカスタマイズ内容のアップグレード」（アイデンティティ・システム・コンポーネントをすべてアップグレードした後）
予期されるシステム動作の詳細は、第4章を参照してください。
