openldap-technical May 2025

openldap-technical@openldap.org

17 participants
23 discussions

MDB monitoring: How many free pages actually?
by Windl, Ulrich 20 Jun '25

20 Jun '25

Hi, Considering this monitoring information, I wonder: olmMDBPagesMax: 12800 olmMDBPagesUsed: 9229 olmMDBPagesFree: 3810 Is the number of actual free pages 12800 - 9229 + 3810, i.e. "unallocated (12800 - 9229)" plus "usable" (3810)? How many free pages are needed before updates stop working? Kind regards, Ulrich Windl

3 5

Translucent/back_ldap and controls
by Bergmann, Clemens 19 Jun '25

19 Jun '25

Hi, we currently configuring openLDAP with translucent overlay to put in front of some legacy non-openLDAP LDAP servers. The translucent configuration is as follows: dn: olcOverlay={3}translucent,olcDatabase={2}mdb,cn=config objectClass: olcConfig objectClass: olcOverlayConfig objectClass: olcTranslucentConfig objectClass: top olcOverlay: {3}translucent olcDisabled: FALSE olcTranslucentBindLocal: TRUE dn: olcDatabase={0}ldap,olcOverlay={3}translucent,olcDatabase={2}mdb,cn=config objectClass: olcConfig objectClass: olcDatabaseConfig objectClass: olcLDAPConfig objectClass: olcTranslucentDatabase objectClass: top olcDatabase: {0}ldap olcDbACLBind: bindmethod=simple binddn=cn=hidden credentials=secret tls_cacert=/etc/ssl/certs/ca-bundle.crt olcDbStartTLS: ldaps tls_cacert=/etc/ssl/certs/ca-bundle.crt olcDbURI: ldaps://legacy-ldap-sever/ olcDbUseTemporaryConn: TRUE Searching via ldapsearch and apache directory studio works fine. When testing with some other clients we got empty results. Looking into the requests with trace debugLevel we see that some of the clients use different controls in the requests. One of the clients used paging and only got some of the entries back. We could prevent this behavior by filtering the value from the rootDSE by adding the following olcAccess ‘{1}to dn.base="" attrs=supportedControl val/objectIdentifierMatch=1.2.840.113556.1.4.319 by * none’. This “fixed” the problem for this client. Another client seems to use the manageDSAIT (2.16.840.1.113730.3.4.2) control. That seems to receive empty results. We can reproduce the results by adding ‘-E "2.16.840.1.113730.3.4.2"’ to the ldapsearch command. This will also result in an empty result. Unfortunately filtering the control in the same way did not work neither for ldapsearch nor for the other client. Had someone seen this seeming incompatibility of back_ldap with some or all controls. Mit freundlichen Grüßen Clemens (Bergmann) -- Clemens Bergmann [er/ihm; he/him] Gruppe Nutzermanagement und Entwicklung Technische Universität Darmstadt Hochschulrechenzentrum, Alexanderstraße 2, 64283 Darmstadt Tel. +49 6151 16 71184 <http://www.hrz.tu-darmstadt.de/> http://www.hrz.tu-darmstadt.de/

3 3

olcPPolicyForwardUpdates not working
by Benjamin Renard 18 Jun '25

18 Jun '25

Hello, I have problem with the olcPPolicyForwardUpdates option that seem not working : On master and slave, I configured Ppolicy with pwdLockout. When I try to connect on master with a bad password, the pwdFailureTime attribute of the entry is successfully updated, but not if I do the same on the slave. On slave, my ppolicy configuration is exactly the same as on master but I add olcPPolicyForwardUpdates=TRUE. I also configured the chain overlay and the updateref parameter on the database. Extract of my slave configuration : olcDatabase={1}mdb,cn=config [...] olcSyncrepl: [...] olcUpdateRef: ldaps://ldap-master olcOverlay={0}chain,olcDatabase={1}mdb,cn=config objectClass: olcOverlayConfig objectClass: olcChainConfig objectClass: top olcOverlay: {0}chain olcChainReturnError: TRUE olcDatabase={0}ldap,olcOverlay={0}chain,olcDatabase={1}mdb,cn=config objectClass: olcLDAPConfig objectClass: olcChainDatabase objectClass: top olcDatabase: {0}ldap olcDbURI: ldaps://ldap-master olcDbIDAssertBind: bindmethod=simple binddn="[same user used in olcSyncrepl of the database]" credentials="secret" mode=self olcDbRebindAsUser: TRUE olcOverlay={1}ppolicy,olcDatabase={1}mdb,cn=config objectClass: olcOverlayConfig objectClass: olcPPolicyConfig objectClass: top olcOverlay: {1}ppolicy olcPPolicyHashCleartext: TRUE olcPPolicyUseLockout: TRUE olcPPolicyForwardUpdates: TRUE Do you have any idea of what I doing wrong ? Thanks, -- Benjamin Renard - Easter-eggs 44-46 rue de l'Ouest - 75014 Paris - France - Métro Gaité Phone: +33 (0) 1 43 35 00 37 - mailto:brenard@easter-eggs.com

3 20

