HOWTO: Setup SASL with SVN

Setup SASL2 with SVN

Sasl makes your passwords encrypted and also encrypts the connection between the SVN server and the client. Basically a good idea to setup for SVN servers on the internet. The example below is based on the linux install on a DS1511+ Synology NAS. In a previous article I describe how to setup SVN. Also one article is about how to use the post-commit triggers of SVN.

Now let’s start setting up SASL for SVN!
 
ipkg install cyrus-sasl
 
bash-3.2# cat svnserve.conf
[general]
anon-access = none
auth-access = write
# password-db = passwd
# authz-db = authz
realm = MyRealm
 
[sasl]
use-sasl = true
min-encryption = 128
max-encryption = 256

Use the same realm else it wont work!
Create users with saslpasswd2

saslpasswd2 -c -f /opt/etc/svnsasldb -u MyRealm <username>

Make it accessible and readable by the svnserve
chown svnowner:root svnsasldb

vi /opt/lib/sasl2/svn.conf
pwcheck_method: auxprop
auxprop_plugin: sasldb
mech_list: DIGEST-MD5
sasldb_path: /opt/etc/svnsasldb

That’s all!.

Beware that the svn on OSX 10.7 does not support DIGEST-MD5 + encryption. Eclipse however will do fine and so will a lot of other SVN software

 

HOWTO: Instant trigger Jenkins for a new build with a SVN post-commit (DS1511+)

Required Software and OS Installed:
– DSM version: 3.1
– wget
– Jenkins
– svn 

In my previous articles I described how to install SVN and how to install Jenkins on a Synology NAS DS1511+ ( or any other linux box ). This post will continue the setup of a development environment and will demonstrate how to create a post-commit SVN hook to trigger a build with Jenkins. 

Your project should be already setup in Jenkins. Pressing the “Build Now” button should checkout the sources from your Repository and build & test your sources. The next step is to automate the process that every commit in your repository should ignite a new incremental build in Jenkins. We now no longer need to poll the SCM anymore and Jenkins will only set to action if there is something to do.

A way to archive this, is using a feature from SVN called hooks. Subversion’s hook scripts provide a powerful and flexible way to associate actions with repository events. The only event that is interesting for Jenkins is the commit event which often mean that new code has been added or existing code has ben altered and It’s time to test the new build.

Installing the Script

The post-commit script can be downloaded here save it as post-commit inside your PATH_TO_REPOSITORY/hooks directory. Make it executable for the svnserve. 

 

DON’T COPY & PAST!

USE THE DOWNLOAD_LINK   

This below is for demonstration purposes only 
#!/bin/sh

#

# Jenkins SVN Build trigger script by Wessel de Roode Aug’ 2011

#

# Please adjust

SERVER=localhost                                                

PORT=8080       

WGET=/opt/bin/wget

SVNLOOK=/opt/bin/svnlook

# Don’t change below this point

###############################

REPOS=”$1″

REV=”$2″

UUID=`/opt/bin/svnlook uuid $REPOS`

echo “——————————————————-“>>${REPOS}/wget.log

#

# Check if “[X] Prevent Cross Site Request Forgery exploits” is activated

# so we can present a valid crum or a proper header

BREAD_URL=

‘http://’${SERVER}:${PORT}’/crumbIssuer/api/xml?xpath=concat(//crumbRequestField,”:”,//crumb)’

CRUMP=`$WGET –append-output=${REPOS}/wget.log –output-document – ${BREAD_URL}`

if [ “$CRUMP” == “” ]

then

HEADER=”Content-Type:text/plain;charset=UTF-8″

else

HEADER=$CRUMP

fi

$WGET

    –header ${HEADER}

    –post-data “`$SVNLOOK changed –revision $REV $REPOS`”

    –append-output=${REPOS}/wget.log  

    –output-document “-“

    –timeout=2

    http://${SERVER}:${PORT}/subversion/${UUID}/notifyCommit?rev=$REV 

# Debug line

echo $(date) HEADER=${HEADER} REPOS=$REPOS REV=$REV UUID=${UUID}
http://${SERVER}:${PORT}/subversion/${UUID}/notifyCommit?rev=$REV

>>${REPOS}/post-commit.log          

What does the script do?

 

1. It is executed by the svnserve daemon when the repository has an commit event
2. It connects to Jenkins and finds out if the install has “Cross Site Request protection” or not
3. It than posts to a Jenkins url that triggers a new build  

Testing the script can be done in the command line with two parameters. The first is the full file path to your repository, the second is the revision number to check out. an example is below where the path to the repository is /opt/svn/test and the revision number of 128:

./post-commit  /opt/svn/test 128

Now check Jenkins if it is building a new build of your project, and check the log files in your repository directory called:

