Plug-ins configuration


 

+

Search Tips   |   Advanced Search

 

The Plug-ins installation wizard...

  1. Installs a binary plug-in module and a plug-in configuration file for the Web server

  2. Creates a Web server definition in the configuration of the appserver.

 

Configuration flows for WAS ND

The Plug-ins installation wizard resolves all configurations of Web server and WAS to three scenarios:

The logic implemented in determining which scenario applies to a configuration is shown in the following diagram.



Default appserver with Web server definition?

If the default profile is an appserver with an existing Web server definition, then the installation is considered a remote installation. We cannot have more than one Web server definition in a standalone appserver.

Use the same name for the Web server to configure a new Web server to use the existing Web server definition.

Use a different Web server name to create a script that creates a new Web server definition in a federated appserver profile.

Default profile?

If WAS is installed but the Profile Management Tool has not yet created a profile, the scenario is considered to be a remote installation.

When multiple profiles exist, the plug-ins installer configures only the default profile.

Default profile_type?

The Plug-ins installation wizard can configure only one profile at a time. The wizard always works with the default profile. These three paths show how processing varies for different types of profiles.

Federated?

If the appserver node is federated, the Plug-ins installation wizard configures the Web server definition on the managed node.

Suppose the Web server and the managed node are on a separate machine. The plugin-cfg.xml file is automatically propagated to the remote node during node synchronization because the Web server definition is part of the node configuration.

Installation type?

The installation type is either remote or local.

Non-default distributed profile?

If the dmgr has a federated custom node (custom profile), the Plug-ins installation wizard configures the Web server definition on the managed node.

Suppose the Web server and the managed node are on a separate machine. The plugin-cfg.xml file is automatically propagated to the remote node during node synchronization because the Web server definition is part of the node configuration.If a federated custom profile is not found, the Plug-ins installation wizard looks for and configures the first federated appserver node (appserver profile) that it finds. So, the logic is:

  1. Look for a federated managed (custom) profile and configure the first one found.

  2. If no federated managed profile is found, look for a federated appserver profile and configure the first one found.

 

Scenario 1. Remote plug-in configuration

The Plug-ins installation wizard does not automatically create a Web server definition within the default distributed profile on a remote machine. The wizard creates the configurewebserver script instead.

The Plug-ins installation wizard configures the Web server to use plugin-cfg.xml that will be maintained on the Web server machine in...

PLUGINS_ROOT/config/webserver

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

PLUGINS_ROOT/config/webserver/plugin-cfg.xml

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

Profile type Federation status Creation of Web server definition? Web server already defined in Application Server configuration?
Any profile anywhere if we select a remote installation type in the Plug-ins installation wizard N/A By script N/A
No default profile detected N/A By script N/A
Default unfederated standalone appserver profile with an existing Web server definition Not federated By script Yes
Default dmgr profile with no managed nodes N/A By script N/A

 

Testing the appserver without a Web server definition:

The following overview shows the procedure for verifying the temporary file...

PLUGINS_ROOT/config/webserver/plugin-cfg.xml

The Web server communicates with the remote Application Server using the temporary plugin-cfg.xml file.

If the appserver has an HTTP Transport port assignment other than 9082, the test is not successful. Continue to the next section to create the Web server definition on the appserver and 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
  2. Start the appserver on the remote machine. Change directories to...

      $WP_PROFILE/bin

    ...and run the startServer command:

      ./$WP_PROFILE/bin/startServer.sh server1

  3. Point the browser to...

    http://localhost:9082/snoop

    ...to test the internal HTTP transport provided by the appserver.

    Point the 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.

 

Completing the installation by configuring a Web server definition:

The configuration is not complete until the Web server definition exists in the configuration of the appserver 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 dmgr if we are configuring the deployment manager or a managed node.

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

  3. Create the Web server definition in the appserver. we have two options for a managed node. Use the script option for a deployment manager node without managed nodes.

    • Use the admin console of the dmgr to create a Web server definition for a managed node. Go to...

      Servers | Web servers | New

      ...and use the Create new Web server entry wizard to create the Web server definition.

    • Run the script to manually create the Web server definition within the configuration of the appserver node:

      1. Copy the script from...

        ...to...

      2. Open a command window and run the script:

          ./configurewebserver.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 we named the web server myserver during plug-in installation, the value for the associated Web server definition created after you 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 admin console of the dmgr 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 admin console of the appserver and save the changed configuration.

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

      $WP_PROFILE/config/cells/cell/nodes/node/servers/webserver

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

    PLUGINS_ROOT/config/webserver/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 the Web server.

  7. Point the browser to...

    http://localhost:9082/snoop

    ...to test the internal HTTP transport provided by the appserver. Point the browser to...

    http://Host_name_of_Web_server_machine/snoop

    ...to test the Web server plug-in.

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

 

Scenario 2. Local distributed plug-in configuration

The Plug-ins installation wizard does not automatically create a Web server definition within a federated appserver profile. The wizard creates the configurewebserver script instead in...

The Plug-ins installation wizard configures the Web server to use plugin-cfg.xml that will be created within the appserver profile when you run the script. The dmgr regenerates plugin-cfg.xml in...

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

After installing the binary plug-in for the local Web server, run the script before we can start the Web server. The Web server has already been configured to use plugin-cfg.xml in the appserver configuration. That file does not exist until you run the configurewebserver script.

