Re: SyncRepl - no write access

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

Anyhow, here is how I've configured syncRepl (using SASL/GSSAPI), for 
OpenLDAP 2.3.0 alpha, which is the release I suggest you test syncRepl on. 
;)

Important bits from the master's slapd.conf:

sasl-regexp uid=ldap/(.*),cn=stanford.edu,cn=gssapi,cn=auth 
ldap:///cn=ldap,cn=Operational,dc=stanford,dc=edu??sub?krb5Princi
palName=ldap/$1@stanford.edu

This maps the bind from the sync Replica to a DN in the database (not 
necessary, but I find it useful).

# Syncrepl Provider
overlay syncprov

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:

# ldapReplica, Applications, stanford.edu
dn: cn=ldapReplica,cn=Applications,dc=stanford,dc=edu
objectClass: groupOfNames
cn: ldapReplica
member: cn=ldap-dev1,cn=ldap,cn=operational,dc=stanford,dc=edu
member: cn=ldap-dev2,cn=ldap,cn=operational,dc=stanford,dc=edu
member: cn=ldap-dev3,cn=ldap,cn=operational,dc=stanford,dc=edu

An individual entry looks like:

# ldap-dev1, ldap, operational, stanford.edu
dn: cn=ldap-dev1,cn=ldap,cn=operational,dc=stanford,dc=edu
objectClass: applicationProcess
objectClass: krb5Principal
cn: ldap-dev1
description: ldap access for ldap-dev1
krb5PrincipalName: ldap/ldap-dev1.stanford.edu@stanford.edu



On the replica side of things:

syncrepl        rid=0
               provider=ldap://ldap-dev0.stanford.edu:389
               updatedn="cn=Manager,dc=stanford,dc=edu"

binddn="cn=ldap-dev1,cn=ldap,cn=operational,dc=stanford,dc=edu"
               bindmethod=sasl
               saslmech=gssapi
               searchbase="dc=stanford,dc=edu"
               authcId=ldap/ldap-dev1.stanford.edu@stanford.edu
               realm=stanford.edu
               schemachecking=on
               type=refreshAndPersist
               retry="60 +"


The next thing I plan on playing with on 2.3.0 alpha is the session logging.

--Quanah

--
Quanah Gibson-Mount
Principal Software Developer
ITSS/Shared Services
Stanford University
GnuPG Public Key: http://www.stanford.edu/~quanah/pgp.html

"These censorship operations against schools and libraries are stronger
than ever in the present religio-political climate. They often focus on
fantasy and sf books, which foster that deadly enemy to bigotry and blind
faith, the imagination." -- Ursula K. Le Guin