As a follow-up to my popular post on how to setup Subversion with SASL authentication against an Active Directory Windows Server, I’ve decided to push this further and share how I manage a high number of repositories with SVN on Linux. There are many different solutions for achieving that, everyone has their own custom solution for doing so. Mine was developed after trying some different tools and choosing the ones that did exactly what I wanted. I also had to speak with the management of the development to have their approval for putting in place a standardized way on how to manage the repositories by the leader of each development team. So that solution had some technical setup to do but it was mostly a political challenge because I was now sharing the administration of the repositories with different people. I empowered them with the tools and the rights to create and manage their own repositories. The final result of this was, of course, to have more security and more options for managing all the different projects under Subversion and less job for me. Hooray!

I have to admit, I’m lazy… And I don’t like spending my time repeating the same tedious task. So I’ve spend some time trying a couple of different tools that will help me and also give power to the dev team for managing their own repository. Let me start by describing you what kind of environment I often have to face with organization that use Subversion. Let say that in your development environment you have a couple of different projects running at the same time, all of which have their own unique repository and dev team. Also let’s say that the projects have usually, a very short dev time and that new projects (and new repositories) are created often. All the repositories could be managed under one big powerful server or they could be spread out among different servers. Or all the project could also be located under one repository. Some might have security access defined with their authz file and other don’t. You understand, you could have a setup that is small and well organized or something that is big and is a complete mess. Whatever the case may be, it’s all possible to make it easier to manage all of this, as long that you are backed up by the management for doing so.

Where do we start from there? You have Subversion running properly, you have put in place some kind of authentication mechanism to make sure that the repository/ies have at least a minimum of security to it. What more can be done after that? The first thing I would check is if you are using a centralized way for managing the authz file for your repositories. Do you have multiples repositories and each of them all use their own authz file for configuring the access? If so it is possible to centralize all the configuration and access to simply one svnserve.conf and authz file. The requisite, tough, are that from now on, all the different repositories will have the same configuration file with the same authentication mechanism. The simple way for doing so is to edit the service configuration file that is located here : /etc/sysconfig/svnserve (if you are using CentOS). Here’s an example of what it could contain :

OPTIONS="--root /svn --config-file /etc/svnserve/svnserve.conf --log-file /var/log/svn.log"

So when the svnserve service start the following options are passed to it. The first option is the root folder that contains all the different repositories. If you have many of them located on different servers or NAS on your network, this path could be centralized with a simple network sharing solution like NFS of Samba/DFS, it’s up to you, but you will need to spend some time for finding the right way to do it (with security in mind also). Now that all your repositories are located under the same folder, the next option, --config-file,  is to tell svnserve to look for the configuration file for all the repo under one folder that is given as a path. In that folder, you will put the authz, passwd (if you use it, not in my case since the authentication is done with Active Directory) and the svnserve.conf file. Also noteworthy, since Subversion version 1.8, you can put these configuration files (with the hooks file) in their own unique repository! So any changes made to it could be reversed. I would highly suggest doing so in an environment where there would be a lot of different team leader managing all repositories. Human mistakes/accidents/errors happen so often. The last option is simply for setting up a log for the SVN service, you would normally only use it to troubleshoot SVN in case of problems, you don’t even need that option, it’s up to you if you want to use it or not.

Now that you have centralized your repositories and your config files, you simply need to edit the access path in your authz file. You will need from now on, to define each project under it’s own section. For the sake of clarity, let continue with an example; you have project A, project B and project C. the 3 of those have their own unique repository and their own dev team. The security access to these repo could be really simple. Like all the users from every projects have read and write access. This is almost like, no security at all. The better way would be to define 3 different groups in the authz file with each group having their proper member. Then inside the authz file again, you can define that each project has their own access. Here’s an example what you could find in the authz file :

[groups]
TeamA = Bob, Roger, Bill
TeamB = Rick, William, Patrick
TeamC = Ashley, Eric, Frank

