ヘッダーをスキップ
Oracle Access Managerアップグレード・ガイド
10g(10.1.4.2.0)
E05837-01
  目次
目次
索引
索引

戻る
戻る
 
次へ
次へ
 

8 コンポーネントのアップグレード準備

この章では、残りのアイデンティティ・システムおよびアクセス・システムのコンポーネントのアップグレードを開始する前に、既存の環境を整えておく際に必要となる情報について説明します。各自の計画ドキュメントを参照し、付録Fの概要を使用して進捗状況を追跡してください。

特に明記されていない場合、使用するアップグレード・メソッドを問わず、これらのアクティビティを実行します。停止時間ゼロのアップグレードの詳細は、第VI部を参照してください。これらのタスクは、アップグレードの際にプラットフォームをSolarisからLinuxに切り替える場合(付録Bを参照)も実行します。内容は次のとおりです。


注意:

この章では、以前の製品やコンポーネントを指している場合でも、新しい製品名およびコンポーネント名を使用しています。たとえば、Oblix NetPointやOracle COREidのかわりにOracle Access Managerが使用されています。詳細は、「Oracle Access Managerの新機能」を参照してください。

8.1 以前のリリースとの互換性のチェック

以前のインストールと10g(10.1.4.0.1)間の互換性を確保するために必要な作業がいくつかあります。第2章で説明しているように、一部の項目はサポートされなくなっています。サポートの変更を受けて対処方法の決定が必要となる場合もあります。

10g(10.1.4.0.1)との互換性を確保する手順

  1. 「終了したサポート」を確認します。

  2. 次の説明に従って、10g(10.1.4.0.1)のプラットフォームのサポートを確認します。

    1. https://metalink.oracle.comのMetaLinkにアクセスします。

    2. 指示に従ってMetaLinkにログインします。

    3. 「Certify」タブをクリックします。

    4. 「View Certifications by Product」をクリックします。

    5. 「Application Server」オプションを選択し、「Submit」をクリックします。

    6. 「Oracle Identity Manager」を選択し、「Submit」をクリックします。

    7. 「Oracle Identity Management Certification Information 10g (10.1.4.0.1)」(html)をクリックして「Oracle Identity Management」ページを表示します。

    8. 「Section 6, "Oracle Access Manager Certification"」のリンクをクリックして、証明書マトリクスを表示します。

  3. ディレクトリ・サーバーまたはWebサーバーのバージョンまたはプラットフォームのサポートが変更されている場合の作業方法は、「サポートが変更または終了した場合のアップグレード計画」を参照してください。

8.2 カスタム・アイデンティティ・イベント・プラグインのコピー

アップグレード時には、すべての標準プラグインと同様に、カスタムの認証および認可プラグインもコピーされます。ただし、アイデンティティ・イベント・プラグインAPIを使用して作成されたカスタム・アイデンティティ・イベント・プラグインは、アップグレード時にコピーされません。

アップグレードの前に独立した小規模な環境(または停止時間ゼロのクローン環境)で次の手順を実行し、カスタム・アイデンティティ・イベント・プラグインを設計変更に備えて準備することをお薦めします。

アイデンティティ・イベント・プラグインをアップグレード前にコピーする手順

  1. アップグレード前に、アイデンティティ・イベントAPIディレクトリの最上位に、古いアイデンティティ・イベント・プラグイン用のディレクトリを作成します。

  2. カスタム・アイデンティティ・イベント・プラグインを新規ディレクトリにコピーします。

  3. 次の「以前のカスタマイズの準備」に進みます。

8.3 以前のカスタマイズの準備

既存環境のカスタマイズの手動処理は、コンポーネントのアップグレードの前に余裕を持って開始することをお薦めします。この処理は、サービスの中断を最小限に抑えるためにテストまたは開発環境で行います。カスタマイズのアップグレードおよびテストが完了した後、「カスタマイズのアップグレード計画」の説明に従って、アップグレード後の環境にカスタマイズをデプロイできます。


注意:

停止時間ゼロのアップグレード・メソッドを使用している場合、カスタマイズのアップグレードを早期に実行して、アップグレードしたクローン環境内で十分にテストすることをお薦めします。詳細は、「停止時間ゼロのアップグレード・メソッドを使用したカスタマイズのアップグレード」を参照してください。

多くのカスタマイズは、使用するアップグレード・メソッドを問わず、コンポーネントのアップグレードの前に作業を開始できます。ただし、コンポーネントのアップグレード後でないと実行できないカスタマイズのアップグレードもいくつかあります。

アイデンティティ・システム: 次のタスクの概要に、実行する必要があるアイデンティティ・システムのカスタマイズ作業と、第12章にある詳細の参照先をリストします。

タスクの概要: 以前のアイデンティティ・システムのカスタマイズのアップグレード

  1. アイデンティティ・システムの監査およびアクセス・レポートのアップグレード

  2. 単一パネルへのチャレンジ属性とレスポンス属性の配置

  3. アイデンティティ・システムのフェイルオーバーおよびロード・バランシングの確認

  4. カスタム・アイデンティティ・イベント・プラグインの移行

  5. 以前のPortal Insertsとの互換性の確保

  6. リリース6.5および7.xからのカスタマイズの組込み

  7. 6.5より前のリリースからのカスタマイズの組込み

アイデンティティ・システムとアクセス・システムの混合: 前述のタスクの概要で示したアイデンティティ・システムの作業の他に、以前のアクセス・システムのカスタマイズもアップグレードする必要があります。次の概要では、手動で実行する必要があるアクセス・システムのカスタマイズのアップグレードを示します。詳細は、第13章を参照してください。

タスクの概要: 以前のアクセス・システムのカスタマイズのアップグレード

  1. アクセス・サーバーの監査およびレポートのアップグレード

  2. フォーム・ベース認証のアップグレード

  3. カスタム認証および認可プラグインの再コンパイルおよび設計変更

  4. リリース6.1.1の認可ルールとアクセス・ポリシーの関連付け

  5. 6.1.1からのアップグレード後に認可失敗のリダイレクトが正しく行われるようにするための作業

  6. カスタムCコードのObAMMasterAuditRule_getEscapeCharacterの更新

詳細は、「アップグレードと下位互換性の概要」を参照してください。

8.4 ポリシー・マネージャのデフォルトのログアウトでの準備

アップグレードの前に、ポリシー・マネージャでデフォルトのログアウトを非保護にする必要があります。非保護にしない場合は、アップグレード後に、ユーザーが、「ログアウト」リンクをクリックしたときに情報の入力を求められます。

デフォルトのログアウトをアップグレード用に準備する手順

  1. ポリシー・マネージャでデフォルトのログアウトを非保護にします。

  2. WebGateのログアウト用にoblogout.cgiを使用する場合は、必ずターゲット・サーバーにインストールします。

8.5 ホスト・コンピュータでの準備

以前のインストールをホストするコンピュータに対する準備の手順は、次のとおりです。

詳細は、「ファイル・システム・ディレクトリ、Webサーバー構成およびレジストリ詳細のバックアップ」を参照してください。

8.5.1 パスワード・ファイルの読取り権限の変更

「シンプル」または「証明書」モードでアイデンティティ・システムを実行する場合、IdentityServer_install_dir\identity\oblix\configディレクトリ内のpassword.xmlファイルは読取りできません。この問題は、install_dir\access\oblix\configにあるアクセス・システムのpassword.lstファイルにもあてはまります。

パスワード・ファイルをアップグレード用に準備する手順

  1. アイデンティティ・システムのアップグレードの場合、アップグレード・プロセスの間だけ有効なpassword.xmlの読取り権限を割り当てます。「必要な管理権限でのログイン」も参照してください。

  2. アップグレードの完了後、password.xmlは元の権限にリセットします。

  3. アクセス・システムのアップグレードの場合は、password.lstファイルに対してこれらの手順を同様に実行します。

8.5.2 空きディスク領域の確認

以前のOracle Access Managerリリース用の旧コンポーネントをホストしているコンピュータには、その旧コンポーネントを新しいリリースでも保持するための十分なディスク領域が必要です。

十分なディスク領域があるかどうかを確認する手順

  1. 『Oracle Access Managerインストレーション・ガイド』を参照して、新規コンポーネントに必要なディスク領域を確認します。

  2. アップグレード前のコンポーネントをホストしているコンピュータ上で、以前のインストールをタイムスタンプ付きのソース・ディレクトリとして名前変更して保持するために必要なディスク領域量を確認します。

8.6 リリース6.x環境での準備

特定のOracle Access Manager 6.xインストール(6.5.1を除く)のアップグレードを成功させるには、元のComponent_install_dirに、標準の10g(10.1.4.0.1)インストール・パッケージに加えて特定のバンドルを追加する必要があります。この項では、特定のリリースからのアップグレードの開始時にのみ必要となる追加ファイルについて説明します。


警告:

各インストールに関連するファイルだけを使用してください。また、「マルチ言語インストールの準備」も参照してください。


8.6.1 リリース6.5.0.x用のパッケージの追加

10g(10.1.4.0.1)へのアップグレード時には、各コンポーネントのインストーラにより、origという名前のディレクトリが作成され、必要なファイルがアップグレードされるよう環境が比較されます。元のOracle Access Manager 6.5.0リリースにはアップグレード機能がないため、origという名前のファイルは作成されていません。

このため、Oracle Access Manager 6.5.0.xからアップグレードする前に、次のパッケージを抽出して元のComponent_install_dirに追加する必要があります。

元のComponent_install_dirに抽出する65-origパッケージ
Netpoint_65_orig_en_COREid_Server_msg.zip
Netpoint_65_orig_COREid_Server_param.zip
Netpoint_65_orig_en_Access_Manager_msg.zip
Netpoint_65_orig_Access_Manager_param.zip
Netpoint_65_orig_en_WebPass_msg.zip
Netpoint_65_orig_WebPass_param.zip
Netpoint_65_orig_en_Access_Server_msg.zip
Netpoint_65_orig_Access_Server_param.zip
Netpoint_65_orig_en_WebGate_msg.zip
Netpoint_65_orig_WebGate_param.zip
Netpoint_65_orig_en_AccessServerSdk_msg.zip

65_origパッケージを取得する手順

  1. 前述のリストにある65_origパッケージをOracle MetaLinkから次のように取得します。

    1. ブラウザに次のURLを入力します。

      https://metalink.oracle.com

    2. 通常どおりMetaLinkにログインします。

    3. 「Quick Find」リストから、「Patch Number」を選択します。

    4. 「Quick Find Patch Number」の近くのフィールドに5724938と入力して、「Go」ボタンをクリックします。

      検索結果が「UNABLE TO LOCATE MIGRATION BUNDLE FOR 6.5-10.1.4 UPGRADE」という説明とともに表示されます。


      注意:

      プラットフォームは自動的にMicrosoft Windows 2000に指定されます。これは、バンドルにすべてのプラットフォームで使用可能なテキスト・ファイルのみが含まれる(バイナリ・ファイルはなし)ためです。

    5. 「Download」ボタンをクリックして画面上の手順に従い、ステップ2に進みます。

  2. コンポーネントごとにファイルを元のインストール・ディレクトリに抽出(untar)します。

    これにより、コンポーネントごとにorigという名前の新規ディレクトリが作成されます。具体的には、Component_install_dir/identity/oblix/orig(またはComponent_install_dir/access/oblix/orig)などとなります。

  3. この章の説明に従って環境の準備を終了します。

8.6.2 リリース6.5.2.xパッチ・バージョン用のパッケージの追加

アップグレード時には、10g(10.1.4.0.1)コンポーネントのインストーラにより、origという名前のディレクトリが作成され、必要なファイルがアップグレードされるよう環境が比較されます。最初にリリース6.5.0.xをインストールした後にパッチを適用して6.5.2.xとした場合、アップグレードの前に、次のパッケージを抽出して元のComponent_install_dirに追加する必要があります。

元のComponent_install_dirに抽出する652_origパッケージ
Netpoint_652_orig_en_COREid_Server_msg.zip
Netpoint_652_orig_COREid_Server_param.zip
Netpoint_652_orig_en_WebPass_msg.zip
Netpoint_652_orig_WebPass_param.zip
Netpoint_652_orig_en_Access_Manager_msg.zip
Netpoint_652_orig_Access_Manager_param.zip
Netpoint_652_orig_en_Access_Server_msg.zip
Netpoint_652_orig_Access_Server_param.zip
Netpoint_652_orig_en_WebGate_msg.zip
Netpoint_652_orig_WebGate_param.zip
Netpoint_652_orig_AccessServerSdk_param.zip
Netpoint_652_orig_en_AccessServerSdk_msg.zip


注意:

次の手順を実行するのは、6.5.2パッチが6.5.0インストールに適用されている場合のみです。パッチなしで6.5.2インストールがインストールされている場合、この手順は無視してください。

6.5.2パッケージを取得する手順

  1. 前述のリストにある652パッケージをOracle MetaLinkから次のように取得します。

    1. ブラウザに次のURLを入力します。

      https://metalink.oracle.com

    2. 通常どおりMetaLinkにログインします。

    3. 「Quick Find」リストから、「Patch Number」を選択します。

    4. 「Quick Find Patch Number」の近くのフィールドに5724938と入力して、「Go」ボタンをクリックします。

      検索結果が「UNABLE TO LOCATE MIGRATION BUNDLE FOR 6.5-10.1.4 UPGRADE」という説明とともに表示されます。


      注意:

      プラットフォームは自動的にMicrosoft Windows 2000に指定されます。これは、バンドルにすべてのプラットフォームで使用可能なテキスト・ファイルのみが含まれる(バイナリ・ファイルはなし)ためです。

    5. 「Download」ボタンをクリックして画面上の手順に従い、ステップ2に進みます。

  2. コンポーネントごとにこれらのファイルを元のインストール・ディレクトリに抽出(untar)します。

    これにより、コンポーネントごとにorigという名前の新規ディレクトリが作成されます。具体的には、Component_install_dir/identity/oblix/orig(またはComponent_install_dir/access/oblix/orig)などとなります。

  3. インストールに複数の言語が含まれる場合、「マルチ言語インストールの準備」を参照してください。

  4. この章の説明に従って環境の準備を終了し、アップグレードを開始します。

8.7 マルチ言語インストールの準備

各10g(10.1.4.0.1)言語パックを含めずにマルチ言語インストールをアップグレードすると、マルチ言語機能が失われます。10g(10.1.4.0.1)インストーラと同じディレクトリに10g(10.1.4.0.1)言語パックをインストールすると、マルチ言語機能を保持できます。新しい言語は、『Oracle Access Managerインストレーション・ガイド』の手順に従ってアップグレード後に追加できます。

アップグレード後にマルチ言語機能を追加する手順


注意:

英語はデフォルト言語であるため、英語用(en-us)の個別言語パックはありません。10g(10.1.4.2.0)言語パックはありません。

既存のマルチ言語機能を保持する手順

  1. 以前にインストールされた言語に対応する10g(10.1.4.0.1)言語パックを探し、10g(10.1.4.0.1)コンポーネント・インストーラと同じディレクトリに追加します。

  2. 選択したメソッドに関するこのマニュアルの説明に従い、以前のインストールをアップグレードします。

8.8 ファイル・システム・ディレクトリ、Webサーバー構成およびレジストリ詳細のバックアップ

問題が発生した場合に元のインストールにロールバックできるよう、アップグレードを開始する前に次の各項目のアクティビティを実行しておくことをお薦めします。

8.8.1 既存のコンポーネント・インストール・ディレクトリのバックアップ

各コンポーネント(またはカスタマイズ)のアップグレードを開始する前に、以前のインスタンスのインストール・ディレクトリをバックアップし、このバックアップを別の場所に保管しておくことをお薦めします。これにより、後で環境をリストアしてアップグレードを再実行する必要が生じたときに、元のディレクトリを取り出すことができます。


注意:

停止時間ゼロのアップグレード・メソッドを使用する場合、ソースを作成します。ソースは、アップグレード時にも変更されないバックアップ・ディレクトリになります。停止時間ゼロのアップグレードの場合、インストール・ディレクトリのバックアップ・コピーを作成する必要はありません。このメソッドの詳細は、第VI部を参照してください。

インプレース・メソッド: 前述のように、インプレース・アップグレードを使用して各コンポーネントをアップグレードすると、元のファイル用のタイムスタンプ付きディレクトリが作成されます。システムによって生成されるこのディレクトリには、以前の元のファイルが含まれます。これらのファイルは、内容を比較したりカスタマイズされた情報を抽出するために、アクセスされる場合があります。タイムスタンプ付きのディレクトリは、アップグレードした10g(10.1.4.0.1)ディレクトリと同じ場所に格納されます。次に例を示します。

C:\611\identity_server\identity

C:\611\identity_server\identity_20060714_1701

既存のインストール・ディレクトリをバックアップする手順

  1. アップグレード対象のコンポーネントをホストしているコンピュータ上で、現在のインストール・ディレクトリを特定します。 次に例を示します。

    C:\611\identity_server\identity

  2. このディレクトリをコピーし、新しい場所に格納します。次に例を示します。

    D:\611_backup\identity_server\identity

8.8.2 既存のWebサーバー構成ファイルのバックアップ

Webサーバー・コンポーネント(WebPass、ポリシー・マネージャ、WebGate)のアップグレードを開始する前に、既存のWebサーバー構成ファイルをバックアップし、このバックアップを別の場所に保管しておくことをお薦めします。

バックアップするファイルは、Webサーバーのタイプによって異なります。次に例を示します。

  • NetscapeまたはSun One Web Serverの場合: obj.confファイルおよびmagnus.confファイルをバックアップします。

  • ApacheベースのすべてのWebサーバー(Apache v1およびv2のWebサーバー、Apache搭載のIBM HTTP Server(IHS)、Oracle HTTP Server(OHS)など)の場合: httpd.confをバックアップします。

  • Internet Information Services(IIS)Webサーバーの場合: 次の手順に従って、Microsoftの構成バックアップ/リストア機能を使用します。

  • Domino Webサーバーの場合: Webサーバーのグラフィカル・ユーザー・インタフェース(GUI)を使用して、Webサーバー構成の各ページの画面ショットを取得することをお薦めします。以前の構成をリストアまたはロールバックする必要がある場合、必要に応じてこの画面を参照してDomino Webサーバーを再構成できます。Dominoでは、バックアップ可能な構成ファイルは保持されません。

既存のWebサーバー構成ファイルをバックアップする手順

  1. アップグレード対象のWebコンポーネントをホストしているコンピュータ上で、既存のWebサーバー構成ファイルを探します。次に例を示します。

    C:/IHS_install_dir/conf/httpd.conf

  2. Webサーバー構成ファイルをコピーし、新しい場所に格納します。次に例を示します。

    D:/IHS_install_dir/conf/httpd.conf

  3. IIS 5の場合: 次のステップを実行します。

    1. Internet Information Services(IIS)ManagerのMMCスナップインでコンピュータ名を右クリックします。

    2. 「構成のバックアップまたは復元」をクリックします。

    3. 「バックアップの作成」ボタンをクリックします。

  4. IIS 6の場合: 次のステップを実行します。

    1. Internet Information Services(IIS)ManagerのMMCスナップインでコンピュータ名を右クリックします。

    2. 「すべてのタスク」→「構成のバックアップまたは復元」をクリックします。

    3. 「バックアップの作成」ボタンをクリックします。

  5. Domino Webサーバーの場合: GUIと以前の構成の画面ショットを使用してWebサーバーを再構成します。

