Installing E-Business Suite R12.2.11 + RDBMS 19c on OEL 8.5: Part 3 – Running RapidWiz

In our previous posts, we built the OEL 8.5 virtual machine, downloaded the software, and built our staging area.

In this post, we’re going to use the RapidWiz tool to perform a single-node Fresh Install of E-Business Suite R12.2.0. (We will have to upgrade to R12.2.11 after the install).

Launch Rapidwiz

As your “generic” user (jmorrow, in my case), open a terminal window and launch RapidWiz.

We’re going to be using “sudo” to actually invoke RapidWiz because, since this is a single node, it needs to run as root in order to handle deploying software for both “oracle” and “applmgr”.

If we were doing a typical two-node installation (dbTier on one node, appsTier on the other), you would simply run rapidwiz as “oracle” or “applmgr” on the appropriate node.

export DL=/Stage/Oracle_EBSR12211
export STAGE=/Stage/StageEBSR12211
cd ${STAGE}/startCD/Disk1/rapidwiz

sudo ./rapidwiz

If you expand the tree, you can see everything that it’s going to install.

We’re going to choose to install E-Business Suite. This will give us an “empty” E-Business Suite database in addition to the necessary software.

If we were preparing a system for an upgrade (where we’re bringing over an existing database), we would choose “Upgrade to Oracle E-Business Suite Release 12.2.0” to only install the software.

You can leave this blank.

We’re going to Create a new configuration.

You’ll want to spread out your port pools. The general recommendation is that the port pool for File System 2 should be at least FS1+10.

There are a few things to pay attention to here. First, you’ll want to select “Fresh Database” (the default is to install VISION).

Next, make sure you set your SID. In our case, we’re going to use “PROD”.

Next, make sure that the database OS user is correct.

The default Database Directory is “/d01/oracle/PROD”. We are using “/oracle/PROD”. Once you make that update, the Database Home will also change.

The default Datafiles Directory is “/d01/oracle/PROD/data”. We’re using “/oradata/PROD” instead.

Since this is a throwaway, we’re going to choose Suite Licensing. Depending on your requirements, you may want to use Component Licensing instead.

We’re going to accept the defaults here. Again, depending on your requirements, you may want to choose differently.

REMEMBER: E-Business Suite Licensing is contractual. Your selection on these menus does NOT change what software will be installed. It only amounts to a “bit flip” in a licensing table. That said, there is no supported way to de-license an E-Business Suite module. So, if you’re doing this for real, make your selections carefully.

This screen is for country-specific functionality, typically called “localizations”. These items are usually to satisfy specific legislative requirements. This screen is NOT for languages.

If you need any country-specific functionality, make those selections here.

THIS screen is where you choose languages and character sets. By default, you only get American English (US) and the US7ASCII character set. If you’re wanting another character set, make that selection here.

Generally speaking, WE8ISO8859P15 should cover most “Western European” languages (English, German, Spanish, French, Italian).

The AL32UTF8 character set will cover any others (Arabic, Hebrew, Chinese, Japanese, etc.)

This screen gives the E-Business Suite details (the appsTier). Because of the changes we made on the dbTier configuration for this node, the defaults here are correct for our installation.

You will need to provide a password to be used for the “weblogic” administrator.

Because we’re running RapidWiz as root, you can leave the password for applmgr blank.

For this exercise, I’m un-checking “Change Default Passwords”.

When you hit “Next”, another window will pop up as RapidWiz performs a bunch of pre-installation checks. These checks will run for a few minutes, depending on the size of your VM.

These should all come back “Green”. If they don’t, click on the button beside each check to see the results.

Click “Yes” to begin the installation.

The installation should run for at least 2-3 hours.

Everything should be “Green”.

And, again, if you expand the tree, you can see everything that was installed.

At this point, RapidWiz will exit. You should have a running E-Business Suite system. Let’s do a few things to tidy up the installation…

Normally, we would create a nice .bash_profile for the oracle and applmgr users that would set up our environments. But we’re going to wait on that until after we’re done with the 19c upgrade.

Meanwhile, AutoConfig has already created some environment files for us. I like to create symbolic links in the users’s home directories to make things easier.

sudo su - oracle
ln -s /oracle/PROD/12.1.0/PROD_prod.env db.env
exit

sudo su - applmgr
ln -s /oracle/PROD/fs1/EBSapps/appl/APPSPROD_prod.env fs1.env
ln -s /oracle/PROD/fs2/EBSapps/appl/APPSPROD_prod.env fs2.env
exit


And that’s the end of Part 3. In the next installment, we’ll upgrade E-Business Suite to R12.2.11. Stay tuned!

Installing E-Business Suite R12.2.11 + RDBMS 19c on OEL 8.5: Part 2 – Staging The Software