using refint overlay for pwdPolicySubentry
by Windl, Ulrich 10 Jun '25

10 Jun '25

Hi! Some time ago U had replaced a password policy, and it was quite sme work to replace all occurrences. So I thought reint cul help. I configured: dn: olcOverlay={4}refint,olcDatabase={1}mdb,cn=config objectClass: olcOverlayConfig objectClass: olcRefintConfig olcRefintAttribute: member olcRefintAttribute: pwdPolicySubentry olcOverlay: {4}refint And I did apply a test rename of the policy used by many users. I got no error from the modify, but slapd said many times: slapd[28826]: ppolicy_get: policy subentry cn=pp-default-2024-05x,...,dc=de missing or invalid at 'pwdPolicySubentry', no policy will be applied! Shouldn't refint have fixed those entries, or is there something special about password policy? The other thing I had noticed was that the MMR consumer did not complain at all, and it even looks as if the update wasn't sent. Did anybody try this before? When I checked for the member attribute by deleting a user, all members containing that user were removed, however. I see "modifiersName: cn=Referential Integrity Overlay", too. Same is true for a rename. Kind regards, Ulrich Windl

2 13

Q: lastbind, pwdLastSuccess, and authTimestamp
by Windl, Ulrich 02 Jun '25

02 Jun '25

Hi! Slapd-config states that pwdLastSuccess (provided by slapd) will be set if olcLastBind is set to true. However to do that the lastbind module/overlay is needed. But the latter sets authTimestamp. Slapo-policy documents that authTimestamp (provided by lastbind module) is set when lastbind is enabled. At it seems pwdLastSuccess and authTimestamp are set to the same value. Can someone explain the logic behind? I'm confused; do I really need the lastbind overlay? I'm using OpenLDAP 2.5.X Kind regards, Ulrich Windl

3 7

delta-syncrepl experience with OpenLDAP 2.5 (from SLES15)
by Windl, Ulrich 02 Jun '25

02 Jun '25

