Dizwell Informatics

News from Nowhere

The Dizwell Blog

Fedora 26 arrives…

Fedora 26 has just been released (I downloaded it even before Distrowatch mentioned it was available, so for once my timing was impeccable!) The release notes are available here, explaining what has changed since the previous version. Combining that with the other changes listed here and here, I have to say that most of the changes seem under-the-hood kind of stuff -though the increment in gcc version sounds like it could be trouble, and the default wallpaper is surprising in its bland twee-ness! The icon for the file manager turns blue, as well. Don’t get too excited!!

As usual, the main question in my mind when a new version hits the streets is: does it work with Atlas (and hence Oracle 12cR1 and 12cR2)?

The news on that is both good and bad: the good news is that the linking stage completes entirely without error (meaning that a software-only install works fine). But the bad news -really bad!- is that when the installer tries to create a database… nothing happens. Even if you try and launch the Database Configuration Assistant manually (type: dbca), it pops up its splash screen and then just sits there doing nothing. No errors are either reported or logged, though. The thing simply sits there idle, for no apparent reason.

So, I expect you could do a software-only install and then create a database using good old SQL*Plus and the ‘create database…’ command, but that’s obviously not the Atlas way of doing things… and I’ll therefore be working on this in the next day or two and, hopefully, get things running ‘properly’ once more; but I haven’t had a chance to try and diagnose this as yet, so I make no promises on that score!

Anyway: despite this failure to run Oracle, and with something approaching sheer recklessness, I nevertheless decided to do an in-place upgrade of my existing Fedora 25 desktop. It’s easy enough to do. First, I made sure everything on my version 25 PC was up-to-date:

sudo dnf upgrade --refresh

Next, I had to allow DNF to do system upgrades by installing a plugin that gives it the necessary functionality:

sudo dnf install dnf-plugin-system-upgrade

After that, just check that an in-place upgrade is actually possible:

sudo dnf system-upgrade download --refresh --releasever=26

If that reports unresolvable dependencies, then the upgrade won’t actually take place (unless you add the –allowerasing option, but then you will lose some software that’s already been installed, which may or may not be acceptable. I had to agree to lose my installation of the Chromium browser, for example: no great hardship these days, as I generally use Vivaldi, though as it turns out, it re-installs a more up-to-date version in its place anyway). But otherwise, it will download a lot of software (2.6GB in my case) and get your PC in a state ready to upgrade. Before finishing things off, best you take a backup of everything you care about: the next command is the point of no return:

sudo dnf system-upgrade reboot

…which actually does the business (and starts off with a reboot, so that the upgrade process takes place essentially in a command line-only environment). My upgrade took a while (my Internet connection is not great at the moment), but otherwise went well. All my apps appear to be running normally afterwards, too… so, no harm done (that I can tell!)

Password-less Samba on Fedora 25

I recently needed to allow a Windows server to access some files which were stored on my Fedora 25 PC. I could have used NFS, but for reasons passeth understanding, I decided to do it with Samba instead -and immediately discovered that my knowledge (or, rather, recollection) of Samba is a bit rusty these days! Sharing stuff is relatively easy to do… but doing it in the context of a PC that uses a firewall and SELinux was definitely not trivial.

So, on the grounds that Fedora 25 has 2 more days of life in it yet; and recognising that I need to remember this stuff from time to time, I wrote the inevitable short piece on the subject.

Understand, I’m not trying to be subtle about it: I wanted anyone to be able to do anything in the Samba network share, without being asked for usernames or passwords. This isn’t the sort of configuration you are likely to want in any production setting I can think of, but for a home network under my total and sole control, I figured it would do!

In any case, the new short article is here.

Atlas and Mint 18.2

It is obviously the season for assorted Linux distros to release new versions. Like busses, you wait a long time with nothing much happening -and then four or more come along at once!

On July 2nd, it was the turn of Linux Mint to release a new version, code-named Sonya, numbered 18.2.

It’s based on Ubuntu 16.04, which means it suffers from the usual problems that beset any Ubuntu-based distro when trying to install Oracle 12c Release 2… basically, nothing works at all! However, installing and using 12c Release 1 is fine.

Nothing about Atlas therefore has changed: it can be used as-is to achieve simpler 12cR1 installs on the new distro version:

Incidentally, I am still trying to work out what is going wrong with Ubuntu (and Ubuntu-based!) distros and 12c Release 2. I am not having much luck tracking it down, though. If anyone has input they’d care to offer, I’m all ears!

Encryption Options

In these days of rampant ransomware and ever-more intrusive “security” screening of incoming laptops by “the authorities”, the subject of easy-to-use encryption is more important than ever, I would have thought.

This recent article is a nice roundup of the available software solutions.

I’d add to it only this much: if you’re a Windows Pro or Enterprise user, make friends with Bitlocker. If you are a user of cloud-based storage, I cannot recommend BoxCryptor (mentioned at the end of that recent article) highly enough. And, as a Linux user, good old gpg is definitely handy for per-file encryption -though key management is always a problem, whatever your encryption methods, and I speak as someone who just toasted 140GB of data because I can’t remember the encryption key I used and, unaccountably, I seem not to have stored it anywhere, as is my usual practice. 🙁

Atlas and Debian 9

Debian 9 (“Stretch”) was released on Sunday 18th June.

There are lots of changes under the hood, but few that make a major difference to the desktop experience (unless you count the death of ‘Ice Weasle’ and the return of vanilla ‘Firefox’ major).

Unfortunately, as I mentioned way back in January, the Atlas-assisted Oracle installation fails completely when run on the finished Debian 9 because of problems with the latest version of gcc and g++, resulting in an ‘error in invoking target links proc gen_pcscfg procob’ failure as soon as the linking phase starts.

Happily, it’s fixable by forcing the use of an older version of the gcc compiler, using the commands (run as root, before attempting the Oracle installation at all):

apt-get install gcc-4.9 g++-4.9
update-alternatives --install /usr/bin/g++ g++ /usr/bin/g++-4.9 50
update-alternatives --install /usr/bin/gcc gcc /usr/bin/gcc-4.9 50
update-alternatives --install /usr/bin/cpp cpp-bin /usr/bin/cpp-4.9 50
update-alternatives --set g++ /usr/bin/g++-4.9
update-alternatives --set gcc /usr/bin/gcc-4.9
update-alternatives --set cpp-bin /usr/bin/cpp-4.9

When you are about to launch the database/runInstaller, check that your environment has picked up the ‘old’ compiler version by typing gcc -v… you should see a great pile of techie stuff, ending in the lines:

Thread model: posix
gcc version 4.9.2 (Debian 4.9.2-10)

If your oracle user sees something like that, then the Oracle installation will succeed:

The problem affects 12cR2 just as much as 12cR1. Fortunately, the same fix applies equally well to both Oracle versions, too:

I haven’t ported this fix into Atlas as yet: it’s something you have to do manually at the moment, but when time permits, I’ll automate this as I automate everything else!

Atlas now includes the fix for Debian 9 and therefore now correctly automates 12cR1 and 12cR2 installations on that distro without error.

Catch Up Delayed…

Sadly, my uncle died on Easter Sunday, at the (for our family!) grand age of 82. My aunt is not taking it particularly well which, given they were married for 59 years, is not entirely surprising.

I will say that getting 12cR2 installed on Ubuntu-based distros is not just a question of altering the gcc version in use, as I had hoped in my last post: I tried that without success. Meaning that we are still without 12cR2 working on any Ubuntu-based distro and with no obvious, simple fixes.

And, I’m afraid, given the need to organise family stuff and deal with funeral attendance etc., it’s unlikely I’m going to get much further with Ubuntu and 12cR2 for some weeks to come.

I’ll get back to it when I can. Meantime, please forgive and understand the posting silence that will now ensue for some time.

Atlas and 12cR2

Continuing the saga of “catching up” with software developments whilst I was en route to the UK from Australia, the question next to be addressed is simply: does Atlas work to allow Oracle 12c Release 2 to be installed onto the many and various distros it claims to support.

The answer is a bit mixed, I’m afraid!

First thing to say: I deliberately coded Atlas to specifically declare 12cR2 ‘didn’t work yet’ when I first released it. So, for it to work for 12cR2 at all, that bit of code has to be removed -and that means Atlas straightaway gets bumped to version 1.2.

Once that code has gone, the good news is that Atlas will successfully help 12cR2 be installed on the majority of the distros it works with (15 out of 19, as it happens). But the bad news is that if your distro is Ubuntu or even just Ubuntu-based, then the linking phase of the Oracle 12c Release 2 installation fails irreparably after Atlas has been run.

The complete list of distros and their results with Atlas for 12c Release 2 is therefore as follows:

Debian 8.2+ ............................ Works fine
Linux Mint 18+ ......................... Fails
Mint Debian Edition 2+ ................. Works fine
Red Hat ES 7.0+ ........................ Works fine
Scientific Linux 7.0+ .................. Works fine
CentOS 7.0+ ............................ Works fine
OpenSuse Leap 42+ ...................... Works fine
Antergos  2016.11+ ..................... Works fine
elementary OS 0.4+ ..................... Fails
Mageia 5+ .............................. Works fine
Korora 25+ ............................. Works fine
Zorin Core 12 .......................... Fails
Ubuntu 16+ ............................. Fails
Manjaro 15+ ............................ Works fine 
Fedora 23+ ............................. Works fine
Peppermint Linux 7+ .................... Fails
GeckoLinux Static 422+ ................. Works fine
Chapeau Linux 24+ ...................... Works fine
PCLinuxOS 2016+ ........................ Works fine

As I say, the pattern is pretty obvious and I suspect the problem is that the gcc versioning tricks I had to pull to get 12cR1 to compile properly on any Ubuntu-based distro back in January are now the cause of woes for 12cR2. The failure always manifests itself in the following manner:

There’s no recovering from that as yet, but I hope to get it sorted within the week.

On the other hand, for any distro listed as working fine in the above list, you can expect the usual plain sailing:

That’s specifically Oracle 12.2.0.1 running on GeckoLinux, which is a spin of openSUSE Tumbleweed, but you get the same outcome for all non-Ubuntu distros.

Whilst testing all this, I discovered a couple of distros which had incremented their version strings since January (Manjaro, for instance, now reports itself as version ’17.something’, so the part of Atlas where it checked for version strings containing the numbers 15 or 16 obviously needed updating). Those sorts of versioning updates are now also included in Atlas 1.2.

There is very little updating of the Atlas doco to do, happily. For a start, you will obtain the new Atlas version just by running exactly the same wget command as was previously documented: the URL alias simply points to the latest version, but the URL itself doesn’t change.

When you install Oracle 12cR2 onto any of these non-standard distros (except the RHCSL ones, of course), you will get this dire-looking warning:

It’s better than the 12cR1 equivalent, which was to say ‘your system is inadequate’! Anyway, for all the distros for which Atlas works at all, it’s perfectly OK to say ‘yes, I want to continue’. The installation will succeed anyway.

Have fun… and wish me luck whilst battling with Ubuntu later this week 🙂

Atlas, Ubuntu 17 and 12cR1

As I mentioned last post, one major issue that has arisen since I left Australia is this: does Atlas run on the freshly-released Ubuntu 17.04 to make Oracle 12c Release 1 (12.1.0.2) installations a piece of cake? It was working fine on 16.04 and 16.10; but would things break with the fresh 17.04 release?

Here’s the answer:

To be fair, I had to alter the Atlas script in one tiny respect: it originally tested for the existence of ’16’ as one component of the distro’s version string. That was obviously a bit restrictive! I’ve now added ’17’ as a test, too… and that means Atlas’s version bumps to 1.1.

You don’t need to do anything different than was originally documented, though: the ‘wget http://bit.do/dizatlas -O atlas.sh‘ instruction works as it always did. It’s just that it now downloads the newer Atlas script instead of the original.

Catch Up

Well, it’s been a rather longer break than I had expected, but I now found myself living in my new 1930s house in sunny Nottingham. The sale finally completed on March 24th; I moved in on April 1st; the furniture from Australia doesn’t get here until early June. In the meantime, I have one sofa bed, 2 plates, 2 cups, 3 pairs of knives and forks and a kettle to live with. A comfortable transition it is not!

But I have proper Internet (50Mb/sec seems like luxury to me, anyway) and the cats arrived safely from Down Under just in time for Easter. They seem to have survived the journey without mishap and don’t appear to be too put out about it. Finding an English cat food they actually like is taking time and many trips to different supermarkets, however!

Short version: private life is still a bit on-hold and will be until at least June, after which we can think of renovating the place properly and turning it into the Art Deco palace we think it could be.

But back to techie stuff: there are two major items of interest that require some catching up, I think. The first is the fact that Ubuntu 17.04 was released on 13th April. Does Atlas work with that as it did for 16.10?

Secondly, and much more substantially: does Atlas work with the new Oracle 12c Release 2 version, for any or all of the distros that it was working with for 12cR1?

This being Day 2 of having a functioning Internet, and all my servers still in a cargo ship’s container somewhere between Sydney and Suez, it’s going to take a while before I can definitively address these issues. But I am at least back on the job… whenever the cats will get off my keyboard, at least.