Issue 6619 - CSN too old
Summary: CSN too old
Status: VERIFIED FEEDBACK
Alias: None
Product: OpenLDAP
Classification: Unclassified
Component: slapd (show other issues)
Version: 2.4.23
Hardware: All All
: --- normal
Target Milestone: ---
Assignee: OpenLDAP project
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2010-08-11 13:36 UTC by heinz.hoelzl@gvcc.net
Modified: 2021-08-03 18:13 UTC (History)
0 users

See Also:


Attachments

Note You need to log in before you can comment on or make changes to this issue.
Description heinz.hoelzl@gvcc.net 2010-08-11 13:36:25 UTC
Full_Name: Heinz H�lzl
Version: 2.4.23
OS: Linux Ubuntu Hardy LTS
URL: ftp://ftp.openldap.org/incoming/
Submission from: (NULL) (84.18.132.37)


If i sync a part of my DIT with syncrepl, the first sync works fine. Then if i
modify some objects on the provider, on the consumer appears: "do_syncrep2:
rid=105 CSN too old, ignoring 20100811125159.871757Z#000000#001#000000"

If i sync the hole DIT all works fine.
If i use openldap 2.4.19 for syncing only a part of the DIT all works fine too.

The version of the provider is 2.4.23 too.

slapd.conf on the provider:

...snip....
database	ldap
lastmod         on
suffix		"dc=krb"
rootdn		"cn=admin,dc=krb"
uri		"ldaps://lbackend.s2.dc.gvcc.net:10636"
readonly	on
...snip...




slapd.conf on the consumer:

# Schema and objectClass definitions
include         /etc/openldap/schema/core.schema
include         /etc/openldap/schema/cosine.schema
include         /etc/openldap/schema/inetorgperson.schema
include         /etc/openldap/schema/nis.schema
include         /etc/openldap/schema/samba3.schema
include         /etc/openldap/schema/openldap.schema
include         /etc/openldap/schema/misc.schema
include         /etc/openldap/schema/sgv.schema
include         /etc/openldap/schema/mozillaOrgPerson.schema
include         /etc/openldap/schema/kerberos.schema



pidfile         /var/run/slapd/slapd.pid
argsfile        /var/run/slapd/slapd.args

allow bind_v2

# Schema check allows for forcing entries to
# match schemas for their objectClasses's
#schemacheck     on

loglevel        none

#######################################################################
# ldbm database definitions
#######################################################################
modulepath	/usr/lib/ldap
moduleload	back_hdb
moduleload	rwm
sizelimit unlimited
tool-threads 1


access to *
	by * write

include		/etc/openldap/tls.conf

backend		hdb

# KERBEROS
database        hdb
dbconfig set_cachesize 0 2097152 0
dbconfig set_lk_max_objects 1500
dbconfig set_lk_max_locks 1500
dbconfig set_lk_max_lockers 1500
lastmod         on
suffix          "dc=krb"
checkpoint      512 30

directory       "/var/lib/ldap/krb"
rootdn          "cn=admin,dc=krb"
rootpw          blabla
include		/etc/openldap/slapd.replica.consumer-krb

index           objectClass                                     eq
index           krbPrincipalName                                eq,pres,sub
index           krbPwdPolicyReference                           eq,pres
index           entryUUID,aliasedObjectName                     eq
index           default                                         sub
###############################################################################

/etc/openldap/slapd.replica.consumer-krb:
# syncrepl 
syncrepl	rid=101 searchbase="dc=krb" scope=base
	provider=ldaps://syncrepl.zid.gvcc.net
	type=refreshAndPersist
	retry="5 5 300 +"
	schemachecking=off
	bindmethod=sasl
	saslmech=EXTERNAL
	tls_cert=/etc/openldap/.ssl/usercert.pem
	tls_key=/etc/openldap/.ssl/user.key
	tls_cacert=/etc/ssl/cacert.pem
	tls_reqcert=try

