[ Net 2000 Ltd. Home | Contact Net 2000 Ltd. | Useful Net 2000 Ltd. Software ]

This page describes the steps used to install Oracle Applications 11.5.7 on SUSE Professional 8.1 and Redhat Linux 8.0.

Disclaimer: Apps 11.5.7 is not certified or supported on either SUSE Professional 8.1 or Redhat Linux 8.0. Presumably as an Oracle professional attempting the install you are already aware of this and are fully cognizant of the consequences.

This page is purely intended to be a summary of our experiences - no guarantee is given as to its accuracy - your mileage may vary. We offer it to the net simply because we would really have appreciated being able to read something like this prior to embarking on our installation process. What you read below is a distillation of many, many separate installation attempts.

For the most part, the following comments apply generically to both Redhat and SUSE. A note will be made if issues exist were found with one O/S and not another. Any reference below made to Redhat means the generically downloadable version 8.0 and any reference to SUSE refers to a purchased version of SUSE 8.1 Professional.

Feel free to email me (Dale Edgar) with your comments and suggestions. I will try to incorporate them as best I can.

Platform

Which O/S

Both SUSE and Redhat installed very easily, found and supported the installed video card (see the SUSE caveat above) and ethernet hardware and generally worked very agreeably. We did not try to contact Redhat support since we were using the version downloaded off of their web site and in any event had no major reason to do so.

Note: To get a generic telnet daemon going on the Redhat platform you have to check the Network Servers option during the install (it isn't the default) or do it afterwards using the Package Manager. We could never figure out how to get a telnetd going with SUSE - this was another issue they ignored our emails on.

Installation: Before You Begin

Helpful Note Reader MG reports that he had to enter the following commands just to get the RapidWiz to run. We did not have to do this - but include them here in case they might be useful.

$export LD_ASSUME_KERNEL=2.2.5 
$cd /usr/i386-glibc21-linux/bin
$./i386-glibc21-linux-env.sh

Get the Java SDK You really need this! SUSE includes a sort of half version that contains just enough stuff to trick the installer into thinking it is there but which causes major problems later. Redhat doesn't have it at all. We installed j2sdk-1_3_1_07-linux-i586.bin available free from http://java.sun.com.

The JRE did not seem to be necessary as the 11.5.7 install put a JRE 1.1.8 in where necessary.

We installed the j2sdk into the /usr/java/jdk1.3.1 directory. This is the default directory assumed by our 11.5.7 rapidwiz installer. We found it best not to try to put this anywhere else. We ignored the jdk.1.4.x versions available on the Sun website, operating on the theory that if that if 1.3.1 is what rapidwiz claims it wants then that is what it is going to get.

You need the libdb.so.3 library or the Apache web server will refuse to start. Note: This means exactly libdb.so.3 not libdb.so or libdb.so.2 or any other flavour. If you haven't got it then get the compat-db-3.3.11-3.i386.rpm RPM and install it - you can find a copy on http://www.rpmfind.com or dig around on Google. We put ours in /lib/libdb.so.3 and the Apache webserver didn't disagree.

You need the libXm.so.2 library or the forms runtime executable f60webmx cannot be started by the forms server (see Note 116804.1). Redhat definitely does not have this (not sure about SUSE). The libXm.so.2 library ships with the Motif software (which is not a freebie) however you can pick up a workable replacement in the lesstif-0.93.36-1.i386.rpm file from the LessTiff website.

Note: We had trouble getting this RPM to installed using the traditional rpm -ivf command so rather than argue with it we just did a quick

rpm2cpio lesstif-0.93.36-1.i386.rpm | cpio -iv --makedirectories

and copied the libXm.so.2 into /usr/X11R6/lib. Make sure your default directory is in the /tmp (or somewhere safe) area before running the rpm2cpio command because it will create an entire tree of files immediately below the current directory.

Create the oracle account. You need this as this is the account from which the installation must be run.

Create the installation filesystems. We accepted the installer defaults and slapped it right into /D01, /D02, /D03, /D04 and /D05. Now we don't know that putting them elsewhere would have caused trouble - but things were touchy enough without making trouble for ourselves. The owner was the oracle account and the group was dba. Permissions were 766.

Installation: Doing it

The discussion below concerns the installation of the VISION sample database. The PROD and TEST databases are not much different.

Install and mount the rapidwiz installation CD as the oracle user. Run the rapidwiz installer from an ordinary terminal session on the Linux console. This avoids the necessity of configuring an X Server and doing it of off a remote PC. When launching rapidwiz give it a full path <mount point>/rapidwiz/rapidwiz. Do not have any terminal sessions using the CD as the current default directory or you will not be able to unmount or eject the CD. The rapidwiz installer will launch an X windows session on the Linux console.

On SUSE you will probably need to enter something like export DISPLAY=:0 in the terminal session prior to running the rapidwiz installer. Also required (as root) on SUSE was an xhost +<hostname> in order to get the rapidwiz xwindow to run. Neither of these seemed to be required by Redhat.

Options. There was some talk on metalink about how on Linux the database tier and the application tier must be on separate machines. We cheerfully ignored that advice mostly because we didn't know about it until after everything was up and running. In any event although the install gave lots of problems there was nothing seemingly attributable to having the application tier and database tier on the same box.

We installed both the application tier and database tier under the user oracle so maybe that was the difference.

All other options were pretty much accepted as the default except we installed the VISION sample database rather than the PROD database the installer suggested by default.

Checks. At the end of the option stage the rapidwiz installer will perform a number of checks. All of these have to succeed - if not, fix the problem.

The 8i CD's. Both 8i CD's went through with no problems. These install 8.1.7 server binaries and re-link them. The whole process was agreeably problem free, and there was no need to mess with the LD_LIBRARY_PATH and other horrors one reads about so often on metalink. Note: if you are re-installing (and you probably will be - see below) you might need to completely drop the oraInventory directory which the installer creates in the home directory of the oracle account in order to get the binaries to link a second time. We had to do so at any rate.

The database CD's. The problems really begin here - (this section gets a bit tricky and technical). About five database CD's were requested and these install the VISION database itself. This installation is not a create of an empty DB and then a run of a multitude of scripts. It is more akin to a cloning process. Pre-populated database files are placed on disk and the control files are re-created to set everything up correctly.

Everything went fine until time came for the installer to re-create the control files. To do this it ran a script called adcrdb.sh. This script failed with listener problems when run by the installer but when run manually from the oracle account it worked perfectly. There was nothing we could do to convince the installer to proceed past this point - it saw the error and wanted to re-start from the beginning. There was also nothing we could do, despite repeated attempts, to convince the error to go away.

Extensive digging around on the net turned up several suggestions pointing to a deficient SEMMNS parameter (or similar). Adjusting these parameters had absolutely no effect - maybe it will for you. Here's a link telling you how to do it - the information is about half way through the document.

So what to do? The adcrdb.sh runs just fine manually and crashes from the installer. Well it's a bit of a sordid hack but if one can trick the installer into thinking it has run the adcrdb.sh script when really it has run just a simple stub which returns 0 (success) then one can run the real adcrdb.sh manually and proceed with the install. So thats what we did (sigh). Here's how to do it:

1. Assuming the rapidwiz installer has just failed with the adcrdb.sh listener "lost contact" problem. Find the adcrdb.sh and adsvdcnv.sh scripts and copy them off to /tmp (or somewhere) with names like 1_adcrdb.sh and 1_adsvdcnv.sh. Yes, as you guessed, the adsvdcnv.sh script has the same problems but you cannot find that out until you get past the adcrdb.sh problem. These 1_* scripts now form the versions which you will run manually.

2. There is nothing for it now but to repeat the installation. Generally this means a rm -rf * on the /D01 &etc directories and kicking off the rapidwiz again. Go through the options (and choose the exact same options) and install up to the fourth CD in the database series.

3. At this point if we put in database CD 5 and continued on we would just run into the same error again. We now replace the two dodgy scripts with stubs (of the same name) which will sit and wait for a signal and then return 0 to trick the rapidwiz installer into thinking that it has completed successfully. Here are the stubs:

   ## adcrdb.sh stub
   printf "adcrdb stub  is waiting for go.adcrdb signal"
   while :
     do
     if [ -f /tmp/go.adcrdb ];
       then
       break
     fi
     echo go.adcrdb `date`
     sleep 10
     done
   printf "adcrdb stub is finished"
   exit 0
   
   ## adsvdcnv.sh stub
   printf "adsvdcnv stub  is waiting for go.adsvdcnv signal"
   while :
     do
     if [ -f /tmp/go.adsvdcnv ];
       then
       break
     fi
     echo adsvdcnv `date`
     sleep 10
     done
   printf "adsvdcnv stub is finished"
   exit 0
   

4. The adcrdb.sh and adsvdcnv.sh scripts are stored as templates in a temporary directory and copied out immediately before they are run by the rapidwiz installer. Therefore you need to replace the templates with the stubs. Here are the commands that worked (your locations will vary):

   cp /tmp/stub_adcrdb.sh /d02/oracle/visdb/8.1.7/appsutil/template/adcrdb.sh
   cp /tmp/stub_adsvdcnv.sh /d02/oracle/visdb/8.1.7/appsutil/template/adsvdcnv.sh
   

   Make sure the copied stub files have exactly the same ownership and permissions as the rest of the shell scripts in the template directory.

5. Put in the database CD 5 and proceed. Eventually the rapidwiz installer will hit the adcrdb.sh (now replaced by a stub) and sit spinning waiting for the /tmp/go.adcrdb file to appear. You will know that it is at this point because you will cleverly have run a tail -f on the log which the rapidwiz installer places in the /tmp directory. Manually run (as the oracle user) the real adcrdb.sh script (which you stored during the last install as 1_adcrdb.sh). When complete, issue a touch /tmp/go.adcrdb command to let the stub proceed. It will always return 0 and the rapidwiz installer will proceed as if it really had done the work itself.

   Very shortly after this point the installer will hit the adsvdcnv.sh stub and you will see from the logs that it is waiing for a /tmp/go.adsvdcnv file. Similar to previously, run the 1_adsvdcnv.sh script and once it is complete and successful issue a touch /tmp/go.adsvdcnv command to release the stub and allow rapidwiz to proceed.

   At this point one can't help but wonder how much easier life would be if only Oracle Corp would put a continue button on their installer.

The Tools CD's. When you are prompted for the tools CD do not put it in! Congratulate yourself for having got through the database CD stage and realize that the listener - although it looks like it is up - is not really right and lots of stuff will fail soon if it is not fixed.

The problem appears to be that the generic listener (which listens on port 1521) is started rather than the VIS listener (which listens on port 1523). This must be fixed - or lots of later stuff will topple. Issue the following commands (as the oracle user):

. /d02/oracle/visdb/8.1.7/VIS.env   # set up the env, note the leading .
lsnrctl stop
lsnrctl start VIS

Test the connectability. If you cannot successfully connect via an oracle terminal session (having run the . VIS.env script) with a sqlplus system/manager@vis command and also via the export TWO_TASK=VIS method then things will not work later on.

Having sorted out the listener, proceed with the Tools CD's as prompted. Be aware that the installer might ask for the 9 IAS Application Server CD such and such when it really means Tools CD such and such. You cannot really get this wrong as the rapidwiz installer knows what it wants (even if it doesn't ask for it correctly) and will accept no substitutes until you get it right.

/d01/oracle/viscomn/admin/scripts/jtffmctl.sh start APPS/APPS

/d01/oracle/viscomn/admin/scripts/VIS/jtffmctl.sh start APPS/APPS

jre oracle.apps.fnd.security.AdminAppServer APPS/APPS STATUS DBC=/d01/oracle/visappl/fnd/11.5.0/secure/<DBCFileName>.dbc

http://<LinuxServerName>:8002/

http://<LinuxServerName>:8002/OA_HTML/jsp/fnd/fndhelp.jsp?dbc=/d01/oracle/visappl/fnd/11.5.0/secure/<DBCFileName>.dbc

http://<LinuxServerName>:8002/OA_HTML/US/ICXINDEX.htm

/d01/oracle/viscomn/admin/scripts/VIS/adcmctl.sh start APPS/APPS

http://<LinuxServerName>:8002/OA_HTML/jtfqalgn.htm