Sick and tired of svnserve? Want an efficient way to serve and manage your Subversion repositories? Well luckily there’s an alternative to the standard svnserve daemon. Through the usage of WebDAV and its Apache module you can serve your Subversion repositories through your web server. This tutorial will quickly go over how that happens.
What and Why?
WebDAV is a standard that allows for the collaboration of work through the HTTP protocol. If you’re familiar with svnserve then you’ll know you’ve been using the svn:// protocol until now. We’re going to change that.
We’re also going to introduce fine grain permissions handling with Authz. Authz is simple an authentication API and it has a dedicated SVN module that comes with the WebDAV SVN module. Combined these two modules bring you more power than you currently have with the standable svnserve daemon.
Installation varies from distro to distro so I’m only going to give an example of how this will happen on a Yum-based distro. You may already have the module installed, so you’ll want to check for that before you waste any more time (it’s called mod_dav_svn.so and will be in your Apache modules directory). Installing the module through Yum is done as follows (as root):
yum install mod_dav_svn
This should install the mod_authz_svn module as well. If you’re not on RHEL/CentOS/Fedora your distro probably has a package manager of its own which you may use in a similar fashion.
We’ll be working with the subversion.conf file found in your Apache configuration directory (probably /etc/httpd/conf.d/). If it doesn’t exist, then just create it. Apache should be importing all *.conf files inside the configuration directory anyways.
The first thing we’re going to do is load the modules.
LoadModule dav_svn_module modules/mod_dav_svn.so LoadModule authz_svn_module modules/mod_authz_svn.so
Now we’ll create a location from which you’ll access your repositories via your web server. In this example we’re going to call it “/repos”. This means your repositories will be accessible through http://domain.tld/repos/reponame. Feel free to change this as you see fit.
We’re also going to declare this location as a DAV SVN directory.
1 2 3
<Location /repos> DAV svn </Location>
Simple enough. The next thing is telling the module where all of your SVN repositories are stored. In other words the parent directory you keep them in. You’ll also need to make this this directory is accessible by Apache. I recommend you change ownership of it and all of its child files to the user your Apache server is running as (apache by default).
chown -R apache:apache /var/svn
Obviously this assumes your parent directory is /var/svn. It’s arbitrary and there is no default location; it is wherever you made it when you started hosting Subversion. I personally use /var/svn and will be using it throughout this tutorial. So remember to replace any occurences of it to your actual location.
Either way, once you’ve got the ownership setup lets tell the module where to look.
1 2 3 4
<Location /repos> DAV svn SVNParentPath /var/svn </Location>
Technically speaking that’s all that is required. If you restart Apache and go to http://domain.tld/repos/somerepository you should see the latest revision display. But there’s a major flaw: this is open for the world. Anonymous viewing is typical, but anybody could commit, merge, branch, add, delete, propset, etc. from your repositories right now. We’re going to fix that.
Before we edit subversion.conf again we need to create two files. The first is an htpasswd file that stores usernames and passwords. These accounts will be used in the authentication set. Lets do that now:
htpasswd -c /var/svn/users disease
Obviously you’ll need to change the location of the users file (and feel free to rename it to whatever you want). And you’ll want to use your own username because chances are you don’t go by mine. Once that has been created lets create our Authz authentication file in the same location.
This is just a plain text file. I’m naming mine “access”. So go ahead and create your file and then open it in your text editor of choice.
1 2 3 4 5 6 7 8 9 10 11 12
[groups] somegroup = disease [repo1:/] @somegroup = rw [anotherepo:/trunk] trunkcontributor = rw trunkreader = r [/] * = r
All of the above is fluff designed to show you the syntax of this file. At the top we created a group. You can create many groups for easier permissions handling. Usernames are seperated by a comma. And when you refer to a group in a repository area, you append the @ sign. We see that right away in repo1.
This syntax states we’re editing the “repo1” repository and we’re dealing with all of it, not just any particular subdirectory. And what we have done inside it is given the somegroup group read and write permissions. Next we see how we can specify subdirectories in a repository: “anotherrepo:/trunk” will restrict the following permissions to the trunk directory of anotherrepo.
And lastly we define the global permissions for all repositories. It’s standard for the world to receive read writes, which is what we’ve done. The asterick character is a wildcard, including anonymous (no username).
It should be noted that an “r” is read and “w” is write. Modify your access file to suit your needs and then we’ll move on back to subversion.conf.
In order to tie everything together we do the following:
1 2 3 4 5 6 7 8 9 10 11 12 13
<Location /repos> DAV svn SVNParentPath /var/svn AuthzSVNAccessFile /var/svn/access AuthType Basic AuthName "SVN Repos" AuthUserFile /var/svn/users Satisfy Any Require valid-user </Location>
Most of that should be familiar to you as it’s basic Apache authentication. We bring in the Authz access file, declare the authentication scheme and bring in the password file. At the end we state “Satisfy Any.” This is an Authz parameter and it facilitates the allowance of anonymous users. You may deny them in your access file anyways, but this directive allows for the possibility of them being allowed. And the last line asks for a valid user should they not be anonymous or otherwise allowed through your Authz file.
Once you have that you’re done. Restart Apache and enjoy.
So it’s a very simple process but has an uncanny ability to get frustrafting when things go wrong. If you have any issues watch your error_log file because Apache will bark at you through it. One common problem, for you mod_security users: this doesn’t play nicely. I recommend disabling mod_security on the repos directory entirely.
1 2 3
<Location /repos> SecRuleEngine Off </Location>
Thanks for reading!