Source control is critical for any software project lasting more than about one day. It is where you store all of your source code, and provides a complete history of all changes to the source code over time. This is essential as it allows easy reverts back to a known working version (when inevitably something gets broken), and allows the exact code at any point in time to be seen (very useful when trying to track down a bug in a prior release).

For some reason though, some software companies seem to think that they don't really need it. They try to get by with just leaving the code on the developers' machines. This is just a disaster waiting to happen, not to mention the difficulties involved in merging changes to the same files by multiple developers, or determining who actually has the most up to date version...

I have used 3 different source control products (four if you count just copying backup folders with the source code around - it works for a single developer, but is very difficult to administer). They are SourceSafe, CVS, and Subversion.

SourceSafe is fairly simple to use, and seems to be semi-popular among some Windows developers as it is bundled with Visual Studio, but has major limitations. Most notably, it does not support the concept of atomic commits. If you make changes to 10 different files that are all linked together, you cannot commit those 10 files at once. Instead you effectively do 10 separate commits. This makes it really easily to get the source control system into an inconsistent state.

So I now use Subversion exclusively, which is basically CVS with a large nunmber of the problems fixed.

Recently we just acquire a new subversion server for work, as the existing server was running Windows 2k Server (not the best server OS for this purpose), and Subversion 1.1. Subversion 1.1 stores all data to a Berkley DB repository which occassionally locks up, requiring an admin to reset - not too difficult, but annoying as it means your nightly builds stop working.

In addition, the server was not really a real server box - just a slightly beefed up workstation.

So, we got a nice new server with a SCSI hot-swapable raid array of drives for all the data. Suse 10.1 and Subversion 1.3 were installed, and then left to myself and one of the senior guys in my team to setup and import everything from the old server.

For security reasons, we decided that we really wanted to go with the svnserve+ssh method of access. Subversion supports multiple access methods. The first is a simple daemon process, called svnserve, that is a simple TCP listener. It works fairly well, but has very limited access control. While subversion 1.3 extends this a little, there is no way to link the security mechanism in with the existing authentication infrastructure at work (currently using ActiveDirectory).

The second option is Apache (a web server) running several custom modules. This does allow authentication using PAM, but we weren't too keen on leaving a web server running on the machine - or at least one that allowed changes to source control.

So, the final option is known as svnserve+ssh. In this mode, users accessing subversion connect and are authenticated using ssh (secure shell), and then invokve svnserve as a normal process to perform any necessary operations. Of course, this process is hidden from the user - they just connect as per normal but with a different URL. We could then integrate the SSH authentication with ActiveDirectory, so normal username and passwords could be used (and more importantly, accounts could be disabled globally).

It sounded fairly simple. But we should have been suspicious as the Subversion documentation is, shall we say, rather light here. In fact, it is actually pretty useless. The attitude seems to be that since SSH is performing that authentication, they don't need to bother talking about it at all...

We got SSH and ActiveDirectory integrated fairly easily, but this then allowed any domain user to open an SSH shell onto the subversion box - something not at all desirable. Even worse, since the launched svnserve process runs as the logged in user this meant that every user with commit access required write access to the repository.

Not at all good. Anyone with commit access could ssh into the machine and then delete the repository. Sure, we could create online backups, but it was definitely not a good idea.

So, after some hunting around we managed to change the default shell for all users connected over SSH, who had been authenticated via ActiveDirectory. Normally the shell is something like /bin/bash, which then allows the user to enter commands. We changed it to our own special shell, that prevented the user from doing anything over than launching svnserve (in fact, if it tried anything else we simply dropped the connection).

It worked great. Local users could still connect, but ActiveDirectory users could now only connect to perform subversion operations.

A few more changes involving setuid, and we no longer required write access to the repository.

We were left with two problems. Firstly, authorisation to specific paths in the repository could not be done with ActiveDirectory integration - we could only do this by manually updating the permissions. Annoying, but managable.

But then came the killer. Since subversion is not performing the authentication (ssh is), it never caches the user's password. Due to the way that subversion works, it invokes ssh several times per command. If I am browsing a repository, I could easily have to enter my password 20-30 times before I find what I want.

Obviously this was not acceptable.

However, we thought that surely someone has done this before.

Apparently not. SSH clients only seem to save passwords if you are using public/private key authentication.

But we can't use public/private keys, because we are integrating with ActiveDirectory. We have it working, but realistically, it is unusable.

So after all this, we have to go back to web access.

It would have been nice if subverison had a little more documentation about this. It is a great source control system, but somewhat lacking in that department.

Posted by Dave Bryant at 3:39 PM | Comments (0) | TrackBacks (1)