Storage

When we built our virtual machine, we mapped some “shared folders” from our host into our VM. We’re going to download our software using the web browser on our host into that shared folder. For the purpose of this document, these are the mappings that I’m using:

Host PathVM PathDescription/Purpose
E:\Backup/BackupBackups
S:\Software/SoftwareSoftware Downloads
E:\Stage/StageStaging Area

Download the Software

Download your installation media from Oracle’s E-Delivery site, https://edelivery.oracle.com. You will need a valid login in order to do this.

Login with your valid Oracle credentials.

In the search box, type “oracle e-business suite”. Then, from the results below, select “DLP: Oracle E-Business Suite 12.2.11” to add it to your cart.

Next, type “oracle database 19c” into the search box and select “DLP: Oracle Database 19c Enterprise Edition 19.3.0.0.0” to add it to your cart. We specifically want Enterprise Edition because it is required for E-Business Suite.

Hit “Continue” in the top right corner to proceed.

First, click on the platform pull-down on the first item in each grouping. Select “Linux x86-64” (it should auto-fill for the remaining packages in that product group).

The packages actually include more than we really need for this exercise. So, if you want to reduce your download, we only need to select the four items shown above.

Once you’ve made your selections, hit “Continue” to proceed.

Of course, you’ll need to accept the license agreement…

Here you will see exactly what is going to be downloaded. When you receive the files, they will have names like “V982063-01.zip”, so it can be somewhat difficult to decode. I recommend you click on the “View Digest Details” link. That will give you a nice report with filenames, descriptions, and checksums to validate the download. Save that report to a PDF file in your download directory for reference.

Once you’ve done that, hit the Download button. This will, initially, download a small download manager that you will need to execute. At that point, your multi-threaded download will begin.

Download the current StartCD and RapidInstall Consolidated Bundle Patch [MOS 1320300.1]

You will need to download the following patches from My Oracle Support (MOS):

PatchDescription
22066363startCD 12.2.0.51
32947483RapidInstall Consolidated Bundle Patch

Staging the Software [MOS 1596433.1]

During this process, I’m going to define some temporary environment variables to keep things simple. If your installation differs, adjust those variables accordingly.

From within our Virtual Machine, we will need to extract the files necessary to build the staging area. Note that we do NOT need to unzip all of the E-Business Suite files directly. That will be done by the buildStage script.

#  This is our download directory, where all of the zip files are placed.
export DL=/Stage/Oracle_EBSR1221

#  This is where we're going to build our staging area
export STAGE=/Stage/StageEBSR1221

Build the Staging Area using startCD 51

cd ${STAGE}
unzip ${DL}/p22066363_R12_GENERIC.zip
cd ${STAGE}/startCD/Disk1/rapidwiz/bin
./buildStage.sh

Using the menus, first choose option 1 “Create new staging area”

               Build Stage Menu

------------------------------------------------------

1.     Create new stage area

2.     Copy new patches to current stage area.

3.     Display existing files in stage TechPatches.

4.     Exit menu


Enter your choice [4]: 1

You will also need to choose a platform (Linux x86-64, in our case)

        Rapid Install Platform Menu

------------------------------------------------------

1.    Oracle Solaris SPARC (64-bit)

2.    Linux x86-64

3.    IBM AIX on Power Systems (64-bit)

4.    HP-UX Itanium

5.    Exit Menu


Enter your choice [5]: 2

Once the script is finished, choose option 4 to exit.

Patch the staging area

cd ${STAGE}
unzip ${DL}/p32947483_R12_GENERIC.zip
cd 32947483
sh patchRIStage.sh

Re-run the staging area script to “Copy patches to the existing staging area”

cd ${STAGE}/startCD/Disk1/rapidwiz/bin
./buildStage.sh

------------------------------------------------------

1.     Create new stage area

2.     Copy new patches to current stage area.

3.     Display existing files in stage TechPatches.

4.     Exit menu


Enter your choice [4]: 2

Again, choose your platform

1.    Oracle Solaris SPARC (64-bit)

2.    Linux x86-64

3.    IBM AIX on Power Systems (64-bit)

4.    HP-UX Itanium

5.    Exit Menu


Enter your choice [5]: 2

And now you have a completed staging area for E-Business Suite.

In our next posting, we’ll run RapidWiz to install E-Business Suite R12.2.11 and RDBMS 12c.

Installing E-Business Suite R12.2.11 + RDBMS 19c on OEL 8.5: Part 1 – Operating System Prep

This is the first post in a multi-part series. The ultimate goal is to have a single node installation running Oracle E-Business Suite R12.2.11 & RDBMS 19c on Oracle Enterprise LInux 8.5.

