Thomas Jaehnel

Apple is doing all kinds of funny things with VAT. iTunes invoices do not have a VAT even though they should, instead digital purchases like the membership to Apple Developer programs are billed with Irish VAT of 23%.

For companies selling cross boarder to other European companies this quite unusual. Normally, any vendor will allow you to register your VAT ID and then bill you without VAT. Apple thinks differently. You have to call them for a refund after every purchase. However, calling them doesn't work. Nobody understands what you want and they keep forwarding your call until you give up (believe me, I tried).

The solution:

1. Make your purchase
2. Send your VAT ID and your Invoice/Order number to vat.refunds@apple.com and request a refund

Done.

This little script was born out of a desire to get rid of DynDNS and similar services. There are several scripts around that do the job, but most of them are pretty complicated because they try to do the Amazon AWS calls manually.

This script requires a fully configured installation AWS cli which is used to do the update.

What it does:

1. Use curl to get the local IP address from a router status page
2. Check whether the internally reported IP matches the one known to a public DNS server
3. If it doesn’t match, create an update record to update a hosted zone file on AWS Route 53

This can be run from a cron job every couple of minutes to ensure the ip is always current.

Currently this is tuned to get the IP from a German Telekom Router, but the curl/grep expression should be easily adapted to use a different source.

I hope this is useful to other trying to achieve the same thing. You can find the code on GitHub

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