I have spent the last two work-days wrestling a copy of Oracle Database 12c onto a remote server running Red Hat 7, for the benefit of a client’s Oracle-insistent legacy application. This oversimplifies the matter a bit; I actually spent most of yesterday trying to get the older Oracle 11g onto the thing, before learning that it simply doesn’t work with the latest RHEL, and thus necessitating a conversation about what downgrades, upgrades, or givings-up the client would rather see before trying again. Either way, getting a fresh Linux machine to a state where it has an Oracle DB ready to accept queries still constitues a plodding, ornery process, at least to someone far more used to working with nimble open-source databases like MySQL, whose installation instructions don’t carry a soupçon of embarrassed apology whenever they involve the command line.

As with the last time I had to install Oracle, I blundered my way through the process by way of several dozen web searches, starting with the most general queries (how to install oracle 11g on rhel 7) and branching with fractal fuzziness down each subtask until I inevitably typed in phrases suggesting a crackpot’s chemistry notebook (“ins_ctx.mk” rhel “libstdc++.so.5”), attempting to find why I couldn’t jam the peg currently at hand into the next hole presented by the installation procedure. For the most part, I made fairly steady progress, but for a couple of places where I remained hung up for an unusually long time. In this post, I’ll share the problems and my solutions to them, hoping that it will aid some future seeker.

Set “X11UseLocalhost” to “yes”. Or maybe “no”. Installing Oracle Database on a remote machine, to which one has an SSH connection, means running the X Window System on your local computer, and then making sure that the remote machine’s SSH daemon configuration allows for X11 mumbo-jumbo to travel over secure connections.

I can’t remember the last time I found myself expected to use X11 for any serious purpose, at least not since leaving the desktop Linux world for Mac OS X during the first year of George W. Bush’s presidency. Oracle’s installation process expects you to use it, though, and I didn’t find any third-party installation guides that offered a command-line-only alternative. Thus does the act of using the internet to set up what calls itself the world’s most advanced commercial database feel like dialing into a fancy graphical BBS circa 1987 with a tinny and underpowered 300-baud modem (the best you could afford on your meager allowance, of course). I found myself waiting for whole minutes each time I filled out a form and clicked Next as each new pane’s menus, sliders and radio buttons laboriously drew themselves onto my window, one by one.

All that aside, I easily found straightforward instructions for pairing X11 and SSH around the web, and I’ve no doubt you can do the same. On a Mac, you’ll need XQuartz, and on your server, you must (unless someone’s done it before you) update /etc/ssh/sshd_config, twiddling various bits to allow X11 forwarding.

However, I found conflicting information about the X11UseLocalhost directive in that file. Some pages said to set it to “no”, others to “yes”. I found that when I set it to “no”, any attempt to ssh -X into the would-be database server from an XQuartz terminal window would result in a message that it server refused to forward X11 stuff. When I tried again with ssh -Xv — setting the “verbose” flag — I saw the error “Can’t get IP address for X11 DISPLAY. X11 forwarding request failed on channel 0.” The web had little to say about this, but I found that all my problems went away when I set X11UseLocalhost to “yes”. So, yes, do that.

…Except that I just now experimentally set it to “no” and restarted the server’s SSH daemon, and I can still log in and run xeyes just fine, even though I feel absolutely certain that making that “no”-to-”yes” switch was the last thing I did before everything suddenly worked. This doesn’t make the action causal, of course, because computers are complicated and terrible. I also get the impression that my installing the “xauth” package on the server somehow played a role… but, ultimately, I don’t find myself wondering about it any deeper than that, as I rather hope not to have to use X11 again for another 15 years.

Alas, then, I must downgrade the utility of this post from definitive answers to sympathetic succor for those arriving here via search engine. Dear friend: know that someone before you has struggled through this same ordeal and gotten through it. You can find the answer with only a little more preserverance. It’s… somewhere in one of these goddamn things. I have faith in you.

Install compat-libstdc++-33 as an RPM from oracle.com. Oracle Database 12c lists a Linux package called “compat-libstdc++-33” among its dependencies. Unlike all the other packages on that list, you can’t simply sudo yum install it, at least not on a fresh RHEL 7 system. Red Hat’s yum repository has no idea what it is. I had no idea what it is, either, which didn’t help.

I did find that Oracle runs its own public yum repository, and I when I followed the instructions on that page to add it to the server’s repo list, it seemed to know about compat-libstdc++-33! But when it came to actually installing it, yum complained about an inability to find a necessary public key — and when I researched that, I found some documentation describing ways to “convert” a Red Hat Linux installation into a rebranded Oracle Linux one, and I fled in fear.

Eventually I noticed that Oracle makes its yum repository browsable from its website, so I navigated to its raw list of Oracle Linux 7 packages, found the URL of the most recent compat-libstdc++-33 RPM file, and then (drawing on knowledge about the rpm command picked up earlier in this installation exercise) spake this command to the remote server:

sudo rpm -ivh http://public-yum.oracle.com/repo/OracleLinux/OL7/latest/x86_64/getPackage/compat-libstdc++-33-3.2.3-72.el7.x86_64.rpm

And that did the trick. If you follow this path, you’ll probably want to make sure to pull the most recent version of this package, rather than the one I happened to find in June 2015. Regardless, I’m happy I can provide a reasonably direct answer to at least this problem.