Using wsadmin to modify configuration variables

The backupConfig and restoreConfig commands for the WebSphere Application Server are pretty handy. The backupConfig command allows you to back up all of the configuration for a selected profile to an archive. The restoreConfig command allows you to restore (or import) the configuration from such an archive to a target profile. You can employ these commands for many purposes such as sharing a common configuration or steeling yourself against unexpected outages.

While working on a cool WebSphere CloudBurst project (that I hope to share soon enough), I was using these two commands to share configurations across two different installations and came across a situation I think is worth discussion.

In addition to having different cell, node, and host names across the installations (something you can overcome by using the commands I talked about here), the two installations existed at different file path locations on their respective disks. On the first machine the product and profile was located at:

/opt/IBM/WebSphere/AppServer

/opt/IBM/WebSphere/Profiles/DefaultAppSrv01

On the second machine the locations were:

/opt/WAS7.0/32bit

/opt/WAS7.0/32bit/profiles/AppSrv01

The backupConfig and restoreConfig commands work on an archive that basically contains all the contents under the config directory of a profile. Given that you may think it really shouldn’t matter what the WAS installation path and profile paths are, but there is a matter worth noting.

If you look in the config tree for a given WAS profile, you will notice that there are variables.xml files at various configuration scopes (cell, node, server, etc.). These files define variables and their associated values, and these variables are in turn used by various scripts in the profile. Obviously it is important for these values to be correct, and in my particular case after restoring the configuration from machine 1 to machine 2 two of the values were no longer correct.

The two variables with incorrect values were located in the node’s variables.xml file. The names of the variables were WAS_INSTALL_ROOT and USER_INSTALL_ROOT and represent the location of the WAS installation and WAS profile location. After restoring the configuration of machine 1 to machine 2, the values for these variables still reflected the paths on machine 1. Since these paths were different on machine 2, I had to update them. I could do it manually, but we all know an automated, scripted approach is better. With that in mind, I wrote a simple wsadmin script to get the job done:

from java.lang import System as jSys
nodeName = sys.argv[0]
newWASInstallRoot = sys.argv[1]
newUserInstallRoot = sys.argv[2]

lineSep = jSys.getProperty('line.separator')

node = AdminConfig.getid('/Node:' + nodeName + '/')
varSubstitutions = AdminConfig.list("VariableSubstitutionEntry",node).split(lineSep)

for varSubst in varSubstitutions:
getVarName = AdminConfig.showAttribute(varSubst, "symbolicName")
if getVarName == 'WAS_INSTALL_ROOT':
AdminConfig.modify(varSubst,[['value', newWASInstallRoot]])
elif getVarName == 'USER_INSTALL_ROOT':
AdminConfig.modify(varSubst,[['value', newUserInstallRoot]])
AdminConfig.save()

I know it’s a pretty simple use of wsadmin, but one that may be useful if you find yourself having to modify configuration variables for this reason or any other. Let me know if you have any questions or comments.