syncrepl	rid=102 searchbase="cn=princs,dc=krb" scope=base
	provider=ldaps://syncrepl.zid.gvcc.net
	type=refreshAndPersist
	retry="5 5 300 +"
	schemachecking=off
	bindmethod=sasl
	saslmech=EXTERNAL
	tls_cert=/etc/openldap/.ssl/usercert.pem
	tls_key=/etc/openldap/.ssl/user.key
	tls_cacert=/etc/ssl/cacert.pem
	tls_reqcert=try

syncrepl	rid=103 searchbase="cn=krbcontainer,dc=krb" scope=sub
	provider=ldaps://syncrepl.zid.gvcc.net
	type=refreshAndPersist
	retry="5 5 300 +"
	schemachecking=off
	bindmethod=sasl
	saslmech=EXTERNAL
	tls_cert=/etc/openldap/.ssl/usercert.pem
	tls_key=/etc/openldap/.ssl/user.key
	tls_cacert=/etc/ssl/cacert.pem
	tls_reqcert=try
	syncdata=default

syncrepl	rid=104 searchbase="o=zid,cn=princs,dc=krb" scope=sub
	provider=ldaps://syncrepl.zid.gvcc.net
	type=refreshAndPersist
	retry="5 5 300 +"
	schemachecking=off
	bindmethod=sasl
	saslmech=EXTERNAL
	tls_cert=/etc/openldap/.ssl/usercert.pem
	tls_key=/etc/openldap/.ssl/user.key
	tls_cacert=/etc/ssl/cacert.pem
	tls_reqcert=try
	syncdata=default

syncrepl	rid=105 searchbase="o=klingons,cn=princs,dc=krb" scope=sub
	provider=ldaps://syncrepl.zid.gvcc.net
	type=refreshAndPersist
	retry="5 5 300 +"
	schemachecking=off
	bindmethod=sasl
	saslmech=EXTERNAL
	tls_cert=/etc/openldap/.ssl/usercert.pem
	tls_key=/etc/openldap/.ssl/user.key
	tls_cacert=/etc/ssl/cacert.pem
	tls_reqcert=try
	syncdata=default


##################################################################


buid-options for both versions (2.4.19 and 2.4.23) used on the consumer an on
the provider:
./configure --prefix=${prefix} --bindir=${prefix}/bin --sbindir=${prefix}/sbin
--libexecdir=${prefix}/lib --libdir=${prefix}/lib --sysconfdir=/etc
--localstatedir=/var --mandir=${prefix}/share/man --enable-debug
--enable-dynamic --enable-syslog --enable-proctitle --enable-ipv6 --enable-local
--enable-slapd --enable-aci --enable-cleartext --enable-crypt --disable-lmpasswd
--enable-spasswd --enable-modules --enable-rewrite --enable-rlookups
--enable-slapi --enable-slp --enable-wrappers --enable-backends=mod
--disable-ndb --enable-overlays=mod --with-subdir=ldap --with-cyrus-sasl
--with-threads --with-tls=openssl --with-odbc=unixodbc --build x86_64-linux-gnu




Comment 1 heinz.hoelzl@gvcc.net 2010-10-27 11:22:44 UTC
I testet it also whithout a back-ldap
The problem exists also if the provider is a "normal" slapd with 
"database hdb"

Comment 2 Quanah Gibson-Mount 2017-03-28 01:17:59 UTC
Hi Heinz,

Do you still see this issue with current OpenLDAP builds?  Also, can you 
confirm that time was tightly sync'd in the case you submitted?  I've seen 
similar issues due to clock skew.

Regards,
Quanah

--

Quanah Gibson-Mount
Product Architect
Symas Corporation
Packaged, certified, and supported LDAP solutions powered by OpenLDAP:
<http://www.symas.com>


Comment 3 OpenLDAP project 2017-03-28 01:18:12 UTC
clock skew?
Comment 4 Quanah Gibson-Mount 2017-03-28 01:18:12 UTC
changed notes
changed state Open to Feedback
moved from Incoming to Software Bugs