I just did an upgrade of my old desktop from Fedora 20 to Fedora 21. The process was similar to this old blog post, but there were some variations, so I’ll list the procedure here.
It seemed to go fine!
Followers of my blog and website know I play around with installations on Fedora for fun. All of my installation guides on Fedora come with a link at the top that points to this disclaimer.
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 18.104.22.168.
The installation process of 22.214.171.124 on the production release of Oracle Linux 7 hasn’t changed since the beta. The installation of 126.96.36.199 on Oracle Linux 7 is a lot neater than the 188.8.131.52 installation. It’s totally problem free for a basic installation.
You can see the articles here.
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 184.108.40.206 installation at the bottom of the 12c article, but now 220.127.116.11 is available from OTN there is really no need for someone to be installing 18.104.22.168 other than for reference I guess.
It feels almost like heresy to discus something that isn’t Oracle-related on the day that Oracle announced the new In-Memory Database Option, but something else was also released today. Red Hat gave birth to Red Hat Enterprise Linux (RHEL) 7.
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!
Nearly two weeks ago, Oracle announced the Oracle Linux 7 Beta 1. Being the Linux fanboy I am, I downloaded it straight away from here.
Oracle Linux is a clone of the Red Hat Enterprise Linux (RHEL) distribution. The RHEL7 beta, and therefore OL7 beta, distro is based on a cut of Fedora 19, although depending on who you ask, it’s possibly more a mix of Fedora 18, 19 and 20… Suffice to say, there are a lot of changes compared to the RHEL6/OL6 distribution.
As I’ve mentioned several times before, my desktop at home is running Fedora 20, so I’m pretty used to most of the changes, but I’ve not written much about them, apart from the odd blog post. It’s not a high priority for me, since I’m not a sysadmin, but I’ll be updating/rewriting a few of the Linux articles on the site to include the new stuff.
When Surachart Opun mentioned having to look at systemd and firewalld, it seemed like the perfect opportunity to update my firewall and services articles. You can see the new versions here.
RHEL7/OL7 is only in beta, and even after the production release I’m sure it will be a long time before Oracle actually certify any products against it, but if you are not a Fedora user, it’s probably worth you having a play around with this stuff.
I’m in the process of taking on some of the MySQL databases in my company. The first ones are MySQL 4.1 running on Windows, so we are upgrading them to MySQL 5.6 on Oracle Linux. As with many of our systems, these will be running on VMware virtual machines.
Since the current installations are so old, we are planning on dumping out the data and creating fresh installations on the new systems. Based on the advice I got from Ronald Bradford and Sheeri Cabral, we are also taking this opportunity to switch to InnoDB and utf8, rather than MyISAM and latin1 that are currently used.
We are using the MySQL yum repository for the installation, so we can be on the latest MySQL version, rather than that shipped as part of Oracle Linux (or RHEL) 6.5. The other neat thing about this is it takes care of point release upgrades as part of the “yum update” process.
So far all my testing has been done on VMs running on my PC, but we are soon going to start rolling this out. It should be an interesting piece of work. The developers are doing a bunch of testing with InnoDB and utf8 to see what issues we come up against…
Update. For those new to MySQL, you might like to read this post by Patrick Hurley.
For those of you using Oracle Linux with UEK3, here are a couple of important blog posts that may have passed you by.
Following on from my recent batch of “what I’m doing at the moment” style posts, I just thought I would mention some of the infrastructure I’ve been installing and configuring recently…
We are still part way through a migration from Oracle Application Server to WebLogic 11g. There are many applications to migrate and test, fortunately not by me, but they fit into two main categories.
Some of our high profile applications of each type are already running in production on WebLogic and the general feedback has been very positive. I guess most of this comes down to the hardware refresh.
There are still a few more apps to migrate, but everything is pretty close to the end of testing now, so hopefully it won’t be long before we can say a not-so-fond farewell to Oracle Application Server!
All of these WebLogic installations are running on top of Oracle Linux 6 inside VMware virtual machines. So far we’ve seen nothing untoward about this setup and I would have no reservations about recommending this approach to others.
If you have any questions/concerns about Oracle Linux, you might want to read my Oracle Linux : Frequently Asked Questions article. If you have any concerns about Oracle’s stance as far as VMware support goes, you might want to read this.
Following from yesterday’s post about Cloud Control 12cR3, Oracle Linux and VMware, I thought I would just mention something I put live yesterday evening.
We have a 3rd party Java-based application that runs on Tomcat 7 and Java 7 that until recently was running on RHEL5 on physical hardware. It runs against an Oracle database, but that is not housed on this server. This application is not that big, but it is *very* high profile as it is what we use to process our REF submissions. If you know anything about higher education in the UK, you’ll know that REF is a very big deal, especially as we are within a couple of months of the next submission.
As I mentioned in February, like many of our systems, the resource utilization on the physical hardware was not optimal. We had this single Java app running on a server with 64G RAM and 12 cores, when it was probably using at most 6G and 2 cores. What’s more, there were two physical servers of this specification to provide manual failover, as the vendor does not support any form of clustering for automated failover.
What I did late yesterday was move this across to a VMware virtual machine running Oracle Linux 6. The benefits of this being:
- We can allocate just the resources we need. The existing physical boxes will be plugged into the VMware cluster and their resources used for something more useful than sitting around doing nothing.
- We can now use VMware’s HA functionality to provide automatic failover, giving us enough high availability for our needs.
- Using Oracle Linux gives us a variety of support options, starting from $0 upward.
IMHO this is another classic no-brainer as far as choosing a virtualized environment over physical and gets me one step closer to my vision for our systems…
If you are considering moving stuff to VMware and/or Oracle Linux, you might like to read these posts.
I mentioned some time ago that I was pushing my current company to move much of their gear on to VMware, mostly because of poor resource utilization on many of the servers. That process is still under way.
One thing I wanted to mention specifically was our use of Cloud Control 12cR3. Up until recently, we were using physical kit for this. We had an 11.2 database on HP-UX, With HA provided by HP Service Guard. We had two management servers on physical kit running RHEL5 pointing at this Service Guard package to give us some resiliency in of the OMS. It worked, but it was over complicated and I was never really happy with it for a number of reasons:
- HP-UX for the databases : I know some of you guys love it, but I don’t.
- Two management servers : Seems like a waste of kit to me. We either have them on their own boxes and waste lots of resources, or have multiple installations on those boxes, which adds to complexity and management of the kit.
- RHEL : Why pay for RHEL when we can use Oracle Linux and decide for ourselves if we want to pay for the extra features support gives us, or just use it for free?
So what are we running now? We have one VMware VM, running Oracle Linux 6. That has both the Oracle 11.2 database for the repository and the Cloud Control 12cR3 OMS running on it. We use VMware functionality for the HA of this system.
Why do I like this situation?
- Cloud Control is a complicated beast and I am a big fan of KISS (Keep It Simple Stupid). Having everything on a single VM is about as simple as it gets.
- If I am using Cloud Control in this way I pay nothing for the database repository. As soon as you start thinking about RAC or Data Guard to protect your repository you have to pay for Enterprise Edition licenses.
- Using VMware HA functionality gives us good enough HA for our purposes. We can failover or live migrate between hosts in the data centre, or between data centres.
- We can clone the whole installation in a few minutes and use that as a base for upgrades. If something goes wrong, we just flip back.
While I was at Oracle OpenWorld I discussed this a number of times and it seems it is a very common approach.
Another thing that came out of those discussions is many people still misunderstand what Oracle Linux is and the support status of Oracle Linux, and more specifically UEK, on VMware. Suffice to say, it’s all supported, as discussed in my Oracle Linux : Frequently Asked Questions article.
If you are struggling to decide how best to run Cloud Control in your organization, I would recommend using a virtual environment (Oracle VM or VMware) and run it on Oracle Linux 6.