[Date Prev][Date Next]
[Chronological]
[Thread]
[Top]
Re: SyncRepl - no write access
Quoting Quanah Gibson-Mount <quanah@stanford.edu>:
> --On Thursday, January 06, 2005 7:39 PM +0100 Turbo Fredriksson
> <turbo@bayour.com> wrote:
>
>> Quoting Turbo Fredriksson <turbo@bayour.com>:
>>
>> I've started (again, I've lost the previous attempts
>> I did a couple of months ago) to play with SyncRepl
>> again...
>>
>> But I can't seem to be able to do the synchronisation.
>>
>> Running the consumer slapd with '-d -1' I get:
>> This is the exact same, broken behaviour I see when using
>> slurpd. Replication does NOT take place, but all 'evidence'
>> of this vanishes and slapd/slurpd pretends that all is well...
>
> Why would you use slurpd if you have syncrepl set up?
Because on my production machine(s) I use slurpd, but on my development
machine I wanted to try syncrepl. They BOTH show the exact same erratic
(?) behaviour...
> # Syncrepl Provider
> overlay syncprov
Eh? Where is this specified/documented!? Is this a 2.3 thing? I'm still
on 2.2.20.
> access to *
> by
> group.base="cn=ldapReplica,cn=Applications,dc=stanford,dc=edu"
> sasl_ssf=56 read
>
> All replica's are members of the "ldapReplica" group:
Any specific reason why you have one object per server? Why isn't
ONE enough?
> binddn="cn=ldap-dev1,cn=ldap,cn=operational,dc=stanford,dc=edu"
> authcId=ldap/ldap-dev1.stanford.edu@stanford.edu
Oki, explains your sasl-regexp. Nice solution! I'll try this...