Standard Subversion authentication using plain text user settings and passwords in the passwd and authz files in the Subversion conf directory. This is all fine for a very small installation on a localhost, but it doesn’t work very well in a work environment. Alternatively, SVN can be set up to use LDAP authentication. That’s okay too, but as a lead developer I’d like to have a little more control over the development setup and users. So, even better, its not too difficult to set up Subversion to authenticate using Unix accounts. I say its not too hard because there are some tricky things to contend with. Here goes.
1. Set up your Subversion repository.
I prefer a single repository for all projects, but this is a separate writeup.
2. Install Apache
3. Install Apache Modules
Okay, 1 and 2 were easy. Here’s where it starts to get tricky. We’re going to need a few things (and I’m assuming we’re using Redhat/Fedora/CentOS here). Some of these things may already be installed. Gcc (you probably already have this) and http-devel are both necessary. Http-devel (the development tools for Apache). This is required because we will be building a couple Apache modules. We’re also going to need to install an apache module for Subversion: mod_dav_svn.
yum install gcc yum install http-devel yum install mod_dav_svn
We need an Apache module for mod_authnz_external. There is no yum installer, so it will have to be downloaded and built (no biggie). Grab the tarball from here Building an Apache module is a little different than building other things… To build an install we use the apxs command (this was installed previously using yum install http-devel). So once the mod-auth-external tarball is downloaded we’ll do something like this:
tar xvf mod_authnz_eternal-3.2.5.tar.gz cd mod_authnz_external-3.2.5 apxs -c mod_authnz_external.c (build the module) apxs -i -a mod_authnz_external.la (install the module)
5. User Groups
Next we’re going to install a tool to handle the authentication part.
This is important: Before we install this tool (pwauth) we need to think about how we want to handle Subversion authentication. Do we want specific users to have access? Do we want to create a specific group with access? As a lead developer in charge of administering Subversion access, I recommend creating a subversion group, and call it something like “svnusers.” This is important because when pwauth is built we will have to provide it with a list of groups and/or users who will be allowed to run it (for security purposes).
Go ahead and add a user or two to this group.
useradd -G <user> svnusers
Now take a look at what the group ID of svnusers is:
This command will show all the groups that a user belongs to, and something like 501(svnusers) should be one of them.
6. Download, build and install pwauth
Pwauth is a handy program for authenticating a user against the Linux user db (/etc/shadow) that is designed to be used with mod_authnz_external. Download it and untar it and go to the directory where you untarred it.
In the pwauth directory you will see a config.h file. Open this up and make the following changes:
#define SERVER_UIDS 501 (or whatever the UID of your svnusers group is)
The SERVER_UIDS setting pwauth that anyone in the svnusers group can be authenticated. The MIN_UNIX_UID setting tells pwauth what the minimum user UID that pwauth can authenticate is. Leave this value out entirely or set it to 0.With this changes save it is safe to compile. From the command line:
After pwauth is built it is time to install it. There is no simple install script, so it is important to read the INSTALL text file that appears in this directory. Everything that you’ll ever need to know about installing pwauth is in this text file. A few important notes are: * pwauth is owned by root so that is has the necessary access to read the shadow file. So wherever you placed the pwauth executible, you’ll have to do something like this:
chmod o+s pwauth
7. Finally, we need to do some stuff to our Apache configuration (httpd.conf).
These are the modules that make the SVN and pwauth magic happen.
Later in the httpd.conf file we’ll create a VirtualHost specifically for serving up Subversion. Any client will use http:// rather than svn:// to access the Subversion repository. That said, I recommend using Apache Virtual Hosts to use different ports for different purposes (for example, plain old port 80 remains your normal http index and port 3600 can be used for Subversion access).
So in httpd.conf do something like this:
Listen 80 Listen 3600 NameVirtualHost *:80 NameVirtualHost *:3600 <VirtualHost *:80> DocumentRoot "/var/www/html" ServerName myserver </VirtualHost> <VirtualHost *:3600 DocumentRoot "/" ServerName myserver <Location /> DAV svn SVNPath /var/svn/repo SVNListParentPath on AuthType Basic AuthNAme "Restricted" AuthBasicProvider external AuthExternal pwauth require valid-user require group svnusers </Location> AddExternalAuth pwauth /usr/local/bin/pwauth SetExternalAuthMethod pwauth pipe </VirtualHost>
Restart Apache (service httpd restart). Now when you want to view, checkout or commit to the Subversion repo you’ll use an ip address something like:
And, of course, you’ll need to enter the username and password of a valid user who belongs to the svnusers group on the Subversion server. To check out a particular subfolder you would use http://my.host.name/project. Notices in the example above I made the SVNPath include the repo (/var/svn/repo). I could have made it simply /var/svn, requiring clients to include the /repo at the end of the URL. This is just a matter of personal preference.
8. One last thing: Back to the repository
That repository that you already created is owned by the user it was created as but it is now accessed via Apache, and we are no longer using the default Subversion authz settings. This means that if a client attempts to modify it (check something in), it will be done as the Apache user, and change are the Apache user doesn’t have read/write access to the repository. So you’ll want to do something like this:
chown -R apache.apache /var/svn
Notes: There are certainly other ways to handle this configuration, and it may be wise to make a few different groups (for example, svnusers, svnreaders, svndevelopers, svntechwriters and so on).