Hi! When upgrading from OpenLDAP 2.4 (SLES12) to OpenLDAP 2.5 (SLES15) I gave delta-syncrepl a try. That was a hard way in several aspects. Meanwhile I think I understand most of the details (docs could be much better IMHO). Where delta-syncrepl has big problems is when sync has been set up, but one database is reloaded and some UUIDs are newly created for entries that exist on the other server(s). Somehow slapd detects that problem and claims that a “content sync” is required, but after some time it seems to start a refresh anyway. When I did the content load on the other server, slapd quit with a core dump. Unfortunately I had quite a lot of core dumps during my testing. So I feel delta-syncrepl is not as solid as it should be (in the version provided with SLES15 SP6). Some of the logs: May 27 13:37:05 v06 slapd[27194]: do_syncrep1: rid=105 starting refresh (sending cookie=rid=105,sid=006,csn=20130708113956.028116Z#000000#000#000000;20240708090039.074592Z#000000#001#0> May 27 13:37:05 v06 slapd[27194]: do_syncrep2: rid=105 LDAP_RES_SEARCH_RESULT May 27 13:37:05 v06 slapd[27194]: do_syncrep2: rid=105 delta-sync lost sync, switching to REFRESH May 27 13:37:05 v06 slapd[27194]: do_syncrep2: rid=105 (4096) Content Sync Refresh Required May 27 13:41:36 v06 slapd[27194]: do_syncrep1: rid=105 starting refresh (sending cookie=rid=105,sid=006,csn=20130708113956.028116Z#000000#000#000000;20240708090039.074592Z#000000#001#0> May 27 13:41:36 v06 slapd[27194]: do_syncrep2: rid=105 LDAP_RES_INTERMEDIATE - SYNC_ID_SET May 27 13:41:36 v06 slapd[27194]: syncrepl_message_to_entry: rid=105 DN: cn=config, UUID: 85353d82-cf3a-103f-9d14-755ae58f92b6 May 27 13:41:36 v06 slapd[27194]: syncrepl_entry: rid=105 LDAP_RES_SEARCH_ENTRY(LDAP_SYNC_ADD) csn=(none) tid 0x7f6b1b7fe6c0 … May 27 13:43:33 v06 slapd[27194]: do_syncrepl: rid=105 rc -1 retrying (4 retries left) May 27 13:43:34 v06 slapd[27194]: conn=1008 op=2 syncprov_op_search: got a persistent search with a cookie=rid=106,sid=005,csn=20130708113956.028116Z#000000#000#000000;20240708090039.0> May 27 13:43:34 v06 slapd[27194]: conn=1008 op=2 syncprov_findbase: searching May 27 13:43:34 v06 slapd[27194]: conn=1008 op=2 syncprov_op_search: registered persistent search May 27 13:43:34 v06 slapd[27194]: conn=1008 op=2 syncprov_sendinfo: refreshDelete cookie= May 27 13:43:34 v06 slapd[27194]: conn=1008 op=2 syncprov_search_response: detaching op May 27 13:43:34 v06 slapd[27194]: conn=1009 op=2 syncprov_op_search: got a persistent search with a cookie=rid=116,sid=005,csn=20130719093756.074776Z#000000#000#000000;20250217105250.3> May 27 13:43:34 v06 slapd[27194]: conn=1009 op=2 syncprov_findbase: searching May 27 13:43:34 v06 slapd[27194]: conn=1009 op=2 syncprov_op_search: registered persistent search May 27 13:43:34 v06 slapd[27194]: conn=1009 op=2 syncprov_op_search: no change, skipping log replay May 27 13:43:34 v06 slapd[27194]: conn=1009 op=2 syncprov_op_search: nothing changed, finishing up initial search early May 27 13:43:34 v06 slapd[27194]: conn=1009 op=2 syncprov_sendinfo: refreshDelete cookie= May 27 13:43:34 v06 slapd[27194]: conn=1009 op=2 syncprov_search_response: detaching op May 27 13:43:34 v06 slapd[27194]: conn=1011 op=2 syncprov_op_search: got a persistent search with a cookie=rid=106,sid=005,csn=20130708113956.028116Z#000000#000#000000;20240708090039.0> May 27 13:43:34 v06 slapd[27194]: conn=1011 op=2 syncprov_findbase: searching May 27 13:43:34 v06 slapd[27194]: conn=1011 op=2 syncprov_op_search: registered persistent search May 27 13:43:34 v06 slapd[27194]: conn=1011 op=2 syncprov_sendinfo: refreshDelete cookie= May 27 13:43:34 v06 slapd[27194]: conn=1011 op=2 syncprov_search_response: detaching op May 27 13:43:34 v06 slapd[27194]: conn=1010 op=2 syncprov_op_search: got a persistent search with a cookie=rid=116,sid=005,csn=20130719093756.074776Z#000000#000#000000;20250217105250.3> May 27 13:43:34 v06 slapd[27194]: conn=1010 op=2 syncprov_findbase: searching May 27 13:43:34 v06 slapd[27194]: conn=1010 op=2 syncprov_op_search: registered persistent search May 27 13:43:34 v06 slapd[27194]: conn=1010 op=2 syncprov_op_search: no change, skipping log replay May 27 13:43:34 v06 slapd[27194]: conn=1010 op=2 syncprov_op_search: nothing changed, finishing up initial search early May 27 13:43:34 v06 slapd[27194]: conn=1010 op=2 syncprov_sendinfo: refreshDelete cookie= May 27 13:43:34 v06 slapd[27194]: conn=1010 op=2 syncprov_search_response: detaching op May 27 13:43:34 v06 slapd[27194]: conn=1012 op=2 syncprov_op_search: got a persistent search with a cookie=rid=116,sid=005,csn=20130719093756.074776Z#000000#000#000000;20250217105250.3> May 27 13:43:34 v06 slapd[27194]: conn=1012 op=2 syncprov_findbase: searching May 27 13:43:34 v06 slapd[27194]: conn=1012 op=2 syncprov_op_search: registered persistent search May 27 13:43:34 v06 slapd[27194]: conn=1012 op=2 syncprov_op_search: no change, skipping log replay May 27 13:43:34 v06 slapd[27194]: conn=1012 op=2 syncprov_op_search: nothing changed, finishing up initial search early May 27 13:43:34 v06 slapd[27194]: conn=1012 op=2 syncprov_sendinfo: refreshDelete cookie= May 27 13:43:34 v06 slapd[27194]: conn=1012 op=2 syncprov_search_response: detaching op May 27 13:43:34 v06 slapd[27194]: conn=1013 op=2 syncprov_op_search: got a persistent search with a cookie=rid=106,sid=005,csn=20130708113956.028116Z#000000#000#000000;20240708090039.0> May 27 13:43:34 v06 slapd[27194]: conn=1013 op=2 syncprov_findbase: searching May 27 13:43:34 v06 slapd[27194]: conn=1013 op=2 syncprov_op_search: registered persistent search May 27 13:43:34 v06 slapd[27194]: conn=1013 op=2 syncprov_sendinfo: refreshDelete cookie= May 27 13:43:34 v06 slapd[27194]: conn=1013 op=2 syncprov_search_response: detaching op May 27 13:43:34 v06 slapd[27194]: conn=1014 op=2 syncprov_op_search: got a persistent search with a cookie=rid=106,sid=005,csn=20130708113956.028116Z#000000#000#000000;20240708090039.0> May 27 13:43:34 v06 slapd[27194]: conn=1014 op=2 syncprov_findbase: searching May 27 13:43:34 v06 slapd[27194]: conn=1014 op=2 syncprov_op_search: registered persistent search May 27 13:43:34 v06 systemd[1]: Started Process Core Dump (PID 27241/UID 0). May 27 13:43:35 v06 systemd-coredump[27242]: [🡕] Process 27194 (slapd) of user 76 dumped core. Stack trace of thread 27199: #0 0x00007f6b34ca8dfc __pthread_kill_implementation (libc.so.6 + 0xa8dfc) #1 0x00007f6b34c57842 raise (libc.so.6 + 0x57842) #2 0x00007f6b34c3f5cf abort (libc.so.6 + 0x3f5cf) #3 0x00007f6b34c3f4e7 __assert_fail_base.cold (libc.so.6 + 0x3f4e7) #4 0x00007f6b34c4fb32 __assert_fail (libc.so.6 + 0x4fb32) #5 0x00007f6b34787258 n/a (syncprov.so + 0xc258) #6 0x000055765d7e04f3 overlay_op_walk (slapd + 0xb74f3) #7 0x000055765d7e06be n/a (slapd + 0xb76be) #8 0x000055765d76ee54 fe_op_search (slapd + 0x45e54) #9 0x000055765d76e726 do_search (slapd + 0x45726) #10 0x000055765d76c18f n/a (slapd + 0x4318f) #11 0x000055765d76c98d n/a (slapd + 0x4398d) #12 0x00007f6b34ff7da0 n/a (libldap-2.5.releng.so.0 + 0x48da0) #13 0x00007f6b34ca6f6c start_thread (libc.so.6 + 0xa6f6c) #14 0x00007f6b34d2e338 __clone3 (libc.so.6 + 0x12e338) Stack trace of thread 27194: #0 0x00007f6b34ca3c1e __futex_abstimed_wait_common (libc.so.6 + 0xa3c1e) #1 0x00007f6b34ca8b83 __pthread_clockjoin_ex (libc.so.6 + 0xa8b83) #2 0x000055765d7691ca slapd_daemon (slapd + 0x401ca) #3 0x000055765d74c88e main (slapd + 0x2388e) #4 0x00007f6b34c40e6c __libc_start_call_main (libc.so.6 + 0x40e6c) #5 0x00007f6b34c40f35 __libc_start_main@@GLIBC_2.34 (libc.so.6 + 0x40f35) #6 0x000055765d74c90a _start (slapd + 0x2390a) Stack trace of thread 27204: #0 0x00007f6b34ca3c1e __futex_abstimed_wait_common (libc.so.6 + 0xa3c1e) #1 0x00007f6b34ca6548 pthread_cond_wait@@GLIBC_2.3.2 (libc.so.6 + 0xa6548) #2 0x00007f6b34ff7e40 n/a (libldap-2.5.releng.so.0 + 0x48e40) #3 0x00007f6b34ca6f6c start_thread (libc.so.6 + 0xa6f6c) #4 0x00007f6b34d2e338 __clone3 (libc.so.6 + 0x12e338) Stack trace of thread 27198: #0 0x00007f6b34ca3c1e __futex_abstimed_wait_common (libc.so.6 + 0xa3c1e) #1 0x00007f6b34ca6548 pthread_cond_wait@@GLIBC_2.3.2 (libc.so.6 + 0xa6548) #2 0x00007f6b34ff7e40 n/a (libldap-2.5.releng.so.0 + 0x48e40) #3 0x00007f6b34ca6f6c start_thread (libc.so.6 + 0xa6f6c) #4 0x00007f6b34d2e338 __clone3 (libc.so.6 + 0x12e338) Stack trace of thread 27197: #0 0x00007f6b34ca3c1e __futex_abstimed_wait_common (libc.so.6 + 0xa3c1e) #1 0x00007f6b34ca6548 pthread_cond_wait@@GLIBC_2.3.2 (libc.so.6 + 0xa6548) #2 0x00007f6b34ff7e40 n/a (libldap-2.5.releng.so.0 + 0x48e40) #3 0x00007f6b34ca6f6c start_thread (libc.so.6 + 0xa6f6c) #4 0x00007f6b34d2e338 __clone3 (libc.so.6 + 0x12e338) Stack trace of thread 27202: #0 0x00007f6b34ca3c1e __futex_abstimed_wait_common (libc.so.6 + 0xa3c1e) #1 0x00007f6b34ca6548 pthread_cond_wait@@GLIBC_2.3.2 (libc.so.6 + 0xa6548) #2 0x00007f6b34ff7e40 n/a (libldap-2.5.releng.so.0 + 0x48e40) #3 0x00007f6b34ca6f6c start_thread (libc.so.6 + 0xa6f6c) #4 0x00007f6b34d2e338 __clone3 (libc.so.6 + 0x12e338) Stack trace of thread 27200: #0 0x00007f6b34ca3c1e __futex_abstimed_wait_common (libc.so.6 + 0xa3c1e) #1 0x00007f6b34ca6548 pthread_cond_wait@@GLIBC_2.3.2 (libc.so.6 + 0xa6548) #2 0x00007f6b34ff7e40 n/a (libldap-2.5.releng.so.0 + 0x48e40) #3 0x00007f6b34ca6f6c start_thread (libc.so.6 + 0xa6f6c) #4 0x00007f6b34d2e338 __clone3 (libc.so.6 + 0x12e338) Stack trace of thread 27203: #0 0x00007f6b34ca3c1e __futex_abstimed_wait_common (libc.so.6 + 0xa3c1e) #1 0x00007f6b34ca6548 pthread_cond_wait@@GLIBC_2.3.2 (libc.so.6 + 0xa6548) #2 0x00007f6b34ff7e40 n/a (libldap-2.5.releng.so.0 + 0x48e40) #3 0x00007f6b34ca6f6c start_thread (libc.so.6 + 0xa6f6c) #4 0x00007f6b34d2e338 __clone3 (libc.so.6 + 0x12e338) Stack trace of thread 27196: #0 0x00007f6b34d2e796 epoll_wait (libc.so.6 + 0x12e796) #1 0x000055765d76607b n/a (slapd + 0x3d07b) #2 0x00007f6b34ca6f6c start_thread (libc.so.6 + 0xa6f6c) #3 0x00007f6b34d2e338 __clone3 (libc.so.6 + 0x12e338) ELF object binary architecture: AMD x86-64 May 27 13:43:35 v06 systemd[1]: systemd-coredump(a)5-27241-0.service: Deactivated successfully. Kind regards, Ulrich Windl

2 2

back-sock module: error "socket connect(<socket_file_name>) failed"
by Gianluca Ramunno 30 May '25

30 May '25

Hello all, I'm a newbie in LDAP/OpenLDAP. I have to implement an LDAP proxy that "simply" authenticates a user against a first LDAP server and, if it fails for invalid credentials, tries to authenticate against a second LDAP server. I've found OpenLDAP and the back-sock backend as a possible way to implement such a scheme, using a python script as a concurrent server listening on the UNIX socket that will be used by the backend back-sock. I'm currently using Ubuntu 22.04 and OpenLDAP 2.5.19 for testing. Now I have a concurrent server in python that works well: it accepts a connection on a UNIX socket, prints what it receives over the connection and closes it. I tested it with a simple python client. On the OpenLDAP side, instead, I have a big issue: I tried to configure the backend using the legacy mode (the slapd.conf config file will follow), but when I try to run the command ldapwhoami -x -D "cn=admin,dc=example,dc=com" -W -H ldap://localhost (with "dc=example,dc=com" replaced with the base DN I used in the configuration during the installation phase) on the same machine where slapd is running, the command returns: ldap_bind: Invalid credentials (49) using the right password input during installation phase, while on the server side in the log I found the error message: socket connect(<socket_file_name>) failed and the server python does not give any sign of accepting a connection. Setting the loglevel to -1 or starting slapd with strace ( strace slapd -d -1 ) does not provide further information. NOTE that the above ldapwhoami command worked fine with the original configuration with the new method in the slapd.d folder. This is the config file I created to use the back-sock backend: modulepath /usr/lib/ldap moduleload back_sock.la include /etc/ldap/schema/core.schema pidfile /var/run/slapd/slapd.pid argsfile /var/run/slapd/slapd.args #loglevel 256 loglevel -1 database sock socketpath /tmp/ldsock suffix "dc=proxy,dc=ldap" Any clue? Thanks in advance Gianluca Ramunno

1 1

auditlogs not listed in monitor database
by Windl, Ulrich 27 May '25

27 May '25

Hi! I have an odd effect: Using ldapsearch -Q -Y EXTERNAL -H ldapi:/// -b 'cn=Databases,cn=monitor' -s sub '(monitoredInfo=mdb)' description monitoredInfo monitorCounter I only get two databases: # Database 1, Databases, Monitor dn: cn=Database 1,cn=Databases,cn=Monitor monitoredInfo: mdb ... olmDbDirectory: /var/lib/ldap/ # Database 3, Databases, Monitor dn: cn=Database 3,cn=Databases,cn=Monitor monitoredInfo: mdb ... olmDbDirectory: /var/lib/ldap/audit/ However I have two mode MDB databases used as auditlog/changelog. Why aren't hose displayed? Kind regards, Ulrich Windl

1 1

Cannot connect over TLS/SSL (ldaps) on v2.6.9
by Nick Milas 26 May '25

26 May '25

Hello, I have managed to start the migrated LDAP server on Rocky 9, v2.6.9 LTB. It seems to be working fine but, I cannot connect over ssl (ldaps, port 636). I am trying to connect with Apache Directory Studio but it fails, although I am using the same certificate as on the orignal server (the cert covers both server names). I have enabled conns logging on the server and I see connection coming in, but for some reason it fails (input error=-2): Could you please guide me to troubleshoot this? May 21 11:19:14 ldap1.noa.gr slapd[17512]: daemon: activity on 1 descriptor May 21 11:19:14 ldap1.noa.gr slapd[17512]: daemon: activity on: May 21 11:19:14 ldap1.noa.gr slapd[17512]: May 21 11:19:14 ldap1.noa.gr slapd[17512]: daemon: epoll: listen=7 active_threads=0 tvp=NULL May 21 11:19:14 ldap1.noa.gr slapd[17512]: daemon: epoll: listen=8 active_threads=0 tvp=NULL May 21 11:19:14 ldap1.noa.gr slapd[17512]: daemon: epoll: listen=9 busy May 21 11:19:14 ldap1.noa.gr slapd[17512]: daemon: epoll: listen=10 active_threads=0 tvp=NULL May 21 11:19:14 ldap1.noa.gr slapd[17512]: daemon: epoll: listen=11 active_threads=0 tvp=NULL *May 21 11:19:14 ldap1.noa.gr slapd[17512]: daemon: accept() = 14* May 21 11:19:14 ldap1.noa.gr slapd[17512]: daemon: activity on 1 descriptor May 21 11:19:14 ldap1.noa.gr slapd[17512]: daemon: activity on: May 21 11:19:14 ldap1.noa.gr slapd[17512]: May 21 11:19:14 ldap1.noa.gr slapd[17512]: daemon: epoll: listen=7 active_threads=0 tvp=NULL May 21 11:19:14 ldap1.noa.gr slapd[17512]: daemon: epoll: listen=8 active_threads=0 tvp=NULL May 21 11:19:14 ldap1.noa.gr slapd[17512]: daemon: epoll: listen=9 active_threads=0 tvp=NULL May 21 11:19:14 ldap1.noa.gr slapd[17512]: daemon: epoll: listen=10 active_threads=0 tvp=NULL May 21 11:19:14 ldap1.noa.gr slapd[17512]: daemon: epoll: listen=11 active_threads=0 tvp=NULL *May 21 11:19:14 ldap1.noa.gr slapd[17512]: daemon: listen=9, new connection on 14 May 21 11:19:14 ldap1.noa.gr slapd[17512]: daemon: added 14r (active) listener=(nil)* May 21 11:19:14 ldap1.noa.gr slapd[17512]: daemon: activity on 1 descriptor May 21 11:19:14 ldap1.noa.gr slapd[17512]: daemon: activity on: May 21 11:19:14 ldap1.noa.gr slapd[17512]: May 21 11:19:14 ldap1.noa.gr slapd[17512]: daemon: epoll: listen=7 active_threads=0 tvp=NULL May 21 11:19:14 ldap1.noa.gr slapd[17512]: daemon: epoll: listen=8 active_threads=0 tvp=NULL May 21 11:19:14 ldap1.noa.gr slapd[17512]: daemon: epoll: listen=9 active_threads=0 tvp=NULL May 21 11:19:14 ldap1.noa.gr slapd[17512]: daemon: epoll: listen=10 active_threads=0 tvp=NULL May 21 11:19:14 ldap1.noa.gr slapd[17512]: daemon: epoll: listen=11 active_threads=0 tvp=NULL *May 21 11:19:14 ldap1.noa.gr slapd[17512]: conn=1002 fd=14 ACCEPT from IP=195.251.xxx.xxx:51334 (IP=0.0.0.0:636)* May 21 11:19:14 ldap1.noa.gr slapd[17512]: daemon: activity on 1 descriptor May 21 11:19:14 ldap1.noa.gr slapd[17512]: daemon: activity on: May 21 11:19:14 ldap1.noa.gr slapd[17512]: 14r May 21 11:19:14 ldap1.noa.gr slapd[17512]: May 21 11:19:14 ldap1.noa.gr slapd[17512]: daemon: read active on 14 May 21 11:19:14 ldap1.noa.gr slapd[17512]: daemon: epoll: listen=7 active_threads=0 tvp=NULL May 21 11:19:14 ldap1.noa.gr slapd[17512]: daemon: epoll: listen=8 active_threads=0 tvp=NULL May 21 11:19:14 ldap1.noa.gr slapd[17512]: daemon: epoll: listen=9 active_threads=0 tvp=NULL May 21 11:19:14 ldap1.noa.gr slapd[17512]: daemon: epoll: listen=10 active_threads=0 tvp=NULL May 21 11:19:14 ldap1.noa.gr slapd[17512]: daemon: epoll: listen=11 active_threads=0 tvp=NULL May 21 11:19:14 ldap1.noa.gr slapd[17512]: daemon: activity on 1 descriptor May 21 11:19:14 ldap1.noa.gr slapd[17512]: daemon: activity on: May 21 11:19:14 ldap1.noa.gr slapd[17512]: May 21 11:19:14 ldap1.noa.gr slapd[17512]: daemon: epoll: listen=7 active_threads=0 tvp=NULL May 21 11:19:14 ldap1.noa.gr slapd[17512]: daemon: epoll: listen=8 active_threads=0 tvp=NULL May 21 11:19:14 ldap1.noa.gr slapd[17512]: daemon: epoll: listen=9 active_threads=0 tvp=NULL May 21 11:19:14 ldap1.noa.gr slapd[17512]: daemon: epoll: listen=10 active_threads=0 tvp=NULL May 21 11:19:14 ldap1.noa.gr slapd[17512]: daemon: epoll: listen=11 active_threads=0 tvp=NULL May 21 11:19:14 ldap1.noa.gr slapd[17512]: daemon: activity on 1 descriptor May 21 11:19:14 ldap1.noa.gr slapd[17512]: daemon: activity on: May 21 11:19:14 ldap1.noa.gr slapd[17512]: 14r May 21 11:19:14 ldap1.noa.gr slapd[17512]: May 21 11:19:14 ldap1.noa.gr slapd[17512]: daemon: read active on 14 May 21 11:19:14 ldap1.noa.gr slapd[17512]: daemon: epoll: listen=7 active_threads=0 tvp=NULL May 21 11:19:14 ldap1.noa.gr slapd[17512]: daemon: epoll: listen=8 active_threads=0 tvp=NULL May 21 11:19:14 ldap1.noa.gr slapd[17512]: daemon: epoll: listen=9 active_threads=0 tvp=NULL May 21 11:19:14 ldap1.noa.gr slapd[17512]: daemon: epoll: listen=10 active_threads=0 tvp=NULL May 21 11:19:14 ldap1.noa.gr slapd[17512]: daemon: epoll: listen=11 active_threads=0 tvp=NULL May 21 11:19:14 ldap1.noa.gr slapd[17512]: daemon: activity on 1 descriptor May 21 11:19:14 ldap1.noa.gr slapd[17512]: daemon: activity on: May 21 11:19:14 ldap1.noa.gr slapd[17512]: May 21 11:19:14 ldap1.noa.gr slapd[17512]: daemon: epoll: listen=7 active_threads=0 tvp=NULL May 21 11:19:14 ldap1.noa.gr slapd[17512]: daemon: epoll: listen=8 active_threads=0 tvp=NULL May 21 11:19:14 ldap1.noa.gr slapd[17512]: daemon: epoll: listen=9 active_threads=0 tvp=NULL May 21 11:19:14 ldap1.noa.gr slapd[17512]: daemon: epoll: listen=10 active_threads=0 tvp=NULL May 21 11:19:14 ldap1.noa.gr slapd[17512]: daemon: epoll: listen=11 active_threads=0 tvp=NULL May 21 11:19:14 ldap1.noa.gr slapd[17512]: daemon: activity on 1 descriptor May 21 11:19:14 ldap1.noa.gr slapd[17512]: daemon: activity on: May 21 11:19:14 ldap1.noa.gr slapd[17512]: 14r May 21 11:19:14 ldap1.noa.gr slapd[17512]: May 21 11:19:14 ldap1.noa.gr slapd[17512]: daemon: read active on 14 May 21 11:19:14 ldap1.noa.gr slapd[17512]: daemon: epoll: listen=7 active_threads=0 tvp=NULL May 21 11:19:14 ldap1.noa.gr slapd[17512]: daemon: epoll: listen=8 active_threads=0 tvp=NULL May 21 11:19:14 ldap1.noa.gr slapd[17512]: daemon: epoll: listen=9 active_threads=0 tvp=NULL May 21 11:19:14 ldap1.noa.gr slapd[17512]: daemon: epoll: listen=10 active_threads=0 tvp=NULL May 21 11:19:14 ldap1.noa.gr slapd[17512]: daemon: epoll: listen=11 active_threads=0 tvp=NULL May 21 11:19:14 ldap1.noa.gr slapd[17512]: daemon: epoll: listen=7 active_threads=0 tvp=NULL May 21 11:19:14 ldap1.noa.gr slapd[17512]: daemon: epoll: listen=8 active_threads=0 tvp=NULL May 21 11:19:14 ldap1.noa.gr slapd[17512]: daemon: epoll: listen=9 active_threads=0 tvp=NULL May 21 11:19:14 ldap1.noa.gr slapd[17512]: daemon: epoll: listen=10 active_threads=0 tvp=NULL May 21 11:19:14 ldap1.noa.gr slapd[17512]: daemon: epoll: listen=11 active_threads=0 tvp=NULL *May 21 11:19:14 ldap1.noa.gr slapd[17512]: conn=1002 fd=14 TLS established tls_ssf=256 ssf=256 tls_proto=TLSv1.3 tls_cipher=TLS_AES_256_GCM_SHA384* May 21 11:19:14 ldap1.noa.gr slapd[17512]: daemon: activity on 1 descriptor May 21 11:19:14 ldap1.noa.gr slapd[17512]: daemon: activity on: May 21 11:19:14 ldap1.noa.gr slapd[17512]: 14r May 21 11:19:14 ldap1.noa.gr slapd[17512]: May 21 11:19:14 ldap1.noa.gr slapd[17512]: daemon: read active on 14 May 21 11:19:14 ldap1.noa.gr slapd[17512]: daemon: epoll: listen=7 active_threads=0 tvp=NULL May 21 11:19:14 ldap1.noa.gr slapd[17512]: daemon: epoll: listen=8 active_threads=0 tvp=NULL May 21 11:19:14 ldap1.noa.gr slapd[17512]: daemon: epoll: listen=9 active_threads=0 tvp=NULL May 21 11:19:14 ldap1.noa.gr slapd[17512]: daemon: epoll: listen=10 active_threads=0 tvp=NULL May 21 11:19:14 ldap1.noa.gr slapd[17512]: daemon: epoll: listen=11 active_threads=0 tvp=NULL May 21 11:19:14 ldap1.noa.gr slapd[17512]: daemon: activity on 1 descriptor May 21 11:19:14 ldap1.noa.gr slapd[17512]: daemon: activity on: May 21 11:19:14 ldap1.noa.gr slapd[17512]: May 21 11:19:14 ldap1.noa.gr slapd[17512]: daemon: epoll: listen=7 active_threads=0 tvp=NULL May 21 11:19:14 ldap1.noa.gr slapd[17512]: daemon: epoll: listen=8 active_threads=0 tvp=NULL May 21 11:19:14 ldap1.noa.gr slapd[17512]: daemon: epoll: listen=9 active_threads=0 tvp=NULL May 21 11:19:14 ldap1.noa.gr slapd[17512]: daemon: epoll: listen=10 active_threads=0 tvp=NULL May 21 11:19:14 ldap1.noa.gr slapd[17512]: daemon: epoll: listen=11 active_threads=0 tvp=NULL *May 21 11:19:14 ldap1.noa.gr slapd[17512]: conn=1002 op=0 BIND dn="uid=userx,ou=people,dc=noa,dc=gr" method=128 May 21 11:19:14 ldap1.noa.gr slapd[17512]: conn=1002 op=0 BIND dn="uid=userx,ou=people,dc=noa,dc=gr" mech=SIMPLE bind_ssf=0 ssf=256 May 21 11:19:14 ldap1.noa.gr slapd[17512]: conn=1002 op=0 RESULT tag=97 err=0 qtime=0.000034 etime=0.000475 text=* May 21 11:19:14 ldap1.noa.gr slapd[17512]: daemon: activity on 1 descriptor May 21 11:19:14 ldap1.noa.gr slapd[17512]: daemon: activity on: May 21 11:19:14 ldap1.noa.gr slapd[17512]: May 21 11:19:14 ldap1.noa.gr slapd[17512]: daemon: epoll: listen=7 active_threads=0 tvp=NULL May 21 11:19:14 ldap1.noa.gr slapd[17512]: daemon: epoll: listen=8 active_threads=0 tvp=NULL May 21 11:19:14 ldap1.noa.gr slapd[17512]: daemon: epoll: listen=9 active_threads=0 tvp=NULL May 21 11:19:14 ldap1.noa.gr slapd[17512]: daemon: epoll: listen=10 active_threads=0 tvp=NULL May 21 11:19:14 ldap1.noa.gr slapd[17512]: daemon: epoll: listen=11 active_threads=0 tvp=NULL May 21 11:19:44 ldap1.noa.gr slapd[17512]: daemon: activity on 1 descriptor May 21 11:19:44 ldap1.noa.gr slapd[17512]: daemon: activity on: May 21 11:19:44 ldap1.noa.gr slapd[17512]: 14r May 21 11:19:44 ldap1.noa.gr slapd[17512]: May 21 11:19:44 ldap1.noa.gr slapd[17512]: daemon: read active on 14 May 21 11:19:44 ldap1.noa.gr slapd[17512]: daemon: epoll: listen=7 active_threads=0 tvp=NULL May 21 11:19:44 ldap1.noa.gr slapd[17512]: daemon: epoll: listen=8 active_threads=0 tvp=NULL May 21 11:19:44 ldap1.noa.gr slapd[17512]: daemon: epoll: listen=9 active_threads=0 tvp=NULL May 21 11:19:44 ldap1.noa.gr slapd[17512]: daemon: epoll: listen=10 active_threads=0 tvp=NULL May 21 11:19:44 ldap1.noa.gr slapd[17512]: daemon: epoll: listen=11 active_threads=0 tvp=NULL *May 21 11:19:44 ldap1.noa.gr slapd[17512]: connection_read(14): input error=-2 id=1002, closing. May 21 11:19:44 ldap1.noa.gr slapd[17512]: connection_closing: readying conn=1002 sd=14 for close May 21 11:19:44 ldap1.noa.gr slapd[17512]: daemon: removing 14 May 21 11:19:44 ldap1.noa.gr slapd[17512]: conn=1002 fd=14 closed (connection lost)*May 21 11:19:44 ldap1.noa.gr slapd[17512]: daemon: activity on 1 descriptor May 21 11:19:44 ldap1.noa.gr slapd[17512]: daemon: activity on: May 21 11:19:44 ldap1.noa.gr slapd[17512]: May 21 11:19:44 ldap1.noa.gr slapd[17512]: daemon: epoll: listen=7 active_threads=0 tvp=NULL May 21 11:19:44 ldap1.noa.gr slapd[17512]: daemon: epoll: listen=8 active_threads=0 tvp=NULL May 21 11:19:44 ldap1.noa.gr slapd[17512]: daemon: epoll: listen=9 active_threads=0 tvp=NULL May 21 11:19:44 ldap1.noa.gr slapd[17512]: daemon: epoll: listen=10 active_threads=0 tvp=NULL May 21 11:19:44 ldap1.noa.gr slapd[17512]: daemon: epoll: listen=11 active_threads=0 tvp=NULL I have tried removing the olcTLSCipherSuite attribute, but it won't work anyway. As a side note, I see that logging is directed to the journal. Could I redirect it to a file instead? I have set olcLogFile, but logging is directed to the journal nevertheless. Thanks a lot, Nick

4 4

Reminder: Long Term Support release series is now OpenLDAP 2.6
by Quanah Gibson-Mount 23 May '25

23 May '25

With the release of OpenLDAP 2.6.10, the OpenLDAP 2.6 release series is now the long term support release. 2.5.20 is the last planned release for the OpenLDAP 2.5 series. Regards, Quanah

1 0

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

openldap-technical May 2025