Again an English post. This time about a little problem I've stumbled across while doing some nice
stuff with one of my SubVersion repositories. For readers who don't know SubVersion is a version
control system useful for working with the same files on multiple places and keeping a history of
these files. But well, version control isn't the topic of this post.
Actually I was trying to add a post-commit hook to one of my repositories. This hook should do a
simple trick: updating a working copy on the same server after each commit. Not a big deal, or at
least it shouldn't be. Writing the hook was no problem:
#!/bin/sh
cd /path/to/working/copy/on/the/server
svn update
Looks easy… but doesn't work. The svn update command just doesn't update the working copy.
As the SubVersion FAQ suggests I've tested the hook a bit. On the server SubVersion is used
together with Apache 2 and therefore the post-commit hook is run by the user Apache 2 is running
with. When I switched to that user and executed the post-commit hook by hand it became obvious
what doesn't work: The svn update command was asking me for my login to the repository and
wanted me to confirm the self signed certificate we're using on the server.
Well, the repository is accessed using HTTPS (with a self signed certificate) and requires a login. Usually
the SubVersion client caches this information but since the user of Apache 2 is just a system user it
can't do so.
The login isn't a problem, a quick look a the parameters of the svn command solved this:
svn update --username [myuser] --password [mypassword]
However there isn't a parameter to confirm self signed certificates which aren't signed by a trusted
issuer. I tried it neverless but always ended up with an "issuer is not trusted" error. I tried searching
around for several hours and found some people with the same problem. However there doesn't seem
to be a solution for this… at least none by using the svn command or one of it's parameters.
This is why I tried some other approach: with Linux it's quite easy to play around with the input and
output streams. So why shouldn't it be possible to fake the "p" key needed to confirm the certificate
when the svn command asks for?
svn update --username [myuser] --password [mypassword] < /bin/echo 'p'
Using the normal input operator < (don't really know how this is called) doesn't work. The svn
command just aborts in some strange way. However with a lucky look at Wikipedias Bash page I
learned something new: Bash supports the "here document" syntax.
command <<< "string to be read as standard input"
So trying this for the svn command
#!/bin/sh
cd /path/to/working/copy/on/the/server
svn update --username [myuser] --password [mypassword] <<< "p"
and it worked! It used the login for the repository, accepted the self signed certificate and updated
the working copy. So this was the solution for this… not by using the svn command but by using
good old Bash.
After all it was funny playing around with this. I hope some other people find this useful. ;)