![[AIX Solaris HP-UX Linux Windows]](../images/dist.gif)
![[IBM i]](../images/iseries.gif)
Plug-ins configuration
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 three 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.

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.

Configuration flows for the Network Deployment product
The Web Server Plug-ins Configuration Tool resolves all configurations of a web server and WebSphere Application Server to three scenarios: a remote application server, local distributed application server, and local standalone application server. The logic implemented in determining which scenario applies to a configuration is shown in the following diagram.

- 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.
- If the product is installed but the Profile Management Tool has not yet created a profile, the scenario is considered to be a remote installation.
- If the profile is an application server with an existing web server definition, the installation is considered a remote installation.
- The Web Server Plug-ins Configuration Tool can configure only one profile at a time. These three paths show how processing varies for different types of profiles.
- If the application server node is federated, the Web Server Plug-ins Configuration Tool configures the web server definition on the managed node. This has advantages. 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 the deployment manager has a federated custom node (custom profile), the Web Server Plug-ins Configuration Tool configures the web server definition on the managed node. This has advantages. 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.
The Web Server Plug-ins Configuration Tool creates a web server definition within the application server profile.
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 standalone application server regenerates the profile_root/config/cells/cell_name/nodes/web_server_name_node/servers/web_server_name/plugin-cfg.xml file whenever a change occurs in the application server configuration that affects deployed applications.
After installing the binary plug-in for the local web server, you can start the application server and the web server immediately upon completion of the installation.
Profile type | Federation status | Automatic creation of web server definition? | Web server already defined in application server configuration? |
---|---|---|---|
Application server | Not federated | Yes | No |
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 Web Server Plug-ins Configuration Tool 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.
The following overview shows the procedure for verifying the web server configuration:
The Web Server Plug-ins Configuration Tool does not automatically create a web server definition within a federated application server profile. The tool creates the configureweb_server_name script instead in the plugins_root/bin directory.
The Web Server Plug-ins Configuration Tool configures the web server to use the plugin-cfg.xml file that will be created within the application server profile when you run the script. The deployment manager regenerates the plugin-cfg.xml file in the profile_root/config/cells/cell_name/nodes/node_name/servers/web_server_name directory. Regeneration occurs whenever a change occurs in the application server configuration that affects deployed applications on the managed node.
Profile type | Federation status | Creation of web server definition? | Web server already defined in application server configuration? |
---|---|---|---|
Application server profile | Federated | By script | N/A |
Custom profile | Not federated | By script | N/A |
Custom profile | Federated | By script | N/A |
Deployment manager profile with a managed node (distributed profile) | N/A | By script | N/A |
The following overview shows the procedure for completing the configuration and verifying the web server configuration:
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 will be 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.
Profile type | Federation status | 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 | N/A | By script | N/A |
No profile | N/A | By script | N/A |
Unfederated standalone application server profile with an existing web server definition | Not federated | By script | Yes |
Deployment manager profile with no managed nodes | N/A | By script | N/A |
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 complete your test of the configuration.
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 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 application server machine, you 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 this article.
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 WebSphere Application Server 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 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.
Scenario | Profile type | Location of the plugin-cfg.xml file | ||
---|---|---|---|---|
plugins_root | profile_root: within the managed node | profile_root: within the web server node | ||
1 | Application server profile | X | ||
2 | Application server profile | X | ||
Custom profile | X | |||
Deployment manager profile with a managed node (distributed profile) | X | |||
3 | Any profile anywhere if you select a remote installation type in the Web Server Plug-ins Configuration Tool | X | ||
No profile | X | |||
Unfederated (standalone) application server profile with an existing web server definition | X | |||
Deployment manager profile with no managed nodes | X |
- plugins_root
/config/web_server_name/plugin-cfg.xml
profile_root/config/cells/cell_name/nodes/node_name_of_AppServer/servers/web_server_name/plugin-cfg.xml
profile_root/config/cells/cell_name/nodes/web_server_name_node/servers/web_server_name/plugin-cfg.xml