- openldap-bugs - openldap.org

Re: (ITS#6262) Wrap gmtime(3) for re-entrancy
by masarati＠aero.polimi.it 18 Aug '09

18 Aug '09

Just to clarify: there is NO re-entrancy issue. This is essentially about code re-factoring. p.

1 0

Re: (ITS#6262) Wrap gmtime(3) for re-entrancy
by masarati＠aero.polimi.it 18 Aug '09

18 Aug '09

> Open issues: > > - check for re-entrancy of the WIN32 version of lutil_gettime() > > - allow apps to use gmtime(3)/localtime(3) in re-entrant manner when the > _r > replacements are not available (the mutex is no longer exposed) - add function checks to configure. p.

1 0

(ITS#6262) Wrap gmtime(3) for re-entrancy
by masarati＠aero.polimi.it 18 Aug '09

18 Aug '09

Full_Name: Pierangelo Masarati Version: HEAD OS: irrelevant URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (93.149.38.235) Submitted by: ando gmtime(3)/gmtime_r(3), localtime(3)/localtime_r(3) can be wrapped in a single place, getting rid of lots of #defines and so. A patch is ready that either provides a re-entrant wrapper or defines the re-entrant functions as macros. Open issues: - check for re-entrancy of the WIN32 version of lutil_gettime() - allow apps to use gmtime(3)/localtime(3) in re-entrant manner when the _r replacements are not available (the mutex is no longer exposed) p.

1 0

Re: (ITS#6257) libldap: getopt flag to return the SASL username
by masarati＠aero.polimi.it 18 Aug '09

18 Aug '09

> masarati(a)aero.polimi.it wrote: >>> libldap should be capable of returning SASL username obtained with >>> sasl_getprop( sasl_context, SASL_USERNAME, ... ) as result of >>> ldap_get_option() >> >> Added to HEAD (LDAP_OPT_X_SASL_USERNAME); please test. Thanks, p. > > Does it simply return a string like LDAP_OPT_URI, > LDAP_OPT_X_TLS_CACERTFILE etc.? It returns whatever returned by sasl_getprop(); it should be a pointer to a zero-terminated string within the SASL context (you don't have to free it, but it may be invalidated when the context is destroyed). See ITS#6260 about documenting the behavior with these options :) Note that SASL documentation is itself relatively poor in this area. I could infer the above from code samples 'round, for which is which. p.

1 0

Re: (ITS#6257) libldap: getopt flag to return the SASL username
by michael＠stroeder.com 18 Aug '09

18 Aug '09

masarati(a)aero.polimi.it wrote: >> libldap should be capable of returning SASL username obtained with >> sasl_getprop( sasl_context, SASL_USERNAME, ... ) as result of >> ldap_get_option() > > Added to HEAD (LDAP_OPT_X_SASL_USERNAME); please test. Thanks, p. Does it simply return a string like LDAP_OPT_URI, LDAP_OPT_X_TLS_CACERTFILE etc.? Ciao, Michael.

1 0

Re: (ITS#6200)
by masarati＠aero.polimi.it 18 Aug '09

18 Aug '09

> Sorry about the stripped trace. I forgot that the install procedure > always strips the binaries... > > Okay, with our stress profile it takes ~36 hours to fail. I always > start with a clean db rebuild before each run. Each failure produces > the same traceback: > > (gdb) where > #0 0x00b97410 in __kernel_vsyscall () > #1 0x00471d80 in raise () from /lib/libc.so.6 > #2 0x00473691 in abort () from /lib/libc.so.6 > #3 0x0046b1fb in __assert_fail () from /lib/libc.so.6 > #4 0x0808d532 in ch_malloc (size=4436335) at ch_malloc.c:57 ^^^ this really looks like memory exhaustion while trying to malloc a large chunk (>4MB). Can you tell, by printing e->e_name, whether it's correct that the server was modifying a large entry? p. > #5 0x08079ad2 in entry_encode (e=0x3a3dac0, bv=0x3a3d9b0) at entry.c:742 > #6 0x0815240e in bdb_id2entry_put (be=0x3a3dca0, tid=0xbc6f7378, > e=0x3a3dac0, flag=0) at id2entry.c:54 > #7 0x08152508 in hdb_id2entry_update (be=0x3a3dca0, tid=0xbc6f7378, > e=0x3a3dac0) at id2entry.c:90 > #8 0x08106374 in hdb_modify (op=0xdabbc28, rs=0x3a3f0e4) at modify.c:611 > #9 0x080ea38e in overlay_op_walk (op=0xdabbc28, rs=0x3a3f0e4, > which=op_modify, oi=0x8be2788, on=0x0) at backover.c:669 > #10 0x080ea543 in over_op_func (op=0xdabbc28, rs=0x3a3f0e4, > which=op_modify) at backover.c:721 > #11 0x080ea60b in over_op_modify (op=0xdabbc28, rs=0x3a3f0e4) at > backover.c:755 > #12 0x08089151 in fe_op_modify (op=0xdabbc28, rs=0x3a3f0e4) at > modify.c:301 > #13 0x08088b90 in do_modify (op=0xdabbc28, rs=0x3a3f0e4) at modify.c:175 > #14 0x0806be8f in connection_operation (ctx=0x3a3f1d0, arg_v=0xdabbc28) at > connection.c:1115 > #15 0x0806c3cf in connection_read_thread (ctx=0x3a3f1d0, argv=0x1a) at > connection.c:1251 > #16 0x081d8fa9 in ldap_int_thread_pool_wrapper (xpool=0x8b941b0) at > tpool.c:685 > #17 0x0043749b in start_thread () from /lib/libpthread.so.0 > #18 0x0051a42e in clone () from /lib/libc.so.6

1 0

Re: (ITS#6200)
by imf＠u.washington.edu 18 Aug '09

18 Aug '09

Sorry about the stripped trace. I forgot that the install procedure always strips the binaries... Okay, with our stress profile it takes ~36 hours to fail. I always start with a clean db rebuild before each run. Each failure produces the same traceback: (gdb) where #0 0x00b97410 in __kernel_vsyscall () #1 0x00471d80 in raise () from /lib/libc.so.6 #2 0x00473691 in abort () from /lib/libc.so.6 #3 0x0046b1fb in __assert_fail () from /lib/libc.so.6 #4 0x0808d532 in ch_malloc (size=4436335) at ch_malloc.c:57 #5 0x08079ad2 in entry_encode (e=0x3a3dac0, bv=0x3a3d9b0) at entry.c:742 #6 0x0815240e in bdb_id2entry_put (be=0x3a3dca0, tid=0xbc6f7378, e=0x3a3dac0, flag=0) at id2entry.c:54 #7 0x08152508 in hdb_id2entry_update (be=0x3a3dca0, tid=0xbc6f7378, e=0x3a3dac0) at id2entry.c:90 #8 0x08106374 in hdb_modify (op=0xdabbc28, rs=0x3a3f0e4) at modify.c:611 #9 0x080ea38e in overlay_op_walk (op=0xdabbc28, rs=0x3a3f0e4, which=op_modify, oi=0x8be2788, on=0x0) at backover.c:669 #10 0x080ea543 in over_op_func (op=0xdabbc28, rs=0x3a3f0e4, which=op_modify) at backover.c:721 #11 0x080ea60b in over_op_modify (op=0xdabbc28, rs=0x3a3f0e4) at backover.c:755 #12 0x08089151 in fe_op_modify (op=0xdabbc28, rs=0x3a3f0e4) at modify.c:301 #13 0x08088b90 in do_modify (op=0xdabbc28, rs=0x3a3f0e4) at modify.c:175 #14 0x0806be8f in connection_operation (ctx=0x3a3f1d0, arg_v=0xdabbc28) at connection.c:1115 #15 0x0806c3cf in connection_read_thread (ctx=0x3a3f1d0, argv=0x1a) at connection.c:1251 #16 0x081d8fa9 in ldap_int_thread_pool_wrapper (xpool=0x8b941b0) at tpool.c:685 #17 0x0043749b in start_thread () from /lib/libpthread.so.0 #18 0x0051a42e in clone () from /lib/libc.so.6 --- Tracy Stenvik University Computing Services 354843. University of Washington email: imf(a)u.washington.edu voice: (206) 685-3344 On Thu, 23 Jul 2009, Howard Chu wrote: > imf(a)u.washington.edu wrote: >> The changes made to 2.4.17 seem to have fixed the crashes in the caching >> module. Thanks for that. >> >> We still are able to crash 2.4.17, however. It only happens after a heavy >> load is placed on the producer for>24 hours continuous. Unfortunately, >> we've not been able to get good tracebacks. They all look like this, >> >> (gdb) where >> #0 0x00869410 in __kernel_vsyscall () >> #1 0x00390d80 in raise () from /lib/libc.so.6 >> #2 0x00392691 in abort () from /lib/libc.so.6 >> #3 0x0038a1fb in __assert_fail () from /lib/libc.so.6 >> #4 0x0808d532 in malloc () >> #5 0x0822c93f in ?? () >> #6 0x0822c933 in ?? () >> #7 0x00000039 in ?? () >> #8 0x0822c908 in ?? () >> #9 0x00000000 in ?? () >> >> The producer slowly grows its memory footprint. I can't tell if it's from >> just normal operations or memory leaks. I suspect it's a little of both. >> The end result, as you can see from the core above, is that there's likely >> some corrupted (or unfreed) memory somewhere. Sorry I can't nail it down >> further. > > There's not enough information here. > > An assert is always accompanied by an error message on stderr; we need to see > the actual error message. > > There are no symbols in the stack trace pertaining to slapd itself. You seem > to be running a stripped binary. Please provide a trace using a non-stripped > binary that was compiled with -g (debug symbols enabled). >> >> The load profile that we placed on the server is documented in my prior >> report. See above. > > > -- > -- 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#6194) Patch - Enhancement - provide LDIF support as libldif
by michael＠stroeder.com 18 Aug '09

18 Aug '09

rmeggins(a)redhat.com wrote: > One thing that a general purpose LDIF parser needs is support for change > records - for example, the ability to read in a changetype: modify and > parse the changes into an LDAPMod ** or something like that. There's > already code in ldapmodify to do this, it would need to be refactored > into libldif. There are not only add/modify operations possible in a LDIF file. Personally I'm banging my head about adding full support for change records in python-ldap's LDIF parser. At the end one would have to trigger all LDAP operations including processing of LDAPv3 extended controls. So I guess for a C API this would mean a call-back interface full-featured like libldap itself. (So the next question would be whether to stick with this LDAP C API...) Ciao, Michael.

1 0

Re: (ITS#6261) Misparsing when commas present in LDAP URL DNs
by hyc＠symas.com 18 Aug '09

18 Aug '09

jwm(a)horde.net wrote: > Full_Name: John Morrissey > Version: RE24 > OS: Linux > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (66.133.190.110) > > > libldap's ldap_url_parselist_int() splits URLs on spaces (" ") and commas > (",") when parsing them. Commas in LDAP URLs do not need to be > percent-encoded (in fact, section 4 of RFC 4516 has a number of examples > with non-encoded commas). > Perhaps this is a documentation bug. In that case, ldap_open(3) should > mention this behavior, especially since it conflicts with RFC 4516. Looks like a doc bug to me. Note that the commandline tools state explicitly: -H ldapuri Specify URI(s) referring to the ldap server(s); a list of URI, separated by whitespace or commas is expected; only the proto‐ col/host/port fields are allowed. The ldap_open(3) manpage should say the same. -- -- 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#6261) Misparsing when commas present in LDAP URL DNs
by jwm＠horde.net 18 Aug '09

18 Aug '09

Full_Name: John Morrissey Version: RE24 OS: Linux URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (66.133.190.110) libldap's ldap_url_parselist_int() splits URLs on spaces (" ") and commas (",") when parsing them. Commas in LDAP URLs do not need to be percent-encoded (in fact, section 4 of RFC 4516 has a number of examples with non-encoded commas). This causes failure in situations like passing a full URL to ldap_initialize(): ldap_initialize("ldap://localhost/dc=example,dc=com"); Breakpoint 1, ldap_url_parselist_int (ludlist=0x7fff99b56470, url=0x400d10 "ldap://localhost:390/dc=example,dc=com", sep=0x0, flags=3) at url.c:1284 [...] 1293 urls = ldap_str2charray( url, sep ); (gdb) 1294 if (urls == NULL) (gdb) print urls[0] $1 = 0xb69280 "ldap://localhost:390/dc=example" (gdb) print urls[1] $2 = 0xb691b0 "dc=com" ldap_url_parselist_int calls ldap_url_parse_ext() on urls[1], which returns LDAP_URL_ERR_BADSCHEME. This makes its way back to ldap_initialize()'s caller as LDAP_PARAM_ERROR. The client tools accept comma-separated lists of URLs passed to -H. It seems better to modify ldap_url_parselist{,_int}() to split on spaces and use ldap_url_parselist_ext() to override this behavior where necessary for backwards compatibility (such as in client tools). Perhaps this is a documentation bug. In that case, ldap_open(3) should mention this behavior, especially since it conflicts with RFC 4516. >From RFC 4516: -- 2.1. Percent-Encoding A generated LDAP URL MUST consist only of the restricted set of characters included in one of the following three productions defined in [RFC3986]: <reserved> <unreserved> <pct-encoded> Implementations SHOULD accept other valid UTF-8 strings [RFC3629] as input. An octet MUST be encoded using the percent-encoding mechanism described in section 2.1 of [RFC3986] in any of these situations: The octet is not in the reserved set defined in section 2.2 of [RFC3986] or in the unreserved set defined in section 2.3 of [RFC3986]. It is the single Reserved character '?' and occurs inside a <dn>, <filter>, or other element of an LDAP URL. It is a comma character ',' that occurs inside an <exvalue>. Note that before the percent-encoding mechanism is applied, the extensions component of the LDAP URL may contain one or more null (zero) bytes. No other component may. -- And from RFC 2986: -- 2.2. Reserved Characters [...] reserved = gen-delims / sub-delims gen-delims = ":" / "/" / "?" / "#" / "[" / "]" / "@" sub-delims = "!" / "$" / "&" / "'" / "(" / ")" / "*" / "+" / "," / ";" / "=" --

1 0

Re: (ITS#6194) Patch - Enhancement - provide LDIF support as libldif
by rmeggins＠redhat.com 18 Aug '09

18 Aug '09

This is a cryptographically signed message in MIME format. --------------ms040103040408070506080709 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit One thing that a general purpose LDIF parser needs is support for change records - for example, the ability to read in a changetype: modify and parse the changes into an LDAPMod ** or something like that. There's already code in ldapmodify to do this, it would need to be refactored into libldif. Since the library should be able to parse any sort of LDIF, the parse function would have to read in the first couple of lines of each LDIF record to determine if it is a plain entry or a change record. The parser would return a struct with a union for the different sets of parameters. The function that parses the LDIF could take a flag (or bitmask) that specifies which types of records it expects (e.g. the LDIF parser usage in slapadd would want to ignore/error on change records). --------------ms040103040408070506080709 Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIJCzCC AuAwggJJoAMCAQICEBMdRWn5u0DKFxH7Tsz20SAwDQYJKoZIhvcNAQEFBQAwYjELMAkGA1UE BhMCWkExJTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMT I1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5nIENBMB4XDTA4MTIwMzE3Mjk0M1oX DTA5MTIwMzE3Mjk0M1owRTEfMB0GA1UEAxMWVGhhd3RlIEZyZWVtYWlsIE1lbWJlcjEiMCAG CSqGSIb3DQEJARYTcm1lZ2dpbnNAcmVkaGF0LmNvbTCCASIwDQYJKoZIhvcNAQEBBQADggEP ADCCAQoCggEBAMoOfo+aL6KtK5e6tnKn7zhbPm6N1YxeYM5RxJ4v3/winPaNsaYrfcgSKWyy ZH8CLUoKbMndV+/BneBbIFWDNYOZEXs8Yzk0CJtaTchg3sU3yOn7qh38zyzjlSHyXFJyVEJv boTcrdGO2u0WOXj/sH5rIhdguHVcwPUu6ZrTtexqc7887R5SvFRSw3MkKeLWozHB5uQcXZO7 l6LDQU1JQbMAlteZ+fDbEXk8FUclZPg0x/fgIjs+LbPloeUK2qWCk1V85f07C135fzyemy0C MEmkAukakZFgS69Ww1LEPncBfL+5dq9pqHs18QdraT1Vgtzb0tpSPczi9H+/8fTvXwkCAwEA AaMwMC4wHgYDVR0RBBcwFYETcm1lZ2dpbnNAcmVkaGF0LmNvbTAMBgNVHRMBAf8EAjAAMA0G CSqGSIb3DQEBBQUAA4GBADX7xNlAbUAG6FmqnfEpb5ieewb8OwWT1rZ0X7ZfzM9T0UIOUrN3 2kIhYAcsARWjKbedoinPUWj+a5B+gMTKSaweZ4EZV9LZmtAdvFCJSFsop1ytTeMYapgBLZpZ 02mlCGUK66r256wx645OuWP188Xe6Z34vdtjAesb9ctB27VLMIIC4DCCAkmgAwIBAgIQEx1F afm7QMoXEftOzPbRIDANBgkqhkiG9w0BAQUFADBiMQswCQYDVQQGEwJaQTElMCMGA1UEChMc VGhhd3RlIENvbnN1bHRpbmcgKFB0eSkgTHRkLjEsMCoGA1UEAxMjVGhhd3RlIFBlcnNvbmFs IEZyZWVtYWlsIElzc3VpbmcgQ0EwHhcNMDgxMjAzMTcyOTQzWhcNMDkxMjAzMTcyOTQzWjBF MR8wHQYDVQQDExZUaGF3dGUgRnJlZW1haWwgTWVtYmVyMSIwIAYJKoZIhvcNAQkBFhNybWVn Z2luc0ByZWRoYXQuY29tMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAyg5+j5ov oq0rl7q2cqfvOFs+bo3VjF5gzlHEni/f/CKc9o2xpit9yBIpbLJkfwItSgpsyd1X78Gd4Fsg VYM1g5kRezxjOTQIm1pNyGDexTfI6fuqHfzPLOOVIfJcUnJUQm9uhNyt0Y7a7RY5eP+wfmsi F2C4dVzA9S7pmtO17GpzvzztHlK8VFLDcyQp4tajMcHm5Bxdk7uXosNBTUlBswCW15n58NsR eTwVRyVk+DTH9+AiOz4ts+Wh5QrapYKTVXzl/TsLXfl/PJ6bLQIwSaQC6RqRkWBLr1bDUsQ+ dwF8v7l2r2moezXxB2tpPVWC3NvS2lI9zOL0f7/x9O9fCQIDAQABozAwLjAeBgNVHREEFzAV gRNybWVnZ2luc0ByZWRoYXQuY29tMAwGA1UdEwEB/wQCMAAwDQYJKoZIhvcNAQEFBQADgYEA NfvE2UBtQAboWaqd8SlvmJ57Bvw7BZPWtnRftl/Mz1PRQg5Ss3faQiFgBywBFaMpt52iKc9R aP5rkH6AxMpJrB5ngRlX0tma0B28UIlIWyinXK1N4xhqmAEtmlnTaaUIZQrrqvbnrDHrjk65 Y/Xzxd7pnfi922MB6xv1y0HbtUswggM/MIICqKADAgECAgENMA0GCSqGSIb3DQEBBQUAMIHR MQswCQYDVQQGEwJaQTEVMBMGA1UECBMMV2VzdGVybiBDYXBlMRIwEAYDVQQHEwlDYXBlIFRv d24xGjAYBgNVBAoTEVRoYXd0ZSBDb25zdWx0aW5nMSgwJgYDVQQLEx9DZXJ0aWZpY2F0aW9u IFNlcnZpY2VzIERpdmlzaW9uMSQwIgYDVQQDExtUaGF3dGUgUGVyc29uYWwgRnJlZW1haWwg Q0ExKzApBgkqhkiG9w0BCQEWHHBlcnNvbmFsLWZyZWVtYWlsQHRoYXd0ZS5jb20wHhcNMDMw NzE3MDAwMDAwWhcNMTMwNzE2MjM1OTU5WjBiMQswCQYDVQQGEwJaQTElMCMGA1UEChMcVGhh d3RlIENvbnN1bHRpbmcgKFB0eSkgTHRkLjEsMCoGA1UEAxMjVGhhd3RlIFBlcnNvbmFsIEZy ZWVtYWlsIElzc3VpbmcgQ0EwgZ8wDQYJKoZIhvcNAQEBBQADgY0AMIGJAoGBAMSmPFVzVftO ucqZWh5owHUEcJ3f6f+jHuy9zfVb8hp2vX8MOmHyv1HOAdTlUAow1wJjWiyJFXCO3cnwK4Va qj9xVsuvPAsH5/EfkTYkKhPPK9Xzgnc9A74r/rsYPge/QIACZNenprufZdHFKlSFD0gEf6e2 0TxhBEAeZBlyYLf7AgMBAAGjgZQwgZEwEgYDVR0TAQH/BAgwBgEB/wIBADBDBgNVHR8EPDA6 MDigNqA0hjJodHRwOi8vY3JsLnRoYXd0ZS5jb20vVGhhd3RlUGVyc29uYWxGcmVlbWFpbENB LmNybDALBgNVHQ8EBAMCAQYwKQYDVR0RBCIwIKQeMBwxGjAYBgNVBAMTEVByaXZhdGVMYWJl bDItMTM4MA0GCSqGSIb3DQEBBQUAA4GBAEiM0VCD6gsuzA2jZqxnD3+vrL7CF6FDlpSdf0wh uPg2H6otnzYvwPQcUCCTcDz9reFhYsPZOhl+hLGZGwDFGguCdJ4lUJRix9sncVcljd2pnDmO jCBPZV+V2vf3h9bGCE6u9uo05RAaWzVNd+NWIXiC3CEZNd4ksdMdRv9dX2VPMYIDcTCCA20C AQEwdjBiMQswCQYDVQQGEwJaQTElMCMGA1UEChMcVGhhd3RlIENvbnN1bHRpbmcgKFB0eSkg THRkLjEsMCoGA1UEAxMjVGhhd3RlIFBlcnNvbmFsIEZyZWVtYWlsIElzc3VpbmcgQ0ECEBMd RWn5u0DKFxH7Tsz20SAwCQYFKw4DAhoFAKCCAdAwGAYJKoZIhvcNAQkDMQsGCSqGSIb3DQEH ATAcBgkqhkiG9w0BCQUxDxcNMDkwODE4MTcxNzQ5WjAjBgkqhkiG9w0BCQQxFgQUzzoGkS1H KNU2s4j2AyhGil+I2/kwXwYJKoZIhvcNAQkPMVIwUDALBglghkgBZQMEAQIwCgYIKoZIhvcN AwcwDgYIKoZIhvcNAwICAgCAMA0GCCqGSIb3DQMCAgFAMAcGBSsOAwIHMA0GCCqGSIb3DQMC AgEoMIGFBgkrBgEEAYI3EAQxeDB2MGIxCzAJBgNVBAYTAlpBMSUwIwYDVQQKExxUaGF3dGUg Q29uc3VsdGluZyAoUHR5KSBMdGQuMSwwKgYDVQQDEyNUaGF3dGUgUGVyc29uYWwgRnJlZW1h aWwgSXNzdWluZyBDQQIQEx1Fafm7QMoXEftOzPbRIDCBhwYLKoZIhvcNAQkQAgsxeKB2MGIx CzAJBgNVBAYTAlpBMSUwIwYDVQQKExxUaGF3dGUgQ29uc3VsdGluZyAoUHR5KSBMdGQuMSww KgYDVQQDEyNUaGF3dGUgUGVyc29uYWwgRnJlZW1haWwgSXNzdWluZyBDQQIQEx1Fafm7QMoX EftOzPbRIDANBgkqhkiG9w0BAQEFAASCAQBwIGppPuaY7Ou8xa50Lbfui02CjwyRXwZoQskw mBL10x217LurVVMd/lUDafUi1eL1F2BEWapkwmpUCBgIZ5b7OyvQPiupkJkFLcDHwL8PLChp xbNnxjl6bLG1JXmvX96+FiqzS0BeW4xlozkKUcq5sjQX7urtqUfQ+b3YZDEl5Hl9tU8NPBRY R3FPT55LeyqhGk1cfVFso8aIP8CAVhwWmuK1ljm/SukMDNnVllUxOSCJ8uuBBE4fp3H2A9js vsxcGqPQbc9yc7udZxa0nlKA7NtFkSypGqv9V4r6E9lV30K242TdBhC4tazLpH6bgNDpwn6Q x1HbXFdlLiKOVXjHAAAAAAAA --------------ms040103040408070506080709--

1 0

(ITS#6260) ldap_get/set_option() does not document SASL/TLS options
by masarati＠aero.polimi.it 18 Aug '09

18 Aug '09

Full_Name: Pierangelo Masarati Version: HEAD OS: irrelevant URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (93.149.38.235) Submitted by: ando Probably we better expose them in the documentation, although LDAP_OPT_X_*. p.

1 0

Re: (ITS#6257) libldap: getopt flag to return the SASL username
by masarati＠aero.polimi.it 18 Aug '09

18 Aug '09

> libldap should be capable of returning SASL username obtained with > sasl_getprop( sasl_context, SASL_USERNAME, ... ) as result of > ldap_get_option() Added to HEAD (LDAP_OPT_X_SASL_USERNAME); please test. Thanks, p.

1 0

Re: (ITS#6259) test020 core dumps
by masarati＠aero.polimi.it 18 Aug '09

18 Aug '09

Can't reproduce, although I can see memory leaks (in entry duplication). p.

1 0

(ITS#6259) test020 core dumps
by dieter＠dkluenter.de 18 Aug '09

18 Aug '09

Full_Name: Dieter Kluenter Version: HEAD OS: openSUSE-11.1 URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (87.154.40.47) my configure flags CFLAGS="-DLDAP_DEVEL -g -march=athlon64" LIBS="-ltcmalloc" ./configure \ --prefix=${PREFIX} \ --enable-dynamic \ --enable-aci \ --enable-modules \ --enable-rewrite \ --enable-bdb=yes \ --enable-hdb=yes \ --enable-ldap=mod \ --enable-monitor=yes \ --enable-meta=mod \ --enable-perl=mod \ --enable-relay=mod \ --enable-monitor=yes \ --enable-sql=mod \ --enable-overlays=mod make depend && make && cd tests test020 core dumps with Core was generated by `/work/ldap-src/servers/slapd/.libs/lt-slapd -s0 -f /work/ldap-src/tests/testrun'. Program terminated with signal 11, Segmentation fault. backtrace is (gdb) bt #0 free (ptr=0x1100ffffff) at src/tcmalloc.cc:842 #1 0x00007f2479ca1bca in ber_memfree_x (p=0x1100ffffff, ctx=0x0) at memory.c:152 #2 0x00007f24753d03a0 in ?? () from /usr/lib64/libldap-2.4.so.2 #3 0x00007f24753b599f in ?? () from /usr/lib64/libldap-2.4.so.2 #4 0x0000000000af9cc8 in ?? () #5 0x0000000000000000 in ?? () (gdb) frame 1 #1 0x00007f2479ca1bca in ber_memfree_x (p=0x1100ffffff, ctx=0x0) at memory.c:152 152 free( p ); Current language: auto; currently c

1 0

Re: (ITS#6194) Patch - Enhancement - provide LDIF support as libldif
by rmeggins＠redhat.com 18 Aug '09

18 Aug '09

Any ideas about what it would take to make a public LDIF API?

1 0

Re: (ITS#4730) Overlay that generates operational attributes to support GUI interaction
by michael＠stroeder.com 18 Aug '09

18 Aug '09

masarati(a)aero.polimi.it wrote: >> You mean an instance of the allowedAttributesEffective with the empty >> value? I'm not seeing anything like that. > > Actually, I confirm I didn't see anything like that, but there was a bug: > the attribute was being added regardless of having any value, and the > a_numvals field was not being filled in any case. Fixing... Yupp, that seems right now. Ciao, Michael.

1 0

Re: (ITS#4730) Overlay that generates operational attributes to support GUI interaction
by michael＠stroeder.com 18 Aug '09

18 Aug '09

masarati(a)aero.polimi.it wrote: > Michael Ströder wrote: >> There's a special corner-case: >> If the user bound (e.g. anonymous in my test configuration) has no write >> access to any attribute an empty attribute value list is returned for >> 'allowedAttributesEffective'. > > You mean an instance of the allowedAttributesEffective with the empty > value? Yes. Here's the python-ldap trace log: Note the 'allowedAttributesEffective': [] in the result. I can also enable OpenLDAP debugging log if that would be more evidence for you. ---------------------------- snip ---------------------------- *** ldap://localhost:2071 - LDAPObject.search_ext (('ou=schulung,dc=stroeder,dc=local', 0, '(objectClass=*)', ['hasSubordinates', 'entryCSN', 'tokenGroupsGlobalAndUniversal', 'localEntryID', 'createTimestamp', 'uSNCreated', 'fromEntry', 'administrativeRole', 'structuralObjectClass', 'mS-DS-CreatorSID', 'msDS-Approx-Immed-Subordinates', 'nsAccountLock', 'authzTo', 'nsLookthroughLimit', 'GUID', 'authzFrom', '*', 'passwordExpWarned', 'whenChanged', 'modifiersName', 'isMemberOf', 'sDRightsEffective', 'governingStructureRule', 'primaryGroupToken', 'pwdPolicySubentry', 'accountUnlockTime', 'passwordHistory', 'subordinateCount', 'allowedAttributesEffective', 'creatorsName', 'entryUUID', 'aclentry', 'uSNChanged', 'tokenGroupsNoGCAcceptable', 'entryDN', 'passwordRetryCount', 'tokenGroups', 'passwordExpirationTime', 'aci', 'passwordAllowChangeTime', 'whenCreated', 'retryCountResetTime', 'canonicalName', 'entryUSN', 'subschemaSubentry', 'numSubordinates', 'modifyTimestamp'], 0, [], None, 300, 0),{}) => result: 13 *** ldap://localhost:2071 - LDAPObject.result3 ((13, 1, 300),{}) => result: (101, [('ou=schulung,dc=stroeder,dc=local', {'hasSubordinates': ['TRUE'], 'entryCSN': ['20090818120115.850129Z#000000#000#000000'], 'objectClass': ['organizationalUnit'], 'creatorsName': ['uid=diradm,ou=schulung,dc=stroeder,dc=local'], 'entryUUID': ['d0ed3070-150d-4a5a-bec3-5c21e78c31c3'], 'allowedAttributesEffective': [], 'modifiersName': ['uid=diradm,ou=schulung,dc=stroeder,dc=local'], 'createTimestamp': ['20090818120115Z'], 'entryDN': ['ou=schulung,dc=stroeder,dc=local'], 'subschemaSubentry': ['cn=Subschema'], 'structuralObjectClass': ['organizationalUnit'], 'ou': ['schulung'], 'modifyTimestamp': ['20090818120115Z']})], 13, []) ---------------------------- snip ---------------------------- > I'm not seeing anything like that. At which level? >> Indeed this is helpful since my web2ldap can >> then distinguish between this attribute being not available at all or no >> attributes are allowed to be written. But I'm not sure whether that >> complies >> to the LDAP data model. What do you think? > > In any case, I'd consider it an error, which deserves to be fixed. If you fix it with hunking out the empty values list the distinction within web2ldap would be then to look at the schema and decide whether allowedAttributesEffective is available. I can see that attr type description of allowedAttributesEffective is hard-coded in allowed.c so that seems fairly reliable to me. Ciao, Michael.

1 0

Re: (ITS#4730) Overlay that generates operational attributes to support GUI interaction
by masarati＠aero.polimi.it 18 Aug '09

18 Aug '09

> You mean an instance of the allowedAttributesEffective with the empty > value? I'm not seeing anything like that. Actually, I confirm I didn't see anything like that, but there was a bug: the attribute was being added regardless of having any value, and the a_numvals field was not being filled in any case. Fixing... p.

1 0

Re: (ITS#4730) Overlay that generates operational attributes to support GUI interaction
by masarati＠aero.polimi.it 18 Aug '09

18 Aug '09

> I've created a simple Makefile derived from the one for slapo-smbk5pwd for > this I'd like to contribute if appropriate. Please review. I grant *all* > rights to the OpenLDAP project. > > Now for the concrete testing: > > In principle it works. That's great! > > There's a special corner-case: > If the user bound (e.g. anonymous in my test configuration) has no write > access to any attribute an empty attribute value list is returned for > 'allowedAttributesEffective'. You mean an instance of the allowedAttributesEffective with the empty value? I'm not seeing anything like that. > Indeed this is helpful since my web2ldap can > then distinguish between this attribute being not available at all or no > attributes are allowed to be written. But I'm not sure whether that > complies > to the LDAP data model. What do you think? In any case, I'd consider it an error, which deserves to be fixed. p.

1 0

Re: (ITS#4730) Overlay that generates operational attributes to support GUI interaction
by michael＠stroeder.com 18 Aug '09

18 Aug '09

This is a multi-part message in MIME format. --------------080500010001090702060704 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit masarati(a)aero.polimi.it wrote: >>> HI! >>> >>> I've added support for 'allowedAttributesEffective' in web2ldap recently >>> which >>> works with AD. I tried this overlay but it seg faults with recent >>> OpenLDAP >>> version. Any chance to get this back on the radar? >> >> I've built and tested my copy of allowed.c with HEAD and re24 and it works >> as expected. However, I might have modified it to keep pace with baseline >> code evolution without resubmitting modifications. > > My version was indeed rather modified, that's why it worked. It's now in > HEAD's contrib/slapd-modules/allowed/. It builds fine with HEAD and re24; > it should also build with OL 2.3, although I haven't checked in a while. > Please test and report. I've created a simple Makefile derived from the one for slapo-smbk5pwd for this I'd like to contribute if appropriate. Please review. I grant *all* rights to the OpenLDAP project. Now for the concrete testing: In principle it works. That's great! There's a special corner-case: If the user bound (e.g. anonymous in my test configuration) has no write access to any attribute an empty attribute value list is returned for 'allowedAttributesEffective'. Indeed this is helpful since my web2ldap can then distinguish between this attribute being not available at all or no attributes are allowed to be written. But I'm not sure whether that complies to the LDAP data model. What do you think? Ciao, Michael. --------------080500010001090702060704 Content-Type: text/plain; name="Makefile" Content-Transfer-Encoding: 7bit Content-Disposition: inline; filename="Makefile" # $OpenLDAP: pkg/ldap/contrib/slapd-modules/allowed/Makefile,v 1.3 2009/08/16 20:55:27 kurt Exp $ # This work is part of OpenLDAP Software <http://www.openldap.org/>. # # Copyright 1998-2009 The OpenLDAP Foundation. # Copyright 2004 Howard Chu, Symas Corp. All Rights Reserved. # # Redistribution and use in source and binary forms, with or without # modification, are permitted only as authorized by the OpenLDAP # Public License. # # A copy of this license is available in the file LICENSE in the # top-level directory of the distribution or, alternatively, at # <http://www.OpenLDAP.org/license.html>. PREFIX=/opt/openldap-HEAD LIBTOOL=../../../libtool OPT=-g -O2 CC=gcc DEFS=-DSLAPD_OVER_ALLOWED=SLAPD_MOD_DYNAMIC LDAP_INC=-I../../../include -I../../../servers/slapd INCS=$(LDAP_INC) LDAP_LIB=-lldap_r -llber -L../../../lib LDAP_LIB= LIBS=$(LDAP_LIB) all: allowed.la allowed.lo: allowed.c $(LIBTOOL) --mode=compile $(CC) $(OPT) $(DEFS) $(INCS) -c $? allowed.la: allowed.lo $(LIBTOOL) --mode=link $(CC) $(OPT) -version-info 0:0:0 \ -rpath $(PREFIX)/lib -module -o $@ $? $(LIBS) clean: rm -f allowed.o allowed.lo allowed.la install: allowed.la mkdir -p $(PREFIX)/libexec/openldap $(LIBTOOL) --mode=install cp allowed.la $(PREFIX)/libexec/openldap $(LIBTOOL) --finish $(PREFIX)/libexec/openldap --------------080500010001090702060704--

1 0

Re: (ITS#4730) Overlay that generates operational attributes to support GUI interaction
by masarati＠aero.polimi.it 17 Aug '09

17 Aug '09

>> HI! >> >> I've added support for 'allowedAttributesEffective' in web2ldap recently >> which >> works with AD. I tried this overlay but it seg faults with recent >> OpenLDAP >> version. Any chance to get this back on the radar? > > Michael, > > I've built and tested my copy of allowed.c with HEAD and re24 and it works > as expected. However, I might have modified it to keep pace with baseline > code evolution without resubmitting modifications. My version was indeed rather modified, that's why it worked. It's now in HEAD's contrib/slapd-modules/allowed/. It builds fine with HEAD and re24; it should also build with OL 2.3, although I haven't checked in a while. Please test and report. p.

1 0

Re: (ITS#5178) [feature request] pcache stats & monitoring
by masarati＠aero.polimi.it 17 Aug '09

17 Aug '09

> This is a feature request for stats and monitoring capabilities for > pcache; > basically: > > - the number of cached queries The number of cachedQueryURL values > - the number of cached entries not available; maybe cachedQueryURL could carry a x-nentries=<num> extension > - possibly, a list of cached queries in cachedQueryURL form ditto > - how many times each cached query was used instead of re-running the > request > - the ratio answerable / cacheable for each cacheable query > - some global figure like the average response time (send searchResult > time - > start caching time) for each query, and the overall average. None of the above is available. The first one is interesting, but it would require query information to survive its life, and match by base/scope/filter rather than by queryUUID. > Adding per-query info could be done by either extending the cachedQueryURL > format or by adding a child entry for each cached query (like connections > and > other dynamic info). This second option does not seem to be viable, although interesting. I fear too much overhead. It's not clear yet how all of this stuff will need to cooperate with the new TTR (and bind caching, when available). p.

1 0

RE: (ITS#6234) CONFIGURABLE TCP BUFFERS IN SLAPD FEATURE REQUEST
by masarati＠aero.polimi.it 17 Aug '09

17 Aug '09

> The traffic model we are testing contains search and modify operations. > The search response contains usually a single entry about 3KB in LDIF > format. There is only a reduce number of LDAP clients (usually one or > two), that are using async LDAP API and sending a lot of operations per > second (> 1000 TPS per client). The client side is an OS Delta box. > > Under these conditions we have tested that increasing the sending buffer > of the server has improved the performance. That's the reason I am > proposing this feature request. > > Pierangelo's proposal allowing hard-set the buffer sizes looks ok. A patch is in HEAD. Please test. It is enabled by default when LDAP_DEVEL is set (namely, when building HEAD). The patch may need some work on architectures different from Linux. p.

1 0

Re: (ITS#6152) proxycache enhancements
by hyc＠symas.com 17 Aug '09

17 Aug '09

Matthew Hardin wrote: > It might be less intrusive codewise and more flexible if we left the > behavior of cache expiration the same and added a parameter to each > template called "Time to Refresh" (TTR). Then you set long or > unlimited cache expirations, which are always in effect, but set a > shorter TTR that would trigger an asynchronous refresh when the TTR > expired. If the db is not available these refreshes will simply fail, > but the data will remain in the cache at least until it's expired by > the usual means. > > This gives the solution designer the option of deciding how long a > system can run disconnected while still being able to separately > determine how stale the contents of the cache will get when connected. > It also means that pcache itself doesn't need to switch modes based on > whether it thinks it's connected to a db or not, and it fact may not > need to even know if it is connected or not. > > There is still room in this design for a flag that controls whether > pcache should behave as if it's disconnected or connected, but I'm not > sure how useful that is given the changes described above. The TTR feature is now available for testing in HEAD. (As well as the offline mode switch.) The TTR behavior is as follows: 1) default is off 2) refreshes are only performed for regular (positive) queries. Negative queries and sizelimit queries are not refreshed. 3) If a query has been referenced in the time since the last refresh, then the expiration time will be extended. So queries that are actively used can stay in the cache indefinitely. 4) If a query has not been referenced, the expiration time will be left unchanged. The query will continue to be refreshed up till its expiration time, at which point it will be removed as normal. A typical configuration for disconnected operation would use TTLs on the order of a few days, with TTR set at whatever refresh interval makes sense. Still need to look at Bind caching. -- -- 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

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

openldap-bugs