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.

Don’t blame me if the script causes your data to be erased or tables to be dropped. It’s ment as a guideline, although it worked for me out of the box.

YMMV.

Usage: python <south_07to06.py> <path/to/migration.py>

import sys
import re
 
create_table_re = re.compile("db.create_table('([^']+)',")
field_name_re = re.compile("^(s*)('([^']+)', self.gf")
 
cur_model = None
 
input = open(sys.argv[1])
 
for line in input.readlines():
    line = line.rstrip()
    match = create_table_re.search(line)
 
    if line.startswith("class Migration"):
        line = "class Migration():"
    elif line.startswith("from south.v2"):
        continue
    elif 'Meta' in line and 'object_name' in line:
        line = re.sub(r"(?:, )?'object_name': '[^']+'", "", line)
 
    if not cur_model and match:
        cur_model = match.group(1)
    elif cur_model and line.strip() == '))':
        cur_model = None
    elif cur_model:
        field_match = field_name_re.search(line)
 
        if field_match:
            spaces = field_match.group(1)
            field_name = field_match.group(2)
            line = "%s('%s', orm['%s:%s']), " % (spaces, field_name, cur_model.replace("_", "."), field_name)
 
    print line

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).

After unmounting the file system, the LVM volume can be resized with lvresize:

$ sudo lvresize -L +2G /dev/vg00/foo.example.com-disk
  Extending logical volume foo.example.com-disk to 8,00 GB
  Logical volume foo.example.com-disk successfully resized

Then, you’re ready to tell the file system that it has been resized:

$ sudo resize2fs /dev/foo.example.com-disk
resize2fs 1.40-WIP (14-Nov-2006)
Resizing the filesystem on /dev/vg00/foo.example.com-disk to 2097152 (4k) blocks.
The filesystem on /dev/vg00/petitepeople01.koho.dk-disk is now 2097152 blocks long.

And there you have it, a file system resized and ready for use.

P.S. I’ve read numorus times that you have to run fsck -f and turn off journaling to use resize2fs but can’t really find any good reason to do so. If you want to, the commands are:

Turn off journal: tune2fs -O ^has_journal

Force check of file system: fsck -f

Turn on journal: tune2fs -j

To help myself manage the multiple identities, I wote a set of bash functions, called:

• aws_load <config-name> – loads configuration from config-name
• ec2ssh <instance-number-in-ec2din-list> – ssh’s into a given instance, with the root key
• ec2scp – a shorthand for scp -i <keyfile>

I keep the configuration files in the directory ~/amazon/conf/name.sh and keypairs in ~/amazon/keypairs/ but that should be obvious to change.

To change or load an identity, one simply calls the function from a shell prompt like so:

mads@workmads ~ % aws_load some-identity
loaded certificate ...
loaded /Users/mads/amazon/conf/some-identity.sh (...)

I hope someone finds this as useful as I do.

Functions (could be placed in .bashrc or .zshrc).

function aws_load {
    if [ -n "$1" ]; then
		ec2_configurations="$HOME/amazon/conf"
		ec2_keys="$HOME/amazon/keypairs"
		conf="$ec2_configurations/$1.sh"
		if [ -x "$conf" ]; then
			unset AMAZON_ID AWS_ACCESS_KEY_ID AWS_SECRET_ACCESS_KEY AWS_CERT EC2_PRIVATE_KEY EC2_CERT AWS_KEYPAIR_NAME
 
			source $conf
 
			if [ -n "$AWS_KEYPAIR_NAME" ]; then
				export AWS_SSH_KEY="$ec2_keys/id_rsa_${AWS_KEYPAIR_NAME}-keypair"
			fi
 
			if [ -n "$AWS_CERT" ]; then
				export EC2_PRIVATE_KEY=~/.ec2/pk-$AWS_CERT.pem
				export EC2_CERT=~/.ec2/cert-$AWS_CERT.pem
 
				echo "loaded certificate $AWS_CERT"
			fi
 
			echo "loaded $conf ($AMAZON_ID)"
		else
			echo "configuration $conf not found (or not executable)"
		fi
    else
        echo "usage: aws_load <configuration name>"
    fi
}
 
function ec2ssh {
    if [ -n "$1" ]; then
        HOST="`ec2din | awk '/i-/ {print $4}' | tail +$1 | head -n 1`"
        ssh -i $AWS_SSH_KEY -l root ${HOST}
    else
        echo "Please write a number"
    fi
}
 
function ec2scp {
	scp -i $AWS_SSH_KEY $@
}

Configuration “file” template to be placed in ~/amazon/conf/<config-name>.sh:

#!/bin/sh
 
export AMAZON_ID=""
export AWS_ACCESS_KEY_ID=""
export AWS_SECRET_ACCESS_KEY=""
export AWS_CERT=""
export AWS_KEYPAIR_NAME=""

Happy identity switching.

Detaching a running process from your shell, proved to be very easy in deed, using a shell command called disown.

To disown a running process, start by suspending the process by pressing ^Z, then send it to the background with the command bg then you can make it run until it’s done by using the disown command. To access the processes you’ve got suspended, you can use the % prefix (%1 for the first, %2 for the second etc.). To get a list of running processes you can use the jobs command.

