Forum OpenACS Q&A: Re: Improvements for OpenACS Oracle install docs

Collapse
2: Re: Improvements for OpenACS Oracle install docs (response to 1)
Posted by Andrew Piskorski on 12/13/02 07:17 AM

Installing Oracle 8.1.7:

External Links:

TODO: You can't back out an Oracle patchset, you have to reinstall. So test if 8.1.7.4 has the INSO filter Intermedia problems Janine Sisk mentioned, then if so try 8.1.7.3 or 8.1.7.2 (which is the earliest with the import fix)

Unless I mention otherwise, all my examples below are from installing Oracle 8.1.7 and upgrading to 8.1.7.4 on a Debian GNU/Linux 3.0 (Woody) system running kernel 2.4.18, using these files from Oracle: 

    93909 Jun 12  2001 glibc-2.1.3-stubs.tar.gz
549867520 Jun 13  2001 oracle-linux81701.tar
134494438 May 27  2002 oracle8-p2376472_8174_LINUX.zip

As I write this, the latest OpenACS Oracle install doc is rev. 1.8.2.2 2002/11/24, but it may not be up on openacs.org - get it from CVS. It is mostly fine, but leaves out a few very important things (e.g., UTF8!) and could stand tweaking in others. Here are my tweaks:

glibc 2.1 vs. 2.2 issues:

Oracle 8.1.7 was built linked against glibc 2.1, not the 2.2 that most Linux distributions now use. Debian 2.2 (potato) and (I think) Red Hat 6.2 were the last versions to use glibc 2.1. This causes us extra work, but basically is no longer that big a deal.

You may see reference to Red Hat glibc compatibility libs, and the Java JRE 1.18. Ignore these, you don't need them, at least not anymore.

Janine Sisk said here that (on Red Hat, which version?) export LD_ASSUME_KERNEL=2.2.5 is definitely necessary, without it, the Oracle installer never comes up. (She also had to edit $ORACLE_HOME/bin/genclntsh, but I did not.) On the other hand, Ola Hansson said here that at least on Debian, there is no need for the LD_ASSUME_KERNEL=2.2.5

I did use LD_ASSUME_KERNEL=2.2.5 at all times throught the Oracle install and database creation process.

After the Oracle install process, so far I have not used LD_ASSUME_KERNEL at all. Oracle and AOLserver both run with no LD_ASSUME_KERNEL set anywhere. The OpenACS 4.6 core installed without problems. However, I have not yet (2002/12/13) tried Itermedia or the OpenACS Site-Wide-Search package.

Linux kernel parameters for Oracle:

TODO: Investigate Linux kernel parameters for Oracle. E.g., Ola Hansson mentioned that "the default value for SHMMAX, 32Mb, worked but is probably not enough for a production worthy database." Also, pawprint.net has a bunch of info on Linux kernel parameters, as well as something about using 22 mount points (/ora8/u01 through /ora/u22) for an Oracle install that might be worth looking into.

Oracle environment variables:

I do not recommend putting the Oracle environment variable settings into ~oracle/.bash_profile. These are system-wide settings that all users need, and which you want defined in one central place. Instead, put them into "/etc/profile-oracle.sh", and also add ORA_OWNER=oracle there as well. Then source /etc/profile-oracle.sh from any other script that needs the Oracle environment variable settings. E.g., you probably want all user shells to get those environment variables, so add this to "/etc/profile": 

for script in  /etc/profile-oracle.sh  /etc/profile-postgres.sh
do
  if [ -e "$script" ]
  then
    . "$script"
  fi
done

Here's a snapshot of my actual /etc/profile-oracle.sh script: 

#
# $Id: oracle.html,v 1.32 2002/12/13 05:52:04 andy Exp $
#
# Single central place for setting all Oracle environment variables.
# Source this from /etc/profile.
#
# See also:
#   https://openacs.org/doc/oracle.html
#   https://openacs.org/doc/openacs-4/oracle.html
#   http://www.greenpeace.org/~bruno/oracle.html
#
# --atp@piskorski.com, 2002/11/28 02:36 EST

# Note that ORACLE_HOME and ORACLE_SID must also be specified in a
# different fashion in /etc/oratab:

ORACLE_BASE=/ora8/m01/app/oracle
ORACLE_HOME=$ORACLE_BASE/product/8.1.7
ORACLE_SID=ora8
export ORACLE_BASE ORACLE_HOME ORACLE_SID

ORACLE_TERM=vt100
ORA_NLS33=$ORACLE_HOME/ocommon/nls/admin/data
ORA_OWNER="oracle"
export ORACLE_TERM ORA_NLS33 ORA_OWNER

# It SHOULD be necessary to include ctx/lib in LD_LIBRART_PATH and perhaps
# PATH as well, for Intermedia to work - but in fact it is not - why?
# --atp@piskorski.com, 2001/08/19 18:23 EDT

PATH=$PATH:$ORACLE_HOME/bin
#LD_LIBRARY_PATH=$ORACLE_HOME/lib:$ORACLE_HOME/ctx/lib:/lib:/usr/lib
LD_LIBRARY_PATH=$ORACLE_HOME/lib:/lib:/usr/lib
export PATH LD_LIBRARY_PATH

Creating Oracle users/groups on Debian:

On Debian, you usually don't want to use useradd and groupadd like you would on Solaris or any other unix system. Instead, use adduser and addgroup, which have much more sensible defaults.

TODO: Add exact examples for the Oracle install stuff. (It's not that important though, the given comm useradd and groupadd commands work ok.)

Fix root.sh:

The OpenACS doc mentions how Oracle's stock root.sh does not work - this is true. However, the changes in the fixed pawprint.net version are actually very simple: 

$ diff root.sh root-pawprint.sh 
11c11
< ORACLE_HOME=/ora8/m01/app/oracle/product/8.1.7
---
> ORACLE_HOME=/oracle/u01/app/oracle/product/8.1.7
102c102
< RMF=/bin/rm -f
---
> RMF="/bin/rm -f"
132c132
< ORACLE_HOME=/ora8/m01/app/oracle/product/8.1.7
---
> ORACLE_HOME=/oracle/u01/app/oracle/product/8.1.7
156c156
< RUID=`/usr/bin/id|$AWK -F\( '{print $2}'|$AWK -F\) '{print $1}`
---
> RUID=`/usr/bin/id|$AWK -F\( '{print $2}'|$AWK -F\) '{print $1}'`
177c177
< $ECHO "\nThe following environment variables are set as:"| $TEE -a $LOG
---
> $ECHO "The following environment variables are set as:"| $TEE -a $LOG
200c200
<   $ECHO "\nCreating ${ORATAB} file..."| $TEE -a $LOG
---
>   $ECHO "Creating ${ORATAB} file..."| $TEE -a $LOG

So, just make those changes, but using your correct value for ORACLE_HOME, and run it.

Install Oracle glibc 2.1 stubs:

After installing the Oracle 8.1.7 software but before creating a database, install glibc-2.1.3-stubs.tar.gz per Oracle's instructions. AKA, as the Oracle user (and with LD_ASSUME_KERNEL=2.2.5 set), do:

$ cd $ORACLE_HOME
$ tar xvfz glibc-2.1.3-stubs.tar.gz
$ ./setup_stubs.sh

Upgrade to Oracle 8.1.7.4:

Next, after installing the Oracle software but still before creating a database, install the 8.1.7.4 patchset per Oracle's instructions. (When I did my intial Oracle install, I did not install the Oracle Installer, so I had to run the Installer out of my Oracle tarball in order to install this patchset. You'd probably be better off to just install the Installer at the beginning.)

Re-install the Oracle glibc 2.1 stubs:

Then after upgrading to 8.1.7.4, install the glibc-2.1.3-stubs.tar.gz again. It probably is sufficient to just to run setup_stubs.sh again, but I untarred everything again first too. But Janine Sisk discovered you definitely need to do it after installing the 8.1.7.4 patchset.

Running dbassist (use UTF8 !):

VERY IMPORTANT! Run dbassit to prepare to create a database, per the OpenACS instructions. But at the screen where you enter "ora8" for the "Global Database Name", also click "Change Character Set" and select "UTF8". I don't know what the significance of "Character Set" vs. "National Character Set" is, so I just picked UTF8 for both.

On the screen with the "Checkpoint Interval" and "Checkpoint Timeout", it might be useful to Enable Archive Log now - it would need to be investigated. However, I leave it off and switch to Archivelog mode later manually, after creating the database.

