このトピックでは、Web サーバー・プラグインのインストール、およびデフォルト・プロファイルではないアプリケーション・サーバーの構成を説明しています。
複数のプロファイルが存在する場合は、 プラグイン・インストーラーはデフォルト・プロファイルのみを構成します。構成するプロファイルをインストーラーが選択する方法を決定する論理の流れについての説明は、プラグイン構成 を参照してください。
デフォルト・プロファイルではないアプリケーション・サーバー用の Web サーバー定義を作成する場合は、プラグイン・インストール・ウィザードを強制して、デフォルト・プロファイルではないプロファイルを構成させなければなりません。
この手順では、1 つのマシンに Web サーバーを、別のマシンに WebSphere Application Server 製品をインストールしたと想定します。 またこの手順は、Web サーバーとアプリケーション・サーバー・プロファイルが同じマシン上にあるときに機能します。 プラグインをインストールして、プラグイン・インストール・ウィザードがアプリケーション・サーバー用の構成スクリプトを作成するようにする場合には、リモート・インストール・タイプを選択します。
この手順では、デフォルト・プロファイルではないアプリケーション・サーバー用の Web サーバー定義の作成方法を説明します。 この手順では、リモート・インストール・シナリオの選択と、選択したプロファイルにコマンドをポイントする構成スクリプト用のコマンドの発行を説明します。
構成スクリプトの通常の振る舞いは、スクリプトが実行されているマシン上のデフォルト・プロファイルで作業することです。 この手順では、デフォルトではないプロファイルを構成するためにスクリプトをリダイレクトする方法を説明します。
umaskumask 設定を 022 に設定するには、以下のコマンドを実行します。
umask 022
アプリケーション・サーバーを Windows サービスとして
実行する予定の場合は、スペースを含むユーザー ID からインストールしないでください。ユーザー ID にスペースが含まれていると、妥当性検査ができません。
このようなユーザー ID を使用すると、インストールを続行できません。
この問題を回避するには、
スペースを含まないユーザー ID を使用して、インストールを行います。
ランチパッドからプラグイン・インストール・ウィザードを選択するか、 あるいはディレクトリーを製品ディスクまたはダウンロードされた インストール・イメージ内の plugin ディレクトリーに 移動して、install コマンドを実行します。
従うべきインストール・シナリオがわからない場合は、代わりにロードマップを表示します。 インストール・ステップの簡単な概説としてロードマップを印刷し、保持します。
プラグイン・ロードマップを表示するブラウザー・ウィンドウに Web ブラウザー・ナビゲーション・コントロールおよびメニュー・バーが表示されない場合は、Ctrl-P を押してロードマップを出力します。 ナビゲーション・コントロールおよびメニュー・バーが 表示されていない場合は、Ctrl-W を押して、ブラウザー・ウィンドウを閉じます。 あるいは、タイトル・バーのウィンドウ・コントロールでブラウザー・ウィンドウを閉じます。
前提条件の欠落については、適切なログ・ファイルを探してください。 インストールを中止する場合は、プラグインをインストールしたユーザーの一時ディレクトリーにある temporaryPluginInstallLog.txt ファイルを参照してください。 例えば、root ユーザーが AIX または Linux などのオペレーティング・システムにおいて、 プラグインをインストールした場合は、/tmp/temporaryPluginInstallLog.txt ファイルが作成されます。
ログ・ファイルについて詳しくは、 インストールのトラブルシューティング を参照してください。
プラグイン・インストール・ウィザード・パネルは、 構成する Web サーバー を識別するためのプロンプトを出します。 プラグイン・インストール・ウィザードを実行するたびに、実際に選択できる Web サーバーは 1 つのみです。
構成している間は Web サーバーを停止します。 この手順の後のステップで、スヌープ・サーブレット・テストを開始する際に Web サーバーの開始を指示します。
「なし」とラベル付けされた Web サーバー識別オプションを 選択すると、Web サーバーはバイナリー・プラグインをインストールしますが、Web サーバーを構成しません。
別の新規ディレクトリーを入力するか、または「参照」をクリックして空のディレクトリーを選択することができます。 完全修飾パスは、プラグイン・インストール・ルート・ディレクトリーを識別します。
デフォルト・ロケーションは、ディレクトリー規則 に示されています。
Web サーバーは、WebSphere Application Server がサポートしないプラットフォームで稼働する可能性があります。
ファイルのディレクトリーだけでなく、ファイルを選択します。 Web サーバーに 2 つの構成ファイルがある場合は、ファイルごとにブラウズする必要があります。
ウィザードは notes.jar ファイルを求めるプロンプトを出します。実際の名前は、Notes.jar です。
プラグイン・インストール・ウィザードは、ファイルの存在を検証しますが、いずれのファイルも妥当性検査しません。
ウィザードは、Web サーバー定義のニックネームのネーミング・パネルを表示します。
ウィザードは、この値を使用して、プラグイン・インストール・ルート・ディレクトリーの 構成フォルダーに名前を付けます。 また、ウィザードはアプリケーション・サーバーの構成スクリプトにある名前を 使用して、Web サーバー定義の名前を付けます。
$AdminTask deleteServer { -serverName webserver1 -nodeName webserver1_node } $AdminTask removeUnmanagedNode { -nodeName webserver1_node } $AdminConfig saveこれらのコマンドにおいて、webserver1 は Web サーバーの名前です。
スタンドアロン Application Server ノードの場合、アプリケーション・サーバーは profile_root /config/cells/ cell_name /nodes/ web_server_name_node/servers/ web_server_name /plugin-cfg.xml ファイル・パス内でファイルを作成します。
フィールド内のロケーションを指定して、Web サーバーとアプリケーション・サーバーが同じマシン上にある場合、Web サーバーがファイルにアクセスできるようにします。 Web サーバーとアプリケーション・サーバーが異なるマシン上にある場合は、デフォルト値を受け入れます。
plugin-cfg.xml ファイルのロケーションが、Web サーバーの構成ファイル内で使用されます。 この時点でロケーションを正しく入力できない場合は、手動で Web サーバー構成ファイルの編集を行い、ロケーションを訂正して、ロケーションが非デフォルト・アプリケーション・サーバー・プロファイル内の plugin-cfg.xml ファイルをポイントするようにすることが可能です。 リモート・インストールでは、デフォルトのロケーションは、プラグイン・インストール・ルート・ディレクトリー内にあります。 伝搬では、アプリケーション・サーバー・マシンから Web サーバー・マシンへ現行ファイルがコピーされます。
パネルは、インストールおよび構成を完了するために実行する手動のステップがあることを通知します。 Web サーバーのタイプ、Web サーバーのニックネーム、および plugin-cfg.xml ファイルのロケーションがパネルに表示されます。
プラグイン・インストール・ウィザードは、plugins_root/bin/ ディレクトリー内に configureweb_server_name スクリプトを作成します。
また、プラグイン・インストール・ウィザードは、plugins_root/config/web_server_name ディレクトリー内にデフォルトの plugin-cfg.xml ファイルを作成します。
「次へ」をクリックすると、パネルにはプラグイン・インストール・ルート・ディレクトリー、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 ディレクトリーにあります。
例えば、デフォルト・ロケーションに webserver1 という名前の IBM HTTP Server がある Linux システムでは、/opt/IBM/WebServer/Plugins/bin/configurewebserver1.sh をアプリケーション・サーバー・マシン上の /opt/IBM/WebSphere/AppServer/bin ディレクトリーにコピーします。
2 つのマシンのデフォルト・ファイル・エンコードが異なる場合、configureweb_server_name.bat スクリプト または configureweb_server_name.sh スクリプトの内容が壊れる可能性があります。 このシナリオは、 1 つのマシンが 2 バイト文字セット (DBCS) ロケール用にセットアップされ、 もう 1 つのマシンがそのようにセットアップされていない場合に可能です。
ファイル・エンコードを判別し、 以下のいずれかの手順を使用して障害を回避します。 デフォルトのファイル・エンコード方式を決定するには、 以下の該当するコマンドを実行します。
locale
CHCP
エンコード差の補正手順
Web サーバーが Linux マシン上で稼働し、Network Deployment が Windows マシン上で稼働していると仮定します。
AIX または Linux などのシステム上で稼働している Web サーバー
iconv -f web_server_machine_encoding ¥ -t application_server_machine_encoding ¥ configureweb_server_name.batコマンドを 1 行で入力する場合、継続文字 (¥) は省略します。
Web サーバーが Windows マシン上で稼働していて、Network Deployment が AIX または Linux などのシステムを持つマシン上で 稼働しているとします。
Windows マシン上で稼働する Web サーバー
iconv -f web_server_machine_encoding ¥ -t application_server_machine_encoding ¥ configureweb_server_name.shコマンドを 1 行で入力する場合、継続文字 (¥) は省略します。
ご使用のシステム上で 変換マッピングが iconv コマンドによってサポートされていない場合は、 Web サーバー構成スクリプトの内容をクリップボードにコピーし、 アプリケーション・サーバーが稼働中のマシン上に貼り付けます。
コマンド・ウィンドウを開いて、マシン A にコピーしたスクリプトを実行します。
Web サーバー定義が作成されるとすぐに、 アプリケーション・サーバーは Web サーバーの plugin-cfg.xml ファイルを作成します。例えば、Linux システム上のファイルは以下のファイル・パスを持つことがあります。profile_root/config/cells/cellname/nodes/webserver1_node/servers/webserver1/plugin-cfg.xml
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」
この手順によって、Web サーバー・マシン上に、WebSphere Application Server 用の Web サーバー・プラグインが インストールされます。変更後、結果スクリプトは、デフォルト・プロファイルではないアプリケーション・サーバーの Web サーバー定義を作成します。 また、プラグイン・インストール・ウィザードは、Web サーバーを構成して、アプリケーション・サーバーをサポートします。
Web サーバーを介してスヌープ・サーブレットが表示されれば、Web サーバーとアプリケーション・サーバーは正常に構成されています。
Web サーバーを構成し、Web サーバー定義を作成したあとは、アプリケーションをデプロイし、Web サーバーを介してそれらを実行します。 アプリケーションのデプロイを開始するには、WebSphere Application Server のファースト・パス を参照してください。