ヘッダーをスキップ

Oracle Application Server アップグレードおよび互換性ガイド
10g(10.1.4.0.1)for Microsoft Windows

B31481-01
目次
目次
索引
索引

戻る 次へ

9 アップグレード後の手順(コンポーネント別)

この章では、アップグレード後の手順(コンポーネント別)について説明します。この手順により、Infrastructureの10g(10.1.4.0.1)へのアップグレードが完了します。 この章の内容は、次のとおりです。

9.1 タスク1: OracleAS Identity Managementコンポーネントに対するOracleAS SSLサポート(SSL)の有効化

SSLを使用するように構成された分散OracleAS Identity Managementコンポーネントをアップグレードしている場合は、アップグレード後にOracleAS Single Sign-OnおよびOracle Delegated Administration ServicesでSSLを再度有効にする必要があります。詳細は、次の項を参照してください。

9.1.1 アップグレード後のOracle Internet Directoryに対するSSLの有効化

Oracle Internet DirectoryでSSLを有効にする必要はありません。これは、ソースOracleホームのOracle Internet DirectoryでSSLを使用していた場合、アップグレード処理によって、アップグレード先OracleホームのOracle Internet DirectoryでSSLが自動的に再度有効にされるためです。

9.1.2 アップグレード後のOracleAS Single Sign-Onに対するSSLの有効化

OracleAS Single Sign-OnでSSLを有効にするには、『Oracle Application Server Single Sign-On管理者ガイド』の「SSLの有効化」に示す手順を使用します。

特に、『Oracle Application Server Single Sign-On管理者ガイド』のこの項で説明されている次の手順を実行する必要があります。

  1. シングル・サインオン中間層でSSLを有効にします。これには、SSLを有効化するための、opmn.xml構成ファイルの編集が含まれます。

  2. ssocfgユーティリティを実行し、シングル・サインオンURLを変更します。

  3. targets.xmlを更新し、SSL証明書を認識するように、Oracle Enterprise Manager Application Server Control を構成します。

    SSL構成処理におけるこの手順の詳細は、9.1.2.1項「Application Server ControlにおけるOracleAS Single Sign-OnおよびOracle Delegated Administration Servicesの監視の有効化」を参照してください。

  4. シングル・サインオンURLを保護します。

  5. Oracle HTTP Serverとシングル・サインオン中間層(OC4J_Security OC4Jインスタンス)を再起動します。

  6. 『Oracle Application Server Single Sign-On管理者ガイド』の仮想ホストでのmod_ossoの構成に関する項に従って、SSL仮想ホストにmod_ossoを登録します。

9.1.2.1 Application Server ControlにおけるOracleAS Single Sign-OnおよびOracle Delegated Administration Servicesの監視の有効化

この項では、Application Server Controlが、SSLを介してOracleAS Single Sign-OnおよびOracle Delegated Administration Servicesコンポーネントを監視できるようにする手順について説明します。

9.1.2.1.1 適切なプロトコルとURLを使用したtargets.xmlの更新

Application Server Control構成ファイル(targets.xml)を変更し、Application Server Controlが、必要なOracleAS Single Sign-OnおよびOracle Delegated Administration ServicesのURLに接続できるようにします。

  1. targets.xmlファイルを検索し、テキスト・エディタで開きます。

    このファイルは、アップグレード先Oracleホームにあります。

    DESTINATION_ORACLE_HOME¥sysman¥emd¥
    
    
  2. targets.xmlファイルで、次に示すOracle Delegated Administration Services要素を検索します。

    <Target TYPE="oracle_das_server" ... >
       ....
    </Target>
    
    
  3. oracle_das_server要素内で、表9-1に示すプロパティをそれぞれの推奨値で更新します。

    表9-1    targets.xml構成ファイルで変更するOracleAS Single Sign-OnおよびOracle Delegated Administration Servicesのプロパティ 
    プロパティ  説明および必須の値 

    HTTPProtocol 

    Oracle HTTP Serverによって使用されるプロパティ。 指定できる値は、HTTPまたはHTTPS(セキュアSSL接続用)です。 

    MonitorPort 

    ホストでのOracle Delegated Administration Servicesの監視に使用される物理ポート。 多くの場合、これはOracle HTTP Serverのデフォルトのポートです。 

    DasPort 

    ホストでのOracle Delegated Administration Servicesの監視に使用される物理ポート。 多くの場合、これはOracle HTTP Serverのデフォルトのポートです。 

    DasURL 

    Oracle Delegated Administration Servicesの完全なURL。これには、プロトコル、物理ホスト名およびポートを含めます。 高可用性環境では、ロード・バランサの仮想ホストおよびポートを使用しないでください。 

    DasMonitorURL 

    Oracle Delegated Administration Servicesを監視するためにApplication Server Controlによって使用される完全なURL。これには、プロトコル、物理ホスト名およびポートを含めます。 高可用性環境では、ロード・バランサの仮想ホストおよびポートを使用しないでください。 

  4. targets.xmlファイルで、次に示すOracleAS Single Sign-On要素を検索します。

    <Target TYPE="oracle_sso_server" ... >
       ....
    </Target>
    
    
  5. oracle_sso_server要素内で、HTTPPortおよびHTTPProtocolプロパティの値を編集します。

    OracleAS Single Sign-Onの物理ホストのポートおよびプロトコルを必ず入力してください。ロード・バランサの接続に使用するポートおよびプロトコルは使用しないでください。

  6. 変更を保存し、targets.xmlファイルを閉じます。

