(ITS#6503) syncrepl provider sends entryUUIDs of all LDAP records to consumer when consumer slapd is started
by bcolston＠xtec.com
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.
13 years, 8 months
Re: (ITS#6488) Nssov updates for new versions of nss-pam-ldapd
by crispy＠cluenet.org
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.
>
13 years, 8 months
Re: (ITS#6501) DBTzeros in bdb/hdb
by hyc＠symas.com
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/
13 years, 8 months
Re: (ITS#6055) Re: Samba4 need 'name' implementation like AD (RDN-Name)
by masarati＠aero.polimi.it
> 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-rdnva...>.
In fact, when adding the suffix entry, the overlay was erroneously
checking its siblings from its superior, which is very likely to fail.
p.
13 years, 8 months
Re: (ITS#6500) get_ldap_property returns stale data from time to time
by alinachegalati＠yahoo.com
--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"><!-- DIV {margin:0px;} --></style></head><body><div style="font-family:times new roman,new york,times,serif;font-size:12pt"><div><br></div><div style="font-family: times new roman,new york,times,serif; font-size: 12pt;">i was using the deprecated function from openldap.<br><br>i switched to ldap_value_free_len, i'll run more tests to see if i still have the problem.<br><br><div style="font-family: arial,helvetica,sans-serif; font-size: 13px;"><font size="2" face="Tahoma"><hr size="1"><b><span style="font-weight: bold;">From:</span></b> "masarati(a)aero.polimi.it" <masarati(a)aero.polimi.it><br><b><span style="font-weight: bold;">To:</span></b> alinachegalati(a)yahoo.com<br><b><span style="font-weight: bold;">Cc:</span></b> openldap-its(a)openldap.org<br><b><span style="font-weight: bold;">Sent:</span></b> Tue, March 30, 2010 7:15:51 AM<br><b><span style="font-weight: bold;">Subject:</span></b> Re: (ITS#6500)
get_ldap_property returns stale data from time to time<br></font><br>
Not clear why you think this is an OpenLDAP bug. There's too little<br>information to determine whether your application is using OpenLDAP's<br>client library correctly.<br><br>p.<br><br>> Full_Name: Alin Vasile<br>> Version: 2.4.19<br>> OS: SuSE 11<br>> URL: <a href="ftp://ftp.openldap.org/incoming/" target="_blank">ftp://ftp.openldap.org/incoming/</a><br>> Submission from: (NULL) (194.237.142.17)<br>><br>><br>> Hi,<br>><br>> In a high load apache environment I am performing some ldap searches for<br>> some<br>> requests using a custom developed application and the OpenLdap client<br>> libraries.<br>>>From time to time I have the following segmentation fault:<br>><br>> Program terminated with signal 11, Segmentation fault.<br>> #0 0x00000000004033b9 in get_ldap_property (ldap=0x764870,<br>> entry=0x841160,<br>> attribute=0x87aa50 "smIMEI", context=0x76fc38)<br>>
at ldap_query.c:30<br>> 30 if ( v != NULL && v[0] != NULL ) {<br>> (gdb) backtrace<br>> #0 0x00000000004033b9 in get_ldap_property (ldap=0x764870,<br>> entry=0x841160,<br>> attribute=0x87aa50 "smIMEI", context=0x76fc38)<br>> at ldap_query.c:30<br>> #1 0x00000000004040f7 in query (pool=0x76fc38, ep=0x610290,<br>> ldap_request=0x76ff60) at ldap_query.c:353<br>><br>> And the function is :<br>><br>> char * get_ldap_property(LDAP* ldap, LDAPMessage *entry, char* attribute,<br>> apr_pool_t* context) {<br>><br>> char ** v = ldap_get_values(ldap, entry, attribute);<br>><br>> if ( v != NULL && v[0] != NULL ) {<br>> char* ret = apr_pstrdup(context, v[0] );<br>> ldap_value_free( v );<br>> return
ret;<br>> }<br>><br>> return NULL;<br>><br>> }<br>><br>> Note that most of the queries (99%) work fine.<br>><br>> Did anyone experienced something simmilar?<br>><br>> Thanks,<br>> Alin<br>><br><br><br></div></div>
</div><br>
</body></html>
--0-808694875-1269950414=:35747--
13 years, 8 months
Re: (ITS#6502) Build failure tls_g.c
by hyc＠symas.com
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/
13 years, 8 months
Re: (ITS#6500) get_ldap_property returns stale data from time to time
by masarati＠aero.polimi.it
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
>
13 years, 8 months
(ITS#6502) Build failure tls_g.c
by kenneth.greiner＠paetec.com
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.
13 years, 8 months
(ITS#6501) DBTzeros in bdb/hdb
by mbackes＠symas.com
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;
13 years, 8 months
(ITS#6500) get_ldap_property returns stale data from time to time
by alinachegalati＠yahoo.com
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
13 years, 8 months
