- openldap-bugs - openldap.org

Re: (ITS#4903) dynlist issues with memory allocation
by ando＠sys-net.it 02 Apr '07

02 Apr '07

quanah(a)stanford.edu wrote: > Full_Name: Quanah Gibson-Mount > Version: RE_23 > OS: Linux 2.6 (64-bit) > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (171.64.19.81) > > > In testing the RE_23 tree, I put it under hoard after everything passed using > glibc as the memory allocator. I found that if I enable dynlist: > > moduleload dynlist.la > > then in my database section add: > > # Dynlist Overlay > overlay dynlist > dynlist-attrset groupOfURLS memberURL member > > > slapd will core dump on startup with: > > Loaded symbols for /usr/local/lib/openldap/dynlist-2.3-releng.so.0 > #0 0x00002ab7651490c9 in malloc () from /usr/local/lib/libhoard.so > (gdb) bt > #0 0x00002ab7651490c9 in malloc () from /usr/local/lib/libhoard.so > #1 0x00002ab765149e38 in realloc () from /usr/local/lib/libhoard.so > #2 0x00002ab76554f890 in ber_memrealloc_x (p=Variable "p" is not available. > ) at memory.c:354 > #3 0x00002ab76542bf88 in ldap_charray_add (a=0x7fff45a7eec0, s=0x2ab7667c2518 > "olcConnMaxPending") at charray.c:49 > #4 0x000000000045e9f9 in matching_rule_use_init () at mr.c:364 > #5 0x0000000000459f62 in slap_schema_check () at schema_prep.c:1368 > #6 0x0000000000415f1b in main (argc=3, argv=0x7fff45a7f0b8) at main.c:711 > > > It looks like there's soemthing incorrect in the way it is allocating memory on > startup. Apparently, there's nothing directly related to dynlist; can you post the entire slapd.conf? I suspect something like ITS#4848, which is NOT fixed in re23 (and likely won't). 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#4903) dynlist issues with memory allocation
by quanah＠stanford.edu 02 Apr '07

02 Apr '07

Full_Name: Quanah Gibson-Mount Version: RE_23 OS: Linux 2.6 (64-bit) URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (171.64.19.81) In testing the RE_23 tree, I put it under hoard after everything passed using glibc as the memory allocator. I found that if I enable dynlist: moduleload dynlist.la then in my database section add: # Dynlist Overlay overlay dynlist dynlist-attrset groupOfURLS memberURL member slapd will core dump on startup with: Loaded symbols for /usr/local/lib/openldap/dynlist-2.3-releng.so.0 #0 0x00002ab7651490c9 in malloc () from /usr/local/lib/libhoard.so (gdb) bt #0 0x00002ab7651490c9 in malloc () from /usr/local/lib/libhoard.so #1 0x00002ab765149e38 in realloc () from /usr/local/lib/libhoard.so #2 0x00002ab76554f890 in ber_memrealloc_x (p=Variable "p" is not available. ) at memory.c:354 #3 0x00002ab76542bf88 in ldap_charray_add (a=0x7fff45a7eec0, s=0x2ab7667c2518 "olcConnMaxPending") at charray.c:49 #4 0x000000000045e9f9 in matching_rule_use_init () at mr.c:364 #5 0x0000000000459f62 in slap_schema_check () at schema_prep.c:1368 #6 0x0000000000415f1b in main (argc=3, argv=0x7fff45a7f0b8) at main.c:711 It looks like there's soemthing incorrect in the way it is allocating memory on startup. --Quanah

1 0

Re: (ITS#4902) ManPage in 2.3.19 RPM is completely screwed up
by ando＠sys-net.it 02 Apr '07

02 Apr '07

quanah(a)stanford.edu wrote: >> I don't know if the people who are in charge to build a RPM are paying >> attention to what they are doing or not. >> >> You can do a man ldap_init, and then look at /usr/include/ldap.h for the >> function definition. >> >> I am not a LDAP expert or anything close to that. But it seems to me that >> function called ldap_init has already been replaced by the function called >> ldap_initialize, and they take even different set of parameters. >> >> And yet the manpage not only didn't reflect that change, but enforce the >> wrong idea of using ldap_init function by having ldap_init in manpages. >> >> An extremely poor job done by the package maintainer. > > Hi, > > I suggest you complain to RedHat if you don't like the way they've packaged > something. The OpenLDAP foundation is not responsible for the way in which > RedHat packages its releases. In any case, if you are taking the time to > read the header file, then pay close attention to the following: > > #if LDAP_DEPRECATED > LDAP_F( LDAP * ) > ldap_init LDAP_P(( /* deprecated, use ldap_create or ldap_initialize */ > LDAP_CONST char *host, > int port )); > > > I.e., ldap_init is a deprecated function, and ldap_initialize should be > used instead. However, there are many programs out there that still use > the old API, so the old functions are maintained for backwards > compatibility purposes. Hence the man page. I'd add that OpenLDAP is a voluntary based project, and volunteers devote their efforts to what they consider mostly important - typically writing good useful code that runs (fast). Man pages typically lag behind, but eventually they get updated/fixed (as they are in currently released code). If you cared so much about up-to-date code and man pages, you would be using the latest release, not a 15 months old one. And if you were able to infer the really useful API from ldap.h, you could have more proficiently spent your time by writing and submitting a useful man page, instead of just complaining quite unpolitely. 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#4902) ManPage in 2.3.19 RPM is completely screwed up
by quanah＠stanford.edu 02 Apr '07

02 Apr '07

--On Monday, April 02, 2007 5:23 PM +0000 wweng(a)kencast.com wrote: > Full_Name: Wei Weng > Version: 2.3.19 > OS: Linux(Fedora 5) > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (69.120.101.108) > > > I don't know if the people who are in charge to build a RPM are paying > attention to what they are doing or not. > > You can do a man ldap_init, and then look at /usr/include/ldap.h for the > function definition. > > I am not a LDAP expert or anything close to that. But it seems to me that > function called ldap_init has already been replaced by the function called > ldap_initialize, and they take even different set of parameters. > > And yet the manpage not only didn't reflect that change, but enforce the > wrong idea of using ldap_init function by having ldap_init in manpages. > > An extremely poor job done by the package maintainer. Hi, I suggest you complain to RedHat if you don't like the way they've packaged something. The OpenLDAP foundation is not responsible for the way in which RedHat packages its releases. In any case, if you are taking the time to read the header file, then pay close attention to the following: #if LDAP_DEPRECATED LDAP_F( LDAP * ) ldap_init LDAP_P(( /* deprecated, use ldap_create or ldap_initialize */ LDAP_CONST char *host, int port )); I.e., ldap_init is a deprecated function, and ldap_initialize should be used instead. However, there are many programs out there that still use the old API, so the old functions are maintained for backwards compatibility purposes. Hence the man page. This ITS will be closed. Regards, Quanah -- Quanah Gibson-Mount Senior Systems Software Developer ITS/Shared Application Services Stanford University GnuPG Public Key: http://www.stanford.edu/~quanah/pgp.html

1 0

(ITS#4902) ManPage in 2.3.19 RPM is completely screwed up
by wweng＠kencast.com 02 Apr '07

02 Apr '07

Full_Name: Wei Weng Version: 2.3.19 OS: Linux(Fedora 5) URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (69.120.101.108) I don't know if the people who are in charge to build a RPM are paying attention to what they are doing or not. You can do a man ldap_init, and then look at /usr/include/ldap.h for the function definition. I am not a LDAP expert or anything close to that. But it seems to me that function called ldap_init has already been replaced by the function called ldap_initialize, and they take even different set of parameters. And yet the manpage not only didn't reflect that change, but enforce the wrong idea of using ldap_init function by having ldap_init in manpages. An extremely poor job done by the package maintainer.

1 0

Re: (ITS#4901) malloc/free mismatches in ldapadd
by quanah＠stanford.edu 31 Mar '07

31 Mar '07

--On Saturday, March 31, 2007 12:54 AM +0000 quanah(a)stanford.edu wrote: > --On Friday, March 30, 2007 2:25 PM +0000 chris.ridd(a)isode.com wrote: > >> Full_Name: Chris Ridd >> Version: 2.3.34 >> OS: Windows >> URL: ftp://ftp.openldap.org/incoming/ >> Submission from: (NULL) (62.3.217.250) >> >> >> On Windows, it is important that mallocs done in one DLL are balanced by >> frees done from the same DLL. Failure to do this consistently leads to >> heap corruption. >> >> This was observed to occur in several places in ldapadd - several buffers >> allocated by ber_memfree() were freed using free(). >> >> Our customer has successfully used a version of ldapadd on Windows >> containing this patch (and the one in ITS 4900.) > > Thanks, testing. --- openldap-2.3.34/clients/tools/common.c.orig Fri Mar 30 15:17:32 2007 +++ openldap-2.3.34/clients/tools/common.c Fri Mar 30 15:21:42 2007 @@ -1244,7 +1244,7 @@ crit ? "critical " : "" ); } - free( ctrls ); + ldap_controls_free( ctrls ); if ( crit ) { exit( EXIT_FAILURE ); } Just to note, this part of the patch is bad. ctrls is a pointer to an array of controls, not an array of controls itself. Therefore, the use of "free" here is appropriate. Using ldap_controls_free results in segfaults. --Quanah -- Quanah Gibson-Mount Senior Systems Software Developer ITS/Shared Application Services Stanford University GnuPG Public Key: http://www.stanford.edu/~quanah/pgp.html

1 0

Re: (ITS#4901) malloc/free mismatches in ldapadd
by quanah＠stanford.edu 31 Mar '07

31 Mar '07

--On Friday, March 30, 2007 2:25 PM +0000 chris.ridd(a)isode.com wrote: > Full_Name: Chris Ridd > Version: 2.3.34 > OS: Windows > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (62.3.217.250) > > > On Windows, it is important that mallocs done in one DLL are balanced by > frees done from the same DLL. Failure to do this consistently leads to > heap corruption. > > This was observed to occur in several places in ldapadd - several buffers > allocated by ber_memfree() were freed using free(). > > Our customer has successfully used a version of ldapadd on Windows > containing this patch (and the one in ITS 4900.) Thanks, testing. --Quanah -- Quanah Gibson-Mount Senior Systems Software Developer ITS/Shared Application Services Stanford University GnuPG Public Key: http://www.stanford.edu/~quanah/pgp.html

1 0

Re: (ITS#4900) command-line utils crash
by quanah＠stanford.edu 31 Mar '07

31 Mar '07

--On Friday, March 30, 2007 2:09 PM +0000 chris.ridd(a)isode.com wrote: > Full_Name: Chris Ridd > Version: 2.3.34 > OS: Windows > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (62.3.217.250) > > > On Windows, the ldapadd tool often crashes while parsing the command-line > arguments. Hi Chris, We formally dropped support for MSVC a long time ago. That being said, working build of OpenLDAP was accomplished with MSVCC a few months ago without hitting this issue. Which version of MSVC is being used, and please doublecheck the conditions spelled out in the comments in <ldap_cdefs.h>, where it starts with "Support for Windows DLLs". Also, instead of declaring things as extern, does changing LDAP_LIBC_V to LDAP_LUTIL_V resolve your issue? --Quanah -- Quanah Gibson-Mount Senior Systems Software Developer ITS/Shared Application Services Stanford University GnuPG Public Key: http://www.stanford.edu/~quanah/pgp.html

1 0

(ITS#4901) malloc/free mismatches in ldapadd
by chris.ridd＠isode.com 30 Mar '07

30 Mar '07

Full_Name: Chris Ridd Version: 2.3.34 OS: Windows URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (62.3.217.250) On Windows, it is important that mallocs done in one DLL are balanced by frees done from the same DLL. Failure to do this consistently leads to heap corruption. This was observed to occur in several places in ldapadd - several buffers allocated by ber_memfree() were freed using free(). Our customer has successfully used a version of ldapadd on Windows containing this patch (and the one in ITS 4900.) Patch follows: --- openldap-2.3.34/clients/tools/common.c.orig Fri Mar 30 15:17:32 2007 +++ openldap-2.3.34/clients/tools/common.c Fri Mar 30 15:21:42 2007 @@ -163,7 +163,7 @@ N_(" -n show what would be done but don't actually do it\n"), N_(" -O props SASL security properties\n"), N_(" -p port port on LDAP server\n"), -N_(" -P version procotol version (default: 3)\n"), +N_(" -P version protocol version (default: 3)\n"), N_(" -Q use SASL Quiet mode\n"), N_(" -R realm SASL realm\n"), N_(" -U authcid SASL authentication identity\n"), @@ -1244,7 +1244,7 @@ crit ? "critical " : "" ); } - free( ctrls ); + ldap_controls_free( ctrls ); if ( crit ) { exit( EXIT_FAILURE ); } --- openldap-2.3.34/clients/tools/ldapmodify.c.orig Fri Mar 30 15:19:34 2007 +++ openldap-2.3.34/clients/tools/ldapmodify.c Fri Mar 30 15:21:07 2007 @@ -389,8 +389,8 @@ fprintf( rejfp, "\n%s\n", rejbuf ); } - if (rejfp) free( rejbuf ); - free( rbuf ); + if (rejfp) ber_memfree( rejbuf ); + ber_memfree( rbuf ); } #ifdef LDAP_GROUP_TRANSACTION @@ -519,7 +519,7 @@ printf(_("%s: skipping change record for entry: %s\n"), prog, dn); printf(_("\t(LDAP host/port does not match replica: lines)\n")); - free( dn ); + ber_memfree( dn ); ber_memfree( type ); ber_memfree( val.bv_val ); return( 0 ); @@ -727,13 +727,13 @@ } if ( dn != NULL ) { - free( dn ); + ber_memfree( dn ); } if ( newrdn != NULL ) { - free( newrdn ); + ber_memfree( newrdn ); } if ( newsup != NULL ) { - free( newsup ); + ber_memfree( newsup ); } if ( pmods != NULL ) { ldap_mods_free( pmods, 1 );

1 0

(ITS#4900) command-line utils crash
by chris.ridd＠isode.com 30 Mar '07

30 Mar '07

Full_Name: Chris Ridd Version: 2.3.34 OS: Windows URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (62.3.217.250) On Windows, the ldapadd tool often crashes while parsing the command-line arguments. This is due to a defect in the way the optarg (et al) variables are declared in ac/unistd.h. When tools/common.c includes that file, the 4 variables end up being declared as being "imported" from a DLL. However they're *actually* present in a static archive that's linked into the ldapadd executable, which is apparently not the same sort of thing. (Visual Studio's compiler warns about inconsistent linkage :-) As a result, the code in getopt.c thinks that optarg is a variable at one address, and the code calling getopt() think that optarg is a variable at a *different* address (NULL in my test rig). Clearly that's not right, and it causes a variety of issues: -D <dn> copies optarg using strdup(NULL), which returns NULL. -w <passwd> scribbles over the passwd string, which crashes doing a *optarg because optarg is NULL. A simple fix is to redeclare the 4 variables as just "extern" instead of LDAP_LIBC_V. Diff follows... --- openldap-2.3.34/include/ac/unistd.h.orig Fri Mar 30 15:05:49 2007 +++ openldap-2.3.34/include/ac/unistd.h Fri Mar 30 15:06:10 2007 @@ -54,8 +54,8 @@ #else /* assume we need to declare these externs */ - LDAP_LIBC_V (char *) optarg; - LDAP_LIBC_V (int) optind, opterr, optopt; + extern char * optarg; + extern int optind, opterr, optopt; #endif /* use lutil file locking */

1 0

Re: (ITS#4890) Enhancement: Default Values overlay (patch)
by quanah＠stanford.edu 29 Mar '07

29 Mar '07

--On Thursday, March 22, 2007 5:25 PM +0000 docelic(a)mail.inet.hr wrote: > Full_Name: Davor Ocelic > Version: CVS-HEAD > OS: Linux > URL: http://www.hcoop.net/~docelic/openldap-slapd.overlays.defvals.patch > Submission from: (NULL) (213.147.110.16) > > > > Hello, > > Attached is a patch which adds a "Default Attribute Values" functionality > to OpenLDAP. It is implemented as an overlay named "defvals", and the > patch is done against cvs-head of today. > > Complete documentation is included in the slapo-defvals(5) manual page. > The overlay code itself is commented as well, as a help for others writing > overlays. > > Feel free to trim comments or improve code as you see fit. Hi Davor, I believe you'll need to complete the attribution bit detailed here: <http://www.openldap.org/devel/contributing.html> for this to be included. --Quanah -- Quanah Gibson-Mount Senior Systems Software Developer ITS/Shared Application Services Stanford University GnuPG Public Key: http://www.stanford.edu/~quanah/pgp.html

1 0

Re: (ITS#4898) slapd crashes when no structural object class provided
by BLentz＠channing-bete.com 29 Mar '07

29 Mar '07

> --On Wednesday, March 28, 2007 8:45 PM +0000 blentz(a)channing-bete.com > wrote: > > ldbm is deprecated, and it is highly advised that it not be used. > Bugs with LDBM are unlikely to be fixed, and it has already been > removed from the 2.4 release. If you can reproduce this issue with > back-bdb, please follow up. > I've removed ldbm support, replacing it with bdb. Everything seems nice and stable now, and I can't reproduce the crashing with back-bdb.

1 0

Re: (ITS#4899) ITS4855 fix breaks 2.3.34
by quanah＠stanford.edu 29 Mar '07

29 Mar '07

--On Wednesday, March 28, 2007 11:43 PM +0000 hyc(a)symas.com wrote: > quanah(a)stanford.edu wrote: >> Full_Name: Quanah Gibson-Mount >> Version: 2.3.34 >> OS: Linux 2.6 >> URL: ftp://ftp.openldap.org/incoming/ >> Submission from: (NULL) (171.66.35.82) >> >> >> I patched 2.3.34 with the patch in RE_23 for fixing the thread pool issue >> (ITS#4855) > > So really this is a bug in RE23, not 2.3.34, yes? True. :/ I was using my laptop, which is a bit more annoying to type, cut, and paste with than my normal system ;) --Quanah -- Quanah Gibson-Mount Senior Systems Software Developer ITS/Shared Application Services Stanford University GnuPG Public Key: http://www.stanford.edu/~quanah/pgp.html

1 0

Re: (ITS#4899) ITS4855 fix breaks 2.3.34
by hyc＠symas.com 29 Mar '07

29 Mar '07

quanah(a)stanford.edu wrote: > Full_Name: Quanah Gibson-Mount > Version: 2.3.34 > OS: Linux 2.6 > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (171.66.35.82) > > > I patched 2.3.34 with the patch in RE_23 for fixing the thread pool issue > (ITS#4855) So really this is a bug in RE23, not 2.3.34, yes? > <http://www.openldap.org/devel/cvsweb.cgi/libraries/libldap_r/tpool.c.diff?r…> > > My patch being: > > ldap-uat00:/usr/local/build/PATCHES/openldap# cat ITS4855 > --- openldap-2.3.34/libraries/libldap_r/tpool.c.orig 2007-03-26 > 15:19:56.000000000 -0700 > +++ openldap-2.3.34/libraries/libldap_r/tpool.c 2007-03-26 15:20:20.000000000 > -0700 > @@ -664,7 +664,7 @@ > int i; > > for ( i=MAXKEYS-1; i>=0; i--) { > - if ( ctx[i].ltk_key ) > + if ( ctx[i].ltk_key == NULL ) > continue; > if ( ctx[i].ltk_free ) > ctx[i].ltk_free( ctx[i].ltk_key, ctx[i].ltk_data ); -- -- 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#4899) ITS4855 fix breaks 2.3.34
by quanah＠stanford.edu 29 Mar '07

29 Mar '07

Full_Name: Quanah Gibson-Mount Version: 2.3.34 OS: Linux 2.6 URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (171.66.35.82) I patched 2.3.34 with the patch in RE_23 for fixing the thread pool issue (ITS#4855) <http://www.openldap.org/devel/cvsweb.cgi/libraries/libldap_r/tpool.c.diff?r…> My patch being: ldap-uat00:/usr/local/build/PATCHES/openldap# cat ITS4855 --- openldap-2.3.34/libraries/libldap_r/tpool.c.orig 2007-03-26 15:19:56.000000000 -0700 +++ openldap-2.3.34/libraries/libldap_r/tpool.c 2007-03-26 15:20:20.000000000 -0700 @@ -664,7 +664,7 @@ int i; for ( i=MAXKEYS-1; i>=0; i--) { - if ( ctx[i].ltk_key ) + if ( ctx[i].ltk_key == NULL ) continue; if ( ctx[i].ltk_free ) ctx[i].ltk_free( ctx[i].ltk_key, ctx[i].ltk_data ); Now when I shut down slapd, it core dumps: 1282 cache.c: No such file or directory. in cache.c (gdb) bt #0 bdb_locker_id_free (key=0x2aad2fe00628, data=0x39) at cache.c:1282 #1 0x00002aad2d0bef21 in ldap_pvt_thread_pool_context_reset (vctx=0x2aad2d1f2260) at tpool.c:670 #2 0x000000000044e07c in slap_destroy () at init.c:304 #3 0x00000000004159f9 in main (argc=3, argv=0x7fff7de07438) at main.c:874 If I remove the patch, there is no core dump. I see no additional related commits for this change. --Quanah

1 0

Re: (ITS#4898) slapd crashes when no structural object class provided
by quanah＠stanford.edu 28 Mar '07

28 Mar '07

--On Wednesday, March 28, 2007 8:45 PM +0000 blentz(a)channing-bete.com wrote: > Full_Name: Ben Lentz > Version: 2.3.34 > OS: Fedora Core 3 > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (12.169.82.130) > > > Background: > This is a heavily modified RPM build of the 2.2.17 release which came > standard with Fedora Core 3. ldbm is deprecated, and it is highly advised that it not be used. Bugs with LDBM are unlikely to be fixed, and it has already been removed from the 2.4 release. If you can reproduce this issue with back-bdb, please follow up. --Quanah -- Quanah Gibson-Mount Senior Systems Software Developer ITS/Shared Application Services Stanford University GnuPG Public Key: http://www.stanford.edu/~quanah/pgp.html

1 0

(ITS#4898) slapd crashes when no structural object class provided
by blentz＠channing-bete.com 28 Mar '07

28 Mar '07

Full_Name: Ben Lentz Version: 2.3.34 OS: Fedora Core 3 URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (12.169.82.130) Background: This is a heavily modified RPM build of the 2.2.17 release which came standard with Fedora Core 3. Versions: OpenLDAP 2.3.34, gcc-3.4.4, glibc-2.3.6, db4-4.2.52 Build: ./configure --enable-ldbm -with-ldbm-api=berkeley --enable-bdb --enable-ldap --enable-meta --enable-monitor --enable-null --enable-rewrite --disable-shared --with-kerberos=k5only --with-cyrus-sasl Configuration: /etc/openldap/slapd.conf: database ldbm /usr/sbin/slapd -u ldap -h "ldap:///" -d 1 & Issue: Client executes something dumb, causing a "No structural object class" error: ldapadd -x -D "cn=Manager,dc=my-domain,dc=com" -w secret dn: dc=my-domain,dc=com objectClass: top objectClass: dcObject dc: my-domain ^D slapd output (crash): connection_get(10): got connid=0 connection_read(10): checking for input on id=0 ber_get_next ber_get_next: tag 0x30 len 79 contents: ber_get_next do_add ber_scanf fmt ({m) ber: >>> dnPrettyNormal: <dc=my-domain,dc=com> <<< dnPrettyNormal: <dc=my-domain,dc=com>, <dc=my-domain,dc=com> ber_scanf fmt ({m{W}}) ber: ber_scanf fmt ({m{W}}) ber: ber_scanf fmt (}) ber: dn2entry_r: dn: "dc=my-domain,dc=com" => dn2id( "dc=my-domain,dc=com" ) => ldbm_cache_open( "dn2id.dbb", 73, 600 ) <= ldbm_cache_open (opened 0) <= dn2id NOID entry failed op attrs add: no structural object class provided (65) slapd: ../../../../servers/slapd/back-ldbm/cache.c:111: cache_return_entry_rw: Assertion `e->e_private != ((void *)0)' failed. [1]+ Aborted /usr/sbin/slapd -u ldap -h "ldap:///" -d 1 ldapadd output: adding new entry "dc=my-domain,dc=com" ldap_result: Can't contact LDAP server (-1) Is there something wrong with my build or runtime environment that would cause this? I am mostly concerned that this is a "minor security issue", e.g. server bugs which clients can use to deny services to others. I am looking to upgrade several production servers from 2.2.17 to 2.3.34 and need to ensure that things are as stable as possible beforehand. I can provide more detailed information (versions, straces, cores, etc.) upon request. Thanks for any insight you can provide.

1 0

(ITS#4897) admin-guide 11.3.3.2. Policy Configuration confuses "from" and "to"
by mb＠computer-leipzig.com 28 Mar '07

28 Mar '07

Full_Name: Michael Bunk Version: 2.3.30 OS: Linux URL: Submission from: (NULL) (84.185.166.80) Wrong: "This directive can be set to none for no rules (the default), from for source rules, to for destination rules, or both for both source and destination rules." Correct: "This directive can be set to none for no rules (the default), to for source rules, from for destination rules, or both for both source and destination rules." This bug is present in http://www.openldap.org/doc/admin23/sasl.html and in revision 1.34.2.2 (HEAD at this moment) of admin/sasl.sdf.

1 0

Re: (ITS#4892) slapd HEAD crashes with ldapi:// and SASL EXTERNAL
by ando＠sys-net.it 27 Mar '07

27 Mar '07

Michael Ströder wrote: > Pierangelo Masarati wrote: >> michael(a)stroeder.com wrote: >> >>> bdb_idl_fetch_key: [5941c014] >>> <= bdb_index_read: failed (-30989) >> ^^^ >> >> $ grep 30989 dn.h >> #define DB_OLD_VERSION (-30989)/* Out-of-date version. */ >> >> I guess something strange is going on with libdb run-time loading... > > Well, it seems you were right. Strange that make test did not reveal any > problems (AFAICS). You can close that for now. I guess it's mostly because make test never uses SASL (the only case I know of is test028 if you explicitly force it by setting SLAPD_USE_SASL). 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#4892) slapd HEAD crashes with ldapi:// and SASL EXTERNAL
by michael＠stroeder.com 27 Mar '07

27 Mar '07

Pierangelo Masarati wrote: > michael(a)stroeder.com wrote: > >> bdb_idl_fetch_key: [5941c014] >> <= bdb_index_read: failed (-30989) > > ^^^ > > $ grep 30989 dn.h > #define DB_OLD_VERSION (-30989)/* Out-of-date version. */ > > I guess something strange is going on with libdb run-time loading... Well, it seems you were right. Strange that make test did not reveal any problems (AFAICS). You can close that for now. Ciao, Michael.

1 0

Re: (ITS#4894) Connection refused
by bgmilne＠staff.telkomsa.net 27 Mar '07

27 Mar '07

--nextPart1606934.cSND5gyAuy Content-Type: text/plain; charset="iso-8859-6" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline On Monday 26 March 2007, mcar_bhim(a)rediffmail.com wrote: > Full_Name: Mukesh > Version: v 1.8.8.7 > OS: Microsoft Windows XP Profesional Version 2002 Service Pack 2 > URL: > Submission from: (NULL) (164.151.129.37) > > > When authenticating user through LDAP "Connection to LDAP could not be > opened. Login of user failed:" appears suddenly. This doesnot happen > regularly but suddenly slapd crash down. To avoid this we open 30 in a day > and at the end of the day we see that only 5 instances are only running. You need to provide a lot more information on this. We are doing millions of authentications per day without any problems. You should provide at least: 1)What software you are reporting this on (I am not aware of a version 1.8.= 8.7=20 of OpenLDAP) 2)Some configuration details, e.g. a sanitized slapd.conf 3)Some means of reproducing the problem with a generic (e.g. OpenLDAP=20 commandline) client =2D-=20 Buchan Milne ISP Systems Specialist - Monitoring/Authentication Team Leader B.Eng,RHCE(803004789010797),LPIC-2(LPI000074592) --nextPart1606934.cSND5gyAuy Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.7 (GNU/Linux) iD8DBQBGCQ31rJK6UGDSBKcRAnZAAJ9YPnPpJewNa4xNZNWaFCbIExTB4ACfUSud +If/rn2ZlB9kj3nh7nEbE88= =HnKz -----END PGP SIGNATURE----- --nextPart1606934.cSND5gyAuy--

1 0

Re: (ITS#4896) overlay auditlog not working in 2.3.34
by bgmilne＠staff.telkomsa.net 27 Mar '07

27 Mar '07

--nextPart1454941.Kjy3Wla0Ym Content-Type: text/plain; charset="iso-8859-6" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline On Tuesday 27 March 2007, atmp(a)yandex.ru wrote: > Full_Name: Artyom > Version: 2.3.34 > OS: linux > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (195.234.190.5) > > > In 2.3.34 overlay auditlog command is not working. > Sample slapd.conf: > ------ > loglevel any > database dbd > suffix ... > overlay auditlog /tmp/audit.log > ------- > Log file records > ------- > line XX: <overlay> extra cruft after <overlay> ignored. > ------- > > No any records will be placed in /tmp/audit.log file in case of > append/modify operations. Please see the man page for slapo-auditlog. Then, correct your configuratio= n.=20 E.g.: database dbd suffix ... overlay auditlog auditlog /tmp/audit.log I am using auditlog in production with 2.3.34. I am sure someone with sufficient rights will close this ITS. Please use th= e=20 OpenLDAP-software mailing list for configuration finger-trouble. Regards, Buchan =2D-=20 Buchan Milne ISP Systems Specialist - Monitoring/Authentication Team Leader B.Eng,RHCE(803004789010797),LPIC-2(LPI000074592) --nextPart1454941.Kjy3Wla0Ym Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.7 (GNU/Linux) iD8DBQBGCQCurJK6UGDSBKcRAiLHAKDIrC1WGqNud9iaeRgYy+iespmy5wCgqaN5 YdTAysCusHYIcCuPRzq2mWQ= =92Px -----END PGP SIGNATURE----- --nextPart1454941.Kjy3Wla0Ym--

1 0

(ITS#4896) overlay auditlog not working in 2.3.34
by atmp＠yandex.ru 27 Mar '07

27 Mar '07

Full_Name: Artyom Version: 2.3.34 OS: linux URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (195.234.190.5) In 2.3.34 overlay auditlog command is not working. Sample slapd.conf: ------ loglevel any database dbd suffix ... overlay auditlog /tmp/audit.log ------- Log file records ------- line XX: <overlay> extra cruft after <overlay> ignored. ------- No any records will be placed in /tmp/audit.log file in case of append/modify operations.

1 0

(ITS#4895) overlay auditlog not working in 2.3.34
by atmp＠yandex.ru 27 Mar '07

27 Mar '07

Full_Name: Version: 2.3.34 OS: linux URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (195.234.190.5) In 2.3.34 overlay auditlog command is not working. Sample slapd.conf: ------ loglevel any database dbd suffix ... overlay auditlog /tmp/audit.log ------- Log file records ------- line XX: <overlay> extra cruft after <overlay> ignored. ------- No any records will be placed in /tmp/audit.log file in case of append/modify operations.

1 0

(ITS#4894) Connection refused
by mcar_bhim＠rediffmail.com 26 Mar '07

26 Mar '07

Full_Name: Mukesh Version: v 1.8.8.7 OS: Microsoft Windows XP Profesional Version 2002 Service Pack 2 URL: Submission from: (NULL) (164.151.129.37) When authenticating user through LDAP "Connection to LDAP could not be opened. Login of user failed:" appears suddenly. This doesnot happen regularly but suddenly slapd crash down. To avoid this we open 30 in a day and at the end of the day we see that only 5 instances are only running.

1 0

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

openldap-bugs