9.1.2.1.2 SSL証明書を認識させるためのApplication Server Controlの構成

Application Server Controlが、SSL接続を介してOracleAS Single Sign-OnおよびOracle Delegated Administration Servicesを監視できるようにするために、Application Server Controlに適切なセキュリティ証明書へのアクセス権があることを確認します。

この手順を実行しないと、OracleAS Single Sign-OnおよびOracle Delegated Administration Servicesが起動され、実行中であっても、Application Server Controlには停止または使用不可と示されます。

この問題を解決するには、HTTPSをサポートするために使用した認証局を、Application Server Controlが認識できるようにする必要があります。 Application Server Controlによって認識される認証局のリストに、その認証局の証明書を追加する必要があります。

Application Server Controlを構成して認証局を認識させるには、次の手順を実行します。

  1. Webサイトの認証局の証明書を取得します。

    1. Microsoft Internet Explorerで、監視するApplication ServerのHTTPS URLに接続します。

    2. ブラウザ画面の下部にある鍵のアイコンをダブルクリックします。このアイコンは、セキュアなWebサイトに接続していることを示します。

      ブラウザに「証明書」ダイアログ・ボックスが表示されます。ここには、このWebサイトで使用されている証明書についての説明が示されます。 他のブラウザでも、Webサイトの証明書の詳細を表示するための類似したメカニズムが提供されています。

    3. 「証明のパス」タブをクリックし、証明書のリストで先頭のエントリを選択します。

    4. 「証明書の表示」をクリックし、2つ目の「証明書」ダイアログ・ボックスを表示します。

    5. 「証明書」ウィンドウで、「詳細設定」タブをクリックします。

    6. 「ファイルにコピー」をクリックして、「証明書のエクスポート」ウィザードを表示します。

    7. 「証明書のエクスポート」ウィザードで、エクスポートする形式として「Base64 encoded X.509 (.CER)」を選択し、簡単に識別できる名前(sso_certificate.cerなど)で、その証明書をテキスト・ファイルに保存します。

    8. 任意のテキスト・エディタを使用して、証明書ファイルを開きます。

      証明書ファイルの内容は、例9-1に示す内容と同様です。

  2. 認証局のリストを更新します。

    1. 次に示すOracle Application ServerのOracleホームのディレクトリで、b64InternetCertificate.txtファイルを検索します。

      ORACLE_HOME¥sysman¥config¥
      
      

      このファイルには、Base64証明書のリストが含まれています。

    2. b64InternetCertificate.txtファイルを編集し、ファイルの末尾にエクスポート直後の証明書ファイルの内容を追加します。証明書のBase64テキストをすべて含めてください(BEGINおよびEND行を含む)。

  3. 証明書が含まれるテキスト・ファイル(たとえば、この手順の前半でsso_certificate.cerという名前を付けたファイル)を、OracleAS Portal中間層にコピーします。

  4. 次のコマンドを使用し、orapkiユーティリティで、Oracle Walletのmonwalletを更新します。

    DESTINATION_ORACLE_HOME¥bin¥orapki wallet add 
        -wallet ORACLE_HOME¥sysman¥config¥monwallet 
        -trusted_cert 
        -cert certificate_location
    
    

    パスワードを要求されたら、monwallet Walletのパスワードを入力します。 デフォルトのパスワードはwelcomeです。

    この例では、certificate_locationに、この手順の前半で保存してOracleAS Portal中間層にコピーした証明書が含まれるテキスト・ファイルへのフルパスを指定します。次に例を示します。

    D:¥oracle¥sso_certificate.cer
    
    
  5. Application Server Controlを再起動します。

    Application Server Controlを再起動した後、Enterprise Managerによって認証局のリストへの追加が検出され、セキュアなApplication Server Control Consoleを使用して、OracleAS Portalメトリックを正常に監視できます。

    例9-1    エクスポートされた証明書の内容の例

    -----BEGIN CERTIFICATE-----
    MIIDBzCCAnCgAwIBAgIQTs4NcImNY3JAs5edi/5RkTANBgk
    ... base64 certificate content ...
    ------END CERTIFICATE------
    

9.1.3 アップグレード後のOracle Delegated Administration Servicesに対するSSLの有効化

アップグレードされたOracleホームにOracle Delegated Administration Servicesも構成されている場合は、Oracle Delegated Administration ServicesのURLを再構成する必要があります。

