openldap-bugs

openldap-bugs@openldap.org

1 participants
20960 discussions

Re: (ITS#4789) can't add BDB database when monitoring
by ando＠sys-net.it 05 Mar '07

05 Mar '07

For the records: I'm sort of working at this. What I'm trying to do is add some specialized calls to monitor_extra_t that allow to register backends, databases, overlays, overlay instances and so. This would allow entity registration/deregistration routines to provide the related monitor entry registration/deregistration as appropriate from within back-config, with all sorts of atomicity issues one can imagine... Cheers, p. Ing. Pierangelo Masarati OpenLDAP Core Team SysNet s.n.c. Via Dossi, 8 - 27100 Pavia - ITALIA http://www.sys-net.it ------------------------------------------ Office: +39.02.23998309 Mobile: +39.333.4963172 Email: pierangelo.masarati(a)sys-net.it ------------------------------------------

1 0

Re: (ITS#4816) slurpd generates invalid ldapadd/modify requests
by gael.roualland＠oleane.net 01 Mar '07

01 Mar '07

This is a multi-part message in MIME format. --------------090002080605050903080106 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit Hello, >> As far as I can see, slurpd merely processes the changes in the replog. If it >> is generating requests out of sequence, then they must have been recorded >> out-of-sequence in the log. And yet I don't see any reason why slapd would >> generate the modifications out of sequence. > > That's right for changetype=modify, since the original code aggregates > multiple values of the same attributes in a signle LDAPmod if they're > given in order in the replog file. > But it doesn't do that for changetype=add, which toggled the bug. I > choosed to use the same code path for both for simplicity when fixing add. > >> What are the circumstances that cause these improper sequences to get into >> the replog in the first place? > > In our case, it was just "add" that was problematic. Although I could > imagine the replog to be generated by something else than slapd, and I'd > expect slurpd to be able to process it as long as it is valid ldif ? The second patch I uploaded has an issue with deleting whole attributes. I have a fixed version of it, but I also wrote another patch to fix the initial issue only on the problematic case (entry adding), so that's a less intrusive change : instead of adding a new LDAPMod for each attribute/value pair, the previous LDAPMod (if any) is reused and the current value added to it if it's for the same attribute. The new patch is attached (no space left on ftp). Would it be possible for such a fix to be in mainline ? Thanks, -- Gaël Roualland -+- gael.roualland(a)oleane.net --------------090002080605050903080106 Content-Type: text/x-patch; name="openldap2.3-slurpd-ldapadd.diff" Content-Transfer-Encoding: 7bit Content-Disposition: inline; filename="openldap2.3-slurpd-ldapadd.diff" --- openldap-2.3.33/servers/slurpd/ldap_op.c.orig 2007-01-25 12:01:46.000000000 +0100 +++ openldap-2.3.33/servers/slurpd/ldap_op.c 2007-03-01 18:05:44.315232000 +0100 @@ -52,7 +52,6 @@ #include "slurp.h" /* Forward references */ -static struct berval **make_singlevalued_berval LDAP_P(( char *, int )); static int op_ldap_add LDAP_P(( Ri *, Re *, char **, int * )); static int op_ldap_modify LDAP_P(( Ri *, Re *, char **, int * )); static int op_ldap_delete LDAP_P(( Ri *, Re *, char **, int * )); @@ -183,28 +182,42 @@ ) { Mi *mi; - int nattrs, rc = 0, i; + int nattrs, nvals, rc = 0, i; LDAPMod *ldm, **ldmarr; int lderr = 0; nattrs = i = 0; ldmarr = NULL; + ldm = NULL; /* * Construct a null-terminated array of LDAPMod structs. */ mi = re->re_mods; while ( mi[ i ].mi_type != NULL ) { - ldm = alloc_ldapmod(); - ldmarr = ( LDAPMod ** ) ch_realloc( ldmarr, - ( nattrs + 2 ) * sizeof( LDAPMod * )); - ldmarr[ nattrs ] = ldm; - ldm->mod_op = LDAP_MOD_BVALUES; - ldm->mod_type = mi[ i ].mi_type; - ldm->mod_bvalues = - make_singlevalued_berval( mi[ i ].mi_val, mi[ i ].mi_len ); + if (ldm == NULL || strcmp(ldm->mod_type, mi[ i ].mi_type) != 0) { + /* not the same attribute, add a new ldm */ + ldm = alloc_ldapmod(); + ldmarr = ( LDAPMod ** ) ch_realloc( ldmarr, + ( nattrs + 2 ) * sizeof( LDAPMod * )); + ldmarr[ nattrs ] = ldm; + nattrs++; + ldm->mod_op = LDAP_MOD_BVALUES; + ldm->mod_type = mi[ i ].mi_type; + nvals = 0; + } + + ldm->mod_bvalues = ( struct berval ** ) + ch_realloc( ldm->mod_bvalues, + ( nvals + 2 ) * sizeof( struct berval * )); + ldm->mod_bvalues[ nvals + 1 ] = NULL; + ldm->mod_bvalues[ nvals ] = ( struct berval * ) + ch_malloc( sizeof( struct berval )); + ldm->mod_bvalues[ nvals ]->bv_val = mi[ i ].mi_val; + ldm->mod_bvalues[ nvals ]->bv_len = mi[ i ].mi_len; + nvals++; + i++; - nattrs++; } if ( ldmarr != NULL ) { @@ -579,25 +592,6 @@ /* - * Create a berval with a single value. - */ -static struct berval ** -make_singlevalued_berval( -char *value, -int len ) -{ - struct berval **p; - - p = ( struct berval ** ) ch_malloc( 2 * sizeof( struct berval * )); - p[ 0 ] = ( struct berval * ) ch_malloc( sizeof( struct berval )); - p[ 1 ] = NULL; - p[ 0 ]->bv_val = value; - p[ 0 ]->bv_len = len; - return( p ); -} - - -/* * Given a modification type (string), return an enumerated type. * Avoids ugly copy in op_ldap_modify - lets us use a switch statement * there. --------------090002080605050903080106--

1 0

Re: ITS#4853
by ando＠sys-net.it 27 Feb '07

27 Feb '07

Richard Bos wrote: > Hello Pierangelo, > > Op dinsdag 27 februari 2007 22:27, schreef u: >> Fixed in re23; please test. >> >> I note that the name of the macro may have tricked you; Debug() is >> actually the logging system of OpenLDAP software, not a mere debug >> statement. > > I assume I may not update the ticket, You should never __assume__, when the system is self-documented: > Replies and Followups > --------------------- > > A reply is a message that has been sent from JitterBug to answer an > incoming message. > > A followup is a reply to a reply. Followups are created when a user > sends a email reply to a JitterBug generated message. Followups are > detected by looking for the PR# automatically added to the subject > line in replies. > hence this email to you: > > What do you mean with fixed in "re23". The code has been fixed in the release engineering branch of 2.3 code, and will thus appear in the next release. > Which release is that exactly? Likely, 2.3.35, if any. > What does the change involve? Look at the code from the CVS. > Is the message now sent to a log file? > < Debug(LDAP_DEBUG_ANY, "%s: line %d: new attribute <%s>\n", >> Debug(LDAP_DEBUG_CONFIG, "%s: line %d: new attribute <%s>\n", It's sent wherever configured, like it was before (see slapd(8) and slapd.conf(5) for details about logging). The difference is that earlier that message was being always issued, while now it's only issued if expressly requested, since it's just informative and not indicative of any bug. The macros seem pretty self-esplicative. I hope that bug didn't cause any harm to your system, though. p. Ing. Pierangelo Masarati OpenLDAP Core Team SysNet s.n.c. Via Dossi, 8 - 27100 Pavia - ITALIA http://www.sys-net.it ------------------------------------------ Office: +39.02.23998309 Mobile: +39.333.4963172 Email: pierangelo.masarati(a)sys-net.it ------------------------------------------

1 0

ITS#4853
by ando＠sys-net.it 27 Feb '07

27 Feb '07

Fixed in re23; please test. I note that the name of the macro may have tricked you; Debug() is actually the logging system of OpenLDAP software, not a mere debug statement. p. Ing. Pierangelo Masarati OpenLDAP Core Team SysNet s.n.c. Via Dossi, 8 - 27100 Pavia - ITALIA http://www.sys-net.it ------------------------------------------ Office: +39.02.23998309 Mobile: +39.333.4963172 Email: pierangelo.masarati(a)sys-net.it ------------------------------------------

1 0

(ITS#4853) A debug message is printed, from the released version
by ml＠radoeka.nl 27 Feb '07

27 Feb '07

Full_Name: Richard Bos Version: 2.3.27 OS: linux URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (80.126.75.243) I just upgraded to the new slapd.conf file from cvs and now when I run slapcat I get the following output: # slapcat >/dev/null /etc/openldap/slapd.conf: line 67: new attribute <member> The config file contains: 63 #### Using overlays to improve data consistency 64 # Ensure that we never get dangling member attributes 65 # Checked on rename and delete 66 overlay refint 67 refint_attributes member 68 The code in servers/slapd/overlays/refint.c reads as follows: if(!strcasecmp(*argv, "refint_attributes")) { for(i = 1; i < argc; i++) { ... some checks for error conditions here but if all is fine we fall through to the following section ... ip = ch_malloc(sizeof(refint_attrs)); ip->attr = ad; ip->next = id->attrs; id->attrs = ip; Debug(LDAP_DEBUG_ANY, "%s: line %d: new attribute <%s>\n", fname, lineno, argv[i]); The final debug message results seems to be the message that is printed. It's my assumption that no debug messages should be printed in a released product/version/project. The initial bug report is located at: https://intevation.de/roundup/kolab/issue1622

1 0

Re: (ITS#4845) Back-perl is non working
by hyc＠symas.com 27 Feb '07

27 Feb '07

kiwi(a)oav.net wrote: >> No surprise that such a careful redesign resulted, as a side >> effect, in a stricter compliance with RFC2589. The fact that >> nobody complained up to now indicates that strict adherence to >> specs usually helps in code portability. > > Yeah. But I didn't know that RFC2589 is used inside back_<whatever>. > Now I am aware of that and I really thanks about your help and your > kindness to take some time to find where my error was. I think he meant RFC2849, which is the LDIF specification. > Maybe a little not in slapd-perl man page that entry sent to openldap > have to conform to RFC2589 should be a point to avoid such loss of time. The slapd-perl(5) man page says that it expects LDIF entries to be returned. As such, it is already a given that they must actually conform to the LDIF spec. > Thanks again, and this bug is closed for me. -- -- Howard Chu Chief Architect, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc Chief Architect, OpenLDAP http://www.openldap.org/project/

1 0

Potential bug (schema or ldap add?)
by Andrew Seguin 27 Feb '07

27 Feb '07

I'm not too sure of the details yet, I wanted to check with this list first, but here's the story. In general, I'm using phpLDAPadmin to work with the ldap directory. I added the iaaa-radius.schema from Interlink. I found it was missing the EQUALITY statements, so phpLDAPadmin couldn't "add" new aaaReply items once the first one was added. Via import and adding a user all at once was not a problem. I modified the iaaa-radius.schema file, found the aaaReply attribute and added the lines "EQUALITY caseIgnoreMatch" and "SUBSTR caseIgnoreSubstringsMatch". I went into phpLDAPadmin, created a new aaaPerson with one initial aaaReply attribute, then added a second aaaReply value without problem. To date all is good. I went to a user which already exists, which already has three aaaReply attributes/values, and tried to add a new aaaReply value - at which point it would seem that slapd either crashed or shutdown. I turned on logging and couldn't see anything really abnormal... nor did I find any core dump file. Any ideas if this is a bug or possibly just some kind of internal consistency check on records created before the Schema was modified? Thank you, Andrew

3 3

Re: (ITS#4845) Back-perl is non working
by kiwi＠oav.net 27 Feb '07

27 Feb '07

--Apple-Mail-13-1003230263 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Hello, >> By the way, I still don't understand why this kind of script was >> working on >> openldap 2.1 and 2.2.... ? >> Does str2entry() is more picky since openldap 2.3 ? > > The fact that something __worked__ doesn't mean it was correct. > That code working was apparently the consequence of two bugs > canceling each other. I totaly agree with you :) > str2entry() is not just more picky: it has been __entirely__ > rewritten, to reduce the performance impact of the related memory > allocation, which guaranteed orders of magnitude of improvement > from 2.0 to 2.3 (the amount of fragmented malloc()s was a > considerable bottleneck). Redesigning code for performance, as well > as for stricter adherence to specs, is part of its natural evolution. Again I agree with you. I am also maintainer of some opensource project and sometimes we need to recode something that is slow to have better performances. > No surprise that such a careful redesign resulted, as a side > effect, in a stricter compliance with RFC2589. The fact that > nobody complained up to now indicates that strict adherence to > specs usually helps in code portability. Yeah. But I didn't know that RFC2589 is used inside back_<whatever>. Now I am aware of that and I really thanks about your help and your kindness to take some time to find where my error was. Maybe a little not in slapd-perl man page that entry sent to openldap have to conform to RFC2589 should be a point to avoid such loss of time. Thanks again, and this bug is closed for me. /Xavier --Apple-Mail-13-1003230263 Content-Transfer-Encoding: base64 Content-Type: application/pkcs7-signature; name=smime.p7s Content-Disposition: attachment; filename=smime.p7s MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIILJjCCAz8w ggKooAMCAQICAQ0wDQYJKoZIhvcNAQEFBQAwgdExCzAJBgNVBAYTAlpBMRUwEwYDVQQIEwxXZXN0 ZXJuIENhcGUxEjAQBgNVBAcTCUNhcGUgVG93bjEaMBgGA1UEChMRVGhhd3RlIENvbnN1bHRpbmcx KDAmBgNVBAsTH0NlcnRpZmljYXRpb24gU2VydmljZXMgRGl2aXNpb24xJDAiBgNVBAMTG1RoYXd0 ZSBQZXJzb25hbCBGcmVlbWFpbCBDQTErMCkGCSqGSIb3DQEJARYccGVyc29uYWwtZnJlZW1haWxA dGhhd3RlLmNvbTAeFw0wMzA3MTcwMDAwMDBaFw0xMzA3MTYyMzU5NTlaMGIxCzAJBgNVBAYTAlpB MSUwIwYDVQQKExxUaGF3dGUgQ29uc3VsdGluZyAoUHR5KSBMdGQuMSwwKgYDVQQDEyNUaGF3dGUg UGVyc29uYWwgRnJlZW1haWwgSXNzdWluZyBDQTCBnzANBgkqhkiG9w0BAQEFAAOBjQAwgYkCgYEA xKY8VXNV+065yplaHmjAdQRwnd/p/6Me7L3N9VvyGna9fww6YfK/Uc4B1OVQCjDXAmNaLIkVcI7d yfArhVqqP3FWy688Cwfn8R+RNiQqE88r1fOCdz0Dviv+uxg+B79AgAJk16emu59l0cUqVIUPSAR/ p7bRPGEEQB5kGXJgt/sCAwEAAaOBlDCBkTASBgNVHRMBAf8ECDAGAQH/AgEAMEMGA1UdHwQ8MDow OKA2oDSGMmh0dHA6Ly9jcmwudGhhd3RlLmNvbS9UaGF3dGVQZXJzb25hbEZyZWVtYWlsQ0EuY3Js MAsGA1UdDwQEAwIBBjApBgNVHREEIjAgpB4wHDEaMBgGA1UEAxMRUHJpdmF0ZUxhYmVsMi0xMzgw DQYJKoZIhvcNAQEFBQADgYEASIzRUIPqCy7MDaNmrGcPf6+svsIXoUOWlJ1/TCG4+DYfqi2fNi/A 9BxQIJNwPP2t4WFiw9k6GX6EsZkbAMUaC4J0niVQlGLH2ydxVyWN3amcOY6MIE9lX5Xa9/eH1sYI Tq726jTlEBpbNU1341YheILcIRk13iSx0x1G/11fZU8wggOVMIIC/qADAgECAgEAMA0GCSqGSIb3 DQEBBAUAMIGUMRowGAYDVQQKExFBc3NvY2lhdGlvbiBLYXphcjEUMBIGA1UECxMLQ0EgRGl2aXNp b24xGzAZBgkqhkiG9w0BCQEWDGtpd2lAb2F2Lm5ldDEOMAwGA1UEBxMFUGFyaXMxDjAMBgNVBAgT BVBhcmlzMQswCQYDVQQGEwJGUjEWMBQGA1UEAxMNS2F6YXIgUm9vdCBDQTAeFw0wMzExMTQxNDEz MjBaFw0xMzExMTExNDEzMjBaMIGUMRowGAYDVQQKExFBc3NvY2lhdGlvbiBLYXphcjEUMBIGA1UE CxMLQ0EgRGl2aXNpb24xGzAZBgkqhkiG9w0BCQEWDGtpd2lAb2F2Lm5ldDEOMAwGA1UEBxMFUGFy aXMxDjAMBgNVBAgTBVBhcmlzMQswCQYDVQQGEwJGUjEWMBQGA1UEAxMNS2F6YXIgUm9vdCBDQTCB nzANBgkqhkiG9w0BAQEFAAOBjQAwgYkCgYEArTJ/TWJb1B9Tgg2Be6BK+KfnNCfyingorlFmQGmN lUvZ+1kK3JSWr7+N4i7oRLRv0htL+oyj7LHoL0OrXhuRdYkG6A3VN73O8Wb+rGI+1Ak2i06TNYRE 7vDtauItxGOwABWgR6Fr+2eItDd8o3+s7H1hwpOZo8zMrVfwyNQOMlcCAwEAAaOB9DCB8TAMBgNV HRMEBTADAQH/MB0GA1UdDgQWBBT7L+QPhVGztBVc65wVFYz95pkTwjCBwQYDVR0jBIG5MIG2gBT7 L+QPhVGztBVc65wVFYz95pkTwqGBmqSBlzCBlDEaMBgGA1UEChMRQXNzb2NpYXRpb24gS2F6YXIx FDASBgNVBAsTC0NBIERpdmlzaW9uMRswGQYJKoZIhvcNAQkBFgxraXdpQG9hdi5uZXQxDjAMBgNV BAcTBVBhcmlzMQ4wDAYDVQQIEwVQYXJpczELMAkGA1UEBhMCRlIxFjAUBgNVBAMTDUthemFyIFJv b3QgQ0GCAQAwDQYJKoZIhvcNAQEEBQADgYEASmOaz1/6V1um4PQSvkEqy5YgWdCoheEIHldkXUk2 Ox9FVDo9tft6S8+phoagZnXyHq6sGISq5ptLNf5BoTJSm4yqPb7W0/IlzCrMoghlYf7DS3RDKiG+ CdTta906lswo04uV8OPYyFjXYFkaxtdlxcXc/vRCdqIvO5QCEyRvGlgwggRGMIIDr6ADAgECAhBf WXY2/Lp97IQmaQuqdQ8+MA0GCSqGSIb3DQEBBQUAMGIxCzAJBgNVBAYTAlpBMSUwIwYDVQQKExxU aGF3dGUgQ29uc3VsdGluZyAoUHR5KSBMdGQuMSwwKgYDVQQDEyNUaGF3dGUgUGVyc29uYWwgRnJl ZW1haWwgSXNzdWluZyBDQTAeFw0wNzAyMDYxNTE2NTRaFw0wODAyMDYxNTE2NTRaMIIBKTEfMB0G A1UEAxMWVGhhd3RlIEZyZWVtYWlsIE1lbWJlcjEbMBkGCSqGSIb3DQEJARYMa2l3aUBvYXYubmV0 MR0wGwYJKoZIhvcNAQkBFg5raXdpQDZtZWF0Lm5ldDEdMBsGCSqGSIb3DQEJARYOa2l3aUBrYXph ci5vcmcxITAfBgkqhkiG9w0BCQEWEmtpd2lAc3VwZXJmbHV4LmJpejEfMB0GCSqGSIb3DQEJARYQ a2l3aUBjYXVkaXVtLm5ldDEfMB0GCSqGSIb3DQEJARYQa2l3aS1tc25Ab2F2Lm5ldDEhMB8GCSqG SIb3DQEJARYScG9zdG1hc3RlckBvYXYubmV0MSMwIQYJKoZIhvcNAQkBFhR4YXZpZXJAYmVhdWRv dWluLm5ldDCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAJdNOyX58MnQHVmyXZAiOkRd niRbx7HUUZg5picgmHOlHlAM8EEcv8tyZfaAxNndt1OtkSDlFrPdeqgbJXW6F/VNksATpxJPAXMc 0hmiiQon5qJvCAtjKTUZHPifNu8IwDHXuuOJm9Xl8dzkmzyy1XkHDnlV2yAPDiuwfV5PjgBcVJQb Pl2jncfQBFoInlfeGdZaChFQKpqIULFUAyuOhpp5vsNQqPAjCfAvGbPKZEIpom1OfBPUshzMB32E eWhG4vF+wKV4F7NlFMsSwAPas9Qil3mvUcwDigei5/nmwvxCsfyQtHCm/A0XcK5//4fKNGeSQK7W 7pkxdUKQFmCJCMsCAwEAAaOBrzCBrDCBmwYDVR0RBIGTMIGQgQxraXdpQG9hdi5uZXSBDmtpd2lA Nm1lYXQubmV0gQ5raXdpQGthemFyLm9yZ4ESa2l3aUBzdXBlcmZsdXguYml6gRBraXdpQGNhdWRp dW0ubmV0gRBraXdpLW1zbkBvYXYubmV0gRJwb3N0bWFzdGVyQG9hdi5uZXSBFHhhdmllckBiZWF1 ZG91aW4ubmV0MAwGA1UdEwEB/wQCMAAwDQYJKoZIhvcNAQEFBQADgYEAA1oQbxpPOZbFEqKS4aph 2LBd+fy6nvBtFFpdgVOx3LZkU3bcXJtk2m6sJPW72sHKpU5m93uQqJCuT6s+sfI062Q3pp27EJjv 0gkIs6OpI36IOKf7zQp7qmN4YANeuE60U4hCrSlXK5uLrPguoBk72PWdPGI8hMOnfJmHa9+0YXIx ggNcMIIDWAIBATB2MGIxCzAJBgNVBAYTAlpBMSUwIwYDVQQKExxUaGF3dGUgQ29uc3VsdGluZyAo UHR5KSBMdGQuMSwwKgYDVQQDEyNUaGF3dGUgUGVyc29uYWwgRnJlZW1haWwgSXNzdWluZyBDQQIQ X1l2Nvy6feyEJmkLqnUPPjAJBgUrDgMCGgUAoIIBuzAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcB MBwGCSqGSIb3DQEJBTEPFw0wNzAyMjcxMzQ1NThaMCMGCSqGSIb3DQEJBDEWBBQ9bmnTVofdoSRh 8583ZE8AFNXOujCBqwYJKwYBBAGCNxAEMYGdMIGaMIGUMRowGAYDVQQKExFBc3NvY2lhdGlvbiBL YXphcjEUMBIGA1UECxMLQ0EgRGl2aXNpb24xGzAZBgkqhkiG9w0BCQEWDGtpd2lAb2F2Lm5ldDEO MAwGA1UEBxMFUGFyaXMxDjAMBgNVBAgTBVBhcmlzMQswCQYDVQQGEwJGUjEWMBQGA1UEAxMNS2F6 YXIgUm9vdCBDQQIBADCBrQYLKoZIhvcNAQkQAgsxgZ2ggZowgZQxGjAYBgNVBAoTEUFzc29jaWF0 aW9uIEthemFyMRQwEgYDVQQLEwtDQSBEaXZpc2lvbjEbMBkGCSqGSIb3DQEJARYMa2l3aUBvYXYu bmV0MQ4wDAYDVQQHEwVQYXJpczEOMAwGA1UECBMFUGFyaXMxCzAJBgNVBAYTAkZSMRYwFAYDVQQD Ew1LYXphciBSb290IENBAgEAMA0GCSqGSIb3DQEBAQUABIIBAB98WnfO9tT2nVJIJ8FVh9+MiP9A 1tC2CirbtmCIgimXAC9A3briBvInedOr85WLpisE2M+VSmownkh9qkVtyIBdPs/M/7qfqvSD3Rlf FkEuIBSGKgU1AcYFmN/XoRTtetDnTgZNDe5aIh6rxd0s1juilxMsJiL4iCSBfk4cGVKpxCXsZlAp 3/QfI3yGscc9sZG2MoROANqAo6JU6vg6D+obhhXfgQqluahRk4LkPdqlgTVuhdaJADGuvQv0y/fY UDEYz3X5w5dDJG/HdECrgzPhRLNygcwUqANuUGXDI5vdrBSsmXOb4raeTfR0FSGjVssdPRMx3Nvc Elughcf1ZlsAAAAAAAA= --Apple-Mail-13-1003230263--

1 0

Re: (ITS#4845) Back-perl is non working
by ando＠sys-net.it 27 Feb '07

27 Feb '07

Xavier Beaudouin wrote: > By the way, I still don't understand why this kind of script was working on > openldap 2.1 and 2.2.... ? > > Does str2entry() is more picky since openldap 2.3 ? The fact that something __worked__ doesn't mean it was correct. That code working was apparently the consequence of two bugs canceling each other. str2entry() is not just more picky: it has been __entirely__ rewritten, to reduce the performance impact of the related memory allocation, which guaranteed orders of magnitude of improvement from 2.0 to 2.3 (the amount of fragmented malloc()s was a considerable bottleneck). Redesigning code for performance, as well as for stricter adherence to specs, is part of its natural evolution. No surprise that such a careful redesign resulted, as a side effect, in a stricter compliance with RFC2589. The fact that nobody complained up to now indicates that strict adherence to specs usually helps in code portability. p. Ing. Pierangelo Masarati OpenLDAP Core Team SysNet s.n.c. Via Dossi, 8 - 27100 Pavia - ITALIA http://www.sys-net.it ------------------------------------------ Office: +39.02.23998309 Mobile: +39.333.4963172 Email: pierangelo.masarati(a)sys-net.it ------------------------------------------

1 0

Re: (ITS#4845) Back-perl is non working
by kiwi＠oav.net 27 Feb '07

27 Feb '07

--Apple-Mail-8-1002308974 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=ISO-8859-1; delsp=yes; format=flowed Hello, Le 26 f=E9vr. 07 =E0 09:35, Pierangelo Masarati a =E9crit : > Xavier Beaudouin wrote: > > >>> Unless you can prove that back-perl LDIF parser doesn't work with >>> decently >>> formatted LDIF, I'll consider this ITS closed. >> >> It *is* buggy proove me the contrary and be not so arrogant. > > OK, I'll be less "arrogant". I've tested back-perl with your script > corrected, and it works exactly as expected both with OpenLDAP 2.3 and > with OpenLDAP 2.4. What are corrections? > > 1) > > <attr>: <value> > > 2) eliminate nonsensical "\t" at end of each line. What is really > offending is the space between "attr" and ":" and the last "\t", while > the other "\t" seem to be tolerated (I suggest to fix str2entry() in > order to detect this malformation as well). > > It took me 5 minutes to rebuild with back-perl and find the error, and > it's the first time in my life that I program perl. Thanks to helped me on that. You can close the bug and sorry to have bother you for such "easy" fix. By the way, I still don't understand why this kind of script was =20 working on openldap 2.1 and 2.2.... ? Does str2entry() is more picky since openldap 2.3 ? /Xavier= --Apple-Mail-8-1002308974 Content-Transfer-Encoding: base64 Content-Type: application/pkcs7-signature; name=smime.p7s Content-Disposition: attachment; filename=smime.p7s MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIILJjCCAz8w ggKooAMCAQICAQ0wDQYJKoZIhvcNAQEFBQAwgdExCzAJBgNVBAYTAlpBMRUwEwYDVQQIEwxXZXN0 ZXJuIENhcGUxEjAQBgNVBAcTCUNhcGUgVG93bjEaMBgGA1UEChMRVGhhd3RlIENvbnN1bHRpbmcx KDAmBgNVBAsTH0NlcnRpZmljYXRpb24gU2VydmljZXMgRGl2aXNpb24xJDAiBgNVBAMTG1RoYXd0 ZSBQZXJzb25hbCBGcmVlbWFpbCBDQTErMCkGCSqGSIb3DQEJARYccGVyc29uYWwtZnJlZW1haWxA dGhhd3RlLmNvbTAeFw0wMzA3MTcwMDAwMDBaFw0xMzA3MTYyMzU5NTlaMGIxCzAJBgNVBAYTAlpB MSUwIwYDVQQKExxUaGF3dGUgQ29uc3VsdGluZyAoUHR5KSBMdGQuMSwwKgYDVQQDEyNUaGF3dGUg UGVyc29uYWwgRnJlZW1haWwgSXNzdWluZyBDQTCBnzANBgkqhkiG9w0BAQEFAAOBjQAwgYkCgYEA xKY8VXNV+065yplaHmjAdQRwnd/p/6Me7L3N9VvyGna9fww6YfK/Uc4B1OVQCjDXAmNaLIkVcI7d yfArhVqqP3FWy688Cwfn8R+RNiQqE88r1fOCdz0Dviv+uxg+B79AgAJk16emu59l0cUqVIUPSAR/ p7bRPGEEQB5kGXJgt/sCAwEAAaOBlDCBkTASBgNVHRMBAf8ECDAGAQH/AgEAMEMGA1UdHwQ8MDow OKA2oDSGMmh0dHA6Ly9jcmwudGhhd3RlLmNvbS9UaGF3dGVQZXJzb25hbEZyZWVtYWlsQ0EuY3Js MAsGA1UdDwQEAwIBBjApBgNVHREEIjAgpB4wHDEaMBgGA1UEAxMRUHJpdmF0ZUxhYmVsMi0xMzgw DQYJKoZIhvcNAQEFBQADgYEASIzRUIPqCy7MDaNmrGcPf6+svsIXoUOWlJ1/TCG4+DYfqi2fNi/A 9BxQIJNwPP2t4WFiw9k6GX6EsZkbAMUaC4J0niVQlGLH2ydxVyWN3amcOY6MIE9lX5Xa9/eH1sYI Tq726jTlEBpbNU1341YheILcIRk13iSx0x1G/11fZU8wggOVMIIC/qADAgECAgEAMA0GCSqGSIb3 DQEBBAUAMIGUMRowGAYDVQQKExFBc3NvY2lhdGlvbiBLYXphcjEUMBIGA1UECxMLQ0EgRGl2aXNp b24xGzAZBgkqhkiG9w0BCQEWDGtpd2lAb2F2Lm5ldDEOMAwGA1UEBxMFUGFyaXMxDjAMBgNVBAgT BVBhcmlzMQswCQYDVQQGEwJGUjEWMBQGA1UEAxMNS2F6YXIgUm9vdCBDQTAeFw0wMzExMTQxNDEz MjBaFw0xMzExMTExNDEzMjBaMIGUMRowGAYDVQQKExFBc3NvY2lhdGlvbiBLYXphcjEUMBIGA1UE CxMLQ0EgRGl2aXNpb24xGzAZBgkqhkiG9w0BCQEWDGtpd2lAb2F2Lm5ldDEOMAwGA1UEBxMFUGFy aXMxDjAMBgNVBAgTBVBhcmlzMQswCQYDVQQGEwJGUjEWMBQGA1UEAxMNS2F6YXIgUm9vdCBDQTCB nzANBgkqhkiG9w0BAQEFAAOBjQAwgYkCgYEArTJ/TWJb1B9Tgg2Be6BK+KfnNCfyingorlFmQGmN lUvZ+1kK3JSWr7+N4i7oRLRv0htL+oyj7LHoL0OrXhuRdYkG6A3VN73O8Wb+rGI+1Ak2i06TNYRE 7vDtauItxGOwABWgR6Fr+2eItDd8o3+s7H1hwpOZo8zMrVfwyNQOMlcCAwEAAaOB9DCB8TAMBgNV HRMEBTADAQH/MB0GA1UdDgQWBBT7L+QPhVGztBVc65wVFYz95pkTwjCBwQYDVR0jBIG5MIG2gBT7 L+QPhVGztBVc65wVFYz95pkTwqGBmqSBlzCBlDEaMBgGA1UEChMRQXNzb2NpYXRpb24gS2F6YXIx FDASBgNVBAsTC0NBIERpdmlzaW9uMRswGQYJKoZIhvcNAQkBFgxraXdpQG9hdi5uZXQxDjAMBgNV BAcTBVBhcmlzMQ4wDAYDVQQIEwVQYXJpczELMAkGA1UEBhMCRlIxFjAUBgNVBAMTDUthemFyIFJv b3QgQ0GCAQAwDQYJKoZIhvcNAQEEBQADgYEASmOaz1/6V1um4PQSvkEqy5YgWdCoheEIHldkXUk2 Ox9FVDo9tft6S8+phoagZnXyHq6sGISq5ptLNf5BoTJSm4yqPb7W0/IlzCrMoghlYf7DS3RDKiG+ CdTta906lswo04uV8OPYyFjXYFkaxtdlxcXc/vRCdqIvO5QCEyRvGlgwggRGMIIDr6ADAgECAhBf WXY2/Lp97IQmaQuqdQ8+MA0GCSqGSIb3DQEBBQUAMGIxCzAJBgNVBAYTAlpBMSUwIwYDVQQKExxU aGF3dGUgQ29uc3VsdGluZyAoUHR5KSBMdGQuMSwwKgYDVQQDEyNUaGF3dGUgUGVyc29uYWwgRnJl ZW1haWwgSXNzdWluZyBDQTAeFw0wNzAyMDYxNTE2NTRaFw0wODAyMDYxNTE2NTRaMIIBKTEfMB0G A1UEAxMWVGhhd3RlIEZyZWVtYWlsIE1lbWJlcjEbMBkGCSqGSIb3DQEJARYMa2l3aUBvYXYubmV0 MR0wGwYJKoZIhvcNAQkBFg5raXdpQDZtZWF0Lm5ldDEdMBsGCSqGSIb3DQEJARYOa2l3aUBrYXph ci5vcmcxITAfBgkqhkiG9w0BCQEWEmtpd2lAc3VwZXJmbHV4LmJpejEfMB0GCSqGSIb3DQEJARYQ a2l3aUBjYXVkaXVtLm5ldDEfMB0GCSqGSIb3DQEJARYQa2l3aS1tc25Ab2F2Lm5ldDEhMB8GCSqG SIb3DQEJARYScG9zdG1hc3RlckBvYXYubmV0MSMwIQYJKoZIhvcNAQkBFhR4YXZpZXJAYmVhdWRv dWluLm5ldDCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAJdNOyX58MnQHVmyXZAiOkRd niRbx7HUUZg5picgmHOlHlAM8EEcv8tyZfaAxNndt1OtkSDlFrPdeqgbJXW6F/VNksATpxJPAXMc 0hmiiQon5qJvCAtjKTUZHPifNu8IwDHXuuOJm9Xl8dzkmzyy1XkHDnlV2yAPDiuwfV5PjgBcVJQb Pl2jncfQBFoInlfeGdZaChFQKpqIULFUAyuOhpp5vsNQqPAjCfAvGbPKZEIpom1OfBPUshzMB32E eWhG4vF+wKV4F7NlFMsSwAPas9Qil3mvUcwDigei5/nmwvxCsfyQtHCm/A0XcK5//4fKNGeSQK7W 7pkxdUKQFmCJCMsCAwEAAaOBrzCBrDCBmwYDVR0RBIGTMIGQgQxraXdpQG9hdi5uZXSBDmtpd2lA Nm1lYXQubmV0gQ5raXdpQGthemFyLm9yZ4ESa2l3aUBzdXBlcmZsdXguYml6gRBraXdpQGNhdWRp dW0ubmV0gRBraXdpLW1zbkBvYXYubmV0gRJwb3N0bWFzdGVyQG9hdi5uZXSBFHhhdmllckBiZWF1 ZG91aW4ubmV0MAwGA1UdEwEB/wQCMAAwDQYJKoZIhvcNAQEFBQADgYEAA1oQbxpPOZbFEqKS4aph 2LBd+fy6nvBtFFpdgVOx3LZkU3bcXJtk2m6sJPW72sHKpU5m93uQqJCuT6s+sfI062Q3pp27EJjv 0gkIs6OpI36IOKf7zQp7qmN4YANeuE60U4hCrSlXK5uLrPguoBk72PWdPGI8hMOnfJmHa9+0YXIx ggNcMIIDWAIBATB2MGIxCzAJBgNVBAYTAlpBMSUwIwYDVQQKExxUaGF3dGUgQ29uc3VsdGluZyAo UHR5KSBMdGQuMSwwKgYDVQQDEyNUaGF3dGUgUGVyc29uYWwgRnJlZW1haWwgSXNzdWluZyBDQQIQ X1l2Nvy6feyEJmkLqnUPPjAJBgUrDgMCGgUAoIIBuzAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcB MBwGCSqGSIb3DQEJBTEPFw0wNzAyMjcxMzMwMzdaMCMGCSqGSIb3DQEJBDEWBBS7xwRCcJciq2f1 0nv+lAcwXB/WaTCBqwYJKwYBBAGCNxAEMYGdMIGaMIGUMRowGAYDVQQKExFBc3NvY2lhdGlvbiBL YXphcjEUMBIGA1UECxMLQ0EgRGl2aXNpb24xGzAZBgkqhkiG9w0BCQEWDGtpd2lAb2F2Lm5ldDEO MAwGA1UEBxMFUGFyaXMxDjAMBgNVBAgTBVBhcmlzMQswCQYDVQQGEwJGUjEWMBQGA1UEAxMNS2F6 YXIgUm9vdCBDQQIBADCBrQYLKoZIhvcNAQkQAgsxgZ2ggZowgZQxGjAYBgNVBAoTEUFzc29jaWF0 aW9uIEthemFyMRQwEgYDVQQLEwtDQSBEaXZpc2lvbjEbMBkGCSqGSIb3DQEJARYMa2l3aUBvYXYu bmV0MQ4wDAYDVQQHEwVQYXJpczEOMAwGA1UECBMFUGFyaXMxCzAJBgNVBAYTAkZSMRYwFAYDVQQD Ew1LYXphciBSb290IENBAgEAMA0GCSqGSIb3DQEBAQUABIIBAECl4VHgzjlhaIgC+ynI6fwsEig0 G2rw/NLSqYGw8cLsMx2iqXSnlQWVV8oLUe5gMGHV0eE65yfKx+vnXTUyJnUN08ECvHx+eM4bxxgV c1cvP6XqqR+nHRUVucriSGrMKqTfI9Qg9DyxPAdF1znIF2TrMwytcVHq+RptaREhEPrpH6+Klnp+ oT9HZwHIRC5tDkZ64uCisHno5QnvwRkT3V2PaSYK5wYtZBHOSchVWWPLeAA9yEzEeMbo07cHWVbj LAxwKoLF+ckJbQRSjWekQ7YwmOkRGVhb4hjtq17b4f6k3Cs3PSOPBOxhktJtinBgU9wSaBYzR5f3 i66IZQDPpkIAAAAAAAA= --Apple-Mail-8-1002308974--

1 0

Jump to page:

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

openldap-bugs