blogging, control and open source

I’ve been sort of trying to get blogging again on WordPress lately, and as part of that, I’ve been paying more attention to the blogs I’m following using the WordPress Reader function. Recently, on Om Malik’s blog, I saw this item, pointing to the blog of photographer Eric Kim:

Instagram is now like Facebook

I clicked because I’ve been thinking grumbling thoughts lately about Instagram and its Twitter preview hiding ways.

OK, yeah, algorithm hate — it seems that every social network eventually adds features for bubbling up, through the magic of computer science, potentially interesting items you may have missed. These features disrupt the straight chronological feed presentation that many users prize (for themselves or for their followers). I know about these sentiments. I don’t share them — I like the option of “smart” timeline presentation. But, to each their own.

Anyway, I was interested to read, lower down, his suggestion: Start your own blog, and use WordPress.

I agree with this. I too am using WordPress, in part because WordPress works well, and in part because WordPress is open source software, and I’m an open source software loving sort. I was intrigued, further down, to see that all of Kim’s site content was open source:

Awesome! I clicked this link, assuming I’d find a creative commons license, but found instead a pair of essays about Kim’s ideas around open source photography:

OK, that sounds good. But what about licensing? I couldn’t Ctrl-F my way to finding the word “license” anywhere, so I broke down and read a bit more closely. I found this:

I also wanted to announce that I have recently made all of my photos on Flickr available for free as full-resolution downloads.

The terms he described sounded like a creative commons non-commercial license, which I don’t really consider to be open source, but whatever. Interestingly, the license he’s actually using is more permissive than he describes. He’s chosen the Public Domain Mark 1.0 license, which states that, “You can copy, modify, distribute and perform the work, even for commercial purposes, all without asking permission.”

As for the content on his site, there’s no license, but this chunk of text suggests that he may be talking about something else when he says “open source”:

So, interestingly, he’s at once ceding more control (over his pictures) and less control (over his blog posts) than he seems to intend. Even among open source software enthusiasts, it’s sort of common to downplay/misunderstand/dismiss licensing, and to insist that what really matters is something else: community, process, governance, etc. All of that definitely matters, but we can’t forget about licensing — copyright laws enforce a no-sharing-allowed default setting, so when we set out to collaborate freely, we need to explicitly change that setting, and open source licensing is how that’s done.

Speaking of which — I hadn’t yet put any license information of my own on this blog, which made it ALL RIGHTS RESERVED. I fixed that with a visit to the creative commons license chooser page and some wordpress widget box-fiddling.

What I Look For In An Open Source Project Web Site

Perusing new open source software projects has long been both a job requirement and a pastime for me. Over the past decade plus so I’ve come across a ton of open source project web sites, running the gamut from good to bad — with a healthy contingent of ugly in the mix.

Of course, it takes more than a sweet web site to make an open source project worth writing about or contributing to — a project that offers up a lousy solution to a real problem, or, worse, seeks to answer an unasked question has more fundamental issues to tackle. On the other hand, you could have a project ideal for scratching, elegantly, some global itch, but if the project does a poor job conveying its whys and hows, it could end up overlooked.

The basic information I look for in an open source project home page, either right up front or no more than one clearly-labeled link deep, fits (or, at least, can be made to fit) into the classic Five W’s (and an H) model:

What is the project about / what does it do / what is it for?

Pretty straightforward. If see a tweet from an open source savvy pal that says something low-context like, “really impressed with what they’ve got going on at $LINK,” and you click, it shouldn’t take long, at all, for you understand what the project is about.

Initially, I’d left mention of license till the bottom of this post, but for an open source project, that’s another “what” I like to see answered right up top: what’s the license?

Why should I care / use / contribute?

What is it and why should I care sort of go together: a first impressions one-two punch. OK, so I see that this project is (say) a command line to do manager. What makes this one better or different than the million other to do apps out there? A well-written “what is it” blurb ought also to answer the “why should I care” query.

Where do I get it (packages / binaries / source)?

All right, the project does X and does it in a way that seems sufficiently interesting. Where do I get it? If the project is packaged up for particular operating systems, which ones and where do I find those packages? Where’s the source?

How do I use it / get involved?

When I’ve gotten interested enough in a project to learn about what it’s supposed to do and where I can go to get it, I like to take it for a short spin. The most effective projects make it easy for users to get their feet wet by offering up some short getting started instructions.

Who’s working on the project, and how can I connect w/ them?

Over the past few years, when I come across a project that seems interesting, but perhaps not yet ready for prime time (or just to be useful to me), I scan the project site for the Twitter feeds or the blogs of the project’s key developers to follow or add to my RSS feed reader. Sometimes these links lead me to other interesting projects, and future tweets or blog posts serve to jog my memory about projects I’ve looked into but didn’t end up digging into in earnest.

When was the last release, repo activity, project update (proof of life / sell by date)?

The Internet is littered with the floating husks of dead open source projects, and depending on the web site, one’s slow-moving-but-not-dead project can look exactly like a project that’s gone, never to return. Abandoned projects tend not to be very interesting to me, but that doesn’t stop my friendly neighborhood search engine from suggesting them. When I’m checking out a project, I stay on the lookout for things like commit dates in source repositories, for release dates on binaries, and for mailing list activity. The best projects don’t make me dig for long.

Those are the basics I look for in an open source project web site, though there are other, specific details I like to see right up front, like the license a project uses. Is it something familiar, like GPL or Apache, or is it some wacky vanity spin of the MPL that requires careful reading before you get an idea of what is and isn’t allowed?

What do you look for in an open source project web site?

How to Get Up and Running with oVirt

NOTE: The most recent version of this howto, for oVirt 4.1, lives HERE.

As a fan both of x86 virtualization and of open source software, I long wondered when the “Linux of virtualization” would emerge. Maybe I should say instead, the GNU/Linux of virtualization, because I’m talking about more than just a kernel for virtualization — we’ve had those for a while now, in the forms of Xen and of KVM. Rather, I’ve been looking for the virtualization project that’ll do to VMware’s vSphere what Linux-based operating systems have done to proprietary OS incumbents: shake up the market, stoke innovation, and place the technology in many more people’s hands.

Now, I may just be biased — I work for one of the companies trying to give this technology away to those who want it (and sell it to those who’re looking for support) — but the time for that Linux of virtualization is has finally come. Last week, the oVirt Project shipped its first release since the source code for the project’s Java-based management server went public last November. After having toiled through building and configuring oVirt back in November, I’m happy to report that the process has gotten much much simpler. Plenty of work remains to be done, particularly around supporting multiple Linux distributions. However, if you have a reasonably beefy machine to test with, you can be up and running in no time. Here’s a step-by-step guide to installing a single server oVirt test rig:

Step one, get a machine with Intel VT or AMD-V hardware extensions, and at least 4GB of RAM. As with all virtualization, the more RAM you have, the better, but 4GB will do for a test rig.

Step two, grab a Fedora 16 x86_64 install disc and install Fedora.  Also, you’ll want to have a client system capable of accessing the spice-based console of your VM–for now, Fedora’s your best  there as well. (update: I did some spice-xpi packaging for Ubuntu 11:10 and openSUSE 12.1) You can access oVirt systems via VNC, as well, though that path is rougher around the edges right now.

(An aside: right now, oVirt is most closely aligned with Fedora, as the only current downstream distribution is Red Hat’s RHEV. However, getting oVirt into as many distros as possible is a priority for the project, so let’s hurry up and install this so we can get to work on Ubuntufication and openSUSEification and whatnot!)

For my Fedora 16 test machine, I went with the minimal install option, and got rid of the separate /home partition that the Fedora installer creates by default, leaving that space instead to the root partition. For networking, I stuck to dhcp.

After installing F16, start the network, set it to start in the future by default, and see what your IP address is:

service network start && chkconfig network on && ifconfig -a

From there, ssh into your machine, where it’s easier to cut and paste directions from the Web. Since I installed my system from the Fedora DVD, I yum update to install the ~79 updates that have been released since. (And remind myself for the 1000th time to look into creating a local Fedora repository)

Next, install wget (the minimal install doesn’t come with it) and grab the repository file for oVirt Stable:

yum install -y wget && wget -P /etc/yum.repos.d/

(I’ve been setting up my test installs using the root user, if you’re logged in as a regular user, use sudo as needed)

Then, install ovirt-engine, the management server for oVirt:

yum install -y ovirt-engine

(on my minimal install, this step pulled in 100 packages)

Next, run the setup script for oVirt Engine, cleverly tucked away under the name:


The script asks a series of questions, and it’s safe to stick with the defaults. The script will ask for your machine’s fully-qualified domain name, and suggest its host name by default. If the name doesn’t resolve properly, the script will ask if you’re sure you want to proceed. It’s OK to proceed anyway — if you run into trouble you can work around it by modifying /etc/hosts, and for this single server config, well, your server knows where to find itself. Choose NFS as the default storage type, and let the script create an NFS iso share for you. I chose the path /mnt/iso and name ‘iso’


Type yes to proceed. When the script finishes, it’ll tell you where to reach the ovirt web interface, at port 8080 or 8443 of your management server. Before we head over there, though, let’s do a bit more storage configuration.

In keeping with the all-in-one theme of this walkthrough, we’re going to create three nfs shares on our management server: one for hosting the iso images from which we’ll install VMs; one for hosting our VMs’ hard disk images; and one for hosting a location to which we can export VMs images we may want to move between data domains. If you let the engine-setup script create an nfs share for you, you’ll see this line in /etc/exports:

/mnt/iso #rhev installer

Create two more like it:


Then head over to /mnt to create the data and export directories:

cd /mnt && mkdir data export

All three of our storage folders need to be owned by user vdsm and group kvm. The iso folder that the engine-setup script created is already owned by vdsm:kvm — the data and export directories we created need to match that:

chown vdsm:kvm data export

Another NFS configuration bit here. oVirt wants to mount its NFS shares in v3, not v4. You can ensure this either by disabling nfs v4 on the server side or on the client side, as described in the oVirt wiki, here. I’ve been disabling NFSv4 on my ovirt-engine boxes by adding this line to /etc/sysconfig/nfs, and then restarting the service:


systemctl restart nfs-server.service

Now we have a oVirt Engine management server and three NFS shares, and we’re ready to add a host to handle the compute. Since this is a single-box install, we’re going to configure our management server as a virtualization host. This step is based on the wiki page at First, we install bridge-utils and create a network bridge:

yum install -y bridge-utils

vi /etc/sysconfig/network-scripts/ifcfg-ovirtmgmt

This is the contents of my bridge config file:


Then, to the config file for my network adapter, I add the line:


And then, restart the network:

service network restart

(Again, this is on my minimal install. If you’re using a Fedora machine with NetworkManager enabled, you should also disable NM. Check the wiki for more info.)

Now let’s hit the oVirt Engine administrator portal, at :8080 or 8443. If your server’s host name doesn’t resolve properly, you can add an entry in the /etc/hosts file of your client to route you in the right direction. Here’s what you should see:


Click one of the administrator portal links, log in with the user name “admin” and the password you gave the engine-setup script. Once you’re logged in, click the “Hosts” tab, then click “New” to add a host. Give your host a name, and enter it’s address or host name, and the machine’s root password:


Once you click OK, a dialog box will inform you that you’ve not configured power management–that’s all right, just click through that.

Now, at the bottom of the screen, you can click on the up/down arrows next to “Events” to expand the events dialog and watch your management server configure itself as a host. You’ll see your server ssh in to itself, and run a bootstrap script that will install everything it needs. The last step in the script reboots the script, so if you click back to check on your progress and see “Error: A Request to the Server failed with the following Status Code: 0” that’s probably a good sign. :) (If something goes wrong during the process, you’ll see in this events area. If the event tells you to look at the log, start with the engine log at /var/logs/ovirt-engine/engine.log. Hopefully, the process will just crank to completion without incident.)

Once your server comes back from it’s reboot, you ought to be able to log in to the admin portal, click on “Hosts,” and see a happy green arrow indicating that your host is Up. Once your host is up, it’s time to hook up our storage. Click the “Storage” tab, then “New Domain.”


Give your new data domain a name (I go with “data”), choose your host from the drop-down box, and then enter the address and mount point of your NFS data share in the “Export Path” field, and click OK. Your server should mount the share and, shortly, you should see another happy green Up arrow next to your data domain.

An oVirt data center needs an active data domain before you can attach or add iso or export domains, which is why the iso domain that the engine-setup script creates starts out unattached. With your data domain in the green, you can click on that iso share, and then, in the pane that appears below the domains list, click the Data Center tab, then “Attach,” and choose your default data center to attach the iso domain to. Next, click the “Default” entry in that same pane, and “Activate.”

Adding the export domain works in just the same way as adding the data domain, just make sure that you choose the export option from the “Domain Function / Storage Type” drop down menu.

Now, let’s add an iso image from which to install a VM. We do this from the command line, using the tool, engine-iso-uploader. On my test systems, I’ve used wget to fetch an iso image (in this example, the Fedora net install image) from the Internet to my oVirt Engine machine. From the directory where I’ve downloaded the image, I issue the command:

engine-iso-uploader -i iso upload Fedora-16-x86_64-netinst.iso

The tool asks me for my admin password, the same one I use to log in to the web console, and starts uploading the image to my iso domain, which I’ve named “iso.”  (For more engine-iso-uploader guidance, see “man engine-iso-uploader”)

Once the upload is finished, I’m ready to create my VM. Click the virtual machines tab in the web admin, click new desktop (or server), give the machine a name, set the memory size, and adjust the cores, if you want. The OS list is limited right now to the RHEL and Windows options officially supported by RHEV, but I’ve installed Fedora, Ubuntu and Windows 8 without any trouble. For my F16 install, I chose RHEL 6.x x86_64 from the list:


After clicking OK in the new VM dialog, click on your new machine in the VM list, and in the secondary pane that appears below, give the VM a network interface clicking on Network Interfaces, then New, then OK:

net1 In the same way, give your VM a disk by clicking on Virtual Disks, New, enter a size, then OK:


We’re ready to install our VM. With your VM selected, click the “Run Once” button, attach your install CD, bump up cd-rom in the boot sequence, and click OK:


In order to access the console of our new VM, we’re going to need to install the Firefox extension for spice. From a Fedora 16 machine with Firefox installed, you can install the spice package with:

yum install -y spice-xpi

You may need to restart Firefox after installing the spice plugin, but once you’re up and running with it, you’ll be able to right-click on your VM and click “Console,” which will bring up the spice console for your machine. From here, install your OS normally. In the spice console, you can hit Shift-F11 to enter/exit full screen mode, and Shift-12 to release your pointer if the console has captured it.

The configuration changes you make in the “Run Once” dialog are supposed to last just once, but I’ve found that they persist until you actually shut down the machine–rebooting it once your install is complete isn’t enough.

I think that’s it — we have an all-in-one oVirt test box, complete with NFS storage and a guest machine. From here, you can add additional hosts, based on other Fedora hosts or on the project’s stripped-down oVirt Node image. You can point your additional hosts at the NFS shares we created in this runthrough, or you can add new storage domains. Consult the oVirt Installation guide for more information on installing and configuring your oVirt environments. That’s enough for this blog post, check back soon for more material on oVirt, and if you’re interested in getting involved with the project, you can find all the mailing list, issue tracker, source repository, and wiki information you need here. On IRC, I’m jbrooks, ping me in the #ovirt room on OFTC or write a comment below and I’ll be happy to help you get up and running or get pointed in the right direction.