+

Search Tips   |   Advanced Search

Web Server Plug-ins Configuration Tool (PCT)

The Web Server Plug-ins Configuration Tool (PCT) is a GUI tool used to configure a web server and create the plugin-cfg.xml file.

The Web Server PCT is supported only on AIX, Linux, and Windows. Alternatively we can use the pct command-line tool.

If we are using the PCT GUI or the pct command-line tool as a non-root user, verify that we have appropriate privileges to update the configuration files for the PCT as the configuration files for our web server (such as IHS) before starting a configuration-especially if we are not the owner of these files.

When using the PCT 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 run setupadm manually after the administration configuration.

The PCT 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 the Liberty profile. For information on generating a web server plug-in for the Liberty profile, read Configure the Liberty profile with a web server plug-in.

See also: Example: Install IHS and configure the plug-in with WebSphere Application Server


Configuration flows for the Network Deployment product

The Web Server Plug-ins Configuration Tool resolves all configurations of a web server and WAS to three scenarios:

The PCT creates a web server definition within the application server profile.

The PCT configures the web server to use the plugin-cfg.xml file within the application server profile. The standalone application server regenerates...

...whenever a change occurs in the application server configuration that affects deployed applications.

After installing the binary plug-in for the local web server, we can start the application server and the web server immediately upon completion of the installation.

Suppose that we create a web server definition on a standalone application server and then federate the node. The web server definition is not federated into the cell because the web server definition is defined as a separate node in a standalone application server. We must recreate the web server definition on the managed node. See Scenario 2.

An unfederated standalone application server that has an existing web server definition should be processed as a remote plug-in configuration.

An existing web server definition on a standalone application server requires that the PCT follow the remote installation path. A standalone application server can have just one web server definition.

See Scenario 3 for a description of this type of node.

A federated standalone application server should be processed as a local distributed plug-in configuration. See Scenario 2 for a description of this type of node.


Verify the web server configuration

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

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

    • (UNIX) ./IHS_root/bin/apachectl start
    • (Windows) IHS_root\bin\apache

  2. Start the application server.

      cd profile_root/bin
      profile_root\bin\startServer server1

    Open the administrative console and save the changed configuration.

  3. To test the internal HTTP transport provided by the application server, point your browser to...

      http://localhost:9080/snoop

    To test the web server plug-in, point your browser to...

      http://Host_name_of_Web_server_machine/snoop

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

The PCT does not automatically create a web server definition within a federated application server profile. The tool creates the configureweb_server script instead in...

For example...

The PCT configures the web server to use the plugin-cfg.xml file that will be created within the application server profile when running the script. The deployment manager regenerates the plugin-cfg.xml file in...

Regeneration occurs whenever a change occurs in the application server configuration that affects deployed applications on the managed node.

After installing the binary plug-in for the local web server, run the script before starting the web server. The web server has already been configured to use the plugin-cfg.xml file in the application server configuration. That file does not exist until we run the configureweb_server script.


Complete the configuration and verify the web server configuration

  1. Start the deployment manager.

  2. If we are planning to add an application server node into a deployment manager cell but have not done so yet, federate the node before installing the plug-ins. If the web server definition exists when we federate the node, the web server definition is lost when we federate.

  3. Create the web server definition in the application server. We have two options:

    • Use the administrative console of the deployment manager to create a web server definition for a managed node.

      Create the web server definition, click...

        Servers > Web servers > New > Create new web server entry wizard

    • Run the script to manually create the web server definition within the configuration of the deployment manager. Run the script from the plugins_root/bin directory. The script can address the deployment manager on the same machine.

      Open a command window to run the appropriate script:

        ./configureweb_server.sh

      The webserverNodeName value in the script is a concatenation of the nick name we have chosen for the web server and the suffix -node. It is automatically created during plug-in installation and cannot be changed. For example, if you named the web server myserver during plug-in installation, 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.

  4. Start the web server with the proper procedure for our web server.

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

    • (*nix) ./IHS_root/bin/apachectl start
    • (Windows) IHS_root\bin\apache

  5. Start the application server.

    cd profile_root/bin and run the startServer command:

    • ./profile_root/bin/startServer.sh server1

  6. Open the administrative console of the deployment manager. Wait for node synchronization to occur and save the changed configuration that includes the new web server definition.

  7. To test the internal HTTP transport provided by the application server, point your browser to...

      http://localhost:9080/snoop

    To test the web server plug-in, point your browser to...

      http://Host_name_of_Web_server_machine/snoop

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

