openldap-bugs March 2010

openldap-bugs@openldap.org

31 participants
72 discussions

(ITS#6503) syncrepl provider sends entryUUIDs of all LDAP records to consumer when consumer slapd is started
by bcolston＠xtec.com 31 Mar '10

31 Mar '10

Full_Name: Barry Colston Version: 2.4.21 OS: Fedora 12 URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (209.255.208.210) When a consumer slapd is started, if the provider slapd has had only Add operations performed while the consumer slapd was down, the provider slapd sends the consumer slapd the entryUUIDs of all records in the provider database. Note: this is not a list of all records that have been added/changed/deleted since the previous synchronization based on the consumer's contextCSN, it is a list of all records in the LDAP database (for some of our customers, this is 10,000,000 entryUUIDs that are returned to the consumer slapd.) The scenario to reproduce this problem is: 1. Start provider slapd 2. Start consumer slapd 3. Ensure that provider contextCSN matches consumer contextCSN 4. Shutdown consumer slapd 5. Add records to provider slapd (1 record is sufficient to create the problem) 6. Start consumer slapd with debug turned on (so the messages being sent can be viewed). The consumer slapd receives 1 to N LDAP_RES_INTERMEDIATE SYNC_ID_SETs (message type = 121) containing the entryUUIDs of the records in the provider's database, followed by a LDAP_RES_SEARCH_ENTRY, LDAP_SYNC_ADD (message type = 100) message for each record added to the provider, then finally a LDAP_RES_INTERMEDIATE, REFRESH_PRESENT message (message type = 121) message containing the provider's sync cookie. I am running OpenLDAP 2.4.21 with Berkeley 4.6.21 (with all patches) on Fedora 12. Running sync replication in RefreshAndPersist mode. Note: if at least 1 Modify or Delete operation is performed against the provider slapd while the consumer slapd is down, when the consumer slapd is started, the provider slapd does NOT send the Sync ID sets containing the entryUUIDs of all records in the provider database.

1 0

Re: (ITS#6488) Nssov updates for new versions of nss-pam-ldapd
by crispy＠cluenet.org 31 Mar '10

31 Mar '10

Hi, any word on if this can be incorporated? Thanks. On Sun, 2010-03-07 at 01:24 +0000, openldap-its(a)OpenLDAP.org wrote: > *** THIS IS AN AUTOMATICALLY GENERATED REPLY *** > > Thanks for your report to the OpenLDAP Issue Tracking System. Your > report has been assigned the tracking number ITS#6488. > > One of our support engineers will look at your report in due course. > Note that this may take some time because our support engineers > are volunteers. They only work on OpenLDAP when they have spare > time. > > If you need to provide additional information in regards to your > issue report, you may do so by replying to this message. Note that > any mail sent to openldap-its(a)openldap.org with (ITS#6488) > in the subject will automatically be attached to the issue report. > > mailto:openldap-its@openldap.org?subject=(ITS#6488) > > You may follow the progress of this report by loading the following > URL in a web browser: > http://www.OpenLDAP.org/its/index.cgi?findid=6488 > > Please remember to retain your issue tracking number (ITS#6488) > on any further messages you send to us regarding this report. If > you don't then you'll just waste our time and yours because we > won't be able to properly track the report. > > Please note that the Issue Tracking System is not intended to > be used to seek help in the proper use of OpenLDAP Software. > Such requests will be closed. > > OpenLDAP Software is user supported. > http://www.OpenLDAP.org/support/ > > -------------- > Copyright 1998-2007 The OpenLDAP Foundation, All Rights Reserved. >

1 0

Re: (ITS#6501) DBTzeros in bdb/hdb
by hyc＠symas.com 30 Mar '10

30 Mar '10

mbackes(a)symas.com wrote: > Full_Name: Matthew Backes > Version: 2.4, HEAD > OS: any > URL: > Submission from: (NULL) (76.88.107.46) > > > The lockobj's in BDB aren't being DBTzero()'d fully before use; they > consist of more than just .data and .size, so this leaves uninit > memory that gets branched on. > > Needs to be applied to HEAD and 2.4. (2.3 as well, for those still > tracking that for some reason, probably all branches with BDB/HDB) Thanks, fixed in HEAD. The dn2id.c patch is obsolete, that function is no longer used. > > Patch vs HEAD: > > =================================================================== > RCS file: /repo/OpenLDAP/pkg/ldap/servers/slapd/back-bdb/cache.c,v > retrieving revision 1.214 > diff -u -u -r1.214 cache.c > --- cache.c 4 Nov 2009 05:09:51 -0000 1.214 > +++ cache.c 29 Mar 2010 16:41:59 -0000 > @@ -184,6 +184,7 @@ > > if ( !lock ) return 0; > > + DBTzero(&lockobj ); > lockobj.data =&ei->bei_id; > lockobj.size = sizeof(ei->bei_id) + 1; > > @@ -225,6 +226,7 @@ > else > db_rw = DB_LOCK_READ; > > + DBTzero(&lockobj ); > lockobj.data =&ei->bei_id; > lockobj.size = sizeof(ei->bei_id) + 1; > > Index: dn2id.c > =================================================================== > RCS file: /repo/OpenLDAP/pkg/ldap/servers/slapd/back-bdb/dn2id.c,v > retrieving revision 1.169 > diff -u -u -r1.169 dn2id.c > --- dn2id.c 15 Feb 2010 14:25:47 -0000 1.169 > +++ dn2id.c 29 Mar 2010 16:41:59 -0000 > @@ -42,6 +42,7 @@ > else > db_rw = DB_LOCK_READ; > > + DBTzero(&lockobj ); > lockobj.data = dn->bv_val; > lockobj.size = dn->bv_len; > > -- -- Howard Chu CTO, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc/ Chief Architect, OpenLDAP http://www.openldap.org/project/

1 0

Re: (ITS#6055) Re: Samba4 need 'name' implementation like AD (RDN-Name)
by masarati＠aero.polimi.it 30 Mar '10

30 Mar '10

> On Tue, 2010-03-02 at 15:30 +1100, Andrew Bartlett wrote: >> On Mon, 2009-08-03 at 20:44 +0200, masarati(a)aero.polimi.it wrote: >> > [Resending because I forgot the ITS number in the subject] >> > >> > I have a simple prototype that on add/modrdn populates/maintains an >> > attribute (rdnValue) with the distinguished values of the naming >> > attributes of the RDN. While doing this, it also checks for >> uniqueness of >> > the rdnValue value within siblings. >> > >> > You can find it here >> > <ftp://ftp.openldap.org/incoming/pierangelo-masarati-2009-08-03-rdnval.2.c> >> > >> > Please test and comment. I hope it does what intended. >> >> I'm starting to look at this now. I'm sorry so many months have past >> since you posted it. > > I've now added it into Samba's provision, and using the diff I attach, > against current 'master', I get the attached error. > > It seems to be unable to add the base DN. (The very first entry in the > database). Try this: <www.aero.polimi.it/masarati/Download/pierangelo-masarati-2010-03-30-rdnval.…>. In fact, when adding the suffix entry, the overlay was erroneously checking its siblings from its superior, which is very likely to fail. p.

1 0

Re: (ITS#6500) get_ldap_property returns stale data from time to time
by alinachegalati＠yahoo.com 30 Mar '10

30 Mar '10

--0-808694875-1269950414=:35747 Content-Type: text/plain; charset=us-ascii i was using the deprecated function from openldap. i switched to ldap_value_free_len, i'll run more tests to see if i still have the problem. ________________________________ From: "masarati(a)aero.polimi.it" <masarati(a)aero.polimi.it> To: alinachegalati(a)yahoo.com Cc: openldap-its(a)openldap.org Sent: Tue, March 30, 2010 7:15:51 AM Subject: Re: (ITS#6500) get_ldap_property returns stale data from time to time Not clear why you think this is an OpenLDAP bug. There's too little information to determine whether your application is using OpenLDAP's client library correctly. p. > Full_Name: Alin Vasile > Version: 2.4.19 > OS: SuSE 11 > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (194.237.142.17) > > > Hi, > > In a high load apache environment I am performing some ldap searches for > some > requests using a custom developed application and the OpenLdap client > libraries. >>From time to time I have the following segmentation fault: > > Program terminated with signal 11, Segmentation fault. > #0 0x00000000004033b9 in get_ldap_property (ldap=0x764870, > entry=0x841160, > attribute=0x87aa50 "smIMEI", context=0x76fc38) > at ldap_query.c:30 > 30 if ( v != NULL && v[0] != NULL ) { > (gdb) backtrace > #0 0x00000000004033b9 in get_ldap_property (ldap=0x764870, > entry=0x841160, > attribute=0x87aa50 "smIMEI", context=0x76fc38) > at ldap_query.c:30 > #1 0x00000000004040f7 in query (pool=0x76fc38, ep=0x610290, > ldap_request=0x76ff60) at ldap_query.c:353 > > And the function is : > > char * get_ldap_property(LDAP* ldap, LDAPMessage *entry, char* attribute, > apr_pool_t* context) { > > char ** v = ldap_get_values(ldap, entry, attribute); > > if ( v != NULL && v[0] != NULL ) { > char* ret = apr_pstrdup(context, v[0] ); > ldap_value_free( v ); > return ret; > } > > return NULL; > > } > > Note that most of the queries (99%) work fine. > > Did anyone experienced something simmilar? > > Thanks, > Alin > --0-808694875-1269950414=:35747 Content-Type: text/html; charset=us-ascii <html><head><style type="text/css"></style></head><body><div style="font-family:times new roman,new york,times,serif;font-size:12pt"><div> </div><div style="font-family: times new roman,new york,times,serif; font-size: 12pt;">i was using the deprecated function from openldap. i switched to ldap_value_free_len, i'll run more tests to see if  i still have the problem. <div style="font-family: arial,helvetica,sans-serif; font-size: 13px;"><hr size="1">From: "masarati(a)aero.polimi.it" <masarati(a)aero.polimi.it> To: alinachegalati(a)yahoo.com Cc: openldap-its(a)openldap.org Sent: Tue, March 30, 2010 7:15:51 AM Subject: Re: (ITS#6500) get_ldap_property returns stale data from time to time Not clear why you think this is an OpenLDAP bug.  There's too little information to determine whether your application is using OpenLDAP's client library correctly. p. > Full_Name: Alin Vasile > Version: 2.4.19 > OS: SuSE 11 > URL: <a href="ftp://ftp.openldap.org/incoming/" target="_blank">ftp://ftp.openldap.org/incoming/</a> > Submission from: (NULL) (194.237.142.17) > > > Hi, > >  In a high load apache environment I am performing some ldap searches for > some > requests using a custom developed application and the OpenLdap client > libraries. >>From time to time I have the following segmentation fault: > > Program terminated with signal 11, Segmentation fault. > #0  0x00000000004033b9 in get_ldap_property (ldap=0x764870, > entry=0x841160, > attribute=0x87aa50 "smIMEI", context=0x76fc38) >    at ldap_query.c:30 > 30          if ( v != NULL && v[0] != NULL ) { > (gdb) backtrace > #0  0x00000000004033b9 in get_ldap_property (ldap=0x764870, > entry=0x841160, > attribute=0x87aa50 "smIMEI", context=0x76fc38) >    at ldap_query.c:30 > #1  0x00000000004040f7 in query (pool=0x76fc38, ep=0x610290, > ldap_request=0x76ff60) at ldap_query.c:353 > > And the function is : > > char * get_ldap_property(LDAP* ldap, LDAPMessage *entry, char* attribute, > apr_pool_t* context) { > >    char ** v = ldap_get_values(ldap, entry, attribute); > >    if ( v != NULL && v[0] != NULL ) { >        char* ret = apr_pstrdup(context,  v[0] ); >        ldap_value_free( v ); >        return ret; >    } > >    return NULL; > > } > > Note that most of the queries (99%) work fine. > > Did anyone experienced something simmilar? > > Thanks, > Alin > </div></div> </div> </body></html> --0-808694875-1269950414=:35747--

1 0

Re: (ITS#6502) Build failure tls_g.c
by hyc＠symas.com 30 Mar '10

30 Mar '10

This is a dup of ITS#5930 (and probably a few others). Solaris ships with a prehistoric version of GnuTLS (even before they added version stamps to the gnutls.h header file). You cannot use it. Use OpenSSL or install a recent version of GnuTLS instead. kenneth.greiner(a)paetec.com wrote: > Full_Name: Ken Greiner > Version: 2.4.21 > OS: SunOS 5.10 Generic_141445-09 i86pc i386 i86pc > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (64.80.108.55) > > > ./configure --disable-slapd --prefix=$HOME > OK > ./make depend > OK > ./make > ... lots of good stuff.. then -> > > /bin/sh ../../libtool --mode=compile gcc -g -O2 -I../../include > -I../../include -DLDAP_LIBRARY -c tls_g.c > gcc -g -O2 -I../../include -I../../include -DLDAP_LIBRARY -c tls_g.c -fPIC > -DPIC -o .libs/tls_g.o > tls_g.c:73: error: syntax error before "gnutls_kx_algorithm_t" > tls_g.c:73: warning: no semicolon at end of struct or union > tls_g.c:74: warning: data definition has no type or storage class > tls_g.c:75: error: syntax error before "mac" > tls_g.c:75: warning: data definition has no type or storage class > .. and so on. > oops! Failed on this tls_g.c file. > > -- -- Howard Chu CTO, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc/ Chief Architect, OpenLDAP http://www.openldap.org/project/

1 0

Re: (ITS#6500) get_ldap_property returns stale data from time to time
by masarati＠aero.polimi.it 29 Mar '10

29 Mar '10

Not clear why you think this is an OpenLDAP bug. There's too little information to determine whether your application is using OpenLDAP's client library correctly. p. > Full_Name: Alin Vasile > Version: 2.4.19 > OS: SuSE 11 > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (194.237.142.17) > > > Hi, > > In a high load apache environment I am performing some ldap searches for > some > requests using a custom developed application and the OpenLdap client > libraries. >>From time to time I have the following segmentation fault: > > Program terminated with signal 11, Segmentation fault. > #0 0x00000000004033b9 in get_ldap_property (ldap=0x764870, > entry=0x841160, > attribute=0x87aa50 "smIMEI", context=0x76fc38) > at ldap_query.c:30 > 30 if ( v != NULL && v[0] != NULL ) { > (gdb) backtrace > #0 0x00000000004033b9 in get_ldap_property (ldap=0x764870, > entry=0x841160, > attribute=0x87aa50 "smIMEI", context=0x76fc38) > at ldap_query.c:30 > #1 0x00000000004040f7 in query (pool=0x76fc38, ep=0x610290, > ldap_request=0x76ff60) at ldap_query.c:353 > > And the function is : > > char * get_ldap_property(LDAP* ldap, LDAPMessage *entry, char* attribute, > apr_pool_t* context) { > > char ** v = ldap_get_values(ldap, entry, attribute); > > if ( v != NULL && v[0] != NULL ) { > char* ret = apr_pstrdup(context, v[0] ); > ldap_value_free( v ); > return ret; > } > > return NULL; > > } > > Note that most of the queries (99%) work fine. > > Did anyone experienced something simmilar? > > Thanks, > Alin >

1 0

(ITS#6502) Build failure tls_g.c
by kenneth.greiner＠paetec.com 29 Mar '10

29 Mar '10

Full_Name: Ken Greiner Version: 2.4.21 OS: SunOS 5.10 Generic_141445-09 i86pc i386 i86pc URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (64.80.108.55) ./configure --disable-slapd --prefix=$HOME OK ./make depend OK ./make ... lots of good stuff.. then -> /bin/sh ../../libtool --mode=compile gcc -g -O2 -I../../include -I../../include -DLDAP_LIBRARY -c tls_g.c gcc -g -O2 -I../../include -I../../include -DLDAP_LIBRARY -c tls_g.c -fPIC -DPIC -o .libs/tls_g.o tls_g.c:73: error: syntax error before "gnutls_kx_algorithm_t" tls_g.c:73: warning: no semicolon at end of struct or union tls_g.c:74: warning: data definition has no type or storage class tls_g.c:75: error: syntax error before "mac" tls_g.c:75: warning: data definition has no type or storage class .. and so on. oops! Failed on this tls_g.c file.

1 0

(ITS#6501) DBTzeros in bdb/hdb
by mbackes＠symas.com 29 Mar '10

29 Mar '10

Full_Name: Matthew Backes Version: 2.4, HEAD OS: any URL: Submission from: (NULL) (76.88.107.46) The lockobj's in BDB aren't being DBTzero()'d fully before use; they consist of more than just .data and .size, so this leaves uninit memory that gets branched on. Needs to be applied to HEAD and 2.4. (2.3 as well, for those still tracking that for some reason, probably all branches with BDB/HDB) Patch vs HEAD: =================================================================== RCS file: /repo/OpenLDAP/pkg/ldap/servers/slapd/back-bdb/cache.c,v retrieving revision 1.214 diff -u -u -r1.214 cache.c --- cache.c 4 Nov 2009 05:09:51 -0000 1.214 +++ cache.c 29 Mar 2010 16:41:59 -0000 @@ -184,6 +184,7 @@ if ( !lock ) return 0; + DBTzero( &lockobj ); lockobj.data = &ei->bei_id; lockobj.size = sizeof(ei->bei_id) + 1; @@ -225,6 +226,7 @@ else db_rw = DB_LOCK_READ; + DBTzero( &lockobj ); lockobj.data = &ei->bei_id; lockobj.size = sizeof(ei->bei_id) + 1; Index: dn2id.c =================================================================== RCS file: /repo/OpenLDAP/pkg/ldap/servers/slapd/back-bdb/dn2id.c,v retrieving revision 1.169 diff -u -u -r1.169 dn2id.c --- dn2id.c 15 Feb 2010 14:25:47 -0000 1.169 +++ dn2id.c 29 Mar 2010 16:41:59 -0000 @@ -42,6 +42,7 @@ else db_rw = DB_LOCK_READ; + DBTzero( &lockobj ); lockobj.data = dn->bv_val; lockobj.size = dn->bv_len;

1 0

(ITS#6500) get_ldap_property returns stale data from time to time
by alinachegalati＠yahoo.com 29 Mar '10

29 Mar '10

Full_Name: Alin Vasile Version: 2.4.19 OS: SuSE 11 URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (194.237.142.17) Hi, In a high load apache environment I am performing some ldap searches for some requests using a custom developed application and the OpenLdap client libraries. >From time to time I have the following segmentation fault: Program terminated with signal 11, Segmentation fault. #0 0x00000000004033b9 in get_ldap_property (ldap=0x764870, entry=0x841160, attribute=0x87aa50 "smIMEI", context=0x76fc38) at ldap_query.c:30 30 if ( v != NULL && v[0] != NULL ) { (gdb) backtrace #0 0x00000000004033b9 in get_ldap_property (ldap=0x764870, entry=0x841160, attribute=0x87aa50 "smIMEI", context=0x76fc38) at ldap_query.c:30 #1 0x00000000004040f7 in query (pool=0x76fc38, ep=0x610290, ldap_request=0x76ff60) at ldap_query.c:353 And the function is : char * get_ldap_property(LDAP* ldap, LDAPMessage *entry, char* attribute, apr_pool_t* context) { char ** v = ldap_get_values(ldap, entry, attribute); if ( v != NULL && v[0] != NULL ) { char* ret = apr_pstrdup(context, v[0] ); ldap_value_free( v ); return ret; } return NULL; } Note that most of the queries (99%) work fine. Did anyone experienced something simmilar? Thanks, Alin

1 0

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

openldap-bugs March 2010