Brane Dump

My Hero!

I just have to say that this bull is my hero. That is all.

Anticlimax

This sounds exciting:

We think developers who want to work on the best, most dynamic, and most interesting open-source web technology project on the planet have no better place to work than here -

Fwowr, dynamic and interesting open-source web technology project! Sign me up!

working on Drupal.

That wasn't where I thought that was going. Those words obviously have very different meanings to different people. Never mind.

On lDAP objectClasses

Does anyone else think that a naming scheme that produces an identifier called dNSDomain is utterly broken, and should be taken out and shot immediately?

Using Virgin Mobile Broadband with wvdial

File Under: Stuff I'm guaranteed to forget if I don't write it down

I just went a bit wild and decided to get myself some mobile broadband love -- I'm finding that I crave a bit of light 'net when I'm out and about, and an impending change in circumstances will mean that I'm out and about a lot more than I am currently.

I have:

Hardware: Huawei E160e USB dongle, USB ID 12d1:1003
Provider: Virgin Mobile Australia Prepaid
OS: Debian GNU/Linux 5.0 with an upgraded 2.6.32 kernel

My wvdial.conf stanza looks like:

[Dialer virgin]
Init1 = ATZ
Init2 = ATQ0 V1 E1 S0=0 &C1 &D2 +FCLASS=0
Init3 = AT+CGDCONT=1,"IP" "VirginBroadband"
Stupid Mode = 1
ISDN = 0
Phone = *99#
Modem = /dev/ttyUSB0
Modem Type = USB Modem
Username = irrelevant
Dial Command = ATDT
Password = irrelevant
Baud = 460800

I also had to disable CHAP (by putting -chap in /etc/ppp/options, although I suspect the same would have worked in /etc/ppp/peers/wvdial).

After that, a simple sudo wvdial virgin and I was away.

Scarily enough, there was actually some useful information on the Virgin support site regarding the settings, which helped me confirm that I was on the right track. I have no doubt that the universe will find some alternate means of punishing me down the line.

Making pbuilder just that little bit faster

Give yourself a small, slightly late christmas present, and put a tmpfs on /var/cache/pbuilder/build. It makes a noticable difference, especially if you're on a laptop system (like I am) with a disk that's not going to win any speed records.

When Scientists Get Into The Kitchen...

You get a rigorous analysis of the science behind boiling eggs. I want one of those thermal circulators for Christmas.

Cool Regex Win-of-the-week

I just had a need to match a regex where there were two occurances of the same string, and it would be really, really nice to make sure that both occurances were actually the same (rather than both being different strings that just happen to match the same regex). Just to be funny, I tried this:

  /([a-z0-9\.-]+).*\1/

And knock me down with a feather, it worked! This is using Ruby's regex handling, but I'd be stunned if Perl didn't also handle this case.

The world just got a little bit awesomer today.

Is There Something Wrong With Me...

When the first thing I thought of when I saw this baby outfit was "What sort of cretin wrote that code?", rather than anything more "paternal"?

I want those two day of my life back, Puppet

Pop Quiz time, everyone (well, the Puppet-using subset of "everyone", anyway). Where is the dependency loop in the following manifest:

class klass {
   file { ['/tmp/a']: ensure => present }
}

define def_file() {
   include klass

   file { $name:
      ensure => present,
      require => File['/tmp/a']
   }
}

def_file { '/tmp/b': }

def_file { '/tmp/c': require => File['/tmp/b'] }

This seems pretty straightforward: /tmp/c can't be created until /tmp/b (via the direct require) and /tmp/a (via the define) have been created, while /tmp/b can't be created until /tmp/a is created. You can draw some pretty graphs and see that everything looks fine.

However, if you run this manifest, you will find that roughly half the time, you will get a failure saying that there's a dependency loop (and the other half of the time it'll work fine), like this: "err: Could not apply complete catalog: Found dependency cycles in the following relationships".

So, where is the loop? It's because the require on the /tmp/c resource also applies to the /tmp/a resource -- iff the include klass directive is applied to the /tmp/c resource. So `/tmp/a` then requires `/tmp/b`, and `/tmp/b` requires `/tmp/a`, and it's LOOP TIME!

Whether or not this loop occurs on a particular Puppet run is controlled by fickle Lady Fate (because Ruby hashes, which are used at some point internally in this process, don't have a well-defined or stable order). As to why the include only applies to one of the defines rather than all of them, well, that's related to the fact that a class only gets evaluated once, and I think someone was having a lazy day when they wrote that part of the system (I can't imagine it would be the end of the world if each instance of the class was linked to the defined resource in the scope tree).

Now, when you've only got the above manifest, it's relatively straightforward to isolate the problem and fix it -- I had it sorted in about an hour. The two days prior to that were isolating the bug from the live manifest, because there are about 20 instances of def_file in our live manifest, and so I'd have to run Puppet (on average) 20 times to make the problem appear every time I had a new hypothesis (and since I didn't know whether the bug was client-side or server-side, I had to run it in the real, full-blown environment, which slows things down further). If the class-handling stuff had been written properly, then the error would have been constant, rather than intermittent, and I would have been asking for a couple of hours credit, not a couple of days.

The fix? Use virtual resources instead of the class, which does $DEITY-only-knows-what to the scope tree. These have their own giant buckets of ugliness, but our options, at this point, are unpleasantly limited.

I really do wonder why I'm not a raging alcoholic sometimes. The reasons not to are strangely hard to recall right at this moment...

Oh Firefox...

What are you doing in that the 1.1GB of resident memory (1357m of virtual memory) you have decided to consume in order to display three web pages? All fairly basic pages -- no flash, no excessive Javascript, and I haven't even done anything particularly exciting in the browser -- just loaded the pages up and let them sit for a few days.

Time to look at Conkeror on the Netbook, I suppose. I'm unlikely to be needing Firebug on there any time soon.