Motorritje

Zondag ging ik een stukje motorrijden, en zoals altijd had ik m’n GPS bij me, zodat ik altijd de weg naar huis weer kan vinden 😉 Al jaren cross ik heel Europa door op de motor (of met de auto, als het even niet anders kan) en al jaren verzamel ik GPS tracks van overal waar ik ben geweest. Het enige wat tot nu toe ontbrak, was een eenvoudige manier om deze tracks met jou te delen op deze website.

Gelukkig is er in de wereld die WordPress heet altijd een oplossing te vinden. Enter Google Maps v3 Shortcode. Deze plugin maakt het kinderlijk eenvoudig om een kaartje in een blogpost op te nemen en daarop een KML file te projecteren. Zie hier het resultaat:

[map id=”map3″ w=560 h=400 z=10 kmlautofit=no lat=”51.367781″ lon=”5.405273″ kml=”http://www.grendelman.net/files/gpx/20110807-track.kml” maptypecontrol=false streetviewcontrol=false]

Download KML file

クレイジー

Svndumpfilter with a lot of files

Once upon a time, I decided it was a good idea to put my photos in a Subversion repository, together with the rest of my website. After about 8 years of digital photography, I collected over 15000 images, and the repository now takes 28 GBytes of disk space.

Trying to convert the Subversion repo to Git, I ran into some problems with corrupted objects, that I haven’t been able to fix. After some time of trying different things, I started looking at ways of deleting all the images from the Subversion repo before trying to convert it to Git. Enter svndumpfilter.

Svndumpfilter is a simple tool, that takes a subversion dumpfile (created with ‘svndadmin dump‘) on standard input and outputs a new dumpfile, with certain paths filtered out (by prefix), or certain paths kept while filtering out the rest, on standard output. It takes path prefixes that need to be in- or excluded on the command line.

At first, the fact that svndumpfilter cannot take some form of pattern (glob, regexp) to match files, seems to make it hard to filter out 15000 JPEGs (and only the JPEGs) scattered over more than 200 directories. However, this appears to be easier than you’d think.

At several websites, I found examples for svndumpfilter, that use a textfile containing the path prefixes:

svndumpfilter exclude `cat filter.txt` \
< repos.dump > repos-filtered.dump

I simply decided to see what would happen, if my filter.txt file contained every file that I wanted excluded (all 15910 of them) as a separate path prefix. A Subversion dumpfile contains all the file names in the repository on a line starting with ‘Node-path: ‘, so I just used some creative grepping to create my filter file:

grep Node-path repos.dump | grep -i 'photo/.*\.jpg' | \
sed 's/Node-path: //' > filter.txt

Next, I ran the svndumpfilter command listed above, and to my big surprise, it executed without complaining. I now have a file called repos-filtered.dump of a mere 1.6 GBytes in size. After restoring that dump with ‘svnadmin load‘ (which also went flawlessly) I ended up with a subversion repository of 1.5 Gbytes. Wonderful!

Next step: see if this new repository will let me convert it to Git…

Weird Apache SSL certificate behaviour

Today, I encountered the following weirdness in Apache’s SSL certificate handling. I have two SSL virtual hosts on different IP addresses. The essentials:

<VirtualHost a.b.c.d:443>
    SSLCertificateFile /path/to/cert1
</VirtualHost>

<VirtualHost a.b.c.e:443>
    SSLCertificateFile /path/to/cert2
</VirtualHost>


This works as expected, as long as the ServerName for both virtual hosts is different. If the ServerNames are identical,

• either, you specify a ServerName with identical values in the virtual host definition
• or, and this is the tricky part, IP addresses a.b.c.d and a.b.c.e resolve to the same host name

Apache serves the certificate from /path/to/cert1 for both virtual hosts, and doesn’t use /path/to/cert2 at all.

Is this somehow documented behaviour or otherwise to be expected?

I understand that there is a close relationship between a virtual host’s name, the server certificate, which also contains the host name, and the name that the client uses to connect to the site, but of these three, the virtual host’s name matters the least of the three. It will cause a warning in Apache error log:

RSA server certificate CommonName (CN) `example.com' does NOT match server name!?

but that’s it. Clients still are able to verify the certificate, because the certificate name still matches the hostname in the request.

I think it should very well be possible to serve different certificates on different virtual hosts, even if they have the same name. The setup that caused me this trouble uses client certificate verification to authenticate and authorize clients to connect. We distinguish between ‘production’ clients and ‘development’ clients, which have different client certificates, signed by different CAs, and we have different server certificates to match. We use DNS views or even /etc/hosts to direct clients to the right server. I don’t see why this shouldn’t work, do you?

Hee, een oude bekende!

Als je je afvraagt waar dit over gaat: zie hier.

Update: helaas was ik niet de eerste met dit idee. Gisteren heeft iemand hier het idee al gelanceerd, en eerder vandaag postte iemand deze variant.