wget.log containing the wget output which gives feedback about the two transactions
post-compile.log Contains the retrieved url and other variables used during the process

A successful triggered event should initiate a build in Jenkins and an shows output on the wget.log as follow:

 

Syno> cat wget.log 

——————————————————-

–2011-08-27 20:20:54–  http://localhost:8080/crumbIssuer/api/xml?xpath=concat(//crumbRequestField,%22:%22,//crumb)

Resolving localhost… 127.0.0.1

Connecting to localhost|127.0.0.1|:8080… connected.

HTTP request sent, awaiting response… 200 OK

Length: 39 [text/plain]

Saving to: `STDOUT’

–2011-08-27 20:20:54–  http://localhost:8080/subversion/168-96b-4949/notifyCommit?rev=60

Resolving localhost… 127.0.0.1

Connecting to localhost|127.0.0.1|:8080… connected.

HTTP request sent, awaiting response… 200 OK

Length: unspecified [text/html]

Saving to: `STDOUT’

NOTE

 

If the “[ ] Cross Site Request protection” is switched off, the first query will result in an 404 error as shown below:

 Syno> cat wget.log 

——————————————————-

–2011-08-27 21:12:08– http://localhost:8080/crumbIssuer/api/xml?xpath=concat(//crumbRequestField,%22:%22,//crumb)

Resolving localhost… 127.0.0.1

Connecting to localhost|127.0.0.1|:8080… connected.

HTTP request sent, awaiting response… 404 Not Found

2011-08-27 21:12:08 ERROR 404: Not Found.

–2011-08-27 21:12:08– http://localhost:8080/subversion/168-96b-4949/notifyCommit?rev=61 

Resolving localhost… 127.0.0.1 

Connecting to localhost|127.0.0.1|:8080… connected. 

HTTP request sent, awaiting response… 200 OK 

Length: unspecified [text/html] Saving to: `STDOUT’

This 404 Not Found Error is not a problem just part of the detection phase.

Happy Coding!

 

Useful links:

https://wiki.jenkins-ci.org/display/JENKINS/Subversion+Plugin

post-commit download

HOWTO: Setup a SVN Repository on a Synology NAS (DS1511+)

This document describes setting up a SVN repository on a DSM 3.1 that will be accessable tunneld through SSH like Eclips and Netbeans do.

 

 

Step 1, install SVN from the repository

Login on your NAS as root and run the following command to install SVN. We presume you already have the NAS boostraped ( read more about this in the forum of Synology )

ipkg install svn

Step 2, Setup svnowner user

Add the user svnowner to the /etc/passwd, /etc/shaddow and /etc/group files. I am using UID and GUID 146 for this, check if this ID is really free on your system, else use another UID and GUID

Update the passwd file:
vi /etc/passwd

Add the line:
svnowner:x:146:146:Subversion:/opt/svn:/bin/sh 

Update the shadow file:
vi /etc/shaddow

Add the line:
svnowner:*:10933:0:99999:7::: 

Update the group file:
vi /etc/group

Add the line:
svnowner:x:146:svn 

 

Step 3, Create the SVN root directory
mkdir /opt/svn
chown svnowner:svnowner /opt/svn

Step 4, Initialize the Repository
su – svnowner
svnadmin create –fs-type fsfs /opt/svn/repos

Recommended reading about SVN from the PDF Book below:
Chapter 5: Repository Administration 
http://svnbook.red-bean.com/en/1.6/svn-book.pdf

Step 5, Setup svnserve

Edit the /etc/services file 
su – root
vi /etc/services

and add the following two lines:
svn             3690/tcp                        # Subversion 
svn             3690/udp                        # Subversion            

Edit the /etc/inetd.conf file and add the svnserve
vi /etc/inetd.conf

Add the line
svn stream tcp nowait svnowner /opt/bin/svnserve svnserve -i -r /var/svn 

Restart the intetd with
kill -HUP inetd 

Step 6, Setup authentication
 

NeIn this setup we use the plain text authentication for the repository. It is usefull for a LAN, but not suitable for an internet connection since the communication is in plain text and unencrypted. In a new blog post I’ll cover how to setup an encrypted svn repository using SASL

 vi /opt/svn/repos/conf/passwd

Add your users under [users] the example will add a user joe with password doe
[users]
john = doe

Next we assign what the users can do. The following example will disable public access and allows the user john to perform write and read transactions

vi /opt/svn/repos/conf/svnserve.conf

 

[general]
anon-access = none
auth-access = write
realm = MyRepository
password-db = passwd

 

Step 7, Enjoy!
Go give it a try!

 

NOTE If this setup was to short, have a look at a very extended description at the wiki
http://forum.synology.com/wiki/index.php/Step-by-step_guide_to_installing_Subversion