Dizwell Informatics

News from Nowhere

Atlas – Installing Oracle on RHCSL 7+

1.0 Introduction

For many years on this website, I have made mention of an ‘RHCSL distro’, which is a short-hand way of acknowledging that Red Hat, CentOS and Scientific Linux are all, essentially, identical. Red Hat provides the original source code for their Enterprise Server distro; the others then strip it of trademarks and logos and re-compile it into their own ‘flavour’ of Enterprise Server. They may make some slight alterations to the software mix or configuration defaults when doing that, but for the most part they are binary-equivalent distros… so what is true for one will most likely be true for any of the others.

I should also fess up: my ‘RHCSL’ abbreviation for this collective of distros was cooked up before Oracle decided to join the party: their “Oracle Enterprise Linux” (OEL) is also a re-compiled copy of Red Hat (though optionally with a unique kernel component that makes it better suited to running Oracle Database workloads than the Red Hat original, along with what has to be the world’s worst desktop wallpaper). So, I suppose we probably ought to call this menagerie of distros RHCSLO… but old habits die hard and I therefore tend not to! Provided you understand that ‘RHCSL’ stands for “any clone of Red Hat Server”, including Oracle, we’ll be fine keeping the abbreviation as it has always been in these parts!

Anyway: RHCSL, whatever specific distro is meant by that, are the gold standard for running Oracle databases …because Oracle actually supports doing so on at least Red Hat and OEL (though not on CentOS, nor on Scientific Linux). The lack of support for two of the RHCSL family doesn’t really matter, though: the fact that the other family members are supported means that you can expect a smooth 12c installation on all of them.

I should mention that Atlas only works for the 7.x releases of RHCSL distros. There’s nothing wrong with the 6.x versions, of course, and they are still supported… but they are quite long in the tooth, and therefore a decision was made simply not to bother with them for the purposes of Atlas-assisted Oracle installs.

As is the case with all Atlas/Oracle installs, of course, your RHCSL server needs to be built with at least 5GB RAM and at least a 40GB hard disk.

Please watch the generic Atlas videos here, here and here to get an idea of how Atlas works in general. The generic documentation (including those videos) are available from this page. Below are RHCSL-specific notes, which happen to be using CentOS specifically -but again, the notes should generally apply to all RHCSL family members.

2.0 What’s been tested?

  • CentOS 7.0, 7.2.1511, 7.3.1612
  • Red Hat Enterprise Server 7.2, 7.3
  • Scientific Linux 7.0, 7.2, 7.3

3.0 Operating System media

RHCSL is available in lots of different ways, of course, given that we’re actually talking about at least 4 actual distros! For the most recent versions of most of the distros, probably the simplest option is to download the 7GB+ “everything” ISO.

Getting hold of Oracle Enterprise Linux is made trickier by the fact that you have to register as a user at the OTN website. However, it doesn’t cost you anything (in cash, at least!) to do so. Only once you’ve logged in will you be able to download the relevant ISOs.

Red Hat is even harder to obtain: you’ll have to register as a Red Hat Developer first, but that again doesn’t cost you anything apart from an email address.

Bear the registration requirements in mind for Red Hat and Oracle when attempting to use the following links -and remember that they are only valid at the time of writing (January 2017, basically), so check the distro’s proper home pages to make sure you’re obtaining the latest version:

4.0 Operating System installation issues

Different members of the RHCSL family do their installs slightly differently. For example, CentOS 7 installation starts by proposing a ‘Minimal Install’; this has to be changed (to Gnome Desktop or KDE Plasma Workspaces or any other similar option that provides a full GUI environment to work in). If you’re using Scientific, however, you’ll get offered a ‘general purpose system’, which includes a GUI and so can be left unchanged. Basically: use your common sense. Check the defaults proposed by your specific distro and make sure you end up with a GUI system.

