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

(ITS#5710) syncrepl event loss with ppolicy and multiple masters



Full_Name: Matthew Backes
Version: 2.4, head
OS: all
URL: ftp://ftp.openldap.org/incoming/
Submission from: (NULL) (76.88.99.93)


When using multiple masters replicating from each other with ppolicy
enabled, bind failure events fail to propagate the pwdFailureTime
changes.  The pwdFailureTime's appear on the directory receiving the
change and contextCSN updates, but the replica-side disregards the
event.

In syncprov.c:1646:

/* Don't do any processing for consumer contextCSN updates */
if ( SLAP_SYNC_SHADOW( op->o_bd ) && 
	op->o_msgid == SLAP_SYNC_UPDATE_MSGID ) {
	ldap_pvt_thread_rdwr_wunlock( &si->si_csn_rwlock );
	return SLAP_CB_CONTINUE;
}

This seems to be designed so that when the local side applies remote
changes, the resulting contextCSN update does not get sent back out to
any persistent searchers.

Unfortuantely, this path is also taken for the pwdFailureTime as a
result of a bad (or good) BIND op on a new connection.  This means the
change is applied to the directory receving the BIND, but replicas of
it in multi-master situations discard the change.

This definitely seems to be the MSGID issue because if the BIND is not
the first thing being done, then the pwdFailureTime messages propagate
correctly; e.g. if using STARTTLS and then BIND, no replication
problem exists.

So... any consensus on the right way to do this test?  We could start
looking specifically for changes to contextCSN, but that's sort of
ugly.  A generic don't-replicate-this flag seems like a better
approach but looks somewhat invasive.

Matthew Backes
Symas Corporation
mbackes@symas.com