Setting up Subversion svnserve daemon on CentOS

When you want to host a Subversion repository on your CentOS (or RHEL) server, its quite annoying that the only options available to serve your repository are SSH (using the svn+ssh:// schema in the Subversion URLs – it is basically set up out of the box, not tweaking necessary) and Apache’s mod_dav_svn (using the http:// or https:// schema in the Subversion URLs – this is somewhat complex to setup but good instructions are easy to find on the web).

The main advantage of either of these methods is security: both have easy transport security (SSH by default, Apache if you set it to server over SSL) and are easy to setup authentication for (SSH authenticate against the system’s accounts using PAM and Apache authenticate against basically anything with a simple setup).

The main disadvantage of these methods are that they are slow (SSH is apparently somewhat faster then HTTP) and when supporting multiple large projects of many developers I started running into all kinds of weird connection errors when you try to manipulate many files on many projects at the same time.

Subversion itself offers another alternative using their own network service called svnserve – this is a standard unix daemon that listens on a specific port1 and uses a native protocol to communicate with Subversion clients (using the svn:// schema in Subversion URLs). It offers very good performance, but no transport security (encryption) by default. Another major problem with using svnserve as a network service is that while CentOS ships the binary itself (it is required as part of the way that the svn+ssh:// protocol is implemented) it doesn’t ship any support files to run it as a standalone service nor to help with its configuration. Also by default svnserve can only authenticate users using its own Apache-style password database file – which makes it unsuitable to integrate in large organizations.


  1. port 3690 by default []

For all the people who have waited patiently, CentOS 6 is here

After a long long time in the making, rumors of abandonment and general discomfort in the community, the CentOS people have finally pulled through and bring you the brand new (though by now several months old) CentOS 6.0.

A lot of system administrators have been waiting for this (me included) so I thought I’d give a heads up 🙂

Kohana 3 RHEL/CentOS RPMs

As I have not found any available, here is my build for Kohana – the PHP development framework – for RHEL 5 based operating systems.

You can find Kohana RPM for the current stable release 3.0.5 here, and the source RPM is available here in case you want to rebuild it yourself (and you might, details follow). New releases to correspond with new releases from Kohana will be updated there as needed.

This package is built on a CentOS 5.4 machine, with pretty much default settings.


How to build a chroot jail environment for CentOS

A chroot environment is simply a directory – inside which you can find a file system hierarchy exactly like your original operating system. You can then use the UNIX chroot command to open a shell in that directory so that command running under that shell see only the chroot environment and can’t mess up your system. This is very useful for many different reasons – for example if you want to build some software packages and you don’t want their build dependencies to pollute your real system.

Building a chroot environment is not difficult at all using the right tools, and YUM – the CentOS installation tool – has what you need.


Upgrading CentOS 5 to Fedora 12

Its time to update an old post about updates: Fedora 7 is again rather old, with the current Fedora being at 12, and 13 is right around the corner, but We’re still with CentOS 5 (I hear that RedHat is deep into beta with their next version – 6 but when it comes out is anyone’s guess).

In the mean time, if you want to run something a bit more modern maybe you’d want to upgrade your CentOS installation to Fedora 12 which can be considered pretty stable after a few months on the market. The reasons for the change may be numerous – maybe you need to run the latest subversion (with better merge tracking) or a new version of Ruby. Either way, if upgrading from CentOS 5 to Fedora 7 was a pain, guess how it is more the two years later?

Before we get to the action itself, I would be remiss if I would not recommend you to reconsider what you are about to do – this is a challenging exercise for many system admins and can sometimes end badly. I do not guarantee anything and if it breaks you get to keep both parts. Often its much faster and easier to just go to the server, stick a Fedora 12 DVD in the slot, reboot and let the DVD upgrade your system1. That being said, this is fun if you’re into that sort of thing, so if you’re still with me, lets dive in!


  1. another safer options would be to upgrade to Fedora 7 using the instruction in the previous article linked above, and then use Fedora’s preupgrade tool to upgrade to Fedora 8, then to fedora 10, and from there to Fedora 12, though this procedure will also require physical access to the machine and multiple reboots and multiple long downloads []

Spam prevention powered by Akismet