Oracle XE 11g on Oracle Linux 7 installation issues

We were installing Oracle XE (following proper instructions) on a fresh Oracle Linux 7.1 installation and were running into weird issues like this:

# rpm -ivh oracle-xe-11.2.0-1.0.x86_64.rpm
Preparing...                          ################################# [100%]
Updating / installing...
   1:oracle-xe-11.2.0-1.0             ################################# [100%]
Executing post-install steps...
sh: -c: line 0: syntax error near unexpected token `('
sh: -c: line 0: `echo ~(unknown)'
You must run '/etc/init.d/oracle-xe configure' as the root user to configure the database.

So, we couldn't finish the installation process properly. I did what anybody would do these days: GOOGLE "oracle rpm syntax error near unexpected token" (maybe now you'll get a link to this post?).

Nothing useful came up (it was March 21st 2015).

So we had to do some fixing ourselves. We extracted the installation scripts from the RPM file like this:

# rpm -qp --scripts oracle-xe-11.2.0-1.0.x86_64.rpm

And we tracked down the culprit to these two lines:

loginuser=`who | cut -d' ' -f1 | uniq | sed -n '1p'`

homedir=`sh -c "echo ~$loginuser"`

It turned out that when you issue a who command in this version of Linux, you will get something like this:

# who
(unknown) :0           2015-03-20 17:04 (:0)
root     pts/0        2015-03-21 08:33 (192.168.16.225)

And that explained the "echo ~(unknown)" error we were getting before.

So, what causes the (unknown) user to appear on the who list? It's the graphical interface that's brought up upon boot. So, in order to be able to install Oracle properly all we needed to do was:

# systemctl set-default multi-user.target

Which is equivalent to the good old runlevel 3 we used to set on /etc/inittab.

After that, reboot the system and you will be able to install Oracle XE without further issues.

When you're done, you can go back to get GUI for login on your server by issuing:

# systemctl set-default graphical.target

And rebooting your linux again.

A little bonus track to this post. Create a file called /etc/profile.d/oracle.sh and put this content on it:

 # /etc/profile.d/oracle.sh - set oracle stuff
ORACLE_BASE=/u01/app/oracle
ORACLE_HOME=$ORACLE_BASE/product/11.2.0/xe
ORACLE_SID=xe
PATH=$PATH:$ORACLE_HOME/bin
export ORACLE_HOME ORACLE_BASE ORACLE_SID PATH

Restoring a lost crontab

I recently issued a command like this on a production server:

$ crontab -r

I really meant to issue this command instead:

$ crontab -e

(I was trying to add an entry to a very important crontab).

Needless to say, after the command I mistakenly executed, my crontab was gone. 

From crontab's man page:

       -r     The current crontab will be removed.

I went to google to search for some answers and here's what I had to do in order to restore my removed crontab file (I am using CentOS 5):

First, there is directory in /var/spool/cron which holds all crontab files for all users. Mine was gone. So you can't get it from there unless you have a backup (which I didn't). So I couldn't t use it to restore my crontab.

But, there is a log file which turned out to be pretty useful. They are located in /var/logs. The file names are 'cron*'.

So I copied them to a folder to avoid working directly on them:

# cp /var/logs/cron* /home/myuser/cron_restore/

# chown -R myuser:myuser /home/myuser/cron_restore/

Then I extracted all different commands that had been running by crond:

$ cd /home/myuser/cron_restore/

$ cat cron* | grep crond | awk '{ split($0, a, "CMD "); print a[2]; }' | sort | uniq

After running the command, I got a list of all different command run and logged by the cron daemon. Of course, this will only bring you the commands that were still present on the log files. But it happened that I got to recover all I needed. Don't know if it will be the same for someone logging some stuff on a yearly or even monthly basis.

Hope you find this entry useful.