In one of my projects we have to be able to set up a (cold) backup Oracle Service Bus domain in a different data center from a domain backup. One of the requirements was that this data center is -for security reasons- completely independent of the “main” data center. In this particular case, just syncing the middleware home and domain directories wasn’t an option.
Fair enough, and not that difficult at all. Setting up this cold backup domain is just using the pack & unpack tools from WebLogic, and “cloning” your domain. Keeping you cold backup domain up to date can be done by just syncing the configuration backups the “main” domain can automatically create for you:
<YOUR DOMAIN> -> Configuration -> General -> Advanced.
Config Archive in WebLogic
With this option enabled, every time an configuration change is activated in your domain, the complete config directory is JAR’ed, and stored in DOMAIN_HOME/configArchive. Getting the latest configuration state in your cold backup domain is just deleting the contents of the config directory and “un-tar” the config backup jar from your main domain in the config directory.
However, if you have set up your cold backup domain using pack and unpack, WebLogic’s “salt” and security configuration such as DefaultAuthenticatorInit.ldif and XACMLRoleMapperInit.ldif are automatically generated. This makes your config archives from your main domain incompatible with your backup domain. Not only isn’t WebLogic able to decrypt the encrypted passwords from the config.xml, the deployed applications in your domain aren’t allowed to run. Although your weblogic-user’s password is set up correctly, nice error messages such as
<Critical> <WebLogicServer> <BEA-000386> <Server subsystem failed. Reason: weblogic.security.SecurityInitializationException: Authentication for user weblogic denied
will fill the logs.
The solution is straightforward: when using the pack.sh tool, make sure that you add/inject the files DefaultAuthenticatorInit.ldif and XACMLRoleMapperInit.ldif from the DOMAIN_HOME/security directory into the created JAR file. For example:
# Pack pack.sh -domain=<YOUR DOMAIN HOME> -template=./backup.jar -template_name=backupDomain # Inject jar ufv backup.jar <YOUR DOMAIN HOME>/security/DefaultAuthenticatorInit.ldift jar ufv backup.jar <YOUR DOMAIN HOME>/security/XACMLRoleMapperInit.ldift
Also, backup the <YOUR DOMAIN HOME>/security/SerializedSystemIni.dat from your main domain separately. This is the “salt / seed” of the encrypted passwords in your configuration. Now, when using unpack to create your cold backup domain, the DefaultAuthenticatorInit.ldif and XACMLRoleMapperInit.ldif are already present. Copy the SerializedSystemIni.dat to your new domain in the security directory, and your cold backup domain should be compatible with your “main”-domain’s config archives.
Using this method my backups for the cold backup domain consists of of the packed domain, the latest configuration archive from the main domain, the SerializedSystemIni.dat, and some misc config files (such as the nodemanager.properties). Basically, I only have to make sure that the configuration archive is up to date in the backup. Nice, clean, small and simple. This backup allows me to quickly setup an new production domain in case of an emergency, using this backup and readily available OSB en WebLogic binaries and deployments from SVN.Overzicht blogs