- openldap-bugs - openldap.org

[Issue 9787] New: 2.6.1 segfault in slaptest when logfile-format param is set
by openldap-its＠openldap.org 04 May '22

04 May '22

https://bugs.openldap.org/show_bug.cgi?id=9787 Issue ID: 9787 Summary: 2.6.1 segfault in slaptest when logfile-format param is set Product: OpenLDAP Version: 2.6.1 Hardware: All OS: Linux Status: UNCONFIRMED Keywords: needs_review Severity: normal Priority: --- Component: slapd Assignee: bugs(a)openldap.org Reporter: smckinney(a)symas.com Target Milestone: --- Segfault in slaptest when any value for logfile-format is set. debug, syslog-utc, etc. This doesn’t occur during slapd startup. Only in slaptest. Observed on U20 and R8 platforms. slapd.conf ``` logfile "/var/symas/openldap-data/openldap26.log" logfile-only on # segfaults when any value for: logfile-format syslog-utc ``` Backtrace: ``` #0 0x00007f8fca27f685 in __strlen_avx2 () from /lib64/libc.so.6 #1 0x000055df6eaddedf in config_logging (c=<optimized out>) at logging.c:731 #2 0x000055df6ea9fe33 in config_set_vals (Conf=0x55df6edbe348 <config_back_cf_table+3432>, c=0x55df70bc4080) at config.c:378 #3 0x000055df6eaa3010 in read_config_file (fname=fname@entry=0x7ffe8f3a4706 "/opt/symas/etc/openldap/slapd.conf", depth=depth@entry=0, cf=cf@entry=0x0, cft=cft@entry=0x55df6edbd5e0 <config_back_cf_table>) at config.c:908 #4 0x000055df6ea98b98 in read_config (fname=fname@entry=0x7ffe8f3a4706 "/opt/symas/etc/openldap/slapd.conf", dir=dir@entry=0x0) at bconfig.c:4519 #5 0x000055df6eb29946 in slap_tool_init (progname=progname@entry=0x55df6eb50da3 "slaptest", tool=tool@entry=8, argc=4, argv=0x7ffe8f3a28f8) at slapcommon.c:682 #6 0x000055df6eb2c27e in slaptest (argc=<optimized out>, argv=<optimized out>) at slaptest.c:99 #7 0x000055df6ea8baea in main (argc=4, argv=0x7ffe8f3a28f8) at main.c:287 (gdb ``` -- You are receiving this mail because: You are on the CC list for the issue.

1 5

[Issue 9780] New: Documenting sticky session support in 2.6
by openldap-its＠openldap.org 04 May '22

04 May '22

https://bugs.openldap.org/show_bug.cgi?id=9780 Issue ID: 9780 Summary: Documenting sticky session support in 2.6 Product: OpenLDAP Version: 2.6.0 Hardware: All OS: All Status: UNCONFIRMED Keywords: needs_review Severity: normal Priority: --- Component: lloadd Assignee: bugs(a)openldap.org Reporter: dpa-openldap(a)aegee.org Target Milestone: --- https://www.openldap.org/doc/admin26/loadbalancer.html contains the documentation for lload version 2.6. It says: • 2.6 release of lloadd will include sticky sessions (coherency). Since this is the documentation for version 2.6, the documentation shall say what is included in v2.6, not what will be included in v2.6. -- You are receiving this mail because: You are on the CC list for the issue.

1 4

[Issue 9790] New: Build failure with GCC 4.1 and 4.3
by openldap-its＠openldap.org 04 May '22

04 May '22

https://bugs.openldap.org/show_bug.cgi?id=9790 Issue ID: 9790 Summary: Build failure with GCC 4.1 and 4.3 Product: OpenLDAP Version: 2.6.1 Hardware: All OS: Linux Status: UNCONFIRMED Keywords: needs_review Severity: normal Priority: --- Component: build Assignee: bugs(a)openldap.org Reporter: orgads(a)gmail.com Target Milestone: --- In file included from ../../include/lutil.h:21, from passwd.c:60: ../../include/ac/socket.h:247: error: redefinition of typedef 'Sockaddr' ../../include/ldap_pvt.h:188: error: previous declaration of 'Sockaddr' was here -- You are receiving this mail because: You are on the CC list for the issue.

1 4

[Issue 9788] New: make warns about disabling/resetting jobserver
by openldap-its＠openldap.org 04 May '22

04 May '22

https://bugs.openldap.org/show_bug.cgi?id=9788 Issue ID: 9788 Summary: make warns about disabling/resetting jobserver Product: OpenLDAP Version: 2.6.1 Hardware: All OS: Linux Status: UNCONFIRMED Keywords: needs_review Severity: normal Priority: --- Component: build Assignee: bugs(a)openldap.org Reporter: orgads(a)gmail.com Target Milestone: --- Running make -j8 issues the following warning for each directory with make 4.3: make[2]: warning: -j8 forced in submake: resetting jobserver mode. with make 4.2.1: make[3]: warning: -jN forced in submake: disabling jobserver mode. With make 3.82 there is no warning, but the jobserver flags are duplicated for each nested directory. e.g.: cd back-monitor && make -w --jobserver-fds=3,4 - --jobserver-fds=3,4 - --jobserver-fds=3,4 - --jobserver-fds=3,4 -j all On my env this is fixed by removing all the occurrences of $(MFLAGS) from build/dir.mk. MFLAGS is picked up by make when it exists, and there is no need to pass it explicitly. -- You are receiving this mail because: You are on the CC list for the issue.

1 4

[Issue 9831] New: connection_next() can skip an active connection
by openldap-its＠openldap.org 04 May '22

04 May '22

https://bugs.openldap.org/show_bug.cgi?id=9831 Issue ID: 9831 Summary: connection_next() can skip an active connection Product: OpenLDAP Version: unspecified Hardware: All OS: All Status: UNCONFIRMED Keywords: needs_review Severity: normal Priority: --- Component: slapd Assignee: bugs(a)openldap.org Reporter: ondra(a)mistotebe.net Target Milestone: --- Uncovered by running test056 under interesting conditions repeatedly. -- You are receiving this mail because: You are on the CC list for the issue.

1 5

[Issue 9809] New: slapo-pcache: incorrect call to monitor unregister_entry
by openldap-its＠openldap.org 04 May '22

04 May '22

https://bugs.openldap.org/show_bug.cgi?id=9809 Issue ID: 9809 Summary: slapo-pcache: incorrect call to monitor unregister_entry Product: OpenLDAP Version: 2.4.18 Hardware: All OS: All Status: UNCONFIRMED Keywords: needs_review Severity: normal Priority: --- Component: overlays Assignee: bugs(a)openldap.org Reporter: hyc(a)openldap.org Target Milestone: --- Also an incorrect check for whether monitoring was initialized, thus calling unregister_entry_callback when there's nothing to unregister. The incorrect call causes a SEGV. The incorrect call is also present in back-mdb, but never invoked because it correctly sees there's nothing to unregister. -- You are receiving this mail because: You are on the CC list for the issue.

1 5

[Issue 9811] New: slapadd silently fails when importing ldif file including another one
by openldap-its＠openldap.org 04 May '22

04 May '22

https://bugs.openldap.org/show_bug.cgi?id=9811 Issue ID: 9811 Summary: slapadd silently fails when importing ldif file including another one Product: OpenLDAP Version: 2.5.11 Hardware: All OS: All Status: UNCONFIRMED Keywords: needs_review Severity: normal Priority: --- Component: slapd Assignee: bugs(a)openldap.org Reporter: david.coutadeur(a)gmail.com Target Milestone: --- This issue is about openldap 2.5.11. (not tested on 2.6) When importing a new configuration from an ldif file, for example by this command: slapadd -n0 -F /usr/local/openldap/etc/openldap/slapd.d -l /var/backups/openldap/config-00000000000000.ldif the command answers by a 0 result code but the cn=config database is not fully imported. Also there is no special message displayed. The complete config-00000000000000.ldif file is below. The problem is in the custom.ldif included from config-00000000000000.ldif For example, the problem appears if the custom.ldif is this one: ``` # Custom ldif schema ``` or if the custom.ldif is that one (with an end-of-line at the end): ``` # Custom ldif schema dn: cn=custom,cn=schema,cn=config objectClass: olcSchemaConfig cn: custom ``` The expected behaviour should be to return an error code, and to display the corresponding message on stdout. Here is the full config-00000000000000.ldif file: ``` dn: cn=config objectClass: olcGlobal cn: config olcConfigFile: slapd.conf olcConfigDir: slapd.d olcArgsFile: /usr/local/openldap/var/run/slapd.args olcAttributeOptions: lang- olcAuthzPolicy: none olcConcurrency: 0 olcConnMaxPending: 100 olcConnMaxPendingAuth: 1000 olcGentleHUP: FALSE olcIdleTimeout: 0 olcIndexSubstrIfMaxLen: 4 olcIndexSubstrIfMinLen: 2 olcIndexSubstrAnyLen: 4 olcIndexSubstrAnyStep: 2 olcIndexIntLen: 4 olcListenerThreads: 1 olcLocalSSF: 71 olcPidFile: /usr/local/openldap/var/run/slapd.pid olcReadOnly: FALSE olcSaslHost: 127.0.0.1 olcSaslSecProps: none olcServerID: 1 olcSockbufMaxIncoming: 262143 olcSockbufMaxIncomingAuth: 16777215 olcThreads: 16 olcTLSCACertificateFile: /etc/ssl/certs/ca-certificates.crt olcTLSCertificateFile: /etc/ssl/certs/ssl-cert-snakeoil.pem olcTLSCertificateKeyFile: /etc/ssl/private/ssl-cert-snakeoil.key olcTLSCRLCheck: none olcTLSVerifyClient: allow olcTLSProtocolMin: 3.3 olcToolThreads: 1 olcWriteTimeout: 0 olcLogLevel: stats dn: cn=module{0},cn=config objectClass: olcModuleList cn: module{0} olcModulePath: /usr/local/openldap/lib64/:/usr/local/openldap/libexec/openldap/ olcModuleLoad: argon2.la olcModuleLoad: pw-pbkdf2.la olcModuleLoad: back_mdb.la olcModuleLoad: dynlist.la olcModuleLoad: ppolicy.la olcModuleLoad: syncprov.la olcModuleLoad: unique.la olcModuleLoad: refint.la dn: cn=schema,cn=config objectClass: olcSchemaConfig cn: schema include: file:///usr/local/openldap/etc/openldap/schema/core.ldif include: file:///usr/local/openldap/etc/openldap/schema/cosine.ldif include: file:///usr/local/openldap/etc/openldap/schema/nis.ldif include: file:///usr/local/openldap/etc/openldap/schema/inetorgperson.ldif include: file:///usr/local/openldap/etc/openldap/schema/dyngroup.ldif include: file:///usr/local/openldap/etc/openldap/schema/custom.ldif dn: olcDatabase={-1}frontend,cn=config objectClass: olcDatabaseConfig objectClass: olcFrontendConfig olcDatabase: {-1}frontend olcAccess: to * by dn.exact=gidNumber=0+uidNumber=0,cn=peercred,cn=external,cn=auth manage by * break olcAccess: to dn.base="" by * read olcAccess: to dn.base="cn=Subschema" by * read olcAccess: to * by self write by users read by anonymous auth olcAddContentAcl: FALSE olcLastMod: TRUE olcMaxDerefDepth: 0 olcReadOnly: FALSE olcSchemaDN: cn=Subschema olcSecurity: ssf=128 olcSizeLimit: 500 olcSyncUseSubentry: FALSE olcMonitoring: FALSE olcPasswordHash: {ARGON2} olcSortVals: member dn: olcDatabase={0}config,cn=config objectClass: olcDatabaseConfig olcDatabase: {0}config olcAccess: {0}to * by * none olcAddContentAcl: TRUE olcLastMod: TRUE olcMaxDerefDepth: 15 olcReadOnly: FALSE olcRootDN: cn=admin,cn=config olcRootPW: {ARGON2}$argon2id$v=19$m=65536,t=2,p=1$eBzdIP+Zv/H/TmAw0xTXOg$JNQR9asBjEX5XYcTuqygvIY5S3iH43uqaqWQa9e0jNU olcSyncUseSubentry: FALSE olcMonitoring: FALSE dn: olcDatabase={1}mdb,cn=config objectClass: olcDatabaseConfig objectClass: olcMdbConfig olcDatabase: {1}mdb olcDbDirectory: /usr/local/openldap/var/openldap-data olcSuffix: dc=my-organization,dc=com olcLastMod: TRUE olcMaxDerefDepth: 15 olcReadOnly: FALSE olcRootDN: cn=admin,dc=my-organization,dc=com olcRootPW: {ARGON2}$argon2id$v=19$m=65536,t=2,p=1$22H7iUTEuPMmwYnLr07PjQ$257rNncoS6L/k4HUXmROU7p2SfinVjfjFeUz4pK8gEw olcSyncUseSubentry: FALSE olcLastBind: TRUE olcMonitoring: TRUE olcDbIndex: objectClass eq olcDbIndex: entryUUID eq olcDbIndex: entryCSN eq olcDbIndex: cn pres,eq,sub olcDbIndex: uid pres,eq,sub olcDbMaxSize: 4294967296 dn: olcOverlay={0}syncprov,olcDatabase={1}mdb,cn=config objectClass: olcOverlayConfig objectClass: olcSyncProvConfig olcOverlay: {0}syncprov olcSpCheckpoint: 100 10 olcSpSessionlog: 100 dn: olcOverlay={1}ppolicy,olcDatabase={1}mdb,cn=config objectClass: olcOverlayConfig objectClass: olcPPolicyConfig olcOverlay: {1}ppolicy olcPPolicyDefault: cn=default,ou=ppolicies,dc=my-organization,dc=com olcPPolicyHashCleartext: TRUE olcPPolicyUseLockout: TRUE dn: olcOverlay={2}refint,olcDatabase={1}mdb,cn=config objectClass: olcOverlayConfig objectClass: olcRefintConfig olcOverlay: {2}refint olcRefintAttribute: member olcRefintNothing: cn=nothing,dc=my-organization,dc=com dn: olcOverlay={3}dynlist,olcDatabase={1}mdb,cn=config objectClass: olcOverlayConfig objectClass: olcDynamicList olcOverlay: {3}dynlist olcDlAttrSet: groupOfURLs memberURL member+memberOf@groupOfNames* dn: olcDatabase={2}monitor,cn=config objectClass: olcDatabaseConfig olcDatabase: {2}monitor olcRootDN: cn=monitor olcRootPW: {ARGON2}$argon2id$v=19$m=65536,t=2,p=1$f1aoIjM0CjWwGIyBAsjzyw$j+1bYxs+CYOPR2lXrvamB7yFzSX/nNMiVwIn7vwPRVw olcAddContentAcl: FALSE olcLastMod: TRUE olcMaxDerefDepth: 15 olcReadOnly: FALSE olcSyncUseSubentry: FALSE olcMonitoring: FALSE ``` -- You are receiving this mail because: You are on the CC list for the issue.

1 6

[Issue 9803] New: liblber: assertion( ber->ber_buf == NULL ); failed
by openldap-its＠openldap.org 04 May '22

04 May '22