For the purpose of this installation, I’m using a VirtualBox VM. However, the steps would be pretty much the same regardless of the physical (or virtual) hardware.

It is important to note, if your goal is simply to have an easy Oracle E-Business Suite Vision VM, then Oracle does have pre-built VM images (templates) that you can download and import into VirtualBox.

However, for our purposes, we’re walking through the steps to build the system from the ground up, similar to a “real” installation.

Create the Virtual Machine The “Hardware”

For a Minimal Installation, the pre-built Oracle VISION VM Templates have the following minimum hardware requirements:

  • 1 CPU Core
  • 16 GB RAM
  • 400 GB Disk

For this installation, I’m using a fairly beefy physical machine, so I’m able to size the Virtual Machine comfortably. I’m also sizing the system in a manner that would be similar to what you might actually use.

  • 8 CPU Cores
  • 24 GB RAM
  • 64GB Main Disk (Operating System)
  • 512 GB for the Oracle Software
  • 512 GB for the database
  • 64 GB for archive logs

After installing VirtualBox, create a VirtualBox VM. Assign the VM 8 CPU cores. Optionally Enable “Bidirectional Clipboard” and “PAE/NX & Nested VT-x/AMD-V”

When defining storage, create 3 disks. 64GB, 512GB, and 512GB. I recommend using “VDI” images for the disks. The “VDI” images are, essentially “thin provisioned”. So, while the disk within the VM would appear as 512GB, the underlying file (at the host level) would only be as large as the “used” portion of that disk.

You may also want to map a shared folder to the VM so that you can keep your staging area and/or downloads outside of the VM.

Install Oracle Enterprise Linux 8 (8.5)

Insert the Oracle Enterprise Linux 8.5 media into the Virtual CD-ROM drive and boot the VM.

When you’re going through the operating system install, you want to set the following:

  • Set the Timezone
  • Set the Root Password
  • Create an additional user (“jmorrow” in my case), assign it UID & GID 1000, and set the user to be administrator.
  • Software Selection: Server with GUI
  • Network: Enabled, Connect Automatically, Assign a hostname of “prod.mydomain.com”
  • On the Storage section, you’ll only want to select the Main Disk (64 GB). Choose to create a Custom Storage Configuration.
    • /boot 1 GiB
    • /home 5 GiB
    • swap 18 GiB
      IMPORTANT: Swap must be NO LESS THAN 17,179,869,184 bytes (16GB) or it will fail the installer check!
    • Use the remainder of the volume for the root volume (/)

Reboot the system when the installer finishes.

Install the VirtualBox Guest Additions

Install prerequisites for VirtualBox Guest Additions

dnf install -y kernel-uek-devel-$(uname -r) perl 
make bzip2 gzip unzip tar

dnf update -y

From the Virtual Box Menu at the top of the screen, choose “Devices –> Insert Guest Additions CD Image”. At that point, a pop-up should appear in the VM to install the Guest Additions. Follow the instructions.

Reboot the VM when done.

The Guest Additions will enable things between the Host Machine and the Guest (like cut and paste and the shared filesystems). It will also help with larger displays and keyboard/mouse capture.

Add the EPEL Repository

The EPEL “Extra Packages for Enterprise Linux” repository contains a number of useful tools that I like on Linux boxes.

tee /etc/yum.repos.d/ol8-epel.repo<<EOF
[ol8_developer_EPEL]
name= Oracle Linux \$releasever EPEL (\$basearch)
baseurl=https://yum.oracle.com/repo/OracleLinux/OL8/developer/EPEL/\$basearch/
gpgkey=file:///etc/pki/rpm-gpg/RPM-GPG-KEY-oracle
gpgcheck=1
enabled=1
EOF

Pre-Create Users/Groups [CONDITIONAL]

We’re going to use the pre-install packages from Oracle to do most of the operating system prep. However, in my case, I’m wanting to use specific UID/GID numbers for user and group creation. So, we’re going to pre-create those users and groups here. If you’re not concerned with the UID/GID numbers, you can skip this step.

groupadd -g 2000 dba
groupadd -g 2001 oinstall
groupadd -g 2002 oper
groupadd -g 2003 backupdba
groupadd -g 2004 dgdba
groupadd -g 2005 kmdba
groupadd -g 2006 racdba
groupadd -g 2007 asmadmin
groupadd -g 2008 asmoper
groupadd -g 2010 oraagent
useradd -u 2000 -g dba -N -m -c "Oracle Database Owner" oracle
useradd -u 3000 -g dba -N -m -c "Oracle Applications Owner" applmgr

Install Prerequisites for E-Business Suite R12.2 [MOS 1330701.1]

dnf install -y oraclelinux-release
dnf config-manager --set-enabled ol8_addons
dnf install -y oracle-ebs-server-R12-preinstall.x86_64

