SLUG_Wiki: Subversion

Installing the Subversion Version Control System From Source

The Subversion version control system relies on a recent version of the Apache webserver and a recent version of the Berkeley DB version 4.

You should also have a recent version of OpenSSL, which is linked into Apache. This will probably be a good time to install the latest OpenSSH as well, since OpenSSH links in the OpenSSL library.

Get the Berkeley DB from: http://www.sleepycat.com

Get the latest 2.0.NN Apache webserver at: http://www.apache.org

Get Subversion here: http://subversion.tigris.org

Get OpenSSL from: http://www.openssl.org

Get OpenSSH from: http://www.openssh.org

Build in this order (so Apache gets OpenSSL and the Berkeley DB):

 # we go a little crazy here to get the OpenSSL with  RFC 3820 X.509 support

 tar xzf openssl-r-0.9.7-stable-SNAP-20050315.tar.gz

 # oh look, OpenSSL uses some lame Perl based config thing. man, I hate that.

 ./config --prefix=/usr/local shared
 make
 make install

 tar xzf openssh-4.0p1.tar.gz
 ./configure --prefix=/usr/local --with-tcp-wrappers
 make
 make install

 tar xzf db-4.3.27.tar.gz
 cd db-4.3.27/build_unix
 ../dist/configure --prefix=/usr/local
 make
 make install
 ldconfig # NOT on Solaris!

 #  Add the apache user to /etc/passwd:

     echo apache:x:80:80:apache:/: >> /etc/passwd

 #  Create the group apache:

     echo apache::80:apache >> /etc/groups

     ./configure --prefix=/apache/apache-2.0.53 \
                 --enable-mods-shared=all \
                 --enable-ssl \
                 --enable-suexec \
                 --with-suexec-caller=apache
     make
     make install

 tar xjf subversion-1.1.3.tar.bz2
 cd subversion-1.1.3
 ./autogen.sh
 # configuring subversion is not trivial!!
 # you need to pay CLOSE attention to the
 # output from configure
 ./configure --prefix=/usr/local \
             --with-apxs=/apache/apache-2.0.53/bin/apxs \
             --with-openssl \
             --with-ssl
 make
 make install

Example of a configure line used for a local install on a system with an additional Apache in the path:

./configure --prefix=/home/pehrens/usr/local/stow/subversion-1.1.3 \

         --with-apxs=/home/pehrens/usr/local/apache-2.0.53/bin/apxs \
         --with-apr=/home/pehrens/usr/local/apache-2.0.53 \
         --with-apr-util=/home/pehrens/usr/local/apache-2.0.53/bin \
         --with-openssl \
         --with-ssl

Note that the Subversion install will modify your Apache httpd.conf file, adding two lines that load the Subversion modules (which are also copied into the /modules directory of your Apache installation).

Creating a Subversion Repository and Configuring Apache

Let's say you want your repository to be in /usr/local/apache/htdocs/svn/repository, create the directory, and type in this command:

 svnadmin create /usr/local/apache/htdocs/svn/repository

Now make sure that httpd can access all the files in the repository:

 chown -R apache.apache /usr/local/apache/htdocs/svn/repository
 chmod g+s /usr/local/apache/htdocs/svn/repository/db

The chmod means that were you to access the repository as a user other than apache there is a fighting chance that the apache httpd server will still be able to access the database files.

Configure Apache

You will need to add a section to your ssl.conf file that looks like this:

# The following two lines are outside of the Location
# block and the internal ones are commented out because
# of a bizarre bug that causes certificates to be rejected
# FOREVER after the ssl_cache times out on them. Scary.
SSLVerifyClient require
SSLVerifyDepth 10
<Location /svn>
   DAV svn
   SVNParentPath /usr/local/apache-2.0.53/svn
   
   # Fancy, fancy
   SVNIndexXSLT "/svnindex.xsl" 
   
   # Limit WRITE permission to list of valid users.
   <LimitExcept GET PROPFIND OPTIONS REPORT>

   #   Client Authentication (Type):
   #   Client certificate verification type and depth.  Types are
   #   none, optional, require and optional_no_ca.  Depth is a
   #   number which specifies how deeply to verify the certificate
   #   issuer chain before deciding the certificate is not valid.
   #
   #   "optional" makes it visible generally...
   #
   #SSLVerifyClient require
   
   # SSLVerifyDepth must be >= the number of CA certificates in your
   # SSLCACertificateFile.
   #SSLVerifyDepth  10

   # This actually is what makes everything work!!
   SSLOptions +FakeBasicAuth

   AuthType Basic
   AuthName "Subversion Repository"
   AuthUserFile /usr/local/apache-2.0.53/conf/subversion.passwords
   Require valid-user
   </LimitExcept>
