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.

Changing cell names, node names, host names

how to change cell names, node names, and host names for a given WebSphere Application Server environment. It usually starts by someone asking me what configuration files they need to change when they want to update this information, and is followed by their surprise when I tell them none. The reason I say that is because it’s time consuming, hard, and unnecessary for you to figure this out. Instead, you can use three simple wsadmin commands. I’ll give you an example of those here (all written in Jython).

To change the cell name for a given environment, use the following wsadmin command:

AdminTask.renameCell(‘[-newCellName -regenCerts ]‘)


This updates your configuration with the new cell name you specify and will optionally regenerate the certificates in that environment.

To change the name of a given node, use the following wsadmin command:

AdminTask.renameNode(‘[-nodeName -newNodeName ]‘)


This updates the name of the node specified by the nodeName parameter to the name specified by the newNodeName parameter.

To change the host name for a given node, use the following wsadmin command:

AdminTask.changeHostName(‘[-nodeName -hostName ]‘)


This updates the host name for the node specified in the nodeName parameter to the value specified in the hostName parameter.

These commands update all of the necessary WAS configuration, but do keep in mind they do not update any shell or batch files in the environment. This means you need to update the setupCmdLine script included in your WAS installation, and you obviously need to update any of your custom scripts that have hard coded values for cell, node, and host names.