Play Hide & Seek with Administration Console

Everyone who work with WLS knows that the Administration Console is the light weight web based UI provided by BEA for configuring, monitoring and managing a WLS domain. Automation and Scripting can be done in many ways. See this post for more info.

Exposing the console in your production environment might be security issue. In those cases you can either disable the console or hide it. Needless to say if you disable the console then your only option is to depend on command-line and scripting tools for any other administration activity or to even enable the console back. But hiding will provide a level or security.

To disable the console:

• In the admin console navigate to --> General --> Advanced Options --> Console Enabled. De-select that option to disable console (restart required).
  

To hide the cosole:

• Enable the administration port on the domain so that console can only be accessed on the 2-way secured admin port. This will force all the clients to have valid certificate installed in their client (browser) to access the console.
• In the admin console navigate to --> General --> Advanced Options --> Console Context Path and change the context-path of the console to something unique and only known to the administrators.

All is fine. But one of the common question is how can I enable the console once I disable them. Like I said earlier you have to rely on the scripting tool to enable the admin console once it is disabled. You either perform this action interactively or by running a WLST script. See the following sample WLST script for more info:

connect("username","password")
edit()
startEdit()
cmo.setConsoleEnabled(true)
save()
activate()
disconnect()
exit()

You have to restart the administration server to get the console back. Have fun playing hide and seek with the console!

In WLS 10.3 with the Light Weight Server Installer, you can choose not to install WLS Admin Console when you install WLS. Along with the other installation options, this provides a way to reduce the server installation footprint and runtime memory footprint. Can't wait to play with WLS 10.3, you can now download the Tech Preview at http://commerce.bea.com/showproduct.jsp?family=WLS&major=10.3Tech&minor=-1
(as of Nov 9, 2007 WLS 10.3 is only a Tech Preview Release). I will write more on the WLS 10.3 release which is build on BEA microService Architecture (mSA) soon. Read more about BEA mSA here http://www.bea.com/framework.jsp?CNT=msa.jsp&FP=/content/.

Is my Administration Server single point of failure?

The answer is No and Yes. Read on for more specific info....

WebLogic domain consists of Servers, Machines, Clusters, Applications and Configurations related to them. Administration sever is the controlling instance for the domain. It is the keeper of all the configuration. Ideally you don't want to host (target) any application or service that clients would access on the admin instance. Managed server(s) or cluster(s) are meant to host such applications and services that clients would access (servers other than admin server in a domain are called as managed servers).

Having said that, if an admin instance fails during the middle of the day what happens to my domain? It is the controlling instance so will it halt my domain? The answer is NO. Admin server will provide all the configurations to each managed server and they will be cached locally. There are limited dependency between the servers during runtime. So an admin server failure will not affect the running managed server(s) or cluster of managed server(s).

Alright, what about the "Yes" part of the above answer?! There are few services you will lose when an admin instance is not available. You cannot introduce any new configuration or change any existing configuration in the domain. Examples are: you cannot deploy new applications, you cannot change the JNDI name of a JMS destination hosted on one or more servers etc. You will also lose the domain log entries in the Domain Log file maintained by the administration server. Still you can use the Server Log maintained on each managed server for auditing or troubleshooting purpose. Also lastly the managed server(s) in the absence of admin server can only be started or restarted in Independence Mode (using the previously cached local configuration information).

• You are not expected to introduce new configuration or change any configuration on the fly in your production setup so losing the ability to do this will have literally no or little impact.
  
• You can use server log file entries for auditing and troubleshooting purposes.
  
• The managed server can be restarted or started if required during the absence of admin server using Independence Mode (which is a default setup now in WLS 10.x - no extra configuration required).

Admin server (for that matter any server in the domain) can be configured to automatically get restarted in case of failures using a feature called - whole server migration. I will talk about this in a later discussion.

So now you know why I said "No" and "Yes"! huh!