We used to use Collabnet SVN/Apache combo on a Windows server with LDAP authentication, and whilst the performance wasn't brilliant it used to work perfectly.

After switching to a fresh Ubuntu 10 install, and setting up an Apache/SVN/LDAP configuration, we have HTTPS access to our repositories, using Active Directory authentication via LDAP.

We're now having a very peculiar issue. Whenever a new user accesses a repository, our SVN clients (we have a few depending on the tool, but for arguments sake, let's stick to Tortoise SVN) report "Error 500 - Unknown Response". To get around this, we have to log into the repo using a web browser and navigate 'backwards' until it works


  1. SVN Checkout https://svn.example.local/SVN/MyRepo/MyModule/ - Error 500 (bad)
  2. Webbrowse to https://svn.example.local/SVN/MyRepo/MyModule/ - Error 500 (bad)
  3. Webbrowse to https://svn.example.local/SVN/MyRepo/ - Error 500 (bad)
  4. Webbrowse to https://svn.example.local/SVN/ - Forbidden 403 (correct)
  5. Webbrowse to https://svn.example.local/SVN/MyRepo/ - OK 200 (correct)
  6. SVN Checkout https://svn.example.local/SVN/MyRepo/MyModule/ - Error 500 (bad)
  7. Webbrowse to https://svn.example.local/SVN/MyRepo/MyModule/ - OK 200 (correct)
  8. SVN Checkout https://svn.example.local/SVN/MyRepo/MyModule/ - OK 200 (correct)

It seems to require authentication up the tree, starting from the svnparentpath up through to the module required.

Has anyone seen anything like this before? Any ideas on where to start before I ditch it back to Collabnet's SVN server?


Using Apache2, Here is the /svn location from my httpd.conf:

<Location /svn>
  DAV svn
  SVNParentPath /var/lib/svn
  AuthName "Subversion Repositories"
  AuthType Basic
  AuthBasicProvider ldap
  AuthzLDAPAuthoritative off
  AuthLDAPURL "ldap://dc1.domain.local:389/DC=domain,DC=local?sAMAccountName?sub?(objectClass=*)" NONE
  AuthLDAPBindDN "domain\apacheaccount"
  AuthLDAPBindPassword superawesomepassword
  require valid-user

The only errors in /var/logs/apache2/error.log are legitimate authentication errors from when I've used the wrong password. In the access.log, an Error 500 line looks like: - fname.sname [11/May/2010:08:39:08 +1000] "OPTIONS /svn/MyRepo HTTP/1.1" 500 634 "-" "SVN/1.6.6 (r40053) neon/0.28.6"
  • In case you're wondering why we made the switch, we decomissioned our physical SVN server (the Windows one) and switched it to a VM. Windows has a very large footprint if all you're doing is serving SVN, which is why we switched to Ubuntu. – Mark Henderson May 10 '10 at 4:47
  • This is very similar to my setup at work. I can get to it in the morning and poke around. I am wondering if you are having AD authentication issues. – Avery Payne May 10 '10 at 4:56
  • @Avery, thanks. When we were running the Collabnet server I copied the location directives straight from one httpd.conf to the other, and it worked perfectly on the old server. Maybe something's different with the *nix LDAP authentication... – Mark Henderson May 10 '10 at 4:59
  • What is showing up in the apache error log when an Error 500 is returned? – Zoredache May 10 '10 at 7:00
  • Are you sure you don't have a case sensitivity issue. Your examples use /SVN/ but your config /svn/. Subversion is case sensitive even though clients try to hide this on the Windows and MAC platforms. – Bert Huijben May 12 '10 at 12:54

I'm using a Debian "Lenny" setup, running Apache2/SVN with LDAP being authenticated through Apache directly to AD, while also hosting a Trac site on the same machine. I'll take a stab at it, but I need some more info...

The SVN access is the built-in module through Apache, so the first question I have is - are you running this as the SVN stand-alone process, or through Apache (it appears to be Apache but I just want to be sure)? The second question is, are you using Apache2 or Apache (1.x)? The third question is, do you use LDAP authentication through PAM, or through Apache's built-in support?

Just for reference, here's a (sanitized) version of the config for Trac, along with the LDAP settings that authenticate through AD (yes, it's open to anyone because Trac has its own permissions system that on my setup defaults to read-only for authenticated users):

