for PL in rpm -qa | grep libstdc++

do

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

if [ ! -z $CPPPL6 ]

then

ptch=0

fi

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 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? :)