2 Oracle B2Bのインストールと構成の準備
Oracle B2Bのインストール準備をするには、システムが基本要件を満たしていることを確認し、正しいインストール・ソフトウェアを入手します。
標準インストール・トポロジのインストールと構成のロードマップ
このロードマップでは、標準Oracle B2Bインストール・トポロジをインストールして構成するために必要なステップを示します。
表2-1では、標準インストール・トポロジをインストールするために必要なおおまかなステップについて説明します。
表2-1 標準インストールのロードマップ
タスク | 説明 | ドキュメント |
---|---|---|
システム環境を確認します |
インストールを開始する前に、最小限のシステム要件およびネットワーク要件を満たしていることを確認します。 |
「システム環境の確認のロードマップ」を参照してください。 |
インストールの前で必要になる必須パッチの確認 |
インストールしているソフトウェアに必要な必須パッチがあるかどうかについては、Oracle Fusion Middleware Infrastructureのリリース・ノートを確認してください。 |
『Oracle Fusion Middleware Infrastructureリリース・ノート』のインストールと構成に関する項を参照してください。 |
適切なディストリビューションを入手します |
B2Bには、既存のOracle Fusion Middleware InfrastructureのインストールとOracle SOA Suiteが必要です。B2Bは、Oracle Fusion Middleware InfrastructureおよびOracle SOA Suiteと同じOracleホームにインストールされている必要があります。B2Bには、 |
「製品ディストリビューションについて」を参照してください。 |
インストール・ディレクトリを決めます |
インストーラが、必要なインストーラ・ディレクトリにアクセスまたは作成できることを確認します。また、最小限の要件を満たすシステムにディレクトリが存在することを確認します。 |
Oracle Fusion Middlewareの理解のOracle Fusion Middlewareの主要なディレクトリに関する項を参照してください。 |
前提条件となるソフトウェアのインストール。 |
Oracle Fusion Middleware Infrastructureのインストールと構成のInfrastructureソフトウェアのインストール を参照してください。 |
|
ソフトウェアのインストール。 |
ソフトウェアのインストールにより、使用しているシステムにソフトウェアが転送され、Oracleホーム・ディレクトリが作成されます。 |
「Oracle B2Bソフトウェアのインストール」を参照してください。 |
データベース・プロファイルの選択と、必要なカスタム変数の確認 |
データベースに必要なスキーマをインストールする前に、Oracle B2Bのスキーマのために設定する必要のあるカスタム変数についての情報を確認します。 |
|
スキーマの作成。 |
リポジトリ作成ユーティリティを実行して、構成に必要なスキーマを作成します。 |
「データベース・スキーマの作成」を参照してください。 |
WebLogicドメインの作成 |
構成ウィザード/アシスタントを使用して、WebLogicドメインを作成して構成します。 |
「ドメインの構成」を参照してください。 |
高可用性のためのドメインの管理と準備 |
ドメインを管理するための追加のツールおよびリソースを確認し、可用性が高くなるようにドメインを構成します。 |
「ドメイン構成後の次のステップ」を参照してください。 |
システム環境の確認のロードマップ
インストールおよび構成プロセスを開始する前に、システム環境を検証する必要があります。
表2-2に示された重要なタスクおよびチェックを実行することにより、Oracle B2Bのインストールと構成のために環境が適切に準備されているかどうかを確認できます。
表2-2 システム環境の検証ロードマップ
タスク | 説明 | ドキュメント |
---|---|---|
動作保証およびシステム要件を確認します |
対象のオペレーティング・システムが動作保証されていて、インストールと構成に備えて構成されていることを確認します。 |
「動作保証、システムおよび相互運用性の要件の確認」 を参照してください。 |
適切なインストール・ユーザーを特定します |
インストール・ユーザーが、ソフトウェアをインストールおよび構成するための必要な権限を持っていることを確認します。 |
「インストール・ユーザーの選択」を参照してください。 |
目的のシステムでインストール・ディレクトリおよび構成ディレクトリを選択します |
推奨ディレクトリ構造に従って、ソフトウェアのインストールと構成に必要なディレクトリを作成できるかどうかを確認します。 |
インストールおよび構成のためのディレクトリについてを参照してください。 |
動作保証されたJDKをインストールします |
配布のインストール・プログラムは、ご使用のシステムで動作保証されたJDKを必要とします。 |
|
中間層のスキーマのデータベースのインストールと構成 |
WebLogicドメインを構成するには、Oracle B2Bに必要なスキーマのために構成された動作保証済のデータベースへのアクセス権が必要です。 |
動作保証、システムおよび相互運用性の要件の確認
ご使用の環境がインストールに必要な要件を満たしていることを確認するには、動作保証マトリックスおよびシステム要件のドキュメントをあわせて使用することをお薦めします。
-
環境が動作保証要件を満たしていることの確認:
サポートされているハードウェア構成およびソフトウェア構成で製品をインストールすることを確認します。
Oracleでは、動作保証済のすべてのシステムおよび環境で製品のパフォーマンスをテストおよび検証しています。新しい動作保証要件がリリースされると、それらはすぐに動作保証に関するドキュメントに追加されます。新しい動作保証は随時リリースされる場合があります。そのため、動作保証のドキュメントはドキュメント・ライブラリとは別に管理され、Oracle Technology Networkで利用できます。
-
動作保証情報を確認するためのシステム要件ドキュメントの使用:
Oracle Fusion Middlewareのシステム要件と仕様に関するドキュメントを使用して、動作保証要件が満たされていることを確認することをお薦めします。システム要件は、将来的に変更されることがあります。そのため、システム要件情報のドキュメントは、ドキュメント・ライブラリとは別に作成され、Oracle Technology Networkで利用できます。
-
複数の製品間での相互運用性の確認:
同じリリースまたは異なるリリースが混在する複数のFusion Middleware製品をインストールおよび実行する方法を学習するには、『相互運用性および互換性の理解』のOracle Fusion Middlewareの相互運用性および互換性に関する項を参照してください。
インストール・ユーザーの選択
システムをインストールおよび構成するユーザーには、必要な権限が付与されている必要があります。
ユーザー権限について
Fusion Middleware製品をインストールするユーザーは、そのファイルを所有し、そのファイルに対する特定の権限を持ちます。
-
実行可能ファイル以外(
.jar
、.properties
、.xml
など)のすべてのファイルに対する読取り権限と書込み権限。その他の同じグループのすべてのユーザーにはファイル所有者として読取り権限のみがあります。 -
すべての実行可能ファイル(
.exe
、.sh
または.cmd
)に対する読取り、書込みおよび実行権限。同じグループのその他のすべてのユーザーにはファイル所有者として読取り権限および実行権限のみがあります。
これは、ソフトウェアをインストールしたユーザー以外のユーザーが、Oracleホーム・ディレクトリにインストールされているバイナリを使用して、ドメインやFusion Middleware製品を構成できることを意味します。
構成中に構成処理で生成されたファイルの所有権は、構成ウィザードを実行するユーザーに属します。このユーザーは、前述のインストール・ユーザーと同じ権限を持ちます。ただし、セキュリティ・センシティブなファイルは、グループ権限では作成されません。ドメインを作成したユーザーのみが読取りおよび書込み権限を持ち、ドメインを管理できます。
次に例を示します。
-
例1: 1人のユーザーがソフトウェアをインストールしてドメインを構成する場合
図2-1は、同じユーザーがソフトウェアをインストールしてドメインを構成する場合のファイル権限を説明したものです。
すべてのファイルに対して適切な権限があるようにするには、同じ所有者が構成ウィザードを使用してOracle Fusion Middleware製品のインストールとWebLogic Serverドメインの構成の両方のタスクを実行することをお薦めします。
図2-1 製品インストールを管理するときのディレクトリ構造 - 単一のユーザーがソフトウェアをインストールしてドメインを構成
ドメインを作成するユーザーがソフトウェアをインストールしたユーザーと異なる場合、次の例に示すように、どちらのユーザーにも同じ権限が必要です。
-
例2: Oracleホーム・ディレクトリとドメインを別のユーザーが作成する場合
図2-2は、Oracleホームを作成するユーザーとドメインを構成するユーザーが異なる場合のファイル権限を説明したものです。
図2-2 異なるユーザーがソフトウェアをインストールしてドメインを構成する場合のディレクトリ構造
ノート:
特定のドメイン・ファイルには、グループ権限がありません。たとえば、cwallet.sso
です。
インストーラを実行する前に、次の点について考慮してください。
-
UNIXオペレーティング・システムでは、ソフトウェアをインストールする前に
umask
を027
に設定することをお薦めします。これにより、インストール時にファイルの権限を適切に設定できます。以下のコマンドを使用します。umask 027
このコマンドは、製品のインストーラと同じ端末ウィンドウで実行する必要があります。
-
UNIXオペレーティング・システムでは、インストール・プログラムを
root
ユーザーで実行しないでください。rootユーザーとしてインストーラを実行すると、起動検証に失敗し、インストールを続行できなくなります。 -
製品のインストールを管理する際(パッチ適用)は、製品インストールに使用したものと同じユーザーIDを使用します。
ドメインを管理する際(管理対象サーバーの起動など)は、ドメイン作成に使用したものと同じユーザーIDを使用します。
-
Windowsオペレーティング・システムでは、製品のインストールに管理者権限が必要です。「Windowsオペレーティング・システムでのインストール・ユーザーに管理者権限があることの確認」を参照してください。
LinuxまたはUNIXオペレーティング・システムでのデフォルト以外のユーザー権限について
デフォルトの権限の設定を変更すると、インストールおよびシステムのセキュリティが低下します。デフォルトの権限の設定を変更することはお薦めしません。
他のユーザーが特定のファイルまたは実行可能ファイルにアクセスする必要がある場合は、LinuxまたはUNIXのsudo
コマンド(または他の同様のコマンド)を使用してファイルのアクセス権を変更してください。
さらにサポートが必要な場合は、ご使用のLinuxまたはUNIXオペレーティング・システムに付属している管理者ガイドを参照するか、オペレーティング・システムのベンダーに問い合せてください。
インストールおよび構成のためのディレクトリについて
インストールとドメイン構成のプロセス中に、Oracleホーム、ドメイン・ホームおよびアプリケーション・ホームのディレクトリの場所の指定について計画する必要があります。
推奨ディレクトリ構造について
Oracleホーム、ドメイン・ホームおよびアプリケーション・ホームには、推奨される特定の場所があります。
図2-3に推奨するディレクトリ構造を示します。
システムでベースの場所(Oracleベース)を決めます(/home/oracle
など)。このベースの場所から、product
ディレクトリおよびconfig
ディレクトリの2つの別々のブランチを作成します。product
ディレクトリには、製品のバイナリ・ファイルとすべてのOracleホーム・ディレクトリを含めます。config
ディレクトリにはドメイン・データとアプリケーション・データを格納します。
Oracleホーム・ディレクトリには構成データを保存しないようにすることをお薦めします。製品を別のメジャー・リリースにアップグレードする場合は、バイナリ・ファイル用にOracleホームを作成する必要があります。また、構成データは、Oracleホーム内のバイナリ・ファイルからアクセスできる場所に置く必要があります。
このドキュメント全体の例を通じて、/home/oracle/product
ディレクトリ(Oracleホーム)と/home/oracle/config
ディレクトリ(アプリケーション・データと構成データ)を使用していますが、これらのディレクトリはご使用のシステムの実際のディレクトリに読み替えてください。
Oracleホーム・ディレクトリについて
Oracle Fusion Middleware製品をインストールする場合は、Oracleホーム・ディレクトリを使用する必要があります。
このディレクトリは、同じマシンにインストールされた複数のFusion Middleware製品で使用される共通ファイルのリポジトリです。これらのファイルは、Fusion Middlewareをシステムで正しく動作させることを保証します。これらによって、インストール時の製品間の依存関係のチェックが容易になります。このためOracleホーム・ディレクトリは、システムにインストールされるすべてのOracle Fusion Middleware製品の中心的なサポート・ディレクトリとみなすことができます。
Oracleホーム・ディレクトリは、Fusion MiddlewareドキュメントでORACLE_HOMEと呼ばれています。
Oracleホームの考慮事項
Oracleホーム・ディレクトリを作成してOracle Fusion Middleware製品をインストールするときには、次の点に注意してください。
-
Oracleホーム・ディレクトリの名前に空白を含めないでください。Oracleホーム・ディレクトリのパスに空白が含まれていると、エラー・メッセージが表示されます。
-
単一のOracleホーム・ディレクトリには、Oracle Fusion Middlewareの各製品に1つのインスタンスのみインストールできます。異なるバージョンの製品を同じマシンにインストールするには、それぞれのバージョンを専用のOracleホーム・ディレクトリに格納する必要があります。
単一のOracleホームに複数の異なる製品をインストールすることもできますが、Oracleホームには各製品で1つのバージョンのみをインストールできます。
複数のホーム・ディレクトリ
ほとんどの場合、Oracleホームは1つで十分ですが、複数のOracleホーム・ディレクトリを作成する場合もあります。たとえば次の場合に、複数のOracleホーム・ディレクトリを作成する必要があります。
-
それぞれ製品のスタックが別々の開発と本番環境を別々に管理する場合。2つのディレクトリを使用するこのにより、準備ができるまで本番環境を変更せずに、開発環境を更新できるようになります。
-
2つのバージョンのFusion Middleware製品を同時に保持する場合。たとえば製品の既存のバージョンを残したまま新しいバージョンをインストールする場合。この場合、製品の各バージョンを専用のOracleホーム・ディレクトリにインストールする必要があります。
-
相互に互換性のない複数の製品をインストールする必要があります。相互運用性および互換性の理解 のOracle Fusion Middlewareの相互運用性および互換性を参照してください。
ノート:
複数のOracleホーム・ディレクトリを作成する場合は、各製品の構成段階で重複しないポート範囲を指定する必要があります。ドメイン・ホーム・ディレクトリについて
ドメイン・ホームは、構成するドメインが作成されるディレクトリです。
デフォルトのドメイン・ホームの場所は、ORACLE_HOME/user_projects/domains/domain_name
です。ただし、このデフォルトの場所を使用しないことをお薦めします。ドメイン・ホームは、Oracleホーム・ディレクトリの外部に置きます(たとえば、/home/oracle/config/domains
)。config
ディレクトリには、ドメインとアプリケーションのデータが含まれている必要があります。新規インストール、パッチの適用およびその他の操作によって、ORACLE_HOMEのみが更新され、ドメインの構成は更新されないように、ドメイン専用のディレクトリをお薦めします。
推奨ディレクトリ構造とドメイン・ホームの場所については、「推奨ディレクトリ構造について」を参照してください。
Fusion Middlewareドキュメントで、ドメイン・ホーム・ディレクトリはDOMAIN_HOMEと呼ばれ、ドメイン名を含むそれ以下のすべてのフォルダが含まれます。たとえば、ドメイン名がexampledomain
で、/home/oracle/config/domains
ディレクトリにドメイン・データを配置する場合、ドキュメントでのDOMAIN_HOMEは/home/oracle/config/domains/exampledomain
を指します。
アプリケーション・ホーム・ディレクトリについて
アプリケーション・ホームは、構成するドメインのアプリケーションが作成されるディレクトリです。
デフォルトのアプリケーション・ホームの場所は、ORACLE_HOME/user_projects/applications/domain_name
です。ただし、アプリケーション・ホームをOracleホーム・ディレクトリ外に置くことをお薦めします。製品を別のメジャー・リリースにアップグレードする場合は、バイナリ・ファイル用にOracleホームを作成する必要があります。
推奨ディレクトリ構造およびアプリケーション・ホームの配置の詳細は、「推奨ディレクトリ構造について」を参照してください。
Fusion Middlewareドキュメントでは、アプリケーション・ホーム・ディレクトリのことをAPPLICATION_HOME
と呼び、ドメイン名を含むそれ以下のすべてのフォルダが含まれます。たとえば、ドメインexampledomain
という名前を付けて、/home/oracle/config/applications
ディレクトリにアプリケーション・データを置いた場合、ドキュメントでは/home/oracle/config/applications/exampledomain
を示すためにAPPLICATION_HOME
を使用します。
同じドメインへの複数の製品のインストール
1つのドメインに複数の製品をインストールして構成するには、2つの方法があります。これは、ドメインの拡張とも呼ばれます。
-
方法1
スキーマの作成やドメイン内の全サーバーの起動によるドメイン構成の成功の確認も含めて、製品Aのインストールと構成を行います。
これは、Fusion Middlewareライブラリのすべてのインストール・ガイドで使用される方法です。製品の数に応じて、必要なだけこの手順を繰り返すことができます。この方法では、一度に1つの製品を検証し、製品を段階的に追加することができます。
製品Aと同じドメインに製品Bをインストールするには:
-
新しい製品を追加する間、すべてのサーバーを停止して、ドメインが更新されないようにします。
『Oracle Fusion Middlewareの管理』のOracle Fusion Middlewareの起動と停止に関する項を参照してください。
-
製品Bについて、必要なスキーマの作成など、インストレーション・ガイドの手順に従います。
-
構成ウィザードを実行してドメインを構成します。
構成中、構成ウィザードはインストールされているコンポーネントを自動的に検出し、製品Bを含めるように既存の製品Aドメインを拡張するオプションを提供します。
-
-
方法2
必要なすべての製品をインストールしてから、すべての製品のスキーマを作成します。スキーマの作成後、必要な製品テンプレートを使用してドメインを構成してから、すべてのサーバーを起動します。
この方法で複数の製品のドメインを作成すると方法1より若干高速になる場合がありますが、Fusion Middlewareライブラリのインストール・ガイドには、この方法でのドメイン作成についての具体的な手順は示されていません。
関連項目:
-
WebLogicドメインを更新するには、構成ウィザードによるWebLogicドメインの作成のWebLogicドメインの更新を参照してください。
-
他のOracle Fusion Middlewareの前のバージョン、Oracleまたはサードパーティ製品と動作するOracle Fusion Middleware製品の機能に関する重要な情報は、『相互運用性および互換性の理解』のOracle Fusion Middlewareの相互運用性および互換性を参照してください。
共有記憶域の準備
Oracle Fusion Middlewareでは、1つのOracleホームから複数のWebLogic Serverドメインを構成できます。これにより、共有ボリューム上の1つの場所にOracleホームをインストールしたり、複数のホストをインストールするためにOracleホストを再利用したりすることもできます。
ご使用の環境で共有記憶域を使用する場合は、詳細について高可用性ガイドの共有記憶域の使用に関する説明を参照してください。
Managed File Transfer特有の構成要件の詳細は、Oracle Managed File Transferの使用の高可用性プロパティを参照してください。
Oracle Fusion MiddlewareのインストールのためのJDK要件について
ほとんどのFusion Middleware製品は、.jar
ファイル形式で配布されます。これらの配布にJDKは含まれていません。.jar
配布インストーラを実行するには、動作保証されたJDKがシステムにインストールされている必要があります。
JDKがOracleホームの外部にインストールされていることを確認してください。Oracleホームの下にJDKをインストールすると、将来タスクを実行しようとしたときに、問題が発生する可能性があります。Oracle Universal Installerは、Oracleホーム・ディレクトリが空であるかどうかを検証し、空のディレクトリが指定されるまで、インストールを進めません。JDKのインストールは、/home/oracle/products/jdk
ディレクトリに配置することをお薦めします。
プラットフォーム固有のディストリビューションには、.bin
(Linuxオペレーティング・システム用)または.exe
(Windowsオペレーティング・システム用)インストーラが含まれます。その場合は、プラットフォーム固有のJDKがディストリビューションに含まれており、JDKを別途インストールする必要はありません。ただし、認定されたJDKのバージョンによっては、より新しいバージョンにそのJDKをアップグレードする必要があります。
Oracle Fusion MiddlewareのOracle Fusion Middlewareでサポートされるシステム構成のページで動作保証情報を参照し、必要なJDKバージョンを必ず確認してください。
必要なJDKをダウンロードするには、次のURLにアクセスしてJava SE JDKをダウンロードします。
http://www.oracle.com/technetwork/java/javase/downloads/index.html
Oracle Fusion Middlewareのインストールのためのデータベース要件について
多くのOracle Fusion Middleware製品は、構成の前にデータベース・スキーマが必要です。このようなスキーマをインストールできるデータベースがない場合は、動作保証されたデータベースをインストールして構成する必要があります。
オペレーティング・システムで動作保証されているデータベースを調べるには、Oracle Technology Network (OTN)のOracle Fusion Middlewareのサポートされるシステム構成ページで、ご使用のリリース向けの動作保証情報のドキュメントを参照してください。
スキーマ作成用にデータベースが適切に構成されていることを確認するには、Oracle Fusion Middlewareのシステム要件と仕様ドキュメントのリポジトリ作成ユーティリティの要件に関する項を参照してください。
データベースが正しく構成されたら、Repository Creation Utility(RCU)を使用してデータベースに製品スキーマを作成する必要があります。このツールはOracle Fusion Middleware製品のOracleホームに用意されています。『リポジトリ作成ユーティリティによるスキーマの作成』のリポジトリ作成ユーティリティに関する項を参照してください。
SOA Suiteスキーマに必要なカスタム変数について
Oracle SOA Suiteのスキーマをインストールするときに、2つのカスタム変数の設定を求めるプロンプトが表示されます。この変数は、該当するスキーマがデータベースに作成される方法に影響します。
これらの変数は、次の各項でさらに詳しく説明します。
データベース・プロファイル・カスタム変数について
リポジトリ作成ユーティリティ(RCU)の「カスタム変数」画面にある、データベース・プロファイル・カスタム変数を使用すると、SOAインフラストラクチャ・スキーマをインストールするデータベースに関する予測サイズまたはプロファイルを確認できます。
Oracle SOA Suite構成に必要なデータベースのサイズを推定する場合は、『Oracle SOA SuiteおよびOracle Business Process Management Suiteの管理』のデータベース増加管理戦略の開発に関する項に記載された情報を考慮に入れてください。
データベース・プロファイルとして「SMALL」または「MEDIUM」と入力すると、スキーマの作成時に、RCUは特別なアクションを実行します。「SMALL」と「MEDIUM」オプションは、情報提供の目的にのみ入力する必要があります。
データベース・プロファイルとして「LARGE」を入力すると、RCUは、間隔パーティション化というOracleデータベースの機能を使用して、SOAインフラストラクチャ・スキーマを作成します。間隔パーティション化により、多数のコンポジット・アプリケーションを処理する必要がある場合に、データベースの効率が向上します。「LARGE」データベース・プロファイルを選択すると、RCUは、Oracle SOA Suiteの削除スクリプトとガイドラインでサポートされる方法で、間隔パーティション化した表を作成します。
データベースのパーティション化に関する詳細は、Oracle Database VLDBおよびパーティション化ガイドで、次の内容に関する項を参照してください。
ノート:
パーティション化機能を使用できるのは、Oracle DatabaseでOracle Partitioningオプションを購入した場合のみです。
製品ディストリビューションについて
Oracle Fusion Middleware Infrastructureディストリビューションを使用して、Oracle WebLogic ServerソフトウェアおよびOracle Java Required Files (JRF)ソフトウェアを含む初期Oracle B2Bドメインを作成します。
Oracle JRFソフトウェアは、次のものから構成されています。
-
Oracle Web Services Manager。
-
Oracle Application Development Framework (Oracle ADF)
-
Oracle Enterprise Manager Fusion Middleware Control。
-
リポジトリ作成ユーティリティ(RCU)
-
Oracle Fusion Middleware製品をサポートするために必要な、その他のライブラリとテクノロジ
- Oracle Fusion Middleware InfrastructureのインストールOracle Fusion Middleware Infrastructureのインストール方法の詳細は、『Oracle Fusion Middleware Infrastructureのインストールと構成』のInfrastructureソフトウェアのインストールに関する項を参照してください。
ノート:
パブリック・インターネットのクラウド・データ・ソースにアクセスする場合、プロキシ・サーバー経由の接続はサポートされていないため、直接ネットワーク接続が必要です。
製品の配布の入手
Oracle Fusion Middleware InfrastructureおよびOracle B2Bディストリビューションはオラクル社の技術リソースで入手できます。
Oracle Fusion Middleware InfrastructureおよびOracle B2Bのインストールを準備するには:
-
コマンドラインで
java -version
と入力し、動作保証されたJDKがシステムにインストールされていることを確認します。14c (14.1.2.0.0)では、動作保証されたJDKは17.0.12以降です。 -
Oracle Fusion Middleware InfrastructureおよびOracle B2Bソフトウェアを検索してダウンロードします。
Oracle Fusion Middlewareのインストールのプランニングの製品ディストリビューションの入手を参照してください。
製品評価のディストリビューションを入手するには、「Oracle Software Delivery Cloud」ページを参照してください。
ソフトウェアのインストールおよび構成の準備が完了したら、「Oracle B2Bソフトウェアのインストール」を参照してください。
インストール・アーカイブ・ファイルのデジタル署名と整合性の検証
インストール・アーカイブ・ファイルは、ご使用の環境へのパッケージのデプロイ前にパッケージの整合性を保証するために、Oracle証明書を使用してデジタル署名されています。
Javaユーティリティjarsigner
を使用して、インストール・アーカイブ・ファイルの整合性を検証します。インストール・ファイルを展開する前にインストール・アーカイブ・ファイルの整合性を検証できます。
クイック検証
インストール・アーカイブ・ファイルをすばやく検証するには、-verify
オプションを指定してjarsigner
コマンドを使用します:
- インストール・アーカイブ・ファイルをダウンロードしたディレクトリに移動します。
-
次のコマンドを実行してインストール・アーカイブ・ファイルを確認します:
jarsigner -verify installation_archive_file
たとえば、Oracle Fusion Middleware Infrastructureアーカイブを確認するには:
jarsigner -verify fmw_14.1.2.0.0_infrastructure.jar
jar verified.
詳細な証明書情報
詳細な証明書情報が必要な場合は、-verbose:summary
および-certs
を-verify
オプションとともに使用します。
- インストール・アーカイブ・ファイルをダウンロードしたディレクトリに移動します。
-
次のコマンドを実行してインストール・アーカイブ・ファイルを確認します:
jarsigner -verify -verbose:summary -certs installation_archive_file
たとえば、Oracle Fusion Middleware Infrastructureイメージを確認するには:
jarsigner -verify -verbose:summary -certs fmw_14.1.2.0.0_infrastructure.jar
出力は、次のようなものです。
2237119 Fri Dec 6 07:02:30 UTC 2023 META-INF/MANIFEST.MF >>> Signer X.509, CN="Oracle America, Inc.", O="Oracle America, Inc.", L=Redwood City, ST=California, C=US [ Signature algorithm: SHA256withRSA, 3072-bit key [certificate is valid from 12/19/24 12:00 AM to 12/19/25 11:59 PM] X.509, CN=DigiCert Trusted G4 Code Signing RSA4096 SHA384 2021 CA1, O="DigiCert, Inc.", C=US [ Signature algorithm: SHA384withRSA, 4096-bit key [certificate is valid from 4/29/24 12:00 AM to 4/28/36 11:59 PM] X.509, CN=DigiCert Trusted Root G4, O=DigiCert Inc, C=US [ Signature algorithm: SHA384withRSA, 4096-bit key [trusted certificate] >>> TSA X.509, CN=DigiCert Timestamp 2024 - 2, O=DigiCert, C=US [ Signature algorithm: SHA256withRSA, 4096-bit key [certificate is valid from 9/21/24 12:00 AM to 11/21/33 11:59 PM] X.509, CN=DigiCert Trusted G4 RSA4096 SHA256 TimeStamping CA, O="DigiCert, Inc.", C=US [ Signature algorithm: SHA256withRSA, 4096-bit key [certificate is valid from 3/23/24 12:00 AM to 3/22/37 11:59 PM] X.509, CN=DigiCert Trusted Root G4, O=DigiCert Inc, C=US [ Signature algorithm: SHA384withRSA, 4096-bit key [certificate is valid from 8/1/24 12:00 AM to 11/9/31 11:59 PM] 2237281 Fri Feb 17 07:02:32 UTC 2024 META-INF/ORACLE_C.SF (and 1 more) (Signature related entries) 0 Fri Feb 17 05:41:24 UTC 2023 OPatch/ (and 1897 more) (Directory entries) 2977 Tue Dec 20 08:02:16 UTC 2024 OPatch/README.txt (and 20199 more) [entry was signed on 2/17/24 7:02 AM] >>> Signer X.509, CN="Oracle America, Inc.", O="Oracle America, Inc.", L=Redwood City, ST=California, C=US [ Signature algorithm: SHA256withRSA, 3072-bit key [certificate is valid from 8/19/24 12:00 AM to 8/19/25 11:59 PM] X.509, CN=DigiCert Trusted G4 Code Signing RSA4096 SHA384 2021 CA1, O="DigiCert, Inc.", C=US [ Signature algorithm: SHA384withRSA, 4096-bit key [certificate is valid from 4/29/24 12:00 AM to 4/28/36 11:59 PM] X.509, CN=DigiCert Trusted Root G4, O=DigiCert Inc, C=US [ Signature algorithm: SHA384withRSA, 4096-bit key [trusted certificate] >>> TSA X.509, CN=DigiCert Timestamp 2024 - 2, O=DigiCert, C=US [ Signature algorithm: SHA256withRSA, 4096-bit key [certificate is valid from 9/21/24 12:00 AM to 11/21/33 11:59 PM] X.509, CN=DigiCert Trusted G4 RSA4096 SHA256 TimeStamping CA, O="DigiCert, Inc.", C=US [ Signature algorithm: SHA256withRSA, 4096-bit key [certificate is valid from 3/23/24 12:00 AM to 3/22/37 11:59 PM] X.509, CN=DigiCert Trusted Root G4, O=DigiCert Inc, C=US [ Signature algorithm: SHA384withRSA, 4096-bit key [certificate is valid from 8/1/24 12:00 AM to 11/9/31 11:59 PM] s = signature was verified m = entry is listed in manifest k = at least one certificate was found in keystore i = at least one certificate was found in identity scope - Signed by "CN="Oracle America, Inc.", O="Oracle America, Inc.", L=Redwood City, ST=California, C=US" Digest algorithm: SHA-256 Signature algorithm: SHA256withRSA, 3072-bit key Timestamped by "CN=DigiCert Timestamp 2024 - 2, O=DigiCert, C=US" on Fri Feb 17 07:02:33 UTC 2024 Timestamp digest algorithm: SHA-256 Timestamp signature algorithm: SHA256withRSA, 4096-bit key jar verified. The signer certificate will expire on 2025-12-19. The timestamp will expire on 2031-11-09.