When running my 8.1.7.4 dbassist, some of the default values are different than mentioned in Vinod's Oracle isntall doc (rev. 1.8.2.2 2002/11/24). E.g., my defaults were Processes 150, Block Size 8192, both larger than in the install doc, so I kept them as is.

I told dbassist to put my sqlora8.sh script in: $ORACLE_BASE/product/8.1.7/assistants/dbca/install/

Put Oracle config files under CVS:

At this point (TODO: Actually, I did some of it earlier, before fixing the bad root.sh script.), I like to put all my Oracle config files under CVS, before I start editing them:

$ sudo find $ORACLE_BASE -type d -exec chmod g+s {} \;

You probably also want to change the permissions on a bunch of these files and directories give the dba group write access, but I didn't record exactly what chmod commands I used. TODO: Create little script to repeatably do the chmod's.

I use a -m commit comment of "Initial version of Oracle config files, no changes yet." for each of these: 

$ cd $ORACLE_BASE/product/8.1.7/network/admin/
$ cvs import ora8-hostname/product/8.1.7/network/admin Oracle ora8-initial

$ cd $ORACLE_BASE/product/8.1.7/hs/admin/
$ cvs import ora8-hostname/product/8.1.7/hs/admin Oracle ora8-initial

$ cd $ORACLE_BASE/product/8.1.7/assistants/dbca/install/
$ cvs import ora8-hostname/product/8.1.7/assistants/dbca/install Oracle ora8-initial

$ cd $ORACLE_BASE/admin/ora8/pfile/
$ cvs importora8-hostname/admin/ora8/pfile Oracle ora8-initial

TODO: Some of the those files (e.g., namesdrp.sql, namesini.sql, namesupg.sql) have CVS Header tags in them, so we might want to delete the first "$" in order to preserve the tag info as it came from Oracle. Bother with this?

Now use the non-invasive method [note: as of 2002/12/13, that link does not yet exist] to stick the appropriate CVS directories into the existing Oracle installation: 

# Do all of this as user oracle:

$ export ORA_CVS_TMP=/tmp/ora-cvs
$ mkdir $ORA_CVS_TMP
# oracle must be in the dba group for this chgrp to work:
$ chgrp dba $ORA_CVS_TMP
$ chmod g+s $ORA_CVS_TMP
$ cvs co -d $ORA_CVS_TMP ora8-koudelka
$ find $ORA_CVS_TMP -name CVS -prune -o -type f -print | xargs rm

$ ./cp-cvs-etc.tcl $ORA_CVS_TMP/product/8.1.7/network/admin/            $ORACLE_BASE/product/8.1.7/network/admin/
$ ./cp-cvs-etc.tcl $ORA_CVS_TMP/product/8.1.7/hs/admin/                 $ORACLE_BASE/product/8.1.7/hs/admin/
$ ./cp-cvs-etc.tcl $ORA_CVS_TMP/admin/ora8/pfile/                       $ORACLE_BASE/admin/ora8/pfile/
$ ./cp-cvs-etc.tcl $ORA_CVS_TMP/product/8.1.7/assistants/dbca/install/  $ORACLE_BASE/product/8.1.7/assistants/dbca/install/

$ rm -rf $ORA_CVS_TMP

Now do the same for some other directories we missed:

The $ORACLE_HOME/bin/ directory has both binary files and shell scripts, a few of which we will need to modify. So let's put the shell scripts (only) under CVS. While we're at it, we'll put the $ORACLE_HOME/root.sh script under CVS as well: 

$ mkdir /tmp/atp/ora-home
$ cp -p $ORACLE_HOME/{root,README}* /tmp/atp/ora-home/
$ cd /tmp/atp/ora-home/
cvs import -m "Initial version of Oracle config files, no changes yet." ora8-koudelka/product/8.1.7/ Oracle ora8-initial