8.8.3 Windowsレジストリ・データのバックアップ

Microsoft Windowsシステム上で各コンポーネントのアップグレードを開始する前に、Oracle Access Manager(以前のNetPointまたはCOREid)データが含まれるレジストリ・データをバックアップすることをお薦めします。

Windowsレジストリ・データをバックアップする手順

  1. regeditコマンドを実行します。

  2. マイ コンピュータ\HKEY_LOCAL_MACHINE\SOFTWARE\Oblix\Oblix NetPointキーを選択します。

  3. メニューで「レジストリ」を選択し、ドロップダウン・メニューで「レジストリ ファイルの書き出し…」を選択します。

  4. 「レジストリ ファイルの書き出し」ダイアログで、書き出すファイルの名前を指定します。

  5. 書き出したレジストリ・ファイルを既知の場所に保存します。

これも、障害発生時に以前のインストール環境にロールバックし、アップグレードを再実行する上で役立ちます。詳細は、Windowsのドキュメントを参照してください。

8.9 サーバーおよびサービスの停止

10g(10.1.4.0.1)へのアップグレードを開始する前に、アップグレード対象のコンポーネントをホストしているコンピュータ上で以前のサーバーまたはサービスを停止する必要があります。

たとえば、WebPassを使用している場合は、WebPassがインストールされているWebサーバーを停止する必要があります。アイデンティティ・サーバーの場合は、アイデンティティ・サーバー・サービスを停止する必要があります。アイデンティティ・サーバーでは、次のコマンドを使用してすべてのアイデンティティ・サーバー・プロセスがSolarisコンピュータ上で停止しているかどうかを確認できます。

     ps -ef | grep IdentityServer_install_dir

アクセス・サーバーの場合、10g(10.1.4.0.1)アクセス・サーバーへのアップグレード前にすべてのアクセス・サーバー・プロセスが完全に停止しているかどうかを確認します。すべてのアクセス・サーバー・プロセスがSolarisコンピュータで停止していることを確認するには、次のコマンドを使用します。

     ps -ef | grep AccessServer_install_dir

実行中のアクセス・サーバー・プロセスは、kill -9コマンドを使用して終了できます。

IISユーザーの場合: IIS Admin Serviceを停止します。

アップグレード前にサーバーまたはサービスを停止する手順

  1. アップグレード対象のコンポーネントをホストしているコンピュータを特定します。

  2. Webサーバー(WebPass、ポリシー・マネージャおよびWebGateの場合)またはサービス(アイデンティティ・サーバーまたはアクセス・サーバーの場合)を停止します。

  3. 統合コンポーネントをアップグレードする場合、対応するアプリケーション・サーバーまたはポータル・サーバーを停止します。たとえば、WebLogic SSPのセキュリティ・プロバイダをアップグレードする場合、対応するWebLogic Application Serverを停止する必要があります。

8.10 必要な管理権限でのログイン

Oracle Access Managerコンポーネントをアップグレードまたはインストールする場合は、管理権限を持つユーザーとしてログインする必要があります。Solarisでは、Oracle Access Managerの以前のリリースをインストールしたユーザーか、より上位の権限を持つユーザーとしてアップグレードを実行する必要があります。

アップグレード・プロセスにスキーマおよびデータのアップグレードが含まれる場合は常に、ディレクトリ・サーバーでスキーマおよびデータを変更する権限を持つユーザーとしてログインする必要があります。つまり、使用するバインドDNには、ディレクトリを更新する権限があることが必要です。

アップグレード時にログインする手順

  1. アップグレードに必要な権限だけでなく、アップグレード中に行うスキーマおよびデータの変更に必要な権限も持つユーザーIDとパスワードを使用してください。

  2. アップグレード対象のコンポーネントをホストしているコンピュータ上で、管理権限を持つユーザーとしてログインします。