始める前に
複数のプロファイルが存在する場合は、
プラグイン・インストーラーはデフォルト・プロファイルのみを構成します。構成するプロファイルをインストーラーが選択する方法を決定する論理の流れについての説明は、プラグイン構成
を参照してください。
この手順は、マシン上のデフォルト・プロファイルであるカスタム・プロファイルを構成します。
この手順では、ユーザーがマシン A にデプロイメント・マネージャーを既にインストールしたと想定します。

マシン B 上の WebSphere
Application Server ノードは、この手順でユーザーが作成するカスタム・ノードです。
この手順では、Web サーバー・プラグインをインストールする前に、デプロイメント・マネージャーを開始し、カスタム・ノードを統合します。
デプロイメント・マネージャーを開始します。デプロイメント・マネージャーが稼働していないと、カスタム・ノードを正常に統合および構成することはできません。
- オペレーティング・システムにログオンします。
root (AIX または Linux などの
オペレーティング・システムの場合)、または
管理者グループのメンバー (Windows システムの場合) として
ログオンします。
![[Windows]](../../windows.gif)
Windows システムでインストールを行う際に、
インストーラーのユーザー・アカウントが、
以下の拡張ユーザー権限を持っている場合、Windows サービスが
自動的に作成され、アプリケーション・サーバーを自動始動します。
- オペレーティング・システムの一部としてアクションを行う
- サービスとしてログオンする
例えば、一部の Windows システムでは、
「管理ツール」 >
「ローカル・セキュリティー・ ポリシー」 >
「User Rights Assignments」をクリックして、拡張オプションを表示します。
詳しくは、Windows の資料を参照してください。
インストール・ウィザードでは、ユーザー ID が
管理者グループのメンバーである場合に、その Windows ユーザー ID
に拡張ユーザー権限が与えられます。サイレント・インストールでは、
これらの権限は与えられません
Windows プラットフォームで新規ユーザー ID を作成してサイレント・インストールを
行う場合、正しくサイレント・インストールを行う前に、システムを再始動して、
そのユーザー ID の適切な権限をアクティブにする必要があります。
アプリケーション・サーバーを Windows サービスとして
実行する予定の場合は、スペースを含むユーザー ID からインストールしないでください。ユーザー ID にスペースが含まれていると、妥当性検査ができません。
このようなユーザー ID を使用すると、インストールを続行できません。
この問題を回避するには、
スペースを含まないユーザー ID を使用して、インストールを行います。
- WebSphere Application Server Network Deployment 製品をインストールします。
製品および追加のソフトウェアのインストール
を参照してください。
- マシン上の最初のプロファイルとしてカスタム・プロファイルを作成し、
作成する際にノードを統合します。 カスタム・プロファイルの作成
を参照してください。
- オプション: デプロイメント・マネージャーの管理コンソールを使用して、
カスタム・ノード上にアプリケーション・サーバーを作成します。
「サーバー」>「Applications servers」>「新規作成」
をクリックし、指示に従ってサーバーを作成します。
プラグインのインストールにサーバーは必要ありませんが、
サーバーによって Web サーバーの機能性を検査することができます。
- オプション: デプロイメント・マネージャーの管理コンソールにいる間に、新規サーバー上で DefaultApplication を
インストールします。
DefaultApplication にはスヌープ・サーブレットが含まれています。検査ステップはスヌープ・サーブレットを使用します。
- アプリケーション・サーバーが稼働している場合は、停止します。
管理対象ノードを停止する
には、stopServer コマンド
またはデプロイメント・マネージャーの管理コンソールを
使用します。
- IBM HTTP Server または別のサポートされる Web サーバーをマシン B にインストールします。
詳しくは、IBM HTTP Server のインストール
またはご使用の Web サーバーの製品文書を参照してください。
- Web サーバーのあるマシン上でプラグイン・インストール・ウィザードを起動します。
ランチパッドからプラグイン・インストール・ウィザードを選択するか、
あるいはディレクトリーを製品ディスクまたはダウンロードされた
インストール・イメージ内の plugin ディレクトリーに
移動して、install コマンドを実行します。
- ロードマップのチェック・ボックスをクリアするか、または
ロードマップを表示するチェック・ボックスを選択して、「次へ」をクリックします。
従うべきインストール・シナリオがわからない場合は、代わりにロードマップを表示します。
インストール・ステップの簡単な概説としてロードマップを印刷し、保持します。
プラグイン・ロードマップを表示するブラウザー・ウィンドウに Web ブラウザー・ナビゲーション・コントロールおよびメニュー・バーが表示されない場合は、Ctrl-P を押してロードマップを出力します。
ナビゲーション・コントロールおよびメニュー・バーが
表示されていない場合は、Ctrl-W を押して、ブラウザー・ウィンドウを閉じます。
あるいは、タイトル・バーのウィンドウ・コントロールでブラウザー・ウィンドウを閉じます。
- 使用許諾契約書を読み、その条件に同意する場合は契約書を承認します。
終了したら、「次へ」をクリックします。
- ご使用のシステムが前提条件の検査にパスしない場合は、インストールを停止し、問題を訂正して、インストールを再始動します。
ご使用のシステムが前提条件の検査をパスしたら、「次へ」をクリックします。
前提条件の欠落については、適切なログ・ファイルを探してください。
- インストールを中止する場合は、プラグインをインストールしたユーザーの一時ディレクトリーにある temporaryPluginInstallLog.txt ファイルを参照してください。
例えば、root ユーザーが AIX または Linux などのオペレーティング・システムにおいて、
プラグインをインストールした場合は、/tmp/temporaryPluginInstallLog.txt
ファイルが作成されます。
- 前提条件の欠落に関する警告が表示されてもインストールを継続する場合は、
インストールの完了後に plugins_root/logs/install/log.txt
ファイルを参照してください。
ログ・ファイルについて詳しくは、
インストールのトラブルシューティング
を参照してください。
- 構成する Web サーバーのタイプを選択し、「次へ」をクリックします。
プラグイン・インストール・ウィザード・パネルは、
構成する Web サーバー を識別するためのプロンプトを出します。
プラグイン・インストール・ウィザードを実行するたびに、実際に選択できる Web サーバーは 1 つのみです。
構成している間は Web サーバーを停止します。
この手順の後のステップで、スヌープ・サーブレット・テストを開始する際に Web サーバーの開始を指示します。
「なし」とラベル付けされた Web サーバー識別オプションを
選択すると、Web サーバーはバイナリー・プラグインをインストールしますが、Web サーバーを構成しません。
- 「Application server machine (local)」を選択し、「次へ」をクリックします。
- プラグインのインストール・ルート・ディレクトリーのデフォルト・ロケーションを受け入れます。
「次へ」をクリックします。
別の新規ディレクトリーを入力するか、または「参照」をクリックして空のディレクトリーを選択することができます。
完全修飾パスは、プラグイン・インストール・ルート・ディレクトリーを識別します。
デフォルト・ロケーションは、ディレクトリー規則
に示されています。
Web サーバーは、WebSphere Application Server がサポートしないプラットフォームで稼働する可能性があります。
- 必要に応じて、「Application Server installation location」パネルで
「参照」をクリックし、管理対象ノードのロケーションを参照します。インストール・ルート・ディレクトリーが正しい場合は、「次へ」をクリックします。
完全修飾パスは、Network Deployment 製品コア・ファイルのインストール・ルート・ディレクトリーを識別します。
- 「参照」をクリックして、ご使用の Web サーバーの構成ファイルを
選択し、Web サーバー・ポートが正しいことを確認し、終了してから「次へ」をクリックします。
ファイルのディレクトリーだけでなく、ファイルを選択します。
Web サーバーに 2 つの構成ファイルがある場合は、ファイルごとにブラウズする必要があります。
以下のリストは、サポートされる Web サーバーの構成ファイルを示します。
- Apache HTTP Server
- apache_root/config/httpd.conf
- Lotus Domino Web サーバー
- names.nsf and Notes.jar
ウィザードは notes.jar ファイルを求めるプロンプトを出します。
実際の名前は、Notes.jar です。
プラグイン・インストール・ウィザードは、
ファイルの存在については検証しますが、いずれのファイルも確認しません。
- IBM HTTP Server
- IHS_root/conf/httpd.conf
- Microsoft Internet
Information Services (IIS)
- プラグイン・インストール・ウィザードは、正しいファイルを判別して編集することができます。
- Sun ONE Web Server 6.0 または Sun Java System Web Server バージョン 6.1
- obj.conf および magnus.conf
ウィザードは、Web サーバー定義のニックネームのネーミング・パネルを表示します。
- Web サーバーのニックネームを指定して、「次へ」をクリックします。
ウィザードは、この値を使用して、プラグイン・インストール・ルート・ディレクトリーの
構成フォルダーに名前を付けます。
また、ウィザードはアプリケーション・サーバーの構成スクリプトにある名前を
使用して、Web サーバー定義の名前を付けます。
- plugin-cfg.xml ファイルのロケーションを受け入れ、「次へ」をクリックします。
デフォルトで構成されるパスを判別する論理の説明については、プラグイン構成
を参照してください。ウィザードは、そのファイルに最適のパスを判断するために、管理対象アプリケーション・サーバー・ノードの特性を判別します。
統合カスタム・ノードには以下のパスがあります。
profile_root
/config/cells/cell_name/nodes/
node_name_of_custom_profile/servers/
web_server_name/plugin-cfg.xml
profile_root
/config/cells/cell_name/nodes/
node_name_of_custom_profile/servers/
web_server_name/plugin-cfg.xml
デフォルト値を受け入れます。
- プラグイン・インストールの特性を検査した後で「次へ」をクリックするか、または
「戻る」をクリックして変更を行います。
デプロイメント・マネージャーの管理コンソールを使用して、既存の Web サーバーを削除したり、新規に作成したりできます。
統合ノードは、複数の Web サーバー定義を含むことができます。
- プリインストール要約パネルで「次へ」をクリックしてインストールを開始するか、
または「戻る」をクリックしてインストールの特性を変更します。
ウィザードはプラグインのインストール、および Web サーバーと管理対象カスタム・ノードの構成を開始します。
ウィザードには、プラグインをインストールする際に、
インストール状況表示パネルが表示されます。インストール完了時には、ウィザードにインストール要約パネルが表示されます。
- ウィザードがコードをインストールし、アンインストーラー・プログラムを作成した後で、
ポストインストール要約パネルを調べます。
終了した後で「次へ」をクリックして、プラグイン・インストール・ロードマップを表示します。
プラグイン・インストール・ウィザードは、バイナリー・プラグイン・モジュールをインストールします。
例えば、Linux システムでは、インストールによって
plugins_root ディレクトリーが作成されます。
plugins_root/config/Web_server_name ディレクトリーには、plugin-cfg.xml ファイルが含まれています。
ウィザードは、
構成スクリプトおよび plugin-cfg.xml ファイルの名前とロケーションを表示します。
またウィザードは、構成される Web サーバーのタイプおよび Web サーバーのニックネームも表示します。
問題が発生し、インストールが失敗した場合は、plugins_root/logs
ディレクトリーのログを調べてください。
問題をすべて修正したら、再インストールしてください。
- ロードマップを閉じ、「終了」をクリックして、ウィザードを終了します。
インストールからのログ・ファイルは、plugins_root/logs/install
ディレクトリーにあります。
- Web サーバー定義を作成して、インストールを完了します。
デプロイメント・マネージャーの管理コンソールを使用して、統合ノードに Web サーバー定義を作成することができます。
または、プラグイン・インストール・ウィザードが作成した構成スクリプトを実行することができます。
スクリプトには、管理コンソール・オプションの使用時に収集する必要があるすべての情報が既に含まれています。
以下のオプションのいずれかを選択します。
- 管理コンソールの使用
「サーバー」 >
「Web サーバー」 > 「新規作成」
をクリックし、「新規 Web サーバー・エントリーの作成」ウィザードを使用して Web サーバー定義を作成します。
- 構成スクリプトの実行
コマンド・ウィンドウから適切なコマンドを実行します。
セキュリティーを使用可能にした場合、
またはデフォルトの JMX コネクター・タイプを変更した場合は、
スクリプトを編集して、wsadmin コマンドに適切なパラメーターを組み込みます。
一部のオペレーティング・システムのシェル・スクリプトには、発音解を持つ 2 バイト文字または
1 バイト文字を含めることができません。
Web サーバーへのファイル・パスに、o ウムラウト (o の上に発音符)、c セディーユ (マークは c の下) などの
発音解を持つ 2 バイト文字または 1 バイト文字、あるいは他の発音解を持つ文字が含まれる場合、
スクリプトは正常に実行されない可能性があります。このようなスクリプトは、その内容をコマンド行にコピーして、wsadmin コマンドを直接実行します。
- Lotus Domino Web サーバーのみ: WAS_PLUGIN_CONFIG_FILE 環境変数を設定します。
AIX または Linux などのプラットフォームでは、
スクリプトを親シェルに提供することで、
エクスポートされた変数を子プロセスが継承することができます。
Windows システムでは、他のコマンドを実行するのと同様にスクリプトを実行します。
Windows システムでのソースは自動です。
- コマンド・ウィンドウをオープンします。
- ディレクトリーをプラグイン・インストール・ルート・ディレクトリーに変更します。
-
plugins_root/bin/setupPluginCfg.sh スクリプトに適したコマンドを発行します。
. plugins_root/bin/setupPluginCfg.sh
(ピリオドとインストール・ルート・ディレクトリーの間のスペースに注意してください。)
source plugins_root/bin/setupPluginCfg.sh
AIX または Linux などのオペレーティング・システムの場合、
このスクリプトは lotus_root/notesdata
ディレクトリーにもあります。
Lotus Domino Web サーバーを開始する前に、スクリプトに適切なコマンドを実行します。
- Snoop サーブレットを開始し、アプリケーション・サーバーからアプリケーションを検索する Web サーバーの機能を検証します。
ご使用のアプリケーション・サーバーおよび Web サーバーを
開始し、IP アドレスとスヌープ・サーブレットを使用して、ご使用の環境をテストします。
- アプリケーション・サーバーを始動します。 Network Deployment 環境では、
セルにアプリケーション・サーバーを追加する際に DefaultApplication を組み込んだ場合にのみ、Snoop サーブレット
をそのセル内で使用することができます。
addNode コマンドの -includeapps オプションにより、DefaultApplication がそのセルにマイグレーションされます。
アプリケーションが存在しない場合は、このステップはスキップしてください。
- 使用している IBM HTTP Server または Web サーバーを始動します。
コマンド・ウィンドウを使用して、IBM HTTP Server のインストール済みイメージ、
またはユーザーの Web サーバーのインストール済みイメージに移動します。
IBM HTTP Server に適切なコマンドを実行して、Web サーバーを始動します。
コマンドの例を以下に示します。
IBM HTTP Server をコマンド行から始動する方法は、以下のとおりです。
IBMHttpServer/bin ディレクトリーの
apache コマンドと
apachectl コマンドにアクセスします。
- ブラウザーで http://localhost:9080/snoop を参照して、アプリケーション・サーバーによって提供される内部 HTTP トランスポートをテストします。
ブラウザーで
http://Host_name_of_Web_server_machine/snoop
を参照して、Web サーバー・プラグインをテストします。
HTTP トランスポート・ポートはデフォルトで 9080 であり、
すべてのプロファイルで固有でなければなりません。このポートは、default_host という名前の仮想ホストと関連し、
その仮想ホストは、インストール済みの DefaultApplication およびインストール済みサンプルをホストするよう構成されています。
スヌープ・サーブレットは、DefaultApplication の一部です。ポートを変更して、
実際の HTTP トランスポート・ポートに一致させます。
- スヌープが稼働していることを確認します。
どちらかの Web アドレスで
「Snoop Servlet - Request/Client Information」ページが表示されるはずです。
- リモート IBM HTTP Server のみ:
以下のステップを使用することによって、
自動伝搬機能がリモート IBM HTTP Server に対して動作することを確認します。
この手順は、ローカル Web サーバーでは必須ではありません。
- IHS_root /conf/admin.passwd ファイル内に user=adminUser、password=adminPassword を作成します。
例: c:¥ws¥ihs60¥bin¥htpasswd -cb c:¥ws¥ihs60¥conf¥admin.passwd
adminUser adminPassword
- デプロイメント・マネージャーまたは Application Server の管理コンソールを使用して、IBM HTTP Server の管理ユーザーのために作成された、ユーザー ID およびパスワード情報を入力します。
「サーバー」>「Web サーバー」>「Web_server_definition」>「Remote Web server
administration」へ進みます。値を admin Port=8008、User Id=adminUser、Password=adminPassword と設定します。
- httpd.conf ファイルおよび
plugin-cfg.xml ファイルについて、正しい読み取り/書き込み許可を設定します。
詳しくは、IHS_root /logs/admin_error.log ファイルを参照してください。
プラグイン構成ファイルの自動伝搬では、
IBM HTTP 管理サーバーが稼働中である必要があります。WebSphere Application Server 管理コンソールを使用して
IBM HTTP Server を管理している場合は、次のエラー・メッセージが表示される場合があります。
「Could not connect to IHS Administration server error」
以下の手順を実行して、
エラーを訂正します。
- IBM HTTP Server 管理サーバーが稼働していることを確認します。
- WebSphere Application Server 管理コンソールで定義された Web サーバーのホスト名とポートが、IBM HTTP Server
の管理ホスト名とポートと一致することを確認します。
- ファイアウォールが原因で WebSphere Application Server 管理コンソールから IBM
HTTP Server 管理サーバーへのアクセスが不能になっていないことを確認します。
-
リモート管理対象の WebSphere Application Server 管理コンソー
ルで指定したユーザー ID
とパスワードが、htpasswd コマンドを使用して admin.passwd ファイルに作成されることを確認します。
- 安全に接続するには、IBM
HTTP Server 管理サーバー keydb 個人証明書を署名者証明書として WebSphere
Application Server 鍵データベースにエクスポートすることを確認します。
この鍵データベースは、
ご使用の管理コンソールが稼働しているプロファイルの sas.client.props ファイル内
の com.ibm.ssl.trustStore ディレクティブによって指定されます。
この考慮事項は、主に
自己署名証明書用です。
- 問題が解決しない場合は、IBM HTTP Server admin_error.log ファイルと
WebSphere Application Server ログ (trace.log ファイル) を確認して、問題の原因を判別します。
- デプロイメント・マネージャーに DefaultApplication がインストールされていない場合は、
独自のアプリケーションを使用して、Web サーバーおよびカスタム・ノードの機能性を検査することができます。
アプリケーションのデプロイに関するヘルプについては、WebSphere Application Server のファースト・パス
を参照してください。
- デプロイメント・マネージャーの管理コンソールから、「システム管理」>「変更をマスター・リポジトリーに保管」>「ノードと変更を同期化」>「保管」をクリックします。
- 管理対象ノードに対して複数の Web サーバー定義を作成するには、
プラグイン・インストール・ウィザードを使用して個々の Web サーバーを構成します。
毎回、同じ管理対象ノードを識別します。個々の Web サーバーに、異なるニックネームを指定します。
結果
この手順によって、Web サーバー・マシン上に、WebSphere Application Server 用の Web サーバー・プラグインが
インストールされます。プラグイン・インストール・ウィザードは、
管理対象ノード内に Web サーバー定義を作成します。
プラグイン・インストール・ウィザードは、Web サーバーを構成して、
管理対象カスタム・ノード内にある plugin-cfg.xml ファイルを使用します。
デプロイメント・マネージャーは、ファイルに影響を及ぼすイベントが
発生する際には必ず、Web サーバー・プラグイン構成ファイル plugin-cfg.xml を再生成します。
そのようなイベントには、アプリケーション、
サーバー、または仮想ホストの追加または除去が含まれます。
クラスターおよびクラスター・メンバーの作成または除去によっても、
ファイルが再生成されます。ノード同期を介した自動伝搬は、
個々の再生成後のファイルを、カスタム・ノード・マシン上の以下のロケーションにコピーします。
profile_root
/config/cells/cell_name/nodes/
node_name_of_custom_profile/servers/
web_server_name/plugin-cfg.xml
バイナリー・プラグイン・モジュールをインストール
すると、
Plugins ディレクトリーおよびいくつかのサブディレクトリーが作成されます。
例えば、以下のディレクトリーは、Linux システムで作成されたものです。
- plugins_root/_uninstPlugin/_jvmForPlugin には、本製品のアンインストールに使用される WebSphere Application Server SDK, Java Technology Edition が含まれています。
- plugins_root/_uninstPlugin には、アンインストーラー・プログラムが含まれています。
- plugins_root/bin には、サポートされるすべての Web サーバーのバイナリー・プラグインが含まれています。
- plugins_root/logs には、ログ・ファイルが含まれています。
- plugins_root/properties には、バージョン情報が含まれています。
- plugins_root/roadmap には、プラグイン・インストール・ウィザードのロードマップが含まれています。
次の作業
ローカル Web サーバーのバイナリー・プラグインをインストールし、
インストールを完了する構成スクリプトを実行した後で、管理対象ノードおよび Web サーバーを始動することができます。
プラグイン構成ファイルのロケーションについて詳しくは、プラグイン構成
を参照してください。
Web サーバーの構成に関連するファイルについての詳細は、Web サーバーの構成
を参照してください。
サポートされる Web サーバーの、プラグイン・インストール・ウィザードによる構成方法について詳しくは、Web サーバー構成ファイルの編集
を参照してください。
Web サーバー・プラグインのインストールに関するその他のインストール・シナリオについては、Web サーバー・プラグインのインストール
を参照してください。