[389-users] Replication. MemberOf plugin generating duplicate changes

Hello, List!
I'm using 389-ds as part of a FreeIPA deployment on AlmaLinux 9 and have encountered some unexpected behavior.

I have two servers configured for replication. When I delete a user on one server (via ipa user-del), the following entries appear in the replication changelog:

dbscan -f /var/lib/dirsrv/slapd-TEST-LOC/db/userRoot/replication_changelog.db

dbid: 68edda57000000040000
encrypted: no
replgen: 1760418390 Tue Oct 14 08:06:30 2025
csn: 68edda57000000040000
uniqueid: 316c0981-a8bb11f0-b7c78566-a52e6fbb
dn: uid=test2,cn=users,cn=accounts,dc=test,dc=loc
operation: delete

dbid: 68edda57000100040000
encrypted: no
replgen: 1760418390 Tue Oct 14 08:06:30 2025
csn: 68edda57000100040000
uniqueid: 316c0983-a8bb11f0-b7c78566-a52e6fbb
dn: cn=test,cn=groups,cn=accounts,dc=test,dc=loc
operation: modify
member: uid=test2,cn=users,cn=accounts,dc=test,dc=loc
modifiersname: cn=referential integrity postoperation,cn=plugins,cn=config
modifytimestamp: 20251014050630Z
entryusn: 2913

dbid: 68edda57000200040000
encrypted: no
replgen: 1760418390 Tue Oct 14 08:06:30 2025
csn: 68edda57000200040000
uniqueid: 02ac4fb5-a83711f0-a3868566-a52e6fbb
dn: cn=ipausers,cn=groups,cn=accounts,dc=test,dc=loc
operation: modify
member: uid=test2,cn=users,cn=accounts,dc=test,dc=loc
modifiersname: cn=referential integrity postoperation,cn=plugins,cn=config
modifytimestamp: 20251014050630Z
entryusn: 2914

dbid: 68edda57000300040000
encrypted: no
replgen: 1760418390 Tue Oct 14 08:06:30 2025
csn: 68edda57000300040000
uniqueid: 316c0982-a8bb11f0-b7c78566-a52e6fbb
dn: cn=test2,cn=groups,cn=accounts,dc=test,dc=loc
operation: delete

dbid: 68edda59000000030000
encrypted: no
replgen: 1760418391 Tue Oct 14 08:06:31 2025
csn: 68edda59000000030000
uniqueid: 02ac4fb5-a83711f0-a3868566-a52e6fbb
dn: cn=ipausers,cn=groups,cn=accounts,dc=test,dc=loc
operation: modify
member: uid=test2,cn=users,cn=accounts,dc=test,dc=loc
modifiersName: cn=MemberOf Plugin,cn=plugins,cn=config
modifyTimestamp: 20251014050631Z

dbid: 68edda59000100030000
encrypted: no
replgen: 1760418391 Tue Oct 14 08:06:31 2025
csn: 68edda59000100030000
uniqueid: 316c0983-a8bb11f0-b7c78566-a52e6fbb
dn: cn=test,cn=groups,cn=accounts,dc=test,dc=loc
operation: modify
member: uid=test2,cn=users,cn=accounts,dc=test,dc=loc
modifiersName: cn=MemberOf Plugin,cn=plugins,cn=config
modifyTimestamp: 20251014050631Z

This log shows that first, a user record is deleted on the replica with ID 4, then the referential integrity plugin clears this user's membership from groups, and then deletes the user's primary group. Then something unexpected happens: additional changes appear from the replica with ID 3 — the MemberOf plugin also removes the user from the groups. If I add another replica to the topology, it will also generate these same changes and send them to the others.

With 2–3 replicas this isn't a big deal, but if, for example, there are 20 replicas and a user is a member of 5 groups, then each replica will generate around 100 changes and attempt to replicate them to all others.

I'm not sure if this is the expected behavior. It seems like there's excessive replication of changes, which could also impact performance. I haven't found any documentation describing this behavior. Could anyone explain why the MemberOf plugin behaves this way, and whether this is considered an issue?

I tested this with 389-ds 2.3.2 and 2.6.1, and observed the same duplicated MemberOf changes in both.

Thanks in advance!
--
_______________________________________________
389-users mailing list -- 389-users@lists.fedoraproject.org
To unsubscribe send an email to 389-users-leave@lists.fedoraproject.org
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@lists.fedoraproject.org
Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue