Create an SVN (Subversion) Server on Linux (Debian / Ubuntu – Redhat / CentOS)

I use SVN a lot – for my personal knowledgebase that I maintain for myself, for my development projects, server configurations, and for my documents (oddly enough). I think it’s a little more thorough than just using a piece of backup software in that there is revision control – and that is the most important thing to me with some of these documents and development bits. For some reason I prefer SVN over git – I think it’s a little more mature and has had bit more time to develop – no doubt that git is a good platform, I just tend to prefer SVN.

In any event, I’ve found softwares for Windows that will run an SVN server, but I think it requires a lot less work to set up on Linux and it runs far more efficiently. Anyway, I’ll detail about how to get that set up and running here.

Let’s start with prerequisites (as usual): You’ll need a box (either virtual or not) with as much space as you think you’ll need. I would suggest at least 8 gigs if it’s a VM – and depending on the server that you use (if you’re using a full out CentOS 6.3 install with GUI, it might be prudent to double that to 16GB) – just make sure it’s practical. It does not need to be a dedicated server – at least not for this instance – we will be using a relatively obscure port dedicated to SVN (3690).

And as usual, you’ll need some form of root.

Alright – here we go.

First you’ll need to install really only one thing – and that is subversion.

Debian / Ubuntu

$ sudo apt-get install subversion

Redhat / CentOS – as root:

# yum install subversion

Once subversion is installed, now we need to create the actual repositories. I generally tend to make a directory solely for this purpose – usually in /var.

# mkdir /var/svn

Once we’ve create the main directory that will house our repositories, we need to go ahead and create the actual repositories. To do that, we issue this command:

# cd /var/svn
# svnadmin create repo_name

After we’ve created the repository, we need to make it accessible. I’m usually not too concerned about this being ultra private – generally I make these local only – as in available to the LAN only – so normally I just will create a password for the repository.

All the configuration files are held within the repository now – so lets say you did this:

# svnadmin create /var/svn/foo

Within the /var/svn/blah folder, there are now going to be a folder we are concerned with, and that is a folder called “conf”.

In the conf folder (which should be at /var/svn/foo/conf). In that folder are two files we are concerned with – one is called “passwd” and the other is “svnserve.conf”.

Let’s first edit “passwd”. The “passwd” file looks like this:

### This file is an example password file for svnserve.
### Its format is similar to that of svnserve.conf. As shown in the
### example below it contains one section labelled [users].
### The name and password for each user follow, one account per line.
 
[users]
# harry = harryssecret
# sally = sallyssecret

As you can see, a username and a password commented out. If you want to create a username and password for yourself and for other users, add some in here.

[users]
foo = bar
luke = skywalker
frodo = baggins
# harry = harryssecret
# sally = sallyssecret

Now we have some users set up.

Next we need to tell the SVN server that we want it to authenticate users, we need to edit “svnserve.conf”.

There are a few lines in here that are concerned with:

One is “# anon access = read”.
Another is “# auth-access = write”.
Another is “# password-db = passwd”.

The first, anon access = read means that anyone can read the repository, regardless of authentication. Meaning anyone can “read” your repository. They can’t edit it, but they can read it. In some cases, this is a big no no. Especially if you have sensitive config files that contain database passwords. You can change it to this:

anon access = none

This will make it so that they have to have a password to even read the repository.

The second is “auth access”. This means authorized access. I tend to keep this on “write”. If you have a username and password, you are probably actively working on the project.

And last, uncomment “password-db = passwd”. This just means that it will use the “passwd” file we previously set up to authenticate users.

Alright – now the repository is set up, the users are up and running. Make sure port 3960 is open.

Last – we need to edit / create a few files to make a service out of this. On CentOS / Redhat – this is already done, but on Ubuntu and Debian, this is not done.

For Debian / Ubuntu, I wrote a little start up script that can be stuck in init.d.

Do this:

# sudo nano /etc/init.d/svnserve

And paste this in (changing your SVN root directory of course):

#!/bin/sh
#
# start/stop subversion daemon.
#
# Let's set some variables first
# If we want more than one root svn path, we can set it here
#
SVN_ROOT_PATH="/var/svn/foo"
SVN_USER="root"
SVNSERVE="/usr/bin/svnserve"
#
# Let's make sure SVN is actually installed
#
test -f $SVNSERVE || 'echo "svnserve not found at $SVNSERVE"; exit 0'
#
# If we want more than one root path, we can set it here
#
OPTIONS="-d -r $SVN_ROOT_PATH"
#OPTIONS="-d -r $SVN_ROOT_PATH2"
#
# Alright - let's start the daemon
#
case "$1" in

start)
        echo "Starting subversion daemon: svnserve."
        start-stop-daemon -S -o -q -u $SVN_USER -c $SVN_USER -v -x $SVNSERVE -- $OPTIONS

;;

stop) 
        echo "Stopping subversion daemon: svnserve."
        start-stop-daemon -K -q -o -x $SVNSERVE

;;

