I was intrigued by this post on socket activated containers with systemd. The basic premise is:

• systemd opens a socket on the host and listens for connections.
• When a client connections, systemd spawns a new container.
• The host systemd passes the connected socket to the container systemd.
• Services in the container receive these sockets from the container systemd.

This is a very neat idea, since it delegates all the socket listening to the host and only spins up container and service resources when necessary.

This is a followup to an earlier post about Arch Linux.

I’ve since spent a little more time working with Arch, and these are the things I like:

• The base system is very small and has a very short boot time. I replaced Ubuntu on my old Eee PC with Arch and suddenly the boot time is reasonable (< 10 seconds to a text prompt, < 30 seconds to a full GUI login).

• I feel better about the Arch installation process after seeing what happened to Anaconda (the Fedora installer) in Fedora 18.

• I have been pleasantly surprised at the speed with which bug reports have been addressed.

• I really like the fact that Arch has completely converted over to systemd. There are no legacy init scripts, the base system relies on the systemd journal for logging, etc.

I’ve been playing around with the LXC support in libvirt recently, and I’m trying to use a model where each LXC instance is backed by a dedicated LVM volume. This means that the process of starting an instance is:

• mount the instance root filesystem if necessary
• start the instance

It’s annoying to have to do this by hand. I could simply add all the LXC filesystems to /etc/fstab, but this would mean and extra step when creating and deleting each instance.

If you are starting virtual machines via libvirt, and you have attached them to the default network, there is a very simple method you can use to determine the address assigned to your running instance:

• Libvirt runs dnsmasq for the default network, and saves leases in a local file (/var/lib/libvirt/dnsmasq/default.leases under RHEL).
• You can get the MAC address assigned to a virtual machine by querying the domain XML description.

Putting this together gets us something along the lines of:

I decided to take a look at Arch Linux this evening. It’s an interesting idea, but has a long way to go:

• The installer configured the wrong root= command line into my syslinux configuration, resulting in a system that wouldn’t boot.

  Update: As far as I can tell, the syslinux-install_update command doesn’t actually make any attempt to configure syslinux.cfg at all.

• I tried to install libvirt and lxc, but there are unresolved library dependencies…the virsh command apparently requires libX11.so.6, but the package is missing the appropriate dependencies to pull in the necessary packages automatically.

• I tried to install puppet, but there is no puppet package in Arch Linux. One apparently exists in the Arch User Repository, but there are no packages in Arch Linux that will let you install packages from the AUR.

  Arch also seems to be missing chef, so there go the two biggest names in configuration management.

• There’s no way to report bugs without first registering with the bug tracking system…and there’s no federated login (e.g., with Google, Facebook, Twitter, OpenID, etc), so this would be Yet Another Account to remember.

I’m been writing a provisioning tool for OpenStack recently, and I’ve put together a demo configuration that installs a simple cluster consisting of three backend nodes and a front-end http proxy. I needed a way for the backend servers to discover the ip address of the frontend server. Since in my target environment everything would be on the same layer-2 network segment, service discovery with multicast DNS (mDNS) seemed like the way to go.

I needed to replace the native OpenJDK based Java VM with the Oracle Java distribution on one of our CentOS servers. In order to do it cleanly I wanted to set up the alternatives system to handle it, but it took a while to figure out the exact syntax.

For the record (and because I will probably forget):

alternatives --install /usr/bin/java java /usr/java/latest/bin/java 2000 \
  --slave /usr/bin/keytool keytool /usr/java/latest/bin/keytool \
  --slave /usr/bin/rmiregistry rmiregistry /usr/java/latest/bin/rmiregistry

I recently embarked upon a quest to categorize a year’s worth of trouble tickets (around 15000 documents total). We wanted to see what sort of things are generating the most work for our helpdesk staff so that we can identify areas in which improvements would have the biggest impact. One of my colleagues took a first pass at the data by manually categorizing the tickets based on their subject. This resulted in some useful data, but in the end just over 40% of the tickets are still uncategorized.

In order to import posts from Blogger into Scriptogr.am I needed to convert all the HTML formatting into Markdown. Thankfully there are a number of tools out there that can help with this task.

• MarkdownRules. This is an online service build around Markdownify. It’s a slick site with a nice API, but the backend wasn’t able to correctly render <pre> blocks. Since I’m often writing about code, my posts are filled with things like embedded XML and #include <stdio.h>, so this was a problem.

• Pandoc. This is a general purpose tool that can convert between a variety of markup formats. Unfortunately, it also had similar problems with <pre> blocks.

• html2text. This a Python tool that converts HTML to Markdown. It seems to do a better job at handling the <pre> blocks, although it doesn’t always get the indent level correct when the <pre> blocks are embedded in lists.

I’m in the process of porting over content from Blogger. This may lead to odd formatting or broken links here and there. If you spot something, please let me know.

If you came here from Google and found a broken link, try starting at the archive and see if you can spot what you were looking for.