[svn.haxx.se] · SVN Dev · SVN Users · SVN Org · TSVN Dev · TSVN Users · Subclipse Dev · Subclipse Users · this month's index

LDAP authentication, strange server behavior.

From: Sean Russell <sean.2.russell_at_gsk.com>
Date: 2003-05-21 20:59:03 CEST

Hi y'all,

I'm observing some behavior that is giving me trouble; I think I have a
solution, but I'm curious about the possible causes of the problem, and think
that the issue may be of interest to SVN developers.

The problem, in a nutshell, is that I have a repository that won't allow
access to users authenticated with LDAP, but will allow authentication with
other mod_auth Apache modules. The curious thing about this situation is
that LDAP authentication /does/ work for (some) other repositories running in
the same server instance.

The repository giving me trouble is one that I've been lugging around for over
a year, and it has survived numerous DB upgrades. I didn't dump/load it for
the my most recent Subversion upgrade (0.21.0), because it didn't seem
necessary.

Attempts to use LDAP authentication against the "old" repository results in
client-side messages of:

        svn ci -m "" build.xml
        ser's password:
        username: ser
        ser's password:
        svn: Authorization failed
        svn: Commit failed (details follow):
        svn: OPTIONS request failed on /svn/repos/rexml/branches/3.0
        svn: OPTIONS of /svn/repos/rexml/branches/3.0: authorization failed

and server-side messages of:

        user ser not found: /svn/repos/!svn/act/8dcaa690-2dbe-0310-bdb9-d8d87bbec96c

As I've said, if I change the Apache config to use basic htpasswd
authentication, I can access the repository normally -- that is, perform
restricted actions -- and if I create /new/ repositories, I'm able to
authenticate with LDAP for them.

I've narrowed this down to being a difference between the BerkeleyDB
repositories themselves, by process of elimination: the only difference in
the apache configurations for the new and old repositories is the SVNPath
(and the <Location>). Both repositories are running in the same server
instance. The user and group ownerships and permissions on all files and
directories in both repositories is the same.

The only thing I haven't tried (yet) is a dump/load -- which, BTW, I suspect
will solve the problem. However, I'm curious about the source of this
problem -- this looks entirely like a DB issue, and I'm surprised that
authentication issues are affecting (or being affected by) things at the DB
layer.

Thanks,

--- SER

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Wed May 21 21:00:33 2003

This is an archived mail posted to the Subversion Dev mailing list.

This site is subject to the Apache Privacy Policy and the Apache Public Forum Archive Policy.