この手順では、デフォルト・プロファイルがデプロイメント・マネージャーであるマシン上での Web サーバーおよびプラグインの インストールについて説明します。
複数のプロファイルが存在する場合は、 プラグイン・インストーラーはデフォルト・プロファイルのみを構成します。構成するプロファイルをインストーラーが選択する方法を決定する論理の流れについての説明は、プラグイン構成 を参照してください。
この手順は、マシン上のデフォルト・プロファイルであるデプロイメント・マネージャー・プロファイルを構成します。 常に管理対象ノード上にある Web サーバー定義を定義するには、管理対象ノードが存在する必要があります。 デプロイメント・マネージャーがデフォルト・プロファイルである場合、 プラグイン・インストール・ウィザードは、デプロイメント・マネージャー構成で管理対象カスタム・ノードを探します。 デプロイメント・マネージャーが管理対象カスタム・ノードを持たない場合、 プラグイン・インストール・ウィザードは管理対象アプリケーション・サーバー・ノードを探します。 デプロイメント・マネージャーが管理対象ノードを持たない場合、 プラグイン・インストール・ウィザードは、このインストールをリモート・インストールとして分類します。
デプロイメント・マネージャー、および管理対象ノードの ノード・エージェントを開始します。デプロイメント・マネージャーおよびそのノードは、 その構成を正常に変更するために、稼働している必要があります。
以下の手順を使用して、Web サーバー・プラグインをインストールし、Web サーバーを構成し、 デフォルト・プロファイルで Web サーバー定義を作成します。
umaskumask 設定を 022 に設定するには、以下のコマンドを実行します。
umask 022
アプリケーション・サーバーを Windows サービスとして
実行する予定の場合は、スペースを含むユーザー ID からインストールしないでください。ユーザー ID にスペースが含まれていると、妥当性検査ができません。
このようなユーザー ID を使用すると、インストールを続行できません。
この問題を回避するには、
スペースを含まないユーザー ID を使用して、インストールを行います。
製品および追加のソフトウェアのインストール を参照してください。
IBM HTTP Server のインストール またはご使用の Web サーバーの製品資料を 参照してください。
ランチパッドからプラグイン・インストール・ウィザードを選択するか、 あるいはディレクトリーを製品ディスクまたはダウンロードされた インストール・イメージ内の plugin ディレクトリーに 移動して、install コマンドを実行します。
従うべきインストール・シナリオがわからない場合は、代わりにロードマップを表示します。 インストール・ステップの簡単な概説としてロードマップを印刷し、保持します。
プラグイン・ロードマップを表示するブラウザー・ウィンドウに Web ブラウザー・ナビゲーション・コントロールおよびメニュー・バーが表示されない場合は、Ctrl-P を押してロードマップを出力します。 ナビゲーション・コントロールおよびメニュー・バーが 表示されていない場合は、Ctrl-W を押して、ブラウザー・ウィンドウを閉じます。 あるいは、タイトル・バーのウィンドウ・コントロールでブラウザー・ウィンドウを閉じます。
ログ・ファイルについて詳しくは、 インストールのトラブルシューティング を参照してください。
プラグイン・インストール・ウィザード・パネルは、 構成する Web サーバー を識別するためのプロンプトを出します。 プラグイン・インストール・ウィザードを実行するたびに、実際に選択できる Web サーバーは 1 つのみです。
構成している間は Web サーバーを停止します。 この手順の後のステップで、スヌープ・サーブレット・テストを開始する際に Web サーバーの開始を指示します。
「なし」とラベル付けされた Web サーバー識別オプションを 選択すると、Web サーバーはバイナリー・プラグインをインストールしますが、Web サーバーを構成しません。
別の新規ディレクトリーを入力するか、または「参照」をクリックして空のディレクトリーを選択することができます。 完全修飾パスは、プラグイン・インストール・ルート・ディレクトリーを識別します。
デフォルト・ロケーションは、ディレクトリー規則 に示されています。
Web サーバーは、WebSphere Application Server がサポートしないプラットフォームで稼働する可能性があります。
完全修飾パスは、Network Deployment 製品コア・ファイルのインストール・ルート・ディレクトリーを識別します。
ファイルのディレクトリーだけでなく、ファイルを選択します。 Web サーバーに 2 つの構成ファイルがある場合は、ファイルごとにブラウズする必要があります。
ウィザードは notes.jar ファイルを求めるプロンプトを出します。 実際の名前は、Notes.jar です。
ウィザードは、Web サーバー定義のニックネームのネーミング・パネルを表示します。
ウィザードは、この値を使用して、プラグイン・インストール・ルート・ディレクトリーの構成フォルダーに名前を付けます。 ウィザードはまた、デプロイメント・マネージャー内の名前を Web サーバー定義の名前として使用します。
デフォルトで構成されるパスを判別する論理の説明については、プラグイン構成 を参照してください。ウィザードは、そのファイルに最適のパスを判断するために、デプロイメント・マネージャーの特性を判別します。
plugins_root/config/ 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 サーバーを管理対象ノードに割り当てる必要があります。
管理対象ノードは、 プラグイン・インストール・ウィザードを実行する前から存在していなければなりません。それ以外の場合は、インストールはリモート・インストールと見なされます。
ノードを追加すると、nodeagent プロセスが開始します。 何らかの理由でノード・エージェントが実行されていない場合は、ノードを開始します。
詳しくは、startNode コマンド を参照してください。
スクリプトには、管理コンソール・オプションの使用時に収集する必要があるすべての情報が既に含まれています。
「サーバー」 > 「Web サーバー」 > 「新規作成」をクリックし、「新規 Web サーバー・エントリーの作成」ウィザードを使用して Web サーバー定義を作成します。
ノードにデプロイメント・マネージャー・プロファイルしかない場合、 プラグイン・インストーラーはリモート・プラグイン構成に戻ります。 plugins_root/ bin/ configureweb_server_name.sh スクリプトまたは plugins_root¥ bin¥ configureweb_server_name.bat スクリプトをデプロイメント・マネージャーの app_server_root/bin ディレクトリーに手動でコピーして、スクリプトを実行する必要があります。
セキュリティーを使用可能にした場合、 またはデフォルトの JMX コネクター・タイプを変更した場合は、 スクリプトを編集して、wsadmin コマンドに適切なパラメーターを組み込みます。
AIX または Linux などのプラットフォームでは、 スクリプトを親シェルに提供することで、 エクスポートされた変数を子プロセスが継承することができます。 Windows システムでは、他のコマンドを実行するのと同様にスクリプトを実行します。 Windows システムでのソースは自動です。
AIX または Linux などのオペレーティング・システムの場合、 このスクリプトは lotus_root/notesdata ディレクトリーにもあります。
Lotus Domino Web サーバーを開始する前に、スクリプトに適切なコマンドを実行します。
ご使用のアプリケーション・サーバーおよび Web サーバーを 開始し、IP アドレスとスヌープ・サーブレットを使用して、ご使用の環境をテストします。
コマンド・ウィンドウを使用して、IBM HTTP Server のインストール済みイメージ、 またはユーザーの Web サーバーのインストール済みイメージに移動します。 IBM HTTP Server に適切なコマンドを実行して、Web サーバーを始動します。 コマンドの例を以下に示します。
IBM HTTP Server をコマンド行から始動する方法は、以下のとおりです。
HTTP トランスポート・ポートはデフォルトで 9080 であり、 すべてのプロファイルで固有でなければなりません。このポートは、default_host という名前の仮想ホストと関連し、 その仮想ホストは、インストール済みの DefaultApplication およびインストール済みサンプルをホストするよう構成されています。 スヌープ・サーブレットは、DefaultApplication の一部です。ポートを変更して、 実際の HTTP トランスポート・ポートに一致させます。
どちらかの Web アドレスで 「Snoop Servlet - Request/Client Information」ページが表示されるはずです。
以下のステップを使用することによって、 自動伝搬機能がリモート IBM HTTP Server に対して動作することを確認します。 この手順は、ローカル Web サーバーでは必須ではありません。
「Could not connect to IHS Administration server error」
プラグイン・インストール・ウィザードは、 plugins_root/plugin-cfg.xml ファイルを使用するよう、新規 Web サーバーを構成します。
ローカル Web サーバーのバイナリー・プラグインをインストールしたら、 構成スクリプトを正常に実行して Web サーバーを使用する前に、管理対象ノードを作成する必要があります。
インストール手順の概要については、プラグイン構成 を参照してください。
Web サーバーの構成に関連するファイルについての詳細は、Web サーバーの構成 を参照してください。
サポートされる Web サーバーの、プラグイン・インストール・ウィザードによる構成方法について詳しくは、Web サーバー構成ファイルの編集 を参照してください。
Web サーバー・プラグインのインストールに関するその他のインストール・シナリオについては、Web サーバー・プラグインのインストール を参照してください。