$ mkdir /tmp/atp/ora-bin
$ cp -p $ORACLE_BASE/product/8.1.7/bin/{dbassist,debugproxy,deployejb,deploync,dropjava,ejbdescriptor,elogin,emwebsite,gatekeeper,genagtsh,genautab,genclntsh,genclntsh.nostub,genclntst,idl2ir,idl2java,irep,java2idl,java2iiop,java2rmi_iiop,jpub,jrelink.sh,loadjava,migprep,modifyprops,ncomp,netasst,netca,oadj,oadutil,ociconv,odma,oemapp,oidadmin,ojspc,owm,publish,publish_816,relink,remove,remove_816,sess_sh,sess_sh_816,sqlj,statusnc,symfind,trcfmt,vbdebug,vbj,vbj_convert,vbjc} /tmp/atp/ora-bin/
$ cp -p $ORACLE_BASE/product/8.1.7/bin/{echodo,demodrop,demobld,owhat,pupbld,gensyslib,coraenv,mergelib,extractlib,dbhome,dbshut,helpins,oraenv,gennfgt,dbstart,gennttab,oerr} /tmp/atp/ora-bin/
$ cd /tmp/atp/ora-bin/
$ cvs import -m "Initial versions of Oracle config files or scripts, no changes yet." ora8-koudelka/product/8.1.7/bin Oracle ora8-initial

# Do all of this as user oracle:

export ORA_CVS_TMP=/tmp/ora-cvs
mkdir $ORA_CVS_TMP
# oracle must be in the dba group for this chgrp to work:
chgrp dba $ORA_CVS_TMP
chmod g+s $ORA_CVS_TMP
cvs co -d $ORA_CVS_TMP ora8-koudelka
find $ORA_CVS_TMP -name CVS -prune -o -type f -print | xargs rm

./cp-cvs-etc.tcl $ORA_CVS_TMP/product/8.1.7  $ORACLE_BASE/product/8.1.7
./cp-cvs-etc.tcl $ORA_CVS_TMP/ora8-koudelka/product/8.1.7/bin  $ORACLE_BASE/ora8-koudelka/product/8.1.7/bin


# as oracle:
cd $ORACLE_HOME/assistants/dbca/install/
./sqlora8.sh

Oracle startup/shutdown scripts

Do not overwrite $ORACLE_HOME/dbstart with the OpenACS version. It contains these lines: 

# Modified 6/1/2000: Fixed bug determining version of Oracle by bquinn@arsdigita.com

# beg mod for linux fix
VERSION=8.1
# end mod
if [ "$VERSION" = "8.1" ]

However, the OpenACS version is in fact much different than the version provided by Oracle - lot's of random changes. Looks like version skew here, perhaps the OpenACS version is from Oracle 8.1.6 or something. The dbstart that comes with Oracle 8.1.7.4 for Linux works just fine.

The OpenACS /etc/init.d/oracle8i script is mostly ok. I've seen other slightly different versions, with some improvements. E.g., fixing the bizarre no-indentation formatting, and adding this extra little check at the top: 

  if [ ! -f $ORACLE_HOME/bin/lsnrctl -o ! -d "$ORACLE_HOME" ]
    then
    echo "Oracle Net8: cannot start"
    exit
  fi

But most importantly, change it to use "/etc/profile-oracle.sh", and change all occurrences of "ORA_HOME" to "ORACLE_HOME".

However, OpenACS's two separate startlsnr and stoplsnr scripts in /etc/init.d/ are silly and non-standard. Instead, use "/etc/init.d/oracle8i-net8", which is constructed like a real init.d script:

TODO: Add link to script here.

Of course for servers, create the appropriate /etc/rc*.d/ symlinks to make Oracle automatically startup, as the OpenACS docs say. However, for testing databases running on my desktop and the like, I prefer to set Oracle to shut down automatically, but to only start up manually. For the rc*.d scripts, I prefer to use S94 and K06, as they seem to have worked fine on a Solaris server I use with many, many different services running.

Which means that on a Debian server I do: 

$ sudo /usr/sbin/update-rc.d oracle8i      defaults 94 06
$ sudo /usr/sbin/update-rc.d oracle8i-net8 defaults 94 06

(Note "defaults 94 06" should be exactly equivalent to: "start 94 2 3 4 5 . stop 06 0 1 6 .")

While on a Debian desktop where Oracle is only used for testing I do: 

sudo /usr/sbin/update-rc.d oracle8i      stop 06 0 1 6 .
sudo /usr/sbin/update-rc.d oracle8i-net8 stop 06 0 1 6 .

As far as I know, it is ok to use the exact same S94 and K06 numbers for both Oracle and the Listener.