Web server configuration

 

+

Search Tips   |   Advanced Search

 

Overview

After installing a supported Web server, install a binary plug-in module for the Web server, which allows the Web server to communicate with the application server.

Use the plug-ins installation wizard to...

  • Install the Web Server plug-in
  • Configure the Web server to use the plug-in
  • Creates a Web server definition in the configuration of the application server.

If you are downloading install images from PartnerWorld, the WAS ND distro C5886ML contains the installation wizard.

We can launch the wizard from the launchpad or change directories to the plugin directory on the Web server product disc or in the downloaded installation image of the Web server and issue the "install" command.

The Plug-ins installation wizard uses five files to configure a plug-in for the Web server you select:

  1. Web server configuration file (httpd.conf)
  2. Binary Web server plug-in file
  3. Plug-in configuration file
  4. Temporary plug-in configuration file
  5. The configureWeb_server.sh script

 

The binary Web server plug-in file

An example of a binary plug-in module is the mod_ibm_app_server_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 whenever you change the configuration of deployed applications.

The binary module reads the XML file to adjust settings and to locate deployed applications for the Web server.

 

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

The plug-in configuration file is an XML file with settings that one can tune in the administrative 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 locate applications for the Web server.

The stand-alone application server regenerates the plugin-cfg.xml file in the directory...

install_root/profiles/profile/config/cells/cell/nodes/Web_server_node/servers/Web_server

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

The deployment manager regenerates the plugin-cfg.xml file in the directory...

install_root/profiles/profile/config/cells/cell/nodes/node/servers/Web_server

...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 V6 Web server plug-in configuration service automatically regenerates the plugin-cfg.xml file whenever the configuration changes. The configuration service automatically propagates the plugin-cfg.xml file to an IBM HTTP Server machine. You must manually copy the file on other Web servers.

See Web server plug-in configuration service properties settings for more information.

 

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

The Plug-ins installation wizard creates the temporary plugin-cfg.xml file in the plugins_install_root/Plugins/config/Web_server directory. 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 application server. The default file is a replica of the file that the application server creates for a default stand-alone application server that has the samples installed.

Run the configureWeb_server script from the was_install_root/bin directory of the application server machine for a remote installation, or directly from the plugins_install_root/bin directory 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 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 application server creates the first plugin-cfg.xml file in the Web server definition on the application server machine. If you 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.

 

The configureWeb_server script

The Plug-ins installation wizard creates the configureWeb_server script on the Web server machine in the plugins_install_root/bin directory. If one machine in a remote scenario is running under Linux or UNIX and the other machine is running under Windows, use the script created in the install_root/Plugins/bin/crossPlatformScripts directory. The script is created for remote installation scenarios only.

Copy the script from the Web server machine to the was_install_root/bin directory on a remote application server 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 application server.

When using the IBM HTTP Server, configure the IBM HTTP 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 your Web server definition with remote Web server management options. Click Servers > 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 using a new command window to run this script.

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

profiles_install_root/profile/bin

...of any profile and the variable is set to that profile.

If you have more than one profile on your 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 the profiles_install_root/profile/bin directory of the default profile and source the setupCmdLine.sh script:

    • source install_root/bin/setupCmdLine.sh

    • . install_root/bin/setupCmdLine.sh (Source the command with a space between the period and the installation root directory.)

    • install_root\bin\setupCmdLine.bat

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

You cannot use the administrative console of a stand-alone application server to add or delete a Web server definition. However, one can do both tasks using the administrative scripting interface:

  • Add a Web server definition through the wsadmin facility using the configureWeb_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.

 

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

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

The file cannot reflect changes that occur in the application server configuration. The file also cannot reflect non-default values that might be in effect on the application server.

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 plug-in configuration file

Virtual host name

default_host

The default_host value is the default virtual 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 that you 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

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

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

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

 

See Also

Configuration behavior of the Plug-ins installation wizard

 

Related Tasks

Edit Web server configuration files
Map modules to servers

 

See Also


 


 

 

IBM is a trademark of the IBM Corporation in the United States, other countries, or both.