Regenerate the plugin configuration for a federated node

Regenerate the plugin configuration for a federated node

Overview

The plugin-cfg.xml file is used by WebSphere-enabled Web servers to ensure that the correct set of requests are forwarded to the WAS runtime. The contents of the plugin-cfg.xml file reflect the WebSphere configuration, and as a result needs to be regenerated as the configuration changes. If the plugin-cfg.xml file becomes inconsistent relative to the WebSphere configuration, URL requests may be improperly routed, causing incorrect responses to be returned to clients (browsers).
In a Network Deployment environment, there is increased complexity in maintaining consistent plugin-cfg.xml files acrossed all federated nodes and the respective Web servers serving requests for those nodes. At issue is the need to synchronize any updates made to the WebSphere configuration so that the plugin-cfg.xml files, used by the various Web servers, reflect those updates. This synchronization is referred to as plugin regeneration and the various Network Deployment specific actions (referred to as ND actions, below) which disseminate the updated plugin-cfg.xml file to the federated WebSphere nodes.
By default the plugin-cfg.xml file is found at this location:
/QIBM/UserData/WebAS5/edition/instance/config/cells

...where edition is either Base (for each federated node) or ND (for the ND instance itself); and instance is the name of the Base or ND instance.
Web server configurations for the WebSphere plugin are by default configured to point to its plugin-cfg.xml file using edition = Base for its path. This point is important to note in an ND environment, because plugin regeneration via the ND administrative console only updates the plugin-cfg.xml file using edition = ND, whose path is not pointed to by any external Web servers. The plugin-cfg.xml file regenerated into the ND path is often unuseable as-is, instead it is typically used as a basis from which customizations can be made.
On iSeries when addNode is used to federate a Node into the ND instance, the plugin-cfg.xml file is implicitly regenerated and placed into the Base instance's path. This ensures the plugin-cfg.xml file is immediately in synch with the WebSphere configuration. However, there are several ND actions which have an undesirable side effect of replacing the Base instance plugin-cfg.xml file with that from the ND path. Such ND actions include:

startNode (Base level script)
startManager (ND level script)
full Resynchronize (Node function at the ND administrative console)

The following are important considerations for formulating the synchronization strategy for the plugin configuration file:

Starting with WebSphere V5.0.1 on iSeries during addNode, "*/plugin-cfg.xml" is automatically added to a file synchronization exclusion list for the federated Base instance's Node Agent. This avoids the undesirable side effect of the various ND actions described previously. If instead, you wish to allow the plugin-cfg.xml file to be replaced during the ND actions, you can remove "*/plugin-cfg.xml" from the exclusion list by accessing the admin console:
System Administration | Node Agent | Specific Node Agent | File Synchronization Service | Exclusions

With this file in the exclusion list the plugin configuration file will not be copied to the Base instance, so run the GenPluginCfg script against the Base instance when you require regeneration of the plugin file.
If instead you prefer to have the ND version of the plugin-cfg.xml file disseminate across the federated nodes when executing the aforementioned actions, need to remove "*/plugin-cfg.xml" from the File Synchronization Service's exclusion list.

If you had federated the node prior to installing WebSphere V5.0.1, the plugin-cfg.xml file will not be present in the Node Agent's exclusion list (see previous list item). You may want to consider adding "*/plugin-cfg.xml" to the Node Agent's exclusion list, using similar directions described above by adding "*/plugin-cfg.xml" (without the quotes) to the exclusion list. With this file in the exclusion list, likewise run the GenPluginCfg script against the Base instance when you require regeneration of the plugin file.

In summary, the suggested approach of synchronizing the contents of the plugin-cfg.xml file within a Network Deployment environment is to run the GenPluginCfg script against the Base instance for the federated nodes.