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