Ansible can certainly be installed using prebuilt packages from the EPEL repository, but while convenient, their offering is limited to Ansible 1.9.x – that is to say only versions prior to the major 2.0 release that includes a number of significant improvements, that were seen further polished in 2.1.

You will, more than likely, want to run 2.1.2, the latest stable release, for any production use, or perhaps the penultimate 2.0.1 release, if you are of a slightly more conservative origin.

That being said, I’ve always been told that DBAs like myself are about as conservative as they come, and I surprisingly experience no additional anxiety doing mission critical work with Ansible 2.1.2, which in truth, appear to be a solid release of the project’s most mature code yet. I should say these feelings are in strong contrast to those that come attached with Enterprise Linux 7 and Oracle Database 12c, products which are still years away from prime time in my twisted paradigm of the world.

These few commands should take care of dependencies required to build an RPM, pull Ansible code from their official repository on GitHub and do a checkout of the 2.1 stable release before building an RPM package on and for your system – which you can then install locally on your machine or distribute in your environment as you see fit. On a side note, I like to maintain local/internal repositories with custom built packages and approved updates, which lets me stay in control while keeping yum in position to deal with the tedious bits.

I’m using Oracle Linux 6.7 and have not tested this elsewhere, but the commands and package names should be identical on any 6 or 7 release of Oracle Linux, CentOS or RHEL and you should consequently be able to install without any modifications other than variations to the name of the generated RPM file.

At some point you may want to register an Oracle Database Appliance with the Oracle Unbreakable Linux Network so you can get a critical security update, without running a complete ODA update bundle.

However, if you happen to be running ODA Virtual Platform (that supports running virtual machines), rather than the bare metal version (that does not) – you may be up for a surprise.

“This system profile has already been registered”

Your ODA appears to already exist on ULN!
But wait, no, there is no sign of it on your account. What is going on here?

At least in the early versions of the ODA software, Oracle forgot to update the UUID for registration on the ODA_BASE image after installation. This means that ALL database appliances (with virtual support, anyway) would try to register with the same UUID.

Well, now that we know what the fuzz is all about, it’s easy enough to fix:

First generate a new UUID

[root@oda1-base ~]# uuidgen -t
abf436a8-0b33-11e6-9210-00163e76eec2

Then edit /etc/sysconfig/rhn/up2date-uuid and change the entry for rhnuuid to the freshly generated value

If you ever have to restore the Oracle Virtual Machine Manager database using the provided RestoreDatabase.sh, chances are that you will end up with a bunch of corrupted or missing tables in the back-end MySQL database schema. Specifically, all tables with 0 rows will be dysfunctional after successful restore. In turn this prevents management of compute-nodes, virtual machines and other resources.

I don’t know which other versions of OVM might be affected, but the latest 2.0.2 software release for the Virtual Compute Appliance certainly is.

I wrote a workaround that will identify, drop and re-create the corrupted tables. No guarantees, but it did the trick here. Perhaps it can save someone a bit of a headache.

If you’re having a rather dull afternoon at the office, and you happen to have an OVCA as your personal playground, you can always try this little trick to spice up your day: Point your browser to the Oracle VM Manager, look for the the network configuration tab and attempt to make the storage and heartbeat network available to virtual machines. I can virtually promise you that your day will be more interesting. Much more. Almost instantly.
ovca_network.png

Without spoiling all of the little surprises, I can disclose that you will have some enlightening moments watching the first compute node (typically ovcacn07r1) head for a rapid reboot, just as soon as the cluster watchdog sees that the OCFS2 voting drive is no longer responding. Granted, it may take a few moments for it to notice, but I can assure you that it’s worth waiting for. You see, it will leave behind an inconsistent Oracle VM Pool, which in turn will trigger dozens of interesting events.

If and when you manage to start any of the lost guest machines, the fun increases as you can watch the pool balancer continuously migrating machines from one compute node to the next. Personally I found this last bit absolutely fascinating. For an additional kick, try having an open ssh session to one such machine.

I will leave the rest for you to figure out. Tons of fun!

Now, if on the other hand, you have an OVCA running, say, a production workload, I strongly suggest you keep your VMs very much isolated from the 192.168.40.0 network.

Well, unless you are you are really, really, really bored and you, preferably, get paid by the hour.

I encountered and worked around a couple of issues when installing MediaWiki 1.20.2 with Oracle 11g Express Edition 11.2.0.2.0 as the database back-end. The solutions below can be also applied to MediaWiki 1.20.0 and 1.20.1.

I did the installation on top of Zend Server Community Edition, saving me the trouble of tinkering too much with apache, php and oracle drivers.

First out, the web installer did not accept the new Easy Connect string format, even though the help text encouraged such use. The Zend Server environment doesn’t play well with TNS based connect strings these days, so I worked around this by commenting out the validation code on line 90 and 91 includes/installer/OracleInstaller.php:

After a couple of attempts, I found that the installer failed to create a database user, so I created a user manually, I suppose this is a good practice in any event, based on maintenance/oracle/user.sql

After installation successfuly completed, I found a bug that was introduced in MediaWiki 1.20.0, where an array would incorrectly translate to a variable thus breaking a lot of SQL queries and making the wiki all but unusable. Luckily, I was able to borrow an existing workaround from the Postgres database script and modified includes/db/DatabaseOracle.php to implode the array to a comma separated list before passing it on to the variable. I found that this problem occurred two places, around line 1165 and 1168.

I really think it’s great that the MediaWiki team has taken the time to support Oracle database, not too many open source products like this do. The bugs I found have been reported and hopefully these issues will be all fixed by the next stable release.