Subversion Repository Administration - Ece

Subversion Repository Administration

From Ece

Jump to: navigation, search

This guide explains how to create a repository and apply an appropriate access configuration.

Contents

Creating a Repository

Creating the repository is the easiest part. Simply decide where you want to put the repository, and create it. For example, if user jdoe wants a personal repository named repos inside his home directory, he would create it as follows: 

cd /home/jdoe
svnadmin create repos

For Subversion 1.2 and later, this will default to the file system type FSFS, in case you are concerned about the file system type used.

Note: this creates a repository with default file permissions according to your umask. You should consider explicitly configuring the repository according to one of the following options.

Configuring Private Access

If you are creating a repository for private/personal use, then this is the easiest to configure. Just make sure you have full read/write permission on all repository files, as well as execute permission on the repository directories.

For example, user jdoe has a repository /home/jdoe/repos intended for private use. To restrict access to himself only, he would run: 

chmod -R u+rwX,go-rwx /home/jdoe/repos

Configuring Group Access

If a group or team needs to a share a repository, and they already have their own user group on a Linux/UNIX server, than group permissions can be leveraged to give access to everyone in the group.

For example, to give the group myteam access to a repository /path/containing/repos:

  1. Change to the directory containing the repository directory. 
    cd /path/containing
  2. Change the group ownership of all files in the repository. 
    chgrp -R myteam repos
  3. Set the setgid bit on only the directories. This causes all new files created inside those directories to be also owned by myteam. 
    find repos -type d -print | xargs -i chmod g+s {}
  4. Grant full permissions to only the owner and the group. 
    chmod -R ug+rwX repos

If your teammates cannot checkout after this, try making sure the execute permission is set on every directory from root / all the way down to the repository. You may not have the permission to do this on some of the higher-level directories, so you would probably just adjust each directory one-at-a-time.

To see the permissions of files and directories, use: 

ls -l

If you see an s where you would normally see an x, then x is set. However, if you see a capital S, then x is not set.

To set the group-execute permission on a directory somedir: 

chmod g+x path/to/somedir

Configuring Shared Access

If a group or team needs to share a repository, but they do not have a user group created on the server, then a single user can instead share access to the repository via public-key authentication. When these instructions are strictly followed, a single user can allow other users to authenticate using that one user's account, but only to access the subversion repository.

While this may not seem very secure, it is actually more restrictive than giving group-write permissions on a folder you own. With this setup, users cannot directly access the repository files. They will only be able to invoke svnserve. Note also that this method will still allow the correct author name to be recorded on each commit.

Start by creating a repository and configuring it just like a private repository.

Granting Limited Access to Public Keys

First, make sure you understand how to set up public-key authentication, particularly how to post a public key on the server.

A typical entry in your authorized_keys file will have the form TYPE KEY COMMENT, such as: 

ssh-rsa AA32h[...]9xz jdoe@yavin.ece.msstate.edu

You can also restrict the use of a key to executing a single command: 

command="COMMAND",no-port-forwarding,no-agent-forwarding,
no-X11-forwarding,no-pty TYPE KEY COMMENT

So, if a user jdoe wanted to grant access to another user jschmoe, he would ask jschmoe for a public key (for which jschmoe has the matching private key). If, for example, jdoe's repository path is /home/jdoe/svn/sharedrepos, then he would add the following to his authorized_keys file (all on one line): 

command="svnserve -t -r /home/jdoe/svn --tunnel-user=jschmoe",
no-port-forward,no-agent-forwarding,no-X11-forwarding,
no-pty ssh-rsa AAphkn[...]4n9a jschmoe@yavin.ece.msstate.edu

During a normal Subversion connection over SSH, svnserve -t (for tunnel mode) would be invoked. This command adds the -r ReposRootPath option to specify a relative path to the repository. This is very important, as it will affect the URL used by jschmoe when he connects. Since /home/jdoe/svn will be his apparent root, his URL would be: 

svn+ssh://jdoe@svn.ece.msstate.edu/sharedrepos

Also, the --tunnel-user=username option has been invoked to identify the actual user (as opposed to jschmoe) who is authenticating with this key.

You can add similar entries for the rest of the members of your team.

Managing Authorization over Multiple Repositories

This scheme works fine in simple situations. But, what if jdoe is taking two classes where he has a group project and needs separate repositories? He might create two repositories: 

/home/jdoe/svn/dsd
/home/jdoe/svn/comparch

jdoe then adds entries in his authorized_keys file for all the members of his Digital Systems Design team, as well as all members of his Computer Architecture team. And for each user, the svnserve command is set up with -r /home/jdoe/svn.

The problem with this is that the members of jdoe's Digital System Design team can access his Computer Architecture team's repository, and vice versa. The answer to this is to use authorization files, which are basically just access lists.

For each repository:

Change into the conf/ directory in the repository. 

cd /home/jdoe/svn/dsd/conf

Edit the file svnserver.conf. Add or uncomment (do not leave a leading space) the following lines beneath [general] 

auth-access = write
authz-db = authz

Then, edit the file authz, adding a [/] line plus a user = rw line for each user you want to allow (this should match the username you specified in the --tunnel-user option. 

[/]
jschmoe = rw

Basic Management Tasks

The repository data is completely contained inside the repository directory, so same trivial file operations are easily performed.

Copying a Repository

Just copy all: 

cp -a path/to/repos some/path/with/copy/of/repos

Moving a Repository

You can easily move the repository as you would any other directory: 

mv path/to/repos new/path/to/repos

Or, similarly, rename the repository; 

mv repos/ comparch/

Deleting a Repository

Recursively delete a repository. Caution: This is not the same as deleting with Subversion's commands. This will kill the entire repository. 

rm -r repos

Or, if you don't want to be prompted a million times about whether to delete all the files, you can force the removal. Extreme Caution should be used with this command. It will not warn you before deleting a file. 

rm -rf repos

See Also

External Links

Retrieved from "http://www.ece.msstate.edu/wiki/index.php/Subversion_Repository_Administration"