Monday, 26 March 2012


In other news, I should hopefully have some notes up for my puppetcamp slides very soon.

Friday, 23 March 2012

Thursday, 2 February 2012

Apache reverse-proxying and the REMOTE_USER variable

I spent an alarming amount of time yesterday attempting to make the most of Apache's ridiculously easy mod_auth_kerb module for SSO Kerberos authentication with a little in-house Sinatra app I've been working on. Apparently Kerberos within nginx or ruby is a bit of an unofficial ballache, so I decided to take the easy route out. However, it transpires that only one person on the whole internet knew of the existence of the ProxyPassInterpolateEnv boolean.

To put this in context, for my app I only want kerberos to validate the user and then pass on the username to the app. It's a git deploy frontend, and I like blaming people.

You'll find a lot of stuff about doing a complicated rewrite so that REMOTE_USER actually evaluates before a reverse proxy. I couldn't get any of this stuff to work - not only that but it's a horrible solution anyway requiring about three lines of rewrite - and I'll be honest, I'm not up together on my apache rewrites anyway.

So the following is the solution I ended up with. It simply makes Apache forward on the REMOTE_USER variable, created by your auth module, to whatever you're reverse proxying - in my case a Sinatra app. It actually appears as REMOTE_USER as opposed to the specified REMOTE-USER as well. I neither know why nor care.

Excuse the formatting.

<Virtualhost *:443>
SSLEngine on
SSLCipherSuite ...
              HA HA SSL BUSINESS
ProxyPassInterpolateEnv On
ProxyPass / http://localhost:4567/
RequestHeader set REMOTE-USER %{REMOTE_USER}s
    <Location />
        AuthType Kerberos
        AuthName "AD Login"
        KrbMethodNegotiate On
        KrbMethodK5Passwd On
        KrbAuthRealms MUMS.COM
        Krb5KeyTab /etc/krb5.keytab
        Require valid-user
</Virtualhost *:443>

Wednesday, 27 July 2011

throw != raise, catch != rescue

This isn't even sysadmin stuff here, so if you don't care about Ruby, look away.

It is increasingly irritating when I'm trying to google examples of usage of Ruby's throw and catch functionality, that people who are very confused about the terminology of exceptions in Ruby appear to be writing tutorials. I can understand that they're writing about it coming from the perspective of some other language, but in Ruby you don't *throw* an exception, nor do you *catch* it because throw and catch are something different. The terminology is important because one set deals with exceptions (unexpected errors) and the other doesn't.

I want to see examples of throw and catch and it's made very difficult by the fact that everyone seems to use the exception stack for flow control (shudder) and referring to it by throw and catch, meaning I keep ending up reading badly worded tutorials on the exception handling tools which I already understand.


Wednesday, 8 June 2011

MCollective and MongoDB registration.

I'm currently working on mashing our mcollective and puppet rigs together into one big nodelessly configured family by using Whack's nodeless setup, hacked about to search node roles from the same mongodb that Volcane's mcollective registration and puppet searching. The idea here is to be able to add user-set "roles" to each node in the database - something that is only ever set by hand unlike the registration data which should only ever be set by a node.

In order to do this, I hacked Volcane's mongodb registration code about a bit so that it would only do atomic updates rather than blatting the entire document whenever it updated, meaning you can put in user defined fields as well. Then the guys who wrote the original code did it on the main branch (albeit as a side effect to fixing other things) but in a much less shitty way because they can code and I tend to do something more akin to hitting ruby with a stick.

I'm now back to working on my frontend to assign these roles through a point and drool interface.

Friday, 20 May 2011


It's been a while.

So this is less of an entry and more of a link to something which has made a lot of sense to me and is a really nice model for developing code - anyone who knows me knows I come from a systems background but have been writing more and more code of late, so this stuff is largely new to me.

This outlines (as you might imagine) a very logical and concise way of laying out a git tree and I love it with mouth because it's tidy.

Edit: and there's a tool to make it easy too!

Wednesday, 12 January 2011

Backports and meta-packages

I've just made an edit on the Puppet+Nginx+Unicorn entry a couple of posts back to include:
  • rubygems 1.3.4-1~bpo50+1 via backports <- Not actually required for this, but many things require the meta-package as well as the versioned package so getting them together can save you some headaches.

I think this is fairly important as a rule of thumb - if you're installing from backports, you should really check for the associated meta-packages as it can cause dependancy problems later on with other packages should you not have them. I was just installing mcollective on my puppetmaster test rig, and I ran in to this problem.

As I've said before, it's usually easiest to set up your own debian repository using reprepro if you're going to install custom-baked debs simply because it saves on headaches.