Wednesday, September 24, 2008

Encrypt the credentials when running WLST in interactive or script mode

One of the common request I hear from administrators is that they want to get away from providing user name and password in plain text when using WLST. WebLogic Server provides a way to encrypt the credentials for server start up. You can create a password file "boot.properties" (called as Boot Identity File) with plain text credentials in a folder named security under the server root directory. This file will be automatically detected during the server start up and the server will encrypt the information in this file for subsequent use. Until WebLogic Server 9.x this file should be placed under the DOMAIN folder. So servers sharing the same file system share the same boot identity file and cannot be configured to use different files.

This boot identity file can also be used by WLST only when started from the domain folder. This is mainly because the domain's password key (SerializedSystemIni.dat) is used to encrypt this file. If you are using WLST from a different location or from a remote machine to connect to the server or if you want to run WLST script you can use a different technique. You can use WLST to generate a User Configuration file which will have encrypted user name and password using storeUserConfig() command. A key file that will be used to encrypt the data will also get generated along with the user config file. The key file is important as it is required to decrypt the values back from the user config file. This is an online WLST command. So you should be connected to a running WebLogic Server or a Node Manager to issue this command.

When you use this command with no arguments the user configuration file for the current user will be generated within the current OS user's home folder.


wls:/testdomain/serverConfig>storeUserConfig()


You can also specify the location and name for the key file and the userconfig file if you want them to be created elsewhere.

wls:/testdomain/serverConfig>storeUserConfig('/usr/home/user1/configfile.secure', '/usr/home/user1/keyfile.secure')


If the files are stored with the default name (osusername-WebLogicConfig.properties & osusername-WebLogicKey.properties) you can simply connect without specifying the username and password in the connect() command.

wls:/offline> connect(url='t3://host:port')


If the files are stored in a different location or with a different name, then they can be passed as an argument to the connect() command.

wls:/offline> connect(userConfigFile='/usr/home/user1/configfile.secure', userKeyFile='/usr/home/user1/keyfile.secure', url='t3://host:port')


No more plain text user name and password in when using WLST. Have a safe and secure scripting!

Friday, September 5, 2008

New differences between development domain and production domain in 10gR3

During domain creation you can specify the start up mode for your domain either as development mode of production mode. Most of you who work with WebLogic Server for the past few releases should know that there are few differences between a development domain and production domain. (http://e-docs.bea.com/common/docs103/confgwiz/newdom.html#wp1097267)

Development Mode
The default JDK for development domain is Sun Hotspot
You can use the demo certificates for SSL
Auto deployment is enabled
Server instances rotate their log files on startup
Admin Server uses an automatically created boot.properties during startup
The default maximum capacity for JDBC Datasource is 15
The debugFlag which is used to start the WebLogic Workshop Debugger is enabled

Production Mode
The default JDK for production domain is JRockit
If you use the demo certificates for SSL a warning is displayed
Auto deployment is disabled
Server instances rotate their log files when it reaches 5MB
Admin Server prompts for username and password during startup
The default maximum capacity for JDBC Datasource is 25
The debugFlag which is used to start the WebLogic Workshop Debugger is disabled

In addition to the above WebLogic Server 10gR3 adds a few more default configurations depending on whether the domain is started in development or production mode.