#Rudimentary Apache2 authentication for Active Directory (without group controls)
<Location /trac>
  SetHandler mod_python
  PythonInterpreter main_interpreter
  PythonHandler trac.web.modpython_frontend
  PythonOption TracEnvParentDir /srv/trac
  PythonDebug on
  Order deny,allow
  Deny from all
  Allow from
  AuthType Basic
  AuthName "Trac Projects"
  AuthBasicProvider "ldap"
  AuthLDAPURL "ldap://enterprise-dc.mycompany.com:3268/DC=localsite,DC=mycompany,DC=com?sAMAccountName?sub?(objectClass=user)"
  AuthLDAPBindDN       apache-account@local-site.mycompany.com
  AuthLDAPBindPassword "supersecretpasswordthatnoonewillguess"
  authzldapauthoritative On
  require valid-user
  # require ldap-group "CN=Users,DC=local-site,DC=mycompany,DC=com"

More importantly for your purposes, using that form of authentication as a template, we can get the settings for /etc/apache2/mods-enabled/dav_svn.conf, which will control your SVN access:

<Location /svn>
  DAV svn
  SVNParentPath /srv/svn
  SVNAutoversioning on
  Order deny,allow
  Deny from all
  Allow from
  AuthType Basic
  AuthName "Subversion Repository"
  AuthBasicProvider "ldap"
  AuthLDAPURL "ldap://enterprise-dc.mycompany.com:3268/DC=local-site,DC=mycompany,DC=com?sAMAccountName?sub?(objectClass=user)"
  AuthLDAPBindDN apache-account@local-site.mycompany.com
  AuthLDAPBindPassword "supersecretpasswordthatnoonewillguess"
  authzldapauthoritative On
  require valid-user

Our desktops have fairly tight controls on program installation so I'm not as concerned about someone (a) installing an SVN client (b) figuring out the exact server name to connect to (c) getting into the repo and mucky-mucking things up, which is why the security is so low. However, with a little tweaking, you should be able to re-use this arrangement by enforcing an AD group (note the commented out cruft in the first example) and get much tighter control on access.

Hope this is of help to you.

Update (based on new information)

I think the problem is that you are not authenticating against the Global Catalog. Change the port number to the one I have in my example, and be sure to point it at a Domain Controller that is at the "Enterprise" level i.e. not a member of a child domain. So instead of site.enterprise.com, point it to enterprise.com at the new port number. Note that you might not need to specify the domain name in your setup for the user name, so if it refuses to authenticate, be sure to try it without as well (see the example I posted); and use the "email-style" account name as well vs. the "domain-style" layout.

My suspicion: The Global Catalog "flattens" the search space for users; but by asking a standard LDAP query on the child DC, I think that the initial failure occurs because there is no "answer" to be had initially, until the DC in the child domain can run out and get one. On the second attempt, the answer is cached, and you succeed.

| improve this answer | |
  • In your dav_svn.conf file, are you (farseeker) using the SVNParentPath or SVNPath directive? your problem smells a little bit like a mixup between those two. – matt May 10 '10 at 18:08
  • I'm using SVNParentPath - and my /svn location looks almost identical to the one Avery has posted. I'll update my question with the relevant info – Mark Henderson May 10 '10 at 22:30
  • Thanks for the update, I'll try this out soon and get back to you. – Mark Henderson May 12 '10 at 3:04
  • Perfect, thanks. Sorry it took so long for me to get back to you, but changing the LDAP port worked. I also switched ldapauthorative to on, not sure if that helped as well. – Mark Henderson May 20 '10 at 3:56
  • while ldapauthorative may have contributed, I can assure you that using the Global Catalog (3268) made a world of difference. :) Glad to hear it's working! – Avery Payne May 20 '10 at 16:47

I can't post comment yet but just a question why not run VisualSVN server on a Windows 2008 box with just the Core OS install. I would bet the install platform is just as small as Ubuntu and you could have just copied your entire VisualSVN directory tree to the new box.

Obviously it doesn't help your current problem but just curious if you had thought of this option and what your reasoning was for switching it all together?

| improve this answer | |
  • Hi Brent, I did actually post a comment about why we avoided using a Windows server. We're looking to deploy on a tiny footprint, which Windows Server doesn't do. Even a Core install is at least 4gb in size and consumes more than 256Mb of memory. And then you've got the hassle of maintaining a core install (we have a few of them already) – Mark Henderson May 10 '10 at 5:40
  • OK, I wasn't sure if you had included the Core install as part of your explanation. – Brent Pabst May 10 '10 at 13:54

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.