Oracle® Fusion Middleware

Oracle HTTP Serverの管理

12c (12.2.1.1)

E77379-02(原本部品番号:E76214-02)

2016年7月

このドキュメントでは、静的なページ、動的なページおよびアプリケーションをWeb経由でホストするフレームワークとして、Oracle HTTP Serverを構成および使用する方法について説明します。

Oracle Fusion Middleware Oracle HTTP Serverの管理, 12c (12.2.1.1)

E77379-02

Copyright © 2015, 2016, Oracle and/or its affiliates. All rights reserved.

原本著者: Tom Pfaeffle

原本協力者: Kevin Clark、M.D. Ibrahim、Brunda Karanam、Prabhat Kishore、Sriram Natarajan、Mike Rumph、Ken Vincent、Asha Yaranga

このソフトウェアおよび関連ドキュメントの使用と開示は、ライセンス契約の制約条件に従うものとし、知的財産に関する法律により保護されています。ライセンス契約で明示的に許諾されている場合もしくは法律によって認められている場合を除き、形式、手段に関係なく、いかなる部分も使用、複写、複製、翻訳、放送、修正、ライセンス供与、送信、配布、発表、実行、公開または表示することはできません。このソフトウェアのリバース・エンジニアリング、逆アセンブル、逆コンパイルは互換性のために法律によって規定されている場合を除き、禁止されています。

ここに記載された情報は予告なしに変更される場合があります。また、誤りが無いことの保証はいたしかねます。誤りを見つけた場合は、オラクル社までご連絡ください。

このソフトウェアまたは関連ドキュメントを、米国政府機関もしくは米国政府機関に代わってこのソフトウェアまたは関連ドキュメントをライセンスされた者に提供する場合は、次の通知が適用されます。

U.S. GOVERNMENT END USERS: Oracle programs, including any operating system, integrated software, any programs installed on the hardware, and/or documentation, delivered to U.S. Government end users are "commercial computer software" pursuant to the applicable Federal Acquisition Regulation and agency-specific supplemental regulations.As such, use, duplication, disclosure, modification, and adaptation of the programs, including any operating system, integrated software, any programs installed on the hardware, and/or documentation, shall be subject to license terms and license restrictions applicable to the programs.No other rights are granted to the U.S. Government.

このソフトウェアもしくはハードウェアは様々な情報管理アプリケーションでの一般的な使用のために開発されたものです。このソフトウェアもしくはハードウェアは、危険が伴うアプリケーション(人的傷害を発生させる可能性があるアプリケーションを含む)への用途を目的として開発されていません。このソフトウェアもしくはハードウェアを危険が伴うアプリケーションで使用する際、安全に使用するために、適切な安全装置、バックアップ、冗長性(redundancy)、その他の対策を講じることは使用者の責任となります。このソフトウェアもしくはハードウェアを危険が伴うアプリケーションで使用したことに起因して損害が発生しても、オラクル社およびその関連会社は一切の責任を負いかねます。

OracleおよびJavaはOracle Corporationおよびその関連企業の登録商標です。その他の名称は、それぞれの所有者の商標または登録商標です。

Intel、Intel Xeonは、Intel Corporationの商標または登録商標です。すべてのSPARCの商標はライセンスをもとに使用し、SPARC International, Inc.の商標または登録商標です。AMD、Opteron、AMDロゴ、AMD Opteronロゴは、Advanced Micro Devices, Inc.の商標または登録商標です。UNIXは、The Open Groupの登録商標です。

このソフトウェアまたはハードウェア、そしてドキュメントは、第三者のコンテンツ、製品、サービスへのアクセス、あるいはそれらに関する情報を提供することがあります。適用されるお客様とOracle Corporationとの間の契約に別段の定めがある場合を除いて、Oracle Corporationおよびその関連会社は、第三者のコンテンツ、製品、サービスに関して一切の責任を負わず、いかなる保証もいたしません。適用されるお客様とOracle Corporationとの間の契約に定めがある場合を除いて、Oracle Corporationおよびその関連会社は、第三者のコンテンツ、製品、サービスへのアクセスまたは使用によって損失、費用、あるいは損害が発生しても一切の責任を負いかねます。

目次

タイトルおよび著作権情報

はじめに

- 対象読者

- ドキュメントのアクセシビリティについて

- 関連ドキュメント

- 表記規則

Oracle HTTP Server 12c (12.2.1.x)の新機能

- 12c (12.2.1.1)での新機能と変更された機能

- 12c (12.2.1)での新機能と変更された機能

- 12c (12.2.1)の新機能

- Apache httpd 2.4で使用可能な新しい機能および変更された機能

- 新しい操作モード—Restricted-JRF

- 新規モジュール

- iPlanetのOracle HTTP Serverへの移行

- 信頼フラグ

- Oracle WebLogic Serverプロキシのモニタリング

- Oracle WebLogic Serverプロキシ・プラグインのマルチテナントおよびパーティションのサポート

- 12c (12.2.1)での重要な更新

- 新しい暗号

- モジュールの削除

- mod_perlの置換え

- mod_fastcgi/mod_cgiの置換え

- mod_plsqlの置換え

- カスタムWLSTコマンドの名前の変更

- 新しいWLSTコマンド

- createOHSTestDomain (ohs_createTestDomain)カスタムWLSTコマンドの削除

- アップグレードのその他の注意

- 削除された機能

第I部 Oracle HTTP Serverの理解

1 Oracle HTTP Serverの概要

- Oracle HTTP Serverとは

- Oracle HTTP Server 12c (12.2.1)のトポロジ

- Oracle HTTP Serverの主要機能

- Restricted-JRFモード

- Oracle WebLogic Serverプロキシ・プラグイン(mod_wl_ohs)

- CGIおよびFast CGIプロトコル(mod_proxy_fcgi)

- セキュリティ機能

- Oracle Secure Sockets Layer (mod_ossl)

- セキュリティ:Secure Sockets Layerによる暗号化

- セキュリティ: WebGateを使用したシングル・サインオン

- URLリライティングとプロキシ・サーバーの機能

- ドメイン・タイプ

- WebLogic Serverドメイン(Full-JRFモード)

- WebLogic Serverドメイン(Restricted-JRFモード)

- スタンドアロン・ドメイン

- Oracle HTTP Serverのディレクトリ構造の理解

- 構成ファイルの理解

- ステージングおよびランタイムの構成ディレクトリ

- Oracle HTTP Serverの構成ファイル

- Oracle HTTP Server構成ファイルの変更

- 以前のリリースのOracle HTTP Serverからのアップグレード

- Oracle HTTP Serverのサポート

2 Oracle HTTP Serverモジュールの理解

- オラクル社が開発したOracle HTTP Server用のモジュール

- mod_certheadersモジュール—リバース・プロキシの有効化

- mod_contextモジュール—ECIDの作成または伝播

- mod_dmsモジュール—DMSデータへのアクセスの有効化

- mod_odlモジュール—ODLへのアクセスの有効化

- mod_ora_audit—認証および認可の監査のサポート

- mod_osslモジュール—暗号(SSL)の有効化」

- mod_webgateモジュール—シングル・サインオンの有効化

- mod_wl_ohsモジュール—Oracle WebLogic Serverへのプロキシ・リクエスト

- Oracle HTTP Server内のApache HTTP Serverおよびサード・パーティのモジュール

3 Oracle HTTP Server管理ツールの理解

- Fusion Middleware Controlを使用したOracle HTTP Serverの管理

- Fusion Middleware Controlへのアクセス

- Oracle HTTP Serverのホームページへのアクセス

- Oracle HTTP Serverのホームページの理解

- Fusion Middleware Controlを使用した構成ファイルの編集

- WLSTを使用したOracle HTTP Serverの管理

- Oracle HTTP Server固有のWLSTコマンド

- スタンドアロン環境でのWLSTの使用方法

第II部 Oracle HTTP Serverの管理

4 Oracle HTTP Serverの実行

- 開始する前に

- OHSインスタンスの作成

- WebLogic ServerドメインでのOracle HTTP Serverインスタンスの作成

- WLSTを使用したインスタンスの作成

- インスタンスの作成

- インスタンスのプロビジョニングについて

- スタンドアロン・ドメインでのOracle HTTP Serverインスタンスの作成

- 基本的なOracle HTTP Serverタスクの実行

- WLSTコマンドの使用について

- PIDファイルの理解

- Oracle HTTP Serverインスタンスの起動

- Fusion Middleware Controlを使用したOracle HTTP Serverインスタンスの起動

- WLSTを使用したOracle HTTP Serverインスタンスの起動

- コマンド行を使用したOracle HTTP Serverインスタンスの起動

- ノード・マネージャのパスワードの格納

- 特権ポートでのOracle HTTP Serverインスタンスの起動(UNIXのみ)

- 別のユーザーとしてのOracle HTTP Serverインスタンスの起動(UNIXのみ)

- Oracle HTTP Serverインスタンスの停止

- Fusion Middleware Controlを使用したOracle HTTP Serverインスタンスの停止

- WLSTを使用したOracle HTTP Serverインスタンスの停止

- コマンド・ラインからのOracle HTTP Serverインスタンスの停止

- Oracle HTTP Serverインスタンスの再起動

- Fusion Middleware Controlを使用したOracle HTTP Serverインスタンスの再起動

- WLSTを使用したOracle HTTP Serverインスタンスの再起動

- 実行中のOracle HTTP Serverインスタンスのステータスの確認

- Fusion Middleware Controlを使用したサーバー・ステータスの確認

- WLSTを使用したサーバー・ステータスの確認

- Oracle HTTP Serverインスタンスの削除

- WebLogic ServerドメインでのOracle HTTP Serverインスタンスの削除

- WLSTを使用したインスタンスの削除

- インスタンスの削除

- スタンドアロン・ドメインからのOracle HTTP Serverインスタンスの削除

- デフォルトのノード・マネージャのポート番号の変更

- WLSTを使用したデフォルトのノード・マネージャのポートの変更

- Oracle WebLogic Server管理コンソールを使用したデフォルトのノード・マネージャのポートの変更

- Oracle HTTP Serverのリモート管理

- リモート環境の設定

- リモート環境のホスト要件

- タスク1: ホスト1での拡張ドメインの設定

- タスク2: ホスト1でのドメインの圧縮

- タスク3: ホスト2でのドメインの解凍

- タスク4: Oracle HTTP Serverのリモート実行

5 Oracle HTTP Serverの操作

- 構成ファイルの編集について

- スタンドアロン・ドメイン用の構成ファイルの編集

- WebLogic Serverドメイン用の構成ファイルの編集

- サーバー・プロパティの指定

- Fusion Middleware Controlを使用したサーバー・プロパティの指定

- httpd.confファイルの編集によるサーバー・プロパティの指定

- Oracle HTTP Serverインスタンスの構成

- Secure Sockets Layerの構成

- スタンドアロン・モードでのSecure Sockets Layerの構成

- SSLの構成

- タスク1: 実際のウォレットの作成

- タスク2: (オプション)構成のカスタマイズ

- 基本SSL構成の例

- サーバー側でのSSLVerifyClientの指定

- クライアントによる証明書を使用した強制的な認証

- クライアントによる特定のURLに対する強制的な認証

- 特定のURLに対するクライアントの認可

- 強力な暗号およびCAクライアント証明書またはBasic認証を使用したクライアントの許可

- Oracle ServerとOracle WebLogic Serverとの間のSSLの有効化

- WLSTを使用したキーストアのOracle HTTP Serverインスタンスへのエクスポート

- WLSTを使用したアップグレード後のウォレットのKSSデータベースへのインポート

- WLSTを使用したOracle HTTP Serverインスタンスのキーストアとの関連付け

- Fusion Middleware Controlを使用したMIME設定の構成

- MIMEタイプの構成

- MIMEエンコーディングの構成

- MIME言語の構成

- mod_proxy_fcgiの構成について

- Oracle WebLogic Serverプロキシ・プラグイン(mod_wl_ohs)の構成について

- mod_wl_ohsのSSLの構成

- 不要なコンテンツへのアクセス権の削除

- cgi-binセクションの編集

- Fancy Indexingセクションの編集

- 製品ドキュメント・セクションの編集

- apxsコマンドを使用した拡張モジュールのインストール

- Optionsメソッドの無効化

- 共有ファイルシステムでのOracle HTTP Serverコンポーネント構成の更新

- mod_securityモジュールの構成

- httpd.confファイルのmod_securityの構成

- mod_security.confファイルのmod_securityの構成

- サンプルmod_secuirity.confファイル

6 サーバー・プロセスの管理およびモニタリング

- Oracle HTTP Serverの処理モデル

- リクエスト処理モデル

- 単一ユニットの処理モデル

- サーバーのパフォーマンスのモニタリング

- Oracle HTTP Serverパフォーマンス・メトリック

- パフォーマンス・メトリックの表示

- Fusion Middleware Controlを使用したサーバー・メトリックの表示

- WLSTを使用したサーバー・メトリックの表示

- Oracle HTTP Serverのパフォーマンス・ディレクティブ

- パフォーマンス・ディレクティブの理解

- スタンドアロン・ドメインのMPMタイプの値の変更

- WebLogic Server管理対象ドメインのMPMタイプの値の変更

- Fusion Middleware Controlを使用したパフォーマンス・ディレクティブの構成

- Fusion Middleware Controlを使用したリクエスト構成の設定

- Fusion Middleware Controlを使用した接続構成の設定

- Fusion Middleware Controlを使用したプロセス構成の設定

- UNIXのプロセス・セキュリティの理解

7 接続の管理

- デフォルトのリスニング・ポート

- 管理ポートの定義

- ポート番号の使用状況の表示

- Fusion Middleware Controlを使用したポート番号の使用状況の表示

- WLSTを使用したポート番号の使用状況の表示

- ポートの管理

- Fusion Middleware Controlを使用したポートの作成

- Fusion Middleware Controlを使用したポートの編集

- スタンドアロン環境でのリスニング・ポートの無効化

- 仮想ホストの構成

- Fusion Middleware Controlを使用した仮想ホストの作成

- Fusion Middleware Controlを使用した仮想ホストの構成

8 Oracle HTTP Serverログの管理

- サーバー・ログの概要

- エラー・ログについて

- アクセス・ログについて

- ログ・ローテーションの構成

- 時間ベースとサイズベースのローテーションの構文と例

- Oracle HTTP Serverログの構成

- Fusion Middleware Controlを使用したエラー・ログの構成

- エラー・ログの形式および場所の構成

- エラー・ログ・レベルの構成

- エラー・ログのローテーション・ポリシーの構成

- Fusion Middleware Controlを使用したアクセス・ログの構成

- アクセス・ログ形式の構成

- アクセス・ログ・ファイルの構成

- ログ・ファイルの作成モードの構成(umask) (UNIX/Linuxのみ)

- スタンドアロン・ドメインでのOracle HTTP Serverインスタンス用のumaskの構成

- WebLogic Server管理対象ドメインでのOracle HTTP Serverインスタンス用のumaskの構成

- WLSTを使用したログ・レベルの構成

- Oracle HTTP Serverのログ・ディレクティブ

- Oracle Diagnostic Loggingディレクティブ

- OraLogMode

- OraLogDir

- OraLogSeverity

- OraLogRotationParams

- Apache HTTP Serverログ・ディレクティブ

- ErrorLog

- LogLevel

- LogFormat

- CustomLog

- Oracle HTTP Serverログの表示

- Fusion Middleware Controlを使用したログの表示

- WLSTを使用したログの表示

- テキスト・エディタでのログの表示

- ECID情報の記録

- ECID情報について

- ECID情報用エラー・ログの構成

- ECID情報用アクセス・ログの構成

- SSLリクエストの終了

- ロード・バランサでのSSLの停止について

- ロード・バランサでのSSLの停止

- Oracle HTTP ServerでのSSLの停止について

- Oracle HTTP ServerでSSLを停止

9 アプリケーション・セキュリティの管理

- Oracle HTTP Serverのセキュリティの概要

- ユーザーのクラスとその権限

- 保護対象のリソース

- 認証、認可およびアクセス制御

- アクセス制御

- ユーザーの認証および認可

- Apache HTTP Serverモジュールを使用したユーザーの認証

- WebGateを使用したユーザーの認証

- FMW監査フレームワークのサポート

- Fusion Middleware Controlを使用した監査ポリシーの管理

- SSLの実装

- グローバル・サーバーIDのサポート

- PKCS #11のサポート

- SSLとロギング

- mod_securityの使用

- 信頼フラグの使用

第III部 付録

A Oracle HTTP ServerのカスタムWLSTコマンド

- Oracle HTTP ServerのカスタムWLSTコマンドのヘルプ

- カスタムWLSTコマンドの名前の変更

- Oracle HTTP Serverのコマンド

- ohs_addAdminProperties

- ohs_addNMProperties

- ohs_createInstance

- ohs_deleteInstance

- ohs_exportKeyStore

- ohs_postUpgrade

- ohs_updateInstances

B mod_proxy_fcgiおよびmod_authnz_fcgiモジュールへの移行

- タスク1: htttpd.confファイルのLoadModuleディレクティブの置換え

- タスク2: mod_fastcgi構成ディレクティブのhtttpd.confファイルからの削除

- タスク3: mod_proxy_fcgiを外部FastCGIサーバーへのリバース・プロキシとして動作するように構成

- タスク4: 外部FastCGI Serverの設定

- タスク5: mod_authnz_fcgiをFastCGI認可プロバイダ・アプリケーションと連携するように設定します。

C よくある質問

- アプリケーション固有のエラー・ページはどのように作成しますか

- HTTPおよびHTTPSでは、どのタイプの仮想ホストがサポートされますか

- 異なる言語および文字セット・バージョンのドキュメントを使用できますか

- Oracle HTTP ServerにApache HTTP Serverセキュリティ・パッチを適用できますか

- Oracle HTTP ServerのApache HTTP Serverバージョンをアップグレードできますか

- Oracle HTTP Serverからの出力を圧縮できますか

- ファイアウォールおよびクラスタを介して機能するネームスペースはどのように作成しますか

- Webサイトのセキュリティを強化する方法

- REDIRECT_ERROR_NOTESが、「ファイルが見つかりません」というエラーに設定されていないのはなぜですか

- Webサーバー・ベンダーおよびバージョンに関する情報はどのように隠すことができますか

- apachectlまたは他のコマンドライン・ツールを使用してOHSを起動できますか

- ポート80でリスニングするOracle HTTP Serverをどのように構成しますか

- Oracle HTTP ServerでSSLを使用してリクエストをどのように停止しますか

- Oracle HTTP ServerでエンドツーエンドSSLをどのように構成しますか

- Oracle HTTP ServerはOracle WebLogic Serverのフロントエンドになれますか

- Oracle WebLogic Serverドメインとスタンドアロン・ドメインの違い

- Oracle HTTP Serverはレスポンス・データをキャッシュできますか

- 仮想サーバー固有のアクセス・ログをどのように構成しますか

D Oracle HTTP Serverのトラブルシューティング

- ポートの競合によりOracle HTTP Serverが起動できない

- 多数のhttpdプロセスによるシステムのオーバーロード

- 1024未満のポートでOracle HTTP Serverの起動時に発生する権限拒否

- ログ・ファイルを使用したエラーの特定

- リライト・ログ

- スクリプト・ログ

- エラー・ログ

- リモート・ホストでのOHSインスタンスの回復

- Oracle HTTP Serverのパフォーマンスの問題

- ネットワーク・ファイル・システムに置かれる特別なランタイム・ファイル

- ネットワーク・ファイル・システムでのUNIXソケット

- 低速なファイル・システムに置かれたDocumentRoot

- DMSの共有メモリーの不足

- 共有ファイル・システム上で生成されたインスタンスのパフォーマンスの問題

- AIXでノード・マネージャ12c (12.1.2) OHSがJava例外をスローする

E 構成ファイル

- httpd.confファイル

- ssl.confファイル

- admin.confファイル

- mod_wl_ohs.confファイル

- mime.typesファイル

- ohs.plugins.nodemanager.propertiesファイル

- magicファイル

- keystores/<wallet-directory>ファイル

- auditconfig.xmlファイル

- component-logs.xmlファイル

- component_events.xmlファイル

- その他の参照

F プロパティ・ファイル

- ohs_admin.propertiesファイル

- ohs_nm.propertiesファイル

- ohs.plugins.nodemanager.propertiesファイル

- クロスプラットフォーム・プロパティ

- 環境変数の構成プロパティ

- LinuxおよびUNIXで実行するOracle HTTP Serverインスタンス固有のプロパティ

G OHSモジュール・ディレクティブ

- mod_wl_ohsモジュールに関する注意

- mod_certheadersモジュール

- AddCertHeaderディレクティブ

- SimulateHttpsディレクティブ

- mod_osslモジュール

- SSLCARevocationFileディレクティブ

- SSLCARevocationPathディレクティブ

- SSLCipherSuiteディレクティブ

- SSLEngineディレクティブ

- SSLFIPSディレクティブ

- SSLHonorCipherOrderディレクティブ

- SSLInsecureRenegotiationディレクティブ

- SSLOptionsディレクティブ

- SSLProtocolディレクティブ

- SSLProxyCipherSuiteディレクティブ

- SSLProxyEngineディレクティブ

- SSLProxyProtocolディレクティブ

- SSLProxyWalletディレクティブ

- SSLRequireディレクティブ

- SSLRequireSSLディレクティブ

- SSLSessionCacheディレクティブ

- SSLSessionCacheTimeoutディレクティブ

- SSLTraceLogLevelディレクティブ

- SSLVerifyClientディレクティブ

- SSLWalletディレクティブ

はじめに

このマニュアルでは、Oracle HTTP Serverの管理方法(Oracle HTTP Serverの起動および停止方法を含む)、ネットワーク・コンポーネントの管理方法、リスニング・ポートの構成方法、およびモジュールを使用した基本機能の拡張方法について説明します。

対象読者

Oracle HTTP Server管理者ガイドは、アプリケーション・サーバー管理者、セキュリティ管理者およびアプリケーション・サーバーで使用されるデータベースの管理者を対象としています。このドキュメントは、読者がApache HTTP Serverについて十分に理解していることを前提としています。

特に他に記載のないかぎり、このドキュメントに収められている情報は、Oracle HTTP ServerがOracle WebLogic ServerおよびOracle Fusion Middleware Controlにインストールされている場合に適用できます。読者は、『Oracle Fusion Middlewareコンセプトの理解』および『Oracle Fusion Middlewareの管理』で説明されているOracle Fusion Middlewareの主要な概念について精通しているものと想定されています。

スタンドアロン・モードでのOracle HTTP Serverのインストールの詳細は、『Oracle HTTP Serverのインストールと構成』を参照してください。

ドキュメントのアクセシビリティについて

Oracleのアクセシビリティについての詳細情報は、Oracle Accessibility ProgramのWebサイト(http://www.oracle.com/pls/topic/lookup?ctx=acc&id=docacc)を参照してください。

Oracleサポートへのアクセス

サポートをご購入のOracleのお客様は、My Oracle Supportにアクセスして電子サポートを受けることができます。詳細情報はhttp://www.oracle.com/pls/topic/lookup?ctx=acc&id=infoか、聴覚に障害のあるお客様はhttp://www.oracle.com/pls/topic/lookup?ctx=acc&id=trsを参照してください。

関連ドキュメント

詳細は、Oracle Fusion Middleware 12c (12.2.1)ドキュメンテーション・セットの次のドキュメントを参照してください。

- Oracle Fusion Middlewareの理解

- Oracle Fusion Middlewareの管理

- パフォーマンスのチューニング

- 高可用性ガイド

- Oracle WebLogic Serverプロキシ・プラグイン12.2.1の使用

- このライブラリに含まれるApacheドキュメント参照: http://httpd.apache.org/docs/2.4/

注意:

このガイドをPDF版またはハード・コピー形式でご利用いただく場合、HTML形式でのみのご提供となるサードパーティのドキュメントを参照できません。文中で参照されているサードパーティのドキュメントをご利用いただくためには、このガイドのHTML版をご利用のうえ、文中のハイパーリンクをクリックしてください。

表記規則

このドキュメントでは次の表記規則を使用します。

規則

意味

太字

太字は、操作に関連するGraphical User Interface要素、または本文中で定義されている用語および用語集に記載されている用語を示します。

イタリック体

イタリックは、ユーザーが特定の値を指定するプレースホルダ変数を示します。

固定幅フォント

固定幅フォントは、段落内のコマンド、URL、サンプル内のコード、画面に表示されるテキスト、または入力するテキストを示します。

Oracle HTTP Server 12c (12.2.1.x)の新機能

次のトピックでは、Oracle HTTP Serverの新機能と変更された機能について、およびこのマニュアルに記載されるその他の重要な変更について紹介し、詳細情報へのリンクを提供します。

12c (12.2.1.1)での新機能と変更された機能

最新のリリースには、新機能または重要な更新はありません。

12c (12.2.1)での新機能と変更された機能

この項には次の情報が含まれます:

- 12c (12.2.1)での新機能

- 12c (12.2.1)での重要な更新

12c (12.2.1)での新機能

この項では、Oracle HTTP Serverの現在のリリースに追加された機能について説明します。

- Apache httpd 2.4で使用可能な新しい機能および変更された機能

- 新しい操作モード—Restricted-JRF

- 新規モジュール

- iPlanetのOracle HTTP Serverへの移行

- 信頼フラグ

- Oracle WebLogic Serverプロキシのモニタリング

- Oracle WebLogic Serverプロキシ・プラグインのマルチテナントおよびパーティションのサポート

Apache httpd 2.4で使用可能な新しい機能および変更された機能

このリリースでは、Oracle HTTP Serverコア・ランタイムはApache httpd 2.4のリリースに基づいています。多くの新しい機能がそのリリースに追加されていますが、このドキュメントの範囲外です。Apache 2.4およびその機能の詳細は、次のURLを参照してください。

- http://httpd.apache.org/docs/2.4/

- http://httpd.apache.org/docs/2.4/new_features_2_4.html

Apache 2.4での以前のリリースからの重大な変更の詳細は、次を参照してください

- http://httpd.apache.org/docs/2.4/upgrading.html

- http://httpd.apache.org/docs/2.4/mod/mpm_winnt.html

新しい操作モード—Restricted-JRF

以前の12cリリースでは、Weblogic ServerドメインのOracle HTTP Serverのインストールには、データベースへの接続が必要です(11gでは必要ありません)。これは「フル・ドメイン」モードと呼ばれます。現在のリリースでは、「Restricted-JRF」と呼ばれる、Oracle HTTP Server用の新しいインストールおよび操作モードが導入されました。このモードでは、データベースが存在している必要がありません。フル・ドメイン・モードのOracle HTTP Serverで使用可能なすべての機能は、コンポーネント間ワイヤリングを除き、Restricted-JRFモードでも使用可能です。

Restrictedモードでは、顧客はOHSサーバーのライフサイクルを管理でき、WebLogic Managementフレームワーク(WLSTおよびFusion Middleware Control)を使用することで、追加のデータベースの依存関係なしで構成管理を処理できます。この機能により、カスタマには、WebLogic Management Frameworkを介してOHSファーム全体を管理する機能が提供されます。この機能の詳細は、Restricted-JRFモードを参照してください。

新規モジュール

次にOracle HTTP Serverの現在のリリースに追加された新しいモジュールを示します。

- mod_proxy_fcgi—このモジュールはmod_proxyモジュールに対するFastCGIサポートを提供します。mod_proxy_fcgiモジュールはmod_proxyモジュールのサービスを必要とし、FastCGIプロトコルのサポートを提供します。mod_proxy_fcgiの構成についておよびmod_proxy_fcgiおよびmod_authnz_fcgiモジュールへの移行を参照してください。

- mod_mpm_event (event MPM)—このモジュールはworker MPMのバリアントで、アクティブな処理との接続にのみスレッドを消費します。EventはLinuxシステム用12c (12.2.1)で使用されるデフォルトのMPMです。MPMタイプと環境に応じたMPMタイプの変更方法の詳細は、パフォーマンス・ディレクティブの理解を参照してください。

- Apache 2.4でのその他の新しいモジュール。Oracle HTTP Serverモジュールの理解を参照してください。

iPlanetのOracle HTTP Serverへの移行

現在のリリースでは、iPlanet Web Server (iWS)からOracle HTTP Serverへの移行パスが定義されています。この移行パスについては、次のURLで参照可能なiPlanet Web ServerからOracle HTTP Server 11gへの移行のマスター・ノート(Doc ID 1536893.1)で説明しています。

https://support.oracle.com

このドキュメントはリリース11g以降のバージョンのOracle HTTP Serverに適用されます。

信頼フラグ

現在のリリースではOracle HTTP Serverの信頼フラグのサポートが追加されました。信頼フラグを使用すると、SSL証明書に割り当てられた適切なロールによる、証明書チェーンの検証やパスの構築などの操作が簡単に実行できます。詳細は、信頼フラグの使用を参照してください。

Oracle WebLogic Serverプロキシのモニタリング

現在のリリースではOracle HTTP Serverのパフォーマンスのモニタリングのサポートが追加されました。パフォーマンス・メトリックはOracle WebLogic Serverプロキシ・プラグインに特有で、そこではリクエストがバックエンドのWebLogicサーバーにプロキシされます。

メトリックはOracle Dynamic Monitoring Service (DMS)を介して提供され、それによりOracle Fusion Middlewareのコンポーネントは、Fusion Middleware Controlなどの管理ツールに、コンポーネントのパフォーマンス、状態および進行中の動作に関するデータを提供できます。

『Oracle WebLogic Serverプロキシ・プラグイン12.2.1の使用』のOracle WebLogic Serverプロキシ・プラグインのパフォーマンス・メトリックの理解に関する項を参照してください。

Oracle WebLogic Serverプロキシ・プラグインのマルチテナントおよびパーティションのサポート

現在のリリースでは、Oracle HTTP ServerはOracle WebLogic Server-MT (マルチテナント)のフロントエンドとなることができるようになりました。詳細は、『Oracle WebLogic Serverプロキシ・プラグイン12.2.1の使用』のパーティションの操作に関する項を参照してください。

12c (12.2.1)での重要な更新

この項では、Oracle HTTP Serverの以前のバージョンから大幅に更新された機能について説明します。次に、これらの機能を示します。

- 新しい暗号

- モジュールの削除

- mod_perlの置換え

- mod_plsqlの置換え

- カスタムWLSTコマンドの名前の変更

- createOHSTestDomain (ohs_createTestDomain)カスタムWLSTコマンドの削除

- アップグレードのその他の注意

新しい暗号

TLSセキュリティ・プロトコルで使用できる新しい暗号が現在のリリースに追加されました。また、FIPS 140で使用できる暗号のリストも拡張されました。詳細は、SSLCipherSuiteディレクティブおよびSSLFIPSディレクティブを参照してください。

モジュールの削除

次のモジュールが削除されて、mod_proxy_fcgiおよびmod_authnz_fcgiモジュールに置き換わりました。

- mod_perl—このモジュールを使用すると管理者はOracle HTTP ServerでPerlスクリプトを実行できます。mod_perlの置換えを参照してください

- mod_fastcgi/mod_cgi—このモジュールを使用すると管理者はOracle HTTP Server上で従来のCGIスクリプトを効率的に実行できます。mod_fastcgi/mod_cgiの置換えを参照してください

- mod_plsql—このモジュールを使用すると、管理者は、PL/SQLパッケージとストアド・プロシージャから動的なWebページを作成可能となり、インターネットやイントラネットで動作可能な高速で自由度の高いアプリケーションの開発に理想的です。mod_plsqlの置換えを参照してください

mod_proxy_fcgiおよびmod_authnz_fcgiモジュールの詳細は、mod_proxy_fcgiおよびmod_authnz_fcgiモジュールへの移行を参照してください。

mod_perlの置換え

mod_perlモジュールはOracle HTTP Server 12c (12.2.1)リリースから削除されました。Oracle HTTP Server 12.1.3以前のリリースでmod_perlを使用していた場合、次の選択肢があります。

- PerlスクリプトをOracle HTTP Server 12c (12.2.1)内でCGIまたはFastCGIスクリプトのいずれかとして引き続き実行させることができます。
PerlスクリプトをCGIスクリプトとして実行する場合、CGIまたはFastCGIスクリプトとして実行するようにPerlスクリプトを変更する必要があります。

- CGIスクリプトを実行している場合、mod_cgidモジュール・ディレクティブの使用に切り替えます。ディレクティブは、次のURLの『Apacheモジュールmod_cgid』で説明されています。
http://httpd.apache.org/docs/2.4/mod/mod_cgid.html

- Oracle HTTP Server 12c (12.2.1)にPerlインタプリタが含まれていますが、それは製品内です。このインタプリタをFastCGI環境でPerlのホスティングに使用することはできません。固有のPerl環境を提供する必要があります。

mod_fastcgi/mod_cgiの置換え

mod_fastcgiおよびmod_cgiモジュールはOracle HTTP Server 12c (12.2.1)リリースから削除されました。mod_fastcgiの代替の実装が提供されています。既存のFastCGIスクリプトまたは構成がある場合、mod_proxy_fcgiおよびmod_authnz_fcgiモジュールへの移行に記載されている移行手順に従ってください。

CGIスクリプトを実行している場合、かわりにmod_cgidモジュール・ディレクティブを使用します。ディレクティブは、次のURLの『Apacheモジュールmod_cgid』で説明されています。

http://httpd.apache.org/docs/2.4/mod/mod_cgid.html

mod_plsqlの置換え

mod_plsqlモジュールはOracle HTTP Server 12c (12.2.1)リリースから削除されました。多くのOracleカスタマがOracle HTTP Serverとmod_plsqlを使用してOracle Application Express (Oracle APEX)を実行しており、それよりは少ないですがスタンドアロンPL/SQL Webページを実行しているカスタマもいます。

詳細は、次のURLのOracle Web Tier - 指示書 (ドキュメントID 1576588.1)を参照してください。

http://support.oracle.com

代替として、Oracle REST Data Services (以前のOracle APEXリスナー)を実装することをお薦めします。Oracle REST Data ServicesはJ2EEベースのサーブレッドで、Webベースの構成、拡張されたセキュリティおよびファイル・キャッシングを含む機能が強化されています。

Oracle REST Data ServicesはOracle Technology Networkのライセンス条件で提供される無料の製品です。サポートされている構成で実行するには、Oracle WebLogic Server、Oracle GlassfishまたはApache TomcatにORDSをインストールする必要があります。スタンドアロンJavaサーブレット(warファイル)の実行は、配布で提供され、本番環境ではサポートされません。開発およびテスト環境での使用のみを想定しています。

Oracle REST Data Servicesの詳細は、次のURLを参照してください。

http://www.oracle.com/technetwork/developer-tools/rest-data-services/overview/index.html

カスタムWLSTコマンドの名前の変更

使いやすさと識別のしやすさの向上のため、Oracle HTTP ServerのカスタムWLSTコマンドの名前が現在のリリースで変更されました。コマンド名に"OHS"が組み込まれるのではなく、コマンドに"ohs_"の接頭辞が付くようになりました。たとえば、createOHSInstanceコマンドはohs_createInstanceになりました。

古いコマンド名は非推奨であることを考慮する必要があります。これらは現在のリリースでWLSTにより許容されますが、使用を避ける必要があります。変更された古いカスタムWLSTコマンドの表および詳細は、変更されたカスタムWLSTコマンドの名前を参照してください。

新しいWLSTコマンド

現在のリリースではOracle HTTP Server用にこれらのカスタムWLSTコマンドが追加されました。これらのコマンドの詳細は、Oracle HTTP ServerのカスタムWLSTコマンドを参照してください。

コマンド

説明

ohs_exportKeyStore

キーストアを指定したOracle HTTP Serverインスタンスにエクスポートします。

ohs_postUpgrade

ドメイン内のすべてのOracle HTTP Serverインスタンスのウォレットの内容(以前のバージョンからアップグレードされたOracle HTTP Serverインスタンスに対して有効なもの)をKSSデータベースにインポートします。

ohs_updateInstances

Oracle HTTP Serverインスタンスが構成ウィザードを使用して作成された場合、KSSデータベースにキーストアを作成します。

createOHSTestDomain (ohs_createTestDomain)カスタムWLSTコマンドの削除

createOHSTestDomain (ohs_createTestDomain)カスタムWLSTコマンドが現在のリリースから削除されました。このコマンドは、Oracle HTTP Server 12.2.1でデータベースの依存関係を持たない構成ウィザードを使用する、ドメインの作成に対するRestricted-JRF (R-JRF)サポートが導入されたため、必要なくなりました。

アップグレードのその他の注意

Oracle HTTP Serverの現在のリリースはApache Server 2.4に基づきます。以前のリリースのOracle HTTP Serverを使用している場合、次の点に注意してください。

FilterProvider

mod_filterの下のFilterProviderディレクティブの構文はApache 2.4で変更されました。このディレクティブは手動でアップグレードする必要があります。詳細は、http://httpd.apache.org/docs/2.4/mod/mod_filter.htmlおよびhttp://httpd.apache.org/docs/2.4/upgrading.htmlを参照してください

認証およびアクセス制御

Apache 2.4では、認証およびアクセス制御の構成に重要な変更がありました。Oracle HTTP Server Upgrade Assistantは、認証およびアクセス制御ディレクティブを新しい構成スタイルにアップグレードしません。そのかわりに、Oracle HTTP Serverには古い構成との互換性を提供するmod_access_compatモジュールが含まれています。

認証およびアクセス制御の構成を手動でApache 2.4スタイルにアップグレードすることをお薦めします。詳細は次のURLを参照してください。http://httpd.apache.org/docs/2.4/upgrading.html#run-time

umask設定

Oracle HTTP Server 12c (12.2.1)以前では、オペレーティング・システム・レベルのumask設定はOracle HTTP Serverにも適用できました。Oracle HTTP Server 12c (12.2.1)では、新しいプロパティがohs.nodemanager.propertiesファイルに導入されてumask設定を指定します。デフォルトでは、0027の値が使用されます。詳細は、ログ・ファイルの作成モードの構成(umask) (UNIX/Linuxのみ)を参照してください。

削除された機能

ODL-XMLファイル形式のサポートが削除されました。

第I部 Oracle HTTP Serverの理解

この部では、Oracle HTTP Serverの基本的および概念的な情報を提供します。次の章が含まれます。

- Oracle HTTP Serverの概要

- Oracle HTTP Serverモジュールの理解

- Oracle HTTP Server管理ツールの理解

1 Oracle HTTP Serverの概要

この章では、Oracle HTTP Server (OHS)を紹介します。この章では、OHSの主要な機能およびOracle Fusion MiddlewareのWeb層での位置関係について説明し、OHSのディレクトリ構造、OHSの構成ファイルおよびOHSのサポートの受け方についても説明します。

Oracle HTTP Serverは、Oracle Fusion MiddlewareのWebサーバー・コンポーネントです。Oracle WebLogic Server用のリスナーと、静的および動的なページおよびアプリケーションをホストするフレームワークがWeb経由で提供されます。

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

- Oracle HTTP Serverとは

- Oracle HTTP Server 12c (12.2.1)のトポロジ

- Oracle HTTP Serverの主要機能

- ドメイン・タイプ

- Oracle HTTP Serverのディレクトリ構造の理解

- 構成ファイルの理解

- 以前のリリースのOracle HTTP Serverからのアップグレード

- Oracle HTTP Serverのサポート

Oracle HTTP Serverとは

Oracle HTTP Server 12c (12.2.1)は、Apache HTTP Server 2.4(以降のバージョンではクリティカルなバグを修正済)のインフラストラクチャに基づいており、Oracleで特別に開発されたモジュールを含みます。シングル・サインオン、クラスタ化されたデプロイ、および高可用性の機能により、Oracle HTTP Serverの動作は拡張されます。Oracle HTTP Serverには、クライアント・リクエストを処理するための次のコンポーネントが含まれます。

- HTTPリスナー: 受信リクエストを処理し、これを適切な処理ユーティリティにルーティングします。

- モジュール(mod): Oracle HTTP Serverの基本機能を実装および拡張します。標準的なApache HTTP Serverモジュールの多くは、Oracle HTTP Serverに組み込まれています。また、Oracle HTTP Serverとその他のOracle Fusion Middlewareコンポーネントとの統合をサポートするために、Oracle Fusion Middlewareに固有のモジュールもいくつか組み込まれています。

- Perlインタプリタ: Oracle HTTP Serverが、mod_proxy_fcgiを使用する永続的なPerlランタイム環境へのfcgiプロトコルを介するリバース・プロキシとして設定できるようにします。
Oracle HTTP ServerにPerlインタプリタは含まれていますが、それは製品内です。このインタプリタをFastCGI環境でPerlのホスティングに使用することはできません。固有のPerl環境を提供する必要があります。

- Oracle WebLogic Serverプロキシ・プラグイン: Oracle HTTP ServerをWebLogic Serverおよびその他のFusion Middlewareベースのアプリケーションのフロントエンドとして機能させることができます。

Oracle HTTP Serverでは、開発者は次のような様々な言語およびテクノロジでサイトをプログラミングできます。

- Perl (mod_proxy_fcgi、CGIおよびFastCGIを介して)

- CおよびC++ (mod_proxy_fcgi、CGIおよびFastCGIを介して)

- Java、RubyおよびPython (mod_proxy_fcgi、CGIおよびFastCGIを介して)

Oracle HTTP Serverは、フォワード・プロキシ・サーバーにも、リバース・プロキシ・サーバーにもなります。リバース・プロキシを使用すると、様々なサーバーから提供されたコンテンツを、1つのサーバーから提供されたように表示できます。

注意:

Fusion Middlewareの概念の詳細は、Oracle Fusion Middlewareの理解を参照してください。

Oracle HTTP Server 12c (12.2.1)のトポロジ

Oracle HTTP Serverは、WebLogic Management Frameworkを活用して、Oracle HTTP Server、Oracle WebLogic Serverおよびその他のFusion Middlewareスタックを管理するための簡単で一貫性のある分散環境を提供します。これは、組込みのOracle WebLogic Serverプロキシ・プラグイン12c (12.2.1)を活用することで、静的コンテンツをホストすることによって、HTTPのフロントエンドとして機能して、動的コンテンツのリクエストをWebLogic管理対象サーバーにルーティングします。このような場合、要件によって、Oracle HTTP Serverを実装する複数の方法があります。表1-1に、主な実装またはトポロジを示します。

表1-1 Oracle HTTP Serverのトポロジ

トポロジ

説明

詳細の参照先

スタンドアロン・ドメインでのOracle HTTP Serverの標準インストール・トポロジ

このトポロジは、Oracle WebLogic Serverドメインのトポロジに似ていますが、管理サーバーまたは管理対象サーバーを提供しません。これは、Oracle HTTP Server実装がFusion Middlewareドメインの前面になることを望まない場合で、Fusion Middleware Controlが提供する管理機能を必要としない場合に便利です。このトポロジについては、図1-1に示します。

このトポロジを取得するには、Oracle HTTP Serverをスタンドアロン・モードでインストールします。PackまたはUnPackコマンドを使用して、Oracle HTTP Serverのコロケート・モードと組み合せることができます。

詳細は、『Oracle HTTP Serverのインストールと構成』のスタンドアロン・ドメインでのOracle HTTP Serverの標準インストール・トポロジに関する項を参照してください。

WebLogic ServerドメインでのOracle HTTP Serverの標準インストール・トポロジ(Restricted-JRF)

このトポロジは、バックアップ用データベースを必要としない点を除き、Full-JRFトポロジと似ています。Restricted-JRFモードは、コンポーネント間ワイヤリングができない点を除き、Full-JRFモードのすべての機能を提供します。

このトポロジを取得するには、コロケート・モードでOracle HTTP Serverをインストールしてから、このドメインをプロビジョニングするためのOracle HTTP Server Restricted-JRFドメイン・テンプレートを選択します。このトポロジは、コンポーネント間ワイヤリングを除くほとんどのユースケースを処理します。

詳細は、『Oracle HTTP Serverのインストールと構成』のWebLogic ServerドメインでのOracle HTTP Serverの標準インストール・トポロジに関する項を参照してください

WebLogic ServerドメインでのOracle HTTP Serverの標準インストール・トポロジ(Full-JRF)

このトポロジは、Fusion Middleware ControlおよびWebLogic Management Frameworkを使用して拡張された管理機能を提供します。複数の物理マシンにWebLogic Serverドメインをスケールアウトすることができ、管理サーバーによる一元管理が可能になります。図1-2に、このトポロジを示します。

このトポロジを取得するには、コロケート・モードでOracle HTTP Serverをインストールしてから、このドメインをプロビジョニングするためのOracle HTTP Server Full-JRFドメイン・テンプレートを選択します。このトポロジは、バックエンドにデータベースを必要とし、コンポーネント間ワイヤリングをサポートできることに注意してください。

詳細は、『Oracle HTTP Serverのインストールと構成』のWebLogic ServerドメインでのOracle HTTP Serverの標準インストール・トポロジに関する項を参照してください。

図1-1に、スタンドアロン・ドメインにおけるOracle HTTP Serverの標準的なインストールのトポロジを示します。

図1-1 スタンドアロン・ドメインでのOHSの標準インストール・トポロジ

図1-2に、Web層のOracle HTTP Server用に2つの別個のホストがあり、FMW Controlにより管理される、高可用性の実装を示します。

図1-2 WebLogic ServerドメインでのOHSの標準インストール・トポロジ

Oracle HTTP Serverの主要機能

次の項では、Oracle HTTP Serverの主要機能の一部について説明します。

- Restricted-JRFモード

- Oracle WebLogic Serverプロキシ・プラグイン(mod_wl_ohs)

- CGIおよびFast CGIプロトコル(mod_proxy_fcgi)

- セキュリティ機能

- URLリライティングとプロキシ・サーバーの機能

Restricted-JRFモード

Oracle HTTP Server12c (12.2.1)ではRestricted-JRFモードが導入されています。Oracle HTTP ServerをOracle WebLogic Serverドメインにこのモードでインストールすることを選択した場合、外部データベースへの接続は必要ありません。コンポーネント間ワイヤリングを除き、このドキュメントで説明しているFusion MiddleWare ControlおよびWLSTを介するOracle HTTP Server機能のすべては引き続き使用可能です。

コンポーネント間ワイヤリングのサポートがないということは次のような意味です。

- Fusion MiddleWare Controlのメニュー・オプションに変更があります。コンポーネント間ワイヤリングをサポートする一部のメニュー・オプションが削除または無効化されます。

- データベースの依存関係は完全に削除されます。

関連項目:

olink:JISEC『Oracle Fusion Middlewareの管理』の連携するコンポーネントのワイヤリングに関する項。

Restricted-JRFドメイン内のOracle HTTP Serverインスタンスのキーおよび証明書の管理は、引き続きキーストア・サービス(KSS)です。Restricted-JRFドメインでは、KSSのデータベースの永続性はファイルの永続性に置き換わります。エンド・ユーザーにとっては、キーまたは証明書を管理する基本KSS APIに視覚的変更はありません。

Oracle HTTP Serverは、Restricted-JRFおよびFull-JRFモードの両方の複雑な仮想サーバー構成用の複数のOracleウォレットを引き続きサポートします。

Oracle WebLogic Serverプロキシ・プラグイン(mod_wl_ohs)

Oracle WebLogic Serverプロキシ・プラグイン(mod_wl_ohs)により、Oracle HTTP Server12c (12.2.1)からOracle WebLogic Serverへのリクエストをプロキシ処理できます。このプラグインによって、Oracle WebLogic Serverが動的機能を必要とするリクエストを処理可能となり、Oracle HTTPサーバーのインストールが拡張されます。すなわち、通常、HTTPサーバーがHTMLページのような静的なページを提供する場合にはプラグインを使用しますが、Oracle WebLogic ServerはHTTP ServletsやJavaサーバー・ページ(JSP)のような動的なページを提供します。

Oracle WebLogic Server Proxyプロキシ・プラグインの詳細は、『Oracle WebLogic Serverプロキシ・プラグイン12.2.1の使用』のOracle HTTP Serverのプラグインの構成に関する項を参照してください

CGIおよびFast CGIプロトコル(mod_proxy_fcgi)

CGIプログラムは、通常、Webアプリケーションのプログラミングに使用されます。Oracle HTTP Serverは、mod_proxy_fcgiモジュールを使用して、リクエストのライフサイクルよりも長くアクティブに保つメカニズムを提供することでプログラムを強化します。

mod_proxy_fcgiモジュールは非推奨のmod_fastcgiモジュールを置き換えるものです。mod_proxy_fcgiモジュールはmod_proxyモジュールのサービスを必要とし、FastCGIプロトコルのサポートを提供します。

mod_proxy_fcgiモジュールの構成の詳細は、mod_proxy_fcgiの構成についてを参照してください。mod_fastcgiモジュールからmod_proxy_fcgiモジュールへの移行の詳細は、mod_proxy_fcgiおよびmod_authnz_fcgiモジュールへの移行を参照してください。

セキュリティ機能

Oracle HTTP Serverは数々のセキュリティ機能を備えています。その中で主な機能は次のものです。

- Oracle Secure Sockets Layer (mod_ossl)

- セキュリティ:Secure Sockets Layerによる暗号化

- セキュリティ: WebGateを使用したシングル・サインオン

Oracle Secure Sockets Layer (mod_ossl)

mod_osslモジュール(Oracle Databaseで使用されるOracle Secure Sockets Layer (SSL)の実装)によって、Oracle HTTP Serverでの強力な暗号化が可能になります。これは、サーバーでのSSLの使用を可能にするOracle HTTP Serverへのプラグインで、OpenSSLモジュール(mod_ssl)によく似ています。mod_osslモジュールはTLSバージョン1.0、1.1および1.2をサポートしています。

セキュリティ: Secure Sockets Layerによる暗号化

Webサイトを安全に運用するには、Secure Sockets Layer (SSL)が必要です。Oracle HTTP Serverでは、業界標準の特許アルゴリズムに基づいたSSL暗号化をサポートしています。SSLは、一般的にサポートされるインターネット・ブラウザとシームレスに連動します。セキュリティ機能は次のとおりです。

- SSLハードウェア・アクセラレーション・サポートでは、SSL用に専用ハードウェアを使用します。ハードウェア暗号化は、ソフトウェア暗号化より高速です。

- ディレクトリ別変数セキュリティでは、ディレクトリをそれぞれ異なる暗号化強度で保護できます。

- Oracle HTTP ServerとOracle WebLogic Serverは、暗号化と認証の両方を提供するためにHTTPプロトコルを使用して通信します。また、クライアントがブラウザを使用せずにWebLogic Serverサービスにアクセスできるように、T3またはIIOPプロトコルに対してHTTPトンネリングを有効化することもできます。

関連項目:

Oracle Platform Security Servicesによるアプリケーションの保護

セキュリティ: WebGateを使用したシングル・サインオン

WebGateによって、Oracle HTTP Serverのシングル・サインオン(SSO)が可能になります。WebGateは受信リクエストを調べて、リクエストされたリソースが保護されているかどうかを判断し、保護されている場合は、ユーザーのセッション情報を取得します。WebGateを使用すると、Oracle HTTP ServerはSSO対応のパートナ・アプリケーションとなり、SSOを使用してユーザーを認証することが可能になり、Oracleシングル・サインオンを使用してユーザーのアイデンティティの取得ができるようになり、また、Oracle HTTP ServerからアクセスされるWebアプリケーションはユーザーのアイデンティティを使用することが可能になります。

関連項目:

Oracle Platform Security Servicesによるアプリケーションの保護

URLリライティングとプロキシ・サーバーの機能

アクティブなWebサイトでは、Webページが更新されるのは普通のことで、ディレクトリの内容は頻繁に入れ替わり、URLも変更される可能性があります。Oracle HTTP Serverでは、URLリライティングをサポートする組込みのエンジンによりこのような変化に容易に対応できるため、エンド・ユーザーはブックマークを変更せずに済みます。

また、Oracle HTTP Serverではリバース・プロキシ機能もサポートされるため、様々なサーバーにより提供されるコンテンツを1つのサーバーから簡単に表示できます。

ドメイン・タイプ

Oracle HTTP Serverは、Oracle WebLogic Serverと同じ場所に(WebLogic Serverドメインと呼ばれる)インストールすることも、Full-JRFまたはRestricted-JRFモードでインストールすることもできます。サーバーはスタンドアロン・ドメインとしてインストールすることもできます。どちらの環境を使用するかはサーバーの構成時に選択できます。スタンドアロン・ドメインでは一部の機能が使用できない点に注意してください。

- WebLogic Serverドメイン(Full-JRFモード)

- WebLogic Serverドメイン(Restricted-JRFモード)

- スタンドアロン・ドメイン

WebLogic Serverドメイン(Full-JRFモード)

Full-JRFモードのWebLogic Serverドメインには、WebLogic管理サーバー、0台以上のWebLogic管理対象サーバーおよび0個以上のシステム・コンポーネント・インスタンス(Oracle HTTP Serverインスタンスなど)が含まれます。このタイプのドメインは、システム全体に存在するFusion Middleware ControlおよびWebLogic Management Frameworkを介して拡張管理機能を提供します。WebLogic Serverドメインは、複数の物理マシンにまたがって設定でき、管理サーバーによって一元管理されます。これらのプロパティのために、WebLogic Serverドメインは、使用しているシステムのコンポーネントとJava EEコンポーネント間の最高の統合を提供します。

WebLogic ServerドメインではすべてのWebLogic Management Frameworkツールがサポートされています。

Fusion Middleware Controlは高度な管理機能を備えていますので、WebLogic Server Domainの使用をお薦めしますが、そのためには、Oracle HTTP Serverのインストール前に、Fusion Middlewareインフラストラクチャを完全にインストールする必要があります。

- WebLogic Server Domainのインストールの詳細は、『Oracle Fusion Middleware Infrastructureのインストールと構成』を参照してください。

- Fusion Middlewareインフラストラクチャの一部、あるいはスタンドアロン・コンポーネントとしてのOracle HTTP Serverのインストールの詳細は、『Oracle HTTP Serverのインストールと構成』を参照してください。

WebLogic Serverドメイン(Restricted-JRFモード)

Restricted-JRFモードのWebLogic Serverドメインは、外部データベースへの接続を定義しない点を除き、FullモードのWeblogic Serverドメインとアーキテクチャおよび機能が似ています。Restricted-JRFモードではデータベースの依存関係はありません。

バックアップ用のデータベースがないということは、コンポーネント間ワイヤリングがRestricted-JRFドメインのOracle HTTP Serverによりサポートされないことを意味します。これはFull-JRFとRestricted-JRFベース・ドメインの大きな違いです。

Full-JRFドメインと同様、Restricted-JRFドメイン内のOracle HTTP Serverインスタンスのキーおよび証明書の管理は、引き続きキーストア・サービス(KSS)です。Restricted-JRFドメインでは、KSSのデータベースの永続性はファイルの永続性に置き換わりましたが、エンド・ユーザーにとっては、キーおよび証明書を管理する基本KSS APIに視覚的変更はありません。

Full-JRFドメインと同様、Restricted-JRFドメインのOracle HTTP Serverは、複雑な仮想サーバー構成用の複数のOracleウォレットをサポートします。

スタンドアロン・ドメイン

スタンドアロン・ドメインはOracle HTTP Serverなどのシステム・コンポーネント用のコンテナです。これはOracle WebLogic Serverドメインと似たディレクトリ構造を持ちますが、管理サーバーまたは管理対象サーバーが含まれません。スタンドアロン・ドメインには、同一タイプのシステム・コンポーネント(Oracle HTTP Serverなど)、またはタイプの混在したシステム・コンポーネントの1つ以上のインスタンスが含まれます。

スタンドアロン・ドメインの場合、WebLogic Management Frameworkでは次のツールがサポートされています。

- ノード・マネージャ

- WebLogic Scripting Tool (WLST)コマンド(次を含む):

- Oracle HTTP Serverインスタンスを起動および停止する、nmStart()、nmKill()、nmSoftRestart()およびnmKill()。

- nmConnect(): ノード・マネージャへの接続

- nmLog(): ノード・マネージャのログ情報の取得

サポートされているWLSTノード・マネージャ・コマンドの完全なリストは、『WebLogic Server WLSTコマンド・リファレンス』のノード・マネージャ・コマンドに関する項を参照してください。

注意:

リモートのOracle HTTP Serverの1台が管理モードにあり、別の1台がリモート管理モードを有効化したスタンドアロンの場合、WLSTを使用してSSL構成などの管理タスクを実行できます。スタンドアロン・ドメインにおける通常のOracle HTTP Serverは、WebLogic Serverのノード・マネージャとしてのみ、そしてOracle HTTP Serverの起動/停止目的でのみ使用できます。これは、コマンドライン・スクリプトでも実行できます。

- 構成ウィザード

- 圧縮/解凍

一般的に、Oracle HTTP Server実装がWebLogic Serverドメインと一緒にインストールされることを望まない場合で、Fusion Middleware Controlが提供する管理機能を必要としない場合には、スタンドアロン・ドメインを使用します。Oracle HTTP ServerをDMZ(非武装地帯のことで内部ファイアウォールと外部ファイアウォールの間のゾーン)内で保持する場合で、ノード・マネージャで使用される管理ポートを開くことを望まない場合には、スタンドアロン・ドメインを使用しません。

Oracle HTTP Serverのディレクトリ構造の理解

Oracle HTTP ServerドメインはWebLogic Serverまたはスタンドアロンのいずれかです。インストールされている場合、各ドメインには、そのドメイン・タイプを実装するために必要なファイルが含まれている、それぞれ独自のディレクトリ構造があります。完全なファイル構造トポロジについては、『Oracle HTTP Serverのインストールと構成』のディレクトリ構造の理解に関する項を参照してください。

構成ファイルの理解

Oracle HTTP Serverの構成は、Apache HTTP Serverで使用されるものと同じようないくつかのタイプ(.confのような)の構成ファイルによって指定されます。この項では、構成ファイル・ディレクトリのレイアウト、ファイルの編集メカニズムおよびファイルそのものについての詳細を説明します。

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

- ステージングおよびランタイムの構成ディレクトリ

- Oracle HTTP Server構成ファイル

- Oracle HTTP Server構成ファイルの変更

ステージングおよびランタイムの構成ディレクトリ

ステージング・ディレクトリとランタイム・ディレクトリの2つの構成ディレクトリが各Oracle HTTP Serverインスタンスに関連します。

- ステージング・ディレクトリ
DOMAIN_HOME/config/fmwconfig/components/OHS/componentName

- ランタイム・ディレクトリ
DOMAIN_HOME/config/fmwconfig/components/OHS/instances/componentName

それぞれの構成ディレクトリには、完全なOracle HTTP Server構成(httpd.conf、admin.conf、auditconfig.xmlなど)が含まれます。

構成への変更はステージング・ディレクトリで行われます。これらの変更内容は、次の操作の間にランタイム・ディレクトリに自動的に伝搬されます。

注意:

ステージング・ディレクトリのファイルを手動で(Fusion Middleware ControlやWLSTを使用せずに)変更する前に管理サーバーを停止します。

- WebLogic Serverドメインの一部であるOracle HTTP Serverインスタンス
変更がFusion Middleware Control内からアクティブ化された後、または管理サーバーが初期化して、以前の変更をレプリケートする必要がある場合に、変更は管理対象Oracle HTTP Serverインスタンスを使用して、ノード上のランタイム・ディレクトリにレプリケートされます。動作時に、ノード・マネージャとの通信が切断されている場合、通信が復元された後でレプリケーションが実行されます。

- スタンドアロンOracle HTTP Serverインスタンス
起動、再起動または停止動作が開始されると、変更がランタイム・ディレクトリに同期されます。一部の変更は、ドメインの更新時にランタイム・ディレクトリに書き込まれることがありますが、それらの変更は同期時に最終的に決定されます。

ランタイム・ディレクトリ内の構成に対する変更は、レプリケーション時または同期時に失われます。

注意:

スタンドアロン・インスタンスが作成されると、デモ用のウォレットを含むキーストア・ディレクトリがランタイム・ディレクトリのみに作成されます。

インスタンス用に最初の新しいウォレットを作成する前に、ステージング・ディレクトリ内にキーストア・ディレクトリを作成する必要があります。

DOMAIN_HOME/config/fmwconfig/components/OHS/componentName/keystores

次に、そのキーストア・ディレクトリ内にウォレットを作成する必要があります。

Oracle HTTP Server構成ファイル

デフォルトのOracle HTTP Server構成には、構成ファイルで説明されているファイルが含まれます。

この構成にファイルを追加することができ、Includeディレクティブを使用してトップレベルの.confファイル(httpd.conf)に含めることができます。このディレクティブの使用方法の詳細は次のドキュメントにあるIncludeディレクティブに関する項を参照してください。

http://httpd.apache.org/docs/2.4/mod/core.html#include

デフォルトの構成にはIncludeディレクティブが存在し、構成内のmoduleconf/ディレクトリにすべての.confファイルが含まれます。

moduleconf/ディレクトリに格納されていない.confファイルについては、Includeディレクティブを既存の.confファイル(通常はhttpd.conf)に追加する必要があります。これは、新しい.confファイルを異なる構成スコープ(既存の仮想ホスト定義内など)に含める必要がある場合に必要になることがあります。

Oracle HTTP Server構成ファイルの変更

WebLogic Serverドメインの一部であるインスタンスの場合、Fusion Middleware Controlおよび管理インフラストラクチャはOracle HTTP Server構成を管理します。ステージング・ディレクトリ内での構成に対する直接編集は、Fusion Middleware Controlでの構成の変更などの後続の管理操作の後で上書きされる可能性があります。このようなインスタンスでは、直接編集は管理サーバーが停止時にのみ実行できます。管理サーバーがその後に起動されると、(起動または再起動によって)手動編集の結果が、管理対象インスタンスのノード上のランタイム・ディレクトリにレプリケートされます。詳細は、構成ファイルの編集についてを参照してください。

注意:

Oracle HTTP Server構成を管理するFusion Middleware Controlおよびその他のOracleソフトウェアは、同等の異なる形式でこれらのファイルを保存する可能性があります。ソフトウェアを使用して構成を変更した後に、複数の構成ファイルがリライトされる可能性があります。

Oracle HTTP Serverの以前のリリースからのアップグレード

「アップグレード・アシスタントを使用したアップグレード」の指示に従い、Fusion MiddlewareおよびOracle HTTP Serverを前のリリースから12c (12.2.1)にアップグレードします。

コロケートされたOracle HTTP Server (スタンドアロン・インストールではない)をアップグレードしている場合、アップグレード・アシスタントを完了した後で次の手動の手順を実行する必要があります。

1. アップグレードするドメインの管理サーバー(WebLogic)を起動します。次に例を示します

UNIX/Linux: ./startWebLogic.sh

Windows: startWebLogic.cmd

2. 12c (12.2.1)インストールのミドルウェア・ホームにあるバージョンのWLSTを起動します。次に例を示します。

LinuxまたはUNIX: $ORACLE_HOME/oracle_common/common/bin/wlst.sh

Windows: $ORACLE_HOME\oracle_common\common\bin\wlst.cmd

3. アップグレードするドメインの管理サーバーに接続します。次に例を示します。

> connect('loginID', 'password', '<adminHost>:<adminPort>')

4. ohs_postUpgrade()カスタムWLSTコマンドを実行します。次に例を示します。

> ohs_postUpgrade()

ohs_postUpgradeカスタムWLSTコマンドの詳細は、WLSTを使用したアップグレード後のウォレットのKSSデータベースへのインポートおよびohs_postUpgradeを参照してください。

Oracle HTTP Serverのサポート

オラクル社では、次に示すOracle HTTP Serverの機能および状態について、テクニカル・サポートを提供しています。

- Oracle製品に組み込まれているモジュール。Apache Software Foundationなどの他のソースから入手したモジュールはサポートされません。ただし、Oracle以外で提供されるモジュールが組み込まれている場合でも、Oracle HTTP Serverはサポートされます。報告された問題に、Oracle以外で提供されたモジュールが関係している疑いがある場合は、それらのモジュールを組み込まない状態で問題を再現するように依頼されることがあります。

- サポート対象のOracle HTTP Serverモジュールのみで構成されているOracle HTTP Server構成内で再現できる問題。

2 Oracle HTTP Serverモジュールの理解

この章では、Oracle HTTP Server (OHS)で使用されるオラクル社が開発したモジュール(つまりプラグイン)の概要について説明します。この章では、OHSで使用されるその他のすべてのApacheおよびサード・パーティ製のモジュールのリストについても説明します。

モジュール(mod)は、Oracle HTTP Serverの基本機能を拡張し、Oracle HTTP Serverとその他のOracle Fusion Middlewareコンポーネントとの統合をサポートします。

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

- オラクル社が開発したOracle HTTP Server用のモジュール

- Oracle HTTP Server内のApache HTTP Serverおよびサード・パーティのモジュール

オラクル社が開発したOracle HTTP Server用のモジュール

次の項では、Oracle HTTP Server用にオラクル社が特に開発したモジュールについて説明します。

- mod_certheadersモジュール—リバース・プロキシの有効化

- mod_contextモジュール—ECIDの作成または伝播

- mod_dmsモジュール—DMSデータへのアクセスの有効化

- mod_odlモジュール—ODLへのアクセスの有効化

- mod_ora_audit—認証および認可の監査のサポート

- mod_osslモジュール—暗号(SSL)の有効化

- mod_webgateモジュール—シングル・サインオンの有効化

- mod_wl_ohsモジュール—Oracle WebLogic Serverへのプロキシ・リクエスト

mod_certheadersモジュール—リバース・プロキシの有効化

mod_certheadersモジュールは、Oracle HTTP Serverの前でSecure Sockets Layer (SSL)接続が終了するリバース・プロキシが、SSL接続に関する情報(SSLクライアント証明書情報など)を、Oracle HTTP ServerおよびOracle HTTP Serverを介して動作しているアプリケーションに送信できるようにします。この情報は、HTTPヘッダーを使用してリバース・プロキシからOracle HTTP Serverに送信されます。その後、情報はヘッダーから標準CGI環境変数に送信されます。SSL接続がOracle HTTP Serverによって終了される場合は、mod_osslモジュールまたはmod_sslモジュールがこの環境変数に値を移入します。

mod_certheadersモジュールでは、特定のリクエストがHTTP経由で受信される場合も、HTTPSリクエストとして扱うことができます。これは、SimulateHttpsディレクティブを使用して実行されます。

SimulateHttpsは、自身が含まれるコンテナ(<VirtualHost>や<Location>など)を使用し、受信されたこのコンテナに対するすべてのリクエストを、リクエストで使用された実際のプロトコルに関係なく、HTTPS経由で受信されたものとして扱います。

mod_certheadersに使用できるディレクティブのリストおよび説明については、mod_certheadersモジュールを参照してください。

mod_contextモジュール—ECIDの作成または伝播

mod_contextモジュールは、Oracle HTTP Serverによって処理されるリクエストに対して、実行コンテキストID (ECID)を作成または伝播します。リクエストがOracle HTTP Serverに到達する前に、ECIDがリクエスト実行フローに作成されていた場合、mod_contextは、Oracle HTTP Server内のロギングに対してECIDを使用可能にし、WebLogic Serverなどの他のFusion Middlewareコンポーネントへの伝播にも使用可能にします。リクエストがOracle HTTP Serverに到達した時点で、ECIDが作成されていなかった場合、mod_contextはECIDを作成します。

mod_contextを構成することはできません。これにより、ECIDのLoadModuleディレクティブを持つサーバーへのロードが有効化され、このモジュールに対応するLoadModuleディレクティブを削除またはコメントアウトすることで無効化されます。問題の診断の助けになるように、常に有効にしておく必要があります。

mod_dmsモジュール—DMSデータへのアクセスの有効化

mod_dmsモジュールは、FMWインフラストラクチャにOHSのOracle Dynamic Monitoring Service (DMS)データへのアクセスを提供します。

関連項目:

パフォーマンスのチューニングのOracle Dynamic Monitoring Service。

mod_odlモジュール—ODLへのアクセスの有効化

mod_odlモジュールを使用すると、Oracle HTTP ServerからOracle Diagnostic Logging (ODL)にアクセスできます。ODLは、エラー・ログ・メッセージ生成用のOracle標準に準拠する形式で、テキストまたはXML形式のログにログ・メッセージを生成します。Oracle HTTP ServerはデフォルトではODLを使用します。

ODLには次の利点があります。

- 保存される診断情報の合計サイズを制限します。保存される情報のレベルを設定したり、ログ・ファイルおよびログ・ファイル・ディレクトリの最大サイズを指定できます。

- 指定サイズに達すると、古いセグメント・ファイルが削除され、新しいセグメント・ファイルが時系列で保存されます。

- コンポーネントがアクティブな状態で古い診断ログ・ファイルを削除でき、停止する必要がありません。

ログ・ファイルは、Fusion Middleware ControlまたはWLSTコマンドを使用して表示できます。また、ログ・ファイルをローカル・クライアントにダウンロードして、他のツール(テキスト・エディタおよびその他のファイル表示ユーティリティ)を使用して表示することもできます。

Oracle HTTP ServerでODLを使用する方法の詳細は、Oracle HTTP Serverログの管理を参照してください。

関連項目:

Oracle Fusion Middlewareの管理のログ・ファイルと診断データの管理に関する項

mod_ora_audit—認証および認可の監査のサポート

このモジュールはOraAuditEnableディレクティブを提供し、FMW共通監査フレームワークを使用した認証および認可の監査をサポートします。すでに監査のコードはOracle HTTP Serverバイナリ自体に統合されました。現在のリリースでは、これは別個のロード可能モジュールとして提供されます。詳細は、FMW監査フレームワークを参照してください。

mod_osslモジュール—暗号(SSL)の有効化

mod_osslモジュール(Oracle Databaseで使用されるOracle Secure Sockets Layer (SSL)の実装)によって、Oracle HTTP Serverでの強力な暗号化が可能になります。これは、サーバーでのSSLの使用を可能にするOracle HTTP Serverへのプラグインで、OpenSSLモジュール(mod_ssl)によく似ています。mod_osslモジュールは、TLSバージョン1, 1.1および1.2をサポートし、CerticomおよびRSAセキュリティ・テクノロジに基づいています。

Oracle HTTP Serverは米国連邦情報処理標準140番(FIPS 140)に準拠しており、正式なFIPS認証を受けた基底SSLライブラリのバージョンを使用しています。Oracle HTTP ServerのFIPS 140準拠の一部として、mod_osslプラグインにSSLFIPSディレクティブが含まれるようになりました。詳細は、SSLFIPSディレクティブを参照してください。

mod_sslモジュールはサポートされなくなりました。mod_sslからmod_osslへの移行およびテキスト証明書のOracleウォレットへの変換を可能にするツールが提供されています。

mod_osslモジュールには、次の機能があります。

- RSAまたはDES暗号化規格を使用した、クライアントとサーバー間の暗号化された通信

- MD5またはSHAチェックサム・アルゴリズムを使用した、クライアント/サーバー通信の整合性チェック。

- Oracleウォレットを使用した証明書管理

- mod_sslモジュールと完全に同じように実行される、複数のアクセス・チェックを使用したクライアントの認可。

mod_osslモジュールのディレクティブ

mod_osslモジュールで使用できるディレクティブのリストおよび説明は、mod_osslモジュールを参照してください。

注意:

詳細は、『Oracle Fusion Middlewareの管理』のWeb層のSSLの構成に関する項を参照してください。

mod_webgateモジュール—シングル・サインオンの有効化

mod_webgateモジュールによって、Oracle HTTP Serverのシングル・サインオン(SSO)が可能になります。WebGateは受信リクエストを調べて、リクエストされたリソースが保護されているかどうかを判断し、保護されている場合は、ユーザーのセッション情報を取得します。

詳細は、WebGateを使用したユーザーの認証およびセキュリティ: WebGateを使用したシングル・サインオンを参照してください。WebGateの構成の詳細は、Oracle HTTP Serverのインストールと構成のOracle Access ManagerのWebGateの構成を参照してください。

関連項目:

Oracle Platform Security Servicesによるアプリケーションの保護

mod_wl_ohsモジュール—Oracle WebLogic Serverへのプロキシ・リクエスト

Oracle HTTP Serverの主要機能であるmod_wl_ohsモジュールにより、Oracle HTTP Server 12c (12.2.1)からOracle WebLogic Serverへのリクエストをプロキシ処理できます。このモジュールは一般的にOracle WebLogic Serverプロキシ・プラグインと呼ばれます。このプラグインによって、Oracle WebLogic Serverが動的機能を必要とするリクエストを処理可能となり、Oracle HTTPサーバーのインストールが拡張されます。すなわち、通常、HTTPサーバーがHTMLページのような静的なページを提供する場合にはプラグインを使用しますが、Oracle WebLogic ServerはHTTP ServletsやJavaサーバー・ページ(JSP)のような動的なページを提供します。

mod_wl_ohsを構成する際の前提条件と手順の詳細は、『Oracle WebLogic Serverプロキシ・プラグイン12.2.1の使用』のOracle HTTP Serverのプラグインの構成に関する項を参照してください。このモジュール用のディレクティブは、前述のドキュメントのOracle WebLogic Serverプロキシ・プラグインのパラメータに関する項に示されています。

注意:

mod_wl_ohsは、Apache HTTP ServerからOracle WebLogic Serverへのリクエストをプロキシ処理するために使用できる、mod_wlプラグインに似ています。ただし、Apache HTTP Server用のmod_wlプラグインは別途ダウンロードしてインストールする必要があるのに対し、mod_wl_ohsプラグインはOracle HTTP Serverにバンドルされています。

Oracle HTTP Server内のApache HTTP Serverおよびサード・パーティのモジュール

Oracle HTTP Serverには、表2-1に示すApache HTTP Serverおよびサード・パーティのモジュールも即時利用可能な状態で組み込まれています。これらのモジュールは、オラクル社が開発したものではありません。

表2-1 Oracle HTTP Server内のApache HTTP Serverおよびサード・パーティのモジュール

モジュール

デフォルトで有効化?

詳細は、次の資料を参照してください。

mod_access_compat

いいえ

http://httpd.apache.org/docs/2.4/mod/mod_access_compat.html

mod_actions

○

http://httpd.apache.org/docs/2.4/mod/mod_actions.html

mod_alias

○

http://httpd.apache.org/docs/2.4/mod/mod_alias.html

mod_asis

○

http://httpd.apache.org/docs/2.4/mod/mod_asis.html

mod_auth_basic

○

http://httpd.apache.org/docs/2.4/mod/mod_auth_basic.html

mod_authn_anon

○

http://httpd.apache.org/docs/2.4/mod/mod_authn_anon.html

mod_authn_core

○

http://httpd.apache.org/docs/2.4/mod/mod_authn_core.html

mod_authn_file

○

http://httpd.apache.org/docs/2.4/mod/mod_authn_file.html

mod_authz_core

○

http://httpd.apache.org/docs/2.4/mod/mod_authz_core.html

mod_authnz_fcgi

いいえ

http://httpd.apache.org/docs/2.4/mod/mod_authnz_fcgi.html

mod_authz_groupfile

○

http://httpd.apache.org/docs/2.4/mod/mod_authz_groupfile.html

mod_authz_host

○

http://httpd.apache.org/docs/2.4/mod/mod_authz_host.html

mod_authz_owner

いいえ

http://httpd.apache.org/docs/2.4/mod/mod_authz_owner.html

mod_authz_user

○

http://httpd.apache.org/docs/2.4/mod/mod_authz_user.html

mod_autoindex

○

http://httpd.apache.org/docs/2.4/mod/mod_autoindex.html

mod_cache

いいえ

http://httpd.apache.org/docs/2.4/mod/mod_cache.html

mod_cache_disk

いいえ

http://httpd.apache.org/docs/2.4/mod/mod_cache_disk.html

mod_cern_meta

○

http://httpd.apache.org/docs/2.4/mod/mod_cern_meta.html

mod_cgi

○

http://httpd.apache.org/docs/2.4/mod/mod_cgi.html

mod_cgid (UNIXのみ)

○

http://httpd.apache.org/docs/2.4/mod/mod_cgid.html

mod_deflate

いいえ

http://httpd.apache.org/docs/2.4/mod/mod_deflate.html

mod_dir

○

http://httpd.apache.org/docs/2.4/mod/mod_dir.html

mod_dumpio

いいえ

http://httpd.apache.org/docs/2.4/mod/mod_dumpio.html

mod_env

○

http://httpd.apache.org/docs/2.4/mod/mod_env.html

mod_expires

○

http://httpd.apache.org/docs/2.4/mod/mod_expires.html

mod_file_cache

○

http://httpd.apache.org/docs/2.4/mod/mod_file_cache.html

mod_filter

いいえ

http://httpd.apache.org/docs/2.4/mod/mod_filter.html

注意: mod_filterの下のFilterProviderディレクティブの構文はApache 2.4で変更されました。このディレクティブは手動でアップグレードする必要があります。詳細は、http://httpd.apache.org/docs/2.4/upgrading.htmlを参照してください

mod_headers

○

http://httpd.apache.org/docs/2.4/mod/mod_headers.html

mod_imagemap

○

http://httpd.apache.org/docs/2.4/mod/mod_imagemap.html

mod_include

○

http://httpd.apache.org/docs/2.4/mod/mod_include.html

mod_info

○

http://httpd.apache.org/docs/2.4/mod/mod_info.html

mod_lbmethod_bybusyness

いいえ

http://httpd.apache.org/docs/2.4/mod/mod_lbmethod_bybusyness.html

mod_lbmethod_byrequests

いいえ

http://httpd.apache.org/docs/2.4/mod/mod_lbmethod_byrequests.html

mod_lbmethod_bytraffic

いいえ

http://httpd.apache.org/docs/2.4/mod/mod_lbmethod_bytraffic.html

mod_log_config

○

http://httpd.apache.org/docs/2.4/mod/mod_log_config.html

mod_log_forensic

○

http://httpd.apache.org/docs/2.4/mod/mod_log_forensic.html

mod_logio

いいえ

http://httpd.apache.org/docs/2.4/mod/mod_logio.html

mod_macro

いいえ

http://httpd.apache.org/docs/2.4/mod/mod_macro.html

mod_mime

○

http://httpd.apache.org/docs/2.4/mod/mod_mime.html

mod_mime_magic

○

http://httpd.apache.org/docs/2.4/mod/mod_mime_magic.html

mod_mpm_event

はい(Linuxのみ)

http://httpd.apache.org/docs/2.4/mod/event.html

mod_mpm_prefork

いいえ

http://httpd.apache.org/docs/2.4/mod/prefork.html

mod_mpm_winnt (Windowsのみ)

○

http://httpd.apache.org/docs/2.4/mod/mpm_winnt.html

mod_mpm_worker

はい(Windows以外およびLinux以外のプラットフォーム)

http://httpd.apache.org/docs/2.4/mod/worker.html

mod_negotiation

○

http://httpd.apache.org/docs/2.4/mod/mod_negotiation.html

mod_proxy

○

http://httpd.apache.org/docs/2.4/mod/mod_proxy.html

mod_proxy_balancer

○

http://httpd.apache.org/docs/2.4/mod/mod_proxy_balancer.html

mod_proxy_connect

○

http://httpd.apache.org/docs/2.4/mod/mod_proxy_connect.html

mod_proxy_fcgi

いいえ

http://httpd.apache.org/docs/2.4/mod/mod_proxy_fcgi.html

mod_proxy_ftp

○

http://httpd.apache.org/docs/2.4/mod/mod_proxy_ftp.html

mod_proxy_http

○

http://httpd.apache.org/docs/2.4/mod/mod_proxy_http.html

mod_remoteip

いいえ

http://httpd.apache.org/docs/2.4/mod/mod_remoteip.html

mod_reqtimeout

いいえ

http://httpd.apache.org/docs/2.4/mod/mod_reqtimeout.html

mod_rewrite

○

http://httpd.apache.org/docs/2.4/mod/mod_rewrite.html

mod_security2

いいえ

http://www.modsecurity.org/documentation/

また、mod_securityに関するOracle HTTP Server固有の情報については、httpd.confファイルのmod_securityの構成を参照してください。

mod_sed

いいえ

http://httpd.apache.org/docs/2.4/mod/mod_sed.html

mod_setenvif

○

http://httpd.apache.org/docs/2.4/mod/mod_setenvif.html

mod_slotmem_shm

○

http://httpd.apache.org/docs/2.4/mod/mod_slotmem_shm.html

mod_socache_shmcb

○

http://httpd.apache.org/docs/2.4/mod/mod_socache_shmcb.html

mod_speling

○

http://httpd.apache.org/docs/2.4/mod/mod_speling.html

mod_status

○

http://httpd.apache.org/docs/2.4/mod/mod_status.html

mod_substitute

いいえ

http://httpd.apache.org/docs/2.4/mod/mod_substitute.html

mod_unique_id

○

http://httpd.apache.org/docs/2.4/mod/mod_unique_id.html

mod_unixd

○

http://httpd.apache.org/docs/2.4/mod/mod_unixd.html

mod_userdir

○

http://httpd.apache.org/docs/2.4/mod/mod_userdir.html

mod_usertrack

○

http://httpd.apache.org/docs/2.4/mod/mod_usertrack.html

mod_version

○

http://httpd.apache.org/docs/2.4/mod/mod_version.html

mod_vhost_alias

○

http://httpd.apache.org/docs/2.4/mod/mod_vhost_alias.html

3 Oracle HTTP Server管理ツールの理解

この章では、Oracle HTTP Serverで使用可能な管理ツールについて説明します。Oracle HTTP Serverの管理、Fusion Middleware Controlへのアクセス方法、Oracle HTTP Serverのホーム・ページへのアクセス方法、およびWebLogic Scripting Tool (WLST)の使用方法が含まれます。

次の管理ツールがOracle HTTP Server用に提供されています。

- Oracle HTTP Serverインスタンスを作成および削除できる構成ウィザード。詳細は、『Oracle HTTP Serverのインストールと構成』を参照してください。

- Fusion Middleware Control(ブラウザベースの管理ツール)。詳細は、『Oracle Fusion Middlewareの管理』を参照してください。

- コマンドドリブンのスクリプト・ツールであるWebLogic Scripting Tool。詳細は、『WebLogic Scripting Toolの理解』を参照してください。

注意:

- Oracle HTTP Server実装で使用可能な管理ツールは、それをWebLogic Serverドメイン(FMWインフラストラクチャを使用)またはスタンドアロン・ドメイン内で構成したかどうかに依存します。詳細は、ドメイン・タイプを参照してください。

- Fusion Middleware ControlまたはWebLogic Scripting Tool (WLST)内にあるOracle HTTP Server MBeansは、Oracleの管理ツールを使用するために提供されています。このインタフェースは、予告なしに変更される場合があり、他の使用目的ではサポートされていません。

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

- Fusion Middleware Controlを使用したOracle HTTP Serverの管理

- WLSTを使用したOracle HTTP Serverの管理

Fusion Middleware Controlを使用したOracle HTTP Serverの管理

Oracle HTTP Serverを管理するための主要ツールは、Fusion Middleware Controlです。Fusion Middleware Controlは、Oracle Fusion Middleware環境を管理およびモニタリングするためのブラウザベースのツールです。この項では、Oracle Fusion Middleware Controlで実行できる基本的なOracle HTTP Serverの管理タスクを説明します。

- Fusion Middleware Controlへのアクセス

- Oracle HTTP Serverのホームページへのアクセス

- Oracle HTTP Serverのホームページの理解

- Fusion Middleware Controlを使用した構成ファイルの編集

関連項目:

Oracle Fusion Middlewareの管理

Fusion Middleware Controlへのアクセス

Fusion Middleware Controlを表示するには、Fusion Middleware ControlのURLを入力します。これには、WebLogic管理サーバー・ホストの名前と、インストール時にFusion Middleware Controlに割り当てたポート番号が含まれます。URLの形式は次のとおりです。

http://hostname.domain:port/em

最後のインストール画面で「保存」をクリックしてインストール情報を保存した場合、Fusion Middleware ControlのURLは、ディスクに書き込まれたファイルに含まれています。

1. WebブラウザでURLを入力して、Fusion Middleware Controlを表示します。次に例を示します。

http://host1.example.com:7001/em

「ようこそ」ページが表示されます。

2. Fusion Middleware Controlの管理者ユーザー名とパスワードを入力し、「ログイン」をクリックします。

管理者ユーザーのデフォルトのユーザー名は、weblogicです。このアカウントは、初めてFusion Middleware Controlにログインするときに使用できます。weblogicパスワードは、Fusion Middleware Controlのインストール中に指定したパスワードです。

Oracle HTTP Serverのホームページへのアクセス

ターゲット(WebLogic管理対象サーバーなど)やコンポーネント(Oracle HTTP Serverなど)を選択すると、コンテンツ・ペインにターゲットのホーム・ページが表示され、ページの一番上のコンテキスト・ペインにそのターゲットのメニューが表示されます。

Oracle HTTP Serverのホーム・ページおよびサーバー・メニューを表示するには、HTTP ServerフォルダからOracle HTTP Serverコンポーネントを選択します。ナビゲーション・ペインでOracle HTTP Serverのターゲットを右クリックすることで、「Oracle HTTP Server」メニューを表示することもできます。

Oracle HTTP Serverのホーム・ページの理解では、ターゲットのナビゲーション・ペインとOracle HTTP Serverのホームページについて説明します。

Oracle HTTP Serverのホームページの理解

Fusion Middleware ControlのOracle HTTP Serverのホームページには、サーバーの管理に使用できるメニューとリージョンが含まれます。各メニューを使用して、モニタリング、管理、ルーティングおよび一般情報の表示を行うことができます。

Oracle HTTP Serverのホームページには、次のリージョンが含まれます。

- 「一般」リージョン: コンポーネントの名前、その状態、ホスト、ポート、マシン名、およびOracleホームの場所が表示されます。

- 「主要統計」リージョン: プロセスおよびリクエストの統計が表示されます。

- 「レスポンスと負荷」リージョン: アクティブ・リクエストの数、発行済のリクエストの数、Oracle HTTP Serverがリクエストに応答するのに要した時間などの情報が表示されます。また、リクエストで処理されたバイト数に関する情報も表示されます。

- 「CPU使用率およびメモリー使用量」リージョン: Oracle HTTP Serverインスタンスで使用されているCPU(%)およびメモリー(MB)が表示されます。

- 「リソース・センター」リージョン: Oracle HTTP Serverに関連するドキュメントおよびトピックへのリンクが表示されます。

図3-1に、ターゲットのナビゲーション・ペインとOracle HTTP Serverのホームページを示します。

図3-1 Fusion MIddleware ControlでのOracle HTTP Serverのホームページ

注意:

『Oracle Fusion Middlewareの管理』に、ターゲット・ナビゲーション・ペインおよびホーム・ページ上のすべてのアイテムが詳しく説明されています。

Fusion Middleware Controlを使用した構成ファイルの編集

Fusion Middleware Controlの「サーバーの詳細構成」ページでは、構成(.conf)ファイルを直接編集せずにOracle HTTP Server構成を編集できます(詳細は、Oracle HTTP Server構成ファイルの変更を参照)。Oracle HTTP Server構成を管理するFusion Middleware Controlおよびその他のOracleソフトウェアでは、これらのファイルが、同等ですが異なる形式で保存される場合がある点に注意してください。ソフトウェアを使用して構成を変更した後に、複数の構成ファイルがリライトされる可能性があります。Fusion Middleware Controlからの構成ファイルの編集手順は、WebLogic Serverドメインの構成ファイルの編集を参照してください。

WLSTを使用したOracle HTTP Serverの管理

WebLogic Scripting Tool (WLST)はコマンドドリブンのスクリプト・ツールです。WLSTの詳細は、『WebLogic Scripting Toolの理解』を参照してください。

Oracle HTTP Serverで使用できるカスタムWLSTコマンドの詳細は、Oracle HTTP ServerのカスタムWLSTコマンドを参照してください。

この項には次の情報が含まれます:

- Oracle HTTP Server固有のWLSTコマンド

- スタンドアロン環境でのWLSTの使用方法

Oracle HTTP Server固有のWLSTコマンド

WLSTではWebLogic Serverドメインでのサーバー管理のためにOracle HTTP Server固有のコマンドが提供されます。コマンドの詳細は、Oracle HTTP ServerのカスタムWLSTコマンドを参照してください。

次に示すものはオンライン・コマンドで、WLSTとドメイン用の管理サーバーが接続されている必要があります。

- ohs_createInstance

- ohs_deleteInstance

- ohs_addAdminProperties

- ohs_addNMProperties

- ohs_exportKeyStore

- ohs_postUpgrade

- ohs_updateInstances

構成ウィザードではなく、ohs_createInstanceおよびohs_deleteInstanceコマンドを使用して、Oracle HTTP Serverインスタンスを作成および削除することをお薦めします。これらのコマンドは追加のエラー・チェックを実行し、インスタンスの作成の場合は、自動ポート割当ても行います。

スタンドアロン環境でのWLSTの使用方法

Oracle HTTP Serverインスタンスがスタンドアロン環境で実行されている場合、WLSTを使用することはできますが、タスクをルーティングするオフライン(またはエージェント)コマンドを使用する必要があります。Oracle HTTP Serverの実行には、実行するタスクとの関連で具体的なWLSTコマンドが記載されていますが(たとえば、WLSTを使用したOracle HTTP Serverインスタンスの開始には、スタンドアロンOracle HTTP Serverインスタンスを開始するWLSTコマンドが記載)、nmConnect()コマンドを使用してオフラインのWLSTに実際に接続する必要があります。LinuxおよびWindowsのどちらでも、コマンドの形式は同じです。

nmConnect('login','password','hostname','port','<domainName>')

例:

nmConnect('weblogic','welcome1','localhost','5556','myDomain')

リモートのOracle HTTP Serverの1台が管理モードにあり、別の1台がリモート管理モードを有効化したスタンドアロンの場合、WLSTを使用してSSL構成などの管理タスクを実行できます。スタンドアロン・ドメインにおける通常のOracle HTTP Serverは、WebLogic Serverとしてのみ、そしてOracle HTTP Serverの起動/停止目的でのみ使用できます。これは、コマンド行スクリプトでも実行できます。

第II部 Oracle HTTP Serverの管理

この部では、Oracle HTTP Serverの管理タスクについて説明します。次の章が含まれます。

- Oracle HTTP Serverの実行

- Oracle HTTP Serverの操作

- サーバー・プロセスの管理およびモニタリング

- 接続の管理

- Oracle HTTP Serverログの管理

- アプリケーション・セキュリティの管理

4 Oracle HTTP Serverの実行

この章では、Oracle HTTP Serverの実行方法に関する情報を提供します。ここには、WebLogic環境およびスタンドアロン環境における、サーバー・インスタンスの生成手順と、インスタンスの起動、停止、管理の方法が含まれています。

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

- 開始する前に

- OHSインスタンスの作成

- 基本的なOracle HTTP Serverタスクの実行

- Oracle HTTP Serverのリモート管理

開始する前に

この章で説明するアクティビティを実行する前に、次のタスクを完了する必要があります。

1. 『Oracle HTTP Serverのインストールと構成』の説明に従って、Oracle HTTP Serverをインストールおよび構成します。

2. WebLogic ServerドメインでOracle HTTP Serverを実行している場合は、『Oracle WebLogic Serverサーバーの起動と停止の管理』のサーバーの起動と停止に関する項に従ってWebLogic Serverを起動します。

注意:

- コマンド行からWebLogic Serverを起動すると、多数の警告メッセージが表示される場合があります。これらのメッセージが表示される場合でも、WebLogic Serverは正常に起動します。

- WindowsプラットフォームでOracle HTTP Serverが機能するには、そのシステムにMicrosoft Visual C++ランタイム・ライブラリがインストールされている必要があります。詳細は、『Oracle HTTP Serverのインストールと構成』を参照してください。

3. 『Oracle WebLogic Serverノード・マネージャの管理』のノード・マネージャの使用に関する項に従って、ノード・マネージャ(WebLogicドメインおよびスタンドアロン・ドメインの両方に必要)を起動します。

OHSインスタンスの作成

構成ウィザードを使用すると、ドメインの作成時に複数のOracle HTTP Serverインスタンスを同時に作成できます。WebLogic Server Domain (FullまたはRestricted JRFドメイン・タイプ)を作成している場合、インスタンスを作成する必要はありません。インスタンスを作成しないことを選択した場合は、警告が表示されますが、構成プロセスは続行できます。

スタンドアロン・ドメインを作成している場合、Oracle HTTP Serverインスタンスはデフォルトで作成されます。

この項には次の情報が含まれます:

- WebLogic ServerドメインでのOracle HTTP Serverインスタンスの作成

- スタンドアロン・ドメインでのOracle HTTP Serverインスタンスの作成

注意:

予約済の範囲内(通常1024未満)にあるTCPポートを使用するOracle HTTP Serverインスタンスを作成しようとしている場合、サーバーを特権ポートにバインドできるように追加の構成を行う必要があります。詳細は、特権ポートでのOracle HTTP Serverインスタンスの起動(UNIXのみ)を参照してください。

WebLogic ServerドメインでのOracle HTTP Serverインスタンスの作成

カスタムWLSTコマンドohs_createInstance()、あるいはOracle Fusion Middlewareインフラストラクチャの一部としてインストールされているFusion Middleware Controlを使用して、WebLogic Serverドメインの中に管理対象のOracle HTTP Serverインスタンスを生成できます。次の項で、これらの手順について説明します。

- WLSTを使用したインスタンスの作成

- インスタンスの作成

- インスタンスのプロビジョニングについて

注意:

WebLogic Serverドメインで作業している場合は、WLSTを使用したOracle HTTP Serverの管理の説明に従ってOracle HTTP ServerのカスタムWLSTコマンドを使用することをお薦めします。これらのコマンドによって、優れたエラー・チェックや自動ポート管理などが提供されます。

WLSTを使用したインスタンスの作成

WLSTを使用してWebLogic ServerドメインにOracle HTTP Serverインスタンスを作成できます。次の手順に従います。

1. コマンド行からWLSTを起動します。

LinuxまたはUNIX: $ORACLE_HOME/oracle_common/common/bin/wlst.sh

Windows: $ORACLE_HOME\oracle_common\common\bin\wlst.cmd

2. WLSTに接続します。

- WebLogic Serverドメインでは:

> connect('loginID', 'password', '<adminHost>:<adminPort>')

例:

> connect('weblogic', 'welcome1', 'abc03lll.myCo.com:7001')

3. インスタンスおよびドメイン作成時に割り当てられたマシン名を指定してohs_createInstance()コマンドを使用し、インスタンスを作成します。

> ohs_createInstance(instanceName='ohs1', machine='abc03lll.myCo.com', [listenPort=XXXX], [sslPort=XXXX], [adminPort=XXXX])

注意:

ノード・マネージャが停止している場合は、createコマンドが部分的に実行されます。構成ファイルのマスター・コピーがOHS/componentNameに表示されます。ノード・マネージャが再開されると、システムが再同期化を行い、ファイルのランタイム・コピーがOHS/instances/componentNameに表示されます。

例:

> ohs_createInstance(instanceName='ohs1', machine='abc03lll.myCo.com')

注意:

ポート番号を指定しない場合は、番号が自動的に割り当てられます。

注意:

WebLogic Scripting Tool (WLST)の使用の詳細は、『WebLogic Scripting Toolの理解』を参照してください。

インスタンスの作成

Oracle Fusion Middlewareインフラストラクチャの一部としてインストールされているFusion Middleware Controlを使用して、WebLogic Serverドメインの中にOracle HTTP Serverインスタンスを生成できます。次の手順に従います。

1. Fusion Middleware Controlにログインし、Oracle HTTP Serverインスタンスを作成するWebLogic Serverドメインのシステム・コンポーネント・インスタンスのホームページに移動します。

2. WebLogic Serverドメインのメニューを開き、「管理」を選択してから、「OHSの作成/削除」を選択します。

注意:

「OHSの作成/削除」は、Oracle HTTP Serverドメイン・テンプレートを使用してドメインを拡張している場合のみ表示されます。そうでない場合は、このコマンドを使用できません。

「OHSインスタンス」ページが表示されます。

3. 「作成」をクリックします。

「OHSインスタンスの作成」ページが表示されます。

4. 「インスタンス名」で、Oracle HTTP Serverインスタンスの一意の名前(ohs_2など)を入力します。

5. 「マシン名」で、ドロップダウン・コントロールをクリックし、インスタンスを関連付けるマシンを選択します。

6. 「OK」をクリックします。

「OHSインスタンス」ページが再表示され、確認メッセージと新しいインスタンスが示されます。ポート番号は自動的に割り当てられます。

インスタンスの作成後、「OHSインスタンス」ページの列に、そのインスタンスに対して下矢印が表示されます。

これは、インスタンスが実行されていないことを示します。インスタンスの起動手順は、Oracle HTTP Serverインスタンスの起動を参照してください。起動後、矢印は上向きになります。

インスタンスのプロビジョニングについて

インスタンスの作成後、インスタンスはDOMAIN_HOME内でプロビジョニングされます。

- マスター(ステージング)コピーは次の場所にあります。
DOMAIN_HOME/config/fmwconfig/components/OHS/componentName

- ランタイムは次の場所にあります。
DOMAIN_HOME/config/fmwconfig/components/OHS/instances/componentName

実行時にインスタンスを提供するために、ノード・マネージャが実行中である必要があります。

作成直後、報告されるOracle HTTP Serveインスタンスの状態は、インスタンスが作成された方法によって異なります。

- ohs_createInstance()が使用された場合、報告されるインスタンスの状態はSHUTDOWNになります。

- 構成ウィザードを使用した場合、報告されるインスタンスの状態はUNKNOWNになります。

スタンドアロン・ドメインでのOracle HTTP Serverインスタンスの作成

サーバー構成時にドメインとして「スタンドアロン」を選択した場合、構成ウィザードによりドメインが作成され、このプロセス中にOracle HTTP Serverインスタンスも作成されます。詳細は、『Oracle HTTP Serverのインストールと構成』を参照してください。

基本的なOracle HTTP Serverタスクの実行

この項には、WLSTまたはFusion Middleware Controlを使用して基本的な管理タスクを実行する方法に関する情報が含まれます。また、WLSTおよびプロセスID (PID)ファイルでの情報も提供します。

- WLSTコマンドの使用について

- PIDファイルの理解

- Oracle HTTP Serverインスタンスの起動

- Oracle HTTP Serverインスタンスの停止

- Oracle HTTP Serverインスタンスの再起動

- 実行中のOracle HTTP Serverインスタンスのステータスの確認

- Oracle HTTP Serverインスタンスの削除

- デフォルトのノード・マネージャのポート番号の変更

WLSTコマンドの使用について

WLSTを使用する予定がある場合は、このツールに精通しておく必要があります。WLSTでの次の制限に注意する必要もあります。

- Oracle HTTP Serverのスタンドアロン・バージョンを実行する場合、オフラインまたは「agent」WLSTコマンドを使用する必要があります。これらのコマンドについては、それぞれの適切な箇所で説明します。

詳細は、『Oracle® Fusion Middleware管理者ガイド』のOracle WebLogic Scripting Tool (WLST)の使用のスタート・ガイドを参照してください。

PIDファイルの理解

管理者は、デーモンの再起動時と終了時にプロセスIDを使用できます。プロセスが異常停止した場合、killコマンドを使用してhttpd子プロセスを停止する必要があります。デフォルトのPIDファイルの名前またはその場所を変更することはできません。

Oracle HTTP Serverは起動時に、親httpdプロセスのプロセスID (PID)を、次のディレクトリにあるhttpd.pidファイルに書き込みます。

DOMAIN_HOME/servers/<componentName>/logs

httpd.confのPidFileディレクティブでは、PIDファイルの場所を指定しますが、このディレクティブの値は変更しないでください。

注意:

PidFileディレクティブを編集する場合、UNIXおよびLinuxプラットフォームでは、ORACLE_HOME/ohs/bin/apachectlファイルを編集してPIDファイルの新しい場所を指定する必要もあります。

関連項目:

PidFileディレクティブの詳細は、次のApache HTTP Serverのドキュメントを参照してください。

http://httpd.apache.org/docs/current/mod/mpm_common.html#pidfile

Oracle HTTP Serverインスタンスの起動

この項には、Fusion Middleware ControlおよびWLSTを使用してOracle HTTP Serverを起動する方法に関する情報が含まれます。

注意:

WindowsプラットフォームでOracle HTTP Serverが機能するには、そのシステムにMicrosoft Visual C++ランタイム・ライブラリがインストールされている必要があります。詳細は、『Oracle HTTP Serverのインストールと構成』を参照してください。

- Fusion Middleware Controlを使用したOracle HTTP Serverインスタンスの起動

- WLSTを使用したOracle HTTP Serverインスタンスの起動

- コマンド行を使用したOracle HTTP Serverインスタンスの起動

- 特権ポートでのOracle HTTP Serverインスタンスの起動(UNIXのみ)

- 別のユーザーとしてのOracle HTTP Serverインスタンスの起動(UNIXのみ)

Fusion Middleware Controlを使用したOracle HTTP Serverインスタンスの起動

Fusion Middleware Controlで、Oracle HTTP Serverのホーム・ページからOracle HTTP Serverを起動します。HTTP Serverのホーム・ページに移動して、次のいずれかを実行します。

- 「Oracle HTTP Server」メニューから次の手順を実行します。

1. 「コントロール」を選択します。

2. 「コントロール」メニューから「起動」を選択します。

- 「ターゲット・ナビゲーション」ツリーから次の手順を実行します。

1. 起動するOracle HTTP Serverインスタンスを右クリックします。

2. 「コントロール」を選択します。

3. 「コントロール」メニューから「起動」を選択します。

- ページ・ヘッダーから「起動」を選択します。
インスタンスがUNKNOWNの状態で起動します。

WLSTを使用したOracle HTTP Serverインスタンスの起動

WLSTを使用してOracle HTTP Serverインスタンスを起動するには、WebLogic Serverドメインでstart()コマンドを使用するか、スタンドアロン・ドメインでnmStart()を使用します。次の表にこれらのコマンドを示します。

注意:

- これらのコマンドを機能させるには、ノード・マネージャが実行中である必要があります。ノード・マネージャが停止している場合は、エラー・メッセージが表示されます。

- スタンドアロン・ドメインの場合、serverTypeは必須です。これが含まれていないと、startWebLogicを検出できないことを示すエラーがスローされます。

OHSインスタンスの作成で説明するように、これらのコマンドではOHSインスタンスとして作成済であり、WLSTが実行中であることを前提としています。

ドメイン

構文

例

WebLogic

start('instanceName')

または

nmStart(serverName='name', serverType='type')

start('ohs1')

または

nmStart(serverName='ohs1', serverType='OHS')

スタンドアロン

nmStart(serverName='name', serverType='type')

nmStart(serverName='ohs1', serverType='OHS')

コマンド行を使用したOracle HTTP Serverインスタンスの起動

スクリプトを経由してコマンド行からOracle HTTP Serverインスタンスを起動できます。

1. ノード・マネージャが稼働していることを確認します。

2. 次のコマンドを入力します。

LinuxまたはUNIX: $DOMAIN_HOME/bin/startComponent.sh componentName

Windows: %DOMAIN_HOME%\bin\startComponent.cmd componentName

例:

$DOMAIN_HOME/bin/startComponent.sh ohs1

startComponentスクリプトはノード・マネージャとコンタクトし、nmStart()コマンドを実行します。

3. プロンプトが表示された場合、ノード・マネージャのパスワードを入力します。システムは次のメッセージにより応答します。

Successfully started server componentName...
Successfully disconnected from Node Manager...

Exiting WebLogic Scripting Tool.

注意:

起動時に奇妙なシステム・メッセージが表示されても、無視して構いません。

ノード・マネージャのパスワードの格納

startComponentコマンドを使用してサーバーを起動するたびにノード・マネージャのパスワードを入力する手間を省くには、初めて起動する際にstoreUserConfigオプションを使用します。次の手順を実行します。

1. プロンプトに次のコマンドを入力します。

$DOMAIN_HOME/bin/startComponent.sh componentName storeUserConfig

システムによりノード・マネージャのパスワードの入力を要求されます。

2. パスワードを入力します。

システムは次のメッセージにより応答します。

Creating the key file can reduce the security of your system if it is not kept
in a secured location after it is created. Creating new key...
The username and password that were used for this WebLogic NodeManager
connection are stored in $HOME/.wlst/nm-cfg-myDomainName.props and
$HOME /.wlst/nm-key-myDomainName.props.

特権ポートでのOracle HTTP Serverインスタンスの起動(UNIXのみ)

警告:

この手順が完了すると、このOracleホームから実行されている任意のOracle HTTP Serverプロセスを特権ポートにバインドできるようになります。

UNIXシステムでは、予約済の範囲内(通常1024未満)にあるTCPポートは、root権限を持つプロセスによってのみバインドできます。Oracle HTTP Serverは常に非rootユーザー(Oracle Fusion Middlewareをインストールしたユーザー)として実行されます。UNIXで、Oracle HTTP Serverを特権ポートにバインドできるようにするには、特別な構成が必要です。

Oracle HTTP Serverが予約済の範囲内にあるポート(デフォルト・ポート80またはポート443など)でリスニングできるようにするには、Oracle HTTP Serverマシンごとに次の1回かぎりのセットアップを使用します。

1. スーパー・ユーザーとして次の手順を実行して、ORACLE_HOME/ohs/bin/launchファイルを更新します(スーパー・ユーザー権限へのアクセス権がない場合、システム管理者にこれらの手順を実行してもらいます)。

a. 次のようにしてファイルの所有権をrootに変更します。

chown root $ORACLE_HOME/ohs/bin/launch

b. ファイルの権限を次のように変更します。

chmod 4750 $ORACLE_HOME/ohs/bin/launch

ルート権限が必要な手順が完了しました。

c. ポートの管理の説明に従って、Oracle HTTP Serverのポート設定を変更します。

2. httpd.confファイルのUserおよびGroupディレクティブを構成します。
User用に構成されたユーザーIDは、インスタンスを作成したのと同じユーザーIDである必要があります。Group用に構成されたグループIDは、インスタンスを作成するのに使用するのと同じグループIDである必要があります。Oracle HTTP Server構成ファイルを参照してください。Oracle HTTP Serverを構成して別のユーザーIDで実行するには、別のユーザーとしてのOracle HTTP Serverインスタンスの起動(UNIXのみ)を参照してください。

3. Oracle HTTP Serverインスタンスの停止で説明されている停止方法のいずれかを使用することで、インスタンスを停止(実行中の場合)します。

4. Oracle HTTP Serverインスタンスの起動で説明されている起動方法のいずれかを使用することで、インスタンスを起動します。

別のユーザーとしてのOracle HTTP Serverインスタンスの起動(UNIXのみ)

UNIXシステムの場合、Oracle HTTP Serverのワーカー・プロセス(接続を受け入れ、リクエストを処理するプロセス)は、インスタンスを作成するのに使用されるユーザーIDとは異なるユーザーIDとして実行するように構成できます。

特権ポートでのOracle HTTP Serverインスタンスの起動(UNIXのみ)の指示に従い、必要なユーザーIDでUserディレクティブを構成します。構成されたユーザーIDは、インスタンス・ディレクトリを含むグループと同じグループに属している必要があります。Groupディレクティブも、インスタンスを作成するのに使用するのと同じグループに構成および設定される必要があります。

注意:

- Oracle HTTP Serverの親プロセスおよびロギング処理はルートとして実行し、これらのプロセスは接続を受け入れることもリクエストを処理することもありません。

- ノード・マネージャがSSLリスナーを使用するように構成されている場合、startComponent.shまたはnmConnectコマンドが別のユーザーとして正常に実行できるように、他のユーザーがノード・マネージャにより使用されるSSLトラスト・ストアにアクセスする適切な権限を持っていることを確認します。
ノード・マネージャの詳細は、『Oracle WebLogic Serverノード・マネージャの管理』のノード・マネージャの概要に関する項を参照してください。

Oracle HTTP Serverインスタンスの停止

この項には、Fusion Middleware ControlおよびWLSTを使用してOracle HTTP Serverを停止する方法に関する情報が含まれます。Oracle HTTP Serverが停止すると、他のサービスも影響を受ける場合がある点に注意してください。

- Fusion Middleware Controlを使用したOracle HTTP Serverインスタンスの停止

- WLSTを使用したOracle HTTP Serverインスタンスの停止

- コマンド・ラインからのOracle HTTP Serverインスタンスの停止

Fusion Middleware Controlを使用したOracle HTTP Serverインスタンスの停止

Fusion Middleware Controlで、Oracle HTTP Serverのホーム・ページからOracle HTTP Serverを停止できます。Oracle HTTP Serverのホーム・ページに移動して、次のいずれかを実行します。

- Oracle HTTP Serverのホームページから、次の手順を実行します。

1. 停止するサーバー・インスタンスを選択します。

2. サーバー・インスタンスのホーム・ページで、「Oracle HTTP Server」ドロップダウン・メニューから、「コントロール」、「停止」の順に選択します。

- 「ターゲット・ナビゲーション」ツリーから次の手順を実行します。

1. 停止するOracle HTTP Serverコンポーネントを右クリックします。

2. 「コントロール」を選択します。

3. 「コントロール」メニューから「停止」を選択します。

- サーバー・インスタンスのホーム・ページのページ・ヘッダーから、「停止」を選択します。

WLSTを使用したOracle HTTP Serverインスタンスの停止

WLSTを使用してOracle HTTP Serverを停止できます。スクリプト・ツール内から次のコマンドのいずれかを使用します。

注意:

- これらのコマンドを機能させるには、ノード・マネージャが実行中である必要があります。ノード・マネージャが停止している場合は、エラー・メッセージが表示されます。

- スタンドアロン・ドメインの場合、serverTypeは必須です。これが含まれていないと、startWebLogicを検出できないことを示すエラーがスローされます

ドメイン

構文

例

WebLogic

shutdown('serverName')

shutdown('ohs1')

スタンドアロン

nmKill(serverName='serverName', serverType='type')[1]

nmKill(serverName='ohs1', serverType='OHS')

警告:

パラメータを指定せずにshutdown()を実行すると、WebLogic Serverが終了し、WLSTを終了します。Oracle HTTP Serverは引き続き実行されます。回復するには、WebLogic Serverを再起動し、WLSTを立ち上げ、AdminServerに再接続します。次に、Oracle HTTP Serverインスタンス名でシャットダウンを再実行します。

コマンド行からのOracle HTTP Serverインスタンスの停止

スクリプトを経由してコマンド行からOracle HTTP Serverインスタンスを停止できます。

1. 次のコマンドを入力します。

$DOMAIN_HOME/bin/stopComponent.sh componentName

例:

$DOMAIN_HOME/bin/stopComponent.sh ohs1

このコマンドは、WLSTを起動して、nmKill()コマンドを実行します。ノード・マネージャが実行中ではない場合には、stopComponentコマンドは動作しません。

2. プロンプトが表示された場合、ノード・マネージャのパスワードを入力します。

ノード・マネージャのパスワードの格納の説明に従って、storeUserConfigオプションを指定してノード・マネージャを起動した場合、プロンプトは表示されません。

サーバーが停止すると、システムは次のように応答します。

Successfully killed server componentName...
Successfully disconnected from Node Manager...

Exiting WebLogic Scripting Tool.

Oracle HTTP Serverインスタンスの再起動

Oracle HTTP Serverを再起動すると、Apache親プロセスが子プロセスに対して現在のリクエストの後に終了する(リクエストの処理中でなければ即時に終了する)ように指示します。再起動時に、親プロセスはその構成ファイルを再び読み取り、そのログ・ファイルを再び開きます。それぞれの子プロセスが終了するたびに、親プロセスは、新しく生成された構成ファイルの子プロセスでそれらの子プロセスを置き換えます。新しい子プロセスは即時に新しいリクエストの処理を開始します。

次の項には、Fusion Middleware ControlおよびWLSTを使用してOracle HTTP Serverを再起動する方法に関する情報が含まれます。

- Fusion Middleware Controlを使用したOracle HTTP Serverインスタンスの再起動

- WLSTを使用したOracle HTTP Serverインスタンスの再起動

Fusion Middleware Controlを使用したOracle HTTP Serverインスタンスの再起動

Fusion Middleware Controlで、Oracle HTTP Serverのホーム・ページからOracle HTTP Serverを再起動します。Oracle HTTP Serverのホーム・ページに移動して、次のいずれかを実行します。

- Oracle HTTP Serverのホームページから、次の手順を実行します。

1. 再起動するサーバー・インスタンスを選択します。「コントロール」を選択します。

2. インスタンスのホーム・ページで「起動」をクリックするか、「Oracle HTTP Server」ドロップダウン・メニューから、「コントロール」、「再起動」の順に選択します。

- 「ターゲット・ナビゲーション」ツリーから次の手順を実行します。

1. 再起動するOracle HTTP Serverインスタンスを右クリックします。

2. 「コントロール」を選択します。

3. 「コントロール」メニューから「再起動」を選択します。

WLSTを使用したOracle HTTP Serverインスタンスの再起動

WLSTを使用してOracle HTTP Serverを再起動するには、softRestart()コマンドを使用します。スクリプト・ツール内から次のコマンドのいずれかを入力します。

注意:

- WebLogicドメインとスタンドアロン・ドメインでは、これらのコマンドが動作するにはノード・マネージャが起動している(すなわち、状態がRUNNINGである)必要があります。ノード・マネージャが停止している場合は、エラー・メッセージが表示されます。

- スタンドアロン・ドメインの場合は、すべてのパラメータが必須です。これらが含まれていないと、startWebLogicを検出できないことを示すエラーがスローされます。

- nmSoftRestartコマンドもWebLogicドメインで使用できます。これを行うには、nmConnectコマンドを使用して先にノード・マネージャに接続する必要があります。

ドメイン

構文

例

WebLogic

softRestart('serverName')

softRestart('ohs1')

スタンドアロン

nmSoftRestart(serverName='name', serverType='type')

nmSoftRestart(serverName='ohs1', serverType='OHS')

実行中のOracle HTTP Serverインスタンスのステータスの確認

この項には、実行中のOracle HTTP Serverインスタンスのステータスを確認する方法に関する情報が含まれます。Oracle Fusion Middlewareインフラストラクチャの一部としてインストールされているFusion Middleware Controlから、またはWLSTを使用して、この情報を確認できます。

- Fusion Middleware Controlを使用したサーバー・ステータスの確認

- WLSTを使用したサーバー・ステータスの確認

Fusion Middleware Controlを使用したサーバー・ステータスの確認

「Oracle HTTP Server」ページのヘッダーの左上角にある上下矢印は、選択したサーバー・インスタンスが実行中であるかどうかを示します。次のイメージは、サーバー・インスタンス(この場合はohs_2)が実行中であることを示す上矢印を表示しています。

次のイメージは、サーバー・インスタンス(この場合は「ohs_2」)が実行中でないことを示す下矢印を表示しています。

WLSTを使用したサーバー・ステータスの確認

WebLogic Serverドメインでは、ohs_createInstance()を使用してOracle HTTP Serverインスタンスを作成している場合、その初期状態(インスタンスを起動する前の状態)はSHUTDOWNになります。

構成ウィザードを使用してインスタンス(WebLogic Serverドメインとスタンドアロン・ドメインの両方)を生成した場合、初期状態(インスタンスを起動する前の状態)はUNKNOWNになります。

WLSTを使用して実行中のOracle HTTP Serverインスタンスのステータスを確認するには、WLST内から次のいずれかを入力します。

注意:

- これらのコマンドを機能させるには、ノード・マネージャが実行中である必要があります。ノード・マネージャが停止している場合は、エラー・メッセージが表示されます。WebLogic Serverドメインでノード・マネージャが停止した場合、インスタンスの実際の状態に関係なく、状態はUNKNOWNに戻ります。また、state()は、ノード・マネージャに接続できないことをユーザーに通知しません。

- 他のWLSTコマンドとは異なり、state()はノード・マネージャが停止したことをユーザーに通知しないため、インスタンスが本当にUNKNOWN状態なのか、ノード・マネージャが停止しただけなのかを区別する方法がありません。

- スタンドアロン・ドメインの場合は、すべてのパラメータが必須です。これらが含まれていないと、startWebLogicを検出できないことを示すエラーがスローされます。

- nmServerStatusコマンドもWebLogicドメインで使用できます。これを行うには、nmConnectコマンドを使用して先にノード・マネージャに接続する必要があります。

ドメイン

構文

例

WebLogic

state('serverName')

state('ohs1')

スタンドアロン

nmServerStatus(serverName='name', serverType='type')

nmServerStatus(serverName='ohs1', serverType='OHS')

注意:

このコマンドは、存在しないコンポーネントとUNKNOWN状態の実在するコンポーネントを区別しません。したがって、存在しないインスタンスを入力した場合(タイプミスなど)には、UNKNOWN状態が返ります。

Oracle HTTP Serverインスタンスの削除

WebLogic Serverドメインとスタンドアロン・ドメイン両方のOracle HTTP Serverインスタンスを削除できます。

- WebLogic ServerドメインでのOracle HTTP Serverインスタンスの削除

- スタンドアロン・ドメインからのOracle HTTP Serverインスタンスの削除

WebLogic ServerドメインでのOracle HTTP Serverインスタンスの削除

WebLogic Serverドメインでは、カスタムWLSTコマンドohs_deleteInstance()、あるいはOracle Fusion Middlewareインフラストラクチャの一部としてインストールされているFusion Middleware Controlを使用できます。次の項で、これらの手順について説明します。

- WLSTを使用したインスタンスの削除

- インスタンスの削除

WLSTを使用したインスタンスの削除

WebLogic Serverドメインにいる場合は、カスタムWLSTコマンドohs_deleteInstance()を使用して、Oracle HTTP Serverインスタンスを削除できます。このコマンドを使用すると、次のようになります。

- 選択したインスタンスの情報がconfig.xmlから削除されます。

- すべてのOHS構成ディレクトリおよびその内容が削除されます(OHS/instanceNameやOHS/instances/instanceNameなど)。これらのパスは構成のランタイムおよびマスター・コピーの両方を参照しています。

- 削除されたインスタンスに関連付けられているすべてのログファイルが削除されます。

- 削除されたインスタンスのすべての状態情報が削除されます。

注意:

ノード・マネージャが停止している場合、ohs_deleteInstance()を使用してインスタンスを削除することはできません。

WLSTを使用してインスタンスを削除するには、次の手順を実行します。

1. コマンド行からWLSTを起動します。

LinuxまたはUNIX: $ORACLE_HOME/oracle_common/common/bin/wlst.sh

Windows: $ORACLE_HOME\oracle_common\common\bin\wlst.cmd

2. WLSTに接続します。

- WebLogic Serverドメインでは:

> connect('loginID', 'password', '<adminHost>:<adminPort>')

例:

> connect('weblogic', 'welcome1', 'abc03lll.myCo.com:7001')

3. コマンド・プロンプトで次のように入力

ohs_deleteInstance(instanceName='instanceName')

たとえば、ohs1という名前のOHSインスタンスを削除するには、次のコマンドを使用します。

ohs_deleteInstance(instanceName='ohs1')

UNKNOWNまたはRUNNING状態のOHSインスタンスは削除できません。

注意:

状態がUNKNOWNの新しく作成されたOHSインスタンス(たとえば、構成ウィザードを使用して作成)の場合、インスタンスを開始および停止して状態をSHUTDOWNにすることができます。その後、正常に削除できます。

状態がRUNNINGのインスタンスの場合、最初にインスタンスを停止して状態をSHUTDOWNにしてから、正常に削除できます。

インスタンスの削除

Fusion Middleware Controlを使用してOracle HTTP Serverインスタンスを削除するには、次の手順を実行します。

注意:

実行中のOracle HTTP Serverインスタンスは削除できません。インスタンスが実行中の場合は、Oracle HTTP Serverインスタンスの停止の説明に従ってインスタンスを停止してから、次の手順を続行します。

1. ログインします。削除するOracle HTTP Serverインスタンスを含むWebLogic Serverドメインのシステム・コンポーネント・インスタンスのホームページに移動します。

2. WebLogic Serverドメインのメニューを開き、「管理」を選択してから、「OHSの作成/削除」を選択します。

3. 「OHSインスタンス」ページで、削除するインスタンスを選択し、「削除」をクリックします。

4. 確認ウィンドウで「はい」をクリックして削除を確認します。

選択したOracle HTTP Serverインスタンスが削除されたことを示す情報メッセージを備えた「OHSインスタンス」ページが表示されます。

スタンドアロン・ドメインからのOracle HTTP Serverインスタンスの削除

構成ウィザードを使用することによって、スタンドアロン・ドメイン内のOracle HTTP Serverインスタンスを削除できます(そのインスタンスがドメイン内の唯一のインスタンスでない場合)。構成ウィザードは常に、スタンドアロン・ドメイン内に少なくとも1つのOracle HTTP Serverインスタンスを必要とするため、ドメイン内に唯一存在するインスタンスについては削除することができません。スタンドアロン・ドメイン内で唯一のインスタンスを削除する場合は、かわりにドメイン・ディレクトリ全体を完全に削除する必要があります。

構成ウィザードを使用したOracle HTTP Serverインスタンスの削除は、実際には部分削除にすぎません(また、ohs_deleteInstance()を使用してWebLogic Serverドメインが実行する削除方法との一貫性がありません。WLSTを使用したインスタンスの削除を参照してください)。構成ウィザードを使用してスタンドアロン・インスタンスを削除すると、次のようになります。

- 特定のインスタンスに関する情報がconfig.xmlから削除されるため、このインスタンスは有効として認識されなくなります。別の更新を行うために構成ウィザードを再度起動したときに、削除されたインスタンスが表示されません。

- 削除されたインスタンスに対してコンパイルされたログは、DOMAIN_HOME/servers/ohs1 (インスタンス名をohs1と仮定)にそのまま残されます。その後、同じ名前の新しいインスタンスが作成された場合、継承されて、それらのファイルへのロギングが続行されます。

- 削除されたインスタンスの構成ディレクトリとその内容は削除されず、DOMAIN_HOME/config/fmwconfig/components/OHS/instanceNameおよびDOMAIN_HOME/config/fmwconfig/components/OHS/instances/instanceNameにそのまま残されます。両方のディレクトリで唯一の変更点は、httpd.conf becomes httpd.conf.bak、ssl.conf becomes ssl.conf.bakおよびadmin.conf becomes admin.conf.bakファイルの名前が変更されることです。これにより、インスタンスが起動されるのを防ぎます。(削除したインスタンスと同じ名前を持つ新しいインスタンスを作成する場合、この情報は上書きされますが、*.bakファイルは残ります)。

- 削除されたインスタンスの状態情報は、DOMAIN_HOME/system_components/..にそのまま残されます。その後、同じ名前の新しいインスタンスが作成された場合、そのインスタンスは古いインスタンスの状態を継承します。UNKNOWN状態で起動するのではなく、SHUTDOWNまたはFAILED_NOT_RESTARTABLEとして表示される場合もあります。

スタンドアロン・ドメインのOracle HTTP Serverインスタンスを削除するには、次の手順を実行します。

1. 実行中のすべてのインスタンスを停止します(Oracle HTTP Serverインスタンスの停止を参照してください)。構成ウィザードはOracle HTTP Serverインスタンスを確認しないため、削除前には、すべてのインスタンスが確実に停止していることを確認する必要があることに注意してください。

2. ノード・マネージャが実行中である場合は停止させます。

3. 構成ウィザードを起動し(『Oracle HTTP Serverのインストールと構成』を参照してください)、次の手順を実行します。

a. 「既存ドメインの更新」を選択し、ドメインへのパスを選択します。

b. 「テンプレート」画面と「JDKの選択」画面の両方を、それぞれで「次」をクリックすることによってスキップします。

c. 「システム・コンポーネント」画面で、削除するインスタンスを選択し、「削除」をクリックします。
選択したインスタンスが削除されます。

d. 「次」,をクリックし、「OHSサーバー」画面で、再度「次」をクリックします。

e. 「構成のサマリー」画面で、選択したインスタンスが削除されていることを確認し、「更新」をクリックします。

f. 「成功」画面で、「終了」をクリックします。

デフォルトのノード・マネージャのポート番号の変更

WLSTまたはOracle WebLogic Server管理コンソールのいずれかを使用して、ノード・マネージャのポートのデフォルト値を変更できます。

- WLSTを使用したデフォルトのノード・マネージャのポートの変更

- Oracle WebLogic Server管理コンソールを使用したデフォルトのノード・マネージャのポートの変更

WLSTを使用したデフォルトのノード・マネージャのポートの変更

WLSTを使用してデフォルトのノード・マネージャのポート番号を変更するには、カスタム・コマンドreadDomainを使用してドメインを開きます。マシン用のノード・マネージャを含むディレクトリに移動します。ListenPortプロパティを設定してからドメインを更新します。

...
readDomain('DOMAIN_HOME')
cd('/Machines/Machine_Name/NodeManager/Node_Manager_Name')
set('ListenPort',9090)
updateDomain()
closeDomain()
...

この例では、DOMAIN_HOMEは、ドメインのルート・ディレクトリを表しています。MachinesおよびNodeManagerはディレクトリです。Node_Manager_NameはMachine_Nameマシンに属するノード・マネージャの名前です。デフォルトのノート・マネージャの名前はlocalmachineです。デフォルトのMachine_Nameもlocalmachineです。ListenPortの値は9090に設定されています。

Oracle WebLogic Server管理コンソールを使用したデフォルトのノード・マネージャのポートの変更

次の手順に従い、Oracle WebLogic Server管理コンソールを使用してデフォルトのノード・マネージャのポート番号を変更します。

1. 手動でDOMAIN_HOME/nodemanager/nodemanager.propertiesファイルを編集して、ListenPortプロパティの値を変更します。

2. WebLogic Server管理コンソールで、ノード・マネージャに関連するマシンの構成を、新しいポート番号を指すように変更します。

管理コンソールの左ペインから、「環境」を展開して「マシン」を選択します。編集する構成のマシンを選択します。「構成」タブ、「ノード・マネージャ」タブの順に選択します。リスニング・ポートをnodemanager.propertiesファイルで更新されたポートに変更します。「保存」をクリックします。

Oracle HTTP Serverのリモート管理

スタンドアロン環境で実行されているOracle HTTP Serverは、別のマシンで実行されている、コロケートされたOracle HTTP Serverの実装でリモート管理できます。この機能によって、WLST、あるいはOracle Fusion Middlewareインフラストラクチャの一部としてインストールされているFusion Middleware Controlを使用して、リモート・マシンからコンポーネントの起動、再起動、構成が行えます。この項では、 Oracle HTTP Serverをリモートから実行する設定方法について説明します。

- リモート環境の設定

- タスク4: Oracle HTTP Serverのリモート実行

リモート環境の設定

次の指示では、リモート環境の設定方法について説明します。これにより、1つのマシンにインストールされているOracle HTTP Serverを別のマシンのインストールから実行できます。この項には次の情報が含まれます:

- リモート環境のホスト要件

- タスク1: ホスト1での拡張ドメインの設定

- タスク2: ホスト1でのドメインの圧縮

- タスク3: ホスト2でのドメインの解凍

- タスク4: Oracle HTTP Serverのリモート実行

リモート環境のホスト要件

Oracle HTTP Serverをリモート管理するには、次のように複数のホストを別々のマシンにインストールする必要があります。

- コロケート・インストール(この例では、このインストールをホスト1と呼びます)。

- スタンドアロン・インストール(ホスト2)。ホスト2のスタンドアロンMW_HOMEへのパスは、ホスト1のコロケートされたMW_HOMEと同じである必要があります。例:

/scratch/user/work

タスク1: ホスト1での拡張ドメインの設定

次の手順では、拡張ドメインを設定して、コロケートされたバージョンのOracle HTTP Server (ホスト1)のデータベースにリンクする方法について説明します。

1. Repository Configuration Utility (RCU)を使用して、拡張ドメイン用のデータベースを設定およびインストールします。詳細は『Repository Creation Utilityによるスキーマの作成』を参照してください。

2. 構成ウィザードを起動して拡張ドメインを作成します。表4-1で指定した値を使用します。

表4-1 拡張ドメインの設定

対象

選択または入力する値

ドメインの作成

新しいドメインを作成し、そのパスを指定します(たとえば、MW_HOME/user_projects/domains/ohs1_domain)。

テンプレート

Oracle HTTP Server (コロケート)

アプリケーションの場所

デフォルトです。

管理者アカウント

ユーザー名とパスワード(たとえば、weblogicとwelcome1)

データベース構成タイプ

RCUデータ。続いて、「RCU構成の取得」→「次へ」をクリックします。

オプションの構成

項目は次のとおりです。

- 管理サーバー

- ノード・マネージャ

- システム・コンポーネント

- デプロイメントおよびサービス

管理サーバー

リスニング・アドレス(「すべてのローカル・アドレス」またはホスト1用の有効な名前かアドレス)およびポート

ノード・マネージャ

「ドメイン当たり」。ノード・マネージャの資格証明を指定します(たとえば、weblogicとwelcome1)。

システム・コンポーネント

「追加」し、コンポーネント・タイプOHSを使用して(たとえば、システム・コンポーネント値ohs1を使用して)フィールドを設定します。

OHSサーバー

リスニング・アドレスとポートか、デフォルトを使用します。

マシン

「追加」。これにより、マシンがドメイン(たとえば、ohs1_Machine)に、ノード・マネージャのリスニング値とポート値と一緒に追加されます。ホスト2用の有効な名前またはアドレスなど(ローカル・ホストまたは「すべてのローカル・アドレス」は使用しない)、ホスト1からアクセス可能なホスト2用のリスニング・アドレスを指定する必要があります。

システム・コンポーネントの割当

OHSコンポーネント(たとえば、ohs1)。続いて、右矢印を使用して、そのコンポーネントをマシン(たとえば、ohs1_machine)に割り当てます。

構成サマリー

「作成」(OPSS手順の実行に数分かかる場合があります)。

タスク2: ホスト1でのドメインの圧縮

ホスト1で、packコマンドを使用してドメインを圧縮します。packコマンドは、ドメイン全体またはドメインのサブセットのスナップショットを格納したテンプレート・アーカイブ(.jar)ファイルを作成します。

<MW_HOME>/ohs/common/bin/pack.sh -domain=path to domain -template=path to template -template_name=name -managed=true

例:

<MW_HOME>/ohs/common/bin/pack.sh -domain=<MW_HOME>/user_projects/domains/ohs1_domain -template=/tmp/ohs1_tmplt.jar -template_name=ohs1 -managed=true

タスク3: ホスト2でのドメインの解凍

unpackコマンドは、リモート・マシンの管理対象サーバー・ドメイン・ディレクトリに使用されるフル・ドメインまたはドメインのサブセットを作成します。次の手順を使用して、タスク2: ホスト1でのドメインの圧縮でホスト1で圧縮したドメインをホスト2で解凍します。

1. タスク2: ホスト1でのドメインの圧縮で作成したテンプレート・ファイルを、ホスト1からホスト2へコピーします。

2. unpackコマンドを使用してドメインを解凍します。

<MW_HOME>/ohs/common/bin/unpack.sh -domain=path to domain -template=path to template

例:

<MW_HOME>/ohs/common/bin/unpack.sh -domain=<MW_HOME>/user_projects/domains/ohs1_domain -template=/tmp/ohs1_tmplt.jar

タスク4: Oracle HTTP Serverのリモート実行

ホスト1で作成したドメインをホスト2で解凍したら、コロケート環境で使用するのと同じ一連のWLSTコマンドとFusion Middleware Controlツールを使用して、コンポーネントの起動、停止、再起動および構成を行えます。

Oracle HTTP Serverをリモート実行するには、次のことを行います。

1. ホスト1でWebLogic管理サーバーを起動します。

<MW_HOME>/user_projects/domains/ohs1_domain/bin/startWebLogic.sh &

2. ホスト2でノード・マネージャを起動します。

<MW_HOME>/user_projects/domains/ohs1_domain/bin/startNodeManager.sh &

ホスト1のコロケート実装から、ホスト2のOracle HTTP Serverインスタンスを実行できるようになりました。任意のWLSTコマンドまたはFusion Middleware Controlツールを使用できます。たとえば、ホスト2をノード・マネージャに接続してサーバーohs1を起動するには、ホスト1で次のように入力します。

<MW_HOME>/ohs/common/bin/wlst.sh
nmConnect('weblogic', '<password>', '<nm-host>', '<nm-port>', '<domain-name>', '<domain-directory>','ssl')
nmStart(serverName='ohs1', serverType='OHS')

Oracle HTTP Serverコンポーネントの起動、停止、再起動および構成の詳細は、基本的なOracle HTTP Serverの実行を参照してください。

[1]
nmKill()もWebLogicドメインで機能します。

5 Oracle HTTP Serverの操作

この章では、インストールされたバージョンのOracle HTTP Serverを操作する際に実行が求められる可能性のある共通タスクについて説明します。次の項で構成されます。

- 構成ファイルの編集について

- サーバー・プロパティの指定

- Oracle HTTP Serverインスタンスの構成

- mod_securityモジュールの構成

構成ファイルの編集について

WebLogic Serverドメインの一部であるインスタンスの場合、Fusion Middleware Controlおよび管理インフラストラクチャはOracle HTTP Server構成を管理します。ステージング・ディレクトリ内での構成に対する直接編集は、Fusion Middleware Controlでの構成の変更などの後続の管理操作の後で上書きされる可能性があります。このようなインスタンスでは、直接編集は管理サーバーが停止時にのみ実行できます。管理サーバーがその後に起動(または再起動)されると、手動編集の結果が、管理対象インスタンスのノード上のランタイム・ディレクトリにレプリケートされます。

詳細は、構成ファイルの理解を参照してください。

次のセクションで、構成ファイルの変更の詳細を説明しています。

- スタンドアロン・ドメイン用の構成ファイルの編集

- WebLogic Serverドメイン用の構成ファイルの編集

スタンドアロン・ドメイン用の構成ファイルの編集

スタンドアロン・インスタンスの場合、構成はいつでもステージング・ディレクトリ内で直接編集できます。ランタイム構成ファイルは、OHSインスタンスの起動、再起動または停止時に更新されます。

WebLogic Serverドメイン用の構成ファイルの編集

Fusion Middleware Control内から構成ファイルを開き、編集することができます。これらの手順に従って、ファイルを変更します。

1. 「HTTP Server」メニューから「管理」を選択します。

2. 「管理」メニュー・アイテムから「詳細構成」を選択します。

3. 「サーバーの詳細構成」ページで、「ファイルの選択」ドロップダウン・リストから、httpd.confファイルなどの構成ファイルを選択して「実行」をクリックします。

4. 必要に応じてファイルを編集します。

5. 設定を確認します。設定に問題がない場合、「適用」をクリックして変更を適用します。設定に問題がある場合、または変更を適用しない場合、「元に戻す」をクリックして元の設定に戻します。

6. Oracle HTTP Serverインスタンスの再起動の説明に従って、Oracle HTTP Serverを再起動します。

ファイルが保存され、「サーバーの詳細構成」ページに表示されます。

サーバー・プロパティの指定

Fusion Middleware Controlを使用するか、Oracle HTTP Server構成ファイルを直接編集することによってのみ、Oracle HTTP Serverプロパティを設定可能です。WLSTコマンドを使用してサーバー・プロパティを指定することはできません。

- Fusion Middleware Controlを使用したサーバー・プロパティの指定

- httpd.confファイルの編集によるサーバー・プロパティの指定

Fusion Middleware Controlを使用したサーバー・プロパティの指定

サーバー・プロパティには、ドキュメント・ルート、管理者の電子メール・アドレス、ディレクトリの索引およびオペレーティング・システムの詳細などの項目が含まれます。次の手順に従い、Fusion Middleware Controlを使用してサーバー・プロパティを指定します。

1. 「Oracle HTTP Server」メニューから「管理」を選択します。

2. 「管理」メニューから「サーバー構成」を選択します。

3. 「サーバー構成」ページで、サーバーのプロパティを入力します。

a. 「ドキュメント・ルート」フィールドに、Webサイトから表示できるメイン・ドキュメント・ツリーを構成するドキュメント・ルート・ディレクトリを入力します。

b. 「管理者の電子メール・アドレス」フィールドに、サーバーがクライアントに送信するエラー・メッセージに挿入する電子メール・アドレスを入力します。

c. 「ディレクトリの索引」フィールドにディレクトリの索引を入力します。これは、クライアントがWebサイトに最初にアクセスしたときに表示されるメイン・ページ(indexページ)です。

d. 「モジュール」リージョンを使用して、モジュールを有効化または無効化します。使用可能なモジュールはmod_authnz_fcgiおよびod_proxy_fcgiです。mod_proxy_fcgiの構成についても参照してください。

e. 必要な場合は、「別名」表に別名を作成します。別名は、指定したディレクトリにマップされます。たとえば、あるグループでコンテンツ・ページの特定のセットを使用するため、そのコンテンツ・ページを含むディレクトリに別名を作成できます。

4. 設定を確認します。設定に問題がない場合、「適用」をクリックして変更を適用します。設定に問題がある場合、または変更を適用しない場合、「元に戻す」をクリックして元の設定に戻します。

5. Oracle HTTP Serverインスタンスの再起動の説明に従って、Oracle HTTP Serverを再起動します。

サーバー・プロパティが保存され、「サーバー構成」ページに表示されます。

httpd.confファイルの編集によるサーバー・プロパティの指定

httpd.confファイルを手動で編集することでサーバー・プロパティを指定できます。次の手順に従って、httpd.confファイルを編集してください。

注意:

.confファイルを編集しようとする前に、構成ファイル・ディレクトリのレイアウト、ファイル編集のメカニズムおよびファイル自体の詳細に精通しておく必要があります。この情報については、構成ファイルの理解を参照してください。

1. テキスト・エディタまたはFusion Middleware Controlの「サーバーの詳細構成」ページを使用して、httpd.confファイル(「マスター」または「ステージング」コピー: $DOMAIN_HOME/config/fmwconfig/components/OHS/ohs1/httpd.conf)を開きます。(Oracle HTTP Server構成ファイルの変更を参照してください。)

2. ファイルのDocumentRootセクションに、Webサイトのメイン・コンテンツを格納するディレクトリを入力します。この構文の例を次に示します。

DocumentRoot "${ORACLE_INSTANCE}/config/fmwconfig/components/${COMPONENT_TYPE}/instances/${COMPONENT_NAME}/htdocs"

3. ファイルのServerAdminセクションに、管理者の電子メール・アドレスを入力します。これは、クライアント・ページに表示される電子メール・アドレスです。この構文の例を次に示します。

ServerAdmin WebMaster@example.com

4. ファイルのDirectoryIndexセクションに、ディレクトリの索引を入力します。これは、クライアントがWebサイトに最初にアクセスしたときに表示されるメイン・ページ(indexページ)です。この構文の例を次に示します。

DirectoryIndex index.html index.html.var

5. 必要に応じて別名を作成します。別名は、指定したディレクトリにマップされます。たとえば、アイコンの特定のセットを使用するため、Webページ用のアイコンを含むディレクトリに別名を作成できます。この構文の例を次に示します。

Alias /icons/ "${PRODUCT_HOME}/icons/"<Directory "${PRODUCT_HOME}/icons">    Options Indexes MultiViews    AllowOverride None    Require all granted</Directory>

6. ファイルを保存します。

7. Oracle HTTP Serverインスタンスの再起動の説明に従って、Oracle HTTP Serverを再起動します。

Oracle HTTP Serverインスタンスの構成

この項では、セキュア・ソケット、MIME設定、Oracle WebLogic Serverプロキシ・プラグイン(mod_wl_ohs)、mod_proxy_fcgiおよびその他の、いくつかの共通のOracle HTTP Serverインスタンスの構成プロシージャについて説明します。

注意:

この項には初期のシステム構成情報は含まれていませんので、それらの構成命令の詳細は、『Oracle HTTP Serverのインストールと構成』を参照してください。

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

- Secure Sockets Layerの構成

- スタンドアロン・モードでのSecure Sockets Layerの構成

- WLSTを使用したキーストアのOracle HTTP Serverインスタンスへのエクスポート

- WLSTを使用したアップグレード後のウォレットのKSSデータベースへのインポート

- WLSTを使用したOracle HTTP Serverインスタンスのキーストアとの関連付け

- Fusion Middleware Controlを使用したMIME設定の構成

- mod_proxy_fcgiの構成について

- Oracle WebLogic Serverプロキシ・プラグイン(mod_wl_ohs)の構成について

- 不要なコンテンツへのアクセス権の削除

- apxsコマンドを使用した拡張モジュールのインストール

- Optionsメソッドの無効化

- 共有ファイルシステムでのOracle HTTP Serverコンポーネント構成の更新

注意:

Oracle HTTP Server構成を管理するFusion Middleware Controlおよびその他のOracleソフトウェアは、同等の異なる形式で構成ファイルを保存する可能性があります。ソフトウェアを使用して構成を変更した後に、複数の構成ファイルがリライトされる可能性があります。

Secure Sockets Layerの構成

Secure Sockets Layer (SSL)は、インターネット経由でメッセージを安全に送信することを目的に設計された、暗号化された通信プロトコルです。Oracle HTTP Server間のアプリケーション層およびTCP/IP層にあって、クライアントによってセキュアな接続が確立された場合に暗号化と復号化を透過的に行います。

SSLの一般的な用途の1つは、ブラウザとWebサーバー間のWeb HTTP通信を保護することです。この場合、保護されていないHTTPの使用は排除されません。保護されたバージョンは、単純にHTTP over SSL (HTTPS)と呼ばれます。HTTPSではURLスキームとしてhttp://ではなくhttps://を使用するという点が異なります。Oracle HTTP Serverのデフォルト通信ポートは4443です。Oracle HTTP Serverでは、セキュリティ上の理由から443標準https://特権ポートを使用しません。特権ポートでOracle HTTP Serverを実行する方法の詳細は、特権ポートでのOracle HTTP Serverインスタンスの起動(UNIXのみ)を参照してください。

デフォルトでは、SSLリスニング・ポートはインストール中にデフォルトのウォレットを使用して構成されて有効化されます。ウォレットには、証明書リクエスト、証明書および秘密鍵など、資格証明が格納されます。

Oracle HTTP Serverとともに自動的にインストールされるデフォルトのウォレットは、テスト目的のみに使用されるものです。本番サーバーに対して実際のウォレットを作成する必要があります。デフォルトのウォレットは、DOMAIN_HOME/config/fmwconfig/components/OHS/instances/componentName/keystores/defaultディレクトリにあります。新しいウォレットをこの場所に配置することも、実際のウォレットの場所を示すようにDOMAIN_HOME/config/fmwconfig/components/OHS/componentName/ssl.confのSSLWalletディレクティブを変更することもできます。

変更を有効にするには、Oracle HTTP Serverインスタンスの再起動の説明に従って、Oracle HTTP Serverを再起動します。

Fusion Middleware ControlでウォレットとSSLを構成する方法の詳細は、『Oracle Fusion Middlewareの管理』.の「Oracle HTTP Server仮想ホストに対するSSLの有効化」を参照してください。

スタンドアロン・モードでのSecure Sockets Layerの構成

次の各項では、スタンドアロン・モードでOracle HTTP ServerのSSLを有効化して構成する方法について説明します。これらの手順では、サーバーでSSLを使用できるようにするOracle HTTP Serverに対するmod_osslモジュールを利用します。

- SSLの構成

- サーバー側でのSSLVerifyClientの指定

- Oracle ServerとOracle WebLogic Serverとの間のSSLの有効化

SSLの構成

デフォルトでは、Oracle HTTP ServerをインストールするときにSSLが有効化されます。次のタスクを実行して、SSLを変更および構成します。

- タスク1: 実際のウォレットの作成

- タスク2: (オプション)構成のカスタマイズ

- 基本SSL構成の例

タスク1: 実際のウォレットの作成

SSL用にOracle HTTP Serverを構成するには、サーバーの証明書を含むウォレットが必要です。ウォレットには、証明書リクエスト、証明書および秘密鍵など、資格証明が格納されます。

Oracle HTTP Serverとともに自動的にインストールされるデフォルトのウォレットは、テスト目的のみに使用されるものです。本番サーバーに対して実際のウォレットを作成する必要があります。デフォルトのウォレットは、$ORACLE_INSTANCE/config/fmwconfig/components/$COMPONENT_TYPE/instances/$COMPONENT_NAME/keystores/defaultにあります。新しいウォレットをこの場所に配置することも、実際のウォレットの場所を示すように$ORACLE_INSTANCE/config/fmwconfig/components/$COMPONENT_TYPE/$COMPONENT_NAME/ssl.conf(インストール前の場所)のSSLWalletディレクティブを変更することもできます。

関連項目:

ウォレットを作成する手順については、Oracle Fusion Middlewareの管理のorapkiに関する項を参照してください。次の作業を実行することが重要です。

証明書リクエストを生成します。共通名には、構成しているサイトの名前または別名を指定します。このauto_login_only機能を必ず有効にしてください。

タスク2: (オプション)構成のカスタマイズ

オプションで、mod_osslディレクティブを使用して構成を詳細にカスタマイズすることができます。

関連項目:

- mod_osslで使用できるディレクティブのリストおよび説明は、mod_osslモジュールを参照してください。

- SSLFIPSディレクティブの構成方法および使用できる暗号スイートのリストについては、SSLFIPSディレクティブを参照してください。

注意:

構成時にインストールされたファイルには、すべての必要なSSL構成ディレクティブおよびSSL用のデフォルト設定が含まれています。

基本SSL構成の例

SSL構成には、最低でも次の例のディレクティブが含まれている必要があります。

LoadModule ossl_module        "${PRODUCT_HOME}/modules/mod_ossl.so"
Listen 4443
ServerName www.testohs.com
SSLEngine on
#  SSL Protocol Support:
#  List the supported protocols.
SSLProtocol TLSv1.2 TLSv1.1 TLSv1
#  SSL Cipher Suite:
#  List the ciphers that the client is permitted to negotiate.
SSLCipherSuite  SSL_RSA_WITH_RC4_128_MD5,SSL_RSA_WITH_RC4_128_SHA,SSL_RSA_WITH_3DES_EDE_CBC_SHA,TLS_RSA_WITH_AES_128_CBC_SHA,TLS_RSA_WITH_AES_256_CBC_SHA
SSLWallet "${ORACLE_INSTANCE}/config/fmwconfig/components/${COMPONENT_TYPE}/instances/${COMPONENT_NAME}/keystores/default"
</VirtualHost>To enable client authentication, do the following:

サーバー側でのSSLVerifyClientの指定

アクセスを認証および認可するためのSSLVerifyClientディレクティブの使用には様々な方法があります。HTTPS接続のためにクライアント側で適切なクライアント証明書を使用します。クライアント証明書の取得および使用方法については、クライアントのドキュメントを参照してください。クライアント証明書がサーバー・ウォレットによって信頼されていることを確認してください。

- クライアントによる証明書を使用した強制的な認証

- クライアントによる特定のURLに対する強制的な認証

- 特定のURLに対するクライアントの認可

- 強力な暗号およびCAクライアント証明書またはBasic認証を使用したクライアントの許可

関連項目:

信頼できる証明書をウォレットにインポートする手順については、Oracle Fusion Middlewareの管理ガイドのWLSTを使用した証明書または信頼できる証明書のインポートに関する項を参照してください。

クライアントによる証明書を使用した強制的な認証

クライアントでSSLVerifyClientを使用してそのクライアント証明書を強制的に検証し、サーバーへのアクセスを許可することができます。このシナリオは、サーバー認証局(CA)から提供されたクライアント証明書を持つすべてのクライアントに有効です。サーバーは追加の権限のために、クライアントの提供された証明書をそのCAに対して検証できます。

# require a client certificate which has to be directly
# signed by our CA certificate
SSLVerifyClient require
SSLWallet "${ORACLE_INSTANCE}/config/fmwconfig/components/${COMPONENT_TYPE}/instances/${COMPONENT_NAME}/keystores/default"

クライアントによる特定のURLに対する強制的な認証

クライアントで特定のURLに対して証明書を使用して強制的に認証するには、mod_osslのディレクトリ単位の再構成機能を使用できます。この場合、SSLVerifyClientはLocationブロックに表示されます。

SSLVerifyClient none
SSLWallet "${ORACLE_INSTANCE}/config/fmwconfig/components/${COMPONENT_TYPE}/instances/${COMPONENT_NAME}/keystores/default"
<Location /secure/area>
SSLVerifyClient require
</Location>

特定のURLに対するクライアントの認可

特定のURLに対しクライアントを認証するには、クライアント証明書の一部が、必要としているものに一致していることを確認します。通常これは、識別名(DN)のすべてまたは一部をチェックして、特定の既知の文字列が含まれているかどうかを確認することを意味します。これを実行する方法は2つあり、mod_auth_basicまたはSSLRequireを使用します。

mod_auth_basicを使用する方法は一般的に、証明書が完全に任意である場合、またはそれらの証明書のDNに共通のフィールド(通常、組織など)がない場合に必要になります。この場合、許可されたすべてのクライアントを含むパスワード・データベースを構築する必要があります。たとえば、次のようになります。

SSLVerifyClient      none
<Directory /access/required>
SSLVerifyClient      require
SSLOptions           +FakeBasicAuth
SSLRequireSSL
AuthName             "Oracle Auth"
AuthType             Basic
AuthBasicProvider    file
AuthUserFile         httpd.passwd
Require              valid-user
</Directory>

この例で使用されているパスワードは、DESで暗号化された文字列passwordです。このディレクティブの詳細は、SSLOptionsディレクティブを参照してください。この項では、mod_osslモジュールのSSLOptionsディレクティブについて説明しています。

httpd.passwd

Subject:        OU=Class 3 Public Primary Certification Authority,O=VeriSign\, Inc.,C=US
Subject:        CN=GTE CyberTrust Global Root,OU=GTE CyberTrust Solutions\, Inc.,O=GTE Corporation,C=US
Subject:        CN=localhost,OU=FOR TESTING ONLY,O=FOR TESTING ONLY
Subject:        OU=Class 2 Public Primary Certification Authority,O=VeriSign\, Inc.,C=US
Subject:        OU=Class 1 Public Primary Certification Authority,O=VeriSign\, Inc.,C=US

クライアントがすべてDNにエンコードされる共通階層の一部である場合、SSLRequireを使用してそれらをより簡単に照合することができます。たとえば、次のようになります。

SSLVerifyClient      none
SSLWallet "${ORACLE_INSTANCE}/config/fmwconfig/components/${COMPONENT_TYPE}/instances/${COMPONENT_NAME}/keystores/default"

<Directory /access/required>
SSLVerifyClient      require
SSLOptions           +FakeBasicAuth
SSLRequireSSL
SSLRequire       %{SSL_CLIENT_S_DN_O}  eq "VeriSign\, Inc." \
and %{SSL_CLIENT_S_DN_OU} in {"Class", "Public", "Primary"}
</Directory>

強力な暗号およびCAクライアント証明書またはBasic認証を使用したクライアントの許可

次の例では、イントラネット上のクライアントが範囲192.168.1.0/24内のIPを持ち、またインターネット・アクセスを許可するイントラネットWebサイトの一部が/access/requiredであると仮定しています。この構成は、HTTPS仮想ホストの外側に残す必要があります。これにより、HTTPSとHTTPの両方に適用されます。

SSLWallet "$ORACLE_INSTANCE/config/fmwconfig/components/$COMPONENT_TYPE/instances/$COMPONENT_NAME/keystores/default"
<Directory  /access/required>
#   Outside the subarea only Intranet access is granted
Require              ip 192.168.1.0/24
</Directory>

<Directory  /access/required>
#   Inside the subarea any Intranet access is allowed
#   but from the Internet only HTTPS + Strong-Cipher + Password
#   or the alternative HTTPS + Strong-Cipher + Client-Certificate

#   If HTTPS is used, make sure a strong cipher is used.
#   Additionally allow client certs as alternative to basic auth.
SSLVerifyClient      optional
SSLOptions           +FakeBasicAuth +StrictRequire
SSLRequire           %{SSL_CIPHER_USEKEYSIZE}>= 128
#   Force clients from the Internet to use HTTPS
RewriteEngine        on
RewriteCond          %{REMOTE_ADDR} !^192\.168\.1\.[0-9]+$
RewriteCond          %{HTTPS} !=on
RewriteRule          . - [F]
#   Allow Network Access and/or Basic Auth
Satisfy              any

#   Network Access Control
Require              ip 192.168.1.0/24
#   HTTP Basic Authentication
AuthType             basic
AuthName             "Protected Intranet Area"
AuthBasicProvider    file
AuthUserFile         htpasswd
Require              valid-user
</Directory>

Oracle ServerとOracle WebLogic Serverとの間のSSLの有効化

HTTP ServerとOracle WebLogic Serverとの間のSSLを有効化するには、Oracle WebLogic Serverプロキシ・プラグインを使用します。このプラグインを使用すると、SSLライブラリを構成して、一方向と双方向のSSL通信を構成できます。詳細は、『Oracle WebLogic Serverプロキシ・プラグイン12.2.1の使用』のプラグインとSSLの併用に関する項およびOracle WebLogic Serverプロキシ・プラグインのパラメータに関する項を参照してください。

WLSTを使用したキーストアのOracle HTTP Serverインスタンスへのエクスポート

カスタムWLSTコマンドohs_exportKeyStoreを使用して、キーストアを指定したOracle HTTP Serverインスタンスの場所にエクスポートします。このコマンドの詳細は、ohs_exportKeyStoreを参照してください。

注意:

キーストアの名前を管理する命名規則があります。詳細は、キーストアの命名規則を参照してください

1. コマンド行からWLSTを起動します。

LinuxまたはUNIX: $ORACLE_HOME/oracle_common/common/bin/wlst.sh

Windows: $ORACLE_HOME\oracle_common\common\bin\wlst.cmd

2. 管理サーバー・インスタンスに接続します。

connect('<userName', '<password>', '<host>:<port>')

3. 次のようにohs_exportKeyStoreカスタムWLSTコマンドを実行します。

ohs_exportKeyStore(keyStoreName = '<keystore_name>', instanceName = '<name_of_the_OHS_instance>')

たとえば、キーストアohs1_myKeystoreをOracle HTTP Serverインスタンスohs1にエクスポートします。

ohs_exportKeyStore(keyStoreName = 'ohs1_myKeystore', instanceName = 'ohs1')

WLSTを使用したアップグレード後のウォレットのKSSデータベースへのインポート

アップグレード・アシスタントを使用して前のバージョンのOracle HTTP Serverからリリース12c (12.2.1)にアップグレードする場合、いくつかの追加のウォレット管理を実行する必要があります。ohs_postUpgradeコマンドを使用してOracle HTTP ServerインスタンスのウォレットをKSSデータベースにインポートします。

このコマンドではドメイン内のすべてのOracle HTTP Serverインスタンス間で解析が行われ、同じキーストア名に対するエントリがデータベースに存在しない場合、ウォレットがKSSデータベースにインポートされます。このコマンドの詳細は、ohs_postUpgradeを参照してください。

1. コマンド行からWLSTを起動します。

LinuxまたはUNIX: $ORACLE_HOME/oracle_common/common/bin/wlst.sh

Windows: $ORACLE_HOME\oracle_common\common\bin\wlst.cmd

2. 管理サーバー・インスタンスに接続します。

connect('<userName', '<password>', '<host>:<port>')

3. ohs_postUpgrade()カスタムWLSTコマンドを実行します。次に例を示します。

ohs_postUpgrade()

WLSTを使用したOracle HTTP Serverインスタンスのキーストアとの関連付け

構成ウィザードを使用してコロケート・モードでOracle HTTP Serverインスタンスを作成した後で、ohs_updateInstancesカスタムWLSTコマンドを使用してインスタンスとキーストアを関連付けます。

このコマンドでは、ドメイン内のすべてのOracle HTTP Serverインスタンス間で解析が行われ、次のタスクが実行されます。

- 存在しない場合、新しいキーストアが<instanceName>_defaultという名前で作成されます。

- 新しく作成したキーストアにデモンストレーション用の証明書demoCASignedCertificateを入れます。

- キーストアをインスタンスの場所にエクスポートします。

このコマンドの詳細は、ohs_updateInstancesを参照してください。

Oracle HTTP Serverインスタンスとキーストアを関連付けるには、次の手順を実行します。

1. コマンド行からWLSTを起動します。

LinuxまたはUNIX: $ORACLE_HOME/oracle_common/common/bin/wlst.sh

Windows: $ORACLE_HOME\oracle_common\common\bin\wlst.cmd

2. 管理サーバー・インスタンスに接続します。

connect('<userName', '<password>', '<host>:<port>')

3. ohs_updateInstancesカスタムWLSTコマンドを実行します。次に例を示します。

ohs_updateInstances()

Fusion Middleware Controlを使用したMIME設定の構成

Oracle HTTP Serverでは、Multipurpose Internet Mail Extension (MIME)設定を使用してファイル・タイプ、エンコーディングおよび言語の解析を行います。Oracle HTTP ServerのMIME設定は、Fusion Middleware Controlでのみ指定できます。WLSTコマンドを使用してMIME設定を指定することはできません。

「MIME構成」ページでは、次のタスクを実行できます。

- MIMEタイプの構成

- MIMEエンコーディングの構成

- MIME言語の構成

MIMEタイプの構成

MIMEタイプにより、指定されたコンテンツ・タイプに特定のファイル拡張子がマップされます。MIMEタイプは、拡張子を含むファイル名に使用されます。

Fusion Middleware Controlを使用してMIMEタイプを構成するには、次の手順を実行します。

1. 「Oracle HTTP Server」メニューから「管理」を選択します。

2. 「管理」メニューから「MIME構成」を選択します。「MIME構成」ページが表示されます。「MIMEタイプ」リージョンにスクロールします。

3. 「MIME構成」リージョンの「行の追加」をクリックします。新規の空白行がリストに追加されます。

4. MIMEタイプおよびそれに関連付けられたファイル拡張子を入力します。

5. 設定を確認します。設定に問題がない場合、「適用」をクリックして変更を適用します。設定に問題がある場合、または変更を適用しない場合、「元に戻す」をクリックして元の設定に戻します。

6. Oracle HTTP Serverインスタンスの再起動の説明に従って、Oracle HTTP Serverを再起動します。

MIME構成が保存され、「MIME構成」ページに表示されます。

MIMEエンコーディングの構成

MIMEエンコーディングにより、Oracle HTTP Serverでは、ファイル拡張子に基づいてファイル・タイプを判別できます。MIMEエンコーディングは、追加および削除できます。エンコーディング・ディレクティブにより、指定のエンコーディング・タイプにファイル拡張子をマップします。

1. 「Oracle HTTP Server」メニューから「管理」を選択します。

2. 「管理」メニューから「MIME構成」を選択します。「MIME構成」ページが表示されます。「MIMEエンコーディング」リージョンにスクロールします。

3. 必要に応じて、「MIMEエンコーディング」の横にあるプラス記号(+)をクリックして「MIMEエンコーディング」リージョンを開きます。

4. 「MIMEエンコーディング」リージョンの「行の追加」をクリックします。新規の空白行がリストに追加されます。

5. MIMEエンコーディング(x-gzipなど)を入力します。

6. ファイル拡張子(.gxなど)を入力します。

7. 設定を確認します。設定に問題がない場合、「適用」をクリックして変更を適用します。設定に問題がある場合、または変更を適用しない場合、「元に戻す」をクリックして元の設定に戻します。

8. Oracle HTTP Serverインスタンスの再起動の説明に従って、Oracle HTTP Serverを再起動します。

MIME言語の構成

MIME言語設定により、特定の言語にファイル拡張子がマップされます。このディレクティブは、一般的にコンテンツ・ネゴシエーションに使用されます(クライアントにより設定されたプリファレンスに対する一致度が最も高いドキュメントがOracle HTTP Serverから返されます)。

1. 「Oracle HTTP Server」メニューから「管理」を選択します。

2. 「管理」メニューから「MIME構成」を選択します。「MIME構成」ページが表示されます。「MIME言語」リージョンにスクロールします。

3. 必要に応じて、「MIME言語」の横にあるプラス記号(+)をクリックして「MIME言語」リージョンを開きます。

4. 「MIME言語」リージョンの「行の追加」をクリックします。新規の空白行がリストに追加されます。

5. MIME言語(en-USなど)を入力します。

6. ファイル拡張子(en-usなど)を入力します。

7. デフォルトのMIME言語を選択するには、必要な行を選択し、「デフォルトとして設定」をクリックします。デフォルト言語が「デフォルトのMIME言語」フィールドに表示されます。

8. 設定を確認します。設定に問題がない場合、「適用」をクリックして変更を適用します。設定に問題がある場合、または変更を適用しない場合、「元に戻す」をクリックして元の設定に戻します。

9. Oracle HTTP Serverインスタンスの再起動の説明に従って、Oracle HTTP Serverを再起動します。

mod_proxy_fcgiの構成について

mod_proxy_fcgiモジュールに構成ディレクティブはありません。そのかわりに、mod_proxyモジュール上のディレクティブ・セットを使用します。mod_fcgidおよびmod_fastcgiモジュールとは異なり、mod_proxy_fcgiモジュールにはアプリケーション・プロセスの開始のプロビジョニングはありません。mod_proxy_fcgiの目的は、より速いパフォーマンスのためにこの機能をWebサーバーの外に移動することです。そのため、mod_proxy_fcgiは外部FastCGIサーバーへのリバース・プロキシとして動作するだけです。

mod_proxy_fcgiモジュールの構成の詳細は、タスク3: mod_proxy_fcgiを外部FastCGIサーバーへのリバース・プロキシとして動作するように構成およびタスク4: 外部FastCGI Serverの設定を参照してください。

Oracle WebLogic Serverプロキシ・プラグイン(mod_wl_ohs)の構成について

Oracle WebLogic Serverプロキシ・プラグイン(mod_wl_ohs)を構成するには、Fusion Middleware Controlを使用するか、またはmod_wl_ohs.conf構成ファイルを手動で編集します。

リクエストをOracle HTTP ServerからOracle WebLogic ServerにプロキシできるようにOracle WebLogic Serverプロキシ・プラグインを構成する際の前提条件と手順の詳細は、『Oracle WebLogic Serverプロキシ・プラグイン12.2.1の使用』のOracle HTTP ServerのWebLogicプロキシ・プラグインの構成に関する項を参照してください。

mod_wl_ohsのSSLの構成

Secure Sockets Layer (SSL)プロトコルを使用することで、プラグインとOracle WebLogic Serverとの間の接続を保護できます。SSLプロトコルによって、プラグインとWebLogic Serverとの間で渡されるデータの機密性と整合性が保持されます。詳細は、『Oracle WebLogic Serverプロキシ・プラグイン12.2.1の使用』のプラグインとSSLの併用に関する項を参照してください。

不要なコンテンツへのアクセス権の削除

デフォルトでは、httpd.confファイルにより、サーバーはドキュメントやサンプル・スクリプトなどの追加のコンテンツにアクセスできます。このアクセスには低いレベルのセキュリティ・リスクが存在する可能性があります。Oracle HTTP Server 12c (12.2.1)リリースから、これらのセクションの一部はコメントアウトされています。

ユースケースに合せて使用環境でのこの追加コンテンツを調整することができます。httpd.confファイルにアクセスするには、構成ファイルの編集についてを参照してください。

- cgi-binセクションの編集

- Fancy Indexingセクションの編集

- 製品ドキュメント・セクションの編集

cgi-binセクションの編集

cgi-binディレクトリのコンテンツを調査します。不要なコードをhttpd.confファイルから削除したり、固有のCGIスクリプト・ディレクトリを指す次のDirectoryディレクティブを変更することができます。

...
#
# "${ORACLE_INSTANCE}/config/fmwconfig/components/${COMPONENT_TYPE}/instances/${COMPONENT_NAME}/cgi-bin" should be changed to whatever your ScriptAliased
# CGI directory exists, if you have that configured.
#
<Directory "${ORACLE_INSTANCE}/config/fmwconfig/components/${COMPONENT_TYPE}/instances/${COMPONENT_NAME}/cgi-bin">
AllowOverride None
Options None
Require all granted
</Directory>
...

Fancy Indexingセクションの編集

ユースケースに応じたhttpd.confファイルのfancy indexingに関する次のセクションを編集します。

...
# Uncomment the following line to enable the fancy indexing configuration
# below.
# Define ENABLE_FANCYINDEXING
<IfDefine ENABLE_FANCYINDEXING>

# IndexOptions: Controls the appearance of server-generated directory
# listings.
#
IndexOptions FancyIndexing HTMLTable VersionSort

# We include the /icons/ alias for FancyIndexed directory listings.  If
# you do not use FancyIndexing, you may comment this out.
#
Alias /icons/ "${PRODUCT_HOME}/icons/"

<Directory "${PRODUCT_HOME}/icons">
Options Indexes MultiViews
AllowOverride None
Require all granted
</Directory>

#
# AddIcon* directives tell the server which icon to show for different
# files or filename extensions.  These are only displayed for
# FancyIndexed directories.
#
AddIconByEncoding (CMP,/icons/compressed.gif) x-compress x-gzip

AddIconByType (TXT,/icons/text.gif) text/*
AddIconByType (IMG,/icons/image2.gif) image/*
AddIconByType (SND,/icons/sound2.gif) audio/*
AddIconByType (VID,/icons/movie.gif) video/*

AddIcon /icons/binary.gif .bin .exe
AddIcon /icons/binhex.gif .hqx
AddIcon /icons/tar.gif .tar
AddIcon /icons/world2.gif .wrl .wrl.gz .vrml .vrm .iv
AddIcon /icons/compressed.gif .Z .z .tgz .gz .zip
AddIcon /icons/a.gif .ps .ai .eps
AddIcon /icons/layout.gif .html .shtml .htm .pdf
AddIcon /icons/text.gif .txt
AddIcon /icons/c.gif .c
AddIcon /icons/p.gif .pl .py
AddIcon /icons/f.gif .for
AddIcon /icons/dvi.gif .dvi
AddIcon /icons/uuencoded.gif .uu
AddIcon /icons/script.gif .conf .sh .shar .csh .ksh .tcl
AddIcon /icons/tex.gif .tex
AddIcon /icons/bomb.gif core

AddIcon /icons/back.gif ..
AddIcon /icons/hand.right.gif README
AddIcon /icons/folder.gif ^^DIRECTORY^^
AddIcon /icons/blank.gif ^^BLANKICON^^

#
# DefaultIcon is which icon to show for files which do not have an icon
# explicitly set.
#
DefaultIcon /icons/unknown.gif

#
# AddDescription allows you to place a short description after a file in
# server-generated indexes.  These are only displayed for FancyIndexed
# directories.
# Format: AddDescription "description" filename
#
#AddDescription "GZIP compressed document" .gz
#AddDescription "tar archive" .tar
#AddDescription "GZIP compressed tar archive" .tgz
...

#
# ReadmeName is the name of the README file the server will look for by
# default, and append to directory listings.
#
# HeaderName is the name of a file which should be prepended to
# directory indexes.
ReadmeName README.html
HeaderName HEADER.html

#
# IndexIgnore is a set of filenames which directory indexing should ignore
# and not include in the listing.  Shell-style wildcarding is permitted.
#
IndexIgnore .??* *~ *# HEADER* README* RCS CVS *,v *,t
</IfDefine>

製品ドキュメント・セクションの編集

Define MANUAL_ENABLE行をアンコメントにして、製品ドキュメントの手動での構成を有効にします。

...
#
# Uncomment the following line to enable the manual configuration below.
# Define ENABLE_MANUAL
<IfDefine ENABLE_MANUAL>
AliasMatch ^/manual(?:/(?:de|en|es|fr|ja|ko|pt-br|ru|tr))?(/.*)?$ "${PRODUCT_HOME}/manual$1"

<Directory "${PRODUCT_HOME}/manual">
Options Indexes
AllowOverride None
Require all granted

<Files *.html>
SetHandler type-map
</Files>
# .tr is text/troff in mime.types!
<Files *.html.tr.utf8>
ForceType text/html
</Files>

SetEnvIf Request_URI ^/manual/(de|en|es|fr|ja|ko|pt-br|ru|tr)/ prefer-language=$1
RedirectMatch 301 ^/manual(?:/(de|en|es|fr|ja|ko|pt-br|ru|tr)){2,}(/.*)?$ /manual/$1$2

LanguagePriority en de es fr ja ko pt-br ru tr
ForceLanguagePriority Prefer Fallback
</Directory>
</IfDefine>

apxsコマンドを使用した拡張モジュールのインストール

注意:

このコマンドはUNIXとLinux専用であり、ソース・コード形式で提供されているモジュールに対してのみ使用する必要があります。バイナリ形式で提供されているモジュールのインストール手順に従ってください。

apxsコマンドの詳細は、次のApache HTTP Serverのドキュメントを参照してください。

http://httpd.apache.org/docs/2.4/programs/apxs.html

Apache拡張ツール(apxs)では、Oracle HTTP Server用のApache HTTP Server拡張モジュールをビルドおよびインストールできます。apxsは、モジュールをORACLE_HOME/ohs/modulesディレクトリにインストールし、このインストールから実行されるOracle HTTP Serverインスタンスがアクセスできるようにします。

注意:

いったんなんらかのサードパーティ製モジュールの生成とロードが行われると、Oracle HTTP Serverサポート・ポリシーに記載されたサードパーティ条件に該当することになります。この手順を続ける前に、このポリシーをお読みください。詳細は、Oracle HTTP Serverのサポートを参照してください。

Oracle HTTP Serverで使用する場合に推奨されるapxsオプションを次に示します。

オプション

用途

コマンド例

-c

モジュール・ソースのコンパイル

$ORACLE_HOME/ohs/bin/apxs -c mod_example.c

-i

ORACLE_HOMEへのモジュール・バイナリのインストール

$ORACLE_HOME/ohs/bin/apxs -ci mod_example.c

モジュール・バイナリがORACLE_HOMEにインストールされると、httpd.confファイルまたはその他の構成ファイルのLoadModuleディレクティブによりモジュールがサーバー・プロセスにロードされます。次に例を示します。

LoadModule example_module "${ORACLE_HOME}/ohs/modules/mod_example.so"

このディレクティブは、モジュールをロードする必要があるすべてのインスタンスの構成で必須です。

-aまたは-Aオプションが指定されている場合、apxsはhttpd.confを編集してモジュールのLoadModuleディレクティブを追加します。WebLogic Serverドメインの一部であるOracle HTTP Serverインスタンスでは-aおよび-Aオプションを使用しないでください。かわりに、Oracle HTTP Server構成ファイルの変更の説明に従って、Fusion Middleware Controlを使用して構成を更新します。

スタンドアロン・ドメインの一部であるOracle HTTP Serverインスタンスでは、apxsの起動前にCONFIG_FILE_PATH環境変数がインスタンスのステージング・ディレクトリに設定されている場合、-aまたは-Aオプションを使用できます。次に例を示します。

CONFIG_FILE_PATH=$ORACLE_HOME/user_projects/domains/base_domain/config/fmwconfig/components/OHS/ohs1
export CONFIG_FILE_PATH
$ORACLE_HOME/ohs/bin/apxs -cia mod_example.c

デフォルトでは、apxsは、/usr/binにあるPerlインタプリタを使用します。apxsが製品のインストールを見つけることができない場合または/usr/bin/perlの使用時にその他の操作エラーが発生した場合は、次のようにapxsを起動することによってMiddlewareホーム内でPerlインタプリタを使用します。

$ORACLE_HOME/perl/bin/perl $ORACLE_HOME/ohs/bin/apxs -c mod_example.c

多くの場合、モジュールは正常に機能するためにLoadModule以外のディレクティブも必要とします。モジュールがインストールされ、LoadModuleディレクティブを使用してロードされた後、その他の構成要件についてモジュールのドキュメントを参照してください。

Optionsメソッドの無効化

Optionsメソッドにより、クライアントは、Webサーバーでサポートされるメソッドを確認できます。これが有効の場合、HTTPレスポンス・ヘッダーのAllow行に出力されます。

たとえば、次のようなリクエストを送信するとします。

---- Request -------
OPTIONS / HTTP/1.0
Content-Length: 0
Accept: */*
Accept-Language: en-US
User-Agent: Mozilla/4.0 (compatible; MSIE 6.0; Win32)
Host: host123:80

この場合、Webサーバーから次のようなレスポンスが返されます。

---- Response --------
HTTP/1.1 200 OK
Date: Wed, 23 Apr 2008 20:20:49 GMT
Server: Oracle-Application-Server-11g/11.1.1.0.0 Oracle-HTTP-Server
Allow: GET,HEAD,POST,OPTIONS
Content-Length: 0
Connection: close
Content-Type: text/html

一部のソースでは、Optionsメソッドを公開することはセキュリティ上のリスクが低いと考えられます。悪質なクライアントは、このメソッドを使用してWebサーバーでサポートされるメソッドを判断できます。ただし、Webサーバーでサポートされるメソッドの数は限られているため、このメソッドを無効にしても悪質なクライアントに対して時間稼ぎとなるだけで、攻撃をやめさせることはできません。また、Optionsメソッドは、正当なクライアントによって使用されることもあります。

Oracle Fusion Middleware環境にOptionsメソッドを必要とするクライアントが存在しない場合、httpd.confファイルに次の行を追加してこのメソッドを無効化できます。

<IfModule mod_rewrite.c>
RewriteEngine on
RewriteCond %{REQUEST_METHOD} ^OPTIONS
RewriteRule .* – [F]
</IfModule>

共有ファイルシステムでのOracle HTTP Serverコンポーネント構成の更新

NFS(ネットワーク・ファイルシステム)などの共有ファイルシステムでOracle HTTP Serverコンポーネントが作成される際、機能上またはパフォーマンス上の問題が発生する場合があります。特に、Oracle HTTP Serverで使用されるロック・ファイルまたはUNIXソケットが機能しない、またはそのパフォーマンスが大幅に低下する可能性があります。また、mod_wl_ohsでルーティングされるOracle WebLogic Serverリクエストが、デフォルト構成のファイルシステム・アクセスが原因で、パフォーマンスが大幅に低下する場合があります。

表5-1に、ロック・ファイルの問題と推奨されるhttpd.confファイルの変更に関する詳細を、オペレーティング・システム別に示します。

表5-1 ロック・ファイルの問題

オペレーティング・システム

説明

httpd.confの変更点

Linux

ロック・ファイルは必要ありません。Sys Vセマフォが、推奨されるプロセス間mutexの実装です。

Mutex fnctl:fileloc defaultをMutex sysvsem defaultに変更します。ここで、filelocはディレクティブMutexの値です(httpd.conf内の3箇所)。

Solaris

ロック・ファイルは必要ありません。プロセス間pthread mutexが、推奨されるプロセス間mutexの実装です。

Mutex fnctl:fileloc defaultをMutex pthread defaultに変更します。ここで、filelocはディレクティブMutexの値です(httpd.conf内の3箇所)。

その他のUNIXプラットフォーム

Mutexディレクティブに指定されたファイルの場所をローカルのファイル・システムを指すように変更します(httpd.conf内の3箇所)。

UNIXソケットの問題

mod_cgidは、デフォルトでは有効になっていません。有効な場合は、ScriptSockディレクティブを使用してmod_cgidのUNIXソケットをローカル・ファイルシステムに配置します。

mod_securityモジュールの構成

オープン・ソースのmod_securityモジュールを使用してOracle HTTP Serverに対する侵入攻撃を検出および防止できます。たとえば、mod_securityルールを指定して、すべての受信リクエストをスクリーニングし、ルールで指定された条件に一致するリクエストを拒否することができます。mod_securityモジュール(バージョン2.8.0)とその前提条件は、mod_security2.soという共有オブジェクトとして、ORACLE_HOME/ohs/modulesディレクトリ内のOracle HTTP Serverインストールに含まれています。

このリリースのOracle HTTP Serverは、mod_security (バージョン2.8.0)のディレクティブ、変数、アクション、フェーズおよび関数のみをサポートしています。このモジュールをより新しいバージョンに置き換えると、これらはサポートされなくなります。

詳細は、次を参照してください。

http://www.modsecurity.org/documentation/

サンプルmod_secuirity.confファイルでは、LoadModule文を含む、mod_security.confファイルの使用可能な例について説明します。

注意:

次の点に注意してください。

- mod_securityは、以前のバージョンのOracle HTTP Serverで削除されましたが、バージョン11.1.1.7で再度搭載されました。このバージョンはオープン・ソースのmod_security 2.8.0で定められた推奨およびプラクティスに従っています。オープン・ソースのmod_security 2.8.0に適用可能なドキュメントのみが、モジュールのOracle HTTP Server実装にも適用できます。

- Oracle HTTP Server 11.1.1.7以上では、mod_securityはデフォルトではロードまたは構成されませんが、インストールに11.1.1.6からのパッチを適用している場合は、パッチの実装によってモジュールがロードおよび構成されている可能性があります。

- Oracleでは、Oracle提供のmod_securityのみがサポートされています。modsecurity.orgが提供するより新しいバージョンはサポートされません。

mod_security構成はhttpd.conf構成ファイルに追加することも、別個のmod_security.conf構成ファイルに表示することもできます。

この項には次の情報が含まれます:

- httpd.confファイルのmod_securityの構成

- mod_security.confファイルのmod_securityの構成

- サンプルmod_secuirity.confファイル

httpd.confファイルのmod_securityの構成

IfModuleコンテナのhttpd.confファイルにmod_securityディレクティブを入力することで、mod_securityモジュールを構成できます。Oracle HTTP Serverの実行時にmod_securityモジュールを使用できるようにするには、mod_security構成が次の行で開始されていることを確認します。

...
#Load module
LoadModule security2_module "${PRODUCT_HOME}/modules/mod_security2.so"
...

mod_security.confファイルのmod_securityの構成

別個のmod_security.confファイルにmod_securityディレクティブを指定し、Includeディレクティブを使用してhttpd.confファイルにその.confファイルを含めることもできます。

1. できればサンプルmod_secuirity.confファイルのテンプレートを使用して、mod_security.confファイルを自身で作成する必要があります。

テキスト・エディタにサンプルをコピーして貼り付け、使用しているシステム用に編集します。

2. Oracle HTTP Serverの実行時にmod_securityモジュールを使用できるようにするには、mod_security.confが次の行で開始されていることを確認します。

#Load module
LoadModule security2_module "${PRODUCT_HOME}/modules/mod_security2.so"

3. 「mod_security.conf」という名前でファイルを保存し、Includeディレクティブを使用してそれをhttpd.confファイルに含めることができます。

記載の手順に従ってmod_security.confファイルを実装する場合は、LoadModuleディレクティブを使用してmod_security2.soを実行環境にロードします。

サンプルmod_secuirity.confファイル

次のコードは、サンプルのmod_security.conf構成ファイルを示しています。

例5-1 mod_security.confの例

#Load module
LoadModule security2_module "${PRODUCT_HOME}/modules/mod_security2.so"
# -- Rule engine initialization ----------------------------------------------

# Enable ModSecurity, attaching it to every transaction. Use detection
# only to start with, because that minimises the chances of post-installation
# disruption.
#
SecRuleEngine DetectionOnly

# -- Request body handling ---------------------------------------------------

# Allow ModSecurity to access request bodies. If you don't, ModSecurity
# won't be able to see any POST parameters, which opens a large security
# hole for attackers to exploit.
#
SecRequestBodyAccess On

# Enable XML request body parser.
# Initiate XML Processor in case of xml content-type
#
SecRule REQUEST_HEADERS:Content-Type "text/xml" "id:'200000',phase:1,t:none,t:lowercase,pass,nolog,ctl:requestBodyProcessor=XML"

# Maximum request body size we will accept for buffering. If you support
# file uploads then the value given on the first line has to be as large
# as the largest file you are willing to accept. The second value refers
# to the size of data, with files excluded. You want to keep that value as
# low as practical.
#
SecRequestBodyLimit 13107200
SecRequestBodyNoFilesLimit 131072

# Store up to 128 KB of request body data in memory. When the multipart
# parser reachers this limit, it will start using your hard disk for
# storage. That is slow, but unavoidable.
#
SecRequestBodyInMemoryLimit 131072

# What do do if the request body size is above our configured limit.
# Keep in mind that this setting will automatically be set to ProcessPartial
# when SecRuleEngine is set to DetectionOnly mode in order to minimize
# disruptions when initially deploying ModSecurity.
#
SecRequestBodyLimitAction Reject

# Verify that we've correctly processed the request body.
# As a rule of thumb, when failing to process a request body
# you should reject the request (when deployed in blocking mode)
# or log a high-severity alert (when deployed in detection-only mode).
#
SecRule REQBODY_ERROR "!@eq 0" \
"id:'200001', phase:2,t:none,log,deny,status:400,msg:'Failed to parse request
body.',logdata:'%{reqbody_error_msg}',severity:2"

# By default be strict with what we accept in the multipart/form-data
# request body. If the rule below proves to be too strict for your
# environment consider changing it to detection-only. You are encouraged
# _not_ to remove it altogether.
#
SecRule MULTIPART_STRICT_ERROR "!@eq 0" \
"id:'200002',phase:2,t:none,log,deny,status:44, \
msg:'Multipart request body failed strict validation: \
PE %{REQBODY_PROCESSOR_ERROR}, \
BQ %{MULTIPART_BOUNDARY_QUOTED}, \
BW %{MULTIPART_BOUNDARY_WHITESPACE}, \
DB %{MULTIPART_DATA_BEFORE}, \
DA %{MULTIPART_DATA_AFTER}, \
HF %{MULTIPART_HEADER_FOLDING}, \
LF %{MULTIPART_LF_LINE}, \
SM %{MULTIPART_MISSING_SEMICOLON}, \
IQ %{MULTIPART_INVALID_QUOTING}, \
IP %{MULTIPART_INVALID_PART}, \
IH %{MULTIPART_INVALID_HEADER_FOLDING}, \
FL %{MULTIPART_FILE_LIMIT_EXCEEDED}'"

# Did we see anything that might be a boundary?
#
SecRule MULTIPART_UNMATCHED_BOUNDARY "!@eq 0" \
"id:'200003',phase:2,t:none,log,deny,status:44,msg:'Multipart parser detected a possible unmatched boundary.'"

# PCRE Tuning
# We want to avoid a potential RegEx DoS condition
#
SecPcreMatchLimit 1000
SecPcreMatchLimitRecursion 1000

# Some internal errors will set flags in TX and we will need to look for these.
# All of these are prefixed with "MSC_".  The following flags currently exist:
#
# MSC_PCRE_LIMITS_EXCEEDED: PCRE match limits were exceeded.
#
SecRule TX:/^MSC_/ "!@streq 0" \
"id:'200004',phase:2,t:none,deny,msg:'ModSecurity internal error flagged: %{MATCHED_VAR_NAME}'"

# -- Response body handling --------------------------------------------------

# Allow ModSecurity to access response bodies.
# You should have this directive enabled in order to identify errors
# and data leakage issues.
#
# Do keep in mind that enabling this directive does increases both
# memory consumption and response latency.
#
SecResponseBodyAccess On

# Which response MIME types do you want to inspect? You should adjust the
# configuration below to catch documents but avoid static files
# (e.g., images and archives).
#
SecResponseBodyMimeType text/plain text/html text/xml

# Buffer response bodies of up to 512 KB in length.
SecResponseBodyLimit 524288

# What happens when we encounter a response body larger than the configured
# limit? By default, we process what we have and let the rest through.
# That's somewhat less secure, but does not break any legitimate pages.
#
SecResponseBodyLimitAction ProcessPartial

# -- Filesystem configuration ------------------------------------------------

# The location where ModSecurity stores temporary files (for example, when
# it needs to handle a file upload that is larger than the configured limit).
#
# This default setting is chosen due to all systems have /tmp available however,
# this is less than ideal. It is recommended that you specify a location that's private.
#
SecTmpDir /tmp/

# The location where ModSecurity will keep its persistent data.  This default setting
# is chosen due to all systems have /tmp available however, it
# too should be updated to a place that other users can't access.
#
SecDataDir /tmp/

# -- File uploads handling configuration -------------------------------------

# The location where ModSecurity stores intercepted uploaded files. This
# location must be private to ModSecurity. You don't want other users on
# the server to access the files, do you?
#
#SecUploadDir /opt/modsecurity/var/upload/

# By default, only keep the files that were determined to be unusual
# in some way (by an external inspection script). For this to work you
# will also need at least one file inspection rule.
#
#SecUploadKeepFiles RelevantOnly

# Uploaded files are by default created with permissions that do not allow
# any other user to access them. You may need to relax that if you want to
# interface ModSecurity to an external program (e.g., an anti-virus).
#
#SecUploadFileMode 0600

# -- Debug log configuration -------------------------------------------------

# The default debug log configuration is to duplicate the error, warning
# and notice messages from the error log.
#
#SecDebugLog /opt/modsecurity/var/log/debug.log
#SecDebugLogLevel 3

# -- Audit log configuration -------------------------------------------------

# Log the transactions that are marked by a rule, as well as those that
# trigger a server error (determined by a 5xx or 4xx, excluding 404,
# level response status codes).
#
SecAuditEngine RelevantOnly
SecAuditLogRelevantStatus "^(?:5|4(?!04))"

# Log everything we know about a transaction.
SecAuditLogParts ABIJDEFHZ

# Use a single file for logging. This is much easier to look at, but
# assumes that you will use the audit log only ocassionally.
#
SecAuditLogType Serial
SecAuditLog "${ORACLE_INSTANCE}/servers/${COMPONENT_NAME}/logs/modsec_audit.log"

# Specify the path for concurrent audit logging.
SecAuditLogStorageDir "${ORACLE_INSTANCE}/servers/${COMPONENT_NAME}/logs"
#Simple test
SecRule ARGS "\.\./" "t:normalisePathWin,id:99999,severity:4,msg:'Drive Access'"

# -- Miscellaneous -----------------------------------------------------------

# Use the most commonly used application/x-www-form-urlencoded parameter
# separator. There's probably only one application somewhere that uses
# something else so don't expect to change this value.
#
SecArgumentSeparator &

# Settle on version 0 (zero) cookies, as that is what most applications
# use. Using an incorrect cookie version may open your installation to
# evasion attacks (against the rules that examine named cookies).
#
SecCookieFormat 0

# Specify your Unicode Code Point.
# This mapping is used by the t:urlDecodeUni transformation function
# to properly map encoded data to your language. Properly setting
# these directives helps to reduce false positives and negatives.
#
#SecUnicodeCodePage 20127
#SecUnicodeMapFile unicode.mapping

6 サーバー・プロセスの管理およびモニタリング

この章では、Oracle HTTP Serverを管理およびモニターする方法について説明します。また、現在の環境でサーバーを管理するための手順とツールについても説明します。

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

- Oracle HTTP Serverの処理モデル

- サーバーのパフォーマンスのモニタリング

- Oracle HTTP Serverのパフォーマンス・ディレクティブ

- UNIXのプロセス・セキュリティの理解

Oracle HTTP Serverの処理モデル

次の各項で、Oracle HTTP Serverの処理モデルについて説明します。

- リクエスト処理モデル

- 単一ユニットの処理モデル

リクエスト処理モデル

Oracle HTTP Serverを起動すると、HTTP(S)リクエストをリスニングしてレスポンスを返す準備ができたことになります。Microsoft Windowsシステムでのリクエスト処理モデルは、UNIXシステムでのモデルとは異なります。

- Microsoft Windowsの場合は、親プロセスと子プロセスが1つずつあります。子プロセスにより、クライアント・リクエストのハンドリングを担当するスレッドが作成されます。作成されるスレッドの数は静的で、パフォーマンス向上のために構成可能です。

- UNIXの場合、複数の子プロセスを管理する親プロセスは1つです。子プロセスは、リクエストのハンドリングを担当します。親プロセスは、構成に基づき、必要に応じて追加の子プロセスを作成します。サーバーでは動的に追加の子プロセスを開始できますが、追加の子プロセスを作成しなくても、リクエストを処理できる十分な子プロセスを最初から開始するようにサーバーを構成することが最善策です。

単一ユニットの処理モデル

Oracle HTTP Serverは、親プロセスに障害が発生した場合に単一ユニットとして終了する機能が備わっています。親プロセスは、Oracle HTTP Serverインスタンスのすべての子プロセスを起動および停止する役割を持ちます。子プロセスを停止する前に親プロセスに障害が発生すると、Oracle HTTP Serverは不整合な状態になります。この状態を修正するには、親のないすべての子プロセスを手動で停止するしかありません。新しいOracle HTTP Serverインスタンスがアクセスする必要のあるポートは親のない子プロセスによってまだ占有されているため、すべての子プロセスを閉じるまで、新しいOracle HTTP Serverを起動することはできません。

この状況を回避するため、UNIXでは子プロセス内のDMSインストゥルメンテーション・レイヤーにより、WindowsではWinNT MPM内のモニター機能により、親プロセスがモニターされます。親プロセスの障害発生が検出されると、残りの子プロセスはすべて停止されます。

サーバーのパフォーマンスのモニタリング

Oracle Fusion Middlewareは、Oracle HTTP ServerおよびOracle WebLogic Serverプロキシ・プラグイン・モジュールの実行時パフォーマンスを自動的かつ継続的に測定します。パフォーマンス・メトリックは自動的に有効になるため、メトリックを収集するためにオプションの設定や追加構成の実行は必要ありません。アプリケーションの実行速度が遅い、アプリケーションがハングするなどの問題が発生した場合は、特定のメトリックを表示して、その問題の詳細情報を調べることができます。

Fusion Middleware Controlにはリアルタイム・データが表示されます。履歴データを表示する必要がある場合は、Cloud Controlの使用を検討してください。

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

- Oracle HTTP Serverパフォーマンス・メトリック

- パフォーマンス・メトリックの表示

Oracle HTTP Serverパフォーマンス・メトリック

この項では、Oracle HTTP Serverのパフォーマンス分析に役立つ、最もよく使用されるメトリックを示します。

OHSサーバー・メトリック

「OHSサーバー・メトリック」フォルダには、Oracle HTTP Serverのパフォーマンス・メトリック・オプションが含まれます。次の表に、「OHSサーバー・メトリック」フォルダに含まれるメトリックを示します。

要素

説明

CPU使用率

CPU使用率とアイドル時間

メモリー使用量

メモリー使用量と空きメモリー(MB単位)

プロセス

ビジーおよびアイドル・プロセス・メトリック

リクエスト・スループット

リクエスト/秒単位で測定されたリクエスト・スループット

リクエスト処理時間

リクエスト処理時間(秒単位)

レスポンス・データ・スループット

レスポンス・データ・スループット(KB/秒単位)

レスポンス・データ処理

レスポンス・データ処理(KB/レスポンス単位)

アクティブなHTTP接続

アクティブなHTTP接続の数

接続期間

接続時間の長さ

HTTPエラー

HTTP 4xxおよび5xxエラーの数

OHS仮想ホスト・メトリック

「OHS仮想ホスト・メトリック」フォルダには、仮想ホスト(アクセス・ポイントとも呼ばれる)のパフォーマンス・メトリック・オプションが含まれます。次の表に、「OHS仮想ホスト・メトリック」フォルダに含まれるメトリックを示します。

要素

説明

仮想ホストに対するリクエスト・スループット

各仮想ホストに対する1秒当たりのリクエストの数

仮想ホストに対するリクエスト処理時間

各仮想ホストで1つのリクエストを処理する時間

仮想ホストに対するレスポンス・データ・スループット

各仮想ホストで送信されたデータの量

仮想ホストに対して処理されたレスポンス・データ

各仮想ホストで処理されたデータの量

OHSモジュール・メトリック

「OHSモジュール・メトリック」フォルダには、モジュールのパフォーマンス・メトリック・オプションが含まれます。次の表に、「OHSモジュール・メトリック」フォルダに含まれるメトリックを示します。

要素

説明

リクエスト・ハンドリング・スループット

モジュールのリクエスト・ハンドリング・スループット(リクエスト/秒単位)

リクエスト・ハンドリング時間

モジュールのリクエスト・ハンドリング時間(秒単位)

モジュール・メトリック

モジュールと、各モジュールのアクティブ・リクエスト、スループットおよび時間

パフォーマンス・メトリックの表示

次のいずれかの手順を使用して、Oracle HTTP ServerおよびOracle WebLogic Serverプロキシ・プラグイン・モジュールのパフォーマンス・メトリックを参照できます。

- Fusion Middleware Controlを使用したサーバー・メトリックの表示

- WLSTを使用したサーバー・メトリックの表示

Fusion Middleware Controlを使用したサーバー・メトリックの表示

メトリックは、Fusion Middleware ControlのOracle HTTP Serverホーム・メニューから表示できます。

1. モニター対象のOracle HTTP Serverを選択します。

2. Oracle HTTP Serverのホーム・ページの「Oracle HTTP Server」メニューから「モニタリング中」を選択し、「パフォーマンス・サマリー」を選択します。

「パフォーマンス・サマリー」ページが表示されます。このページに、パフォーマンス・メトリックと、Oracle HTTP Serverインスタンスのレスポンス時間およびリクエスト処理時間に関する情報が表示されます。

3. その他のメトリックを表示するには、「メトリック・パレットの表示」をクリックし、メトリックのカテゴリを開きます。

ヒント:

Oracle HTTP Serverホーム・メニューからは、Oracle HTTP Serverのポート使用状況情報も利用できます。

次の図は、「メトリック・パレット」が表示されたOracle HTTP Serverの「パフォーマンス・サマリー」ページを示しています。

4. 追加のメトリックを選択して、「パフォーマンス・サマリー」に追加します。

WLSTを使用したサーバー・メトリックの表示

コマンド行からインスタンスのメトリックの取得と表示を行うには、接続して、適切なWLSTコマンドを発行する必要があります。これらのコマンドを使用して、次のような機能のいずれかを実行できます。

- メトリック表名の表示

- メトリック表の表示

- メトリックのダンプ

注意:

WLSTの使用方法の詳細は、『WebLogic Scripting Toolの理解』を参照してください。

この手順を実行してみる前に、次の内容を実行します。

コマンド行からサーバー・メトリックにアクセスを試みる前に、次の内容を確認してください。

- ドメインが存在し、メトリックを表示するインスタンスが存在すること。

- インスタンスが実行中であること。

- インスタンスのマシン上でノード・マネージャが実行中であること。

管理サーバーが動作中でも構いませんが、必要条件ではありません。

WLSTを使用してメトリックを表示するには、次の手順を実行します。

注意:

管理対象ドメインとスタンドアロン・ドメインのいずれの種類においても、同一のマシンまたはサーバーに対してリモートのマシンのいずれからコマンドを実行したかによらず、次の手順が機能します。

1. WLSTを起動します。

LinuxまたはUNIXの場合:

$ORACLE_HOME/oracle_common/common/bin/wlst.sh

Windowsの場合:

$ORACLE_HOME\oracle_common\common\bin\wlst.cmd

2. 選択したドメイン・ディレクトリ(ORACLE_HOME/user_projects/domains/domainNameなど)からインスタンスに接続します。

nmConnect('username', 'password', nm_host, nm_port, domainName)

3. 実行するタスクに応じて、次のWLSTコマンドの1つを入力します。

- displayMetricTableNames(servers=['serverName'], servertype='serverType')

- displayMetricTables(servers=['serverName'], servertype='serverType')

- dumpMetrics(servers=['serverName'], servertype='serverType')

例:

displayMetricTableNames(servers=['ohs1'], servertype='OHS')
displayMetricTables(servers=['ohs1'], servertype='OHS')
dumpMetrics(servers=['ohs1'], servertype='OHS')

Oracle HTTP Serverのパフォーマンス・ディレクティブ

次の項では、Oracle HTTP Serverのパフォーマンス・ディレクティブについて説明します。

- パフォーマンス・ディレクティブの理解

- Fusion Middleware Controlを使用したパフォーマンス・ディレクティブの構成

パフォーマンス・ディレクティブの理解

Oracle HTTP Serverでは、httpd.confおよび他の構成ファイルで宣言されたディレクティブが使用されます。この構成ファイルは、同時に処理できるHTTPリクエストの最大数、ロギングの詳細、および特定の制限やタイムアウトを指定するものです。Oracle HTTP Serverでは次のMulti-Processing Module (MPM)をサポートし、またこれらが付属しています。これらのモジュールは、マシン上のネットワーク・ポートへのバインド、リクエストの受入れ、およびリクエストを処理するための子のディスパッチを行います。

- Worker: これはUNIX (Linux以外)環境のOracle HTTP Serverに対するデフォルトのMPMです。このMPMは、マルチプロセスでマルチスレッドのハイブリッド・サーバーを実装します。このサーバーは、リクエストの処理にスレッドを使用することで、プロセスベースのサーバーよりも少ないシステム・リソースで多数のリクエストを処理できます。しかし、このサーバーは、それぞれが多数のスレッドを持つ複数のプロセスを常に使用可能にしておくため、安定性はプロセスベースのサーバーとほとんど変わりません。Worker MPMを使用している場合、CGIアプリケーション用にmod_cgiではなくmod_cgidモジュールを構成する必要があります。詳細は、次のURLを参照してください。
http://httpd.apache.org/docs/2.4/mod/mod_cgid.html

- WinNT: これはWindowsプラットフォーム上のOracle HTTP Serverに対するデフォルトのMPMです。単一の子プロセスを起動し、次にこれによってリクエストを処理するスレッドが作成される、単一の制御プロセスが使用されます。

- Prefork: このMPMは、Apache 1.3と同様の方法でリクエストを処理する、スレッドを使用しないプリフォーク・サーバーを実装します。これは、スレッド・セーフでないライブラリとの互換性のためにスレッドを回避する必要のあるサイトに適しています。またこのMPMは、1つのリクエストに関連する問題が他のリクエストに影響を与えないように、各リクエストを分離する場合に最も適しています。このMPMと一緒にCGIモジュールを実装する場合には、mod_fastcgiのみを使用してください。

- Event: これはLinux環境のOracle HTTP Serverに対するデフォルトのMPMです。このMPMは、一部の処理をサポートしているスレッドに渡し、新しいリクエストを処理するメイン・スレッドを解放することで、より多くのリクエストを同時に処理できるように設計されています。これはハイブリッド・マルチプロセス、マルチスレッド・サーバーを実装するWorker MPMに基づきます。ランタイム構成ディレクティブはWorkerにより提供されるものと同じです。

次の項では、スタンドアロンおよびOracle WebLogic ServerドメインのOracle HTTP Serverインスタンス用のMPMタイプの値を変更する方法について説明します

- スタンドアロン・ドメインのMPMタイプの値の変更

- WebLogic Server管理対象ドメインのMPMタイプの値の変更

スタンドアロン・ドメインのMPMタイプの値の変更

スタンドアロン・ドメインのOracle HTTP Serverインスタンス用のMPMタイプの値を変更するには、次の手順に従います。

1. ${ORACLE_INSTANCE}/config/fmwconfig/components/OHS/${COMPONENT_NAME}にある、ohs.plugins.nodemanager.propertiesファイルに移動します。

2. ohs.plugins.nodemanager.propertiesファイルを編集して、次の変更を加えます。

非コメント行のキーmpmを探します。

- 非コメント行のキーを見つけたら、既存のmpmの値をMPMに設定する値に置き換えます。

- 非コメント行で見つからなかった場合、次の形式を使用して新しい行をファイルに追加します。

mpm = mpm_value

ここで、mpm_valueはMPMとして設定する値です。

3. Oracle HTTP Serverインスタンスを起動または再起動します。

WebLogic Server管理対象ドメインのMPMタイプの値の変更

Oracle WebLogic ServerドメインのOracle HTTP Serverインスタンス用のMPMタイプの値を変更するには、次の手順に従います。

注意:

次の手順では、ドメインの管理サーバーおよびノード・マネージャがすでに実行していると仮定します。

1. コマンド行からWLSTを起動します。

LinuxまたはUNIX: $ORACLE_HOME/oracle_common/common/bin/wlst.sh

2. 管理サーバー・インスタンスに接続します。

connect('<userName', '<password>', '<host>:<port>')

3. MPMタイプの値キーを含むMbeanに移動します。

editCustom()コマンドは、WLSTが管理サーバーに接続されている場合にのみ入力できます。cdを使用して管理オブジェクトの階層をナビゲートします。この例では、ohs1という名前のOracle HTTP Serverインスタンスを想定します。

editCustom()
cd('oracle.ohs')
cd('oracle.ohs:type=OHSInstance.NMProp,OHSInstance=ohs1,component=OHS')

4. MPMタイプの値キーを設定します。

編集セッションを開始し、MPMタイプの値キーMpmをそのタイプ値に設定します。この例では、タイプ値がeventに設定されています。

startEdit()
set('Mpm','event')
save()
activate()

Fusion Middleware Controlを使用したパフォーマンス・ディレクティブの構成

この項での説明および推奨は、スレッドを使用するWorker MPM、Event MPMまたはWinNT MPMに基づいています。Prefork MPMを使用している場合、次に示すスレッド関連ディレクティブは適用不可です。

次の図に示すFusion Middleware Controlの「パフォーマンス・ディレクティブ」ページでは、Oracle HTTP Serverのパフォーマンス関連ディレクティブをチューニングできます。

パフォーマンス・ディレクティブの管理は、リクエスト構成、接続構成およびプロセス構成という領域で構成されます。次の各項では、これらの構成を設定する方法について説明します。

- Fusion Middleware Controlを使用したリクエスト構成の設定

- Fusion Middleware Controlを使用した接続構成の設定

- Fusion Middleware Controlを使用したプロセス構成の設定

Fusion Middleware Controlを使用したリクエスト構成の設定

Fusion Middleware Controlを使用してOracle HTTP Serverのリクエスト構成を指定するには、次の手順を実行します。

1. 「Oracle HTTP Server」メニューから「管理」を選択します。

2. 「管理」メニューから「パフォーマンス・ディレクティブ」を選択します。「パフォーマンス・ディレクティブ」ページが表示されます。

3. 「最大リクエスト数」フィールド(MaxRequestWorkersディレクティブ)に最大リクエスト数を入力します。

この設定により、一度に処理されるリクエストの数が制限されます。デフォルト値は400です。これはすべてのLinux/UNIXプラットフォームに適用可能です。

4. 子プロセス1件当たりの最大リクエスト数フィールド(MaxConnectionsPerChildディレクティブ)で、子プロセス1件当たりの最大リクエスト数を設定します。

無制限とするか、または最大数を設定できます。制限する場合、フィールドに最大数を入力します。

5. 「リクエスト・タイムアウト(秒)」フィールド(Timeoutディレクティブ)にリクエスト・タイムアウト値を入力します。

この値により、Oracle HTTP ServerがGETリクエストの受信を待機する最大時間(秒単位)、POSTまたはPUTリクエストでTCPパケットを受信する際の間隔時間、および応答時にTCPパケットを転送する際のACKの間隔時間を設定します。

6. 設定を確認します。設定に問題がない場合、「適用」をクリックして変更を適用します。設定に問題がある場合、または変更を適用しない場合、「元に戻す」をクリックして元の設定に戻します。

7. Oracle HTTP Serverを再起動します。詳細は、Oracle HTTP Serverインスタンスの再起動を参照してください。

リクエスト構成設定が保存され、「パフォーマンス・ディレクティブ」ページに表示されます。

Fusion Middleware Controlを使用した接続構成の設定

Fusion Middleware Controlを使用して接続構成を指定するには、次の手順を実行します。

1. 「Oracle HTTP Server」メニューから「管理」を選択します。

2. 「管理」メニューから「パフォーマンス・ディレクティブ」を選択します。「パフォーマンス・ディレクティブ」ページが表示されます。

3. 「接続キューの最大長」フィールド(ListenBacklogディレクティブ)に、接続キューの最大長を入力します。

これは、保留中の接続用のキューです。この設定は、TCP SYNオーバーロードがサーバーで発生し、その結果多くの新規接続がオープンしたが、保留中のタスクが完了していない場合に便利です。

4. 「1接続当たり複数のリクエストを許可」フィールド(KeepAliveディレクティブ)を設定して、複数の接続を許可するかどうかを指定します。複数の接続を許可するように選択する場合は、「接続タイムアウトを許可」フィールドにタイムアウトの秒数を入力します。

「接続タイムアウトを許可」の値により、サーバーが接続をクローズする前に後続のリクエストを待機する時間(秒数)を設定します。リクエストの受信後、指定した値が適用されます。デフォルトは5秒です。

5. 設定を確認します。設定に問題がない場合、「適用」をクリックして変更を適用します。設定に問題がある場合、または変更を適用しない場合、「元に戻す」をクリックして元の設定に戻します。

6. Oracle HTTP Serverを再起動します。詳細は、Oracle HTTP Serverインスタンスの再起動を参照してください。

接続構成設定が保存され、「パフォーマンス・ディレクティブ」ページに表示されます。

Fusion Middleware Controlを使用したプロセス構成の設定

子プロセスと構成設定は、サーバーによるリクエスト処理能力に影響します。状況によっては、サーバーの良好なパフォーマンスを維持するために、リクエスト数を増加または減少させるように設定を変更する必要があります。

UNIXの場合、子サーバー・プロセスのデフォルト数は3です。Microsoft Windowsの場合、リクエストを処理するためのスレッドのデフォルト数は150です。

Fusion Middleware Controlを使用してプロセス構成を指定するには、次の手順を実行します。

1. 「Oracle HTTP Server」メニューから「管理」を選択します。

2. 「管理」メニューから「パフォーマンス・ディレクティブ」を選択します。「パフォーマンス・ディレクティブ」ページが表示されます。

3. 「初期子サーバー・プロセス」フィールド(StartServersディレクティブ)に初期子サーバー・プロセス数を入力します。

これは、Oracle HTTP Serverの起動時に作成される子サーバー・プロセスの数です。デフォルトは3です。これは、UNIX専用です。

4. 「最大アイドル・スレッド」フィールド(MaxSpareThreadsディレクティブ)に最大アイドル・スレッド数を入力します。

アイドル・スレッドは、稼働しているがリクエストを処理していないプロセスです。

5. 「最小アイドル・スレッド」フィールド(MinSpareThreadsディレクティブ)に最小アイドル・スレッド数を入力します。

6. 「1子サーバー・プロセス当たりのスレッド数」フィールド(ThreadsPerChildディレクティブ)に子サーバー・プロセス当たりのスレッド数を入力します。

7. 設定を確認します。設定に問題がない場合、「適用」をクリックして変更を適用します。設定に問題がある場合、または変更を適用しない場合、「元に戻す」をクリックして元の設定に戻します。

8. Oracle HTTP Serverを再起動します。詳細は、Oracle HTTP Serverインスタンスの再起動を参照してください。

プロセス構成設定が保存され、「パフォーマンス・ディレクティブ」ページに表示されます。

UNIXのプロセス・セキュリティの理解

デフォルトでは、Oracle HTTP Serverは、UNIXでの予約済の範囲内にあるポート(通常1024未満)にバインドできません。Oracle HTTP Serverが、UNIXでの予約済の範囲内にあるポート(ポート80とポート443など)でリスニングできるようにするには、特権ポートでのOracle HTTP Serverインスタンスの起動(UNIXのみ)を参照してください。

7 接続の管理

この章では、Oracle HTTP Server接続を管理する方法を説明します。これには、ポート番号の使用状況の表示、ポートの管理および仮想ホストの構成を行う手順が含まれます。

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

- デフォルトのリスニング・ポート

- 管理ポートの定義

- ポート番号の使用状況の表示

- ポートの管理

- 仮想ホストの構成

デフォルトのリスニング・ポート

自動ポート割当ては、ohs_createInstance()またはFusion Middleware Controlを使用している場合のみ発生します。デフォルトの非SSLポートは7777です。ポート7777が占有されている場合は、7777から65535の範囲で次に使用可能なポート番号が割り当てられます。デフォルトのSSLポートは4443です。この場合も、ポート4443が占有されている場合は、4443から65535の範囲で次に使用可能なポート番号が割り当てられます。

Configuration Wizardを使用してインスタンスを生成する場合には、自分でポート管理を行う必要があります。Configuration Wizardには、自動ポート割当て機能はありません。

新しいOracle HTTP Serverコンポーネントを作成する際のポートの指定の詳細は、OHSインスタンスの作成を参照してください。

管理ポートの定義

自動Adminポート割当ては、ohs_createInstance()またはFusion Middleware Controlを使用している場合のみ発生します。Adminポートは、Oracle HTTP Serverがノード・マネージャとの通信に内部的に使用します。このポートは、admin.confに構成されています。

Configuration Wizardを使用してインスタンスを生成する場合には、自分で管理ポートの管理を行う必要があります。Configuration Wizardには、自動ポート割当て機能はありません。

なんらかの理由で別の目的のためにデフォルトのポートを使用する必要がある場合は、構成ウィザードを使用してドメインを更新し、そこでポートを手動でリセットすることによって、管理ポートを再構成できます。

ポート番号の使用状況の表示

この項では、Fusion Middleware ControlまたはWLSTを使用してポートを表示する方法について説明します。

- Fusion Middleware Controlを使用したポート番号の使用状況の表示

- WLSTを使用したポート番号の使用状況の表示

Fusion Middleware Controlを使用したポート番号の使用状況の表示

Fusion Middleware Controlの「ポートの使用状況」詳細ページに、ポートの割当て方法を表示できます。Fusion Middleware Controlを使用してポート番号の使用状況を表示するには、次の手順を実行します。

1. Oracle HTTP Serverのホームページに移動します。

2. 「Oracle HTTP Server」メニューから「ポートの使用状況」を選択します。

「ポートの使用状況」詳細ページには、コンポーネント、使用中のポート、ポートがバインドされているIPアドレス、および使用中のプロトコルが表示されます(次の図を参照)。

WLSTを使用したポート番号の使用状況の表示

Oracle HTTP Serverをコロケート・モードで使用している場合には、WLSTコマンドを使用して特定インスタンスのポート番号情報を表示できます。

1. WLSTを起動します。

$ORACLE_HOME/oracle_common/common/bin/wlst.sh

2. AdminServerに接続します。

3. editCustom()コマンドを使用して、oracle.ohs MBeanのルートに移動します。WLSTがAdministration Serverに接続されている場合にかぎり、editCustom()コマンドを使用できます。cdを使用して管理オブジェクト階層に移動し、get()でPortsパラメータの値を取得します。

editCustom()
cd('oracle.ohs')
cd('oracle.ohs:type=OHSInstance,name=ohs1')
get('Ports')

WLSTは次のような値を返します。

array(java.lang.String,['7777', '4443', '127.0.0.1:9999'])

注意:

OHS構成ファイルのマスター・コピーのディレクトリにcdして、Listenディレクティブに対しgrepを実行することもできます。

ポートの管理

Oracle HTTP Serverで使用するポートは、インストール中およびインストール後に設定できます。また、ポート番号は必要に応じて変更できます。この項では、Fusion Middleware Controlを使用してポートを作成、編集および削除する方法について説明します。

注意:

admin.confファイル内に定義されているOracle HTTP Server管理仮想ホストおよびその構成は、WebLogic Scripting Tool (WLST)を使用して編集しないでください。

関連項目:

『Oracle Fusion Middlewareの管理』のOracle HTTP Serverのリスニング・ポートの変更に関する項

- Fusion Middleware Controlを使用したポートの作成

- Fusion Middleware Controlを使用したポートの編集

注意:

ポートを削除するときに、削除するポートを使用するように構成されている仮想ホストがある場合は、ポートの削除前にその仮想ホストを削除する必要があります。

Fusion Middleware Controlを使用したポートの作成

Fusion Middleware Control Createの「ポートの作成」ページでOracle HTTP Serverエンドポイントのポートを作成します。Fusion Middleware Controlを使用してポートを作成するには、次の手順を実行します。

1. Oracle HTTP Serverのホームページに移動します。

2. 「Oracle HTTP Server」メニューから「管理」を選択します。

3. 「管理」メニューから「ポート構成」を選択します。

4. 「作成」をクリックします。

5. 「IPアドレス」メニューを使用して、新しいポートのIPアドレスを選択します。ポートは、関連付けられたホストのローカルIPアドレス、または使用可能なネットワーク・インタフェースでリスニングできます。

ポートのSSLは、「仮想ホスト」ページで構成できます(Fusion Middleware Controlを使用した仮想ホストの構成を参照)。

6. 「ポート」にポート番号を入力します。

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

8. Oracle HTTP Serverを再起動します。詳細は、Oracle HTTP Serverインスタンスの再起動を参照してください。

注意:

ポート番号の変更や、URLに影響を与えるその他の変更(ホスト名の変更、SSLの有効化または無効化など)を行う場合、新しいURLを使用してパートナ・アプリケーションをSSOサーバーに再登録する必要があります。詳細は、『Oracle Platform Security Servicesによるアプリケーションの保護』のOSSO Server 10.1.4へのOracle HTTP Server mod_ossoの登録に関する項を参照してください。

Fusion Middleware Controlを使用したポートの編集

Fusion Middleware Controlの「ポートの編集」ページで既存のポートの値を編集できます。Fusion Middleware Controlを使用してポートを編集するには、次の手順を実行します。

1. Oracle HTTP Serverのホームページに移動します。

2. 「Oracle HTTP Server」メニューから「管理」を選択します。

3. 「管理」メニューから「ポート構成」を選択します。

4. ポート番号を変更するポートを選択します。

Fusion Middleware Controlを使用して管理ポートを編集することはできません。これはOracle HTTP Serverがノード・マネージャとの内部通信に使用するポートですが、ほとんどの場合、変更する必要はありません。本当にこれを変更する必要がある場合は、手動でDOMAIN_HOME/config/fmwconfig/components/OHS/componentName/admin.confファイルを編集します。

5. 「編集」をクリックします。

6. ポートの「IPアドレス」または「ポート」(あるいはその両方)の番号を編集します。

ポートのSSLは、「仮想ホスト」ページで構成できます(Fusion Middleware Controlを使用した仮想ホストの構成を参照)。

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

8. Oracle HTTP Serverを再起動します。詳細は、Oracle HTTP Serverインスタンスの再起動を参照してください。

注意:

ポート番号の変更や、URLに影響を与えるその他の変更(ホスト名の変更、SSLの有効化または無効化など)を行う場合、新しいURLを使用してパートナ・アプリケーションをSSOサーバーに再登録する必要があります。

スタンドアロン環境でのリスニング・ポートの無効化

WebLogic Server環境のリスニング・ポートはFusion Middleware Controlを使用して無効化できますが、これをスタンドアロン環境で行う場合は、ポートが公開されている行をコメントアウトすることによって、ステージング構成ファイルを直接更新する必要があります。次に例を示します。

#Listen slc01qtd.us.myCo.com:7777

注意:

.confファイルを編集しようとする前に、構成ファイル・ディレクトリのレイアウト、ファイル編集のメカニズムおよびファイル自体の詳細に精通しておく必要があります。この情報については、構成ファイルの理解を参照してください。

仮想ホストの構成

1つのマシンで複数のWebサイト(www.company1.comとwww.company2.comなど)を実行する仮想ホストを作成できます。仮想ホストはIPベース(各Webサイトが固有のIPアドレスを持つ)にすることも、名前ベース(各IPアドレスで複数の名前が機能する)にすることもできます。それらが同じ物理サーバー上で動作しているという事実は、エンド・ユーザーにはわかりません。

注意:

admin.confファイル内に定義されているOracle HTTP Server管理仮想ホストおよびその構成は、WebLogic Scripting Tool (WLST)を使用して編集しないでください。

Oracle HTTP Serverの現在のリリースでは、仮想ホスト名としてIPv6およびIPv4のアドレスを使用できます。

同じ仮想ホストに対して複数のアドレスを構成することもできます。つまり、複数のアドレスに対してサービスを提供するように1つの仮想ホストを構成できます。これにより、同じ仮想ホストから同じコンテンツを使用して、異なるアドレスへの要求に対応することができます。

この項では、Fusion Middleware Controlを使用して仮想ホストを作成および編集する方法について説明します。

- Fusion Middleware Controlを使用した仮想ホストの作成

- Fusion Middleware Controlを使用した仮想ホストの構成

関連項目:

仮想ホストの詳細は、Apache HTTP Serverのドキュメントを参照してください。

Fusion Middleware Controlを使用した仮想ホストの作成

Fusion Middleware Control Createの「仮想ホストの作成」ページでOracle HTTP Serverの仮想ホストを作成できます。Fusion Middleware Controlを使用して仮想ホストを作成するには、次の手順を実行します。

1. Oracle HTTP Serverのホームページに移動します。

2. 「Oracle HTTP Server」メニューから「管理」を選択します。

3. 「管理」メニューから「仮想ホスト」を選択します。

4. 「作成」をクリックします。

5. 仮想ホスト・フィールドに名前を入力し、新規のリスニング・アドレスを入力するか、既存のリスニング・アドレスを使用するかを選択します。

- 新規リスニング・アドレス— 特定のホスト名、IPアドレス、またはIPv6アドレス(たとえば、mymachine.com:8080など)にマップされる仮想ホストを作成する場合は、このオプションを使用します。このオプションを使用すると、次のVirtualHostディレクティブが作成されます。

<VirtualHost mymachine.com:8080>

- 既存のリスニング・アドレスの使用— 既存のリスニング・ポートを使用して、すべてのIPアドレスにマップされる仮想ホストを作成する場合は、このオプションを使用します。このオプションを使用すると、次のタイプのVirtualHostディレクティブが作成されます。

<VirtualHost *:8080>

注意:

ワイルドカード文字を使用して仮想ホストを作成しようとしているときに(たとえば、*:ポート)、そのポートにListenディレクティブが存在しない場合、仮想ホストの作成は失敗します。

この場合、最初にListenディレクティブを追加し、次に仮想ホストを追加するようにする必要があります。

6. 新規の仮想ホストの場合、残りの属性を入力します。

- サーバー名: Oracle HTTP Serverのサーバー名

- ドキュメント・ルート: Webサイトから表示できるメイン・ドキュメント・ツリーを構成するドキュメント・ルート・ディレクトリ

- ディレクトリの索引: クライアントが最初にWebページにアクセスしたときに表示されるメイン(索引)ページ

- 管理者の電子メール・アドレス: サーバーがクライアントに送信するエラー・メッセージに挿入する電子メール・アドレス

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

8. Oracle HTTP Serverを再起動します。Oracle HTTP Serverインスタンスの再起動を参照してください。

不要なListenディレクティブの削除

Fusion Middleware Controlを使用して仮想ホストを作成すると、その仮想ホストのListenディレクティブも追加されます。ただし、次のような状況で仮想ホストを作成すると、不要なListenディレクティブが追加されます。

- 仮想ホストをある1つのホスト名に対して作成中で、それと同じIPアドレスに解決される異なるホスト名にListenディレクティブがすでに存在する。

- 仮想ホストをある1つのホスト名に対して作成中で、そのホスト名の解決先となるIPアドレスにListenディレクティブがすでに存在する。

- 仮想ホストを複数のホスト名に対して作成中で、それらのホスト名が同じIPアドレスに解決される。

これらの状況では、同じIPアドレスに対して複数のListenディレクティブが存在するため、Oracle HTTP Serverは起動に失敗します。同じIPアドレスに対して構成された余計なListenディレクティブがある場合は、削除する必要があります。

Fusion Middleware Controlを使用した仮想ホストの構成

「仮想ホスト」ページの「構成」メニューのオプションを使用して、選択した仮想ホストの「サーバー構成」、「MIME構成」、「ログ構成」、「SSL構成」および「mod_wl_ohs構成」を指定できます。

Fusion Middleware Controlを使用して仮想ホストを構成するには、次の手順を実行します。

1. Oracle HTTP Serverのホームページに移動します。

2. 「Oracle HTTP Server」メニューから「管理」を選択します。

3. 「管理」メニューから「仮想ホスト」を選択します。

4. 表内の既存の仮想ホストを強調表示します。

5. 「構成」をクリックします。

6. 「構成」メニューから次のいずれかのオプションを選択し、それに対応する構成ページを開きます。これらのページの値は、仮想ホストのみに適用されます。フィールドが空白の場合、仮想ホストはサーバー・レベルで構成されている値を使用します。

- サーバー構成: 基本的な仮想ホスト・プロパティ(ドキュメント・ルート・ディレクトリ、インストールされているモジュール、別名など)を構成します。Fusion Middleware Controlを使用したサーバー・プロパティの指定を参照してください。

- MIME構成: Oracle HTTP Serverでファイル・タイプ、エンコーディングおよび言語の解析に使用されるMIME設定を構成します。Fusion Middleware Controlを使用したMIME設定の構成

- ログ構成: 仮想ホストにより処理されたすべてのリクエストを記録するアクセス・ログを構成します。このログには、仮想ホストにより処理されたすべてのHTTPトランザクションに関する基本情報が含まれます。Oracle HTTP Serverログの構成を参照してください。

- SSL構成: Fusion Middleware Controlを使用したSSLの構成手順は、『Oracle Fusion Middlewareの管理』のOracle HTTP Server仮想ホストでのSSLの有効化に関する項を参照してください。

- mod_wl_ohs構成: リクエストをOracle HTTP ServerからOracle WebLogic Serverにプロキシできるようにmod_wl_ohsモジュールを構成します。Oracle WebLogic Serverプロキシ・プラグイン(mod_wl_ohs)の構成についてを参照してください。

7. 各構成ページの設定を確認します。設定に問題がない場合、「OK」をクリックして変更を適用します。設定に問題がある場合、または変更を適用しない場合、「取消」をクリックして元の設定に戻します。

8. Oracle HTTP Serverを再起動します。Oracle HTTP Serverインスタンスの再起動を参照してください。

8 Oracle HTTP Serverログの管理

この章では、Oracle HTTP Serverログの管理方法について説明します。ここでは、サーバー・ログの管理方法、エラーの原因とその修正処置に関する情報を調べる方法、システム・アクティビティのモニタリングに役立つログ・ファイルを表示して管理する方法、および問題を診断する方法について説明します。

Oracle HTTP Serverでは、すべてのタイプのイベントを記録したメッセージが含まれるログ・ファイルが生成されます。これには、起動と停止の情報、エラー、警告メッセージ、HTTPリクエストに関するアクセス情報、および追加情報が含まれます。

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

- サーバー・ログの概要

- Oracle HTTP Serverログの構成

- WLSTを使用したログ・レベルの構成

- Oracle HTTP Serverのログ・ディレクティブ

- Oracle HTTP Serverログの表示

- ECID情報の記録

- SSLリクエストの終了

サーバー・ログの概要

Oracle Fusion Middlewareのログ・ファイルは、Fusion Middleware Controlまたはテキスト・エディタのいずれかを使用して表示できます。Oracle HTTP Serverのログ・ファイルは、次のディレクトリに存在します。

ORACLE_HOME/user_projects/domains/<base_domain>/servers/componentName/logs

Oracle HTTP Serverには、次の2つのタイプのログがあります。

- エラー・ログ: サーバーの問題が記録されます。

- アクセス・ログ: どのコンポーネントとアプリケーションに誰がアクセスしたかが記録されます。

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

- エラー・ログについて

- アクセス・ログについて

- ログ・ローテーションの構成

エラー・ログについて

Oracle HTTP Serverでは、ログ・メッセージを生成する形式を選択できます。レガシーのApache HTTP Serverメッセージ形式でログ・メッセージを生成するか、エラー・ログ・メッセージ生成用のOracle標準に準拠するOracle Diagnostic Logging (ODL)を使用してテキストまたはXML形式のログにログ・メッセージを生成するかを選択できます。

デフォルトでは、Oracle HTTP Serverエラー・ログでは診断メッセージの生成用にODLが使用されます。これにより、すべての診断メッセージおよびログ・ファイルのための共通書式と、Oracle Fusion Middleware全体の様々なコンポーネントからの診断メッセージを相互に関係付ける仕組みが提供されます。

エラー・ログ・ファイルのデフォルト名は、instance_name.logです。

注意:

ODLエラー・ロギングでは各仮想ホスト用に別個のログ・ファイルを持たせることはできません。グローバルにすべての仮想ホスト用に構成できるのみです。

アクセス・ログについて

アクセス・ログには、サーバーによって処理されたすべてのリクエストが記録されます。このログには、サーバーで処理されたすべてのHTTPトランザクションに関する基本情報が含まれます。アクセス・ログに含まれる情報は、次のとおりです。

- ホスト名

- リモート・ログ名

- リモート・ユーザーおよび時間

- リクエスト

- レスポンス・コード

- 転送バイト数

アクセス・ログ・ファイルのデフォルト名は、access_logです。

アクセス・ログの形式

管理者は、アクセス・ログに含める情報とその書込み方法を指定できます。デフォルトの形式は共通ログ形式(CLF)です。

LogFormat "%h %l %u %t %E \"%r\" %>s %b" common

CLF形式には、次のフィールドが含まれます。

host ident remote_logname remote_usre date  ECID request authuser status bytes

- host: クライアントのドメイン名またはIPアドレスログにホスト・フィールドを指定するには、%hを使用します。

- ident: IdentityCheckが有効で、クライアント・システムによりidentdが実行されている場合のクライアントのアイデンティティ情報。ログにクライアント・アイデンティティ・フィールドを指定するには、%iを使用します。

- remote_logname: リモート・ログ名(提供された場合、identdから)。ログにリモート・ログ名を指定するには、%lを使用します。

- remote_user: リクエストが認証された場合のリモート・ユーザー。ログにリモート・ユーザーを指定するには、%uを使用します。

- date: day/month/year:hour:minute:second書式のリクエスト日時。ログに日時を指定するには、%tを使用します。

- ECID: ECID情報を取得します。ログのECIDを取得するには、%Eを使用します。ECID情報用アクセス・ログの構成も参照してください。

- request: 二重引用符で囲まれたクライアントからのリクエスト行ログにリクエストを指定するには、%rを使用します。

- authuser: 認可ユーザーのユーザーID。ログに認可ユーザー・フィールドを指定するには、%aを使用します。

- status: クライアントに戻される3桁のステータス・コードログにステータスを指定するには、%sを使用します。リクエストが別のサーバーから転送される場合、ログに最後のサーバーを指定するには、%>sを使用します。

- bytes: ヘッダーを除き、クライアントに返されるバイト数ログにバイト数を指定するには、%bを使用します。ログにヘッダーを含めるには、%iを使用します。

関連項目:

Apache HTTP Serverドキュメントの「Access Log」。

ログ・ローテーションの構成

Oracle HTTP Serverでは、サイズベースと時間ベースの2種類のログ・ローテーション・ポリシーをサポートしています。ORACLE_HOME/ohs/binにあるodl_rotatelogsを使用することで、2つのローテーション・ポリシーのいずれかを使用するようにOracle HTTP Serverログを構成することができます。デフォルトでは、Oracle HTTP Serverではエラー・ログとアクセス・ログの両方に対してodl_rotatelogsを使用します。

odl_rotatelogsは、Apache HTTP Serverのrotatelogsのすべての機能と、ログ保存の追加機能をサポートします。

rotatelogsによって提供される機能とオプションに関する情報は、次のURLで参照できます。

http://httpd.apache.org/docs/2.4/programs/rotatelogs.html

odl_rotatelogsの一般構文は次のとおりです。

odl_rotatelogs [-u:offset] logfile {size-|time-based-rotation-options}

odl_rotatelogsは、パイプ化されたログファイル機能で使用されます。この機能により、エラーおよびアクセス・ログ・ファイルが、ファイルに直接ではなく、別のプロセスへのパイプを通じて書き込むことができます。これによりロギングの柔軟性が高まるため、メイン・サーバーにコードを追加する必要はありません。ログをパイプに書き込むには、ファイル名を縦線「|」で置き換え、続けて標準入力でログ入力を受け入れる実行可能ファイルの名前を指定します。パイプ化されたログファイル機能の詳細は、次のURLを参照してください。

http://httpd.apache.org/docs/2.4/logs.html#piped

パイプ化されたログファイル機能とともに使用される、odl_rotatelogsの構文は次のようになります。

CustomLog " |${PRODUCT_HOME}/bin/odl_rotatelogs [-u:offset] logfile {size-|time-based-rotation-options}" log_format

odl_rotatelogsへの入力があるたびに、指定したローテーションの条件に合っているかがチェックされます。合っていれば、ファイルをローテーションします。合っていなければ、単にコンテンツに書き込みます。何も入力されていない場合は、何も起こりません。

表8-1にサイズベースおよび時間ベースのローテーションのオプションを示します。

表8-1 odl_rotatelogsのオプション

オプション

説明

-u

UTCからオフセットする時間(秒)。

logfile

ログ・ファイルのパスと名前、その後にハイフン(-)そしてタイムスタンプ・フォーマットが続きます。

次に一般的なタイムスタンプ・フォーマット文字列を示します。

- %m: 2桁の数値で表される月(01-12)

- %d: 2桁の数値で表される日(01-31)

- %Y: 4桁の数値で表される年

- %H: 2桁の数値で表される時刻(00-23)

- %M: 2桁の数値で表される分(00-59)

- %S: 2桁の数値で表される秒(00-59)

スラッシュを含むまで拡張されるフォーマットを含むことはできません。

frequency

ログ・ファイルのローテーションの間の時間(秒)。

retentionTime

ローテーションされたログ・ファイルが保存される最大時間。

startTime

時間ベースのローテーションが開始する時間。

maxFileSize

ログ・ファイルの最大サイズ(MB)。

allFileSize

保存されたファイルの合計サイズ(MB)。

時間ベースのローテーションの場合、odl_rotatelogsを使用したOracle HTTP Serverのログ・ローテーションは、デフォルトではUTC時間に従って計算されます。たとえば、ログ・ローテーションを86400 (24時間)に設定すると、UTCで真夜中の12:00になるたびにログがローテーションされます。Oracle HTTP Serverがインド標準時(IST)で実行されている場合、ISTはUTC+05:30であるので、ログは午前05:30にローテーションされます。

UTCオフセットに対して-uオプションを使用するかわりに、Apacheによって提供される-lオプションを使用することもできます。このオプションの場合、Oracle HTTP Serverでは間隔の基準としてローカル時間が使用されます。UTCオフセットを変更した環境(英国標準時(BST)またはサマータイム(DST)など)で-lオプションを使用すると、予測できない結果につながる可能性があります。

時間ベースとサイズベースのローテーションの構文と例

次の例で、時間ベースとサイズベースのログのローテーションを設定するodl_rotatelogsの構文を示します。

- 時間ベースのローテーション
構文:

odl_rotatelogs u:offset logfile frequency retentionTime startTime

例:

CustomLog "| odl_rotatelogs u:-18000 /varlog/error.log-%Y-%m-%d 21600 172800 2014-03-10T08:30:00" common

これは、UTC-05:00 (18000 秒、ニューヨークなど)の場所に対して実行されるログ・ローテーションを構成します。このローテーションは、2014年3月10日の午前8時30分から21600秒(6時間)ごとに実行され、ローテーションされたログ・ファイルを172800秒(2日)間保存するように指定します。ログの形式はcommonです。

構文:

odl_rotatelogs logfile frequency retentionTime startTime

例:

CustomLog "| odl_rotatelogs /varlog/error.log-%Y-%m-%d 21600 172800 2014-03-10T08:30:00" common

これは、2014年3月10日の午前8時30分から21600秒(6時間)ごとにログ・ローテーションを実行するように構成し、ローテーションされたログ・ファイルを172800秒(2日)間保存するように指定します。ログの形式はcommonです。

- サイズベースのローテーション
構文:

odl_rotatelogs logfile maxFileSize allFileSize

例:

これは、ログ・ファイルのサイズが10 MBに達するとログ・ローテーションを実行するように構成し、ローテーションされたすべてのログ・ファイルの最大サイズを70 MBと指定します(最大7個のログ・ファイル(=70/10)が保存されます)。ログの形式はcommonです。

CustomLog "| odl_rotatelogs /var/log/error.log-%Y-%m-%d 10M 70M" common

Oracle HTTP Serverログの構成

Fusion Middleware Controlを使用してエラー・ログとアクセス・ログを構成できます。次の各項では、「ログ構成」ページから設定できるログ・タスクについて説明します。

- Fusion Middleware Controlを使用したエラー・ログの構成

- Fusion Middleware Controlを使用したアクセス・ログの構成

- ログ・ファイルの作成モードの構成(umask) (UNIX/Linuxのみ)

Fusion Middleware Controlを使用したエラー・ログの構成

Fusion Middleware Controlの「ログ構成」ページでエラー・ログを構成します。Fusion Middleware Controlを使用してOracle HTTP Serverのエラー・ログを構成するには、次の手順を実行します。

1. Oracle HTTP Serverのホームページに移動します。

2. 「管理」メニューから「ログ構成」を選択します。

「ログ構成」ページが表示されます(次の図を参照)。

3. このページからは、次のエラー・ログ構成タスクを設定できます。

- エラー・ログの形式および場所の構成

- エラー・ログ・レベルの構成

- エラー・ログのローテーション・ポリシーの構成

エラー・ログの形式および場所の構成

Fusion Middleware Controlの「ログ構成」ページでエラー・ログの形式および場所を変更できます。デフォルトで、Oracle HTTP Serverはエラー・ログ形式としてODL-Textを使用し、DOMAIN_HOME/servers/component_name/logsディレクトリ内にcomponent_name.logという名前のログ・ファイルを作成します。別の形式またはログ場所を使用するには、次の手順を実行します。

1. 「ログ構成」ページから、「エラー・ログ」セクションの下の「一般」セクションに移動します。

2. 目的のファイル形式を選択します。

- ODL-Text: この形式の診断メッセージはOracle標準に準拠しており、テキスト形式で書き込まれます。

- Apache: この形式の診断メッセージはレガシーのApache HTTP Serverメッセージ形式に準拠しています。

3. 「ログ・ファイル/ディレクトリ」フィールドにエラー・ログのパスを入力します。このディレクトリは、ここに入力する前に存在している必要があります。

4. 設定を確認します。設定に問題がない場合、「適用」をクリックして変更を適用します。設定に問題がある場合、または変更を適用しない場合、「元に戻す」をクリックして元の設定に戻します。

5. Oracle HTTP Serverを再起動します。Oracle HTTP Serverインスタンスの再起動を参照してください。

エラー・ログ・レベルの構成

ログ・ファイルに書き込まれる情報の量とタイプは、メッセージのタイプおよびレベルを指定することによって構成できます。Oracle HTTP Serverのエラー・ログ・レベルは、デフォルトで「WARNING:32」に構成されています。別のエラー・ログ・レベルを使用するには、次の手順を実行します。

1. 「ログ構成」ページから、「エラー・ログ」セクションの下の「一般」セクションに移動します。

2. 「レベル」メニューからロギングのレベルを選択します。ロギング・レベルが高くなると、ログに含まれる情報も増加します。

3. 設定を確認します。設定に問題がない場合、「適用」をクリックして変更を適用します。設定に問題がある場合、または変更を適用しない場合、「元に戻す」をクリックして元の設定に戻します。

4. Oracle HTTP Serverを再起動します。Oracle HTTP Serverインスタンスの再起動を参照してください。

注意:

Apache HTTP Serverログ形式用とODL-Text形式用のログ・レベルは異なります。

- ODLログ・レベルの詳細は、『Oracle Fusion Middlewareの管理』のログ・ファイルに書き込まれる情報レベルの設定に関する項を参照してください

- Apache HTTP Serverのログ・レベルの詳細は、Apache HTTP ServerドキュメントのLogLevelディレクティブに関する項を参照してください。

エラー・ログのローテーション・ポリシーの構成

エラー・ログのログ・ローテーション・ポリシーは、1週間に1回などの時間ベース、または120MBなどのサイズベースで設定します。デフォルトでは、エラー・ログ・ファイルは10MBに達するとローテーションされます。また、最大で7個のエラー・ログ・ファイルが保持されます。別のローテーション・ポリシーを使用するには、次の手順を実行します。

1. 「ログ構成」ページから、「エラー・ログ」セクションの下の「一般」セクションに移動します。

2. ローテーション・ポリシーを選択します。

- ローテーションなし: ログ・ファイルをローテーションしない場合は、このポリシーを選択します。

- サイズ・ベース: ログ・ファイルは、構成されたサイズに達するたびにローテーションされます。「最大ログ・ファイル・サイズ」フィールドでログ・ファイルの最大サイズを設定し、「最大保持ファイル数」フィールドでエラー・ログ・ファイルの最大保持数を設定します。

- 時間ベース: 構成された時刻になるたびにログ・ファイルがローテーションされます。開始時間、ローテーション頻度および保存期間を設定します。

3. 設定を確認します。設定に問題がない場合、「適用」をクリックして変更を適用します。設定に問題がある場合、または変更を適用しない場合、「元に戻す」をクリックして元の設定に戻します。

4. Oracle HTTP Serverを再起動します。Oracle HTTP Serverインスタンスの再起動を参照してください。

Fusion Middleware Controlを使用したアクセス・ログの構成

Fusion Middleware Controlの「ログ構成」ページから、Oracle HTTP Server用のアクセス・ログの形式および場所を構成できます。

このページからは、次のアクセス・ログ構成タスクを設定できます。

- アクセス・ログ形式の構成

- アクセス・ログ・ファイルの構成

アクセス・ログ形式の構成

ログ形式は、アクセス・ログに含める情報とその書込み方法を指定するものです。新規のアクセス・ログ形式を追加したり、既存の形式を編集または削除するには、次の手順を実行します。

1. Oracle HTTP Serverのホームページに移動します。

2. 「管理」メニューから「ログ構成」を選択します。

3. 「ログ構成」ページから「アクセス・ログ」セクションに移動します。

4. 「ログ形式の管理」をクリックします。

「カスタム・アクセス・ログ形式の管理」ページが表示されます(次の図を参照)。

5. 既存の形式を選択して変更または削除するか、「行の追加」をクリックして新規形式を作成します。

6. 新しいフォーマットを作成する場合には、「ログ形式名」フィールドに新しいログ・フォーマットを入力し、「ログ形式パターン」フィールドにログ・フォーマットを入力します。

関連項目:

ログ形式のディレクティブの詳細は、Apache HTTP Serverドキュメントを参照してください。

7. 「OK」をクリックして新規形式を保存します。

アクセス・ログ・ファイルの構成

Fusion Middleware Controlの「アクセス・ログの作成」または「アクセス・ログの編集」ページでアクセス・ログのローテーション・ポリシーを構成できます。Oracle HTTP Serverのアクセス・ログ・ファイルを構成するには、次の手順を実行します。

1. Oracle HTTP Serverのホームページに移動します。

2. 「管理」メニューから「ログ構成」を選択します。

3. 「ログ構成」ページから「アクセス・ログ」セクションに移動します。

4. 新規のアクセス・ログを作成する場合は、「作成」をクリックします。既存のアクセス・ログ・ファイルを編集する場合は、表から行を選択して「編集」ボタンをクリックします。

「アクセス・ログの作成」ページまたは「アクセス・ログの編集」ページが表示されます。

5. 「ログ・ファイル・パス」フィールドにアクセス・ログのパスを入力します。このディレクトリは、ここに入力する前に存在している必要があります。

6. 「ログ形式」メニューから既存のアクセス・ログ形式を選択します。

7. ローテーション・ポリシーを選択します。

- ローテーションなし: ログ・ファイルをローテーションしない場合は、このポリシーを選択します。

- サイズ・ベース: ログ・ファイルは、構成されたサイズに達するたびにローテーションされます。「最大ログ・ファイル・サイズ」フィールドでログ・ファイルの最大サイズを設定し、「最大保持ファイル数」フィールドでエラー・ログ・ファイルの最大保持数を設定します。

- 時間ベース: 構成された時刻になるたびにログ・ファイルがローテーションされます。開始時間、ローテーション頻度および保存期間を設定します。

8. 「OK」をクリックして継続します。

複数のアクセス・ログ・ファイルを作成できます。

ログ・ファイルの作成モードの構成(umask) (UNIX/Linuxのみ)

Oracle HTTP Serverインスタンスを起動する前に、デフォルトのファイル・モード作成マスク(umask)の値を設定します。umaskに設定する値により、エラー・ログ、アクセス・ログなどの、Oracle HTTP Serverインスタンスにより作成されるファイルのアクセス権が決まります。umaskが明示的に設定されていない場合、デフォルトで0027の値が使用されます。

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

- スタンドアロン・ドメインでのOracle HTTP Serverインスタンス用のumaskの構成

- WebLogic Server管理対象ドメインでのOracle HTTP Serverインスタンス用のumaskの構成

スタンドアロン・ドメインでのOracle HTTP Serverインスタンス用のumaskの構成

スタンドアロン・ドメインでデフォルトのファイル・モード作成マスクを構成するには、ステージング場所のohs.plugins.nodemanager.propertiesファイルのumaskプロパティを設定します。

DOMAIN_HOME/config/fmwconfig/components/OHS/instanceName/ohs.plugins.nodemanager.properties

WebLogic Server管理対象ドメインでのOracle HTTP Serverインスタンス用のumaskの構成

WebLogic Server(Full-JRFまたはRestricted-JRFのいずれか)ドメインでデフォルトのファイル・モード作成マスクを構成するには、次の手順に従います。

1. ドメインのAdminServerおよびNodeManagerを起動します。次に例を示します。

<Domain_HOME>/bin/startWebLogic.sh &
<DOMAIN_HOME>/bin/startNodeManager.sh &

2. WLSTを起動してAdminServerに接続します。

<ORACLE_HOME>/oracle_common/bin/wlst.sh
connect('<userName', <'password'>, <'adminServerURL'>

3. 次のMBeanに移動します。このMBeanのObjectNameはOracle HTTP Serverインスタンスの名前に依存することに注意してください。この例では、Oracle HTTP Serverインスタンスの名前はohs1です

editCustom()
cd('oracle.ohs')
cd('oracle.ohs:OHSInstance=ohs1,component=OHS,type=OHSInstance.NMProp')

4. umaskの値を必要な値に設定します。

startEdit()
set('Umask','0022')

5. 変更を保存してアクティブ化します。

save()
activate()

WLSTを使用したログ・レベルの構成

WLSTコマンドを使用して、エラー・ログの冗長度を制御する、LogLevelディレクティブを設定できます。

注意:

LogLevelディレクティブの詳細は、Apacheのドキュメント(http://httpd.apache.org/docs/current/mod/core.html#loglevel)を参照してください

次の手順に従い、WLSTコマンドを使用してLogLevelディレクティブを設定します。

1. WLSTを起動します。

$ORACLE_HOME/oracle_common/common/bin/wlst.sh

2. 管理サーバーに接続します。

connect('<user-name>', '<password>','<host>:<port>')

3. editCustom()コマンドを使用して、oracle.ohs MBeanのルートに移動します。editCustom()コマンドは、WLSTが管理サーバーに接続されている場合にのみ入力できます。cdを使用して管理オブジェクトの階層をナビゲートします。この場合、oracle.ohsの下のohs1です。startEdit()コマンドを使用して編集セッションを開始します。

editCustom()
cd('oracle.ohs')
cd('oracle.ohs:type=OHSInstance,name=ohs1')
startEdit()

4. setコマンドを使用してログ・レベル属性の値を設定します。次の例では、グローバル・ログ・レベルをtrace7に、モジュールのステータス・ログ・レベルをerrorに、モジュールのenvログ・レベルをwarn (警告)に設定します。

set('LogLevel','trace7 status:error env:warn')

5. 変更を保存してアクティブ化します。この編集セッションと関連付られた編集ロックは、アクティブ化が完了すると解放されます。

save()
activate()

Oracle HTTP Serverのログ・ディレクティブ

次の項では、httpd.confファイル内のOracle HTTP Serverのエラー・ログおよびアクセス・ログに関連するディレクティブについて説明します。

- Oracle Diagnostic Loggingディレクティブ

- Apache HTTP Serverログ・ディレクティブ

Oracle Diagnostic Loggingディレクティブ

Oracle HTTP Serverはデフォルトで、診断メッセージの生成にOracle Diagnostic Logging (ODL)を使用します。ODLを使用したロギングを設定する場合、次のディレクティブを使用します。

- OraLogMode

- OraLogDir

- OraLogSeverity

- OraLogRotationParams

OraLogMode

これにより、ログ・メッセージを生成する形式を選択できます。レガシーのApache HTTP Server形式またはODLテキスト形式でログ・メッセージを生成するように選択できます。

OraLogMode Apache | ODL-Text

デフォルト値: ODL-Text

例: OraLogMode ODL-Text

注意:

Apache HTTP Serverログ・ディレクティブのErrorLogおよびLogLevelは、OraLogModeがApacheに設定されている場合のみ有効です。OraLogModeがODL-Textに設定されている場合、ErrorLogおよびLogLevelディレクティブは無視されます。

OraLogDir

すべてのログ・ファイルが含まれるディレクトリへのパスを指定します。このディレクトリは存在している必要があります。

このディレクティブは、OraLogModeがODL-Textに設定されている場合にのみ使用されます。OraLogModeがApacheに設定されている場合、OraLogDirは無視され、かわりにErrorLogが使用されます。

OraLogDir <path>

デフォルト値: ORACLE_INSTANCE/servers/componentName/logs

例: OraLogDir /tmp/logs

OraLogSeverity

メッセージ重大度を設定できます。このディレクティブを使用して指定したメッセージ重大度は、必要な最低レベルのメッセージ重大度として解釈され、その重大度以上のメッセージはすべてログに記録されます。

このディレクティブは、OraLogModeがODL-Textに設定されている場合にのみ使用されます。OraLogModeがApacheに設定されている場合、OraLogSeverityは無視され、かわりにLogLevelが使用されます。次の構文で、short_module_identifierNameは末尾の_moduleが省略されたモジュール名です。

OraLogSeverity [short_module_identifierName] <msg_type>[:msg_level]

デフォルト値: WARNING:32

例: OraLogSeverity mime NOTIFICATION:32

msg_type

メッセージ・タイプは大文字でも小文字でも指定できますが、メッセージ出力は大文字で表示されます。このパラメータは、次のいずれかの値にする必要があります。

- INCIDENT_ERROR

- ERROR

- WARNING

- NOTIFICATION

- TRACE

msg_level

このパラメータは1から32の整数にする必要があります。重大度が最も高いのが1で、最も低いのが32です。レベル1を使用した方が、レベル32を使用した場合よりもメッセージが少なくなります。

OraLogRotationParams

エラー・ログ・ファイルのローテーション・ポリシーを選択できます。このディレクティブは、OraLogModeがODL-Textに設定されている場合にのみ使用されます。OraLogModeがApacheに設定されている場合、OraLogRotationParamsは無視されます。

OraLogRotationParams <rotation_type> <rotation_policy>

デフォルト値: S 10:70

例: OraLogRotationParams T 43200:604800 2009-05-08T10:53:29

rotation_type

このパラメータはS(サイズベースのローテーション)またはT(タイムベースのローテーション)のいずれかです。

rotation_policy

rotation_typeがS(サイズベース)に設定されている場合は、rotation_policyパラメータを次のように設定します。

maxFileSize:allFilesSize (MB)

たとえば、10:70として構成した場合、エラー・ログ・ファイルが10MBに達するたびにローテーションが行われます。また、すべてのエラー・ログ・ファイルの合計として70MBが許可されます(最大で70/10=7個のエラー・ログ・ファイルが保存されます)。

rotation_typeがT(タイムベース)に設定されている場合は、rotation_policyパラメータを次のように設定します。

frequency(in sec) retentionTime(in sec) startTime(in YYYY-MM-DDThh:mm:ss)

たとえば、43200:604800 2009-05-08T10:53:29として構成した場合、エラー・ログは43200秒(12時間)ごとにローテーションが行われます。ローテーションされたログ・ファイルは、2009年5月5日の10時53分29秒から最大で604800秒(7日)間保存されます。

Apache HTTP Serverログ・ディレクティブ

Oracle HTTP Serverではデフォルトでエラー・ログにODLが使用されますが、エラー・ログ・メッセージがレガシーのApache HTTP Serverメッセージ形式で生成されるようにOraLogModeディレクティブをApacheに構成することもできます。この項では、次のディレクティブについて説明します。

- ErrorLog

- LogLevel

- LogFormat

- CustomLog

ErrorLog

ErrorLogディレクティブは、サーバーにより検出されたエラーが書き込まれるファイル名を設定します。ファイルパスが絶対パスでない場合は、ServerRootからの相対パスであると想定されます。

このディレクティブは、OraLogModeがApacheに設定されている場合にのみ使用されます。OraLogModeがODL-Textに設定されている場合、ErrorLogは無視され、かわりにOraLogDirが使用されます。

関連項目:

Apache ErrorLogディレクティブの詳細は、次を参照してください。

http://httpd.apache.org/docs/current/mod/core.html#errorlog

LogLevel

LogLevelディレクティブは、エラー・ログに記録されるメッセージの冗長性を調整します。

このディレクティブは、OraLogModeがApacheに設定されている場合にのみ使用されます。OraLogModeがODL-Textに設定されている場合、LogLevelは無視され、かわりにOraLogSeverityが使用されます。

関連項目:

Apache HTTP Server LogLevelディレクティブの詳細は、次を参照してください。

http://httpd.apache.org/docs/current/mod/core.html#loglevel

LogFormat

LogFormatディレクティブは、アクセス・ログ・ファイルの形式を指定します。デフォルトでは、Oracle HTTP Serverには次の4つのアクセス・ログ形式が定義されています。

LogFormat "%h %l %u %t %E \"%r\" %>s %b" commonLogFormat "%h %l %u %t %E \"%r\" %>s %b \"%{Referer}i\" \"%{User-Agent}i\"" combinedLogFormat "%h %l %u %t %E \"%r\" %>s %b \"%{Referer}i\" \"%{User-Agent}i\" %I %O" combinedio

関連項目:

Apache HTTP Server LogFormatディレクティブの詳細は、次を参照してください。

http://httpd.apache.org/docs/current/mod/mod_log_config.html#logformat

CustomLog

CustomLogディレクティブは、サーバーへのリクエストをログに記録する場合に使用します。ログ形式を指定し、オプションで環境変数を使用して、リクエストの特性に基づいてロギングを条件付きで実行することもできます。デフォルトでは、アクセス・ログ・ファイルは共通ログ形式を使用するように構成されています。

関連項目:

Apache CustomLogディレクティブの詳細は、次を参照してください。

http://httpd.apache.org/docs/current/mod/mod_log_config.html#customlog

Oracle HTTP Serverログの表示

Oracle HTTP Serverにはエラー・ログとアクセス・ログの主に2種類のログ・ファイルがあります。エラー・ログ・ファイルは、サーバーのパフォーマンスを良好に保つための重要な情報源です。エラー・ログには、システム管理者が問題を簡単に診断して修正できるように、問題の状況に関するすべての情報が記録されます。アクセス・ログ・ファイルには、サーバーが処理するあらゆるHTTPトランザクションの基本情報が含まれます。この情報を使用して、サーバーの使用状況パターンに関する統計レポートを生成できます。

エラー・ログおよびアクセス・ログの詳細は、サーバー・ログの概要を参照してください。

Oracle HTTP Serverのログを表示する方法を次に示します。

- Fusion Middleware Controlを使用したログの表示

- WLSTを使用したログの表示

- テキスト・エディタでのログの表示

Fusion Middleware Controlを使用したログの表示

Oracle HTTP Serverインスタンスのログ・メッセージにアクセスするには、次の手順を実行します。

1. Oracle HTTP Serverのホームページに移動します。

2. ログ・メッセージを表示するサーバー・インスタンスを選択します。

3. 「Oracle HTTP Server」ドロップダウン・リストから、「ログ」、「ログ・メッセージの表示」の順に選択します。

「ログ・メッセージ」ページが開きます。

ログ・ファイルの検索および表示の詳細は、『Oracle Fusion Middlewareの管理』のFusion Middleware Controlを使用したログ・ファイルとそのメッセージの表示に関する項を参照してください。

WLSTを使用したログの表示

コマンド行からサーバーのログの取得と表示を行うには、ノード・マネージャに接続して、適切なWebLogic Scripting Tool (WLST)コマンドを発行する必要があります。これらのコマンドを使用して、次のような機能のいずれかを実行できます。

- サーバー・ログのリスト表示。

- 特定のログの内容を表示。

注意:

WLSTの使用方法の詳細は、『WebLogic Scripting Toolの理解』を参照してください。

この手順を実行してみる前に、次の内容を実行します。

コマンド行からサーバー・メトリックにアクセスを試みる前に、次の内容を確認してください。

- ドメインが存在すること。

- 使用するインスタンスが存在すること。

- インスタンスのマシン上でノード・マネージャが実行中であること。

この手順を使用するには、インスタンスと管理サーバーが動作中でも構いませんが、その必要はありません。

WLSTを使用してメトリックを表示するには、次の手順を実行します。

注意:

管理対象のドメインでは、この手順は、インスタンスが動作状態であるか停止状態であるかによって、管理マシンあるいはリモート・マシンで動作している管理サーバー上で動作します。スタンドアロン・ドメインでは、手順はローカル・マシン上でしか動作しませんが、インスタンスは動作中と停止中のいずれであっても構いません。

1. WLSTを起動します。

LinuxまたはUNIXの場合:

$ORACLE_HOME/oracle_common/common/bin/wlst.sh

Windowsの場合

C:\ORACLE_HOME\oracle_common\common\bin\wlst.cmd

2. 選択したドメイン・ディレクトリ(ORACLE_HOME/user_projects/domains/domainNameなど)からノード・マネージャに接続します。

nmConnect('username', 'pwd', localhost, 5556, domainName)

3. 実行するタスクに応じて、次のWLSTコマンドの1つを入力します。

- listLogs(nmConnected=1, ...)

- displayLogs(nmConnected=1, ...)

例:

listLogs(nmConnected=1, target='ohs1')
displayLogs(nmConnected=1, target='ohs1', tail=5)

テキスト・エディタでのログの表示

また、テキスト・エディタを使用して、DOMAIN_HOMEディレクトリから直接Oracle HTTP Serverログ・ファイルを表示することもできます。デフォルトでは、Oracle HTTP Serverログ・ファイルは、DOMAIN_HOME/servers/component_name/logsディレクトリにあります。ログ・ファイルをご使用のローカル・クライアントにダウンロードして、別のツールを使用してログ・ファイルを表示します。

ECID情報の記録

次の項では、エラー・ログおよびアクセス・ログにExecution Context ID (ECID)情報を記録するようにOracle HTTP Serverを構成する方法について説明します。

- ECID情報について

- ECID情報用エラー・ログの構成

- ECID情報用アクセス・ログの構成

ECID情報について

ECIDとは、Oracleコンポーネント間のリクエストにアタッチ可能なグローバルに一意のIDです。ECIDを使用すると、複数のリクエストが並行して処理される場合に同じリクエストに関する複数のログ・メッセージを追跡できます。

Oracle HTTP Serverモジュールmod_contextは、URIまたはCookieの中のECID-ContextキーあるいはECID-Contextヘッダーに対する受信リクエストをそれぞれスキャンします。見つかった場合には、有効であれば値を実行コンテキストとして使用します。見つからなかった場合には、mod_contextはリクエストに対して新たな実行コンテキストを生成し、ECID-Contextヘッダーの値として加算します。

ECID情報用エラー・ログの構成

ECID情報は、Oracle Diagnostic Logging (ODL)の一部として記録されます。ODLは、診断メッセージおよびログ・ファイルのための共通書式を示す診断メッセージを生成する方法と、様々なコンポーネントからのすべての診断メッセージを相互に関係付ける方法です。

ECIDが記録されるようにOracle HTTP Serverのエラー・ログを構成するには、httpd.conf内のOraLogModeディレクティブを、デフォルト値であるodlに必ず設定してください。odl値は標準のApacheログ書式で、特に1つのリクエストに関連付けられたログ記録用のECID情報です。

OraLogModeおよびこのディレクティブに対する他に取りうる値の詳細は、OraLogModeを参照してください。

注意:

モジュール固有のロギング重大度を有効にして初めてモジュールがロギングを実行できるように、これらのディレクティブは、httpd.confファイルでモジュールがロードされる前に(LoadModuleディレクティブの前に)指定することをお薦めします。

ECID情報用アクセス・ログの構成

デフォルトで、httpd.confファイルのLogFormatディレクティブは、ECID情報を取得するように構成されています。

LogFormat "%h %l %u %t %E \"%r\" %>s %b" common

マイクロ秒単位で測定するレスポンス時間を追加する場合、次のように%Dを追加します。

LogFormat "%h %l %u %t %E %D \"%r\" %>s %b" common

ECID情報の取得を抑制するには、LogFormatディレクティブから%Eを削除します。

LogFormat "%h %l %u %t \"%r\" %>s %b" common

SSLリクエストの終了

この項では、mod_wl_ohsモジュールがWebLogic Serverにリクエストを転送する、Oracle HTTP Serverの前あるいはその中で、SSLを使用してリクエストを停止する方法を説明します。リクエストがOracle HTTP Serverに届く前にSSLを停止するか、リクエストがサーバーの中にある時に停止するかは、トポロジによります。SSLを停止する一般的な理由は、第三者によって通信中のデータが傍受されるリスクを伴うことなく、別の方法によって内部ネットワークが保護されている場合の、パフォーマンス上の考慮によるものです。もうひとつの理由としては、WebLogic ServerがHTTPSリクエストを受け付けるように構成されていない場合があります。

- ロード・バランサでのSSLの停止について

- Oracle HTTP ServerでのSSLの停止について

ロード・バランサでのSSLの停止について

SSLを使用しているリクエストをOracle HTTP Serverへの到達前に終了させるロード・バランサやリバース・プロキシなどの装置を使用している場合には、サーバーは、あたかもHTTPSを介して受信したようにリクエストを扱う構成とする必要があります。さらに、サーバーは、クライアントにHTTPS応答を返すように構成される必要があります。

表8-1に、ブラウザからHTTPSを介してWebLogic Serverにリクエストが送信される場合の例を示します。ロード・バランサは、SSLを停止し、リクエストをHTTPとして送信します。Oracle HTTP Serverは、あたかもHTTPSを介して受信したようにリクエストを処理する構成とする必要があります。

図8.1 Oracle HTTP Serverの前にSSLを停止

ロード・バランサでのSSLの停止

Oracle HTTP Serverに命令を与えてHTTPSを介して受信されたかのようにリクエストを扱うには、mod_certheadersモジュールのSimulateHttpsディレクティブでhttpd.confファイルを構成します。

mod_certheadersモジュールでの詳細は、mod_certheadersモジュール—リバース・プロキシの有効化を参照してください。

注意:

SSLがOracle HTTP Serverで構成されている場合(すなわち、HTTPSを使用して直接Oracle HTTP Serverにアクセスしている場合)には、この手順は不要です。

1. サーバーの外部名とポート番号を使用して、たとえばhttpd.conf構成ファイルを次のように構成します。

ServerName <www.company.com:port>

2. mod_certheadersモジュールをロードするように、httpd.conf構成ファイルをたとえば次のように構成します。

- UNIXの場合:

LoadModule certheaders_module libexec/mod_certheaders.so

- Windowsの場合:

LoadModule certheaders_module modules/ApacheModuleCertHeaders.dll
AddModule mod_certheaders.c

注意:

他のAddModuleディレクティブにAddModule行を含めることを推奨します。

3. HTTPS応答をクライアントに返すように、httpd.confファイルの最後にあるSimulateHttpsディレクティブをたとえば次のように構成します。

# For use with other load balancers and front-end devices:
SimulateHttps On

4. Oracle HTTP Serverを再起動してサーバーへのアクセスをテストします。特に、https://host:port/index.htmlのような静的ページにアクセス可能であるかテストします。

基本設定として構成をテストします。問題が生じた場合には、仮想ホストなどの潜在的な問題とのオーバーラップを避けるため、ここでトラブルシューティングを行ってください。

5. 理想的には、すべてのHTTPSリクエストを処理するようにhttpd.confファイルのVirtualHostを構成するとよいでしょう。こうすると、HTTPSリクエストがHTTPリクエストからよりスケーラブルに分離されます。多目的サイトの場合や、ロード・バランサなどの装置がHTTPリクエストとHTTPSリクエストの両方を処理するOracle HTTP Serveの前にある場合には、こうした構成がさらに望まれます。

次の命令例では、mod_certheadersモジュールをロードし、HTTPSリクエストだけを処理するように仮想ホストを生成します。

# Load correct module here or where other LoadModule lines exist:
LoadModule certheaders_module libexec/mod_certheaders.so
# This only handles https requests:
<VirtualHost <name>:<port>
# Use name and port used in url:
ServerName <www.company.com:port>
SimulateHttps On
# The rest of your desired configuration for this VirtualHost goes here
</VirtualHost>

6. Oracle HTTP Serverを再起動し、サーバーへのアクセスをテストします。最初にhttps://host:port/index.htmlのような静的ページをテストし、次にご使用のアプリケーションをテストします。

Oracle HTTP ServerでのSSLの停止について

SSLがOracle HTTP Serverで構成されていてOracle WebLogic Serverでは構成されていない場合には、Oracle HTTP Serverから送信されるリクエストに対するSSLを停止できます。

次の図はリクエスト・フローをまとめたもので、HTTPSがどこで停止するかを示しています。図8-2では、ブラウザからHTTPSリクエストが送信されます。ロード・バランサは、HTTPSリクエストをOracle HTTP Serverに送信します。SSLはOracle HTTP Serverで停止し、HTTPリクエストがWebLogic Serverに送られます。

図8-2 Oracle HTTP ServerでSSLを停止(ロード・バランサあり)

図8-3では、ロード・バランサは存在せず、HTTPSリクエストは直接Oracle HTTP Serverに送信されます。この場合にも、SSLはOracle HTTP Serverで停止し、HTTPリクエストがWebLogic Serverに送られます。

図8-3 Oracle HTTP ServerでSSLを停止(ロード・バランサなし)

Oracle HTTP ServerでSSLを停止

Oracle HTTP Serverに命令を与えてHTTPSを介して受信されたかのようにリクエストを扱うには、mod_wl_ohs.confファイルのWLSProxySSLディレクティブを構成し、SecureProxyディレクティブが構成されていないことを確認します。

1. mod_wl_ohs.confファイルを構成して、ご使用の非SSL構成の管理対象サーバーの場所に対するWLSProxySSLディレクティブを次のように追加します。

WLProxySSL ON

2. ロード・バランサなどの装置をOracle HTTP Server (同じくSSLを使用)の前で使用している場合には、WL-Proxy-SSLをすでに設定済であるかどうかによって、次の例のように、かわりにWLProxySSLPassThroughディレクティブを構成することが必要な場合があります。

WLProxySSLPassThrough ON

詳細は、ご使用のロード・バランサのドキュメントを参照してください。WLProxySSLPassThroughの詳細は、『Oracle WebLogic Serverプロキシ・プラグイン12.2.1の使用』のOracle WebLogic Serverプロキシ・プラグインのパラメータに関する項を参照してください。

3. コンポーネント間の所定の通信に障害を与えますので、SecureProxyディレクティブが構成されていないことを確認してください。SSLが全体的に使用されている場合にかぎり、このディレクティブを使用します。次の例では、SecureProxyディレクティブはコメントアウトされています。

# To configure SSL throughout (all the way to WLS):
# SecureProxy ON
# WLSSLWallet  "<Path to Wallet>"

4. Oracle HTTP Serverを再起動し、https://host:port/path/application_nameなどのJavaアプリケーションへのアクセスをテストします。

9 アプリケーション・セキュリティの管理

この章では、Oracle HTTP Serverのセキュリティ機能の概要、およびセキュアなWebサイトを設定するための構成情報について説明します。

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

- Oracle HTTP Serverのセキュリティの概要

- ユーザーのクラスとその権限

- 保護対象のリソース

- 認証、認可およびアクセス制御

- SSLの実装

- mod_securityの使用

- 信頼フラグの使用

Oracle HTTP Serverのセキュリティについて

セキュリティは、認証、認可および秘匿性の3つのカテゴリに分けられます。Oracle HTTP Serverは、これら3種類のカテゴリをすべてサポートします。Oracle HTTP ServerはApache HTTP Serverに基づいており、そのセキュリティ・インフラストラクチャは主にApacheモジュール(mod_auth_basic、mod_authn_file、mod_auth_userおよびmod_authz_groupfile)、とWebGateにより提供されます。mod_auth_basic、mod_authn_file、mod_auth_userおよびmod_authz_groupfileモジュールは、ユーザー名とパスワードのペアに基づく認証を提供します。mod_authz_hostはリクエストの特性(ホスト名やIPアドレスなど)に基づいてサーバーへのアクセスを制御し、mod_osslは、SSLを介したX.509クライアント証明書によって秘匿性および認証を提供します。

Oracle HTTP Serverは、httpd.confファイル内のアクセス制御ディレクティブを使用して構成できるアクセス制御、認証および認可の方法を提供します。URLリクエストはOracle HTTP Serverに到達すると、サーバーのデフォルトおよび構成パラメータにより指定された手順で処理されます。URLリクエストの処理手順は、多くのWebリスナーに共通のモジュールまたはプラグイン・アーキテクチャを介して実装されます。

ユーザーおよびその権限のクラス

Oracle HTTP Serverは、ユーザーを認可および認証してから、そのユーザーにサーバーのリソースへのアクセスまたは変更を許可します。Oracle HTTP Serverを使用してサーバーにアクセスする3つのユーザー・クラスと、それらの権限を次に示します。

- 認証を提供せずにサーバーにアクセスするユーザー。これらのユーザーは、保護されていないリソースにしかアクセスできません。

- Oracle HTTP Server内のモジュールによって認証され、将来的に認可される予定のユーザー。これには、mod_auth_basic、mod_authn_file、mod_auth_userおよびmod_authz_groupfileモジュールのようなApache HTTP ServerモジュールとOracleのmod_osslにより認証されたユーザーが含まれます。このようなユーザーは、http.confファイル内で定義されたURLにアクセスできます。

関連項目:

認証、認可およびアクセス制御

- Oracle Access Managerによって認証されたユーザー。これらのユーザーは、シングル・サインオンによって許可されたリソースにアクセスできます。

関連項目:

Oracle Platform Security Servicesによるアプリケーションの保護

保護対象のリソース

Oracle HTTP Serverは、管理対象のすべてのリソースを保護するように構成できます。リソースが必要とする任意の保護を構成することができます。

認証、認可およびアクセス制御

Oracle HTTP Serverは、ユーザーの認証および認可を、アクセス制御、ユーザーの認証および認可の2段階で行います。

- アクセス制御(第1段階): これは、受信HTTPリクエストとそのヘッダーの詳細(IPアドレスやホスト名など)に基づいています。

- ユーザーの認証および認可(第2段階): これは、HTTPサーバー構成に応じた様々な基準に基づいています。ユーザー名とパスワードのペアでユーザーを認証するようにサーバーを構成できます。ユーザー名とパスワードは、既知のユーザーおよびパスワードのリストと比較して確認されます。また、Webアプリケーションに対してシングル・サインオン認証を使用するようにサーバーを構成したり、SSLを介したX.509クライアント証明書を使用するようにサーバーを構成することもできます。

アクセス制御

アクセス制御とは、リソースに対するアクセスを制御する手段のことです。

関連項目:

リソースへのアクセス制御の構成方法の詳細は、Apache HTTP Serverドキュメントを参照してください。

ユーザーの認証および認可

認証は、ユーザーが本物であることを確認するプロセスです。認可は、ユーザーにリソースへのアクセスや情報の取得を許可するプロセスです。Apache HTTP ServerモジュールまたはWebGateのいずれかを使用してユーザーを認証できます。

- Apache HTTP Serverモジュールを使用したユーザーの認証

- WebGateを使用したユーザーの認証

Apache HTTP Serverモジュールを使用したユーザーの認証

Apache HTTP Server認証ディレクティブを使用して、ユーザーが本物であることを確認できます。

関連項目:

ユーザーを認証する方法の詳細は、次のApache HTTP Serverのドキュメントの認証および認可に関する項を参照してください。

http://httpd.apache.org/docs/2.4/howto/auth.html

WebGateを使用したユーザーの認証

WebGateによって、Oracle HTTP Serverのシングル・サインオン(SSO)が可能になります。WebGateは受信リクエストを調べて、リクエストされたリソースが保護されているかどうかを判断し、保護されている場合は、ユーザーのセッション情報を取得します。

WebGateを使用すると、Oracle HTTP ServerはSSO対応のパートナ・アプリケーションとなり、SSOを使用してユーザーを認証することが可能になり、Oracleシングル・サインオンを使用してユーザーのアイデンティティの取得ができるようになり、また、Oracle HTTP ServerからアクセスされるWebアプリケーションはユーザーのアイデンティティを使用することが可能になります。

WebGateを使用することで、Webアプリケーションは、SSO認証を必要とするURLを登録できます。WebGateは、Oracle HTTP Serverが受信したクエストからSSO認証が必要なリクエストを検出し、それらをSSOサーバーにリダイレクトします。SSOサーバーによってユーザーが認証されると、ユーザーの認証済アイデンティティをWebGateにセキュア・トークンで渡します。WebGateがトークンからユーザーのアイデンティティを取得すると、それをOracle HTTP Serverからアクセスされるアプリケーション(Oracle WebLogic Server上で実行されているアプリケーション、CGI、Oracle HTTP Serverによって処理される静的ファイルなど)に伝搬します。

関連項目:

Oracle Platform Security Servicesによるアプリケーションの保護

FMW監査フレームワークのサポート

Oracle HTTP Serverは、FMW共通監査フレームワークを使用した認証および認可の監査をサポートしています。監査の有効化の一部として、Oracle HTTP ServerはOraAuditEnableと呼ばれるディレクティブをサポートしています(デフォルトはOn)。有効化されると、auditconfig.xmlで有効化されている監査イベントが監査ログに記録されます。デフォルトでは、auditconfig.xmlで有効化されている監査イベントはありません。

OraAuditEnableがOffに設定されている場合は、auditconfig.xmlでの設定に関係なく監査は無効になります。

Fusion Middleware Controlを使用するか、またはauditconfig.xmlを直接編集することで、監査フィルタを構成できます。

関連項目:

『Oracle Platform Security Servicesによるアプリケーションの保護』の監査機能の概要に関する項

Fusion Middleware Controlを使用した監査ポリシーの管理

Fusion Middleware Controlの「監査ポリシー」ページを使用して、監査ポリシーを選択したOracle HTTP Serverインスタンスに割り当てます。

1. 「Oracle HTTP Server」ホーム・ページに移動します。

2. 監査ポリシーを適用するサーバー・インスタンスを選択します。

3. 「Oracle HTTP Server」ドロップダウン・メニューから、「セキュリティ」、「監査ポリシー」の順に選択します。

「監査ポリシー」ページが開きます。

監査ポリシーの設定の詳細は、『Oracle Platform Security Servicesによるアプリケーションの保護』のFusion Middleware ControlによるJava Componentsの監査ポリシーの管理に関する項を参照してください

SSLの実装

Oracle HTTP Serverは、Secure Sockets Layer (SSL)プロトコルを使用して通信を保護します。SSLは、メッセージの暗号化、整合性および認証を提供することで、通信を保護します。SSL標準により、関係するコンポーネント(ブラウザやHTTPサーバーなど)は、どの暗号化、認証および整合性メカニズムを使用するかのネゴシエーションができます。

Oracle HTTP Serverに対するSSLの実装方法の詳細は、『Oracle Fusion Middlewareの管理』の「Web Tierに対するSSLの実装」を参照してください。OracleのSSLモジュールであるmod_osslの使用の詳細は、mod_osslモジュール—暗号(SSL)の有効化を参照してください。mod_osslディレクティブの詳細は、mod_osslモジュールを参照してください。

mod_wl_ohsモジュールにもSSL用の構成が含まれています。詳細は、『Oracle WebLogic Serverプロキシ・プラグイン12.2.1の使用』のプラグインとSSLの併用に関する項およびWeb Serverプラグインのパラメータに関する項を参照してください。

この項では、このリリースでサポートされているSSL機能について説明します。

- グローバル・サーバーIDのサポート

- PKCS #11のサポート

- SSLとロギング

グローバル・サーバーIDのサポート

この機能は、「ステップアップ」、「サーバー・ゲート暗号化」または「グローバル・サーバーID」などと様々に呼ばれる、サポートSSLプロトコル機能を追加します。「ステップアップ」とは、旧式で低強度の暗号化ブラウザの「ステップアップ」を可能にする機能であり、これにより、512ビットより長い公開鍵および64ビットより長いバルク暗号化鍵をSSLプロトコルで使用できるようになります。つまり、512ビットを超える公開鍵を含みかつ「ステップアップ」デジタル著作権を含むサーバーX.509証明書が、Oracle Application Serverで使用できるようになりました。このような証明書は、(通常は証明書自体に1024ビット証明書が含まれますが)しばしば「128ビット」証明書と呼ばれます。Verisign Secure Site Proはこのような証明書の一例であり、Oracle Application Serverで使用できるようになっています。

グローバル・サーバーID機能はデフォルトで提供されており、構成は必要ありません。

PKCS #11のサポート

公開鍵暗号化規格#11(略してPKCS #11)とは、システムがハードウェア・セキュリティ・モジュールを使用する方法の概要を示した公開鍵暗号化仕様であり、これは基本的に、暗号化機能(暗号/復号)が実行され、暗号化鍵が格納される「箱」となっています。

Oracle HTTP Serverでは、nCipherによる専用のSSLハードウェアを使用するオプションをサポートしています。nCipherは、認証されたサード・パーティのアクセラレータで、SSLで使用されるPKI暗号のパフォーマンスを改善します。

関連項目:

- Oracle Fusion Middlewareの管理ガイド

- http://www.ncipher.com

SSLとロギング

SSL関連および通信関連のデバッギングは、SSLTraceLogLevelディレクティブを使用して設定できます。ここでは、ロギング要件に従って、ログ・レベルの様々な冗長性を設定できます。このディレクティブは、SSLログおよび通信ログを生成します。詳細は、SSLTraceLogLevelディレクティブを参照してください。

注意:

SSLログは、OHSログがINFOレベル以上に設定されている場合に機能します。

mod_securityの使用

mod_securityは、Oracle HTTP Serverに対する侵入攻撃を検出および防止するために使用できる、オープンソース・モジュールです。たとえば、mod_securityルールを指定して、すべての受信リクエストをスクリーニングし、ルールで指定された条件に一致するリクエストを拒否することができます。mod_securityモジュール(バージョン2.7.2)とその前提条件は、mod_security2.soという共有オブジェクトとして、ORACLE_HOME/ohs/modulesディレクトリ内のOracle HTTP Serverインストールに含まれています。

mod_securityの詳細は、mod_securityモジュールの構成を参照してください。

信頼フラグの使用

信頼フラグを使用すると、証明書に割り当てられた適切なロールによる、証明書チェーンの検証やパスの構築などの操作が簡単に実行できます。デフォルトでは、ウォレットで信頼フラグはサポートされていません。

orapkiユーティリティを使用して、Oracleウォレットにインストールされている証明書に信頼フラグを保持できます。また、信頼フラグをサポートするウォレットの作成と変換、適切なフラグの作成と各証明書での保持などを実行できます。信頼フラグと、それらをセキュリティ戦略に組み込む方法の詳細は、『Oracle Fusion Middlewareの管理』の信頼フラグの作成および管理に関する項を参照してください。

第III部 付録

この部には次の付録と用語集が含まれます。

- Oracle HTTP ServerのカスタムWLSTコマンド

- mod_proxy_fcgiおよびmod_authnz_fcgiモジュールへの移行

- よくある質問

- Oracle HTTP Serverのトラブルシューティング

- 構成ファイル

- プロパティ・ファイル

- OHSモジュール・ディレクティブ

A Oracle HTTP ServerのカスタムWLSTコマンド

次のOracle HTTP Server固有のWLSTコマンドがWebLogic Serverドメインのサーバーを管理するために提供されています。ほとんどがオンライン・コマンドであり、WLSTとそのドメインの管理サーバー間の接続が必要です。

この付録の内容は次のとおりです。

- Oracle HTTP ServerのカスタムWLSTコマンドのヘルプ

- カスタムWLSTコマンドの名前の変更

- Oracle HTTP Serverのコマンド

Oracle HTTP ServerのカスタムWLSTコマンドのヘルプ

Oracle HTTP ServerのカスタムWLSTコマンドについてはオンライン・ヘルプを使用できます。オンライン・ヘルプを取得するには、WLSTコマンド行にhelp('manageohs')と入力すると、Oracle HTTP ServerのすべてのカスタムWLSTコマンドが表示されます。

特定のカスタムWLSTコマンドを取得するには、WLSTコマンド行にhelp('custom_command_name')と入力します。次に例を示します。

help('ohs_createInstance')

カスタムWLSTコマンドの名前の変更

使いやすさと識別のしやすさの向上のため、次のOracle HTTP ServerのカスタムWLSTコマンドの名前が現在のリリースで変更されました。コマンド名に"OHS"が組み込まれるのではなく、コマンドに"ohs_"の接頭辞が付くようになりました。たとえば、createOHSInstanceコマンドはohs_createInstanceになりました。古いコマンド名は非推奨です。これらは現在のリリースでWLSTにより許容されますが、使用を避ける必要があります。古いコマンド名を使用すると、その名前は非推奨であることを伝えるメッセージが、新しいコマンドへのポインタとともに受信されます。

次の表に、新しいコマンド名と古いコマンド名をリストします。

表A-1 Oracle HTTP ServerのカスタムWLSTコマンドの新しい名前と古い名前

古い名前(非推奨)

新しい名前

addOHSAdminProperties

ohs_addAdminProperties

addOHSNMProperties

ohs_addNMProperties

createOHSInstance

ohs_createInstance

deleteOHSInstance

ohs_deleteInstance

Oracle HTTP Serverのコマンド

構成ウィザードではなく、ohs_createInstanceおよびohs_deleteInstanceコマンドを使用して、Oracle HTTP Serverインスタンスを作成および削除する必要があります。これらのカスタム・コマンドは追加のエラー・チェックを実行し、インスタンスの作成の場合は、自動ポート割当ても行います。

表A-2にリストしているカスタムWLSTコマンドを使用して、WebLogic ServerドメインのOracle HTTP Serverインスタンスを管理します。

表A-2 Oracle HTTP Serverコマンド

使用するコマンド

目的

WLSTでの使用

ohs_addAdminProperties

Oracle HTTP Serverの管理サーバーのプロパティ・ファイルにLogLevelプロパティを追加します。

オンライン

ohs_addNMProperties

Oracle HTTP Serverのノード・マネージャのプラグイン・プロパティ・ファイルにプロパティを追加します。

オンライン

ohs_createInstance

Oracle HTTP Serverの新しいインスタンスを作成します。

オンライン

ohs_deleteInstance

指定したOracle HTTP Serverインスタンスを削除します。

オンライン

ohs_exportKeyStore

キーストアを指定したOracle HTTP Serverインスタンスにエクスポートします。

オンライン

ohs_postUpgrade

ドメイン内のすべてのOracle HTTP Serverインスタンスのウォレットの内容(以前のバージョンからアップグレードされたOracle HTTP Serverインスタンスに対して有効なもの)をKSSデータベースにインポートします。

オンライン

ohs_updateInstances

Oracle HTTP Serverインスタンスが構成ウィザードを使用して作成された場合、KSSデータベースにキーストアを作成します。

オンライン

ohs_addAdminProperties

WLSTでの使用: オンライン

説明

ohs_addAdminPropertiesコマンドはLogLevelプロパティをOracle HTTP Server管理サーバーのプロパティ・ファイル(ohs_admin.properties)に追加します。LogLevelはohs_addAdminPropertiesが現在サポートしている唯一のパラメータです。このコマンドは、WLSTが管理サーバーのインスタンスに接続している場合にのみ使用できます。

構文

ohs_addAdminProperties(logLevel = 'value')

引数

説明

LogLevel

ログに書き込む情報の粒度。デフォルトはINFOで、その他の許容値は次のとおりです。

- ALL

- CONFIG

- FINE

- FINER

- FINEST

- OFF

- SEVERE

- WARNING

例

この例では、ログ・レベルをFINESTに設定したログ・ファイルを作成します。

ohs_addAdminProperties(logLevel = 'FINEST')

ohs_addNMProperties

WLSTでの使用: オンライン

説明

ohs_addNMPropertiesコマンドはプロパティをOracle HTTP Serverノード・マネージャのプラグイン・プロパティ・ファイル(ohs_nm.properties)に追加します。このコマンドは、WLSTが管理サーバーのインスタンスに接続している場合にのみ使用できます。

構文

ohs_addNMProperties(logLevel = 'value', machine='node-manager-machine-name')

引数

説明

LogLevel

ログに書き込む情報の粒度。デフォルトはINFOで、その他の許容値は次のとおりです。

- ALL

- CONFIG

- FINE

- FINER

- FINEST

- OFF

- SEVERE

- WARNING

machine

ノード・マネージャを実行するマシンの名前。

例

この例では、ターゲット・マシンmy_NM_machineのパス<domain_dir>/system_components/OHSの下に、ログ・レベルをFINESTに設定してohs_nm.logという名前のログ・ファイルを作成します。ユーザーはノード・マネージャを再起動する必要はありません。

ohs_addNMProperties(logLevel = 'FINEST', machine = 'my_NM_machine')

ohs_createInstance

WLSTでの使用: オンライン

説明

ohs_createInstanceコマンドでは、Oracle HTTP Serverの新しいインスタンスを作成し、明示的に指定されるか自動的に割り当てられるリスニング・ポートなどの重要な構成が可能です。

構文

ohs_createInstance(instanceName='xxx', machine='yyy', serverName='zzz', ...)

引数

定義

instanceName

作成する管理対象インスタンスの名前。

machine

インスタンスの既存マシンのエントリ。この名前(しばしば<hostName>.myCorp.com)はWebLogic Serverドメインの作成時に設定されます。名前を忘れた場合は、$ORACLE_INSTANCE/config/config.xmlを確認して<machine>ブロックを検索します。または、WLSTで、次を実行することでマシン名を見つけることができます。

serverConfig()
cd('Machines')
ls()

listenPort

(オプション) 非SSLサーバーのポート番号。この値が指定されない場合、ポートは自動的に割り当てられます。リスニング・ポートは通常7777から始まり、ここから順次増加します。

sslPort

(オプション) SSL仮想ホストのポート番号。この値が指定されない場合、ポートは自動的に割り当てられます。SSLポートは通常4443から始まり、ここから順次増加します。

adminPort

(オプション) ノード・マネージャとの通信に使用するポート番号。この値が指定されない場合、ポートは自動的に割り当てられます。管理ポートは通常9999から始まり、ここから順次増加します。

serverName

(オプション) 非SSLサーバーのServerNameディレクティブの値。この値が指定されない場合、マシンのホスト名およびリスニング・ポートを使用してこの値が作成されます。

例

次の例では、マシンabc03.myCorp.com上で動作するohs1というOracle HTTP Serverインスタンスを作成します。

ohs_createInstance(instanceName='ohs1', machine='abc03.myCorp.com')

ohs_deleteInstance

WLSTでの使用: オンライン

説明

ohs_deleteInstanceコマンドは指定したOracle HTTP Serverインスタンスを削除します。インスタンスは削除する前に停止しておく必要があります。インスタンスがUNKNOWNまたはRUNNING状態の場合、このコマンドによってエラーが返されます。

構文

ohs_deleteInstance(instanceName='xxx')

instanceNameはOracle HTTP Serverインスタンスの名前です。

例

次の例では、Oracle HTTP Serverインスタンスohs1を削除します。

ohs_deleteInstance(instanceName='ohs1')

ohs_exportKeyStore

WLSTでの使用: オンライン

説明

ohs_exportKeyStoreコマンドはキーストアを指定したOracle HTTP Serverインスタンスの場所にエクスポートします。このコマンドは、WLSTが管理サーバーのインスタンスに接続している場合にのみ使用できます。このコマンドの使用方法の詳細は、WLSTを使用したキーストアのOracle HTTP Serverインスタンスへのエクスポートを参照してください。

構文

ohs_exportKeyStore(keyStoreName='<keyStoreName>', instanceName = '<instanceName>')

引数

説明

keyStoreName

キーストアの名前。

instanceName

Oracle HTTP Serverインスタンスの名前。

キーストアの命名規則

キーストアの名前(keyStoreName)は文字列<instanceName>_で始まる必要があります。

たとえば、キーストアがohs1という名前のOracle HTTP Serverインスタンスにエクスポートされる必要があるとします。この場合、ohs1にエクスポートされる必要のあるすべてのキーストアの名前は、ohs1_で始まる必要があります。

キーストアの作成中にこの構文に従わなかった場合、キーストアのエクスポートは成功しない可能性があります。

例

この例では、キーストアohs1_myKeystoreをOracle HTTP Serverインスタンスohs1にエクスポートします。

ohs_exportKeyStore(keyStoreName='ohs1_myKeystore', instanceName = 'ohs1')

ohs_postUpgrade

WLSTでの使用: オンライン

説明

前のバージョンのOracle HTTP Serverからリリース12c (12.2.1)にアップグレードした後に、ohs_postUpgradeコマンドを使用します。

リリース12c (12.2.1)以前は、Oracle HTTP Serverインスタンス/コンポーネントはウォレットをKSSと統合せずに使用していました。アップグレード・アシスタントを使用して12c (12.2.1)にアップグレードする場合、既存のウォレット・コンテンツは高度な管理のためにKSSデータベースにインポートされる必要があります。

ohs_postUpgradeコマンドではドメイン内のすべてのOracle HTTP Serverインスタンス間で解析が行われ、同じキーストア名に対するエントリがデータベースに存在しない場合、そのウォレットがKSSデータベースにインポートされます。このコマンドは、WLSTが管理サーバーのインスタンスに接続している場合にのみ使用できます。このコマンドの使用の詳細は、Oracle HTTP Serverの以前のリリースからのアップグレードおよびWLSTを使用したアップグレード後のウォレットのKSSデータベースへのインポートを参照してください。

構文

ohs_postUpgrade()

このコマンドは引数を取りません。

例

ohs_postUpgrade()

ohs_updateInstances

WLSTでの使用: オンライン

説明

WLSTが管理サーバー・インスタンスに接続されている場合のみ、ohs_updateInstancesコマンドを使用できます。ドメイン内のすべてのOracle HTTP Serverインスタンス間で解析が行われ、次のタスクが実行されます。

- 存在しない場合、新しいキーストアが<instanceName>_defaultという名前で作成されます。

- 新しく作成したキーストアにデモンストレーション用の証明書demoCASignedCertificateを入れます。

- キーストアをインスタンスの場所にエクスポートします。

このコマンドは、構成ウィザードをコロケート・モードでのみ使用してOracle HTTP Serverインスタンスが作成された後に使用されます。このコマンドの使用の詳細は、WLSTを使用したOracle HTTP Serverインスタンスとキーストアとの関連付けを参照してください。

構文

ohs_updateInstances()

このコマンドは引数を取りません。

例

ohs_updateInstances()

B mod_proxy_fcgiおよびmod_authnz_fcgiモジュールへの移行

この付録では、mod_fastcgiモジュールの使用からmod_proxy_fcgiおよびmod_authnz_fcgiモジュールへの移行方法を示します。

mod_fastcgiモジュールは以前のリリースで非推奨になり、現在のリリースでは、mod_proxy_fcgiおよびmod_authnz_fcgiモジュールに置き換わっています。mod_proxy_fcgiモジュールはmod_proxyを使用してFastCGIのサポートを提供します。mod_authnz_fcgiモジュールにより、FastCGI認可プロバイダ・アプリケーションはユーザーを認証し、リソースへのアクセスを許可することができます。

次のタスクを完了して、mod_fastcgiモジュールからmod_proxy_fcgiおよびmod_authnz_fcgiモジュールへ移行します。

- タスク1: htttpd.confファイルのLoadModuleディレクティブの置換え

- タスク2: mod_fastcgi構成ディレクティブのhtttpd.confファイルからの削除

- タスク3: mod_proxy_fcgiを外部FastCGIサーバーへのリバース・プロキシとして動作するように構成

- タスク4: 外部FastCGI Serverの設定

- タスク5: mod_authnz_fcgiをFastCGI認可プロバイダ・アプリケーションと連携するように設定します。

タスク1: htttpd.confファイルのLoadModuleディレクティブの置換え

httpd.confファイルを編集して、mod_fastcgiおよびmod_fcgi用のLoadModule行をコメント・アウトします。mod_proxy、mod_proxy_fcgiおよびmod_authnz_fcgi用のLoadModule行を追加します。次に例を示します。

# LoadModule fastcgi_module modules/mod_fastcgi.so
# LoadModule fcgi_module modules/mod_fcgi.so
LoadModule proxy_module modules/mod_proxy.so
LoadModule proxy_fcgi_module modules/mod_proxy_fcgi
LoadModule authnz_fcgi_module modules/mod_authnz_fcgi

タスク2: mod_fastcgi構成ディレクティブのhtttpd.confファイルからの削除

htttpd.confファイルにある次のmod_fastcgi構成ディレクティブのいずれかを削除します。これらのディレクティブの詳細は、次のURLを参照してください

http://www.fastcgi.com/drupal/node/25

- FastCgiServer

- FastCgiConfig

- FastCgiExternalServer

- FastCgiIpcDir

- FastCgiWrapper

- FastCgiAuthenticator

- FastCgiAuthenticatorAuthoritative

- FastCgiAuthorizer

- FastCgiAuthorizerAuthoritative

- FastCgiAccessChecker

- FastCgiAccessCheckerAuthoritative

タスク3: mod_proxy_fcgiを外部FastCGIサーバーへのリバース・プロキシとして動作するように構成

mod_proxy_fcgiモジュールに構成ディレクティブはありません。そのかわりに、mod_proxyモジュール上のディレクティブ・セットを使用します。mod_fcgidおよびmod_fastcgiモジュールとは異なり、mod_proxy_fcgiモジュールにはアプリケーション・プロセスの開始のプロビジョニングはありません。mod_proxy_fcgiの目的は、より速いパフォーマンスのためにこの機能をWebサーバーの外に移動することです。そのため、mod_proxy_fcgiは外部FastCGIサーバーへのリバース・プロキシとして動作するだけです。

mod_proxy_fcgiの使用の例は、次のURLを参照してください。

http://httpd.apache.org/docs/trunk/mod/mod_proxy_fcgi.html

リバース・プロキシの例を含む、mod_proxyで使用可能なディレクティブの詳細は、次のURLを参照してください。

http://httpd.apache.org/docs/trunk/mod/mod_proxy.html

mod_proxy_fcgiをFastCGIサーバーへのリバース・プロキシとして動作するように設定するもう1つの方法は、リクエストをリバース・プロキシ・リクエストとして強制的に処理することです。これを行うには、適切なハンドラ・パススルー(ハンドラ経由アクセスとも呼ばれる)を作成する必要があります。ハンドラ・パススルーの設定方法の詳細は、次のURLを参照してください

http://httpd.apache.org/docs/trunk/mod/mod_proxy.html#handler

タスク4: 外部FastCGI Serverの設定

外部FastCGIサーバーにより、FastCGIスクリプトをWebサーバーの外部またはリモート・マシンでも実行することができます。次のリストに、いくつかの使用可能なFastCGIサーバー・ソリューションの情報を示します。

- fcgistarter、FastCGIプログラムを開始するユーティリティ。このソリューションはApache httpd 2.4により提供されます。これはUNIXシステムでのみ動作します。fcgistarterの詳細は、次のURLを参照してください。
http://httpd.apache.org/docs/trunk/programs/fcgistarter.html

- PHP-FPM、別のPHP FastCGI実装。このソリューションはPHPリリース5.3.3以降に含まれます。PHP-FPMの詳細は、次のURLを参照してください。
http://php.net/manual/en/install.fpm.configuration.php

- spawn-fcgi、リモートおよびローカルFastCGIプロセスを起動するユーティリティ。spawn-fcgiの詳細は、次のURLを参照してください。
http://redmine.lighttpd.net/projects/spawn-fcgi/wiki/WikiStart

タスク5: mod_authnz_fcgiをFastCGI認可プロバイダ・アプリケーションと連携するように設定します。

mod_authnz_fcgiモジュールにより、FastCGI認可プロバイダ・アプリケーションはユーザーを認証し、リソースへのアクセスを許可することができます。これは認証および認可の1つのフェーズに参加する一般的なFastCGI認可プロバイダと、Apache httpd特有のオーセンティケータおよび認可プロバイダをサポートします。FastCGI認可プロバイダは、Basic認証などに対するユーザーIDおよびパスワードを使用した認証、または任意のメカニズムを使用した認証を行うことができます。mod_authnz_fcgiの使用の詳細は、次のURLを参照してください。

http://httpd.apache.org/docs/trunk/mod/mod_authnz_fcgi.html

C よくある質問

この付録では、Oracle HTTP Server (OHS)に関するよくある質問とそれに対する回答について説明します。内容は次のとおりです。

- アプリケーション固有のエラー・ページはどのように作成しますか

- HTTPおよびHTTPSでは、どのタイプの仮想ホストがサポートされますか

- 異なる言語および文字セット・バージョンのドキュメントを使用できますか

- Oracle HTTP ServerにApache HTTP Serverセキュリティ・パッチを適用できますか

- Oracle HTTP ServerのApache HTTP Serverバージョンをアップグレードできますか

- Oracle HTTP Serverからの出力を圧縮できますか

- ファイアウォールおよびクラスタを介して機能するネームスペースはどのように作成しますか

- Webサイトのセキュリティを強化する方法

- REDIRECT_ERROR_NOTESが、「ファイルが見つかりません」というエラーに設定されていないのはなぜですか

- Webサーバー・ベンダーおよびバージョンに関する情報はどのように隠すことができますか

- apachectlまたは他のコマンドライン・ツールを使用してOHSを起動できますか

- ポート80でリスニングするOracle HTTP Serverをどのように構成しますか

- Oracle HTTP ServerでSSLを使用してリクエストをどのように停止しますか

- Oracle HTTP ServerでエンドツーエンドSSLをどのように構成しますか

- Oracle HTTP ServerはOracle WebLogic Serverのフロントエンドになれますか

- Oracle WebLogic Serverドメインとスタンドアロン・ドメインの違い

- Oracle HTTP Serverはレスポンス・データをキャッシュできますか

- 仮想サーバー固有のアクセス・ログをどのように構成しますか

該当する場合は、Apache Software Foundationのドキュメントを参照しています。

注意:

このガイドをPDF版またはハード・コピー形式でご利用いただく場合、HTML形式でのみのご提供となるサードパーティのドキュメントを参照できません。文中で参照されているサードパーティのドキュメントをご利用いただくためには、このガイドのHTML版をご利用のうえ、文中のハイパーリンクをクリックしてください。

アプリケーション固有のエラー・ページはどのように作成しますか

Oracle HTTP Serverには、エラー処理用のデフォルトのコンテンツ・ハンドラが用意されています。ErrorDocumentディレクティブを使用すると、デフォルトをオーバーライドできます。

関連項目:

ErrorDocumentディレクティブの詳細は、次のApache HTTP Serverのドキュメントを参照してください。

http://httpd.apache.org/docs/current/mod/core.html#errordocument

HTTPおよびHTTPSでは、どのタイプの仮想ホストがサポートされますか

(Apache 2.4が必要)

HTTPの場合、Oracle HTTP Serverでは、名前ベースとIPベースの両方の仮想ホストがサポートされます。名前ベースの仮想ホストは共通のリスニング・アドレス(IPとポートの組合せ)を共有する仮想ホストですが、クライアントにより送信されたHostヘッダーとVirtualHost内のServerNameディレクティブの間の一致に基づいてリクエストをルーティングします。IPベースの仮想ホストは、固有のリスニング・アドレスを持つ仮想ホストです。IPベースの仮想ホストは、リクエストが受信されたアドレスに基づいてリクエストをルーティングします。

HTTPSの場合、Oracle HTTP Serverで使用できるのはIPベースの仮想ホストのみです。これは、名前ベースの仮想ホストの場合、リクエストを処理する仮想ホストを判別するために、リクエストを読み取って調査する必要があるためです。HTTPSが使用されている場合、リクエストを読み取る前にSSLハンドシェイクを実行する必要があります。SSLハンドシェイクを実行するためには、サーバー証明書を提供する必要があります。意味のあるサーバー証明書を提供するには、証明書のホスト名が、クライアントがリクエストしたホスト名に一致する必要があります。これは、仮想ホストごとにサーバー証明書が一意であることを意味します。しかし、サーバーはリクエストを読み取るまで、そのリクエストのルーティング先の仮想ホストを認識できず、また提供するサーバー証明書がわからなければリクエストを適切に読み取ることもできないため、HTTPSでは名前ベースの仮想ホスティングを行うことは不可能です。

異なる言語および文字セット・バージョンのドキュメントを使用できますか

使用できます。Apache HTTP Serverの機能に与えられた汎用名であるMultiviewsを使用すると、リクエストに対するレスポンスで様々なバージョンの言語と文字固有のドキュメントを提供できます。

関連項目:

コンテント・ネゴシエーションの詳細は、次のApache HTTP ServerのドキュメントのMultiviewsオプションを参照してください。

http://httpd.apache.org/docs/current/content-negotiation.html

Oracle HTTP ServerにApache HTTP Serverセキュリティ・パッチを適用できますか

次の理由で、Oracle HTTP ServerにはApache HTTP Serverセキュリティ・パッチを適用できません。

- OracleではOracle HTTP Serverユーザーにリリースする前に、セキュリティ・パッチをテストして適切に変更しています。

- Oracleではセキュリティ・パッチのコンポーネントをスタックから削除しているため、多くの場合、OpenSSLアラートなどのApache HTTP Serverアラートは適用できません。

Oracle HTTP Serverに対するセキュリティ関連の最新の修正は、Oracle Critical Patch Update (CPU)を介して実行します。詳細は、OracleのWebページ「Critical Patch Updates and Security Alerts」を参照してください。

注意:

CPUを適用した後、Apache HTTP Serverベースのバージョンがそのまま残っていることがありますが、脆弱性は修正されます。バージョンを確認できるサード・パーティのセキュリティ検出ツールがありますが、これらのツールで脆弱性そのものを確認することはできません。

Oracle HTTP ServerのApache HTTP Serverバージョンをアップグレードできますか

Oracle HTTP Server内のApache HTTP Serverバージョンのみをアップグレードすることはできません。Oracle HTTP ServerのベースとなるApache HTTP Serverの新バージョンが、パッチ更新またはOracle Fusion Middlewareの次期メジャー・リリースかマイナー・リリースの一部として提供されます。

Oracle HTTP Serverからの出力を圧縮できますか

一般に、Oracle HTTP Serverに組み込まれているmod_deflateを使用することをお薦めします。mod_deflateに関する詳細は、http://httpd.apache.org/docs/current/mod/mod_deflate.htmlを参照してください。

ファイアウォールおよびクラスタを介して機能するネームスペースはどのように作成しますか

一般的には、1つの分散Webサイトの全サーバーで、単一のURLネームスペースを使用する必要があります。すべてのサーバーでネームスペースの一部を処理し、処理しないURLのリクエストをそのURLにより近いサーバーにリダイレクトまたはプロキシできます。たとえば、次のようなネームスペースがあるとします。

/app1/login.html
/app1/catalog.html
/app1/dologin.jsp
/app2/orderForm.html
/apps/placeOrder.jsp

最初に、server1にapp1、server2にapp2を置いて、これらのネームスペースを2つのWebサーバーにマップします。server1の構成は次のようになります。

Redirect permanent /app2 http://server2/app2
Alias /app1 /myApps/application1
<Directory /myApps/application1>
...
</Directory>

server2の構成は補足的です。

ネームスペースをコンテンツ・タイプ(server1ではHTML、server2ではJSP)別にパーティション化すると決定した場合、サーバー構成を変更してファイルを移動できますが、アプリケーション自体を変更する必要はありません。その結果、server1の構成は次のようになります。

RedirectMatch permanent (.*) \.jsp$ http://server2/$1.jsp
AliasMatch ^/app(.*) \.html$ /myPages/application$1.html
<DirectoryMatch "^/myPages/application\d">
...
</DirectoryMatch>

実際のリダイレクションの量は、ハードウェアのロード・バランサ(F5システムのBIG-IPなど)を、URLに基づいてserver1またはserver2にリクエストが送信されるように構成することで、最小限に抑えることが可能です。

Webサイトのセキュリティを強化する方法

Webサイトの保護に関する一般的なガイドラインは、次のとおりです。

- ISPとWebサーバーの間に市販のファイアウォールを使用します。

- 切替式のイーサネットを使用して、セキュリティを破られたサーバーにより検出される可能性のある通信量を制限します。Webサーバー・マシンと、データベースやエンタープライズ・アプリケーションを実行中の機密性の高い内部サーバーの間に、追加のファイアウォールを使用します。

- RPC、Finger、telnetなど、不要なネットワーク・サービスをサーバーから削除します。

- Webフォームからの入力と、アプリケーションからの出力を常にすべて検証します。エンコーディング、長い入力文字列、印刷不能文字やHTMLタグ、またはJavaScriptタグを含む入力は必ず検証してください。

- 重要情報を含むCookieの内容は、暗号化します。

- すべてのシステムとアプリケーション・ソフトウェアのセキュリティ・パッチを頻繁にチェックし、入手後すぐにインストールします。パッチは、OracleまたはOracleサポート担当者からのもののみ受け入れます。

- 該当する場合は、侵入検出パッケージを使用して、改変されたWebページ、ウィルスおよびrootkitの有無を監視します。可能な場合は、システムの実行可能ファイルとWebのコンテンツを読取り専用ファイル・システムにマウントしてください。

- アプリケーションに対して侵入テストやその他の適切なセキュリティ・テストを使用することを検討してください。アプリケーションを保護するために適切なカスタムmod_securityルールを使用してWebセキュリティを構成することを検討してください。mod_securityの詳細は、mod_securityモジュールの構成およびmod_securityの使用を参照してください。

- 不要なコンテンツをhttpd.confファイルから削除します。詳細は、不要コンテンツへのアクセスの削除を参照してください。

- Webページをクリックジャック攻撃から保護するための予防措置を講じます。インターネットには多くの使用可能な参考情報があります。クリックジャックの詳細は、Oracle DatabaseおよびFusion Middlewareのセキュリティ脆弱性に関するFAQ (Doc ID 1074055.1)のセキュリティのベスト・プラクティスに関する項を参照してください。

REDIRECT_ERROR_NOTESが、「ファイルが見つかりません」というエラーに設定されていないのはなぜですか

Apache HTTP Serverとの互換性によって、この条件でのCGIおよび他のアプリケーションで、この情報を使用可能にしていないため、Oracle HTTP Serverでは、REDIRECT_ERROR_NOTES CGI環境変数は「ファイルが見つかりません」というエラーに設定されていません。

Webサーバー・ベンダーおよびバージョンに関する情報はどのように隠すことができますか

この情報をWebサーバーで生成されたレスポンスから削除するには、ServerSignature Offを指定します。Oracle HTTP ServerがWebサーバー・レスポンス・ヘッダーを生成したときにWebサーバー・ソフトウェアを非表示にするには、ServerTokens Custom some-server-stringを指定します。(バックエンド・サーバーがレスポンスを生成するときは、プロキシ・メカニズムに応じてバックエンド・サーバーからサーバー・レスポンス・ヘッダーが生成される場合があります。)

注意:

ServerTokens Custom some-server-stringは、Oracle HTTP Server 10gのServerHeader Off設定の置換文字列です。

apachectlまたは他のコマンド行ツールを使用してOHSを起動できますか

Oracle HTTP Server 12c (12.2.1)のプロセス管理はノード・マネージャによって処理されます。startComponentコマンドを使用して、WLSTまたはFusion Middleware Controlを直接使用せずに、Oracle HTTP Serverを起動することができます。詳細は、コマンド行を使用したOracle HTTP Serverインスタンスの起動を参照してください。

ポート80でリスニングするOracle HTTP Serverはどのように構成しますか

デフォルトでは、Oracle HTTP Serverは、UNIXでの予約済の範囲内にあるポート(通常1024未満)にバインドできません。特権ポートでのOracle HTTP Serverインスタンスの起動(UNIXのみ)の手順に従って、Oracle HTTP Serverが予約済の範囲内にあるポート(たとえば、デフォルトのポート80)でリスニングするようにできます。

Oracle HTTP ServerでSSLを使用してリクエストをどのように停止しますか

mod_wl_ohsモジュールがWebLogic Serverにリクエストを転送する、Oracle HTTP Serverの前あるいはその中で、SSLを使用してリクエストを停止できます。リクエストがOracle HTTP Serverに届く前にSSLを停止するか、リクエストがサーバーの中にある時に停止するかは、トポロジによります。詳細は、ロード・バランサでのSSLの停止およびOracle HTTP ServerでのSSLの停止を参照してください。

Oracle HTTP ServerでエンドツーエンドSSLをどのように構成しますか

Secure Sockets Layer (SSL)のサポートは、Oracle WebLogic Serverプラグインにより提供されます。SSLプロトコルを使用することで、プラグインとOracle WebLogic Serverとの間の接続を保護できます。SSLプロトコルによって、プラグインとWebLogic Serverとの間で渡されるデータの機密性と整合性が保持されます。SSLライブラリの設定およびWebサーバーとOracle WebLogic Server間の一方向または双方向のSSL通信の設定については、『Oracle WebLogic Serverプロキシ・プラグイン12.2.1の使用』のプラグインを使用したSSLの使用に関する項を参照してください。

SSLをOracle HTTP Serverでは構成し、Oracle WebLogic Serverでは構成しない場合、Oracle HTTP Serverから送信されるリクエストに対するSSLを停止できます。このシナリオの構成の詳細は、Oracle HTTP ServerでのSSLの停止を参照してください。

Oracle HTTP ServerはOracle WebLogic Serverのフロントエンドになれますか

Oracle HTTP Serverは、Oracle Fusion MiddlewareのWebサーバー・コンポーネントです。サーバーはWebLogic Management Frameworkを活用して、Oracle HTTP Server、Oracle WebLogic Serverおよびその他のFusion Middlewareスタックを管理するための簡単で一貫性のある分散環境を提供します。これは、組込みのOracle WebLogic Serverプロキシ・プラグイン(mod_wl_ohsモジュール)を使用し、静的コンテンツを内部からホストすることによって、HTTPのフロントエンドとして機能して、動的コンテンツのリクエストをWebLogic管理対象サーバーにルーティングします。

Oracle HTTP Serverをインストールできるトポロジの詳細は、Oracle HTTP Server 12c (12.2.1)のトポロジを参照してください。

Oracle WebLogic Serverドメインとスタンドアロン・ドメインの違い

Oracle HTTP Serverはスタンドアロン、Full-JRFまたはRestricted-JRFドメインのいずれかにインストールできます。スタンドアロン・ドメインは、Oracle HTTP Serverなどのシステム・コンポーネントのコンテナです。これはオーバーヘッドが最小のため、DMZ環境に理想的です。スタンドアロン・ドメインにはOracle WebLogic Serverドメインに類似したディレクトリ構造がありますが、これには管理サーバー、管理対象サーバーまたは管理サポートは含まれていません。スタンドアロン・ドメインには、同一タイプのシステム・コンポーネント(Oracle HTTP Serverなど)、またはタイプの混在したシステム・コンポーネントの1つ以上のインスタンスが含まれます。

WebLogic ServerドメインではすべてのWebLogic Management Frameworkツールがサポートされています。Oracle WebLogic ServerドメインはFull-JRFまたはRestricted JRFのいずれかです。Full-JRFモードのWebLogic Serverドメインには、WebLogic管理サーバー、0台以上のWebLogic管理対象サーバーおよび0個以上のシステム・コンポーネント・インスタンス(Oracle HTTP Serverインスタンスなど)が含まれます。このタイプのドメインは、システム全体に存在するFusion Middleware ControlおよびWebLogic Management Frameworkを介して拡張管理機能を提供します。WebLogic Serverドメインは、複数の物理マシンにまたがって設定でき、管理サーバーによって一元管理されます。これらのプロパティのために、WebLogic Serverドメインは、使用しているシステムのコンポーネントとJava EEコンポーネント間の最高の統合を提供します。

Restricted-JRFドメインは12.2.1リリースの新機能で、WebLogicサーバー・ドメインを使用してOracle HTTP Serverの管理を簡素化することが目的です。Oracle WebLogic ServerのRestricted-JRFドメインは、外部データベースへの接続が必要ない点を除き、Full-JRFドメインと似ています。Fusion MiddleWare ControlおよびWLSTを介するOracle HTTP Server機能のすべては引き続き使用可能です。

これらの各ドメインの詳細は、ドメイン・タイプを参照してください。

Oracle HTTP Serverはレスポンス・データをキャッシュできますか

Oracle HTTP Serverはレスポンス・データをキャッシュするApache mod_cacheおよびmod_cache_diskモジュールを含むようになりました。

mod_cacheおよびmod_cache_diskでの詳細は、Apacheドキュメントのmod_cacheに関する項を参照してください。

http://httpd.apache.org/docs/2.4/mod/mod_cache.html

仮想サーバー固有のアクセス・ログをどのように構成しますか

各VirtualHostディレクティブ内で、Apache LogFormatおよびCustomLogディレクティブを使用して、仮想ホスト固有のアクセス・ログ形式およびログ・ファイルを構成できます。詳細は、LogFormatおよびCustomLogを参照してください。

D Oracle HTTP Serverのトラブルシューティング

この付録では、Oracle HTTP Server (OHS)の使用時に発生する可能性がある一般的な問題およびその解決方法について説明します。内容は次のとおりです。

- ポートの競合によりOracle HTTP Serverが起動できない

- 多数のhttpdプロセスによるシステムのオーバーロード

- 1024未満のポートでOracle HTTP Serverの起動時に発生する権限拒否

- ログ・ファイルを使用したエラーの特定

- リモート・ホストでのOHSインスタンスの回復

- Oracle HTTP Serverのパフォーマンスの問題

- DMSの共有メモリーの不足

- 共有ファイル・システム上で生成されたインスタンスのパフォーマンスの問題

- AIXでノード・マネージャ12c (12.1.2) OHSがJava例外をスローする

ポートの競合によりOracle HTTP Serverが起動できない

ポートの競合によりOracle HTTP Serverが起動できない場合に、次のエラーが発生することがあります。

[VirtualHost: main] (98)Address already in use: make_sock: could not bind to address [::]:7777

解決方法

そのポートをすでに使用しているプロセスを判別し、Oracle HTTP ServerのIPポート・アドレスか、競合しているプロセスのポートを変更します。

注意:

OHSインスタンスが構成ウィザードで作成された場合、自動的なポート管理は行われません。同じリスニング・ポートを使用して複数のインスタンスを作成することが可能です。

多数のhttpdプロセスによるシステムのオーバーロード

1つのシステム上で実行中のhttpdプロセスが多すぎると、通常処理のためのリソースが不足し、レスポンス時間が低下します。

解決方法

マシンが対処できる値までMaxRequestWorkersの値を下げます。

1024未満のポートでOracle HTTP Serverの起動時に発生する権限拒否

1024未満のポートでOracle HTTP Serverを起動しようとすると、次のエラーが発生します。

[VirtualHost: main] (13)Permission denied: make_sock: could not bind to address [::]:443

1024未満のポートでは、Oracle HTTP Serverは起動しません。これは、これらのポートをバインドするには、root権限が必要になるためです。

解決方法

特権ポートでのOracle HTTP Serverインスタンスの起動(UNIXのみ)の手順に従って、特権ポートでOracle HTTP Serverを起動します。

ログ・ファイルを使用したエラーの特定

次のログ・ファイルを使用すると、エラーの特定に役立ちます。

- リライト・ログ

- スクリプト・ログ

- エラー・ログ

リライト・ログ

このログ・ファイルは、mod_rewriteが使用されている場合のデバッグに必要です。このログ・ファイルでは、リライト・エンジンによるリクエストの変換方法の詳細分析が生成されます。LogLevelディレクティブの値は詳細レベルを制御します。

スクリプト・ログ

このログ・ファイルでは、CGIスクリプトからの入出力を記録できます。このファイルはテストにのみ使用し、本番サーバーには使用しないでください。

関連項目:

次のApache HTTP Serverドキュメントの「ScriptLog」

http://httpd.apache.org/docs/current/mod/mod_cgi.html#scriptlog

エラー・ログ

このログ・ファイルには、全体的なサーバー問題が記録されます。エラー・ログを構成および表示する方法の詳細は、Oracle HTTP Serverログの管理を参照してください。

リモート・ホストでのOHSインスタンスの回復

リモート・ホスト(管理サーバーを持たず、管理対象サーバーのみを持つホスト)にインストールされているOracle HTTP Serverインスタンスを回復する必要がある場合、このシナリオでは、pack.shとunpack.shが動作しないので、tarとuntarを使用する必要があります。

Oracle HTTP Serverのパフォーマンスの問題

次に、Oracle HTTP Serverの実行時に発生する可能性があるフォーマンスの問題とその解決策を示します。

- ネットワーク・ファイル・システムに置かれる特別なランタイム・ファイル

- ネットワーク・ファイル・システムでのUNIXソケット

- 低速なファイル・システムに置かれたDocumentRoot

ネットワーク・ファイル・システムに置かれる特別なランタイム・ファイル

Oracle HTTP Serverは内部処理にロック(つまりロック・ファイル)を使用します。これらのファイルはロックが作成されると動的に作成され、ロックが取得または解放されるたびにアクセスされます。これらのファイルが低速なファイル・システム(たとえばネットワーク・ファイル・システム)に置かれると、サーバーのパフォーマンスが低下する場合があります。この問題を回避するには:

Linuxの場合:

httpd.confで、Mutex fnctl:fileloc defaultをMutex sysvsem defaultに変更します。ここで、filelocはディレクティブLockFile (2箇所)の値です。

Solarisの場合:

httpd.confで、Mutex fnctl:fileloc defaultをMutex pthread defaultに変更します。ここで、filelocはディレクティブLockFile (2箇所)の値です。

ネットワーク・ファイル・システムでのUNIXソケット

mod_cgidモジュールは、デフォルトでは有効になっていません。有効な場合、このモジュールはUNIXソケットを内部で使用します。UNIXソケットが低速なファイル・システム(たとえばネットワーク・ファイル・システム)に置かれると、大幅なパフォーマンスの低下が発生することがあります。次のディレクティブを設定して、この問題を回避できます。

- mod_cgidが有効な場合は、ScriptSockディレクティブを使用してmod_cgidのUNIXソケットをローカル・ファイルシステムに配置します。

低速なファイル・システムに置かれたDocumentRoot

mod_wl_ohsを使用してリクエストをバックエンドのWLSサーバー/クラスタにルーティングし、DocumentRootが低速なファイル・システム(ネットワーク・ファイル・システムなど)に置かれている場合は、mod_wl_ohsによりバックエンドのサーバーにルーティングされるすべてのリクエストでパフォーマンスの問題が発生することがあります。これは、SetHandler weblogic-handlerではなく、WLSRequestをONに設定することで解決できます。

DMSの共有メモリーの不足

一部の極端な構成では、OHSのエラー・ログに次のメッセージが表示されます。

dms_fail_shm_expansion: out of DMS shared memory in pid XXX, disabling DMS; increase DMSProcSharedMem directive from YYY

これは、OHS DMSに必要な共有メモリーの誤った計算によるものです。これは、DMSProcSharedMemをデフォルトの4096より大きい値に設定することで解決できます。問題が解決するまで継続してDMSProcSharedMemを50%ずつ高く設定します。DMSProcSharedMemの最小値は256バイトで、最大値は65536です。

数百から数千もの多くの仮想ホストを持つ構成で、前述の回避策で解決できない場合は、かわりに環境変数OHS_DMS_BLOCKSIZEをOracle HTTP Serverがエラーなく開始する十分大きな値に設定できます。この変数の値は数キロバイトであり、524288は開始値として適切です。エラーが繰り返される場合は、Oracle HTTP Serverがエラーなく開始するまで値を50%ずつ増加させてください。

共有ファイル・システム上で生成されたインスタンスのパフォーマンスの問題

NFS(ネットワーク・ファイル・システム)を含む共有ファイルシステム上でOracle HTTP Serverインスタンスを生成する際に、機能上や性能上の問題が生じた場合には、デフォルト構成のファイルシステム・アクセスに起因する可能性があります。この場合、オペレーティング・システムに固有のhttpd.confファイルを更新する必要があります。このファイルの更新の詳細は、共有ファイルシステムでのOracle HTTP Serverコンポーネント構成の更新を参照してください。

AIXでノード・マネージャ12c (12.1.2) OHSがJava例外をスローする

AIXでOracle HTTP Serverを実行している場合、ファイル・ハンドラのULIMIT値が小さいと、AIXでノード・マネージャのコンソール/ログから「java.io.IOException: error=24, Too many open files」エラーがスローされます。

回避策

この問題を解決するには、次の手順に従ってファイル・ハンドラのULIMIT値を大きくします。

1. ルート・ユーザーとしてログインします。

2. /etc/security/limitsファイルを開きます。

3. このファイルを編集して、次の値を設定します。

- nofiles=8192

- nofiles_hard=65536

4. マシンを再起動して、この変更を有効にします。

E 構成ファイル

Oracle HTTP Serverのデフォルトの構成には、次の各項で説明するファイルが含まれています。

- httpd.confファイル

- ssl.confファイル

- admin.confファイル

- mod_wl_ohs.confファイル

- mime.typesファイル

- ohs.plugins.nodemanager.propertiesファイル

- magicファイル

- keystores/<wallet-directory>ファイル

- auditconfig.xmlファイル

- component-logs.xmlファイル

- component_events.xmlファイル

- その他の参照

構成ファイルの詳細は、構成ファイルの理解を参照してください。

httpd.confファイル

次の表で、httpd.confファイルについて説明します。

説明

形式

構成済の主な機能

トップレベルのWebサーバー構成ファイル

Apache HTTP Serverの.confファイル形式

非SSLリスニング・ソケットなど多数

ssl.confファイル

次の表で、ssl.confファイルについて説明します。

説明

形式

構成済の主な機能

SSL用のWebサーバー構成ファイル

Apache HTTP Serverの.confファイル形式

mod_ossl

admin.confファイル

次の表で、admin.confファイルについて説明します。

説明

形式

構成済の主な機能

管理ポート用のWebサーバー構成ファイル

Apache HTTP Serverの.confファイル形式

mod_dms、ノード・マネージャとの通信に使用される管理ポート

注意:

カスタマによる構成を想定しているのはリスニング・ポートとローカル・アドレスのみです。

mod_wl_ohs.confファイル

次の表で、mod_wl_ohs.confファイルについて説明します。

説明

形式

構成済の主な機能

WebLogicプラグイン用のWebサーバー構成ファイル

Apache HTTP Serverの.confファイル形式

WebLogicプラグイン(mod_wl_ohs)

mime.typesファイル

次の表で、mime.typesファイルについて説明します。

説明

形式

構成済の主な機能

mod_mime用のWebサーバー構成ファイル

mod_mimeファイル形式

mod_mimeで使用されるMIMEタイプ

ohs.plugins.nodemanager.propertiesファイル

次の表で、ohs.plugins.nodemanager.propertiesファイルについて説明します。

説明

形式

構成済の主な機能

Oracle HTTP Serverノード・マネージャ・プラグイン用の構成ファイル

Javaプロパティのファイル形式

Oracle HTTP Serverプラグイン

magicファイル

次の表で、magicファイルについて説明します。

説明

形式

構成済の主な機能

オプションで、mod_mime_magic用に無効化されているWebサーバー構成ファイル

mod_mime_magicのファイル形式

mod_mime_magicで使用されるファイルの内容のパターン

keystores/<wallet-directory>ファイル

次の表で、デフォルトのキーストア・ファイルについて説明します。

名前の例: keystores/default

説明

形式

構成済の主な機能

Oracleウォレット

Oracleウォレットの形式

SSL/TLS通信用のOracleウォレット

auditconfig.xmlファイル

次の表で、auditconfig.xmlファイルについて説明します。

説明

形式

構成済の主な機能

OHSの監査およびロギングの構成

FMW監査フレームワークの監査構成のXML形式

Oracle HTTP Server操作の監査を行うFMW監査フレームワーク

component-logs.xmlファイル

次の表で、component-logs.xmlファイルについて説明します。

説明

形式

構成済の主な機能

ログ収集用のOHSログ・ファイルの構成

FMWログ・ファイル構成のXML形式

ログの収集

component_events.xmlファイル

次の表で、component_event.xmlファイルについて説明します。

説明

形式

構成済の主な機能

OHS監査イベント定義の静的な構成

FMW監査フレームワーク・コンポーネント・イベントのXML形式

FMW監査フレームワーク

注意:

この構成ファイルはカスタマによる構成を想定していません。

その他の参照

追加情報については、次のドキュメントを参照してください。

- Apache HTTP Serverの.confファイル形式
http://httpd.apache.org/docs/2.4/configuring.html

- mod_mimeファイル形式
http://httpd.apache.org/docs/2.4/mod/mod_mime.html

- mod_mime_magicファイル形式
http://httpd.apache.org/docs/2.2/mod/mod_mime_magic.html

F プロパティ・ファイル

この付録では、Oracle HTTP Serverで使用されるプロパティ・ファイルについて説明します。該当するファイルは次のとおりです。

- ohs_admin.propertiesファイル

- ohs_nm.propertiesファイル

- ohs.plugins.nodemanager.propertiesファイル

ohs_admin.propertiesファイル

ohs_admin.propertiesファイルは、Oracle HTTP Server管理サーバーのMBeansを構成するために使用されるドメイン・ファイルごとのファイルです。

ファイル・パス: DOMAIN_HOME/config/fmwconfig/components/OHS/ohs_admin.properties

このファイルの編集可能なプロパティを次に示します。

プロパティ

説明

LogLevel

OHSプラグインのログ・レベル

許容値:

- SEVERE(最高値)

- WARNING

- INFO

- CONFIG

- FINE

- FINER

- FINEST(最低値)

デフォルト: INFO

ohs_nm.propertiesファイル

ohs_nm.propertiesファイルは、Oracle HTTP Serverのプラグインを構成するために使用されるドメイン・ファイルごとのファイルです。

ファイル・パス: DOMAIN_HOME/config/fmwconfig/components/OHS/ohs_nm.properties

プロパティ

説明

LogLevel

OHSの必要性の低いプラグインのログ・レベル。

許容値:

- SEVERE(最高値)

- WARNING

- INFO

- CONFIG

- FINE

- FINER

- FINEST(最低値)

デフォルト: INFO

ohs.plugins.nodemanager.propertiesファイル

ohs.plugins.nodemanager.propertiesファイルは、構成済のOracle HTTP Serverごとに存在し、OHSプロセス管理用の構成済のパラメータを含んでいます。

ファイル・パス: DOMAIN_HOME/config/fmwconfig/components/OHS/ohs1/ohs.plugins.nodemanager.properties

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

- クロスプラットフォーム・プロパティ

- 環境変数の構成プロパティ

- LinuxおよびUNIXで実行するOracle HTTP Serverインスタンス固有のプロパティ

注意:

ohs.plugins.nodemanager.propertiesのWindows実装に配置されるパスで、バックスラッシュを含むものについては、そのバックスラッシュをエスケープする必要があります。

これは、Oracle HTTP Server 11gからアップグレードした後に、バックスラッシュを含むパスがopmn.xmlからohs.plugins.nodemanager.propertiesに移行された状態で、手動で行う必要があります。

例:

environment.TMP = C:\Users\user\AppData\Local\Temp\1

手動で、次のように修正する必要があります。

environment.TMP = C:\\Users\\user\\AppData\\Local\\Temp\\1

クロスプラットフォーム・プロパティ

次の表では、クロスプラットフォーム・プロパティについて説明します。

プロパティ

説明

config-file

初期Oracle HTTP Server構成ファイルのベースのファイル名。

config-fileには、インスタンスの構成ディレクトリ内の任意の有効な.confファイルを指定できます。

注意: 指定した.confファイルには、デフォルトのhttpd.confと同じ方法でadmin.confが含まれている必要があります。

デフォルト: httpd.conf

command-line

httpdの呼出しに追加される引数。

command-lineには、任意の有効なhttpdコマンド行パラメータを指定できます。

注意: これらは、通常の起動、停止および再起動のパラメータと競合することはできません。このプロパティには-Dと記号を使用できます。

デフォルト: なし

start-timeout

Oracle HTTP Serverが起動および初期化するのを待機する最大時間(秒数)。

start-timeoutには、5から3600の任意の数値を指定できます。

デフォルト: 120

stop-timeout

Oracle HTTP Serverが終了するのを待機する最大時間(秒数)。

stop-timeoutには、5から3600の任意の数値を指定できます。

デフォルト: 60

restart-timeout

Oracle HTTP Serverが再起動するのを待機する最大秒数。

restart-timeoutには5から3600の任意の数値を指定できます。

デフォルト: 180

ping-interval

Oracle HTTP Serverへの1回のヘルス・チェックのpingの完了から次回の開始までの秒数。値を0にするとpingが無効になります。

ping-intervalには、0から3600の任意の数値を指定できます。

デフォルト: 30

ping-timeout

Oracle HTTP Serverのヘルス・チェックのpingが完了するのを待機する最大秒数。

ping-tmeoutには、5から3600の任意の数値を指定できます。

デフォルト: 60

例:

config-file = httpd.conf
command-line = -DSYMBOL
start-timeout = 120
stop-timeout = 60
restart-timeout = 180
ping-interval = 30
ping-timeout = 60

環境変数の構成プロパティ

環境プロパティを使用して、OHSサーバーのその他の環境変数を指定する場合があります。

環境プロパティの構文を次に示します。

environment[.append][.<order>].<name> = <value>

ここで:

- オプションの.appendは、<name>の既存の値に新しい<value>を追加します。<name>が定義されていない場合は、<value>が新しい値になります。

- オプションの.<order>値は、環境変数内でこの定義の設定の順位を設定します(デフォルトは0)。順位によって、構成済の変数がプロセスの環境にいつ追加されるかが決まります(およびその評価された値)。低い順位の値を持つ環境プロパティは、高い順位の値を持つものより先に処理されます。順位の値は0以上の整数にする必要があります。

- <name>は、環境変数の名前で、文字またはアンダースコアで始まり、文字、数字またはアンダースコアで構成される必要があります。

- <value>は、環境変数<name>の値です。値は、自身も含め他の環境変数名を参照できます。
この値には、次の特別な参照が含まれている場合があります。

- パス・セパレータとして"$:"

- ファイル・セパレータとして"$/"

- '$'として"$$"

これらの特殊文字の例外を使用して、UNIX変数の構文の参照(「$name」または「${name}」)およびWindows変数の構文の参照(「%name%」)がサポートされています。

同じプロパティ・ファイル内の個々のプロパティの名前は一意である必要があるため(複数のプロパティを同じ名前で定義した場合の動作は未確定)、同じ環境変数<name>内に複数の定義を指定する場合は、プロパティ名を一意に保持するために.<order>フィールドを使用する必要があります。

次の環境変数は、Oracle HTTP Serverプラグインによって設定されます。

- SHELL: 環境から、デフォルトでは/bin/sh、またはWindowsの場合はcmd.exe

- ORA_NLS33: $ORACLE_HOME/nls/dataに設定

- NLS_LANG: 環境から、それ以外はデフォルト

- LANG: 環境から、それ以外はデフォルト

- LC_ALL: 環境から(設定されている場合)

- TZ: 設定されている場合、環境から

- ORACLE_HOME: Oracleホームへのフルパス

- ORACLE_INSTANCE: ドメイン・ホームへのフルパス

- INSTANCE_NAME: ドメインの名前

- PRODUCT_HOME: OHSインストール: $ORACLE_HOME/ohsへのパス

- PATH: デフォルトで次のように設定されます。

- UNIXの場合:
$PRODUCT_HOME/bin:$ORACLE_HOME/bin:

$ORACLE_HOME/jdk/bin:/bin:/usr/bin:/usr/local/bin

- Windowsの場合:
%PRODUCT_HOME%\bin;%ORACLE_HOME%\bin;

%ORACLE_HOME%\jdk\bin;%SystemRoot%;%SystemRoot%\system32

これらの変数はUNIXのみに適用されます。

- TNS_ADMIN: 環境から、または$ORACLE_HOME/network/admin

- LD_LIBRARY_PATH: $PRODUCT_HOME/lib:$ORACLE_HOME/lib:$ORACLE_HOME/jdk/lib

- LIBPATH: LD_LIBARY_PATHと同じ

- X_LD_LIBRARY_PATH_64: LD_LIBRARY_PATHと同じ

これらの変数はWindowsのみに適用されます。

- ComSpec: デフォルトでシステムの%ComSpec%値に設定されます。

- SystemRoot: デフォルトでシステムの%SystemRoot%値に設定されます。

- SystemDrive: デフォルトでシステムの%SystemDrive%値に設定されます。

例

/oracleとしてインストールされたWeb層およびノード・マネージャの環境に設定された環境変数「MODX_RUNTIME=special」を使用するUNIX系のシステムでは、次の定義を使用します。

environment.MODX_RUNTIME = $MODX_RUNTIME
environment.1.MODX_ENV = Value A
environment.1.MODX_PATH = $PATH$:/opt/modx/bin
environment.2.MODX_ENV = ${MODX_ENV}, Value B
environment.append.2.MODX_PATH = /var/modx/bin
MODX_ENV = Value A, Value B
MODX_PATH = /oracle/ohs/bin:/oracle/bin:/oracle/jdk/bin:/bin:/usr/bin: /usr/local/bin:/opt/modx/bin:/var/modx/bin

前述の定義により、追加の環境変数がOracle HTTP Serverに設定されます。

MODX_RUNTIME = special

LinuxおよびUNIXで実行するOracle HTTP Serverインスタンス固有のプロパティ

これらは、Linuxまたはその他のUNIX系のシステムで実行するインスタンスの場合にのみ構成する必要があります。

プロパティ

説明

restart-mode

構成の変更がアクティブ化された場合に、Oracle HTTP Serverに対して正常な再起動を使用するか、または強制的な再起動を使用するかを決定します。

restart-modeには次の値を使用できます。

- restart

- graceful

デフォルト: graceful

stop-mode

Oracle HTTP Serverを停止する場合、正常な停止を使用するか、または強制的な停止を使用するかを決定します。

stop-modeには次の値を使用できます。

- stop

- graceful-stop

デフォルト: stop

mpm

Oracle HTTP Serverに対してprefork、workerまたはevent MPMを使用するかを決定します。

mpmには次の値を使用できます。

- prefork

- worker

- event

デフォルト: UNIXの場合worker、Linuxの場合event

allow-corefiles

OHSサーバーがクラッシュした場合に、コア・ファイルが書き込まれることを許可するために、無制限に設定するかどうかを決定します。

allow-corefilesには次の値を使用できます。

- yes

- no

デフォルト: no

例

restart-mode = graceful
stop-mode = stop
mpm = worker
allow-corefiles = no

G OHSモジュール・ディレクティブ

この付録では、オラクル社が開発したOHSによってサポートされているモジュールで使用できるディレクティブについて説明します。これらの項目が含まれます。

- mod_wl_ohsモジュールに関する注意

- mod_certheadersモジュール

- mod_osslモジュール

mod_wl_ohsモジュールに関する注意

Oracle HTTP Serverには、この付録に記載されたディレクティブおよびモジュールに加えて、通常、Oracle WebLogic Serverプロキシ・プラグインと呼ばれるmod_wl_ohsモジュールが含まれています。このモジュールのディレクティブの詳細は、Oracle WebLogic Serverプロキシ・プラグイン12.2.1の使用のWeb Serverプラグインのパラメータを参照してください。

mod_certheadersモジュール

mod_certheadersモジュールには次のディレクティブを使用できます。

- AddCertHeaderディレクティブ

- SimulateHttpsディレクティブ

AddCertHeaderディレクティブ

CGI環境変数に変換する必要があるヘッダーを指定します。これは、AddCertHeaderディレクティブを使用して実行できます。このディレクティブは単一の引数を取ります。この引数は、受信リクエストのHTTPヘッダーから移入する必要があるCGI環境変数です。たとえば、SSL_CLIENT_CERT CGI環境変数を移入します。

カテゴリ

値

構文

AddCertHeader environment_variable

例

AddCertHeader SSL_CLIENT_CERT

デフォルト

なし

SimulateHttpsディレクティブ

mod_certheadersを使用すると、特定のリクエストがHTTP経由で受信された場合でも、HTTPS経由で受信されたかのようにそれらのリクエストを扱うように、Oracle HTTP Serverに指示することができます。これは、Oracle HTTP Serverがリバース・プロキシまたはロード・バランサのフロントエンドになっている場合に役立ちます。リバース・プロキシまたはロード・バランサは、SSLリクエストの終端点の機能を果たし、HTTPS経由でOracle HTTP Serverにリクエストを転送します。

カテゴリ

値

構文

SimulateHttps on|off

例

SimulateHttps on

デフォルト

off

mod_osslモジュール

Oracle HTTP Serverに対してSSLを構成するには、使用するmod_osslモジュールのディレクティブをssl.confファイルに入力します。

次の項で、これらのmod_osslディレクティブについて説明します。

- SSLCARevocationFileディレクティブ

- SSLCARevocationPathディレクティブ

- SSLCipherSuiteディレクティブ

- SSLEngineディレクティブ

- SSLFIPSディレクティブ

- SSLHonorCipherOrderディレクティブ

- SSLInsecureRenegotiationディレクティブ

- SSLOptionsディレクティブ

- SSLProtocolディレクティブ

- SSLProxyCipherSuiteディレクティブ

- SSLProxyEngineディレクティブ

- SSLProxyProtocolディレクティブ

- SSLProxyWalletディレクティブ

- SSLRequireディレクティブ

- SSLRequireSSLディレクティブ

- SSLSessionCacheディレクティブ

- SSLSessionCacheTimeoutディレクティブ

- SSLTraceLogLevelディレクティブ

- SSLVerifyClientディレクティブ

- SSLWalletディレクティブ

SSLCARevocationFileディレクティブ

証明書を発行したCA(認証局)からの証明書失効リスト(CRL)をまとめるファイルを指定します。このリストは、クライアント認証に使用されます。このファイルは、PEMでエンコードされた様々なCRLファイルを優先順位の順に連結したものです。このディレクティブは、SSLCARevocationPathの代替または補助用に使用できます。

カテゴリ

値

構文

SSLCARevocationFile file_name

例

SSLCARevocationFile ${ORACLE_INSTANCE}/config/fmwconfig/components/${COMPONENT_TYPE}/instances/${COMPONENT_NAME}/keystores/crl/ca_bundle.cr

デフォルト

なし

SSLCARevocationPathディレクティブ

PEMでエンコードされている証明書失効リスト(CRL)が格納されるディレクトリを指定します。CRLは、証明書の発行元のCA(認証局)から届きます。CRLのいずれかに記載されている証明書を使用してクライアントが自身を認証しようとすると、証明書は取り消され、そのクライアントはサーバーに対して自身を認証できなくなります。

このディレクティブは、CRLのハッシュ値が含まれるディレクトリを指している必要があります。ハッシュを生成するコマンドは、『Oracle Fusion Middlewareの管理』の「orapki」を参照してください。

カテゴリ

値

構文

SSLCARevocationPath path/to/CRL_directory/

例

SSLCARevocationPath ${ORACLE_INSTANCE}/config/fmwconfig/components/${COMPONENT_TYPE}/instances/${COMPONENT_NAME}/keystores/crl

デフォルト

なし

SSLCipherSuiteディレクティブ

クライアントがSSLハンドシェイク時に使用できるSSL暗号スイートを指定します。このディレクティブでは、カンマまたはコロンで区切られた暗号指定文字列を使用して暗号スイートを識別します。表11-2は、必要な暗号スイートを記述するためにこの文字列で使用できるタグを示しています。SSLCipherSuiteには次の接頭辞を使用できます。

- none: リストに暗号を追加します。

- +: リストに暗号を追加し、リスト内の正しい位置に配置します。

- -: リストから暗号を削除します(後で追加できます)。

- !: リストから暗号を永続的に削除します。

タグは、暗号指定文字列を構成する接頭辞と結合されます。表G-1に、暗号スイートのタグを示します。

カテゴリ

値

例

SSLCipherSuite ALL:!MD5

この例では、MD5強度暗号を除くすべての暗号が指定されています。

構文

SSLCipherSuite cipher-spec

デフォルト

TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384,TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256,TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA384,TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA256,TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA,TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA,TLS_ECDHE_ECDSA_WITH_RC4_128_SHA,TLS_ECDHE_ECDSA_WITH_3DES_EDE_CBC_SHA,TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384,TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256,TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384,TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256,TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA,TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA,TLS_ECDHE_RSA_WITH_RC4_128_SHA,TLS_ECDHE_RSA_WITH_3DES_EDE_CBC_SHA,TLS_RSA_WITH_AES_256_GCM_SHA384,TLS_RSA_WITH_AES_128_GCM_SHA256,TLS_RSA_WITH_AES_256_CBC_SHA256,TLS_RSA_WITH_AES_128_CBC_SHA256,SSL_RSA_WITH_AES_256_CBC_SHA,SSL_RSA_WITH_AES_128_CBC_SHA,SSL_RSA_WITH_RC4_128_SHA,SSL_RSA_WITH_3DES_EDE_CBC_SHA

表G-1 SSL暗号スイートのタグ

機能

タグ

意味

鍵の交換

kRSA

RSA鍵の交換

鍵の交換

kECDHE

楕円曲線Diffie–Hellman交換のキー交換

認証

aRSA

RSA認証

暗号化

3DES

Triple DESエンコード

暗号化

RC4

RC4エンコード

データの整合性

SHA

SHAハッシュ関数

データの整合性

SHA256

SHA256ハッシュ関数

データの整合性

SHA384

SHA384ハッシュ関数

別名

TLSv1

すべてのTLS V1暗号

別名

TLSv1.1

すべてのTLS V1.1暗号

別名

TLSv1.2

すべてのTLS V1.2暗号

別名

MEDIUM

128ビット暗号化を使用したすべての暗号

別名

HIGH

サイズが128ビットを超える暗号鍵を使用したすべての暗号

別名

AES

AES暗号化を使用したすべての暗号

別名

RSA

RSA認証およびRSA鍵交換の両方を使用したすべての暗号

別名

ECDSA

認証の楕円曲線デジタル署名アルゴリズムを使用したすべての暗号

別名

ECDHE

楕円曲線Diffie–Hellman交換のキー交換を使用したすべての暗号

別名

AES-GCM

暗号用のGalois/Counter Mode (GCM)でAdvanced Encryption Standardを使用するすべての暗号。

表G-2に、Oracle Advanced Security 12c (12.2.1)でサポートされている暗号スイートを示します。

表G-2 Oracle Advanced Security 12.2.1でサポートされている暗号スイート

暗号スイート

鍵の交換

認証

暗号化

データの整合性

TLS v1

TLS v1.1

TLS v1.2

SSL_RSA_WITH_RC4_128_SHA

RSA

RSA

RC4 (128)

SHA

○

○

○

SSL_RSA_WITH_3DES_EDE_CBC_SHA

RSA

RSA

3DES (168)

SHA

○

○

○

SSL_RSA_WITH_AES_128_CBC_SHA

RSA

RSA

AES (128)

SHA

○

○

○

SSL_RSA_WITH_AES_256_CBC_SHA

RSA

RSA

AES (256)

SHA

○

○

○

TLS_RSA_WITH_AES_128_CBC_SHA256

RSA

RSA

AES (128)

SHA256

×

×

○

TLS_RSA_WITH_AES_256_CBC_SHA256

RSA

RSA

AES (256)

SHA256

×

×

○

TLS_RSA_WITH_AES_128_GCM_SHA256

RSA

RSA

AES (128)

SHA256

×

×

○

TLS_RSA_WITH_AES_256_GCM_SHA384

RSA

RSA

AES (256)

SHA384

×

×

○

TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA

ECDHE

ECDSA

AES (128)

SHA

○

○

○

TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA

ECDHE

ECDSA

AES (256)

SHA

○

○

○

TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA256

ECDHE

ECDSA

AES (128)

SHA256

×

×

○

TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA384

ECDHE

ECDSA

AES (256)

SHA384

×

×

○

TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256

ECDHE

ECDSA

AES (128)

SHA256

×

×

○

TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384

ECDHE

ECDSA

AES (256)

SHA384

×

×

○

TLS_ECDHE_RSA_WITH_RC4_128_SHA

RSA署名付きのエフェメラルECDH

RSA

RC4 (128)

SHA

○

○

○

TLS_ECDHE_RSA_WITH_3DES_EDE_CBC_SHA

RSA署名付きのエフェメラルECDH

RSA

3DES

SHA

○

○

○

TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA

RSA署名付きのエフェメラルECDH

RSA

AES (128)

SHA

○

○

○

TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA

RSA署名付きのエフェメラルECDH

RSA

AES (256)

SHA

○

○

○

TLS_ECDHE_ECDSA_WITH_RC4_128_SHA

ECDSA署名付きのエフェメラルECDH

ECDSA

RC4 (128)

SHA

○

○

○

TLS_ECDHE_ECDSA_WITH_3DES_EDE_CBC_SHA

ECDSA署名付きのエフェメラルECDH

ECDSA

3DES

SHA

○

○

○

TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384

RSA署名付きのエフェメラルECDH

RSA

AES (256)

SHA384

×

×

○

TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256

RSA署名付きのエフェメラルECDH

RSA

AES (128)

SHA256

×

×

○

TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384

RSA署名付きのエフェメラルECDH

RSA

AES (256)

SHA384

×

×

○

TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256

RSA署名付きのエフェメラルECDH

RSA

AES (128)

SHA256

×

×

○

SSLEngineディレクティブ

SSLプロトコル・エンジンの使用を切り替えます。通常は<VirtualHost>セクションの中で使用し、特定の仮想ホストに対してSSLを有効にします。デフォルトでは、SSLプロトコル・エンジンは、メイン・サーバーとすべての構成済仮想ホストの両方で無効にされています。

カテゴリ

値

構文

SSLEngine on|off

例

SSLEngine on

デフォルト

Off

SSLFIPSディレクティブ

このディレクティブは、SSLライブラリのFIPS_modeフラグの使用方法を切り替えます。これは、グローバル・サーバー・コンテキスト内に設定される必要があり、競合する設定(SSLFIPS offが続くSSLFIPS onなど)があると構成できません。このモードはすべてのSSLライブラリ操作に適用されます。

カテゴリ

値

構文

SSLFIPS ON | OFF

例

SSLFIPS ON

デフォルト

Off

SSLFIPSの変更を構成する場合は、SSLFIPS on/offディレクティブがssl.conf内でグローバルに設定されている必要があります。仮想レベルの構成はSSLFIPSディレクティブ内で無効になっています。したがって、仮想ディレクティブにSSLFIPSを設定するとエラーになります。

注意:

SSLFIPSに関する次の制限に注意してください。

- Oracle HTTP ServerでSSLFIPSモードを有効化するには、AESで暗号化された(compat_v12)ヘッダー付きで作成されたウォレットが必要になります。新しいウォレットを作成する場合、または既存のウォレットをAES暗号を使用して変換する場合は、Oracle Fusion Middlewareの管理のorapkiに関する項で次の項を参照してください。
orapkiを使用したOracleウォレットの作成と表示

AES暗号化によるOracleウォレットの作成

AES暗号化を使用するように既存のウォレットを変換

次の表で、SSLFIPSモードで様々なプロトコルとともに動作する暗号スイートについて説明します。これらの暗号スイートの実装方法の手順は、SSLCipherSuiteディレクティブを参照してください。

表G-3に、SSLFIPSモードのTLS 1.0、TLS1.1およびTLS 1.2プロトコルで動作する暗号スイートを示します。

表G-3 SSLFIPSモードのすべてのTLSプロトコルで動作する暗号

暗号名

暗号は次のプロトコルで動作します。

SSL_RSA_WITH_3DES_EDE_CBC_SHA

TLS 1.0、TLS1.1およびTLS 1.2

SSL_RSA_WITH_AES_128_CBC_SHA

TLS 1.0、TLS1.1およびTLS 1.2

SSL_RSA_WITH_AES_256_CBC_SHA

TLS 1.0、TLS1.1およびTLS 1.2

表G-4に、SSLFIPSモードで使用できる暗号スイートおよびプロトコルを示します。

表G-4 FIPSモードで動作する暗号

暗号名

暗号は次のプロトコルで動作します。

TLS_ECDHE_ECDSA_WITH_3DES_EDE_CBC_SHA

TLS 1.0以降

TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA

TLS 1.0以降

TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA

TLS 1.0以降

TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA256

TLS1.2以降

TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA384

TLS1.2以降

TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256

TLS1.2以降

TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384

TLS1.2以降

TLS_RSA_WITH_AES_128_CBC_SHA256

TLS1.2以降

TLS_RSA_WITH_AES_256_CBC_SHA256

TLS1.2以降

TLS_RSA_WITH_AES_128_GCM_SHA256

TLS1.2以降

TLS_RSA_WITH_AES_256_GCM_SHA384

TLS1.2以降

TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256

TLS1.2以降

TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384

TLS1.2以降

TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256

TLS1.2以降

TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384

TLS1.2以降

TLS_ECDHE_RSA_WITH_3DES_EDE_CBC_SHA

TLS 1.0以降

TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA

TLS 1.0以降

TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA

TLS 1.0以降

注意:

- SSLFIPSがONに設定され、FIPSをサポートしない暗号がサーバーで使用されている場合、その暗号を使用するクライアント・リクエストは失敗します。

- SSLFIPSがONに設定され、FIPSをサポートする暗号がサーバーで使用されている場合、その暗号を使用するクライアント・リクエストは成功します。

表G-5に、SSPFIPSモードで動作しない暗号スイートを示します。

表G-5 SSLFIPSモードで動作しない暗号

暗号名

説明

TLS_ECDHE_ECDSA_WITH_RC4_128_SHA

すべてのプロトコルでSSLFIPSモードで動作しない

SSL_RSA_WITH_RC4_128_SHA

すべてのプロトコルでSSLFIPSモードで動作しない

TLS_ECDHE_RSA_WITH_RC4_128_SHA

すべてのプロトコルでSSLFIPSモードで動作しない

SSLHonorCipherOrderディレクティブ

ハンドシェイク中に暗号を選択すると、通常、クライアントのプリファレンスが使用されます。このディレクティブが有効な場合、サーバーのプリファレンスがかわりに使用されます。

カテゴリ

値

構文

SSLHonorCipherOrder ON | OFF

例

SSLHonorCipherOrder ON

デフォルト

OFF

サーバーのプリファレンス順序はSSLCipherSuiteディレクティブを使用して構成できます。SSLHonorCipherOrderがONに設定されている場合、SSLCipherSuiteの値は暗号値の順序付きリストとして扱われます。

このリストの最初に表示される暗号値は、リストのそれ以降に表示される暗号よりもサーバーで優先されます。

例:

SSLCipherSuite TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384,TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256,TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA384,TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA256

SSLHonorCipherOrder ON

この例では、サーバーはTLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384を、クライアントがサポートしている場合、リストで最初に表示され、SSL接続用にこの暗号を選択するので、SSLCipherSuiteディレクティブで構成されているその他のすべての暗号よりも優先します。

SSLInsecureRenegotiationディレクティブ

最初は指定されていたように、SSLプロトコルとTLSプロトコルのすべてのバージョン(TLS/1.2を含めて、これまで)は、ネゴシエーション中の中間者攻撃(CVE-2009-3555)に対して脆弱でした。この脆弱性によって、攻撃者は、Webサーバーで表示される任意の平文をHTTPリクエストの前に付け加えることができます。クライアントとサーバーの両方でサポートされている場合は、この脆弱性を修正するプロトコルの拡張が開発されています。

中間者攻撃(CVE-2009-3555)の詳細は、次を参照してください。

https://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2009-3555

デフォルト・モード

ディレクティブSSLInsecureRenegotionが構成に指定されていない場合、Oracle HTTP Serverは互換モードで動作します。

このモードでは、Renegotiation Info/Signaling Cipher Suite Value (RI/SCSV)をサポートしない脆弱なピアとの接続が可能になりますが、再ネゴシエーションはRI/SCSVをサポートしているピアとのみ許可されます。

SSLInsecureRenegotiation ON

このオプションでは、再ネゴシエーションを実行するRI/SCSVのない脆弱なピアを許可します。したがって、このオプションはCVE-2009-3555で説明している再ネゴシエーション攻撃に対してサーバーを脆弱なままにするため、注意して使用する必要があります。

SSLInsecureRenegotiation OFF

このオプションが使用されると、RI/SCSVをサポートするピアのみがセッションとネゴシエーションおよび再ネゴシエーションできます。これが最もセキュアな推奨されるモードです。

カテゴリ

値

構文

SSLInsecureRenegotiation ON | OFF

例

SSLInsecureRenegotiation ON

デフォルト

デフォルト値は、ONでもOFFでもありません。見出しの「デフォルト・モード」で説明しているように、デフォルトでは、Oracle HTTP Serverは互換モードで動作します。

SSLInsecureRenegotiationを構成するには、ssl.confファイルを編集して、SSLInsecureRenegotiation ON/OFFをグローバルまたは仮想的に設定し、セキュアでない再ネゴシエーションを有効(または無効)に設定します。

SSLOptionsディレクティブ

ディレクトリ単位で様々なランタイム・オプションを制御します。一般に、1つのディレクトリに複数のオプションが適用される場合は、最も包括的なオプションが適用されます(オプションはマージされません)。ただし、SSLOptionsディレクティブのすべてのオプションの前にプラス(+)またはマイナス(-)符号が付いている場合は、オプションがマージされます。プラスが前に付いているオプションは、現在有効なオプションに追加され、マイナスが前に付いているオプションは、現在有効なオプションから除外されます。

使用できる値は次のとおりです。

- StdEnvVars: SSLに関連するCGI/SSI環境変数の標準セットを作成します。抽出操作はCPU時間が長くかかること、また静的コンテンツを提供するときには一般に適用されないことから、これはデフォルトでは無効になっています。一般に、この値はCGI/SSIリクエストの場合にのみ有効にします。

- ExportCertData: 次の追加CGI/SSI変数を有効にします。
SSL_SERVER_CERT

SSL_CLIENT_CERT

SSL_CLIENT_CERT_CHAIN_n (ここでn= 0, 1, 2...)

これらの変数には、現在のHTTPS接続のサーバーおよびクライアント用にPrivacy Enhanced Mail (PEM)でエンコードされたX.509証明書が含まれています。CGIスクリプトではこれを使用して、より詳しい証明書チェックを行うことができます。クライアント証明書連鎖の他の証明書がすべて提供されます。このオプションを使用するとパフォーマンスに時間がかかるため、デフォルトではOffになっています。

SSL_CLIENT_CERT_CHAIN_n変数の順序は、次のようになります。SSL_CLIENT_CERT_CHAIN_0は、SSL_CLIENT_CERTを署名する中間的なCAです。SSL_CLIENT_CERT_CHAIN_1は、SSL_CLIENT_ROOT_CERTをルートCAとして、SSL_CLIENT_CERT_CHAIN_0などを署名する中間的なCAです。

- FakeBasicAuth: クライアントのX.509証明書の対象識別名をHTTP Basic認証のユーザー名に変換します。これは、標準のHTTPサーバー認証方式がアクセス制御に使用できることを意味します。ユーザーからはパスワードが取得されず、文字列passwordが置き換えられます。

- StrictRequire: SSLRequireSSLディレクティブまたはディレクティブに従ってアクセスを禁止する必要がある場合にアクセスを拒否します。StrictRequireを指定しないと、Satisfy anyディレクティブ設定がSSLRequireまたはSSLRequireSSLディレクティブをオーバーライドして、クライアントがホスト制約を渡した場合、または有効なユーザー名とパスワードを指定した場合に、アクセスが許可されてしまう可能性があります。
このように、SSLRequireSSLまたはSSLRequireをSSLOptions +StrictRequireと組み合せることで、mod_osslはあらゆる場合にSatisfy anyディレクティブをオーバーライドできます。

- CompatEnvVars: Apache SSL 1.x、mod_ssl 2.0.x、Sioux 1.0およびStronghold 2.xとの後方互換性のために、廃止された環境変数をエクスポートします。これは、既存のCGIスクリプトに対する互換性を提供するために使用します。

- OptRenegotiate: SSLのディレクティブがディレクトリ単位のコンテキストで使用されるときに、最適化されたSSL接続再ネゴシエーション処理を有効にします。

カテゴリ

値

構文

SSLOptions [+-] StdEnvVars | ExportCertData | FakeBasicAuth | StrictRequire | CompatEnvVars | OptRenegotiate

例

SSLOptions -StdEnvVars

デフォルト

なし

SSLProtocolディレクティブ

mod_osslがサーバー環境を設定するときに使用するSSLプロトコルを指定しますクライアントは、指定されたプロトコルのいずれかでのみ接続できます。使用できる値は次のとおりです。

- TLSv1

- TLSv1.1

- TLSv1.2

- All

注意:

SSLv3はリリース12.2.1では無効化されています。

複数の値をスペース区切りのリストとして指定できます。構文で、"-"および"+"記号の意味は次のとおりです。

- + : プロトコルをリストに追加します

- - : プロトコルをリストから削除します

現在のリリースでは、Allは+TLSv1 +TLSv1.1 +TLSv1.2として定義されます。

カテゴリ

値

構文

SSLProtocol [+-] TLSv1 | TLSv1.1 | TLSv1.2 | All

例

SSLProtocol +TLSv1 +TLSv1.1 +TLSv1.2

デフォルト

ALL

SSLProxyCipherSuiteディレクティブ

プロキシがSSLハンドシェイク時に使用できるSSL暗号スイートを指定します。このディレクティブでは、コロンで区切られた暗号指定文字列を使用して暗号スイートを識別します。表G-1に、必要な暗号スイートを記述するためにこの文字列で使用するタグを示します。SSLProxyCipherSuiteには次の値を使用できます。

- none: リストに暗号を追加します。

- +: リストに暗号を追加し、リスト内の正しい位置に配置します。

- -: リストから暗号を削除します(後で追加できます)。

- !: リストから暗号を永続的に削除します。

タグは、暗号指定文字列を構成する接頭辞と結合されます。タグは、暗号指定文字列を構成する接頭辞と結合されます。SSLProxyCipherSuiteディレクティブはSSLCipherSuiteディレクティブと同じタグを使用します。サポートされているスイート・タグのリストについては、表G-1を参照してください。

カテゴリ

値

例

SSLProxyCipherSuite ALL:!MD5

この例では、MD5強度暗号を除くすべての暗号が指定されています。

構文

SSLProxyCipherSuite cipher-spec

デフォルト

ALL:!ADH:+HIGH:+MEDIUM

SSLProxyCipherSuiteディレクティブはSSLCipherSuiteディレクティブと同じ暗号スイートを使用します。Oracle Advanced Security 12.2.1でサポートされている暗号スイートのリストについては、表G-2を参照してください。

SSLProxyEngineディレクティブ

プロキシのSSL/TLSプロトコル・エンジンを有効または無効にします。SSLProxyEngineは<VirtualHost>セクションの中で使用し、特定の仮想ホストでのプロキシの使用に対してSSL/TLSを有効にします。デフォルトでは、SSL/TLSプロトコル・エンジンは、メイン・サーバーとすべての構成済仮想ホストの両方でプロキシに対して無効になっています。

SSLProxyEngineは、(ProxyディレクティブまたはProxyRequestディレクティブを使用した)フォワード・プロキシとして動作する仮想ホストに含めることはできません。プロキシSSL/TLSリクエストに対してフォワード・プロキシ・サーバーを有効化する際に、SSLProxyEngineは必須ではありません。

カテゴリ

値

構文

SSLProxyEngine ON | OFF

例

SSLProxyEngine on

デフォルト

Disable

SSLProxyProtocolディレクティブ

mod_osslがサーバー環境でプロキシ接続を設定するときに使用するSSLプロトコルを指定します。プロキシは、指定されたプロトコルのいずれかでのみ接続できます。使用できる値は次のとおりです。

- TLSv1

- TLSv1.1

- TLSv1.2

- All

複数の値をスペース区切りのリストとして指定できます。構文で、"-"および"+"記号の意味は次のとおりです。

- + : リストにプロトコルを追加

- - : リストからプロトコルを削除

現在のリリースでは、Allは+TLSv1 +TLSv1.1 +TLSv1.2として定義されます。

カテゴリ

値

構文

SSLProxyProtocol [+-] TLSv1 | TLSv1.1 | TLSv1.2 | All

例

SSLProxyProtocol +TLSv1 +TLSv1.1 +TLSv1.2

デフォルト

ALL

SSLProxyWalletディレクティブ

プロキシ接続が使用する必要のある、WRLを使用してウォレットの場所を指定(ファイルパスとして指定)します。

カテゴリ

値

構文

SSLProxyWallet file:path to wallet

例

SSLProxyWallet "${ORACLE_INSTANCE}/config/fmwconfig/components/${COMPONENT_TYPE}/instances/${COMPONENT_NAME}/keystores/proxy"

デフォルト

なし

SSLRequireディレクティブ

任意の複合ブール式がTRUEでないかぎり、アクセスを拒否します。

カテゴリ

値

構文

SSLRequire expression (「式変数の理解」を参照)

例

SSLRequire word ">=" word |word "ge" word

デフォルト

なし

式変数の理解

式変数は、次の構文と一致する必要があります(BNF構文表記として示してあります)。

expr ::= "true" | "false"
"!" expr
expr "&&" expr
expr "||" expr
"(" expr ")"

comp ::=word "==" word | word "eq" word
word "!=" word |word "ne" word
word "<" word |word "lt" word
word "<=" word |word "le" word
word ">" word |word "gt" word
word ">=" word |word "ge" word
word "=~" regex
word "!~" regex
wordlist ::= word
wordlist "," word

word ::= digit
cstring
variable
function

digit ::= [0-9]+

cstring ::= "..."

variable ::= "%{varname}"

表G-6と表G-7に、標準変数とSSL変数を示します。これらの値はvarnameの有効値です。

function ::= funcname "(" funcargs ")"

funcnameには、次の関数を使用できます。

file(filename)

file関数は文字列引数(ファイル名)を1つ取り、そのファイルの内容に拡張します。これは、正規表現に照らしてファイルの内容を評価する場合に役立ちます。

表G-6に、SSLRequireディレクティブのvarnameの標準変数を示します。

表G-6 SSLRequireのvarnameの標準変数

標準変数

標準変数

標準変数

HTTP_USER_AGENT

PATH_INFO

AUTH_TYPE

HTTP_REFERER

QUERY_STRING

SERVER_SOFTWARE

HTTP_COOKIE

REMOTE_HOST

API_VERSION

HTTP_FORWARDED

REMOTE_IDENT

TIME_YEAR

HTTP_HOST

IS_SUBREQ

TIME_MON

HTTP_PROXY_CONNECTION

DOCUMENT_ROOT

TIME_DAY

HTTP_ACCEPT

SERVER_ADMIN

TIME_HOUR

HTTP:headername

SERVER_NAME

TIME_MIN

THE_REQUEST

SERVER_PORT

TIME_SEC

REQUEST_METHOD

SERVER_PROTOCOL

TIME_WDAY

REQUEST_SCHEME

REMOTE_ADDR

TIME

REQUEST_URI

REMOTE_USER

ENV:variablename

REQUEST_FILENAME

表G-7に、ディレクティブのvarnameのSSL変数を示します。

表G-7 SSLRequireのvarnameのSSL変数

SSL変数

SSL変数

SSL変数

HTTPS

SSL_PROTOCOL

SSL_CIPHER_ALGKEYSIZE

SSL_CIPHER

SSL_CIPHER_EXPORT

SSL_VERSION_INTERFACE

SSL_CIPHER_USEKEYSIZE

SSL_VERSION_LIBRARY

SSL_SESSION_ID

SSL_CLIENT_V_END

SSL_CLIENT_M_SERIAL

SSL_CLIENT_V_START

SSL_CLIENT_S_DN_ST

SSL_CLIENT_S_DN

SSL_CLIENT_S_DN_C

SSL_CLIENT_S_DN_CN

SSL_CLIENT_S_DN_O

SSL_CLIENT_S_DN_OU

SSL_CLIENT_S_DN_G

SSL_CLIENT_S_DN_T

SSL_CLIENT_S_DN_I

SSL_CLIENT_S_DN_UID

SSL_CLIENT_S_DN_S

SSL_CLIENT_S_DN_D

SSL_CLIENT_I_DN_C

SSL_CLIENT_S_DN_Email

SSL_CLIENT_I_DN

SSL_CLIENT_I_DN_O

SSL_CLIENT_I_DN_ST

SSL_CLIENT_I_DN_L

SSL_CLIENT_I_DN_T

SSL_CLIENT_I_DN_OU

SSL_CLIENT_I_DN_CN

SSL_CLIENT_I_DN_S

SSL_CLIENT_I_DN_I

SSL_CLIENT_I_DN_G

SSL_CLIENT_I_DN_Email

SSL_CLIENT_I_DN_D

SSL_CLIENT_I_DN_UID

SSL_CLIENT_CERT

SSL_CLIENT_CERT_CHAIN_n

SSL_CLIENT_ROOT_CERT

SSL_CLIENT_VERIFY

SSL_CLIENT_M_VERSION

SSL_SERVER_M_VERSION

SSL_SERVER_V_START

SSL_SERVER_V_END

SSL_SERVER_M_SERIAL

SSL_SERVER_S_DN_C

SSL_SERVERT_S_DN_ST

SSL_SERVER_S_DN

SSL_SERVER_S_DN_OU

SSL_SERVER_S_DN_CN

SSL_SERVER_S_DN_O

SSL_SERVER_S_DN_I

SSL_SERVER_S_DN_G

SSL_SERVER_S_DN_T

SSL_SERVER_S_DN_D

SSL_SERVER_S_DN_UID

SSL_SERVER_S_DN_S

SSL_SERVER_I_DN

SSL_SERVER_I_DN_C

SSL_SERVER_S_DN_Email

SSL_SERVER_I_DN_L

SSL_SERVER_I_DN_O

SSL_SERVER_I_DN_ST

SSL_SERVER_I_DN_CN

SSSL_SERVER_I_DN_T

SSL_SERVER_I_DN_OU

SSL_SERVER_I_DN_G

SSL_SERVER_I_DN_I

SSLRequireSSLディレクティブ

SSLを使用していないクライアントに対してアクセスを拒否します。構成エラーにより、セキュリティがぜい弱になる可能性があるSSL対応の仮想ホストまたはディレクトリの完全保護に役立つディレクティブです。

カテゴリ

値

構文

SSLRequireSSL

例

SSLRequireSSL

デフォルト

なし

SSLSessionCacheディレクティブ

グローバル・セッションまたはプロセス間セッションのセッション・キャッシュ・ストレージ・タイプを指定します。キャッシュは、リクエストのパラレル処理を高速化するオプションの方法を提供します。使用できる値は次のとおりです。

- none: グローバルまたはプロセス間セッション・キャッシュを無効にします。機能に対する影響はありませんが、パフォーマンスに大きな差が出ます。

- nonenotnull: グローバルおよびプロセス間セッション・キャッシュを無効にします。

- shmcb:/path/to/datafile[bytes]: 高パフォーマンスのShared Memory Cyclic Buffer (SHMCB)セッション・キャッシュを使用して、サーバー・プロセスのローカルSSLメモリー・キャッシュと同期化します。注意: このshm設定では、ローカル・ディスクの/path/to/datafileの下にログ・ファイルは作成されません。

カテゴリ

値

構文

SSLSessionCache none | nonenotnull | shmcb:/path/to/datafile[bytes]

例

SSLSessionCache "shmcb:${ORACLE_INSTANCE}/servers/${COMPONENT_NAME}/logs/ssl_scache(512000)"

デフォルト

SSLSessionCache shmcb:/path/to/datafile[bytes]

SSLSessionCacheTimeoutディレクティブ

セッション・キャッシュ内でSSLセッションの有効期限が満了になるまでの秒数を指定します。

カテゴリ

値

構文

SSLSessionCacheTimeout seconds

例

SSLSessionCacheTimeout 120

デフォルト

300

SSLTraceLogLevelディレクティブ

SSLTraceLogLevelは、Oracle Securityライブラリのエラー・ログに記録されるメッセージの冗長性を調整します。特定のレベルを指定すると、それより上位レベルの重要度のメッセージもすべて報告されます。たとえば、SSLTraceLogLevel sslが設定されていると、error、warn、userおよびdebugのログ・レベルのメッセージも報告されます。

注意:

このディレクティブはssl.confファイルにグローバルにのみ設定できます。

SSLTraceLogLevelでは次のログ・レベルが使用されます。

- none: Oracle Security Traceが無効

- fatal: 致命的なエラーが発生してシステムが使用できない状態

- error: エラー状態

- warn: 警告状態

- user: 正常ではあるが、重大な状態

- debug: デバッグ・レベルの状態

- ssl: SSLレベルのデバッグ

カテゴリ

値

構文

SSLTraceLogLevel none | fatal | error | warn | user | debug | ssl

例

SSLTraceLogLevel fatal

デフォルト

なし

SSLVerifyClientディレクティブ

接続時にクライアントが証明書を提示する必要があるかどうかを指定します。使用できる値は次のとおりです。

- none: クライアント証明書は不要です。

- optional: クライアントは有効な証明書を提示できます。

- require: クライアントは有効な証明書を提示する必要があります。

カテゴリ

値

構文

SSLVerifyClient none | optional | require

例

SSLVerifyClient optional

デフォルト

なし

注意:

mod_sslに含まれているレベルoptional_no_ca(クライアントは有効な証明書を提示できるが、証明書が検証可能である必要はない)は、mod_osslではサポートされていません。

SSLWalletディレクティブ

WRLを使用してウォレットの場所を指定します。ファイルパスとして指定されます。

カテゴリ

値

構文

SSLWallet file:path to wallet directory

file:pathは単にpathと表すこともできます。

例

SSLWallet "${ORACLE_INSTANCE}/config/fmwconfig/components/${COMPONENT_TYPE}/instances/${COMPONENT_NAME}/keystores/default"

デフォルト

これがデフォルトです。

オラクルの法律上の注意点について

コピーライトについて

Copyright © 1994-2017, Oracle and/or its affiliates. All rights reserved.

ライセンス制約の保証と結果的に生じる損害の免責

このソフトウェアおよび関連ドキュメントの使用と開示は、ライセンス契約の制約条件に従うものとし、知的財産に関する法律により保護されています。ライセンス契約で明示的に許諾されている場合もしくは法律によって認められている場合を除き、形式、手段に関係なく、いかなる部分も使用、複写、複製、翻訳、放送、修正、ライセンス供与、送信、配布、発表、実行、公開または表示することはできません。このソフトウェアのリバース・エンジニアリング、逆アセンブル、逆コンパイルは互換性のために法律によって規定されている場合を除き、禁止されています。

保証免責

ここに記載された情報は予告なしに変更される場合があります。また、誤りが無いことの保証はいたしかねます。誤りを見つけた場合は、オラクルまでご連絡ください。

制限付権利について

このソフトウェアまたは関連ドキュメントを、米国政府機関もしくは米国政府機関に代わってこのソフトウェアまたは関連ドキュメントをライセンスされた者に提供する場合は、次の通知が適用されます。

U.S. GOVERNMENT END USERS: Oracle programs, including any operating system, integrated software, any programs installed on the hardware, and/or documentation, delivered to U.S. Government end users are "commercial computer software" pursuant to the applicable Federal Acquisition Regulation and agency-specific supplemental regulations. As such, use, duplication, disclosure, modification, and adaptation of the programs, including any operating system, integrated software, any programs installed on the hardware, and/or documentation, shall be subject to license terms and license restrictions applicable to the programs. No other rights are granted to the U.S. Government.

危険な用途への使用について

このソフトウェアまたはハードウェアは様々な情報管理アプリケーションでの一般的な使用のために開発されたものです。このソフトウェアまたはハードウェアは、危険が伴うアプリケーション(人的傷害を発生させる可能性があるアプリケーションを含む)への用途を目的として開発されていません。このソフトウェアまたはハードウェアを危険が伴うアプリケーションで使用する際、安全に使用するために、適切な安全装置、バックアップ、冗長性(redundancy)、その他の対策を講じることは使用者の責任となります。このソフトウェアまたはハードウェアを危険が伴うアプリケーションで使用したことに起因して損害が発生しても、Oracle Corporationおよびその関連会社は一切の責任を負いかねます。

商標と登録商標について

OracleおよびJavaはオラクルおよびその関連会社の登録商標です。その他の社名、商品名等は各社の商標または登録商標である場合があります。

Intel、Intel Xeonは、Intel Corporationの商標または登録商標です。すべてのSPARCの商標はライセンスをもとに使用し、SPARC International, Inc.の商標または登録商標です。AMD、Opteron、AMDロゴ、AMD Opteronロゴは、Advanced Micro Devices, Inc.の商標または登録商標です。UNIXは、The Open Groupの登録商標です。

第三者のコンテンツ、製品、サービスに対する免責事項

このソフトウェアまたはハードウェア、そしてドキュメントは、第三者のコンテンツ、製品、サービスへのアクセス、あるいはそれらに関する情報を提供することがあります。適用されるお客様とOracle Corporationとの間の契約に別段の定めがある場合を除いて、Oracle Corporationおよびその関連会社は、第三者のコンテンツ、製品、サービスに関して一切の責任を負わず、いかなる保証もいたしません。適用されるお客様とOracle Corporationとの間の契約に定めがある場合を除いて、Oracle Corporationおよびその関連会社は、第三者のコンテンツ、製品、サービスへのアクセスまたは使用によって損失、費用、あるいは損害が発生しても一切の責任を負いかねます。

アルファ版およびベータ版ドラフト・ドキュメントについて

このドキュメントが試作版の場合:

このドキュメントは試作版であり、デモおよび暫定使用のみを目的としたものです。このソフトウェアを使用するハードウェアに限定するものではありません。Oracle Corporationおよびその関連会社は、このドキュメントに関して一切の責任を負わず、いかなる保証もいたしません。また、このドキュメントを使用したことによって損失、費用、あるいは損害が発生しても、一切の責任を負いかねます。

非公開のアルファ版およびベータ版ドラフト・ドキュメントについて

このドキュメントが非公開の試作版の場合:

このドキュメントに含まれる情報は、情報の共有のみを目的としたものであって、顧客諮問委員会(Customer Advisory Board)のメンバーとしてのお客様の立場でのみ、またはお客様のベータ・トライアル契約のみに従って検討されるべきものとします。マテリアル、コード、または機能の提供をお約束するものではなく、購入決定を行う際の判断材料とすべきではありません。このドキュメントに記載されている特徴または機能の開発、リリースおよび時期については、オラクルの裁量により決定されます。

このドキュメントには、ソフトウェアまたは印刷物などの形式を問わず、オラクルが独占的な権利を有する財産的情報が含まれています。この機密資料へのアクセスと使用は、お客様とオラクルとの間で締結され、お客様が遵守に同意した、Oracle Master Agreement、Oracle License and Oracle Services Agreement (オラクル・ライセンスおよびサービスに関する契約書)、Oracle PartnerNetwork Agreement、Oracle Distribution Agreementまたはその他のライセンス契約の条件に従うものとします。このドキュメントとその内容の開示、コピー、複製および配布には、オラクルによる事前の承諾を必要とします。このドキュメントはライセンス契約の一部となるものではなく、オラクルおよびその子会社や関連会社との契約を構成するものではありません。

ドキュメントのアクセシビリティについて

オラクルのアクセシビリティについての詳細情報は、Oracle Accessibility ProgramのWebサイトhttp://www.oracle.com/pls/topic/lookup?ctx=acc&id=docacc を参照してください。

Oracle Supportへのアクセス

サポートをご契約のお客様には、My Oracle Supportを通して電子支援サービスを提供しています。詳細情報はhttp://www.oracle.com/pls/topic/lookup?ctx=acc&id=infoか、聴覚に障害のあるお客様はhttp://www.oracle.com/pls/topic/lookup?ctx=acc&id=trsを参照してください。