- openldap-bugs - openldap.org

(ITS#4855) slapd crash on exit (tpool)
by gael.roualland＠oleane.net 05 Mar '07

05 Mar '07

Full_Name: Gaël Roualland Version: 2.3.34 OS: Linux URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (213.56.0.199) Hello, Upgrading 2.3.33 to 2.3.34 introduced a bug on slapd stop: the daemon segfaults while waiting for threads to stop. This is reproducible on every run, and without any queries processed. Running under gdb on a test system, the following is reported: slapd starting [New Thread 32769 (LWP 22877)] [New Thread 16386 (LWP 22878)] daemon: added 7r listener=(nil) daemon: added 9r listener=0x813df78 [New Thread 32771 (LWP 22879)] daemon: select: listen=9 active_threads=0 tvp=zero Program received signal SIGTERM, Terminated. [Switching to Thread 16384 (LWP 22876)] 0x40070604 in __pthread_sigsuspend () from /lib/libpthread.so.0 (gdb) n Single stepping until exit from function __pthread_wait_for_restart_signal, which has no line number information. daemon: shutdown requested and initiated. daemon: closing 9 slapd shutdown: waiting for 0 threads to terminate Program received signal SIGSEGV, Segmentation fault. [Switching to Thread 32771 (LWP 22879)] 0x401e1aa0 in __check_rhosts_file () from /lib/libc.so.6 (gdb) bt #0 0x401e1aa0 in __check_rhosts_file () from /lib/libc.so.6 #1 0x080c3c36 in ldap_pvt_thread_pool_context_reset (vctx=0xbf5ff94c) at tpool.c:670 #2 0x080c38df in ldap_int_thread_pool_wrapper (xpool=0x814aa78) at tpool.c:494 #3 0x4006de51 in pthread_start_thread () from /lib/libpthread.so.0 #4 0x4006decf in pthread_start_thread_event () from /lib/libpthread.so.0 #5 0x401908aa in clone () from /lib/libc.so.6 (gdb) info threads * 4 Thread 32771 (LWP 22879) 0x401e1aa0 in __check_rhosts_file () from /lib/libc.so.6 3 Thread 16386 (LWP 22878) 0x40070604 in __pthread_sigsuspend () from /lib/libpthread.so.0 2 Thread 32769 (LWP 22877) 0x40187a5a in poll () from /lib/libc.so.6 1 Thread 16384 (LWP 22876) 0x40070604 in __pthread_sigsuspend () from /lib/libpthread.so.0 Looking at ldap_pvt_thread_pool_context_reset, it seems that the test "if ( ctx[i].ltk_key )" should be reversed as "if ( ctx[i].ltk_key != NULL )". This change fixed the bug. Regards,

1 0

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

04 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

Re: (ITS#4850) back-meta stops returning data
by ulf.moeller＠secardeo.com 27 Feb '07

27 Feb '07

2.3.34 solves the problem. Thanks. -- ____________________________________ Ulf Möller Senior Consultant Secardeo GmbH Office +49 (0)89 - 18 93 589-5 Fax +49 (0)89 - 18 93 589-9 E-mail ulf.moeller(a)secardeo.com Secardeo GmbH Betastrasse 9a D-85774 Unterföhring Web http://www.secardeo.de Geschäftsführer: Dr. Gunnar Jacobson Amtsgericht München HRB 137969 ____________________________________

1 0

Re: (ITS#4685) Updated changelog overlay by Neil Dunbar
by sebastian＠rieger.info 26 Feb '07

26 Feb '07

I placed an updated version in ftp://ftp.openldap.org/incoming/changelog-rieger-070226.c <ftp://ftp.openldap.org/incoming/changelog-rieger-060925.c> that compiles and works with CVS HEAD Sebastian Rieger

1 0

Re: (ITS#4852) back-perl/str2entry odd interaction
by ando＠sys-net.it 26 Feb '07

26 Feb '07

ando(a)sys-net.it wrote: > Malformed perl can cause a double free in str2entry2(). Steps to reproduce: > from back-perl's "search" routine, generate a malformed entry that begins with > "dn : ..." ends with "...\n\t". Fixed in HEAD/re23; please test. 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#4852) back-perl/str2entry odd interaction
by ando＠sys-net.it 26 Feb '07

26 Feb '07

Full_Name: Pierangelo Masarati Version: HEAD/re23 OS: irrelevant URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (81.72.89.40) Submitted by: ando Malformed perl can cause a double free in str2entry2(). Steps to reproduce: from back-perl's "search" routine, generate a malformed entry that begins with "dn : ..." ends with "...\n\t". Backtrace (from HEAD; similar in re23) follows: (gdb) bt #0 0x003957a2 in _dl_sysinfo_int80 () from /lib/ld-linux.so.2 #1 0x003d57a5 in raise () from /lib/tls/libc.so.6 #2 0x003d7209 in abort () from /lib/tls/libc.so.6 #3 0x0040971a in __libc_message () from /lib/tls/libc.so.6 #4 0x0040ffbf in _int_free () from /lib/tls/libc.so.6 #5 0x0041033a in free () from /lib/tls/libc.so.6 #6 0x08226022 in ber_memfree_x (p=0x84e5960, ctx=0x0) at memory.c:149 #7 0x080a11fe in ch_free (ptr=0x84e5960) at ch_malloc.c:139 #8 0x0808d12a in str2entry2 (s=0x0, checkvals=1) at entry.c:374 #9 0x0808c1a0 in str2entry (s=0x84e5838 "dn") at entry.c:100 #10 0x0813c7c8 in perl_back_search (op=0x84e50f8, rs=0xb78f01c8) at search.c:78 #11 0x080846f4 in fe_op_search (op=0x84e50f8, rs=0xb78f01c8) at search.c:374 #12 0x08084078 in do_search (op=0x84e50f8, rs=0xb78f01c8) at search.c:217 #13 0x08081083 in connection_operation (ctx=0xb78f02a4, arg_v=0x84e50f8) at connection.c:1129 #14 0x08081550 in connection_read_thread (ctx=0xb78f02a4, argv=0x9) at connection.c:1257 #15 0x081f38d4 in ldap_int_thread_pool_wrapper (xpool=0x8364c08) at tpool.c:704 #16 0x00692371 in start_thread () from /lib/tls/libpthread.so.0 #17 0x00475ffe in clone () from /lib/tls/libc.so.6

1 0

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

26 Feb '07

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. 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: Antwort: Re: (ITS#4848) Another slapd startup segfault
by ando＠sys-net.it 26 Feb '07

26 Feb '07

Michael.Heep(a)o2.com wrote: > Hello Pierangelo, > >> ando(a)sys-net.it wrote: >> >> The above had nothing to do with your problem. Your problem is related >> to the fact that you intermixed overlay and database configuration >> statements, so the idletimeout statement after the accesslog overlay >> instantiation was causing invalid memory write (beyond the private data >> of the accesslog overlay instead of in the private data of the bdb >> database) resulting in heap corruption. > > You meant the limits option, not the idletimeout, right? Because when I > remove it slapd starts and runs properly. > But now I'm quite lost here. With that statement I intended to disable the > default limits for all users below ou=CNO-LDC when viewing the accesslog > (as it's bound to grow beyond the 500 entries sooner or later). The > manpage lists limits as a general database option, so I assumed placing it > at the end of the accesslog db options would impose these limits on it. > Now where would be the proper placement to achive that? > Under 2.3.33 in my test environment with an accesslog > 500 entries and > the limits directive at just this place in the conf everything worked as > expected. The limits was just a false track. It was idlcachesize to trigger the dangling memory access, but the root cause is the config statement ordering which triggered something much more subtle: basically, if database statements follow overlay instantiation, slapd is fooled into writing to the database (in this case back-bdb) private structure using a pointer to the overlay's (in this case accesslog) structure. This is now fixed in HEAD (thanks to Howard), but backporting to re23 may not be trivial, so please stick with strict ordering of configure statements. 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

Antwort: Re: (ITS#4848) Another slapd startup segfault
by Michael.Heep＠o2.com 26 Feb '07

26 Feb '07

Dies ist eine mehrteilige Nachricht im MIME-Format. --=_alternative 002D0ED3C125728E_= Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: base64 SGVsbG8gUGllcmFuZ2VsbywNCg0KPiBhbmRvQHN5cy1uZXQuaXQgd3JvdGU6DQo+DQo+IFRoZSBh Ym92ZSBoYWQgbm90aGluZyB0byBkbyB3aXRoIHlvdXIgcHJvYmxlbS4gIFlvdXIgcHJvYmxlbSBp cyByZWxhdGVkDQo+IHRvIHRoZSBmYWN0IHRoYXQgeW91IGludGVybWl4ZWQgb3ZlcmxheSBhbmQg ZGF0YWJhc2UgY29uZmlndXJhdGlvbg0KPiBzdGF0ZW1lbnRzLCBzbyB0aGUgaWRsZXRpbWVvdXQg c3RhdGVtZW50IGFmdGVyIHRoZSBhY2Nlc3Nsb2cgb3ZlcmxheQ0KPiBpbnN0YW50aWF0aW9uIHdh cyBjYXVzaW5nIGludmFsaWQgbWVtb3J5IHdyaXRlIChiZXlvbmQgdGhlIHByaXZhdGUgZGF0YQ0K PiBvZiB0aGUgYWNjZXNzbG9nIG92ZXJsYXkgaW5zdGVhZCBvZiBpbiB0aGUgcHJpdmF0ZSBkYXRh IG9mIHRoZSBiZGINCj4gZGF0YWJhc2UpIHJlc3VsdGluZyBpbiBoZWFwIGNvcnJ1cHRpb24uDQoN CllvdSBtZWFudCB0aGUgbGltaXRzIG9wdGlvbiwgbm90IHRoZSBpZGxldGltZW91dCwgcmlnaHQ/ IEJlY2F1c2Ugd2hlbiBJIA0KcmVtb3ZlIGl0IHNsYXBkIHN0YXJ0cyBhbmQgcnVucyBwcm9wZXJs eS4NCkJ1dCBub3cgSSdtIHF1aXRlIGxvc3QgaGVyZS4gV2l0aCB0aGF0IHN0YXRlbWVudCBJIGlu dGVuZGVkIHRvIGRpc2FibGUgdGhlIA0KZGVmYXVsdCBsaW1pdHMgZm9yIGFsbCB1c2VycyBiZWxv dyBvdT1DTk8tTERDIHdoZW4gdmlld2luZyB0aGUgYWNjZXNzbG9nIA0KKGFzIGl0J3MgYm91bmQg dG8gZ3JvdyBiZXlvbmQgdGhlIDUwMCBlbnRyaWVzIHNvb25lciBvciBsYXRlcikuIFRoZSANCm1h bnBhZ2UgbGlzdHMgbGltaXRzIGFzIGEgZ2VuZXJhbCBkYXRhYmFzZSBvcHRpb24sIHNvIEkgYXNz dW1lZCBwbGFjaW5nIGl0IA0KYXQgdGhlIGVuZCBvZiB0aGUgYWNjZXNzbG9nIGRiIG9wdGlvbnMg d291bGQgaW1wb3NlIHRoZXNlIGxpbWl0cyBvbiBpdC4gDQpOb3cgd2hlcmUgd291bGQgYmUgdGhl IHByb3BlciBwbGFjZW1lbnQgdG8gYWNoaXZlIHRoYXQ/DQpVbmRlciAyLjMuMzMgaW4gbXkgdGVz dCBlbnZpcm9ubWVudCB3aXRoIGFuIGFjY2Vzc2xvZyA+IDUwMCBlbnRyaWVzIGFuZCANCnRoZSBs aW1pdHMgZGlyZWN0aXZlIGF0IGp1c3QgdGhpcyBwbGFjZSBpbiB0aGUgY29uZiBldmVyeXRoaW5n IHdvcmtlZCBhcyANCmV4cGVjdGVkLg0KDQpXaXRoIGtpbmQgcmVnYXJkcy4NCk1pY2hhZWwgSGVl cA0KVE8tQ05TLUxEQw0KbzIgKEdlcm1hbnkpIEdtYkggJiBDby5PSEcNCkJlcm5lciBTdHJhw59l IDc2LCBELTYwNDM3IEZyYW5rZnVydCBhLiBNLg0KVGVsICs0OSgwKTY5LTUwMDItNjE1OA0KTW9i aWwgKzQ5KDApMTc2LTIwNjMxMzcyDQpGYXggKzQ5KDApNjktNTAwMi02MTY5DQptaWNoYWVsLmhl ZXBAbzIuY29tDQoNCm8yIChHZXJtYW55KSBHbWJIICYgQ28uIE9IRyDigKIgR2VvcmctQnJhdWNo bGUtUmluZyAyMy0yNSDigKIgODA5OTIgTcO8bmNoZW4g4oCiIA0KRGV1dHNjaGxhbmQg4oCiIHd3 dy5vMi5jb20vZGUNCg0KVXN0Li1JZC4tTnIuIERFIDgxMSA4ODkgNjM4LiBBbXRzZ2VyaWNodCBN w7xuY2hlbiBIUkEgNzAzNDMuIA0KR2VzZWxsc2NoYWZ0ZXI6IG8yIChHZXJtYW55KSBNYW5hZ2Vt ZW50IEdtYkguIEFtdHNnZXJpY2h0IE3DvG5jaGVuIEhSQiANCjEwOTA2MSB1bmQNCm8yIChHZXJt YW55KSBWZXJ3YWx0dW5ncyBHbWJILiBBbXRzZ2VyaWNodCBNw7xuY2hlbiBIUkIgMTIxMzg5LCBi ZWlkZSANCmViZW5kYS4NCkdlc2Now6RmdHNmw7xocmVyIGJlaWRlciBHZXNlbGxzY2hhZnRlcjog RHIuIGguYy4gUnVkb2xmIEdyw7ZnZXIsIA0KVm9yc2l0emVuZGVyLiBEaWV0cmljaCBCZWVzZS4g QW5kcsOpIEtyYXVzZS4gUHJvZi4gRHIuIEFsZXhhbmRlciBSw7ZkZXIuIA0KS2FybC1XaWxoZWxt IFJvaHJzZW4uIEx1dHogU2Now7xsZXIuDQoNCg== --=_alternative 002D0ED3C125728E_= Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: base64 DQo8YnI+PGZvbnQgc2l6ZT0yIGZhY2U9InNhbnMtc2VyaWYiPkhlbGxvIFBpZXJhbmdlbG8sPC9m b250Pg0KPGJyPg0KPGJyPjxmb250IHNpemU9MiBmYWNlPSJzYW5zLXNlcmlmIj4mZ3Q7IGFuZG9A c3lzLW5ldC5pdCB3cm90ZTo8L2ZvbnQ+DQo8YnI+PGZvbnQgc2l6ZT0yIGZhY2U9InNhbnMtc2Vy aWYiPiZndDs8L2ZvbnQ+DQo8YnI+PGZvbnQgc2l6ZT0yIGZhY2U9InNhbnMtc2VyaWYiPiZndDsg VGhlIGFib3ZlIGhhZCBub3RoaW5nIHRvIGRvIHdpdGgNCnlvdXIgcHJvYmxlbS4gJm5ic3A7WW91 ciBwcm9ibGVtIGlzIHJlbGF0ZWQ8L2ZvbnQ+DQo8YnI+PGZvbnQgc2l6ZT0yIGZhY2U9InNhbnMt c2VyaWYiPiZndDsgdG8gdGhlIGZhY3QgdGhhdCB5b3UgaW50ZXJtaXhlZA0Kb3ZlcmxheSBhbmQg ZGF0YWJhc2UgY29uZmlndXJhdGlvbjwvZm9udD4NCjxicj48Zm9udCBzaXplPTIgZmFjZT0ic2Fu cy1zZXJpZiI+Jmd0OyBzdGF0ZW1lbnRzLCBzbyB0aGUgaWRsZXRpbWVvdXQNCnN0YXRlbWVudCBh ZnRlciB0aGUgYWNjZXNzbG9nIG92ZXJsYXk8L2ZvbnQ+DQo8YnI+PGZvbnQgc2l6ZT0yIGZhY2U9 InNhbnMtc2VyaWYiPiZndDsgaW5zdGFudGlhdGlvbiB3YXMgY2F1c2luZyBpbnZhbGlkDQptZW1v cnkgd3JpdGUgKGJleW9uZCB0aGUgcHJpdmF0ZSBkYXRhPC9mb250Pg0KPGJyPjxmb250IHNpemU9 MiBmYWNlPSJzYW5zLXNlcmlmIj4mZ3Q7IG9mIHRoZSBhY2Nlc3Nsb2cgb3ZlcmxheSBpbnN0ZWFk DQpvZiBpbiB0aGUgcHJpdmF0ZSBkYXRhIG9mIHRoZSBiZGI8L2ZvbnQ+DQo8YnI+PGZvbnQgc2l6 ZT0yIGZhY2U9InNhbnMtc2VyaWYiPiZndDsgZGF0YWJhc2UpIHJlc3VsdGluZyBpbiBoZWFwIGNv cnJ1cHRpb24uPC9mb250Pg0KPGJyPg0KPGJyPjxmb250IHNpemU9MiBmYWNlPSJzYW5zLXNlcmlm Ij5Zb3UgbWVhbnQgdGhlIGxpbWl0cyBvcHRpb24sIG5vdCB0aGUNCmlkbGV0aW1lb3V0LCByaWdo dD8gQmVjYXVzZSB3aGVuIEkgcmVtb3ZlIGl0IHNsYXBkIHN0YXJ0cyBhbmQgcnVucyBwcm9wZXJs eS48L2ZvbnQ+DQo8YnI+PGZvbnQgc2l6ZT0yIGZhY2U9InNhbnMtc2VyaWYiPkJ1dCBub3cgSSdt IHF1aXRlIGxvc3QgaGVyZS4gV2l0aCB0aGF0DQpzdGF0ZW1lbnQgSSBpbnRlbmRlZCB0byBkaXNh YmxlIHRoZSBkZWZhdWx0IGxpbWl0cyBmb3IgYWxsIHVzZXJzIGJlbG93DQpvdT1DTk8tTERDIHdo ZW4gdmlld2luZyB0aGUgYWNjZXNzbG9nIChhcyBpdCdzIGJvdW5kIHRvIGdyb3cgYmV5b25kIHRo ZQ0KNTAwIGVudHJpZXMgc29vbmVyIG9yIGxhdGVyKS4gVGhlIG1hbnBhZ2UgbGlzdHMgbGltaXRz IGFzIGEgZ2VuZXJhbCBkYXRhYmFzZQ0Kb3B0aW9uLCBzbyBJIGFzc3VtZWQgcGxhY2luZyBpdCBh dCB0aGUgZW5kIG9mIHRoZSBhY2Nlc3Nsb2cgZGIgb3B0aW9ucw0Kd291bGQgaW1wb3NlIHRoZXNl IGxpbWl0cyBvbiBpdC4gTm93IHdoZXJlIHdvdWxkIGJlIHRoZSBwcm9wZXIgcGxhY2VtZW50DQp0 byBhY2hpdmUgdGhhdD88L2ZvbnQ+DQo8YnI+PGZvbnQgc2l6ZT0yIGZhY2U9InNhbnMtc2VyaWYi PlVuZGVyIDIuMy4zMyBpbiBteSB0ZXN0IGVudmlyb25tZW50DQp3aXRoIGFuIGFjY2Vzc2xvZyAm Z3Q7IDUwMCBlbnRyaWVzIGFuZCB0aGUgbGltaXRzIGRpcmVjdGl2ZSBhdCBqdXN0IHRoaXMNCnBs YWNlIGluIHRoZSBjb25mIGV2ZXJ5dGhpbmcgd29ya2VkIGFzIGV4cGVjdGVkLjwvZm9udD4NCjxi cj4NCjxicj48Zm9udCBzaXplPTIgZmFjZT0ic2Fucy1zZXJpZiI+V2l0aCBraW5kIHJlZ2FyZHMu PC9mb250Pg0KPGJyPjxmb250IHNpemU9MiBmYWNlPSJzYW5zLXNlcmlmIj5NaWNoYWVsIEhlZXA8 YnI+DQpUTy1DTlMtTERDPGJyPg0KbzIgKEdlcm1hbnkpIEdtYkggJmFtcDsgQ28uT0hHPGJyPg0K QmVybmVyIFN0cmHDn2UgNzYsIEQtNjA0MzcgRnJhbmtmdXJ0IGEuIE0uPGJyPg0KVGVsICs0OSgw KTY5LTUwMDItNjE1ODxicj4NCk1vYmlsICs0OSgwKTE3Ni0yMDYzMTM3Mjxicj4NCkZheCArNDko MCk2OS01MDAyLTYxNjk8YnI+DQptaWNoYWVsLmhlZXBAbzIuY29tPGJyPg0KPGJyPg0KbzIgKEdl cm1hbnkpIEdtYkggJmFtcDsgQ28uIE9IRyDigKIgR2VvcmctQnJhdWNobGUtUmluZyAyMy0yNSDi gKIgODA5OTIgTcO8bmNoZW4NCuKAoiBEZXV0c2NobGFuZCDigKIgd3d3Lm8yLmNvbS9kZTxicj4N Cjxicj4NClVzdC4tSWQuLU5yLiBERSA4MTEgODg5IDYzOC4gQW10c2dlcmljaHQgTcO8bmNoZW4g SFJBIDcwMzQzLiBHZXNlbGxzY2hhZnRlcjoNCm8yIChHZXJtYW55KSBNYW5hZ2VtZW50IEdtYkgu IEFtdHNnZXJpY2h0IE3DvG5jaGVuIEhSQiAxMDkwNjEgdW5kPGJyPg0KbzIgKEdlcm1hbnkpIFZl cndhbHR1bmdzIEdtYkguIEFtdHNnZXJpY2h0IE3DvG5jaGVuIEhSQiAxMjEzODksIGJlaWRlIGVi ZW5kYS48YnI+DQpHZXNjaMOkZnRzZsO8aHJlciBiZWlkZXIgR2VzZWxsc2NoYWZ0ZXI6IERyLiBo LmMuIFJ1ZG9sZiBHcsO2Z2VyLCBWb3JzaXR6ZW5kZXIuDQpEaWV0cmljaCBCZWVzZS4gQW5kcsOp IEtyYXVzZS4gUHJvZi4gRHIuIEFsZXhhbmRlciBSw7ZkZXIuIEthcmwtV2lsaGVsbSBSb2hyc2Vu Lg0KTHV0eiBTY2jDvGxlci48L2ZvbnQ+DQo8YnI+DQo= --=_alternative 002D0ED3C125728E_=--

1 0

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

25 Feb '07

--Apple-Mail-19-845722018 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=ISO-8859-1; delsp=yes; format=flowed Le 25 f=E9vr. 07 =E0 17:40, Pierangelo Masarati a =E9crit : >> [...] >> Note that this "simpified" back-perl backend what working very well >> on OpenLDAP 2.2.xx branch... And the documentation doesn't seems to >> show some big changes in this part... > > The question is: have you ever read RFC2849 (LDIF specs)? I know the > answer: NO. The point is: you're developing code (back-perl =20 > scripting is > considered code development) and you don't even care to find out =20 > what the > specs say for a minimal detail like code interoperability! Have =20 > you even > looked at an LDIF example? How can you pretend to guess, by trial and > error, when your LDIF formatting will be finally accepted by a =20 > (decent) > LDIF parser? The syntax (made easy) is clear: > > <attribute name> (no space) : (space) <value> > that's it. Apparently you tried all combinations __except__ the =20 > one that > works, but looking, e.g., to the output of ldapsearch would have =20 > put you > in the right direction even without reading RFC 2849. I am sorry *but* I have tried this combination : We get a request for UID Looking for : (uid=3Dkiwi(a)oav.net) We get some results... Sending -> dn: uid=3Dkiwi(a)oav.net,ou=3Dmailboxes,dc=3Dkazar,dc=3Dnet objectClass: top objectClass: kazarPerson uid: kiwi(a)oav.net cn: Nom Prenom description: Sample description uidNumber: 10 gidNumber: 10 userPassword: Password homeDirectory: /home/test mailQuota: 50 CouriermailQuota: 50S =3D> ldap_bv2dn(uid=3Dkiwi(a)oav.net,ou=3Dmailboxes,dc=3Dkazar,dc=3Dnet,0) <=3D ldap_bv2dn(uid=3Dkiwi(a)oav.net,ou=3Dmailboxes,dc=3Dkazar,dc=3Dnet)=3D0= =3D> ldap_dn2bv(272) <=3D ldap_dn2bv(uid=3Dkiwi(a)oav.net,ou=3Dmailboxes,dc=3Dkazar,dc=3Dnet)=3D0= =3D> ldap_dn2bv(272) <=3D ldap_dn2bv(uid=3Dkiwi(a)oav.net,ou=3Dmailboxes,dc=3Dkazar,dc=3Dnet)=3D0= ldif_parse_line: missing ':' after <=3D str2entry: slap_str2undef_ad(): empty AttributeDescription str2entry(dn) failed send_ldap_result: err=3D0 matched=3D"" text=3D"" conn=3D0 op=3D1 SEARCH RESULT tag=3D101 err=3D0 nentries=3D0 text=3D daemon: select: listen=3D6 active_threads=3D0 tvp=3DNULL daemon: select: listen=3D7 active_threads=3D0 tvp=3DNULL daemon: activity on 1 descriptor daemon: activity on: 8r daemon: read activity on 8 connection_get(8) ber_dump: buf=3D0x08539150 ptr=3D0x08539150 end=3D0x08539155 len=3D5 0000: 02 01 03 42 00 ...B. conn=3D0 op=3D2 UNBIND daemon: removing 8 conn=3D0 fd=3D8 closed daemon: select: listen=3D6 active_threads=3D0 tvp=3DNULL daemon: select: listen=3D7 active_threads=3D0 tvp=3DNULL daemon: activity on 1 descriptor daemon: waked daemon: select: listen=3D6 active_threads=3D0 tvp=3DNULL daemon: select: listen=3D7 active_threads=3D0 tvp=3DNULL > Unless you can prove that back-perl LDIF parser doesn't work with =20 > decently > formatted LDIF, I'll consider this ITS closed. It *is* buggy proove me the contrary and be not so arrogant. /Xavier= --Apple-Mail-19-845722018 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 MBwGCSqGSIb3DQEJBTEPFw0wNzAyMjUxODAwNTBaMCMGCSqGSIb3DQEJBDEWBBQWG+Gb4d19rwPE aRI6PmdcJ9AsYTCBqwYJKwYBBAGCNxAEMYGdMIGaMIGUMRowGAYDVQQKExFBc3NvY2lhdGlvbiBL YXphcjEUMBIGA1UECxMLQ0EgRGl2aXNpb24xGzAZBgkqhkiG9w0BCQEWDGtpd2lAb2F2Lm5ldDEO MAwGA1UEBxMFUGFyaXMxDjAMBgNVBAgTBVBhcmlzMQswCQYDVQQGEwJGUjEWMBQGA1UEAxMNS2F6 YXIgUm9vdCBDQQIBADCBrQYLKoZIhvcNAQkQAgsxgZ2ggZowgZQxGjAYBgNVBAoTEUFzc29jaWF0 aW9uIEthemFyMRQwEgYDVQQLEwtDQSBEaXZpc2lvbjEbMBkGCSqGSIb3DQEJARYMa2l3aUBvYXYu bmV0MQ4wDAYDVQQHEwVQYXJpczEOMAwGA1UECBMFUGFyaXMxCzAJBgNVBAYTAkZSMRYwFAYDVQQD Ew1LYXphciBSb290IENBAgEAMA0GCSqGSIb3DQEBAQUABIIBAHi4NB/J3cucstsrftaOUUAQMNtT 3KEWDBGoYOmtTTDAxa48+6arC2V5DOc6Wob9M4qZOeQ3PmOYId+aq+ItQLQPtuAo7TsqtdjgMCKj JXR/k0iVobcJF1JNYEVWazm69fOtonEBQSRCwXS02NlO+amfDSLNfBuICfS9w78xDNnnIk3QDSyf GJX2M1muvJuZYCUNkSiHKmmxb9zXW4Mfp61mih1JOfrjDdwg2ZGX8NKgkuOFKlDNp/8HjAKsPAYN yA6N1zwdT4s8XjLRJIW2jZL2Xom0lYRVYPU3LmV1zb5YWXMrDElOY5YyPiTUXP0l9yhMipCIEKH0 /6On1ERVnRgAAAAAAAA= --Apple-Mail-19-845722018--

1 0

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

25 Feb '07

>> If the above is the way your LDIF is formatted, then back-perl >> (actually, str2entry, a helper function in the core of slapd) is >> working >> as intended. There's supposed to be no space between attribute >> names or >> "dn" and the colon ":". Please fix you PERL and report. > > I did several tests : one too less, I fear. > > - No space between attribute and data : ... > > Still getting no results. > > But there is an interressing error : "ldif_parse_line: missing ':' > after" > > So it seems that "old way" I used in OpenLDAP 2.2.xx branch doesn't > seems to be bad. ... > Note that this "simpified" back-perl backend what working very well > on OpenLDAP 2.2.xx branch... And the documentation doesn't seems to > show some big changes in this part... The question is: have you ever read RFC2849 (LDIF specs)? I know the answer: NO. The point is: you're developing code (back-perl scripting is considered code development) and you don't even care to find out what the specs say for a minimal detail like code interoperability! Have you even looked at an LDIF example? How can you pretend to guess, by trial and error, when your LDIF formatting will be finally accepted by a (decent) LDIF parser? The syntax (made easy) is clear: <attribute name> (no space) : (space) <value> that's it. Apparently you tried all combinations __except__ the one that works, but looking, e.g., to the output of ldapsearch would have put you in the right direction even without reading RFC 2849. Unless you can prove that back-perl LDIF parser doesn't work with decently formatted LDIF, I'll consider this ITS closed. 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 25 Feb '07

25 Feb '07

--Apple-Mail-17-824115749 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=ISO-8859-1; delsp=yes; format=flowed Hi, Le 21 f=E9vr. 07 =E0 23:02, Pierangelo Masarati a =E9crit : > kiwi(a)oav.net wrote: >> Full_Name: Xavier Beaudouin >> Version: 2.3.33 >> OS: FreeBSD 6.2 >> URL: http://www.oav.net/tmp/openldap/ >> Submission from: (NULL) (82.225.248.92) > >> Sending -> dn : uid=3Dkiwi(a)oav.net,ou=3Dmailboxes,dc=3Dkazar,dc=3Dnet >> objectClass : top >> objectClass : kazarPerson >> uid : kiwi(a)oav.net >> cn : Nom Prenom >> description : Sample description >> uidNumber : 10 >> gidNumber : 10 >> userPassword : Password >> homeDirectory : /home/test >> mailQuota : 50 >> CouriermailQuota : 50S >> >> str2entry: entry -1 has no dn >> str2entry(dn) failed >> send_ldap_result: err=3D0 matched=3D"" text=3D"" >> connection_get(8) > > If the above is the way your LDIF is formatted, then back-perl > (actually, str2entry, a helper function in the core of slapd) is =20 > working > as intended. There's supposed to be no space between attribute =20 > names or > "dn" and the colon ":". Please fix you PERL and report. I did several tests : - No space between attribute and data : conn=3D0 op=3D1 SRCH base=3D"ou=3Dmailboxes,dc=3Dkazar,dc=3Dnet" scope=3D2= deref=3D0 =20 filter=3D"(uid=3Dkiwi(a)oav.net)" We get a request for UID Looking for : (uid=3Dkiwi(a)oav.net) We get some results... Sending -> dn:uid=3Dkiwi@oav.net,ou=3Dmailboxes,dc=3Dkazar,dc=3Dnet objectClass:top objectClass:kazarPerson uid:kiwi@oav.net cn:Nom Prenom description:Sample description uidNumber:10 gidNumber:10 userPassword:Password homeDirectory:/home/test mailQuota:50 CouriermailQuota:50S =3D> ldap_bv2dn(uid=3Dkiwi(a)oav.net,ou=3Dmailboxes,dc=3Dkazar,dc=3Dnet,0) <=3D ldap_bv2dn(uid=3Dkiwi(a)oav.net,ou=3Dmailboxes,dc=3Dkazar,dc=3Dnet)=3D0= =3D> ldap_dn2bv(272) <=3D ldap_dn2bv(uid=3Dkiwi(a)oav.net,ou=3Dmailboxes,dc=3Dkazar,dc=3Dnet)=3D0= =3D> ldap_dn2bv(272) <=3D ldap_dn2bv(uid=3Dkiwi(a)oav.net,ou=3Dmailboxes,dc=3Dkazar,dc=3Dnet)=3D0= ldif_parse_line: missing ':' after <=3D str2entry: slap_str2undef_ad(): empty AttributeDescription str2entry(dn) failed send_ldap_result: err=3D0 matched=3D"" text=3D"" conn=3D0 op=3D1 SEARCH RESULT tag=3D101 err=3D0 nentries=3D0 text=3D daemon: activity on 1 descriptor daemon: activity on: 8r daemon: read activity on 8 connection_get(8) ber_dump: buf=3D0x08253a00 ptr=3D0x08253a00 end=3D0x08253a05 len=3D5 0000: 02 01 03 42 00 ...B. connection_read(8): input error=3D-2 id=3D0, closing. daemon: select: listen=3D6 active_threads=3D0 tvp=3DNULL daemon: select: listen=3D7 active_threads=3D0 tvp=3DNULL daemon: activity on 1 descriptor daemon: waked daemon: select: listen=3D6 active_threads=3D0 tvp=3DNULL daemon: select: listen=3D7 active_threads=3D0 tvp=3DNULL conn=3D0 op=3D2 UNBIND daemon: removing 8 conn=3D0 fd=3D8 closed - No space between attribute 'dn' and ':' : conn=3D0 op=3D1 SRCH base=3D"ou=3Dmailboxes,dc=3Dkazar,dc=3Dnet" scope=3D2= deref=3D0 =20 filter=3D"(uid=3Dkiwi(a)oav.net)" We get a request for UID Looking for : (uid=3Dkiwi(a)oav.net) We get some results... Sending -> dn: uid=3Dkiwi(a)oav.net,ou=3Dmailboxes,dc=3Dkazar,dc=3Dnet objectClass : top objectClass : kazarPerson uid : kiwi(a)oav.net cn : Nom Prenom description : Sample description uidNumber : 10 gidNumber : 10 userPassword : Password homeDirectory : /home/test mailQuota : 50 CouriermailQuota : 50S =3D> ldap_bv2dn(uid=3Dkiwi(a)oav.net,ou=3Dmailboxes,dc=3Dkazar,dc=3Dnet,0) <=3D ldap_bv2dn(uid=3Dkiwi(a)oav.net,ou=3Dmailboxes,dc=3Dkazar,dc=3Dnet)=3D0= =3D> ldap_dn2bv(272) <=3D ldap_dn2bv(uid=3Dkiwi(a)oav.net,ou=3Dmailboxes,dc=3Dkazar,dc=3Dnet)=3D0= =3D> ldap_dn2bv(272) <=3D ldap_dn2bv(uid=3Dkiwi(a)oav.net,ou=3Dmailboxes,dc=3Dkazar,dc=3Dnet)=3D0= ldif_parse_line: missing ':' after <=3D str2entry: slap_str2undef_ad(objectClass): AttributeDescription =20 contains inappropriate characters str2entry(dn) failed send_ldap_result: err=3D0 matched=3D"" text=3D"" conn=3D0 op=3D1 SEARCH RESULT tag=3D101 err=3D0 nentries=3D0 text=3D daemon: activity on 1 descriptor daemon: activity on: 8r daemon: read activity on 8 connection_get(8) ber_dump: buf=3D0x08253830 ptr=3D0x08253830 end=3D0x08253835 len=3D5 0000: 02 01 03 42 00 ...B. connection_read(8): input error=3D-2 id=3D0, closing. daemon: select: listen=3D6 active_threads=3D0 tvp=3DNULL daemon: select: listen=3D7 active_threads=3D0 tvp=3DNULL daemon: activity on 1 descriptor daemon: waked daemon: select: listen=3D6 active_threads=3D0 tvp=3DNULL daemon: select: listen=3D7 active_threads=3D0 tvp=3DNULL conn=3D0 op=3D2 UNBIND daemon: removing 8 conn=3D0 fd=3D8 closed Still getting no results. But there is an interressing error : "ldif_parse_line: missing ':' =20 after" So it seems that "old way" I used in OpenLDAP 2.2.xx branch doesn't =20 seems to be bad. What are the changes in str2entry() that may change ? Here is the kind of string I sent to : my $entry =3D "dn : uid=3D$mailaddr,ou=3Dmailboxes,dc=3Dkazar,dc=3Dnet\= n\t". "objectClass : top\n\t". "objectClass : kazarPerson\n\t"; $entry .=3D "uid : $mailaddr\n\t"; $entry .=3D "cn : Nom Prenom\n\t"; $entry .=3D "description : Sample description\n\t"; $entry .=3D "uidNumber : 10\n\t"; $entry .=3D "gidNumber : 10\n\t"; $entry .=3D "userPassword : Password\n\t"; $entry .=3D "homeDirectory : /home/test\n\t"; $entry .=3D "mailQuota : 50\n\t"; $entry .=3D "CouriermailQuota : 50S\n\t"; print STDERR "Sending -> $entry\n"; push @match_entries, $entry; return(0, @match_entries); Note that this "simpified" back-perl backend what working very well =20 on OpenLDAP 2.2.xx branch... And the documentation doesn't seems to =20 show some big changes in this part... THanks, /Xavier= --Apple-Mail-17-824115749 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 MBwGCSqGSIb3DQEJBTEPFw0wNzAyMjUxMjAwNDRaMCMGCSqGSIb3DQEJBDEWBBTEQXOv2cw7Da2M Gxgl5MPnGXmD1zCBqwYJKwYBBAGCNxAEMYGdMIGaMIGUMRowGAYDVQQKExFBc3NvY2lhdGlvbiBL YXphcjEUMBIGA1UECxMLQ0EgRGl2aXNpb24xGzAZBgkqhkiG9w0BCQEWDGtpd2lAb2F2Lm5ldDEO MAwGA1UEBxMFUGFyaXMxDjAMBgNVBAgTBVBhcmlzMQswCQYDVQQGEwJGUjEWMBQGA1UEAxMNS2F6 YXIgUm9vdCBDQQIBADCBrQYLKoZIhvcNAQkQAgsxgZ2ggZowgZQxGjAYBgNVBAoTEUFzc29jaWF0 aW9uIEthemFyMRQwEgYDVQQLEwtDQSBEaXZpc2lvbjEbMBkGCSqGSIb3DQEJARYMa2l3aUBvYXYu bmV0MQ4wDAYDVQQHEwVQYXJpczEOMAwGA1UECBMFUGFyaXMxCzAJBgNVBAYTAkZSMRYwFAYDVQQD Ew1LYXphciBSb290IENBAgEAMA0GCSqGSIb3DQEBAQUABIIBAD3RgUWLs5Si0VF628WxzJOIIzRd 3DyKLsc54IrVo60ReQxWJOS1GKH6T+r5kfbGnyhUXIwtMBpBF8Pvr6z/TlQIF+4XJKvVnW2YD3ML Rw2jHQjl8Dm73/Md+ViJ3E6PsQwkuRsONYl93CkqsET8UL1AFg9wc2fjI9vDT9SKgUzppK4nY7py aKJuTm3avopBaZyOQNrcr4LOrdWDQM/xh/n1u8VX5u3CanOum2sHyHqbcxTuHj2p3yKaxpigFiO2 L0fMc4ZY1baLuPDXHj8mbY36edl6TqxoFilGz5E9a9rVgSA5tMciRtZge2R3ZjxoaKRvCy7wNBMx iQKGpG/tL24AAAAAAAA= --Apple-Mail-17-824115749--

1 0

Re: (ITS#4851) improper database recovery at startup when using shared memory for db cache
by hyc＠symas.com 24 Feb '07

24 Feb '07

hyc(a)symas.com wrote: > erici(a)motown.cc.utexas.edu wrote: >> Full_Name: Eric Irrgang >> Version: 2.3.34 >> OS: Solaris 9 >> URL: ftp://ftp.openldap.org/incoming/ >> Submission from: (NULL) (128.83.217.14) >> >> >> Using Berkeley DB 4.4.20 for the hdb backend to OpenLDAP 2.3.34 with a shared >> memory segment for the db cache, the automatic bdb database recovery fails after >> a reboot (because the shared memory segment doesn't exist yet). > > In fact there is no automatic DB recovery happening here, this is a regular > Open that fails because the (shared memory) environment is missing. We don't > detect that recovery is needed because presumably slapd exited cleanly at the > previous shutdown. > > I guess we'll have to add a check for this condition (e.g., if ENV open fails > and we're using shared memory, recover and try again). This is now fixed in HEAD, back-bdb/init.c 1.272 -- -- 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

Re: (ITS#4851) improper database recovery at startup when using shared memory for db cache
by hyc＠symas.com 24 Feb '07

24 Feb '07

erici(a)motown.cc.utexas.edu wrote: > Full_Name: Eric Irrgang > Version: 2.3.34 > OS: Solaris 9 > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (128.83.217.14) > > > Using Berkeley DB 4.4.20 for the hdb backend to OpenLDAP 2.3.34 with a shared > memory segment for the db cache, the automatic bdb database recovery fails after > a reboot (because the shared memory segment doesn't exist yet). In fact there is no automatic DB recovery happening here, this is a regular Open that fails because the (shared memory) environment is missing. We don't detect that recovery is needed because presumably slapd exited cleanly at the previous shutdown. I guess we'll have to add a check for this condition (e.g., if ENV open fails and we're using shared memory, recover and try again). > slapd logs show the following: > [ID 446079 local3.debug] bdb(dc=directory,dc=utexas,dc=edu): shmat: id 0: unable > to attach to shared system memory region: Invalid argument > [ID 656078 local3.debug] bdb_db_open: Database cannot be opened, err 22. Restore > from backup! > [ID 446079 local3.debug] bdb(dc=directory,dc=utexas,dc=edu): > DB_ENV->lock_id_free interface requires an environment configured for the > locking subsystem > [ID 446079 local3.debug] bdb(dc=directory,dc=utexas,dc=edu): txn_checkpoint > interface requires an environment configured for the transaction subsystem > [ID 881909 local3.debug] bdb_db_close: txn_checkpoint failed: Invalid argument > (22) > [ID 658289 local3.debug] backend_startup_one: bi_db_open failed! (22) > [ID 948119 local3.debug] bdb_db_close: alock_close failed > [ID 486161 local3.debug] slapd stopped. > [ID 432338 local3.debug] connections_destroy: nothing to destroy. > > > db_recover must be used to clean up the environment. It gives the message > "db_recover: shmat: id 0: unable to attach to shared system memory region: > Invalid argument" but completes with return code 0, removes the __db.001 file, > and slapd is then able to start without errors. -- -- 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

(ITS#4851) improper database recovery at startup when using shared memory for db cache
by erici＠motown.cc.utexas.edu 24 Feb '07

24 Feb '07

Full_Name: Eric Irrgang Version: 2.3.34 OS: Solaris 9 URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (128.83.217.14) Using Berkeley DB 4.4.20 for the hdb backend to OpenLDAP 2.3.34 with a shared memory segment for the db cache, the automatic bdb database recovery fails after a reboot (because the shared memory segment doesn't exist yet). slapd logs show the following: [ID 446079 local3.debug] bdb(dc=directory,dc=utexas,dc=edu): shmat: id 0: unable to attach to shared system memory region: Invalid argument [ID 656078 local3.debug] bdb_db_open: Database cannot be opened, err 22. Restore from backup! [ID 446079 local3.debug] bdb(dc=directory,dc=utexas,dc=edu): DB_ENV->lock_id_free interface requires an environment configured for the locking subsystem [ID 446079 local3.debug] bdb(dc=directory,dc=utexas,dc=edu): txn_checkpoint interface requires an environment configured for the transaction subsystem [ID 881909 local3.debug] bdb_db_close: txn_checkpoint failed: Invalid argument (22) [ID 658289 local3.debug] backend_startup_one: bi_db_open failed! (22) [ID 948119 local3.debug] bdb_db_close: alock_close failed [ID 486161 local3.debug] slapd stopped. [ID 432338 local3.debug] connections_destroy: nothing to destroy. db_recover must be used to clean up the environment. It gives the message "db_recover: shmat: id 0: unable to attach to shared system memory region: Invalid argument" but completes with return code 0, removes the __db.001 file, and slapd is then able to start without errors.

1 0

Re: (ITS#4792) not able to install Slapd i.e. when I install openldap it does'nt install server module
by ando＠sys-net.it 24 Feb '07

24 Feb '07

azia(a)techxact.com wrote: > Full_Name: Ahmad Zia > Version: openldap-2.3.31 > OS: Redhat ES 4 > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (80.227.142.2) > > > I have successfully compiled, make openldad but when I get to the point where I > have to run "make test" it says cannot connect to the openldap server after > timing out. You should ask software usage related questions on the openldap-software mailing list. The ITS is intended to track software bugs or development issues, and you are not pointing out any evidence of software malfunction yet. > When I use this command , I get the following: > > [root@TXDXB openldap]# rpm -qa | grep openldap > openldap-devel-2.2.13-6.4E > openldap-2.2.13-6.4E > openldap-clients-2.2.13-6.4E > > its not listing openldap-server-2.2.13-6.4E and in my /etc/openldap directory I > only have ldap.conf and I do not have slapd.conf, so what I gather so far is > that I am not able to install the server module. This has nothing to do with OpenLDAP software; OpenLDAP software is released only in source form, and it's up to dofwtare distributors to package it in binary form. It is very unlikely that by simply compiling OpenLDAP software as distributed by OpenLDAP you may see anything show up with rpm -qa, since building OpenLDAP software does not result in any rpm package (and, in any case, you'd need to explicitly __install__ any rpm package to see it appear with rpm -qa). > I have used the parameter --enable-slapd with ./configure command but its still > the same thing. Slapd is built by default; the --enable-slapd switch is provided to allow users to __disable__ it. > Can you please tell me what am I doing wrong Testing may fail for hundreds of reasons beyond a bug in the software. You should check trivial things first, e.g. by inspecting any log messages resulting from the tests. See <http://www.openldap.org/faq/data/cache/1089.html> and <http://www.openldap.org/faq/data/cache/56.html> for possible directions. This ITS will be closed. 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

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

openldap-bugs