Profile type Federation status Creation of Web server definition? Web server already defined in Application Server configuration?
Default appserver profile Federated By script N/A
Default Custom profile Not federated By script N/A
Default Custom profile Federated By script N/A
Default dmgr profile with a managed node (non-default distributed profile) N/A By script N/A

The following overview shows the procedure for completing the configuration and verifying the Web server configuration:

  1. Start the dmgr.

  2. If planning to add an appserver 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 you federate the node, the Web server definition is lost when you federate.

  3. Create the Web server definition in the appserver. we have two options:

    • Use the admin console of the dmgr to create a Web server definition for a managed node....

      Servers | Web servers | New

      Use the Create new Web server entry wizard to create the Web server definition.

    • Run the script to manually create the Web server definition within the configuration of the dmgr. Run the script from...

PLUGINS_ROOT/bin

The script can address the dmgr on the same machine. Open a command window to run the appropriate script:

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 we named the web server myserver during plug-in installation, the value for the associated Web server definition created after you 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.

  • Start the Web server with the proper procedure for the Web server. For example, start the IBM HTTP Server from a command line:

  • Start the appserver. Change directories to...

    ...and run the startServer command:

  • Open the admin console of the dmgr. Wait for node synchronization to occur and save the changed configuration that includes the new Web server definition.

  • Point the browser to...

    http://localhost:9082/snoop

    ...to test the internal HTTP transport provided by the appserver. Point the 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.

     

    Scenario 3. Local standalone plug-in configuration

    The Plug-ins installation wizard creates a Web server definition within the appserver profile.

    The Plug-ins installation wizard configures the Web server to use plugin-cfg.xml that is within the appserver profile. The standalone appserver regenerates...

    $WP_PROFILE/config/cells/cell/nodes/node/servers/webserver/plugin-cfg.xml

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

    After installing the binary plug-in for the local Web server, we can start the appserver and the Web server.

    Suppose created a Web server definition on a standalone appserver 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. You must recreate the Web server definition on the managed node. See Scenario 2.

    Profile type Federation status Automatic creation of Web server definition? Web server already defined in Application Server configuration?
    Application Server Not federated Yes No

     

    Redirection to Scenario 1

    An unfederated default standalone appserver that has an existing Web server definition is processed as a remote plug-in configuration.

    An existing Web server definition on a standalone appserver causes the Plug-ins installation wizard to follow the remote installation path. A standalone appserver can have just one Web server definition. Specify the same nick name for the Web server to configure a new Web server.

    Use plugin-cfg.xml that is within the Web server definition in the configuration of the appserver. Simply click Browse on the appropriate panel in the Plug-ins installation wizard to select the file. This file must exist. Otherwise, the Plug-ins installation wizard displays a warning and prevents you from proceeding until you select an existing file. The Web server is configured to use this existing plugin-cfg.xml file.

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

     

    Redirection to Scenario 2

    A federated default standalone Application Server is processed as a local distributed plug-in configuration. See Scenario 2 for a description of this type of node.

     

    Overview of the verification procedure

    The following overview shows the procedure for verifying the Web server configuration after installing the binary plug-in module:

    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
    2. Start the appserver. Change directories to...

        $WP_PROFILE/bin

      ...and run the startServer command:

        ./$WP_PROFILE/bin/startServer.sh server1

      Open the admin console and save the changed configuration.

    3. Point the browser to...

      http://localhost:9082/snoop

      ...to test the internal HTTP transport provided by the appserver.

      Point the 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.

     

    Summary

    Three scenarios exist for Web server plug-ins for WAS. Each scenario revolves around a unique location for the plug-in configuration file, plugin-cfg.xml.

    The appserver generates the plug-in configuration file. The purpose of the file is to publish the location of all of the appserver elements that are 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 appserver machine, 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 1 in this topic.

    In each of the local scenarios, the Web server can get to plugin-cfg.xml 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 V6 of 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 3 in this topic. All Scenario 2 configurations require the Web server definition to exist within a managed appserver node. All Scenario 3 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 admin console of a standalone appserver. The inability of a standalone appserver to create a Web server definition is the basis for the configuration scripts created by the Web server plug-ins for WAS. Without the scripts you could not create a Web server definition on a standalone appserver node.

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

    Scenario Profile type Location of plugin-cfg.xml
    Plugins_ install_ root profiles_ root: within the managed node profiles_ root: within the Web server node
    1 Any profile anywhere if we select a remote installation type in the Plug-ins installation wizard X    
    No default profile detected X    
    Default unfederated (stand-alone) Application Server profile with an existing Web server definition X    
    Default dmgr profile with no managed nodes X    
    2 Default appserver profile   X  
    Default custom profile   X  
    Default dmgr profile with a managed node (non-default distributed profile)   X  
    3 Default appserver profile     X

    PLUGINS_ROOT

    PLUGINS_ROOT

    /config/webserver/plugin-cfg.xml

    profiles_ root: within the managed node

    $WP_PROFILE/config/cells/cell/nodes/node/servers/webserver/plugin-cfg.xml

    profiles_ root: within the Web server node

    $WP_PROFILE/config/cells/cell/nodes/node/servers/webserver/plugin-cfg.xml




     

    Related concepts

    Web server configuration

     

    Related tasks

    Install Web server plug-ins