Web server configuration

 

+

Search Tips   |   Advanced Search

 

Plug-in configuration involves...

• Configuring the Web server to use the binary plug-in module that WAS provides.
• Updating plugin-cfg.xml to reflect the current appserver configuration.

The binary module uses plugin-cfg.xml to route Web client requests.

The Plug-ins installation wizard installs the Web server plug-in. The wizard configures the Web server. The wizard also creates a Web server definition in the configuration of the appserver.

The Plug-ins installation wizard uses the following files to configure a plug-in...

Web server configuration file	On the Web server machine. Example: httpd.conf
Binary Web server plug-in file	Plug-ins installation Wizard installs on the Web server machine.
Plug-in configuration file.	plugin-cfg.xml. Copied from appserver machine to Web server machine.
Temporary plug-in configuration file	plugin-cfg.xml. On the Web server machine.
configureweb_server_name	Script copied from the Web server machine to the appserver machine.

 

Web server configuration file

The Web server configuration file is installed as part of the Web server.

The wizard must reconfigure the configuration file for a supported Web server. Configuration consists of adding directives that identify file locations of two files:

• The binary plug-in file
• The plugin-cfg.xml configuration file

 

The binary Web server plug-in file

An example of a binary plug-in module is mod_ibm_app_server_http.dll 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, plugin-cfg.xml. The appserver 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 appserver.

 

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

The plug-in configuration file is an XML file with settings that we can tune in the admin console. The file lists all of the applications installed on the Web server definition. The binary module reads the XML file to adjust settings and to route requests to the appserver.

The stand-alone appserver regenerates the plugin-cfg.xml file in...

$WP_PROFILE/config/cells/cell_name/nodes/web_server_name_node/servers/web_server_name

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

The dmgr regenerates the plugin-cfg.xml file in...

$WP_PROFILE/config/cells/cell_name/nodes/node_name/servers/web_server_name

...whenever a change occurs in appserver 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 the plugin-cfg.xml file after certain events that change the configuration. The configuration service automatically propagates the plugin-cfg.xml file to an IBM HTTP Server machine when the file is regenerated. You must manually copy the file on other Web servers.

 

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

The Plug-ins installation wizard creates the temporary plugin-cfg.xml file in...

PLUGINS_ROOT/config/web_server_name

The wizard creates the file for every remote installation scenario. The wizard creates the file at the same time that it installs the binary plug-in module for the Web server.

The default file is a placeholder that replace with the plugin-cfg.xml file from the Web server definition on the appserver. The default file is a replica of the file that the appserver creates for a default stand-alone appserver that has the samples installed.

Run...

cd APP_ROOT/bin
configureweb_server_name

...of the appserver machine for a remote installation, or directly from...

PLUGINS_ROOT/bin

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

After the Web server definition is created, the Web server plug-in configuration service within the appserver creates the first plugin-cfg.xml file in the Web server definition on the appserver 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 appserver machine to the Web server machine to replace the default file.

 

The configureweb_server_name script for the Web server definition

The Plug-ins installation wizard creates the configureweb_server_name script on the Web server machine in...

PLUGINS_ROOT/bin

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

PLUGINS_ROOT/bin/crossPlatformScripts

The script is created for remote installation scenarios only.

Copy the script from the Web server machine to...

APP_ROOT/bin

on a remote appserver machine. You 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 appserver.

When using the IHS, configure the IBM HTTP Administration Server also. The IBM HTTP Administration Server works with the admin console to manage Web server definitions.

Also, use the admin console to update the Web server definition with remote Web server management options. Go to...

Servers | Web servers | web_server_name

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

• Host name
• Administrative port
• User ID

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. However, if the WAS_USER_SCRIPT environment variable is set, 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...

$WP_PROFILE/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.

• Change directories to $WP_PROFILE/bin of the default profile and source the setupCmdLine.sh script:

  (Windows)

  cd APP_ROOT\bin
  setupCmdLine.bat

  Use the same command prompt window to start the update installer, as described in the appropriate procedure.

  [AIX] [HP-UX] [Linux] [Solaris]

  cd APP_ROOT/bin
  . ./setupCmdLine.sh

  Use the same command shell window to start the update installer, as described in the appropriate procedure.

If a Web server definition already exists for a stand-alone appserver, running the script does not add a new Web server definition. Each stand-alone appserver can have only one Web server definition.

We cannot use the admin console of a stand-alone appserver to add or delete a Web server definition. However, we can do both tasks using the admin scripting interface:

• Add a Web server definition through the wsadmin facility using the configureweb_server_name script.

  The script uses 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.

 

Replacing the default plug-in configuration file with the file from the Web server definition (propagation)

The default file uses fixed parameter values that might not match the parameter values in the actual file on the appserver. The default file is a placeholder only.

The file cannot reflect changes that occur in the appserver configuration.

The file also cannot reflect non-default values that might be in effect on the appserver.

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 appserver.

The following are fixed parameter values in the temporary plug-in configuration file.

• Virtual host name

  Default value: default_host

  This virtual host is configured to serve the DefaultApplication and the Sample applications. This value is probably the same as the value in the real plugin-cfg.xml file.

  However, suppose created 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 appserver machine to the Web server machine.

• HTTP transport port

  Default value: 9082

  The 9082 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 appserver machine. The HTTP transport port value must be unique for every appserver.

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

• Web server listening port

  Default value: 80

  The 80 value is the default value for the port that controls communication with the Web server. However, each appserver 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 value: 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 appserver machine. The HTTPS transport port value must be unique for every appserver.

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

• Applications installed on the server1 appserver

  All of the default servlets and applications are included in the default file, including the WSsamples application and the SamplesGallery application.

  The default file lists all of the default applications and samples. The list can be inaccurate. If we performed a custom installation and did not install the samples, for example, the list is inaccurate.

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

---

 

Related concepts

Plug-ins configuration

 

Related tasks

Edit Web server configuration files
Mapping modules to servers
Install Web server plug-ins

 

Related

Web server plug-in configuration service property