--On Thursday, July 02, 2009 3:40 PM -0700 Quanah Gibson-Mount quanah@zimbra.com wrote:

So, it appears to me that even though it must have at some point accepted the first change, the entry on the server is not truly updated to reflect that for some reason? That, or it "skipped" that change for reasons unknown to me.

Adding to the mystery, is what the server believes the entry looks like, even across restarts:

dn: uid=acyen,cn=accounts,dc=stanford,dc=edu suSeasSunetID: acyen suDialinStatus: active suCreateAgent: AccountSlog suService: dialin suService: afs suService: leland suService: email suService: pts suService: seas suService: kerberos suEmailAdmin: acyen suSeasUriRouteTo: /~acyen suName: XXXXXXX uid: acyen suNameLF: XXXXXXXX suSeasStatus: active suKerberosStatus: active suEntryStatus: active suAccountStatus: active krb5PrincipalName: XXXXXXXX suSeasLocal: XXXXXXXXX suEmailAccountType: personal suAfsStatus: active suEmailStatus: active suMailDrop: XXXXXXXXX suCreateAPI: JNDI suKrb4Name: XXXXXXXXXX suPtsStatus: active suLelandStatus: active gecos: XXXXXX cn: XXXXXXX suAfsHomeDirectory: /afs/ir/users/a/c/acyen suPtsUid: 28906 loginShell: /bin/tcsh uidNumber: 28906 gidNumber: 37 homeDirectory: /afs/ir/users/a/c/acyen objectClass: posixAccount objectClass: suPtsService objectClass: suAccount objectClass: suOperational objectClass: suAfsService objectClass: suEmailService objectClass: suLelandService objectClass: suDialinService objectClass: suKerberosService objectClass: suSeasService suIdentifies: suRegID=85ddc8aaf61311d2ae662436000baa77,cn=People,dc=Stanford,d c=edu seeAlso: suRegID=85ddc8aaf61311d2ae662436000baa77,cn=People,dc=Stanford,dc=edu owner: suRegID=85ddc8aaf61311d2ae662436000baa77,cn=People,dc=Stanford,dc=edu description: XXXXXXXXXX suEmailQuota: 1000 suDescription: XXXXXXXXXX structuralObjectClass: suAccount entryUUID: bd300052-dbd5-102c-8575-cd5814f999c3 creatorsName: cn=slog-accounts,cn=service,cn=applications,dc=stanford,dc=edu createTimestamp: 20080701162309Z modifiersName: cn=slog-accounts,cn=service,cn=applications,dc=stanford,dc=edu modifyTimestamp: 20090210171734Z entryCSN: 20090702065034.772554Z#000000#000#000000 entryDN: uid=acyen,cn=accounts,dc=stanford,dc=edu subschemaSubentry: cn=Subschema hasSubordinates: FALSE

The first change, which we'd think had gone across given it is stuck on the second change, never appears to have been applied, but nothing was ever logged about this. The attributes and objectClass that were supposed to be deleted are still present. The value changes that were supposed to occur haven't.

Now, the entryCSN is: 20090702065034.772554Z#000000#000#000000

vs the change time which is:

20090702070150.000014Z

so clearly, the entry has never been updated with the change. Yet it *should* have been. How did we end up skipping a change from the accesslog db????

--Quanah

--

Quanah Gibson-Mount Principal Software Engineer Zimbra, Inc -------------------- Zimbra :: the leader in open source messaging and collaboration