Categories: ,
Posted by: bjb

I want to get an IPv6 address from SixXS.net. The first step is to apply for an account. They gave me one. I tried to use the username/password credentials to log in, and was not able to read the page. I guess it must be xhtml, and it had some kind of error right after the head element. So all I got was a message in the browser saying that there was an error on line 14 character 8.

I tried logging in again today, and was able to see a page full of info.

I don’t know what the problem was. Could have been a problem on the remote end, or maybe I didn’t have cookies enabled. It works now, and I was able to apply for a tunnel. We’ll see what happens next!

Categories: , , ,
Posted by: bjb

I’m trying to run xen 4.0 but it’s not working, It seems that the input devices (keyboard and mouse) are not being supplied to the linux kernel from the xen hypervisor.

 http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=589373

I’m keeping this here for easy reference.

Categories: ,
Posted by: bjb

Another bug I want to keep track of:

http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=611407

This one refers to the breakage of the —ip=auto in xen-create-image from xen-tools 4.2-1. Some parameter checking was implemented, and the value if the —ip option is supposed to resemble an IPv4 address (but the literal string “auto” obviously doesn’t look like an IPv4 address).

UPDATE: fixed in 4.2.1-1. Yay! Unfortunately, it’s not in Debian squeeze, it’s in unstable. To get it, but still prefer stable packages for everything else:

echo 'deb http://debian.mirror.iweb.com/debian unstable main' >> /etc/apt/sources.list
echo 'APT::Default-Release "stable" >> /etc/apt/apt.conf
apt-get update
apt-get install -t unstable xen-tools
Categories: ,
Posted by: bjb

When learning about formsets, it was never clear to me how many submit buttons there would be:

  • one per form
  • one for the whole formset.

It turns out, there is one submit button for the whole formset.

Categories:
Posted by: bjb

Using xen-create-image in a “restore from backup tgz” scenario.

xen-create-image  --dist option

can create your own distro (called option) hooks that might:

  • adjust the new ip address (add extra interfaces as on old machine)
  • restore the database from a proper dump

Don’t run the distro hooks (like lenny) that would destroy your carefully crafted old machine

Note that the --dist option is NOT ignored when you use --install tar option. You will need to make your own dist script set (on Debian, look in /usr/lib/xen-tools).

In addition, you can run extra scripts using the —role option. Roles can be combined: --role udev,pg_restore,etc

Note that the xen-create-image --config option takes a xen-tools config file, not a xen cfg file. Also, the —config option does not replace the “global” config file, it augments it.

Categories: ,
Posted by: bjb

South migration names cannot have hyphens in them. grrr.

In fact they cannot have anything but alphanumeric characters and underscore.

Categories: , ,
Posted by: bjb

If you’re getting the error:

-sh: <( compgen -f -X -- 'b' ): No such file or directory

when you’re trying to invoke filename completion, for example like this:

bjb@edouard:/etc$ ls b<tab>

where you typed a b and then tab, to find all the directory entries in /etc that start with b, then you might have the posix option set on your shell while using an old version of bash_completion package. The version that gave me grief was 20080705. Another machine has version 1:1.2-3 and it doesn’t suffer from this problem.

You can check by showing the contents of $SHELLOPTS:

echo $SHELLOPTS

(And getting the package version number: apt-cache policy bash_completion.)

If the contents of the SHELLOPT shell variable includes the posix keyword, then you will need to disable posix because the shell completion implementation in bash-completion 20080705 doesn’t seem to be posix compliant.

set +o posix

will turn OFF posix mode, and

set -o posix

will turn ON posix mode.

So to make command line completion work, I had to give the command set +o posix CORRECTED 2010-12-16

Figuring this out introduced me to an interesting shell construct that I hadn’t seen before. In the old version of /etc/bash_completion, in function _filedir, you see this:

