Nov 24

So we have decided to move the subversion direction, so its time to get some infrastructure working so lets get through the initial setup.

The aim of the setup is to have the following:

  • Authentication from the Windows Active Directory
  • Folder permissions to control write access
  • Emails sent on each commit

I’ve chosen to use Ubuntu 8.10 as the base operating system, and will assume that you can install the operating system.

Setup AD Authentication

The other main step is the AD integration, this is not that straight forward, but as long as you remember to put the domain in UPPERCASE, its not too hard.

I followed the http://tech.givemethe.net/node/18 post that goes into much detail on the required packages and the testing to get authentication working.

Basically the aim is to get the PAM subsystem authenticating off the domain, which we can then use as a base for subversion to do it authentication against.

I you don’t want to authenticate off an AD, then you can skip all of this information and just use local account authentication.

Install Packages

We need to get the subversion binaries, apache and the connecters to allow apache to do its authentication from pam, along with the apache svn module.

apt-get install subversion
apt-get install apache
apt-get install libapache2-mod-auth-pam
apt-get install libapache2-svn

Dependancy management rocks.  If you don’t have apt-get then try yum (redhat based distros) if you have to download compile and install the packages manually, then there are probably more detailed walkthroughs than I have time to write.

Setup Repository

Pretty simple, just create the location and create the repository.

mkdir /usr/local/svnroot
svnadmin create /usr/local/svnroot/

Configure Apache

When we installed the mod-auth-pam and svn modules for apache2, they should have been activated.

Check this by looking in the ‘mods-enabled’ directory.

ls -l /etc/apache2/mods-enabled/
total 0
<content trimmed>
lrwxrwxrwx 1 root root 31 2008-11-24 10:11 auth_pam.load -> ../mods-available/auth_pam.load
<content trimmed>
lrwxrwxrwx 1 root root 26 2008-11-24 10:17 dav.load -> ../mods-available/dav.load
lrwxrwxrwx 1 root root 30 2008-11-24 10:17 dav_svn.conf -> ../mods-available/dav_svn.conf
lrwxrwxrwx 1 root root 30 2008-11-24 10:17 dav_svn.load -> ../mods-available/dav_svn.load
<content trimmed>

Now that we have all the pre-requisites installed, we can start to configure the applications.

Lets first start with the apache configurations

cd /etc/apache2/sites-available/
vi default

And then put in the following section in the file.  Of course you can do things like setup a Virtual Host just for subversion, but for the testing we require installing inside the default configuration is acceptable.

<Location /svn>
    DAV svn
    AuthzSVNAccessFile /etc/svn/svnaccess.conf
    SVNPath /usr/local/svnroot
    AuthUserFile /dev/null
    AuthType Basic
    AuthName "SVN repository"
    AuthBasicAuthoritative Off
    AuthPAM_Enabled on
    Require valid-user
</Location>

So a bit of detail here, this says to mount the /svn location as a WEBDAV point, using the svn provider.

We will be setting up per-path authentication shortly, so the AuthzSVNAccessFile directive shows where to access the config file.

SVNPath is the path to the actual svn repository.

AuthUserFile is to fix a bug in apache2 due to the fact we are not using the basic authentication (see below for more details).

The rest of the auth setup is pretty standard as with any apache authentication, apart from the AuthPAM_Enabled, and you can guess what that is doing.

SVN Testing

At this point you might want to comment out the AuthzSVNAccessFile line and just test that you can access the repository and the AD pam passthrough authenitcation is working.

I did this from eclipse, and it took a couple of tweeks in my config file to get the login working.

Just ensure that you can logon locally with the domain credentials, then it should all pass through apache smoothly.

I took this time to create a /trunk /branches /releases folders that I use later for security.

Per path authentication

I’ve only just started to configure the access restriction, so see http://svnbook.red-bean.com/en/1.1/ch06s04.html 2/3’s of the way down for details on the configuration of the authentications. Future posts will go into more detail on this subject.

As I only have a single repository configured I don’t need to set repository prefixes, but the link above shows more details.

What I want to do is ensure that you can’t write to trunk, only to project based sub-directories.

[groups]
admins = steve
developers = steve, someoneelse

[/]
* = r

[/trunk]
* = r

[/trunk/project1]
* = rw

[/trunk/project2]
* = rw

[/branches]
steve = rw

[/releases]
steve = rw

This setup allows any authenticated user to write to the project1 and project2 folders, but only ‘steve’ to write to /releases and /branches

Error messages

The bulk of the error messages I got was with (as expected) the apache—>pam—>AD integration.

  • (9)Bad file descriptor: Could not open password file: (null)

This was caused by a bug in apache trying to do file authentication even though we are using PAM lookups.  To remove this from the log file, just add the following to the apache config.

AuthUserFile /dev/null

  • (2)No such file or directory: The URI does not contain the name of a repository.

This on was my fault, I was coping a configuration from a forum post, and it used SVNParentPath instead of what I needed SVNPath. See below for a discussion on the differences.

Sidenote: Configuring multiple repositories

If you are going to run multiple repositories on the server you can have 1 set of configuration manage all repositories.  Just create all the repositories under a single directory, and use the SVNParentPath directive to point to that folder.

For example, if you have repositories in

/usr/local/svnroot/repo1
/usr/local/svnroot/repo2
/usr/local/svnroot/repo3

With repo1, repo2 and repo3 each being seperate repositories, then use

SVNParentPath /usr/local/svnroot

and you will be able to access

http://servername/svn/repo1
http://servername/svn/repo2
http://servername/svn/repo3

with the single configuration

Setup email commits

The last step is to get the

I followed the instructions on http://help.joyent.com/index.php?pg=kb.page&id=53, but they are detailed below for completeness.

If you want to use a local mailer in your configuration then you might need to install your favourite.

apt-get install sendmail

Its then just a matter of installing the svnnotify script, and configure the post-commit hook.

perl -MCPAN -e ‘install SVN::Notify’
vi /usr/local/svnroot/hooks/post-commit

Add in the content

#!/bin/sh
REPOS="$1"
REV="$2"
/usr/local/bin/svnnotify -r $REV -C -d -H HTML::ColorDiff -p $REPOS –smtp localhost -t svn-commits@mydomain.com.au –from svn-commits@mydomain.com.au –reply-to svn-commits@mydomain.com.au

Then just save the file, ensure that the owner and permissions are correct.

chown www-data /usr/local/svnroot/hooks/post-commit
chmod u+x /usr/local/svnroot/hooks/post-commit

Email Testing

You should be able to now perform a commit and see the email sent to your specified to address, if not, check the permissions on the file are executable by your apache user.  To test that the script is configured correctly you can manually run the script and check for errors

/usr/local/svnroot/hooks/post-commit /usr/local/svnroot/ 4

Next Steps

Now that we have a working repository, that authenticates off our Active Directory, has per-path access controls and emails us on each commit we can do some testing.

Items to follow up:

  • Discussion on repository layout
  • Virtual Host configuration inc SSL
  • ViewVC integraton
  • Continuous integration
  • Bug / Issue tracking integration
  • AD Based Group Access
    • I don’t want all users in the AD to have access, only those in the SVN Users group

Thats all for now, post any questions in the comments.