Author: dizwell

As the last post indicated, I’ve done with Dizwell and will not be maintaining content here any longer.

Meanwhile, I am paying for hosting Dizwell, regardless of its relevance -which I’ve been happy to do for the past three months. I’ll even be happy to pay for it for another couple of months. But I can’t in all conscience pay indefinitely for something I’m not actually using (TOH won’t wear it, basically!)

Therefore, we cut to the chase: I shall be shutting down the Dizwell server in a few months.

If someone wants to take on Churchill or Atlas (or, indeed, any other content on these pages), please get in touch at [email protected].

I’ll be shutting the site down on 1st June. This isn’t, either, an invitation for the unscrupulous to just scrape all content and host it as their own: I’ll protect my intellectual property rights regardless. But I am definitely in the market for someone to pick up where I’ve left off and to curate the content in a way that continues to provide useful help to others.

If I don’t hear from anyone by the end of May… the plug gets pulled. My ego can cope!

Last year was the year I decided to quit Australia (after 23 happy years there) in order to move back to the UK (which doesn’t require flying for 22 hours before you get somewhere more interesting!) It was a big move and resulted in us buying a nice 1930s house in Nottingham -and then spending the next six months renovating it and taking it back to its full Art Deco glory. That project took much longer (and much, much more cash) than we’d planned, but it’s now all looking pretty fine and the builders are -finally!!- gone for good.

So, as the year turns, I find myself happily bedded down in my new home and wondering about what direction my life will take in this newest of New Years. At which point, it occurs to me that this year is the nineteenth I’ve been working with Oracle databases in one way or another… and I’ve come to the conclusion that that’s at least one year too many. It’s time to change perspective, just as I changed countries, and look for different things to get interested in.

There are many consequences that flow from that thought -and the main one, from this website’s perspective at any rate, is that I don’t want to maintain the Dizwell website any longer. It’s time to move on and check out…

Practically, this means that the website content that is here today will remain here for the foreseeable future. The site is not disappearing. But there won’t be any new content and the existing content won’t be maintained or kept relevant. In particular, this means that Atlas gets frozen at the point it has reached (and thus is doomed to eventual irrelevance as distros keep on churning out fresh versions that break Oracle installations in interesting new ways!) I’m sorry about that, but maybe someone will offer to take on Atlas and keep it relevant in a different context?

Of course, this is just a New Year’s resolution and is therefore subject to the same pitfalls that all such resolutions face; namely, that people don’t tend to keep them for long! But on this occasion, I really wouldn’t hold your breath: as best as I can tell, I’m permanently done here.

I have enjoyed the ride (on the whole) and like to think the Dizwell site, in all its many forms, did a little good for some, somewhere along the way… but for now, I wish my long-suffering readers all the best for 2018 and trust their Linux and Oracle adventures go well without me. Bye…

Just a short note to point out that, finally, the ZFS on Linux guys have released a version which works with Fedora 27. There is therefore nothing to stop you upgrading to version 27 now (though the fact there was a month-plus wait for the v27 repository from the ZFS developers is another reminder that using ZFS on a bleeding-edge distro is not the faint-hearted!)

There is a ghastly new look (I suggest changing the default jellyfish wallpaper the moment you first log on!), but there is otherwise not a lot listed as being new in the release notes, apart from an upgrade to the latest release of LibreOffice.

Mostly underwhelming, in other words; but still just about the most functional distro out there (imho, naturally). It remains my desktop of choice, anyway. Unfortunately, I can’t actually upgrade my main desktop to version 27 because when I do, I get told:

Error:
Problem: package zfs-dkms-0.7.3-1.fc26.noarch requires /bin/ksh, but none of the providers can be installed
- ksh-20120801-35.fc26.x86_64 does not belong to a distupgrade repository
- problem with installed package zfs-dkms-0.7.3-1.fc26.noarch

As far as I have been able to tell, this is caused by the ZFS on Linux project not having Fedora 27-compatible repositories ready -and, allegedly, they won’t have one until mid-December. So any Fedora 26 users who have committed to using ZFS for their important data won’t be able to upgrade for a few weeks. Fingers crossed for the December timeline.

My laptop doesn’t use ZFS, though, and was able to upgrade without drama.

I’ve also re-jigged Atlas, so Oracle 12c will run on Fedora 27 without too much fuss (the same need to do a software-only install that plagued version 26 also affects version 27, but the workaround previously described works for the new version of Fedora perfectly well):

A reader asked an extremely sensible question on hearing that Atlas has been made to work on OpenIndiana: does it therefore work on “proper” Solaris too?

The short answer to that question is “no”, but I’ll take the opportunity to explain why that is so here.

To run Atlas on any one of 20 different operating systems and/or Linux distros, you first obtain the atlas shell script with a command such as:

wget https://bit.do/dizatlas -O atlas.sh

Wget is an ancient (well, 1996… but that’s ancient in Internet years!) utility that simply fetches data from a web server. The web server in question is a little obfuscated by that short-form “bit.do” URL shown in the above command -but it’s actually my own web server, based in Paris, that hosts dizwell, diznix and some other websites I dabble with from time to time. As I say, wget has zero problem fetching the atlas script contents when told to do so on 20 different distros and OSes.

But, uniquely, on proper Solaris (in this case, 11.3), this happens:

The important bit there is “sslv3 alert handshake failure“: it means that Solaris’ version of wget is built to use the sslv3 protocol, and my web server doesn’t support that. Quite what the version of wget used by OpenIndiana, Ubuntu, Red Hat, etc etcad infinitum is using to connect to my web server, I really have no idea. But whatever those other wget versions are using, it works happily! Only Solaris uses a wget configured in a way that doesn’t.

