- openldap-bugs - openldap.org

Re: (ITS#7673) rwm and bad ACL evaluation
by michael＠stroeder.com 15 Mar '14

15 Mar '14

This is a cryptographically signed message in MIME format. --------------ms000109040804090309020609 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Russell.Mosemann(a)cune.edu wrote: > simply referencing rwm >=20 > overlay rwm >=20 > returns no search results at all, if an attribute is specified for the > search. Specifying no attributes returns all of the allowed attributes.= > Commenting the line above permits the specified attribute to be returne= d, > as expected. Did you already try with this? rwm-drop-unrequested-attrs no Ciao, Michael. --------------ms000109040804090309020609 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIFfzCC BXswggNjoAMCAQICAwxOfTANBgkqhkiG9w0BAQUFADB5MRAwDgYDVQQKEwdSb290IENBMR4w HAYDVQQLExVodHRwOi8vd3d3LmNhY2VydC5vcmcxIjAgBgNVBAMTGUNBIENlcnQgU2lnbmlu ZyBBdXRob3JpdHkxITAfBgkqhkiG9w0BCQEWEnN1cHBvcnRAY2FjZXJ0Lm9yZzAeFw0xMjEw MDIyMDE3MDlaFw0xNDEwMDIyMDE3MDlaMD8xGDAWBgNVBAMUD01pY2hhZWwgU3Ry9mRlcjEj MCEGCSqGSIb3DQEJARYUbWljaGFlbEBzdHJvZWRlci5jb20wggEiMA0GCSqGSIb3DQEBAQUA A4IBDwAwggEKAoIBAQDo2SKth5GhtaDrCyfGtyUG+/hAAa/J52L0NFN4SSRvTtdGf9HfWwwd NCtgae0TVGWk2lKDbXA9d5vmyIiRhuwxd90H6FLErhRBeB9G67qtw87E8WUoXt2DwPQEUTWV hqHpPadlmgFw3+i3TGQQTe3O3W9MMMd4GJNhObem2VGRuCD37OXnzBksTcq0FPJgcWAhe3d/ 0ItOkNWBqgq8Mf3p7WFBhaQ0a27BC/mKtH8fI3kPcS305imPRja69Msq3EwUZBc9ToVp6FRQ NYKjfOBybDUzVkmRZl3H8xutQP2w8Zxb8m5f7Q1BfLLrIFScfYvIDgOERxTCd4lab8+/09XH AgMBAAGjggFEMIIBQDAMBgNVHRMBAf8EAjAAMFYGCWCGSAGG+EIBDQRJFkdUbyBnZXQgeW91 ciBvd24gY2VydGlmaWNhdGUgZm9yIEZSRUUgaGVhZCBvdmVyIHRvIGh0dHA6Ly93d3cuQ0Fj ZXJ0Lm9yZzAOBgNVHQ8BAf8EBAMCA6gwQAYDVR0lBDkwNwYIKwYBBQUHAwQGCCsGAQUFBwMC BgorBgEEAYI3CgMEBgorBgEEAYI3CgMDBglghkgBhvhCBAEwMgYIKwYBBQUHAQEEJjAkMCIG CCsGAQUFBzABhhZodHRwOi8vb2NzcC5jYWNlcnQub3JnMDEGA1UdHwQqMCgwJqAkoCKGIGh0 dHA6Ly9jcmwuY2FjZXJ0Lm9yZy9yZXZva2UuY3JsMB8GA1UdEQQYMBaBFG1pY2hhZWxAc3Ry b2VkZXIuY29tMA0GCSqGSIb3DQEBBQUAA4ICAQC9ouXq3p/bDWMM4tBKgD3tl4HY5H0eECl8 q9/nqk0UL6YeWkrCiQdrDtNPW7DcGqNYtzdgtzmyTr1GhiAX+igrOjdk/ge5NRcQOpONK/4b zrmpQEcIUyxSSDKLWh211/kcFfxxLEiJ5teF4GL8Fc1qbrLP4+DCvJXWfYaaR5NLjZMqm2VP yKTv3qpXWnGohiRkGTwS/11QM2XCfIGdRsQT9a8mO4m2fn2tGPp2TEIoCLrDDrbGVeDWaOWB OIeTrp4wa3Q4OI6yCptJhEqKvjhV96IBRYgM76nTBqsqnDzwxExAyhhWiUS5DunRHOr/+NyF pUpD4883RBLO0g9kUEGOhtZNF1u+8zEL0YgMGvifAom9JEklLOXZuqj0MThypKs/3d/OyOQb 4gURnu6oZwcKZ7LskytWnlRKUxF6o0A8grtmyKkqe14TS7cQbg0NTaIYXPkHR+dfFmb3uEqn BBjvpJXFcEtWI2lQXC/ET+au991pK797ExBOmpQwjIn3SjiW80vw/UoL6DMvqY/6JhVhyNTP MJ2W5AX5kc27DIbVtVGZs8J4AYhuNALJUq9N9Ka7rPRj3RcYDrfehDLOkM5iMnarpmtuOpLK d1SvZhqj/0N/JWGIDpPSTkTFOPP6ZN9I9Rqyf+9NGqb2sjo4DkIiZcHxt735/GJLwus5KLBl 2DGCA6EwggOdAgEBMIGAMHkxEDAOBgNVBAoTB1Jvb3QgQ0ExHjAcBgNVBAsTFWh0dHA6Ly93 d3cuY2FjZXJ0Lm9yZzEiMCAGA1UEAxMZQ0EgQ2VydCBTaWduaW5nIEF1dGhvcml0eTEhMB8G CSqGSIb3DQEJARYSc3VwcG9ydEBjYWNlcnQub3JnAgMMTn0wCQYFKw4DAhoFAKCCAfUwGAYJ KoZIhvcNAQkDMQsGCSqGSIb3DQEHATAcBgkqhkiG9w0BCQUxDxcNMTQwMzE1MDkxMjE4WjAj BgkqhkiG9w0BCQQxFgQUrABzEjElf3V/cUntQuLyr7sa6GcwbAYJKoZIhvcNAQkPMV8wXTAL BglghkgBZQMEASowCwYJYIZIAWUDBAECMAoGCCqGSIb3DQMHMA4GCCqGSIb3DQMCAgIAgDAN BggqhkiG9w0DAgIBQDAHBgUrDgMCBzANBggqhkiG9w0DAgIBKDCBkQYJKwYBBAGCNxAEMYGD MIGAMHkxEDAOBgNVBAoTB1Jvb3QgQ0ExHjAcBgNVBAsTFWh0dHA6Ly93d3cuY2FjZXJ0Lm9y ZzEiMCAGA1UEAxMZQ0EgQ2VydCBTaWduaW5nIEF1dGhvcml0eTEhMB8GCSqGSIb3DQEJARYS c3VwcG9ydEBjYWNlcnQub3JnAgMMTn0wgZMGCyqGSIb3DQEJEAILMYGDoIGAMHkxEDAOBgNV BAoTB1Jvb3QgQ0ExHjAcBgNVBAsTFWh0dHA6Ly93d3cuY2FjZXJ0Lm9yZzEiMCAGA1UEAxMZ Q0EgQ2VydCBTaWduaW5nIEF1dGhvcml0eTEhMB8GCSqGSIb3DQEJARYSc3VwcG9ydEBjYWNl cnQub3JnAgMMTn0wDQYJKoZIhvcNAQEBBQAEggEAv0di+TXxwjmc85Xw+S9qBwQag6dOQupE IkAwHTdBFaFAYayl0ohH4+WQk2G7lxxyy1Mr1dmva4ziV9Q0qhN7Oo7NMBMenK8WfcFJGlEs +DrZoe4ZXws9BwArgzny5zZzJBaWod0nFaJ30Jj5A0S0GyiKAiOt2rzuFNIoEqiy9aSa/rqF APQR7P3ocuY9yZsHi9Sr5vNQrQA9E1qk/iERvL2YTA0QAWSeNoD0YWY7qr5QoSQofwhmkGYf UuCgmgjEPtztIVXrmxfx6FAx+/rr2ynYfMGwy3oLd9AhIC937NYoMxsBVsc7Tf7damWDanjH rrcuNYm9zXayrPcANmjgHAAAAAAAAA== --------------ms000109040804090309020609--

1 0

RE: (ITS#7673) rwm and bad ACL evaluation
by Russell.Mosemann＠cune.edu 14 Mar '14

14 Mar '14

I'm still looking for a resolution to the issue of the rewrite module interfering with a search that does not use the rewrite module. The behavior has not changed in the intervening updates. We are running 2.4.39, and simply referencing rwm overlay rwm returns no search results at all, if an attribute is specified for the search. Specifying no attributes returns all of the allowed attributes. Commenting the line above permits the specified attribute to be returned, as expected. The rewrite module should have no interaction with the search whatsoever, since no rewrite has been specified. Instead, it appears that the rwm intercepts the returned results and somehow "loses" all of the attributes when the search specifies a specific attribute. When no attribute is specified in the search, rwm quietly stays out of the way and lets all of the returned attributes proceed to the frontend. -- Russell Mosemann, Ph.D. Professor of Computer Science

1 0

Re: (ITS#7817) Wrong if condition for string length
by flo＠geekplace.eu 11 Mar '14

11 Mar '14

I just got a report [1] that the patch is incomplete, because authzid is used to calculate A1 value of the response (RFC2831 2.1.2.1). Stay tuned for an updated version. 1: https://github.com/Flowdalic/asmack/commit/2b4d004fe5a7b4224380a32658ff2056…

1 0

(ITS#7819) jldap DigesetMD5SaslClient is using m_serverName for digest-uri, when it should be use m_digestURI instead
by flo＠geekplace.eu 11 Mar '14

11 Mar '14

Full_Name: Florian Schmaus Version: OS: URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (131.188.31.107) com.novell.sasl.client.DigestMD5SaslClient is using a hard-coded prefix "ldap/" concatenated with 'm_ServerName' as value for the 'digest-uri' attribute in the SASL response. The correct value for 'digest-uri' is 'm_digestURI'. This would make the code ldap agnostic and re-useable for other purposes (e.g. XMPP), while still being able to perform ldap auth. See the following patch: --- a/com/novell/sasl/client/DigestMD5SaslClient.java 2009-12-07 19:14:10.000000000 +0100 +++ b/com/novell/sasl/client/DigestMD5SaslClient.java 2009-12-07 19:19:07.000000000 +0100 @@ -673,8 +673,8 @@ digestResponse.append("00000001"); //nounce count digestResponse.append(",qop="); digestResponse.append(m_qopValue); - digestResponse.append(",digest-uri=\"ldap/"); - digestResponse.append(m_serverName); + digestResponse.append(",digest-uri=\""); + digestResponse.append(m_digestURI); digestResponse.append("\",response="); digestResponse.append(response); digestResponse.append(",charset=utf-8,nonce=\"");

1 0

Re: (ITS#7817) Wrong if condition for string length
by quanah＠zimbra.com 11 Mar '14

11 Mar '14

--On Tuesday, March 11, 2014 5:31 PM +0000 quanah(a)zimbra.com wrote: > --On Tuesday, March 11, 2014 2:03 PM +0000 fschmaus(a)gmail.com wrote: > >> --bcaec53969d8ce043204f45455b2 >> Content-Type: text/plain; charset=ISO-8859-1 >> >> Of course the if condition for string length should be '>0' not '>=0'. > > Can you expand upon your report? What source code, for example, you're > referring to? This is a bit vague. Never mind. ;) Your reply came through like a new ITS. :P --Quanah -- Quanah Gibson-Mount Architect - Server Zimbra, Inc. -------------------- Zimbra :: the leader in open source messaging and collaboration

1 0

Re: (ITS#7817) Wrong if condition for string length
by quanah＠zimbra.com 11 Mar '14

11 Mar '14

--On Tuesday, March 11, 2014 2:03 PM +0000 fschmaus(a)gmail.com wrote: > --bcaec53969d8ce043204f45455b2 > Content-Type: text/plain; charset=ISO-8859-1 > > Of course the if condition for string length should be '>0' not '>=0'. Can you expand upon your report? What source code, for example, you're referring to? This is a bit vague. --Quanah -- Quanah Gibson-Mount Architect - Server Zimbra, Inc. -------------------- Zimbra :: the leader in open source messaging and collaboration

1 0

(ITS#7817) Wrong if condition for string length
by fschmaus＠gmail.com 11 Mar '14

11 Mar '14

--bcaec53969d8ce043204f45455b2 Content-Type: text/plain; charset=ISO-8859-1 Of course the if condition for string length should be '>0' not '>=0'. --bcaec53969d8ce043204f45455b2 Content-Type: text/html; charset=ISO-8859-1 <div dir="ltr">Of course the if condition for string length should be '>0' not '>=0'.</div> --bcaec53969d8ce043204f45455b2--

1 0

(ITS#7818) err=52 - unsuccessful bind due to lack of unbind
by maciej.uhlig＠us.edu.pl 11 Mar '14

11 Mar '14

Full_Name: Maciej Uhlig Version: 2.4.39 OS: CentOS release 6.5 (Final) URL: http://usnet.us.edu.pl/files/openldap/err52.txt Submission from: (NULL) (155.158.97.72) There are two OpenDJ servers and one OpenLDAP server. OpenLDAP server acts as a proxy to OpenDJ servers. OpenLDAP server is used by Dovecot mailbox server (here LDAP client) for user authentication. /---OpenDJ1 Dovecot---OpenLDAP \---OpenDJ2 OpenLDAP server runs 2.4.39 software. The problem is observed during OpenLDAP and OpenDJ servers interaction. Users can't send their mail. Dovecot server logs "ldap_bind() failed: Server is unavailable". OpenLDAP server logs "err=52". Restart of OpenLDAP server is required to resume normal operation. Analysis of OpenDJ log shows: - conn=40822 (correct) takes not more than one second - conn=40823 (incorrect) takes more than eleven minutes (it persists until OpenLDAP server is stopped) Analysis of OpenLDAP log shows: - op=29970 (conn=40822 in OpenDJ server) ends with err=0 - op=29972 (conn=40823 in OpenDJ server) ends with err=0 - op=29976 (not seen in OpenDJ server) ends with err=52 - similarly op=29979 and all subsequent end with err=52 Looks like OpenLDAP server doesn't unbind (eleven minutes above) from OpenDJ server. Instead it tries to make next bind which is unsuccesful (err=52).

1 0

(ITS#7817) jldap DigesetMD5SaslClient is using authzid for username when it should use authcid
by flo＠geekplace.eu 10 Mar '14

10 Mar '14

Full_Name: Florian Schmaus Version: OS: URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (88.217.98.14) The openldap-jldap's com.novell.sasl.cient.DigestMD5SaslClient is using authorization id (authzid) as value for the username. But the relevant RFC2831 states in section 2.1.2 that there is an extra attribute 'authzid' when assembling the response. The value of username should use m_name (the authcid) and the response should only add the authzid if it's set (Note that authzid is *optional*). --- a/com/novell/sasl/client/DigestMD5SaslClient.java +++ b/com/novell/sasl/client/DigestMD5SaslClient.java @@ -661,7 +661,7 @@ public class DigestMD5SaslClient implements SaslClient true); digestResponse.append("username=\""); - digestResponse.append(m_authorizationId); + digestResponse.append(m_name); if (0 != m_realm.length()) { digestResponse.append("\",realm=\""); @@ -679,8 +679,12 @@ public class DigestMD5SaslClient implements SaslClient digestResponse.append(response); digestResponse.append(",charset=utf-8,nonce=\""); digestResponse.append(m_dc.getNonce()); + if (m_authorizationId != null && m_authorizationId.length() >= 0) + { + digestResponse.append("\",authzid=\""); + digestResponse.append(m_authorizationId); + } digestResponse.append("\""); - return digestResponse.toString(); }

1 0

Re: ITS#7796 "not indexed" log messages
by ck＠cksoft.de 09 Mar '14

09 Mar '14

Hi, On Sun, 9 Mar 2014, michael(a)stroeder.com wrote: > hyc(a)symas.com wrote: >> I'd consider instead, resurrecting the LDAP_DEBUG_INDEX debug flag, or putting >> these in LDAP_DEBUG_FILTER. TRACE is already too verbose. > > I'm fine with any solution which avoids that these messages are sent to the > log in case of "loglevel stats stats2". I would also welcome a separate loglevel for these daemon messages: Mar 9 11:00:24 ldap1 slapd[19539]: daemon: read activity on 9 Mar 9 11:00:24 ldap1 slapd[19539]: daemon: select: listen=6 active_threads=0 tvp=zero Mar 9 11:00:24 ldap1 slapd[19539]: daemon: select: listen=7 active_threads=0 tvp=zero Mar 9 11:00:24 ldap1 slapd[19539]: daemon: activity on 1 descriptor Mar 9 11:00:24 ldap1 slapd[19539]: daemon: waked Mar 9 11:00:24 ldap1 slapd[19539]: daemon: select: listen=6 active_threads=0 tvp=zero Mar 9 11:00:24 ldap1 slapd[19539]: daemon: select: listen=7 active_threads=0 tvp=zero They currently seem to be triggered by loglevel conns. So what about adding loglevel daemon or even conns2 for these. Greetings Christian -- Christian Kratzer CK Software GmbH Email: ck(a)cksoft.de Wildberger Weg 24/2 Phone: +49 7032 893 997 - 0 D-71126 Gaeufelden Fax: +49 7032 893 997 - 9 HRB 245288, Amtsgericht Stuttgart Mobile: +49 171 1947 843 Geschaeftsfuehrer: Christian Kratzer Web: http://www.cksoft.de/

1 0

Re: ITS#7796 "not indexed" log messages
by michael＠stroeder.com 09 Mar '14

09 Mar '14

hyc(a)symas.com wrote: > I'd consider instead, resurrecting the LDAP_DEBUG_INDEX debug flag, or putting > these in LDAP_DEBUG_FILTER. TRACE is already too verbose. I'm fine with any solution which avoids that these messages are sent to the log in case of "loglevel stats stats2". Ciao, Michael.

1 0

ITS#7796 "not indexed" log messages
by hyc＠symas.com 08 Mar '14

08 Mar '14

I'd consider instead, resurrecting the LDAP_DEBUG_INDEX debug flag, or putting these in LDAP_DEBUG_FILTER. TRACE is already too verbose. -- -- Howard Chu CTO, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc/ Chief Architect, OpenLDAP http://www.openldap.org/project/

1 0

Re: (ITS#7816) Bug in LMDB's mdb_cmp_memn[r] functions
by hyc＠symas.com 08 Mar '14

08 Mar '14

dror.harari(a)gmail.com wrote: > Full_Name: Dror Harari > Version: > OS: Windows 7 64bit > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (79.181.198.22) > > > The default compare functions start with: > > mdb_cmp_memn(const MDB_val *a, const MDB_val *b) > { > int diff; > ssize_t len_diff; > unsigned int len; > > len = a->mv_size; > len_diff = (ssize_t) a->mv_size - (ssize_t) b->mv_size; > if (len_diff > 0) { > > This code assumes that ssize_t is signed and in all normal platforms it is. > However, on Windows Visal Studio 2010 (did not check others) it is defined as: > > #ifndef _SSIZE_T_DEFINED > #ifdef _WIN64 > typedef unsigned __int64 ssize_t; > #else > typedef _W64 unsigned int ssize_t; > #endif > #define _SSIZE_T_DEFINED > #endif > > So it is unsigned and len_diff would never become <0. If this is true, then you've found a bug in MSVC. The extra S in "SSIZE_T" means "signed." This is part of the C standard, and even the Microsoft documentation agrees with the standard (for once). http://msdn.microsoft.com/en-us/library/windows/desktop/aa383751%28v=vs.85%… You should file a bug report with Microsoft. Closing this ITS. > > There's a workaround to defined a custom compare function but one can rewrite > the default compare around this bug (that is, avoiding subtraction). > > This issue was detected with SET_KEY_RANGE on a key value of 00 00 00 02 where > the database had keys: > 00 00 00 01 65 > 00 00 00 02 65 > 00 00 00 03 65 > > Instead of getting the 00 00 00 02 65, the code returns 00 00 00 03 65 > > -- -- Howard Chu CTO, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc/ Chief Architect, OpenLDAP http://www.openldap.org/project/

1 0

(ITS#7816) Bug in LMDB's mdb_cmp_memn[r] functions
by dror.harari＠gmail.com 07 Mar '14

07 Mar '14

Full_Name: Dror Harari Version: OS: Windows 7 64bit URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (79.181.198.22) The default compare functions start with: mdb_cmp_memn(const MDB_val *a, const MDB_val *b) { int diff; ssize_t len_diff; unsigned int len; len = a->mv_size; len_diff = (ssize_t) a->mv_size - (ssize_t) b->mv_size; if (len_diff > 0) { This code assumes that ssize_t is signed and in all normal platforms it is. However, on Windows Visal Studio 2010 (did not check others) it is defined as: #ifndef _SSIZE_T_DEFINED #ifdef _WIN64 typedef unsigned __int64 ssize_t; #else typedef _W64 unsigned int ssize_t; #endif #define _SSIZE_T_DEFINED #endif So it is unsigned and len_diff would never become <0. There's a workaround to defined a custom compare function but one can rewrite the default compare around this bug (that is, avoiding subtraction). This issue was detected with SET_KEY_RANGE on a key value of 00 00 00 02 where the database had keys: 00 00 00 01 65 00 00 00 02 65 00 00 00 03 65 Instead of getting the 00 00 00 02 65, the code returns 00 00 00 03 65

1 0

Re: (ITS#7809) cross-compiling and openldap-thread-check.m4
by h.b.furuseth＠usit.uio.no 06 Mar '14

06 Mar '14

On Mon, 2014-03-03 at 02:09 +0000, stenn(a)ntp.org wrote: > openldap-thread-check.m4 seems to hand-code an equivalent of AC_ARG_WITH() > processing for the with_yielding_select stuff. This code has at least one typo > and at least one bug; it does not work in the case where one is > cross-compiling. OpenLDAP has no openldap-thread-check.m4. Maybe you're referring to some other package which checks how OpenLDAP uses threads. It could be doing something to match how OpenLDAP handles threads.

1 0

Re: (ITS#7815) mdb cannot retrieve inserted word
by hyc＠symas.com 05 Mar '14

05 Mar '14

clayton.stangeland(a)gmail.com wrote: > Full_Name: Clayton Stangeland > Version: gitorious mdb 2014-02-19 e2bdd44624a525 > OS: Fedora 20 64 bit > URL: http://www.strerror.com/mdb_bug_report/ > Submission from: (NULL) (192.94.73.31) > > > DUPLICATE bug report. New URL: for data file > http://www.strerror.com/mdb_bug_report/. > You can use the 3 non tgz files or download the tgz file which includes all of > them. Thanks for the report. This is now fixed in mdb.master. > I have a text file of words (words.txt). Each is 511 or less characters. When > inserting them into the database there comes a point when I can no longer > retrieve words that were successfully added with mdb_cursor_put. > > It should be put in the libraries/liblmdb directory. The Makefile has an added > command at the end. So put that, words.txt, and word_test.c in liblmdb directory > and run 'make words'. > > It will build and run a failing test. First it reads each line of words.txt. > Then it inserts them with their index as the value into mdb. If you change count > = 29523 on line 145 to be count = 29522 then it works. Inserting the next word > causes it to fail. > > It doesn't fail at the insert but it fails later. When iterating the cursor the > words are not in order and looking up individually not all words can be > retrieved. > > Also, changing line 151 to set val.mv_data, and val.mv_size to a string version > of i (the index, using sprintf), it works. > > This fails the same way on 64 bit Fedora and 64 bit Windows 7. > > -- -- Howard Chu CTO, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc/ Chief Architect, OpenLDAP http://www.openldap.org/project/

1 0

Re: (ITS#7813) lmdb multi threaded env creation on Win32 can fail
by hyc＠symas.com 05 Mar '14

05 Mar '14

clayton.stangeland(a)gmail.com wrote: > Full_Name: Clayton Stangeland > Version: gitorious mdb last commit Feb 19, 2014 e2bdd44624a525d4847c22d7ebf1ea4d154ed734 > OS: Windows 7 > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (192.94.73.31) > > > There is a bug in lightning mdb in mdb.c when running Windows. When creating an > environment to the same file in multiple threads, an error can occur on the > OpenMutex call and some of the creations will fail. > > In mdb_env_setup_locks, mdb_env_excl_lock is called. > If it acquires an exclusive lock CreateMutex is called. > env->me_rmutex = CreateMutex(&mdb_all_sa, FALSE, env->me_txns->mti_rmname); > > If not OpenMutex is called. > env->me_rmutex = OpenMutex(SYNCHRONIZE, FALSE, env->me_txns->mti_rmname); > > The OpenMutex call can fail if there is a thread context switch between the time > the exclusive lock is acquired and the time CreateMutex is called, because the > mutex to open has not actually been created yet. To be clear OpenMutex in > another thread gets run before CreateMutex in the first thread. > > The solution is to replace the OpenMutex calls with CreateMutex. It will either > open the mutex if it exists or create it if it does not. Setting the > bInitialOwner flag to FALSE as is already done is the recommended way to use > CreateMutex in this situation. There is already a note about multiple processes/threads opening the same environment at the same time. In short, don't do this. Even if the code is changed as you describe, if such a race condition can occur, then it also means that the check for mti_magic != MDB_MAGIC can also fail, so the fix is ineffective. -- -- Howard Chu CTO, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc/ Chief Architect, OpenLDAP http://www.openldap.org/project/

1 0

(ITS#7815) mdb cannot retrieve inserted word
by clayton.stangeland＠gmail.com 05 Mar '14

05 Mar '14

Full_Name: Clayton Stangeland Version: gitorious mdb 2014-02-19 e2bdd44624a525 OS: Fedora 20 64 bit URL: http://www.strerror.com/mdb_bug_report/ Submission from: (NULL) (192.94.73.31) DUPLICATE bug report. New URL: for data file http://www.strerror.com/mdb_bug_report/. You can use the 3 non tgz files or download the tgz file which includes all of them. I have a text file of words (words.txt). Each is 511 or less characters. When inserting them into the database there comes a point when I can no longer retrieve words that were successfully added with mdb_cursor_put. It should be put in the libraries/liblmdb directory. The Makefile has an added command at the end. So put that, words.txt, and word_test.c in liblmdb directory and run 'make words'. It will build and run a failing test. First it reads each line of words.txt. Then it inserts them with their index as the value into mdb. If you change count = 29523 on line 145 to be count = 29522 then it works. Inserting the next word causes it to fail. It doesn't fail at the insert but it fails later. When iterating the cursor the words are not in order and looking up individually not all words can be retrieved. Also, changing line 151 to set val.mv_data, and val.mv_size to a string version of i (the index, using sprintf), it works. This fails the same way on 64 bit Fedora and 64 bit Windows 7.

1 0

(ITS#7814) mdb cannot retrieve inserted word
by clayton.stangeland＠gmail.com 05 Mar '14

05 Mar '14

Full_Name: Clayton Stangeland Version: gitorious mdb 2014-02-19 e2bdd44624a525 OS: Fedora 20 64 bit URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (192.94.73.31) I have a text file of words (words.txt). Each is 511 or less characters. When inserting them into the database there comes a point when I can no longer retrieve words that were successfully added with mdb_cursor_put. I will send the code to reproduce to your ftp server. It should be put in the libraries/liblmdb directory. The Makefile has an added command at the end. So put that, words.txt, and word_test.c in liblmdb directory and run 'make words'. It will build and run a failing test. First it reads each line of words.txt. Then it inserts them with their index as the value into mdb. If you change count = 29523 on line 145 to be count = 29522 then it works. Inserting the next word causes it to fail. It doesn't fail at the insert but it fails later. When iterating the cursor the words are not in order and looking up individually not all words can be retrieved. Also, changing line 151 to set val.mv_data, and val.mv_size to a string version of i (the index, using sprintf), it works. This fails the same way on 64 bit Fedora and 64 bit Windows 7.

1 0

(ITS#7813) lmdb multi threaded env creation on Win32 can fail
by clayton.stangeland＠gmail.com 05 Mar '14

05 Mar '14

Full_Name: Clayton Stangeland Version: gitorious mdb last commit Feb 19, 2014 e2bdd44624a525d4847c22d7ebf1ea4d154ed734 OS: Windows 7 URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (192.94.73.31) There is a bug in lightning mdb in mdb.c when running Windows. When creating an environment to the same file in multiple threads, an error can occur on the OpenMutex call and some of the creations will fail. In mdb_env_setup_locks, mdb_env_excl_lock is called. If it acquires an exclusive lock CreateMutex is called. env->me_rmutex = CreateMutex(&mdb_all_sa, FALSE, env->me_txns->mti_rmname); If not OpenMutex is called. env->me_rmutex = OpenMutex(SYNCHRONIZE, FALSE, env->me_txns->mti_rmname); The OpenMutex call can fail if there is a thread context switch between the time the exclusive lock is acquired and the time CreateMutex is called, because the mutex to open has not actually been created yet. To be clear OpenMutex in another thread gets run before CreateMutex in the first thread. The solution is to replace the OpenMutex calls with CreateMutex. It will either open the mutex if it exists or create it if it does not. Setting the bInitialOwner flag to FALSE as is already done is the recommended way to use CreateMutex in this situation.

1 0

Re: (ITS#7812) Applictaion going down due to Ldap Break down and Restart is required
by quanah＠zimbra.com 05 Mar '14

05 Mar '14

--On March 5, 2014 at 9:17:52 AM +0000 m.noorishah.burhan(a)accenture.com wrote: > Full_Name: Mohammed Noorishah > Version: 2.3.43-12.el5 > OS: Linux version 2.6.18-194.el5 > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (170.248.47.80) > > > Dear All, > > we are getting application down almost like every 2/3 day > and Required LDAP Restart as a fix, can any one advice what could be the > problem .. > > Required to know, > what all data get cleared in ldap or refreshed during openLdap restart. > so that application will work fine. We have no idea who wrote your application or what it involves. You are running an unsupported release of OpenLDAP provided by RedHat. If you have issue with the OpenLDAP build provided by RedHat, then you must contact them for support. The openldap ITS system is not the correct place to be pursuing the issues you have with your RedHat build of an ancient unsupported version of OpenLDAP. --Quanah -- Quanah Gibson-Mount Principal Software Engineer Zimbra, Inc -------------------- Zimbra :: the leader in open source messaging and collaboration

1 0

(ITS#7812) Applictaion going down due to Ldap Break down and Restart is required
by m.noorishah.burhan＠accenture.com 05 Mar '14

05 Mar '14

Full_Name: Mohammed Noorishah Version: 2.3.43-12.el5 OS: Linux version 2.6.18-194.el5 URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (170.248.47.80) Dear All, we are getting application down almost like every 2/3 day and Required LDAP Restart as a fix, can any one advice what could be the problem .. Required to know, what all data get cleared in ldap or refreshed during openLdap restart. so that application will work fine.

1 0

RE: (ITS#7811) Applictaion going down due to Ldap Break down and Restart is required
by m.noorishah.burhan＠accenture.com 04 Mar '14

04 Mar '14

Hi Howard, Sorry for the confusion - we have marked in property file as version = 3 Kindly advice on the same . Your help would be really grateful. Thanks and Regards Noorishah. 09663398005 -----Original Message----- From: Howard Chu [mailto:hyc@symas.com] Sent: Tuesday, March 04, 2014 9:49 PM To: Noorishah Burhan, M.; openldap-its(a)openldap.org Subject: Re: (ITS#7811) Applictaion going down due to Ldap Break down and Restart is required m.noorishah.burhan(a)accenture.com wrote: > Full_Name: Mohammed Noorishah > Version: 3.3 > OS: Unix > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (170.248.47.80) > There is no OpenLDAP v3.3. It seems you're not using OpenLDAP software and you've contacted us in error. This ITS will be closed. > related to 7810, Wrongly given my email id ..corrected now > (m.noorishah.burhan(a)accenture.com) > > Kindly do the needful > > > -- -- Howard Chu CTO, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc/ Chief Architect, OpenLDAP http://www.openldap.org/project/ ________________________________ This message is for the designated recipient only and may contain privileged, proprietary, or otherwise confidential information. If you have received it in error, please notify the sender immediately and delete the original. Any other use of the e-mail by you is prohibited. Where allowed by local law, electronic communications with Accenture and its affiliates, including e-mail and instant messaging (including content), may be scanned by our systems for the purposes of information security and assessment of internal compliance with Accenture policy. ______________________________________________________________________________________ www.accenture.com

1 0

Re: (ITS#7811) Applictaion going down due to Ldap Break down and Restart is required
by hyc＠symas.com 04 Mar '14

04 Mar '14

m.noorishah.burhan(a)accenture.com wrote: > Full_Name: Mohammed Noorishah > Version: 3.3 > OS: Unix > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (170.248.47.80) > There is no OpenLDAP v3.3. It seems you're not using OpenLDAP software and you've contacted us in error. This ITS will be closed. > related to 7810, Wrongly given my email id ..corrected now > (m.noorishah.burhan(a)accenture.com) > > Kindly do the needful > > > -- -- Howard Chu CTO, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc/ Chief Architect, OpenLDAP http://www.openldap.org/project/

1 0

(ITS#7811) Applictaion going down due to Ldap Break down and Restart is required
by m.noorishah.burhan＠accenture.com 04 Mar '14

04 Mar '14

Full_Name: Mohammed Noorishah Version: 3.3 OS: Unix URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (170.248.47.80) related to 7810, Wrongly given my email id ..corrected now (m.noorishah.burhan(a)accenture.com) Kindly do the needful

1 0

(ITS#7810) Applictaion going down due to Ldap Break down and Restart is required
by m.noorishah.burhan＠accneture.com 04 Mar '14

04 Mar '14

Full_Name: Mohammed Noorishah Version: v3.3 OS: Unix URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (170.248.47.80) Hi Team, we are getting application down almost like every 3 day and Required LDAP Restart as a fix can any one advice what could be the problem .. Required to know, what all data get cleared in ldap or refreshed during Ldap restart. so that application is working fine.

1 0

(ITS#7809) cross-compiling and openldap-thread-check.m4
by stenn＠ntp.org 02 Mar '14

02 Mar '14

Full_Name: Harlan Stenn Version: OS: URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (63.155.158.122) openldap-thread-check.m4 seems to hand-code an equivalent of AC_ARG_WITH() processing for the with_yielding_select stuff. This code has at least one typo and at least one bug; it does not work in the case where one is cross-compiling. Before I go and submit a patch that would convert this macro to using AC_ARG_WITH, I figured I should ask to see why things were done the way they were.

1 0

RE: (ITS#7807) rebind-as-user in slapd-meta not running
by theedgeu2＠live.com 01 Mar '14

01 Mar '14

--_b67832eb-f95f-44fc-96d8-4e1d626f474b_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable First of all thank you for your quick answer. =20 Before I posted the question I've read the man pages several times trying t= o understand how slapd-meta runs. I don't speak english very well (as you c= an see) so it's probably that i've don't understand it completly. =20 As I've tried to explain in my question=2C I used idassert-bind before and = it runs ok=2C but I don't understand why I've to use an administrative acco= unt to connect the proxy with the targets if I only want to passthrough the= credentials of the user that was authenticated on the proxy. So I tried to= use rebind-as-user thinking it was the solution but as you say this is for= another use. =20 Only for confirm what I'm doing. Is this the correct directive for what I'm= trying to do? idassert-bind mode=3Dself bindmethod=3Dsimple binddn=3D"cn=3Dadminuser=2Cou= =3Dusers=2Cdc=3Dtest=2Cdc=3Dcom" credentials=3D"password of admin user" =20 Regards =20 > Date: Fri=2C 28 Feb 2014 21:23:52 +0100 > From: pierangelo.masarati(a)polimi.it > To: theedgeu2(a)live.com > CC: openldap-its(a)openldap.org > Subject: Re: (ITS#7807) rebind-as-user in slapd-meta not running >=20 > On 02/28/2014 11:00 AM=2C theedgeu2(a)live.com wrote: > > Full_Name: Angel Martinez > > Version: 2.4.39 > > OS: Red Hat Linux 6.4 > > URL: ftp://ftp.openldap.org/incoming/ > > Submission from: (NULL) (217.71.18.36) > > > > > > I'm trying to configure a LDAP proxy with slapd-meta. > > > > I have several suffixs over several instances that shares the same user > > accounts. It's posible that one user had access to several targets. > > > > The targets are: > > > > * Users: ou=3Dusers=2C dc=3Dtest=2C dc=3Dcom (here resides all accounts= ) > > > > * Target1: ou=3Dtarget1=2C dc=3Dtest=2C dc=3Dcom > > > > * Target2: ou=3Dtarget2=2C dc=3Dtest=2C dc=3Dcom > > > > These 3 suffix are on 3 differents instances. > > > > The instances where target1 and target2 are also have another suffix: o= u=3Dusers=2C > > dc=3Dtest=2C dc=3Dcom. This suffix is replicated from the first instanc= e (Users) > > > > Normally=2C the users connect throught the proxy=2C but sometimes will = connect > > directly to the others instances. > > > > Basically this is the slapd.conf of the proxy: > > > > database meta > > chase-referrals yes > > rebind-as-user yes > > > > suffix "ou=3Dusers=2Cdc=3Dtest=2Cdc=3Dcom" > > uri "ldap://192.168.1.34:3891/ou=3Dusers=2Cdc=3Dtest=2Cdc=3Dcom" > > > > suffix "ou=3Dtarget1=2Cdc=3Dtest=2Cdc=3Dcom" > > uri "ldap://192.168.1.34:3892/ou=3Dtarget1=2Cdc=3Dtest=2Cdc=3Dcom" > > > > suffix "ou=3Dtarget2=2Cdc=3Dtest=2Cdc=3Dcom" > > uri "ldap://192.168.1.34:3893/ou=3Dtarget2=2Cdc=3Dtest=2Cdc=3Dcom" > > > > When a user connects to the proxy with cn=3Duser1=2Cou=3Dusers=2Cdc=3Dt= est=2Cdc=3Dcom=2C the > > user is validated against the first target (ou=3Dusers) and can search = over this > > suffix=2C but if this user try to search something over other target (f= or example > > ou=3Dtarget1) the proxy does not use the credentials of the user and do= an > > anonymous bind to target1=2C so the search doesn't run. > > > > I thought that rebind-as-user resolve this but doesn't run. > > > > I've tried using idassert-bind mode=3Dself bindmethod=3Dsimple > > binddn=3D"cn=3Dadminuser=2Cou=3Dusers=2Cdc=3Dtest=2Cdc=3Dcom" credentia= ls=3D"password" and runs > > ok=2C but I prefer not to use an administrative account to connect the = proxy with > > the targets. > > > > Is there something I'm missing? >=20 > Yes=2C you did not read slapd-meta(5) man page. rebind-as-user is used i= n=20 > a totally different context. What you need is idassert-bind. >=20 >=20 > Please direct further conversation to <openldap-technical(a)openldap.org>.= =20 > This ITS will be closed. >=20 > p. >=20 >=20 > --=20 > Pierangelo Masarati > Associate Professor > Dipartimento di Scienze e Tecnologie Aerospaziali > Politecnico di Milano = --_b67832eb-f95f-44fc-96d8-4e1d626f474b_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable <html> <head> <style></style></head> <body class=3D'hmmessage'><div dir=3D'ltr'> First of all thank you for y= our quick answer. &nbsp=3B Before I posted the question I've read the= man pages several times trying to understand how slapd-meta runs. I don't = speak english very well (as you can see) so it's probably that i've don't u= nderstand it completly. &nbsp=3B As I've tried to&nbsp=3Bexplain in m= y question=2C I used idassert-bind before and it runs ok=2C but I don't und= erstand why I've to use an administrative account to connect the proxy with= the targets if I only want to passthrough the credentials of the user that= was authenticated on the proxy. So I tried to use rebind-as-user thinking = it was the solution but as you say this is for another use. &nbsp=3B = Only for confirm what I'm doing. Is this the correct directive for what I'm= trying to do? idassert-bind mode=3Dself bindmethod=3Dsimple binddn=3D"c= n=3Dadminuser=2Cou=3Dusers=2Cdc=3Dtest=2Cdc=3Dcom" credentials=3D"password = of admin user" &nbsp=3B Regards &nbsp=3B <div>&gt=3B Date: Fri= =2C 28 Feb 2014 21:23:52 +0100 &gt=3B From: pierangelo.masarati(a)polimi.i= t &gt=3B To: theedgeu2(a)live.com &gt=3B CC: openldap-its(a)openldap.org<= br>&gt=3B Subject: Re: (ITS#7807) rebind-as-user in slapd-meta not running<= br>&gt=3B &gt=3B On 02/28/2014 11:00 AM=2C theedgeu2(a)live.com wrote:<br= >&gt=3B &gt=3B Full_Name: Angel Martinez &gt=3B &gt=3B Version: 2.4.39<b= r>&gt=3B &gt=3B OS: Red Hat Linux 6.4 &gt=3B &gt=3B URL: ftp://ftp.openl= dap.org/incoming/ &gt=3B &gt=3B Submission from: (NULL) (217.71.18.36)<b= r>&gt=3B &gt=3B &gt=3B &gt=3B &gt=3B &gt=3B I'm trying to configure a= LDAP proxy with slapd-meta. &gt=3B &gt=3B &gt=3B &gt=3B I have sever= al suffixs over several instances that shares the same user &gt=3B &gt= =3B accounts. It's posible that one user had access to several targets. = &gt=3B &gt=3B &gt=3B &gt=3B The targets are: &gt=3B &gt=3B &gt=3B = &gt=3B * Users: ou=3Dusers=2C dc=3Dtest=2C dc=3Dcom (here resides all accou= nts) &gt=3B &gt=3B &gt=3B &gt=3B * Target1: ou=3Dtarget1=2C dc=3Dtest= =2C dc=3Dcom &gt=3B &gt=3B &gt=3B &gt=3B * Target2: ou=3Dtarget2=2C d= c=3Dtest=2C dc=3Dcom &gt=3B &gt=3B &gt=3B &gt=3B These 3 suffix are o= n 3 differents instances. &gt=3B &gt=3B &gt=3B &gt=3B The instances w= here target1 and target2 are also have another suffix: ou=3Dusers=2C &gt= =3B &gt=3B dc=3Dtest=2C dc=3Dcom. This suffix is replicated from the first = instance (Users) &gt=3B &gt=3B &gt=3B &gt=3B Normally=2C the users co= nnect throught the proxy=2C but sometimes will connect &gt=3B &gt=3B dir= ectly to the others instances. &gt=3B &gt=3B &gt=3B &gt=3B Basically = this is the slapd.conf of the proxy: &gt=3B &gt=3B &gt=3B &gt=3B data= base meta &gt=3B &gt=3B chase-referrals yes &gt=3B &gt=3B rebind-as-u= ser yes &gt=3B &gt=3B &gt=3B &gt=3B suffix "ou=3Dusers=2Cdc=3Dtest= =2Cdc=3Dcom" &gt=3B &gt=3B uri "ldap://192.168.1.34:3891/ou=3Dusers= =2Cdc=3Dtest=2Cdc=3Dcom" &gt=3B &gt=3B &gt=3B &gt=3B suffix "ou=3Dt= arget1=2Cdc=3Dtest=2Cdc=3Dcom" &gt=3B &gt=3B uri "ldap://192.168.1.= 34:3892/ou=3Dtarget1=2Cdc=3Dtest=2Cdc=3Dcom" &gt=3B &gt=3B &gt=3B &gt= =3B suffix "ou=3Dtarget2=2Cdc=3Dtest=2Cdc=3Dcom" &gt=3B &gt=3B uri = "ldap://192.168.1.34:3893/ou=3Dtarget2=2Cdc=3Dtest=2Cdc=3Dcom" &gt=3B = &gt=3B &gt=3B &gt=3B When a user connects to the proxy with cn=3Duser1= =2Cou=3Dusers=2Cdc=3Dtest=2Cdc=3Dcom=2C the &gt=3B &gt=3B user is valida= ted against the first target (ou=3Dusers) and can search over this &gt= =3B &gt=3B suffix=2C but if this user try to search something over other ta= rget (for example &gt=3B &gt=3B ou=3Dtarget1) the proxy does not use the= credentials of the user and do an &gt=3B &gt=3B anonymous bind to targe= t1=2C so the search doesn't run. &gt=3B &gt=3B &gt=3B &gt=3B I though= t that rebind-as-user resolve this but doesn't run. &gt=3B &gt=3B &gt= =3B &gt=3B I've tried using idassert-bind mode=3Dself bindmethod=3Dsimple<b= r>&gt=3B &gt=3B binddn=3D"cn=3Dadminuser=2Cou=3Dusers=2Cdc=3Dtest=2Cdc=3Dco= m" credentials=3D"password" and runs &gt=3B &gt=3B ok=2C but I prefer no= t to use an administrative account to connect the proxy with &gt=3B &gt= =3B the targets. &gt=3B &gt=3B &gt=3B &gt=3B Is there something I'm m= issing? &gt=3B &gt=3B Yes=2C you did not read slapd-meta(5) man page= . rebind-as-user is used in &gt=3B a totally different context. What = you need is idassert-bind. &gt=3B &gt=3B &gt=3B Please direct fu= rther conversation to &lt=3Bopenldap-technical(a)openldap.org&gt=3Bt=3B. &gt= =3B This ITS will be closed. &gt=3B &gt=3B p. &gt=3B &gt=3B= &gt=3B -- &gt=3B Pierangelo Masarati &gt=3B Associate Professor= &gt=3B Dipartimento di Scienze e Tecnologie Aerospaziali &gt=3B Poli= tecnico di Milano </div> </div></body> </html>= --_b67832eb-f95f-44fc-96d8-4e1d626f474b_--

1 0

ITS#7788
by michael＠stroeder.com 01 Mar '14

01 Mar '14

I do not consider this to be a bug. I'd vote for closing it as "won't fix".

1 0

Re: (ITS#7801) test033-glue-syncrepl with bdb/hdb gets stuck on ppc64
by hyc＠symas.com 28 Feb '14

28 Feb '14

jsynacek(a)redhat.com wrote: > Full_Name: Jan Synacek > Version: 2.4.39 > OS: GNU/Linux > URL: > Submission from: (NULL) (209.132.186.34) > > > I configured openldap with --enable-bdb, --enable-hdb and --enable-mdb. No other > options were used. > Reproduced on a ppc64 system with kernel 3.10.0. > > # ./run -b hdb test033-glue-syncrepl > Cleaning up test run directory leftover from previous run. > Running ./scripts/test033-glue-syncrepl for hdb... > running defines.sh > Running slapadd to build glued slapd databases... > Starting slapd 1 on TCP/IP port 9011... > Using ldapsearch to check that slapd 1 is running... > Starting slapd 2 on TCP/IP port 9012... > Using ldapsearch to check that slapd 2 is running... > Using ldapadd to populate subtree="ou=Information Technology > Division,ou=People,dc=example,dc=com" on port 9011... > Using ldapadd to populate subtree="ou=Groups,dc=example,dc=com" on port 9012... > > After that, there is no output. First thing to look at is a gdb stack trace of both slapds, to see what threads are actually stuck and where. Also look at the log files in the testrun directory to see what was the last operation being performed. -- -- Howard Chu CTO, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc/ Chief Architect, OpenLDAP http://www.openldap.org/project/

1 0

Re: (ITS#7807) rebind-as-user in slapd-meta not running
by pierangelo.masarati＠polimi.it 28 Feb '14

28 Feb '14

On 02/28/2014 11:00 AM, theedgeu2(a)live.com wrote: > Full_Name: Angel Martinez > Version: 2.4.39 > OS: Red Hat Linux 6.4 > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (217.71.18.36) > > > I'm trying to configure a LDAP proxy with slapd-meta. > > I have several suffixs over several instances that shares the same user > accounts. It's posible that one user had access to several targets. > > The targets are: > > * Users: ou=users, dc=test, dc=com (here resides all accounts) > > * Target1: ou=target1, dc=test, dc=com > > * Target2: ou=target2, dc=test, dc=com > > These 3 suffix are on 3 differents instances. > > The instances where target1 and target2 are also have another suffix: ou=users, > dc=test, dc=com. This suffix is replicated from the first instance (Users) > > Normally, the users connect throught the proxy, but sometimes will connect > directly to the others instances. > > Basically this is the slapd.conf of the proxy: > > database meta > chase-referrals yes > rebind-as-user yes > > suffix "ou=users,dc=test,dc=com" > uri "ldap://192.168.1.34:3891/ou=users,dc=test,dc=com" > > suffix "ou=target1,dc=test,dc=com" > uri "ldap://192.168.1.34:3892/ou=target1,dc=test,dc=com" > > suffix "ou=target2,dc=test,dc=com" > uri "ldap://192.168.1.34:3893/ou=target2,dc=test,dc=com" > > When a user connects to the proxy with cn=user1,ou=users,dc=test,dc=com, the > user is validated against the first target (ou=users) and can search over this > suffix, but if this user try to search something over other target (for example > ou=target1) the proxy does not use the credentials of the user and do an > anonymous bind to target1, so the search doesn't run. > > I thought that rebind-as-user resolve this but doesn't run. > > I've tried using idassert-bind mode=self bindmethod=simple > binddn="cn=adminuser,ou=users,dc=test,dc=com" credentials="password" and runs > ok, but I prefer not to use an administrative account to connect the proxy with > the targets. > > Is there something I'm missing? Yes, you did not read slapd-meta(5) man page. rebind-as-user is used in a totally different context. What you need is idassert-bind. Please direct further conversation to <openldap-technical(a)openldap.org>. This ITS will be closed. p. -- Pierangelo Masarati Associate Professor Dipartimento di Scienze e Tecnologie Aerospaziali Politecnico di Milano

1 0

(ITS#7808)
by theEdgeU2＠live.com 28 Feb '14

28 Feb '14

I'm sorry but ITS#7807 is the same as this. Regards

1 0

(ITS#7808) rebind-as-user in slapd-meta not running
by theedgeu2＠live.com 28 Feb '14

28 Feb '14

Full_Name: Angel Martinez Version: 2.4.39 OS: Red Hat Linux 6.4 URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (217.71.18.36) I'm trying to configure a LDAP proxy with slapd-meta. I have several suffixs over several instances that shares the same user accounts. It's posible that one user had access to several targets. The targets are: * Users: ou=users, dc=test, dc=com (here resides all accounts) * Target1: ou=target1, dc=test, dc=com * Target2: ou=target2, dc=test, dc=com These 3 suffix are on 3 differents instances. The instances where target1 and target2 are also have another suffix: ou=users, dc=test, dc=com. This suffix is replicated from the first instance (Users) Normally, the users connect throught the proxy, but sometimes will connect directly to the others instances. Basically this is the slapd.conf of the proxy: database meta chase-referrals yes rebind-as-user yes suffix "ou=users,dc=test,dc=com" uri "ldap://192.168.1.34:3891/ou=users,dc=test,dc=com" suffix "ou=target1,dc=test,dc=com" uri "ldap://192.168.1.34:3892/ou=target1,dc=test,dc=com" suffix "ou=target2,dc=test,dc=com" uri "ldap://192.168.1.34:3893/ou=target2,dc=test,dc=com" When a user connects to the proxy with cn=user1,ou=users,dc=test,dc=com, the user is validated against the first target (ou=users) and can search over this suffix, but if this user try to search something over other target (for example ou=target1) the proxy does not use the credentials of the user and do an anonymous bind to target1, so the search doesn't run. I thought that rebind-as-user resolve this but doesn't run. I've tried using idassert-bind mode=self bindmethod=simple binddn="cn=adminuser,ou=users,dc=test,dc=com" credentials="password" and runs ok, but I prefer not to use an administrative account to connect the proxy with the targets. Is there something I'm missing? Thanks

1 0

(ITS#7807) rebind-as-user in slapd-meta not running
by theedgeu2＠live.com 28 Feb '14

28 Feb '14

Full_Name: Angel Martinez Version: 2.4.39 OS: Red Hat Linux 6.4 URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (217.71.18.36) I'm trying to configure a LDAP proxy with slapd-meta. I have several suffixs over several instances that shares the same user accounts. It's posible that one user had access to several targets. The targets are: * Users: ou=users, dc=test, dc=com (here resides all accounts) * Target1: ou=target1, dc=test, dc=com * Target2: ou=target2, dc=test, dc=com These 3 suffix are on 3 differents instances. The instances where target1 and target2 are also have another suffix: ou=users, dc=test, dc=com. This suffix is replicated from the first instance (Users) Normally, the users connect throught the proxy, but sometimes will connect directly to the others instances. Basically this is the slapd.conf of the proxy: database meta chase-referrals yes rebind-as-user yes suffix "ou=users,dc=test,dc=com" uri "ldap://192.168.1.34:3891/ou=users,dc=test,dc=com" suffix "ou=target1,dc=test,dc=com" uri "ldap://192.168.1.34:3892/ou=target1,dc=test,dc=com" suffix "ou=target2,dc=test,dc=com" uri "ldap://192.168.1.34:3893/ou=target2,dc=test,dc=com" When a user connects to the proxy with cn=user1,ou=users,dc=test,dc=com, the user is validated against the first target (ou=users) and can search over this suffix, but if this user try to search something over other target (for example ou=target1) the proxy does not use the credentials of the user and do an anonymous bind to target1, so the search doesn't run. I thought that rebind-as-user resolve this but doesn't run. I've tried using idassert-bind mode=self bindmethod=simple binddn="cn=adminuser,ou=users,dc=test,dc=com" credentials="password" and runs ok, but I prefer not to use an administrative account to connect the proxy with the targets. Is there something I'm missing? Thanks

1 0

RE: (ITS#7805) fatal region error detected; run recovery
by quanah＠zimbra.com 27 Feb '14

27 Feb '14

--On Thursday, February 27, 2014 8:22 AM +0000 venkatachalam.dk(a)accenture.com wrote: > Hi , > > Below is the LDAP version used in the server , I have provided wrongly , > version is : 2.3.43-12 > > openldap-clients-2.3.43-12.el5 > openldap-2.3.43-12.el5 > openldap-2.3.43-12.el5 OpenLDAP 2.3 reached end of life in 2008. The current supported release series is OpenLDAP 2.4. I.e., you're using a release that hasn't been had any further development in nearly 6 years. I'd strongly advise you to look at the packages from Symas or the LTB project if you are unable to compile OpenLDAP yourself. If you wish to continue using the utterly broken and outdated packages provided by RedHat, then you need to file tickets with RedHat for support. Regards, Quanah -- Quanah Gibson-Mount Architect - Server Zimbra, Inc. -------------------- Zimbra :: the leader in open source messaging and collaboration

1 0

Re: (ITS#7805) fatal region error detected; run recovery
by ualex73＠gmail.com 27 Feb '14

27 Feb '14

--001a11c2f5ea1bbd3804f35f38ba Content-Type: text/plain; charset=ISO-8859-1 This is a RedHat supplied version, so you need to contact them for support. 2014-02-27 9:24 GMT+01:00 <venkatachalam.dk(a)accenture.com>: > Hi , > > Below is the LDAP version used in the server , I have provided wrongly , > version is : 2.3.43-12 > > openldap-clients-2.3.43-12.el5 > openldap-2.3.43-12.el5 > openldap-2.3.43-12.el5 > > Thanks > Venkat > > -----Original Message----- > From: Quanah Gibson-Mount [mailto:quanah@zimbra.com] > Sent: 26 February 2014 23:11 > To: Dk, Venkatachalam; openldap-its(a)openldap.org > Subject: Re: (ITS#7805) fatal region error detected; run recovery > > --On Wednesday, February 26, 2014 10:17 AM +0000 > venkatachalam.dk(a)accenture.com wrote: > > > Full_Name: Venkatachalam > > Version: 2.4.3.1 > > There is no such OpenLDAP release. If you are using the build provided by > RHEL, then the correct contact is RedHat. Generally, it is very wise to > avoid RH's build of OpenLDAP. > > --Quanah > > > > -- > > Quanah Gibson-Mount > Architect - Server > Zimbra, Inc. > -------------------- > Zimbra :: the leader in open source messaging and collaboration > > > ________________________________ > > This message is for the designated recipient only and may contain > privileged, proprietary, or otherwise confidential information. If you have > received it in error, please notify the sender immediately and delete the > original. Any other use of the e-mail by you is prohibited. Where allowed > by local law, electronic communications with Accenture and its affiliates, > including e-mail and instant messaging (including content), may be scanned > by our systems for the purposes of information security and assessment of > internal compliance with Accenture policy. . > > ______________________________________________________________________________________ > > www.accenture.com > > > > --001a11c2f5ea1bbd3804f35f38ba Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable <div dir=3D"ltr">This is a RedHat supplied version, so you need to contact = them for support. </div><div class=3D"gmail_extra"> <div class=3D= "gmail_quote">2014-02-27 9:24 GMT+01:00 <<a href=3D"m= ailto:venkatachalam.dk@accenture.com" target=3D"_blank">venkatachalam.dk@ac= centure.com</a>>: <blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p= x #ccc solid;padding-left:1ex">Hi , Below is the LDAP version used in the server , I have provided wrongly , ve= rsion is : 2.3.43-12 openldap-clients-2.3.43-12.el5 openldap-2.3.43-12.el5 openldap-2.3.43-12.el5 Thanks Venkat <div><div class=3D"h5"> -----Original Message----- From: Quanah Gibson-Mount [mailto:<a href=3D"mailto:quanah@zimbra.com">quan= ah(a)zimbra.com</a>] Sent: 26 February 2014 23:11 To: Dk, Venkatachalam; <a href=3D"mailto:openldap-its@openldap.org">openlda= p-its(a)openldap.org</a> Subject: Re: (ITS#7805) fatal region error detected; run recovery --On Wednesday, February 26, 2014 10:17 AM +0000 <a href=3D"mailto:venkatac= halam.dk(a)accenture.com">venkatachalam.dk(a)accenture.com</a> wrote: > Full_Name: Venkatachalam > Version: 2.4.3.1 There is no such OpenLDAP release. =A0If you are using the build provided b= y RHEL, then the correct contact is RedHat. =A0Generally, it is very wise t= o avoid RH's build of OpenLDAP. --Quanah -- Quanah Gibson-Mount Architect - Server Zimbra, Inc. -------------------- Zimbra :: =A0the leader in open source messaging and collaboration </div></div>________________________________ This message is for the designated recipient only and may contain privilege= d, proprietary, or otherwise confidential information. If you have received= it in error, please notify the sender immediately and delete the original.= Any other use of the e-mail by you is prohibited. Where allowed by local l= aw, electronic communications with Accenture and its affiliates, including = e-mail and instant messaging (including content), may be scanned by our sys= tems for the purposes of information security and assessment of internal co= mpliance with Accenture policy. . ___________________________________________________________________________= ___________ <a href=3D"http://www.accenture.com" target=3D"_blank">www.accenture.com</a= > </blockquote></div> </div> --001a11c2f5ea1bbd3804f35f38ba--

1 0

RE: (ITS#7805) fatal region error detected; run recovery
by venkatachalam.dk＠accenture.com 27 Feb '14

27 Feb '14

Hi , Below is the LDAP version used in the server , I have provided wrongly , version is : 2.3.43-12 openldap-clients-2.3.43-12.el5 openldap-2.3.43-12.el5 openldap-2.3.43-12.el5 Thanks Venkat -----Original Message----- From: Quanah Gibson-Mount [mailto:quanah@zimbra.com] Sent: 26 February 2014 23:11 To: Dk, Venkatachalam; openldap-its(a)openldap.org Subject: Re: (ITS#7805) fatal region error detected; run recovery --On Wednesday, February 26, 2014 10:17 AM +0000 venkatachalam.dk(a)accenture.com wrote: > Full_Name: Venkatachalam > Version: 2.4.3.1 There is no such OpenLDAP release. If you are using the build provided by RHEL, then the correct contact is RedHat. Generally, it is very wise to avoid RH's build of OpenLDAP. --Quanah -- Quanah Gibson-Mount Architect - Server Zimbra, Inc. -------------------- Zimbra :: the leader in open source messaging and collaboration ________________________________ This message is for the designated recipient only and may contain privileged, proprietary, or otherwise confidential information. If you have received it in error, please notify the sender immediately and delete the original. Any other use of the e-mail by you is prohibited. Where allowed by local law, electronic communications with Accenture and its affiliates, including e-mail and instant messaging (including content), may be scanned by our systems for the purposes of information security and assessment of internal compliance with Accenture policy. . ______________________________________________________________________________________ www.accenture.com

1 0

Re: (ITS#7806) memory leak in contrib/ldapc++/LDAPAsynConnection.cpp
by hyc＠symas.com 26 Feb '14

26 Feb '14

kevpatt(a)khptech.com wrote: > Full_Name: Kevin H. Patterson > Version: git master HEAD > OS: macosx 10.9.1 > URL: http://campus.hartland.edu/temp/0001-fixed-memory-leak-in-LDAPAsynConnectio… > Submission from: (NULL) (65.207.4.130) > > > In libldapcpp, there is a memory leak in the LDAPAsynConnection class. > ldap_initialize() allocates memory which is never freed. This memory (ld > structure) should be freed by a call to ldap_unbind() in the class destructor > and other places where the ld structure is replaced with a new one. > > I have included a patch against git master HEAD below. Thanks for the patch, committed to master. > > --- > >>From c9b4b1a2638eec20f35c2eae31f0471cc61a21ff Mon Sep 17 00:00:00 2001 > From: "Kevin H. Patterson" <kevpatt(a)khptech.com> > Date: Wed, 26 Feb 2014 13:08:24 -0500 > Subject: [PATCH] fixed memory leak in LDAPAsynConnection.cpp > > --- > contrib/ldapc++/src/LDAPAsynConnection.cpp | 10 +++++++++- > 1 file changed, 9 insertions(+), 1 deletion(-) > > diff --git a/contrib/ldapc++/src/LDAPAsynConnection.cpp > b/contrib/ldapc++/src/LDAPAsynConnection.cpp > index 894f8ba..582d2b5 100644 > --- a/contrib/ldapc++/src/LDAPAsynConnection.cpp > +++ b/contrib/ldapc++/src/LDAPAsynConnection.cpp > @@ -43,7 +43,10 @@ LDAPAsynConnection::LDAPAsynConnection(const string& url, int > port, > this->setConstraints(cons); > } > > -LDAPAsynConnection::~LDAPAsynConnection(){} > +LDAPAsynConnection::~LDAPAsynConnection(){ > + unbind(); > + delete m_constr; > +} > > void LDAPAsynConnection::init(const string& hostname, int port){ > DEBUG(LDAP_DEBUG_TRACE,"LDAPAsynConnection::init" << endl); > @@ -51,6 +54,8 @@ void LDAPAsynConnection::init(const string& hostname, int > port){ > " hostname:" << hostname << endl > << " port:" << port << endl); > > + unbind(); > + > m_uri.setScheme("ldap"); > m_uri.setHost(hostname); > m_uri.setPort(port); > @@ -66,6 +71,8 @@ void LDAPAsynConnection::init(const string& hostname, int > port){ > } > > void LDAPAsynConnection::initialize(const std::string& uri){ > + unbind(); > + > m_uri.setURLString(uri); > int ret = ldap_initialize(&cur_session, m_uri.getURLString().c_str()); > if ( ret != LDAP_SUCCESS ) { > @@ -277,6 +284,7 @@ void LDAPAsynConnection::unbind(){ > > void LDAPAsynConnection::setConstraints(LDAPConstraints *cons){ > DEBUG(LDAP_DEBUG_TRACE,"LDAPAsynConnection::setConstraints()" << endl); > + delete m_constr; > m_constr=cons; > } > > -- -- Howard Chu CTO, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc/ Chief Architect, OpenLDAP http://www.openldap.org/project/

1 0

(ITS#7806) memory leak in contrib/ldapc++/LDAPAsynConnection.cpp
by kevpatt＠khptech.com 26 Feb '14

26 Feb '14

Full_Name: Kevin H. Patterson Version: git master HEAD OS: macosx 10.9.1 URL: http://campus.hartland.edu/temp/0001-fixed-memory-leak-in-LDAPAsynConnectio… Submission from: (NULL) (65.207.4.130) In libldapcpp, there is a memory leak in the LDAPAsynConnection class. ldap_initialize() allocates memory which is never freed. This memory (ld structure) should be freed by a call to ldap_unbind() in the class destructor and other places where the ld structure is replaced with a new one. I have included a patch against git master HEAD below. --- >From c9b4b1a2638eec20f35c2eae31f0471cc61a21ff Mon Sep 17 00:00:00 2001 From: "Kevin H. Patterson" <kevpatt(a)khptech.com> Date: Wed, 26 Feb 2014 13:08:24 -0500 Subject: [PATCH] fixed memory leak in LDAPAsynConnection.cpp --- contrib/ldapc++/src/LDAPAsynConnection.cpp | 10 +++++++++- 1 file changed, 9 insertions(+), 1 deletion(-) diff --git a/contrib/ldapc++/src/LDAPAsynConnection.cpp b/contrib/ldapc++/src/LDAPAsynConnection.cpp index 894f8ba..582d2b5 100644 --- a/contrib/ldapc++/src/LDAPAsynConnection.cpp +++ b/contrib/ldapc++/src/LDAPAsynConnection.cpp @@ -43,7 +43,10 @@ LDAPAsynConnection::LDAPAsynConnection(const string& url, int port, this->setConstraints(cons); } -LDAPAsynConnection::~LDAPAsynConnection(){} +LDAPAsynConnection::~LDAPAsynConnection(){ + unbind(); + delete m_constr; +} void LDAPAsynConnection::init(const string& hostname, int port){ DEBUG(LDAP_DEBUG_TRACE,"LDAPAsynConnection::init" << endl); @@ -51,6 +54,8 @@ void LDAPAsynConnection::init(const string& hostname, int port){ " hostname:" << hostname << endl << " port:" << port << endl); + unbind(); + m_uri.setScheme("ldap"); m_uri.setHost(hostname); m_uri.setPort(port); @@ -66,6 +71,8 @@ void LDAPAsynConnection::init(const string& hostname, int port){ } void LDAPAsynConnection::initialize(const std::string& uri){ + unbind(); + m_uri.setURLString(uri); int ret = ldap_initialize(&cur_session, m_uri.getURLString().c_str()); if ( ret != LDAP_SUCCESS ) { @@ -277,6 +284,7 @@ void LDAPAsynConnection::unbind(){ void LDAPAsynConnection::setConstraints(LDAPConstraints *cons){ DEBUG(LDAP_DEBUG_TRACE,"LDAPAsynConnection::setConstraints()" << endl); + delete m_constr; m_constr=cons; } -- 1.8.3.4 (Apple Git-47)

1 0

Re: (ITS#7805) fatal region error detected; run recovery
by quanah＠zimbra.com 26 Feb '14

26 Feb '14

--On Wednesday, February 26, 2014 10:17 AM +0000 venkatachalam.dk(a)accenture.com wrote: > Full_Name: Venkatachalam > Version: 2.4.3.1 There is no such OpenLDAP release. If you are using the build provided by RHEL, then the correct contact is RedHat. Generally, it is very wise to avoid RH's build of OpenLDAP. --Quanah -- Quanah Gibson-Mount Architect - Server Zimbra, Inc. -------------------- Zimbra :: the leader in open source messaging and collaboration

1 0

(ITS#7805) fatal region error detected; run recovery
by venkatachalam.dk＠accenture.com 26 Feb '14

26 Feb '14

Full_Name: Venkatachalam Version: 2.4.3.1 OS: RHEL URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (144.36.234.91) Hi, We have recently migrated open ldap 2.4.3.1 , after migration ,we are getting below error in ldap log file and need to restart the ldap service to function again. It happens every twice or thrice in a day . Need to solution on this . fd=12 ACCEPT from IP=192.x.x.x:407xx (IP=10.x.x.x:7xx1) 530d6be3 conn=1115 op=0 BIND dn="cn=Directory Manager,dc=axacr,dc=com" method=128 530d6be3 conn=1115 op=0 BIND dn="cn=Directory Manager,dc=axacr,dc=com" mech=SIMPLE ssf=0 530d6be3 conn=1115 op=0 RESULT tag=97 err=0 text= 530d6be3 conn=1115 op=1 SRCH base="uid=052248084077000,l=hk,c=hk,ou=people,dc=axacr,dc=com" scope=2 deref=3 filter="(objectClass=*)" 530d6be3 conn=1115 op=1 SRCH attr=1.1 530d6be3 bdb(dc=axacr,dc=com): PANIC: fatal region error detected; run recovery 530d6be3 bdb(dc=axacr,dc=com): PANIC: fatal region error detected; run recovery 530d6be3 bdb(dc=axacr,dc=com): PANIC: fatal region error detected; run recovery 530d6be3 bdb(dc=axacr,dc=com): PANIC: fatal region error detected; run recovery 530d6be3 conn=1115 op=1 SEARCH RESULT tag=101 err=80 nentries=0 text=internal error Thanks Venkat

1 0

(ITS#7803) slapd.ldif refers to non-existent man page slapd.d(5)
by webadmin＠caotus.ru 26 Feb '14

26 Feb '14

Full_Name: Vasiliy Version: openldap-2.4.39 OS: GNU/Linux URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (91.215.36.84) Originally (reason of report) seen in OpenLDAP 2.4.35, prompted in OpenLDAP 2.4.39 (file openldap-2.4.39/servers/slapd/slapd.ldif). # head -n 2 openldap-2.4.39/servers/slapd/slapd.ldif | tail -n 1 # See slapd.d(5) for details on configuration options. But the correct name of manual page is slapd-config(5), there is no manual page slapd.d(5). Header of servers/slapd/slapd.ldif file should be fixed.

1 0

Re: (ITS#7802) Global overlays are unusable with cn=config
by quanah＠zimbra.com 20 Feb '14

20 Feb '14

--On Friday, February 21, 2014 1:22 AM +0000 quanah(a)OpenLDAP.org wrote: > Full_Name: Quanah Gibson-Mount > Version: 2.4.39 > OS: Linux 3.11 > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (75.111.58.125) steps to reproduce: [zimbra@fishfood ~]$ ldapmodify -x -H ldapi:/// -D cn=config -w zimbra123 dn: cn=module{0}, cn=config changetype: modify add: olcModuleLoad olcModuleLoad: {7}pw-sha2.la [zimbra@fishfood config]$ ldapmodify -x -H ldapi:/// -D cn=config -w zimbra123 dn: cn=config changetype: modify add: olcPasswordHash olcPasswordHash: {SSHA512} --Quanah -- Quanah Gibson-Mount Architect - Server Zimbra, Inc. -------------------- Zimbra :: the leader in open source messaging and collaboration

1 0

(ITS#7802) Global overlays are unusable with cn=config
by quanah＠OpenLDAP.org 20 Feb '14

20 Feb '14

Full_Name: Quanah Gibson-Mount Version: 2.4.39 OS: Linux 3.11 URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (75.111.58.125) Global overlays (such as pw-sha2 from contrib) are unusable with cn=config. This is because the module is loaded after the bootstrap of cn=config.ldif. I.e., add the module as loaded: olcModuleLoad: {7}pw-sha2.la to dn: cn=module{0}, cn=config In cn=config.ldif, set: olcPasswordHash: {SSHA512} As long as slapd is not restarted, this works, because the module gets loaded, and then the password hash gets set with the module loaded. If you stop slapd and restart it, slapd will fail to load because it is loading cn=config.ldif with the olcPasswordHash set to something it doesn't recognize because it has not yet loaded the modules: 5306a920 >>> dnPrettyNormal: <cn=config> => ldap_bv2dn(cn=config,0) <= ldap_bv2dn(cn=config)=0 => ldap_dn2bv(272) <= ldap_dn2bv(cn=config)=0 => ldap_dn2bv(272) <= ldap_dn2bv(cn=config)=0 5306a920 <<< dnPrettyNormal: <cn=config>, <cn=config> 5306a920 >>> dnNormalize: <cn=config> => ldap_bv2dn(cn=config,0) <= ldap_bv2dn(cn=config)=0 => ldap_dn2bv(272) <= ldap_dn2bv(cn=config)=0 5306a920 <<< dnNormalize: <cn=config> 5306a920 >>> dnNormalize: <cn=config> => ldap_bv2dn(cn=config,0) <= ldap_bv2dn(cn=config)=0 => ldap_dn2bv(272) <= ldap_dn2bv(cn=config)=0 5306a920 <<< dnNormalize: <cn=config> 5306a920 <= str2entry(cn=config) -> 0x1dd8008 5306a920 => test_filter 5306a920 PRESENT 5306a920 => access_allowed: search access to "cn=config" "objectClass" requested 5306a920 <= root access granted 5306a920 => access_allowed: search access granted by manage(=mwrscxd) 5306a920 <= test_filter 6 5306a920 olcPasswordHash: value #0: <olcPasswordHash> scheme not available ({SSHA512}) 5306a920 olcPasswordHash: value #0: <olcPasswordHash> no valid hashes found 5306a920 config error processing cn=config: <olcPasswordHash> no valid hashes found 5306a920 send_ldap_result: conn=-1 op=0 p=0 5306a920 send_ldap_result: err=80 matched="" text="" 5306a920 slapd destroy: freeing system resources. 5306a920 slapd stopped. 5306a920 connections_destroy: nothing to destroy.

1 0

(ITS#7801) test033-glue-syncrepl with bdb/hdb gets stuck on ppc64
by jsynacek＠redhat.com 17 Feb '14

17 Feb '14

Full_Name: Jan Synacek Version: 2.4.39 OS: GNU/Linux URL: Submission from: (NULL) (209.132.186.34) I configured openldap with --enable-bdb, --enable-hdb and --enable-mdb. No other options were used. Reproduced on a ppc64 system with kernel 3.10.0. # ./run -b hdb test033-glue-syncrepl Cleaning up test run directory leftover from previous run. Running ./scripts/test033-glue-syncrepl for hdb... running defines.sh Running slapadd to build glued slapd databases... Starting slapd 1 on TCP/IP port 9011... Using ldapsearch to check that slapd 1 is running... Starting slapd 2 on TCP/IP port 9012... Using ldapsearch to check that slapd 2 is running... Using ldapadd to populate subtree="ou=Information Technology Division,ou=People,dc=example,dc=com" on port 9011... Using ldapadd to populate subtree="ou=Groups,dc=example,dc=com" on port 9012... After that, there is no output. # ps afx ... 25204 pts/0 S+ 0:00 | \_ /bin/sh ./run -b hdb test033-glue-syncrepl 25221 pts/0 S+ 0:00 | \_ /bin/sh ./scripts/test033-glue-syncrepl 25241 pts/0 Sl+ 0:00 | \_ /root/openldap-2.4.39/tests/../servers/slapd/slapd -s0 -f /root/openldap-2.4.39/tests/testrun/slapd.1.conf -h ldap://localhost:9011/ -d 0x4105 25247 pts/0 Sl+ 8:48 | \_ /root/openldap-2.4.39/tests/../servers/slapd/slapd -s0 -f /root/openldap-2.4.39/tests/testrun/slapd.2.conf -h ldap://localhost:9012/ -d 0x4105 25254 pts/0 S+ 0:00 | \_ ../clients/tools/ldapmodify -a -P 3 -x -D cn=Manager 2,dc=example,dc=com -w -h localhost -p 9012 -f ./testdata/test-ordered.ldif -c ... 25131 pts/0 Sl 9:36 /root/openldap-2.4.39/tests/../servers/slapd/slapd -s0 -f /root/openldap-2.4.39/tests/testrun/slapd.2.conf -h ldap://localhost:9012/ -d 0x4105 ...

1 0

Re: (ITS#7800) slapd with back-mdb segfaults periodically
by hyc＠symas.com 13 Feb '14

13 Feb '14

openldap(a)semyon.org wrote: > Full_Name: Semyon Chaichenets > Version: 2.4.38 > OS: Linux --- 3.2.0-58-generic #88-Ubuntu SMP Tue Dec 3 17:37:58 UTC 2013 x86_64 > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (142.244.152.148) > > > We had slapd crash four times in the past 2 weeks, on two separate nodes. > I cannot provide core dumps for confidentiality reasons, but hopefully you will > find the following information helpful: Upgrade to 2.4.39. -- -- Howard Chu CTO, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc/ Chief Architect, OpenLDAP http://www.openldap.org/project/

1 0

(ITS#7800) slapd with back-mdb segfaults periodically
by openldap＠semyon.org 13 Feb '14

13 Feb '14

Full_Name: Semyon Chaichenets Version: 2.4.38 OS: Linux --- 3.2.0-58-generic #88-Ubuntu SMP Tue Dec 3 17:37:58 UTC 2013 x86_64 URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (142.244.152.148) We had slapd crash four times in the past 2 weeks, on two separate nodes. Each time, the last instruction executed was back-mdb/dn2id.c:738, and each time, it was called from back-mdb/search.c:747. In every case, the cause appears to be an infinite loop: the stack is very deep - in once instance, we had 2492641 frames in the back-trace; while the function calls are oscillating between two addresses. Both nodes in question had their database initialized from scratch by syncrepl. I cannot provide core dumps for confidentiality reasons, but hopefully you will find the following information helpful: # ldd `which slapd` linux-vdso.so.1 => (0x00007fff673ff000) libldap_r-2.4.so.2 => /usr/lib/x86_64-linux-gnu/libldap_r-2.4.so.2 (0x00007f56feb1a000) liblber-2.4.so.2 => /usr/lib/x86_64-linux-gnu/liblber-2.4.so.2 (0x00007f56fe90c000) libuuid.so.1 => /lib/x86_64-linux-gnu/libuuid.so.1 (0x00007f56fe706000) libslp.so.1 => /usr/lib/libslp.so.1 (0x00007f56fe4f5000) libsasl2.so.2 => /usr/lib/x86_64-linux-gnu/libsasl2.so.2 (0x00007f56fe2da000) libcrypt.so.1 => /lib/x86_64-linux-gnu/libcrypt.so.1 (0x00007f56fe0a0000) libslapi-2.4.so.2 => /usr/lib/x86_64-linux-gnu/libslapi-2.4.so.2 (0x00007f56fde82000) libltdl.so.7 => /usr/lib/x86_64-linux-gnu/libltdl.so.7 (0x00007f56fdc78000) libwrap.so.0 => /lib/x86_64-linux-gnu/libwrap.so.0 (0x00007f56fda6e000) libpthread.so.0 => /lib/x86_64-linux-gnu/libpthread.so.0 (0x00007f56fd851000) libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 (0x00007f56fd491000) libresolv.so.2 => /lib/x86_64-linux-gnu/libresolv.so.2 (0x00007f56fd274000) libssl.so.1.0.0 => /lib/x86_64-linux-gnu/libssl.so.1.0.0 (0x00007f56fd016000) libcrypto.so.1.0.0 => /lib/x86_64-linux-gnu/libcrypto.so.1.0.0 (0x00007f56fcc3b000) /lib64/ld-linux-x86-64.so.2 (0x00007f56ff0f6000) libnsl.so.1 => /lib/x86_64-linux-gnu/libnsl.so.1 (0x00007f56fca20000) libdl.so.2 => /lib/x86_64-linux-gnu/libdl.so.2 (0x00007f56fc81c000) libz.so.1 => /lib/x86_64-linux-gnu/libz.so.1 (0x00007f56fc604000) === node 1, crash on 2014-02-07 === GNU gdb (Ubuntu/Linaro 7.4-2012.04-0ubuntu2.1) 7.4-2012.04 [..] Reading symbols from /usr/sbin/slapd...done. warning: exec file is newer than core file. [New LWP 6117] [New LWP 16603] [New LWP 6106] [New LWP 6116] [New LWP 16602] [New LWP 6115] [New LWP 6114] [New LWP 6113] [New LWP 16604] [New LWP 6112] [..] Core was generated by `/usr/sbin/slapd -u openldap -g openldap -h ldap://127.0.0.1 ldap://-------'. Program terminated with signal 11, Segmentation fault. #0 0x00007fe30c4818b1 in mdb_idscopes (op=0x7fe0d8000c30, isc=0x7fe0f94e9670) at ../../../../../servers/slapd/back-mdb/dn2id.c:738 warning: Source file is more recent than executable. 738 isc->nrdns[isc->numrdns].bv_len = nrlen; (gdb) info locals mdb = <optimized out> dbi = <optimized out> key = {mv_size = 8, mv_data = 0x7fe0f9369588} data = {mv_size = 38, mv_data = 0x7fe11e1e9df4} id = 315367 id2 = {mid = 315054, mval = {mv_size = 34, mv_data = 0x7fe19e83f5e6}} ptr = <optimized out> rc = 1 x = <optimized out> nrlen = 13 rlen = 13 d = 0x7fe11e1e9df4 (gdb) info registers rax 0xd 13 rbx 0x7fe0f94e9670 140604232078960 rcx 0x130c990 19974544 rdx 0x7fe11e1e9df4 140604849692148 rsi 0x7fe0fa7fe000 140604252086272 rdi 0x7fe108147010 140604479926288 rbp 0x7fe0f9369588 0x7fe0f9369588 rsp 0x7fe0f9369540 0x7fe0f9369540 r8 0x26 38 r9 0x130c97 1248407 r10 0xd 13 r11 0x7fe11e1e9df6 140604849692150 r12 0x7fe0d8000c30 140603673283632 r13 0x1 1 r14 0x7fe0ec1029c0 140604009884096 r15 0x7fe0f94f98b0 140604232145072 rip 0x7fe30c4818b1 0x7fe30c4818b1 <mdb_idscopes+177> eflags 0x10206 [ PF IF RF ] cs 0x33 51 ss 0x2b 43 ds 0x0 0 es 0x0 0 fs 0x0 0 gs 0x0 0 (gdb) info locals scopeok = 0 edata = {mv_size = 13, mv_data = 0x7fe11e1e9e04} mdb = <optimized out> id = 1437644 cursor = 140604849692164 nsubs = 13 ncand = 1036510 cscope = 0 lastid = 140604849692164 candidates = {18446744073709551615, 1, 18446744073709551615, 208401, 208402, 270076, 292060, 528090, 528091, 528092, 528093, 528094, 528095, 528096, 528097, 528098, 528099, 617378, 687228, 1448040, 1448041, 524157, 524158, 524159, 574368, 656851, 810235, 864549, 84040, 84041, 94183, 94184, 118570, 132095, 132096, 132097, 132098, 132099, 132100, 132101, 132102, 132103, 132104, 132105, 132106, 132107, 142374, 142375, 149621, 150352, 175234, 175235, 175236, 175237, 175238, 175239, 175240, 175241, 175242, 175243, 175244, 175245, 175246, 185347, 185348, 205311, 236539, 242770, 242771, 242772, 242773, 242774, 242775, 242776, 242777, 242778, 242779, 242780, 242781, 242782, 253264, 253265, 282749, 308079, 308080, 308081, 308082, 308083, 308084, 308085, 308086, 308087, 308088, 308089, 308090, 308091, 318449, 318450, 404268, 404269, 620845, 665852, 665853, 665854, 665855, 665856, 665857, 665858, 665859, 665860, 665861, 665862, 665863, 665864, 677595, 677596, 836477, 1279141, 1287440, 1287441, 1287442, 1287443, 1287444, 1287445, 1287446, 1287447, 1287448, 1287449, 1287450, 1287451, 1294713, 1294714, 1303316, 1303317, 1303318, 1303319, 1303320, 1303321, 1303322, 1303323, 1303324, 1303325, 1303326, 1303327, 1310725, 1310726, 1319676, 1319677, 1319678, 1319679, 1319680, 1319681, 1319682, 1319683, 1319684, 1319685, 1319686, 1319687, 1327161, 1327162, 1336551, 1336552, 1336553, 1336554, 1336555, 1336556, 1336557, 1336558, 1336559, 1336560, 1336561, 1336562, 1343735, 1353674, 1353675, 1353676, 1353677, 1353678, 1353679, 1353680, 1353681, 1353682, 1353683, 1353684, 1353685, 1360913, 1371324, 1371325, 1371326, 1371327, 1371328, 1371329, 1371330, 1371331, 1371332, 1371333, 1371334, 1371335, 1378691, 1388937...} iscopes = {0 <repeats 65502 times>, 140604009884096, 140604010617776, 635087, 140604479926288, 4294967298, 2, 12, 140606314528669, 9, 140606770728942, 12, 140604966947099, 9, 140606770728942, 14, 140606644291055, 24, 140606471143055, 14, 140606533666287, 14, 140606572504559, 0 <repeats 12 times>} scopes = 0x7fe108147010 e = 0xd base = 0x7fe11e1e9e04 matched = 0xd attrs = <optimized out> mask = <optimized out> stoptime = 1391778836 manageDSAit = <optimized out> isc = {mt = 0x7fe0ec1029c0, mc = 0x7fe0ec1db620, id = 1437644, scopes = 0x7fe108147010, numrdns = 1248406, nscope = 0, oscope = 2, rdns = {{bv_len = 14, bv_val = 0x7fe1115e75a1 <Address 0x7fe1115e75a1 out of bounds>}, {bv_len = 11, bv_val = 0x7fe11e1e98d2 <Address 0x7fe11e1e98d2 out of bounds>}, {bv_len = 13, bv_val = 0x7fe11e1e9e04 <Address 0x7fe11e1e9e04 out of bounds>} <repeats 2046 times>}, nrdns = {{bv_len = 13, bv_val = 0x7fe11e1e9e04 <Address 0x7fe11e1e9e04 out of bounds>} <repeats 2048 times>}} mci = 0xd mcd = 0x7fe11e1e9e04 opinfo = {moi_oe = {oe_next = {sle_next = 0xd}, oe_key = 0x7fe11e1e9e04}, moi_txn = 0xd, moi_ref = 505323012, moi_flag = -31 '\341'} moi = 0xd ltid = <optimized out> (gdb) info registers rax 0xd 13 rbx 0x7fe0d8000c30 140603673283632 rcx 0x130c990 19974544 rdx 0x7fe11e1e9df4 140604849692148 rsi 0x7fe0fa7fe000 140604252086272 rdi 0x7fe108147010 140604479926288 rbp 0x7fe0f94faa00 0x7fe0f94faa00 rsp 0x7fe0f93695c0 0x7fe0f93695c0 r8 0x26 38 r9 0x130c97 1248407 r10 0xd 13 r11 0x7fe11e1e9df6 140604849692150 r12 0x7fe0f94e96d0 140604232079056 r13 0x7fe0f94f96d0 140604232144592 r14 0x7fe0ec1029c0 140604009884096 r15 0x7fe0f94f98b0 140604232145072 rip 0x7fe30c47ab9b 0x7fe30c47ab9b <mdb_search+7451> eflags 0x10206 [ PF IF RF ] cs 0x33 51 ss 0x2b 43 ds 0x0 0 es 0x0 0 fs 0x0 0 gs 0x0 0 (gdb) bt #0 0x00007fe30c4818b1 in mdb_idscopes (op=0x7fe0d8000c30, isc=0x7fe0f94e9670) at ../../../../../servers/slapd/back-mdb/dn2id.c:738 #1 0x00007fe30c47ab9b in mdb_search (op=0x7fe0d8000c30, rs=0x7fe0f94faa00) at ../../../../../servers/slapd/back-mdb/search.c:747 #2 0x00007fe11e1e9e04 in ?? () #3 0x000000000000000d in ?? () #4 0x00007fe11e1e9e04 in ?? () #5 0x000000000000000d in ?? () [..] #2492634 0x00007fe11e1e9df6 in ?? () #2492635 0x000000000000000d in ?? () #2492636 0x00007fe11e1e9df6 in ?? () #2492637 0x000000000000000d in ?? () #2492638 0x00007fe11e1e9df6 in ?? () #2492639 0x000000000000000d in ?? () #2492640 0x00007fe11e1e9df6 in ?? () #2492641 0x0000000000000000 in ?? ()

1 0

Re: (ITS#7797) crash with slapo-collect with existing attribute
by danno＠umich.edu 07 Feb '14

07 Feb '14

Requested stacktrace is below. [root@cnsutil0 yum.repos.d]# gdb /pub/src/openldap-2.4.39/servers/slapd/slapd GNU gdb (GDB) Red Hat Enterprise Linux (7.2-60.el6_4.1) Copyright (C) 2010 Free Software Foundation, Inc. License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html> This is free software: you are free to change and redistribute it. There is NO WARRANTY, to the extent permitted by law. Type "show copying" and "show warranty" for details. This GDB was configured as "x86_64-redhat-linux-gnu". For bug reporting instructions, please see: <http://www.gnu.org/software/gdb/bugs/>... Reading symbols from /pub/src/openldap-2.4.39/servers/slapd/slapd...done. (gdb) run -d 0 -h ldaps:/// -u ldap -f /usr/local/pkg/openldap-2.4.39/etc/openldap/slapd-bugreport.conf -n slapd-bugreport Starting program: /pub/src/openldap-2.4.39/servers/slapd/slapd -d 0 -h ldaps:/// -u ldap -f /usr/local/pkg/openldap-2.4.39/etc/openldap/slapd-bugreport.conf -n slapd-bugreport [Thread debugging using libthread_db enabled] [New Thread 0x7ffff549d700 (LWP 13453)] [New Thread 0x7ffff4c9c700 (LWP 13455)] [New Thread 0x7fffeffff700 (LWP 13456)] slapd: attr.c:484: attr_merge: Assertion `( nvals == ((void *)0) && (*a)->a_nvals == (*a)->a_vals ) || ( nvals != ((void *)0) && ( ( (*a)->a_vals == ((void *)0) && (*a)->a_nvals == ((void *)0) ) || ( (*a)->a_nvals != (*a)->a_vals ) ) )' failed. Program received signal SIGABRT, Aborted. [Switching to Thread 0x7ffff4c9c700 (LWP 13455)] 0x00007ffff6c85925 in raise (sig=6) at ../nptl/sysdeps/unix/sysv/linux/raise.c:64 64 return INLINE_SYSCALL (tgkill, 3, pid, selftid, sig); (gdb) bt full #0 0x00007ffff6c85925 in raise (sig=6) at ../nptl/sysdeps/unix/sysv/linux/raise.c:64 resultvar = 0 pid = <value optimized out> selftid = 13455 #1 0x00007ffff6c87105 in abort () at abort.c:92 save_stage = 2 act = {__sigaction_handler = {sa_handler = 0x5a73c0, sa_sigaction = 0x5a73c0}, sa_mask = {__val = {140737334912189, 140737298668624, 9945192, 140737298668864, 140737333925142, 206158430232, 140737298668880, 140737298668656, 140737333831240, 206158430256, 140737298668912, 140737085704496, 140737085702200, 0, 8529643138936561962, 140737488349297}}, sa_flags = -153449043, sa_restorer = 0x6144cc} sigs = {__val = {32, 0 <repeats 15 times>}} #2 0x00007ffff6c7ea4e in __assert_fail_base (fmt=<value optimized out>, assertion=0x5a73c0 "( nvals == ((void *)0) && (*a)->a_nvals == (*a)->a_vals ) || ( nvals != ((void *)0) && ( ( (*a)->a_vals == ((void *)0) && (*a)->a_nvals == ((void *)0) ) || ( (*a)->a_nvals != (*a)->a_vals ) ) )", file=0x6144cc "attr.c", line=<value optimized out>, function=<value optimized out>) at assert.c:96 str = 0x7fffe8000930 "`\n" total = 4096 #3 0x00007ffff6c7eb10 in __assert_fail ( assertion=0x5a73c0 "( nvals == ((void *)0) && (*a)->a_nvals == (*a)->a_vals ) || ( nvals != ((void *)0) && ( ( (*a)->a_vals == ((void *)0) && (*a)->a_nvals == ((void *)0) ) || ( (*a)->a_nvals != (*a)->a_vals ) ) )", file=0x6144cc "attr.c", line=484, function=0x5a74a9 "attr_merge") at assert.c:105 No locals. #4 0x0000000000429b22 in attr_merge (e=<value optimized out>, desc=<value optimized out>, vals=0x7fffe8015010, nvals=0x0) at attr.c:481 i = 0 a = 0xc11ca8 __PRETTY_FUNCTION__ = "attr_merge" #5 0x0000000000528a9d in collect_response (op=0x7fffe8013b40, rs=0x7ffff4c9b950) at collect.c:404 vals = 0x7fffe8015010 idx = <value optimized out> on = 0x97c680 ci = 0x97c060 #6 0x0000000000484488 in over_back_response (op=0x7fffe8013b40, rs=0x7ffff4c9b950) at backover.c:237 oi = <value optimized out> on = 0x97c680 rc = 32768 be = 0x7ffff4c9a6b0 db = {bd_info = 0x97c4a0, bd_self = 0x97a850, be_ctrls = "\000\000\000\001\001\001\000\001\000\000\001\000\000\001\001\000\001", '\000' <repeats 15 times>, "\001", be_flags = 2312, be_restrictops = 0, be_requires = 0, be_ssf_set = {sss_ssf = 0, sss_transport = 0, sss_tls = 0, sss_sasl = 0, sss_update_ssf = 0, sss_update_transport = 0, sss_update_tls = 0, sss_update_sasl = 0, sss_simple_bind = 0}, be_suffix = 0x942590, be_nsuffix = 0x97af80, be_schemadn = {bv_len = 0, bv_val = 0x0}, be_schemandn = {bv_len = 0, bv_val = 0x0}, be_rootdn = {bv_len = 44, bv_val = 0x97c300 "cn=Manager,dc=adsroot,dc=itd,dc=umich,dc=edu"}, be_rootndn = {bv_len = 44, bv_val = 0x97c360 "cn=manager,dc=adsroot,dc=itd,dc=umich,dc=edu"}, be_rootpw = {bv_len = 38, bv_val = 0x97b200 "{SSHA}RRCj1QvzdwlpWoZPapidy4XLgWUlS+m1"}, be_max_deref_depth = 15, be_def_limit = {lms_t_soft = 3600, lms_t_hard = 0, lms_s_soft = 500, lms_s_hard = 0, lms_s_unchecked = -1, lms_s_pr = 0, lms_s_pr_hide = 0, lms_s_pr_total = 0}, be_limits = 0x0, be_acl = 0x97c180, be_dfltaccess = ACL_READ, be_extra_anlist = 0x0, be_update_ndn = {bv_len = 0, bv_val = 0x0}, be_update_refs = 0x0, be_pending_csn_list = 0xbd9390, be_pcl_mutex = {__data = {__lock = 0, __count = 0, __owner = 0, __nusers = 0, __kind = 0, __spins = 0, __list = {__prev = 0x0, __next = 0x0}}, __size = '\000' <repeats 39 times>, __align = 0}, be_syncinfo = 0x0, be_pb = 0x0, be_cf_ocs = 0x84b340, be_private = 0x97a9f0, be_next = {stqe_next = 0x0}} #7 0x000000000042fa8e in slap_response_play (op=0x7fffe8013b40, rs=0x7ffff4c9b950) at result.c:491 sc_next = 0x0 sc_nextp = 0x7ffff4c9a840 rc = 32768 sc = 0x7ffff4c9a840 scp = 0x7ffff4b1a028 #8 0x0000000000431fb8 in slap_send_search_entry (op=0x7fffe8013b40, rs=0x7ffff4c9b950) at result.c:995 berbuf = { buffer = "Р\261\364\377\177\000\000\020\023\001\350\377\177\000\000\020\027\301\000\000\000\000\000\243\000\000\000\000\000\000\000\006", '\000' <repeats 23 times>"\250, M\001\350\377\177\000\000@\241\261\364\377\177\000\000\t", '\000' <repeats 20 times>, "\001\000\000@;\001\350\377\177\000\000\324e\365R\006\000\000\000\270ؿ\000\000\000\000\000\240M\001\350\377\177\000\000\360\251\227", '\000' <repeats 21 times>"\360, \251\227\000\000\000\000\000\330M\001\350\377\177\000\000P\271\311\364\377\177\000\000@;\001\350\377\177\000\000\270ؿ\000\000\000\000\000\005\000\000\000\000\000\000\000r\344C", '\000' <repeats 13 times>, "\005", '\000' <repeats 38 times>, ialign = -189685552, lalign = 140737298669776, falign = -1.12585231e+32, dalign = 6.9533464361235288e-310, palign = 0x7ffff4b1a0d0 "\020\027\301"} ber = 0x7ffff4b1a0c0 a = <value optimized out> i = <value optimized out> j = <value optimized out> rc = 0 ---Type <return> to continue, or q <return> to quit--- bytes = <value optimized out> userattrs = <value optimized out> acl_state = {as_desc = 0x0, as_access = ACL_NONE, as_vd_acl = 0x0, as_vd_acl_present = 0, as_vd_acl_count = 0, as_vd_mask = 1, as_result = -1, as_fe_done = 0} attrsonly = <value optimized out> ad_entry = 0x923790 e_flags = 0x0 #9 0x0000000000497160 in bdb_search (op=0x7fffe8013b40, rs=0x7ffff4c9b950) at search.c:1014 bois = {boi_oe = {oe_next = {sle_next = 0x0}, oe_key = 0x97a9f0}, boi_txn = 0x0, boi_locks = 0x0, boi_err = 0, boi_acl_cache = 0 '\000', boi_flag = 1 '\001'} blis = {bli_next = 0x0, bli_lock = {off = 0, ndx = 295, gen = 13, mode = DB_LOCK_READ}, bli_id = 5, bli_flag = 0} scopeok = <value optimized out> bdb = <value optimized out> id = 5 cursor = 1 lastid = 18446744073709551615 candidates = {1, 5, 3, 4, 5, 6, 0 <repeats 131066 times>} scopes = {0 <repeats 64944 times>, 140737085708896, 140737300240256, 6, 140737300240272, 140737334911689, 140737333785703, 140737334911690, 1, 1, 0, 0, 0, 0, 0, 140737300239984, 0, 140737334911686, 0, 0, 0, 140737300240092, 140737300240120, 0, 140737300240152, 0, 0, 0, 140737333983582, 140737085708896, 140737300240480, 4294967295, 140737300240752, 5943820, 140737333785703, 23, 0, 0, 140737300239944, 0, 32, 0, 0, 17638794651555069952, 42949675439, 13446, 0, 140737300239939, 0, 0, 140737300239939, 0, 140737300239944, 100, 0, 140737334911687, 0, 0, 47244640256, 0 <repeats 24 times>, 5943843, 0, 0, 47244640256, 0 <repeats 85 times>, 140737334182606, 0, 0, 140737300240085, 0, 0, 2, 140737300240512, 25769803776, 4106852054, 0, 3905804171320334016, 140737300240086, 140737337225952, 140737300240479, 9405680, 140737300240000, 206158430224, 140737300240496, 140737300240304, 0, 0, 0, 0, 0, 0, 0, 0, 0, 61787399520256, 0, 0, 140737334911683, 140737085709516, 140737085709516, 140737337227968, 7, 8187, 140737334178082, 8192, 140733193388032, 140737300240389, 140733193388032, 4106852357, 4294967297, 206158430224, 140737300240976, 140737300240784, 140737085709488, 85, 140737085702176, 8208, 140737085717696, 8208, 140737334012430, 140737300240304, 8180, 140737085702176, 140737085709504, 69, 140737085709488, 80, 140737334013397, 140737337241216, 90, 1, 3892320864, 140733193388056, 140737300240512, 140737300240432, 3892320864, 24, 140737300240544, 140737300240464, 140737085708896, 11275264, 4294967295, 11, 18446744073709551528, 2050, 16, 1, 5886190, 4294967324, 140737019656096, 16, 5886457, 0, 18446744073709533616, 9405680, 0, 0, 0, 0, 0, 0, 0, 0, 0, 140737085709504, 0, 0, 68, 140737085709504, 1391814088, 0, 140737085782848, 12572856...} e = 0xbfd8b8 base = {e_id = 2, e_name = {bv_len = 8589934592, bv_val = 0x0}, e_nname = {bv_len = 42, bv_val = 0x7fffe80055c0 "ou=umich,dc=adsroot,dc=itd,dc=umich,dc=edu"}, e_attrs = 0x0, e_ocflags = 0, e_bv = {bv_len = 0, bv_val = 0x0}, e_private = 0x7fffe4103230} e_root = <value optimized out> matched = 0x0 ei = 0x7fffe8004350 attrs = <value optimized out> realbase = {bv_len = 42, bv_val = 0x7fffe80055c0 "ou=umich,dc=adsroot,dc=itd,dc=umich,dc=edu"} mask = <value optimized out> stoptime = 1391817700 manageDSAit = <value optimized out> tentries = 1 nentries = 1 idflag = 0 lock = {off = 317176, ndx = 295, gen = 13, mode = DB_LOCK_READ} opinfo = <value optimized out> ltid = 0x7fffe8013f00 oex = <value optimized out> #10 0x0000000000484797 in overlay_op_walk (op=0x7fffe8013b40, rs=0x7ffff4c9b950, which=op_search, oi=0x97c4a0, on=0x0) at backover.c:671 func = <value optimized out> rc = 32768 #11 0x0000000000485177 in over_op_func (op=0x7fffe8013b40, rs=<value optimized out>, which=<value optimized out>) at backover.c:723 oi = <value optimized out> on = <value optimized out> be = 0x97a850 db = {bd_info = 0x846a80, bd_self = 0x97a850, be_ctrls = "\000\000\000\001\001\001\000\001\000\000\001\000\000\001\001\000\001", '\000' <repeats 15 times>, "\001", be_flags = 2312, be_restrictops = 0, be_requires = 0, be_ssf_set = {sss_ssf = 0, sss_transport = 0, sss_tls = 0, sss_sasl = 0, sss_update_ssf = 0, sss_update_transport = 0, sss_update_tls = 0, sss_update_sasl = 0, sss_simple_bind = 0}, be_suffix = 0x942590, be_nsuffix = 0x97af80, be_schemadn = {bv_len = 0, bv_val = 0x0}, be_schemandn = {bv_len = 0, bv_val = 0x0}, be_rootdn = {bv_len = 44, bv_val = 0x97c300 "cn=Manager,dc=adsroot,dc=itd,dc=umich,dc=edu"}, be_rootndn = {bv_len = 44, bv_val = 0x97c360 "cn=manager,dc=adsroot,dc=itd,dc=umich,dc=edu"}, be_rootpw = {bv_len = 38, bv_val = 0x97b200 "{SSHA}RRCj1QvzdwlpWoZPapidy4XLgWUlS+m1"}, be_max_deref_depth = 15, be_def_limit = {lms_t_soft = 3600, lms_t_hard = 0, lms_s_soft = 500, lms_s_hard = 0, lms_s_unchecked = -1, lms_s_pr = 0, lms_s_pr_hide = 0, lms_s_pr_total = 0}, be_limits = 0x0, be_acl = 0x97c180, be_dfltaccess = ACL_READ, be_extra_anlist = 0x0, be_update_ndn = {bv_len = 0, bv_val = 0x0}, be_update_refs = 0x0, ---Type <return> to continue, or q <return> to quit--- be_pending_csn_list = 0xbd9390, be_pcl_mutex = {__data = {__lock = 0, __count = 0, __owner = 0, __nusers = 0, __kind = 0, __spins = 0, __list = {__prev = 0x0, __next = 0x0}}, __size = '\000' <repeats 39 times>, __align = 0}, be_syncinfo = 0x0, be_pb = 0x0, be_cf_ocs = 0x84b340, be_private = 0x97a9f0, be_next = {stqe_next = 0x0}} cb = {sc_next = 0x0, sc_response = 0x484420 <over_back_response>, sc_cleanup = 0, sc_private = 0x97c4a0} sc = <value optimized out> rc = 32768 __PRETTY_FUNCTION__ = "over_op_func" #12 0x0000000000422981 in fe_op_search (op=0x7fffe8013b40, rs=0x7ffff4c9b950) at search.c:402 bd = 0x853ac0 #13 0x00000000004231ac in do_search (op=0x7fffe8013b40, rs=0x7ffff4c9b950) at search.c:247 base = {bv_len = 42, bv_val = 0x7fffe80123c8 "ou=UMICH,dc=adsroot,dc=itd,dc=umich,dc=edu"} siz = 9 off = 0 i = <value optimized out> #14 0x00000000004207c9 in connection_operation (ctx=0x7ffff4c9bab0, arg_v=0x7fffe8013b40) at connection.c:1155 rc = 80 cancel = <value optimized out> op = 0x7fffe8013b40 rs = {sr_type = REP_SEARCH, sr_tag = 0, sr_msgid = 0, sr_err = 0, sr_matched = 0x0, sr_text = 0x0, sr_ref = 0x0, sr_ctrls = 0x0, sr_un = { sru_search = {r_entry = 0xbfd958, r_attr_flags = 17, r_operational_attrs = 0x0, r_attrs = 0x7fffe8014e10, r_nentries = 0, r_v2ref = 0x0}, sru_sasl = {r_sasldata = 0xbfd958}, sru_extended = {r_rspoid = 0xbfd958 "\005", r_rspdata = 0x11}}, sr_flags = 3} tag = 99 opidx = SLAP_OP_SEARCH conn = 0xac0c00 memctx = 0x7fffe8013a20 memctx_null = 0x0 memsiz = 1048576 __PRETTY_FUNCTION__ = "connection_operation" #15 0x0000000000420fe5 in connection_read_thread (ctx=0x7ffff4c9bab0, argv=<value optimized out>) at connection.c:1291 rc = <value optimized out> cri = {op = 0x7fffe8013b40, func = 0, arg = 0x0, ctx = 0x7ffff4c9bab0, nullop = <value optimized out>} s = <value optimized out> #16 0x0000000000572810 in ldap_int_thread_pool_wrapper (xpool=0x928330) at tpool.c:688 pool = 0x928330 task = 0x7ffff0000a20 work_list = <value optimized out> ctx = {ltu_id = 140737300252416, ltu_key = {{ltk_key = 0x41f4d0, ltk_data = 0x7fffe8013910, ltk_free = 0x41f5a0 <conn_counter_destroy>}, { ltk_key = 0x470780, ltk_data = 0x7fffe8013a20, ltk_free = 0x4707a0 <slap_sl_mem_destroy>}, {ltk_key = 0x433880, ltk_data = 0x0, ltk_free = 0x433660 <slap_op_q_destroy>}, {ltk_key = 0xbd93b0, ltk_data = 0x7fffe8013f00, ltk_free = 0x4d6d00 <bdb_reader_free>}, { ltk_key = 0x4950d0, ltk_data = 0x7fffee7fe010, ltk_free = 0x4951a0 <search_stack_free>}, {ltk_key = 0x0, ltk_data = 0x0, ltk_free = 0} <repeats 24 times>, {ltk_key = 0x0, ltk_data = 0x7ffff6fef06a, ltk_free = 0}, {ltk_key = 0x0, ltk_data = 0x0, ltk_free = 0}, {ltk_key = 0x0, ltk_data = 0x0, ltk_free = 0}}} kctx = <value optimized out> keyslot = 258 hash = <value optimized out> __PRETTY_FUNCTION__ = "ldap_int_thread_pool_wrapper" #17 0x00007ffff6fee9d1 in start_thread (arg=0x7ffff4c9c700) at pthread_create.c:301 __res = <value optimized out> pd = 0x7ffff4c9c700 now = <value optimized out> unwind_buf = {cancel_jmp_buf = {{jmp_buf = {140737300252416, -8145800067874208241, 140737308634272, 140737300253120, 0, 3, 8145785136454125071, 8145780284905833999}, mask_was_saved = 0}}, priv = {pad = {0x0, 0x0, 0x0, 0x0}, data = {prev = 0x0, cleanup = 0x0, canceltype = 0}}} not_first_call = <value optimized out> pagesize_m1 = <value optimized out> sp = <value optimized out> freesize = <value optimized out> #18 0x00007ffff6d3bb6d in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:115 No locals.

1 0

Re: (ITS#7799) Crash in servers/slapd/backover.c / Solaris
by hyc＠symas.com 07 Feb '14

07 Feb '14

marty(a)maui.co.uk wrote: > Full_Name: Marty Lee > Version: 2.4.39 > OS: Solaris 10 / 11 > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (81.149.129.52) > > > With a global overlay set, slapd is crashing in servers/slapd/backover.c at line > 703, with a SEGV. > > Seems someone else has seen the same issue and put an asset in there: > Maybe I've missed something that says global overlays are bad; but if so, then > I'd expect slapd to complain about it in the messages.... Global overlays are generally a bad idea. They were not part of the original overlay design, they were added ad hoc and require explicit support in the overlay code. Most overlays have not been written to support global use. In fact only two overlays even mention support for global use in their manpage; you should assume none of the others do. -- -- Howard Chu CTO, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc/ Chief Architect, OpenLDAP http://www.openldap.org/project/

1 0

(ITS#7799) Crash in servers/slapd/backover.c / Solaris
by marty＠maui.co.uk 07 Feb '14

07 Feb '14

Full_Name: Marty Lee Version: 2.4.39 OS: Solaris 10 / 11 URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (81.149.129.52) With a global overlay set, slapd is crashing in servers/slapd/backover.c at line 703, with a SEGV. Seems someone else has seen the same issue and put an asset in there: (703) BackendDB *be = op->o_bd, db; slap_callback cb = {NULL, over_back_response, NULL, NULL}, **sc; int rc = SLAP_CB_CONTINUE; /* FIXME: used to happen for instance during abandon * when global overlays are used... */ assert( op->o_bd != NULL ); However, the assert is after the first use of op->o_bd, so slapd has already crashed! The overlay I was using globally was overlay memberof memberof-refint true After reading the comment above the assert, I checked my config and I am indeed using a global overlay. When I put it into each database block instead, everything works ok. I guess there is a more fundamental issue with global overlays and this assert isn't actually catching the error. I can quickly replicate the problem, so if you need me to look at anything specific, let me know. Maybe I've missed something that says global overlays are bad; but if so, then I'd expect slapd to complain about it in the messages....

1 0

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

openldap-bugs