Easy Syntax with WLST

WLST is a powerful scripting solution for managing and administering WebLogic Server and resources deployed on them. WLST is built on the Java implementation of the scripting language Python called as Jython. All the commands in WLST are implemented as Jython functions and they require a set of parentheses for passing any arguments. Even any commands that do not require any arguments are supposed to be suffixed with parentheses. For example the command "ls" is used to list all the child MBeans and/or attributes of the current MBean you are at.

ls() - lists all the child MBeans and attributes
ls('a') - lists all the attribute names and values only
ls('c') - lists all the child MBeans only

So even if you want to invoke "ls" with no arugments you must use "ls()". This might not be an issue when you are building scripts that you might want to run many times. But while connected to a server and working with WLST in interactive mode, it might get a little frustated to type the parentheses everytime you want to run some simple commands with no arguments. To ease this pain there is a hidden option in WLST which can be used to ease the syntax for WLST commands - easeSyntax().



You can supply the "easeSyntax()" command to ease the syntax but this is not recommended for script mode and especially when using loop constructs. You can also use the regular Jython syntax with parentheses even after you enabled the easy syntax. To turn off the easy syntax mode simply issue the command again "easeSyntax".

Bye Bye parentheses!

How To Encrypt Clear Text Passwords With WebLogic Server

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).

Prior to WebLogic Server 9.0

If those passwords need to be reset either the configuration tools (Console or scripting tools) can be used which will automatically re-encrypt the passwords or by directly changing the configuration files using a text editor. When files are directly modified using a text editor the passwords will get encrypted during the subsequent restart.

Starting from WebLogic Server 9.0

Using clear text passwords in the configuration files are supported only for Development domain and it will not re-encrypt the passwords. If the domain is a Production domain then you cannot set the passwords in clear text. You have to either use a dedicated command-line utility or WLST to encrypt the clear text passwords. If the server encounters a clear text password when parsing the configuration file(s) while starting in Production Mode, then you will get an error similar to the following:

<Oct 20, 2008 9:05:35 PM EDT> <Critical> <WebLogicServer> <BEA-000362> <Server failed. Reason: [Management:141266]Parsing Failure in config.xml: java.lang.IllegalArgumentException: In production mode, it's not allowed to set a clear text value to the property: PasswordEncrypted of ServerStartMBean>


Depending on the configuration the MBean name value of the error message may change. In this case the ServerStartMBean has clear text value for a password property. Either the dedicated Java utility to encrypt clear text values can be used or WLST cant be used to re-encrypt. To run the encrypt utility follow the instructions below:

1. Change directory to your domain's bin folder (For Eg. cd c:\bea\user_projects\domains\mydomain\bin)
2. Execute the setDomainEnv script (For Eg. setDomainEnv.cmd)
3. Execute java weblogic.security.Encrypt which will prompt for the password and will print the encrypted value in stdout.

The following are some sample output from running the utility

C:\bea\user_projects\domains\mydomain>java weblogic.security.Encrypt
Password:
{3DES}9HWsf87pJTw=

You should execute this utility from the domain folder as it requires the domain's password salt file (SerializedSystemIni.dat) for encrypting the clear text string. You can also pass the clear text string as an argument

C:\bea\user_projects\domains\mydomain>java weblogic.security.Encrypt testpwd
{3DES}9HWsf87pJTw=


You can also use WLST to encrypt clear text strings as below:

C:\bea\user_projects\domains\mydomain>java weblogic.WLST

Initializing WebLogic Scripting Tool (WLST) ...

Welcome to WebLogic Server Administration Scripting Shell

Type help() for help on available commands

wls:/offline> es = encrypt('testpwd')
wls:/offline> print es
{3DES}9HWsf87pJTw=
wls:/offline>

When running WLST from a location different than the domain folder you can pass in an argument to specify the domain directory. Once you have the encrypted value, the configuration files can be modified to include this encrypte value instead of clear text passwords. These features will make your domain to operate when resetting the encrypted passwords on a Production domain's configuration XML files. These methods not only can be used to encrypt configuration XML (config.xml) but also the JDBC or JMS descriptor XML files.

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!

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.

• The domain configuration locking feature is only enabled for production domains - http://e-docs.bea.com/wls/docs103/notes/new.html#wp1088380
• Confirmation prompts for operations are enabled only for production domains - http://e-docs.bea.com/wls/docs103/notes/new.html#wp1088380
• Fast Track deployments are not recommended for production domains - http://e-docs.bea.com/wls/docs103/quickstart/quick_start.html

Add your own commands to WLST

Do you want to add your own commands to the already rich set of WLST commands?

You can do so by building your own *.py file and adding them to WL_HOME/common/wlst/lib folder. Any *.py file added to this folder will be automatically compiled and imported by WLST when started on that machine. So the custom commands built as definitions inside these modules can be used by calling them on the respective module names.

If you have a TestLib.py stored under WL_HOME/common/wlst/lib folder:

TestLib.py
----------
def testCmd():
    print 'This is a test command'

And if there is a definition called testCmd() defined in it then you can call it as follows:

wls:/offline>TestLib.testCmd()

What you waiting for? Go and add you command to WLST now.

Finally Embedded LDAP dependency is gone!

WebLogic Security Realm is a collection of configuration that protects a WebLogic Domain, its application and resources. Until WebLogic Server 10.3 the default store (Security Provider Database) used for security configuration such as users, groups, roles, policies etc. is the Embedded LDAP Server. But many customers want to externalize these information from WebLogic's Embedded LDAP Server. Different options are available only to externalize the authentication information to an external LDAP server, RDBMS etc. But still other information like authorization information, role mapping etc. stayed within the Embedded LDAP server.

With WebLogic Server 10.3 now you can choose to use an external RDBMS as a security provider database to store all security provider information. This removes the dependency of Embedded LDAP server. The other options is to build custom security providers which can use properties file as security provider database. Now you can build a WebLogic domain with no dependency to bundled Embedded LDAP server.

See http://edocs.bea.com/wls/docs103/secintro/realm_chap.html#wp1033627 for more info on how to configure a RDBMS based security provider database. One of the key thing to note is that the tables should be manually created using the appropriate *.sql file available from BEA_HOME/wlserver_10.3/server/lib directory. The domain's security provider database can be based on RDBMS when you create the domain using Configuration Wizard or later using Administration Console. Also the default Authentication Provider that comes with the default security realm - myrealm is Embedded LDAP based. So if you want to completely avoid the dependency with Embedded LDAP server then after the domain is created you have to create an Authentication provider that will use an external user repository (RDBMS, external LDAP etc.)

You can configure a domain to use RDBMS based security provider database during the domain creation using Domain Configuration Wizard.



But make sure that the tables are created before starting the Administration server according to the *.sql files provided with WebLogic installation.




If you created the domain with the default configuration (Embedded LDAP server as the security provider database) then you can change the domain configuration later to use RDBMS based security provider database.



Will meet you all with more exciting new features from Oracle WebLogic Server 10gR3!

New Flexible WebLogic 10gR3 Installer

Before installing WebLogic Server 10.3 you can now customize and select various components you want to install. I already wrote about this in my other post on WebLogic Server 10.3 Tech Preview. But here is the updated screens shot from the GA release which is now called as Oracle WebLogic Server 10gR3.


The new cool feature that customers will really benefit from is the information about the approximate install size of these different products and components so that you can reduce your server installation footprint.

Also now you can choose which JVM you need to install from the default JVMs that Oracle ships with WebLogic Server 10gR3 (Hotspot and JRockit). In addition if you already have local JDK you can select that during installation.



Along the same line you can choose to install Eclipse or use an existing Eclipse installation for Workshop.

Free Workshop Eclipse Plug-in

In addition to the standard IDE - JDeveloper, Oracle is also providing Eclipse tools (plug-ins) for WebLogic Server 10gR3. Oracle made it really simple for developers by making them as a single install. Also the Workshop Eclipse Plug-ins are now free - Yes! Oracle removed the licensing on them with the new WebLogic Server 10gR3.

Go here to download Workshop for WebLogic 10gR3 - http://www.oracle.com/technology/software/products/ias/bea_main.html#devtools
Workshop is now a one-stop-shop for building Java EE components and Web Service components for not just WebLogic Server but for a variety of different application servers. Yes, Workshop for WebLogic will be freely available on all supported platforms, including websphere, weblogic, tomcat, jboss, jetty and resin. But Adobe Flex Builder bundle has been removed from the Workshop for WebLogic bundle.

Now Workshop can be used for building Struts, Spring, Tiles, Hibernate, JPA and many more Java components to run on a variety of different web containers. Try now!

Oracle WebLogic Server !!!

If you are following the news BEA is now Oracle and so Oracle WebLogic Server. Go the Oracle website and click on the Application Server area, you will find out that WebLog ic found its spot there. Click to go there - http://www.oracle.com/appserver/index.html.

One of the key information you find on the above website is a 90 minute web-cast that explains Oracle's Middleware Strategy or go directly here - http://www.oracle.com/webapps/events/EventsDetail.jsp?p_eventId=81641. Oracle President, Charles Phillip and SVP, Thomas Kurian talks about the companies strategy in general and the future of Fusion Middleware products and BEA products. If you are interested in BEA products OR in Oracle middleware products this presentation will be worth you time.

I will soon come up more more information about some exciting features of WebLogic Server 10.3.

WebLogic Server 10.3 Tech Preview

I am so excited about the new features of WebLogic Server 10.3 which is in Tech Preview right now. So I thought I would share some of the cool features coming...

• In development Admin Console is deployed on demand the very first time someone access it. This will save memory and will speed up the development servers startup.
• Admin Console is now internally tuned for better response time.
• Light Weight Installer- Fine grained installer to reduce the footprint of the installation.

• Light Weight Runtime - If you are not using EJB, JMS, JCA you can disable those services to start WLS in a light weight mode.
• On Demand Internal Application Deployment - UDDI Explorer, Console, WS Test Client and their runtime can be be deployed on demand. This will also reduce the server's footprint when you are not using them.
• WLS 10.3 is shipping with JDK 6.
• Web 2.0 is now supported for building rich internet applications.
• Support for C# client with JMS will let .NET applications directly access JMS in WLS 10.3

