2007 May 31 - Thu

Setting Up and Working With a Remote Subversion Repository

I maintain a number of different servers, and work on a number of different projects. I'd like to put all of these things under some sort of version control. I chose Subversion as it has a good command line environment, has much access flexibility, and will work with Windows and Linux based files. I also wanted to secure the respository on a remote computer. At some time in the future, I may allow limited public access to portions of the repository. For now, I want to restrict access via ssh only. Also, at some later time, I may experiment with WebDav and such (which, if I read this stuff correctly, provides Subversion repository access through Windows Explorer).

Installing the software on Debian for a Subversion Repository is easy:

apt-get install subversion

To create a base repository directory for a number of servers would use a command like:

adduser svn
mkdir /home/svn
su - svn
mkdir -p /var/local/svn/servers

This adds a user named svn, and then uses that user account to create the Subversion directory and respository. This is needed so that appropriate file permissions are maintained for remote access users. I'll describe a technique of access where no additional user accounts are needed for the server in which the repository resides.

To create a repository for the various directories and files for server server01 (still using user svn):

svnadmin create /var/local/svn/servers/server01

Configuring everything for remote use is a more complicated scenario and uses a bunch of concepts I wrote about in my ssh article.

On the server to be put under version control, which, for this example, is server01, create a private/public key with:

ssh-keygen -t rsa -b 2048
mv ~/.ssh/id_rsa.pub ~/.ssh/server01.pub

On the repository computer, with the account svn, ssh to a computer somewhere in order to create the .ssh directory (if it hasn't already been created). Use SCP or a similar capability to get server01's ~/.ssh/server01.pub file into the /home/svn/.ssh directory of the repository computer. Append the file to authorized_keys:

cat server01.pub >> ~/.ssh/authorized_keys

Now edit the authorized_keys and insert the following in front of the line of the key that was just inserted:

command="/usr/bin/svnserve -t --tunnel-user=user1 \
-r /var/local/svn/servers/server01/"\
,no-port-forwarding,no-agent-forwarding,no-X11-forwarding,no-pty

You'll need to take out the line-ending slashes and put everything on one line, ssh doesn't appear to like line continuations in the authorized_keys file. You should have a format like:

command="stuff",sshsettings ssh-rsa onelongkey admin@server01

The '-t' in the command tells svnserve that commands are coming in from an ssh tunnel. The --tunnel-user parameter gives Subversion a username with which it may tag repository changes. The name has nothing to do with any authentication or authorization. As such, it should be changed to reflect an appropriately descriptive name for each public key in the authorized_keys file. The '-r' command provides a 'root' location for the Subversion client to use for new projects and directories. The remaining commands tell ssh to enhance the security of the connection by disabling certain ssh forwarding capabilities.

Back on server01, start up a new Bash session with:

ssh-agent sh -c 'ssh-add < /dev/null && bash'

This loads your private key for automated use in subsequent Subversion interactions.

Now to maintain version history of seleected files in server01's /etc directory:

svn mkdir svn+ssh://svn@svn.example.com/server01/etc
cd /etc
svn co svn+ssh://svn@svn.example.com/server01/etc .
svn status
svn add hosts -m "added hosts to repository"
svn commit

The first line creates an empty directory in the repository. After changing into the /etc directory, the svn diretory is then checked out. By doing a status, you'll see all the files have a '?', as unknown. Files can then be added and committed as needed.

The inspiration for the 'mkdir' command came from the second example in the TLUG Wiki HowTo. The Wiki does make a valid point about not maintaining permissions by default, and does offer up a script that saves these as Subversion properties.

[/OpenSource/Debian] permanent link