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.
In my case I had the Ansible 1.9.4-1 package from EPEL already installed on my system, yum smoothly replaced the existing RPM installation and upgraded to Ansible 2.1.2 without any fuzz.
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.
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.
All set, just run rhn_register (or up2date-nox –register) and complete the registration.
If the browser can't connect to Oracle VM Manager due to obsolete protocol stack, use Firefox 44 or newer, and make your way through the obsolete protocol warnings and queries.
Please note that my fast track posts are intended for lab use only.
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.
Assorted errors related to missing tables after restoring OVMM database using provided tools.
All ovs tables with 0 rows are corrupted during restore.
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.
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.
wget --no-cookies --no-check-certificate --header "Cookie: gpw_e24=http%3A%2F%2Fwww.oracle.com%2F; oraclelicense=accept-securebackup-cookie" "http://download.oracle.com/otn-pub/java/jdk/7u67-b01/jdk-7u67-linux-x64.tar.gz"
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.
The installer now accepted localhost/XE:POOLED quite nicely for my Oracle 11g XE database with Database Resident Connection Pooling (DRCP) enabled.
[oracle@lonora02 ~]$ sqlplus "/as sysdba"
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.