The Web Server Plug-ins Configuration Tool configures an
application server for a web server type and creates a web server
definition in the configuration of the application server. Become
familiar with the different processing paths that the Web Server Plug-ins
Configuration Tool can use.
This article describes the two ways
that the Web Server Plug-ins Configuration Tool can configure a web
server and create the plugin-cfg.xml file, which
is the plug-in configuration file.
Tip: As an alternative to using the Web Server Plug-ins
Configuration Tool, you can use the pct command-line tool with a response
file to configure a web server. For more information, read Configuring
a web server plug-in using the pct tool.
Before you begin: The plug-ins and web-server
configuration files are updated during plug-ins configuration. If
you are using the Web Server Plug-ins Configuration Tool or the pct
command-line tool as a non-root user, verify that you have appropriate
privileges to update the configuration files for the Web Server Plug-ins
as well as the configuration files for your web server (such as IHS)
before starting a configuration—especially if you are not the
owner of these files.
Attention: When using the Web Server Plug-ins Configuration Tool to configure the IBM® HTTP Server Administration Server, the WebSphere Customization
Toolbox must be run as a "local" account with administrator/root privileges.
In addition, the
default httpd.conf configuration file must stay within the
<IHS_HOME>/conf directory, and you must run
setupadm manually after the administration configuration.
Supported configurations: The Web Server Plug-ins Configuration Tool
is intended for use with the full WebSphere® Application
Server profile. It is not required or supported for use in generating a web server plug-in for
Liberty.
Configuration flows
The Web Server Plug-ins Configuration Tool resolves all configurations of the web server and WebSphere
Application Server to two scenarios: remote plug-in configuration and local plug-in configuration.
The logic implemented in determining which scenario applies to a configuration is shown in the
following diagram.
Legend:
- Installation type?
- The installation type is either remote or local.
When the Web server and application server
are not on the same computer, choose the remote scenario. When both the web server and application
server are on the same computer, choose the local scenario.
- Profile?
- If the product is installed but the profile is accidentally deleted or otherwise missing, the
scenario is considered to be a remote installation. Create a profile before running the script.
- Standalone application server with web server definition?
- If the profile has an existing web server definition, the installation is considered a remote
plug-in configuration. You cannot have more than one web server definition in a standalone
application server.
Scenario A. Local standalone plug-in configuration
In this scenario, the Web Server Plug-ins Configuration Tool creates a web server definition
within the application server profile directly, without the use of a script.
The Web Server Plug-ins Configuration Tool configures the web server to use the
plugin-cfg.xml file that is within the application server profile. The
application server regenerates the plugin-cfg.xml file in the
profile_root/config/cells/
cell_name/nodes/
web_server_name_node/servers/
web_server_name directory. Regeneration occurs whenever a change occurs in the
application server configuration that affects deployed applications.
After configuring the application server for the local web server, you can start the application
server and the web server immediately.
Table 1. Configuration
that qualifies for the local application server scenario.
Profile type |
Automatic creation of web server definition? |
Web server already defined in application server configuration? |
Application server |
Yes |
No |
A application server profile that has an existing web server definition should be processed as a
remote plug-in configuration. An application server can have just one web server definition.
See Scenario B for a description of this type of node.
The following overview shows the procedure for verifying the web server configuration:
- Start the web server with the proper procedure for your web server.
- Start the application server.
Change directories to the
profile_root/bin directory and run the
startServer command:
./profile_root/bin/startServer.sh
server1
profile_root\bin\startServer server1
Open the administrative console, and save the changed configuration.
- Point your browser to http://localhost:9080/snoop to test the internal HTTP
transport provided by the Application Server. Point your browser to
http://Host_name_of_Web_server_machine/snoop to test the web
server plug-in.
- Verify that both web addresses display the Snoop Servlet - Request/Client Information page.
The Web Server Plug-ins Configuration Tool does not automatically create a web server definition
within the distributed profile on a remote machine. The tool creates the
configureweb_server_name script instead.
The Web Server Plug-ins Configuration Tool configures the web server to use the
plugin-cfg.xml file that is maintained on the web server machine in the
plugins_root/config/web_server_name
directory. This file requires periodic propagation. Propagation is copying the current
plugin-cfg.xml file from the application server machine to replace the
plugins_root/config/web_server_name/plugin-cfg.xml
file.
After installing the binary plug-in for the local web server, you do not have to run the script
before you can start the application server and the web server. However, you do not have the
benefits of a Web server definition in the application server node until you run the script.
Table 2. Configurations that qualify for the remote application
server scenario.
Profile type |
Creation of web server definition? |
Web server already defined in application server configuration? |
Any profile anywhere if you select a remote installation type in the Web
Server Plug-ins Configuration Tool |
By script |
N/A |
No profile |
By script |
N/A |
Standalone application server profile with an existing web server
definition |
By script |
Yes |
The following overview shows the procedure for verifying the temporary
plugins_root/config/web_server_name/plugin-cfg.xml
file.
The web server communicates with the remote application server using the temporary
plugin-cfg.xml file.
If the application server has an HTTP Transport port assignment other than 9080, the test is not
successful. Continue to the next section to create the web server definition on the application
server and to complete your test of the configuration.
- Start the web server with the proper procedure for your web server.
- Start the application server on the remote machine.
- Point your browser to http://localhost:9080/snoop to test the internal HTTP
transport provided by the application server. Point your browser to
http://Host_name_of_Web_server_machine/snoop to test the web
server plug-in.
- Verify that both web addresses display the Snoop Servlet - Request/Client Information page.
The following overview shows the procedure for completing the configuration. The configuration
is not complete until the Web server definition exists in the configuration of the application
server node. The web server definition is a central element in the regeneration of a valid plug-in
configuration file,
plugin-cfg.xml.
- Create the web server definition in the application server.
Run the script to manually create
the web server definition within the configuration of the application server node:
- Copy the script from the plugins_root/bin directory to
the remote app_server_root/bin directory.
- Open a command window and run the script:
- ./configureweb_server_name.sh
- configureweb_server_name.bat
The
configureweb_server_name script can take three
parameters:
profile_name,
Admin_Console_Username and
Admin_Console_Password.
- profile_name indicates the name of the profile used to create the web server
definition.
- Admin_Console_Username indicates the username of the administrative console.
The profile with the administrative console deployed must have administrative-console security
turned on. This parameter can not be used if profile_name is blank.
- Admin_Console_Password indicates the password corresponding to the username.
This parameter cannot be used if both profile_name and
Admin_Console_Username are blank.
Note: The webserverNodeName value in the script is a concatenation of the
nickname that you have chosen for the Web server and the suffix -node. It is
automatically created during plug-in configuration and cannot be changed. For example, if you named
your web server myserver during plug-in configuration, the value for the
associated web server definition created after you ran the script would be
myserver-node.
If you have enabled security or changed the default JMX connector type, edit the script and
include the appropriate parameters.
- Copy the current plug-in configuration file, plugin-cfg.xml, in the
profile_root/config/cells/cell_name/nodes/web_server_name_node/servers/web_server_name
directory. Paste the file on the web server machine to replace the temporary
plugins_root/config/web_server_name/plugin-cfg.xml
file. The IBM HTTP
Server supports automatic propagation. Other web servers require manual propagation.
- Start the web server with the proper procedure for your web server. Open the administrative
console, and save the changed configuration.
- Point your browser to http://localhost:9080/snoop to test the internal HTTP
transport provided by the application server. Point your browser to
http://Host_name_of_Web_server_machine/snoop to test the web
server plug-in.
- Verify that both web addresses display the Snoop Servlet - Request/Client Information page.
To summarize, two scenarios exist for Web Server Plug-ins. Each scenario revolves around a unique
location for the plug-in configuration file, plugin-cfg.xml.
The application server generates the plug-in configuration file. The purpose of the file is to
publish the location of all of the application server objects that are relevant to a web server and
to control binary plug-in configuration options. The file identifies objects such as applications
and virtual hosts for serving applications.
If the web server cannot access the file on the application server machine, you must copy the
file to the web server. That process is called propagation. Propagation is reserved for the remote
plug-in configuration scenario, which is Scenario B in this article.
In the local scenario, the web server can access the plugin-cfg.xml file
because the web server is on the same machine as the file.
All Scenario A configurations have the web server definition within its own web server node.
Limited management options do not let you create or delete the one web server definition in the
administrative console of a standalone application server. The inability of a standalone application
server to create a web server definition is the basis for the configuration scripts created by the
Web Server Plug-ins Configuration Tool. Without the scripts, you could not easily create a web
server definition on a standalone application server node.
The location of the
plugin-cfg.xml file for each configuration described in
this article is shown in the following table:
Table 3. Plug-in
configuration file locations. This table describes the plug-in configuration file
locations.
Scenario |
Profile type |
Location of the
plugin-cfg.xml file |
plugins_root |
profile_root: within the web server
node |
A |
Application server profile |
|
X |
B |
Any profile anywhere if you select a remote installation type in the Web
Server Plug-ins Configuration Tool |
X |
|
No profile |
X |
|
Application server profile with an existing web server definition |
X |
|
Legend:
- plugins_root
-
plugins_root/config/web_server_name/plugin-cfg.xml
- profile_ root: within the web server node
-
profile_root/config/cells/cell_name/nodes/web_server_name_node/servers/web_server_name/plugin-cfg.xml