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

Re: syncrepl questions

--On Saturday, September 20, 2003 3:39 PM -0700 Quanah Gibson-Mount <quanah@stanford.edu> wrote:


I dumped my output to a file so I could see what was happening and debug.

In the syncrepl definition in slapd.conf, there are these two lines:


What I find, is that the replica binds to the server as ldap-dev2 (as
expected), but then tries to read from the master as cn=replicator.  My
understanding from the documentation was that the updatedn entry was the
entry that would be used from the master to the replica to write changes
back into the replica -- definitely not the case from what I can see.  I
would expect the replica to continue to use its binddn as its method to
read... is it also using this updatedn to write back into itself?  More
investigation on my part. ;)

I've now changed the updatedn to match the binddn. Now in looking at the log of what is happening (-d -1), I see:

=> bdb_entry_get: ndn: "cn=ldapadmin,cn=applications,dc=stanford,dc=edu"
=> bdb_entry_get: oc: "groupOfNames", at: "member"
=> bdb_dn2id( "cn=ldapadmin,cn=applications,dc=stanford,dc=edu" )
<= bdb_dn2id: got id=0x00000006
entry_decode: "cn=ldapAdmin,cn=Applications,dc=stanford,dc=edu"
<= entry_decode(cn=ldapAdmin,cn=Applications,dc=stanford,dc=edu)
=> bdb_entry_get: found entry: "cn=ldapadmin,cn=applications,dc=stanford,dc=edu"
bdb_entry_get: rc=0

dnMatch 0 "cn=ldap-dev2,cn=ldap,cn=operational,dc=stanford,dc=edu" "cn=ldap-dev2,cn=ldap,cn=operational,dc=stanford,dc=edu" <= check a_authz.sai_sasl_ssf: ACL 56 > OP 0

A definate bug here -- It isn't keeping the sasl_ssf stored when connecting (ITS#2734).

I can't continue anymore on syncrepl till this at least is fixed.


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