The installer’s Network and Hostname options default to ‘not connected’. This can be accepted, though if you want to change it now, that’s fine (Atlas will sort out a hostname for you later on if you don’t do it now). If you leave it unconfigured, you will be prompted again to sort it out when the O/S comes back from its first reboot: it is again unnecessary to do so, though you can do it then if you like. If you do not configure the network before your first log-in, it will be necessary to manually switch on networking so that the server can reach the Internet before you attempt anything else (simply click on the top right-hand part of the top bar to show the drop-down menu that allows you to turn networking on).

You are required to click into the Installation Destination option, though you do not need to change anything once you do and can immediately click the [Done] button to quit the relevant screen.

When creating yourself as the non-root user, click the option to Make this user administrator’: it means that you’ll be able to sudo -i to become root (which requires only that you know your own password) rather than to su – root (which requires that you know root’s password). The one is a slightly saner and more secure option than the other!

Be prepared to click [Done] twice when creating the root and non-root user’s passwords, if the O/S installer doesn’t consider them sufficiently complex enough!

After the O/S has been installed, you may have trouble getting the screen resolution high enough (remember that Atlas requires at least 1200 x 750). Here is my CentOS VirtualBox machine, straight after installation, showing the Display options (Applications -> System Tools -> Settings -> Displays):

Note that only two screen resolutions are offered, neither of which are viable for use with Atlas. The possible solutions to this are: (1) use a different virtualization tool (VMware, for example, doesn’t experience this particular issue) or (2) install the VirtualBox guest additions.

Installing the guest additions, however, requires installing extra software. Keeping this extra software to a minimum is quite important, so I just use these commands:

sudo -i
yum -y update kernel*

Wait for the PC to come back up, and then issue these commands:

sudo -i
yum -y install kernel-devel gcc

Note that (uniquely) on Scientific Linux 7.3, I had to first do a yum remove libgomp before this set of installs would work. SL’s packaging is different enough from Red Hat’s that the existing libgomp (which in any case gets replaced by the eventual install command) appears to cause versioning issues that prevent the required installs being successful in the first place.

Also note that (uniquely) on OEL 7.3, I had to add kernel-uek-devel to the list of packages to install, because OEL defaults to using its ‘unbreakable kernel’. If you had chosen at boot time to use a non-uek kernel, however, then that wouldn’t be necessary.

And finally, note that on Red Hat proper, you need to complete the Subscription Manager details (with your developer credentials) in order to be able to use yum at all, so do that before doing anything else.

Anyway: once the kernel and gcc bits and pieces are installed, click to install the guest additions and either click on the option to auto-run the Additions installer, or (again as root or using sudo) use these commands to run the installer manually:

sh /run/media/<username>/<VBOXADDITIONS_version>/VBoxLinuxAdditions.run

Once the VM comes back up, your choice of screen resolution should be much more extensive than before:

Indeed, you should find that you can now make your VM window as big or small as you like and the guest OS will resize itself to fit automatically (provided that the View -> Auto-resize Guest Display option has been switched on at the host, of course).

Another of Atlas’ requirements is that either wmctrl or xdotool are installed before it is run: however, neither package is available in the default repositories! So to get either of them installed, you’ll need to enable at least one extra repository. The following two commands will sort that out for you:

sudo yum -y install epel-release
sudo yum -y install wmctrl

Note that on OEL and Red Hat, the first install (of epel-release) won’t work. Instead:

wget http://dl.fedoraproject.org/pub/epel/7/x86_64/e/epel-release-7-9.noarch.rpm
sudo rpm -ivh epel-release-7-9.noarch.rpm

…and you might want to check for the latest version of the rpm on the relevant website before issuing those commands, since the version numbers increment regularly. Once the rpm has been installed, though, wmctrl or xdotool can be installed without drama.

Once you’ve got a decent screen resolution and wmctrl (or xdotool) installed, you’re technically ready to run Atlas. I would suggest one further refinement before you do so, however: change the Profile Preferences for a terminal to use a Custom Font, size 8 or 9:

It is not essential to do this, but the default font size that is otherwise in use is, frankly, enormous and doesn’t make reading Atlas’ screen-handling handywork a very pleasant experience!

5.0 Running Atlas

Once you have a decent screen resolution and wmctrl or xdotool installed, fetch and run Atlas in the normal way:

wget http://bit.do/dizatlas -O atlas.sh
chmod +x atlas.sh

…after which, I simply followed the prompts.

RHCSL and Fedora are about the only distros on the planet which do not ship with lsb-release out of the hood: since Atlas uses that tool to determine the exact distro version that’s in use, almost the first thing it has to do is to fetch and install that package before it can go any further. Unfortunately, it has a lot of dependencies, so fetching it can take many minutes. (If you prefer, you can pre-install lsb-release yourself. That also takes many minutes to complete, of course, but at least Atlas itself then completes its work more quickly).

Once Atlas has determined that you are running a proper RHCSL distro, it will potentially discover that you left the hostname un-set during the OS install:

That’s fine, because you get to specify a hostname now anyway. Make it a fully-qualified one (i.e., it needs a domain name component). If you don’t have a genuine domain name to work with, make one up (such as ‘mydomain.home’ or ‘.localdomain’ or just ‘.local’, as the mood takes you). Type the fully-qualified host-and-domain name at the prompt shown. Note that if you just press Enter, you get given the hostname “osrvr.test.lab” anyway.

Here’s my attempt:

Other than that, there are no surprises. Just follow the prompts.

6.0 Installing Oracle 12c

Unsurprisingly (given that two of the RHCSL family are supported distros), there are no major dramas during the Oracle database installation.

Before the installation starts in earnest, you may see this sort of warning:

This complaint that your swap size is insufficient is a bit annoying -especially if you look at the specific numbers shown in the lower part of the screenshot. Oracle is complaining that it wants 4.6GB of swap space and I’ve only supplied 4GB (or rather, the default O/S partitioning process has done so). You and I might think a 0.6GB difference is trivial… but the Oracle installer begs to differ!

Anyway: it is a trivial difference, and you should therefore ignore this warning -by clicking the Ignore All radio button on the top right-hand corner of the screen and confirming when prompted that you know what you’re doing.

In Scientific Linux, you’ll also get warnings about a couple of missing packages: they, too, can be ignored in the same way. Their alleged absence does not prevent a successful installation in any way. The same is true for Red Hat‘s complaint that compat-libstdc++ is missing: ignore it and it won’t trouble you further.

Other than that, the installation will sail through to completion without drama:

Since there are no linking errors to worry about, Atlas will have created a post-install script in the oracle user’s Documents directory which you can (optionally) run once the Oracle installation completes successfully. Since I am my own oracle user, the following screenshot shows me checking the contents of my own Documents directory:

Note that the file is already executable: Atlas created it that way. You can therefore run that script now, as yourself, using the following command:


Do that as yourself, not as root. The command will not appear to have done anything at all, and you’ll merely return to the next line on the command prompt. Nevertheless, it will actually have altered some of the interface settings for the command-line SQL*Plus tool so that its query results are presented more sensibly than they are by default:

The default SQL*Plus settings would have resulted in that query’s return being broken up into a fairly illegible mess. Nevertheless, it’s up to you whether to run the post-install script: it is entirely optional to do so.

Incidentally: the command you see me typing in that last screenshot (“sql“) is the alias of the full command (“sqlplus / as sysdba“). It is aliased with a reference to the rlwrap utility, so that if you get into SQL*Plus using it, you can press the up and down cursor keys to retrieve and scroll through any previous SQL commands you’ve typed. If you ever need the vanilla, un-rlwrapped version of SQL*Plus, however, then just type the full-blown sqlplus  command and you’ll be running the exact same program as before but without a command line history.

Here are some other screenshots from other family members of the RHCSL distro group (all of the 7.3 variety), just for completeness’s sake: