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

Re: slurpd problems

Michael Belanger wrote: 
We are using a bdb backend. Both ldap servers work and both accept
connections from uid=replica.


Master Server info:
@(#) $OpenLDAP: slurpd 2.1.29 (Apr 14 2004 15:02:04) $

from slapd.conf
replogfile /var/lib/ldap/openldap-master-replog
replica uri=ldap://bender.ciclops.org
	binddn="uid=replica,ou=People,dc=ciclops,dc=org"
	starttls=no bindmethod=simple  	
        credentials={crypt}encryptedstring


Slave Server info:
@(#) $OpenLDAP: slapd 2.3.27 (Sep 29 2006 13:05:21) $
updatedn "uid=replica,ou=People,dc=ciclops,dc=org"
updateref ldap://porbeagle.ciclops.org


Simple change of shell for a user:

on master:
[root@porbeagle replica]# cat slurpd.replog
replica: bender.ciclops.org:389
time: 1159572211
dn: uid=mrb,ou=People,dc=ciclops,dc=org
changetype: modify
replace: loginShell
loginShell: /bin/csh
-
replace: entryCSN
entryCSN: 2006092923:23:31Z#0x0001#0#0000
-
replace: modifiersName
modifiersName: cn=Manager,dc=ciclops,dc=org
-
replace: modifyTimestamp
modifyTimestamp: 20060929232331Z

openldap-master-replog contains nothing.


on slave:
no change in entries for loginShell.

I don't see any errors anywhere in the system -- even with a higher
debug level.

Could this be a problem with syncing to a newer version of openldap?
Suggestions?

You're using an encrypted password in your "replica" directive. That is not allowed. If you run slurpd in debug mode you should see it failing to Bind to the slave server.

Also the 2.1 entryCSN format is incompatible with 2.2/2.3. You should filter it out of the replication.

--
  -- Howard Chu
  Chief Architect, Symas Corp.  http://www.symas.com
  Director, Highland Sun        http://highlandsun.com/hyc
  OpenLDAP Core Team            http://www.openldap.org/project/