Setting up Subversion Access through Apache

Posted by Pat Thu, 09 Feb 2006 22:10:00 GMT

I’ve been using Subversion for my source code control for a few months now. For the server, I’ve just been using the built-in svnserve, which has worked perfectly fine for me. However lately I’ve been doing more projects for outside companies, and dealing with SVN access has been a pain. I have access control on my repository, but svnserve doesn’t allow any fine-grained access…any user has access to the entire repository. I also want to make some of my code publicly available over SVN. Naturally I don’t want everyone in the world to have access to all my business code.

One way to have more fine-grained access control over the repository is to use Apache and mod_dav_svn. Unfortunately we can’t use lighttpd for the task because it doesn’t support mod_dav_svn. I’m not too pleased about having to install Apache, but it’s the right tool for the job. Also, since it will only be a front end to my Subversion repository, I can keep it pretty small.

Installing and Configuring Apache 2

The Subversion documentation says you need to use Apache 2.0, not 1.3. Checking out /usr/ports/www, you’ll see there are three versions of Apache 2 – 2.0, 2.1, and 2.2. I figure it makes sense to just go with the latest one, so that’s what I’ll install. Should work fine though if you decide to go with 2.0 or 2.1 instead.

There are a couple make options that we need to set for the Apache install. You can do these on the command line, but it’s probably a good idea to throw them in /etc/make.conf so that when you upgrade Apache, those options are remembered. So put the following lines in /etc/make.conf:
# Apache config
.if ${.CURDIR:M*/www/apache2*}
WITH_AUTH_MODULES=yes
WITH_DAV_MODULES=yes
WITH_SSL_MODULES=yes
WITH_BERKELEYDB=db42
.endif

# Subversion config
.if ${.CURDIR:M*/devel/subversion}
WITH_APACHE2=true
WITH_MOD_DAV_SVN=yes
.endif
Now go ahead and build Apache:
# cd /usr/ports/www/apache22/ && make install clean
Now you’ll need to rebuild subversion:
# cd /usr/ports/devel/subversion && make deinstall && make install clean
For Apache to be able to use the repository, it must have read/write access to it. Initially I set up my repository at /home/svn/repos, but since I’ll no longer be using the ‘svn’ user, I wanted to move it under /usr/local. So just copy the whole repository over and change the ownership.
# cp -Rp /home/svn/repos /usr/local/repos
# chown -R www:www /usr/local/repos
Finally you need to configure Apache to expose your SVN repository. Go ahead and edit /usr/local/etc/apache22/httpd.conf. I commented out all the modules I didn’t need, so that I could keep Apache as small as possible. Here’s what my module list looks like, along with an example Subversion config:
LoadModule authn_file_module libexec/apache22/mod_authn_file.so
LoadModule authz_host_module libexec/apache22/mod_authz_host.so
LoadModule authz_groupfile_module libexec/apache22/mod_authz_groupfile.so
LoadModule authz_user_module libexec/apache22/mod_authz_user.so
LoadModule authz_dbm_module libexec/apache22/mod_authz_dbm.so
LoadModule authz_owner_module libexec/apache22/mod_authz_owner.so
LoadModule authz_default_module libexec/apache22/mod_authz_default.so
LoadModule auth_basic_module libexec/apache22/mod_auth_basic.so
LoadModule auth_digest_module libexec/apache22/mod_auth_digest.so
LoadModule include_module libexec/apache22/mod_include.so
LoadModule log_config_module libexec/apache22/mod_log_config.so
LoadModule logio_module libexec/apache22/mod_logio.so
LoadModule env_module libexec/apache22/mod_env.so
LoadModule dav_module libexec/apache22/mod_dav.so
LoadModule dav_svn_module libexec/apache22/mod_dav_svn.so
LoadModule authz_svn_module libexec/apache22/mod_authz_svn.so
LoadModule dav_fs_module libexec/apache22/mod_dav_fs.so

<Location />
  DAV svn
  SVNPath /usr/local/repos
</Location>
Now put the following line in /etc/rc.conf:
apache22_enable="YES"
And start up apache:
# /usr/local/etc/rc.d/apache22.sh start

Congrats, you should now be able to go to http://ip/ in your web browser to view your repository. For more detailed config info, check out the Apache section of the SVN Book.

Switching your working copies to use the new URL

You have two options at this point – either just check out your projects again using the new URL, or use the svn switch command to switch each working copy to the new URL. Either one works fine, and the first is probably easier in general. Just ‘svn co http://12.34.56.78/project’. However in case you want to immediately switch it, run the following commands (you need to have svnserve running for this to work):
$ cd working_copy
$ svn switch --relocate svn://12.34.56.78/project http://12.34.56.78/project

Once you’ve done all of this, you don’t need to run svnserve anymore, so you should kill it off. If you forgot to switch a working copy to the new URL, you’ll get an error as soon as you try to execute a command like svn update, so you’ll immediately know to just check out the project again.

Final thoughts

I spent about 15 minutes configuring Apache last night, have a nice little setup. Now my SVN repository is available to the public, and my private projects are all password protected. In addition, I can create users for each private project I’m working on, so the companies I’m developing for have easy SVN access to their own projects, without exposing other companies’ projects. Pretty sweet.

Posted in  | Tags ,  | 5 comments

Using Subversion

Posted by Pat Tue, 30 Aug 2005 03:23:00 GMT

Why the need for version control?

Because I screw up all the time. Seriously. I break my code so much, thrash up my system all the time…I need to be able to go back to a time when things worked. So I use version control.

There are also some pretty nifty things you can do with it to help deploy your apps. I’ll cover some of those in a future article.

There are a couple different pieces of software for version control. CVS, RCS (which I had to use when I was doing Software Engineering at RIT – bleh), and Subversion. Subversion seems to be the tool of choice for Rails developers, so that’s why I started using it. Again, not really based on good technical reasons, but it works really well for me. I’m not sure many people would notice a lot of difference in version control systems because most of us have simple needs, so it’s not that big of a deal.

Getting it set up.

I almost feel bad making a post, because subversion is so easy to set up on FreeBSD.
# cd /usr/ports/devel/subversion && make install clean
And that’s it. I’ll admit this is the first article I’ve written where I’m not typing in the steps as I do them, but I’m pretty sure that’s right.

Next I like to create a subversion user, and store all my repositories under that user’s home dir. It’s pretty simple, just use FreeBSD’s adduser command to create the user. I always set it up as username ‘svn’, random password, rest are defaults. Only time I ever become svn is when I su from root. Alter the setup to match your preferences.

I had initially started instructions on how to create a repository, import a project, etc but that’s all covered very well in the SVN Quickstart Guide. Just so you guys know, I like to store all my repositories in /home/svn/repositories, and I put a bunch of scripts in /home/svn.

Running svnserve to serve up your repository

For people to be able to access your repositories, you have to actually serve it somehow. I do it with svnserve, but you can also use apache+mod_dav_svn. That’s all covered in the excellent SVN Book.

I put the following command in a shell script that I execute as the svn user:
#!/bin/sh
svnserve -d -r /home/svn/repositories --listen-host machine.hostname
Just chmod+x it and run it whenever you want to start up your SVN server. The command means svnserve will run in daemon mode (basically transparent, runs as a background process), and the root is at /home/svn/repositories, so if someone accesses svn://yourserver/projectname it serves up the repository named projectname under /home/svn/repositories – good for security so people can’t just access any file on your system. The last thing to mention is the—listen-host directive. I have to put this in because by default, svnserve runs with IPv6 enabled, so I’m unable to actually make a connection to my server. You may or may not need it – I’d just leave it in. Last thing to do is connect to your svn server. This is pretty simple. From a remote machine (whatever you develop on, usually), type:
%svn checkout svn://hostname/projectname
And you’ve got an up-to-date copy of your project. Check out the quickstart and boook for more info.

SVN runs on port 3690 by default, so be sure to open that in your firewall, or specify a different port using the—listen-port directive.

Setting up authentication for users

If you want to make sure that only authorized users ever take a look at or modify your code, you’ll need to set up basic authentication. After you’ve created a repository, you should have a svnserve.conf file in the conf directory. Edit the contents to contain:
[general]
password-db = passwd
anon-access = none
realm = My Projects Repository
This will prevent anyone from checking out or making modifications to your code without authenticating. If you want people to check it out, set anon-access to read. The password-db command means that the password database will be stored in a file named passwd. So create a passwd file in the conf directory that looks like
[users]
pergesu=ilovefreebsd
That means I can authenticate with username pergesu and password ‘ilovefreebsd’. That’s not my actual password, by the way :) Now that you’ve set up authentication, you’ll need to be sure to use it when checking out a project:
% svn checkout --username pergesu svn://hostname/myproject
Enter your password at the prompt, good to go. Once you’ve authenticated once, you never need to use—username in there again. Not sure how – must be magic.

Wrapping up

So you should have a working SVN repository going, maybe even with authentication. Check out the SVN Book to learn how to do practically everything with SVN. It’s pretty cool. I’ll show you my neat little deployment set up in a couple days. Have fun for now

Posted in  | Tags ,  | no comments