Thomas Jaehnel

I just started using the database-migration plugin inside a grails project and the documentation is not very concise. This short intro isn't meant to cover a lot of functionality, it's more like a quick reference. So here are a few steps on how to get started:

1. install dbmigrate plugin
2. configure the database connection to none
3. create an initial changelog
4. apply changes to database

To create an initial changelog run the following command:
grails dbm-generate-gorm-changelog changelog.groovy
This will generate a changelog based on your current object model

grails dbm-update will update your database to the current level of your object model.

If late on you make changes that affect the database, run
grails dbm-gorm-diff --add changelog.groovy

This will create a new changeset and automatically add it to the global changelog. Running the above command without any parameters will dump the changes to the console for easy review.

When you're satisfied with the result, you can run dbm-update again to sync your db.

I will try to cover some more ground when I have time.

When I started experimenting with Amazon's ec2 I ran into the issue that I wanted to test on the cheapest instance type possible, which is t1.micro but does not support instance-store AMI images. Since a lot of prepacked images are available only as instance-store images, it's a lot easier to start from one of those than to roll your own from scratch.

To convert an instance-store image into an EBS backed AMI you need to perform the following steps:

Boot up an instance-store AMI
ec2run ami-xxx

create a volume big enough to hold your root partition
ec2addvol -s X -z <zone>
The zone has to be the same as the current intance

attach the volume to the instance
ec2attvol vol-xxx -i <intance> -d /dev/sdd

create a file system
log into your instance and
mkfs.ext3 /dev/sdd

mount the disk
mount /dev/sdd /ebs

copy the root partition over to the volume
Install cpipe if unavailable
tar cpS / | cpipe -vt -b 1024 | tar xpS -C /ebs

detach the volume
ec2detvol vol-xxx

create a snapshot
ec2addsnap vol-xxx -d "Some meaningful description"
check with ec2dsnap if the snapshot has completed

register your new ami with EBS backing
ec2reg --kernel aki-xxx --ramdisk ari-xxx -b "/dev/sda1=snap-xxx:<size>:true" -d "Debian Lenny/5.0 2 GiB EBS i386" --root-device-name "/dev/sda1" -n "deb_lenny_ebs_i386"

On a side note: the true at the end of the block device mapping above means that the ebs volume is automatically deleted after the instance terminates (not after it is stopped).

After you performed all the steps above you can delete the ebs volume. Whenever you fire up one of your new ebs backed instances, this will create a new ebs root device for it.

As in the past years I'm currently attending the Chaos Communication Congress, the annual 4 day hacker conference organized by the CCC in Berlin, Germany. Currently we're on day 2 of the conference and I will try to post a summary of the most interesting talks for my own reference and for anyone who's interested in the details. To get an overview of this years schedule, refer to the Fahrplan or search for #27c3 on twitter.

More to come in the following hours and days...

Been trying to figure out the problem for some time. When you connect with Firefox to a VMWare web interface it fails with some sort of SSL issue.

To fix this you need to reenable SSLv2 in Firefox:

• enter about:config in the location bar
• set security.enable_ssl2 to true

Great security, thank you VMWare!

Due some weird problem with my old PGP key (gnupg couldn't verify signatures any more) I have created a new PGP Key.

As of today, please disregard the old key and only use my new one. You can find it here and the new fingerprint is appended to all my emails as well as stated here:

C2BF ED57 0057 FB92 C90A
D86F FAED 4C3B 4CB2 5115

The key has also been pushed to all the relevant key servers for your convenience.