The PCT does not automatically create a web server definition within the distributed profile on a remote machine. The tool creates the configureweb_server script instead.

The PCT configures the web server to use the plugin-cfg.xml file that will be 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 we run the script.


Verify the temporary 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 complete your test of the configuration.

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

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

    • (UNIX) ./IHS_root/bin/apachectl start
    • (Windows) IHS_root\bin\apache

  2. Start the application server on the remote machine.

  3. To test the internal HTTP transport provided by the application server, point your browser to...

      http://localhost:9080/snoop

    To test the web server plug-in, point your browser to...

      http://Host_name_of_Web_server_machine/snoop

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


Complete 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. Start the deployment manager if we are configuring the deployment manager or a managed node.

  2. Federate a remote application server node or custom node now if we are planning to federate the node at some point. If a web server definition already exists when we federate a node, the definition is lost.

  3. Create the web server definition in the application server. We have two options for a managed node. Use the script option for a deployment manager node without managed nodes.

    • Use the administrative console of the deployment manager to create a web server definition for a managed node. Click...

        Servers > Web servers > New > Create new web server entry wizard

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

        • (UNIX) ./configureweb_server.sh
        • (Windows) configureweb_server.bat

      The webserverNodeName value in the script is a concatenation of the nick name we have chosen for the web server and the suffix -node. It is automatically created during plug-in installation and cannot be changed. For example, if you named the web server myserver during plug-in installation, 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.

  4. Open the administrative console of the deployment manager if the node is federated. Wait for node synchronization to occur on the managed node, and save the changed configuration that includes the new Web server definition. If the remote node is not federated, open the administrative console of the application server and save the changed configuration.

  5. Copy the current plug-in configuration file, plugin-cfg.xml, in...

      profile_root/config/cells/cell/nodes/web_server_node/servers/web_server

    Paste the file on the web server machine to replace the temporary file...

      plugins_root/config/web_server/plugin-cfg.xml

    The IBM HTTP Server supports automatic propagation. Other web servers require manual propagation.

  6. Start the web server with the proper procedure for our web server.

  7. To test the internal HTTP transport provided by the application server, point your browser to...

      http://localhost:9080/snoop

    To test the web server plug-in, point your browser to...

      http://Host_name_of_Web_server_machine/snoop

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

To summarize, three 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 elements relevant to a web server. Such elements include applications, virtual hosts for serving applications, clusters, and cluster members for example.

If the web server cannot get to the file on the application server machine, we must take the file to the web server. That process is called propagation. Propagation is reserved for the remote plug-in configuration scenario, which is Scenario 3

In each of the local scenarios, the Web server can get to the plugin-cfg.xml file because it is on the same machine as the file. Two local scenarios exist because of two distinct locations for a local plugin-cfg.xml file.

The configuration scheme for WAS puts the plug-in configuration file in a web server definition that is either within a web server node or a managed node. The type of node is the difference between Scenario 2 and Scenario 1 in this article. All Scenario 2 configurations require the web server definition to exist within a managed application server node. All Scenario 1 configurations have the web server definition within its own web server node.

Limited management options do not let us 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 we 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:

Legend:


Related:

  • Example: Install IHS and configure the plug-in with WebSphere Application Server
  • Web server configuration
  • Configure a web server plug-in using the pct tool
  • Install and remove tools in the WebSphere Customization Toolbox