[Date Prev][Date Next] [Chronological] [Thread] [Top]

Re: ldapmodify when using syncrepl fails due to referral (ITS#2715)



[redirected to openldap-devel]

I note that Jong and I chatted about adding a "turn" capability
to the SyncRepl engine.  It is desirable to support both
consumer->provider connections (as SyncRepl currently supports)
and provider->consumer connections (as slurpd(8) does).

To provide this, I was thinking that slapd(8) (on the consumer):
  syncrepl id=1
         provider=turn://string
         updatedn="cn=Replica,o=University of Michigan,c=US"
         binddn="cn=Manager,o=University of Michigan,c=US"
         bindmethod=simple
         credentials=secret
         searchbase="o=University of Michigan,c=US"
         filter="(objectClass=*)"
         attrs="*"
         schemachecking=off
         scope=sub
         type=refreshOnly
         interval=00:00:01

and on the producer
   turn string
        uri=ldap://consumer
        bindmethod=... binddn=...

where string is used to coordinate the turn (and possibly be used
in turn authorization).   The producer (client) would connect to
the consumer (server), after authenticating, issue a TURN extended
op (providing the string).  The connection would then turn.  That
is, the producer would become the server and the consumer would
become the client.  Then the consumer would initiate syncrepl.

Thoughts on this (and contributions) welcomed.


At 03:09 PM 9/11/2003, quanah@stanford.edu wrote:


>--On Thursday, September 11, 2003 6:00 PM -0400 Jonghyuk Choi 
><jongchoi@us.ibm.com> wrote:
>
>>
>>> You are saying the slave needs to have access to bind to the master?  So
>>> each slave needs permission to bind to the master to read the data it
>>> needs?
>>
>> yes. just like ordinary search requests...
>
>Okay, that is a major departure from how things were done previously via 
>slurpd (slurpd had to have permission to bind to the slave).  Well, that 
>makes things interesting.  I'll have to figure out how we want to set that 
>up on our end, as it means we now have to run a process to get kerberos 
>tickets on all the replica's, and grant them access into the master, which 
>they previously didn't have.
>
>--Quanah
>
>--
>Quanah Gibson-Mount
>Principal Software Developer
>ITSS/TSS/Computing Systems
>Stanford University
>GnuPG Public Key: http://www.stanford.edu/~quanah/pgp.html