It’s 2017 and it’s still not possible to reliably upgrade an Enterprise Linux distribution between major versions!
At this point you are scrolling down to the comments to “educate me” about the redhat-upgrade-tool, because you read about it somewhere and you once heard someone successfully upgraded an installation on a lab machine. Unless you have an ultra vanilla starting point, you are going to end up with a mess that probably won’t boot. By the time you come to upgrade a “real server”, there have been years of changes and it is unlikely to resemble some pristine minimal installation.
I know your next comment is going to be something about the architectural changes brought in by project X and version Y in RHEL7, which is why it is all so hard. Stop now! You are boring me already! Is it an enterprise distribution or isn’t it? If it is, you should be able to upgrade it reliably!
Next up comes, “But you have to reinstall when you get new hardware!” I present to you virtual machines. Physical hardware upgrades with no need to reinstall the OS on the VM.
I can’t believe I’ve been using Linux for about 19 years and this is where we are at.
A few days ago we had a rather unproductive web session at work with an Oracle Linux Support sales team. They were obviously keen to sell us Oracle Linux support contracts and I was keen to only pay if we were getting something of value from the deal.
We already use Cloud Control for managing our Oracle Database and WebLogic installations. We are currently transitioning from Cloud Control 12c to Cloud Control 13c. Buying OS support brings nothing to the table here.
We have a company policy to use SCOM (and Squared Up) for monitoring, so at this point Cloud Control 13c is never going to be used as a general monitoring tool across the organisation.
We don’t really have a need for Ksplice. I’m not denying it’s a cool piece of kit, but at this point we really don’t need it.
We don’t want to rip out all our other tools to replace them with Cloud Control.
Although I predominantly work on UNIX and Linux systems, the vast majority of the servers in the company run Windows. As a result, products that suit Windows tend to take priority. 🙂
The piece of the puzzle we are really missing is management of Linux patching, repositories, channels etc. After asking several times for some information I got pretty angry and said something to the tune of, “Look, I’m throwing you a bone here. Give us some information on using Cloud Control 13c for Linux patch management and maybe you’ll be able to persuade us to spend some money.” The response was something to the tune of, “Yes. You can do Linux patch management.” What a well thought out response! Amazing!
I’ve held back on writing this post for a few days because the whole process was infuriating and I would have ended up calling those salespeople fuckwits and morons, which would be rather unproductive…
Anyway, as a response to that fiasco I decided to spend the weekend having a play with Spacewalk at home. Not the jazzed up Oracle version, but the open source and, more importantly, free version.
I’m not part of the Sys Admin team at work, but I like to play around with stuff and get an idea of what it brings to the table. I think Spacewalk will fit well into what we already have, and it won’t cost us any money. As a result of playing around with it I’ve decided to use Spacewalk at home to manage all my VMs. 🙂
I’m a fan of Oracle Linux and I’m a fan of Cloud Control. I’m not saying Cloud Control is not capable doing the stuff we need. It might even be better than what we have now. It’s just not an option for anything other than managing our Oracle databases and WebLogic servers at this time.
I’m not a fan of idiot sales people that don’t care to understand what the customer wants and repeatedly spout preplanned sentences that are meant mislead and to scare you into buying something you don’t need.
No real drama here. It was pretty much the same as Fedora 23 in that respect.
It’s kind-of hard to get excited about a new version of Fedora since I switched my desktop from Fedora to Mac. One thing that was interesting is the change to the upgrade process. In previous releases I used “fedup” to do it. Now it’s pretty much done using DNF (YUM). If you are interested, you can read about it here.
This did cause one really annoying problem in F23 though. The “MATE Desktop” had a single documentation package that was causing a problem. Usually I would use the following.
yum groupinstall "MATE Desktop" -y --skip-broken
Unfortunately, DNF doesn’t support “–skip-broken”, so I was left to either manually install the pieces, or give up. I chose the latter and use LXDE instead. 🙂 F23 is an Alpha, so you expect issues, but DNF has been in since F22 and still no “–skip-broken”, which I find myself using a lot. Pity.
A few times recently I’ve been contacted by people saying their boss, teacher or customer is insisting they install Oracle on Fedora. Rather than repeat myself, I’ve added another point at the bottom of this disclaimer that reads:
Q: My boss/teacher/customer is insisting that I should install Oracle on Fedora. What should I say to them? A: Your boss/teacher/customer is making a mistake, probably because they do not understand the implications of what they are asking you to do, or do not know about the free alternatives. You should probably get them to read this Oracle Linux FAQ. If they are still unsure, feel free to put them into contact with me and I will happily educate them.
If you are being asked to do something that is blatantly incorrect, it is your responsibility to educate those around you so they can (hopefully) make better choices in future.
I did a quick update of my Oracle installation articles on Oracle Linux 7. The last time I ran through them was with the beta version OL7 and before the release of 22.214.171.124.
The installation process of 126.96.36.199 on the production release of Oracle Linux 7 hasn’t changed since the beta. The installation of 188.8.131.52 on Oracle Linux 7 is a lot neater than the 184.108.40.206 installation. It’s totally problem free for a basic installation.
There is a bold warning on the top of both articles reminding you that the database is not supported on Oracle Linux 7 yet! Please don’t do anything “real” with it until the support is official.
Note. I left the fix-it notes for the 220.127.116.11 installation at the bottom of the 12c article, but now 18.104.22.168 is available from OTN there is really no need for someone to be installing 22.214.171.124 other than for reference I guess.
I’m a big fan of all things Linux. I’m typing this blog post on a Fedora 20 desktop at home. I’m a rabid fan of Oracle Linux for servers at home and at work. As a result, the birth of RHEL7 is a pretty big deal for me.
I’ve been playing with the Oracle Linux 7 betas for a while (OL7 Install, DB 11gR2 Install, DB 12c Install). I expect we will see the birth of Oracle Linux 7 pretty soon, which is where it gets really interesting for me.
I’m sure it’s going to take quite a long time for Oracle to start supporting their products on RHEL7/OL7, but this is the future, so you’ve for to get your skates on! 🙂