Thursday, June 20, 2013

How to get around OS certification check in Fusion MiddleWare installers

Information has to be corrected in two locations:
  1. /etc/redhat-release or /etc/oracle-release
  2. <installer>/Disk1/stage/prereq/linux64/refhost.xml

redhat-release/oracle-release:

One of these files - depending on the installer is to be modified. Fix them both to avoid re-running the installer. Sample:


refhost.xml:

In the refhost.xml  copy the entire block for a release, whatever you find to be near the version of OS you have and make the appropriate changes. Here's mine for Oracle 6.4:

The installer should now 'match' the two correctly and perform the certification checks.

Tuesday, June 4, 2013

WebLogic wlst.sh how to set the JVM args

It is completely, entirely, unbelievable to me that something as simple as this was not clearly documented.

My previous solution was:
Edit:

${WL_HOME}/server/bin/setWLSEnv.sh

And add below the line:
. "${WL_HOME}/common/bin/commEnv.sh"

The following lines:
 
if [ -n "${CUSTOM_WLST_ENV}" ]
then
    if [ -f "${CUSTOM_WLST_ENV}" ]
    then

        . "${CUSTOM_WLST_ENV}"
    fi
fi

Well, guess what? there is a hidden custom script sourcing line exactly but not exactly like what I did. in the setWLSEnv.sh around line 64 there is a line that sources an extEnv.sh.
One big caveat - they expect it to be in the $PATH environment so that it can be invoked by just ". extEnv.sh". I would think this is not ideal, but it is still manageable.

 62 # Import extended environment
 63 
 64 if [ -f extEnv.sh ]; then
 65   . extEnv.sh
 66 fi

Therefore to introduce custom attributes into this mix, you will have to create an extEnv.sh. And then add its directory to the path, and export it such that it precedes all other PATH items:
export PATH= "<extEnv.sh's dir>:$PATH"
Then running wlst.sh should include the extEnv.sh in the above path.
Simplest would be to add the dot "." in the $PATH to indicate current directory and place an extEnv.sh in the current directory. The dot in the PATH in unix'es is not a recommended practice and it is generally a better practice to run scripts explicitly.

Some important variables:
CONFIG_JVM_ARGS: sets JVM args for the java, so all your "-D" properties can go here. Be sure to not wipe out existing ones and use: CONFIG_JVM_ARGS=$CONFIG_JVM_ARGS -D... form so existing values are copied.


-- Old Stuff I am keeping for editing later --

Now you in the calling script or shell you can create an external shell script with the overrides for the values in commEnv.sh

For example add this to: customwlstenv.sh:
 
export MEM_ARGS="-Xms512m -Xmx1024m -XX:PermSize=128m -XX:MaxPermSize=256m"
Then export - note it is important to fully qualify the path so that commEnv.sh can execute it from wherever it is running:
export CUSTOM_WLST_ENV="$PWD/customwlstenv.sh"

If you now run the wlst.sh script it should pick up on the MEM_ARGS and override the ones in commEnv.sh