この章では、残りのアイデンティティ・システムおよびアクセス・システムのコンポーネントのアップグレードを開始する前に、既存の環境を整えておく際に必要となる情報について説明します。各自の計画ドキュメントを参照し、付録Fの概要を使用して進捗状況を追跡してください。
特に明記されていない場合、使用するアップグレード・メソッドを問わず、これらのアクティビティを実行します。停止時間ゼロのアップグレードの詳細は、第VI部を参照してください。これらのタスクは、アップグレードの際にプラットフォームをSolarisからLinuxに切り替える場合(付録Bを参照)も実行します。内容は次のとおりです。
注意: この章では、以前の製品やコンポーネントを指している場合でも、新しい製品名およびコンポーネント名を使用しています。たとえば、Oblix NetPointやOracle COREidのかわりにOracle Access Managerが使用されています。詳細は、「Oracle Access Managerの新機能」を参照してください。 |
以前のインストールと10g(10.1.4.0.1)間の互換性を確保するために必要な作業がいくつかあります。第2章で説明しているように、一部の項目はサポートされなくなっています。サポートの変更を受けて対処方法の決定が必要となる場合もあります。
「終了したサポート」を確認します。
次の説明に従って、10g(10.1.4.0.1)のプラットフォームのサポートを確認します。
https://metalink.oracle.com
のMetaLinkにアクセスします。
指示に従ってMetaLinkにログインします。
「Certify」タブをクリックします。
「View Certifications by Product」をクリックします。
「Application Server」オプションを選択し、「Submit」をクリックします。
「Oracle Identity Manager」を選択し、「Submit」をクリックします。
「Oracle Identity Management Certification Information 10g (10.1.4.0.1)」(html)をクリックして「Oracle Identity Management」ページを表示します。
「Section 6, "Oracle Access Manager Certification"」のリンクをクリックして、証明書マトリクスを表示します。
ディレクトリ・サーバーまたはWebサーバーのバージョンまたはプラットフォームのサポートが変更されている場合の作業方法は、「サポートが変更または終了した場合のアップグレード計画」を参照してください。
アップグレード時には、すべての標準プラグインと同様に、カスタムの認証および認可プラグインもコピーされます。ただし、アイデンティティ・イベント・プラグインAPIを使用して作成されたカスタム・アイデンティティ・イベント・プラグインは、アップグレード時にコピーされません。
アップグレードの前に独立した小規模な環境(または停止時間ゼロのクローン環境)で次の手順を実行し、カスタム・アイデンティティ・イベント・プラグインを設計変更に備えて準備することをお薦めします。
アイデンティティ・イベント・プラグインをアップグレード前にコピーする手順
アップグレード前に、アイデンティティ・イベントAPIディレクトリの最上位に、古いアイデンティティ・イベント・プラグイン用のディレクトリを作成します。
カスタム・アイデンティティ・イベント・プラグインを新規ディレクトリにコピーします。
次の「以前のカスタマイズの準備」に進みます。
既存環境のカスタマイズの手動処理は、コンポーネントのアップグレードの前に余裕を持って開始することをお薦めします。この処理は、サービスの中断を最小限に抑えるためにテストまたは開発環境で行います。カスタマイズのアップグレードおよびテストが完了した後、「カスタマイズのアップグレード計画」の説明に従って、アップグレード後の環境にカスタマイズをデプロイできます。
注意: 停止時間ゼロのアップグレード・メソッドを使用している場合、カスタマイズのアップグレードを早期に実行して、アップグレードしたクローン環境内で十分にテストすることをお薦めします。詳細は、「停止時間ゼロのアップグレード・メソッドを使用したカスタマイズのアップグレード」を参照してください。 |
多くのカスタマイズは、使用するアップグレード・メソッドを問わず、コンポーネントのアップグレードの前に作業を開始できます。ただし、コンポーネントのアップグレード後でないと実行できないカスタマイズのアップグレードもいくつかあります。
アイデンティティ・システム: 次のタスクの概要に、実行する必要があるアイデンティティ・システムのカスタマイズ作業と、第12章にある詳細の参照先をリストします。
タスクの概要: 以前のアイデンティティ・システムのカスタマイズのアップグレード
アイデンティティ・システムとアクセス・システムの混合: 前述のタスクの概要で示したアイデンティティ・システムの作業の他に、以前のアクセス・システムのカスタマイズもアップグレードする必要があります。次の概要では、手動で実行する必要があるアクセス・システムのカスタマイズのアップグレードを示します。詳細は、第13章を参照してください。
タスクの概要: 以前のアクセス・システムのカスタマイズのアップグレード
詳細は、「アップグレードと下位互換性の概要」を参照してください。
アップグレードの前に、ポリシー・マネージャでデフォルトのログアウトを非保護にする必要があります。非保護にしない場合は、アップグレード後に、ユーザーが、「ログアウト」リンクをクリックしたときに情報の入力を求められます。
ポリシー・マネージャでデフォルトのログアウトを非保護にします。
WebGateのログアウト用にoblogout.cgiを使用する場合は、必ずターゲット・サーバーにインストールします。
以前のインストールをホストするコンピュータに対する準備の手順は、次のとおりです。
詳細は、「ファイル・システム・ディレクトリ、Webサーバー構成およびレジストリ詳細のバックアップ」を参照してください。
「シンプル」または「証明書」モードでアイデンティティ・システムを実行する場合、IdentityServer_install_dir\identity\oblix\configディレクトリ内のpassword.xmlファイルは読取りできません。この問題は、install_dir\access\oblix\configにあるアクセス・システムのpassword.lstファイルにもあてはまります。
アイデンティティ・システムのアップグレードの場合、アップグレード・プロセスの間だけ有効なpassword.xmlの読取り権限を割り当てます。「必要な管理権限でのログイン」も参照してください。
アップグレードの完了後、password.xmlは元の権限にリセットします。
アクセス・システムのアップグレードの場合は、password.lstファイルに対してこれらの手順を同様に実行します。
特定のOracle Access Manager 6.xインストール(6.5.1を除く)のアップグレードを成功させるには、元のComponent_install_dirに、標準の10g(10.1.4.0.1)インストール・パッケージに加えて特定のバンドルを追加する必要があります。この項では、特定のリリースからのアップグレードの開始時にのみ必要となる追加ファイルについて説明します。
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パッケージをOracle MetaLinkから次のように取得します。
ブラウザに次のURLを入力します。
通常どおりMetaLinkにログインします。
「Quick Find」リストから、「Patch Number」を選択します。
「Quick Find Patch Number」の近くのフィールドに5724938
と入力して、「Go」ボタンをクリックします。
検索結果が「UNABLE TO LOCATE MIGRATION BUNDLE FOR 6.5-10.1.4 UPGRADE」という説明とともに表示されます。
注意: プラットフォームは自動的にMicrosoft Windows 2000に指定されます。これは、バンドルにすべてのプラットフォームで使用可能なテキスト・ファイルのみが含まれる(バイナリ・ファイルはなし)ためです。 |
「Download」ボタンをクリックして画面上の手順に従い、ステップ2に進みます。
コンポーネントごとにファイルを元のインストール・ディレクトリに抽出(untar)します。
これにより、コンポーネントごとにorigという名前の新規ディレクトリが作成されます。具体的には、Component_install_dir/identity/oblix/orig(またはComponent_install_dir/access/oblix/orig)などとなります。
この章の説明に従って環境の準備を終了します。
インストールにリリース6.5.2.xのパッチ・セットが含まれる場合、「リリース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インストールがインストールされている場合、この手順は無視してください。 |
前述のリストにある652パッケージをOracle MetaLinkから次のように取得します。
ブラウザに次のURLを入力します。
通常どおりMetaLinkにログインします。
「Quick Find」リストから、「Patch Number」を選択します。
「Quick Find Patch Number」の近くのフィールドに5724938
と入力して、「Go」ボタンをクリックします。
検索結果が「UNABLE TO LOCATE MIGRATION BUNDLE FOR 6.5-10.1.4 UPGRADE」という説明とともに表示されます。
注意: プラットフォームは自動的にMicrosoft Windows 2000に指定されます。これは、バンドルにすべてのプラットフォームで使用可能なテキスト・ファイルのみが含まれる(バイナリ・ファイルはなし)ためです。 |
「Download」ボタンをクリックして画面上の手順に従い、ステップ2に進みます。
コンポーネントごとにこれらのファイルを元のインストール・ディレクトリに抽出(untar)します。
これにより、コンポーネントごとにorigという名前の新規ディレクトリが作成されます。具体的には、Component_install_dir/identity/oblix/orig(またはComponent_install_dir/access/oblix/orig)などとなります。
インストールに複数の言語が含まれる場合、「マルチ言語インストールの準備」を参照してください。
この章の説明に従って環境の準備を終了し、アップグレードを開始します。
各10g(10.1.4.0.1)言語パックを含めずにマルチ言語インストールをアップグレードすると、マルチ言語機能が失われます。10g(10.1.4.0.1)インストーラと同じディレクトリに10g(10.1.4.0.1)言語パックをインストールすると、マルチ言語機能を保持できます。新しい言語は、『Oracle Access Managerインストレーション・ガイド』の手順に従ってアップグレード後に追加できます。
アップグレード後にマルチ言語機能を追加する手順
インプレース・メソッド: 10g(10.1.4.0.1)へのインプレース・アップグレード後に10g(10.1.4.0.1)言語パックを個別にインストールできます。
停止時間ゼロのメソッド: 10g(10.1.4.0.1)のアップグレード先を作成した後、リリース10.1.4パッチ・セット1(10.1.4.2.0)を所定の場所に適用する前に、10g(10.1.4.0.1)言語パックを個別にインストールできます。
注意: 英語はデフォルト言語であるため、英語用(en-us)の個別言語パックはありません。10g(10.1.4.2.0)言語パックはありません。 |
以前にインストールされた言語に対応する10g(10.1.4.0.1)言語パックを探し、10g(10.1.4.0.1)コンポーネント・インストーラと同じディレクトリに追加します。
選択したメソッドに関するこのマニュアルの説明に従い、以前のインストールをアップグレードします。
問題が発生した場合に元のインストールにロールバックできるよう、アップグレードを開始する前に次の各項目のアクティビティを実行しておくことをお薦めします。
各コンポーネント(またはカスタマイズ)のアップグレードを開始する前に、以前のインスタンスのインストール・ディレクトリをバックアップし、このバックアップを別の場所に保管しておくことをお薦めします。これにより、後で環境をリストアしてアップグレードを再実行する必要が生じたときに、元のディレクトリを取り出すことができます。
注意: 停止時間ゼロのアップグレード・メソッドを使用する場合、ソースを作成します。ソースは、アップグレード時にも変更されないバックアップ・ディレクトリになります。停止時間ゼロのアップグレードの場合、インストール・ディレクトリのバックアップ・コピーを作成する必要はありません。このメソッドの詳細は、第VI部を参照してください。 |
インプレース・メソッド: 前述のように、インプレース・アップグレードを使用して各コンポーネントをアップグレードすると、元のファイル用のタイムスタンプ付きディレクトリが作成されます。システムによって生成されるこのディレクトリには、以前の元のファイルが含まれます。これらのファイルは、内容を比較したりカスタマイズされた情報を抽出するために、アクセスされる場合があります。タイムスタンプ付きのディレクトリは、アップグレードした10g(10.1.4.0.1)ディレクトリと同じ場所に格納されます。次に例を示します。
C:\611\identity_server\identity
C:\611\identity_server\identity_20060714_1701
アップグレード対象のコンポーネントをホストしているコンピュータ上で、現在のインストール・ディレクトリを特定します。 次に例を示します。
C:\611\identity_server\identity
このディレクトリをコピーし、新しい場所に格納します。次に例を示します。
D:\611_backup\identity_server\identity
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コンポーネントをホストしているコンピュータ上で、既存のWebサーバー構成ファイルを探します。次に例を示します。
C:/IHS_install_dir/conf/httpd.conf
Webサーバー構成ファイルをコピーし、新しい場所に格納します。次に例を示します。
D:/IHS_install_dir/conf/httpd.conf
IIS 5の場合: 次のステップを実行します。
Internet Information Services(IIS)ManagerのMMCスナップインでコンピュータ名を右クリックします。
「構成のバックアップまたは復元」をクリックします。
「バックアップの作成」ボタンをクリックします。
IIS 6の場合: 次のステップを実行します。
Internet Information Services(IIS)ManagerのMMCスナップインでコンピュータ名を右クリックします。
「すべてのタスク」→「構成のバックアップまたは復元」をクリックします。
「バックアップの作成」ボタンをクリックします。
Domino Webサーバーの場合: GUIと以前の構成の画面ショットを使用してWebサーバーを再構成します。
Microsoft Windowsシステム上で各コンポーネントのアップグレードを開始する前に、Oracle Access Manager(以前のNetPointまたはCOREid)データが含まれるレジストリ・データをバックアップすることをお薦めします。
regeditコマンドを実行します。
マイ コンピュータ\HKEY_LOCAL_MACHINE\SOFTWARE\Oblix\Oblix NetPointキーを選択します。
メニューで「レジストリ」を選択し、ドロップダウン・メニューで「レジストリ ファイルの書き出し…」を選択します。
「レジストリ ファイルの書き出し」ダイアログで、書き出すファイルの名前を指定します。
書き出したレジストリ・ファイルを既知の場所に保存します。
これも、障害発生時に以前のインストール環境にロールバックし、アップグレードを再実行する上で役立ちます。詳細は、Windowsのドキュメントを参照してください。
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を停止します。
アップグレード対象のコンポーネントをホストしているコンピュータを特定します。
Webサーバー(WebPass、ポリシー・マネージャおよびWebGateの場合)またはサービス(アイデンティティ・サーバーまたはアクセス・サーバーの場合)を停止します。
統合コンポーネントをアップグレードする場合、対応するアプリケーション・サーバーまたはポータル・サーバーを停止します。たとえば、WebLogic SSPのセキュリティ・プロバイダをアップグレードする場合、対応するWebLogic Application Serverを停止する必要があります。
Oracle Access Managerコンポーネントをアップグレードまたはインストールする場合は、管理権限を持つユーザーとしてログインする必要があります。Solarisでは、Oracle Access Managerの以前のリリースをインストールしたユーザーか、より上位の権限を持つユーザーとしてアップグレードを実行する必要があります。
アップグレード・プロセスにスキーマおよびデータのアップグレードが含まれる場合は常に、ディレクトリ・サーバーでスキーマおよびデータを変更する権限を持つユーザーとしてログインする必要があります。つまり、使用するバインドDNには、ディレクトリを更新する権限があることが必要です。
アップグレードに必要な権限だけでなく、アップグレード中に行うスキーマおよびデータの変更に必要な権限も持つユーザーIDとパスワードを使用してください。
アップグレード対象のコンポーネントをホストしているコンピュータ上で、管理権限を持つユーザーとしてログインします。