When I was contracting at Sun, someone sent out a memo using the phrase “eat our own dog food.”  Scott McNeally sent out a response to the effect that Sun did not make dog food, “We Fly our own airplanes.”

In the software world, the phrase has become so used that it has been verbed; If you work at a software company that uses its own products in house,  you are Dogfooding.

Since so much of my professional work has been on Red Hat Enterprise, I’ve tended to run Debian based systems for my desktop, to keep abreast of what is happening in both worlds.  At Red Hat, I’ve finally had reason to run Fedora as my desktop machine, and have been enjoying the experience.  The vast majority of the Software I run now is distributed by the company I work for, and is Open Source.  It really is an amazing feeling. I am now running Fedora 11 not only on my work laptop, but my wife gave me permission to blow away the Windows install on her eeepc and install it there as well.  Fedora makes a great Netbook OS.

However, one tenant of Software Development is to develop on the platform on which you are going to ship.  For Red Hat, that is RHEL5, and so I need access to a RHEL5 install, and in fact need both 32 and 64 bit, since the world has not completely moved to 64 bit yet.  I’ve used virtual machines in the past, but always from VMware.  Now I am running QEMU/KVM on my Laptop.  Like most things Linux-y, the command prompt method of controlling the virtual machine subsystem is a first class citizen:  I don’t need a visual console to start up a VM.  I realize this is old hat to some people, but It is new to me, and I am enjoying it.

That is the wonderful thing about the Open Source development model:  you very quickly take ownership of the software that is essential to you.  Whenever a user becomes a contributor, that software is no longer just something out there.  It has become personal.

Anyways. As I Fly the Red Hat virtualization airplane, I’ve learned a few things.  The GUI, Virtual Machine Manger, is great for getting over the learning curve.  The command line is virsh.  These tools are a  part of the libvirt project.  There is a command to start Qemu based vms directly, but his seems to bypass the libvirt infrastructure.  Rnning qemu-kvm allowed me to start a VM saved in /var/lib/libvirt/images, but was not able to talk to the kvm subsystem.  One thing that threw me was that connecting to the virtual shell and running the list command did not show my virtual machine;  by default, that only shows running virtual machines, and you need to add the –all option to see non-running VMs..important if you want to only run them occasionally as I do.  To connect to the system, run:

sudo virsh -c qemu:///system

There is also another URL qemu:///session that I am not yet familiar with.

Working with VMware, I was comfortable with the split of the info into a vmdk and vmx files for binary data and configuration information.  IN KVM/Qemu/libvirt land, the equivalent of the VMDK is  a boot image.  This seems right to me, in keeping with the fearless Unix way of not inventing a new technology if an existing one makes sense.  The Analogue of the vmx file is in /etc/libvirt/qemu/.

One thing I would like to get set up is bridged networking for my VMs to the corporate lan.  The base install takes the conservative view that the network should be confined to the local system.  I’ve seen some write ups to getting TAP interfaces set up to allow your virtual NICs to get packets to and from the physical NICs, but haven’t done that yet.  The configuration for the host local network can be viewed from the virtual machine manager, and it shows the range of DHCP address given out to the hosts.  It contains a wizard for adding new networks, but I am not sure if the VMware paradigm of a bridged network maps cleanly to the Linux view…I suspect not.  I see under advanced options when creating the VM that I can set the Network to bridged, but it doesn’t seem to find my DHCP server to PXE boot.  As an aside, I’d like to understand how this operates in an Ipv6 environment, as Uncle Sam is now dictating IPv6 for all new Software purchases.    So many things to learn!

I needed to see the set of RPMs in a YUM repository. I wanted to do this as part of a larger script. To do this, I fetched the page via wget, and then applied an xsl transform on it using the command line tool xsltproc.

Here is how I called it:

wget -q -O – http://spacewalk.redhat.com/yum/0.5/Fedora/10/x86_64/os/Packages/ | xsltproc –html showhrefs.xslt –

And here is the xslt file showrefs.xslt

<?xml version=”1.0″ encoding=”UTF-8″?>
<xsl:stylesheet xmlns:xsl=”http://www.w3.org/1999/XSL/Transform” version=”1.0″>
<xsl:output method=”xml” indent=”yes”/>

<!–  shut off the default matchin rule –>
<xsl:template match=”text()” />

<!– print the href value of the hyperlinks –>
<xsl:template match=”a”>
<xsl:value-of select=”@href” />
<xsl:text >
</xsl:text>

</xsl:template>

</xsl:stylesheet>

The following script, when run on a RPM based system, tells you what licenses your application might trip by linking with other code.  You have to  set $MYEXE to som path to an executable.

for LIB in `ldd $MYEXE | sed -e ‘s!.*=>!!’ -e ‘s! (.*!!’` ; do rpmquery –whatprovides $LIB ; done | grep -v “any package” | sort -u | xargs rpmquery –qf %-30{NAME}:%{LICENSE}”\n

Here is a sample run for perl:

glibc                         :LGPL
perl                          :Artistic or GPL

Note that this is only for the linked files that are registered with RPM.