| Oracle Access Managerアップグレード・ガイド 10g（10.1.4.2.0） E05837-01 |
|
 戻る |
 次へ |
インストールにアイデンティティ・システムのみが含まれる場合、アクセス・システムの統合コネクタのアップグレードをスキップし、個別にインストールされたSDKをアップグレードできます。ただし、以前のインストールに特定のサード・パーティ製品用のアクセス・システムおよびOracle Access Managerの統合コネクタが含まれる場合、SDKをアップグレードする前に統合コネクタをアップグレードする必要があります。
特に明記されていない場合、この章に記載されている情報はどちらのアップグレード・メソッドにも同様に適用されます。内容は次のとおりです。
|
注意: 統合コンポーネントまたは個別にインストールされたSDKをアップグレードする前に、アクセス・システムをアップグレードする必要があります。停止時間ゼロのメソッドを使用している場合は、第VI部も参照してください。 |
使用している環境に次のものが統合されている場合、ここで説明する手順を実行し、10g（10.1.4.0.1）との互換性を確保する必要があります。
WebLogic SSPI用セキュリティ・プロバイダ
WebSphere用Oracle Access Managerコネクタ
このタスクは、その他のアップグレードの場合と同じです。この章で示す例では、WebLogic SSPI用Oracle Access Managerセキュリティ・プロバイダのアップグレード方法について説明します。その他の統合コネクタの場合も、手順は同じです。
リリース10g（10.1.4.0.1）の統合の構成に関する最新情報は、『Oracle Access Manager統合ガイド』を参照してください。
ここで説明するサンプルのアップグレードは、Oracle Access Manager 6.1.1インストールから開始する場合です。開始リリースは同じでなくてもかまいません。
表11-1の前提条件が満たされていないと、アップグレードに悪影響が生じる場合があります。
| 統合のアップグレードの前提条件 |
|---|
|
第II部の説明に従って、スキーマおよびデータが正常にアップグレードされている。 |
|
第III部の説明に従って、コンポーネントが正常にアップグレードされている。 |
|
第8章の説明に従って、コンポーネントの準備に必要なステップがすべて実行されている。
|
|
WebSphere: WebSphere用Oracle Access Managerコネクタをアップグレードする場合、次を確認する。
|
|
Weblogic: 現在のコネクタのインストール・ディレクトリ内のNetPointProvidersConfig.propertiesファイルがWeblogicサーバーのドメイン・ディレクトリ内のファイルと同期化されていることを確認する。 |
|
対応するアプリケーション/ポータル・サーバーを停止します。たとえば、WebLogic SSPI用セキュリティ・プロバイダをアップグレードする場合、対応するWebLogic Application Serverを停止する必要があります。 |
これは、その他のコンポーネントのアップグレードと同じです。エラーが発生した場合、エラーに関する情報が含まれるログ・ファイルの名前が特定されます。実行するインストールに該当しない詳細はスキップしてください。
この手順で示すサンプルのアップグレードは、WebLogic SSPI用Oracleセキュリティ・プロバイダに統合されているインストールから開始します。これらは環境によって異なります。
「統合のアップグレードの前提条件」で説明されているように、このインスタンスの前提条件が満たされていることを確認します。
対応するアプリケーション/ポータル・サーバーを停止します。たとえば、WebLogic SSPI用セキュリティ・プロバイダをアップグレードする場合、対応するWebLogic Application Serverを停止する必要があります。
管理者権限を持つユーザーとしてログインします。
選択したメソッドで10g（10.1.4.0.1）インストーラを特定し起動します。
「次へ」をクリックして、「ようこそ」画面を閉じます。次に、プラットフォームに基づいて管理者権限に関する質問に回答します。
以前の統合コンポーネントをインストールしたディレクトリを選択し、指示に従って続行するようクリックします。
「はい」をクリックしてアップグレードに同意し、「次へ」をクリックします。
前述の説明に従って言語に関する質問に回答し、「次へ」をクリックします。
このフェーズが完了したことがステータス画面で示された後、「次へ」をクリックします。
この手順は、その他のコンポーネントのアップグレードの場合と同じです。ただし、WebLogic SSPI用セキュリティ・プロバイダに固有の手順がいくつかあります。
WebLogic SSPI用セキュリティ・プロバイダをアップグレードする手順
自動モードまたは確認モードのアップグレード・モードを選択します。
画面上のプロンプトに従います。
GUIが終了し、コマンドライン・ウィンドウにアップグレードの進捗状況を示すメッセージが表示されます。
------------------------------------- Starting migration (6.1.1 -> 6.5.0) ---------------------------------------------------- Updating component-specific configuration files ... OK. ---------------------------------------------------- Starting migration (6.5.0 -> 7.0.0) ---------------------------------------------------- Updating component-specific configuration files ... OK. ---------------------------------------------------- Starting migration (7.0.0 -> 10.1.4) ---------------------------------------------------- Updating component-specific configuration files ... OK. ---------------------------------------------------- Migration has completed successfully! Press <ENTER> to continue :
Software Developer Kit（SDK）をアップグレードします。アップグレードしない場合、現在のSDK構成設定は保持されません。このため、『Oracle Access Managerアクセス管理ガイド』の説明に従って、configureAccessGateツールを使用してSDKを後で再構成する必要があります。
WebLogic SSPI用セキュリティ・プロバイダをアップグレードする場合、次の手順を実行します。
|
注意: WebSphere ApplicationおよびPortal Serverの統合コンポーネントをアップグレードする場合、NetPointCMR.jarファイルをPortal_install_dirに、NetPointWASRegistry.jarファイルおよびjobaccess.jarファイルをWAS_install_dirにコピーし、サーバーを再起動する必要があります。詳細は、『Oracle Access Manager統合ガイド』を参照してください。 |
次の場所から適切なmbean.jarファイルをコピーします。次に例を示します。
コピー元: SecurityProvider_install_dir/oblix/lib/mbeantypes
コピー先: WebLogic_Home/server/lib/mbeantypes
次のファイルをSecurityProvider_install_dirからWebLogicのドメイン・フォルダにコピーします。
NetPointProvidersConfig.properties
NetPointResourceMap.conf（アプリケーション・サーバーのドメイン用のみ）
アプリケーション/ポータル/Webサーバーを起動し、このアップグレードが成功したことを確認します。
サーバーが起動しない場合: すべてのタスクを実行して、すべての情報を正確に指定したかどうかを確認します。付録Gのトラブルシューティングのヒントを参照してください。
移行ログ・ファイルを表示して、エラーが含まれているかどうかを確認します。「ログ・ファイルへのアクセス」を参照してください。
アップグレードが成功した場合: このインスタンスに対して「アップグレードされた統合コネクタまたはSDKデータのバックアップ」のアクティビティを実行し、以前のポリシー・マネージャのアップグレードに進みます。
アップグレードが失敗した場合: 「統合コネクタまたはSDKのアップグレードの失敗からのリカバリ」に進みます。
すべての統合コネクタのアップグレード後、次の「個別にインストールされたSoftware Developer Kitのアップグレード」に進みます。
SDK（以前のアクセス・サーバーSDK）は現在、10g（10.1.4.0.1）ではAccess Manager SDKと呼ばれています。
ここで説明するように、個別にインストールされた任意のSDKをアップグレードする必要があります。SDKにバンドルされているコンポーネント（WebSphere SSPI用のアイデンティティ・サーバーおよびOracle Access Managerのセキュリティ・コネクタなど）をアップグレードする場合の最後のステップとして自動的に起動されるSDKのアップグレードは、個別にインストールされたSDKには影響しません。
タスクの概要: Software Developer Kitのアップグレード
Software Developer Kitのアップグレードを開始する前に、表11-2のタスクをチェックし、これらが実行されていることを確認します。前提条件が満たされていないと、アップグレードに悪影響が生じる場合があります。
| SDKのアップグレードの前提条件 |
|---|
|
第II部のアクティビティが完了している。 |
|
使用している環境に応じて、第III部のアクティビティが完了している。 |
|
統合コンポーネント: 使用している環境に応じて、「サード・パーティ製品の統合コネクタのアップグレード」の説明に従って、統合コンポーネントをアップグレードする。 |
|
このインスタンスおよびホストについて、第8章の必要なステップがすべて実行されている。
|
ここで説明するサンプルのアップグレードは、リリース6.1.1インストールから開始します。アップグレード元リリースや環境は同じでなくてもかまいません。エラーが発生した場合、エラーに関する情報が含まれるログ・ファイルの名前が特定されます。
実行するインストールに該当しない詳細はスキップしてください。
「SDKのアップグレードの前提条件」のアクティビティがすべて完了していることを確認します。
サーバーまたはサービスをオフにし、管理者権限を持つユーザーとしてログインします。
選択したメソッドでプログラムを特定し起動します。
「ようこそ」画面が表示されます。
「ようこそ」画面を閉じます。次に、プラットフォーム固有の管理者確認画面に応答します。
以前のSDKをインストールしたディレクトリを選択し、「次へ」をクリックします。
「はい」をクリックしてアップグレードに同意し、「次へ」をクリックします。
「英語」やインストールしたその他の言語の横にチェックマークが付いていることを確認し、「次へ」をクリックします。
「次へ」をクリックし、リストされている言語を確定します。
タイムスタンプの付いたディレクトリ名を記録し、次に進みます。
必要なディスク領域量を記録してから、ターゲット・ディレクトリへのファイルの抽出を開始します。
UNIX: 指定されたコマンドを実行し、[Enter]キーを押して次に進みます。
次の「SDK構成のアップグレードおよびアップグレードの検証」に進みます。
この手順では、ユーザーが入力する必要はほとんどありません。
自動モードか確認モードかを指定し、次に進みます。
次のように、アップグレードに関するステータス・メッセージがスクロールを始めます。
------------------------------------- Starting migration ( 6.1.1 -> 6.5.0 )... ------------------------------------- Copying general configuration files... OK. ------------------------------------- Updating message catalogs... OK. ------------------------------------- Updating parameter catalogs... OK. ------------------------------------- Updating component-specific configuration files... OK. --------------------------------------
10g（10.1.4.0.1）に到達するまでメッセージが続いた後、次のメッセージが表示されます。
------------------------------------- Migration has completed successfully! Press <ENTER> to continue :
指示に従ってアップグレードを終了してから、サーバー・サービスを再起動します。
サーバーまたはサービスが起動しない場合: すべてのタスクを実行して、すべての情報を正確に指定したかどうかを確認します。付録Gのトラブルシューティングのヒントを参照してください。
移行ログ・ファイルを表示して、エラーが含まれているかどうかを確認します。「ログ・ファイルへのアクセス」を参照してください。
アップグレードが成功した場合: 「アップグレードされた統合コネクタまたはSDKデータのバックアップ」のアクティビティを実行します。
アップグレードが失敗した場合: 「統合コネクタまたはSDKのアップグレードの失敗からのリカバリ」に進みます。
使用している環境内で個別にインストールされたSDKごとに作業を繰り返してから、「他の章の内容」を参照してください。
前述のように、10g（10.1.4.0.1）コンポーネント・ディレクトリが正常に動作していることを確認した後にこのディレクトリをバックアップして、各コンポーネントのアップグレードを終了することをお薦めします。これにより、アップグレード直後の環境にリストアする必要が生じたときに簡単にリストアできるようになります。
統合コネクタまたはSDKのアップグレード後の重要な情報をバックアップする手順
アップグレードされた10g（10.1.4.0.1）の統合コネクタまたはSDKディレクトリをバックアップし、新しい場所に保存します。
Webサーバー: 必要に応じて、ベンダーのドキュメントを参照し、アップグレードされたWebサーバーの構成ファイルをバックアップします。
必要に応じて、Windowsのレジストリ・データをバックアップします。
コンポーネントのアップグレードが失敗した場合、次の手順を実行してこのアップグレードをロールバックし、アップグレードしなおすことができます。
統合コネクタまたはSDKのアップグレードの失敗からリカバリする手順
このアップグレード前にバックアップした以前のディレクトリをリストア（以前の環境をリカバリ）してから、このディレクトリを再度バックアップします。以前のディレクトリの一方をバックアップ・コピーとして保存し、他方のディレクトリを使用してアップグレードを再開します。
Windows: バックアップされたコンポーネントのレジストリをリストア（以前の環境をリカバリ）します。
Webサーバー: このコンポーネントに必要な場合、以前のバックアップされたWebサーバーの構成ファイルをリストア（以前の環境をリカバリ）します。
以前の環境のバックアップ・コピーを使用して、この章の説明に従ってアップグレードを再開します。
アップグレードされたアイデンティティ・システムおよびアクセス・システムのコンポーネントでは、UTF-8エンコーディングで情報が送受信されます。以前のコンポーネントでは、Latin-1エンコーディングでデータが送受信されます。アップグレードを続けるには、以前のインストールに適した方法で作業を進めます。次に例を示します。
アイデンティティ・システムのみ: 以前のインストールにアクセス・システムが含まれない場合、次に記載された手順でアクティビティを実行します。
アイデンティティ・システムとアクセス・システムの混合: この場合、次に記載された手順に従ってアクティビティを行う必要があります。
予期されるシステム動作の詳細は、第4章を参照してください。
