| Oracle Access Managerアップグレード・ガイド 10g（10.1.4.2.0） E05837-01 |
|
 戻る |
 次へ |
この章では、アップグレード・プロセス中にコールされて実行されるユーティリティについて説明します。
内容は次のとおりです。
各コンポーネントをアップグレードする場合、最新の製品リリースを以前の製品リリースと同じ場所にインストールします。この項では、コンポーネントのアップグレード中にプログラムによって実行されるプロセスについて概説します。
インプレース・アップグレードを実行する場合と停止時間ゼロのアウトオブプレース・アップグレードを実行する場合では、いくつかの相違があります。
インプレース・アップグレードは、対応するOracle Access Manager 10g（10.1.4.0.1）インストーラを使用して開始します。基礎となるユーティリティで必要な引数は、インストーラによって収集されます。各コンポーネントのアップグレードでは、インストーラが一連のイベントとメッセージを自動的に処理します。このプロセスでは、ユーザーによる入力はほとんど必要ありません。
停止時間ゼロのアウトオブプレース・アップグレードは、10.1.4.2.0のMigrateOAMスクリプトを使用してコマンドラインから開始します。この場合、操作のモードと、基礎となるユーティリティに渡される引数やパラメータを手動で入力する必要があります。
インプレース・アップグレード: コンポーネントのアップグレードは、対応するOracle Access Manager 10g（10.1.4.0.1）インストーラを使用して開始します。各コンポーネントのアップグレードでは、インストーラが一連のイベントとメッセージを自動的に処理します。コンポーネントのアップグレード・プロセスでは、ユーザーが入力する必要はほとんどありません。
アップグレードを開始し、以前（ソース）のコンポーネントが格納されているのと同じ（ターゲット）インストール・ディレクトリを指定すると、以前のバージョンのコンポーネントをアップグレードするかどうかの確認を求められます。
ディレクトリ名に空白が含まれる場合、プログラムを正しく起動するには、使用するコマンド内で各パス名を引用符で囲む必要があります。次に例を示します。
obmigratenp.exe -c ois -f 650 -t 700 -s
"C:\Program Files\NetPoint\identity_20060519_134931"
-d "C:\Program Files\NetPoint\identity"
-i "C:\Program Files\NetPoint\identity"
|
警告: ディレクトリ名に空白が含まれる場合は、必ず使用するコマンド内で各パス名を引用符で囲んでください。 |
すべてのアップグレード: 図C-1およびそれに続く「プロセスの概要」には、各プログラム（およびプロセス中に自動的にコールされるユーティリティ）によって実行される一般的なコンポーネントのアップグレードを示します。
インプレース・アップグレードが説明されています。コンポーネントのインストール・プログラムを開始すると、ようこそメッセージが表示され、インストール・パス名などの特定の入力が求められます。自動処理を続行すると、操作メソッド（自動または確認）に同意するか、単に続行する準備ができていることを確認するかを尋ねられます。
停止時間ゼロのアップグレード時に、MigrateOAMスクリプトの引数と仕様を含むコマンドラインを手動で入力します。MigrateOAMスクリプトによって、アップグレードに関連する、あるいはアップグレードを制御する他のユーティリティに引数と仕様が渡されます。インプレース・アップグレードまたは停止時間ゼロのアップグレードのどちらを実行する場合も、図C-1のプロセス3以降の内部処理はほぼ同じです。停止時間ゼロのアップグレードのスクリプトとモードの詳細は、第15章を参照してください。
プロセスの概要: 以前のソースが検出されてアップグレードする場合
ソース・ディレクトリがタイムスタンプ付きの名前に変更されます。
ターゲット・ディレクトリが作成され、10g（10.1.4.0.1）ファイルがそのディレクトリに抽出されます。最新のリリースは元のターゲット・パスに抽出する必要があります。これにより、以前のインストールの言語が検出されます。
英語は自動的にアップグレードされます。10g（10.1.4.0.1）言語パックがソース・ディレクトリにある場合は、以前の言語のアップグレードや新規の言語の追加ができます。
|
注意: 10g（10.1.4.0.1）言語パックを使用せずにマルチ言語実装をアップグレードすると、マルチ言語機能が失われます。マルチ言語実装の詳細は、第4章「システム動作と下位互換性」を参照してください。 |
obmigratenpユーティリティがコールされます（移行元と移行先のリリースを判別します）。このユーティリティは、この特定コンポーネントに対してアップグレードする必要のある機能と、これらのアップグレードに使用する必要のあるその他のユーティリティを内部で検出します。
インストールに複数の言語が含まれている場合、obmigratenpは次の処理を実行します。
コンポーネント・ソース・ディレクトリに10g（10.1.4.0.1）言語パックがある場合は、英語以外の選択した言語でメッセージ・カタログを移行します。
「基本ユーティリティ: obmigratenp」の説明に従って、通常のアップグレードを開始します。
|
注意: 各ユーティリティとそれによって生成されるログ・ファイルの詳細は、この付録で後述する説明を参照してください。 |
obmigratefilesユーティリティが、プログラム・ファイルおよびライブラリ・ファイルをアップグレードするためにコールされます。
必要なファイルがターゲット・ディレクトリに抽出されます。
名前の変更されたソース・ディレクトリからターゲット・ディレクトリに必要な構成ファイルとSSL関連のファイルがコピーされ、10g（10.1.4.0.1）がインストールされます。
詳細は、「ファイルのアップグレード: obmigratefiles」を参照してください。
obmigrateparamsgユーティリティが、メッセージ・カタログ・ファイルおよびパラメータ・カタログ・ファイルをアップグレードするためにコールされます。
名前の変更されたソース領域から、必要な（.xmlおよび.lst）ファイルが特定されます。
ファイルが最新のリリースに合せて変更され、ターゲット・ディレクトリに書き込まれます。10g（10.1.4.0.1）では、LSTファイルがXMLファイルに変換され、元のファイルに加えられたカスタマイズがアップグレードされたファイルで保持されます。
詳細は、「メッセージおよびパラメータのアップグレード: obmigrateparamsg」を参照してください。
スキーマおよびデータのアップグレードのみ: 2つのユーティリティobmigratedおよびobmigratedataが、Oracle Access Managerのスキーマとデータのアップグレードを開始するために自動的にコールされます。
停止時間ゼロのアップグレード: スキーマとデータが個別にアップグレードされます。詳細は、「停止時間ゼロのアップグレード・メソッドを使用したスキーマおよびデータのアップグレード」を参照してください。
インプレース・アップグレード: スキーマとデータは、マスター・アイデンティティ・サーバー（インストールにアクセス・システムが含まれる場合はマスター・ポリシー・マネージャも）と一緒にアップグレードされます。後続のアイデンティティ・サーバー（およびポリシー・マネージャ）のアップグレード時には、最初のスキーマおよびデータのアップグレードが検出され、プロセスのその部分がスキップされます。第II部「スキーマおよびデータのアップグレード」の説明に従って、Oracle Access Managerのスキーマとデータを自動的にアップグレードすることをお薦めします。このような自動アップグレードでは、ユーザーのディレクトリ・サーバーに固有のLDIFファイルが使用されます。各LDIFファイルに含まれるのは、Oracle Access Managerの1つのリリースと次のリリースとの間の変更点のみです。つまり、スキーマおよびデータのアップグレードは、開始するリリースから10g（10.1.4.0.1）にいたるまで、各リリースへのアップグレードごとに1回繰り返されます。たとえば、リリース6.1.1からアップグレードする場合、スキーマおよびデータのアップグレードが次のように行われます。
リリース6.1.1.からリリース6.5へ
リリース6.5からリリース7.0へ
リリース7.0から10g（10.1.4.0.1）へ
obmigratewsユーティリティがコールされ、指定のWebサーバー構成ファイルおよびフィルタのアップグレードを実行し、ポリシー・マネージャ、WebPassおよびWebGateの新しいバージョンの変更内容を必要に応じて組み込みます。
Webサーバー構成ファイルに変更が加えられます。
詳細は、「Webサーバーのアップグレード: obmigratews」を参照してください。
コンポーネント固有のユーティリティを使用して、Windowsの関連するレジストリ・エントリ、プラグインおよびその他のファイルを変更します。
例:
アイデンティティ・サーバー: obMigrateNetPointOisは、アイデンティティ・サーバーの既存レジストリ・エントリをアップグレードして新しいリリースを反映し、PPPカタログを必要に応じて変更し、password.xmlおよびpassword.lstにあるパスワードを必要に応じて変更し、適切なuninstall_info.txtを再作成します。詳細は、「アイデンティティ・サーバー: obMigrateNetPointOis」を参照してください。
|
注意: Oracle Access Manager 5.2のpassword.xmlファイルおよびpassword.lstファイルに書き込まれたパスワードは暗号化されていません。これに対して、それより以後のバージョンでは暗号化されます。暗号化はアップグレード中に自動的に行われます。 |
WebPass: obMigrateNetPointWPは、WebPassの既存レジストリ・エントリをアップグレードして新しいリリースを反映し、password.xmlおよびpassword.lstにあるパスワードを必要に応じて変更します。詳細は、「WebPass: obMigrateNetPointWP」を参照してください。
ポリシー・マネージャ: obMigrateNetPointAMは、ポリシー・マネージャのレジストリ・エントリをアップグレードし、password.lstにある暗号化パスワードを必要に応じて変更します。また、名前の変更されたソース・ディレクトリからターゲット・インストール・ディレクトリにカスタム・プラグインをコピーします。詳細は、「ポリシー・マネージャ: obMigrateNetPointAM」を参照してください。
アクセス・サーバー: obMigrateNetPointAAAは、アクセス・サーバーのレジストリ・エントリをアップグレードして、暗号化パスワードを必要に応じて変更し、名前の変更されたソース・ディレクトリからターゲット・インストール・ディレクトリにカスタム・プラグインをコピーして、次に示すフェイルオーバー・ファイルをアップグレードします。
AppDB.lst: .xmlに変換されます。
ConfigDB.lst: .xmlに変換されます。
Group.lst: .xmlに変換されます（存在する場合）。
UserDB.lst: .xmlに変換されます（存在する場合）。
WebResrcDB.lst: .xmlに変換されます。
詳細は、「アップグレードされる項目」を参照してください。
WebGate: obMigrateNetPointWGは、WebGateのレジストリ・エントリをアップグレードし、必要に応じて暗号化パスワードを変更します。詳細は、「WebGate: obMigrateNetPointWG」を参照してください。
SDK: obMigrateNetPointASDKがobmigratenpからコールされ、Access Manager SDKのアップグレードを実行します。
SDKのアップグレードは、SDKにバンドルされたコンポーネント（アイデンティティ・サーバーおよびOracle Access Manager WebSphere用コネクタ）のアップグレードの最終ステップとして自動的に開始されます。
|
注意: 自動SDKアップグレードを拒否すると、現在のSDK構成設定が保持されなくなるため、『Oracle Access Managerアクセス管理ガイド』で説明されているように、configureAccessGateツールを使用してSDKを再構成する必要があります。 |
詳細は、「Software Developer Kit（SDK）: obMigrateNetPointASDK」を参照してください。
通常のインストール作業を終了する場合と同様の方法で終了します。
必須の手動処理作業の詳細は、「手動でアップグレードする必要のある項目」を参照してください。
|
注意: アップグレードは段階的に行われます。つまり、古いものから順にアップグレード・プロセスが始まり、次のメジャー・リリースにアップグレードされます。コンポーネント固有のアップグレードの後、元のリリースと最新のリリース間の変更がすべて反映されるまで、アップグレード・プロセスが自動的に繰り返されます。 |
コンポーネントがインストールされたことが通知された後でアップグレードを取り消す場合は、次のステップを実行してOracle Access Managerの構成を元の状態にリストアする必要があります。
停止時間ゼロのアップグレードを実行する場合、Oracle Access Managerリリース10g（10.1.4.2.0）で使用可能なMigrateOAMスクリプトを使用する必要があります。MigrateOAMスクリプトと処理の詳細は、「停止時間ゼロのアップグレードのツールおよびプロセス」を参照してください。
インプレース・アップグレード・メソッドを使用する場合、コンポーネントのアップグレードを実行する基本ユーティリティはobmigratenpです。停止時間ゼロのアップグレード・メソッドを使用する場合、プロセスはMigrateOAMスクリプトにより実行されます。obmigrateユーティリティは、表C-1で説明されているように、メジャー・リリースXからメジャー・リリースYにいたる、コンポーネントのアップグレード・プロセス全体を統括します。
表C-1 アップグレード実行ユーティリティobmigratenp
obmigratefilesは、ファイルとフォルダに関連したアップグレードを実行するため、obmigratenpから複数回コールされます。
ファイルのアップグレードには、名前の変更されたソース・ディレクトリからターゲット・インストール・ディレクトリへの必須ファイルのコピーが伴います。obmigratenpツールからコールされるobmigratefilesツールは、次の内容が指定されたマップ・ファイルを使用します。
コピー元ファイル
ソース・ディレクトリ
ターゲット・ディレクトリ
詳細は、次のプロセスの概要を参照してください。
プロセスの概要: obmigratenpからのobmigratefilesのコール
次の2つの場合は、obmigratefilesにより、元の各ファイルを入れるフォルダがソース・ディレクトリ内に作成されます。この理由は、リリース5.2.0のインストーラ（Solarisの場合は6.0.0のインストーラ）が元の各ファイルを入れるフォルダを作成しないためです。
Oracle Access Manager 5.2.0からアップグレードする場合
Solaris上でリリース6.0.0からアップグレードする場合
使用されるマップ・ファイルはcomponent_Version_orig_files.lstです。次に例を示します。
ois_520_orig_files.lst
または
ois_600_orig_files.lst
このフォルダは、メッセージおよびパラメータのアップグレードにも使用されます。
obmigratefilesは、次のマップ・ファイルを使用して、現在のリリースの元のファイルを入れるフォルダを現在のインストール・ディレクトリに作成します。
component_Version_orig_files.lst
例:
ois_600_orig_files.lst
現在のリリースから新しいリリースへのアップグレードが次に実行された際、メッセージおよびパラメータをアップグレードする段階で、現在のリリース用の元のファイルを入れるフォルダが作成され、使用できるようになります。
obmigratefilesにより、名前の変更されたソース・ディレクトリからターゲット・インストール・ディレクトリに構成ファイルやSSL設定関連ファイルなどがコピーされます。
この場合、obmigratefilesは該当するcomponent_base_filesを使用します。次に例を示します。
ois_base_files.lst
am_base_files.lst
このようになります。
ベース・ファイルには、アップグレードに必要な構成ファイルがリストされています。通常、構成ファイルは変更されません。ベース・ファイル内のファイル（フェイルオーバー関連のファイルを含む）とディレクトリは、アップグレード中にコピーされます。必要に応じてファイルとディレクトリのクリーンアップが実行されます。たとえば、特定のOracle Access Managerリリースにより新規ファイルが追加されるかわりに別のファイルがなくなる場合は、クリーンアップが実行されます。Oracle Access Manager 6.0で追加されたファイルが6.5で不要になったと想定します。このような場合、該当するファイルが次のインストールに含まれなくなります。
ベース・ファイルにリストされているファイルをすべてアップグレードします。
ベース・ファイル・リリースから現在のソース・リリースにいたるすべてのソース・バージョンについて、component_source-version_files.lstファイルにリストされているファイルをアップグレードします。
たとえば、Oracle Access Manager 5.2からアップグレードし、Oracle Access Manager 6.0、6.5および7.0にリリース固有のファイルが存在すると想定します。この場合は、ois_610_files.lst、ois_650_files.lstおよびois_700_files.lstにリストされているファイルがステップ2でコピーされます。ただし、Oracle Access Manager 7.0から10g（10.1.4.0.1）にアップグレードする場合は、現在のソース・リリースがベース・ファイル・リリースとなるため、ステップ2が実行されません。
|
注意: ベース・ファイル内に削除されるファイルが存在する場合は、ベース・ファイルにリストされている内容からそのファイルが削除されます。以前のOracle Access Managerリリースに存在していた場合でも、以降のリリースでは不要になります。 |
また、リリース固有のファイルには、特定のcomponent_source-version_files.lstに固有の変更（この情報は、そのリリースからアップグレードする場合にコピーする必要があります）が含まれます。たとえば、Oracle Access Manager 6.0および6.5で追加になったファイルを考えます。この場合、次のものにこのファイルを追加する必要があります。
ois_600_files.lst
ois_650_files.lst
ois_700_files.lst
|
注意: Oracle Access Managerリリース6.1で何も変更する必要がなかった場合は、ois_610_files.lstは不要となります。 |
詳細を表C-2に示します。
表C-2 obmigratefilesによるファイルのアップグレード
obmigrateparamsgユーティリティは、各コンポーネントに必要なファイルとともにobmigratenpユーティリティからコールされます。
メッセージのアップグレード・プロセス: 以前のメッセージを新しいメッセージにアップグレードし、次のアップグレード先リリース用に新規のメッセージを追加できます。カスタマイズされたメッセージは保持されます。ただし、メッセージ内のパラメータの数が変更された場合は、新しいメッセージしか保持されません。次に例を示します。
ファイル%1をコピーできませんファイル%1のコピー操作に失敗しましたファイル%1を%2から%3にコピーできません|
注意: ここに示した例では、保持されるのは新しいメッセージです。 |
パラメータのアップグレード・プロセス: パラメータのアップグレードはパラメータ・ファイル内で行われます。ユーザーがあるパラメータを以前のOracle Access Managerリリースで変更していた場合に、同じパラメータが新しいリリースによりさらに変更された場合は、obmigrateparamsgユーティリティによって最初の変更が上書きされます。各変更についてはログ・ファイルを確認してください。
以前のOracle Access Managerバージョン: component_Fromrelease_to_Torelease_msg|param.lstという名前のファイルをcomponent_install_dir\identity|access\oblix\tools\migration_toolsディレクトリに追加します。次に例を示します。
ois_520_to_600_msg.lst
ois_520_to_600_param.lst
obmigrateparamsgは、各中間リリースへのアップグレードの実行を伴う繰返しプロセスで使用されます。
|
注意: 前に説明したように、これに先立ってリリース7.0から10g（10.1.4.0.1）へアップグレードした際、LSTファイルがXMLファイルに変換されてターゲット・ディレクトリに保存されています。以前のLSTカタログで行われたカスタマイズが保持され、XMLバージョンのファイルに記載されます。カスタマイズを保持するために手動ステップを別に実行する必要はありません。 |
Oracle Access Manager 10g（10.1.4.0.1）: パラメータ・カタログとメッセージ・カタログの移行は単一のプロセスで実行されます。10g（10.1.4.0.1）には、component_release_param_files.lstという名前のファイルとcomponent_release_msg_files.lstという名前のファイルが含まれています。次にファイルの例を示します。
am_700_param_files.lst
am_700_msg_files.lst
以前のリリースに含まれていた、隠れていたオプションのパラメータが、ターゲットにコピーされます。隠れていたパラメータとは、Oracle Access Managerでサポートされており、ユーザーが追加できるものです。
Oracle Access Manager 10g（10.1.4.0.1）では、Oracle Access Manager 6.5で導入されたマルチ言語機能に対応するための言語IDが、_param|msg_files.lstファイル内のパスに含まれています。この例を次に示します。
file:/oblix/lang/%lang%/frontpagemsg.xml
-pオプションを指定すると、obmigrateparamsgツールは、指定された言語のメッセージ・カタログしかアップグレードしません。このインストーラは次の決定事項に従って以前のリリースの言語を検出してobmigratenpに渡します。
5.2、6.0および6.1の場合: globalparams.xmlファイルから言語タグを検出します。たとえば、language:En_USなどがあります。
6.5以降の場合: obnls.xmlから言語リストを検出します。
表C-3にobmigrateparamsgに関する追加情報を示します。
表C-3 obmigrateparamsgによるメッセージおよびパラメータのアップグレード
「mine_types関連のカスタマイズが維持されない問題」で説明されているように、Oracle Access Manager 6.0からアップグレードする際に、同じParamNameを有する複数のエントリがmime_types（.xmlおよび.lst）ファイル内に存在する場合、これらのエントリはアップグレードされません。
|
注意: 両方のバージョンのファイルが必要となります。不要になったMIMEタイプは、削除することも、今後の使用のために特定の属性に関連付ける新規のMIMEタイプとして追加することもできます。必要な作業は、アイデンティティ・サーバー用のmime_types.lstおよび.xmlファイルを編集して、これらをWebPass_install_dirにコピーし、以前のバージョンを上書きすることだけです。 |
Oracle Access Managerのスキーマは、通常、Oracle Access Managerのメジャー・リリースのたびに拡張されてきました。たとえば、アイデンティティ・サーバーの機能が拡張された場合、アイデンティティ・サーバーは、以前のバージョンよりも多くのスキーマ属性とオブジェクト・クラスを参照できるようになりました。
アップグレードでは、以前のリリースのスキーマと次のリリースのスキーマとの差異が、特定のディレクトリ・サーバーで必要とされるスキーマldifファイルを使用して、ディレクトリ・サーバーにアップロードされます。どのスキーマldifファイルにも、2つのバージョン間の差異に基づく、スキーマを変更するためのエントリが含まれています。スキーマldifファイルでは、次のネーミング規則が使用されます。
DataType_fromrelease_to_torelease_schema_DsType.ldif
次に例を示します。
osd_650_to_700_schema_ad.ldif
policy_650_to_700_schema_nds.ldif
このようになります。
これらのファイルは、様々なアップグレード・マップ・ファイルを含む次のディレクトリに配置されます。
Component_install_dir\identity|access\oblix\tools\migration_tools
アップグレード中に、obmigratenpユーティリティはobmigratenpparams.lstファイルを読み取り、次のファイル内のkMigrateData kMigrateSchemaフラグがtrueに設定されている場合にobmigratedsをコールして、スキーマ・ファイルを内部的にアップロードします。
Component_install_dir\identity|access\oblix\tools\migration_tools
\obmigratenpparams.lst
スキーマのアップグレードは段階的に行われます。つまり、元のリリースがその次の後継リリースにアップグレードされ、アップグレード結果のスキーマも同じ後継リリースにアップグレードされ、以降同様に、元のリリースと最新リリース間の中間スキーマ変更がすべて反映されるまで繰り返されます。不要になったスキーマ要素は、アップグレード中に削除されます。
スキーマのアップグレードは、ディレクトリ・サーバーとのインタフェースとなるOracle Access Managerコンポーネント（アイデンティティ・サーバー、ポリシー・マネージャおよびアクセス・サーバー）においてのみ実行可能です。表C-4に、obmigratedsに関する詳細を示します。
表C-4 obmigratedsによるスキーマのアップグレード
| 説明 | 機能 |
|---|---|
|
obmigrateds.exe |
注意: リリース6.0以降、ChallengeResponsePhrase値のユーザー・エントリをアップグレードするために、RC6暗号化スキームを使用するようになりました。以前のOracle Access Managerバージョンでは、同じ目的にRC4暗号化スキームが使用されていました。 注意: 停止時間ゼロのスキーマのアップグレードにデータのアップグレードは含まれません。詳細は、「スキーマ・モードの処理の概要」を参照してください。 |
|
パス |
Component_install_dir\identity|access\oblix\tools\migration_tools\obmigrateds |
|
コマンドライン |
パラメータを指定せずにobmigrateds.exeを実行してください。すべての入力パラメータの意味を含め、使用方法が出力されます。 |
|
使用するその他のファイル |
|
|
出力 |
このユーティリティは、スキーマとデータの移行を遂行するために、適切な各ユーティリティを起動していきます。 |
|
ログ・ファイル |
次のログ・ファイルを生成します。 install_dir\identity|access\oblix\tools\migration_tools\obmigrateds.log |
新しいOracle Access ManagerリリースにOracle Access Manager固有のデータの新しい編成または値が含まれる場合、データのアップグレードはスキーマのアップグレードとほぼ同様に実行されます。以前のバージョンと新しいバージョンとのデルタが検出されてデータの適切なldifが提供されるため、これらのデータをディレクトリ・サーバーにアップロードできます。アップグレードが完了するまで、メジャー・リリース間のアップグレードが段階的に実行されます。アップグレードが完了すると、Oracle Access Managerはディレクトリにあるデータを検索して使用し、円滑に動作できるようになります。
データのアップグレードは、ディレクトリ・サーバーとのインタフェースとなるOracle Access Managerコンポーネント（アイデンティティ・サーバー、ポリシー・マネージャおよびアクセス・サーバー）においてのみ実行可能です。
オブジェクト・クラス・マッピングと属性マッピングが両方含まれるファイルが入力として使用されます。オブジェクト・クラス・マッピング・ファイルと属性マッピング・ファイルは、次の場所に配置されています。
install_dir\identity|access\oblix\tools\migration_tools\obmigratedata
オブジェクト・クラス・マッピング・ファイルの名前はoc_Fromrelease_to_Torelease_map.lstになります。次に例を示します。
oc_520_to_600_map.lst
oc_610_to_650_map.lst
oc_650_to_700_map.lst
|
注意: Oracle Access Managerリリース6.0.0からリリース6.1.0へはデータは移行されません。このため、oc_600_to_610_map.lstという名前のファイルはありません。 |
属性マッピング・ファイルの名前は次のようになります。
at_Fromrelease_to_Torelease_map_DataType.lst（次に例を示します）
at_520_to_600_map_osd.lst—Oblix schema data
at_520_to_600_map_policy.lst—NetPoint policy data
at_520_to_600_map_user.lst—User data
at_520_to_600_map_wf.lst—Workflow data
600から650、650から700、および700から10g（10.1.4.0.1）にアップグレードする場合のファイルの名前も同様になります。次に例を示します。
at_600_to_650_map_item.lst
at_650_to_700_map_item.lst
itemはOSD、ポリシー、ユーザーまたはワークフローの属性マッピング・ファイルを示します。
obmigratedsユーティリティは、データをアップグレードするために、初期情報（OSDディレクトリ、バインドDN、パスワード、個人オブジェクト・クラス、グループ・オブジェクト・クラスなど）を含むマップ・ファイルを入力引数としてobmigratedataを起動します。このマップ・ファイルでは、次のネーミング規則が使用されます。
data_Fromrelease_to_Torelease_osd.lst
data_Fromrelease_to_Torelease_user.lst
次に例を示します。
data_520_to_600_osd.lst
data_520_to_600_psc.lst
data_610_to_650_osd.lst
data_610_to_650_psc.lst
data_650_to_700_osd.lst
data_650_to_700_psc.lst
data_700_to_1014_osd.lst
data_700_to_1014_psc.lst
ファイル名がこのようになる理由は、アップグレードが段階的に実行されるためです。たとえば、リリース520から始める場合は、最初にデータを520から600にアップグレードし、次に610から650、650から700と続き、最後に700から10g（10.1.4.0.1）にアップグレードします。
|
注意: リリース600から610へのデータのアップグレードはありません。リリース5.2から始める場合は、最初に6.1.1インストーラを使用してリリース6.1.1にアップグレードし、次に10g（10.1.4.0.1）を使用して6.1.1からのアップグレードを実行します。 |
詳細は、表C-5を参照してください。
表C-5 obmigratedataによるデータのアップグレード
ポリシー・マネージャ、WebPassおよびWebGateを拡張すると、使用しているWebサーバー構成ファイルも変更する必要が生じてきます。アップグレード・プロセス中に、Webサーバー構成ファイルを自動更新するかどうかの確認を求められます。Webサーバー構成ファイルは、アップグレード後の手動更新もできますが、自動で更新することをお薦めします。
obmigratenpユーティリティは、Webサーバー構成を更新するため、マップ・ファイルとその他のパラメータを入力引数としてobmigratewsをコールします。マップ・ファイルの名前と場所は次のとおりです。
Component_fromrelease_to_torelease_ws_WebserverType.lst
install_dir\identity|access\oblix\tools\migration_tools
次に例を示します。
am_520_to_600_ws_nsapi.lst
また、obmigratenpは、obmigratewsで生成されたファイルを元のWebサーバー構成ファイルに上書きします。これにより、Webサーバー構成ファイルには、新しいリリースのコンポーネントに適合させるための変更が反映されます。詳細は、表C-6を参照してください。
表C-6 obmigratewsによるWebサーバー構成のアップグレード
どのコンポーネントでも、特定のレジストリや特定ファイルの変更などに対応するための特別な処理がアップグレード中に必要となります。このため、obmigratenp.exeは、アップグレード対象として選択されたコンポーネントに応じて適切なユーティリティをコールします。この工程で実行される一般的なアクションを次に示します。
特定ファイルのコピー/変更
既存コンポーネントのレジストリ・エントリの変更
特定プラグインのコピー
次に、各コンポーネント固有のユーティリティについて説明します。
アイデンティティ・サーバーのアップグレードを実行する場合、obmigratenpツールはobMigrateNetPointOisツールをコールします。詳細は、表C-7を参照してください。
表C-7 obMigrateNetPointOisによるアイデンティティ・サーバーのアップグレード
WebPassのアップグレードを実行する場合、obmigratenpはobMigrateNetPointWPをコールします。詳細は、表C-8を参照してください。
表C-8 obMigrateNetPointWPによるWebPassのアップグレード
ポリシー・マネージャ（以前のAccess Managerコンポーネント）のアップグレードを実行する場合、obmigratenpはobMigrateNetPointAMをコールします。詳細は、表C-9を参照してください。
表C-9 obMigrateNetPointAMによるポリシー・マネージャのアップグレード
アクセス・サーバーのアップグレードを実行する場合、obmigratenpユーティリティはobMigrateNetPointAAAユーティリティをコールします。詳細は、表C-10を参照してください。
表C-10 obMigrateNetPointAAAによるアクセス・サーバーのアップグレード
WebGateのアップグレードを実行する場合、obmigratenpはobMigrateNetPointWGをコールします。詳細は、表C-11を参照してください。
表C-11 obMigrateNetPointWGによるWebGateのアップグレード
Software Developer Kitのアップグレードを実行する場合、obmigratenpはobMigrateNetPointASDKをコールします。詳細は、表C-12を参照してください。
表C-12 obMigrateNetPointASDKによるSDKのアップグレード
