spaceblog

A little over a year ago, I was planning a datacentre move for Anchor. This was overall a very challenging experience, because our target was to move 8 racks of equipment in one night, from the outskirts of the city into the middle of the CBD. Making sure that went as smoothly as possible meant writing new tools to assist the planning work.

So, a little over a year ago, I hacked up some python code that rendered some nice vector graphics of our planned rack layout; a graphviz-like file format let me place our switches, rackmounts, shelves, and minitowers in racks, and then I’d generate a bunch of EPS files, and do this many many times to make sure all the equipment was going to fit. This also made collaborating with my bosses very easy, because we could draw on printouts, take the sheets down to the DC and make notes about positions of network ports, serial cables, and so on.

This code got called fengshui, because it involved a lot of pseudoscience to get the balance and harmony of the new DC to maximise chi flow :)

After the move, the diagrams stagnated; I hacked a bit on the code and broke it, and since then the diagrams have been left unused, too hard to update with changes on the racks, and so what was once a useful reference for provisioning space turned to rot.

This last week I started playing with the code again, and now with less pressure to deliver, have chucked out the old EPS and SVG generation code and replaced it with cairo as the rendering engine, and made the input file format less suckful, chucking out the parser, perhaps 50% of the total LOC, replacing it with an XML format. (Yes, if I’ve made it less suckful with XML, imagine how awful it must have been before!)

The cairo renderer is totally awesome: in the space of about 5 minutes I refactored the generator interface to allow me to pass in a cairo context, and then patched in the widget from the pycairo clock example, and I have a GTK viewer for rack diagrams. I’m still trying to find parts of my jaw that have since snapped off when it dropped to the floor.

Anyway, check it out, if you’re a sysadmin or netops guy, it may come in useful. Patches always welcome :)

We had another Halloween party at the Casa this year, and somehow a flash of inspiration hit me when I was thinking about decorations: polystyrene foam balls painted like jack-o-lanterns, on christmas lights.

I picked up a bag of foam balls from the local craft store, and carved them out using the cutting wheel and the sanding wheel on a Dremel.

Carve it so there’s about 1-2cm of foam shell left. You want to be careful during this stage so as to keep a firm grip on the ball whilst carving it, otherwise you’re likely to have the ball flick around on the dremel, with disastrous consequences.

The face can then be cut out using the cutting wheel. Pictured here, my favourite face. You have limited amount of creative control when using a straight edge, so most of my experiments with faces ended up looking unspooky or just bizarre. A hotknife can give you better facial features but you’ve got to watch out for toxic fumes from the foam :)

Do two coats of water-based paint, to make the colour nice and bright. Don’t use enamel paint or you’re likely to dissolve your precious jacks.

Drill some holes in the top for the lights to poke through, then paint on some leaves. You can get a snug fit for the lights, but I usually didn’t bother, so the bulb would be close to the centre of the ball for better illumination from within.

Poke the lights in, and fix them with a dab of hot glue.

Test them! You might find some of the lights aren’t working, swap the jacks around on the vine until you get them all glowing.

The finished product! I hung them with gaffer tape from the roof of the patio, and then draped them around the plants on the side.

There are more photos in the polyfoam jacks set on flickr.

Thanks to unknownblogger, who has managed to make them look superb with the green downlight.

Today I made the wonderful discovery that gnome.org email was working fine, and that my attempts to subscribe to the f-spot-list were successful – at least, as far as sending me the request for confirmation makes it a successful transaction. Trouble is, procmail had been deciding for some time now to deliver certain mail to the wrong spot.

The short of it is this: if the \/ match command includes some whitespace in $MATCH, then procmail will treat something like this:

:0
.list.$MATCH/

as two targets, and skip the second part. For example, with the above recipe, a $MATCH of ’ f-spot-list' will end up telling procmail to deliver to thw two words .list. f-spot-list/, and will then tell you that it is skipping f-spot-list/ and delivering to .list.. However, in the process, procmail has seen the / at the end of the line and decided to remove the From_ magic from the start of the message when it is delivered to the mbox .list., and so you’ll end up with not only a new mbox that you didn’t want, but also one with a single message in it containing what you’d expect to be many messages.

So, first fix procmail to match out the whitespace before using the $MATCH variable, this is just sensible sanitising.

Second, move your broken mbox out of the way, so that we don’t duplicate mail when you inevitably break this process in a moment. Create a scratch directory, and cd into it.

% mkdir scratchmonkey
% cd scratchmonkey
% csplit ~/borken.mbox '/^Return-Path/' '{*}'

You want to make sure that the first line of your broken mbox messages are actually Return-Path: headers, otherwise adjust to suit. You also want to be doing this on a single message, so if you’ve got an mbox with correct message delimiters in it, first move them to the right place (formail -s procmail < ~/borken.mbox then find where the uber message got delivered, and move it out of the Maildir).

Now you’ve got a directory full of single files. There are now three ways to deliver them. If you like manual labour and also like to cheat death by breaking Maildir delivery protocol, you can just move these files to your inbox Maildir/new directory.

If you want safe delivery, but still like manual labour, try safecat:

% for i in xx*; do safecat Maildir/tmp Maildir/new < $i; done

If you’re certain your procmail is now correct, let it take care of the safe delivery and also the filtering job:

% for i in xx*; do procmail < $i; done

Check your mail, all the messages from the busted mailbox should now be safely stowed and visible to your MUA.

Today’s random trivia: when using the match-completed signal of a gtk.EntryCompletion in pygtk, you may be confused into thinking the model argument passed to your handler is the same gtk.TreeModel that you passed the EntryCompletion when you set it up.

It is not. It is not a copy of your model, though if you foolishly picked the first item in your model to test the completer with then you may be duped into thinking it is. But it isn’t! The model you’re given contains only the values presented to you in the completer popdown list, which means if you want to associate the selection made from that list to one in the big model, you’re shit out of luck. The TreeIter has no meaning in your full model.

Unless there’s a better way of finding the matching iter in your full model of the iter given to you that I don’t know about, try this:

1
2
3
4
5
6

    def on_match_selected(self, comp, model, i):
        row_id = model[i][0]
        for r in self.cbe.get_model():
            if r[0] == row_id:
                # set the cbe active row
                self.cbe.set_active_iter(r.iter)

(Assuming your handler is part of a class, and that your class contains a gtk.ComboBoxEntry with whom you are trying to do the completion and selection. Also, we assume that the 0th column contains a unique identifier for your row, out-of-band of the model, which isn’t displayed (i.e. set_text_column(1) or sommat).)

The docs on match-selected fail to mention the nature of the model being passed in, only that it is a model pointed to by the TreeIter also passed in.

Documentation is never going to get better, so rather than fight it, I introduce a new paradigm in programming: ADVENTURE PROGRAMMING! Like Indiana Jones hacking through the jungle with a machete, you hack through APIs on a quest for Inca Gold… with a machete.

I’m trying to find some documentation on Bugzilla’s supposed XML-RPC API. A lot of people, according to Google, especially around the Gnome and Fedora traps, are talking about it, but as yet I haven’t found anything on the internets describing what the fucking API is.

Also, alledgedly, there were plans for a SourceForget XML-RPC interface too – chances of this actually existing let alone finding any documentation: close to nil.

If anyone has any clues or actual docs, please comment in your regular planet, or email me :)

(If you’re curious, and you probably are, I’m working on a GTK triage tool, for aggregating bugs from various locations on similar projects. arch coords are jaq@spacepants.org--2004/bugtool--main--0.)

Debbugs and RT interfaces have been pretty easy; if you’ve got docs for another interface that actually exists, let me know too. I’m only going through the pain of SF and bugzilla integration because of the high mindshare these two have.