November 2020 - openldap-bugs

[Issue 9390] New: syncrepl: Fix debug message for size limit exceeded

by openldap-its＠openldap.org

https://bugs.openldap.org/show_bug.cgi?id=9390 Issue ID: 9390 Summary: syncrepl: Fix debug message for size limit exceeded Product: OpenLDAP Version: unspecified Hardware: All OS: All Status: UNCONFIRMED Severity: normal Priority: --- Component: slapd Assignee: bugs(a)openldap.org Reporter: fumiyas(a)osstech.co.jp Target Milestone: --- Created attachment 778 --> https://bugs.openldap.org/attachment.cgi?id=778&action=edit Proposed patch for OPENLDAP_REL_ENG_2_4 branch In server/slapd/syncrepl.c:dn_callback(): } else if ( rs->sr_type == REP_RESULT ) { if ( rs->sr_err == LDAP_SIZELIMIT_EXCEEDED ) { Debug( LDAP_DEBUG_ANY, "dn_callback : consistency error - " "entryUUID is not unique\n", 0, 0, 0 ); } } Is this wrong debug message? -- You are receiving this mail because: You are on the CC list for the issue.

2 years, 4 months

1
3
0 / 0

[Issue 9389] New: Improve the way how libldap handles interruption signal while in tls_read

by openldap-its＠openldap.org

https://bugs.openldap.org/show_bug.cgi?id=9389 Issue ID: 9389 Summary: Improve the way how libldap handles interruption signal while in tls_read Product: OpenLDAP Version: unspecified Hardware: All OS: All Status: UNCONFIRMED Severity: normal Priority: --- Component: libraries Assignee: bugs(a)openldap.org Reporter: simon.pichugin(a)gmail.com Target Milestone: --- Description: When signal-interrupted (by any signal, i.e. SIGRTMIN+1) while in tls_read, libldap will stop the execution. It will be better to make libldap more robust because some applications may use the signals in their watchdogs (i.e. SSSD). The issue happens when client executes the function - libraries/libldap/tls2.c:1280:ldap_install_tls(LDAP *ld) (Tue Jun 2 15:01:06 2020) [sssd[be[LDAP]]] [sss_ldap_debug] (0x4000): libldap: TLS trace: SSL_connect:SSLv3 read server certificate A (Tue Jun 2 15:01:06 2020) [sssd[be[LDAP]]] [sss_ldap_debug] (0x4000): libldap: TLS trace: SSL_connect:SSLv3 read server certificate request A (Tue Jun 2 15:01:06 2020) [sssd[be[LDAP]]] [sss_ldap_debug] (0x4000): libldap: TLS trace: SSL_connect:SSLv3 read server done A (Tue Jun 2 15:01:06 2020) [sssd[be[LDAP]]] [sss_ldap_debug] (0x4000): libldap: TLS trace: SSL_connect:SSLv3 write client certificate A (Tue Jun 2 15:01:06 2020) [sssd[be[LDAP]]] [sss_ldap_debug] (0x4000): libldap: TLS trace: SSL_connect:SSLv3 write client key exchange A (Tue Jun 2 15:01:06 2020) [sssd[be[LDAP]]] [sss_ldap_debug] (0x4000): libldap: TLS trace: SSL_connect:SSLv3 write change cipher spec A (Tue Jun 2 15:01:06 2020) [sssd[be[LDAP]]] [sss_ldap_debug] (0x4000): libldap: TLS trace: SSL_connect:SSLv3 write finished A (Tue Jun 2 15:01:06 2020) [sssd[be[LDAP]]] [sss_ldap_debug] (0x4000): libldap: tls_write: want=610, written=610 (Tue Jun 2 15:01:06 2020) [sssd[be[LDAP]]] [sss_ldap_debug] (0x4000): libldap: 0000: 16 03 00 00 07 0b 00 00 03 00 00 00 16 03 03 02 ................ (Tue Jun 2 15:01:06 2020) [sssd[be[LDAP]]] [sss_ldap_debug] (0x4000): libldap: 0010: 06 10 00 02 02 02 00 83 00 20 ec bc 90 f5 f3 d3 ......??? ...... (Tue Jun 2 15:01:06 2020) [sssd[be[LDAP]]] [sss_ldap_debug] (0x4000): libldap: 0020: 87 72 d6 a2 1e 00 d0 5d a0 64 00 00 99 9f 0b db .r.......d.M.... .... (Tue Jun 2 15:01:06 2020) [sssd[be[LDAP]]] [sss_ldap_debug] (0x4000): libldap: 0230: 44 06 1c 96 00 28 ee a1 28 00 63 1f 00 49 00 34 D.......(.c..I.4 (Tue Jun 2 15:01:06 2020) [sssd[be[LDAP]]] [sss_ldap_debug] (0x4000): libldap: 0240: 50 63 79 78 00 11 65 de 00 5d e0 aa 00 c8 00 aa P.x.....]..[.Z. (Tue Jun 2 15:01:06 2020) [sssd[be[LDAP]]] [sss_ldap_debug] (0x4000): libldap: 0250: 88 83 3e 59 00 7b 80 6b 65 a2 c3 ee 12 20 00 2c ..>Y.{.ke.... ., (Tue Jun 2 15:01:06 2020) [sssd[be[LDAP]]] [sss_ldap_debug] (0x4000): libldap: 0260: 00 a1 .. (Tue Jun 2 15:01:06 2020) [sssd[be[LDAP]]] [sss_ldap_debug] (0x4000): libldap: TLS trace: SSL_connect:SSLv3 flush data (Tue Jun 2 15:01:06 2020) [sssd[be[LDAP]]] [sss_ldap_debug] (0x4000): libldap: tls_read: want=5 error=Interrupted system call (Tue Jun 2 15:01:06 2020) [sssd[be[LDAP]]] [sss_ldap_debug] (0x4000): libldap: TLS trace: SSL_connect:error in SSLv3 read finished A (Tue Jun 2 15:01:06 2020) [sssd[be[LDAP]]] [sss_ldap_debug] (0x4000): libldap: TLS trace: SSL_connect:error in SSLv3 read finished A (Tue Jun 2 15:01:06 2020) [sssd[be[LDAP]]] [sss_ldap_debug] (0x4000): libldap: TLS: can't connect: . (Tue Jun 2 15:01:06 2020) [sssd[be[LDAP]]] [sss_ldap_debug] (0x4000): libldap: ldap_free_connection 1 1 (Tue Jun 2 15:01:06 2020) [sssd[be[LDAP]]] [sss_ldap_debug] (0x4000): libldap: ldap_send_unbind (Tue Jun 2 15:01:06 2020) [sssd[be[LDAP]]] [sss_ldap_debug] (0x4000): libldap: ber_flush2: 7 bytes to sd 23 (Tue Jun 2 15:01:06 2020) [sssd[be[LDAP]]] [sss_ldap_debug] (0x4000): libldap: 0000: 00 05 00 01 00 42 00 .....B. (Tue Jun 2 15:01:06 2020) [sssd[be[LDAP]]] [sss_ldap_debug] (0x4000): libldap: ldap_write: want=7, written=7 (Tue Jun 2 15:01:06 2020) [sssd[be[LDAP]]] [sss_ldap_debug] (0x4000): libldap: 0000: 00 05 00 01 01 42 00 .....B. (Tue Jun 2 15:01:06 2020) [sssd[be[LDAP]]] [sss_ldap_debug] (0x4000): libldap: ldap_free_connection: actually freed The issue is hard to reproduce as it should be interrupted in a very precise moment. Proposal: Add a retry action somewhere inside of ldap_install_tls which will reinitiate the operation from the beginning (so it won't affect the security aspect but it will increase reliability). -- You are receiving this mail because: You are on the CC list for the issue.

2 years, 4 months

1
2
0 / 0

[Issue 9384] Assertion failure in OpenLDAP: slapd v2.X - schema_init.c:csnNormalize23:5405

by openldap-its＠openldap.org

https://bugs.openldap.org/show_bug.cgi?id=9384 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.

2 years, 4 months

1
0
0 / 0

[Issue 9383] Assertion failure in OpenLDAP: slapd v2.X - schema_init.c:certificateListValidate:419

by openldap-its＠openldap.org

https://bugs.openldap.org/show_bug.cgi?id=9383 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.

2 years, 4 months

1
0
0 / 0

[Issue 9379] New: slapd should reject invalid listener URLs

by openldap-its＠openldap.org

https://bugs.openldap.org/show_bug.cgi?id=9379 Issue ID: 9379 Summary: slapd should reject invalid listener URLs Product: OpenLDAP Version: 2.4.53 Hardware: All OS: All Status: UNCONFIRMED Severity: trivial Priority: --- Component: slapd Assignee: bugs(a)openldap.org Reporter: hyc(a)openldap.org Target Milestone: --- Most common instance of invalid listener URLs is specifying an ldapi URL without URLencoding the socket pathname. Then the slashes in the pathname are treated as URL field separators, which yields a pathname quite different from what was intended. -- You are receiving this mail because: You are on the CC list for the issue.

2 years, 4 months

1
4
0 / 0

[Issue 9387] New: Support C++ Linkage

by openldap-its＠openldap.org

https://bugs.openldap.org/show_bug.cgi?id=9387 Issue ID: 9387 Summary: Support C++ Linkage Product: LMDB Version: unspecified Hardware: All OS: All Status: UNCONFIRMED Severity: normal Priority: --- Component: liblmdb Assignee: bugs(a)openldap.org Reporter: kriszyp(a)gmail.com Target Milestone: --- Created attachment 777 --> https://bugs.openldap.org/attachment.cgi?id=777&action=edit Add directive for supporting C++ linking The chacha8.h and module.h header files won't link properly (at least for me) with a C++ compiler/linker. I think they just need the linkage directives. -- You are receiving this mail because: You are on the CC list for the issue.

2 years, 4 months

1
4
0 / 0

[Issue 9156] latest ppolicy draft support

by openldap-its＠openldap.org

https://bugs.openldap.org/show_bug.cgi?id=9156 Quanah Gibson-Mount <quanah(a)openldap.org> changed: What |Removed |Added ---------------------------------------------------------------------------- See Also| |https://bugs.openldap.org/s | |how_bug.cgi?id=9386 -- You are receiving this mail because: You are on the CC list for the issue.

2 years, 4 months

1
0
0 / 0

[Issue 8125] MMR throws away valid changes causing drift

by openldap-its＠openldap.org

https://bugs.openldap.org/show_bug.cgi?id=8125 --- Comment #19 from Ondřej Kuzník <ondra(a)mistotebe.net> --- (In reply to Ondřej Kuzník from comment #12) > This is my understanding of the above discussion: > - deltasync consumer has just switched to full refresh (but is ahead > from this provider in some ways) > - provider sends the present list > - consumer deletes extra entries, builds a new cookie > - problem is that the new cookie is built to reflect the union of both > the local and received cookies even though we may have undone some of > the changes which we then ignore > > If that's accurate, there are some approaches that could fix it: > > 1. Simple one is to remember the actual cookie we got from the server > and refuse to delete entries with entryCSN ahead of the provided CSN > set. Problem is that we get even further from being able to replicate > from a generic RFC4533 provider. This has actually been done in ITS#9282. > 2. Instead, when present phase is initiated, we might terminate all > other sessions, adopt the complete CSN set and restart them only once > the new CSN set has been fully established. > > Also, whenever we fall back from deltasync into plain syncrepl, we > should make sure that the accesslog entries we generate from this are > never used for further replication which might be thought to be a > separate issue. Maybe the ITS#8486 work might be useful for this if > we have a way of signalling to accesslog to reset minCSN accordingly > to the new CSN set. > > The former is simpler, but the latter feels like the only one that > actually addresses these problems in full. I have some code to do this, terminate only persist sessions when we detect getting into a present refresh. Need a way to reproduce this in current master since a lot of the issues would have been fixed in ITS#9282 and might only be diverging in relayed deltasync, possibly if we're refreshing from two other providers at the same time. -- You are receiving this mail because: You are on the CC list for the issue.

2 years, 4 months

1
0
0 / 0

[Issue 5808] jldap library connect timeout doesn't work

by openldap-its＠openldap.org

https://bugs.openldap.org/show_bug.cgi?id=5808 --- Comment #4 from klasen(a)gmx.net --- The same problem can be observed, if a non-default SocketFactory (e.g. for LDAPS connections) is used: See https://bugs.openldap.org/show_bug.cgi?id=5808 (SocketFactory does not support a connect timeout.) -- You are receiving this mail because: You are on the CC list for the issue.

2 years, 4 months

1
0
0 / 0

[Issue 9354] New: Tool for monitoring slapd status

by openldap-its＠openldap.org

https://bugs.openldap.org/show_bug.cgi?id=9354 Issue ID: 9354 Summary: Tool for monitoring slapd status Product: OpenLDAP Version: 2.4.53 Hardware: All OS: All Status: UNCONFIRMED Severity: enhancement Priority: --- Component: client tools Assignee: bugs(a)openldap.org Reporter: hyc(a)openldap.org Target Milestone: --- Something we've seen in various scripts many times - this tool continuously reports operation counts from cn=Monitor and tracks contextCSN from a specified baseDN, polling at the specified interval (default 10 seconds). It tracks when contextCSN changes start and stop, and for a set of multiprovider servers, reports the lag between consumers and providers. Sample output of a screen: 2020-09-21 06:25:36 ldap://tx01 Entries Bind Unbind Search Compare Modify ModDN Add Delete Abandon Extended Num 1601143 95 108 617710 0 0 0 600000 0 0 9 Num/s 0.00 0.00 0.00 0.40 0.00 0.00 0.00 0.00 0.00 0.00 0.00 contextCSN: 20200921004518.559704Z#000000#001#000000 idle contextCSN: 20200921004548.656746Z#000000#002#000000 actv@2020-09-21 00:58:57, idle@2020-09-21 01:12:24, sync'd, max delta 00:03:11 contextCSN: 20200921004446.224575Z#000000#003#000000 actv@2020-09-21 00:58:57, idle@2020-09-21 01:12:24, sync'd, max delta 00:02:54 contextCSN: 20200921004331.841460Z#000000#004#000000 actv@2020-09-21 00:58:57, idle@2020-09-21 01:12:24, sync'd, max delta 00:02:19 ldap://tx02 Entries Bind Unbind Search Compare Modify ModDN Add Delete Abandon Extended Num 1601143 105 120 2217678 0 0 0 400000 200000 0 3 Num/s 0.00 0.00 0.00 0.40 0.00 0.00 0.00 0.00 0.00 0.00 0.00 contextCSN: 20200921004518.559704Z#000000#001#000000 actv@2020-09-21 00:58:57, idle@2020-09-21 01:11:33, sync'd, max delta 00:03:09 contextCSN: 20200921004548.656746Z#000000#002#000000 idle contextCSN: 20200921004446.224575Z#000000#003#000000 actv@2020-09-21 00:58:57, idle@2020-09-21 01:11:33, sync'd, max delta 00:02:52 contextCSN: 20200921004331.841460Z#000000#004#000000 actv@2020-09-21 00:58:57, idle@2020-09-21 01:11:33, sync'd, max delta 00:02:17 ldap://uk03 Entries Bind Unbind Search Compare Modify ModDN Add Delete Abandon Extended Num 1601143 1407 107 675570 0 3677 0 601135 14 0 3 Num/s 0.00 0.00 0.00 0.40 0.00 0.00 0.00 0.00 0.00 0.00 0.00 contextCSN: 20200921004518.559704Z#000000#001#000000 actv@2020-09-21 00:58:57, idle@2020-09-21 01:05:56, sync'd, max delta 00:02:11 contextCSN: 20200921004548.656746Z#000000#002#000000 actv@2020-09-21 00:58:57, idle@2020-09-21 01:05:56, sync'd, max delta 00:02:14 contextCSN: 20200921004446.224575Z#000000#003#000000 idle contextCSN: 20200921004331.841460Z#000000#004#000000 actv@2020-09-21 00:58:57, idle@2020-09-21 01:05:56, sync'd, max delta 00:01:33 ldap://uk04 Entries Bind Unbind Search Compare Modify ModDN Add Delete Abandon Extended Num 1601143 98 116 2217670 0 0 0 400000 200000 0 3 Num/s 0.00 0.00 0.00 0.40 0.00 0.00 0.00 0.00 0.00 0.00 0.00 contextCSN: 20200921004518.559704Z#000000#001#000000 actv@2020-09-21 00:58:57, idle@2020-09-21 01:02:11, sync'd, max delta 00:01:13 contextCSN: 20200921004548.656746Z#000000#002#000000 actv@2020-09-21 00:58:57, idle@2020-09-21 01:02:11, sync'd, max delta 00:01:17 contextCSN: 20200921004446.224575Z#000000#003#000000 actv@2020-09-21 00:58:57, idle@2020-09-21 01:02:11, sync'd, max delta 00:01:01 contextCSN: 20200921004331.841460Z#000000#004#000000 idle -- You are receiving this mail because: You are on the CC list for the issue.

2 years, 4 months

1
4
0 / 0

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

openldap-bugs November 2020