The oracle-ebs-server-R12-preinstall.x86_64 package will handle most of the configurations mentioned in MOS 1330701.1. It will also create the following users and groups (if they don’t already exist):

oinstall:65535
dba:65536
oracle:65535
applmgr:65536

Install Prerequisites for RDBMS 19c [MOS 2552181.1]

dnf install -y oracle-database-preinstall-19c

This package will create the following users and groups on top of what the EBS package creates (if they don’t already exist):

oper:54323
backupdba:54324
dgdba:54325
kmdba:54326
racdba:54330

Install Additional Packages [MOS 2790032.1]

When I was building the staging area, I encountered MOS 2790032.1.

dnf install -y libnsl.i686

Install Additional Packages [OPTIONAL]

Many of these are things that I’ve found useful/necessary with E-Business Suite systems. They are not necessary to complete the EBS or RDBMS intallation.

dnf install -y fontconfig-devel.x86_64 libXrender-devel.x86_64 screen.x86_64 xinetd.x86_64 dos2unix.x86_64 curl.x86_64 wget.x86_64 htop.x86_64

Modify User/Group Membership [CONDITIONAL]

This is largely for convenience. We want to make sure that certain users have access to the Virtual Box Shared Folders (vboxsf). Additionally, we want to make sure that my personal user (jmorrow) can sudo easily.

usermod -G vboxsf,oinstall,dba oracle
usermod -G vboxsf,oinstall,dba applmgr
usermod -G vboxsf,oinstall,dba,wheel jmorrow

Add Additional Volumes

This is where we bring in those additional disks that we created along with the Virtual Machine.

Create the volume for our Oracle Software Installation (/oracle)

# Create the volume
pvcreate /dev/sdb
vgcreate OracleVG /dev/sdb
lvcreate -l 100%FREE -n OracleLV OracleVG

# Put a filesystem on it
mkfs.xfs /dev/OracleVG/OracleLV

# Update /etc/fstab, create the mountpoint, and mount the volume
export BLKID=`blkid -o export /dev/OracleVG/OracleLV|grep "^UUID="|cut -f2 -d"="`

echo "UUID=${BLKID} /oracle/PROD xfs defaults 1 2" >>/etc/fstab
mkdir -p /oracle/PROD
mount /oracle/PROD

Create the volume for the Oracle Database (/oradata)

# Create the volume
pvcreate /dev/sdc
vgextend OracleVG /dev/sdc
lvcreate -l 100%FREE -n OradataLV OracleVG

# Put a filesystem on it
mkfs.xfs /dev/OracleVG/OradataLV

# Update /etc/fstab, create the mountpoint, and mount the volume
export BLKID=`blkid -o export /dev/OracleVG/OradataLV|grep "^UUID="|cut -f2 -d"="`
echo "UUID=${BLKID} /oradata/PROD xfs defaults 1 2" >>/etc/fstab
mkdir -p /oradata/PROD
mount /oradata/PROD

Create the volume for the Oracle Database Archivelogs (/oraarch)

# Create the volume
pvcreate /dev/sdd
vgextend OracleVG /dev/sdd
lvcreate -l 100%FREE -n OraarchLV OracleVG

# Put a filesystem on it
mkfs.xfs /dev/OracleVG/OraarchLV


# Update /etc/fstab, create the mountopint, and mount the volume
export BLKID=`blkid -o export /dev/OracleVG/OraarchLV|grep "^UUID="|cut -f2 -d"="`
echo "UUID=${BLKID} /oraarch/PROD xfs defaults 1 2" >>/etc/fstab
mkdir -p /oraarch/PROD
mount /oraarch/PROD

Update SELINUX

This will run for about 5 minutes (depending on your system).

fixfiles relabel 

Prepare the oraInventory

We’re going to pre-create the oraInventory to our preferences and so that ownership/permissions are correct.

echo "inst_group=dba" > /etc/oraInst.loc
echo "inventory_loc=/var/opt/oracle/oraInventory" >>/etc/oraInst.loc
mkdir -p /var/opt/oracle/oraInventory

Adjust Ownership & Permissions

chown -R oracle:oinstall /var/opt/oracle /etc/oraInst.loc
chmod u+rw,g+rw,o+r /etc/oraInst.loc

chown -R oracle:dba /oracle/PROD /oradata/PROD /oraarch/PROD
chmod -R u+rwX,g+rwX,o+rX /var/opt/oracle /oracle/PROD

Update /etc/hosts

Oracle E-Business Suite requires that the entry for this host is formatted as such:

<IP Address> <hostname.domainname> <hostname>

Determine your IP address (ip addr show) and assign that to the IPADDR variable. For the purpose of illustration, we’re going to use 192.168.1.100.

