Recently I was installing a regular 11gR2 installation and tried to use it by an other user than the software owner or a member of the dba group. A - so called - regular user.
When I ran oraenv to configure my environment for the ORACLE_SID I was going to use I was told that
ORACLE_BASE environment variable is not being set since this
information is not available for the current user ID ciber
You can set ORACLE_BASE manually if it is required.
This made me wonder why so I dived in the /usr/local/bin/oraenv script and found:
ORABASE_EXEC=$ORACLE_HOME/bin/orabase
if [ ${ORACLE_BASE:-"x"} != "x" ]; then
echo "The Oracle base for ORACLE_HOME=$ORACLE_HOME is $ORACLE_BASE"
else
if [ -w $ORACLE_HOME/inventory/ContentsXML/oraclehomeproperties.xml ]; then
if [ -e $ORABASE_EXEC ] ; then
if [ -x $ORABASE_EXEC ]; then
ORACLE_BASE=`$ORABASE_EXEC`
export ORACLE_BASE
echo "The Oracle base for ORACLE_HOME=$ORACLE_HOME is $ORACLE_BASE"
else
echo "The $ORACLE_HOME/bin/orabase binary does not have execute privilege"
echo "for the current user, $USER. Rerun the script after changing"
echo "the permission of the mentioned executable."
fi
else
ORACLE_BASE=$ORACLE_HOME
export ORACLE_BASE
echo "The Oracle base for ORACLE_HOME=$ORACLE_HOME is $ORACLE_BASE"
fi
else
echo "ORACLE_BASE environment variable is not being set since this"
echo "information is not available for the current user ID $USER."
echo "You can set ORACLE_BASE manually if it is required."
fi
fi
What this code does is
1) check ORACLE_BASE
2) if set => all ok and report ORACLE_BASE
3) else, check if $ORACLE_HOME/inventory/ContentsXML/oraclehomeproperties.xml is WRITEABLE and try to set ORACLE_BASE using $ORACLE_HOME/bin/orabase.
I made a little tweek on this script, to check for READABLE on $ORACLE_HOME/inventory/ContentsXML/oraclehomeproperties.xml. Why would we give an ordinary user write privileges on anything within ORACLE_HOME? ([in]Secure by default?).
Still I keep getting this error:
ORACLE_BASE environment variable is not being set since this
information is not available for the current user ID ciber.
You can set ORACLE_BASE manually if it is required.
So when the script is no longer the culprit, the filesystem security bits have to be it. In unix, to be able to access a file, all directories that we have to pass through need to have at least execute permission for me to pass. The fresh created app directory (/home/oracle/app) has 770 so I won't be able to pass this one.
chmod o+x app
to fix that but still I am getting the same error. When digging deeper I get to $ORACLE_HOME/inventory that also has 770 defined on it. Here again:
chmod o+x $ORACLE_HOME/inventory
Now it is the ContentsXML directory that is blocking me, it again has 770.
chmod o+x $ORACLE_HOME/inventory/ContentsXML
Finally we get to the oraclehomeproperties.xml file, this has 660 for the permisssion bits. To fix this
chmod o+r $ORACLE_HOME/inventory/ContentsXML/oraclehomeproperties.xml
Finally oraenv does no longer complain.
If it is important enough to give an error message when running oraenv, why make this file inaccessible to other users? BTW: my previous post was more or less caused by figuring out this setup. I thought I made an error so I wanted to re-install the ORACLE_HOME, just to make sure that what I write is right.
and proceed to the next page to choose the desired language. In the next page specify the ORACLE_HOME location of your choice.
and proceed to the next page 
where you can select the tool to install, in this case the Scheduler Agent.
Here you specify the current hostname and a port number. Don't worry, they only appear in the $ORACLE_HOME/schagent.conf and can easily be changed afterwards.
In the summary screen hit Finish to start the actual installation.
After a while the request to run the root.sh pops up, as usual.
Run the root.sh, connected as root and the installation is ready.
Does this look familiar?
