I finally decided it is time to switch to accessing subversion repositories via apache and the https scheme rather than ‘file://’ scheme. Search revealed many articles touching the subject, but none providing exactly what I need. So documenting:
- The problem and motivation
- Up to date?
- Getting apache to serve https
- Configuring apache to serve subversion
- Migrating existing working copies to the new scheme
- Reference links to articles that helped
Problem and motivation
My main development machine is a Mac Pro running 10.6.4. My development projects are all kept outside my home directory on a second disc, one project per folder. Each project folder contains a subversion repository folder named ‘svn’ along with one or more working copies.
For the last few years I have checked out working copies using the ‘file://’ protocol. This seemed the simplest and most efficient approach in this single-user environment. I use svn clients such as SvnX, and Subclipse and occasionally the command line (for which having the svnbook to hand is a must). I have groaned previously about DreamWeaver’s subversion integration ‘attempt’ failing to support the file protocal (remains unchanged in CS5).
There are a couple of things I want to solve:
Firstly, I occasionally use VisualStudio in Windows7 running in parallels on this machine to work with ASP.NET. In the past I’ve simply pointed it at the working copy via the network drive. Of course this means that I can’t undertake svn operations through Win7 since that working copy’s URL is alien to the Windows 7 instance. Not too much of an issue since it’s only a matter of switching back to a Mac window to do svn business. However there is an annoying problem with VisualStudio’s code completion where it is unable to correlate markup within an .aspx file with it’s .aspx.cs file when the site is on a parallels network drive. To solve this I need to check out a working copy to the Windows7 local disk.
Second, I have taken to getting out and about with my MacBook Pro. If I want to work on the move I need to check-out a working copy.
For both these situations using the ‘file’ protocol is inappropriate. Attempts to check work back in are bound to generate svn errors as multiple svn systems attempt to obtain exclusive locks on the repository.
If however we can get to a single user/process touching repository files we can solve this problem – enter apache.
Up to date?
First thing I did was get my subversion installation up to date. At time of writing 1.6.12. Installer available from CollabNet. Just run the installer and follow the instructions. Note: this version installs into a different location to that installed by Apple. You may need to tell your client tools the location of the subversion to use.
That said, this isn’t going to help with DreamWeaver all that much. DW’s Subversion functionality is tightly tied to specific versions. Should you dare touch a working copy with a later version (which changes some of the meta data) DreamWeaver will cease to work with that working copy. More information at this Adobe technote. So for now as far as I am concerned, until Adobe start releasing ‘upgrader extensions‘, DW’s subversion functionality remains useless and turned off with ‘.svn’ files cloaked and svnX used for commits.
Getting apache to serve https
In the short term I have no plans to open access to my repositories via the net. However it is a future possibility so I think it worth getting going with https from the outset is worth it.
Mac OS X of course uses Apache for web-sharing. However it’s default state is not configured to serve SSL. To do so, we need a secure certificate and some configuration changes. As I am the only person accessing this machine, and I trust myself, I have no need to obtain a certificate from a commercial authority.
Steps taken to create the certificate and configure apache to use it…
Create a certificate authority
mkdir /Library/Certs
cd /Library/Certs
perl /System/Library/OpenSSL/misc/CA.pl -newca
[ENTER](to create new certificate)
Generate private key
openssl genrsa -des3 -out webserver.key 1024
generate a non-password protected copy of the key
openssl rsa -in webserver.key -out webserver.nopass.key
Generate a certificate request
openssl req -config /System/Library/OpenSSL/openssl.cnf \
-new -key webserver.key -out newreq.pem -days 3650
Sign the certificate request
perl /System/Library/OpenSSL/misc/CA.pl -signreq
You should now have created…
/Library/Certs/demoCA/
/Library/Certs/newcert.pem
/Library/Certs/newreq.pem
/Library/Certs/webserver.key
/Library/Certs/webserver.nopass.key
Tell Apache to include SSL
We now need to edit apache’s httpd.conf. You need to ‘sudo’ to acquire sufficient privileges to do so, and need to take care. Optionally make a backup copy of httpd.conf.
cd /private/etc/apache2/
sudo cp httpd.conf httpd.conf.bak
sudo pico httpd.conf
Find the following line and uncomment it by removing it’s # prefix
Include /private/etc/apache2/extra/httpd-ssl.conf
Use CTRL-O then CTRL-X to exit pico and we now need to edit the file we just included…
cd extra
sudo pico httpd-ssl.conf
Go through the file finding the following attributes ensuring they are uncommented and point to the SSL files we just created…
SSLCertificateFile "/Library/Certs/newcert.pem"
SSLCertificateKeyFile "/Library/Certs/webserver.nopass.key"
SSLCACertificateFile "/Library/Certs/demoCA/cacert.pem"
SSLCARevocationPath "/Library/Certs/demoCA/crl"
You should now be able to restart apache either through System Preferences… > Sharing > Web sharing, or
sudo apachectl graceful
You can access any errors via the Console application. If all is well you should be able to enter https://localhost/ into your browser’s address bar and get a result.
Configuring apache to connect to and serve subversion
Firstly, we are going to require a login. In my case I am going to create 3 login IDs. One for my normal workstation. Others for access via Win7 and my MacBook pro. So although all the work in the repro is by me, I can see which environment was used.
To do this, we will create an authorisation file containing the three users and place it somewhere sensible. For me…
cd /Volumes/projectdisc/projects
mkdir subversion
cd subversion
mkdir authfile
cd authfile
sudo htpasswd -c svn_passwd mpuser
sudo htpasswd svn_passwd mbpuser
sudo htpasswd svn_passwd win7user
you should now have svn_passwd contianing 3 users and their password hash strings. Returning to apache configuration, you may have noticed that the last line of httpd.conf reads…
Include /private/etc/apache2/other/*.conf
This includes, in alphabetical order, any further files ending .conf in the subfolder ‘other’. We will use this to add a svn.conf file to that folder…
cd /private/etc/apache2/other
sudo pico svn.conf
Will open an editor with empty/new file svn.conf. The first line of which will be:
LoadModule dav_svn_module /usr/libexec/apache2/mod_dav_svn.so
After this, we will add configuration blocks, one per project repository…
<Location /svn0000-svntest>
DAV svn
SVNPath /Volumes/projectdisc/projects/0000-svntest/svn
AuthType Basic
AuthName "subversion"
AuthUserFile /Volumes/projectdisc/projects/subversion/authfile/svn_passwd
Require valid-user
SSLRequireSSL
</Location>
Using keys ctrl-o then ctrl-x will save the new file and exit pico.
This configuration block tells apache to redirect svn0000-svntest to the repository at path /Volumes/projectdisc/projects/0000-svntest/svn. It requires a valid user authenticated against the file at /Volumes/projectdisc/projects/subversion/authfile/svn_passwd. Since this location will only ever be served through SSL, basic AuthType is ok and secure.
For apache to pick up this change, we need to restart it:
sudo apachectl graceful
One further step we need to make is to ensure apache is the only user/process to have control of the repository files. This shouldn’t be an issue as we are migrating access to be always via https and don’t want the file protocol used any more…
cd Volumes/projectdisc/projects/0000-svntest/
sudo chown -R www:www svn
At this point you should be able to access the repository through your browser with url http://localhost/svn0000-svntest
You will receive an alert indicating that the certificate is not trusted. You can tell safari that it should always trust this certificate.
To add further repositories, we simply need to change ownership as above, then add the detail to the configuration by simply duplicating the code block above with the Location text and SVNPath modified accordingly. The rest can remain as is.
Migrating existing working copies to the new scheme
My existing working copies each use the file:// url scheme. We need to convert them to use the new https scheme. This is pretty easy assuming you already have the Location added to svn.conf. Just cd to the working copy folder, use svn info to reveal the working copy’s url and relocate…
cd Volumes/projectdisc/projects/0000-svntest/wc
svn info
svn switch --relocate file:///Volumes/projectdisc/projects/0000-svntest/svn/trunk/wc https://localhost/svn0000-svntest/trunk/wc
If you are prompted that the certificate is invalid, use option p to permanently trust the certificate.
Reference links to articles that helped
Reading the following, articles that helped me work out what I wanted to do…
Along with chapters 3 and 10 of Subversion Version Control: Using The Subversion Version Control System in Development Projects ISBN-10: 0-13-185518-2 also on Safari books online.
