Good morning!
Sorry for the late answer. I indeed still have this error - for each of my 3
backends, 3 times. And, what was further surprising to me - as far as I
remember, the error still persisted and also persists after running the
suggested fix
dsconf <instance> backend index set <be_name> --attr parentId --add-mr
integerOrderingMatch
as well as the recommended reindex
dsconf <instance> backend index reindex <be_name> --attr parentId
The only difference was, that after applying the fix the recommended
healthcheck actions disappeared - but not the error reports. I'm a little
hesitant about potential troubleshooting after an update from my current
version 389-ds-base-2.6.1-12.el9_6.x86_64 to 389-ds-base-2.7.0-7.el9_7.x86_64
as I’m not really experienced in LDAP installations. This is the reason, why I
wanted to wait and see how these potential bug and workarounds develop.
What might be further interesting or helpful: our multi-master LDAP cluster has
been build from scratch on RHEL 9 using dscreate and - at least in my opinion -
a quite ordinary setup file
;
; This is a version 2 ds setup inf file.
;
; The special value {instance_name} is substituted at installation time.
;
[general]
; latest version number taken from
/usr/lib/python3.9/site-packages/lib389/configurations/__init__.py
defaults = 002003000
full_machine_name = {{ inventory_hostname }}
strict_host_checking = True
[slapd]
; Having replication problems with mdb and 389-ds-base-2.4.5-8.el9_4
; https://www.spinics.net/linux/fedora/389-users/msg22932.html
;db_lib = mdb
instance_name = {{ ds_instance_name }}
port = {{ ds_ldap_port }}
root_password = {{ ds_root_passwd }}
; Even if the SSL certificate is changed later on, it's recommended to install
; the Server with a self signed certificate. Doing so, the installer
; automatically creates two files:
; - /etc/dirsrv/slapd-instance_name/pwdfile.txt
; - /etc/dirsrv/slapd-instance_name/pin.txt
; which are needed by dirsrv to access the NSS database and its certificates.
; References:
; -
https://access.redhat.com/documentation/en-us/red_hat_directory_server/12/html/securing_red_hat_directory_server/assembly_enabling-tls-encrypted-connections-to-directory-server_securing-rhds#con_how-directory-server-unlocks-the-nss-database_assembly_enabling-tls-encrypted-connections-to-directory-server
; -
https://access.redhat.com/documentation/en-us/red_hat_directory_server/12/html/installing_red_hat_directory_server/assembly_setting-up-a-new-instance-on-the-command-line-using-a-inf-file_installing-rhds#proc_creating-a-inf-file-for-a-directory-server-instance-installation_assembly_setting-up-a-new-instance-on-the-command-line-using-a-inf-file
self_sign_cert = True
self_sign_cert_valid_months = 12
[backend-{{ be_name }}]
create_suffix_entry = True
enable_replication = True
replica_binddn = {{ ds_replica_dn }}
; This will create the manager entry if a value is set
; and fails therefore if the binddn already exists!
replica_bindpw = {{ ds_replica_passwd }}
replica_id = {{ ds_be_name_replica_id }}
replica_role = supplier
suffix = {{ ds_suffixes.be_name }}
Please let me know if there is any further info you might need to assist.
Best regards
Christopher
On 09.01.2026, at 20:24, Viktor Ashirov <[email protected]> wrote:
Hi,
On Fri, Jan 9, 2026 at 5:53 PM Zechmeister Christopher via 389-users
<[email protected]<mailto:[email protected]>>
wrote:
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.
Do you also have the issue with the same versions of 389-ds-base? I.e. after
upgrading 389-ds-base-2.6.1-12.el9_6.x86_64 to 389-ds-base-2.7.0-7.el9_7.x86_64?
There is a known issue when some searches may return incomplete or empty
results, but it affects 389-ds-base-2.6.1-12 too.
Could you please check if dsctl <instance> healthcheck returns DSBLE0007 errors?
Thanks.
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]<mailto:[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]<mailto:[email protected]>
To unsubscribe send an email to
[email protected]<mailto:[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]<mailto:[email protected]>
To unsubscribe send an email to
[email protected]<mailto:[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
--
Viktor
--
_______________________________________________
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
