test

Sun Java Enterprise System 2005Q4 インストール計画ガイド

インストール計画の問題

インストールと設定のプロセスの目標は、配備アーキテクチャーに記述された分散システムを実現することです。分散システムは、複数のコンピュータ上で実行され、互いに連携して動作するコンポーネントインスタンスで構成されます。正しく機能する分散システムを構築するには、複数のコンピュータにコンポーネントインスタンスをインストールし、コンポーネントインスタンス間の相互動作を確立する基本設定を実行する必要があります。

インストールと設定の手順は、Java ES インストーラの動作と、個別のコンポーネントの要件によって決定されます。正しく機能する分散システムを確実に実現するためには、インストーラを適切に使用する、また、ソリューションで使用されるコンポーネントの要件を考慮したインストール計画を作成する必要があります。計画では、コンポーネントインスタンスのインストールと基本設定の実行の正しい順序を記述する必要があります。計画ではさらに、コンポーネントインスタンスを相互動作させるための設定値を指定する必要もあります。

この節では、インストール計画の作成時に考慮する必要のある主な問題について説明します。

分散インストール

本稼働 Java ES ソリューションに求められるサービス品質要件は、結果として複数のコンピュータにコンポーネントインスタンスを配置するアーキテクチャーになります。たとえば、信頼性のあるメッセージングサービスを実現するために、2 台の異なるコンピュータに Messaging Server の 2 つのインスタンスを配置し、負荷分散を使用して 2 つのインスタンス間にフェイルオーバー関係を確立するアーキテクチャーが必要になる場合があります。

ただし、Java ES インストーラは一度に 1 台のコンピュータ上でしか動作しません。したがって、分散ソリューションをインストールするときは、ソリューションで使用されるすべてのコンピュータ上で個別にインストーラを実行する必要があります。

多くの場合、1 台のコンピュータに 1 つまたは複数のコンポーネントをインストールしたあと、設定ウィザードを実行して基本設定を実行します。通常は、1 台のコンピュータ上でインストールと設定を完了してから、別のコンピュータにコンポーネントの別のセットをインストールして設定する作業に進みます。分散コンポーネントインスタンスをインストールして設定するために、図 3–1 に示すような一連のタスクを実行する場合があります。

図 3–1 分散インストール手順の例

コンピュータ 01 上で、Messaging Server および Calendar Server をインストールし、Messaging Server を設定し、Calendar Server を設定します。コンピュータ 02 上で同じ手順を繰り返します。

相互動作のための設定

インストールプロセスの目標は、複数のコンポーネントインスタンスが相互に連携して動作するシステムを実現することです。コンポーネントをインストールして基本設定を実行するとき、コンポーネントインスタンスを相互動作させるための設定値を指定します。

相互動作のための設定値には、あるコンポーネントインスタンスが別のコンポーネントインスタンスと通信するために使用する URL やポート番号などの値や、あるコンポーネントインスタンスが別のコンポーネントインスタンスへのアクセスを承認するために使用する管理者アカウント ID やパスワードなどが含まれます。たとえば、ソリューションで Access Manager を使用する場合、まず Directory Server インスタンスなどの LDAP リポジトリをインストールして設定する必要があります。次に、Access Manager インスタンスをインストールして設定するとき、準備した LDAP ディレクトリを検索する場所をインスタンスに知らせる設定値を指定する必要があります。

Java ES インストーラは、ソリューションで使用されているほかのコンピュータにどのようなコンポーネントがインストールされているかについては認識しません。たとえば、Access Manager をインストールするとき、適切な LDAP ディレクトリが位置している場所をインストーラは認識していません。インストールと設定のプロセスを確実に成功させるためには、それぞれのコンピュータにどのコンポーネントをインストールするかを事前に計画する必要があります。ソリューションにコンポーネントを追加するたびに、ほかのコンピュータにすでにインストールされているコンポーネントと相互動作させるための設定を行います。

図 3–2 に示すような、一連のインストールおよび設定タスクを実行する場合があります。

図 3–2 コンポーネントの相互動作のための設定

コンピュータ 01: Directory Server。コンピュータ 02: Access Manager をインストールし、コンピュータ 01 上の Directory Server インスタンスと相互動作するように設定します。

ソリューションのアーキテクチャーがどのようなものであれ、コンポーネントの設定と、正しく相互動作する分散ソリューションの実現のために必要なすべての設定値を含むインストール計画を作成する必要があります。

コンポーネントの依存性

Java ES コンポーネントの中には、ほかのコンポーネントをまずインストールして設定してからでないと、インストールと設定ができないものがあります。依存性が発生する理由はいくつかあります。

これらの依存性には、ソリューションレベルのものとローカルのものがあることに注意してください。インストール計画を作成するときは、システムレベルの依存性とローカルの依存性を分けて考えます。次の例で違いを説明します。

Directory Server に対する Access Manager の依存性はシステムレベルの依存性です。Access Manager をインストールするとき、Directory Server の 1 つまたは複数のインスタンスによって提供されるディレクトリサービスの URL を指定します。Directory Server のインストールと設定が完了すると、ソリューション内のすべてのコンポーネントでディレクトリサービスを利用できるようになります。このタイプの依存性は、コンポーネントインスタンスのインストールと設定に関するソリューションレベルのシーケンスを決定します。Directory Server は Access Manager よりも先にインストールおよび設定されます。インストール計画において、ソリューションレベルの依存性は、インストールと設定のステップの全体的なシーケンスを決定します。

Web コンテナに対する Access Manager の依存性はローカル依存性です。この依存性を満たすには、Access Manager を実行するコンピュータに Web コンテナをインストールする必要があります。ただしこの Web コンテナは、ソリューション全体に対してサービスを提供するものではありません。分散ソリューションでは、Web コンテナは複数のコンピュータにインストールされるのが一般的です。各 Web コンテナは、それぞれ異なるコンポーネントをローカルでサポートします。したがって分散ソリューションでは、Web コンテナをインストールする 1 つの決まった場所は存在せず、インストールシーケンスの中で Web コンテナをインストールするポイントも特に決まっていません。

ソリューションのインストール計画を作成するために、ソリューションを記述してコンポーネント間の依存性を識別する配備アーキテクチャーを分析します。計画では、すべての依存性を満たすシーケンスでコンポーネントをインストールおよび設定する必要があります。一般に、全体的なインストールシーケンスはソリューションレベルの依存性を基にして作成します。その後、それぞれのコンピュータ上に存在する可能性があるローカルの依存性を考慮します。

コンポーネントの依存性のリストを表 3–1 に示します。これらの依存性への対処方法については、「インストール計画の作成」の個別コンポーネントの説明を参照してください。

表 3–1 Java ES コンポーネントの依存性

製品コンポーネント

依存性 

依存性の性質 

ローカルである必要性 

Access Manager

Directory Server 

設定データを格納するため。ユーザーデータを格納し、検索を可能にするため 

なし 
 

J2EE Web コンテナ (次のいずれか): 

-Application Server 

-Web Server 

-BEA WebLogic Server 

-IBM WebSphere Application Server 

Access Manager はこれらの Web コンテナのいずれかに配備される必要がある 

あり 

Access Manager SDK

Access Manager 

Access Manager サービスを提供するため 

なし 
 

J2EE Web コンテナ (次のいずれか): 

-Application Server 

-Web Server 

-BEA WebLogic Server 

-IBM WebSphere Application Server 

Access Manager SDK はこれらの Web コンテナのいずれかに配備される必要がある 

あり 

Administration Server

Directory Server 

設定ディレクトリを提供するため 

なし 

Application Server

Message Queue

信頼性のある非同期メッセージングを提供するため 

あり 
 

Web Server (オプション)

Application Server インスタンス間の負荷分散を提供するため 

あり 
 

High Availability Session Store (オプション)

Application Server 間のフェイルオーバーをサポートするセッション状態を格納するため 

あり 

Calendar Server

Directory Server

認証と承認に使われるユーザーデータを格納するため 

なし 
 

Directory Preparation Tool

Calendar Server で使用するための LDAP ディレクトリを準備する 

なし 
 

Access Manager (オプション)

ソリューションでシングルサインオンを使用する場合に必要 

なし 
 

Messaging Server (オプション)

電子メール通知を提供するため 

なし 
 

Delegated Administrator (オプション)

LDAP スキーマを管理するため。カレンダサービスのユーザーをプロビジョニングするため 

なし 

Communications Express

J2EE Web コンテナ (次のいずれか):

-Application Server 

-Web Server 

Communications Express は Web コンテナに配備される必要がある 

あり 
 

Directory Server

アドレス帳などのユーザーデータを格納するため 

なし 
 

Directory Preparation Tool

Communications Express 用の LDAP ディレクトリを準備するため 

なし 
 

Access Manager または Access Manager SDK のどちらか

認証および承認サービスとシングルサインオンを提供するため。ローカルの Access Manager SDK はリモートの Access Manager へのアクセスを提供する 

あり 
 

Messaging Server

基盤のメッセージングサービスを提供するため 

なし 
 

Calendar Server

基盤のカレンダサービスを提供するため 

なし 

Delegated Administrator

J2EE Web コンテナ (次のいずれか): 

-Application Server 

-Web Server 

Delegated Administrator はこれらの Web コンテナのいずれかに配備される必要がある 

あり 
 

Directory Server 

Delegated Administrator で扱う LDAP データを格納するため 

なし 
 

Directory Preparation Tool 

Delegated Administrator 用の LDAP ディレクトリを準備するため 

なし 
 

Access Manager または Access Manager SDK のどちらか 

Access Manager サービスを提供するため。ローカルの Access Manager SDK はリモートの Access Manager へのアクセスを提供する 

あり 

Directory Preparation Tool

Directory Server 

Directory Preparation Tool は、Java ES の通信コンポーネントで使用するディレクトリを準備する 

あり 

Directory Proxy Server

Administration Server 

Directory Proxy Server を設定するため 

なし 
 

Directory Server 

基盤の LDAP ディレクトリサービスを提供するため 

なし 

Directory Server

Administration Server 

Directory Server を設定するため 

なし 

High Availability Session Store 

なし 

   

Instant Messaging

Directory Server 

ユーザー、会議室、およびニュースチャネルのデータを格納するため 

なし 
 

Access Manager または Access Manager SDK (オプション) 

Access Manager サービスを提供するため。ローカルの Access Manager SDK はリモートの Access Manager へのアクセスを提供する 

あり 
 

J2EE Web コンテナ (次のいずれか): 

-Application Server 

-Web Server (Instant Messenger クライアントリソースの配信に必要) 

Instant Messenger クライアントリソースの配布とダウンロードをサポートするため 

あり 
 

Calendar Server (オプション、カレンダポップアップ機能を使用する場合) 

Calendar Server ポップアップをサポートするため 

なし 
 

Messaging Server (オプション、インスタントメッセージのオフライン配信を使用する場合) 

電子メールメッセージとしてのインスタントメッセージのオフライン配信をサポートするため 

なし 

Message Queue 

なし 

   

Messaging Server

Directory Server 

設定データを格納するため。認証および承認のためのユーザーデータを格納および検索するため 

なし 
 

Administration Server 

Directory Server 設定ディレクトリに設定データを格納するため 

あり 
 

Directory Preparation Tool 

Messaging Server 用の LDAP ディレクトリを準備するため 

なし 
 

Access Manager (ソリューションでシングルサインオンを使用する場合) 

シングルサインオンの認証および承認サービスを提供するため 

なし 
 

Delegated Administrator (オプション) 

ユーザーおよびグループのデータを管理するため。ディレクトリスキーマを管理するため 

なし 

Portal Server

J2EE Web コンテナ (次のいずれか):

-Application Server 

-Web Server 

-BEA WebLogic Server 

-IBM WebSphere Application Server 

Portal Server はこれらの Web コンテナのいずれかに配備される必要がある 

あり 
 

Directory Server 

認証と承認に使われるユーザーデータを格納するため 

なし 
 

Access Manager または Access Manager SDK 

Access Manager サービスを提供するため。ローカルの Access Manager SDK はリモートの Access Manager へのアクセスを提供する 

あり 
 

Communications Express 

ポータルデスクトップ用のメッセージングおよびカレンダチャネルを提供するため 

なし 

Portal Server Secure Remote Access

Portal Server 

基盤のポータルサービスを提供するため 

あり 
 

Access Manager または Access Manager SDK のどちらか 

Access Manager サービスを提供するため。ローカルの Access Manager SDK はリモートの Access Manager へのアクセスを提供する 

あり 

Service Registry 

Application Server 

 

あり 

Sun Cluster ソフトウェア 

なし 

   

Sun Cluster Agents

Sun Cluster 

Sun Cluster ノードにインストールされているコンポーネントを認識するため 

あり 

Web Proxy Server

Web Server 

Web アプリケーションへのリモートアクセスを提供するため 

あり 

Web Server 

なし 

   

冗長性戦略

本稼働環境での使用を想定したほとんどのソリューションでは、何らかの種類の冗長化を利用します。冗長性戦略では、コンポーネントの複数のインスタンスを使って 1 つのサービスを提供します。冗長化はサービス品質要件を満たすために利用されます。たとえば、スループットを増強してパフォーマンス要件を満たす目的や、シングルポイント障害を回避して信頼性要件を満たす目的で冗長化を使用します。

Java ES コンポーネントのインスタンス冗長化のために利用できる戦略は 3 つあります。負荷分散、Sun Cluster ソフトウェアによるクラスタリング、および、Directory Server マルチマスターレプリケーションです。ここでは、これらの戦略のそれぞれに対して推奨されるインストールおよび設定手順の概略を示します。

配備アーキテクチャーでこれらの冗長性戦略のいずれかを使用するとき、コンポーネントの複数のインスタンスをインストールし、単独のサービスとして動作するようそれらのインスタンスを設定するための計画を作成する必要があります。

分散サブコンポーネント

Instant Messaging コンポーネントには、独立したインストールと設定が可能なサブコンポーネントを持つものもあります。たとえば Messaging Server には、Message Transfer Agent、Message Multiplexor (MMP)、Messenger Express Multiplexor (MEM)、および Message Store の 4 つのサブコンポーネントがあります。サービス品質要件を満たすために、配備アーキテクチャーでこれらのサブコンポーネントを別々のコンピュータシステムに配置する場合があります。たとえば、図 2–1 のサンプルアーキテクチャーでは、MEM のインスタンスをコンピュータシステム CX1 および CX2 上に、発信側 Message Transfer Agent をコンピュータシステム MTA1 および MTA2 上に、着信側 Message Transfer Agent をコンピュータシステム MTA3 および MTA4 上に、MMP をコンピュータシステム MMP1 および MMP2 上に、メッセージストアをコンピュータシステム STR1 および STR2 上にそれぞれ配置します。

表 3–2 は、独立でのインストールが可能なサブコンポーネントを持つ Java ES コンポーネントのリストです。ソリューションの配備アーキテクチャーを分析し、ソリューションで分散サブコンポーネントを使用するかどうかを決定します。ソリューションで分散サブコンポーネントを使用する場合、適切なコンピュータシステム上に正しい順序でサブコンポーネントをインストールし、サブコンポーネントが相互動作するように設定する計画を作成する必要があります。分散サブコンポーネントの設定の詳細については、「インストール計画の作成」の個別コンポーネントの説明を参照してください。

表 3–2 サブコンポーネントを持つコンポーネント

コンポーネント 

サブコンポーネント 

Instant Messaging

Instant Messaging Multiplexor 

Instant Messaging リソース 

Instant Messaging Server 

Messaging Server

Message Transfer Agent (MTA) 

Message Store 

Messaging Multiplexor (MMP) 

Messenger Express Multiplexor (MEM) 

サブコンポーネントは個別にインストール可能です。配備アーキテクチャーで分散サブコンポーネントが必要な場合、各コンピュータ上でインストーラを実行し、アーキテクチャーで指定されたサブコンポーネントを選択します。インストーラまたは設定ウィザードで要求される入力値は、完全なコンポーネントに対して指定する値の一部です。インストーラによって設定されないコンポーネントについては、設定ウィザードを起動し、コンピュータ上で設定するサブコンポーネントを選択し、設定ウィザードが要求する入力値を指定します。

LDAP スキーマと LDAP ディレクトリツリーの構造

ほとんどの Java ES ソリューションには Directory Server が含まれます。ソリューションのインストールと設定には、ディレクトリスキーマとディレクトリツリー構造の両方を確立する入力値が必要です。インストール計画では、正しい LDAP スキーマとディレクトリツリー構造を作成する入力値をリストする必要があります。

LDAP スキーマとディレクトリツリー構造は、インストール計画を開始する前に指定します。仕様の例については、「ユーザー管理仕様の作成」を参照してください。

LDAP スキーマは、次のインストールおよび設定プロセスによって確立されます。

  1. Directory Server をインストールすると、スキーマ 1 のディレクトリが自動的に確立されます。スキーマを選択するための入力は不要です。

  2. Access Manager をインストールすると、ディレクトリが自動的に変更され、そのディレクトリがスキーマ 2 に変換されます。スキーマを選択するための入力は不要です。

  3. Directory Preparation Tool を実行すると、Messaging Server、Calendar Server、および Communications Express で使用するためのスキーマが拡張されます。Directory Preparation Tool は、スキーマ 1 ディレクトリとスキーマ 2 ディレクトリの両方を拡張します。Directory Preparation Tool に対する入力値はインストール計画にリストされます。

  4. Delegated Administrator を実行すると、スキーマが拡張され、特定のサービスに対してユーザーを承認および認証するために使われるオブジェクトクラスと属性が追加されます。入力値は、ソリューションが提供するサービスの内容によって異なります。入力値はインストール計画にリストされます。入力値の詳細については、「Delegated Administrator 用の手順をインストール計画に追加する」を参照してください。

インストールと設定のプロセスでは、基本ディレクトリツリー構造も確立されます。

  1. Directory Server をインストールすると、ベースサフィックス (ディレクトリツリーのルート) が作成されます。ベースサフィックスは、Java ES インストーラが Directory Server をインストールするときに必要な入力値です。インストール計画では、インストールプロセスのための入力値の 1 つとしてベースサフィックスを指定します。

  2. Messaging Server をインストールして設定すると、ディレクトリツリーが分岐して LDAP 組織が作成されます。この組織は、Messaging Server インスタンスによって管理される電子メールドメインを表します。組織の名前は、Messaging Server の設定ウィザードで必須の入力です。インストール計画では、Messaging Server の設定プロセス用の入力値の 1 つとして組織 DN を指定します。

  3. Calendar Server、Communications Express、Delegated Administrator、および Instant Messaging のインストールと設定では、これらのコンポーネントがユーザーデータを検索するディレクトリ構造内の場所を指定します。LDAP DN は各コンポーネントの設定ウィザードの必須入力であり、インストール計画では各設定ウィザード用の入力値として DN を指定します。ソリューションで Access Manager シングルサインオンを使用する場合、これらのコンポーネントがすべて同じ場所 (Messaging Server の設定ウィザードで作成された組織) にユーザーデータを保存するように設定する必要があります。これら全コンポーネントの設定ウィザードで、同じ LDAP DN が入力されます。インストール計画では、すべての設定ウィザードに対する入力値の 1 つとして組織 DN を指定します。

LDAP ベースサフィックスおよび電子メール組織の名前は、ユーザー管理仕様をもとに決定され、インストール計画に追加されます。ユーザー管理仕様の詳細については、「ユーザー管理仕様の作成」を参照してください。インストール計画への LDAP ベースサフィックスの追加については、表 3–5を参照してください。インストール計画への電子メールドメインの追加については、表 3–9、表 3–10、表 3–11、表 3–13、および表 3–14 を参照してください。

Java ES インストーラの動作

ここでは、インストール計画に影響する Java ES インストーラの一部の動作について説明します。

インストーラはローカルである

Java ES インストーラは、コンポーネントソフトウェアを一度に 1 台のコンピュータにインストールします。つまり、ほとんどのソリューションにおいて、インストーラが複数回実行されることになります。インストール計画では、インストーラを実行する回数を指示する必要があります。ここでは、ソリューションをインストールおよび設定するためにインストーラを実行する回数を、配備アーキテクチャーの分析に基づいて決定する方法について説明します。

ソリューションの中には 1 台のコンピュータにのみインストールされるものがあり、そのようなソリューションのインストール計画は、インストーラを 1 回だけ実行するための手順を定義します。インストーラの実行が 1 回で済むのは次のようなソリューションです。

ほとんどのソリューションは、複数のコンピュータに分散されます。そのようなソリューションのインストール計画では、ソリューション全体をインストールおよび設定するために、複数回のインストーラ実行を記述する必要があります。そのようなソリューションを分析するには、次のガイドラインを使用します。

この節の目的は、インストール計画では時として、1 台のコンピュータ上でのインストーラと設定ウィザードの実行、または、1 台のコンピュータ上での複数回のインストーラ実行を記述しなければならないという概念を紹介することです。さまざまなコンポーネントの組み合わせに対する実際のインストール手順の詳細については、「インストール計画の作成」を参照してください。

インストーラの動作モード

インストーラは、「今すぐ設定」と「あとで設定」の 2 つの異なるモードで動作します。2 つのモードの違いは次の点です。

選択した設定オプションは、インストールセッション全体に適用されます。一部のコンポーネントに対して別の設定オプションを選択する必要がある場合、追加のインストールセッションを実行しなければならない場合があります。

インストーラの互換性チェック

インストーラでは、依存性と互換性に関するいくつかのチェックが実行されます。ローカルにインストールされる項目のチェックだけが可能です。たとえば、ソリューションでリモートの Directory Server インスタンスを使用している場合、インストーラでは、リモートの Directory Server がインストール中の Access Manager と互換性があるかどうかのチェックを行うことはできません。完全に新規のソリューションをインストールおよび設定している場合。確立済みのソリューションに新しいコンポーネントを追加している場合や、既存のコンポーネントの周囲に Sun Java System を構築している場合、そのことが問題となる可能性があります。たとえば、すでに Directory Server を使用しており、Access Manager、Messaging Server、Calendar Server、および Communications Express を使用するソリューションを既存の Directory Server の周囲に構築している場合、コンポーネント間の互換性が問題となります。

インストールに関するその他の問題

この節では、一部のソリューションで発生するいくつかの固有の問題を、詳細な情報の参照先とともに示します。

表 3–3 考慮する必要のあるインストールの問題

ソリューションに必要なもの 

ガイドラインまたは指示 

Solaris 10 ゾーンの使用 

Solaris 10 ゾーンへのインストールを予定している場合、『Sun Java Enterprise System 2005Q4 インストールガイド(UNIX 版)』の「Solaris 10 ゾーン」を参照してください。

Directory Server 暗号化の使用 

Directory Server インスタンス上での LDAPS (SSL over LDAP) の設定 

注意: Directory Server 暗号化が必要な場合、Directory Server のインストール時に Administration Server をインストールする必要があります。 

Access Manager でのサードパーティー製 Web コンテナの使用

サードパーティー製 Web コンテナ (BEA WebLogic Server または IBM WebSphere Application Server) を Portal Server および Access Manager と組み合わせて使用できます。これらのコンテナは、コンテナに依存する Java ES コンポーネントをインストールする前にインストールして実行する必要があります。

Access Manager SDK に対してサードパーティー製 Web コンテナを使用するには、インストール後に Access Manager SDK を手動で設定する必要があります。『Sun Java Enterprise System 2005Q4 インストールガイド(UNIX 版)』の「コンテナの設定を使用する Access Manager SDK の例」を参照してください。

注意: Portal Server は、Solaris OS 上ではサードパーティー製 Web コンテナのみを使用できます。 

注意: Access Manager と Portal Server では同じ種類の Web コンテナを使用することが推奨されます。 

負荷分散プラグインに対する Apache Web Server の使用

Apache Web Server は、Application Server の負荷分散プラグインで使用することができます。この場合、Apache Web Server は、このサーバーに依存する Java ES コンポーネントをインストールする前にインストールし、実行する必要があります。詳細については、『Sun Java Enterprise System 2005Q4 インストールガイド(UNIX 版)』の「インストール前提条件」を参照してください。

スキーマ 1 LDAP の使用

LDAP スキーマ 1 に基づくインストール例については、『Sun Java Enterprise System 2005Q4 インストールガイド(UNIX 版)』の「Calendar-Messaging Schema 1 の例」で説明しています。スキーマ 1 配備については、Access Manager を使用できません。

シングルユーザーエントリとシングルサインオンの設定

シングルサインオンをセットアップする手順は、『Sun Java Enterprise System 2005Q1 Deployment Example Series: Evaluation Scenario』の第 8 章「Configuring and Using Single Sign-On」に記載されています。シングルサインオンを行うには Access Manager が必要です。 

HADB を使用した高可用性の設定 

高可用性のための HADB の設定例は、『Sun Java Enterprise System 2005Q4 インストールガイド(UNIX 版)』の「Web とアプリケーションサービスの例」に記載されています。

Application Server 負荷分散 

Application Server の負荷分散プラグインの使用方法を含む例は、『Sun Java Enterprise System 2005Q4 インストールガイド(UNIX 版)』の「Web とアプリケーションサービスの例」に掲載されています。

非ルート所有権 

Application Server または Web Server に対して非ルート所有権が必要な場合、次のいずれかの例を参照してください。

『Sun Java Enterprise System 2005Q4 インストールガイド(UNIX 版)』の「非ルートユーザーとして実行するように設定された Access Manager の例」または

『Sun Java Enterprise System 2005Q4 インストールガイド(UNIX 版)』の「非ルート所有の Web Server または Application Server インスタンスでの Portal Server の例」