Why not set up a local reliable LDAP server which proxies requests from the 
remote unreliable site? This could then be set up to perform the necessary 
authentication if/when the remote site is unavailable.

That would minimise the configuration required within Subversion by addressing 
the underlying reliability problem.

________________________________
--
David Grierson<http://amsdatapp244.bskyb.com:8080/display/~DGR02/> – SDLC Tools 
Specialist
Sky Broadcasting - Customer Business Systems - SDLC Tools
Tel: +44 1506 325100 / Email: 
david.grier...@bskyb.com<mailto:david.grier...@bskyb.com> / Chatter: CBS SDLC 
Tools<https://bskyb.my.salesforce.com/_ui/core/chatter/groups/GroupProfilePage?g=0F9200000008Z8b>
Watermark Building, Alba Campus, Livingston, EH54 7HH


From: Alessandro [mailto:alex.fala...@gmail.com]
Sent: 23 October 2013 10:12
To: users@subversion.apache.org
Subject: mod_dav_svn: double LDAP and file authentication with faulty LDAP 
server...

Hello all,
  it's my first time posting, please bear with me.

I have setup a svn repository served trough apache httpd with the mod_dav_svn 
module with a double authentication scheme: LDAP first then file.
Unfortunately the network connection to the LDAP server hosted on another 
machine is not reliable and the server is not always reachable.
I would like the file authentication to act as a back-up of the LDAP one in 
case the server is unavailable.
I somewhat achieved the desired behaviour at the expense of loosing the user 
names by using the Satisfy Any directive (see commented directive below).
If I omit that directive and the LDAP server is unreachable any commit fails 
with an internal server error and the apache access.log shows lines such as:
10.150.41.26 - - [23/Oct/2013:10:44:45 +0200] "MKACTIVITY 
/svn/test/!svn/act/b14626ae-5ff3-4119-a040-b9da3b5d7b68 HTTP/1.1" 401 626 "-" 
"SVN/1.7.13 neon/0.29.6"
10.150.41.26 - afalappa [23/Oct/2013:10:44:45 +0200] "MKACTIVITY 
/svn/test/!svn/act/b14626ae-5ff3-4119-a040-b9da3b5d7b68 HTTP/1.1" 500 635 "-" 
"SVN/1.7.13 neon/0.29.6"

Is there a way to achieve robustness towards LDAP server availability without 
loosing user names?

Here is my apache <Location> configuration:
# test subversion repository
<Location /svn/test>
   DAV svn
   SVNPath /var/svn/test
   SVNPathAuthz off

   # Limit write permission to list of valid users.
   <LimitExcept GET PROPFIND OPTIONS REPORT>
      AuthName "Test subversion repository"
      AuthType Basic
      AuthBasicProvider ldap file
      AuthLDAPURL  "ldap://ldap-server:8080/dc=organization,dc=com?cn";
      AuthzLDAPAuthoritative off
      AuthUserFile /etc/apache2/svn_users.passwd
      Require valid-user
#      Uncommenting the following line auth succeeds even if ldap server 
unreachable but we lose user names in commit
#      Satisfy any
   </LimitExcept>
</Location>

Thank in advance for any suggestion and please put me in CC in any answers.
--
Alessandro Falappa

Information in this email including any attachments may be privileged, 
confidential and is intended exclusively for the addressee. The views expressed 
may not be official policy, but the personal views of the originator. If you 
have received it in error, please notify the sender by return e-mail and delete 
it from your system. You should not reproduce, distribute, store, retransmit, 
use or disclose its contents to anyone. Please note we reserve the right to 
monitor all e-mail communication through our internal and external networks. 
SKY and the SKY marks are trademarks of British Sky Broadcasting Group plc and 
Sky International AG and are used under licence. British Sky Broadcasting 
Limited (Registration No. 2906991), Sky-In-Home Service Limited (Registration 
No. 2067075) and Sky Subscribers Services Limited (Registration No. 2340150) 
are direct or indirect subsidiaries of British Sky Broadcasting Group plc 
(Registration No. 2247735). All of the companies mentioned in this paragraph 
are incorporated in England and Wales and share the same registered office at 
Grant Way, Isleworth, Middlesex TW7 5QD.

Reply via email to