Example:

mads@workmads ~ % sleep 120
^Z
zsh: suspended  sleep 120
mads@workmads ~ % bg
[1]  + continued  sleep 120
mads@workmads ~ % disown %1
 
mads@workmads ~ % ps xawu|grep sleep
mads     31725   0.0  0.0    75332    304 s003  S     2:25PM   0:00.00 sleep 120

If you accedently didn’t background your process, you can tell it to resume by sending it a SIGCONT signal with kill -SIGCONT <pid>.

Of course, this is no replacement for nohup or screen, but I think it is a great supplement.

% 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.

Until recently I’ve been using the file:// django cache, but that has a “problem” when multiple users needs to manipulate the cache (think uid 80 writes a key, that uid 1000 wants to delete).

My problem with the memcached:// django cache provider has been, that it cannot handle being used on a shared memcached instance, because of the danger of key collissions.

If project A and project B would share a memcached instance, they basiclly share the same global namespace. So if they both write a key called actor there is no telling what will happen.

So I wrote a little cache backend for django, that uses the current memcached backend, but adds a pre-defined prefix to all keys.

Usage: Put the code somewhere inside your project in a file called memcachedkeyprefix.py, and set your CACHE_BACKEND to something like: path.to.memcached_key_prefix:///127.0.0.1:11211/?keyprefix=sewc&foo=bar&timeout=3600

"Memcached cache backend with key prefixing"
 
from django.core.cache.backends.base import InvalidCacheBackendError
from django.core.cache.backends.memcached import CacheClass as MemcachedCacheClass
from django.utils.encoding import smart_unicode, smart_str
 
class CacheClass(MemcachedCacheClass):
    def __init__(self, server, params):
        try:
            self._key_prefix = smart_str(params['key_prefix'])
        except KeyError:
            raise InvalidCacheBackendError('key_prefix not specified')
 
        super(CacheClass, self).__init__(server, params)
 
    def _get_key(self, key):
        return self._key_prefix + smart_str(key)
 
    def add(self, key, value, timeout=0):
        return super(CacheClass, self).add(self._get_key(key), value, timeout)
 
    def get(self, key, default=None):
        return super(CacheClass, self).get(self._get_key(key), default)
 
    def set(self, key, value, timeout=0):
        return super(CacheClass, self).set(self._get_key(key), value, timeout)
 
    def delete(self, key):
        return super(CacheClass, self).delete(self._get_key(key))
 
    def get_many(self, keys):
        keys = [self._get_key(key) for key in keys]
        return super(CacheClass, self).get_many(keys)
 
    def incr(self, key, delta=1):
        return super(CacheClass, self).incr(self._get_key(key), delta)
 
    def decr(self, key, delta=1):
        return super(CacheClass, self).decr(self._get_key(key), delta)

Seeing as how there are a lot of benefits to using djangos own test suite (fixtures and automatic database generation to name a few), i set out to write a little test client for PyAMF to utilize django’s test client, so it would be possible to write a proper test suite.

This turned out great, and is now ticket 508 over at PyAMFs trac. Look at the client.py for the code. At some point, it will be integrated into PyAMF mainline as p.r.c.django.TestClient (or something like that).

I love it.

When it comes to actionscript files, flash has always had odd newlines. For some reason, it has always used r as it’s newline. Mercurial, beeing a unix tool, likes it’s newlines to be n. So what better to do, than to make mercurial encode/decode the files for us.

To do that, we can simply add the following to our .hgrc file:

[encode]
*.as = perl -pe 's/r/n/g'
[decode]
*.as = perl -pe 's/r/n/g'

I don’t really know wether the decode part is necessary, but I like to keep it around (if someone should commit poison).

As far as their interface goes, I can deal with that. It works, and it seems to do what it’s supposed to do fairly easy. A thing that has pushed me over the top, is the admins inability to help diagnostic a technical issue related to using their system as a secondary dns in front of a hidden primary.

Yesterday a good friend of mine told me that there was a new player in the dns game, one started by some people that seem to care about usability, exciting features (multiple dns templates per domain) and external api’s (goodbuy BeautifulSoup). It’s called QuickDNS.

So I rushed to their site, created myself a user and started tinkering around. Let’s just say, the it was actually a pleasant experience to do, things just worked^tm. So I setup a few templates and now have transfered a handful of my domains over there. Seems to work very well, just as expected.

So a very big congratulations to the whole QuickDNS team, you’ve done an excellent job, and made me a happy customer.

I seem to have agreed to give them a case of cola once they start implementing the axfr / hidden primary feature, and another one on completion. Can’t wait!

To use the hook you must place it somewhere inside your PYTHONPATH and tell mercurial to use it (I placed it in a module called trachook — don’t call your module trac):

[hooks]
changegroup = python:trachook.hook

And tell the hook where to find your trac installation:

[trac-hook]
root = /path/to/trac
url = http://url/to/trac

Grab your own copy of the source, and happy coding. And a big thank you to Jesper Nøhr.

Also, if you need a place to host your mercurial repository but don’t wan’t to set it up yourself, check out bitbucket.