create new tag
view all tags

Subversion Component

Note: Some of this assumes you are using version 2.0.6 of the LCFG subversion component

The Basics

In the simplest case you can just use the subversion component to create repositories and manage the unix user/group access permissions. In this scenario you just need

#define _SUBVERSION_REPOSDIR /var/svn
#define _SUBVERSION_USER svn

#include <lcfg/options/subversion-server.h>

/* A helpful macro for creating repositories */


The three macros must be defined before including the header. They are:

The base directory into which the subversion repositories will be stored
This is the default username for a repository, it is also the user under which the service will run from xinetd
This controls what access is permitted to tcp and udp port 3690 via tcpwrappers

This gets you a working repository which can be accessed via svn+ssh and svnserve. You would need to manage the configuration and authorization files by hand for each repository though.

Managing the Configuration.

If you want to do anything more sophisticated you want to turn on the manageconf and authz resources for your repositories. Here's an example for the lcfg subversion repository:

!subversion.authzdb_lcfg           mSET(authz)
!subversion.manageconf_lcfg    mSET(yes)

You can then manage the authorization via lcfg. For each repository you can create groups of users and then you can control access for as many different paths as you like. This can quickly get a bit complex.

Here's how to create a group of users for the lcfg repository:

!subversion.authzgroups_lcfg                          mADD(rainbow)
subversion.authzmembers_lcfg_rainbow         rod jane freddy zippy george bungle

You can then refer to groups in your access control lists:

!subversion.authzentries_lcfg                                mADD(root)
subversion.authzpath_lcfg_root                             /
subversion.authzallow_lcfg_root                           rainbow
subversion.authzallowperms_lcfg_root_rainbow   rw

A path can have as many access rules as you like. For each entity (i.e. a user or group) you will need to specify the access permissions, these can be any of the standard svn authz options "" (empty string, no access), "r" (read-only access) or "rw" (read-write access), you can also use "none" which is an alias for the empty string where you want to be more clear and explicit. If you do not specify anything then that entity will be specified to have no access to that path.

There is a special entity "ALL" which is used when you want to insert an entry which matches all users which is done with an asterisk "*" in the authorization file. In terms of access controls, this works in the same way as any other entity. For example:

!subversion.authzallow_lcfg_root                        mADD(ALL)
subversion.authzallowperms_lcfg_root_ALL       none

If you need to give access to an entity which contains characters which are not allowed in LCFG resource names you can work around it like this:

!subversion.authzallow_lcfg_root                        mADD(foo)
subversion.authzallowname_lcfg_root_foo          foo@example.org
subversion.authzallowperms_lcfg_root_foo         rw

The authorization file for each repository is created in the location specified in the subversion.authzdb_ resource. If it is a relative path it will be created within the repository conf directory, if it is an absolute path then that is used.


There is also another file created which is named webdav_authz which is put into the top-level subversion directory (e.g. /var/svn/webdav_authz) which contains all the authorization information for all the repositories. This can then be used to control access to the subversion repositories if they are access through webdav.

Currently there is no LCFG-level support for configuring apache to support svn over WebDAV.


An extra method is provided in the subversion component for dumping repositories. This can then be used nightly from cron to get gzipped dump files which can be stored as backups. Using dumps is a safer method than just taking a direct copy of the repository tree. For example:

50 23 * * * /usr/bin/om subversion dumpdb -- -r lcfg -g -k 30 2>&1 |egrep -v '^\[OK\]'

There are a number of options for this method:

This is a string which is the repository name and it is required
This is a flag to control whether the dump file will be gzipped
This is a flag to control whether anything should actually be done or whether to just print out some debug messages
This is the directory into which the dump file will be placed. It defaults to /var/lcfg/svndump/$repository
This is the name of the dump file, if not specified it defaults to a name based on the date, $repository.%Y-%m-%d.dump
This is the integer number of backups to keep, if specified and there are more than the specified number then the oldest number of files over the limit will be removed.

-- Main.squinney - 22 Jan 2009

Topic revision: r1 - 2009-01-22 - squinney
This site is powered by the TWiki collaboration platform Powered by PerlCopyright © 2008-2020 by the contributing authors. All material on this collaboration platform is the property of the contributing authors.
Ideas, requests, problems regarding TWiki? Send feedback