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.
As a side note, for the string 'svn+ssh://svn@svn.example.com/...', when
running TortoiseSVN, the svn.example.com can be the name of a saved profile from the Windows
based SSH program called Putty.