I had a minor fight with south earlier today, where someone had created a migration with south 0.7, and I needed it to work with south 0.6.
Needless to say that it would be a pain to manually convert it from the better 0.7 format back into 0.6, so I wrote a fairly small python script, that does the job.
Earlier today I had to find out what the capacity of a soekris net4801 running openwrt.
Using a fairly normal rule set, it can forward 51.8 Mbits/sec which is alright for a 266 MHz processor.
Sadly for me, we’ll be getting a 100 Mbit fiber optic connection at work in a few months, so I guess I’ll have to move to a net5501 unit in order to max out the connection.
From time to time I have to resize the file systems on various systems which are primarily using ext3 on top of LVM.
Resizing such an ext3 file system is not a complex task at all. For starters, make sure you shut the domU down (or unmount the file system – unless you feel brave enough to do an online resize, in which case you should not be reading this).
Some data got deleted from one of our databases, and we had to restore it from our backups.
To make sure we get everything from our PostgreSQL cluster’s, we use pg_dumpall to make a SQL dump. It’s in no way the most efficient way to do a backup of a PostgreSQL database cluster, but it is by far the most flexible.
I had to get some statistics about file sizes today, but couldn’t really find a tool for the job, so naturally, I wrote one.
I keep doing the same ipfw commands over and over. Enough of that, here is my first applescript application every. Probably filled with bugs and other scary things, and I’m probably not the first one to do this, but I think I’m the first to stick the source out there.
I’ve recently installed Apple’s new 64 bit OS Snow Leopard, on my work computer. I use postgresql extensivly together with python, and usually use apple’s bundled python2.5 for working with django.
As the daredevil I am, I wanted to recompile all my macports to use the new 64 bit system, and therefore deleted them all, and made a fresh install of macports. After building the postgresql81 port, I was about to build the psycopg2 python postgresql driver for python 2.5, when it gave me a warning about not being able to find some symbols in the postgresql library it had linked to. I quickly realized that this might be an architecture problem, and sure enough, it turns out that python 2.5 is a i386/ppc and python 2.6 is x86_64/i386/ppc binary, as can be seen here:
I’m running multiple different project on AWS which was so much of a pain to use, as I often find myself having to use the identity of project-a together with the official amazon ec2 tools.
To help myself manage the multiple identities, I wote a set of bash functions, called:
aws_load <config-name> – loads configuration from config-nameec2ssh <instance-number-in-ec2din-list> – ssh’s into a given instance, with the root keyec2scp – a shorthand for scp -i <keyfile>
Recently (10-20 minutes ago), amazon couldfront (a cdn) stopped sending dns replies in europe:
% dig -t ns cloudfront.net ; <<>> DiG 9.4.3-P1 <<>> -t ns cloudfront.net ;; global options: printcmd ;; connection timed out; no servers could be reached
I was going to do a guide to set up a varnish to replace cloudfront temporarily (and did actually set up the instance, and software – I might do the guide and ami anyway) when I realized, that I (as well as most other people) can just change the relevant url to point to the S3 bucket. Problem solved. That will, however, not be as fast as either cloudfront itself, or a varnish cached backend.
Should anyone be interested in how varnish is setup to handle failures from cloudfront, I’ll happily do an ami.