X

Antony Reynolds' Blog

Installing the Latest & Greatest

Antony Reynolds
Senior Director Integration Strategy

Running SOA Suite 11.1.1.5 on OEL 6

In my last post I set up Oracle 11gR2 on an Oracle Enterprise Linux 6 system hosted in VirtualBox.  In this post I will install SOA Suite onto the same box.

This will give me a complete SOA environment in a single virtual image that has all the latest software, OS, database, Java, App Server and SOA.  Because I am running a 64-bit Linux I will install 64-bit JVMs (multiple for choice and testing) and a generic WebLogic install.

Specifically I will install

I will also run the Repository Creation Utility to create the required schemas in the database.

Additional OS Preparation

Most of the OS configuration was done in preparing it for the database install but I needed to add two more packages in order to run the RCU.  These packages are:

  • libXext.i686
  • libXtst.i686

I added them by using yum:

yum install libXext.i686 libXtst.i686

Creating SOA Repository

Having added the required packages I ran the RCU and installed into my 11gR2 database.  The RCU doesn’t check the client it is executing on, only that the target database server is certified so there were no problems with running the RCU.

Installing Java

Because I am on a 64-bit system I don’t want to use the 32-bit JVMs bundled in the WebLogic install so I started off by installing the JVMs I wanted to use.

Before installing the JVMs I created a Middleware Home directory because I wanted my JVMs to be in the same middleware home as the rest of my installation.  My database installation had created an ORACLE_BASE at “/home/oracle/app/oracle” and an ORACLE_HOME at “$ORACLE_BASE/product/11.2.0/db”.  I decided to use the same ORACLE_BASE and put my MW_HOME at “$ORACLE_BASE/product/FMW” so that my middleware installs would mirror the structure of my database install.

I then changed to that directory and installed the 1.6 HotSpot JVM, the JRockit JVM for Java 6 and the JDK 1.7 JVM.  To make it easier to upgrade in the future I then created symbolic links for the JVMs:

ln –s jrockit-jdk1.6.0_24-R28.1.3-4.0.1 jrockit-jdk1.6

ln -s jdk1.7.0 jdk1.7

ln -s jdk1.6.0_25 jdk1.6

Using symbolic links allows me to install a later version of a JDK and start using it by updating the link.

Installing WebLogic

Having installed the JVMs I was then ready to run the WebLogic installer.  Because I was using a 64-bit JVM I had to run the generic installer which is delivered as an executable jar file.  I added all three of my JVMs to the list of JVMs in WebLogic and made the 1.6 HotSpot JVM the default.  Note that WebLogic identifies the JVMs and follows symbolic links to get to the actual directory.  The 1.7 JDK is identified as an Oracle rather than a Sun JDK because Oracle now own Sun.  Normally if the vendor is Oracle then WebLogic assumes that this is a JRockit JVM.  This will cause a problem later because HotSpot has different parameters to JRockit.

After installing WebLogic I edited $MW_HOME/wlserver_10.3/common/bin/commEnv.sh to refer to the synbolic link for the JVM rather than the actual directory.  This will make it easier in the future to upgrade the JVM.

JAVA_HOME="/home/oracle/app/oracle/product/FMW/jdk1.6"

Installing OSB

Both OSB and SOA Suite use the Oracle Universal Installer to check the platform, required OS parameters and packages of the target system.  Unfortunately OEL 6 is not on the list of expected OS platforms and so the installer fails it pre-requisite checks.  In the DB installer we could choose to ignore failed checks from the GUI.  With the DB and OSB installers you can’t.  So we have two options, ignore the pre-requisite checks or add new ones.  Whichever choice you go with the install of OSB is now straightforward.  I didn’t install the designer because it is currently only built for a 32-bit system.  I will install the designer on a client machine rather than on my server VM.

Option 1 – Ignore Pre-Reqs

You can ignore the installer pre-req check by passing the –ignoreSysPrereqs to the installer

./runInstaller –ignoreSysPrereqs

This has the advantage that it is quick and easy but of course you may actually fail a check because something really is needed and you would never know it.  So that leads us to option 2.

Option 2 – Create New Check for OEL 6

