FSVS Installation on CentOS 6.2

(See prior posts on FSVS installation.)

The FSVS install tarball is available at fsvs.tigris.org.

I'm starting this time with a minimal CentOS 6.2 install.  No GUI installed, not much of anything.  As with all software installation from source packages, you should do this as a regular user on the box, not as the root user.

Download and compile FSVS

You might need to install "wget" first

$ sudo yum install wget

Now you can download and compile the FSVS package.  Note that you'll need to go through the above link for fsvs.tigris.org in order to find the actual download location.

$ cd /usr/local/src

$ sudo mkdir fsvs

$ sudo chown thomas:thomas fsvs

$ cd fsvs

$ wget http://download.fsvs-software.org/fsvs-1.2.4.tar.gz

$ tar xzf fsvs-1.2.4.tar.gz

$ cd fsvs-1.2.4

$ ./configure

Now, on a fresh CentOS 6.2 minimal install, you're going to have to install lots of extra things at this point.  Or you could compile it on another CentOS 6 box and copy it over.  But for our purposes, here is the list of all of the supplemental packages that you will have to install.  Note that the "subversino-devel" currently in the CentOS repositories is 1.6.11, which is not too far out of date.  In some cases, you may prefer to pull in 1.7 from RPMForge or somewhere else.

(Note that you could do all of these installations in a single "yum install" command.)

$ sudo yum install gcc make

$ sudo yum install subversion-devel

$ sudo yum install pcre-devel

$ sudo yum install gdbm-devel

$ sudo yum install openssh-clients

Once again, run the configure script and look for errors or missing dependencies.

$ ./configure

With no errors, we can now run the "make" command and then copy the "fsvs" executable to /usr/local/bin.

$ make

$ sudo cp src/fsvs /usr/local/bin/

$ sudo chmod 755 /usr/local/bin/fsvs

Setting up a repository on the SVN server

We'll assume that you have a SVN server elsewhere, where you want to store your system configuration and any files that you want to track.

This is how we setup users on our SVN server. Machine accounts are prefixed as "sys-" in front of the machine name. The SVN repository name matches the name of the machine. In general, only the machine account should have write access to the repository, although you may wish to add other users to the group so that they can gain read-only access.

# useradd -m sys-www-test
# passwd sys-www-test
# svnadmin create /var/svn/sys-www-test
# chmod -R 750 /var/svn/sys-www-test
# chmod -R g+s /var/svn/sys-www-test/db
# chown -R sys-www-test:sys-www-test /var/svn/sys-www-test

Setting up the SSH private/public key pair to talk to the SVN repository server

We'll need to create an SSH key that can be used on our SVN server. You may wish to use a slightly larger RSA key (3200 bits or 4096 bits) if you're working on an extra sensitive server. But a key size of 2048 bits should be secure for another decade for this purpose.

# cd /root/
# mkdir .ssh

# chcon -R -t ssh_home_t ~/.ssh
# chmod 700 .ssh
# cd .ssh
# /usr/bin/ssh-keygen -N '' -C 'svn key for root@hostname' -t rsa -b 2048 -f ~/.ssh/svn-fsvs-ssh-key
# chmod 600 *
# cat svn-fsvs-ssh-key.pub

Then configure a SSH config file to point at the proper port and identity file that you just created.

# vi /root/.ssh/config
Host svn.example.com
Port 22
User sys-www-test
IdentityFile /root/.ssh/svn-fsvs-ssh-key
# chmod 600 *

Back to the Subversion repository server

Back on the SVN server, you'll need to finish configuration of the user that will add files to the SVN repository.

# su username
$ cd ~/
$ mkdir .ssh
$ chmod 700 .ssh
$ cd .ssh
$ cat >> authorized_keys
(paste in the SSH key from the other server)
$ chmod 600 *

Now you'll want to prepend the following in front of the key line in the authorized_keys file.

command="/usr/bin/svnserve -t -r /var/svn",no-agent-forwarding,no-pty,no-port-forwarding,no-X11-forwarding

That ensures (mostly) that the key can only be used to run the svnserve command and that it can't be used to access a command shell on the SVN server. Test the configuration back on the original server by issuing the "svn info URL" command. Alternately, you can try to ssh to the SVN repository server. Errors will usually either be logged in /var/log/secure on the source server or in the same log file on the SVN repository server. Here's an example of a successful connection:

# ssh svn.example.com
( success ( 2 2 ( ) ( edit-pipeline svndiff1 absent-entries commit-revprops depth log-revprops partial-replay ) ) )

This shows that they key is running the "svnserve" command automatically.

Connect the system to the SVN repository

The very first command that you'll need to issue for FSVS is the "urls" (or "initialize") command. This tells FSVS what repository will be used to store the files.

# cd /
# mkdir /var/spool/fsvs
# mkdir /etc/fsvs/
# fsvs urls svn+ssh://svn.example.com/sys-www-test/

You may see the following error, which means you need to create the /var/spool/fsvs folder, then reissue the fsvs urls command.

stat() of waa-path "/var/spool/fsvs/" failed. Does your local WAA storage area exist?

The following error means that you forgot to create the /etc/fsvs/ folder.

Cannot write to the FSVS_CONF path "/etc/fsvs/".

Configure ignore patterns and doing the base check-in

When constructing ignore patterns, generally work on adding a few directories at a time to the SVN repository. Everyone has different directories that they won't want to version, so you'll need to tailor the following to match your configuration. However, I generally recommend starting with the following (this is the output from "fsvs ignore dump", which you can pipe into a file, edit, then pipe back into "fsvs ignore load"):

group:ignore,./bin/
group:ignore,./dev/
group:ignore,./etc/fsvs/
group:ignore,./etc/gconf/
group:ignore,./etc/gdm/
group:ignore,./home/
group:ignore,./lib/
group:ignore,./lib64/
group:ignore,./lost+found
group:ignore,./mnt/
group:ignore,./proc/
group:ignore,./sbin/
group:ignore,./selinux/
group:ignore,./srv/
group:ignore,./sys/
group:ignore,./tmp/
group:ignore,./usr/bin/
group:ignore,./usr/include/
group:ignore,./usr/kerberos/
group:ignore,./usr/lib/
group:ignore,./usr/lib64/
group:ignore,./usr/libexec/
group:ignore,./usr/local/share/man/
group:ignore,./usr/mail/
group:ignore,./usr/sbin/
group:ignore,./usr/share/
group:ignore,./usr/src/
group:ignore,./usr/tmp/
group:ignore,./usr/X11R6/
group:ignore,./var/cache/
group:ignore,./var/lib/clamav
group:ignore,./var/lib/mlocate/
group:ignore,./var/lib/ntp/
group:ignore,./var/lib/php/session
group:ignore,./var/lib/postfix/
group:ignore,/var/lib/rpm/
group:ignore,./var/lock/
group:ignore,./var/log/
group:ignore,./var/mail/
group:ignore,./var/opt/compaq/locks/
group:ignore,./var/run/
group:ignore,./var/spool/
group:ignore,./var/tmp/
group:ignore,./var/vmail

Then you'll either want to ignore (or encrypt) the SSH key files.

# cd /
# fsvs ignore group:ignore,./root/.ssh
# fsvs ignore group:ignore,./etc/ssh/shadow*
# fsvs ignore group:ignore,./etc/ssh/ssh_host_key
# fsvs ignore group:ignore,./etc/ssh/ssh_host_dsa_key
# fsvs ignore group:ignore,./etc/ssh/ssh_host_rsa_key

You can check what FSVS is going to version by using the "fsvs status pathname" command (such as "fsvs status /etc"). Once you are happy with the selection in a particular path, you can do the following command:

# fsvs ci -m "base check-in" /etc

Repeat this for the various top level trees until you have checked everything in. Then you should do one last check-in at the root level that catches anything you might have missed.