Not sure this is a bug, but I'm curious... I hit this while checking for ITS#5661. The code below is from HEAD's syncprov.c:613 (not changed recently; pardon any unintended line wrapping):
<snip> again: switch( mode ) { case FIND_MAXCSN: cf.f_choice = LDAP_FILTER_GE; /* If there are multiple CSNs, use the one with our serverID */ for ( i=0; i<si->si_numcsns; i++) { if ( slap_serverID == si->si_sids[i] ) { maxid = i; break; } } </snip>
When run by a consumer, with no serverID set (and thus slap_serverID == 0), it causes the consumer to use the contextCSN with SID == "000" instead of the most recent one. As a consequence, if one searches the contextCSN within that consumer, slapo-syncprov's syncprov_operational() causes only that value to be returned, instead of all contextCSNs. After the consumer is restarted, all values are correctly returned. To reproduce:
- populate a DSA (SIDs in CSNs will default to "000")
- turn it into a (multi)master by adding the serverID statement (with SID > "000") and so
- perform a modification (so that the most recent contextCSN will have SID != "000")
- create a consumer (no serverID statement, so that it defaults to "000") and let it pull data from the producer
- search the contextCSN of the consumer
I'm not sure this is a bug; it might be harmless, apart from being definitely misleading. There might be multiple solutions:
- don't let syncprov_operational() muck with contextCSN that way
- make syncprov_findcsn() search the newest contextCSN instead of the one with its SID
- initialize slapd_serverID with some SID_UNDEFINED in order to take the action above only when SID is not defined
p.
Ing. Pierangelo Masarati OpenLDAP Core Team
SysNet s.r.l. via Dossi, 8 - 27100 Pavia - ITALIA http://www.sys-net.it ----------------------------------- Office: +39 02 23998309 Mobile: +39 333 4963172 Fax: +39 0382 476497 Email: ando@sys-net.it -----------------------------------