WAS v8.5 > Reference > Administrator best practices

Plug-ins configuration

The Web Server Plug-ins Configuration Tool...

As an alternative to using the Web Server Plug-ins Configuration Tool, we can use the pct command-line tool with a response file to configure a web server.

The plug-in and web server configuration files are updated during plug-ins configuration.

If we are using the Web Server Plug-ins Configuration Tool or the pct command-line tool as a non-root user, verify that we have appropriate privileges to update the configuration files for the Web Server Plug-ins as well as the configuration files for the web server (such as IHS) before starting a configuration, especially if you are not the owner of these files. When using the Web Server Plug-ins Configuration Tool to configure the IHS Administration Server, the Websphere Customization Toolbox must be run as a "local" account with administrator/root privileges.

The tool is intended for use with the full WAS profile; it is not required or supported for use in generating a web server plug-in for the Liberty profile.

Installation type 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. We 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 tool configures the web server to use plugin-cfg.xml that is within the application server profile. The application server regenerates...

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, we can start the application server and the web server immediately.

An 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:

  1. Start the web server...

      ./IHS_root/bin/apachectl start

  2. Start the application server.

    Open the dmgr console, and save the changed configuration.

  3. Test the internal HTTP transport

      http://localhost:9080/snoop

  4. Verify that both web addresses display the Snoop Servlet - Request/Client Information page.

The 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 tool configures the web server to use plugin-cfg.xml that is maintained on the web server machine in...

This file requires periodic propagation. Propagation is copying the current plugin-cfg.xml file from the application server machine to replace...

After installing the binary plug-in for the local web server, we do not have to run the script before we can start the application server and the web server. However, we do not have the benefits of a Web server definition in the application server node until you run the script.

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.

  1. Start the web server with the proper procedure for the web server.

    For example, start the IBM HTTP Server from a command line:

      ./IHS_root/bin/apachectl start

    • IHS_root\bin\apache

  2. Start the application server on the remote machine.

    Change directories to the profile_root/bin directory and run the startServer command:

      ./profile_root/bin/startServer.sh server1

    • profile_root\bin\startServer server1

  3. 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.
  4. 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.

  1. 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:

    1. Copy the script from the plugins_root/bin directory to the remote app_server_root/bin directory.
    2. 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 dmgr console. The profile with the dmgr 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.

    The webserverNodeName value in the script is a concatenation of the nickname that we 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 the web server myserver during plug-in configuration, the value for the associated web server definition created after we ran the script would be myserver-node.

    If we have enabled security or changed the default JMX connector type, edit the script and include the appropriate parameters.

  2. 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.
  3. Start the web server with the proper procedure for the web server. Open the dmgr console, and save the changed configuration.
  4. 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.
  5. 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 plugin-cfg.xml.

The application server generates plugin-cfg.xml. 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 plugin-cfg.xml 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 dmgr 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 are create a web server definition on a standalone application server node.

The location of plugin-cfg.xml for each configuration described in this article is shown in the following table:

Plug-in configuration file locations. This table describes plugin-cfg.xml locations.

Scenario Profile type Location of plugin-cfg.xml
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:


Related concepts:
Web server configuration
Configure a web server plug-in using the pct tool


+

Search Tips   |   Advanced Search