| Oracle Access Managerアップグレード・ガイド 10g（10.1.4.2.0） E05837-01 |
|
 戻る |
 次へ |
この章では、アップグレード・プロセス中にコールされて実行されるツールおよびユーティリティについて説明します。
内容は次のとおりです。
第II部で説明されているように、スキーマおよびデータは自動的にアップグレードすることをお薦めします。ただし、アップグレード・プロセス中にエラーが発生した場合は、次の指示に従って1つのリリースから別のリリースへ手動でアップグレードする必要があります。
スキーマおよびデータの手動アップグレードの実行には、Oracle Access Managerに含まれる特定のユーティリティを使用する必要があります。これらのユーティリティの詳細は、付録Cを参照してください。
この章の例では、リリース5.2を単に説明用として使用しています。6.1.1より前のリリースからアップグレードを開始する場合は、「間接アップグレード・パス」を参照してください。
スキーマを手動でアップグレードする場合、表D-1に記載のように、ディレクトリ・サーバーと、アップグレード元およびアップグレード先の特定のリリースに対して適切なスキーマ・ファイルを選択する必要があります。
|
注意: 表D-1内のアップグレード元およびアップグレード先のリリースが連続していない場合があります。これは、そのリリースではスキーマまたはデータの更新が不要なためです。たとえば、リリース6.0.0と6.1.0では、スキーマが変更されていないため、...600_to_610_ schema_....という名前のファイルはありません。 |
| ディレクトリ・タイプ | スキーマ・ファイル |
|---|---|
|
Active Directory |
osd_520_to_600_schema_ad.ldif policy_520_to_600_schema_ad.ldif user_520_to_600_schema_ad.ldif osd_610_to_650_schema_ad.ldif policy_610_to_650_schema_ad.ldif user_610_to_650_schema_ad.ldif osd_650_to_700_schema_ad.ldif policy_650_to_700_schema_ad.ldif user_650_to_700_schema_ad.ldif osd_700_to_1014_schema_ad.ldif policy_700_to_1014_schema_ad.ldif user_700_to_1014_schema_ad.ldif |
|
ADAM |
osd_650_to_700_schema_adam.ldif policy_650_to_700_schema_adam.ldif user_650_to_700_schema_adam.ldif osd_700_to_1014_schema_adam.ldif policy_700_to_1014_schema_adam.ldif user_700_to_1014_schema_adam.ldif |
|
IBM SecureWay |
osd_520_to_600_schema_ibm.ldif policy_520_to_600_schema_ibm.ldif user_520_to_600_schema_ibm.ldif osd_610_to_650_schema_ibm.ldif policy_610_to_650_schema_ibm.ldif osd_650_to_700_schema_ibm.ldif policy_650_to_700_schema_ibm.ldif user_650_to_700_schema_ibm.ldif osd_700_to_1014_schema_ibm.ldif policy_700_to_1014_schema_ibm.ldif user_700_to_1014_schema_ibm.ldif |
|
Novell eDirectory |
osd_520_to_600_schema_nds.ldif policy_520_to_600_schema_nds.ldif user_520_to_600_schema_nds.ldif osd_610_to_650_schema_nds.ldif policy_610_to_650_schema_nds.ldif osd_650_to_700_schema_nds.ldif policy_650_to_700_schema_nds.ldif user_650_to_700_schema_nds.ldif osd_700_to_1014_schema_nds.ldif policy_700_to_1014_schema_nds.ldif user_700_to_1014_schema_nds.ldif |
|
Oracle Internet Directory |
osd_700_to_1014_schema_oid.ldif policy_700_to_1014_schema_oid.ldif user_700_to_1014_schema_oid.ldif |
|
Siemens DirX |
osd_700_to_1014_schema_dirx.ldif policy_700_to_1014_schema_dirx.ldif user_700_to_1014_schema_dirx.ldif |
|
Sun 4.xおよび5.x |
osd_520_to_600_schema_ns.ldif policy_520_to_600_schema_ns.ldif user_520_to_600_schema_ns.ldif osd_610_to_650_schema_ns.ldif policy_610_to_650_schema_ns.ldif osd_650_to_700_schema_ns.ldif policy_650_to_700_schema_ns.ldif user_650_to_700_schema_ns.ldif osd_700_to_1014_schema_ns.ldif policy_700_to_1014_schema_ns.ldif user_700_to_1014_schema_ns.ldif |
|
Oracle Virtual Directory Server（VDS） |
user_700_to_1014_schema_vde.ldif |
アップグレード・ディレクトリに移動します。
IdentityServer_install_dir\identity\oblix\tools\migration_tools
ディレクトリ・サーバーと、特定のfromrelease_to_releaseに対して適切なスキーマ・ファイルを選択します。
次のコマンドを使用し、スキーマ・アップグレード・ツールds_conf_updateを起動します。
次に例を示します。
IdentityServer_install_dir\identity\oblix\tools\ldap_tools
\ds_conf_update -f schema_file
schema_fileは、表D-1内のサンプルのスキーマ・ファイル名です。
プロンプトに従い、ホスト、ポート、ユーザーID、パスワードなどのオプションを入力します。
このツールの実行中に生じたすべてのエラーは、stdoutに出力されます。このツールは、Oracle Access Manager 10g（10.1.4.0.1）と互換性のあるすべてのディレクトリ・サーバーで使用できます。
Oracle Access Managerには、Oracle Access Manager 5.2から10g（10.1.4.0.1）へのアップグレード時にコールされ、使用されるいくつかのファイルが含まれます。これらのファイルをコピーし、テンプレートとして使用して、アップグレード時に応答するプロンプトを表示または非表示にできます。たとえば、自動データ・アップグレードを可能にするためのプロンプトを表示したり、手動アップグレードを行うためにプロンプトを非表示にすることが可能です。
「サンプルのデフォルトobmigratenpparams.lstファイル」に含まれるテンプレートは、Oracle Access Manager 5.2から10g（10.1.4.0.1）へのアップグレード時に表示されるプロンプトを決定します。
\IdentityServer_install_dir\identity\oblix\tools
\migration_tools\obmigratenpparams.lst
このファイルは、リリース5.2からリリース10g（10.1.4.0.1）までの各メジャー・リリースを、次のメジャー・リリースへアップグレードするセクションに分かれています。obmigratenpparams.lstファイルの、完全な注釈付きのバージョンを、「サンプルのデフォルトobmigratenpparams.lstファイル」に示します。
|
警告: ファイル内のパラメータの順序は、アップグレードの順序を表しているとはかぎりません。 |
ファイルでは各パラメータに適切な値を指定する必要があります。TrueまたはFalseの値の場合、次のようになります。
値がTrueの場合: 自動データ・アップグレード・プロンプトとプログラムを起動します。
値がFalseの場合: データ・アップグレード・プロンプトおよびプログラムが非表示となるため、手動データ・アップグレードを実行する場合に使用できます。
|
警告: お薦めしませんが、「自動データ・アップグレードの抑止」で説明されているように、Oracle Access Managerの構成データおよびユーザー・データの自動アップグレードを抑止できます。その場合、「ユーザー・データの手動アップグレード」の説明に従って、構成データおよびユーザー・データを手動でアップグレードする必要があります。 |
スキーマおよびデータは、自動的にアップグレードすることをお薦めします。ただし、スキーマおよびデータを手動でアップグレードする必要がある場合、この概要を参照してアップグレードしてください。
リリース6.5および7.0の不要なスキーマ要素の削除（必要な場合）
|
警告: スキーマおよびデータは、自動的にアップグレードすることをお薦めします。 |
手動データ・アップグレードを選択した場合、ディレクトリ内の構成データおよびユーザー・データに対して、2つのファイルが提供されます。
\install_dir\identity\oblix\tools\migration_tools\obmigratedata
data_520_to_600_osd.lst: Oracle Access Manager構成データの手動アップグレードを実行します。次に例を示します。
osd_migration:true
policy_migration:true
wf_migration:true
user_migration:false
|
注意: 値がtrueの場合、データをアップグレードします。値がfalseの場合、アップグレードは抑止されます。 |
data_520_to_600_user.lst: ユーザー・データのアップグレードを実行します（Oracle Access Manager 5.2.xから6.0.0へアップグレードする場合のみ必要）。次に例を示します。
osd_migration:false
policy_migration:false
wf_migration:false
user_migration:true
osd.lstファイルおよびuser.lstファイルには同様の情報が含まれます。ただし、ユーザー・データおよび構成データの両方に対して手順が実行され、ファイル内の各パラメータに値が指定される必要があります。表C-7を参照してください。「サンプルdata_520_to_600_xxx.lst」に、注釈付きの例を示します。「データのアップグレード: obmigratedata」も参照してください。
前述の2つの.lstファイルに加え、Oracle Access Manager 10g（10.1.4.0.1）には次のファイルがあります。
data_610_to_650_multi_lang.lst: multi_lang_migration:true
data_610_to_650_osd.lst: osd_migration:true
data_610_to_650_psc.lst: psc_migration:true
data_650_to_700_osd.lst: osd_migration:true and wf_migration:true
data_650_to_700_psc.lst: psc_migration:true
data_700_to_1014_osd.lst: osd_migration:true
data_700_to_1014_psc.lst: psc_migration:true
データを手動でアップグレードする場合、自動データ・アップグレードを抑止する必要があります。
obmigratenpparams.lstファイルをコピーし、元のファイルを別名で保存します。
例:
IdentityServer_install_dir\identity\oblix\tools
\migration_tools\obmigratenpparams.lst
コピーしたファイルのoisセクションを編集し、太字で表示されている値をfalseに変更して自動データ・アップグレードを抑止します。
例:
ois
BEGIN:vCompoundList
520_to_600:
BEGIN:vNameList:
kMigrateData:false
kMigrateSchema:false
kMigratePublisher:false
|
注意: 1つのメジャー・リリースから次のメジャー・リリースへのアップグレードの詳細は、「サンプルのデフォルトobmigratenpparams.lstファイル」の各項を参照してください。たとえば、520_to_600などが該当します。 |
「構成ツリーの手動アップグレード」の手順に従って、手動データ・アップグレードを実行します。
まず構成データ・ツリーのアップグレードを行い、データの手動アップグレードを開始します。次のコマンドは例としてのみ示します。これらは環境によって異なります。
data_fromrelease_to_release_osd.lstファイルをコピーし、元のファイルを別名で保存します。
例:
コピー元
\install_dir\identity\oblix\tools\migration_tools\obmigratedata
\data_520_to_600_osd.lst
コピー先
\install_dir\identity\oblix\tools\migration_tools\obmigratedata
\config_data_520to600_osd.lst
「サンプルdata_520_to_600_xxx.lst」の注釈付きのサンプルに基づいて、ファイルを編集し、使用している環境に合せて情報を指定します。
構成ツリーとデータのパラメータ値がtrueであることを確認してください。
osd_migration:true
policy_migration:true
wf_migration:true
ユーザー・データの移行パラメータ値がfalseであることを確認してください。
user_migration:false
古い構成ツリーをLDIFにエクスポートしてバックアップをとります。
obmigratedataツールを探し、これを実行して、更新されたファイルの名前を指定することによって構成ツリーをアップグレードします。次に例を示します。
\IdentityServer_install_dir\identity\oblix\tools
\migration_tools\obmigratedata\obmigratedata.exe
run obmigratedata.exe -f config_data_520to600_osd.lst -I install_dir
プログラムにより、FunctionalityTBMigratedで選択されたオプションに基づいてLDIFを生成します。生成されるLDIFファイルは、outputFileNameパラメータの指定に基づいて命名されます。
OSDのアップグレードの完了後、既存の構成ツリーを削除します。
6.5から10g（10.1.4.0.1）の場合: アイデンティティ・サーバーおよびポリシー・マネージャをアップグレードする際、ステップ9に進む前に、次の項の「リリース6.5および7.0の不要なスキーマ要素の削除」に進んでください。
すべてのアップグレード: 次の処理を実行し、構成データのアップグレードを完了してください。
Oracleには、リリース6.5と7.0との間の段階的アップグレードに使用するクリーンアップ・ファイルが用意されています。7.xと10g（10.1.4.0.1）間の段階的アップグレード用のディレクトリ・サーバーに対応するクリーンアップ・ファイルは用意されていません。
開始リリースが7.0の場合、また、不要なスキーマをディレクトリ・サーバーから削除しない場合は、この手順をスキップできます。
リリース6.5から10g（10.1.4.0.1）へのアップグレード時に、次の手順を使用してディレクトリ・サーバーから不要なスキーマ要素を削除できます。この手順を実行する場合、次の手動アップグレードのフローで構成ツリーを削除した後に実行する必要があります。
アイデンティティ・サーバーのアップグレード時
ポリシー・マネージャのアップグレード時
スキーマのクリーンアップ後、ディレクトリ・サーバーへLDIFファイルをアップロードできます。構成スキーマとポリシー・スキーマのスキーマ・ファイルは異なります。そのため、不要なスキーマをクリーンアップする場合に考慮する必要のあるシナリオには次の2つがあります。
構成データとポリシー・データが同じディレクトリ・サーバーに格納されている場合
構成データとポリシー・データが別のディレクトリ・サーバーに格納されている場合
表D-2に、特定のディレクトリ・サーバー・タイプごとの構成データ・クリーンアップ・ファイルを示します。
| ディレクトリ・タイプ | スキーマ・クリーンアップ・ファイル |
|---|---|
|
Active Directory |
osd_650_to_700_schema_delete_ad.ldif |
|
ADAM |
osd_650_to_700_schema_delete_adam.ldif |
|
IBM SecureWay |
osd_650_to_700_schema_delete_ibm.ldif |
|
Novell eDirectory |
osd_650_to_700_schema_delete_nds.ldif |
|
Oracle Internet Directory |
Oracle Internet Directoryのサポートは、Oracle COREidリリース7.0.4で導入されました（Oracle Application Server 10gリリース2（10.1.2）の一部としても提供）。そのため、削除する不要なスキーマ・エントリがなく、Oracle Internet Directory用のファイルはありません。 |
|
Sun 4.xおよび5.x 注意: 10g（10.1.4.0.1）は、Sun 4.x Directory Serverをサポートしていません。「Sun Directory Serverの検討と準備」を参照してください。 |
osd_650_to_700_schema_delete_ns.ldif |
表D-3に、特定のディレクトリ・サーバー・タイプごとのポリシー・データ・クリーンアップ・ファイルを示します。
| ディレクトリ・タイプ | スキーマ・クリーンアップ・ファイル |
|---|---|
|
Active Directory |
policy_650_to_700_schema_delete_ad.ldif |
|
ADAM |
policy_650_to_700_schema_delete_adam.ldif |
|
IBM SecureWay |
policy_650_to_700_schema_delete_ibm.ldif |
|
Novell eDirectory |
policy_650_to_700_schema_delete_nds.ldif |
|
Oracle Internet Directory |
Oracle Internet Directoryのサポートは、Oracle COREidリリース7.0.4で導入されました（Oracle Application Server 10gリリース2（10.1.2）の一部としても提供）。そのため、削除する不要なスキーマ・エントリがなく、Oracle Internet Directory用のファイルはありません。 |
|
Sun 4.xおよび5.x 注意: Oracle Access Manager 10g（10.1.4.0.1）は、Sun 4.x Directory Serverをサポートしていません。「Sun Directory Serverの検討と準備」を参照してください。 |
policy_650_to_700_schema_delete_ns.ldif |
ディレクトリ・サーバーおよび開始リリースによっては、この手順を複数回実行する必要があります。
アイデンティティ・サーバーのリリース6.5から7.0へのアップグレード時に不要な要素を削除するには、次の手順を使用します。
アイデンティティ・サーバー・アップグレード時に不要な要素を削除する手順
アップグレード・ディレクトリに移動します。
IdentityServer_install_dir/identity/oblix/tools/migration_tools
ステップ3で名前を指定する必要があるため、表D-2に従って、ディレクトリ・サーバーに適したファイルを選択します。
環境に応じたアクションを実行します。
同じディレクトリ・サーバーの場合: 構成データとポリシー・データが同じディレクトリ・サーバーにある場合、次のコマンドを使用してスキーマ・アップグレード・ツールds_conf_updateを起動します。
IdentityServer_install_dir/identity/oblix/tools/ldap_tools
/ds_conf_update -f schema_file
schema_fileは、表D-2内のスキーマ・クリーンアップ・ファイル名です。
別のディレクトリ・サーバーの場合: 構成データとポリシー・データが別のディレクトリ・サーバーにある場合、ds_conf_updateを次のように2回実行してください。1回目は構成スキーマ用、2回目はポリシー・スキーマ用です。
IdentityServer_install_dir/identity/oblix/tools/ldap_tools
/ds_conf_update -f identity/oblix/tools/migration_tools
schema_fileは、表D-2内の適切なスキーマ・クリーンアップ・ファイル名です。
プロンプトに従い、ホスト、ポート、ユーザーID、パスワードなどのオプションを入力します。
「生成済LDIFのアップロード」からアップグレードを続行してください。
ポリシー・マネージャのリリース6.5から7.0へのアップグレード時に不要な要素を削除するには、次の手順を使用します。
ポリシー・マネージャ・アップグレード時に不要な要素を削除する手順
アップグレード・ディレクトリに移動します。
PolicyManager_install_dir/identity/oblix/tools/migration_tools
表D-3に従って、ディレクトリ・サーバーに適したスキーマ・ファイルを見つけます。
環境に応じたアクションを実行します。
同じディレクトリ・サーバーの場合: 構成データとポリシー・データが同じディレクトリ・サーバーにある場合、次のコマンドを使用してスキーマ・アップグレード・ツールds_conf_updateを起動します。
PolicyManager_install_dir/identity/oblix/tools/ldap_tools
/ds_conf_update -f schema_file
schema_fileは、表D-3内のポリシー・スキーマ・クリーンアップ・ファイル名です。
別のディレクトリ・サーバーの場合: 構成データとポリシー・データが別のディレクトリ・サーバーにある場合、スキーマ・アップグレード・ツールds_conf_updateを次のように2回実行してください。1回目は構成スキーマ用、2回目はポリシー・スキーマ用です。
PolicyManager_install_dir/identity/oblix/tools/ldap_tools
/ds_conf_update -f schema_file
schema_fileは、表D-3または表D-2内の構成スキーマおよびポリシー・スキーマのクリーンアップ・ファイル名です。
プロンプトに従い、ホスト、ポート、ユーザーID、パスワードなどのオプションを入力します。
|
注意: ツールが、属性やオブジェクトが存在しないことを報告するようなエラーを生成することがあります。これは、ディレクトリ・サーバーに存在しないOracle Access Managerリリース3.6の不要なスキーマすべてのリストがLDIFに含まれている場合に発生する場合があります。 |
構成ツリーをアップグレードし、必要に応じて不要なスキーマ要素を削除した後は、生成済LDIFをアップロードできます。
生成済LDIFをアップロードするには、ldapmodifyを実行します。次に例を示します。
\IdentityServer_install_dir\identity\oblix\tools\ldap_tools\ldapmodify
run ldapmodify.exe -f generated_ldif
このプログラムのプロンプトに従い、ホスト、ポート、ユーザーID、パスワードなどのオプションを入力します。
「ユーザー・データの手動アップグレード」の説明に従って、ユーザー・データをアップグレードします。
次に新しいリリースのdata_fromrelease_to_release_osd.lstファイルを使用し、すべてのデータをリリース10g（10.1.4.0.1）にアップグレードするまで、前述のステップを繰り返します。
ここで使用されるリリース番号は、単なる説明用の例です。6.1.1より前のリリースからアップグレードする場合は、その前にOracleサポート・サービスにお問い合せください（http://www.oracle.com/support/contact.html）。
ユーザー・データのアップグレードは、Oracle Access Manager 5.2.xからOracle Access Manager 6.xへの直接的または中間的な移行の場合のみ必要です。
data_fromrelease_to_release_user.lstファイルをコピーし、元のファイルを別名で保存します。
例:
コピー元
\IdentityServer_install_dir\identity\oblix\tools
\migration_tools\obmigratedata\data_520_to_600_user.lst
コピー先
\install_dir\identity\oblix\tools\migration_tools\obmigratedata
\config_data_520to600_user.lst
表D-4を参照しながら、この注釈付きのサンプルに基づいて、使用環境に合せてファイルのキーを編集します。
data_520_to_600_xxx.lstファイルの、完全な注釈付きのバージョンを、「サンプルdata_520_to_600_xxx.lst」に示します。osd.lstファイルおよびuser.lstファイルには同様の情報が含まれます。
Oracle Access Manager構成ツリーとデータのパラメータ値がfalseであることを確認してください。
osd_migration:false
policy_migration:false
wf_migration:false
ユーザー・データのアップグレード・パラメータ値がtrueであることを確認してください。
user_migration:true
|
注意: ユーザー・データ・アップグレードは構成データ・ツリーには影響を与えませんが、ステップ5を実行することをお薦めします。 |
構成ツリーをバックアップします。
obmigratedata.exeを実行し、更新されたファイルの名前を指定することによってユーザー・データをアップグレードします。次に例を示します。
run obmigratedata.exe -f config_data_520to600_user.lst
表D-4 追加または編集するキー
| キー | 説明 |
|---|---|
|
hostname: ホスト名 |
ディレクトリ・サーバー・ホスト。 |
|
portNo: ポート番号 |
ディレクトリ・サーバーのポート。 |
|
bindDN: DS資格証明 |
ディレクトリ・サーバー管理者アカウントのDN。installdir/oblix/config/ldap/AppDB.xmlを参照。 |
|
password: 暗号化されたパスワード |
ディレクトリ・サーバー管理者アカウントのパスワード。installdir/oblix/config/ldap/AppDB.xmlを参照。 |
|
directoryType: NS|AD|NDS|IBM |
実行中のディレクトリ・サーバーのタイプ。 |
|
directoryMode: SSL|OPEN |
使用しているディレクトリ・サーバーのモード。使用可能な値はSSLまたはOpen。 |
|
Oblixnode: ou=Oblix|o=Oblix |
Oracle Access Manager構成ツリーのRDN。 |
|
groupOC: Groupオブジェクト・クラス名 |
例: groupまたはgroupOfUniqueNames。 |
|
PersonOC: Personオブジェクト・クラス名 |
例: userまたはinetOrgPerson。 |
|
oldVersion: リリース番号 |
Oracle Access Manager 5.2システムの正確なリリース番号。./oblix/config/np52_is.txtを参照。例: 5.2、5.2.1.12。 |
|
oldVersionSearchBase: 検索ベース |
使用する検索ベース。通常はグローバル検索ベース。 |
|
binAttrFileName:at_520_to_600_binary.lst |
このファイルをそのまま使用。このファイルには、アップグレード・プログラムの重要な情報が含まれる。 |
|
objclassMapFileName:oc_520_to_600_map.lst |
このファイルをそのまま使用。このファイルには、アップグレード・プログラムの重要な情報が含まれる。 |
|
logFileName: ファイル名 |
変換プロセスにおいて、ロギング情報を取得するファイルの名前。 |
|
outputFileName: ファイル名 |
変換したデータを取得するLDIFファイルの名前。 |
|
missedSuppliedAttrsDetailsFileName: ファイル名 |
Oracle Access Manager 5.2のプロビジョニング属性を含むワークフローを取得するファイルの名前。これらのワークフローを適切なサブフローと関連付けるために、アプレット内で手動で変更することが必要。 |
|
WFDefContainer: |
ワークフロー定義コンテナのDN。例: obcontainerID=workflowDefinitions,OU= oblix,DC=company,DC=com。 |
|
WFInstanceContainer |
ワークフロー・インスタンス・コンテナのDN。例: obcontainerId=workflowInstances, OU=oblix,DC=company,DC =com。 |
|
FunctionalityTBMigrated BEGIN:vNameList |
|
|
osd_migration: true|false |
構成ツリーでデータ・アップグレードを実行。 注意: 以前実行した際に発生したエラーが原因で、データ・アップグレードを実行する場合、次の点に注意すること。
|
|
policy_migration: true|false |
詳細はosd_migrationを参照。 |
|
wf_migration: true|false |
前に指定したワークフロー・コンテナに対してデータ・アップグレードを実行。 注意: ワークフローが別のディレクトリ・サーバーにあるため、手動でデータ・アップグレードを行う場合、次の点に注意すること。
|
|
user_migration: true|false |
ユーザー・エントリ（Oracle以外のデータ）に対してデータ・アップグレードを実行。リリース5.2と10g（10.1.4.0.1）では、チャレンジ・フレーズのレスポンスの暗号化形式が、RC-4からRC-6へと変更された。 ユーザー・データのアップグレードは、デフォルトではインラインで実行される。ユーザー・エントリは、中間LDIFを作成することなく直接変更される。 |
|
END:vNameList |
|
|
Additional_DS_Info: |
ユーザー・データのアップグレードの際、ユーザー・ディレクトリが複数ある場合は、このセクション内で追加のディレクトリ・サーバーを指定する。 |
|
BEGIN:vCompoundList |
|
|
user_migration_ds_1: |
ユーザー・ディレクトリ・サーバーをさらに指定する必要がある場合、形式はuser_migration_ds_n（nに1、2、3などを指定）となる。 |
|
BEGIN:vCompoundList |
|
|
hostname: ホスト名 |
ディレクトリ・サーバー・ホスト。 |
|
portNo: ポート番号 |
ディレクトリ・サーバーのポート。 |
|
bindDN: DS資格証明 |
ユーザー・データ・ディレクトリ・サーバー管理者アカウントのDN。installdir/oblix/config/ldap/AppDB.xmlを参照。 注意: ユーザー・データおよび構成データが別々に格納されている場合、AppDB.xmlファイルには、ユーザー・データ・ディレクトリの正しいバインドDNおよび暗号化されたパスワードが含まれていない場合がある。 |
|
password: 暗号化されたパスワード |
ユーザー・データ・ディレクトリ・サーバー管理者アカウントのパスワード。installdir/oblix/config/ldap/AppDB.xmlを参照。 |
|
directoryType: NS|AD|NDS|IBM |
実行中のディレクトリ・サーバーのタイプ。 |
|
directoryMode: SSL|OPEN |
使用しているディレクトリ・サーバーのモード。使用可能な値はSSLまたはOpen。 |
|
oldVersionSearchBase: 検索ベース |
使用する検索ベース。通常はグローバル検索ベース。 注意: config.lstファイルのAdditional DSにある各ディレクトリ・サーバーには、かつてキーワードoldVersionSearchBaseの検索ベースが割り当てられていた。ただし、10g（10.1.4.0.1）の追加のディレクトリ・サーバー・セクションには、oldVersionSearchBaseキーワードが存在しない。かわりのキーワードがsearchbaseである。このキーワードの値は、必ずしもグローバル検索ベースである必要はない。1つの追加のディレクトリ・サーバー（user_migration_ds_1など）は、構成ツリーの1つのディレクトリ・プロファイルを表す。このセクションのsearchbaseキーワードにより、このディレクトリ・プロファイルに保護されているNamespaceが与えられる。 |
|
END:vCompoundList |
|
|
END:vCompoundList |
BEGIN:vCompoundList am: Policy Manager Parameters BEGIN:vCompoundList kMigrateLicense:false 520_to_600: BEGIN:vNameList: kMigrateWS:true kMigrateData:false kMigrateSchema:true END:vNameList 600_to_610: BEGIN:vNameList: kMigrateWS:false kMigrateData:false kMigrateSchema:false END:vNameList 610_to_650: BEGIN:vNameList: kMigrateWS:true kMigrateData:true kMigrateSchema:true END:vNameList 650_to_700: BEGIN:vNameList: kMigrateWS:true kMigrateData:true kMigrateSchema:true END:vNameListr 700_to_1014: BEGIN:vNameList: kMigrateWS:false kMigrateData:true kMigrateSchema:true END:vNameListr END:vCompoundList wg: (WebGate) BEGIN:vCompoundList 520_to_600: BEGIN:vNameList: kMigrateWS:true END:vNameList 600_to_610: BEGIN:vNameList: kMigrateWS:false END:vNameList 650_to_700: BEGIN:vNameList: kMigrateWS:true END:vNameList 700_to_1014: BEGIN:vNameList: kMigrateWS:true END:vNameList END:vCompoundList wp: (webPass) BEGIN:vCompoundList 520_to_600: BEGIN:vNameList: kMigratePublisher:true END:vNameList 600_to_610: BEGIN:vNameList: kMigratePublisher:false END:vNameList 610_to_650: BEGIN:vNameList: kMigratePublisher:false END:vNameList 650_to_700: BEGIN:vNameList: kMigrateWS:true END:vNameList 700_to_1014: BEGIN:vNameList: END:vNameList END:vCompoundList aaa: (Access Server) Authentication, Authorization, Auditing Parameters BEGIN:vCompoundList 520_to_600: BEGIN:vNameList: kMigrateData:true kMigrateSchema:true END:vNameList 600_to_610: BEGIN:vNameList: kMigrateData:false kMigrateSchema:false END:vNameList 610_to_650: BEGIN:vNameList: kMigrateSchema:false kMigrateData:true END:vNameList 700_to_1014: BEGIN:vNameList: END:vNameList END:vCompoundList bea: BEGIN:vCompoundList 600_to_610: BEGIN:vNameList: kMigrateASDK:true END:vNameList 650_to_700: BEGIN:vNameList: kMigrateASDK:true END:vNameList END:vCompoundList idlk: BEGIN:vCompoundList kMigrateLicense:false END:vCompoundList ois: Identity Server Parameters: True triggers automatic data migration BEGIN:vCompoundList kMigrateLicense:false kMigrateASDK:true 520_to_600: BEGIN:vNameList: kMigrateData:true kMigrateSchema:true kMigratePublisher:true END:vNameList 600_to_610: BEGIN:vNameList: kMigrateASDK:true kMigrateData:false kMigrateSchema:false kMigratePublisher:false kASDKSubDir:/AccessServerSDK END:vNameList 610_to_650: BEGIN:vNameList: kMigrateASDK:true kMigrateSchema:true kMigrateData:true kMigratePublisher:false kASDKSubDir:/AccessServerSDK END:vNameList 650_to_700: BEGIN:vNameList: kMigrateASDK:true kMigrateData:true kMigrateSchema:true kMigratePublisher:false kASDKSubDir:/AccessServerSDK END:vNameList 700_to_1014: BEGIN:vNameList: kMigrateASDK:true kMigrateData:true kMigrateSchema:true kMigratePublisher:false kASDKSubDir:/AccessServerSDK END:vNameList END:vCompoundList was: BEGIN:vCompoundList kMigrateASDK:true 600_to_610: BEGIN:vNameList: kMigrateASDK:true END:vNameList 650_to_700: BEGIN:vNameList: kMigrateASDK:true END:vNameList END:vCompoundList END:vCompoundList
ここでも、使用されるリリース番号は、単なる説明用の例です。6.1.1より前のリリースからアップグレードする場合は、その前にOracleサポート・サービスにお問い合せください（http://www.oracle.com/support/contact.html）。
osd.lstファイルおよびuser.lstファイルには同様の情報が含まれます。詳細は、表C-7を参照してください。ユーザーの移行は、Oracle Access Manager 5.2.xからOracle Access Manager 6.0.0へアップグレードする場合のみ必要です。Oracle Access Manager 6.5.1以降のディレクトリ・サーバーとしてADAMを使用している場合、使用するディレクトリ・タイプはADAMとなります。
BEGIN:vCompoundList hostName:<hostName> portNo:<portNo> bindDN:<bindDN> password:<password> Copy encrypted credentials from \COREid\identity\oblix\config\ldap\AppDB.xml directoryMode:<directoryMode> Open or SSL directoryType:<directoryType> NS or AD or NDS or IBM oldConfigDN:<oldConfigDN> o=company,c=us oldVersionSearchbase:<oldVersionSearchbase>Global Searchbase binAttrFileName:at_520_to_600_binary.lst objclassMapFileName:oc_520_to_600_map.lst logFileName:output_520_to_600_osd.log Okay to change outputFileName:output_520_to_600_osd.ldif Okay to change missedSuppliedAttrsDetailsFileName:output_520_to_600_supplied_osd.txt oblixnode:o=oblix For AD use ou=oblix groupOC:<groupOC> Your Group personOC:<personOC> doUTFConversion:<doUTFConversion> True or False oldVersion:5.2.1.7 Must be specific newVersion:6.0.0 Use proper Release encryptionType:Oblix Changes the encryption scheme from RC4 to RC6; use Oblix unless you have a customized encryption scheme #We want to know wf-containers names Workflow definition containers WFDefContainer:<wfdefcontainer> WFInstanceContainer:<wfdefcontainer> FunctionalityTBMigrated: In the following parameters, True migrates automatically; False does not BEGIN:vNameList osd_migration:true Configuration tree migration (True or False) policy_migration:true wf_migration:true user_migration:false (True migrates data, False does not) END:vNameList oblixdeletedobjects: BEGIN:vCompoundList ad: BEGIN:vList 0ADEL: CN=Deleted Objects adam: BEGIN:vList 0ADEL: CN=Deleted Objects END:vList END:vCompoundList END:vCompoundList
