By John Piwowar [
blog |
twitter ]
This is the second post in my "Installing E-Business Suite" series, where we actually install the software. Hopefully by now you've read part 1, downloaded the software, and configured your Linux server. Thanks again to Chet for the opportunity to share on his blog; I'm enjoying this guest spot on ORACLENERD Inc's New Media Empire (2.0!). And now, welcome to screenshot village; we hope you enjoy your stay.Part 1 --> Part 2 -->
Part 3 -->
Part 4The Oracle Applications Rapid Install Wizard, more commonly called RapidWiz, drives the EBS installation process. If you're accustomed to using the Oracle Universal Installer, you'll find that RapidWiz "feels" a bit different, but it still has that comforting grey, "Hi, I'm a Java-based Oracle software installer!" look to it.
Step 1: Launching RapidWizLog in to your Linux server's desktop as root, not oracle. Open a terminal window and change to the startCD/Disk1/rapidwiz subdirectory of the software staging area
Run the rapidwiz utility in that directory:
[root@londo R12stage]# cd startCD/Disk1/rapidwiz/
[root@londo rapidwiz]# ./rapidwiz
You should see a few launch messages in your terminal window, and the welcome screen of the installer will appear. Click Next:
Step 2: Select installation typeIn the Wizard Operations window, make sure that "Install Oracle Applications" is selected, but do
not check the Express Install box. Click Next:
Step 3: OCM configurationIn the Oracle Configuration Manager window, leave all the fields and options blank, and click Next. OCM is not a complication we need right now. :-)
Step 4: Configuration ChoiceSince this is a new install, select the first option ("Create a new configuration") in the Configuration Options window and click Next.
Step 5: Port pool assignmentSelect a number between 0 and 99 from the
port pool list in the Global System Settings window, then click Next. Doesn't matter which number; choose your favorite. In past releases I've had issues where selecting 0, 1, or 99 has caused strange problems later, but those were pretty obscure and not consistently repeatable, so don't let that stop you from living on the edge. ;-)
Step 6: Database node configurationNow we're finally getting to the fun bits! In the Database Node Configuration window, verify that the following fields have correct values:
- Database type is "Vision Demo Database"
- Hostname and domain name match the host and domain names on your Linux server. If you've configured this correctly in /etc/hosts and /etc/sysconfig/network, RapidWiz should pull the correct values.
- The Operating System value should match your server's platform (Linux x86 or Linux x86-64)
Change the following fields as necessary:
- Database SID: You can leave this at the default (VIS), or change it if you prefer.
- Database OS user: The OS user you created in part 1 as the owner of the Oracle software (e.g. oravis)
- Database OS group: Change to oinstall
- Base Directory: This should be set to a directory in the Very Large Mount Point(tm) that you created in part 1. RapidWiz doesn't exactly conform to the OFA standard, but if you're picky about such things, you can click the "Edit Paths" button for finer control over where things go. I'm usually picky, but for the sake of saving you a few more screenshots, I'm letting RapidWiz decide where to file everything this time. :-)
Note: If your specified base directory doesn't exist, you'll need to create it. Um, whoops. Actually, I intentionally skipped that step just so you could get an example of what error conditions you might encounter during configuration. That's me, taking one for the team. It's just the sort of guy I am.
Make sure to change the ownership, and to grant write permissions to the oinstall group:
[root@londo rapidwiz]# cd /u01
[root@londo u01]# mkdir -m 775 -p ebs/R12VIS
[root@londo u01]# chown -R oravis:oinstall ebs
[root@londo u01]# ls -lR ebs
Click OK once you've created the base directory, make sure the installer has retained your other configuration settings, and click Next.
Step 7: Applications node configurationThe next window, "Primary Applications Node Configuration," takes most of its values from the database node configuration. You'll need to change the values of
Apps OS user and Apps OS group to match the ones created in part 1 of this series. Everything else should be fine; you'll just need to verify. Again, if you want to tinker with specific locations in the installation, you can click the Edit Paths button, but that's beyond the scope of these instructions. Oh yeah, and click Next when you're done.
Step 8: Node information reviewThe Node Information window presents a review of the servers you've configured so far, and offers the option to add an additional server. Adding a server would be useful in the case of multi-node installations, but for now, just click (what else?) Next:
Step 9: Pre-install system checksRapidWiz will pop up a window showing the system checks it is performing prior to installation. Basically, it's making sure that the necessary ports are open for the applications and database to run, that there's enough disk space to install, that it can write to all its directories, etc. After the checks are done, a Pre-Install Checks results window will appear. Hopefully you'll see all green checkmarks, as below. If you see red X's next to any of the test categories, click on the X to see a log from the test run, find and fix the errors, and click the Retry button to re-run the tests. Once all tests have been run successfully, click Next.
Step 10: The actual installation partClick Next at the Install Review window, then Yes in the inevitable "are you sure you want to install?" box, and you're off to the races! Or maybe off to run some errands while
blue bars crawl across the installer windows for a few hours, whichever. You'll notice that the terminal window from which you launched RapidWiz will display some information about where it's writing out log files. Hopefully we won't need those, because the installation will just go swimmingly, right?
Step 11: Post-install checksAfter a while (probably a few hours, depending on how speedy your server is) the installation will complete, and post-install checks will begin. If some of the post-install checks are listed as failed initially, don't be too worried. The initial startup of E-Business Suite can pretty resource-intensive, and it's not unusual for some of the post-install checks to time out waiting for responses from web pages, or for application server components themselves to time out when starting up. Keep in mind that you're installing software intended to run on server-class hardware, and your server might be under spec somewhere (disk speed, CPU, memory).
Here's what my post-install checks looked like the first time around. Ouch. As with the pre-install checks, you can click on the icons to see more about the failed checks. I'll spare you all 5 screenshots, but in this case, all the messages have the same theme: HTTP server taking too long to respond.
Step 12: A troubleshooting interludeMy poor 2-CPU "server" had a load average above 10 when the post-install checks first ran, and a ridiculous level of I/O wait (thanks, 5400RPM hard drive!), so the first thing I did was to wait until the system has settled down a bit, and then click the Retry button. Unfortunately, the outcome of the post-install checks didn't change, so I had to look into fixing the web server. What follows may not be applicable to your install situation, but it does provide a small taste of basic Oracle Applications troubleshooting, so please bear with me. If you get bored, or if your post-install checks were all successful, you can always skip ahead to step 14. ;-)
The first thing I did was to log in as the owner of the Oracle Applications software, applvis in this case. Then, I set up the OS environment to be able to better navigate the various sections of the Apps filesystem. You'll often hear this called "sourcing the Apps environment."
[root@londo ~]# su - applvis
[applvis@londo ~]$ . /u01/ebs/R12VIS/apps/apps_st/appl/R12VIS_londo.env
If you don't feel like digging through the documentation to find out where the Apps environment file should be for your system, you can find the value from the result of the "Environment File" post-install check. The output from that check lists a number of environment files; the one that's relevant here is the "
APPL_TOP environment file." Using the newly-defined environment variables, I checked the status of the 10g Application Server components and tried to restart the web server:
[applvis@londo ~]$ $ADMIN_SCRIPTS_HOME/adopmnctl.sh status
You are running adopmnctl.sh version 120.6
Checking status of OPMN managed processes...
Processes in Instance: R12VIS_londo.londo.local
---------------------------------+--------------------+---------+---------
ias-component | process-type | pid | status
---------------------------------+--------------------+---------+---------
OC4JGroup:default_group | OC4J:oafm | 10677 | Alive
OC4JGroup:default_group | OC4J:forms | 12390 | Alive
OC4JGroup:default_group | OC4J:oacore | 10505 | Alive
HTTP_Server | HTTP_Server | N/A | Down
adopmnctl.sh: exiting with status 0
adopmnctl.sh: check the logfile
/u01/ebs/R12VIS/inst/apps/R12VIS_londo/logs/appl/admin/log/adopmnctl.txt for more information ...
This confirms that the web server is the only component that's currently failing, and the other app server components of the system are starting as expected.
[applvis@londo ~]$ $ADMIN_SCRIPTS_HOME adapcctl.sh start
You are running adapcctl.sh version 120.7.12010000.2
Starting OPMN managed Oracle HTTP Server (OHS) instance ...
opmnctl: opmn is already running.
opmnctl: starting opmn managed processes...
================================================================================
opmn id=londo.local:6255
0 of 1 processes started.
ias-instance id=R12VIS_londo.londo.local
++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
--------------------------------------------------------------------------------
ias-component/process-type/process-set:
HTTP_Server/HTTP_Server/HTTP_Server/
Error
--> Process (index=1,uid=1625958549,pid=26727)
failed to start a managed process after the maximum retry limit
Log:/u01/ebs/R12VIS/inst/apps/R12VIS_londo/logs/ora/10.1.3/opmn/HTTP_Server~1.log
adapcctl.sh: exiting with status 0adapcctl.sh: check the logfile
/u01/ebs/R12VIS/inst/apps/R12VIS_londo/logs/appl/admin/log/adapcctl.txt for more information ...
That doesn't look so great, but at least I have a log file to review:
[applvis@londo ~]$ tail /u01/ebs/R12VIS/inst/apps/R12VIS_londo/logs/ora/10.1.3/opmn/HTTP_Server~1.log
--------
09/12/05 19:28:55 Start process
--------
/u01/ebs/R12VIS/inst/apps/R12VIS_londo/ora/10.1.3/Apache/Apache/bin/apachectl startssl: execing httpd
/u01/ebs/R12VIS/apps/tech_st/10.1.3/Apache/Apache/bin/httpd:
error while loading shared libraries:
libdb.so.2: cannot open shared object file: No such file or directory
That missing shared object library file is the most likely culprit. This often, but not always, means that there's a required OS package missing. In this case, a review of the installed packages on my server didn't show anything missing, so I turned to Google and My Oracle Support. I quickly found a handful of references in OTN forums and Oracle's non-EBS documentation to a quirk of installing R12.1 on 64-bit Oracle Enterprise Linux 5. One symlink later, and I was on my way:
[root@londo ~]# ln -s /usr/lib/libgdbm.so.2.0.0 /usr/lib/libdb.so.2
[applvis@londo ~]$ $ADMIN_SCRIPTS_HOME/adapcctl.sh start
You are running adapcctl.sh version 120.7.12010000.2
Starting OPMN managed Oracle HTTP Server (OHS) instance ...
opmnctl: opmn is already running.
opmnctl: starting opmn managed processes...
adapcctl.sh: exiting with status 0
adapcctl.sh: check the logfile
/u01/ebs/R12VIS/inst/apps/R12VIS_londo/logs/appl/admin/log/adapcctl.txt for more information ...
[applvis@londo ~]$ $ADMIN_SCRIPTS_HOME/adopmnctl.sh status
You are running adopmnctl.sh version 120.6
Checking status of OPMN managed processes...Processes in Instance: R12VIS_londo.londo.local
---------------------------------+--------------------+---------+---------
ias-component | process-type | pid | status
---------------------------------+--------------------+---------+---------
OC4JGroup:default_group | OC4J:oafm | 10677 | Alive
OC4JGroup:default_group | OC4J:forms | 12390 | Alive
OC4JGroup:default_group | OC4J:oacore | 10505 | Alive
HTTP_Server | HTTP_Server | 29299 | Alive
After that, the post-install checks all came back green. Which is good, because I hadn't clicked Next in a while:
Step 14: Grand Finale(what, you thought I'd risk the whole exercise by ending on step 13?)And now, after hours of downloads and nigh-endless unzipping, the EBS install is done! That tempting "Connect to Oracle Applications Release 12.1.1" button may work, but if it doesn't, don't despair. Click Finish, open a web browser, and go the URL http://
server.domain:80nn. The value for
nn is the "port pool" value you selected in the early stages of the installation. Hopefully you know what "server" and "domain" are. :-) For example, when I browse to http://londo.local:8055, I am redirected to the main login page for EBS:
If you want to start looking around a little bit, the "superuser" for Oracle Applications is SYSADMIN, and the default password for the account is the same as the username. If you attempt to launch any of the Oracle Forms-based parts of the Apps interface from a browser on your Linux server, you may run into trouble. The EBS Forms interface is famously finicky on Linux-based browsers; I usually access EBS from browser on a Windows or OS X desktop, rather than from Linux, but the OTN forums are full of tips on how to get EBS Forms working on Linux. I'll try to dig up some links for the next post, or you can chime in with comments if you've already been down that road.
Thanks for following along! I hope that your installation experience is even more painless than this one. In part 3, I'll cover a few basic topics following the theme, "great, it's installed, now what do I do?"
References
