I blogged somewhat recently about my interest in, and inaction around, static site blogging, where you write blog posts, use an app to turn them into plain HTML, and then drop them somewhere on the web, with no shadow of potentially/eventually vulnerable PHP and MySQL cranking away to deliver dynamically what needn't be dynamic.

I hadn't yet pulled the trigger on ditching WordPress yet, preferring instead to satisfy my desire for writing posts in plain AsciiDoc-formatted text by copying and pasting rendered AsciiDoc into WordPress, or using this AsciiDoc-to-WordPress script to pump in posts through the WordPress API.

The latest version of the open source virtualization platform, oVirt, has arrived, which means it's time for the third edition of my "running oVirt on a single machine" blog post. I'm delighted to report that this ought to be the shortest (and least-updated, I hope) post of the three so far.

When I wrote my first "Up and Running" post last year, getting oVirt running on a single machine was more of a hack than a supported configuration. Wrangling large groups of virtualization hosts is oVirt's reason for being. oVirt is designed to run with its manager component, its virtualization hosts, and its shared storage all running on separate pieces of hardware. That's how you'd want it set up for production, but a project that requires a bunch of hardware just for kicking the tires is going to find its tires un-kicked.

Rock the Vote needed a way to manage the fast growth of the data handled by its Web-based voter registration application. The organization turned to GlusterFS replicated volumes to allow for filesystem size upgrades on its virtualized hosting infrastructure without incurring downtime.

Over its twenty-one year history, Rock the Vote has registered more than five million young people to vote, and has become a trusted source of information about registering to vote and casting a ballot.

Since 2009, Rock the Vote has run a Web-based voter registration application, powered by an open source rails application stack called Rocky.

I'm a big fan of virtualization – the ability to take a server and slice it up into a bunch of virtual machines makes life trying out and writing about software much, much easier than it'd be in a one instance per server world.

Things get tricky, however, when the software you want to try out is itself intended for hosting virtual machines. These days, all of the virtualization work I do centers around the KVM hypervisor, which relies on hardware extensions to do its thing.

The Fedora Project'sinfrastructure team needed a way to ensure the reliability of its Fedora Hosted service, while making the most of their available hardware resources. The team tapped GlusterFS replicated volumes to convert what had been a two-node, active/passive, eventually consistent hosting configuration into a well-synchronized setup in which both nodes could take on user load.

Hosting Fedora Hosted

The Fedora Infrastructure team develops, deploys, and maintains various services for the Fedora Project. One of these services, Fedora Hosted, provides open source projects with a place to host their code and collaborate online.

This morning I was trying to help figure out why a slick new Mediawiki skin was working just fine on an OpenShift-hosted Mediawiki instance, but was totally borked on a second Mediawiki instance, running on a VPS server.

Both the VPS and OpenShift run on the same OS: Red Hat Enterprise Linux. Both were running the same version of Mediawiki, 1.19.2, both had the same version of PHP: 5.3.3.

I compared the php.ini file from the VPS machine with the php.ini from OpenShift, which is findable at ~/php-5.3/conf/php.ini in your OpenShift gear. (You can ssh into your OpenShift instance at the remote "origin" location in your APPNAME/.git/config file).

I've been installing oVirt 3.1 on some shiny new lab equipment, and I came across a pair of interesting snags with engine-iso-uploader, a tool you can use to upload iso images to your oVirt installation.

I installed the tool on a F17 client machine and festooned the command with the many arguments required to send an iso image off through the network to the iso domain of my oVirt rig. The command failed with the message, "ERROR:root:mount.nfs: Connection timed out."

A little while back, I tested out the Unified File and Object feature in Gluster 3.3, which taps OpenStack's Swift component to handle the object half of the file and object combo. It took me kind of a long time to get it all running, so I was pleased to find this blog post promising a Quick and Dirty guide to UFO setup, and made a mental note to return to UFO.

When my colleague John Mark asked me about this iOS Swift client from Rackspace, I figured that now would be a good time to revisit UFO, and do it on one of the Google Compute Engine instances available to me while I'm in my free trial period with the newest member of Google's cloud computing family. (OpenStack, iOS & Cloud: Feel the Search Engine Optimization!)