I am not entirely certain what possessed ToH to suggest that it would be OK if I bought the Benjamin Britten and Peter Pears autographs that you see to the left.
But the suggestion was, for some reason, made… and swiftly acted upon. 😀
In consequence of which, yours truly got an early Christmas Present (I am told it’s also my January 2018 birthday present, plus Christmas 2018’s gift and also Birthday 2019’s… and probably ad infinitum thereafter!)
In fact, it didn’t cost the Earth (though a slightly smaller planetary body probably covers it); but framing it turned out to be surprisingly expensive -UV-protective, non-reflective glass doesn’t come cheap, apparently.
But at last Britten’s autograph now takes pride of place in my study …next to those of Nixon and Maria Callas.
Which makes me very happy.
In case I don’t write again this year, therefore: equal happiness and joy to all my readers as the Christmas season approaches!!
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:
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:
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:
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:
Red Hat has just released the latest update to its version 7 Enterprise Linux, so we are now up to RHEL 7.4.
Getting hold of it is, of course, rather more hard work than it would be for most distros, since Red Hat charge a pretty penny for the real thing! However, signing up as a Red Hat developer can be done entirely free of charge… and getting your mitts on it after that is a piece of cake (and costs precisely nothing at all 🙂 )
On to the obvious question: does Atlas work to make Oracle 12cR1 and 12cR2 installations on this new Red Hat version as simple as it did for earlier ones? Absolutely:
The article describing how to do it still holds true without any alteration or update being necessary, too.
OpenSuse Leap 42.3 has just been released. All sorts of under-the-hood improvements have, no doubt, taken place… but it basically looks exactly the same as before and I think you’d be hard-pressed to tell anything much had happened! (Which is a good thing, of course :-))
Crucially, it still works fine with Atlas for an Oracle 12cR1 or 12cR2 installation: