389-users January 2026

389-users@lists.fedoraproject.org

12 participants
8 discussions

howto retrieve backend cache statistics with mdb on 389ds 2.5.x ?
by Bob Green 23 Jan '26

23 Jan '26

It seems if one configures 389ds 2.x instance with mdb backend, one loses the ability to run "dsconf <instance> monitor dbmon", with "Error: list index out of range". This is a known issue: https://github.com/389ds/389-ds-base/issues/6614 . "dsconf <instance> monitor ldbm" appears to provide some of the same information, in particular with normalizeddncachehitratio, but not necessarily for the backend entry cache information, or am I mistaken? Outside of upgrading to the latest version, is there an alternative means of retrieving the same information that "monitor dbmon" provides? Or, should I stick to bdb until I get around to upgrading to 389ds 3.x? This issue observed with: % rpm -qi 389-ds|head -n3 Name : 389-ds Version : 2.5.3~git144.95b15d57c Release : 150700.3.6.1 on SLES15_sp7 % dsconf dev backend config get |grep nsslapd-backend-implement nsslapd-backend-implement: mdb % dsconf dev monitor dbmon Error: list index out of range Thanks, Bob

1 0

Recovery of a 389 instance that's participating in multi-master replication
by tdarby＠arizona.edu 23 Jan '26

23 Jan '26

I'm testing disaster recovery for a set of 389 servers in multi-master replication. These are AWS instances with attached EBS volumes, so it amounts to restoring the EBS from backup and starting a new EC2. My preferred scenario would be to recover just one of the instances, attempting to avoid any out-of-sync replication issues with the others, and then create new replicas from the one recovered instance. When I do this, however, the recovered instance wants to rebuild the replication changelog and this can take up to an hour. My questions are: 1. Is there any way to start an instance like this with replication completely disabled? 2. Is there a better way to do this recovery? Tim

4 3

Error message "Can't locate CSN in the changelog", allthough CSN is present in the changelog
by Fl Sch 14 Jan '26

14 Jan '26

Hello, we have recently upgraded our 389-ds setup to version 2.6.1 running on AlmaLinux 9.6 (installed from the official AlmaLinux appstream repo). Or upgrade approach was to build a completely new setup, import all the data and afterwards switch the IP addresses of the old and new servers. Our setup consists of 2 suppliers (mdir01 + mdir02) and 2 consumers (sdir01 + sdir02). Both suppliers each have a replication agreement between each other, aswell as agreements to both consumers. Our provisioning system is designed to only write changes to mdir01, it just uses mdir02 in case it can't reach mdir01. Our clients (DHCP servers) use all 4 directory servers. Since the upgrade we have that problem that we observe the following messages in the error logs of both suppliers: <code> [10/Jul/2025:09:58:55.479913820 +0200] - ERR - agmt="cn=agreement-mdir01-to-sdir02" (10:1389) - clcache_load_buffer - Can't locate CSN 686f72bf00050f4b0000 in the changelog (DB rc=-12797). If replication stops, the consumer may need to be reinitialized. [10/Jul/2025:09:58:55.484629809 +0200] - ERR - agmt="cn=agreement-mdir01-to-mdir02" (10:1389) - clcache_load_buffer - Can't locate CSN 686f72bf00050f4b0000 in the changelog (DB rc=-12797). If replication stops, the consumer may need to be reinitialized. [10/Jul/2025:09:58:55.484868342 +0200] - ERR - agmt="cn=agreement-mdir01-to-sdir01" (10:1389) - clcache_load_buffer - Can't locate CSN 686f72bf00050f4b0000 in the changelog (DB rc=-12797). If replication stops, the consumer may need to be reinitialized. [10/Jul/2025:10:01:07.738009372 +0200] - ERR - agmt="cn=agreement-mdir01-to-sdir02" (10:1389) - clcache_load_buffer - Can't locate CSN 686f734300000f4b0000 in the changelog (DB rc=-12797). If replication stops, the consumer may need to be reinitialized. [10/Jul/2025:10:01:07.741023198 +0200] - ERR - agmt="cn=agreement-mdir01-to-mdir02" (10:1389) - clcache_load_buffer - Can't locate CSN 686f734300000f4b0000 in the changelog (DB rc=-12797). If replication stops, the consumer may need to be reinitialized. [09/Jul/2025:12:18:14.429187195 +0200] - ERR - agmt="cn=agreement-mdir02-to-sdir01" (10:1389) - clcache_load_buffer - Can't locate CSN 686eb26600000f4b0000 in the changelog (DB rc=-12797). If replication stops, the consumer may need to be reinitialized. [09/Jul/2025:12:18:14.430628311 +0200] - ERR - agmt="cn=agreement-mdir02-to-sdir02" (10:1389) - clcache_load_buffer - Can't locate CSN 686eb26600000f4b0000 in the changelog (DB rc=-12797). If replication stops, the consumer may need to be reinitialized. [09/Jul/2025:12:18:16.909625172 +0200] - ERR - agmt="cn=agreement-mdir02-to-sdir01" (10:1389) - clcache_load_buffer - Can't locate CSN 686eb26800000f4b0000 in the changelog (DB rc=-12797). If replication stops, the consumer may need to be reinitialized. [09/Jul/2025:12:18:16.913147068 +0200] - ERR - agmt="cn=agreement-mdir02-to-sdir02" (10:1389) - clcache_load_buffer - Can't locate CSN 686eb26800000f4b0000 in the changelog (DB rc=-12797). If replication stops, the consumer may need to be reinitialized. [09/Jul/2025:12:42:30.255121122 +0200] - ERR - agmt="cn=agreement-mdir02-to-sdir01" (10:1389) - clcache_load_buffer - Can't locate CSN 686f60d500010f4b0000 in the changelog (DB rc=-12797). If replication stops, the consumer may need to be reinitialized. </code> On mdir01 these messages appear on average every 5 minutes during peak hours. On mdir02 much more infrequently, on average every 15-20 minutes. However, looking through the changelog I can find all the CSNs which it apparently can't locate: <code> changetype: delete replgen: 62b5bf320000010f0000 csn: 686f72bf00050f4b0000 nsuniqueid: da0de304-593411f0-aef0dc83-b57f4cfd dn: ClientIdentifier=00:00:00:00:d9:05,ou=dhcpldap,o=customer,dc=domain,dc=net changetype: delete replgen: 62b5bf320000010f0000 csn: 686f734300000f4b0000 nsuniqueid: 4c315e08-5d6111f0-aef0dc83-b57f4cfd dn: ClientIdentifier=00:00:00:00:c6:f4,ou=dhcpldap,o=customer,dc=domain,dc=net changetype: delete replgen: 62b5bf320000010f0000 csn: 686eb26600000f4b0000 nsuniqueid: 54f4e05b-04a311f0-9233a0e8-dc56aea6 dn: ClientIdentifier=00:00:00:00:26:99,ou=dhcpldap,o=customer,dc=domain,dc=net changetype: delete replgen: 62b5bf320000010f0000 csn: 686eb26800000f4b0000 nsuniqueid: 463ba84b-0af711f0-a597a0e8-dc56aea6 dn: ClientIdentifier=00:00:00:00:f7:a0,ou=dhcpldap,o=customer,dc=domain,dc=net changetype: add replgen: 62b5bf320000010f0000 csn: 686f60d500010f4b0000 nsuniqueid: e9d45f81-5d5811f0-aef0dc83-b57f4cfd parentuniqueid: 6167af03-f3c311ec-862ceac3-35201d04 dn: ClientIdentifier=00:00:00:00:16:68,ou=dhcpldap,o=customer,dc=domain,dc=net change:: ... </code> All the changes are populated to all directory servers in the cluster. So there is no real problem visible. In general, we have not seen any problems with replication whatsoever, we just have these seemingly "false" messages in the error log. Changelog trim is currently set to the following values: <code> nsslapd-changelogmaxage: 30d nsslapd-changelogtrim-interval: 3600 </code> Does anybody know why these error messages appear? And if / how we can get rid of them? I just want to make sure that there is really no underlying issue somewhere. And if those messages really falsely appear, I would like to get rid of them if possible to avoid confusion and to stop spamming the error logs. Thank you very much in advance.

5 6

ACI Issues After 389-ds Package Upgrade
by Trenc, Mike 13 Jan '26

13 Jan '26

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? 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/>

5 5

how to apply increased search limits to a group of accounts?
by Bob Green 09 Jan '26

09 Jan '26

I have a group of 389ds accounts that all need to return query results beyond the default administrative limit. I was hoping I might apply nsSizeLimit and nsLookThroughLimit -1 to the OU where all the accounts reside and have that setting inherited by the accounts residing underneath. This does not seem to work, so I tried to create a group that would have as members the accounts that need to exceed the admin limit and where the size and look through limits were applied. This doesn't work either. I don't want to modify the default global setting and was hoping to avoid having to apply the limit settings to each account. Is there a way to apply these admin limit increases to a group of accounts without having to make the changes to each account? Bob

3 5

replication via ldaps
by Van Remoortere, Arnaud 08 Jan '26

08 Jan '26

Hi, I'm following the instructions to setup replication in CHAPTER 2. CONFIGURING SINGLE-SUPPLIER REPLICATION<https://docs.redhat.com/en-us/documentation/red_hat_directory_server/12/pdf…> USING THE WEB CONSOLE<https://docs.redhat.com/en-us/documentation/red_hat_directory_server/12/pdf…> I get a "Error (-1) - LDAP error: Can't contact LDAP server - no response received " in the GUI The logs on supplier say this: [06/Jan/2026:11:47:51.180037306 +0000] - ERR - slapi_ldap_bind - Could not send bind request for id [cn=replication manager,cn=config] authentication mechanism [SIMPLE]: error -1 (Can't contact LDAP server), system error -5987 (Invalid function argument.), network error 0 (Unknown error, host "second.xxx.com:636") LDAPS definitely is enabled and working on the secondary though, I've used ldapsearch to confirm it: ldapsearch -x -b ou=users,dc=com -H ldaps://second.xxx.com -D "cn=ldap_ro,dc=com" -W The logs on the consumer don't show anything strange There's no failed bind so it's not getting that far. Suspecting that it might have something to do with the self signed ssl I've added the primary CA cert to the secondary and vice versa, Trusted Certificate Authorities but no joy. Any help appreciated Arnaud

3 7

Metadata Inconsistency: Glue object with incorrect numSubordinates prevents deletion.
by Filip Slunecko 08 Jan '26

08 Jan '26

Hi, Following a failed replication/deletion of an OU, a residual glue object remains with corrupted metadata. Specifically, the numSubordinates attribute is inconsistent across the topology; the supplier and consumers report different values (ranging from 1 to 6) for the same DN. The entry can be moved or renamed, but standard delete operations fail. Is there a method to trigger a recalculation of numSubordinates for this entry, or a way to force-delete it despite the metadata mismatch? Filip

1 0

[ANN] LDAP Assistant MCP v0.2.0 - AI-Powered 389 DS Diagnostics
by Simon Pichugin 07 Jan '26

07 Jan '26

Hello 389 Directory Server community, I'm excited to share an experimental project: *LDAP Assistant MCP* - an AI-powered assistant for diagnosing *389 Directory Server* instances. *What is it?* LDAP Assistant MCP is a Model Context Protocol (MCP) server that enables AI models like Claude to interact with your 389 DS instances. Instead of manually running dsconf/dsctl commands and parsing output, you can ask: - "What's wrong across all my servers?" - "Check replication status and tell me if there's any lag" - "Are there any unindexed searches causing performance issues?" The assistant runs the appropriate tools and provides actionable recommendations with severity levels. *Key Features (v0.2.0)* - *Health & Diagnostics:* first_look() for multi-server health overview, run_healthcheck() equivalent to dsctl healthcheck - *Replication:* status checks, topology mapping, lag analysis (CSN comparison), conflict detection - *Performance:* cache statistics, connection analysis, operation metrics, thread utilization - *Index Analysis:* list indexes, analyze against best practices, find unindexed searches from access logs - *Configuration: *server config retrieval, multi-server comparison, plugin listing - *User & Group Management: *list, search, filter users by status, check groups *Use Cases* *Support Engineers:* Rapid root cause analysis, multi-server health scans, replication troubleshooting *LDAP Administrators:* Performance tuning, index optimization, configuration audits *Getting Started* *Prerequisites:* - Python 3.13+ - uv package manager - MCP client (Claude Desktop, Claude Code, Cursor, or any MCP-compatible client) *Quick Setup:* 1. Clone and install: git clone https://github.com/droideck/ldap-assistant-mcp.git cd ldap-assistant-mcp uv venv source .venv/bin/activate uv pip install -r requirements.txt 2. Create servers.json with your server(s). You can configure local servers (with is_local: true and serverid for full diagnostics including disk/logs/etc) or remote servers (LDAP-only). 3. Install to your MCP client: fastmcp install claude-desktop fastmcp.json or fastmcp install claude-code fastmcp.json 4. Edit MCP client config to set LDAP_SERVERS_CONFIG path to your servers.json 5. Restart and start asking questions! *Important Notes* - Experimental - Early-stage project, APIs may change - Read-only - No write operations yet - Privacy mode - Set LDAP_MCP_EXPOSE_SENSITIVE_DATA=false to anonymize output - Plain text passwords - Use restrictive file permissions on config files *Feedback* I'd love to hear your thoughts: - What diagnostics would be most useful? - What operations would you want AI assistance with? *GitHub:* https://github.com/droideck/ldap-assistant-mcp *Issues:* https://github.com/droideck/ldap-assistant-mcp/issues *References:* - *Model Context Protocol:* https://modelcontextprotocol.io/introduction - *FastMCP:* https://gofastmcp.com - *lib389: *https://pypi.org/project/lib389/ Kind regards, Simon

2 6

2026

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

389-users January 2026