Well, this was a productive 2 hour stint. I just managed to hack my way past the OBIEE installer to get ahead to the actual installation. After downloading the cpio (I chose the RedHat file, since I knew that I could at least install the Oracle Linux because I have the disks laying around somewhere. First step is obviously to deflate the file:

oracle@borg:~/$ cpio -idvm < ./biee_linux_x86_redhat_101321_disk1.cpio .

To start the installer, I simply ran
oracle@borg:~/RH_Linux/Server/Oracle_Business_Intelligence$ export DISPLAY=:0.0
oracle@borg:~/RH_Linux/Server/Oracle_Business_Intelligence$ ./setup.sh

Now the fun started.

Once the installer got going I was greeted with a message: . Fair enough. This is why I started this exercise in the first place, right?
The installation also comes with a shell script that you can run to see if your Linux box is valid for an OBIEE installation, called UnixChk.sh .

oracle@borg:~/RH_Linux/Server/Oracle_Business_Intelligence$ ./UnixChk.sh
CHECK FAILED - borg is NOT Oracle Enterprise Linux, Red Hat Linux, or SuSE Linux!
rpm: To install rpm packages on Debian systems, use alien. See README.Debian.
error: cannot open Packages index using db3 - No such file or directory (2)
error: cannot open Packages database in /var/lib/rpm
CHECK FAILED - borg should have Runtime libstdc++.so.6 !
CHECK FAILED - ulimit -n should be at least 10240 or unlimited
FAILURE!! - This machine is NOT configured for Oracle BI 10.1.3.2.1

First off, indeed. This isn't an Enterprise Oracle Linux, Oracle RedHat nor Suse Linux. But we can get past that easily. As root, create a file called /etc/redhat-release like this:

echo "Red Hat Enterprise Linux AS release 4 (Nahant 4)" > /etc/redhat-release

Second, some issue with rpm being used on a Debian system (i.e. Ubuntu) . As it turns out, the script is simply using rpm to check if the libstdc++.so.6 libraries are installed. I know it is (locate libstdc++.so.6 ) so I simply commented out the test from the script, lines 941 to 955

#ptch=1

for PL in rpm -qa | grep libstdc++

do

CPPPL6=rpm -ql $PL | grep $stdcpplib | tail -1

if [ ! -z $CPPPL6 ]

then

ptch=0

fi

done

if [ $ptch = 1 ]

then

echo "CHECK FAILED - $h should have Runtime $stdcpplib !"

failure=1

fi

The third issue, has to do with security settings on system level. By default my user, oracle, doesn't have permissions to have more than 1024 files open at any given time

oracle@borg:~/RH_Linux/Server/Oracle_Business_Intelligence$ ulimit -n
1024


Once again as root, we edit the file /etc/security/limits.conf and add the following lines,

This should do the trick, but for the changes to take effect you must start a new session for your oracle user.

oracle@borg:~/RH_Linux/Server/Oracle_Business_Intelligence$ ./UnixChk.sh /home/oracle/product/obiee10.1.3.2.1
SUCCESS!! - This machine is configured for Oracle BI 10.1.3.2.1


That's more like it!

Now, we run the setup.sh again and see what happens. This is what happens: . but but but but ...? Seems the setup.sh doesn't even use this UnixChk.sh script I just spent 30 mins on getting to work. Just great. And here I was thinking the real fun had started and was over with. Far from it. The setup.sh script is just quick wrapper to start the Java installer, and test for supported platform is done 'somewhere inside' that 600mb .jar file, called setup.jar

oracle@borg:~/RH_Linux/Server/Oracle_Business_Intelligence$ ls -lrt setup.jar
-rw-r--r-- 1 oracle oracle 636777135 2007-04-12 08:44 setup.jar

A quick peek in that file, showed some interesting classes, such as

oracle@borg:~/RH_Linux/Server/Oracle_Business_Intelligence$ unzip -l setup.jar |grep RedHat
2782 04-11-07 23:37 com/siebel/analytics/install/ValidateRedHatLinux.class
1669 04-11-07 23:37 com/ibm/wizard/platform/linux/LinuxRedHatCommands.class

That first one looks like it could be of some help here.
borkur@borg:~/Oracle/OBIEE/RH_Linux/Server/Oracle_Business_Intelligence$ unzip setup.jar com/siebel/analytics/install/ValidateRedHatLinux.class
Archive: setup.jar
inflating: com/siebel/analytics/install/ValidateRedHatLinux.class

Now we have a class file that is quite likely to be used to test if the machine running the installer is actually a Redhat Linux. But how can we peek inside it? A quick Google gave me some choices of tools to reverse engineer Java classes. One that seemed to work just fine is called jad. Running jad on the classfile showed me that the not only does the installer read from the /etc/redhat-release file but also from the pseudo-file /proc/version which is not something I wanted to try to mess with (e.g. recompiling a kernel to fake the signature there). So, why not just alter this file and put it back in the setup.jar file?

package com.siebel.analytics.install;
import com.installshield.wizard.WizardBeanCondition;
import java.io.*;
public class ValidateRedHatLinux extends WizardBeanCondition
{
public ValidateRedHatLinux()
{
}
public boolean evaluateTrueCondition()
{
return true;
}
public String defaultName()
{
return "Validate if the OS is correct Red Hat Linux.";
}
public String describe()
{
return "Condition check bean that evaluates to true if the OS os correct Red Hat Linux.";
}
}


And then compile it back to a class file:

oracle@borg:~/$ javac -classpath /home/oracle/RH_Linux/Server/Oracle_Business_Intelligence/setup.jar ValidateRedHatLinux.java

1. WARNING in ValidateRedHatLinux.java (at line 3)
   import java.io.*;
   ^^^^^^^
   The import java.io is never used

1 problem (1 warning)

Finally we need to get the newly compiled class file back in to the monster jar file.

oracle@borg:~/RH_Linux/Server/Oracle_Business_Intelligence$ cp ValidateRedHatLinux.class com/siebel/analytics/install/ValidateRedHatLinux.class
zip setup.jar com/siebel/analytics/install/ValidateRedHatLinux.class


and then run the installer again, using the modified setup.jar

But, seems this is far as I got. Once the installer started running, it just sat there dead. I left it running for the night but the only thing that happened was that some files got copied in to the OracleBI :(

I might give it another go, to track down why the installer doesn't at least copy all the files in place but that remains to be seen. Now I ask myself, Was it worth it? Was this failed attempt any good? Sure it was. It was fun and what better way to spend 2 hours of your time, once the kid is in bed and the wife is away in Spain? :)