Re: (ITS#8607) Second master in MMR config logging contextCSN changes to accesslog

[mberg@synacor.com]

Storing the update to the contextCSN to the root object makes sense,
but propagating that update through the accesslog?  Even if it were
intended behavior, shouldn't the server receiving the update directly
generate a similar access log entry, rather than just the server
applying it from the accesslog.

But practically speaking, the contextCSN on a given server should
presumably reflect the most recent entryCSN that particular server has
applied, and this would seem to break that.

To illustrate I added a third contextCSN to my lab servers, with a
stale CSN on ldap01-a:

  [zimbra@ldap01-a ~ldapsearch -LLL -D uid=zimbra,cn=admins,cn=zimbra -H ldapi:/// -w ******** -s base contextCSN
  dn:
  contextCSN: 20170302203943.550330Z#000000#001#000000
  contextCSN: 20170302175436.282737Z#000000#002#000000
  contextCSN: 20160302175436.282737Z#000000#003#000000
 
  [zimbra@ldap01-b ~]$ ldapsearch -LLL -D uid=zimbra,cn=admins,cn=zimbra -H ldapi:/// -w ******** -s base contextCSN
  dn:
  contextCSN: 20170302203943.550330Z#000000#001#000000
  contextCSN: 20170302175436.282737Z#000000#002#000000
  contextCSN: 20170302175436.282737Z#000000#003#000000

Wrote a new entry on ldap01-a (which is SID 001).  The change
propagated to ldap01-b, wrote an auditModify to the accesslog with its
new contextCSNs:

  dn: reqStart=20170302214742.843377Z,cn=accesslog
  objectClass: auditModify
  structuralObjectClass: auditModify
  reqStart: 20170302214742.843377Z
  reqEnd: 20170302214742.844297Z
  reqType: modify
  reqSession: 100
  reqAuthzID: cn=config
  reqDN:
  reqResult: 0
  reqMod: contextCSN:= 20170302214737.049475Z#000000#001#000000
  reqMod: contextCSN:= 20170302175436.282737Z#000000#002#000000
  reqMod: contextCSN:= 20170302175436.282737Z#000000#003#000000
  reqEntryUUID: e1475404-93d7-1036-989f-315f78f5905f
  entryUUID: 9bceae9e-93dd-1036-8a51-85a9c542cb5f
  creatorsName: cn=config
  createTimestamp: 20170302214737Z
  entryCSN: 20170302214737.049475Z#000000#001#000000
  modifiersName: cn=config
  modifyTimestamp: 20170302214737Z

Which was subsequently read by ldap01-a:

  Mar  2 16:47:42 ldap01-a slapd[9577]: syncprov_search_response: cookie=rid=100,sid=001,csn=20170302214737.049475Z#000000#001#000000

And now it has an updated contextCSN for 003 despite receiving no update for that SID:

  [zimbra@ldap01-a ~]$ ldapsearch -LLL -D uid=zimbra,cn=admins,cn=zimbra -H ldapi:/// -w ******** -s base contextCSN
  dn:
  contextCSN: 20170302214737.049475Z#000000#001#000000
  contextCSN: 20170302175436.282737Z#000000#002#000000
  contextCSN: 20170302175436.282737Z#000000#003#000000

I'm not sure if there is any guard against writing an older contextCSN
than is currently stored, but this could theoretically rewind the
stored contextCSN on A if there is any latency in replication from B.

This message and any attachment may contain information that is confidential and/or proprietary. Any use, disclosure, copying, storing, or distribution of this e-mail or any attached file by anyone other than the intended recipient is strictly prohibited. If you have received this message in error, please notify the sender by reply email and delete the message and any attachments. Thank you.