# SVN url for this project would be :
# svn://svnserver/ProjectA
[ProjectA:/]
@TeamA = rw

# svn://svnserver/ProjectB
[ProjectB:/]
@TeamB = r
[ProjectB:/Trunk0]
Rick = rw
[ProjectB:/branch1]
@TeamB = r
William = rw
[ProjectB:/branch2]
@TeamB = r
Patrick = rw

# svn://svnserver/ProjectC
[ProjectC:/]
@TeamC = rw
@TeamA = r

So in project A, everyone from TeamA can read and write wherever they want in the repo of Project A only. Project B has some special need and is a little bit more secure. All members of the TeamB can read everywhere in the repo of Project B. Rick is the leader of that project and he’s the only one who can write in the Trunk of the project. The 2 others members, William and Patrick have each their own branch and can write to their own folder. For Project C, the teamC has read and write to their own project and sometimes, teamA need to get the code from that project to integrate with their own project, that’s why they can read this repo. Everything make senses so far? I hope so. Now let’s push that scenario further and imagine that you would have 100 of these kind of projects. Would you spend your time configuring the access that each team would ask of you? Would you give some way to each team leader to be able to write inside the text file by themselves (and adding human errors in the lot)? This would be too much time consuming and you cannot trust the human condition that we always make mistakes. You need to give them the tools to do it and to remove the human error.

That’s why you now need to use a tool for the administration of SVN. The best would be a web based tool, that way, no client software to install. I’ve tried 3 different one and the one I’m now using is iF.SVNAdmin. For me it’s the best so far because : it support AD/LDAP authentication and management. I can create new repositories with it and I can give power to specific users (team leader) to manage the SVN access in the authz file and other specific need. All inside a webpage only, with no software to install on their side. For running a web page of iF.SVNAdmin, you need a working web server and PHP version 5.3 at minimum. I created a virtual host configuration inside apache with an internal DNS name for the webpage. Really easier for the users to access it. Here’s my config :

NameVirtualHost ipaddress:80
<VirtualHost ipaddress:80>
ServerName svnadmin.internaldomain.local
DocumentRoot /var/www/html/SVNAdmin
DirectoryIndex index.php
ErrorLog /var/log/httpd/svnadmin_error_log
CustomLog /var/log/httpd/svnadmin_access_log combined
</VirtualHost>


For the complete installation process, i really suggest you read the documentation located here. It’s quite simple, if you ever have configured a web page, it should be easy. Once it’s done, when you access the web page of iF.SVNAdmin for the time you should be greeted with the backend page for setting up the access of iF.SVNAdmins to the repositories. If you, like me, are using Active Directory for the users creation, you should follow these 2 screenshots with the proper field configured for your environment.

The first field/line is simply the path of where you have located your central SVN configuration file. The next part is more interresting. Called the “Data providers” These will let you choose how you will manage your users and groups creations with SVN. In my case, since I’m using Active directory for the users the “User view provider type” has been set up to “ldap” but then, the second choice after that, “User edit” cannot be selected and will turn off automatically. It’s for the simple reason that by choosing the LDAP provider, I must create the new users for SVN directly inside the AD/LDAP environment. I am not using the passwd file for doing so. The next 2 choices, is the same idea, for but groups only. Now, in this part, I could also manage the SVN access by groups that are created inside the AD/LDAP database. But I don’t want that because then, the team leader will always contact and ask me to create, manage and update the SVN security group. I don’t want to do that, I’m lazy and beside, I’ve got better things to do, like drinking beers. I prefer instead to use the groups created inside the authz file, hence, giving the option/power to the team leader for managing by themselves the security groups for SVN only. The last 2 choices are if I want to enable the repository view inside the tool or not. I recommend to enable it. The next section goes without comment, it’s simple a matter of pointing to the web tool where all of your repositories are located and making sure that the path for your svn and svnadmin binaries on the server is ok for repositories creation through the web interface.

