Depending on your edition of WebSphere (Base, ND, or EE) the regeneration
process updates different plugin-cfg.xml files.
In a Base environment, the plugin-cfg.xml that is updated
is:
$WAS_HOME_BASE/config/cells/plugin-cfg.xml
In a Cell environment (Deployment Manager with one or more Base
nodes) the plugin-cfg.xml that is updated is:
$WAS_HOME_NDconfig/cells/plugin-cfg.xml
The "Update Web Server plug-in" will ONLY update plugin-cfg.xml
in the ND Machine in a cell environment. The plugin-cfg.xml files located
on the Base nodes are not updated. To update them, a synchronize operation
from the ND node is needed to push the updated data to all the Base nodes
in the Cell.
This example has Base on
Solaris™ and ND on Windows 2000:
Machine1:
Base installation on a Sun Machine
WebSphere Base install root is opt\WebSphere\AppServer
Here, the plugin-cfg.xml is located at
opt\WebSphere\AppServer\config\cells\plugin-cfg.xml
Originally this plugin-cfg.xml has the following information for the log,
keyring, and stash files:
<LogLogLevel="Error"Name="opt\WebSphere\AppServer\logs\http_plugin.log"/>
<Property name="keyring"
value="opt\WebSphere\AppServer\etc\plugin-key.kdb"/>
<Property name="stashfile"
value="opt\WebSphere\AppServer\etc\plugin-key.sth"/>
Machine1 also has IBM HTTP Server installed at opt\IBMHTTPServer
The httpd.conf file location is opt\IBMHTTPServer\conf\httpd.conf
This httpd.conf file has following information for plug-in
LoadModule
ibm_app_server_http_module"opt\WebSphere\AppServer/bin/mod_ibm_app_server_http.dll"
WebSpherePluginConfig
"opt\WebSphere\AppServer/config/cells/plugin-cfg.xml"
Machine2: ND installation on a Windows Machine
WebSphere ND install root is C:\WebSphere\DeploymentManager
Scenario:
The following steps are taken:
a. "addNode" from Base node (Machine 1)
b. re-generate plug-in
c. stop and start nodeagent on the Base node (Machine 1)
On Machine 1, we see the original plugin-cfg.xml file
(opt\WebSphere\AppServer\config\cells\plugin-cfg.xml) has been modified
and now reflects the following (note that the directories are all Windows
based, not UNIX based):
<Log LogLevel="Error"
Name="C:\WebSphere\DeploymentManager\logs\http_plugin.log"/>
<Property name="keyring"
value="C:\WebSphere\DeploymentManager\etc\plugin-key.kdb"/>
<Property name="stashfile"
value="C:\WebSphere\DeploymentManager\etc\plugin-key.sth"/>
This is not correct, but is currently working as designed. The
keyring and
stashfile files are located only on the Base
node and do not exist on the ND node. However, during the synchronization
operation the data pushed from the ND machines overrides their locations.
The Web server fails unless the file is manually updated to the original
directory paths. There are three ways to workaround this issue.
The synchronization process updates more than just the log, keyring and
stashfile entries. If you make a copy of the plugin-cfg.xml file,run
synchronization, then copy the original file back, you will not have any
of the required updates to the rest of the plugin-cfg.xml file.
Workaround 1:
From Machine 1 (Base and HTTP server) complete the following four steps.
1.
Make a backup copy of the plugin-cfg.xml:
copy
opt\WebSphere\AppServer\config\cells\plugin-cfg.xml
to
opt\<MyDirForPlugIn>\plugin-cfg.xml
Note: The MyDirForPlugIn must be located outside of the
\WebSphere\ directory path, such as
opt\MyDirForPlugIn\plugin-cfg.xml
2.
Edit the copied version of the plugin-cfg.xml file to reflect the
following changes:
post sync plugin-cfg.xml file
<Log LogLevel="Error"
Name="C:\WebSphere\DeploymentManager\logs\http_plugin.log"/>
<Property name="keyring"
value="C:\WebSphere\DeploymentManager\etc\plugin-key.kdb"/>
<Property name="stashfile"
value="C:\WebSphere\DeploymentManager\etc\plugin-key.sth"/>
edit to reflect the following lines
<Log LogLevel="Error"
Name="opt\WebSphere\AppServer\logs\http_plugin.log"/>
<Property name="keyring"
value="opt\WebSphere\AppServer\etc\plugin-key.kdb"/>
<Property name="stashfile"
value="opt\WebSphere\AppServer\etc\plugin-key.sth"/>
3.
Edit following in the HTTP server's httpd.conf, which is located at
the Web Server Home\conf directory, to reflect the
new location of the plugin-cfg.xml file.
from:
WebSpherePluginConfig
"opt\WebSphere\AppServer/config/cells/plugin-cfg.xml"
change to
WebSpherePluginConfig "opt\<MyDirForPlugIn>\plugin-cfg.xml"
4.
Re-Start HTTP server to load plugin-cfg.xml from new location
For any changes made to the WebSphere
configuration (addNode, installing a new application, creating new server
or virtual host, and so forth) you must copy and manually edit the
opt\MyDirForPlugIn\plugin-cfg.xml file.
Workaround 2:
From Machine 2 (ND) complete the following two steps.
1.
From $WAS_HOME_ND/config/cells directory edit the
plugin-cfg.xml file to point to the correct directory structure for the
log, keyring and stashfile locations.
from:
<Log LogLevel="Error"
Name="C:\WebSphere\DeploymentManager\logs\http_plugin.log"/>
<Property name="keyring"
value="C:\WebSphere\DeploymentManager\etc\plugin-key.kdb"/>
<Property name="stashfile"
value="C:\WebSphere\DeploymentManager\etc\plugin-key.sth"/>
edit to reflect the following lines
<Log LogLevel="Error"
Name="opt\WebSphere\AppServer\logs\http_plugin.log"/>
<Property name="keyring"
value="opt\WebSphere\AppServer\etc\plugin-key.kdb"/>
<Property name="stashfile"
value="opt\WebSphere\AppServer\etc\plugin-key.sth"/>
2.
Do a full sync (see the "How do I perform a manual
synchronization?" section above)
This modified "plugin-cfg.xml" from Machine
1 (ND) is replicated to Machine 2 (Base and HTTP server).
1. Do not delete the modified plugin-cfg.xml from Machine 1 because on
the next regeneration it creates a new plugin-cfg.xml file that does not
contain the location of the log, keyring, and stashfile locations. If you
delete the plugin-cfg.xml file from Machine 1, you must perform Workaround
2 again.
2. If you are running 5.0 without any fix packs and you do a manual edit
to the plugin-cfg.xml file on Machine 1, it updates Machine 2; however,
the manual changes made to Machine 1 are not retained. PQ72596 enables you
to do manual changes of the plugin-cfg.xml file that are retained. This
fix has been incorporated in 5.0.1 and higher.
Workaround 3:
From node 2 (ND), complete the following. If you have more than one Base
node in your cell and the nodes are different operating systems and/or if
the installation directories are different, you cannot use this
workaround. You can specify only one destination root.
Generate plug-in: From the command line,
issue:
$WAS_HOME_ND\bin> GenpluginCfg.bat/sh -destination.root
This changes all the directories in Machine 1 plugin-cfg.xml file to this
specified directory.
Example:
GenpluginCfg -destination.root opt\WebSphere\AppServer
Note: opt\WebSphere\AppServer is
located on Machine 1.
Starting in V5.0 releases, the configurable
auto regeneration function is no longer available. This is a function that
was deprecated in V3.5 and V4.0.