</Location>

The next time you start Apache, the Subversion server should be running. Point your browser at https://localhost/svn/repository and you should see something like this:

 Revision 0: /

 Powered by Subversion version 1.1.3 (r12730).

Securing Your Server

Create the passwords file:

 mkdir /etc/httpd/passwd
 htpasswd -c /etc/httpd/passwd/passwords username password

You don't have to put the password file at this location, change the paths if you would prefer to store it somewhere else. The -c flag creates a new file, to add more users leave out the -c.

If you are using client certificate challenge authentication each user must provide the Subject: line from the output of following command to the administrator of the subversion repository:

 grid-cert-info -f usercert.pem

The content of that line will be reformatted for use in the password file. The format required by the password file looks like:

 /DC=org/DC=doegrids/OU=People/CN=Joe User 3639:xxj31ZMTZzkVA

Where the code xxj31ZMTZzkVA is an Apache internal flag that is the same for all users and all installations.

Now if you visit the URL http://localhost/svn/repos you should be prompted for your user name and password.

That's it, you now have a fully functional Subversion server.

Apache SSL and Certificate authentication document:

This is the document that describes in detail how to configure Apache to make use of SSL and certificates in a variety of configurations.

http://httpd.apache.org/docs-2.0/ssl/ssl_howto.html

DOE Grid Certificate Authority Homepage:

https://pki1.doegrids.org/

Certificate Creation using OpenSSL

In order to make use of certificates, a passphrase-less private key file should be generated.

First, cd to ~/.ssh

Then generate a passphrase-less RSA key:

 openssl genrsa -out privkey.pem 2048

Or, to generate a passphrase-less DSA key run the following two commands, which create a privkey.pem file with a DSA key instead of an RSA key (this will take a relatively long time, but it spits out a load of rubbish to let you know it is still churning):

 openssl dsaparam -out dsaparam.pem 2048
 openssl gendsa -out privkey.pem dsaparam.pem

Alternately, you can force the use of a passphrase even when using certificates by adding the option -des3. This is certainly more secure, but most people feel the point of using certificates is to avoid login challenges. IMHO, certificates are minimally secure for online transactions (note that they do not stop somebody ELSE from pretending to be YOU... but a password that is only in your head DOES), but password challenge authentication is better. Combining the two is probably better to the degree that it is somewhat more difficult to implement ;^)

You can now generate a certificate request (CSR) that can be sent to a certification authority (who will use it to generate a certificate for you):

 openssl req -outform CSR -new -key privkey.pem -out cert.csr

Or you can generate a self-signed certificate (and maybe setup a certification authority of your very own!) (1095 days is three years):

 openssl req -new -x509 -key privkey.pem -out cacert.pem -days 1095

Sometimes it is necessary to convert a certificate to DER form, i.e. to get Internet Explorer to accept it:

 openssl x509 -in cacert.pem -outform DER -out cacert.der

Converting Digital Certificate Formats Using OpenSSL?