Now I respect Solaris’ “bullet-proof” nature, so I rather suspect that it’s my web server configuration that is at fault here, rather than Solaris. But I’m not re-configuring my entire server just because one O/S can’t handle it!

Anyway, Solaris’ inability to fetch stuff from my web server means Atlas falls at the first hurdle: you can’t even download the script to it in the first place! But suppose you persevered and somehow managed to download the relevant file to a Solaris machine via a web browser or some other technique… surely it would work then? Sort of… except that you would then fall at the second hurdle -which is that the atlas script expects to be able to download -using wget- a second script. Since that will fail too, for the same sslv3 reason described above, the entire thing collapses in a heap without configuring a thing on your Solaris box! 🙁

This is annoying!

So I resolved the matter by the simple expedient of storing a copy of the atlas script at Dropbox: Solaris’ version of wget is happy to negotiate a suitable connection with their servers, so a wget from there works fine. Similarly, if I rejig things slightly, the second script download works. And Lo! It then becomes trivially easy to run Atlas on Solaris 11.3 after all. Once you do, Oracle 12c R1 and R2 both install without incident or error.

So the rather longer answer to my original reader’s question is: Atlas didn’t run on proper Solaris, for abstruse technical reasons to do with encryption protocols, secret handshakes and the like… but now it does:

Obviously, I will alter the Atlas documentation again to take account of this new capability (which may take a day or two), but the quick instructions are:

wget https://bit.do/dizatlas2 -O atlas.sh
chmod +x atlas.sh
./atlas

Note the use of dizatlas2 in that first wget command. That forces wget to talk to the Dropbox copy of Atlas, not the original as stored on my own server. I dislike needing to have copies of things in two entirely independent locations like this (it makes synchronizing the two repositories more difficult than it should be), but it’s the quickest solution for now: since you’ve pointed to the Dropbox repository, the wget command will succeed in fetching the file -and the script will similarly succeed in fetching the second file it needs to do its configuration work.

No other OS or distro needs -or indeed should– use this dizatlas2 respository: it’s only ever useful and required for Solaris 11.

However, OpenIndiana (which is based on the forked, open source Solaris 10) continues to be fitfully developed and refreshed by its loyal band of devotee developers: a brand new release hit the download servers at the tail-end of October (and is thus called the 1710 release of the Hipster fast development branch of OpenIndiana).

It is probably slightly odd to spend any time worrying about whether Oracle 12c runs on this new version of OpenIndiana, given its niche appeal and the imminent demise of the ‘real thing’ it’s based on. But I did anyway… and I can therefore report that both 12cR1 and 12cR2 install without drama.

12c Release 2 complains of a missing package, called ‘assembler-0.5’, but this warning can be ignored and the installation will continue to a successful conclusion anyway. There are no warnings about anything with 12c Release 1, I’m happy to say.

To make things easier, I’ve re-jigged Atlas to work to get these installations automated. Atlas was always promised to be the ‘universal’ script to get Oracle installed on ‘*nix’, so getting it to work for ‘proper’ Unix as well as for Linux is, if anything, long overdue.

I’ll be updating the Atlas documentation to reflect its new-found OpenIndiana-capabilities in the course of the next day or so. In the meantime, the short version is simply to build a Hipster VM with at least 5120MB of virtual RAM, then:

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

After that, follow the prompts to completion (including a reboot). Then download the Solaris X86 flavour of one of the Oracle 12c database versions, unzip the download(s) and then invoke the Oracle installer by the usual database/runInstaller command.

Way back on July 11th, I welcomed the release of Fedora 26 and noted that Atlas didn’t run on it properly: the Oracle software would link properly, but no executables could then be run. I promised to look into it and see what I could do to come up with a fix.

Unfortunately, I reckoned without the fact that my barely-functional study swiftly thereafter got dismantled by the builders who proceeded to put down a new floor, ruin it, replace it, ruin that and finally installed a third that they managed not to screw around with! Long story short, I’ve been without functioning computers for many weeks and it’s only in the past couple of days that I’ve been able to turn my attention to the Oracle/Atlas/Fedora conundrum. (Which is a bit sad, as Fedora 27 is due to be released imminently! But better late than never, I guess…)

Anyway, it turns out that the problem concerns the new version of glibc that ships with Fedora 26. It interacts with the Oracle compiler in ways that prevent all binaries produced by the linking phase from being able to run correctly (or, indeed, at all).

I had hoped that by now, an updated version of glibc might be shipping that would have meant the linking phase could produce functional binaries, but no such luck. Therefore, I am reduced to having to re-compile all the binaries after a software-only Oracle installation and having first made sure that Oracle’s own versions of libc-related libraries are deleted.

The short story is, therefore, that a new version of Atlas has been released (1.6, if anyone’s counting) that works to allow a software-only install of Oracle 12R1 or 12R2. Fedora 26 users can thereafter run the ~/Documents/atlas-postinstall.sh script to trigger the correct re-linking of all the Oracle binaries and the automated creation of a database (for which the SYS and SYSTEM passwords are set to “oracle”). It isn’t pretty and I wish there were a nicer way of achieving it, but it at least works:

Back on September 8th, a new version of Zorin was released (version 12.2 for anyone counting!) The release announcement explains what’s changed since 12.1 -basically, some under-the-hood tweaks, a newer version of Wine to help it run things like Office 2013, and a 4.10 kernel. It’s not exactly going to set the world on fire, I can’t help thinking!

Anyway: Atlas works on this new release of Zorin as it did on its predecessors, so Oracle 12c (either release 1 or 2) works fine: