openldap-technical December 2024

openldap-technical@openldap.org

24 participants
25 discussions

Replication issues with openldap 2.5
by Ulises Gonzalez Horta 27 Dec '24

27 Dec '24

Good morning I am trying to setup a replication in ldap 2.5, using syncrepl, I have a provider server and a consumer, both of the servers are running 2.5.11 from Ubuntu 22.04, I followed the admin guide chapter 18.3.1 to do the configuration. I have some information on the provider that is successfully being replicated to the consumer without any errors Consumer configuration ldapsearch -Y EXTERNAL -H ldapi:/// -b cn=config olcSyncRepl olcUpdateref dn: olcDatabase={1}mdb,cn=config olcSyncrepl: {0}rid=100 provider=ldap://provider:389 type=refr eshOnly interval=00:00:05:00 retry="300 +" searchbase="dc=metrocast,dc=net" f ilter="(|(entryDN:=dc=metrocast,dc=net)(entryDN:dnOneLevelMatch:=dc=metrocast ,dc=net)(&(entryDN:dnSubtreeMatch:=dc=metrocast,dc=net)(entrydn:dnSubtreeMatc h:=ou=Boxes,dc=metrocast,dc=net))(&(entryDN:dnSubtreeMatch:=dc=metrocast,dc=n et)(entrydn:dnSubtreeMatch:=ou=RadiusGroups,dc=metrocast,dc=net))(&(entryDN:d nSubtreeMatch:=dc=metrocast,dc=net)(entrydn:dnSubtreeMatch:=ou=group,dc=metro cast,dc=net))(&(entryDN:dnSubtreeMatch:=dc=metrocast,dc=net)(entryDN:distingu ishedNameMatch:=ou=People,dc=metrocast,dc=net))(&(entryDN:dnSubtreeMatch:=dc= metrocast,dc=net)(entryDN:dnSubtreeMatch:=ou=employees,dc=metrocast,dc=net))) " timelimit=unlimited sizelimit=unlimited bindmethod=simple binddn="cn=user,ou=boxes,dc=metrocast,dc=net" credentials="xxxx" start tls=critical tls_cacertdir="/etc/ldap/certs" olcUpdateRef: ldap://ldap-write.metrocast.net:389 I can confirm the DIT is present on the consumer and the values matches the provider item by item, including the encrypted passwords, The issue I am having is that a query that runs on the provider without any issue is failing to run on the consumer with error 49 invalid credentials, but I do know for sure that the provided credentials are good, I even did a tcpdump and confirmed they are fine On the provider a query similar to this one runs fine and returns a result ldapsearch -Z -LLL -H ldap://providert:389 -D "uid=user1,ou=employees,dc=metrocast,dc=net" -W -b "ou=employees,dc=metrocast,dc=net" "(mail=*pepe(a)breezeline.com) On the consumer this same query returns error 49 ldapsearch -Z -LLL -H ldap://providert:389 -D "uid=user1,ou=employees,dc=metrocast,dc=net" -W -b "ou=employees,dc=metrocast,dc=net" "(mail=*pepe(a)breezeline.com) I confirmed with ldapsearch -Y EXTERNAL -H ldapi:/// ..... that the information for user1 is exactly the same in the provider and the consumer for all the attributes including the passwords. Tcpdump confirmed that I am sending the right password, doing -W or -w $password gives the same result. For any user I use to run the query I get exactly the same error 49, I did verify that ACLs are not blocking the query. Is there anything else I should check?? any log level that could help me identify where the error is?? Currently my loglevel is olcLogLevel: 128 256 1024 This is a dev environment so I can do changes at will. Thanks and happy new year Ulises Gonzalez Horta Lead Linux Engineer C: 786 450 2970/ 240 727 6267 E: ugonzalezhorta(a)breezeline.com <jsutherland1(a)breezeline.com>

2 1

Re: consumer replication net recovering
by Suresh Veliveli 23 Dec '24

23 Dec '24

Pretty sure It didn't hit the defined maxsize. -rw-------. 1 ldap_svc ldap_svc 108993459200 Dec 20 17:36 data.mdb du -c -h data.mdb 5.2G data.mdb 5.2G total I don't see any "syncrepl_sync" references in the replica logs. The loglevel is "stats sync". Am I missing something? Thanks, Suresh On Fri, Dec 20, 2024 at 5:15 PM Quanah Gibson-Mount <quanah(a)fast-mail.org> wrote: > > > --On Friday, December 20, 2024 2:07 PM -0500 Suresh Veliveli > <Suresh.Veliveli(a)georgetown.edu> wrote: > > > > > I do have sync logging enabled. This is the last record in the log file, > > and after that, nothing. It isn't attempting to get changes. > > One thing I'd confirm is that you haven't hit the defined maxsize of your > MDB database. > > Also, I don't see the result in what you posted for the operation. You > seem to have excluded all the "syncrepl_sync" log lines which are critical. > > --Quanah > > -- Suresh Veliveli Sr. UNIX Systems Engineer Georgetown University University Information Services | Security Infrastructure and Policy-Identity and Collaboration 202-262-6676 (cell) | 202-687-3108 (work)

2 2

Re: consumer replication net recovering
by Suresh Veliveli 20 Dec '24

20 Dec '24

I do have sync logging enabled. This is the last record in the log file, and after that, nothing. It isn't attempting to get changes. Log on the replica: Dec 12 08:59:30 aaa-prod-gcp-9 slapd[4165]: slap_queue_csn: queueing 0x7f67101bc860 20241212135921.652395Z#000000#000#000000 Dec 12 08:59:30 aaa-prod-gcp-9 slapd[4165]: slap_graduate_commit_csn: removing 0x7f67101bc860 20241212135921.652395Z#000000#000#000000 Dec 12 08:59:30 aaa-prod-gcp-9 slapd[4165]: slap_queue_csn: queueing 0x7f67102311b0 20241212135921.652395Z#000000#000#000000 Dec 12 08:59:30 aaa-prod-gcp-9 slapd[4165]: slap_graduate_commit_csn: removing 0x7f67102311b0 2*0241212135921.652395Z#000000#000#000000* *Log on the master:* Dec 12 08:59:30 aaa-prod-master-1 slapd[4072]: conn=936345 op=1 syncprov_sendresp: cookie=rid=129,csn=20241212135921.637305Z#000000#000#000000 *Dec 12 08:59:30 aaa-prod-master-1 slapd[4072]: conn=936345 op=1 syncprov_sendresp: cookie=rid=129,csn=20241212135921.652395Z#000000#000#000000* There is nothing in the log on the master or the replica after this entry. Regards, Suresh On Fri, Dec 20, 2024 at 1:40 PM Quanah Gibson-Mount <quanah(a)fast-mail.org> wrote: > > > --On Friday, December 20, 2024 11:22 AM -0500 Suresh Veliveli > <Suresh.Veliveli(a)georgetown.edu> wrote: > > > > > > > > > Hi, > > > > > > We have a single master with multiple replicas. Our backend is mdb, and > > we are on the latest version, 2.6.9. The replication type > > is refreshAndPersist. Here is the relevant configuration. > > > > > > syncrepl rid=141 > > provider=ldaps://ldap-master.georgetown.edu:636/ > > type=refreshAndPersist > > > > .. > > .. > > keepalive=300:5:5 retry="5 5 300 +" > > > > > > > > This is now happening at regular intervals. When a consumer replication > > gets stuck, only a service restart seems to restart replication. > > > Need more information on what you mean by "getting stuck". Is it actually > attemping to get changes? Do you have sync logging enabled? If so, you > could see if that particular consumer is having an issue during > replication > and returning a non-zero result code as to why it's unable to proceed. Or > is it not establishing a replication connection at all? etc. > > --Quanah > > > -- Suresh Veliveli Sr. UNIX Systems Engineer Georgetown University University Information Services | Security Infrastructure and Policy-Identity and Collaboration 202-262-6676 (cell) | 202-687-3108 (work)

