hi everyone ok, i think i found it :-). It is the sizelimit parameter on the provider.
'The olcSizeLimit/sizelimit attribute/directive specifies the number of entries to return to a search request' Due to the website http://www.zytrax.com/books/ldap/ch6/ It says that 'If no sizelimit directive is defined the default is 500.' No wonder that i had always 500 results with ldapsearch -x, despite the fact, that i deleted some entries. Walter 2013/3/18 Walter Werner <[email protected]>: > hello everyone > > I still did not solve my problem, but i think the solution could be > really some size limitation (already suggested by Marc) > > LDAP_RES_SEARCH_RESULT (4) Size limit exceeded > > The replication was until Object stud31. So i deleted on provider (on > the test environment i can do that) Objects stud01 until stud06. And > the replication went until stud34. 6 deleted and 3 could replicate. I > guess the other 3 objects where replicated in some other sub trees, i > did not noticed, if the size-limit is a constant. The question is, is > there an easy way to see the difference between the provider and > consumer? > > And the main question is, where can the size limitation (if i am > thinking right) comes from? > > Every help is highly appreciated. > > Walter > > 2013/3/15 Walter Werner <[email protected]>: >> hi Marc >> >> Thanks a lot for you quick answer. >> >> 2013/3/15 Marc Patermann <[email protected]>: >>> Walter, >>> >>> Walter Werner schrieb (15.03.2013 10:58 Uhr): >>> >>> >>>> I get a strange replication problem. After i didn't find a solution >>>> somewhere on internet i decided to post to this mailing-list. Probably >>>> i should describe my system settings. Both consumer and provider are >>>> running on suse 12.1. And i got the errors with openldap version >>>> 2.4.26-3.1.3. Since it is a good >>>> behavior i red somewhere on this email-list, i compiled the latest >>>> openldap v2.4.34 and could unfortunately reproduce the same error. >>> >>> The is a repo, did you know? >>> http://download.opensuse.org/repositories/network:/ldap:/OpenLDAP:/ >>> (it is still 2.4.33, but anyway) >> >> No, i didn't. That can save me a lot of time in the future. >> >>> >>>> Mar 15 09:17:43 ismvm22 slapd[17313]: dn_callback : entries have >>>> identical CSN uid=stud31,ou=Student,ou=People,ou=myou,dc=mybase >>>> 20130315072217.081269Z#000000#000#000000 >>> >>> do the objects differ from provider to consumer? >> >> Especially that stud31 object is exactly the same. I am not sure all >> copied objects are the same, if that was the question. Apparently ldap >> has added the stud objects in alphabetical order. There are all studXX >> until stud31. So after stud31 there should be stud32 stud33 and so on, >> but they are missing on the consumer. It is maybe no accident that in >> the log it ends with stud31 object. >> >> dn_callback : entries have identical CSN uid=stud31... >> >>> >>>> Mar 15 09:17:43 ismvm22 slapd[17313]: do_syncrep2: rid=010 >>>> LDAP_RES_SEARCH_RESULT (4) Size limit exceeded >>>> Mar 15 09:17:43 ismvm22 slapd[17313]: do_syncrep2: rid=010 (4) Size >>>> limit exceeded >>>> Mar 15 09:17:43 ismvm22 slapd[17313]: do_syncrepl: rid=010 rc -2 >>>> retrying (58 retries left) >>> >>> Change that! >> >> Do you mean Size limit exceeded? I already thought about that. Please >> look at the partial configs in the first mail.On the provider time and >> size are set to unlimited for the replicator reader. On the consumer >> it is also set to unlimited. Maybe i forgot some other option. >> >>>> overlay syncprov >>> >>> man slapo-syncprov tells more about options to the syncprov overlay. >> >> There are indeed a lot more. I tried with additional parameter for checkpoint >> >> syncprov-checkpoint 100 10 >> >> No effect. Other options seems to me for speeding up ldap. I do not >> want to complicate things. I don't now if it is useful, before trying >> out something, i also always deleted the database files on the >> consumer to avoid memory effects of some sort. >> >> Still not replicating properly. >> >> Walter
