OpenIndiana is a fork of what used to be the OpenSolaris project, before Oracle bought out Sun and closed the OpenSolaris project down. It’s therefore essentially a version of Solaris circa version 10-and-a-bit. Development of it is slow and its user-base is not large. But it is still being developed and regular refreshes of it are made every six months or so. The latest (at the time of writing, obviously!) was in October 2017 and is therefore called the 1710 release.
You may well ask why anyone should bother with OpenIndiana when the real thing (i.e., genuine Solaris) can be downloaded for free from the Oracle website. My answer to that entirely valid question comes in two parts. Firstly, Solaris may be free to download, but using it for real in a production environment costs a hefty license fee. And secondly, whilst Solaris is available to download now, there’s no telling if that is always going to be the case. In any event, I decided that getting Atlas working on OpenIndiana was an interesting-enough exercise to make the effort worthwhile, for me if not others!
As is the case with all Atlas/Oracle installs, of course, your OpenIndiana server needs to be built with at least 5GB RAM and at least a 40GB hard disk -though personally, given that Solaris is a little bit ‘heavier’ than most Linux distros, I’d recommend at least 8GB RAM. 5GB has been tested, though, and works well enough.
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 OpenIndiana-specific notes.
2.0 What’s been tested?
- OpenIndiana ‘Hipster’ 1710 (Live DVD)
3.0 Operating System media
OpenIndiana 1710 is available to download from the project’s website. You can download a ‘Live’ version in either DVD or USB format; a text-only version in either DVD or USB format; or a minimum install version in DVD or USB format. For ease of use, I’d recommend sticking to the Live version, because that’s the only one that gives you the full GUI experience that the Oracle installer expects to be able to run in. (It is, of course, possible to create a text-mode server and then use remote X techniques to run a GUI installer on it from another PC: I’ve explained how to do this for remotely running Linux applications in a number of previous articles. But I won’t consider that approach here.)
4.0 Operating System installation issues
Using the Live DVD, you boot OpenIndiana into a ‘live’ environment that runs the Mate desktop environment. It will look very familiar to anyone who has ever run Mate on a Linux distro! On the desktop, you’ll find an icon labelled ‘Install OpenIndiana’: double-click that and the install wizard will appear. Just click your way through it, accepting the default suggestions for the most part and clicking [Next] a number of times: it’s pretty painless. Of course, you’ll have to choose an appropriate timezone and locale, but other than that you only real interaction with the installer is to specify a root password and create yourself as a non-root user of the system:
Note that you also get a chance to name your new server, though Atlas will prompt you for this later on anyway, so don’t get too worked up about it at this point.
After the O/S has been installed, you reboot. Make sure you’ve removed the installation DVD before the server starts to come back up, otherwise you’ll end up booting back into the live environment instead of the ‘real’ one, installed on your hard drive.
If you’re using VirtualBox as your virtualization platform, you’ll probably find that the maximum resolution you can get from your new OpenIndiana box is 1024×768. Usually, you’d expect to have to (somehow!) get higher resolutions than this before Atlas will run, but -uniquely!- Atlas’ screen resolution checks are not performed when Atlas detects that it is running on OpenIndiana, so 1024×768 will be fine.
However, the Atlas screen display will still be complete garbage if you don’t arrange to run terminals with very small fonts: so I suggest the first thing you do when logging on to your new server for the first time is to open a terminal, click Edit -> Profile Preferences and then uncheck the option to use ‘the system fixed width font’. Then click the ‘Monospace Regular 12-point’ button and select instead to use a 7-point font:
Click Select and then Close. Finally, maximize your terminal window, so that it occupies the entire screen:
When you then come to run Atlas, you’ll find everything will be rather small -but at least it will display legibly 🙂 Once you’ve completed the Atlas run, of course, you can always set your terminal preferences back to using larger fonts than this: 7-point fonts get a bit hard on tired eyes after a while, after all!
A second thing to do immediately upon logging onto your new server for the first time is to attempt to become root:
su - root
It is a quirk of OpenIndiana that it expires the root password you supply during the initial OS installation -so this attempt to become root will trigger a prompt for a new password for the root account: you need a non-expired root account to be available for when Atlas runs. Here’s me encountering this issue:
So, having first supplied the original password when prompted, I am then immediately prompted to create a new password for root. Once that’s been supplied successfully, this is a root password that won’t automatically expire again in the future.
5.0 Running Atlas
Once you have sorted out your terminal font size and changed the root password to a non-expired one, fetch and run Atlas in the normal way:
wget https://bit.do/dizatlas -O atlas.sh chmod +x atlas.sh ./atlas.sh
…after which, you simply follow the prompts.
At one point, Atlas will probably discover that it doesn’t like the hostname you specified during the installation:
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. Note that if you happen to want a really long host+domain name, just keep typing it and try and ignore the fact that, at one point, it will wrap onto the beginning of the next line. It’s ugly -and quite difficult to read your handiwork in consequence! But, provided you don’t type any spaces or attempt to backspace back to the original line, it will work correctly, no matter how much text you type.
Here’s my attempt, anyway:
Other than that, there are no surprises. Just follow the prompts.
Be warned that when Atlas starts installing necessary software prerequisites, it will appear to stall for a very long time. Depending on your Internet speed, of course, you can expect to wait many, many minutes. (Mine is reasonably fast, and I sit there twiddling my thumbs for getting on for 10 minutes). Just be patient: left to its own devices, the script will eventually complete and prompt you to trigger a necessary reboot. Don’t try to be clever by avoiding the reboot: if you don’t reboot when prompted, rather important bits of configuration will never be performed.
6.0 Installing Oracle 12c
There are no major dramas arising during the Oracle database installation: you just download the relevant ZIP files from Oracle (I suggest to the /osource directory which Atlas created for you for just this purpose), unzip them and then launch the installer from the database subdirectory created by the unzipping process:
…does it for me, anyway!
Database 12c Release 1 will actually install without any complaint at all: all its prerequisites are met and therefore nothing fails the pre-install checks. Database 12c Release 2, on the other hand, will trigger a complaint that the package ‘assembler-0.5’ is missing. However, this warning can be ignored and the installation will run through to a successful completion anyway. Just click the ‘ignore all’ checkbox when prompted:
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 also see what this script actually does: it merely adds three settings into the glogin.sql script which SQL*Plus uses to configure its display. The stuff is, therefore, entirely cosmetic and it’s entirely up to you whether you want these changes made to SQL*Plus’ default way of working or not (but I’d recommend them anyway!)
You run that script now -as yourself, not root- using the following commands:
cd cd Documents ./atlas-postinstall.sh
Once you see the ‘all done’ message indicating successful completion of the script, you can launch SQL*Plus in the usual way and immediately start working with your new database.
Incidentally, Atlas provides two ways of launching SQL*Plus: the usual ‘sqlplus / as sysdba‘ way that is familiar to all users of Oracle databases, and the simpler ‘sql‘ command. This is just an alias of the full-blown ‘sqlplus / as sysdba’ command, but it’s quicker to type! It also uses the rlwrap utility to give SQL*Plus a command-line history -so you can scroll up and down through any previously submitted SQL commands to edit and re-submit them as you like. Use the traditional command when you don’t want this sort of facility, then, and the shortened ‘sql’ command when you do (and I rather suspect that you will want it a lot!)
Note that Atlas provides two other alias commands you can experiment with: diag simply takes you to your database’s trace directory, so that all files associated with explaining what the database is doing and what issues it is running into can be accessed simply, without having to remember the convoluted path needed to find them! Finally, there’s the tailalert command, which simply ‘tails’ the alert log in ‘following’ mode, so that you can see the output of the alert log as it is generated in real-time: I find it a convenient way of being able to see what the database is doing internally without having to type much!
Finally, be aware that the Oracle instance will not automatically restart at every reboot of the server unless you first, as root, edit the /var/opt/oracle/oratab file. Replace the ‘N’ that ends the line on which your new database is listed with a ‘Y’. For a database called “orcl”, for example, you’d change this:
Once the file is saved with that trailing ‘y’ in place, you’ll find that you can immediately connect to your database once the server comes back up from a reboot: Atlas has already created the necessary service scripts needed to make that happen.