2 1

consumer replication net recovering
by Suresh Veliveli 20 Dec '24

20 Dec '24

Hi, We have a single master with multiple replicas. Our backend is mdb, and we are on the latest version, 2.6.9. The replication type is refreshAndPersist. Here is the relevant configuration. syncrepl rid=141 provider=ldaps://ldap-master.georgetown.edu:636/ type=refreshAndPersist .. .. keepalive=300:5:5 retry="5 5 300 +" This is now happening at regular intervals. When a consumer replication gets stuck, only a service restart seems to restart replication. ex: ldap-replica-1:1636 # requesting: contextCSN contextCSN: 20241212135921.652395Z#000000#000#000000 ldap-replica-1:2636 # requesting: contextCSN contextCSN: 20241220010002.746041Z#000000#000#000000 You can see the replica on port 1636 CSN is stuck at 20241212135921. Any thoughts? Thanks, -- Suresh Veliveli Sr. UNIX Systems Engineer Georgetown University University Information Services | Security Infrastructure and Policy-Identity and Collaboration 202-262-6676 (cell) | 202-687-3108 (work)

2 1

Replication Specifics and Clarification
by michael.miceli88＠gmail.com 19 Dec '24

19 Dec '24

Hi, this is my first post to this mailing list, so I apologize if this is in the wrong location. I have recently started replicating our openLdap database and as part of that I combed through the admin guide to get a better understanding. I believe I have a decent grasp on replication now, but I had a few clarifying questions to ensure I understand. 1. Firstly and least importantly, how is "present" in "present phase" pronounced? Is it present as a noun, e.g. these are things that are present in the database, or is it present like a verb, e.g. I'm presenting all the things in the database? 2. Besides not needing to send the entire object in the delete phase, is it true that delta-syncrRepl provides an additional benefit of having a persisted session log store, e.g. the session store can survive an openLdap reboot? I didn't see that explicitly mentioned in the admin guide, but it would seem to be to be true. Is it true? 3. Does having a session log configured make sense if delta-syncrepl is being used? I saw a non-authoritative guides saying it's nice to have just in case a fallback to syncrepl happens, but the admin guide doesn't do this anywhere, nor does it make sense to me since even if a consumer provides a stale session cookie, a present phase must occur regardless of a session log. 4. I found in a non-authoritative document online saying during the refresh stage, that either present or delete or both phases can occur. In what situation would both a present and a delete phase occur? Or is that document wrong? 5. Does the phrase "delete phase" feel confusingly named? I spent significant time trying to figure out how data would be synchronized when a non-stale cookie was provided by the consumer since I assumed the delete phase only handled deletes. It wasn't until I read this paragraph carefully in the admin guide. In fact, no where in the admin guide can I find explicit mention that adds occur in the delete phase as well. However, it can be inferred in the last sentence of the following quote. > The transmission of the updated entries in the delete phase is the same as in the present phase. The provider sends all the requested attributes of the entries updated within the search scope since the last synchronization to the consumer. In the delete phase, however, the provider sends a delete message for each entry deleted from the search scope, instead of sending present messages. The delete message consists only of the name of the entry and the synchronization control representing state delete. The new consumer copy can be determined by adding, modifying, and removing entries according to the synchronization control attached to the SearchResultEntry message.

3 3

Problem getting slapd-meta to work
by cyril＠stoll.info 18 Dec '24

18 Dec '24

Hi there Sorry for the long post however I aim to provide as much information as possible to help pinpoint the issue. Also sorry for any wrong wording as I am still a bit overwhelmed with OpenLDAP and struggle to understand everything I need. From my predecessor I inherited an OpenLDAP 2.4.x cluster running on RHEL 7. My job is to migrate this cluster to OpenLDAP 2.6.x on RHEL 8. The cluster consists of two provider and four consumer servers. The old cluster was based on self-compiled original OpenLDAP binaries. For the new cluster I am using the LTB version of OpenLDAP, currently with version 2.6.8. I also switched from HDB to MDB with the new cluster and am using Let's Encrypt instead of DigiCert certificates and upped the TLS version from 1.0 to 1.2. And for the default password hashing algorhythm I switched from SSHA to ARGON2. So there are lots of changes that might potentially influence the meta databases though I did not see anything that suggests this. The synchronisation of the normal databases between the provider servers and to the consumer servers is working fine. My problem is with the meta databases I try to build using slapd-meta. They are only needed on the consumer servers. Unfortunately the meta databases do not seem to be created or are not working as expected. On the old cluster I can ldapsearch in the meta databases and they show up as trees when connecting with Apache Directory Studio. On the new cluster I am setting up I don't see those meta trees in Apache Directory Studio and ldapsearches don't return any results. Furthermore slapcat on those databases returns the message "slapcat: database doesn't support necessary operations." The meta trees don't query external servers but suffixmassage locally present sub-trees. From what I've read this could also be accomplished with slapd-relay but the man page states that it is experimental. That is why I am trying the same way my predecessor did using slapd-meta. I temporarily set the loglevel to 4094 but even then did not see any hint on what goes wrong with those meta databases. By the way, when I do set the loglevel so high I can no longer connect using Apache Directory Studio, but that is not the issue I'm concerned about. Neither the documentation, nor the slapd-meta man page, nor the very few tutorials/stackexchange-posts/mailinglist-posts I found online about meta-back helped me in solving this issue. That is why I hope someone on this mailinglist can spot an issue in my configuration. Or point me to other resources/tutorials or share some debugging advice. For the purpose of sharing the configuration I omitted all the schemata and some of the ACLs. Also I removed the linebreaks so what belongs together is all on one line. Lastly I redacted any sensitive information. It is attached as a text/ldif file. Thanks a lot in advance and let me know if I need to share further information such as log entries etc. Best regards, Cyril

3 2

Replication Issue with OpenLDAP 2.6.3
by mridumit＠amdocs.com 18 Dec '24

18 Dec '24