Oracle Delegated Administration ServicesのURLを再構成するには、次の手順を実行します。

  1. Oracle Directory Manager(oidadmin)を起動し、Oracle Internet Directoryに接続します。

    oidadminツールは、アップグレード先Oracleホームの次のディレクトリにあります。

    DESTINATION_ORACLE_HOME\bin\
    
    

    SSLを介してディレクトリに接続する場合は、ディレクトリ・サーバーに接続するときに「SSL有効」チェック・ボックスを選択します。

  2. システム・オブジェクト・ナビゲータで、次のようにcn=OperationURLsエントリまで移動します。

    Entry Management ->
      cn=OracleContext ->
         cn=Products -> 
            cn=DAS -> 
               cn=OperationURLs
    
    
  3. cn=OperationURLsエントリを選択してから、Oracle Directory Managerウィンドウの右側のペインにある「プロパティ」タブで、orcldasurl属性の場所を確認します。

  4. Oracle Delegated Administration ServicesのSSL URLを参照するように、orcldasurlbase属性を変更します。

    https://virtual_server_name:load_balancer_ssl_listen_port
    

    関連項目:

    『Oracle Internet Directory管理者ガイド』のOracle Directory Managerの使用方法に関する項を参照してください。 

9.2 タスク2: Oracle Internet Directoryのアップグレード後の手順の実行

Oracle Internet Directoryのアップグレードを完了するには、次のタスクを実行する必要があります。

9.2.1 証明書のアップグレード・ツール(upgradecert.pl)の実行

リリース2(10.1.2)からは、証明書のハッシュ値を使用してOracle Internet Directoryにバインドできるようになりました。このハッシュ値を導入するには、リリース2(10.1.2)より前に発行されたユーザー証明書をディレクトリで更新する必要があります。

結果的に、10gリリース2(10.1.2)より前のリリースからアップグレードする場合、およびユーザー証明書をディレクトリでプロビジョニングする場合は、このアップグレード後の追加手順を実行する必要があります。

Oracle Internet Directory 10gリリース2(10.1.2)からアップグレードする場合、この手順は必要でないことに注意してください。

証明書のアップグレード・ツール(upgradecert.pl)の実行方法の詳細は、『Oracle Internet Directory管理者ガイド』のLDIFおよびコマンドライン・ツールの構文に関する項を参照してください。

9.2.2 Oracle Internet Directoryのアップグレード後のアクセス・ポリシーの変更

Oracle Internet Directoryのアップグレード時、ディレクトリ内のLDAPオブジェクトは、変更されるか、またはOracle Internet Directoryに追加されます。これらの更新には、アクセス制御情報が含まれる場合があります。

本番環境では、カスタマイズされたアクセス制御ポリシーがディレクトリ内での適用されます。 そのため、アップグレード処理では、ディレクトリで実装したカスタマイズ済の動作を維持するために、意図的にディレクトリ内の特定のエントリがそのまま残されます。

また、Oracleコンポーネントが正常に動作するためには、デフォルトでそのまま使用できるアクセス制御設定が必要な場合があります。そのため、Oracle Internet Directoryのアップグレード後、デフォルトでそのまま使用できるアクセス制御ポリシーと、実装済のカスタム・ポリシーの差異を分析する必要があります。このタスクを実行した結果、Oracleコンポーネントの要件を満たす、カスタマイズ済のアクセス制御ポリシーと、組織のアクセス制御ポリシーが実装されます。

カスタマイズ済のアクセス制御ポリシーを実装していない場合でも、アップグレード後は、ACLを新しいデフォルト値に手動で更新することをお薦めします。

次の例では、デフォルトのレルムDNとして「dc=acme, dc=com」を使用します。この例では、ディレクトリのACLポリシーを分析する場合に次の事項を考慮します。

そのまま使用できるアクセス制御ポリシーは、次のファイルで使用可能です。

デフォルトのACLポリシーは、『Oracle Internet Directory管理者ガイド』の第17章にある共通グループ属性を読み取るためのデフォルトの権限の項で説明されています。

9.2.3 レプリケーションWalletパスワードのリセット

9.0.xのノードを10g(10.1.4.0.1)にアップグレードし、このノードのレプリケーションを設定しようとすると、レプリケーション・サーバーが起動に失敗し、レプリケーションの設定自体が失敗する場合があります。 レプリケーションWalletパスワードの変更およびリセットについては、A.4.1項「各レプリカでのOracle Internet Directory WalletのレプリケーションDNのパスワードの変更」を参照してください。

9.2.4 Oracle Directory Integration Platformのアップグレードの完了

別のコンピュータ上の別のOracleホームで、より古いリリース(9.0.2または9.0.4)のDirectory Integration Platformが動作しており、アップグレード対象のOracle Internet Directoryを使用している場合、そのOracle Directory Integration Platformを使い続けるには、Oracle Directory Integration Platformサーバーを再登録する必要があります。

関連項目:

DIPサーバーの登録手順については、『Oracle Identity Management統合ガイド』を参照してください。 

9.2.5 Oracle Internet Directoryを10g(9.0.4)からアップグレードした後のoidstats.sqlスクリプトの実行

Oracle Internet Directoryを10g(9.0.4)から10g(10.1.4.0.1)にアップグレードした後、一部のLDAP問合せのパフォーマンスが低下する場合があります。

この問題を解決するには、次の手順を実行します。これによって、Oracle Internet DirectoryサーバーをホスティングするOracle Database 10gデータベース内の一部のデータベース統計が更新されます。

  1. 新しくアップグレードしたOracle Internet DirectoryのOracleホームで、ODSデータベース・ユーザーとしてOIDデータベースに接続し、次のSQLスクリプトを実行します。

    sqlplus ods/<passwd> @%ORACLE_HOME%/ldap/admin/oidstats.sql
    
    
  2. 次のようにOracle Internet Directoryサーバーを再起動します。

    1. 次のコマンドを実行してOracle Internet Directoryサーバーを停止します。

      opmnctl stopproc ias-component=OID
      
      
    2. Oracle Internet Directoryサーバーが完全に停止するまで数秒間待機します。

    3. 次のコマンドを実行してOracle Internet Directoryサーバーを起動します。

      opmnctl startproc ias-component=OID
      
      

同様に、Oracle Internet Directoryのアップグレード前にOracle Internet Directoryをホスティングするデータベースがアップグレードされる環境で実行している場合は、データベースのアップグレード直後にデータベースに対して次のSQLコマンドを実行してデータベース統計を収集する必要があります。

exec dbms_stats.gather_schema_stats('ODS'); 

9.2.6 アップグレード後のDSA構成エントリの変更

Oracle Internet Directoryを10g(9.0.4)から10g(10.1.4.0.1)にアップグレードすると、DSA構成エントリ内のすべての属性がデフォルト値にリセットされます。たとえば、次に示すとおりです。

cn=dsaconfig,cn=configsets,cn=oracle internet directory

このため、アップグレード前にこのエントリ内の属性を変更した場合は、アップグレード前にそれらの属性を対応する値に再構成する必要があります。

9.2.7 アップグレード後のOracle Internet Directory索引の再作成

Oracle Internet Directoryを10g(9.0.4)から10g(10.1.4.0.1)にアップグレードすると、このアップグレード処理によって一部の索引が自動的に再作成されます。たとえば、EI_attrstore索引はアップグレード時に自動的に再作成されます。

このため、アップグレード前にEI_attrstore索引を再作成した場合は、アップグレード後に再度その索引を再作成する必要があります。 EI_attrstore索引の再作成は、大きいグループ・エントリを検索する場合のパフォーマンスに関する推奨事項(『Oracle Internet Directory管理者ガイド』の大きいグループ・エントリの検索の最適化に関する項を参照)の一部です。10g(10.1.4.0.1)にアップグレードする前にこの手順を実行した場合は、アップグレード後に再度この手順を実行する必要があります。

9.2.8 サーバーの管理性についての情報へのアクセスに使用する新しいアカウント

Oracle Internet Directoryデータベース・アカウントODSSMを使用して、データベースにあるサーバーの管理性についての情報にアクセスします。 このアカウントは、10g(10.1.4.0.1)へのアップグレード中に作成され、ランダムに生成されたパスワードが指定されます。

このアカウントの資格証明(ランダムなパスワードを含む)は、Enterprise Managerファイルtargets.xmlのOracle Internet Directoryの部分に格納されます。

このアカウントのパスワードを変更できる唯一の方法は、SQLPLUSを使用することです。 oidpasswdツールを使用して、このパスワードを変更することはできません。 また、このパスワードはWalletに格納されません。 このパスワードをデータベースで変更した後に、targets.xmlファイルでも変更する必要があります。 これを行うには、ユーザー・フィールドおよびパスワード・フィールドに新しい値を設定するか、またはoidemdpasswdツールを実行します。

9.3 タスク3: OracleAS Single Sign-Onのアップグレード後の手順の実行

OracleAS Single Sign-Onのアップグレードを完了するには、アップグレードされた構成に応じて、次の項で説明するタスクの実行が必要です。

9.3.1 OracleAS Single Sign-On中間層の再構成

Single Sign-Onサーバーの10g(9.0.4)または10gリリース2(10.1.2)中間層がカスタム構成であった場合(Oracle HTTP ServerがSSL用に構成されていたり、Oracle Application Server Single Sign-Onサーバーのデータベース・アクセス記述子がカスタム構成されていた場合など)、アップグレードされた10g(10.1.4.0.1)中間層も同様に再構成する必要があります。

関連項目:

中間層を構成する方法については、『Oracle Application Server Single Sign-On管理者ガイド』を参照してください。 

OracleAS Portalを使用している場合に、SSL用に10gリリース2(10.1.2)中間層を再構成すると、Oracle Delegated Administration Servicesに使用するURLが最新でなくなる可能性があります。この問題を解決するには、ポータル・キャッシュのリフレッシュを実行します。これによって、関連するOracle Internet Directory情報は保持されます。

  1. 管理者権限を持つユーザーとしてOracleAS Portalにログオンします。

  2. 「ビルダー」に移動します。

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

  4. 「ポータル」タブから、「グローバル設定」を開き、「SSO/OID」タブに移動します。

  5. ページの下部にスクロールします。

  6. 「OIDパラメータ用キャッシュのリフレッシュ」を選択します。

  7. 「適用」をクリックします。

    ページの「DASホスト名」フィールドが適切な値にリフレッシュされます。

    関連項目:

    『Oracle Application Server Portal構成ガイド』 

9.3.2 サード・パーティ認証の構成

10g(9.0.4)または10gリリース2(10.1.2)中間層がユーザー証明書または第三者機関の認証メカニズムを使用して認証するように構成されていた場合、10g(10.1.4.0.1)のOracleAS Single Sign-Onサーバーも同様に再構成する必要があります。

関連項目:

中間層を構成する方法については、『Oracle Application Server Single Sign-On管理者ガイド』の第13章を参照してください。 

9.3.3 カスタマイズされたページのアップグレードされたサーバーへのインストール

10g(9.0.4)または10gリリース2(10.1.2)のSingle Sign-Onサーバーでログイン、パスワードおよびサインオフのページをカスタマイズしていた場合、そのページを10g(10.1.4.0.1)の仕様に従って更新する必要があります。これは、アプリケーション・サービス・プロバイダのサポートを有効にし、デプロイのログイン・ページを更新して企業フィールドを有効にしていた場合も同様です。

関連項目:

中間層を構成する方法については、『Oracle Application Server Single Sign-On管理者ガイド』の第12章を参照してください。 

9.3.4 OracleAS Single Sign-Onレプリケーションの設定

Oracle Internet Directoryレプリケーションを使用してOracleAS Single Sign-Onレプリケーションも使用する場合、アップグレードされた10g(10.1.4.0.1)表を10g(9.0.4)Oracle Internet Directoryとともにレプリケーション・グループに追加します。レプリケーションにOracleAS Single Sign-On表を追加するには、次の手順を実行します。

  1. ディレクトリ・レプリケーション・グループのすべてのレプリカでOracle Internet Directoryレプリケーション・サーバーを停止します。

  2. マスター・ディレクトリ・レプリカの%ORACLE_HOME%¥ldap¥adminで、次のコマンドを実行します。

    sqlplus repadmin/password@<mds connect id> @oidrssou.sql
    
    
  3. ディレクトリ・レプリケーション・グループのすべてのレプリカでOracle Internet Directoryレプリケーション・サーバーを起動します。

    関連項目:

    詳細は、『Oracle Internet Directory管理者ガイド』のディレクトリ・レプリケーションの管理に関する項を参照してください。  

9.3.5 カスタマイズされた中間層のOracleAS Single Sign-Onサーバーのアップグレード

10g(9.0.4)または10gリリース2(10.1.2)のOracleAS Single Sign-Onサーバーがデフォルトの中間層インストール以外の中間層を使用していた場合、中間層がアップグレードされたOracleAS Single Sign-Onサーバーを指し示すように構成する必要があります。

たとえば、10g(9.0.4)または 10gリリース2(10.1.2) OracleAS Single Sign-Onサーバー中間層でリバース・プロキシを構成していた場合、10g(10.1.4.0.1)のOracleAS Single Sign-Onサーバー中間層でも構成する必要があります。

9.3.6 Wireless Voice認証のトラブルシューティング

Wireless Voice認証を10g(10.1.4.0.1)のOracleAS Single Sign-Onサーバーで使用する場合に機能しないときは、OracleAS Single Sign-Onサーバー・エントリがOracle Internet Directoryでベリファイア・サービス・グループのメンバーであること(cn=verifierServices,cn=Groups,cn=OracleContext)を確認します。このメンバーであることが、Wireless Voice認証の要件です。メンバーであることを確認するには、次の手順を実行します。

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

    ldapsearch -h host
        -p port 
        -D "cn=orcladmin" 
        -w password
        -b "cn=verifierServices, cn=Groups, cn=OracleContext" "objectclass=*"
    
    

    例9-2に示すように、エントリでuniquememberとして表示されていれば、OracleAS Single Sign-Onサーバーはベリファイア・サービス・グループのメンバーです。

    例9-2    OracleAS Single Sign-Onサーバーのuniquememberの表示

    cn=verifierServices, cn=Groups,cn=OracleContext
    .
    .
    .
    uniquemember=orclApplication
    CommonName=ORASSO_SSOSERVER,cn=SSO,cn=Products,cn=OracleContext
    .
    .
    .
    

9.3.7 OracleAS Single Sign-Onサーバーへの言語のインストール

OracleAS Single Sign-Onのアップグレード時に言語を選択しなかった場合、またはアップグレード後に追加の言語をインストールする場合、次の手順に従って必要な言語をインストールできます。

  1. Repository Creation AssistantのCD-ROMから必要な言語ファイルをOracleAS Single Sign-OnサーバーのOracleホームにコピーします。

    copy repCA_CD¥portal¥admin¥plsql¥nlsres¥ctl¥lang¥*.* DESTINATION_ORACLE_
    HOME¥sso¥nlsres¥ctl¥lang
    
    

    この例では、langが言語コードです。たとえば、日本語の言語コードはjaです。

  2. 言語をサーバーにロードします。

    関連項目:

    言語のロード方法は、『Oracle Application Server Single Sign-On管理者ガイド』の第2章にあるグローバリゼーション・サポートの構成に関する項を参照してください。  

9.3.8 不要なOracleAS Single Sign-Onパートナ・アプリケーションの削除

アップグレード後、OracleAS Single Sign-Onパートナ・アプリケーションの管理ページには、余分な、または使用されていないパートナ・アプリケーションが表示されます。

たとえば、2つのOracle Application Server Certificate Authority(OCA)パートナ・アプリケーションおよび2つのOracleAS Wirelessパートナ・アプリケーションが表示されます。

ポート4400を使用する10g(9.0.4) OCAは、削除してもかまいません。

関連項目:

パートナ・アプリケーションのリストからソース・コンポーネントを削除する手順については、10.2項「タスク2: OracleAS Identity ManagementのソースOracleホームの破棄」を参照してください。 

OracleAS Wirelessパートナ・アプリケーションの場合は、アップグレード後、10g(9.0.4) HTTP Serverポートが使用されるように10gリリース2(10.1.2) Oracle HTTP Server構成が変更されます。このパートナ・アプリケーションは、有効ではないため削除できます。有効なOracleAS Wirelessパートナ・アプリケーションは、10g(9.0.4)環境に存在していた、アップグレード後のパートナ・アプリケーションです。

パートナ・アプリケーションのリストで、不要になったり、アップグレード済であるコンポーネントまたはアプリケーションを確認します。

関連項目:

アップグレード済のOracleAS Identity Managementインストールと表示されるパートナ・アプリケーションの削除については、10.2項「タスク2: OracleAS Identity ManagementのソースOracleホームの破棄」を参照してください。 

9.4 タスク4: OracleAS Portalのアップグレード後の手順の実行

次の項で、OracleAS Portalスキーマのアップグレードを完了する方法について説明します。


注意:

この項で説明する手順は、10g(10.1.4.0.1)のMetadata Repository Upgrade Assistant(MRUA)を実行し、MRUAによって、PORTALスキーマが10gリリース2(10.1.2.0.2)にアップグレードされたことがレポートされた場合にのみ実行する必要があります。

MRUAの出力にPORTALスキーマがすでにアップグレードされていることが示された場合、この項に示す手順を実行する必要はありません。 


9.4.1 アップグレードされたPortalインスタンスを使用するすべての中間層の起動

スクリプトが正常に実行された後、次の手順を実行して、アップグレードされたPortalインスタンスを使用する各中間層を起動します。

  1. 「サービス」コントロール パネルでProcess Managerサービスを開始して、OPMNおよびそれによって管理されるプロセスを起動します。

  2. 「サービス」コントロール パネルで、Application Server Controlサービスを開始します。

9.4.2 ポートレット・リポジトリの新形式への移行(オプション)

デフォルトでは、ポートレット・リポジトリはOracleAS Portalスキーマにインプレース・アップグレードされます。ポートレット・リポジトリ内の既存のページ、テンプレート、アイテムなどがアップグレードされ、新しいポートレットがリポジトリに追加されます。以前の設定が維持されるため、ページはアップグレード実行前と非常によく似ています。


注意:

アップグレード前のリリースがOracle9iAS Portalリリース2(9.0.2)で、ポートレット・リポジトリをプロバイダ名でグループ化するようにレンダリングした場合、アップグレード後にリポジトリ内のフォルダはカテゴリでグループ化されます。これは、OracleAS 10g(9.0.4)以上ではプロバイダ名ごとにグループ化オプションは推奨されていないためです。

同様の編成を作成するには、プロバイダ名を表すカテゴリにポートレット名を割り当てます。 


リポジトリの外観を新しくインストールされたインスタンスの外観にするには、スクリプトを使用して、アップグレードされたポートレット・リポジトリを再作成します。スクリプトは、既存のポートレット・リポジトリを削除して、再作成します。スクリプトは、ポートレット・リポジトリ内のカスタマイズ、設定、スタイル、バナーなどを保持しない場合にのみ使用してください。

ポートレット・リポジトリを再作成するには、9.4.1項「アップグレードされたPortalインスタンスを使用するすべての中間層の起動」の説明に従って中間層を起動した後で、次の手順を実行します。

  1. スクリプトによってリポジトリが上書きされて元に戻すことができなくなるため、データベースのバックアップを実行します。

  2. OracleAS Metadata Repository Upgrade Assistant and UtilitiesのCD-ROMの次のディレクトリに移動します。このディレクトリには、prrplc.sqlスクリプトが含まれています。

    MRUA_CDROM_ROOT¥portal¥admin¥plsql¥upg¥common
    
    
  3. Portalスキーマ・ユーザーとして、SQL*PlusからOracleAS Metadata Repositoryデータベースにログインします。

  4. 引数を指定せずにprrplc.sqlスクリプトを実行します。

9.4.3 アップグレードされたOracleAS Portalへのアクセス

OracleAS Portal Repositoryのアップグレードでエラーが発生しなかった場合、アップグレードされたPortalにアクセスできます。ブラウザを開き、次のURLに移動します。

http://host.domain:port/pls/portal_DAD

次に例を示します。

http://portalhost42.acme.com:7777/pls/portal

9.4.4 OracleAS PortalのOracle Text索引でOracleAS Metadata Repositoryデータベースを停止する場合の影響

欠落したOracle Text索引がOracleAS Portalのアップグレード処理中に作成されますが、移入は行われません。移入には非常に長い時間がかかる場合があるためです。新しい索引は、アップグレードの完了後、次の同期ジョブのスケジューリング時に移入されます。

アップグレード(バックアップ用)およびOracle Text索引の同期ジョブの起動後、データベースを停止する必要がある場合は、同期プロセスに対する次の停止コマンドの影響を考慮してください。

9.4.5 Delegated Administration Servicesで動作するためのOracleAS Portalの再構成

10gリリース2(10.1.2)より前のOracleAS Portalでは、InfrastructureおよびApplication Server中間層が別々のホストまたはプロトコルに分割されていた場合、ユーザーおよびグループLOVは、JavaScriptのオリジナル・サーバー・セキュリティ・ポリシーに対応するように構成する必要がありました。JavaScriptエラーが発生する原因は、OracleAS PortalとDelegated Administration Services(DAS)が別々のドメインにあることでした。

この問題には次の2つの解決方法がありました。

OracleAS Portal 10gリリース2(10.1.2)では、LOVの実装はコールバック方式をサポートするように変更され、ドメイン間の問題が解消され、前述の構成手順は不要になりました。ただし、このコールバック方式では、ドメイン間でのLOVの使用をサポートするために、DAS環境に対応するパッチが必要になります。

コールバック方式は、DAS 10g(9.0.4)以上でサポートされています。DASリリース2(9.0.2.3)を使用している場合は、パッチ3278638を適用するとコールバックをサポートできます。

ご使用の環境に適切なDASリリースがインストールされ、前述の構成オプションを実装していない場合は、個別のホストでLOVをサポートするためにOracleAS Portalで追加の構成手順を実行する必要はありません。ただし、前述の構成オプションを使用した場合は、その手順を削除する必要があります。手順は次のとおりです。

  1. 共通ドメインが定義されていた場合は、secjsdom.sqlスクリプトを次のとおり実行してリセットします。

    1. オペレーティング・システムのコマンド・プロンプトから、次のディレクトリに移動します。

      DESTINATION_MIDTIER_ORACLE_HOME¥portal¥admin¥plsql¥wwc 
      
      
    2. SQL*Plusを使用して、スキーマ所有者としてOracleAS Portal Repositoryに接続し、次のコマンドを実行します。

      @secjsdom ''
      commit;
      
      
  2. ローカルにデプロイされたDASサーブレットを使用するようにOracleAS Portalが構成されている場合は、secdaslc.sqlスクリプトを次のとおり実行し、Infrastructure層を指し示すように再構成します。

    1. オペレーティング・システムのプロンプトから、次のディレクトリに移動します。

      DESTINATION_MIDTIER_ORACLE_HOME¥portal¥admin¥plsql¥wwc
      
      
    2. SQL*Plusを使用して、スキーマ所有者としてOracleAS Portal Repositoryに接続し、次のコマンドを実行します。

      @secdaslc N
      commit;
      

9.4.6 カスタマイズされたログイン・ポートレットの更新

ログイン・ポートレットがカスタマイズされている場合は、このリリースで動作するように更新する必要があります。以前のリリースでは、ユーザー証明書はOracleAS Portalのwwptl_login.login_urlプロシージャに渡されていました。今回のリリースでは、ユーザー証明書はOracleAS Single Sign-Onのwwsso_app_admin.ls_loginプロシージャに渡される必要があります。OracleMetaLinkのNote 290445.1に記載されている手順に従って、カスタマイズされたログイン・ポートレットがwwsso_app_admin.ls_loginを使用するように更新します。


注意:

Oracle Application Server 10g(9.0.4)パッチ・セット1(9.0.4.1)または次の個別パッチの適用後に、パッチのドキュメントで説明されている手順を実行した場合は、この時点で追加の手順を実行する必要はありません。

  • 3273358(10g(9.0.4))

  • 3273354(リリース2(9.0.2.6))

  • 3273342(リリース2(9.0.2.3))

 

9.4.7 OracleAS Portalのパフォーマンス・レポートの更新

OracleAS Portalのパフォーマンス・レポートを生成するには、一連のSQLスクリプトを使用する必要があります。それらのスクリプトは、OracleAS Portalのログ・ファイルをデータベース表にロードし、その情報に基づいてレポートを作成するために使用されます。それらのスクリプトは、次のディレクトリにあります。

ORACLE_HOME¥portal¥admin¥plsql¥perf

