watzmann.blog

One of the nice things about having your configuration data in a uniform data structure like Augeas' tree is that you can query it in a uniform way. A couple of releases ago, I added support for querying the tree with XPath — it was surprising, even to me, how easy some tasks of finding your way through config files has become with that. And there's no need to worry whether the file is a inistyle file, stores one record per line, or contains shell variables.

To whet your appetite, here are a few examples; if you want to play along at home, you can just type them into augtool (you need Augeas 0.4.2 for them to work properly). As a simple example, let's look up the canonical name of a host with a given IP address:

  augtool> match "/files/etc/hosts/*/canonical[../ipaddr = '127.0.0.1']"
  /files/etc/hosts/1/canonical = localhost.localdomain

A little more complicated is listing all the enabled yum repos that do not have gpgcheck turned on:

  augtool> match "/files/etc/yum.repos.d/*/*[enabled = '1'][gpgcheck = '0']"
    (no matches)

In a similar vein, we can find all the bridges that are configured to come up at boot (for readability, I'll write $net for the string /files/etc/sysconfig/network-scripts):

  augtool> match "$net/*[TYPE = 'Bridge' and ONBOOT = 'yes']/DEVICE"
  /files/etc/sysconfig/network-scripts/ifcfg-br0/DEVICE = br0

While that is still fairly easy to do with a one-liner from the shell, finding all the network interfaces that get enslaved into such a bridge using grep or awk requires a small amount of head scratching; as a path expression it's lengthy but straightforward (again, for readability, I'll write $bridge for the path expresion above):

  augtool> match "$net/*[$bridge = BRIDGE]/DEVICE"
  /files/etc/sysconfig/network-scripts/ifcfg-eth0/DEVICE = eth0

The 'g' key on my laptop is dyin. Now all my typin is goin to be lookin like I can see Russia from my front porch.

Like many people, I have the problem that I have way too many home directories - one on my laptop, one on my main desktop etc. For the longest time, I tried to keep them in sync with crazy schemes involving rsync or NFS mounting and the like. And it never quite worked; with rsync, it's too easy to clobber changes, since you always modify files in both places, no matter how hard you try not to. With NFS you really need to export your home directory from the laptop (otherwise you're back to rsyncing every time you go on a trip) — and that just breaks beautifully when pull your laptop out of your home network and your other machines fall over themselves because they can't access your home directory any more.

While these mirroring solutions work just well enough that you try and live with their shortcomings, I finally got so annoyed that I started to look for something else and came across Unison As the project page points out, what I have isn't a mirroring problem, where one side is the master and the other a mere copy, I have a synchronization problem, one where both copies can be changed independently. And a file synchronizer like Unison will spot modifications on both sides and do its best to reconcile them automatically, or failing that, it will ask the user what to do. But it will never, ever clobber changes.

With Unison, life is good; I now have separate home directories on my laptop and my desktop, and keep them in sync by running Unison periodically, and so far, it hasn't let me down. Given its provenance, there is of course a nice amount of theory behind it — though you don't need to know about it to use Unison.

Another aspect that quite literally blew me away is that Unison is very fast (I can't really tell a difference between Unison and running rsync on my quite rotund home directory). Even more surprisingly, it's not written in C, but in OCaml; that nicely supports the claim that I've heard a few times now that OCaml is both fast and suitable for writing code that's pretty close to the system.

LXer has a very nice summary of Raphael's talk on Augeas — though, contrary to what the author says, writing lenses (i.e., the plumbing that explains to Augeas how to map a config file into the tree) is not hard. You can mostly focus on how to take your file apart with regular expressions and how their matches should be mapped into the tree, and get the mapping from tree back to file for free.

None of this lens writing is of importance if you only want to use Augeas to modify files — as the author notes, reading the Quick Tour will explain most of what you need to know.

Looking at the schedule for FOSDEM next week makes me regret that I am halfway around the world from Brussels — there's a ton of talks I'd love to go to.

Raphaël is going to talk about Augeas. He's done a lot of work on Augeas in the past, and knows a ton about getting Augeas to process even pretty hairy config files.

I better finish up the XPath support in Augeas, so he can talk about that without saying "real soon now" too often.