_filedir()
{
        local IFS=$'\t\n' xspec

        _expand || 0

        local toks=( ) tmp
        while read -r tmp; do
                [[ -n $tmp ]] && toks[${#toks[@]}]=$tmp
        done < <( compgen -d -- "$(quote_readline "$cur")" )

        if [[ "$1" != -d ]]; then
                xspec=${1:+"!*.$1"}
                while read -r tmp; do
                        [[ -n $tmp ]] && toks[${#toks[@]}]=$tmp
                done < <( compgen -f -X "$xspec" -- "$(quote_readline "$cur")" )
        fi

        COMPREPLY=( "${COMPREPLY[@]}" "${toks[@]}" )
}

It is the <( some command with output to stdout ) construct that I hadn’t seen before. It represents “process substitution” and the man page says it “is supported on systems that support named pipes (FIFOs) or the /dev/fd method of naming open files. It takes the form of <( list ) or >( list ). The process list is run with its input or output connected to a FIFO or some file in /dev/fd. The name of this file is passed as an argument to the current command as the result of the expansion. If the >(list) form is used, writing to the file will provide input for list. If the <(list) form is used, the file passed as an argument should be read to obtain the output of list.”

And also I relearned about the declare -f which will show you all the function definitions your shell currently knows about.

Categories: ,
Posted by: bjb

My app wasn’t running in the virtualenv I had prepared for it … I activated a virtualenv by sourcing /usr/local/pythonenv/DJANGO-1-1/bin/activate, and then ran ./manage.py runserver. However, according to the debug stuff I put in the template (django.get_version() and python.VERSION), the app wasn’t using the right django.

It turns out that manage.py has #!/usr/bin/python at the top — it wasn’t running the python in the path but a hardcoded path to the system python. To use the virtualenv’s python, change that top line to:

#!/usr/bin/env python

This will use the python that can be found in the path of the calling process — which is what you want when using virtualenv.

It may be that newer django’s will generate the /usr/bin/env line, but if you created your project with an older django, you might need this step.

Categories: , ,
Posted by: bjb

If you are using pip install somepackage, and it is not going into your virtualenv, perhaps you are tripping over the same thing I did.

I had activated the virtualenv with /usr/local/pythonenv/DJANGO-1-1/bin/activate, and (DJANGO-1-1) was appearing in the shell prompt. which pip showed /usr/local/pythonenv/DJANGO-1-1/bin/pip. python followed by

import sys
for p in sys.path:
    print p

showed that the system site-packages directories were not being included. So why was the python package being installed to /usr/local/python2.6/site-packages???

Well, the pythonenvs had been installed as root. I was actually running sudo pip install somepackage and that meant I was losing the virtualenv environment (which sets some environment variables that don’t survive the sudo to root transition).

So the solution was to run [UPDATED 2011/01/04]

sudo /usr/local/pythonenv/DJANGO-1-1/bin/pip install -E /usr/local/pythonenv/DJANGO-1-1/ somepackage

and indeed I threw in the --download-cache option to cut down on the download time (although I subscribe to DSL, my download times are closer to dial-up speeds) for subsequent installs into the DJANGO-1-0 and DJANGO-1-2 virtual envs.

Categories: , ,
Posted by: bjb

I really like django, but one thing it lacks is db schema migration. I’m trying out a django package called “south” that does that. (Debian package python-django-south).

South keeps track of migrations applied by adding a table to your database called south_migrationhistory. Of course, this table has to be added before south will work … you add it using syncdb. Fortunately, south keeps track of what it does and what syncdb does.

So you start using south by installing south, and then running ./manage.py syncdb. Now you have some new ./manage.py commands, called startmigration and migrate (also datamigration, schemamigration and graphmigrations, maybe I’ll look at those another time). To snapshot your initial db state or to detect changes to your schema, you use the startmigration command. To apply migrations to your database, you use the migrate command.

To snapshot your initial db state, use startmigration --initial. To detect changes to your schema, use startmigration --auto. The startmigration command will, in addition to other things, dump out the current db schema into the migration file. Every generated migration file contains a schema declaration towards the end. It also contains a migrate forwards and a migrate backwards command, for applying the migration and unapplying it automatically. The schema changes are detected by comparing the model data declarations with the migration schema dumps.

Some examples, for a db named clientportal and an app named portal:

# create migration named portal/migrations/0001_initial.py
./manage.py startmigration portal initial --initial

The initial migration is already in your database, so you don’t have to apply it yourself. Then you edit the portal/models.py file, and add a field. Then you can have south detect this and create a migration that applies the change to the database.

./manage.py startmigration portal add_field --auto  

You can use the newly created migration to change the database:

# will find all migrations named 0002_add_field
# and apply them (in alpha order of app name)
./manage.py migrate 0002_add_field 

I’m not sure how to better control the migrating naming and order of application. For instance, it seems that migrations are numbered sequentially within applications, but you don’t specify the number. So if you have more than one app (app a and app b), and you create a migrations in this order:

b/migration/0001_initial.py
a/migration/0001_initial.py
b/migration/0002_add_field.py

then you run ./manage.py migrate, the migrations will be applied in this order:

a/migration/0001_initial.py
b/migration/0001_initial.py
b/migration/0002_add_field.py

And I’m afraid that if I made a new migration (add_another_field) for app a, it would be called 0002_add_another_field and would be applied with all the other migrations (on ./manage.py migrate on a new db):

a/migration/0001_initial.py
a/migration/0002_add_another_field.py
b/migration/0001_initial.py
b/migration/0002_add_field.py

A little annoying when the migrations should have been applied in this order:

b/migration/0001_initial.py
a/migration/0001_initial.py
b/migration/0002_add_field.py
a/migration/0002_add_another_field.py

Hopefully there is a way to handle it, even if I don’t yet know what it is. Just being able to specify the 000n numbers would do it.

To list out the available migrations, you can ./manage.py migrate --list. The migrations that have been installed have a * next to them.

UPDATE 2011/Jan/12: to revert to an old version: ./manage.py migrate appname 0006_shortname_not_null

brings you to the state just after 0006_shortname_not_null has been applied.