Python 3.2 Is Released

Python 3.2 is released. That is all.

Except that I neglected to highlight the release of the 1.2.5 & 1.1.4 security patches for Django a couple of weeks ago. Tsk. Slack.


Posted in Uncategorized | Tagged | Leave a comment

udev ate my hamster

I upgraded one of my elderly and somewhat unloved Ubuntu boxes recently and on reboot the new kernel (2.6.32-24) failed to boot complaining that udev wasn’t configured. I have no idea what udev is.

Hmmm. It was late. What to do? Yes, emulate the best, most dedicated sysadmins! I went to bed and forgot about it for a few days.

Eventually I decided I ought to actually go and … you know … fix it. Or at least put the error message into Google and see what came back. Google tells me that udev isn’t configured, probably because the install actually didn’t complete properly.

One of the lovely things about Linux and especially the apt (Debian) based distros like Ubuntu is that several previous kernel versions are usually readily available to boot into. So I boot into a previous version and run dpkg -a –configure. Doesn’t work. Pants.

Try a system update. Also doesn’t work. Also Pants.

Use aptitude to reinstall udev. Also doesn’t work.

Ponder and cogitate on the problem.

Interestingly at around this point I finally notice that I’ve not been booting into a previous kernel version exactly as I’d meant to, but without paying enough attention into image-2.6.32-24-generic rather than image-2.6.32-24-386 (the default). Light slowly dawns and I use aptitude to reinstall the -386 version.

sudo aptitude reinstall linux-image-2.6.32-24-386

And bob’s yer uncle: all back working again.

Posted in Uncategorized | Tagged , , | Leave a comment

Django 1.2.3 released

Only two days after the 1.2.2 Security Patch comes a 1.2.3 Release.

Posted in Uncategorized | Tagged | Leave a comment

Django 1.2.2 Security release

The Django team have put out a security fix of 1.2. See their blog post.


Posted in Uncategorized | Tagged | Leave a comment

Should developers have access to Production?

There’s an interesting blog post over on ServerFault at the moment: Should Developers have Access to Production?

The argument presented is that sysadmins should deploy and manage production websites rather than developers, and it’s a fairly convincing argument.

I’ve recently started a new job and the company I’ve joined has a slightly different take on things which I think is an interesting additional angle to bring to the question.

The developers will have a keen understanding of the system being deployed, where its boundaries are, how things need to be configured and why. Sysadmins will have broader experience building and monitoring production systems in general, will be responsible for the rest of the installed software and appreciation of how systems need to be managed once they’re exposed to the real world.

There is a third group, however. Testers.

Test Engineers have a foot in both camps – they need to be technical enough to pull the code apart, inspect it, provoke it and generally stress it. They know about settings machines up and managing them since it will be likely that’s a regular feature of their day. They also already have responsibility for signing off the code as ready to be seen externally. (Arguably they ‘own’ the system at that point).

Of course there’s an unspoken assumption that I’m making, here: that Test is a first-class function of the workflow and not, as is usually the case, the unpopular cousin who has to be invited but whom everyone secretly hopes can’t make it this time.

It’s interesting to work in an environment where Test Engineers are given a first-class role alongside everyone else, involved in projects from day #1. Responsible for advising and supporting developers, observing the system as it’s developed and through out into the live environment. The place I now work has testers in every team and attempts to have a 1:1 balance of coders and testers. That’s in rather stark contrast to most places I’ve worked where a handful of overworked testers get dragged onto a project at the last minute to run through as much testing as they can before the immovable shipping deadline rolls over them.

As a developer I quite like this scenario – I’m relatively close to test & therefore production, but there’s a strong level of sanity checking before I’m allowed to monkey around with a live system (not that I would ever monkey around with a live system, you understand!).

I’m not sure there’s a right answer for any one organisation, let alone every organisation, but I do think there are more than two options on the table and it’s interesting to explore them all.

Posted in Uncategorized | Tagged , , , | Leave a comment

Why is my auth backend silently failing?

Having written my own Django authentication backend, I was tripped up recently by the way it was handled when I introduced a bug.

While testing my auth procedure, I kept seeing a NotImplementedError exception being thrown in my view.

login(request, user) …

django\contrib\auth\ in login …

django\contrib\auth\ in save
raise NotImplementedError

Which confused me a bit, but I had a strong suspicion this was because my user, returned from django.contrib.auth.authenticate(), was an AnonymousUser object rather than a proper user (something the docs confirmed).

However, my initial debugging implied that my authenticate() method was at least being called, and was passing the initial checks, so was executing the code I was expecting. Where was this coming from? If my method was being called why wasn’t it either throwing an Exception or returning a valid user? There wasn’t actually a path which could return ‘None’ – which should have been the only way to generate that AnonymousUser.

After adding much logging and poking about in the code, I discovered a simple typo in my backend:

user = User.objects.create_user(nickname)

create_user takes two arguments (nickname and email), not one.

Ok, bug fixed and everything starts working. But this is odd. Why no exception?

The answer to that lies with django.contrib.auth‘s authenticate() function which I shall reproduce here.

def authenticate(**credentials):
    If the given credentials are valid, return a User object.
    for backend in get_backends():
            user = backend.authenticate(**credentials)
        except TypeError:
            # This backend doesn't accept these credentials as arguments. Try the next one.
        if user is None:
        # Annotate the user object with the path of the backend.
        user.backend = "%s.%s" % (backend.__module__, backend.__class__.__name__)
        return user

Notice the try/except … it specifically catches TypeError.

And what gets thrown when a function is called with too few arguments?

>>> def fun(a,b):

>>> fun(1)

Traceback (most recent call last):
  File "<pyshell#64>", line 1, in <module>
TypeError: fun() takes exactly 2 arguments (1 given)

Ah yes, a TypeError.

Indeed that is exactly why TypeError is being caught, of course: because we want to skip over calls to authenticate() methods which don’t take the arguments we’ve been given.

My code just happened to be buggy in exactly the way that authenticate() would hide!

Posted in Uncategorized | Tagged , | Leave a comment

Today I stumbled upon Django-Registration

Django-Registration is a tool built by James Bennett who wrote some thoughts about it in this blog post (and has some very interesting thoughts on WSGI, too). It looks very flexible and has a sister project Django-Profiles to handle user profile info.

As these things always seem to happen, I’ve stumbled upon it half way through my user handling development and when I seem to have no time to investigate new libraries and tools. Of course what I want to do doesn’t align perfectly with Django-Registration’s default config so it’ll need some hacking about, probably some integration with OpenId, Oauth and possibly Google’s user API.

So, yet again I’ve got that decision to make: do I spend time looking at a new, likely more solid approach using someone else’s older, more robust code, possibly to find it doesn’t work at all. Or do I plough on, head down and write my own implementation which will definitely do what I want, but probably be pretty rough and shoddy at least in the early iterations.

Am thinking that I’ll definitely need to invest some time investigating Django-Registration, even if it’s just to learn about someone else’s approach & tools.

Reading James’s blog has also pointed me towards Armin Ronacher’s blog which looks well worth a read.Lucky I have so much time on my hands. Oh. Damn.

Posted in Uncategorized | Tagged , | Leave a comment