The pre-req checks are held in a file “Disk1/stage/prereq/linux64/refhost.xml” on the installation image.  I added a new <OPERATING-SYSTEM> tag to the <CERTIFIED-SYSTEMS>.  I copied the redhat 5.4 tag and changed the “<VERSION>” “VALUE” attribute to “6.0” and changed the “i386” “ARCHITECTURE” attributes in “<PACKAGE>” elements to “i686”:

    <OPERATING_SYSTEM>
      <VERSION VALUE="6.0"/>
      <ARCHITECTURE VALUE="x86"/>
      <NAME VALUE="Linux"/>
      <VENDOR VALUE="redhat"/>
      <GLIBC ATLEAST="2.5-12">
      </GLIBC>
      <PACKAGES>
              <PACKAGE NAME="binutils" VERSION="2.17.50.0.6" />
          <PACKAGE NAME="compat-libstdc++-33" VERSION="3.2.3" ARCHITECTURE="x86_64" />
          <PACKAGE NAME="compat-libstdc++-33" VERSION="3.2.3" ARCHITECTURE="i686" />
              <PACKAGE NAME="elfutils-libelf" VERSION="0.125" />
              <PACKAGE NAME="elfutils-libelf-devel" VERSION="0.125" />
              <PACKAGE NAME="gcc" VERSION="4.1.1" />
              <PACKAGE NAME="gcc-c++" VERSION="4.1.1" />
              <PACKAGE NAME="glibc" VERSION="2.5-12" ARCHITECTURE="x86_64" />
              <PACKAGE NAME="glibc" VERSION="2.5-12" ARCHITECTURE="i686" />
              <PACKAGE NAME="glibc-common" VERSION="2.5" />
              <PACKAGE NAME="glibc-devel" VERSION="2.5" ARCHITECTURE="x86_64" />
          <PACKAGE NAME="glibc-devel" VERSION="2.5-12" ARCHITECTURE="i686" />
          <PACKAGE NAME="libaio" VERSION="0.3.106" ARCHITECTURE="x86_64" />
          <PACKAGE NAME="libaio" VERSION="0.3.106" ARCHITECTURE="i686" />
              <PACKAGE NAME="libaio-devel" VERSION="0.3.106" />
          <PACKAGE NAME="libgcc" VERSION="4.1.1" ARCHITECTURE="x86_64" />
          <PACKAGE NAME="libgcc" VERSION="4.1.1" ARCHITECTURE="i686" />
          <PACKAGE NAME="libstdc++" VERSION="4.1.1" ARCHITECTURE="x86_64" />
          <PACKAGE NAME="libstdc++" VERSION="4.1.1" ARCHITECTURE="i686" />
          <PACKAGE NAME="libstdc++-devel" VERSION="4.1.1" />
          <PACKAGE NAME="make" VERSION="3.81" />
          <PACKAGE NAME="sysstat" VERSION="7.0.0" />
      </PACKAGES>
      <KERNEL>
<!--
              <PROPERTY NAME="semmsl" NAME2="semmsl2" VALUE="250" />
              <PROPERTY NAME="semmns" VALUE="32000" />
              <PROPERTY NAME="semopm" VALUE="100" />
              <PROPERTY NAME="semmni" VALUE="128" />
              <PROPERTY NAME="shmmax" VALUE="536870912" />
              <PROPERTY NAME="shmmni" VALUE="4096" />
              <PROPERTY NAME="shmall" VALUE="2097152" />
              <PROPERTY NAME="file-max" VALUE="65536" />
              <PROPERTY NAME="ip_local_port_range" ATLEAST="1024" ATMOST="65000" />
              <PROPERTY NAME="rmem_default" VALUE="4194304" />
              <PROPERTY NAME="rmem_max" VALUE="4194304" />
              <PROPERTY NAME="wmem_default" VALUE="262144" />
              <PROPERTY NAME="wmem_max" VALUE="262144" />
-->
              <PROPERTY NAME="VERSION" VALUE="2.6.18"/>
              <PROPERTY NAME="hardnofiles" VALUE="4096"/>
              <PROPERTY NAME="softnofiles" VALUE="4096"/>
      </KERNEL>
    </OPERATING_SYSTEM>

This allows you to run the installer as normal and it will validate the pre-reqs correctly giving you confidence that things are set up correctly in the OS.

Installing SOA Suite

After installing OSB I installed SOA Suite using the same work around for the OS pre-req mismatch as we used for OSB.  At this point I took another snapshot so that I could build different types of domain from the same repository.

Creating a Development Domain

My next step was to create a domain suitable for development with SOA Suite and Service Bus.  I chose the Developer OSB and Developer SOA Suite templates from the domain configuration wizard along with the Enterprise Manager template.  This creates a single server, the AdminServer, that has all the SOA and Service Bus components.  This works well for development environments as it minimizes the memory footprint required by putting everything into a single server.  After creating the domain and starting the AdminServer I fired up jconsole to check the memory usage of the JVM.  I saw that it had committed 1.3GB out of a maximum 1.5GB.  I was surprised to notice that the PermGen was using almost 500MB.  The initial default memory size is 750MB and the maximum is 1.5GB so I changed the memory settings by editing setSOADomainEnv.sh.  I increased the initial memory size to 1.5GB and set the maximum memory size to be 2.5GB by setting the PORT_MEM_ARGS in setSOADomainEnv.sh.  I also modified the initial PermGen size to be 512MB and the maximum PermGen size to be 750MB to ensure I didn’t run out of space for code.

PORT_MEM_ARGS=”-Xms1536m –Xmx2560m”
PORT_MEM_ARGS=”${PORT_MEM_ARGS} -XX:PermSize=512m -XX:MaxPermSize=768m"

