> What you are wondering about is attribute level conflicts I don't *think* I am. The one problem I'm trying to understand right now is based on a simple password change. That password change generates many attribute changes on a single entry: password history, various krb attributes, etc. What I saw from audit logs is that those various attribute changes on the one entry got split into two ldap modifications. The audit log shows that all of my servers got one of the modifications, but a few failed to get the other. The thing I've been pursuing here is if those both had the same CSN, since they were created at the same time on the same replica, then it's possible that one of my replicas got an update that contained only one of the modifications, recorded it as the most recent CSN from that replica, and then a second attempt to push the second one resulted in the check seeing that it already had the most recent update and failing to make that other change. I recognize that that's a lot of weirdness. Everything I read claims that CSNs aren't inextricably tied to timestamp, in order to make sure that they're unique, so that would suppose a bug in that system. And then the idea that one of those updates would be carried separately from the other seems like an odd situation, at best. The more I understand about the replication system, the less likely this hypothesis seems. But I'm having a hard time coming up with another. -- _______________________________________________ 389-users mailing list -- 389-users@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe send an email to 389-users-leave@xxxxxxxxxxxxxxxxxxxxxxx Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/389-users@xxxxxxxxxxxxxxxxxxxxxxx Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