reload) 

;;

force-reload)
        $0 restart
        
;;


restart)
        $0 stop
        $0 start

;;

*)
	echo "Usage: /etc/init.d/svnserve {start|stop|reload|restart}"
	exit 1
	
;;

esac

exit

Save and close. Now the SVN daemon starts on boot.

If we want to connect to your SVN repo, there are some handy utilities – For Windows you can use TortoiseSVN or Eclipse, for Linux you can use subversion on the command line (I’ll write another post here in the near future) or Eclipse as well.

Cron Daemon Email Spam

I had a Cron Job on one of our servers here just start spamming my email the week. It was basically a cron I set up every half hour to rotate some fast moving apache logs. Anyway, long story short, this cron just started emailing me every 30 minutes every time the job ran.

The easiest thing to do for a situation like this, is just to add to add > /dev/null 2>&1 to the end of your file in crontab (cron.d, cron.weekly, whatever).

5 0 * * * root /scripts/backup_test > /dev/null 2>&1

Of course, the better thing to do would be to find any issues in your email as it usually prints the output of the job. But in some cases, I don’t care. I set this script up to email me when it finishes successfully and if it doesn’t run, I get another email.

Web Server “Essential Services” Monitoring Script

A while back I wrote a script that I set as a cron (every 5 minutes) to monitor my web server (LAMP with mod_proxy / BIND). I was having trouble, specifically with BIND, with few or no logs (I changed this, but they were so non-descript that I had no idea why it was dying). Thankfully an update came out for it via repo that fixed that issue, but not before I’d written a script to do it for me. So I present, the Web Monitoring Script.

This was written for Debian, but a few easy modifications to your variables will have it working on CentOS / RedHat / Fedora.

Prerequisites – You need root to add this as a cron. You also need to create this folder “/var/log/server_monitor/”.

It would also be a good idea to do set up log rotation on those logs.

To do that, follow this (and use whatever text editor you like, my server doesn’t have a GUI, so I tend to use text based tools):

# cd /etc/logrotate.d
nano server_monitor

And add this to that file and save.

/var/log/server_monitor/*.log {
	weekly
	missingok
	rotate 5
	compress
	notifempty
	create 640 root adm
	sharedscripts
	postrotate
	endscript
}

Now your logs will rotate weekly and will be compressed.

Now on to the actual script:

#!/bin/bash
#
# This is a server monitor that will run every 5 minutes to be sure all services are running, and if they are not, to start them.
#
# Let's set some variables quick
############################################################
RESTARTAPACHE="/etc/init.d/apache2 restart"
RESTARTBIND="/etc/init.d/bind9 restart"
RESTARTMYSQL="/etc/init.d/mysql restart"
RESTARTXINETD="/etc/init.d/xinetd restart"
RESTARTQMAIL="/etc/init.d/qmail restart"
############################################################
############################################ Path to pgrep
PGREP="/usr/bin/pgrep"
############################################################
############################################ Program names
APACHE2="apache2"
BIND9="named"
MYSQL="mysql"
XINETD="xinetd"
QMAIL="qmail"
############################################################
########################################## Set the log file
LOG="/var/log/server_monitor/server_monitor.log"
SUCCESS=" was down and has restarted successfully at $(date)"
###########################################################
############################################### Set date
set $(date)
#
# Apache
#
$PGREP $APACHE2
if
	[ $? -ne 0 ] #This shows that apache is not running since there are no pids
then
	$RESTARTAPACHE
	echo "$APACHE2 $SUCCESS" >> $LOG
else
	echo "$APACHE2 is running fine at $(date)" >> $LOG
fi;
#
# Bind
#
$PGREP $BIND9
if
	[ $? -ne 0 ]
then
	$RESTARTBIND
	echo "$BIND9 $SUCCESS" >> $LOG
else
	echo "$BIND9 is running fine at $(date)" >> $LOG
fi;
#
# MySQL
#
$PGREP $MYSQL
if
	[ $? -ne 0 ]
then
	$RESTARTMYSQL
	echo "$MYSQL $SUCCESS" >> $LOG
else
	echo "$MYSQL is running fine at $(date)" >> $LOG
fi;
#
# Xinetd
#
if
	[ $? -ne 0 ]
then
	$RESTARTXINETD
	echo "$XINETD $SUCCESS" >> $LOG
else
	echo "$XINETD is running fine at $(date)" >> $LOG
fi;
#
# Qmail
#
if
	[ $? -ne 0 ]
then
	$RESTARTQMAIL
	echo "$QMAIL $SUCCESS" >> $LOG
else
	echo "$QMAIL is running fine at $(date)" >> $LOG
fi;

Then if you want it to run every 5 or so minutes (I have mine on every 5 minutes), just add it to crontab. It’s an extremely light script and uses basically zero system resources.

That will keep your server running pretty smooth. If you want to get an email notification when this happens, it’s also fairly easy to set up. It would also be a good idea to check the logs once in a while and make sure you’re not having too many service issues.