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
On 20.11.2025, at 16:11, Mark Reynolds via 389-users <389-users@lists.fedoraproject.org> 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_64389-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 ServicesHarvard University Information Technology
-- 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