Note I used PORT_MEM_ARGS because I was using a 64-bit Linux system.  If it was a 32-bit system then I would have set the DEFAULT_MEM_ARGS.

I then took a snapshot of my virtual image so I can jump straight to a ready to use domain when I need it.

Creating a Production Domain

Having created a development domain that ran in a single server I also wanted a production style domain that had everything I would need for SOA.  I chose the BPM Suite, SOA Suite, Enterprise Manager, Service Bus and Business Activity Monitoring templates for this domain.  I chose production mode for my domain to make it better reflect what customers would have in their production environments.  I accept all the other defaults and created the domain.  This creates separate managed servers for SOA/BPM, BAM and OSB.  Consoles still run in the AdminServer.  Before starting I created a boot.properties file with the following properties:

username=weblogic
password=welcome1

I created the following directories under my domain directory (using “mkdir –p <dirname>”) and put a boot.properties file in each of them.

  • servers/AdminServer/security
  • servers/soa_server1/security
  • servers/bam_server1/security
  • servers/osb_server1/security

I then started the admin server.  While it was starting I ran the “$MW_HOME/oracle_common./common/bin/setNMProps.sh” script to enable Node Manager to start the managed servers.  I then started the Node Manager.

With the node manager running I was able to check the consoles were working fine and then I noticed that the OSB server was not targeted at a machine and so could not be started by node manager.  I targeted “osb_server1” at the default “LocalMachine” and then started the managed servers.

After verifying that all was well with the managed servers I shutdown the machine and took a snapshot.

A Solid Base

I use this kind of VM configuration all the time because I can always create a new domain from the base software to match my exact requirements.  But most of the time I can use one of the existing domains.  Although it is quite heavy on disk it is more efficient than having multiple images.  Hope you find this useful.

Join the discussion

Comments ( 10 )
  • guest Tuesday, May 17, 2011
    Thanks for this Antony - it's great to have all the instructions for a laptop VM in one post. I'm also glad that Oracle have released PS4 for SOA as a full installer again as it's much easier than having to patch up a base release... long may it continue! (and spread to other OFM products)
  • Geoff Wednesday, May 18, 2011
    Hi Antony,
    I thought that, at least with earlier versions of the WebLogic Server installer, symbolic links were dereferenced at install-time, so the actual path winds up embedded in places like setDomainEnv.sh. Perhaps I'm mis-remembering, but I had tried exactly your approach, and found myself having to change config files in order to use a different JVM.
    Cheers,
    Geoff.
  • Antony Thursday, May 19, 2011
    Geoff,
    You are correct that symbolic links are de-referenced by WebLogic. But only in the installer. If you alter the commEnv.sh script then when you create a domain it will use the symbolic link rather than the physical link.
    Antony
  • Simon Haslam Thursday, May 19, 2011
    FWIW I always install the JDK(s) outside the MW_HOME and just reference the full path in the installer. Then I can easily upgrade each domain to a new version later in the setDomainEnv.sh.
  • guest Thursday, August 4, 2011

    Thanks for your postings.

    I wondered if this VM was available for download for people like me that are architects and are not skilled administrators.


  • guest Monday, September 12, 2011

    Hi Anthony,

    I have one quick question, Is it possible to have the Repository in AIX while maintaining FMW stack on OEL 5.6 or equivalent ?

    Regards,

    Makarand


  • Simon Haslam Friday, September 23, 2011

    Makarand

    I don't see why not - providing both ends are on supported versions of the platforms (see SOA sections of FMW certification matrix at http://www.oracle.com/technetwork/middleware/ias/downloads/fusion-certification-100350.html). In fact the database requirements aren't very challenging for lab environments like this - using Oracle XE for the repository should be fine (I think a few minor workarounds were required but am not sure with the latest patchset).

    HTH

    Simon


  • Antony Tuesday, October 11, 2011

    The repository can be in any supported database version on any platform supported for that database version. However the Repository Creation Utility (RCU) must be run from Windows or Linux, although it can populate a remote database on AIX for example.

    Antony


  • Eric Friday, December 16, 2011

    Hi Antony,

    I'm having trouble running the RCU and was hoping you could point me in the right direction. I've google'd all manner of useless info. I'm getting the error "..../rcuHome/jdk/jre/lib/i386/xawt/libmawt.so: libXext.so.6: cannot open shared object file: No such file or directory"

    I've run "rpm -qa | grep libXext" and found "libXext-1.1-3.el6.x86_64", so it's my understanding that libXext.so.6 is installed (since it's in /usr/lib64)

    Thanks in Advance :)

    Eric


  • Eric Thursday, December 29, 2011

    By the time the moderator posted my comment / request for help, I was able to resolve the issues.

    Posted Dec 16th - posting shown Dec 29th

    Thank you,

    Eric


Please enter your name.Please provide a valid email address.Please enter a comment.CAPTCHA challenge response provided was incorrect. Please try again.