[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...