https://bugs.openldap.org/show_bug.cgi?id=9803 Issue ID: 9803 Summary: liblber: assertion( ber->ber_buf == NULL ); failed Product: OpenLDAP Version: 2.4.46 Hardware: x86_64 OS: Linux Status: UNCONFIRMED Keywords: needs_review Severity: normal Priority: --- Component: libraries Assignee: bugs(a)openldap.org Reporter: jengelh(a)inai.de Target Milestone: --- libraries/liblber/io.c function ber_get_next contains a line assert( ber->ber_buf == NULL ); and with a larger application that uses libldap-2.4.46, I am running into that sporadically. I have no idea how that happens, but it seems probable the LDAP server (of which there is also no info on) is sending something that is interpreted as invalid and ber_buf does not get freed, so it's set on the next invocation. ``` (gdb) zcore: io.c:514: ber_get_next: Assertion `ber->ber_buf == NULL' failed. Thread 40 "rpc/34" received signal SIGABRT, Aborted. [Switching to Thread 0x7fffd6ff8700 (LWP 18485)] (gdb) up #1 0x00007ffff20fb585 in abort () from /lib64/libc.so.6 (gdb) #2 0x00007ffff20f285a in __assert_fail_base () from /lib64/libc.so.6 (gdb) #3 0x00007ffff20f28d2 in __assert_fail () from /lib64/libc.so.6 (gdb) #4 0x00007fffee0f48a1 in ber_get_next (sb=0x6040000aa650, len=len@entry=0x7fffd6ff61c8, ber=ber@entry=0x6070000b0360) at io.c:514 514 assert( ber->ber_buf == NULL ); (gdb) p ber $1 = (BerElement *) 0x6070000b0360 (gdb) p *ber $2 = {ber_opts = {lbo_valid = 2, lbo_options = 1, lbo_debug = 0}, ber_tag = 116, ber_len = 78, ber_usertag = 0, ber_buf = 0x6070000b03d0 "cP", ber_ptr = 0x6070000b03d0 "cP", ber_end = 0x6070000b041e "", ber_sos_ptr = 0x0, ber_rwptr = 0x0, ber_memctx = 0x0} (gdb) up #5 0x00007fffee310c91 in try_read1msg (result=0x7fffd6ff6348, lc=0x6080001182a0, all=1, msgid=18, ld=0x6040000aa610) at result.c:494 494 tag = ber_get_next( lc->lconn_sb, &len, ber ); (gdb) up #6 wait4msg (result=0x7fffd6ff6348, timeout=<optimized out>, all=1, msgid=<optimized out>, ld=0x6040000aa610) at result.c:365 365 rc = try_read1msg( ld, msgid, all, lc, result ); (gdb) #7 ldap_result (ld=ld@entry=0x6040000aa610, msgid=<optimized out>, all=all@entry=1, timeout=timeout@entry=0x0, result=result@entry=0x7fffd6ff6348) at result.c:120 120 rc = wait4msg( ld, msgid, all, timeout, result ); (gdb) p result $3 = (LDAPMessage **) 0x7fffd6ff6348 (gdb) p result[0] $4 = (LDAPMessage *) 0x0 (gdb) dow #6 wait4msg (result=0x7fffd6ff6348, timeout=<optimized out>, all=1, msgid=<optimized out>, ld=0x6040000aa610) at result.c:365 365 rc = try_read1msg( ld, msgid, all, lc, result ); (gdb) dow #5 0x00007fffee310c91 in try_read1msg (result=0x7fffd6ff6348, lc=0x6080001182a0, all=1, msgid=18, ld=0x6040000aa610) at result.c:494 494 tag = ber_get_next( lc->lconn_sb, &len, ber ); (gdb) p ber $5 = <optimized out> (gdb) dow #4 0x00007fffee0f48a1 in ber_get_next (sb=0x6040000aa650, len=len@entry=0x7fffd6ff61c8, ber=ber@entry=0x6070000b0360) at io.c:514 514 assert( ber->ber_buf == NULL ); (gdb) l 509 * 510 * We expect tag and len to be at most 32 bits wide. 511 */ 512 513 if (ber->ber_rwptr == NULL) { 514 assert( ber->ber_buf == NULL ); 515 ber->ber_rwptr = (char *) &ber->ber_len-1; 516 ber->ber_ptr = ber->ber_rwptr; 517 ber->ber_tag = 0; 518 } (gdb) p ber $6 = (BerElement *) 0x6070000b0360 (gdb) p ber[0] $7 = {ber_opts = {lbo_valid = 2, lbo_options = 1, lbo_debug = 0}, ber_tag = 116, ber_len = 78, ber_usertag = 0, ber_buf = 0x6070000b03d0 "cP", ber_ptr = 0x6070000b03d0 "cP", ber_end = 0x6070000b041e "", ber_sos_ptr = 0x0, ber_rwptr = 0x0, ber_memctx = 0x0} (gdb) p ber->ber_buf $8 = 0x6070000b03d0 "cP" (gdb) up #5 0x00007fffee310c91 in try_read1msg (result=0x7fffd6ff6348, lc=0x6080001182a0, all=1, msgid=18, ld=0x6040000aa610) at result.c:494 494 tag = ber_get_next( lc->lconn_sb, &len, ber ); (gdb) p len $10 = 99 (gdb) p lc $11 = (LDAPConn *) 0x6080001182a0 ``` -- You are receiving this mail because: You are on the CC list for the issue.

1 15

[Issue 9802] New: Segfault while changing configuration in OpenLDAP 2.6.1
by openldap-its＠openldap.org 04 May '22

04 May '22

https://bugs.openldap.org/show_bug.cgi?id=9802 Issue ID: 9802 Summary: Segfault while changing configuration in OpenLDAP 2.6.1 Product: OpenLDAP Version: 2.6.1 Hardware: All OS: All Status: UNCONFIRMED Keywords: needs_review Severity: normal Priority: --- Component: slapd Assignee: bugs(a)openldap.org Reporter: manuel.flury(a)gmail.com Target Milestone: --- Created attachment 878 --> https://bugs.openldap.org/attachment.cgi?id=878&action=edit GDB traces and olcConfig Dear all, I am trying to configure back_meta for testing virtual directory. Attached is my config. It may not make sense. Trying to change configuration under olcMetaSub={0}uri,olcDatabase={1}meta,cn=config From : {5}rewriteRule "^(.+uid=[^,]+)(a)domain.two.com(,.*)$" "${&&target(\"ou=people,dc=domain,dc=two,dc=com\")}$1$2" ":" To: {5}rewriteRule "^(.+uid=[^,]+)(a)domain.two.com(,.*)$" "${&&target(\"ou=mynetworkpeople,o=my.example.com\")}$1$2" ":" I get a segfault. Please find attached the gdb traces. Before segfault, slapd is able to log the following messages: Feb 25 19:08:38 mydevldapsrvmd21.datacenter.my.example.com slapd[1066842]: daemon: activity on 1 descriptor Feb 25 19:08:38 mydevldapsrvmd21.datacenter.my.example.com slapd[1066842]: daemon: activity on:Feb 25 19:08:38 mydevldapsrvmd21.datacenter.my.example.com slapd[1066842]: 10rFeb 25 19:08:38 mydevldapsrvmd21.datacenter.my.example.com slapd[1066842]: Feb 25 19:08:38 mydevldapsrvmd21.datacenter.my.example.com slapd[1066842]: daemon: read active on 10 Feb 25 19:08:38 mydevldapsrvmd21.datacenter.my.example.com slapd[1066842]: daemon: epoll: listen=7 active_threads=0 tvp=NULL Feb 25 19:08:38 mydevldapsrvmd21.datacenter.my.example.com slapd[1066842]: daemon: epoll: listen=8 active_threads=0 tvp=NULL Feb 25 19:08:38 mydevldapsrvmd21.datacenter.my.example.com slapd[1066842]: connection_get(10): got connid=1000 Feb 25 19:08:38 mydevldapsrvmd21.datacenter.my.example.com slapd[1066842]: connection_read(10): checking for input on id=1000 Feb 25 19:08:38 mydevldapsrvmd21.datacenter.my.example.com slapd[1066842]: op tag 0x66, time 1645812518 Feb 25 19:08:38 mydevldapsrvmd21.datacenter.my.example.com slapd[1066842]: conn=1000 op=14 do_modify Feb 25 19:08:38 mydevldapsrvmd21.datacenter.my.example.com slapd[1066842]: daemon: activity on 1 descriptor Feb 25 19:08:38 mydevldapsrvmd21.datacenter.my.example.com slapd[1066842]: >>> dnPrettyNormal: <olcMetaSub={0}uri,olcDatabase={1}meta,cn=config> Feb 25 19:08:38 mydevldapsrvmd21.datacenter.my.example.com slapd[1066842]: daemon: activity on:Feb 25 19:08:38 mydevldapsrvmd21.datacenter.my.example.com slapd[1066842]: Feb 25 19:08:38 mydevldapsrvmd21.datacenter.my.example.com slapd[1066842]: daemon: epoll: listen=7 active_threads=0 tvp=NULL Feb 25 19:08:38 mydevldapsrvmd21.datacenter.my.example.com slapd[1066842]: daemon: epoll: listen=8 active_threads=0 tvp=NULL Feb 25 19:08:38 mydevldapsrvmd21.datacenter.my.example.com slapd[1066842]: <<< dnPrettyNormal: <olcMetaSub={0}uri,olcDatabase={1}meta,cn=config>, <olcMetaSub={0}uri,olcDatabase={1}meta,cn=config> Feb 25 19:08:38 mydevldapsrvmd21.datacenter.my.example.com slapd[1066842]: conn=1000 op=14 MOD dn="olcMetaSub={0}uri,olcDatabase={1}meta,cn=config" Feb 25 19:08:38 mydevldapsrvmd21.datacenter.my.example.com slapd[1066842]: conn=1000 op=14 MOD attr=olcDbRewrite olcDbRewrite Feb 25 19:08:38 mydevldapsrvmd21.datacenter.my.example.com slapd[1066842]: slap_get_csn: conn=1000 op=14 generated new csn=20220225180838.334352Z#000000#001#000000 manage=1 Feb 25 19:08:38 mydevldapsrvmd21.datacenter.my.example.com slapd[1066842]: slap_queue_csn: queueing 0x7f030c140330 20220225180838.334352Z#000000#001#000000 Feb 25 19:08:38 mydevldapsrvmd21.datacenter.my.example.com slapd[1066842]: oc_check_required entry (olcMetaSub={0}uri,olcDatabase={1}meta,cn=config), objectClass "olcMetaTargetConfig" Feb 25 19:08:38 mydevldapsrvmd21.datacenter.my.example.com slapd[1066842]: oc_check_allowed type "objectClass" Feb 25 19:08:38 mydevldapsrvmd21.datacenter.my.example.com slapd[1066842]: oc_check_allowed type "olcMetaSub" Feb 25 19:08:38 mydevldapsrvmd21.datacenter.my.example.com slapd[1066842]: oc_check_allowed type "olcDbURI" Feb 25 19:08:38 mydevldapsrvmd21.datacenter.my.example.com slapd[1066842]: oc_check_allowed type "olcDbIDAssertBind" Feb 25 19:08:38 mydevldapsrvmd21.datacenter.my.example.com slapd[1066842]: oc_check_allowed type "olcDbRewrite" Feb 25 19:08:38 mydevldapsrvmd21.datacenter.my.example.com slapd[1066842]: oc_check_allowed type "olcDbKeepalive" Feb 25 19:08:38 mydevldapsrvmd21.datacenter.my.example.com slapd[1066842]: oc_check_allowed type "olcDbBindTimeout" Feb 25 19:08:38 mydevldapsrvmd21.datacenter.my.example.com slapd[1066842]: oc_check_allowed type "olcDbCancel" Feb 25 19:08:38 mydevldapsrvmd21.datacenter.my.example.com slapd[1066842]: oc_check_allowed type "olcDbChaseReferrals" Feb 25 19:08:38 mydevldapsrvmd21.datacenter.my.example.com slapd[1066842]: oc_check_allowed type "olcDbNoRefs" Feb 25 19:08:38 mydevldapsrvmd21.datacenter.my.example.com slapd[1066842]: oc_check_allowed type "olcDbNoUndefFilter" Feb 25 19:08:38 mydevldapsrvmd21.datacenter.my.example.com slapd[1066842]: oc_check_allowed type "olcDbNretries" Feb 25 19:08:38 mydevldapsrvmd21.datacenter.my.example.com slapd[1066842]: oc_check_allowed type "olcDbProtocolVersion" Feb 25 19:08:38 mydevldapsrvmd21.datacenter.my.example.com slapd[1066842]: oc_check_allowed type "olcDbRebindAsUser" Feb 25 19:08:38 mydevldapsrvmd21.datacenter.my.example.com slapd[1066842]: oc_check_allowed type "olcDbSessionTrackingRequest" Feb 25 19:08:38 mydevldapsrvmd21.datacenter.my.example.com slapd[1066842]: oc_check_allowed type "olcDbTFSupport" Feb 25 19:08:38 mydevldapsrvmd21.datacenter.my.example.com slapd[1066842]: oc_check_allowed type "structuralObjectClass" Feb 25 19:08:38 mydevldapsrvmd21.datacenter.my.example.com slapd[1066842]: oc_check_allowed type "entryUUID" Feb 25 19:08:38 mydevldapsrvmd21.datacenter.my.example.com slapd[1066842]: oc_check_allowed type "creatorsName" Feb 25 19:08:38 mydevldapsrvmd21.datacenter.my.example.com slapd[1066842]: oc_check_allowed type "createTimestamp" Feb 25 19:08:38 mydevldapsrvmd21.datacenter.my.example.com slapd[1066842]: oc_check_allowed type "entryCSN" Feb 25 19:08:38 mydevldapsrvmd21.datacenter.my.example.com slapd[1066842]: oc_check_allowed type "modifiersName" Feb 25 19:08:38 mydevldapsrvmd21.datacenter.my.example.com slapd[1066842]: oc_check_allowed type "modifyTimestamp" Feb 25 19:08:38 mydevldapsrvmd21.datacenter.my.example.com slapd[1066842]: >>> dnPrettyNormal: <dc=my,dc=example,dc=com> Feb 25 19:08:38 mydevldapsrvmd21.datacenter.my.example.com slapd[1066842]: <<< dnPrettyNormal: <dc=my,dc=example,dc=com>, <dc=my,dc=example,dc=com> Best Regards -- You are receiving this mail because: You are on the CC list for the issue.

1 19

[Issue 9818] New: slapo-translucent overlay crashes during wildcard search with subordinate
by openldap-its＠openldap.org 04 May '22

04 May '22

