How to migrate Weblogic's config.xml to multiple machines?

Question

our development team develops a J2EE application that runs on Weblogic 10.3. Each development machine runs its own copy of Weblogic 10.3 application server. The development environment's Weblogic domain was initially created on one machine and then copied onto all the machines using Weblogic's configuration tool (bea10/wlserver_10.3/common/bin/config.cmd).

Each development machine has its own copy of config.xml. All the passphrases (those for JDBC datasources etc.) in this file are encrypted and the encryption apparently uses a different seed on each machine since the same password has different encrypted forms on different machines.

The problem is that every once in a while config.xml needs to updated (for example when a new EJB is added) and the updates need to be applied on all the machines. How should we go about doing this? If we just put the file in CVS and update the other machines from there the encrypted passwords on each machine would get overwritten. This results in ugly paddingexceptions when the server tries to decrypt the passphrases originally encrypted on another machine.

Is there an ant task (I couldn't find one) or a similar mechanism that would take care of correctly merging the changes in config.xml without overwriting the encrypted passwords? Or is it possible to somehow specify the passphrases in plaintext and encrypt them on the first start (I have a faint recollection that this was possible in previous versions but not in 10.3).

How do development teams working on Weblogic handle this?

BR,

Marko

Sill

Answer 1

[...] Each development machine has its own copy of config.xml. All the passphrases (those for JDBC datasources etc.) in this file are encrypted ...

Yes, WebLogic Server encrypts all the plain text passwords stored in its domain configuration XML file(s). This is to prevent access to sensitive information. When passwords are entered using administration console or scripting tools, it will automatically get encrypted before they are stored in the configuration XML files(s).

... and the encryption apparently uses a different seed on each machine since the same password has different encrypted forms on different machines.

About the the encrypt utility (from the Oracle WebLogic Server Java Utilities), the documentation says:

The weblogic.security.Encrypt encrypts cleartext strings for use with WebLogic Server. The utility uses the encryption service of the current directory, or the encryption service for a specified WebLogic Server domain root directory.

Note: An encrypted string must have been encrypted by the encryption service in the WebLogic Server domain where it will be used. If not, the server will not be able to decrypt the string.

This is not mentioned in the documentation but, AFAIK, Weblogic uses the domain's password salt file (SerializedSystemIni.dat) for encrypting the clear text string.

[...] If we just put the file in CVS and update the other machines from there the encrypted passwords on each machine would get overwritten.

You could choose to use clear text passwords in the config.xml stored in your VCS (if this is not an issue). Actually, prior to WebLogic Server 9.0, the passwords would get encrypted during the subsequent restart. Starting from WebLogic Server 9.0, using clear text passwords in the configuration files is "fully" supported only for Development domain and Weblogic will not re-encrypt the passwords. In both case, this would allow people to check out the config file without troubles.

Is there an ant task (I couldn't find one) or a similar mechanism that would take care of correctly merging the changes in config.xml without overwriting the encrypted passwords?...

I'm not sure this answers directly your question but Oracle WebLogic Server provides Ant tasks for most of (if not all) its Java Utilities. Maybe you'll find something useful there (check out Configuring a WebLogic Server Domain Using the wlconfig Ant Task)

Or is it possible to somehow specify the passphrases in plaintext and encrypt them on the first start (I have a faint recollection that this was possible in previous versions but not in 10.3).

As I wrote above, this was the "default" behavior prior to Weblogic Server 9.0. I don't know if you can force this behavior for later versions. Of course, you could always use ant and encrypt to do it but, honestly, if you allow people to see clear text passwords once, I don't really see the point of encrypting them after the facts.

Histrionics

Hi Pascal, thanks a lot for your thoughtful reply! Storing plaintext passwords is ok in the development environment, so I think this is the way to go. However, I could not find the proper way to store these in config.xml. Element <credential-encrypted> is allowed, but I could not find its plaintext alternative in the dtd (oracle.com/technology/weblogic/920/domain.xsd). What am I missing here? An alternative (rather hacky) approach would be to use the same SerializedSystemIni.dat on every development server. Would this allow to use the same encrypted credentials on all PCs? – Sill

Did you try to put the clear text password in <credential-encrypted>? There is no other option IMO. Regarding the alternative, i.e. using the same SerializedSystemIni.dat, I was not sure and this would require some testing. That's why I didn't mention it. – Histrionics

Hi, putting plaintext passwords into <credential-encrypted> actually worked. Also copying SerializedSystemIni.dat onto different domains seems to work, so there's now alternatives. Thank you again. – Sill

Answer 2

I would use something like mercurial or git, and use the export/import functionality, so that the changes are moved in diffs, not in complete files.

Short instructions

Well, if you are stuck with CVS (I'm sorry, I share your pain to some extent), you might consider creating a CVS repo of diffs. E.g. when a new version of the config file is made, the new file is diffed to the old file and the diff file is added to the repo, other hosts checkout from cvs and patch the config file.

It's a hack, but should work.

Tsan

Were quite stuck with CVS (company policy), but thanks anyway. – Sill

Answer 3

Personally I'd look into WLST to do mass domain updates. It's really simple even if you have no experience with python or WLST

1. turn on recording for a domain (admin web interface)
2. do your changes on one domain (admin web interface)
3. activate changes (admin web interface)
4. you should get a python script in your default domain folder
5. for each environment
   1. connect to the admin server with WLST
   2. apply your script
   3. restart domain or managed servers if required

Currently the company I work for does a similar thing to what you describe - hack around with weblogic domain files and then deploy the same files with small tweaks to all our environments. Over the years we've ended up with an absolute mess. It's just not the way to go.

Nmr

Answer 4

We did it using WLST. We use some kind of simple declarative "domain model" in python which is rather abstract (i.e. it doesn't specify the configuration of different servers in a cluster, in our environments all the nodes must be identical). This model is quite short (2-3 pages for biggest applications that have 30+ connection pools, a bunch of JMS stuff and some foreign JMS providers). After that, we have 2 scripts: first creates an empty domain in the target enviornment, the 2nd applies the domain model. To collect the changes that developers do in the "master" environment we have a script that goes through the domain configuration and outputs the model file. Using a diff on those model files we can see what has been changes.

This looks like a heavyweight framework, but it really saves a lot of time when we have to manage development, testing, staging and production environments for 100+ applications.

For smaller cases just copying the files and using the same SerializedSystemIni.dat should do. Just make sure that your domain name stays the same, adjust the addresses/ports. If you want to use different SerializedSystemInit.dat, it is rather easy to do that as well, based on this code (http://gustlik.wordpress.com/2008/08/06/decryption-of-configuration-passwords-in-weblogic/) it's quite easy to write a utility that will decode the password with original SerializedSystemIni.dat and encode with a new one. This should do the trick.

Alexi