Hi I am very new to OpenLDAP, and we have a multi master configuration with us and our replication is not working. The error we get in log file is mainly : slap_client_connect: URI=<provider url> DN="cn=<sample value>,dc=<sample value>,dc=<sample value>" ldap_sasl_bind_s failed (-1). Attaching below logs after starting slapd service , Could you please help us ? Oct 16 14:15:47 <our ldap host> slapd[853101]: @(#) $OpenLDAP: slapd 2.6.3 (Nov 15 2023 00:00:00) $#012#011openldap Oct 16 14:15:47 <our ldap host> slapd[853101]: /etc/openldap/slapd.conf: line 11 (TLSProtocolMin 3.3) Oct 16 14:15:47 <our ldap host> slapd[853101]: /etc/openldap/slapd.conf: line 12 (TLSCertificateFile <path to crt file>) Oct 16 14:15:47 <our ldap host> slapd[853101]: /etc/openldap/slapd.conf: line 13 (TLSCertificateKeyFile <path to key file file>) Oct 16 14:15:47 <our ldap host> slapd[853101]: /etc/openldap/slapd.conf: line 14 (TLSCipherSuite ECDHE-RSA-AES256-SHA) Oct 16 14:15:47 <our ldap host> slapd[853101]: /etc/openldap/slapd.conf: line 17 (disallow bind_anon) Oct 16 14:15:47 <our ldap host> slapd[853101]: /etc/openldap/slapd.conf: line 19 (require bind) Oct 16 14:15:47 <our ldap host> slapd[853101]: /etc/openldap/slapd.conf: line 21 (security simple_bind=128) Oct 16 14:15:47 <our ldap host> slapd[853101]: /etc/openldap/slapd.conf: line 23 (serverID 001) Oct 16 14:15:47 <our ldap host> slapd[853101]: /etc/openldap/slapd.conf: line 23: SID=0x001 Oct 16 14:15:47 <our ldap host> slapd[853101]: /etc/openldap/slapd.conf: line 25 (moduleload syncprov) Oct 16 14:15:47 <our ldap host> slapd[853101]: loaded module syncprov Oct 16 14:15:47 <our ldap host> slapd[853101]: module syncprov: null module registered Oct 16 14:15:47 <our ldap host> slapd[853101]: /etc/openldap/slapd.conf: line 28 (database config) Oct 16 14:15:47 <our ldap host> slapd[853101]: /etc/openldap/slapd.conf: line 29 (rootdn cn=admin,cn=config) Oct 16 14:15:47 <our ldap host> slapd[853101]: >>> dnPrettyNormal: <cn=admin,cn=config> Oct 16 14:15:47 <our ldap host> slapd[853101]: <<< dnPrettyNormal: <cn=admin,cn=config>, <cn=admin,cn=config> Oct 16 14:15:47 <our ldap host> slapd[853101]: /etc/openldap/slapd.conf: line 30 (rootpw ***) Oct 16 14:15:47 <our ldap host> slapd[853101]: /etc/openldap/slapd.conf: line 33 (database monitor) Oct 16 14:15:47 <our ldap host> slapd[853101]: >>> dnPrettyNormal: <cn=Monitor> Oct 16 14:15:47 <our ldap host> slapd[853101]: <<< dnPrettyNormal: <cn=Monitor>, <cn=monitor> Oct 16 14:15:47 <our ldap host> slapd[853101]: /etc/openldap/slapd.conf: line 36 (database mdb) Oct 16 14:15:47 <our ldap host> slapd[853101]: mdb_db_init: Initializing mdb database Oct 16 14:15:47 <our ldap host> slapd[853101]: /etc/openldap/slapd.conf: line 37 (suffix dc=<sample value>,dc=com) Oct 16 14:15:47 <our ldap host> slapd[853101]: >>> dnPrettyNormal: <dc=<sample value>,dc=com> Oct 16 14:15:47 <our ldap host> slapd[853101]: <<< dnPrettyNormal: <dc=<sample value>,dc=com>, <dc=<sample value>,dc=com> Oct 16 14:15:47 <our ldap host> slapd[853101]: /etc/openldap/slapd.conf: line 38 (rootdn cn=Manager,dc=<sample value>,dc=com) Oct 16 14:15:47 <our ldap host> slapd[853101]: >>> dnPrettyNormal: <cn=Manager,dc=<sample value>,dc=com> Oct 16 14:15:47 <our ldap host> slapd[853101]: <<< dnPrettyNormal: <cn=Manager,dc=<sample value>,dc=com>, <cn=manager,dc=<sample value>,dc=com> Oct 16 14:15:47 <our ldap host> slapd[853101]: /etc/openldap/slapd.conf: line 39 (rootpw ***) Oct 16 14:15:47 <our ldap host> slapd[853101]: /etc/openldap/slapd.conf: line 40 (directory /home/ldap) Oct 16 14:15:47 <our ldap host> slapd[853101]: /etc/openldap/slapd.conf: line 49 (syncrepl ***) Oct 16 14:15:47 <our ldap host> slapd[853101]: >>> dnNormalize: <cn=<sample value>,dc=<sample value>,dc=com> Oct 16 14:15:47 <our ldap host> slapd[853101]: <<< dnNormalize: <cn=<sample value>,dc=<sample value>,dc=com> Oct 16 14:15:47 <our ldap host> slapd[853101]: >>> dnNormalize: <dc=<sample value>,dc=com> Oct 16 14:15:47 <our ldap host> slapd[853101]: <<< dnNormalize: <dc=<sample value>,dc=com> Oct 16 14:15:47 <our ldap host> slapd[853101]: str2filter "(objectclass=*)" Oct 16 14:15:47 <our ldap host> slapd[853101]: begin get_filter Oct 16 14:15:47 <our ldap host> slapd[853101]: PRESENT Oct 16 14:15:47 <our ldap host> slapd[853101]: end get_filter 0 Oct 16 14:15:47 <our ldap host> slapd[853101]: Config: ** successfully added syncrepl rid=001 "<provider url>" Oct 16 14:15:47 <our ldap host> slapd[853101]: /etc/openldap/slapd.conf: line 51 (mirrormode TRUE) Oct 16 14:15:47 <our ldap host> slapd[853101]: /etc/openldap/slapd.conf: line 52 (multiprovider on) Oct 16 14:15:47 <our ldap host> slapd[853101]: /etc/openldap/slapd.conf: line 55 (index entryCSN eq) Oct 16 14:15:47 <our ldap host> slapd[853101]: index entryCSN 0x0004 Oct 16 14:15:47 <our ldap host> slapd[853101]: /etc/openldap/slapd.conf: line 56 (index entryUUID eq ) Oct 16 14:15:47 <our ldap host> slapd[853101]: index entryUUID 0x0004 Oct 16 14:15:47 <our ldap host> slapd[853101]: /etc/openldap/slapd.conf: line 58 (index objectClass eq) Oct 16 14:15:47 <our ldap host> slapd[853101]: index objectClass 0x0004 Oct 16 14:15:47 <our ldap host> slapd[853101]: /etc/openldap/slapd.conf: line 59 (index ps eq) Oct 16 14:15:47 <our ldap host> slapd[853101]: index ps 0x0004 Oct 16 14:15:47 <our ldap host> slapd[853101]: /etc/openldap/slapd.conf: line 60 (index <sample value>-safe-id eq) Oct 16 14:15:47 <our ldap host> slapd[853101]: index <sample value>--id 0x0004 Oct 16 14:15:47 <our ldap host> slapd[853101]: /etc/openldap/slapd.conf: line 61 (checkpoint 128 15) Oct 16 14:15:47 <our ldap host> slapd[853101]: /etc/openldap/slapd.conf: line 64 (overlay syncprov) Oct 16 14:15:47 <our ldap host> slapd[853101]: /etc/openldap/slapd.conf: line 66 (syncprov-checkpoint 100 10) Oct 16 14:15:47 <our ldap host> slapd[853101]: /etc/openldap/slapd.conf: line 72 (limits dn.exact=cn=<sample value>,dc=<sample value>,dc=com size=unlimited time=unlimited) Oct 16 14:15:47 <our ldap host> slapd[853101]: >>> dnNormalize: <cn=<sample value>,dc=<sample value>,dc=com> Oct 16 14:15:47 <our ldap host> slapd[853101]: <<< dnNormalize: <cn=<sample value>,dc=<sample value>,dc=com> Oct 16 14:15:47 <our ldap host> slapd[853101]: >>> dnNormalize: <cn=Subschema> Oct 16 14:15:47 <our ldap host> slapd[853101]: <<< dnNormalize: <cn=subschema> Oct 16 14:15:47 <our ldap host> slapd[853103]: slapd startup: initiated. Oct 16 14:15:47 <our ldap host> slapd[853103]: backend_startup_one: starting "cn=config" Oct 16 14:15:47 <our ldap host> slapd[853103]: config_back_db_open Oct 16 14:15:47 <our ldap host> slapd[853103]: config_back_db_open: line 0: warning: cannot assess the validity of the ACL scope within backend naming context Oct 16 14:15:47 <our ldap host> slapd[853103]: config_back_db_open: No explicit ACL for back-config configured. Using hardcoded default Oct 16 14:15:47 <our ldap host> slapd[853103]: config_build_entry: "cn=config" Oct 16 14:15:47 <our ldap host> slapd[853103]: slap_get_csn: conn=-1 op=0 generated new csn=20241016084547.895827Z#000000#001#000000 manage=0 Oct 16 14:15:47 <our ldap host> slapd[853103]: config_build_entry: "cn=module{0}" Oct 16 14:15:47 <our ldap host> slapd[853103]: slap_get_csn: conn=-1 op=0 generated new csn=20241016084547.896054Z#000000#001#000000 manage=0 Oct 16 14:15:47 <our ldap host> slapd[853103]: config_build_entry: "cn=schema" Oct 16 14:15:47 <our ldap host> slapd[853103]: slap_get_csn: conn=-1 op=0 generated new csn=20241016084547.897011Z#000000#001#000000 manage=0 Oct 16 14:15:47 <our ldap host> slapd[853103]: >>> dnNormalize: <cn={0}core> Oct 16 14:15:47 <our ldap host> slapd[853103]: <<< dnNormalize: <cn={0}core> Oct 16 14:15:47 <our ldap host> slapd[853103]: config_build_entry: "cn={0}core" Oct 16 14:15:47 <our ldap host> slapd[853103]: slap_get_csn: conn=-1 op=0 generated new csn=20241016084547.899435Z#000000#001#000000 manage=0 Oct 16 14:15:47 <our ldap host> slapd[853103]: >>> dnNormalize: <cn={1}> Oct 16 14:15:47 <our ldap host> slapd[853103]: <<< dnNormalize: <cn={1}> Oct 16 14:15:47 <our ldap host> slapd[853103]: config_build_entry: "cn={1}" Oct 16 14:15:47 <our ldap host> slapd[853103]: slap_get_csn: conn=-1 op=0 generated new csn=20241016084547.903375Z#000000#001#000000 manage=0 Oct 16 14:15:47 <our ldap host> slapd[853103]: config_build_entry: "olcDatabase={-1}frontend" Oct 16 14:15:47 <our ldap host> slapd[853103]: slap_get_csn: conn=-1 op=0 generated new csn=20241016084547.903549Z#000000#001#000000 manage=0 Oct 16 14:15:47 <our ldap host> slapd[853103]: config_build_entry: "olcDatabase={0}config" Oct 16 14:15:47 <our ldap host> slapd[853103]: slap_get_csn: conn=-1 op=0 generated new csn=20241016084547.903679Z#000000#001#000000 manage=0 Oct 16 14:15:47 <our ldap host> slapd[853103]: config_build_entry: "olcDatabase={1}monitor" Oct 16 14:15:47 <our ldap host> slapd[853103]: slap_get_csn: conn=-1 op=0 generated new csn=20241016084547.903828Z#000000#001#000000 manage=0 Oct 16 14:15:47 <our ldap host> slapd[853103]: config_build_entry: "olcDatabase={2}mdb" Oct 16 14:15:47 <our ldap host> slapd[853103]: slap_get_csn: conn=-1 op=0 generated new csn=20241016084547.904066Z#000000#001#000000 manage=0 Oct 16 14:15:47 <our ldap host> slapd[853103]: config_build_entry: "olcOverlay={0}syncprov" Oct 16 14:15:47 <our ldap host> slapd[853103]: slap_get_csn: conn=-1 op=0 generated new csn=20241016084547.904212Z#000000#001#000000 manage=0 Oct 16 14:15:47 <our ldap host> slapd[853103]: backend_startup_one: starting "cn=Monitor" Oct 16 14:15:47 <our ldap host> slapd[853103]: >>> dnNormalize: <cn=Monitor> Oct 16 14:15:47 <our ldap host> slapd[853103]: <<< dnNormalize: <cn=monitor> Oct 16 14:15:47 <our ldap host> slapd[853103]: >>> dnPretty: <cn=Backends> Oct 16 14:15:47 <our ldap host> slapd[853103]: <<< dnPretty: <cn=Backends> Oct 16 14:15:47 <our ldap host> slapd[853103]: >>> dnNormalize: <cn=Backends> Oct 16 14:15:47 <our ldap host> slapd[853103]: <<< dnNormalize: <cn=backends> Oct 16 14:15:47 <our ldap host> slapd[853103]: >>> dnPretty: <cn=Connections> Oct 16 14:15:47 <our ldap host> slapd[853103]: <<< dnPretty: <cn=Connections> Oct 16 14:15:47 <our ldap host> slapd[853103]: >>> dnNormalize: <cn=Connections> Oct 16 14:15:47 <our ldap host> slapd[853103]: <<< dnNormalize: <cn=connections> Oct 16 14:15:47 <our ldap host> slapd[853103]: >>> dnPretty: <cn=Databases> Oct 16 14:15:47 <our ldap host> slapd[853103]: <<< dnPretty: <cn=Databases> Oct 16 14:15:47 <our ldap host> slapd[853103]: >>> dnNormalize: <cn=Databases> Oct 16 14:15:47 <our ldap host> slapd[853103]: <<< dnNormalize: <cn=databases> Oct 16 14:15:47 <our ldap host> slapd[853103]: >>> dnPretty: <cn=Listeners> Oct 16 14:15:47 <our ldap host> slapd[853103]: <<< dnPretty: <cn=Listeners> Oct 16 14:15:47 <our ldap host> slapd[853103]: >>> dnNormalize: <cn=Listeners> Oct 16 14:15:47 <our ldap host> slapd[853103]: <<< dnNormalize: <cn=listeners> Oct 16 14:15:47 <our ldap host> slapd[853103]: >>> dnPretty: <cn=Log> Oct 16 14:15:47 <our ldap host> slapd[853103]: <<< dnPretty: <cn=Log> Oct 16 14:15:47 <our ldap host> slapd[853103]: >>> dnNormalize: <cn=Log> Oct 16 14:15:47 <our ldap host> slapd[853103]: <<< dnNormalize: <cn=log> Oct 16 14:15:47 <our ldap host> slapd[853103]: >>> dnPretty: <cn=Operations> Oct 16 14:15:47 <our ldap host> slapd[853103]: <<< dnPretty: <cn=Operations> Oct 16 14:15:47 <our ldap host> slapd[853103]: >>> dnNormalize: <cn=Operations> Oct 16 14:15:47 <our ldap host> slapd[853103]: <<< dnNormalize: <cn=operations> Oct 16 14:15:47 <our ldap host> slapd[853103]: >>> dnPretty: <cn=Overlays> Oct 16 14:15:47 <our ldap host> slapd[853103]: <<< dnPretty: <cn=Overlays> Oct 16 14:15:47 <our ldap host> slapd[853103]: >>> dnNormalize: <cn=Overlays> Oct 16 14:15:47 <our ldap host> slapd[853103]: <<< dnNormalize: <cn=overlays> Oct 16 14:15:47 <our ldap host> slapd[853103]: >>> dnPretty: <cn=SASL> Oct 16 14:15:47 <our ldap host> slapd[853103]: <<< dnPretty: <cn=SASL> Oct 16 14:15:47 <our ldap host> slapd[853103]: >>> dnNormalize: <cn=SASL> Oct 16 14:15:47 <our ldap host> slapd[853103]: <<< dnNormalize: <cn=sasl> Oct 16 14:15:47 <our ldap host> slapd[853103]: >>> dnPretty: <cn=Statistics> Oct 16 14:15:47 <our ldap host> slapd[853103]: <<< dnPretty: <cn=Statistics> Oct 16 14:15:47 <our ldap host> slapd[853103]: >>> dnNormalize: <cn=Statistics> Oct 16 14:15:47 <our ldap host> slapd[853103]: <<< dnNormalize: <cn=statistics> Oct 16 14:15:47 <our ldap host> slapd[853103]: >>> dnPretty: <cn=Threads> Oct 16 14:15:47 <our ldap host> slapd[853103]: <<< dnPretty: <cn=Threads> Oct 16 14:15:47 <our ldap host> slapd[853103]: >>> dnNormalize: <cn=Threads> Oct 16 14:15:47 <our ldap host> slapd[853103]: <<< dnNormalize: <cn=threads> Oct 16 14:15:47 <our ldap host> slapd[853103]: >>> dnPretty: <cn=Time> Oct 16 14:15:47 <our ldap host> slapd[853103]: <<< dnPretty: <cn=Time> Oct 16 14:15:47 <our ldap host> slapd[853103]: >>> dnNormalize: <cn=Time> Oct 16 14:15:47 <our ldap host> slapd[853103]: <<< dnNormalize: <cn=time> Oct 16 14:15:47 <our ldap host> slapd[853103]: >>> dnPretty: <cn=TLS> Oct 16 14:15:47 <our ldap host> slapd[853103]: <<< dnPretty: <cn=TLS> Oct 16 14:15:47 <our ldap host> slapd[853103]: >>> dnNormalize: <cn=TLS> Oct 16 14:15:47 <our ldap host> slapd[853103]: <<< dnNormalize: <cn=tls> Oct 16 14:15:47 <our ldap host> slapd[853103]: >>> dnPretty: <cn=Waiters> Oct 16 14:15:47 <our ldap host> slapd[853103]: <<< dnPretty: <cn=Waiters> Oct 16 14:15:47 <our ldap host> slapd[853103]: >>> dnNormalize: <cn=Waiters> Oct 16 14:15:47 <our ldap host> slapd[853103]: <<< dnNormalize: <cn=waiters> Oct 16 14:15:47 <our ldap host> slapd[853103]: >>> dnNormalize: <cn=Backend 0> Oct 16 14:15:47 <our ldap host> slapd[853103]: <<< dnNormalize: <cn=backend 0> Oct 16 14:15:47 <our ldap host> slapd[853103]: >>> dnNormalize: <cn=Database 0,cn=Databases,cn=Monitor> Oct 16 14:15:47 <our ldap host> slapd[853103]: <<< dnNormalize: <cn=database 0,cn=databases,cn=monitor> Oct 16 14:15:47 <our ldap host> slapd[853103]: >>> dnNormalize: <cn=Backend 1> Oct 16 14:15:47 <our ldap host> slapd[853103]: <<< dnNormalize: <cn=backend 1> Oct 16 14:15:47 <our ldap host> slapd[853103]: >>> dnNormalize: <cn=Backend 2> Oct 16 14:15:47 <our ldap host> slapd[853103]: <<< dnNormalize: <cn=backend 2> Oct 16 14:15:47 <our ldap host> slapd[853103]: >>> dnNormalize: <cn=Database 1,cn=Databases,cn=Monitor> Oct 16 14:15:47 <our ldap host> slapd[853103]: <<< dnNormalize: <cn=database 1,cn=databases,cn=monitor> Oct 16 14:15:47 <our ldap host> slapd[853103]: >>> dnNormalize: <cn=Backend 3> Oct 16 14:15:47 <our ldap host> slapd[853103]: <<< dnNormalize: <cn=backend 3> Oct 16 14:15:47 <our ldap host> slapd[853103]: >>> dnNormalize: <cn=Backend 4> Oct 16 14:15:47 <our ldap host> slapd[853103]: <<< dnNormalize: <cn=backend 4> Oct 16 14:15:47 <our ldap host> slapd[853103]: >>> dnNormalize: <cn=Max File Descriptors> Oct 16 14:15:47 <our ldap host> slapd[853103]: <<< dnNormalize: <cn=max file descriptors> Oct 16 14:15:47 <our ldap host> slapd[853103]: >>> dnNormalize: <cn=Total> Oct 16 14:15:47 <our ldap host> slapd[853103]: <<< dnNormalize: <cn=total> Oct 16 14:15:47 <our ldap host> slapd[853103]: >>> dnNormalize: <cn=Current> Oct 16 14:15:47 <our ldap host> slapd[853103]: <<< dnNormalize: <cn=current> Oct 16 14:15:47 <our ldap host> slapd[853103]: >>> dnNormalize: <cn=Frontend> Oct 16 14:15:47 <our ldap host> slapd[853103]: <<< dnNormalize: <cn=frontend> Oct 16 14:15:47 <our ldap host> slapd[853103]: >>> dnNormalize: <cn=Database 0> Oct 16 14:15:47 <our ldap host> slapd[853103]: <<< dnNormalize: <cn=database 0> Oct 16 14:15:47 <our ldap host> slapd[853103]: >>> dnNormalize: <cn=Backend 0,cn=Backends,cn=Monitor> Oct 16 14:15:47 <our ldap host> slapd[853103]: <<< dnNormalize: <cn=backend 0,cn=backends,cn=monitor> Oct 16 14:15:47 <our ldap host> slapd[853103]: >>> dnNormalize: <cn=Database 1> Oct 16 14:15:47 <our ldap host> slapd[853103]: <<< dnNormalize: <cn=database 1> Oct 16 14:15:47 <our ldap host> slapd[853103]: >>> dnNormalize: <cn=Backend 2,cn=Backends,cn=Monitor> Oct 16 14:15:47 <our ldap host> slapd[853103]: <<< dnNormalize: <cn=backend 2,cn=backends,cn=monitor> Oct 16 14:15:47 <our ldap host> slapd[853103]: >>> dnNormalize: <cn=Database 2> Oct 16 14:15:47 <our ldap host> slapd[853103]: <<< dnNormalize: <cn=database 2> Oct 16 14:15:47 <our ldap host> slapd[853103]: >>> dnNormalize: <cn=Overlay 1,cn=Overlays,cn=Monitor> Oct 16 14:15:47 <our ldap host> slapd[853103]: <<< dnNormalize: <cn=overlay 1,cn=overlays,cn=monitor> Oct 16 14:15:47 <our ldap host> slapd[853103]: >>> dnNormalize: <cn=Backend 3,cn=Backends,cn=Monitor> Oct 16 14:15:47 <our ldap host> slapd[853103]: <<< dnNormalize: <cn=backend 3,cn=backends,cn=monitor> Oct 16 14:15:47 <our ldap host> slapd[853103]: >>> dnNormalize: <cn=Overlay 0> Oct 16 14:15:47 <our ldap host> slapd[853103]: <<< dnNormalize: <cn=overlay 0> Oct 16 14:15:47 <our ldap host> slapd[853103]: >>> dnNormalize: <cn=Overlay 1,cn=Overlays,cn=Monitor> Oct 16 14:15:47 <our ldap host> slapd[853103]: <<< dnNormalize: <cn=overlay 1,cn=overlays,cn=monitor> Oct 16 14:15:47 <our ldap host> slapd[853103]: >>> dnNormalize: <cn=Listener 0> Oct 16 14:15:47 <our ldap host> slapd[853103]: <<< dnNormalize: <cn=listener 0> Oct 16 14:15:47 <our ldap host> slapd[853103]: >>> dnNormalize: <cn=Listener 1> Oct 16 14:15:47 <our ldap host> slapd[853103]: <<< dnNormalize: <cn=listener 1> Oct 16 14:15:47 <our ldap host> slapd[853103]: >>> dnNormalize: <cn=Listener 2> Oct 16 14:15:47 <our ldap host> slapd[853103]: <<< dnNormalize: <cn=listener 2> Oct 16 14:15:47 <our ldap host> slapd[853103]: >>> dnNormalize: <cn=Listener 3> Oct 16 14:15:47 <our ldap host> slapd[853103]: <<< dnNormalize: <cn=listener 3> Oct 16 14:15:47 <our ldap host> slapd[853103]: >>> dnNormalize: <cn=Listener 4> Oct 16 14:15:47 <our ldap host> slapd[853103]: <<< dnNormalize: <cn=listener 4> Oct 16 14:15:47 <our ldap host> slapd[853103]: >>> dnNormalize: <cn=Bind> Oct 16 14:15:47 <our ldap host> slapd[853103]: <<< dnNormalize: <cn=bind> Oct 16 14:15:47 <our ldap host> slapd[853103]: >>> dnNormalize: <cn=Unbind> Oct 16 14:15:47 <our ldap host> slapd[853103]: <<< dnNormalize: <cn=unbind> Oct 16 14:15:47 <our ldap host> slapd[853103]: >>> dnNormalize: <cn=Search> Oct 16 14:15:47 <our ldap host> slapd[853103]: <<< dnNormalize: <cn=search> Oct 16 14:15:47 <our ldap host> slapd[853103]: >>> dnNormalize: <cn=Compare> Oct 16 14:15:47 <our ldap host> slapd[853103]: <<< dnNormalize: <cn=compare> Oct 16 14:15:47 <our ldap host> slapd[853103]: >>> dnNormalize: <cn=Modify> Oct 16 14:15:47 <our ldap host> slapd[853103]: <<< dnNormalize: <cn=modify> Oct 16 14:15:47 <our ldap host> slapd[853103]: >>> dnNormalize: <cn=Modrdn> Oct 16 14:15:47 <our ldap host> slapd[853103]: <<< dnNormalize: <cn=modrdn> Oct 16 14:15:47 <our ldap host> slapd[853103]: >>> dnNormalize: <cn=Add> Oct 16 14:15:47 <our ldap host> slapd[853103]: <<< dnNormalize: <cn=add> Oct 16 14:15:47 <our ldap host> slapd[853103]: >>> dnNormalize: <cn=Delete> Oct 16 14:15:47 <our ldap host> slapd[853103]: <<< dnNormalize: <cn=delete> Oct 16 14:15:47 <our ldap host> slapd[853103]: >>> dnNormalize: <cn=Abandon> Oct 16 14:15:47 <our ldap host> slapd[853103]: <<< dnNormalize: <cn=abandon> Oct 16 14:15:47 <our ldap host> slapd[853103]: >>> dnNormalize: <cn=Extended> Oct 16 14:15:47 <our ldap host> slapd[853103]: <<< dnNormalize: <cn=extended> Oct 16 14:15:47 <our ldap host> slapd[853103]: >>> dnNormalize: <cn=Overlay 0> Oct 16 14:15:47 <our ldap host> slapd[853103]: <<< dnNormalize: <cn=overlay 0> Oct 16 14:15:47 <our ldap host> slapd[853103]: >>> dnNormalize: <cn=Overlay 1> Oct 16 14:15:47 <our ldap host> slapd[853103]: <<< dnNormalize: <cn=overlay 1> Oct 16 14:15:47 <our ldap host> slapd[853103]: >>> dnNormalize: <cn=Database 2,cn=Databases,cn=Monitor> Oct 16 14:15:47 <our ldap host> slapd[853103]: <<< dnNormalize: <cn=database 2,cn=databases,cn=monitor> Oct 16 14:15:47 <our ldap host> slapd[853103]: >>> dnNormalize: <cn=Overlay 2> Oct 16 14:15:47 <our ldap host> slapd[853103]: <<< dnNormalize: <cn=overlay 2> Oct 16 14:15:47 <our ldap host> slapd[853103]: >>> dnNormalize: <cn=Bytes> Oct 16 14:15:47 <our ldap host> slapd[853103]: <<< dnNormalize: <cn=bytes> Oct 16 14:15:47 <our ldap host> slapd[853103]: >>> dnNormalize: <cn=PDU> Oct 16 14:15:47 <our ldap host> slapd[853103]: <<< dnNormalize: <cn=pdu> Oct 16 14:15:47 <our ldap host> slapd[853103]: >>> dnNormalize: <cn=Entries> Oct 16 14:15:47 <our ldap host> slapd[853103]: <<< dnNormalize: <cn=entries> Oct 16 14:15:47 <our ldap host> slapd[853103]: >>> dnNormalize: <cn=Referrals> Oct 16 14:15:47 <our ldap host> slapd[853103]: <<< dnNormalize: <cn=referrals> Oct 16 14:15:47 <our ldap host> slapd[853103]: >>> dnNormalize: <cn=Max> Oct 16 14:15:47 <our ldap host> slapd[853103]: <<< dnNormalize: <cn=max> Oct 16 14:15:47 <our ldap host> slapd[853103]: >>> dnNormalize: <cn=Max Pending> Oct 16 14:15:47 <our ldap host> slapd[853103]: <<< dnNormalize: <cn=max pending> Oct 16 14:15:47 <our ldap host> slapd[853103]: >>> dnNormalize: <cn=Open> Oct 16 14:15:47 <our ldap host> slapd[853103]: <<< dnNormalize: <cn=open> Oct 16 14:15:47 <our ldap host> slapd[853103]: >>> dnNormalize: <cn=Starting> Oct 16 14:15:47 <our ldap host> slapd[853103]: <<< dnNormalize: <cn=starting> Oct 16 14:15:47 <our ldap host> slapd[853103]: >>> dnNormalize: <cn=Active> Oct 16 14:15:47 <our ldap host> slapd[853103]: <<< dnNormalize: <cn=active> Oct 16 14:15:47 <our ldap host> slapd[853103]: >>> dnNormalize: <cn=Pending> Oct 16 14:15:47 <our ldap host> slapd[853103]: <<< dnNormalize: <cn=pending> Oct 16 14:15:47 <our ldap host> slapd[853103]: >>> dnNormalize: <cn=Backload> Oct 16 14:15:47 <our ldap host> slapd[853103]: <<< dnNormalize: <cn=backload> Oct 16 14:15:47 <our ldap host> slapd[853103]: >>> dnNormalize: <cn=State> Oct 16 14:15:47 <our ldap host> slapd[853103]: <<< dnNormalize: <cn=state> Oct 16 14:15:47 <our ldap host> slapd[853103]: >>> dnNormalize: <cn=Runqueue> Oct 16 14:15:47 <our ldap host> slapd[853103]: <<< dnNormalize: <cn=runqueue> Oct 16 14:15:47 <our ldap host> slapd[853103]: >>> dnNormalize: <cn=Tasklist> Oct 16 14:15:47 <our ldap host> slapd[853103]: <<< dnNormalize: <cn=tasklist> Oct 16 14:15:47 <our ldap host> slapd[853103]: >>> dnNormalize: <cn=Start> Oct 16 14:15:47 <our ldap host> slapd[853103]: <<< dnNormalize: <cn=start> Oct 16 14:15:47 <our ldap host> slapd[853103]: >>> dnNormalize: <cn=Current> Oct 16 14:15:47 <our ldap host> slapd[853103]: <<< dnNormalize: <cn=current> Oct 16 14:15:47 <our ldap host> slapd[853103]: >>> dnNormalize: <cn=Uptime> Oct 16 14:15:47 <our ldap host> slapd[853103]: <<< dnNormalize: <cn=uptime> Oct 16 14:15:47 <our ldap host> slapd[853103]: >>> dnNormalize: <cn=Read> Oct 16 14:15:47 <our ldap host> slapd[853103]: <<< dnNormalize: <cn=read> Oct 16 14:15:47 <our ldap host> slapd[853103]: >>> dnNormalize: <cn=Write> Oct 16 14:15:47 <our ldap host> slapd[853103]: <<< dnNormalize: <cn=write> Oct 16 14:15:47 <our ldap host> slapd[853103]: backend_startup_one: starting "dc=<sample value>,dc=com" Oct 16 14:15:47 <our ldap host> slapd[853103]: mdb_db_open: "dc=<sample value>,dc=com" Oct 16 14:15:47 <our ldap host> slapd[853103]: mdb_db_open: database "dc=<sample value>,dc=com": dbenv_open(/home/ldap). Oct 16 14:15:47 <our ldap host> slapd[853103]: syncprov_db_open: starting syncprov for suffix dc=<sample value>,dc=com Oct 16 14:15:47 <our ldap host> slapd[853103]: => mdb_entry_get: ndn: "dc=<sample value>,dc=com" Oct 16 14:15:47 <our ldap host> slapd[853103]: => mdb_entry_get: oc: "(null)", at: "contextCSN" Oct 16 14:15:47 <our ldap host> slapd[853103]: mdb_dn2entry("dc=<sample value>,dc=com") Oct 16 14:15:47 <our ldap host> slapd[853103]: => mdb_dn2id("dc=<sample value>,dc=com") Oct 16 14:15:47 <our ldap host> slapd[853103]: <= mdb_dn2id: got id=0x1 Oct 16 14:15:47 <our ldap host> slapd[853103]: => mdb_entry_decode: Oct 16 14:15:47 <our ldap host> slapd[853103]: <= mdb_entry_decode Oct 16 14:15:47 <our ldap host> slapd[853103]: => mdb_entry_get: found entry: "dc=<sample value>,dc=com" Oct 16 14:15:47 <our ldap host> slapd[853103]: mdb_entry_get: rc=0 Oct 16 14:15:47 <our ldap host> slapd[853103]: slapd starting Oct 16 14:15:47 <our ldap host> slapd[853103]: daemon: added 4r listener=(nil) Oct 16 14:15:47 <our ldap host> slapd[853103]: daemon: added 7r listener=0x5612300dd830 Oct 16 14:15:47 <our ldap host> slapd[853103]: daemon: added 8r listener=0x5612300dd920 Oct 16 14:15:47 <our ldap host> slapd[853103]: daemon: added 9r listener=0x5612300ddad0 Oct 16 14:15:47 <our ldap host> slapd[853103]: daemon: added 10r listener=0x5612300ddbc0 Oct 16 14:15:47 <our ldap host> slapd[853103]: daemon: added 11r listener=0x5612300ddd10 Oct 16 14:15:47 <our ldap host> slapd[853103]: daemon: epoll: listen=7 active_threads=0 tvp=zero Oct 16 14:15:47 <our ldap host> slapd[853103]: daemon: epoll: listen=8 active_threads=0 tvp=zero Oct 16 14:15:47 <our ldap host> slapd[853103]: daemon: epoll: listen=9 active_threads=0 tvp=zero Oct 16 14:15:47 <our ldap host> slapd[853103]: daemon: epoll: listen=10 active_threads=0 tvp=zero Oct 16 14:15:47 <our ldap host> slapd[853103]: daemon: epoll: listen=11 active_threads=0 tvp=zero Oct 16 14:15:47 <our ldap host> slapd[853103]: daemon: activity on 1 descriptor Oct 16 14:15:47 <our ldap host> slapd[853103]: daemon: activity on: Oct 16 14:15:47 <our ldap host> slapd[853103]: Oct 16 14:15:47 <our ldap host> slapd[853103]: daemon: epoll: listen=7 active_threads=0 tvp=zero Oct 16 14:15:47 <our ldap host> slapd[853103]: daemon: epoll: listen=8 active_threads=0 tvp=zero Oct 16 14:15:47 <our ldap host> slapd[853103]: daemon: epoll: listen=9 active_threads=0 tvp=zero Oct 16 14:15:47 <our ldap host> slapd[853103]: daemon: epoll: listen=10 active_threads=0 tvp=zero Oct 16 14:15:47 <our ldap host> slapd[853103]: daemon: epoll: listen=11 active_threads=0 tvp=zero Oct 16 14:15:47 <our ldap host> slapd[853103]: >>> dnNormalize: <cn=Consumer 001> Oct 16 14:15:47 <our ldap host> slapd[853103]: <<< dnNormalize: <cn=consumer 001> Oct 16 14:15:47 <our ldap host> slapd[853103]: =>do_syncrepl rid=001 Oct 16 14:15:47 <our ldap host> slapd[853103]: slap_client_connect: URI=<provider url> DN="cn=<sample value>,dc=<sample value>,dc=com" ldap_sasl_bind_s failed (-1) Oct 16 14:15:47 <our ldap host> slapd[853103]: do_syncrepl: rid=001 rc -1 retrying (4 retries left) Oct 16 14:15:47 <our ldap host> slapd[853103]: daemon: activity on 1 descriptor Oct 16 14:15:47 <our ldap host> slapd[853103]: daemon: activity on: Oct 16 14:15:47 <our ldap host> slapd[853103]: Oct 16 14:15:47 <our ldap host> slapd[853103]: daemon: epoll: listen=7 active_threads=0 tvp=zero Oct 16 14:15:47 <our ldap host> slapd[853103]: daemon: epoll: listen=8 active_threads=0 tvp=zero Oct 16 14:15:47 <our ldap host> slapd[853103]: daemon: epoll: listen=9 active_threads=0 tvp=zero Oct 16 14:15:47 <our ldap host> slapd[853103]: daemon: epoll: listen=10 active_threads=0 tvp=zero Oct 16 14:15:47 <our ldap host> slapd[853103]: daemon: epoll: listen=11 active_threads=0 tvp=zero Oct 16 14:15:52 <our ldap host> slapd[853103]: daemon: epoll: listen=7 active_threads=0 tvp=zero Oct 16 14:15:52 <our ldap host> slapd[853103]: daemon: epoll: listen=8 active_threads=0 tvp=zero Oct 16 14:15:52 <our ldap host> slapd[853103]: daemon: epoll: listen=9 active_threads=0 tvp=zero Oct 16 14:15:52 <our ldap host> slapd[853103]: daemon: epoll: listen=10 active_threads=0 tvp=zero Oct 16 14:15:52 <our ldap host> slapd[853103]: daemon: epoll: listen=11 active_threads=0 tvp=zero Oct 16 14:15:52 <our ldap host> slapd[853103]: =>do_syncrepl rid=001 Oct 16 14:15:52 <our ldap host> slapd[853103]: slap_client_connect: URI=<provider url> DN="cn=<sample value>,dc=<sample value>,dc=com" ldap_sasl_bind_s failed (-1) Oct 16 14:15:52 <our ldap host> slapd[853103]: do_syncrepl: rid=001 rc -1 retrying (3 retries left) Oct 16 14:15:52 <our ldap host> slapd[853103]: daemon: activity on 1 descriptor Oct 16 14:15:52 <our ldap host> slapd[853103]: daemon: activity on: Oct 16 14:15:52 <our ldap host> slapd[853103]: Oct 16 14:15:52 <our ldap host> slapd[853103]: daemon: epoll: listen=7 active_threads=0 tvp=zero Oct 16 14:15:52 <our ldap host> slapd[853103]: daemon: epoll: listen=8 active_threads=0 tvp=zero Oct 16 14:15:52 <our ldap host> slapd[853103]: daemon: epoll: listen=9 active_threads=0 tvp=zero Oct 16 14:15:52 <our ldap host> slapd[853103]: daemon: epoll: listen=10 active_threads=0 tvp=zero Oct 16 14:15:52 <our ldap host> slapd[853103]: daemon: epoll: listen=11 active_threads=0 tvp=zero Oct 16 14:15:57 <our ldap host> slapd[853103]: daemon: epoll: listen=7 active_threads=0 tvp=zero Oct 16 14:15:57 <our ldap host> slapd[853103]: daemon: epoll: listen=8 active_threads=0 tvp=zero Oct 16 14:15:57 <our ldap host> slapd[853103]: daemon: epoll: listen=9 active_threads=0 tvp=zero Oct 16 14:15:57 <our ldap host> slapd[853103]: daemon: epoll: listen=10 active_threads=0 tvp=zero Oct 16 14:15:57 <our ldap host> slapd[853103]: daemon: epoll: listen=11 active_threads=0 tvp=zero Oct 16 14:15:57 <our ldap host> slapd[853103]: =>do_syncrepl rid=001 Oct 16 14:15:57 <our ldap host> slapd[853103]: slap_client_connect: URI=<provider url> DN="cn=<sample value>,dc=<sample value>,dc=com" ldap_sasl_bind_s failed (-1) Oct 16 14:15:57 <our ldap host> slapd[853103]: do_syncrepl: rid=001 rc -1 retrying (2 retries left) Oct 16 14:15:57 <our ldap host> slapd[853103]: daemon: activity on 1 descriptor

4 9

Meta backends as Failover for replication
by Compy Ulix 16 Dec '24

16 Dec '24

Hello, I have 2 openldap backends with replication configured in mirror mode. Can I use a third openLDAP with the slapd-meta backend as failover system? Is it a reliable solution? Does anyone have a feedback on this kind of solution ? Thanks you for your answer, Franck

2 1

LDIF conversion
by duttaa＠hotmail.com 13 Dec '24

13 Dec '24

Hi, I want to build an application using Java and C++ to convert LDAP responses (sub tree search, tree with multi level hierarchy) into LDIF file. Are there any open source libraries which can be used for this use case. Thanks Abhijit

3 3

ECDSA certs TLS init failed for slapd
by jehan Procaccia 11 Dec '24

11 Dec '24

Hi we finally moved from RSA signed certificate to ECDSA signature as it is the defaults nowdays (https://community.letsencrypt.org/t/ecdsa-certificates-by-default-and-other…) unfortunatly , slapd doesnt like those certificates : / slapd[641]: @(#) $OpenLDAP: slapd 2.4.44 (Feb 23 2022 17:11:27) $/ /mockbuild@x86-01.bsys.centos.org:/builddir/build/BUILD/openldap-2.4.44/openldap-2.4.44/serve/ / slapd[641]: main: TLS init def ctx failed: -1/ / slapd[641]: slapd stopped./ This happened on a server running old openldap 2.4 (openldap-2.4.44-25.el7_9.x86_64) is there a directive to allow ECDSA certs in slapd (2.4) ? is it natively supported in up2date versions of openldap 2.5 / 2.6 ? is there a special directive in certbot to request slapd certs ? thanks .

4 5

2026

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

openldap-technical December 2024