Altijd hetzelfde gezeik bij die damestoiletten
Tekening: Toon van Driel, tekst: ikke 🙂
6e plaats in de Niet Lullen Maar Vullen van 22 juli.
Tekening: Toon van Driel, tekst: ikke 🙂
6e plaats in de Niet Lullen Maar Vullen van 22 juli.
Gisteravond zijn mijn eega en ik teruggekomen van een vakantie in Engeland, voornamelijk in Cornwall en Devon. Ik ben wel vaker in Engeland geweest (voornamelijk bezoekjes aan Londen) maar nooit twee weken aaneen, en er zijn me wel wat dingen opgevallen:
Verder was het best de moeite waard. Vooral de noordkust van Cornwall is met z’n ruige kliffen erg mooi en twee weken vond ik precies lang genoeg voor dit stukje Engeland.
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…
En nog mooi weer ook!
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,
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?
I’m not going to stay – with the people whose ideas are just what other people say