Setting Up a Subversion Server on Debian Sarge (3.1) ---------------------------------------------------- Introduction ------------ I've recently moved my meager number of projects into Subversion repositories to keep track of them easier. I strongly suggest that everyone do this, including those with only a single project; revision control is a wonderful and easy system for storing source code. Originally I set up my Debian Sarge HPPA system on a nice, but rather slow, HP workstation. Everything ran like a dream. The easiest way to set it up is the wonderful apt-get command: apt-get install subversion All done! Setting up svnserve, the subversion server, is also rather easy. A single line needs to be added into you inetd.conf file: svn stream tcp nowait svn /usr/bin/svnserve svnserve -i Again, everything is peachy. Problems with Apache2 --------------------- There is a problem, however, with the Subversion package compiled for Debian. I noticed the issue when I moved my Subversion repositories to a much faster HP workstation. I planned on running Apache2 and Subversion on this system. The problems began after running the Subversion server for a few days alongside Apache2. Eventually, any request to the Subversion server (still operating through svnserve through inetd) ran unbelievably slowly. Waiting for a repository listing took at least 5 minutes to complete. Examining the process list showed that svnserve was indeed running, but did not seem to be doing anything. Please note at this point that I have alluded to the fact that the problem stems from Apache2, which I haven't even mentioned. Indeed Apache2 has nothing to do with svnserve under this simple setup. Simply disabling or removing Apache2 also does not fix the problem. The problem stems from svnserve's prefered source for entropy, namely /dev/random. This device under Linux is apparently a blocking device, meaning only one process can connect to it at a time, and others have to wait in line for their turn. A google search turned up an obscure mailing list submission mentioning that svnserve, which uses /dev/random for encrypting transmissions, and Apache2 were getting into some conflicts with accesses to /dev/random, quickly consuming all the entropy in the device. Because the entropy was being consumed so quickly, svnserve was becoming unresponsive while waiting for entropy from /dev/random. How to Fix Your Problem: Some Theory ------------------------------------------------- Linux provides another random device, /dev/urandom, that does not block and does not (apparently) run out of entropy so quickly. The only issue with /dev/urandom is that it is not quite as random. Now remember that svnserve uses /dev/random to encrypt transmissions, but is it really that essential that the encryption be rock-solid? I admit that I am completely unfamiliar with svnserve's need for randomness, but I always remember a few facts about my use of subversion: 1) Is my project that sensitive that I don't want people to see my source code? In my case, no, but in a corporate environment, maybe. But rememeber the next point... 2) If you care so much about security, maybe svnserve isn't for you. Apache2 has Subversion plugins I'm not totally aware of. 3) My transmissions all take place behind a firewall anyway. If nobody can even get on the network to sniff your only 99.99999% secure subversion transmissions, then who really cares how secure each subversion transmission is. 4) Backups. People shouldn't leave only one copy of their work lying around anyway. If someone with way to much free time and an apparent personal vendetta against you decides to hack in and destroy your repository because you only used less than ideal randomness on the server side, then you should have a backup on removable media anyways. 5) Read that last sentence on point 4 and see if you're really that worried about the quality of your server-side entropy. How to Fix Your Problem: The Nuts and Bolts ------------------------------------------- Okay, now get ready. We're about to abandon Debian's apt-get methodology. First step is to dump all your repositories to files with your currently installed distribution of Subversion. Run the command: svnadmin dump myrepos > dumpfile Do the above for each repository. The next step is to get rid of Debian's subversion: apt-get remove subversion Your system is now clean of the troublesome Debian Subversion package. Go to the Subversion website (http://subversion.tigris.org/) and download the latest distribution. Extract the archive and enter the created directory. It is time to configure subversion. Run ./configure in the top subversion source directory. I suggest adding the flag --without-berkeley-db. Using the berkeley-db storage format for subversion is, in my eyes, a bit risky. This is a matter of taste, however, and more info can be found at: http://svnbook.red-bean.com/nightly/en/svn.reposadmin.html#svn.reposadmin.basics.backends Most likely, you will have all the required development libraries installed. Should configure complain about some missing library, some careful apt-get's should install everything you need. Now try to hold on a minute. Once configure is done, don't just run make. Next comes the step where the random number source is specified. Descend into the apr/ directory from the top-level subversion source directory. This directory contains the Apache Portable Runtime, and it's purpose is not important here. When ./configure was run on the top level source directory, APR was also configured. However, it defaults to using /dev/random. While in apr/, run configure with the following flag: ./configure --with-devrandom=/dev/urandom This will reconfigure APR only. Return to the top level subversion source directory and run make. I suggest that when make has completed running 'make check' which exercises all the subversion tools. Since you're no longer using a prebuilt and tested Debian package, you'll want to make sure that everything went well. Once complete, run 'make install' as root, which puts all the binaries in /usr/local/bin. Some Setup and Cleanup ---------------------- Okay, now you're ready to set up your new Subversion repositories. I'll leave that to the reader to do alone. For tips on setting up Subversion repositories, I suggest the following site: http://www.linuxfromscratch.org/blfs/view/stable/server/svnserver.html Once you've created the new repositories, the original repositories can be restored using the command: svnadmin load newrepos < dumpfile One last change is necessary for svnserve to run correctly. Recall that the entry in inetd.conf fro svnserve referred to /usr/bin/svnserve, which is no longer there. Your new svnserve line should read: svn stream tcp nowait svn /usr/local/bin/svnserve svnserve -i Your svnserve installation should run like a dream now! Conclusions ----------- A quick change to the subversion configuration during compilation can result in a version of svnserve that coexists peacefully with an Apache2 server. I've seen no problems with my servers under this configuration. If you have any problems with these instructions, feel free to contact me with questions. -Jeff Armstrong jba@member.fsf.org March 21, 2006 --- Copyright 2006 Jeffrey Armstrong - All Rights Reserved ---