389-users July 2025

389-users@lists.fedoraproject.org

10 participants
6 discussions

nsslapd-haproxy-trusted-ip is ignored
by Mitja Mihelič 21 Aug '25

21 Aug '25

Hi! I am trying to set up HAProxy with two 389DS nodes in multi-supplier setup. I have followed the instructions on https://www.port389.org/docs/389ds/howto/howto-test-haproxy-ldaps.html and https://docs.redhat.com/en/documentation/red_hat_directory_server/12/html/c…. I am using 389-ds-base-2.6.1-10.el9_6 on AlmaLinux 9.6. Please excuse the IPs and hostnames, they have been changed. I have set "nsslapd-haproxy-trusted-ip" to the following [root@389ds-node1 ~]# dsconf my-389ds-instance config add nsslapd-haproxy-trusted-ip=1.2.3.4 nsslapd-haproxy-trusted-ip=1:2:3::4 nsslapd-haproxy-trusted-ip=2.3.4.5 nsslapd-haproxy-trusted-ip=2:3:4::5 [root@389ds-node1 ~]# dsconf my-389ds-instance config get nsslapd-haproxy-trusted-ip nsslapd-haproxy-trusted-ip: 1.2.3.4 nsslapd-haproxy-trusted-ip: 2.3.4.5 nsslapd-haproxy-trusted-ip: 1:2:3::4 nsslapd-haproxy-trusted-ip: 2:3:4::5 When trying to connect through HAProxy, the client reports the following error [root@389ds-node1 ~]# ldapwhoami -vvv -H ldaps://ldap-test.example.com -D "uid=username(a)example.com,dc=example,dc=com" -x -W ldap_initialize( ldaps://ldap-test.example.com:636/??base ) ldap_result: Can't contact LDAP server (-1) Access log on 389ds-node1 reports this [25/Jul/2025:08:32:41.207106191 +0200] conn=216 fd=74 slot=74 SSL connection from 1.2.3.4 to 11.22.33.44 [25/Jul/2025:08:32:41.207237108 +0200] conn=216 op=-1 fd=74 Disconnect - Protocol error - Unknown Proxy - P4 It looks like the values in "nsslapd-haproxy-trusted-ip" are being ignored. How can I get this to work? Best regards, Mitja

2 3

Error message "Can't locate CSN in the changelog", allthough CSN is present in the changelog
by Fl Sch 12 Aug '25

12 Aug '25

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.

4 5

upgrade from DS 1.3..10 to 3.1 version question
by Ghiurea, Isabella 29 Jul '25

29 Jul '25

Hello 389-users, We are in the process of migration our past overdue 389-DS ldap system running 1.3.10 version ( member of pluging enabled) to a new VM with OS AL 9 and 389-DS version 3.1. X Here are the steps I'm thinking to follow for this migration, will this be sufficient ? - deploy new 389-ds ( version 3.1) - copy old schema:99users.ldif ---> new schema file version 3.1 - export 389-ds data(1.3) ---> import data to version 3.1 - export acis(1.3 ldapsearch) --> apply acis to 3.1 (ldapmodify) - re-run memberof pluging DS ver 3.1 - rebuild DS indexes (db2index version 3.1) When should the BASEDN be cfg ? Are any changes we need to make in dse.ldif ( version 3.1) to accommodate our DS structure ? thanks a lot!! Isabella

2 1

trouble signing the csr
by Van Remoortere, Arnaud 28 Jul '25

28 Jul '25

Hi there, I'm using the self-signed CA with a server cert generated by the installer and it's working, I'd just like to add another server cert with a subject alt name for the same server. I generated the CSR ut can't work out how to generate the certificate. I had to convert the CSR to DER format and then this is the command I'm trying: certutil -C -c "Self-Signed-CA" -i ./dirsrv_der.csr -o ./newcert.cer -m 010 -v 24 -w 1 -d /etc/dirsrv/slapd-primary/ -1 nonRepudiation,dataEncipherment -5 sslClient -6 clientAuth -7 avanremo(a)me.com The output I get from the above command is: 0 - Digital Signature 1 - Non-repudiation 2 - Key encipherment 3 - Data encipherment 4 - Key agreement 5 - Cert signing key 6 - CRL signing key Other to finish > Nothing seems to do anything at this point, selecting any number here and hitting return just pops that menu up again. Arnaud

2 1

389DS Version 3.1.3-1 on copr?
by Bryan K. Walton 09 Jul '25

09 Jul '25

Hi, We are currently running 389-ds-base and cockpit-389-ds (both version 2.2.9) from the copr repo. I've been monitoring https://copr.fedorainfracloud.org/coprs/g/389ds/389-directory-server/packag… and for the last few months, the builds for 3.1.3 have been failing. Should we be getting our 389-ds rpms from another location? Thanks, Bryan

2 2

user password change issue
by Van Remoortere, Arnaud 07 Jul '25

07 Jul '25

Hi there, I've created a posixAccount with a userPassword and can login using this user over SSH, the issue is that although "Allow Users to Change their Passwords" is selected in General Settings, I only managed to allow a user to change their own password by writing an ACI: (target="ldap:///cn=jack,ou=users,dc=lab")(targetattr="userPassword")(version 3.0; acl "password"; allow(write) userdn="ldap:///cn=jack,ou=users,dc=lab";) I'm hoping to not need an ACI for each user if there's a better way? Thanks Arnaud

3 6

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

389-users July 2025