openldap-technical March 2025

openldap-technical@openldap.org

26 participants
30 discussions

Feature Requests; where to go? (diff-friendly slapcat/ldapsearch)
by Windl, Ulrich 20 Mar '25

20 Mar '25

Hi! I had an idea for a new feature of slapcat (maybe ldapsearch, too), but I don't know where to file such. So I'm presenting the idea here: "Diff-friendly output format" The order of LDAP attributes is not determined, so after a change to an entry the order of attributes may vary. If you diff the older with the current output, there are more differences than actually there were changes. For example consider this diff (partial output): +entryCSN: 20250319115404.360112Z#000000#005#000000 +modifiersName: cn=config +modifyTimestamp: 20250319115404Z contextCSN: 20130722065709.189194Z#000000#000#000000 contextCSN: 20241204070658.632888Z#000000#001#000000 contextCSN: 20200721123717.002866Z#000000#002#000000 contextCSN: 20181031083258.073732Z#000000#003#000000 -contextCSN: 20250319114038.822575Z#000000#005#000000 +contextCSN: 20250319140809.186543Z#000000#005#000000 contextCSN: 20250227092006.790591Z#000000#006#000000 -entryCSN: 20250319115404.360112Z#000000#005#000000 -modifiersName: cn=config -modifyTimestamp: 20250319115404Z The modifiersName did not change, but its position had moved in output. In a diff-friendly format the position would not change. Obviously that could be done by sorting the output by attribute names (which would also help to locate a specific attribute), but it would have performance impacts, obviously. Another related option is attributes with a list of sub-attributes (name-value pairs), like syncrepl: In standard format the lines are wrapped, and with "-o ldif-wrap=no" you get one long line. For diff-friendliness may idea was to optionally wrap such name-value pairs after each pair, and if a single one exceeds the standard lengh, it would be wrapped still. So the idea could be like this: Use option -D for diff-friendly output format (sorting of attributes), and when doubled, also enable wrapping of name-value pairs. With "-o ldif-wrap=no" given also, single name-value pairs would end up on a separate line, but such lines wouldn't be wrapped themselves. Alternatively one could use "-odiff-friendly=X" where X is 1 or 2. (In case of contextCSN one could even think of X=3 activating sort of the same attribute by attribute value) Do you think it's a useful enhancement? I must admit I played with the idea implementing it myself, but after having had a look at the source of slapcat, it looked more low-level than I had expected, so I had no idea where to start... Kind regards, Ulrich Windl

3 2

Q: DN of a user certificate
by Windl, Ulrich 19 Mar '25

19 Mar '25

Hi! I'm playing with mapping the DN of user certificates to (the DN of) LDAP users. Maybe I'm missing something, but it seems openLDAP appends the certificate DN to the LDAP context for authentication. That way the names can get really long, just as the olcAuthzRegexp will. So can anybody give a real-life example which DN to use for the user certificates? I mean certificate DN, LDAP user context and olcAuthzRegexp. Kind regards, Ulrich Windl

2 1

Q: Using SASL EXTERNAL with certificates for syncrepl
by Windl, Ulrich 19 Mar '25

19 Mar '25

