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.