export IPADDR=
echo "${IPADDR} `hostname` `hostname -s`" >> /etc/hosts
cd /usr/lib
ln -s libXm.so.4.0.4 libXm.so.2

And that’s it. The operating system is prepared.

For our next post, we’ll build the staging area and perform the Fresh Installation of Oracle E-Business Suite R12.2.11 and RDBMS 12cR1.

To be continued…

Passing Variables to EBS Start Scripts (without having them show up in the environment)

In earlier releases of Oracle E-Business Suite, many of the standard startup/shutdown scripts would accept a password as a command-line argument.  This gave us the ability to automate and/or script certain maintenance tasks.

E-Business Suite R12.1.3

In E-Business Suite R12.1.3, for example, you could start the appsTier with the following:

cd ${ADMIN_SCRIPTS_HOME}

./adstrtal.sh apps/${APPSPW}

E-Business Suite R12.2

When we get to E-Business Suite R12.2, the startup procedure is pretty much the same, but the command line arguments are no longer there.  To get around this, we’re told to pass things on the command line u sing the echo command.  Per MOS 1902776.1, the recommendation is:

cd ${ADMIN_SCRIPTS_HOME}

{ echo "APPS" ; echo ${APPSPW} ; echo ${WLADMINPW} ; }|\
./adstrtal.sh @ -nopromptmsg

Although the command line is complicated, it works well. 

The Problem

However, the variables that are set will persist in the Unix environment of the adstrtal.sh script (and all processes that is spawns).

Test Script

So, to figure this out (and test our approaches), we have this simple test script:

#!/bin/bash
echo -e "\n--------------------------------------------------\n"
echo -e "Variables:\n"
echo -e "\tAPPSPW:  ${APPSPW}"
echo -e "\tAPPSUN:  ${APPSUN}\n"

echo -e "Full ENV DUMP in /tmp/env.txt"
echo -e "Searching through /tmp/env.txt for APPSUN and APPSPW"
echo -e "\n--------------------------------------------------\n"
env >/tmp/env.txt

grep "APPSPW\|APPSUN" /tmp/env.txt
echo -e "\n--------------------------------------------------\n"

We can set these variables and run the script normally:

{ echo ${APPSUN} ; echo ${APPSPW} ; }|./test.sh

--------------------------------------------------

Variables:

   APPSPW:  appspw
   APPSUN:  apps

Full ENV DUMP in /tmp/env.txt
Searching through /tmp/env.txt for APPSUN and APPSPW

--------------------------------------------------

APPSPW=appspw
APPSUN=apps

--------------------------------------------------

As you can see, the ${APPSUN} and ${APPSPW} variables are in the text file.

However, when we run the script with a different command line, we get a different result.

{ echo ${APPSUN} ; echo ${APPSPW} ; }|env -u APPSPW bash ./test.sh

--------------------------------------------------

Variables:

   APPSPW: 
   APPSUN:  apps

Full ENV DUMP in /tmp/env.txt
Searching through /tmp/env.txt for APPSUN and APPSPW

--------------------------------------------------

APPSUN=apps

--------------------------------------------------

The Solution

To get around that problem, we can actually DELETE the variables from the environment.

cd ${ADMIN_SCRIPTS_HOME}

{ echo "APPS" ; echo ${APPSPW} ; echo ${WLADMINPW} ; }|\
 env -u APPSPW -u SYSTEMPW -U WLADMINPW bash ./adstrtal.sh @ -nopromptmsg

The command line is even uglier. We still have ${APPSPW}, ${SYSTEMPW}, and ${WLADMINPW} in our shell, but, those variables are not inherited by the running EBS processes.

E-Business Suite 12.1 is now Certified on OEL7 and RHEL7

New this week from Steven Chan’s blog:

https://blogs.oracle.com/stevenChan/entry/oracle_e_business_suite_release5

One thing that Steven’s blog posting mentions that deserves specific emphasis is that Oracle Database 11.2.0.4 and 12.1.0.2 are ALSO certified on OEL7/RHEL7 [see MOS 1304727.1].  Please note that the certification is specific to the version of the database.  Most notably that 11.2.0.3 and 12.1.0.1 appear to be excluded from this certification.  As always, be sure to pay close attention to the certification status of your various components when planning any installation/upgrade.

It’s also important to note that, while there is a 32-bit version of RHEL6 (and E-Business Suite 12.1.3 is certified on it), there isn’t a 32-bit version of RHEL7.  This is important and, at the same time, it isn’t.  First of all, it’s highly unlikely that anyone is still using 32-bit hardware.  (Or that they ever were, for E-Business Suite on Linux).  Yes, it’s true that the appsTier components of E-Business Suite 12.1 are still 32-bit, running them on a 64-bit Linux requires only minor adjustments.  The bulk of which involve dependencies on kernel settings and Linux packages.

So, with all of this out there… Go forth and upgrade!

— James

Listing Installed Packages on Linux

First, let me mention that, unless otherwise indicated, when I blog about Linux it will be about the RPM-based distributions that are certified with the Oracle Database (RedHat Enterprise Linux, Oracle Enterprise Linux).

Normally, when you’re looking to see which packages are installed on Linux (RedHat, Oracle, CentOS), you would use this command:

rpm -qa

Unfortunately, the standard output of that command omits alot of useful information. It may or may not indicate if you have the 32 or 64 bit version of a package installed, for example.

So, for a command that will show you which packages are installed in a format that looks like the name of the RPM file:

rpm -qa --queryformat \
"%{NAME}-%{VERSION}-%{RELEASE}.%{ARCH}.rpm\n" |\
sort > pkglist_`date +%Y%m%d-%H%M`.txt

— James

E-Business Suite R12.1.1 is Certified on Oracle Linux 6!

Back in February, I blogged about the pending certification of Oracle E-Business Suite on Oracle Enterprise Linux 6 and RedHat Enterprise Linux 6. In that blog post, I noted that the certification announcement was “planned” but, of course, Oracle doesn’t provide dates.

Well, guess what? The waiting is finally over. As these things go, the announcements come out in parts.

First, on March 22, 2012, Oracle announced that Oracle Database 11gR2 and Fusion Middleware 11gR1 were certified. (The press release can be found here.)

And today (April 4, 2012), through the Oracle E-Business Suite Technology blog (known to many of us as “Steven Chan’s blog”), we have the E-Business Suite announcement (available here)!

While this is fantastic news, read the announcements carefully!

These certifications are ONLY for Oracle Enterprise Linux 6 on the x86-64 with the Unbreakable Enterprise Kernel (UEK) version 1.

These certifications are ONLY for Oracle Enterprise Linux 6 on the x86-64 with the Unbreakable Enterprise Kernel (UEK) version 1.

According to the database announcement, certification on RedHat Enterprise Linux 6 (and Oracle Enterprise Linux 6 [without UEK]) should be available within 90 days. I would expect the E-Business Suite R12 announcement to follow shortly behind.

What about other E-Business Suite releases? At this point, I have no actual information. But, I can speculate (with a good degree of certainty) that you won’t see any 11.5.10.2 certifications against OEL/RHEL 6. E-Business Suite 11.5.10.2 is currently in Extended Support. Even though the support fees have been waived (through the end of Extended Support, November 30, 2012), Oracle doesn’t typically certify new platforms once a product goes into Extended Support. (A more detailed discussion of Oracle’s recent support announcements can be found here.)

The other question mark out there is OEL/RHEL 6.0 on x86-32. Personally, if you’re implementing R12 or upgrading to R12 on Linux, you should be using an x86-64 distribution on x86-64 hardware. However, certification on x86-32 is also forthcoming.

As always, be sure to read/follow the relevant notes through the Certify Tab on My Oracle Support before you start any project to make sure that the combination of components you intend to use are, in fact, certified. These certifications will also detail the various always steps, operating system parameters, packages, and even patches specific to your combination that you will need to follow.

All of this is excellent news, as the OEL and RHEL 5.x line is getting pretty long in the tooth and is approaching it’s end of life.

Now… when will we get that R12.2 announcement? Collaborate, maybe? OpenWorld? … the waiting continues.

– James

UPDATE 6/27/2012:  Oracle has just announced certification for Oracle Enterprise Linux 6.0 (x86-32), Red Hat Enterprise Linux 6.0 (x86-32 and x86-64), and  Novell SUSE Linux Enterprise Server (SLES) version 11 (64-bit).  See Steven Chan’s blog for more details:  https://blogs.oracle.com/stevenChan/entry/oracle_e_business_suite_release3

Stupid Unix Tricks… Part 1

So, let’s say you’re trying to figure out if the database (or E-Business Suite) is down. Now, the logical way is use the Unix commands ps and grep to check for a particular process. Generally speaking, we would look for the SMON process for that particular instance.

However, maybe you’re looking for something else that has multiple processes and you want to see that they’re all shut down.

We’re going to use a database as an example (largely because I assume you are familiar with the database). The basic command would be:

ps -ef|grep ora_smon_PROD
oracle 10445 6643 0 15:32 pts/0 00:00:00 grep ora_smon_PROD
oracle 19710 1 0 Feb28 ? 00:00:36 ora_smon_PROD

However, the problem here is that it also gives our grep command. To get around that, we can strip it out using grep -v grep (which would strip from our results anything that contains the string grep). Additionally, maybe we want to get something we can use in an if statement. The simplest way to do that is to count the number of lines returned by the command. That can be done by piping the output through the wc -l command. Our final command will look like this:

ps -ef|grep ora_smon_PROD|grep -v grep |wc -l

So, assuming that we just wanted to look for SMON we can build our if statement like this:

if [ `ps -ef |grep ora_smon_PROD|grep -v grep |wc -l` -gt 0 ]; then
   echo "SMON is UP"
else
   echo "SMON is DOWN"
fi

Now, let’s assume that you want to check for PMON as instead:

if [ `ps -ef |grep ora_pmon_PROD|grep -v grep |wc -l` -gt 0 ]; then
   echo "PMON is UP"
else
   echo "PMON is DOWN"
fi

But what if you wanted to make sure that they were BOTH down?

if [ `ps -ef |grep -e ora_pmon_PROD -e ora_smon_PROD|grep -v grep |wc -l` -gt 0 ]; then
   echo "PMON and SMON are UP"
else
   echo "PMON and SMON are DOWN"
fi

The key here is grep -e. Because grep allows you to use the -e flag more than once per invocation, you can specify multiple strings to search for. Multiple -e strings are treated as a logical “or” by grep when it’s parsing the input.

As with everything, your results may vary. Different platforms may have different versions of grep with different capabilities. This example was tested on Linux.

– James

Password-less Login Using SSH Pre-Shared Keys

Way back when I started working with Unix (otherwise known as “the olden days” or “days of yore”), one of the tricks we used was a concept known as “remote login” and the “Berkeley R commands”. This was based on a number of things, most of them depending on either the /etc/hosts.equiv or the ${HOME}/.rhosts file to establish the trusting relationship. Configuring these would allow you the ability to do some really neat things. Among them, copying files from one host to another using a command like rcp /tmp/file user@remotehost:/tmp/file without being asked for a password. This made for some really neat scripting opportunities and made it much easier to manage multiple systems.

Unfortunately, the Berkeley “R” commands are notoriously insecure. The way that the trusting was done was based entirely on the username and hostname of the remote user on the remote host. Literally, you told the server to trust “jmorrow@remotehost.mydomain.com”. The problem with this is that all that was required was knowledge of the trusting relationship. All you had to do was set up a machine named “remotehost.mydomain.com” and create a “jmorrow” user on it. Then you could go anywhere that that trusting relationship allowed.

Fortunately for us, the cool features that were introduced by the Berkeley “R” commands are implemented much more securely in the SSH protocol and toolset.

The SSH Protocol can use pre-shared keys to establish trusting relationships. In this case, each node has both a public and a private key. When the client talks to the server, the client offers a ” key”. The server, which maintains a list of trusted “public keys”, then compares that key to it’s database to determine if it actually trusts the client. If the client passes the test, then it is allowed in without any further challenge. This can be very useful for administrators, automated file transfer, also for scripting interactions between hosts. Note that this is not a “Machine A” trusts “Machine B” relationship. It is “user@machinea” trusts “user@machineb”.

For the purposes of this article, the “server” is the node that you are logging into from the “client”. So, the “server” is the one that is doing the trusting. The terms “server” and “client” refer only to the role being played by each component in the ssh communications session. I should also mention that Oracle Real Application Clusters (RAC) depends on this relationship as well.

Generate your public/private key pairs [Both Client and Server]

The server (user@host) needs to have one, and each client (user@host) that is being trusted needs to have one.

Execute these two commands (in a Unix/Linux environment) to create both your rsa and your dsa keys. You will be prompted for a location to store the files (typically under ${HOME}/.ssh), and for a passphrase. In all cases, it’s ok to accept the defaults.

ssh-keygen -t rsa
ssh-keygen -t dsa

If you know you don’t want to use a passphrase, you could generate the keys with these two commands:

ssh-keygen -t rsa -f ${HOME}/.ssh/id_rsa -N ""
ssh-keygen -t dsa -f ${HOME}/.ssh/id_dsa -N ""

Transfer the public key files from the client to the server

I prefer to make sure that I have a uniquely named copy of the public keys (makes it easier to transfer to another box when first establishing the relationship).

cd ${HOME}/.ssh
ls -1 id_[dr]sa.pub |while read LINE
do
cp ${LINE} ${LINE}.`whoami`@`hostname -s`
done

Now copy these files to the server:

scp ${LINE}.`whoami`@`hostname -s` trustinguser@trustingserver:.ssh/.

Copy the public keys you’re trusting into the authorized_keys file

Here, we’ll need to put those keys into the authorized_keys file. Do this for each of the files that you transferred in the previous step.

cd ${HOME}/.ssh
cat filename >> authorized_keys

Make sure permissions are correct

