Install plug-ins to specific locationsSometimes, you might want to install the WAS plug-ins for Web servers to locations other than their default locations.
Install Web server plug-ins to non-default locations
Depending on the operating system, when you run the WAS installation program and select to install a Web server plug-in, the plug-in might install silently if the Web server is installed in a standard location for that Web server brand. In such a case, the WAS installation program does not prompt you for the configuration file location.
If you have installed two Web servers of the same brand, on the same machine, the plug-in operates properly for the server installed at the standard location, but the plug-in does not operate properly for the server that is in the non-standard location.
For example, suppose IBM HTTP Server "installation 1" is installed in the standard directory in which the Web server is installed on Solaris, /opt/IBMHTTPD. When the plug-in for this first Web server is installed, it silently modifies the httpd.conf file in /opt/IBMHTTPD/conf, which is appropriate.
But now suppose that you installed IBM HTTP Server "installation 2" in /opt/IHS2. When the Web server plug-in for this second Web server is installed, it too is installed in httpd.conf in /opt/IBMHTTPD/conf.
One way around this is to manually edit the httpd.conf file of the second IBM HTTP Server installation, rather than installing the plug-in. You could copy the modified configuration file from the first Web server and make it the configuration file of the second server. Of course, this approach assumes that you have not customized the configuration file of the second server, and find it acceptable for its configuration to match that of the first server.
Another way is to install both Web servers in some non-standard place, such as /opt/IHS1 and /opt/IHS2. When the WAS installation program cannot find either httpd.conf file, you are prompted for the one to edit. Specify the location of one of the Web server files. Then repeat the plug-in installation, specifying the other location this time.
Install WAS plug-ins on non-default IIS servers
When the product installs the WAS plug-in for Microsoft Internet Information Server (IIS), it assumes the user wants to attach the plug-in to the default IIS server. The following instructions explain how to attach the plug-in to an IIS server other than the default.
The procedure might be necessary for a user implementing multiple Web sites that separate the pages they serve along some logical boundary, such as security level. Follow the steps to allow a newly defined site (using an IIS instance other than the default) to exercise servlets in conjunction with an existing site or sites.
The instructions apply to IIS Versions 4.x and 5.x.
- Use the Internet Service Manager (from Microsoft IIS) to create a new site with a name, port number, and base subdirectory.
- Go to the WAS administrative console and configure the virtual host to contain an alias for the port number used by the site.
- Create a virtual directory for the new site.
- Open the Internet Service Manager for IIS.
- Select the new site in the tree view.
- Right-click to display a menu. Select New > Virtual Directory.
- Ensure that the values are set appropriately...
- The name of the virtual directory should be set to SEPLUGINS (using all capital letters).
- The physical path should be set to the WAS bin directory (such as c:\WebSphere\AppServer\bin on Windows NT).
Note, the directory must have the EXECUTE permission set, but setting any other permissions (or allowing it to inherit other permissions) is a security risk.
- Start the new site.
- Issue a browser request to verify that the configuration works, such ashttp://mymachine:8080/servlet/snoop for WAS V4 or http://mymachine:8080/snoop for WAS V5
- The administrator must ensure that the SEPLUGINS retains its EXECUTE permission.It is possible for virtual directories under a site to inherit properties from the site. Ensure that the SEPLUGINS virtual directory does not inherit permissions from changes to the site, if those changes involve withdrawing the EXECUTE permission.
See AlsoConfiguring Web server plug-ins
Configuring virtual hosts