Svnserve Based Server

Introduction

There may be situations where it's not possible to use Apache as your server. Fortunately, Subversion includes Svnserve - a lightweight stand-alone server which uses a custom protocol over an ordinary TCP/IP connection.

In most cases svnserve is easier to setup and runs faster than the Apache based server. And now that SASL support is included it is easy to secure as well.

Installing svnserve

  1. Get the latest version of Subversion from http://subversion.tigris.org/servlets/ProjectDocumentList?folderID=91 . Alternatively get a pre-packaged installer from CollabNet at http://www.collab.net/downloads/subversion . This installer will setup svnserve as a Windows service, and also includes some of the tools you need if you are going to use SASL for security.

  2. If you already have a version of Subversion installed, and svnserve is running, you will need to stop it before continuing.

  3. Run the Subversion installer. If you run the installer on your server (recommended) you can skip step 4.

  4. Open the windows-explorer, go to the installation directory of Subversion (usually C:\Program Files\Subversion) and in the bin directory, find the files svnserve.exe, intl3_svn.dll, libapr.dll, libapriconv.dll, libapriutil.dll, libdb*.dll, libeay32.dll and ssleay32.dll - copy these files, or just copy all of the bin directory, into a directory on your server e.g. c:\svnserve

Running svnserve

Now that svnserve is installed, you need it running on your server. The simplest approach is to run the following from a DOS shell or create a windows shortcut:

svnserve.exe --daemon

svnserve will now start waiting for incoming requests on port 3690. The --daemon switch tells svnserve to run as a daemon process, so it will always exist until it is manually terminated.

If you have not yet created a repository, follow the instructions given with the Apache server setup the section called “Configuration”.

To test that svnserve is working, use TortoiseSVNRepo-Browser to view a repository.

Assuming your repository is located in c:\repos\TestRepo, and your server is called localhost, enter:

svn://localhost/repos/TestRepo

when prompted by the repo browser.

You can also increase security and save time entering URLs with svnserve by using the --root switch to set the root location and restrict access to a specified directory on the server:

svnserve.exe --daemon --root drive:\path\to\repository\root

Using the previous test as a guide, svnserve would now run as:

svnserve.exe --daemon --root c:\repos

And in TortoiseSVN our repo-browser URL is now shortened to:

svn://localhost/TestRepo

Note that the --root switch is also needed if your repository is located on a different partition or drive than the location of svnserve on your server.

Svnserve will service any number of repositories. Just locate them somewhere below the root folder you just defined, and access them using a URL relative to that root.

Warning

Do not create or access a Berkeley DB repository on a network share. It cannot exist on a remote filesystem. Not even if you have the network drive mapped to a drive letter. If you attempt to use Berkeley DB on a network share, the results are unpredictable - you may see mysterious errors right away, or it may be months before you discover that your repository database is subtly corrupted.

Run svnserve as a Service

Running svnserve as a user is usually not the best way. It means always having a user logged in on your server, and remembering to restart it after a reboot. A better way is to run svnserve as a windows service. Starting with Subversion 1.4, svnserve can be installed as a native windows service.

To install svnserve as a native windows service, execute the following command all on one line to create a service which is automatically started when windows starts.

sc create svnserve binpath= "c:\svnserve\svnserve.exe --service 
    --root c:\repos" displayname= "Subversion" depend= tcpip 
    start= auto

If any of the paths include spaces, you have to use (escaped) quotes around the path, like this:

sc create svnserve binpath= "
    \"C:\Program Files\Subversion\bin\svnserve.exe\"
    --service --root c:\repos" displayname= "Subversion" 
    depend= tcpip start= auto

You can also add a description after creating the service. This will show up in the Windows Services Manager.

sc description svnserve "Subversion server (svnserve)"

Note the rather unusual command line format used by sc. In the key= value pairs there must be no space between the key and the = but there must be a space before the value.

Tip

Microsoft now recommend services to be run as under either the Local Service or Network Service account. Refer to The Services and Service Accounts Security Planning Guide . To create the service under the Local Service account, append the following to the example above.

obj= "NT AUTHORITY\LocalService"

Note that you would have to give the Local Service account appropriate rights to both Subversion and your repositories, as well as any applications which are used by hook scripts. The built-in group for this is called "LOCAL SERVICE".

Once you have installed the service, you need to go to the services manager to start it (this time only; it will start automatically when the server reboots).

For more detailed information, refer to Windows Service Support for Svnserve .

If you installed an earlier version of svnserve using the SVNService wrapper, and you now want to use the native support instead, you will need to unregister the wrapper as a service (remember to stop the service first!). Simply use the command

svnservice -remove

to remove the service registry entry.

Basic Authentication with svnserve

The default svnserve setup provides anonymous read-only access. This means that you can use an svn:// URL to checkout and update, or use the repo-browser in TortoiseSVN to view the repository, but you won't be able to commit any changes.

To enable write access to a repository, you need to edit the conf/svnserve.conf file in your repository directory. This file controls the configuration of the svnserve daemon, and also contains useful documentation.

You can enable anonymous write access by simply setting:

[general]
anon-access = write

However, you will not know who has made changes to a repository, as the svn:author property will be empty. You will also be unable to control who makes changes to a repository. This is a somewhat risky setup!

One way to overcome this is to create a password database:

[general]
anon-access = none
auth-access = write
password-db = userfile

Where userfile is a file which exists in the same directory as svnserve.conf. This file can live elsewhere in your file system (useful for when you have multiple repositories which require the same access rights) and may be referenced using an absolute path, or a path relative to the conf directory. If you include a path, it must be written /the/unix/way. Using \ or drive letters will not work. The userfile should have a structure of:

[users]
username = password
...

This example would deny all access for unauthenticated (anonymous) users, and give read-write access to users listed in userfile.

Tip

If you maintain multiple repositories using the same password database, the use of an authentication realm will make life easier for users, as TortoiseSVN can cache your credentials so that you only have to enter them once. More information can be found in the Subversion book, specifically in the sections Create a 'users' file and realm and Client Credentials Caching

Better Security with SASL

What is SASL?

The Cyrus Simple Authentication and Security Layer is open source software written by Carnegie Mellon University. It adds generic authentication and encryption capabilities to any network protocol, and as of Subversion 1.5 and later, both the svnserve server and TortoiseSVN client know how to make use of this library.

For a more complete discussion of the options available, you should look at the Subversion book in the section Using svnserve with SASL . If you are just looking for a simple way to set up secure authentication and encryption on a Windows server, so that your repository can be accessed safely over the big bad Internet, read on.

SASL Authentication

To activate specific SASL mechanisms on the server, you'll need to do three things. First, create a [sasl] section in your repository's svnserve.conf file, with this key-value pair:

use-sasl = true

Second, create a file called svn.conf in a convenient location - typically in the directory where subversion is installed.

Thirdly, create two new registry entries to tell SASL where to find things. Create a registry key named [HKEY_LOCAL_MACHINE\SOFTWARE\Carnegie Mellon\Project Cyrus\SASL Library] and place two new string values inside it: SearchPath set to the directory path containing the sasl*.dll plug-ins (normally in the Subversion install directory), and ConfFile set to the directory containing the svn.conf file. If you used the CollabNet installer, these registry keys will already have been created for you.

Edit the svn.conf file to contain the following:

pwcheck_method: auxprop
auxprop_plugin: sasldb
mech_list: DIGEST-MD5
sasldb_path: C:\TortoiseSVN\sasldb

The last line shows the location of the authentication database, which is a file called sasldb. This could go anywhere, but a convenient choice is the repository parent path. Make sure that the svnserve service has read access to this file.

If svnserve was already running, you will need to restart it to ensure it reads the updated configuration.

Now that everything is set up, all you need to do is create some users and passwords. To do this you need the saslpasswd2 program. If you used the CollabNet installer, that program will be in the install directory. Use a command something like this:

saslpasswd2 -c -f C:\TortoiseSVN\sasldb -u realm username

The -f switch gives the database location, realm must be the same as the value you defined in your repository's svnserve.conf file, and username is exactly what you expect it to be. Note that the realm is not allowed to contain space characters.

You can list the usernames stored in the database using the sasldblistusers2 program.

SASL Encryption

To enable or disable different levels of encryption, you can set two values in your repository's svnserve.conf file:

[sasl]
use-sasl = true
min-encryption = 128
max-encryption = 256

The min-encryption and max-encryption variables control the level of encryption demanded by the server. To disable encryption completely, set both values to 0. To enable simple checksumming of data (i.e., prevent tampering and guarantee data integrity without encryption), set both values to 1. If you wish to allow (but not require) encryption, set the minimum value to 0, and the maximum value to some bit-length. To require encryption unconditionally, set both values to numbers greater than 1. In our previous example, we require clients to do at least 128-bit encryption, but no more than 256-bit encryption.

Authentication with svn+ssh

Another way to authenticate users with a svnserve based server is to use a secure shell (SSH) to tunnel requests through. It is not as simple to set up as SASL, but it may be useful is some cases.

With this approach, svnserve is not run as a daemon process, rather, the secure shell starts svnserve for you, running it as the SSH authenticated user. To enable this, you need a secure shell daemon on your server.

A basic method for setting up your server is given in Appendix G, Securing Svnserve using SSH. You can find other SSH topics within the FAQ by searching for “SSH”.

Further information about svnserve can be found in the Version Control with Subversion .

Path-based Authorization with svnserve

Starting with Subversion 1.3, svnserve supports the same mod_authz_svn path-based authorization scheme that is available with the Apache server. You need to edit the conf/svnserve.conf file in your repository directory and add a line referring to your authorization file.

[general]
authz-db = authz

Here, authz is a file you create to define the access permissions. You can use a separate file for each repository, or you can use the same file for several repositories. Read the section called “Path-Based Authorization” for a description of the file format.