(ITS#7540) syncrepl "replicates" entries with unknown schema elements

[quanah@OpenLDAP.org]

Full_Name: Quanah Gibson-Mount
Version: 2.4.34
OS: Linux 2.6
URL: ftp://ftp.openldap.org/incoming/
Submission from: (NULL) (75.111.39.181)


This is similar to ITS#6473, but somewhat new and unique to back-mdb and
syncrepl fallback.

If, during the process of upgrading a provider/replica cluster, a new schema
element is introduced to the provider, and a modification introducing a value
pair to that attribute is introduced to the provider prior to the replica having
its schema updated, very bad things happen.  In essence, a control-charactered
version of the attribute is introduced into the replica's DB.  The value for the
attribute is not necessarily the value that was written into the providers DB. 
The result is a somewhat corrupted DB on the replica.  For example, when this
occurs with an attribute with binary syntax, what we see on the replica is
things like:

ZIMBRAMOBILEMETADATAMAXSIZEENABLED^]: 30
ZIMBRAMOBILEMETADATAMAXSIZEENABLED^]: -1
ZIMBRAMOBILEMETADATAMAXSIZEENABLED^]: 10000
ZIMBRAMOBILEMETADATAMAXSIZEENABLED^]: 60000

in the slapcat output of the DB.  Clearly these values are *not* binary, and the
introduction of ^] (or sometimes ^Z) is clearly a very bad thing as well.

On the provider, we see something like this in the accesslog:

dn: reqStart=20130317181046.000001Z,cn=accesslog
objectClass: auditModify
structuralObjectClass: auditModify
reqStart: 20130317181046.000001Z
reqEnd: 20130317181046.000002Z
reqType: modify
reqSession: 1001
reqAuthzID: uid=zimbra,cn=admins,cn=zimbra
reqDN: cn=config,cn=zimbra
reqResult: 0
reqMod: zimbraMobileMetadataMaxSizeEnabled:= FALSE
reqMod: entryCSN:= 20130317181046.334253Z#000000#000#000000
reqMod: modifiersName:= uid=zimbra,cn=admins,cn=zimbra
reqMod: modifyTimestamp:= 20130317181046Z
reqEntryUUID: c8e8ac5a-22de-1032-8b13-915a6d80e6d8
entryUUID: bc0a83f0-2379-1032-8335-47fcfae022fc
creatorsName: cn=config
createTimestamp: 20130317181046Z
entryCSN: 20130317181046.334253Z#000000#000#000000
modifiersName: cn=config
modifyTimestamp: 20130317181046Z


However, as a part of this particular upgrade process, the accesslog DB was
recreated (because of the MDB corruption issues).  So delta-syncrepl "falls
back" to normal syncrepl refresh mode.  Instead of halting its fallback due to
the missing schema entry, it *blindly* replicates the entire entry:

Mar 17 11:10:47 zre-ldap003 slapd[8104]: do_syncrep2: rid=100
cookie=rid=100,csn=20130317181046.501990Z#000000#000#000000
Mar 17 11:10:47 zre-ldap003 slapd[8104]: nonpresent_callback: rid=100 present
UUID c8df54ac-22de-1032-8b02-915a6d80e6d8, dn cn=zimbra
Mar 17 11:10:47 zre-ldap003 slapd[8104]: nonpresent_callback: rid=100 present
UUID c8df7662-22de-1032-8b03-915a6d80e6d8, dn cn=admins,cn=zimbra
Mar 17 11:10:47 zre-ldap003 slapd[8104]: nonpresent_callback: rid=100 present
UUID c8dfa1fa-22de-1032-8b04-915a6d80e6d8, dn uid=zimbra,cn=admins,cn=zimbra

Now when the DB is slapcat'd, we see:

zimbra@zre-ldap003:~$ ./libexec/zmslapcat /tmp
51460a8c UNKNOWN attributeDescription "ZIMBRAMOBILEMETADATAMAXSIZEENABLED"
inserted.

And then in the entry itself we have:

zimbraVersionCheckLastAttempt: 20130317011805Z
zimbraVersionCheckLastSuccess: 20130317011805Z
ZIMBRAMOBILEMETADATAMAXSIZEENABLED^]: FALSE
ZIMBRAMOBILEMETADATAMAXSIZEENABLED^]: 30
ZIMBRAMOBILEMETADATAMAXSIZEENABLED^]: -1
ZIMBRAMOBILEMETADATAMAXSIZEENABLED^]: 10000
ZIMBRAMOBILEMETADATAMAXSIZEENABLED^]: 60000
zimbraRedoLogDeleteOnRollover: FALSE


So syncrepl not only incorrectly replicated the entry with an unknown schema
element, it corrupted the database in the process.


Here is the actual data from the provider for this entry:

zimbraVersionCheckLastAttempt: 20130317011805Z
zimbraVersionCheckLastSuccess: 20130317011805Z
zimbraMobileMetadataMaxSizeEnabled: FALSE
zimbraHttpDosFilterMaxRequestsPerSec: 30
zimbraHttpDosFilterDelayMillis: -1
zimbraHttpThreadPoolMaxIdleTimeMillis: 10000
zimbraHttpConnectorMaxIdleTimeMillis: 60000
zimbraRedoLogDeleteOnRollover: FALSE



--Quanah