Web server configuration

Plug-in configuration involves...

• Configuring the web server to use the binary plug-in module that WebSphere Application Server provides
• Updating the plug-in XML configuration file to reflect the current application server configuration

The binary module uses the XML file to help route web client requests.

First install a supported web server. Then install the Web Server Plug-ins for that web server using the Web Server Plug-ins Configuration Tool, which...

• Configures the web server
• Creates a web server definition in the configuration of the application server

The Tool uses the following files to configure a plug-in for the web server:

Description	File name example	Location
Web server configuration file	httpd.conf	Web server machine
Binary web server plug-in file	mod_was_ap22_http.dll	Web server machine
Plug-in configuration file	plugin-cfg.xml	Application server machine
Plug-in configuration file	plugin-cfg.xml	Web server machine (Propagated from the appserver machine)
Configuration shell script	configure_webserver	Application server machine (Copied from the web server machine)

Web server configuration file

The web server configuration file is installed as part of the web server. The tool re-configures the configuration file for a supported web server. Configuration consists of adding directives that identify file locations of the binary web server plug-in file and the plug-in configuration file.

Binary web server plug-in file

An example of a binary plug-in module is the mod_was_ap22_http.dll file for IBM HTTP Server on the Windows platform. The binary plug-in file does not change. However, the configuration file for the binary plug-in is an XML file. The application server changes the configuration file when certain changes to the WAS configuration occur. The binary module reads the XML file to adjust settings and to route requests to the application server.

Plug-in configuration file (plugin-cfg.xml)

The plug-in configuration file (plugin-cfg.xml) contains settings and applications in the web server definition. The binary module reads the XML file to adjust settings and route requests to the application server. Regeneration occurs whenever a change occurs in the application server configuration that affects deployed applications.

On the application server machine, after generation, the file can be found in...

profile_root/config/cells/cell/nodes/node/servers/web_server/plugin-cfg.xml

On the deployment manager the regenerated file can be found in...

profile_root/config/cells/cell/nodes/node/servers/web_server/plugin-cfg.xml

The Dmgr version represents a topology-centric file, which is deprecated.

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

After regeneration, propagate (copy) the file to the web server machine. The binary plug-in then has access to the most current copy of its configuration file. The web server plug-in configuration service automatically regenerates plugin-cfg.xml after certain events that change the configuration. The configuration service automatically propagates plugin-cfg.xml to an IBM HTTP Server machine when the file is regenerated. We must manually copy the file on other web servers.

Default plug-in configuration file, plugin-cfg.xml

The Web Server Plug-ins Configuration Tool creates the temporary plugin-cfg.xml file in...

plugins_root/config/web_server

The tool creates the file for every remote installation scenario.

The default file is a placeholder replaced with plugin-cfg.xml from the web server definition on the application server. The default file is a replica of the file that the application server creates for a default standalone application server.

Run the web_server script from...

app_server_root/bin

...of the application server machine for a remote installation or directly from...

plugins_root/bin

...for a local installation. The web_server script creates the web server definition in the configuration files of the default profile. To configure a different profile than the default, edit the web_server script. Use the -profileName parameter to identify a profile other than the default profile.

After the web server definition is created, the web server plug-in configuration service within the application server creates the first plugin-cfg.xml file in the web server definition on the application server machine. If we install an application, create a virtual host, or do anything that changes the configuration, propagate the updated plugin-cfg.xml file from the application server machine to the web server machine to replace the default file.

configureweb_server script for the web server definition

The Web Server Plug-ins Configuration Tool creates the web_server script on the web server machine in the plugins_root/bin directory. If one machine in a remote scenario is running under an operating system like AIX or Linux and the other machine is running under Windows, use the script created in the plugins_root/bin/crossPlatformScripts directory. The script is created for remote installation scenarios only.

Copy the script from the web server machine to app_server_root/bin on a remote application server machine. We do not have to copy the script on a local installation. Run the script to create a web server definition in the configuration of the application server.

When using the IBM HTTP Server, configure the IBM HTTP Server Administration server also. The IBM HTTP Administration Server works with the administrative console to manage web server definitions. Also, use the administrative console to update our web server definition with remote web server management options. Click...

Servers > Server Types > Web servers > web_server

...to see configuration options. For example, click Remote Web server management to change such properties as:

• Host name
• Administrative port
• User ID
• Password

Important: Always open a new command window before running this script. We can avoid a potential problem by doing so.

The problem is a potential conflict between a shell environment variable, the WAS_USER_SCRIPT environment variable, and the actual default profile. The script always works against the default profile. If the WAS_USER_SCRIPT environment variable is set, however, a conflict arises as the script attempts to work on the profile identified by the variable.

The variable is easy to set accidentally. Issue any command from the profile_root/bin directory of any profile and the variable is set to that profile.

If we have more than one profile on the system, the potential exists that the default profile and the profile identified by the variable are different profiles. If so, a conflict occurs and the script might not create the web server definition in the correct profile, or might not create the web server definition at all.

Reset the variable in either of two ways:

• Close the command window where the variable is set and open a new one.

• Run...
  cd profile_root/bin
  . ./setupCmdLine

  Notice the space between the periods. The special format for this command sources the command to make the setting active for all processes started from the command shell.

If a web server definition already exists for a standalone application server, running the script does not add a new web server definition. Each standalone application server can have only one web server definition.

We cannot use the administrative console of a standalone application server to add or delete a Web server definition. However, we can do both tasks using the administrative scripting interface:

• Add a web server definition through the wsadmin facility using the web_server script. The script uses a Java Command Language (Jacl) script named configureWebserverDefintion.jacl to create and configure the web server definition.

• Delete a web server definition using wsadmin commands. The Web server is named webserver1 in the following example:
  set webserverName webserver1
  set webserverNodeSuffix _node
  set webserverNodeName $webserverName$webserverNodeSuffix
  $AdminConfig remove [$AdminConfig getid /Node:$webserverNodeName/Server:$webserverName]
  $AdminConfig remove [$AdminConfig getid /Node:$webserverNodeName]
  $AdminConfig save

A managed node, on the other hand, can have multiple web server definitions. The script creates a new Web server definition unless the web server name is the same.

Replace the default plugin-cfg.xml with the file from the web server definition (propagation)

The application server must have the following values in the actual plugin-cfg.xml file. If so, the default file can successfully configure the binary plug-in module. Then, the plug-in module can successfully communicate with the web server and the application server. Suppose that the application server does not have the following values in the actual plugin-cfg.xml file. In that case, the default file configures the binary plug-in module incorrectly. The plug-in module can always communicate with the web server. But with an improper configuration file, the plug-in module cannot communicate successfully with the application server.

Fixed parameter values in the temporary plugin-cfg.xml.

• Virtual host name

  Default: default_host

  This virtual host is configured to serve the DefaultApplication. This value is probably the same as the value in the real plugin-cfg.xml file. However, suppose that we create another virtual host for serving applications and install the DefaultApplication on it. If so, the actual plugin-cfg.xml file is regenerated. The web server cannot access the DefaultApplication. (The application includes the snoop servlet and the hitcount servlet.)

  To access applications on the new virtual host, propagate the real plugin-cfg.xml file. Propagation is copying the updated file from the application server machine to the web server machine.

• HTTP transport port

  Default: 9080

  The 9080 value is the default value for the HTTP transport port for the default_host virtual host. This value is probably the same as the value in the updated file. However, this value changes for every profile on the application server machine. The HTTP transport port value must be unique for every application server.

  To communicate over a different port, propagate the real plugin-cfg.xml file.

• Web server listening port

  Default: 80

  The 80 value is the default value for the port that controls communication with the web server. However, each application server profile must have a unique port value to communicate to a web server. The actual port value might be 81 or another number.

  To communicate over a different port, propagate the real plugin-cfg.xml file.

• HTTPS transport port

  Default: 9443

  The 9443 value is the default value for the HTTPS (secure) transport port for the default_host virtual host. This value is probably the same as the value in the updated file. However, this value changes for every profile on the application server machine. The HTTPS transport port value must be unique for every application server.

  To communicate over a different secure port, propagate the real plugin-cfg.xml file.

• Applications installed on the server1 application server

  All of the default servlets and applications are included in the default file.

  To serve an application that you developed with the web server, propagate the real plugin-cfg.xml file.

Related

Web Server Plug-ins Configuration Tool (PCT)

Configure web server plug-ins

Editing web server configuration files

Web server plug-in configuration service property

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