Peppermint Linux is based on Ubuntu (like Linux Mint is, but don’t confuse Peppermint with Mint!). Actually, it’s more correct to say it’s based on Lubuntu, the Ubuntu respin that uses the extremely lightweight LXDE desktop environment. That means Peppermint inherits Lubuntu’s svelte, minimalist approach to things -and the speed that can potentially flow from that. The aim is to have a good-looking, fast distro that’s good for low-resource (older) computer hardware.
As such, sticking the behemoth that is Oracle 12c on top of it might not seem a terribly sensible thing to do… but if you can cope with the 5GB RAM requirement, there’s no reason why Peppermint can’t run Oracle 12c just as well as its Ubuntu/Lubuntu parent.
Visually, Peppermint is quite pleasing, though all the default application icons look exactly the same to me! It doesn’t come with a lot of software pre-installed (though obviously, everything you can run on Ubuntu can be added from the repositories).
Rather than fill your local hard disk up with software, though, Peppermint aims more to be a ‘cloud OS’ by virtue of including ‘Ice’ out of the box. Ice is a ‘site specific browser’ (or SSB in the jargon): it basically invokes Chrome or Firefox under the hood to make a website look as if it’s running an application locally. One that’s included by default in the Office menu, for example, is something that looks like an application called “Gmail”. In fact, if you click it, you simply get taken to the Gmail website. It’s a cloud application that looks local: it’s quite neat.
Anyway, as I say: installing Oracle locally on it maybe runs counter to the O/S’s general ethos, but it works… so why not?!
As is the case with all Atlas/Oracle installs, of course, your Peppermint 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 Peppermint-specific notes.
2.0 What’s been tested?
- Peppermint 7
- Peppermint 8
Both Oracle 12c Release 1 and Release 2 work successfully on these distros.
3.0 Operating System media
Get your Peppermint downloads from here. There are no variants to worry about (apart from the 32/64-bit one… you need the 64-bit version to run Atlas/Oracle, of course)
4.0 Operating System installation issues
There are no surprises with the OS installation. You can accept all the defaults and just click your way through to completion.
For disk partitioning:
The default option here is simply to ‘erase the disk’. That can safely be accepted: you will get a simple ‘everything in one root volume’ partitioning scheme which Atlas will find entirely acceptable. If you decide to go the ‘something else’ path and cook up your own partitioning scheme, remember that Atlas wants a ‘big root’ to work with (at least 25GB of free space on the ‘/’ mount point, basically).
Other than that, the installation proceeds to completion without drama or need to alter any of the defaults.
No wmctrl or xdotool utilities are installed by default, so once your OS has come back from its post-install reboot, you need to add that to Peppermint before you try running Atlas:
sudo apt-get install wmctrl
…will do the job.
I found I was able to scale the display on my Peppermint VirtualBox VMs without needing to install any Guest Additions. You simply need to click Start > Preferences > Monitor Settings:
It’s a bit peculiar to click on the right-hand side of the menu before seeing the option you need to select on the left… but every distro is allowed its quirks!
I did also change the default font size on the terminal, which starts out much too large for my tastes:
Just open a terminal session, right-click anywhere within the terminal and then select Options > Select font…
I found 9-point more than sufficient, but your mileage may well vary, of course.
5.0 Running Atlas
Assuming you’ve installed wmctrl (or xdotool) and have a big enough screen resolution, therefore, acquiring and running Atlas is straightfoward:
wget http://bit.do/dizatlas -O atlas.sh chmod +x atlas.sh ./atlas.sh
When you first launch Atlas like this, you may well find the end result practically unreadable, thanks to Peppermint’s fondness for translucency in its terminal windows:
That can be cured easily enough by again right-clicking on the terminal window, selecting Options > Select colors… and changing things to use (say) Color Set 2. This works nicely to increase contrast (but I’d pay money for a distro that uses UK spelling rather than US all the time!):
Once you can read the thing properly, just follow the prompts. There are no surprises.
6.0 Installing Oracle 12c
Oracle installation on Peppermint starts by warning you that your system is not adequate for the task:
The warning is a red herring, however, and it is perfectly OK to click [Yes] at this point to continue the installation regardless. You mostly just keep clicking [Next] after that!
Sadly, however, it remains the case that Peppermint, reflecting its Ubuntu heritage, is one of the few distros these days to throw errors during the installer’s ‘linking phase’:
As you can see, you get a pop-up at around the 59% mark, claiming that there’s a problem with compiling the ins_rdbms.mk makefile. As you can also see, however: your response to this error should be to open a new terminal window and change directory to the oracle user’s Documents directory. There, you’ll find an ‘atlas-fixup.sh’ shell script, previously created by Atlas.
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:
The script takes practically no time at all to run, but indicates it has completed by putting a big pop-up dialog box in the middle of your screen:
So now you do what the pop-up tells you to do: click [OK] to dismiss this new pop-up itself, switch back to the error message dialog generated by the original Oracle installer …and there click the [Retry] button.
Do all of that, and you’ll see that the linking phase resumes… and completes without further incident:
After that, the Oracle installation follows its usual path: you are asked to run two scripts as root, as you can see, so you can just prefix the script path/names the Oracle dialog gives you with “sudo” to achieve that.
Note that if you elected to create a new, dedicated oracle user when first running Atlas (instead of using the default option of making yourself the oracle user), using sudo in this way will not be possible, because Atlas doesn’t make new users members of the sudo-capable group by default.
If that happens to you, the trick is to use “su – <username>” to become the original non-root user (the user account specified when you first installed the operating system), and only then to prefix the path/filenames with the sudo command. That is, make the oracle user become someone who can sudo things, and run the root scripts as that other user with sudo prefixes.
You could alternatively just make the oracle user a sudo-capable user (by issuing the sudo adduser <username> sudo command), but that would not be a particularly secure way to do things: I don’t like my oracle users having more powers than they need strictly to run a database!
Once the database has been created for you, you should be able to immediately log on to the database and see visually-pleasing results:
The key point here is that, since there were linking errors that required you to run a fixup script, there is no Atlas-created post-install script to be run, as there would be with many other distros. Therefore, SQL*Plus is already configured to display line lengths and page sizes sensibly.
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.