Installing Oracle Applications 11i (11.5.7) on Linux

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.

Platform

Dell Dimension 4550, 2.6 GHz, 512 Mb RAM, 80 Gb hard drive. Complete installation of the Apps 11.5.7 VISION database and O/S used about 70% of the 80Gb drive. We make no suggestion one way or the other that this platform would be suitable for a production environment.

Which O/S

Well, we tried both. In our opinion we prefer Redhat. The reasons for this are both trivial and serious. With SUSE we could not find a way to set the screen refresh frequency off of its 60Hz default. This drove us blind - ok, this is reasonably trivial as the platform will be used as a server. Repeated attempts to contact SUSE support (we had a Purchased copy of SUSE 8.1 Professional) met with absolutely no response. Other than an automated ticket number to say that our request had been received we didn't even get (despite repeated requests over a period of weeks) a returned email to say they wouldn't provide assistance, I regard this as very serious.

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.

  • The APPL_TOP CD's. There will be several errors in various scripts when running these CD's and unless you are monitoring the logs very closely you will not see them happening. It's OK though as these failures do not cause the installation to stop (it doesn't even notice actually). Provided you sorted out the jdk and the listener earlier on you should be able to fix these little problems by re-running the files manually. Just finish the installation and run the install off the end.

    In the final completion checks we never could get the check that confirmed that the database was up to work. The database was actually fine - just the check itself didn't want to work. So we ignored it - all of the other completion checks were fine.

    In the log we noticed the /d01/oracle/viscomn/admin/install/VIS/adgenjky.sh script did not execute correctly. The problem was the line jinitver=`printf "1.1.8.16" | sed 's/.//'` did not work correctly on our system (both Redhat and SUSE) replacing it with jinitver=11816 (which is really what it wanted to do) and manually re-running the file using the same command line as was recorded in the log file moved things along agreeably.

    We had to manually start the Oracle Fulfillment Server. The path was wrong in the install. Run the command:

    /d01/oracle/viscomn/admin/scripts/jtffmctl.sh start APPS/APPS
    
    the installer tries to run
    /d01/oracle/viscomn/admin/scripts/VIS/jtffmctl.sh start APPS/APPS
    
    which does not exist.

    Post Installation

  • Set up the oracle account by putting a call to . /d01/oracle/visappl/APPSORA.env (note the .) in the .bash_profile. Not strictly necessary but it does set up the environment variables nicely whenever you log in.

  • Is your DBC file OK. You will want to make sure the Java Runtime Environment is operational and the DBC file can properly connect to the database. Here's a nifty test to run in a Linux terminal session (assuming you set up the .bash_profile above).

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

  • Try to Connect. You should be able to hit the Oracle Applications main page on the URL
    http://<LinuxServerName>:8002/
    and the help at
    http://<LinuxServerName>:8002/OA_HTML/jsp/fnd/fndhelp.jsp?dbc=/d01/oracle/visappl/fnd/11.5.0/secure/<DBCFileName>.dbc

    You might think that if the above works then everything works? Well no, not necessarily, you have yet to login. All the above tells you is that the Apache server is happy and the JDK is workable.

  • Try to Login. Hit the URL
    http://<LinuxServerName>:8002/OA_HTML/US/ICXINDEX.htm
    and login as guest/oracle. Assuming that goes well try logging in as SYSADMIN/SYSADMIN. If that too goes well try navigating to the System Administrator options visible as a link far down the page under the SYSADMIN login.

    If on your travels you get complaints about ActiveX security settings from your browser you'll probably want to have a look at note 125924.1. If you are getting FRM-92950 messages you might wish to view note 175332.1.

  • Where are my concurrent managers. You'll soon notice that you don't have any concurrent managers started. The non-existence of the concurrent managers can readily be detected by the absence of any FNDLIBR processes in the output of a ps -eawf | grep oracle command.

    The concurrent managers are kicked off by a command like:

    /d01/oracle/viscomn/admin/scripts/VIS/adcmctl.sh start APPS/APPS
    
    but this does not seem to work (although the script returns without error) and only one FNDLIBR process appears and it soon dies. A quick look through the logs indicates that things are very unhappy and there are numerous notes to the effect that is <machine.domain> registered for concurrent processing. If you see this you have run into a bug and need to patch your apps installation. Check out this page and look up patch 2401012 (11.5.7 only) on metalink. Applying this patch and kicking off the start command shown above got all of the concurrent managers going just fine.

  • Tests and Diagnostics. You should find a number of basic connectivity tests at the URL
    http://<LinuxServerName>:8002/OA_HTML/jtfqalgn.htm
    and there are a number of SQL tests you can run to test various things work ok. Check out notes 167000.1 and 179661.1 on metalink.