Happy new year everyone! May I ask about the status of this presumable bug? Is there already some ticket I simply cannot find or is it currently not possible to reproduce the described behaviour? I’m in a similar situation and have currently locked the pkg version on our hosts, with the consequence that I cannot update other packages as well due to broken dependencies. I would be very interested in any news I missed.
Thanks for your answer in advance! Best regards Christopher Zechmeister Dipl.-Ing. Christopher Zechmeister Senior Software Developer Online Systeme APA-Tech Laimgrubengasse 10 1060 Wien www.apa.at<https://www.apa.at/> On 20.11.2025, at 16:11, Mark Reynolds via 389-users <[email protected]> wrote: On 11/20/25 8:57 AM, Trenc, Mike via 389-users wrote: Hi everyone, We recently performed OS patching within our Test LDAP environment consisting of six RHEL 9 servers (2 primaries and 4 replicas) such that it upgraded from Red Hat Enterprise Linux release 9.6 to Red Hat Enterprise Linux release 9.7. During the patching process, the 389-DS packages below were also updated. 389-ds-base-2.6.1-12.el9_6.x86_64 ===> 389-ds-base-2.7.0-7.el9_7.x86_64 389-ds-base-libs-2.6.1-12.el9_6.x86_64 ===> 389-ds-base-libs-2.7.0-7.el9_7.x86_64 Shortly after patching and rebooting, we noticed an issue whereby the service accounts associated with applications in our Test environment were no longer able to search the OU that they were previously able to search successfully prior to patching. To correct the issue, we ended up moving the ACIs associated with application service accounts one level higher in the OU. As an example, below represents the change that we made to an ACI before and after the OS patching event to resolve the issue: Original pre-patching ACI when service account searches were successful: DN: ou=people,dc=university,dc=edu (targetattr = "*") (version 3.0;acl "app-user";allow (read,search,compare)(userdn = "ldap:///uid=app-user,ou=ldap-apps,dc=university,dc=edu";);) Post-Patching change made when service account searches no longer worked with the above original ACI configuration: DN: dc=university,dc=edu (targetattr = "*") (version 3.0;acl "app-user";allow (read,search,compare)(userdn = "ldap:///uid=app-user,ou=ldap-apps,dc=university,dc=edu";);) Has anyone else experienced any changes in ACI behavior when upgrading to the latest 389-ds-base-2.7.0-7 and 389-ds-base-libs-2.7.0-7 packages? This is a regression :-( I'm going to try and reproduce it and then file a bug. I'll let you know what the ticket is once it's created. Thanks, Mark Thanks, Mike — Michael Trenc Senior DevOps Engineer | Technology Partner Services Harvard University Information Technology P:(617) 496-6544 | W:huit.harvard.edu<https://huit.harvard.edu/> -- Identity Management Development Team -- _______________________________________________ 389-users mailing list -- [email protected] To unsubscribe send an email to [email protected] 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/[email protected] Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
-- _______________________________________________ 389-users mailing list -- [email protected] To unsubscribe send an email to [email protected] 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/[email protected] Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
