On 10/15/25 5:43 AM, vectinx via 389-users wrote:
> 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.
Have you modified the memberOf configuration, or is it all "default"
from the IPA installation? I'm assuming these are all IPA servers, and
no standalone directory servers, is that correct?
Thanks,
Mark
>
> Thanks in advance!
--
Identity Management Development Team
--
_______________________________________________
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
No comments:
Post a Comment