| Oracle Access Managerアップグレード・ガイド 10g（10.1.4.2.0） E05837-01 |
|
 戻る |
 次へ |
この章では、コンポーネントのアップグレードを開始する際に起動される自動プロセス、および実行する必要がある手動タスクについて概説します。特に明記されていない場合、この章に記載されている情報はインプレース・アップグレードと停止時間ゼロのアップグレードのどちらにも適用されます。内容は次のとおりです。
Oracle Access Managerのすべてのリリースで次のコンポーネントがサポートされます。
アイデンティティ・サーバー（以前のCOREidサーバー）、WebPass、ポリシー・マネージャ（以前のAccess Managerコンポーネント）、アクセス・サーバー、WebGateおよびSoftware Developer Kit。
|
注意: Simple Network Management Protocol（SNMP）は変わっておらず、アップグレードの必要はありません。 |
各Oracle Access Managerアプリケーション。各コンポーネントに不可欠であり、アイデンティティ・システム・コンソール、ユーザー・マネージャ、グループ・マネージャ、組織マネージャ、セレクタ、アクセス・システム・コンソール、ポリシー・マネージャ（以前のAccess Manager）およびその他のアプリケーションがあります。
統合コンポーネント。これには、WebLogic SSPIのセキュリティ・プロバイダやWebSphere用コネクタ、ならびにシングル・サインオン（SSO）、プロビジョニング、ポータル・サーバーおよびアプリケーション・サーバーの統合などがあります。完全な実装については、『Oracle Access Manager統合ガイド』で詳しく説明します。
システム要件および変更については、「プラットフォームのサポート」を参照してください。
各コンポーネントをアップグレードする場合、最新の製品リリースを以前の製品リリースと同じ場所にインストールします。この項では、コンポーネントのアップグレード中にプログラムによって実行されるプロセスについて概説します。
停止時間ゼロのアウトオブプレース・アップグレード: 10g（10.1.4.2.0）のMigrateOAMスクリプトを使用してコマンドラインから開始します。この場合、操作モードと、基盤のユーティリティに渡される引数やパラメータを手動で入力する必要があります。特に明記されていない場合、この項の情報は停止時間ゼロのアップグレード・メソッドに適用されます。自動処理の詳細は、「停止時間ゼロのアップグレードのツールおよびプロセス」を参照してください。ソースとアップグレード先の作成およびその他の準備タスクについては、「停止時間ゼロのメソッドの準備タスク」を参照してください。
インプレース・アップグレード: 対応するOracle Access Manager 10g（10.1.4.0.1）インストーラを使用して開始します。基盤のユーティリティで必要な引数は、処理中にインストーラによって収集されます。一連のイベントとメッセージは、プログラムで自動制御されます。このプロセスでは、ユーザーによる入力はほとんど必要ありません。アップグレードを開始し、アップグレードするコンポーネントが格納されているファイル・システム・ディレクトリを指定すると、以前のバージョンのコンポーネントをアップグレードするかどうかの確認を求められます。
アップグレード・オプションを受け入れる場合、以前のソース・ディレクトリはタイムスタンプ（yearmonthday_hourminutesecond）が追加された名前に変更されます。このタイムスタンプの付いたソースには、以前の元のファイルが含まれます。これらのファイルは、内容の比較やカスタマイズ情報の抽出のために、アクセスされる場合があります。
タイムスタンプの付いたファイル・システム・ディレクトリのサンプル:
\IdentityServer_install_dir_20060422_141440\identity
ソース・ディレクトリの名前がタイムスタンプ付きで変更された後に、ターゲット・ディレクトリが作成され、新規ファイルがターゲットに抽出されます。次に例を示します。
ターゲットのファイル・システム・ディレクトリのサンプル: \IdentityServer_install_dir\identity
すべてのアップグレード・メソッド: ターゲットのファイル・システム・ディレクトリ（停止時間ゼロのアップグレード・メソッドを使用する場合はアップグレード先）が以前のコンポーネントのインストール・パスと一致しない場合、コンポーネント・インスタンスはインストールされます（アップグレードされません）。
「アップグレードのイベントのモード」で説明するように、個々のアップグレード・イベントは、自動実行するか、ユーザーの確認付きで実行するかを選択できます。
必要となる新規フォルダがターゲットのファイル・システム・パス内に作成されます。Oracle Access Managerリリース6.5、リリース7.0および10g（10.1.4.0.1）のディレクトリ構造は、これらのリリース間では同じですが、以前のリリースとは異なります。詳細は、付録Aを参照してください。
図3-1とそれに続くプロセスの概要は、典型的なコンポーネントのアップグレードを説明しています。各コンポーネントに必要な処理は、プロセス中に自動的にコールされるユーティリティによって実行されます。図3-1は、インプレース・アップグレードを示しています。使用するメソッドによって、若干の違いがあります。
インプレース・メソッド: このメソッドが図に示されています。コンポーネントのインストール・プログラムを開始すると、ようこそのメッセージが表示され、特定の入力（コンポーネントのインストール・ディレクトリのファイル・システム・パスなど）が求められます。自動処理を続行すると、操作メソッド（自動または確認）に同意するか、単に続行する準備ができていることを確認するかを尋ねられます。
停止時間ゼロのメソッド: コンポーネント・インスタンスの引数および仕様を含めたコマンドラインを手動で入力すると、この引数および仕様がアップグレードを制御するユーティリティに渡されます。図3-1のプロセス3以降の内部処理は、使用するメソッドを問わずほぼ同じです。停止時間ゼロのアップグレードのスクリプトとモードの詳細は、第15章を参照してください。
インプレース・メソッドを使用している場合、10g（10.1.4.0.1）インストーラを起動すると処理が開始します。停止時間ゼロのメソッドを使用している場合、10g（10.1.4.2.0）のMigrateOAMスクリプトを起動すると、処理はプロセス3から開始します。
各コンポーネントを、各メジャー・リリースから次のメジャー・リリース、さらに10g（10.1.4.0.1）へアップグレードする際に、各リリース間での追加と変更が実装されます。このため、開始リリースと10g（10.1.4.0.1）との間にあるすべての変更点が組み込まれるまで、一連のイベントおよびメッセージが自動的に繰り返されます。
|
注意: 次のような「プロセスの概要」では、自動化されたプロセスを示しています。プロセスを開始した後、いくつかのイベントの承認または確認を求められる場合があります。場合によっては、イベントをスキップするか拒否することも可能です。 |
インプレース・メソッド: 10g（10.1.4.0.1）コンポーネント・インストーラを起動して、同じ場所に以前のソース・ディレクトリがあることが検出されると、アップグレードするかどうかの確認を求められます。アップグレードを受け入れる場合、ソース・ディレクトリがタイムスタンプ付きの名前に変更されます。
インプレース・メソッド: ターゲット・ディレクトリが作成され、10g（10.1.4.0.1）ファイルがそのディレクトリに抽出されます。言語は自動的に英語がアップグレードされます。その他にインストール済である言語は、対応する10g（10.1.4.0.1）言語パックを、10g（10.1.4.0.1）コンポーネント・インストーラと同じディレクトリにインストールすることでアップグレードされます。
|
注意: 10g（10.1.4.0.1）言語パックを使用しないで既存のマルチ言語実装をアップグレードすると、マルチ言語機能が失われます。 |
両方のメソッド: ユーティリティobmigratenpが、コンポーネント・インストーラによってコールされ、アップグレード元のリリースとアップグレード先のリリースを判別します。obmigratenpは、アップグレードする必要があるこのコンポーネントの機能、およびアップグレードに使用する他のユーティリティを内部的に検出します。既存インストールに複数の言語が含まれている場合、obmigratenpはメッセージ・カタログを移行します。
両方のメソッド: ユーティリティobmigratefilesが、以前のプログラム・ファイルおよびライブラリ・ファイルをアップグレードするためにコールされます。
両方のメソッド: ユーティリティobmigrateparamsgが、以前のメッセージ・カタログ・ファイルおよびパラメータ・カタログ・ファイルをアップグレードするためにコールされます。
スキーマおよびデータのアップグレードのみ: 2つのユーティリティobmigratedsおよびobmigratedataが、Oracle Access Managerのスキーマとデータのアップグレードを開始するために自動的にコールされます。
停止時間ゼロのメソッド: スキーマとデータが個別にアップグレードされます。詳細は、「停止時間ゼロのアップグレード・メソッドを使用したスキーマおよびデータのアップグレード」を参照してください。
インプレース・メソッド: スキーマとデータは、マスター・アイデンティティ・サーバー（インストールにアクセス・システムが含まれる場合はマスター・ポリシー・マネージャも）と一緒にアップグレードされます。後続のアイデンティティ・サーバー（およびポリシー・マネージャ）のアップグレード時には、最初のスキーマおよびデータのアップグレードが検出され、プロセスのその部分がスキップされます。Oracle Access Managerのスキーマおよびデータは、自動的にアップグレードすることをお薦めします。このような自動アップグレードでは、ユーザーのディレクトリ・サーバーに固有のLDIFファイルが使用されます。各LDIFファイルに含まれるのは、Oracle Access Managerの1つのリリースと次のリリースとの間の変更点のみです。つまり、スキーマおよびデータのアップグレードは、開始するリリースから10g（10.1.4.0.1）にいたるまで、各リリースへのアップグレードごとに1回繰り返されます。詳細は、第II部を参照してください。
Web Server構成の更新のみ: ユーティリティobmigratewsがコールされ、指定のWebサーバー構成ファイルおよびフィルタのアップグレードを実行し、ポリシー・マネージャ、WebPassおよびWebGateの新しいリリースの変更内容を組み込みます。
両方のメソッド: コンポーネント固有のユーティリティが選択、実行され、Windowsの関連するレジストリ・エントリ、プラグインおよびその他のファイルが変更されます。コンポーネントの構成ファイルが更新されます。詳細は、「コンポーネント固有のアップグレード」を参照してください。
各コンポーネントのアップグレード中に、問題が発生していないかどうかを通知するためのログ・ファイルが1つ以上生成されます。ログ・ファイルが作成される場合、アップグレード・プロセスのメッセージにより、ログ・ファイルの名前と場所が表示されます。通常、アップグレード・ログ・ファイルは次の場所に生成されます。
\Component_install_dir\identity|access\oblix\tools\migration_tools\toolname.log
ここで、\Component_install_dirはそのコンポーネントがインストールされた場所、identity|accessはコンポーネントが属するシステム（それぞれアイデンティティ・システムまたはアクセス・システム）、toolnameは、ログを生成するユーティリティの名前です。
各ログ・ファイルには、コンポーネントのアップグレード中に発生する特定のアクティビティに関する情報が含まれます。たとえば、ファイルのアップグレード、メッセージとパラメータのアップグレード、およびOracle Access Managerスキーマのアップグレードに対して、別個のログ・ファイルが生成されます。各ログ・ファイルとその内容については、付録Cを参照してください。
また、ldap固有のエラーを通知するために、次のログ・ファイルが作成されます。
アイデンティティ・サーバー・データの移行時に、error_output_fromversion_to_toversion_osd.ldifファイルがIdentityServer_install_dir\identity\oblix\tools\migration_tools\obmigratedataディレクトリに作成されます。
ポリシー・マネージャ・データの移行時に、error_output_fromversion_to_toversion_psc.ldifファイルがPolicyManager_install_dir\access\oblix\tools\migration_tools\obmigratedataディレクトリに作成されます。
停止時間ゼロのアップグレードの場合、MigrateOAMスクリプトのブランチ作成（Mkbranch）操作中に実行されるアクティビティのログを記録する新しいログ・ファイルも提供されます。詳細は、「停止時間ゼロのアップグレードのツールおよびプロセス」を参照してください。
ログ・ファイルの使用とその他のトラブルシューティングのヒントについては、付録Gを参照してください。
インプレースまたは停止時間ゼロのどちらの手法を選択する場合も、コンポーネントのアップグレード時に次の項目がアップグレードされます。
Oracle Access Managerのスキーマならびに構成およびポリシーのデータが、アップグレード用にインストールされたマスターのアイデンティティ・サーバーおよびポリシー・マネージャのみを使用してアップグレードされます。
Webサーバー構成の、Webコンポーネント（WebPass、ポリシー・マネージャ、WebGate）用のファイルおよびフィルタのみが、アップグレードされます。
コンポーネント固有の情報（コンポーネント構成ファイル、およびWin32のレジストリ・エントリなどのシステム環境設定を含む）。
製品名およびコンポーネント名が、「製品およびコンポーネントの名前の変更」に説明されているように変更されます。
次のリストに示すように、いくつかの構成ファイル（フェイルオーバー用の構成ファイルとSoftware Developer Kit（SDK）の構成ファイル）がアップグレードされます。
アクセス・サーバー: フェイルオーバー・ファイル
SDK構成: アップグレードは、アイデンティティ・サーバー（およびSoftware Developer Kitライブラリを使用する統合コンポーネント）のアップグレード時の最終ステップとして自動的に開始されます。現在の構成設定を保持する場合は、自動アップグレードを受け入れることをお薦めします。自動アップグレードにしない場合は、第11章の説明にあるように、後でconfigureAccessGateツールを使用してSDKを再構成する必要があります。
次の情報は、インプレースまたは停止時間ゼロのどちらのアップグレード手法を選択する場合も適用されます。
製品のインストールおよび構成の際に管理者が割り当てた名前は、アップグレードの間、保持されます（変更されません）。したがって、サービスに「COREid Identity Server」または「NetPoint Identity Server」と名前を付けた場合、これらの名前はアップグレード環境でも変わりません。
管理者によって割り当てられた以前の認証スキームおよびポリシー・ドメインも、アップグレード時に保持されます。すなわち、アップグレードの後も、これらの名前は有効です。
次のリストの項目が、タイムスタンプ付きのディレクトリに保持され、新しいターゲット・ディレクトリにコピーされます。
リリース7.0に始まり10g（10.1.4.0.1）でも、デフォルトの証明書ストアの形式と名前はcert7.dbからcert8.dbに変わっています。アップグレードの後、古い証明書ストアが使用されます。10g（10.1.4.0.1）（およびリリース7.x）は、cert7.db（アップグレードされた環境）とcert8.db（新規インストール）の両方の証明書ストアで動作します。「証明書ストアおよびローカライズされた証明書」を参照してください。
詳細は、次の項を参照してください。
アクセス・システムのリリース6.5以降、ディレクトリ・プロファイルはポリシー・マネージャの設定時に作成され、ユーザー・ディレクトリ・データにアクセスするためにアクセス・システムによって使用されます。これらのプロファイルは、アクセス・システムの以前のリリースで使用されていたUserDB.lstとGroupDB.lstファイルおよびUserDBFailover.lstとGroupDBFailover.lstの各構成ファイルに置き換わるものです。
リリース6.1.1からのアクセス・システムのアップグレード時には、新規のディレクトリ・プロファイルが、UserDB.lstとGroupDB.lstファイルおよびUserDBFailover.lstとGroupDBFailover.lstの各構成ファイルに基づいて作成されます。
以前の実装に、アイデンティティ・サーバーとディレクトリ・サーバーの間のフェイルオーバーも含まれている場合があります。アイデンティティ・サーバーのフェイルオーバー構成は、リリース5.2以降、ディレクトリ・サーバー・プロファイルに格納されています。このため、アイデンティティ・サーバーのアップグレード時には、フェイルオーバー構成ファイルからディレクトリ・プロファイルへのパラメータの移行はありません。スキーマ自体が変更されていますが、この変更の移行はアップグレード中に自動的に実行されます。
リリース6.5以降、アクセス・システムは、ユーザー・データへのアクセスに対するディレクトリ・プロファイルとデータベース・インスタンスの使用を部分的に開始しました。ディレクトリ・プロファイルは、アクセス・システムの以前のリリースで使用されていたUserDB.lst、GroupDB.lst、UserDBFailover.lst、GroupDBFailover.lstの各構成ファイルのかわリに使用されます。リリース6.5への段階的アップグレード中に、アクセス・サーバーのディレクトリ・プロファイルが自動的に作成され、次に示すいくつかの以前の構成ファイルと置き換えられます。
プライマリ・ディレクトリ・サーバーの情報: AccessServer_install_dir/access/oblix/config/UserDB.lstおよびGroupDB.lst
フェイルオーバーおよびロード・バランシングのためのすべてのディレクトリ・サーバー（プライマリおよびセカンダリ）に関する情報: AccessServer_install_dir/access/oblix/config/UserDBFailover.lstおよびGroupDBFailover.lst
ポリシー・マネージャに対するディレクトリ・サーバー・プロファイルを作成する場合、ディレクトリ・サーバー資格証明はPolicyManager_install_dir/access/oblix/config/userDB.lstから読み取られます。
|
注意: 構成ツリーがユーザー・ディレクトリ・サーバー内でユーザー・ノードの下にある場合、構成ディレクトリ・プロファイルは作成されません。ノードの下にない場合、構成ディレクトリ・プロファイルはPolicyManager_install_dir/oblix/config/ldap/configdb.lstからのディレクトリ・サーバー情報を使用して作成され、ポリシー・マネージャ専用としてマークされます。 |
ポリシー・マネージャ・フェイルオーバー・サーバー用に使用されるプロファイルが作成されなくなります。リリース6.1では、ポリシー・ツリーが別のディレクトリ・サーバー上にある場合に、ポリシー・データのプロファイルが用意されていました。
アイデンティティ・システムおよびアクセス・システムをアップグレードした後は、フェイルオーバーおよびロード・バランシングの構成を検証し、これらがアップグレード後も意図したとおりに動作するかどうかテストすることをお薦めします。詳細は、次を参照してください。
次の「接続プールの詳細」も参照してください。
『Oracle Access Managerデプロイメント・ガイド』で説明されているように、ディレクトリとの間で開かれる接続の数は、データベース・インスタンス・プロファイルの「最初の接続数」パラメータによって指定されています。必要に応じて、追加の接続が、データベース・インスタンス・プロファイルの「最大接続数」パラメータに指定した数と等しくなるまで開かれます。アイデンティティ・サーバーまたはアクセス・サーバーが停止するかディレクトリ・サーバーからのレスポンスが停止するまで、接続は開いたままの状態になります。開かれた接続は、アイデンティティ・サーバーおよびアクセス・サーバーによってプールされて使用されます。
|
注意: Oracle Access Managerリリース7.0以降、接続プールはシステム全体でのフェイルオーバーのサポートに統合されました。ディレクトリ接続プールは、ディレクトリのタイプに依存しません。 |
使用される各ディレクトリ・サーバーに対するOracle Access Managerの以前の構成によって、アクセス・システムのアップグレードになんらかの影響が出る場合があります。詳細は、「アクセス・システムのフェイルオーバーおよびロード・バランシングの確認」を参照してください。
また、前述の「ディレクトリ・サーバーのフェイルオーバー」も参照してください。
使用される各ディレクトリ・サーバーに対するOracle Access Managerの以前の構成によって、アップグレードになんらかの影響が出る場合があります。次に例を示します。
アイデンティティ・システム接続プール: 影響はありません。データベース・インスタンス・プロファイルで指定した「最初の接続数」および「最大接続数」は保持され、以前と同様に動作します。
リリース6.5より前のアクセス・システム接続プール: UserDB.lstおよびUserDBFailover.lstの「最初の接続数」および「最大接続数」の値は保持されません。アクセス・システム・コンポーネントをアップグレードした後は、新規に作成されたディレクトリ・サーバー・プロファイルのデータベース・インスタンス・プロファイルの値を確認することをお薦めします。
NDS: NDSディレクトリ・サーバーへの同時認証リクエストの場合は、システム・コンソールを使用して、接続プールのサイズを、ユーザー・ディレクトリ・プロファイルのデフォルト（1）より大きい値に設定することをお薦めします。
共有シークレット暗号化アルゴリズムは、Oracle Access Manager全体に対しての設定です。これは、すべての暗号化Cookieに影響を与えます。たとえば、ObSSOCookieは共有シークレットと呼ばれる構成可能な暗号化スキームを使用して暗号化されます。アップグレードにおいて、以前の暗号化スキームは保持されます。
7.0.4およびそれより以前のリリースでは、WebGate/アクセス・ゲートが共有シークレット値を使用して暗号化と復号化を処理していました。これに対して、10g（10.1.4.0.1）からは、アクセス・サーバーが暗号化と復号化を処理します。この結果、WebGateでは共有シークレットは不要になりました。
以前のWebGateをアップグレードすることをお薦めします。ただし、以前のWebGateでも、特定の条件を満たしている場合は、10g（10.1.4.0.1）のアクセス・サーバーと共存できます。暗号化スキーム、共有シークレット、アクセス・サーバーおよびWebGateの詳細は、第4章を参照してください。
インプレース・アップグレードまたは停止時間ゼロのどちらのアップグレード手法を選択する場合も、次の項目が適用されます。リリース10g（10.1.4.0.1）との互換性が確保され、正しく動作するように、手動でアップグレード・タスクを実行する必要がある項目は次のとおりです。
上の項目だけでなく、次の各項で詳細を参照してください。
Oracle Access Manager 10g（10.1.4.0.1）は、Unicode規格をサポートしています。Oracle Access Manager 10g（10.1.4.0.1）で使用可能な言語をすべてサポートするために、監査およびレポートの表の定義が変更されました。既存のデータベース・インスタンスや表の単純なアップグレードや変更はサポートされていないため、それらの処理を行うと、既存データが永久的に切り捨てられ、失われます。
アイデンティティ・システム（およびアクセス・システム）のアップグレード後に、10g（10.1.4.0.1）で動作する新規のデータベース・インスタンスを作成する必要があります。10g（10.1.4.0.1）UTF-8データの監査とこの新規SQLサーバー・インスタンスへのこのデータの書込みをサポートする新規の監査表スキーマをアップロードするため、新規のoblix_audit_events表を作成する必要があります。このスキーマのアップグレードには、監査表の列内のデータ型の変更が含まれます。次に、レポート・アプリケーションに使用する表（oblix_rpt_as_reports、oblix_rpt_as_resourcesおよびoblix_rpt_as_users）を10g（10.1.4.0.1）で作成する必要があります。
新旧両方のデータベースからのデータを使用するレポートを問合せまたは生成するには、10g（10.1.4.0.1）で監査を開始する前に、元のインスタンスから新規インスタンスにデータをインポートする必要があります。これは、環境によって必要の有無が異なる、オプションの手順です。
|
注意: 元のデータを保持しておくため、以前のデータベースは残しておいてください。以前のデータをインポートすると、データが切り捨てられて失われることがあるためです。ただし、監査の開始前に旧データをインポートしない場合は、旧データベースと新規データベースの両方からのデータを使用したレポートは生成できません。 |
英語のみの環境であったとしても、使用しているデータベースのタイプによって、実行する必要のある手順が異なります。詳細は、次を参照してください。
「プラグイン」に記載した理由により、アップグレードの後に、Software Developer KitおよびOracle Access Manager APIで作成したC++プログラムを再コンパイルする必要があります。
|
注意: コンポーネントのアップグレードを開始する前に、最初に以前のカスタマイズをテスト環境に移行することをお薦めします。これにより、本番環境のアップグレードおよびカスタマイズの再デプロイを行う際のシステム停止時間を削減できます。 |
アイデンティティ・システムおよびアクセス・システムの場合のC++プログラムとこれらのアップグレードの詳細は、第4章、第12章、第13章をそれぞれ参照してください。
以前のリリースでは、チャレンジ・フレーズ属性とレスポンス属性を各「プロファイル」ページの異なるパネルに配置できました。ただし、10g（10.1.4.0.1）では、チャレンジ・フレーズ属性とレスポンス属性を同じパネルにのみ配置できます。10g（10.1.4.0.1）では、チャレンジ・フレーズとレスポンスがパネル上で連続して構成されなくても、隣接して表示されます。
単一パネルへのチャレンジ属性とレスポンス属性の表示の詳細は、「単一パネルへのチャレンジ属性とレスポンス属性の配置」を参照してください。
製品のデフォルト・スタイルシートは、オラクル社によって、改善点を反映するために定期的に更新されます。たとえば、Oracle Access Managerリリース6.5以降、マルチ言語をサポートするため、JavaScript、スタイルシートおよびイメージの場所が変更されました。リリース6.5で導入されたディレクトリ構造が、10g（10.1.4.0.1）でも引き続き使用されています。
アップグレードされた機能は、部分的に、新しいリリースの\style0ディレクトリおよび\sharedディレクトリにあるスタイルシート・ファイルに依存します。
|
注意: 以前のOracle Access Managerの\style0ディレクトリにあったファイルをカスタマイズした場合は、アップグレードの後で、\style0および\sharedディレクトリにある新しいバージョンのファイルを手動で変更する必要があります。 |
カスタム・イメージおよびスタイルシートを10g（10.1.4.0.1）に正常に移行するには、新しいファイル階層とスタイルシート構造を理解することが重要です。古いスタイルシート、イメージ、JavaScriptファイルおよび新リリースの関連項目を単純にコピーすると、Oracle Access Managerで問題が発生することがあります。
アップグレード後に手動で次のファイルを処理する必要があります。
|
注意: コンポーネントのアップグレードを開始する前に、最初に以前のカスタマイズをテスト環境に移行することをお薦めします。これにより、本番環境のアップグレードおよびカスタマイズの再デプロイを行う際のシステム停止時間を削減できます。 |
アイデンティティ・システムのカスタマイズのアップグレードについては、第12章を参照してください。Oracle Access Managerのディレクトリ構造の詳細は、付録A「Oracle Access Managerディレクトリ構造の変更点」を参照してください。
プラグインの動作は、最新リリースで変更されました。カスタム・プラグインに関する次の各項目を重要ポイントとして認識しておく必要があります。
以前のプラグインはすべて、Latin-1エンコーディングでデータを送受信します。10g（10.1.4.0.1）からは、Oracle Access Managerのコンポーネントおよびプラグインは、UTF-8形式でデータを送受信します。10g（10.1.4.0.1）にアップグレードされたアイデンティティ・サーバーおよびアクセス・サーバーは、自動的にLatin-1エンコーディングを使用して、以前のプラグインとの下位互換性を持ちます。ただし、以前のプラグインで国際化されたデータを送受信するには、以前のプラグインをUTF-8エンコーディングで通信するように設計を変更する必要があります。これには、アイデンティティ・イベント・プラグインと、カスタム認証および認可プラグインも含まれます。グローバリゼーションの詳細は、第4章を参照してください。
Oracle Access Managerリリース7.0以降、それより前のコンパイラ・リリースで発生していたマルチスレッドの問題に対処するため、SolarisおよびLinuxでのコンポーネントはGCC v3.3.2 C++コンパイラを使用してコンパイルされます。つまり、アップグレードした後は、GCC v3.3.2 C++コンパイラを使用して、リリース5.xまたは6.xのカスタム・プラグインを再コンパイルする必要があります。これには、アイデンティティ・イベント・プラグインと、カスタム認証および認可プラグインも含まれます。オペレーティング・システムに付属のコンパイラがある場合でも、GCC v3.3.2コンパイラを使用する必要があります。
|
注意: リリース7.0のプラグイン、および実行可能ファイルとして実装されている以前のプラグインやスクリプト言語（Perlなど）を使用するプラグインは、アップグレード後の再コンパイルを必要としません。ただし、以前のプラグインで国際化されたデータを送受信するには、以前のプラグインをUTF-8エンコーディングで通信するように設計を変更する必要があります。 |
アイデンティティ・イベントAPIプラグイン: いくつかのプラグインはアップグレード中にコピーされますが、アイデンティティ・イベントAPIプラグインはコピーされません。アップグレード後に、以前のアイデンティティ・イベント・プラグインを移行する必要があります。これらのプラグインの再コンパイルや設計変更が必要な場合もあります。詳細は、「カスタム・アイデンティティ・イベント・プラグインの移行」を参照してください。
認証および認可プラグイン: アクセス・システムのアップグレードが終了したら、「カスタム認証および認可プラグインの再コンパイルおよび設計変更」を参照してください。また、『Oracle Access Managerアクセス管理ガイド』には、次に関する詳細が記載されています。
保護するアプリケーション・サーバー上のカスタム認可プラグインをインストールし、デフォルト・スキームのタスクと異なる（または追加の）タスクを実行するためにカスタム・プラグインを含むカスタム・スキームを作成すること。
|
注意: コンポーネントのアップグレードを開始する前に、最初に以前のカスタマイズをテスト環境に移行することをお薦めします。これにより、本番環境のアップグレードおよびカスタマイズの再デプロイを行う際のシステム停止時間を削減できます。詳細は、「カスタマイズのアップグレード計画」を参照してください。 |
既知の問題に対する最新の修正を入手するには、最新のパッチ・セットを入手して適用することをお薦めします。リリース10.1.4パッチ・セット1（10.1.4.2.0）には、『Oracle Access Manager概要』の新機能を記載する章で説明するように、いくつかの新機能も組み込まれています。
インプレース・メソッド: Oracle Access Manager 10g（10.1.4.0.1）へのアップグレード後、最新のパッチ・セットを入手して、アップグレードした各インスタンスにそのパッチ・セットを適用することをお薦めします。詳細は、サポートされるすべてのオペレーティング・システム用のOracle Access Manager Patch Set Notes Release 10.1.4 Patchset 1 (10.1.4.2.0)を参照してください。
停止時間ゼロのメソッド: この場合、各コンポーネント・インスタンスは10g（10.1.4.2.0）のMigrateOAMスクリプトを使用してアップグレードされ、インスタンスはすでにリリース10g（10.1.4.2.0）になっています。リリース10.1.4パッチ・セット1（10.1.4.2.0）を適用する必要はありません。ただし、後続のパッチ・セットが入手可能な場合、そのパッチ・セットを入手して適用する必要があります。
