Take the 2-minute tour ×
Server Fault is a question and answer site for professional system and network administrators. It's 100% free, no registration required.

I'm having some trouble setting up authentication in Apache2 for a SVN repository that's being served using mod_dav_svn.

Here is my Apache config for the directory:

<Location /svn>
    DAV svn
    SVNParentPath /var/svn/repos

    AuthType Basic
    AuthName "Subversion Repository"
    AuthUserFile /etc/apache2/dev.passwd
    Require valid-user
</Location>

I can use svn with the projects under /var/svn/repos, so I know that the DAV is working, but when I do svn updates or commits (or anything), Apache doesn't ask for any authentication... It does the exact same thing whether the Auth directives are there or not.

The permissions on the repository directory (and all subdirectories/files) only give permission to www-data (the Apache2 user/group).

I have also ensured that all relevant modules are enabled (in particular mod_auth is enabled, as are all mod_dav* modules).

Any ideas why svn commands aren't authenticating?

Thanks in advance.

share|improve this question

migrated from superuser.com Jun 16 '10 at 18:57

This question came from our site for computer enthusiasts and power users.

    
Are you on a RHEL/Fedora or a Debian/Ubuntu sytem or other? –  wag2639 Jun 16 '10 at 17:46
    
I'm using Ubuntu 8.04.4 –  Poita_ Jun 16 '10 at 18:55
    
Has your Subversion client cached credentials <svnbook.red-bean.com/en/1.1/ch07.html#svn-ch-7-sect-1.1>; ? –  200_success Jun 18 '10 at 4:59
    
@200_success: Thanks, that was it :) If you make your comment into an answer then I'll give it to you. –  Poita_ Jun 18 '10 at 7:12

6 Answers 6

up vote 1 down vote accepted
+150

Has your Subversion client cached credentials?

share|improve this answer

Have you tried making a non-dav_svn (basically a regular web directory) and check if permissions are working?

For example, you can try something like this:

<Location /test_auth>
    AuthType Basic
    AuthName "TEST TEST TEST"
    AuthUserFile /etc/apache2/dev.passwd
    Require valid-user
</Location>
share|improve this answer
    
I just tried that and permissions are working on the new directory. The permissions just aren't applying to svn access. –  Poita_ Jun 17 '10 at 6:41
1  
Have you tried accessing your svn directory in a web browser just to test it out? I found out this helped the last time I was setting up an SVN server. –  wag2639 Jun 17 '10 at 23:00

Read this if you haven't already.

If that doesn't work...

Are you positive that there aren't any .htaccess .htpasswd files aren't overriding the authentication routine in httpd.conf?

Apache has an all-encompassing inheritance model for permissions that's pretty tricky to get used to. If your permissions are set correctly there, they may be blocked by a setting lower in the hierarchy or overridden by something higher in the hierarchy.

I wish I could give you a more specific answer but my forays into Apache usually involve me pounding my head against the wall for a couple of days to get it right.

share|improve this answer
    
Your guide is pretty much exactly what I have done. I'll check for htaccess and htpasswd files when I get home, but I'm pretty sure there are none. Note: I tried adding "Deny all" to the location, and that worked (denied all access), so some authentication is working, just not this kind... –  Poita_ Jun 16 '10 at 15:29
    
Thanks Evan. I had a look and I did not find any .htaccess or .htpasswd files –  Poita_ Jun 17 '10 at 6:42

A few ideas, in order of conseqeunces:

  1. Check the log files to see what's going on. Maybe that'll clarify the problem.
  2. Apache config changes require you to reload Apache. If you don't, your changes will never take.
  3. You've specified user authentication but not authorization. Make an explicit svn authz and add it. I'm not sure what SVN does in the absence of of an authorization file.
  4. Ubuntu 10.04 LTS is released; I'd recommend an upgrade from 8.04 LTS. It could magically solve the problem, between updates to the kernel, SVN, and apache.
share|improve this answer

It sounds like you most likely have some sort of overlapping configuration which is preventing SVN from working as expected.

What happens when you browse different subdirectories in the repository with a webbrowser? Does it always ask for a username/password? Try using wget or curl to browse the repositories from the commandline. These commandline utilities don't keep session information around, so you can quickly fire off requests to different URLs, quickly use different usernames and passwords, etc.

Enable mod_info. mod_info will create a page (At http://www.example.org/server-info by default) which will combine your entire configuration in detail. This allows you to see if overlapping configuration files (e.g those under /etc/apache2/conf/ and /etc/apache2/conf.d) are causing problems.

Apache's inheritance model can be hard to grok sometimes. I find that mod_info can help me see things a little more clearly. The Satisfy directive might be to blame.

Be sure to restrict mod_info to only allow access from your IP address/network.

share|improve this answer

Another suggestion, create a second repository with a different access path, and make sure these things are competely outside of the namespace of your first repository. This will help to eliminate anomalies under your existing SVN repo.

Something like this:

<Location /svntest>
    DAV svn
    SVNParentPath /tmp/test/repos

    AuthType Basic
    AuthName "TEST"
    AuthUserFile /tmp/test/test.passwd
    Require valid-user
</Location>

Does the problem still happen? If it does, then your problem is due to a configuration oddity in Apache. If the problem does not happen with, then the problem is due to a configuration problem with the subversion repositories under /var/svn/repos.

share|improve this answer

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

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