https://bugs.openldap.org/show_bug.cgi?id=9818 Issue ID: 9818 Summary: slapo-translucent overlay crashes during wildcard search with subordinate Product: OpenLDAP Version: 2.5.11 Hardware: All OS: All Status: UNCONFIRMED Keywords: needs_review Severity: normal Priority: --- Component: overlays Assignee: bugs(a)openldap.org Reporter: jeremy.diaz(a)rexconsulting.net Target Milestone: --- I found that slapd 2.5.11 w/slapo-translucent will crash when queried with a wildcard search. It looks like any wildcard search on any attribute specified in "translucent_local" will cause the SIGSEGV on the latest version of Symas OpenLDAP slapd, 2.5.11, MDB databases, running on CentOS7. It seems that the SIGSEGV problem does not occur w the 2.4.44 from the RHEL7 distribution, and so the problem may have be a regression. I have not tested any other versions but have verified that, with the exact same config, the problem does not happen on the RHEL7 2.4.44 version, but does happen w/Symas OpenLDAP 2.5.11. It's an interesting config here. There are two database+suffixes defined in the instance. The first one is subordinate (ou=someorg,dc=corp,dc=com) to the second one (dc=corp,dc=com). The "subordinate" option is set to "True". The second database section loads the translucent overlay which is pointed to the upstream Active Directory instance and has the same suffix of AD. The problem is administrative. The group want their admins who manage LDAP data to be able to search using wildcard "cn=xyx*" filters. Besides crashing, we have noticed that these work, but only when setting the basedn of the subordinate database. I tried a few things in a test lab and was able to reproduce the issue. with "cn" in "translucent_local" and sublevel search of translucent superior basedn dc=corp,dc=com "(cn=jed)" filter returns subordinate database entry "(cn=je*)" filter crashes slapd with "cn" not in "translucent_local" and sublevel search of translucent superior basedn dc=corp,dc=com "(cn=jed)" filter return referrals from upstream Active Directory "(cn=je*)" filter return referrals from upstream Active Directory with "cn" in "translucent_local" and sublevel search of subordinate basedn ou=someorg,dc=corp,dc=com "(cn=jed)" filter returns subordinate database entry from ou=someorg "(cn=je*)" filter returns subordinate database entry(ies) from ou=someorg with "cn" not in "translucent_local" and sublevel search of subordinate dbasedn ou=someorg,dc=corp,dc=com "(cn=jed)" filter returns subordinate database entry from ou=someorg "(cn=je*)" filter returns subordinate database entry(ies) from ou=someorg Here's what the crash looks like: 622eb2f7.0393c4d6 0x7fcf15e89880 slapd starting 622eb2fd.32371976 0x7fce8d9f3700 slap_listener_activate(8): 622eb2fd.323bb364 0x7fce8d1f2700 >>> slap_listener(ldap:///) 622eb2fd.3247761c 0x7fce8d1f2700 connection_get(15): got connid=1000 622eb2fd.3247962c 0x7fce8d1f2700 connection_read(15): checking for input on id=1000 622eb2fd.3247b177 0x7fce8d1f2700 ber_get_next 622eb2fd.3247e0b8 0x7fce8d1f2700 ber_get_next: tag 0x30 len 12 contents: 622eb2fd.3247f6f1 0x7fce8d1f2700 op tag 0x60, time 1647227645 622eb2fd.32480615 0x7fce8d1f2700 ber_get_next 622eb2fd.32484eca 0x7fce8d1f2700 conn=1000 op=0 do_bind 622eb2fd.324861e8 0x7fce8d1f2700 ber_scanf fmt ({imt) ber: 622eb2fd.324871c1 0x7fce8d1f2700 ber_scanf fmt (m}) ber: 622eb2fd.32488890 0x7fce8d1f2700 >>> dnPrettyNormal: <> 622eb2fd.32489324 0x7fce8d1f2700 <<< dnPrettyNormal: <>, <> 622eb2fd.3248ce51 0x7fce8d1f2700 do_bind: version=3 dn="" method=128 622eb2fd.3248efc7 0x7fce8d1f2700 send_ldap_result: conn=1000 op=0 p=3 622eb2fd.324906be 0x7fce8d1f2700 send_ldap_response: msgid=1 tag=97 err=0 622eb2fd.32492605 0x7fce8d1f2700 ber_flush2: 14 bytes to sd 15 622eb2fd.324ab763 0x7fce8d1f2700 do_bind: v3 anonymous bind 622eb2fd.325dc3b4 0x7fce8d1f2700 connection_get(15): got connid=1000 622eb2fd.325de12a 0x7fce8d1f2700 connection_read(15): checking for input on id=1000 622eb2fd.325dec44 0x7fce8d1f2700 ber_get_next 622eb2fd.325e0856 0x7fce8d1f2700 ber_get_next: tag 0x30 len 63 contents: 622eb2fd.325e1663 0x7fce8d1f2700 op tag 0x63, time 1647227645 622eb2fd.325e22e8 0x7fce8d1f2700 ber_get_next 622eb2fd.325e500c 0x7fce8d1f2700 conn=1000 op=1 do_search 622eb2fd.325e5ae0 0x7fce8d1f2700 ber_scanf fmt ({miiiib) ber: 622eb2fd.325e69ea 0x7fce8d1f2700 >>> dnPrettyNormal: <dc=corp,dc=com> 622eb2fd.325e98bd 0x7fce8d1f2700 <<< dnPrettyNormal: <dc=corp,dc=com>, <dc=corp,dc=com> 622eb2fd.325eaad7 0x7fce8d1f2700 ber_scanf fmt ({m) ber: 622eb2fd.325ebce5 0x7fce8d1f2700 ber_scanf fmt (m) ber: 622eb2fd.325eddcb 0x7fce8d1f2700 ber_scanf fmt ({M}}) ber: 622eb2fd.325f334c 0x7fce8d1f2700 ==> limits_get: conn=1000 op=1 self="[anonymous]" this="dc=corp,dc=com" 622eb2fd.325f4dcc 0x7fce8d1f2700 ==> translucent_search: <dc=corp,dc=com> (cn=jed*) Segmentation fault Thanks! -- You are receiving this mail because: You are on the CC list for the issue.

1 8

[Issue 9785] New: test050 deadlock
by openldap-its＠openldap.org 04 May '22

04 May '22

https://bugs.openldap.org/show_bug.cgi?id=9785 Issue ID: 9785 Summary: test050 deadlock Product: OpenLDAP Version: 2.5.11 Hardware: All OS: All Status: UNCONFIRMED Keywords: needs_review Severity: normal Priority: --- Component: slapd Assignee: bugs(a)openldap.org Reporter: quanah(a)openldap.org Target Milestone: --- Running test050 in a loop sometimes results in a deadlock. Took 17 iterations on one system, was 100% on another. -- You are receiving this mail because: You are on the CC list for the issue.

1 7

[Issue 9789] New: syncprov uses a thread-local counters for the detached op
by openldap-its＠openldap.org 04 May '22

04 May '22

https://bugs.openldap.org/show_bug.cgi?id=9789 Issue ID: 9789 Summary: syncprov uses a thread-local counters for the detached op Product: OpenLDAP Version: unspecified Hardware: All OS: All Status: UNCONFIRMED Keywords: needs_review Severity: normal Priority: --- Component: slapd Assignee: bugs(a)openldap.org Reporter: ondra(a)mistotebe.net Target Milestone: --- Persistent searches routinely migrate across threads, however they keep using op->o_counters from the original search op which is meant to be thread-local. During shutdown, this counter can be destroyed as the original thread finishes, but the persistent search might still be live somewhere else. At that point, trying to acquire the destroyed sc_mutex fails and the thread usually stalls forever. slapd-asyncmeta is very likely to suffer from the same issues. A representative backtrace of this happening: Thread 3 (Thread 0x7f0b7d933640 (LWP 2928392) "slapd"): #0 futex_wait (private=0, expected=2, futex_word=0x7f0b74000ff8) at ../sysdeps/nptl/futex-internal.h:146 #3 0x00007f0b7fd17a05 in ldap_pvt_thread_mutex_lock (mutex=Locked by LWP 0) at thr_posix.c:313 #4 0x0000000000469564 in slap_send_search_entry (op=Search request conn=1003 op=1 = {...}, rs=Search entry = {...}) at result.c:1503 #5 0x00007f0b7f30561c in syncprov_sendresp (op=Search request conn=1003 op=1 = {...}, ri=0x7f0b701eb8e0, so=0x7f0b74102b20, mode=1) at syncprov.c:976 #6 0x00007f0b7f305064 in syncprov_qplay (op=Search request conn=1003 op=1 = {...}, so=0x7f0b74102b20) at syncprov.c:1028 #7 0x00007f0b7f304ecc in syncprov_qtask (ctx=0x7f0b7d932a58, arg=0x7f0b74102b20) at syncprov.c:1086 -- You are receiving this mail because: You are on the CC list for the issue.

1 4

[Issue 9804] New: slapd.conf(5) - remove comment from syncrepl about sizelimit
by openldap-its＠openldap.org 04 May '22

04 May '22

https://bugs.openldap.org/show_bug.cgi?id=9804 Issue ID: 9804 Summary: slapd.conf(5) - remove comment from syncrepl about sizelimit Product: OpenLDAP Version: unspecified Hardware: All OS: All Status: UNCONFIRMED Keywords: needs_review Severity: normal Priority: --- Component: documentation Assignee: bugs(a)openldap.org Reporter: michael(a)stroeder.com Target Milestone: --- slapd.conf(5) and slapd-config(5) contain the following really mis-leading text: "The sizelimit and timelimit parameters define a consumer requested limitation on the number of entries that can be returned by the LDAP Content Synchronization operation; as such, it is intended to implement partial replication based on the size of the replicated database and on the time required by the synchronization." This is wrong. One cannot implement deterministic partial replication with these limits. => This text should be removed. -- You are receiving this mail because: You are on the CC list for the issue.

1 4

[Issue 9808] New: olcLastBind populated incorrectly when converting from slapd.conf
by openldap-its＠openldap.org 04 May '22

04 May '22

https://bugs.openldap.org/show_bug.cgi?id=9808 Issue ID: 9808 Summary: olcLastBind populated incorrectly when converting from slapd.conf Product: OpenLDAP Version: unspecified Hardware: All OS: All Status: UNCONFIRMED Keywords: needs_review Severity: normal Priority: --- Component: slapd Assignee: bugs(a)openldap.org Reporter: ondra(a)mistotebe.net Target Milestone: --- Fix coming shortly. -- You are receiving this mail because: You are on the CC list for the issue.

1 6

[Issue 9801] New: Segmentation Fault of Openldap 2.6.1 when the syncprov overlay tries to synchronize from ODSEE an attribute that it does not know.
by openldap-its＠openldap.org 04 May '22

04 May '22

https://bugs.openldap.org/show_bug.cgi?id=9801 Issue ID: 9801 Summary: Segmentation Fault of Openldap 2.6.1 when the syncprov overlay tries to synchronize from ODSEE an attribute that it does not know. Product: OpenLDAP Version: 2.6.1 Hardware: All OS: All Status: UNCONFIRMED Keywords: needs_review Severity: normal Priority: --- Component: overlays Assignee: bugs(a)openldap.org Reporter: laurent.revillion(a)icloud.com Target Milestone: --- Created attachment 877 --> https://bugs.openldap.org/attachment.cgi?id=877&action=edit The files from gdb Hello, I just tested Opendlap 2.6.1 synchronization from ODSEE. It seemed to me that everything was going very well but I had a "Segmention Fault" when I tested on ODSEE to add the nsAccountLock: TRUE attribute. This attribute does not exist in the Openldap schema. The Openldap server detects the thing well but ... segmentation fault.:(( 620f6bd2.1b555d23 0x7fd0c9aff700 ldap_get_attribute_ber 620f6bd2.1b556639 0x7fd0c9aff700 ber_scanf fmt ({mM}) ber: 620f6bd2.1b5576f3 0x7fd0c9aff700 ldap_get_attribute_ber 620f6bd2.1b55b147 0x7fd0c9aff700 syncrepl_changelog_mods: rid=002 Invalid attribute nsAccountLock, attribute type undefined ./start-consumer1.sh : ligne 3 : 12531 Erreur de segmentation /opt/symas/lib/slapd -d 1 -u ldap -g ldap -h "ldap://:5389/" -f /opt/symas/config/static-test/slapd-dsee-consumer1.conf Attached are the files generated via gdb. Thanks Laurent -- You are receiving this mail because: You are on the CC list for the issue.

1 5

[Issue 9584] New: cn=config replication ops/refresh should pause server
by openldap-its＠openldap.org 04 May '22

04 May '22

https://bugs.openldap.org/show_bug.cgi?id=9584 Issue ID: 9584 Summary: cn=config replication ops/refresh should pause server Product: OpenLDAP Version: unspecified Hardware: All OS: All Status: UNCONFIRMED Severity: normal Priority: --- Component: slapd Assignee: bugs(a)openldap.org Reporter: ondra(a)mistotebe.net Target Milestone: --- Looking into this crash: https://git.openldap.org/openldap/openldap/-/jobs/7286 The thread in question is running a plain syncrepl refresh while another thread seems to have done the same. This thread fetched the entryUUID attribute of the 'cn=config' entry as 'a' and in the meantime, that entry has been rewritten, with 'a' presumably cleaned up and returned to the pool, so addressing a->a_nvals[0] is a NULL-dereference now. This might or might not be related to the fix in ITS#8102. -- You are receiving this mail because: You are on the CC list for the issue.

1 18

[Issue 9791] New: Build failure with certain disabled features in openssl
by openldap-its＠openldap.org 04 May '22

04 May '22

https://bugs.openldap.org/show_bug.cgi?id=9791 Issue ID: 9791 Summary: Build failure with certain disabled features in openssl Product: OpenLDAP Version: 2.6.1 Hardware: All OS: All Status: UNCONFIRMED Keywords: needs_review Severity: normal Priority: --- Component: build Assignee: bugs(a)openldap.org Reporter: orgads(a)gmail.com Target Milestone: --- If openssl is configured with either OPENSSL_NO_MD4 or OPENSSL_NO_MD5 the build fails. -- You are receiving this mail because: You are on the CC list for the issue.

1 4

[Issue 9794] New: Define behaviour for pwdChangedTime modifications
by openldap-its＠openldap.org 04 May '22

04 May '22

https://bugs.openldap.org/show_bug.cgi?id=9794 Issue ID: 9794 Summary: Define behaviour for pwdChangedTime modifications Product: OpenLDAP Version: unspecified Hardware: All OS: All Status: UNCONFIRMED Keywords: needs_review Severity: normal Priority: --- Component: slapd Assignee: bugs(a)openldap.org Reporter: david.coutadeur(a)gmail.com Target Milestone: --- This issue applies to: - draft-behera-ldap-password-policy - openldap 2.5 - openldap 2.6 It is a proposition of behaviour for pwdChangedTime modifications. modification of the draft: -------------------------- In section: "8.2.7. Policy State Updates", change this paragraph: If the value of either pwdMaxAge or pwdMinAge is non-zero, the server updates the pwdChangedTime attribute on the entry to the current time. into: If the value of either pwdMaxAge or pwdMinAge is non-zero, the server MUST update the pwdChangedTime attribute on the entry according to this workflow: Then insert a new paragraph: - if the current operation (add or modify) on the password includes adding or modifying a valid pwdChangedTime attribute, then use this pwdChangedTime. A "Valid" pwdChangedTime means a syntactically correct value, compliant with the schema, approved by access rules, and MAY require a relax control according to the schema defined in section 5.3.2. See Relax control RFC for more information: https://datatracker.ietf.org/doc/html/draft-zeilenga-ldap-relax - an invalid pwdChangedTime value MUST result in an error, and the pwdChangedTime MUST NOT be stored - in any other case, compute the current date and store it in a GeneralizedTime format Feel free to comment or propose other ideas. modification of the code: -------------------------- If this behaviour makes a consensus, it would be useful to patch both OpenLDAP 2.5 and 2.6. NOTE: current OpenLDAP 2.5 allows modifying pwdChangedTime alone, but fails to add a user with both userPassword and pwdChangedTime (it results in a duplicated pwdChangedTime error) modification of the documentation: ---------------------------------- In slapo-ppolicy, it can be useful to add a comment in "OPERATIONAL ATTRIBUTES" section: Every attribute defined as "NO-USER-MODIFICATION" SHOULD not be written by standard users. If needed, an administrator MAY modify them with the relax control. See Relax control RFC for more information: https://datatracker.ietf.org/doc/html/draft-zeilenga-ldap-relax -- You are receiving this mail because: You are on the CC list for the issue.

1 12

[Issue 9825] New: MemberOf group in group search not working
by openldap-its＠openldap.org 04 May '22

04 May '22

https://bugs.openldap.org/show_bug.cgi?id=9825 Issue ID: 9825 Summary: MemberOf group in group search not working Product: OpenLDAP Version: 2.6.1 Hardware: All OS: All Status: UNCONFIRMED Keywords: needs_review Severity: normal Priority: --- Component: overlays Assignee: bugs(a)openldap.org Reporter: erikdewaard(a)gmail.com Target Milestone: --- Created attachment 891 --> https://bugs.openldap.org/attachment.cgi?id=891&action=edit database ldif dynlist group in group search not working correctly. Multiple queries needed before returning correct answer. ldapsearch -H ldap:/// -LLL -x -b 'dc=example,dc=com' '(&(uid=user1)(memberOf=cn=groupingroup,ou=groups,dc=example,dc=com))' uid ldapsearch -H ldap:/// -LLL -x -b 'dc=example,dc=com' '(&(uid=user1)(memberOf=cn=groupingroup,ou=groups,dc=example,dc=com))' uid ldapsearch -H ldap:/// -LLL -x -b 'dc=example,dc=com' '(&(uid=user1)(memberOf=cn=groupingroup,ou=groups,dc=example,dc=com))' uid dn: uid=user1,ou=People,dc=example,dc=com uid: user1 -conf # stand-alone slapd config include /etc/openldap/schema/core.schema include /etc/openldap/schema/cosine.schema include /etc/openldap/schema/inetorgperson.schema include /etc/openldap/schema/rfc2307bis.schema include /etc/openldap/schema/dyngroup.schema # allow big PDUs from anonymous (for testing purposes) sockbuf_max_incoming 4194303 moduleload back_ldap moduleload dynlist ####################################################################### # database definitions ####################################################################### database config database mdb suffix "dc=example,dc=com" rootdn "cn=Manager,dc=example,dc=com" rootpw secret directory /var/lib/ldap lastbind off overlay dynlist dynlist-attrset groupOfURLs memberURL uniqueMember+memberOf@groupOfUniqueNames* database monitor -- You are receiving this mail because: You are on the CC list for the issue.

1 6

[Issue 9820] New: v2.5 and 2.6 closed (idletimeout) during ldapsearch (work fine with v2.4)
by openldap-its＠openldap.org 04 May '22

04 May '22

https://bugs.openldap.org/show_bug.cgi?id=9820 Issue ID: 9820 Summary: v2.5 and 2.6 closed (idletimeout) during ldapsearch (work fine with v2.4) Product: OpenLDAP Version: 2.6.1 Hardware: x86_64 OS: Linux Status: UNCONFIRMED Keywords: needs_review Severity: normal Priority: --- Component: slapd Assignee: bugs(a)openldap.org Reporter: jlbs.gregoire(a)gmail.com Target Milestone: --- Hello, Please excuse me for my bad English. Is there a bug with openldap 2.5 and 2.6 ? When I launch a ldapsearch on the whole directory, the connection is abruptly cut during the search (same problem with syncrepl). All work fine with openldap 2.4.48 and 2.4.59. Tested on Debian 10 buster and openssl 1.1.1n (also tested with openssl 1.1.1d and 1.1.1k). The directory contains over one million entries. OpenLDAP 2.6.1 compiled with the following options ./configure --prefix=/opt/openldap-2.6.1 --disable-ipv6 --enable-debug --enable-syslog --enable-slapd --enable-cleartext --enable-crypt --enable-wrappers --enable-backends=no --enable-mdb --enable-overlays --with-tls /opt/openldap-2.6.1/bin/ldapsearch -x -D cn=manager,dc=societe,dc=com -w 'password' ... # numResponses: 50146 # numEntries: 50146 ldap_result: Can't contact LDAP server (-1) Apr 8 21:28:37 debian slapd[20880]: @(#) $OpenLDAP: slapd 2.6.1 (Apr 8 2022 20:34:26) $#012#011root@debian:/opt/src/openldap-2.6.1/servers/slapd Apr 8 21:28:37 debian slapd[20881]: slapd starting Apr 8 21:29:12 debian slapd[20881]: conn=1000 fd=11 ACCEPT from PATH=/opt/openldap-2.6.1/var/run/ldapi (PATH=/opt/openldap-2.6.1/var/run/ldapi) Apr 8 21:29:12 debian slapd[20881]: conn=1000 op=0 BIND dn="cn=manager,dc=societe,dc=com" method=128 Apr 8 21:29:12 debian slapd[20881]: conn=1000 op=0 BIND dn="cn=manager,dc=societe,dc=com" mech=SIMPLE bind_ssf=0 ssf=71 Apr 8 21:29:12 debian slapd[20881]: conn=1000 op=0 RESULT tag=97 err=0 qtime=0.000005 etime=0.000041 text= Apr 8 21:29:12 debian slapd[20881]: conn=1000 op=1 SRCH base="dc=societe,dc=com" scope=2 deref=0 filter="(objectClass=*)" Apr 8 21:29:57 debian slapd[20881]: conn=1000 fd=11 closed (idletimeout) OpenLDAP 2.5.11 compiled with the following options ./configure --prefix=/opt/openldap-2.5.11 --disable-ipv6 --enable-debug --enable-syslog --enable-slapd --enable-cleartext --enable-crypt --enable-wrappers --enable-backends=no --enable-mdb --enable-overlays --with-tls /opt/openldap-2.5.11/bin/ldapsearch -x -D cn=manager,dc=societe,dc=com -w 'password' ... # numResponses: 44638 # numEntries: 44638 ldap_result: Can't contact LDAP server (-1) Apr 8 21:44:18 debian slapd[21063]: @(#) $OpenLDAP: slapd 2.5.11 (Apr 8 2022 20:55:50) $#012#011root@debian:/opt/src/openldap-2.5.11/servers/slapd Apr 8 21:44:18 debian slapd[21064]: slapd starting Apr 8 21:44:45 debian slapd[21064]: conn=1000 fd=11 ACCEPT from PATH=/opt/openldap-2.5.11/var/run/ldapi (PATH=/opt/openldap-2.5.11/var/run/ldapi) Apr 8 21:44:45 debian slapd[21064]: conn=1000 op=0 BIND dn="cn=manager,dc=societe,dc=com" method=128 Apr 8 21:44:45 debian slapd[21064]: conn=1000 op=0 BIND dn="cn=manager,dc=societe,dc=com" mech=SIMPLE bind_ssf=0 ssf=71 Apr 8 21:44:45 debian slapd[21064]: conn=1000 op=0 RESULT tag=97 err=0 qtime=0.000006 etime=0.000045 text= Apr 8 21:44:45 debian slapd[21064]: conn=1000 op=1 SRCH base="dc=societe,dc=com" scope=2 deref=0 filter="(objectClass=*)" Apr 8 21:45:30 debian slapd[21064]: conn=1000 fd=11 closed (idletimeout) OpenLDAP 2.4.59 compiled with the following options ./configure --prefix=/opt/openldap-2.4.59 --disable-ipv6 --enable-debug --enable-syslog --enable-slapd --enable-cleartext --enable-crypt --enable-wrappers --enable-backends=no --enable-mdb --enable-overlays --with-tls /opt/openldap-2.4.59/bin/ldapsearch -x -D cn=manager,dc=societe,dc=com -w 'password' Apr 8 21:53:22 debian slapd[17963]: @(#) $OpenLDAP: slapd 2.4.59 (Apr 8 2022 21:51:41) $#012#011root@debian:/opt/src/openldap-2.4.59/servers/slapd Apr 8 21:53:22 debian slapd[17964]: slapd starting Apr 8 21:53:54 debian slapd[17964]: conn=1000 fd=11 ACCEPT from PATH=/opt/openldap-2.4.59/var/run/ldapi (PATH=/opt/openldap-2.4.59/var/run/ldapi) Apr 8 21:53:54 debian slapd[17964]: conn=1000 op=0 BIND dn="cn=manager,dc=societe,dc=com" method=128 Apr 8 21:53:54 debian slapd[17964]: conn=1000 op=0 BIND dn="cn=manager,dc=societe,dc=com" mech=SIMPLE ssf=0 Apr 8 21:53:54 debian slapd[17964]: conn=1000 op=0 RESULT tag=97 err=0 text= Apr 8 21:53:54 debian slapd[17964]: conn=1000 op=1 SRCH base="dc=societe,dc=com" scope=2 deref=0 filter="(objectClass=*)" Apr 8 22:06:02 debian slapd[17964]: conn=1000 op=1 SEARCH RESULT tag=101 err=0 nentries=1021397 text= Apr 8 22:06:02 debian slapd[17964]: conn=1000 op=2 UNBIND Apr 8 22:06:02 debian slapd[17964]: conn=1000 fd=11 closed OpenLDAP 2.4.48 compiled with the following options ./configure --prefix=/opt/openldap-2.4.48 --disable-ipv6 --enable-debug --enable-syslog --enable-slapd --enable-cleartext --enable-crypt --enable-wrappers --enable-backends=no --enable-mdb --enable-overlays --with-tls /opt/openldap-2.4.48/bin/ldapsearch -x -D cn=manager,dc=societe,dc=com -w 'password' Apr 8 21:30:44 debian slapd[20942]: @(#) $OpenLDAP: slapd 2.4.48 (Apr 8 2022 20:58:01) $#012#011root@debian:/opt/src/openldap-2.4.48/servers/slapd Apr 8 21:30:44 debian slapd[20943]: slapd starting Apr 8 21:31:05 debian slapd[20943]: conn=1000 fd=11 ACCEPT from PATH=/opt/openldap-2.4.48/var/run/ldapi (PATH=/opt/openldap-2.4.48/var/run/ldapi) Apr 8 21:31:05 debian slapd[20943]: conn=1000 op=0 BIND dn="cn=manager,dc=societe,dc=com" method=128 Apr 8 21:31:05 debian slapd[20943]: conn=1000 op=0 BIND dn="cn=manager,dc=societe,dc=com" mech=SIMPLE ssf=0 Apr 8 21:31:05 debian slapd[20943]: conn=1000 op=0 RESULT tag=97 err=0 text= Apr 8 21:31:05 debian slapd[20943]: conn=1000 op=1 SRCH base="dc=societe,dc=com" scope=2 deref=0 filter="(objectClass=*)" Apr 8 21:43:15 debian slapd[20943]: conn=1000 op=1 SEARCH RESULT tag=101 err=0 nentries=1021397 text= Apr 8 21:43:15 debian slapd[20943]: conn=1000 op=2 UNBIND Apr 8 21:43:15 debian slapd[20943]: conn=1000 fd=11 closed Content of slapd.conf : pidfile /opt/openldap/var/run/slapd.pid argsfile /opt/openldap/var/run/slapd.args tool-threads 2 require ldapv3 authc disallow bind_anon loglevel stats modulepath /opt/openldap/libexec/openldap moduleload back_mdb moduleload syncprov include /opt/openldap/etc/openldap/schema/core.schema include /opt/openldap/etc/openldap/schema/cosine.schema include /opt/openldap/etc/openldap/schema/inetorgperson.schema include /opt/openldap/etc/openldap/schema/dyngroup_cgi.schema include /opt/openldap/etc/openldap/schema/qmail_cgi.schema defaultsearchbase "dc=societe,dc=com" backend mdb database mdb directory "/ldap/base-ldap" suffix "dc=societe,dc=com" rootdn "cn=manager,dc=societe,dc=com" rootpw password maxsize 12884901888 mode 600 checkpoint 10240 2 dbnosync lastmod on include /opt/openldap/etc/openldap/acl.conf idletimeout 120 reverse-lookup off sizelimit 100 timelimit unlimited include /opt/openldap/etc/openldap/index.conf index_substr_if_minlen 2 index_substr_if_maxlen 4 index_substr_any_len 4 index_substr_any_step 2 When I set loglevel -1 it works correctly (but generates a very huge log file). It's very strange. If you need any further information, feel free to contact me. Jean-Loup Gregoire -- You are receiving this mail because: You are on the CC list for the issue.

1 12

[Issue 9815] Serious SQL injection vulnerability in back-sql
by openldap-its＠openldap.org 04 May '22

04 May '22

https://bugs.openldap.org/show_bug.cgi?id=9815 Quanah Gibson-Mount <quanah(a)openldap.org> changed: What |Removed |Added ---------------------------------------------------------------------------- Group|OpenLDAP-devs | Status|RESOLVED |VERIFIED -- You are receiving this mail because: You are on the CC list for the issue.

1 0

[Issue 9837] New: Don't throw exceptions when requesting empty integer fields
by openldap-its＠openldap.org 02 May '22

02 May '22

https://bugs.openldap.org/show_bug.cgi?id=9837 Issue ID: 9837 Summary: Don't throw exceptions when requesting empty integer fields Product: JLDAP Version: unspecified Hardware: All OS: All Status: UNCONFIRMED Keywords: needs_review Severity: normal Priority: --- Component: JDBC Assignee: bugs(a)openldap.org Reporter: fredrik(a)roubert.name Target Milestone: --- LibreOffice Base expects to be able to call LdapResultSet.getLong() on an empty Types.INTEGER field without any exception being thrown and the exception that Long.parseLong() throws when passed an empty string will terminate the query with an error message. While I don't know if the JDBC standard says anything about how this is supposed to be handled, it seems reasonable (and harmless) for JDBC-LDAP to accomodate the existing behaviour such a popular open source software package as LibreOffice Base. -- You are receiving this mail because: You are on the CC list for the issue.

1 3

[Issue 9836] New: Support for TLS is needed
by openldap-its＠openldap.org 02 May '22

02 May '22

https://bugs.openldap.org/show_bug.cgi?id=9836 Issue ID: 9836 Summary: Support for TLS is needed Product: JLDAP Version: unspecified Hardware: All OS: All Status: UNCONFIRMED Keywords: needs_review Severity: normal Priority: --- Component: JDBC Assignee: bugs(a)openldap.org Reporter: fredrik(a)roubert.name Target Milestone: --- Using TLS is becoming increasingly more common and the LDAP library has support for this since a long time already, the JDBC connection string just needs to support a new property to allow this to be configured. -- You are receiving this mail because: You are on the CC list for the issue.

1 3

[Issue 9835] New: LDAP aliases ought to always be dereferenced
by openldap-its＠openldap.org 02 May '22

02 May '22

https://bugs.openldap.org/show_bug.cgi?id=9835 Issue ID: 9835 Summary: LDAP aliases ought to always be dereferenced Product: JLDAP Version: unspecified Hardware: All OS: All Status: UNCONFIRMED Keywords: needs_review Severity: normal Priority: --- Component: JDBC Assignee: bugs(a)openldap.org Reporter: fredrik(a)roubert.name Target Milestone: --- No software connecting to an LDAP database through JDBC can be expected to know anything at all about LDAP, so no such software can be expected to be able to do anything useful with an LDAP alias entry. LDAP aliases must therefore always be dereferenced in the JDBC driver. -- You are receiving this mail because: You are on the CC list for the issue.

1 3

[Issue 3872] Issue with norwegian UTF-8 characters JDBC Bridge
by openldap-its＠openldap.org 02 May '22

02 May '22

https://bugs.openldap.org/show_bug.cgi?id=3872 Quanah Gibson-Mount <quanah(a)openldap.org> changed: What |Removed |Added ---------------------------------------------------------------------------- Status|RESOLVED |VERIFIED -- You are receiving this mail because: You are on the CC list for the issue.

1 0

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

openldap-bugs