and much more...

See http://e-docs.bea.com/wls/essex/TechPreview/pdf/feature_overview.pdf for more info.

Try WLS 10.3 TP

Audit WebLogic Server domain for configuration changes

In a typical WebLogic shop with more than one administrator managing the WebLogic domain(s) there is possibility that these admins can make changes without one others knowledge (at different times). To have an audit of all the configuration changes the "Configuration Audit Type" of the domain should be set. You can create the audit log entries in the administration server's server log by setting it to "Change Log" or "Change Audit" will forward it to the security audit log or "Change Log and Audit" will send it to both these logs.

See this section of edocs for more info on how to change this value.

I believe this is one of the hidden secrets in WLS. You can also audit any changes that were made and not activated but released in the audit log entries. Another main use of this feature could be to watch the security changes like who is adding new users, groups etc. The actual security audit provider only audit events like AUTHENTICATION, USERLOCKOUT etc.

Here are some sample configuration audit entries when I create a user called 'test' and added the user to the 'Administrator' group (other entries from the log file are removed for clarity):



####<Apr 1, 2008 5:12:07 PM EDT> <Info> <Configuration Audit> <BALA02> <AdminServer>
<[ACTIVE] ExecuteThread: '3' for queue: 'weblogic.kernel.Default (self-tuning)'>
<weblogic> <> <> <1207084327610> <BEA-159907>
<USER weblogic INVOKED ON Security:Name=myrealmDefaultAuthenticator METHOD listMemberGroups PARAMS test>

####<Apr 1, 2008 5:12:07 PM EDT> <Info> <Configuration Audit> <BALA02> <AdminServer>
<[ACTIVE] ExecuteThread: '3' for queue: 'weblogic.kernel.Default (self-tuning)'>
<weblogic> <> <> <1207084327626> <BEA-159907>
<USER weblogic INVOKED ON Security:Name=myrealmDefaultAuthenticator METHOD addMemberToGroup PARAMS Administrators; test>

####<Apr 1, 2008 4:59:48 PM EDT> <Info> <Configuration Audit> <BALA02> <AdminServer>
<[ACTIVE] ExecuteThread: '0' for queue: 'weblogic.kernel.Default (self-tuning)'>
<weblogic> <> <> <1207083588603><BEA-159907>
<USER weblogic INVOKED ON Security:Name=myealmDefaultAuthenticator METHOD createUser PARAMS test; ****; >

As WebLogic doesn't have the concept of super admin, all the administrators are treated the same. So when you have more than one administrative user managing a domain, the configuration audit feature will help you find out which admin did what.

Would you like to have a view of WebLogic Server instances from a control tower ?!

If you have enterprise-wide management systems in place and are looking a way to integrate WebLogic Server instances then WebLogic Server SNMP is your option. You can use Simple Network Management Protocol (SNMP) to provide monitoring data from your WebLogic Server instances to your enterprise-wide management systems.

SNMP set of standards provides a framework for the definition of management information along with a protocol for the exchange of that information. The SNMP model assumes the existence of managers and agents. A manager is a software module responsible for managing part or all of the configuration on behalf of network management applications and users. An agent is a software module in a managed device responsible for maintaining local management information and delivering that information to a manager via SNMP. A management information exchange can be initiated by the manager (via polling) or by the agent (via a trap). Agents function as collection devices that gather and send data about the managed resource in response to a request from a manager.

WebLogic supports SNMP for a long time starting from version 5.1. WebLogic SNMP enables you to move towards a single management console and thus provide integrated systems management of WebLogic Server based applications. Also WebLogic SNMP enables you to connect WebLogic Server to popular management systems such as HP OpenView, IBM Tivoli, MRTG, and Sun SunNet Manager. This makes managing WebLogic Server more effective by providing a whole-system perspective instead of piecemeal solutions.

In WebLogic Server Version 10.x SNMP implementation went through a lot of changes. Some of the important changes are:

• WebLogic Server SNMP implementation now supports SNMPv3 with SNMPv1 and SNMPv2. SNMPv3 provides additional security compared to prior versions.

• Previously only one SNMP agent per domain which runs on the Administration Server now you can create multiple agents on different servers. This removes the dependency with Administration Servers.

• Now custome MBeans can be monitored using SNMP in addition to standard WLS MBeans.

• The old command-line utilities are not deprecated and a new command-line utility is introduced - weblogic.diagnostics.snmp.cmdline.Manager

• SNMP agents in WLS can now use TCP port in addition to UDP Port which was the only option in the previous versions. And many of the configuration changes in SNMP are now dynamic which doesn't require start.

For more information read the edocs - http://edocs.bea.com/wls/docs100/snmpman/snmpagent.html

With more and more system and server administrator coming to the paradigm of administering application servers and enterprise applications, this will provide them a way to integrate WebLogic with enterprise level monitoring solutions.