(Adapted from: http://epic.lesc.ic.ac.uk/ConvertingCertificates.html)

Most browsers use PKCS format, while Globus uses PEM format. You may need to switch your certificate format. This page is intended to give you some basic information, which covers most cases. However, you should consult openssl, Globus or your browser's own documentation for specific details.

For Globus, you usually have usercert.pem and userkey.pem in your ~/.globus directory:

    [user@machine ~/.globus]% ls -l
     -r--r--r-    1 user    group      2309 Nov 21 15:34 usercert.pem
     -r-          1 user    group      2036 Nov 21 19:09 userkey.pem

Loading the PKCS format certificate into your browser

In Firefox: Edit -> Preferences -> Advanced -> Certificates -> Manage Certificates, click on the Import button to select your .p12 file.

Converting Globus certificate (PEM format) to Browser certificate (PKCS format)

Create a .p12 file from userkey.pem and usercert.pem files:

 openssl pkcs12 -export -out user.p12 \
 -inkey userkey.pem -in usercert.pem

Same, including CA metadata:

 openssl pkcs12 -export -out user.p12 \
 -inkey userkey.pem -in usercert.pem \
 -CAfile /etc/grid-security/certificates/xxxxx.0 -des3

A pkcs12 version of a given pem file with some metadata:

 openssl pkcs12 -export -in file.pem -out file.p12 -name "My Certificate"

Even more metadata:

 openssl pkcs12 -export -in file.pem -out file.p12 \
 -name "My Certificate" - certfile othercerts.pem

Converting Browser certificate (PKCS format) to Globus certificate (PEM format):

Certificate and key pair from p12 file, for use with Globus:

 openssl pkcs12 -in export.p12 -clcerts -nokeys -out usercert.pem
 openssl pkcs12 -in export.p12 -nocerts -out userkey.pem

Passphrase-less certificate and key pair, with unencrypted private key - for host certs:

 openssl pkcs12 -in export.p12 -out hostcert.pem -nodes -nokeys
 openssl pkcs12 -in export.p12 -out hostkey.pem -nodes -nocerts

Relevant OpenSSL documents:

Using Subversion:

There is a complete online reference for Subversion available at http://svnbook.red-bean.com/en/1.1/index.html

The output from svn help:

 usage: svn <subcommand> [options] [args]
 Type "svn help <subcommand>" for help on a specific subcommand.

 Most subcommands take file and/or directory arguments, recursing
 on the directories.  If no arguments are supplied to such a
 command, it will recurse on the current directory (inclusive) by
 default.

 Available subcommands:
    add
    blame (praise, annotate, ann) ?? really ??
    cat
    checkout (co)
    cleanup
    commit   (ci)
    copy     (cp)
    delete   (del, remove, rm)
    diff     (di)
    export
    help     (?, h)
    import
    info
    list     (ls)
    log
    merge
    mkdir
    move     (mv, rename, ren)
    propdel  (pdel, pd)
    propedit (pedit, pe)
    propget  (pget, pg)
    proplist (plist, pl)
    propset  (pset, ps)
    resolved
    revert
    status (stat, st)
    switch (sw)
    update (up)

Example successful certificate authenticated user session:

 dilcue@abdera ~/cluster-tools:>>svn commit foo
 Authentication realm: https://foo.bar.edu:8080
 Client certificate filename: /home/dilcue/.globus/usercert.p12
 Passphrase for '/home/dilcue/.globus/usercert.p12': 
 Error validating server certificate for 'https://foo.bar.edu:8080':
  - The certificate is not issued by a trusted authority. Use the
   fingerprint to validate the certificate manually!

Certificate information:

 - Hostname: foo.bar.edu
  - Valid: from Apr  1 00:57:23 2005 GMT until Apr  1 00:57:23 2006 GMT
  - Issuer: Certificate Authorities, DOEAphids, org
  - Fingerprint: 15:4c:11:c2:41:01:2c:2e:12:7c:68:ad:25:5c:65:79:fd:28:05:e5
 (R)eject, accept (t)emporarily or accept (p)ermanently? t
 Adding         foo
 Transmitting file data .
 Committed revision 16.

Enter p at the prompt to have your subversion client cache the DOE cert and avoid this challenge for the future.

The amount of prompting at the svn command line can be minimised by editing the file ~/.subversion/servers to include the lines:

 [global]
 ssl-client-cert-file = /home/user/.globus/usercert.p12
 ssl-client-cert-password = "this should be passphrase not password"

However my svn client seems to not make use of the ssl-client-cert-password option at all, and always prompts.

 This is because Subversion does not like spaces in client passwords.