If the permissions on these files are too open, the trusting relationship will not work. Here are my recommendations:

chmod 600 ${HOME}/.ssh/auth*
chmod 700 ${HOME}/.ssh
chmod 644 ${HOME}/.ssh/id_[dr]sa.pub*
chmod 600 ${HOME}/.ssh/id_[dr]sa

Now, you should be able to ssh from the client to the server witout being prompted for a password.

— James

Certification on Oracle (RedHat) Enterprise Linux 6?

One of the questions that getting with increasing frequency is “Can we upgrade our systems to Oracle (or RedHat) Enterprise Linux 6”. 

As always, my first response is to jump on My Oracle Support, navigate to the “Certifications” tab, and attempt to query up the certified platforms for the Oracle Server (RDBMS). In my experience, the Oracle Server is usually among the first products certified on any (major) platform. 

So, I go to the Certify page on MOS, and it appears that Oracle (or RedHat) Enterprise Linux 5 is the most recent certified with the current version of the database (11.2.0.3).

Now, I’m thinking to myself, “Hasn’t it (Linux 6) been out for some time?”. Turns out, it has. RedHat Enterprise Linux 6 was initially released in November, 2010.

So, a with a little effort (“the Google knows all”), I was able to find a few tidbits:

First, from a RedHat Blog Post back in August, 2011:

The certification process we conducted with Oracle 11gR2 and Red Hat Enterprise Linux 6 is the same process we have successfully completed a number of times with earlier Red Hat Enterprise Linux releases. With those releases, Oracle’s certification approval process took about six weeks from the day we submitted test results to Oracle to the day that Oracle posted the certification on their MetaLink support site (https://support.oracle.com). Based on this experience, we would expect certification of the 11gR2 database on Red Hat Enterprise Linux 6 to occur sometime in CYQ4 of this year. We look forward to Oracle’s response and to working with them to complete this certification process. In the interim, customers may also contact Oracle directly for updates on the certification status at gcp-customerfeedback_us@oracle.com.

In addition to the certification testing described above, we perform ongoing and extensive testing on Oracle 11gR2 at every minor release of Red Hat Enterprise Linux. Consequently, we confidently recommend the deployment of Oracle 11gR2 in Red Hat Enterprise Linux 6 production environments today.

And also, from a note on My Oracle Support:

Database Client or Database Server Install on Red Hat Enterprise Linux 6 (RHEL6) or Oracle Linux 6 [ID 1350000.1]

At the time of the last update of this article (30-Jan-2012), Red Hat Enterprise Linux 6 (RHEL6) and Oracle Linux 6 are not certified or supported for use with any Oracle Database version. Be sure to use only certified/supported combinations of Database version and OS version, which you can find under the Certifications tab of My Oracle Support (MOS). Please note that although Certify used to have a status of “Planned” for Red Hat Enterprise Linux 6 (RHEL6) / Oracle Linux 6, this does not imply any guarantee of certification. Also, please do not open a Service Request asking when the OS will be certified. Any additional information will be added to Certify when it becomes available, and Support is unable to provide any more information than what is there. The Certify information on MOS is the only official source for Oracle certification.

So there you have it. Oracle Server (and, consequently, E-Business Suite) are NOT currently certified to run on either Oracle Enterprise Linux 6.x or on RedHat Enterprise Linux 6.x. Unfortunately, anyone you ask at Oracle will basically tell you that “due to revenue recognition rules, we can’t say”.

What I can tell you is, despite the “this does not imply any guarantee of certification” message, I think it highly likely that they will certify it (eventually). Especially given Oracle’s large Linux installed base (and the fact that Oracle’s own Linux distribution has so much in common with RedHat’s).

Meanwhile… we wait.

— James

UPDATE:  I sent a few emails and heard back from some people at Oracle.  From the sound of it, a certification announcement for Oracle Enterprise Linux 6 is being “planned” but, naturally, they can’t provide any date information.  But, when you combine this with the information above, it leads me to believe that some certification might be coming sooner rather than later.  Let’s keep our fingers crossed!

UPDATE #2:  Oracle has now (22 March, 2012) certified 11.2.0.3 against Oracle Enterprise Linux 6 (Using the Unbreakable Enterprise Kernel V1) for x86-64 platforms. (Press Release).  They have also announced that certification against RHEL 6 will be complete within 90 days.

UPDATE #3 (6/27/2012):  Oracle has just announced certification for Oracle Enterprise Linux 6.0 (x86-32), Red Hat Enterprise Linux 6.0 (x86-32 and x86-64), and  Novell SUSE Linux Enterprise Server (SLES) version 11 (64-bit).  See Steven  Chan’s blog for more details:  https://blogs.oracle.com/stevenChan/entry/oracle_e_business_suite_release3