Hi! I'm trying to convert out rencreplc configurtation using plain authentication over TLS to external authentication using a user certificate. It almost works, but slapd is reporting "connection_read(11): TLS accept failure error=-1 id=1002, closing" and "conn=1002 fd=11 closed (TLS negotiation failure)" while I can connect using the certificate and peer with openssl s_client Openssl reports: ... Requested Signature Algorithms: ECDSA+SHA256:ECDSA+SHA384:ECDSA+SHA512:Ed25519:Ed448:RSA-PSS+SHA256:RSA-PSS+SHA384:RSA-PSS+SHA512:RSA-PSS+SHA256:RSA-PSS+SHA384:RSA-PSS+SHA512:RSA+SHA256:RSA+SHA384:RSA+SHA512:ECDSA+SHA224:ECDSA+SHA1:RSA+SHA224:RSA+SHA1 Shared Requested Signature Algorithms: ECDSA+SHA256:ECDSA+SHA384:ECDSA+SHA512:Ed25519:Ed448:RSA-PSS+SHA256:RSA-PSS+SHA384:RSA-PSS+SHA512:RSA-PSS+SHA256:RSA-PSS+SHA384:RSA-PSS+SHA512:RSA+SHA256:RSA+SHA384:RSA+SHA512 Peer signing digest: SHA256 Peer signature type: RSA-PSS Server Temp Key: X25519, 253 bits --- SSL handshake has read 20974 bytes and written 5070 bytes Verification: OK --- New, TLSv1.3, Cipher is TLS_AES_256_GCM_SHA384 Server public key is 2400 bit This TLS version forbids renegotiation. Compression: NONE Expansion: NONE No ALPN negotiated Early data was not sent Verify return code: 0 (ok) ... Somehow I suspect that the certificate being a user certificate (DN mapped to a user entry) is not acceptable in syncrepl's tls_cert; can anybody confirm? The problem is that I'd like to trust a user certificate more than a host certificate for replication. And if I'd use a host certificate, how could I authenticate the user being used to get the changes? I looked a lot around using popular search engines, but could not find a useful example that is complete enough. Let me remark at this point that the description of tls_reqsan is quite poor in {SLAPD-CONFIG(5); it was not obvious to me that i9s is about "Subject Alternate Name". The other thing I noticed was a capitalized "Binding" in "...to establish a TLS session before Binding to the provider." (also in SLAPD-CONFIG(5)) Kind regards, Ulrich Windl

2 2

accesslog seemingly needs a lot of space
by Windl, Ulrich 19 Mar '25

19 Mar '25

Hi! Trying to convert my syncrepl configuration to a delta syncrepl configuration, the slave runs out of accesslog space during initial sync. For the main database about 30MB should be enough, but I configured 50MB, also for the accesslog files. It seems sync continues even if accesslog periodically complains like this: slapd[13951]: => mdb_idl_insert_keys: c_put id failed: MDB_MAP_FULL: Environment mapsize limit reached (-30792) slapd[13951]: conn=-1 op=0 accesslog_response: got result 0x50 adding log entry reqStart=20250314110032.000187Z,cn=changelog-1 From stat I guess that accesslog needs at least three times as much space as the main database does: # stat /var/lib/ldap/data.mdb /var/lib/ldap/changelog-1/data.mdb File: /var/lib/ldap/data.mdb Size: 22888448 Blocks: 44704 IO Block: 4096 regular file Device: 33h/51d Inode: 259467 Links: 1 Access: (0600/-rw-------) Uid: ( 76/ ldap) Gid: ( 70/ ldap) Access: 2025-03-14 11:57:46.303713632 +0100 Modify: 2025-03-14 12:01:08.417328586 +0100 Change: 2025-03-14 12:01:08.417328586 +0100 Birth: 2025-03-14 11:57:46.303713632 +0100 File: /var/lib/ldap/changelog-1/data.mdb Size: 52424704 Blocks: 102392 IO Block: 4096 regular file Device: 33h/51d Inode: 259471 Links: 1 Access: (0600/-rw-------) Uid: ( 76/ ldap) Gid: ( 70/ ldap) Access: 2025-03-14 11:57:46.323713395 +0100 Modify: 2025-03-14 12:01:08.425328492 +0100 Change: 2025-03-14 12:01:08.425328492 +0100 Birth: 2025-03-14 11:57:46.323713395 +0100 Shouldn't (assuming the sync happens entry-by-entry) the accesslog have about the same size as the main database after initial sync (when all databases were empty)? When setting the size of the accesslog database to twice the size of the database it succeeded which stats like this: # stat /var/lib/ldap/data.mdb /var/lib/ldap/changelog-1/data.mdb File: /var/lib/ldap/data.mdb Size: 22888448 Blocks: 44704 IO Block: 4096 regular file Device: 33h/51d Inode: 259514 Links: 1 Access: (0600/-rw-------) Uid: ( 76/ ldap) Gid: ( 70/ ldap) Access: 2025-03-14 12:39:01.278545521 +0100 Modify: 2025-03-14 12:45:03.558274733 +0100 Change: 2025-03-14 12:45:03.558274733 +0100 Birth: 2025-03-14 12:39:01.278545521 +0100 File: /var/lib/ldap/changelog-1/data.mdb Size: 89657344 Blocks: 175112 IO Block: 4096 regular file Device: 33h/51d Inode: 259518 Links: 1 Access: (0600/-rw-------) Uid: ( 76/ ldap) Gid: ( 70/ ldap) Access: 2025-03-14 12:39:01.298545286 +0100 Modify: 2025-03-14 12:45:03.566274639 +0100 Change: 2025-03-14 12:45:03.566274639 +0100 Birth: 2025-03-14 12:39:01.298545286 +0100 So the blocks in the accesslog are roughly four times (3.91 ) as much as in the original database. Is there any doc making statements about the proportion? (I'm a fan of "small is beautiful" instead of "bigger is better") Kind regards, Ulrich Windl

3 8

invalid olcAuthzRegexp crashed openLDAP server in SLES15 SP6
by Windl, Ulrich 17 Mar '25

17 Mar '25

Hi! At work I have to connect to our SLES servers via Windows RDP and a Windows server. Unfortunately RDP is not working reliably, and it sometimes misses key presses, and at other times it duplicates them. That way I ended up adding an olcAuthzRegexp that lacked a backspace. Unfrtunately when trying to ldapmodify the server I just got: modifying entry "cn=config" ldap_result: Can't contact LDAP server (-1) the regex in question is: olcAuthzRegexp: {3} "^dn:dnQualifier=uid\3D(^,)\\2Cou\\3Dpeople\\2Cdc\\3DXXX \\2Cdc\\3Dde$" "dn: uid=$1,ou=people,dc=XXX=de" As it turned out the server dumped core (100% reproducible). I know the regex is bad, but maybe it shouldn’t kill the server. The server is SUSE’s version that corresponds to some 2.5.x with patches. Anyway the backtrace is: Mar 17 14:36:23 v05 slapd[15911]: conn=1000 op=1 syncprov_matchops: recording uuid for dn=cn=config on opc=0x7fcfe0000d58 Mar 17 14:36:23 v05 slapd[15911]: slap_get_csn: conn=1000 op=1 generated new csn=20250317133623.651964Z#000000#005#000000 manage=1 Mar 17 14:36:23 v05 slapd[15911]: slap_queue_csn: queueing 0x7fcfe0106c70 20250317133623.651964Z#000000#005#000000 Mar 17 14:36:23 v05 kernel: slapd[15919]: segfault at 7fc81ceea633 ip 00007fcff658553e sp 00007fcfe9ff4e40 error 4 in libldap-2.5.releng.so.0.1.13[7fcff653b000+5c000] likely on CPU 1 (core 0, socket 2) Mar 17 14:36:23 v05 kernel: Code: 7f 08 4d 85 ff 75 9e 48 83 c4 18 b8 fa ff ff ff 5b 5d 41 5c 41 5d 41 5e 41 5f c3 90 48 85 ff 74 3b 41 54 55 31 ed 53 48 89 fb <48> 8b 7f 08 49 89 f4 48 85 ff 75 3e 48 8b 7b 10 48 85 ff 75 25 4d … Mar 17 14:36:23 v05 systemd[1]: Started Process Core Dump (PID 15922/UID 0). Mar 17 14:36:23 v05 systemd-coredump[15923]: [🡕] Process 15911 (slapd) of user 1000 dumped core. Stack trace of thread 15919: #0 0x00007fcff658553e ldap_avl_free (libldap-2.5.releng.so.0 + 0x4a53e) #1 0x0000555fb6ca9b42 rewrite_info_delete (slapd + 0xd6b42) #2 0x0000555fb6c64bae slap_sasl_regexp_config (slapd + 0x91bae) #3 0x0000555fb6c03a09 n/a (slapd + 0x30a09) #4 0x0000555fb6c091d3 config_set_vals (slapd + 0x361d3) #5 0x0000555fb6c0a14f config_parse_add (slapd + 0x3714f) #6 0x0000555fb6bfcdcc n/a (slapd + 0x29dcc) #7 0x0000555fb6bfdc96 n/a (slapd + 0x2ac96) #8 0x0000555fb6c8a523 overlay_op_walk (slapd + 0xb7523) #9 0x0000555fb6c8a6ae n/a (slapd + 0xb76ae) #10 0x0000555fb6c2dbd2 fe_op_modify (slapd + 0x5abd2) #11 0x0000555fb6c2f941 do_modify (slapd + 0x5c941) #12 0x0000555fb6c1618f n/a (slapd + 0x4318f) #13 0x0000555fb6c1698d n/a (slapd + 0x4398d) #14 0x00007fcff6583da0 n/a (libldap-2.5.releng.so.0 + 0x48da0) #15 0x00007fcff62a758c start_thread (libc.so.6 + 0xa758c) #16 0x00007fcff632ea28 __clone3 (libc.so.6 + 0x12ea28) Stack trace of thread 15915: #0 0x00007fcff62a3c4e __futex_abstimed_wait_common (libc.so.6 + 0xa3c4e) #1 0x00007fcff62a6890 pthread_cond_wait@@GLIBC_2.3.2 (libc.so.6 + 0xa6890) #2 0x00007fcff6583e40 n/a (libldap-2.5.releng.so.0 + 0x48e40) #3 0x00007fcff62a758c start_thread (libc.so.6 + 0xa758c) #4 0x00007fcff632ea28 __clone3 (libc.so.6 + 0x12ea28) Stack trace of thread 15917: #0 0x00007fcff62a3c4e __futex_abstimed_wait_common (libc.so.6 + 0xa3c4e) #1 0x00007fcff62a6890 pthread_cond_wait@@GLIBC_2.3.2 (libc.so.6 + 0xa6890) #2 0x00007fcff6583e40 n/a (libldap-2.5.releng.so.0 + 0x48e40) #3 0x00007fcff62a758c start_thread (libc.so.6 + 0xa758c) #4 0x00007fcff632ea28 __clone3 (libc.so.6 + 0x12ea28) Stack trace of thread 15911: #0 0x00007fcff62a3c4e __futex_abstimed_wait_common (libc.so.6 + 0xa3c4e) #1 0x00007fcff62a91a3 __pthread_clockjoin_ex (libc.so.6 + 0xa91a3) #2 0x0000555fb6c131ca slapd_daemon (slapd + 0x401ca) #3 0x0000555fb6bf688e main (slapd + 0x2388e) #4 0x00007fcff6240e6c __libc_start_call_main (libc.so.6 + 0x40e6c) #5 0x00007fcff6240f35 __libc_start_main@@GLIBC_2.34 (libc.so.6 + 0x40f35) #6 0x0000555fb6bf690a _start (slapd + 0x2390a) Stack trace of thread 15913: #0 0x00007fcff632ee86 epoll_wait (libc.so.6 + 0x12ee86) #1 0x0000555fb6c1007b n/a (slapd + 0x3d07b) #2 0x00007fcff62a758c start_thread (libc.so.6 + 0xa758c) #3 0x00007fcff632ea28 __clone3 (libc.so.6 + 0x12ea28) Stack trace of thread 15918: #0 0x00007fcff62a3c4e __futex_abstimed_wait_common (libc.so.6 + 0xa3c4e) #1 0x00007fcff62a6890 pthread_cond_wait@@GLIBC_2.3.2 (libc.so.6 + 0xa6890) #2 0x00007fcff6583e40 n/a (libldap-2.5.releng.so.0 + 0x48e40) #3 0x00007fcff62a758c start_thread (libc.so.6 + 0xa758c) #4 0x00007fcff632ea28 __clone3 (libc.so.6 + 0x12ea28) Stack trace of thread 15914: #0 0x00007fcff62a3c4e __futex_abstimed_wait_common (libc.so.6 + 0xa3c4e) #1 0x00007fcff62a6890 pthread_cond_wait@@GLIBC_2.3.2 (libc.so.6 + 0xa6890) #2 0x00007fcff6583e40 n/a (libldap-2.5.releng.so.0 + 0x48e40) #3 0x00007fcff62a758c start_thread (libc.so.6 + 0xa758c) #4 0x00007fcff632ea28 __clone3 (libc.so.6 + 0x12ea28) ELF object binary architecture: AMD x86-64 Mar 17 14:36:23 v05 ldapmodify[15921]: DIGEST-MD5 common mech free Mar 17 14:36:23 v05 systemd[1]: slapd.service: Main process exited, code=dumped, status=11/SEGV Mar 17 14:36:23 v05 systemd[1]: slapd.service: Failed with result 'core-dump'. Mar 17 14:36:23 v05 systemd[1]: systemd-coredump(a)3-15922-0.service: Deactivated successfully. Kind regards, Ulrich Windl

2 1

Trying to set 'olcPasswordHash' I get "ldap_modify: Object class violation (65) additional info: attribute 'olcPasswordHash' not allowed"
by Windl, Ulrich 17 Mar '25

17 Mar '25

Hi! After having loaded pw-sha2 in oOpenmLDAp 2.5, I tried to set a new default hashing schema, but I fail to do so using dn: olcDatabase={-1}frontend,cn=config changetype: modify add: olcPasswordHash olcPasswordHash: {SSHA256} olcPasswordHash: {SSHA} ---- modifying entry "olcDatabase={-1}frontend,cn=config" ldap_modify: Object class violation (65) additional info: attribute 'olcPasswordHash' not allowed Before I had tried "replace" instead of "add", and I tried to place both values in one line as suggested by slapd-config: olcPasswordHash: <hash> [<hash>...] This option configures one or more hashes to be used in generation of user passwords stored in the userPassword attribute during processing of LDAP Password Modify Extended Operations (RFC 3062). The <hash> must be one of {SSHA}, {SHA}, {SMD5}, {MD5}, {CRYPT}, and {CLEARTEXT}. The default is {SSHA}. The manual page also states: This setting is only allowed in the frontend entry. I'm running out of ideas. Kind regards, Ulrich Windl

3 11

Understanding sync log for delta syncrepl
by Windl, Ulrich 17 Mar '25

17 Mar '25

Hi! Most likely I misconfigured the accesslog databases used for delta syncrepl (I'm still working on it), but I have some trouble understanding the logs created. I have two identical servers (SIDs 5 and 6) that also have an identical cn=config that is to be synced as well) I created two accesslog databases, one for cn=config, and one for the main database. For SDID=5 I see messages like: Mar 14 15:17:39 v05 slapd[26377]: do_syncrep1: rid=006 starting refresh (sending cookie=rid=006,sid=005,csn=20250314000000.000000Z#000000#000#000000;20250314000000.000000Z#000000#001#000000;20200721123717.002866Z#000000#002#000000;20181031083258.073732Z#000000#003#000000;20250314000002.000000Z#000000#005#000000;20250227092006.790591Z#000000#006#000000) Mar 14 15:17:39 v05 slapd[26377]: do_syncrep2: rid=006 LDAP_RES_SEARCH_RESULT Mar 14 15:17:39 v05 slapd[26377]: do_syncrepl: rid=006 rc -101 retrying Mar 14 15:17:39 v05 slapd[26377]: do_syncrep1: rid=006 starting refresh (sending cookie=rid=006,sid=005,csn=20130719093756.074776Z#000000#000#000000;20250217105250.345944Z#000000#001#000000;20250218171739.629994Z#000000#002#000000;20250217065706.238392Z#000000#003#000000;20250227092327.859231Z#000000#005#000000;20250227092348.803001Z#000000#006#000000) Mar 14 15:17:39 v05 slapd[26377]: do_syncrep2: rid=006 got search entry without Sync State control (reqStart=20250314114001.000003Z,cn=changelog-1) Mar 14 15:17:39 v05 slapd[26377]: do_syncrepl: rid=006 rc -1 retrying For the same time interval I see for SID=6: Mar 14 15:17:26 v06 slapd[14537]: do_syncrep1: rid=005 starting refresh (sending cookie=rid=005,sid=006,csn=20130719093756.074776Z#000000#000#000000;20250217105250.345944Z#000000#001#000000;20250218171739.629994Z#000000#002#000000;20250217065706.238392Z#000000#003#000000;20250227092327.859231Z#000000#005#000000;20250227092348.803001Z#000000#006#000000) Mar 14 15:17:26 v06 slapd[14537]: do_syncrep2: rid=005 LDAP_RES_SEARCH_RESULT Mar 14 15:17:26 v06 slapd[14537]: do_syncrepl: rid=005 rc -101 retrying Mar 14 15:17:26 v06 slapd[14537]: do_syncrep1: rid=005 starting refresh (sending cookie=rid=005,sid=006,csn=20250314000000.000000Z#000000#000#000000;20250314000000.000000Z#000000#001#000000;20200721123717.002866Z#000000#002#000000;20181031083258.073732Z#000000#003#000000;20250314000002.000000Z#000000#005#000000;20250227092006.790591Z#000000#006#000000) Mar 14 15:17:26 v06 slapd[14537]: do_syncrep2: rid=005 got search entry without Sync State control (reqStart=20250314123529.000001Z,cn=changelog-0) Mar 14 15:17:26 v06 slapd[14537]: do_syncrepl: rid=005 rc -1 retrying (no corelated messages on Node 1) Mar 14 15:17:39 v06 slapd[14537]: send_search_entry: conn 1021 ber write failed. Specifically I wonder what the "rc -101 retrying" is really about: the servers should be able to connect to each other. Also what "got search entry without Sync State control" means. Finally I also have a "rc -1 retrying" and the "ber write failed". I really don't know where to start debugging. The first syncprov is. dn: olcOverlay={0}syncprov,olcDatabase={0}config,cn=config objectClass: olcSyncProvConfig olcOverlay: syncprov olcSpCheckpoint: 100 10 olcSpSessionlog: 10 My first accesslog looks like: dn: olcOverlay={1}accesslog,olcDatabase={0}config,cn=config objectClass: olcOverlayConfig objectClass: olcAccessLogConfig olcOverlay: accesslog olcAccessLogDB: cn=changelog-0 olcAccessLogOps: writes olcAccessLogPurge: 60+00:00 1+00:00 olcAccessLogSuccess: FALSE olcAccessLogOld: (objectClass=*) The second syncprov is: dn: olcOverlay={0}syncprov,olcDatabase={1}mdb,cn=config objectClass: olcSyncProvConfig olcOverlay: syncprov olcSpCheckpoint: 100 10 olcSpSessionlog: 100 The second accesslog is: dn: olcOverlay={1}accesslog,olcDatabase={1}mdb,cn=config objectClass: olcOverlayConfig objectClass: olcAccessLogConfig olcOverlay: accesslog olcAccessLogDB: cn=changelog-1 olcAccessLogOps: writes olcAccessLogPurge: 60+00:00 1+00:00 olcAccessLogSuccess: FALSE olcAccessLogOld: (objectClass=*) And the databases are: dn: olcDatabase={3}mdb,cn=config objectClass: olcDatabaseConfig objectClass: olcMdbConfig olcDatabase: mdb olcDbDirectory: /var/lib/ldap/changelog-0 olcSuffix: cn=changelog-0 olcAccess: {0}to * by dn.exact="uid=syncrepl,..." read by * break olcLimits: {0}dn.exact="uid=syncrepl,..." size.soft=unlimited olcRootDN: cn=admin,cn=changelog-0 olcRootPW: log-0 dn: olcDatabase={4}mdb,cn=config objectClass: olcDatabaseConfig objectClass: olcMdbConfig olcDatabase: mdb olcDbDirectory: /var/lib/ldap/changelog-1 olcSuffix: cn=changelog-1 olcAccess: {0}to * by dn.exact="uid=syncrepl,..." read by * break olcLimits: {0}dn.exact="uid=syncrepl,..." size.soft=unlimited olcRootDN: cn=admin,cn=changelog-1 olcRootPW: log-1 The syncrepl definitions are like this: olcSyncrepl: {0}rid=5 provider="ldap://v05 /" searchbase="cn=config" type="refreshAndPersist" \ retry="60 5 300 5 1800 +" logbase=cn=changelog-0 logfilter="(&(objectClass=auditWriteObject)(reqResult=0))" \ schemachecking=on syncdata=accesslog starttls=critical tls_reqcert=demand bindmethod="simple" binddn="uid=syncrepl,..." credentials="replicationtest" olcSyncrepl: {1}rid=6 provider="ldap://v06 /" searchbase="cn=config" type="refreshAndPersist" \ retry="60 5 300 5 1800 +" logbase=cn=changelog-0 logfilter="(&(objectClass=auditWriteObject)(reqResult=0))" \ schemachecking=on syncdata=accesslog starttls=critical tls_reqcert=demand bindmethod="simple" binddn="uid=syncrepl,..." credentials="replicationtest" olcSyncrepl: {0}rid=5 provider="ldap:// v05 /" searchbase="dc=..." type="refreshAndPersist" \ retry="60 5 300 5 1800 +" logbase=cn=changelog-1 logfilter="(&(objectClass=auditWriteObject)(reqResult=0))" schemachecking=on syncdata=accesslog \ starttls=critical tls_reqcert=demand bindmethod="simple" binddn="uid=syncrepl,..." credentials="replicationtest" olcSyncrepl: {1}rid=6 provider="ldap://v06 /" searchbase="dc=... " type="refreshAndPersist" \ retry="60 5 300 5 1800 +" logbase=cn=changelog-1 logfilter="(&(objectClass=auditWriteObject)(reqResult=0))" schemachecking=on syncdata=accesslog \ starttls=critical tls_reqcert=demand bindmethod="simple" binddn="uid=syncrepl,..." credentials="replicationtest" Kind regards, Ulrich Windl

1 0

Re: consumer replication not recovering
by Ondřej Kuzník 14 Mar '25

14 Mar '25

On Wed, Mar 12, 2025 at 03:10:12PM -0400, Suresh Veliveli wrote: > Here it is. Hi Suresh, I apologise for not really getting back to you for a while, rest assured I'm still thinking about it. However I'm still confused what might be happening and don't have much in terms of advice yet except that yes, the two (replication effectively stopping and the crash) seem to be two symptoms of the same issue. It looks like you're building OpenLDAP yourself, would you be able to apply a patch or two adding extra information to the sync logs that might help us trace this better? Are you able to compile and run OpenLDAP with -fsanitize=address in CFLAGS or an equivalent? > [root@...] # gdb ... > Reading symbols from /var/services/openldap/libexec/slapd... > BFD: warning: > /var/users/suresh.a/core.slapd.3003.bea19f5a376843abb488dce68d6e81af.5036.1741456520000000 > has a segment extending past end of file > [...] > warning: Error reading shared library list entry at 0x696e6e75723a5652 > Cannot access memory at address 0x69626f6e6e613a5e > Cannot access memory at address 0x69626f6e6e613a56 > Failed to read a valid object file image from memory. > [...] > Thread 2 (LWP 5036): > #0 0x00007f792d8868ba in ?? () > No symbol table info available. > Backtrace stopped: Cannot access memory at address 0x7ffebb22d9a0 I am a little concerned by the above warnings and the fact gdb is unable to extract any stack information at all from most threads. Doesn't seem to correspond what I'd usually see even when debugging information is missing. > Thread 1 (LWP 7650): > #0 connection_abandon (c=0x7f79158a5ba8) at connection.c:714 > o = 0x7f5fa0148170 > next = 0x7f5f90010300 In this frame, would you be able to print the following and paste/attach them here? - '*c' - '*o' - '*o->o_hdr' Thanks, -- Ondřej Kuzník Senior Software Engineer Symas Corporation http://www.symas.com Packaged, certified, and supported LDAP solutions powered by OpenLDAP

1 0

Request for Guidance on Upgrading from 2.4.x(BDB with ppolicy) to 2.6.9
by anilkumar.pathuri7＠gmail.com 13 Mar '25

13 Mar '25

Dear LDAP Community, We are planning to upgrade our setup from OpenLDAP 2.4.x to 2.6.9 (latest version) and would appreciate your guidance on the following: Is a direct upgrade from 2.4.x to 2.6.9 possible, or are there intermediate steps required? We are currently using BDB with ppolicy. Does 2.6.9 support BDB, or is migration to MDB mandatory? Is ppolicy still supported in 2.6.9? Are the ppolicy module and schema included in 2.6.9, or do they need to be obtained externally? If a migration from BDB with ppolicy to MDB with ppolicy is required, could you kindly provide step-by-step guidance? We greatly appreciate any insights, documentation, or recommendations you can share. Thank you for your support! Regards, Anil P

3 3

Re: consumer replication net recovering
by Suresh Veliveli 12 Mar '25

12 Mar '25

This is another instance where replication stops. Dec 23 01:01:23 aaa-prod-aws-3 slapd[1182444]: syncrepl_entry: rid=143 LDAP_RES_SEARCH_ENTRY(LDAP_SYNC_MODIFY) csn=20241223060050.594465Z#000000#000#000000 tid 0x7f5aed0fb640 Dec 23 01:01:23 aaa-prod-aws-3 slapd[1182444]: syncrepl_entry: rid=143 be_search (0) Dec 23 01:01:23 aaa-prod-aws-3 slapd[1182444]: syncrepl_entry: rid=143 uid=xxxx,ou=People,dc=georgetown,dc=edu Dec 23 01:01:23 aaa-prod-aws-3 slapd[1182444]: syncrepl_entry: rid=143 be_modify uid=xxxxx,ou=People,dc=georgetown,dc=edu (0) Dec 23 01:01:23 aaa-prod-aws-3 slapd[1182444]: syncrepl_message_to_entry: rid=143 DN: uid=xxxxx,ou=People,dc=georgetown,dc=edu, UUID: db41232e-527d-103f-995c-4344349468b5 Dec 23 01:01:23 aaa-prod-aws-3 slapd[1182444]: syncrepl_entry: rid=143 LDAP_RES_SEARCH_ENTRY(LDAP_SYNC_MODIFY) csn=20241223060104.603554Z#000000#000#000000 tid 0x7f5aed0fb640 Dec 23 01:01:23 aaa-prod-aws-3 slapd[1182444]: syncrepl_entry: rid=143 be_search (0) Dec 23 01:01:23 aaa-prod-aws-3 slapd[1182444]: syncrepl_entry: rid=143 uid=yyyyy,ou=People,dc=georgetown,dc=edu Dec 23 01:01:23 aaa-prod-aws-3 slapd[1182444]: syncrepl_entry: rid=143 be_modify uid=yyyy,ou=People,dc=georgetown,dc=edu (0) No "syncrep_" messages were logged after the above. Regards, Suresh On Mon, Dec 23, 2024 at 2:42 PM Quanah Gibson-Mount <quanah(a)fast-mail.org> wrote: > > > --On Friday, December 20, 2024 5:46 PM -0500 Suresh Veliveli > <Suresh.Veliveli(a)georgetown.edu> wrote: > > > > > I do have these but no syncrepl_sync. > > > > > > Dec 12 08:59:30 aaa-prod-gcp-9 slapd[4165]: syncrepl_message_to_entry: > > rid=129 DN: uid=xxxx,ou=xxxx,dc=georgetown,dc=edu, UUID: > > 37387976-3ae0-103f-94fc-3b4be3361dc7 > > Dec 12 08:59:30 aaa-prod-gcp-9 slapd[4165]: syncrepl_entry: rid=129 > > LDAP_RES_SEARCH_ENTRY(LDAP_SYNC_MODIFY) > > csn=20241212135921.652395Z#000000#000#000000 tid 0x7f671b7fe640 > > Yes sorry, that was a typo on my end. > > "syncrepl_" sync messages. Specifically you want to see the ones that > have > "be_" in them, but not "be_search". I.e., be_add, be_modify, etc. They > show the result of the operation, something like: > > syncrepl_entry: rid=100 be_modify <DN> (<result code>) > > --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)

5 30

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

openldap-technical March 2025