The last section is important if your are using AD/LDAP. You have to populate the fields properly for making sure that the connection to the AD/LDAP with authentication is working properly. Lucky bastard, you  even have a test button beside each section to make sure that your configuration is working properly. Just like the SASL + AD authentication, you need a user from the AD to be able to bind in order to make any query to the AD. You will then need to point where are your users located in the AD, this configuration is using the default layout OU for Active Directory. After all of that is done properly, simple click the button “Save configuration”.

There, you should have it, the most important tool that will help you manage a, way too big, list of repositories in your organization. The “Repositories” menu will let you browse the different repositories and also, will let you create new one. By browsing the repositories, you can easily add access path for defining the security access to it. If not, you can do it from the menu itself. Under the menu of “Users” you should be able to “List” all of them and then, you can select the one you would like assigning specific role.There are 8 different type of roles for working with if.SVNAdmin. Once you have assigned the proper role you want to a user, you will then give him the url of the webpage and he will be able to login with his own user of SVN or AD/LDAP depending of what you are using. From that point he will be able to do whatever access you gave him. The “Groups” menu will let you create and manage the groups access to the repositories and the “Access-Paths” menu will let you create the path for all the different repositories and managing the access to it. If you are using the AD/LDAP connection, you will have an additional menu titled “Update”. From there you can force iF.SVNAdmin to read the users (and groups) from your AD/LDAP because the result of the query is put in cache and is not in real time. So if you have created a new user in your AD and it’s still not listed under the “Users” menu list, you can then force the application to refresh its users list from there. The rest is a matter of trying, testing and discovering how iF.SVNAdmin works.

But before we finish, let’s put some icing on that cake with that. iF.SVNAdmin also support the use of web based repo browser like either ViewVC or WebSVN. In my case I use WebSVN so I’ll add it to the installation to give another tool for the users. They usually use either TortoiseSVN on Windows or Version on Mac OS X but sometimes, having a web based repo browser is handy. More so when you are using the computer in the conference room during a meeting and it doesn’t have any SVN client installed. The web based repo browser is a quick tool to use. Installing WebSVN is a simple matter, again, of creating a webpage on your server. In my case I’ve created another DNS entry called svn so that we might access it using the url of http://svn.internaldomain.local. Now the trick is that by default, if you just configure quickly WebSVN, you might have access to all the different repositories but without any authentication at all. This is a big problem since it’s defeating the main reason of everything we did so far, having a good security system in place. Fortunately, there is an option for keeping all of that in WebSVN, the trick is to create a web page with apache that will also check for your AD/LDAP authentication with accessing the page of svn. Here’s a copy of my apache configuration file that I named websvn.conf :

NameVirtualHost ipaddress:80
<VirtualHost ipaddress:80>
ServerName svn.internaldomain.local
DocumentRoot /usr/share/websvn
DirectoryIndex index.php
<Directory /usr/share/websvn/>
AuthBasicProvider ldap
AuthType Basic
AuthzLDAPAuthoritative off
AuthName "Subversion Repository Web Browsing"
AuthLDAPURL "ldap://adserver.domain.local/CN=Users,DC=domain,DC=local?sAMAccountName?sub?(objectClass=*)"
AuthLDAPBindDN "ldapbind@domain.local"
AuthLDAPBindPassword "password"
require valid-user
Options MultiViews
order deny,allow
deny from all
allow from ipsubnet/24
</Directory>
</VirtualHost>

Again you need a user for binding your apache authentication system to your Active Directory. Once this is done, we need to configure the include/config.php file in the folder of the WebSVN application. We are looking for the following 2 lines in it that should not be commented anymore :

$config->parentPath('/svn');
$config->useAuthenticationFile('/etc/svnserve/authz');

First line is simply the path of where all your repositories are centralized. The second line is the main authz file for accessing the repo. And there you go. You should now be able to browse the repositories without sacrificing all the security you put in place from the beginning. I hope that this will help you save some times in the future and will make your users happy using this system. Feel free to drop your comments and feedback about this setup.