すでにパフォーマンス・レポート・スクリプトを使用している場合は、OracleAS Portalリリース2(10.1.2.0.2)にアップグレードした後、次のファイルの新しいコピーを実行する必要があります。

ORACLE_HOME¥portal¥admin¥plsql¥perf¥install¥update.sql

これは、Repositoryのリクエストに新しいURL形式を対応させ、新しいデータの収集を可能にするためです。これを行わないと、スクリプトが機能しません。

それらのスクリプトを使用してOracleAS Portalのパフォーマンスを監視する方法については、スクリプトのサブディレクトリにある次のファイルを参照してください。

ORACLE_HOME¥portal¥admin¥plsql¥perf¥scripts¥README.html

9.5 タスク5: OracleAS Wirelessのアップグレード後の手順の実行

次の項で、Oracle Application Server Wirelessのアップグレードを完了するために実行する必要があるタスクについて説明します。

9.5.1 Oracle Internet DirectoryでのorclWirelessAccountNumber属性に対する一意性制約の追加

10g(10.1.4.0.1)では、Oracle Internet Directoryは、ユーザー属性に対する一意性制約を自動的に設定しません。orclUserV2オブジェクト・クラスのorclWirelessAccountNumber属性に対して一意性制約が設定されていない場合、Wireless Voice認証は正しく機能しません。

中間層およびInfrastructureのアップグレードの完了後、次の手順を実行して一意性制約を設定します。

  1. スクリプトaddAccountNumberUniqueConstraint.batを実行します。このスクリプトは、次のディレクトリにあります。

    DESTINATION_ORACLE_HOME¥wireless¥bin
    
    

    このスクリプトには、1つの引数(Oracleホームのフルパス)を指定します。たとえば、次に示すとおりです。

    addAccountNumberUniqueConstraint.bat DESTINATION_ORACLE_HOME
    
    
  2. Oracle Internet Directoryサーバーを再起動します。

9.5.2 OracleAS Wirelessに対するパスワード変更権限の割当て

Oracle Application Server 10g(10.1.4.0.1)では、OracleAS Wirelessアプリケーション・エンティティは、デフォルトではユーザー・パスワードを変更できる権限を持っていません。そのため、ユーザーはインストール直後にOracleAS Wirelessサーバーに対するパスワードを変更できません。ただし、UserSecurityAdmins権限をOracleAS Wirelessアプリケーション・エンティティに割り当てることによって、パスワードを変更する機能を有効にできます。

これを行うには、次のスクリプトを実行します。

DESTINATION_ORACLE_HOME¥wireless¥bin¥assignUserSecurityAdminsPrivilege.bat

構文は次のとおりです。

assignUserSecurityAdminsPrivilege.bat oid_super_user_dn user_password

この例の内容は、次のとおりです。

次に例を示します。

assignUserSecurityAdminsPrivilege.bat "cn=orcladmin" welcome1

関連項目:

『Oracle Application Server Wireless管理者ガイド』のパスワードのリセットに関する項を参照してください。 

9.5.3 HTTPアダプタを使用するWirelessサービスの場合のURL問合せパラメータの指定

HTTPアダプタを使用してWirelessサービスを構築する場合、指定する必要があるサービス・パラメータの1つにバックエンド・アプリケーションに対するURLがあります。場合によって、問合せパラメータをバックエンド・アプリケーションに送信することがあります。OracleAS Wirelessからこれを行うには、例9-3および例9-4に示すように2つの方法があります。 例9-3のパラメータ名はfn、値はJoeです。

例9-3    問合せパラメータを使用するURL

http://localhost:7777/myapp/home.jsp?fn=Joe

問合せパラメータは、サービスの最初のページに対するリクエストにおいてのみ送信されます。最初のページから他のページへのリンクがある場合でも、そのページに対するリクエストにはパラメータが追加されません。

例9-4    追加サービス・パラメータを使用するURL

http://localhost:7777/myapp/home.jsp 

URLを変更するかわりに、パラメータ名がfnおよび値Joeである追加サービス・パラメータを追加します。パラメータは最初のページだけでなくすべてのページに送信されます。さらに、そのパラメータはすべてのHTTPリダイレクト・リクエストでも送信されます。ただし、この方法では追加URLパラメータがOracleAS Single Sign-Onサーバーにも送信されるので、その場合にはサーバーからエラーが返されます。

エラーが発生するのは、バックエンド・アプリケーションがmod_ossoによって保護されている場合です。この場合、アプリケーションに対するリクエストは捕捉され、ユーザー認証のためにOracle SSOサーバーにリダイレクトされます。OracleAS Single Sign-Onサーバーには、送信されてくる問合せパラメータを制限するルールがあります。そのため、mod_ossoによって保護されているバックエンド・アプリケーションの場合、Wirelessサービスを変更し、例9-3のように問合せパラメータをURLに追加する必要があります。


戻る 次へ
Oracle
Copyright © 2006 Oracle Corporation.

All Rights Reserved.
目次
目次
索引
索引