openldap-bugs

openldap-bugs@openldap.org

1 participants
20967 discussions

(ITS#6717) syncprov performs unnecessary presentations/refreshes.
by cmikk＠qwest.net 19 Nov '10

19 Nov '10

Full_Name: Chris Mikkelson Version: 2.4.23 OS: FreeBSD URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (204.147.85.37) I have a multimaster setup, and some read-only slaves mirroring the data with syncrepl. In some circumstances, I've noticed that restarting a slave server leads to a full presentation, even though the masters have an adequately sized sessionlog. This makes refreshOnly synchronization prohibitively expensive. It appears that the problem is as follows: The syncprov overlay uses the minimum CSN from the client cookie to decide where to start synchronization, regardless of whether that CSN has changed relative to the same SID's CSN on the provider. For example: Provider state: CSN: <1 second ago>...#001#... CSN: <1 year ago>.....#002#... sessionlog mincsn: <1 hour ago>...#001#... Consumer state: CSN: <1 minute ago>...#001#... CSN: <1 year ago>.....#002#... <-- same as SID 2 CSN on provider The syncprov overly will take the mincsn from the consumer cookie (the <1 year ago> one above) and compare it to the sessionlog mincsn when deciding whether to do a full presentation. Since the SID 2 CSN hasn't changed in the above example, the consumer is up to date on changes recorded on SID 2, so the SID 1 CSN from the cookie should be used. To reproduce: * Set up slapd servers ID 1 and 2 as multimaster nodes, and a third slapd server replicating from server 1. * Insert one entry into server ID 2, and restart servers 1 and 2. * Insert entries into Server ID 1. * Perform enough modifications / deletions on Server ID 1 to cause entries to be purged from the sessionlog (see ITS #6716). * Wait for slave to catch up, then stop the slave. * Do any modification on Server ID 1 (only need to change the SID 1 contextCSN) * Restart slave. Server will present entries to the slave rather than replaying the session log.

1 0

(ITS#6716) syncprov sessionlog 'sl_mincsn' not assigned a value.
by cmikk＠qwest.net 19 Nov '10

19 Nov '10

Full_Name: Chris Mikkelson Version: 2.4.23 OS: FreeBSD URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (204.147.85.37) On line 2875 of servers/slapd/overlays/syncprov.c (release 2.4.23), the sessionlog mincsn is initialized to a zero-length value. if ( !sl ) { sl = ch_malloc( sizeof( sessionlog ) + LDAP_PVT_CSNSTR_BUFSIZE ); sl->sl_mincsn.bv_val = (char *)(sl+1); sl->sl_mincsn.bv_len = 0; sl->sl_num = 0; sl->sl_head = sl->sl_tail = NULL; ldap_pvt_thread_mutex_init( &sl->sl_mutex ); si->si_logs = sl; } >From there, sl->sl_mincsn isn't touched until log entries are purged from the sessionlog on line 1522: while ( sl->sl_num > sl->sl_size ) { se = sl->sl_head; sl->sl_head = se->se_next; strcpy( sl->sl_mincsn.bv_val, se->se_csn.bv_val ); sl->sl_mincsn.bv_len = se->se_csn.bv_len; ch_free( se ); sl->sl_num--; } So, after the sessionlog has its first entry recorded and before it has its first entry received, sl->sl_mincsn is a zero-length value, which means the following comparison on line 2536: if ( sl->sl_num > 0 && ber_bvcmp( &mincsn, &sl->sl_mincsn ) >= 0 ) { do_present = 0; will evaluate to true in cases where it should not. A quick fix would be to compare directly against the CSN of the sessionlog's head: --- syncprov.c.orig 2010-11-17 14:07:26.000000000 -0600 +++ syncprov.c 2010-11-19 16:50:58.000000000 -0600 @@ -2533,7 +2533,7 @@ /* Are there any log entries, and is the consumer state * present in the session log? */ - if ( sl->sl_num > 0 && ber_bvcmp( &mincsn, &sl->sl_mincsn ) >= 0 ) { + if ( sl->sl_num > 0 && ber_bvcmp( &mincsn, &sl->sl_head->se_csn ) >= 0 ) { do_present = 0; /* mutex is unlocked in playlog */ syncprov_playlog( op, rs, sl, srs, ctxcsn, numcsns, sids );

1 0

Re: ITS#6713
by masarati＠aero.polimi.it 19 Nov '10

19 Nov '10

DevMan wrote: > Please let me know the upgradation procedure. <http://www.openldap.org/doc/admin24/install.html> In general, <http://www.openldap.org/doc/admin24/index.html> p.

1 0

Re: ITS#6713
by devman1624＠yahoo.com 19 Nov '10

19 Nov '10

Please let me know the upgradation procedure. Thx DevMan Sent from my iPhone On Nov 18, 2010, at 3:33 PM, Pierangelo Masarati <masarati(a)aero.polimi.it> w= rote: > Please note that the current release is 2.4.23; since 2.4.16 many issues h= ave been fixed. If the problem persists after upgrading, please make sure y= ou provide useful information, as illustrated here <http://www.openldap.org/= faq/data/cache/56.html> and in subordinate links. >=20 > p.

1 0

(ITS#6715) Broken 'sortvals' for attr with 1 value
by h.b.furuseth＠usit.uio.no 19 Nov '10

19 Nov '10

Full_Name: Hallvard B Furuseth Version: 2.4.23 OS: URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (129.240.6.233) Submitted by: hallvard slapd.conf:'sortvals ATTR' sometimes complains attributeType ATTR value #1 provided more than once when ATTR has one value, because slapd/modify.c:slap_sort_vals() then leaves the result value 'rc' uninitialized. Fixing.

1 0

(ITS#6714) Patch - Mozilla NSS - implement full non-blocking semantics
by rmeggins＠redhat.com 18 Nov '10

18 Nov '10

Full_Name: Rich Megginson Version: 2.4.23 (current CVS HEAD) OS: RHEL6 URL: ftp://ftp.openldap.org/incoming/openldap-2.4.23-use-non-blocking-semantics-… Submission from: (NULL) (76.113.111.209) This patch implements full non-blocking semantics for the MozNSS crypto implementation in the same manner as the openssl and gnutls implementations. SSL_ForceHandshake can be called repeatedly until it gets enough data to complete. One wrinkle is that, when SSL_ForceHandshake returns PR_WOULD_BLOCK_ERROR, we have no way of knowing if it needs data for a read or a write (a la openssl SSL_ERROR_WANT_WRITE and SSL_ERROR_WANT_READ). In order to keep track of that, we use the io_flag in the tls_data object - if the last operation called was a read/recv, we set the io_flag to TLSM_READ, and similar for send/write and TLSM_WRITE. This way, the upflags function knows how to set the sbiod needs_read and needs_write flags appropriately. I also added special handling for the common case where the client uses ldapTOOL -Z and the TLS fails from the client side (e.g. bogus CA cert file). In this case, tlsm_session_accept will get a plain LDAP message beginning with LBER_SEQUENCE instead of a valid SSL header. The code can short circuit the process and return a more meaningful error message. The tlsm_is_io_ready() function is now obsolete - keeping track of the io_flag, plus using the function SSL_DataPending(), removes the need for the former function. I added a convenience function tlsm_get_pvt_tls_data() to get the tls_data associated with the tlsm_session (secure PRFileDesc). This patch file is derived from OpenLDAP Software. All of the modifications to OpenLDAP Software represented in the following patch(es) were developed by Red Hat. Red Hat has not assigned rights and/or interest in this work to any party. I, Rich Megginson am authorized by Red Hat, my employer, to release this work under the following terms. Red Hat hereby place the following modifications to OpenLDAP Software (and only these modifications) into the public domain. Hence, these modifications may be freely used and/or redistributed for any purpose with or without attribution and/or other notice.

1 0

ITS#6712
by masarati＠aero.polimi.it 18 Nov '10

18 Nov '10

Thanks for the report. "hasSubordinates" is generated, not stored in the database; this may explain why multiple values appear despite its "single-valuedness". I'm investigating... p.

1 0

ITS#6713
by masarati＠aero.polimi.it 18 Nov '10

18 Nov '10

Please note that the current release is 2.4.23; since 2.4.16 many issues have been fixed. If the problem persists after upgrading, please make sure you provide useful information, as illustrated here <http://www.openldap.org/faq/data/cache/56.html> and in subordinate links. p.

1 0

(ITS#6713) slad crashing automatically in production server
by devman1624＠yahoo.com 18 Nov '10

18 Nov '10

Full_Name: DevMan Version: 2.4.16 OS: RHEL5.4 64 bit URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (12.191.136.3) Hi All, I am facing issue in my prod server. PLease find the below details: DS: Openldap2.4.16(2 Multimaster with one slave) Database: BDB4.7.25 OS: RHEL5.4 64 bit Number of databases: 2 Number of entries in one database is 9lakhs and in second database is 2000. RAM: 2GB CPU: 2(Model name: Intel(R) Xeon(R) CPU E5504 @ 2.00GHz) Issue: slapd automatically killed once in a day or some time 3 in a day. I have run the below command and found segfault error 4: [root@MYINSGGNSBILDAP2 openldap]# dmesg |grep slapd slapd[30387]: segfault at 0000000000000017 rip 00000000004dca25 rsp 00007fff61425f80 error 4 slapd[32121]: segfault at 0000000000000048 rip 0000003cd8008950 rsp 0000000042554948 error 4 slapd[1013]: segfault at 0000000000000048 rip 0000003cd8008950 rsp 000000004233c948 error 4 slapd[13060]: segfault at 0000000000000000 rip 0000003cd747997a rsp 00000000422408e8 error 4 slapd[24417]: segfault at 0000000000000008 rip 000000000048d6b2 rsp 0000000046333560 error 4 slapd[694]: segfault at 0000000000000008 rip 000000000048d6b2 rsp 0000000043cfa560 error 4 slapd[1068]: segfault at 0000000000000008 rip 000000000048d6b2 rsp 0000000041446560 error 4 slapd[5557]: segfault at 0000000000000008 rip 000000000048d6b2 rsp 0000000041fd2560 error 4 slapd[15633]: segfault at 0000000000000008 rip 000000000048d6b2 rsp 0000000041a9d560 error 4 slapd[31922]: segfault at 0000000000000008 rip 000000000048d6b2 rsp 0000000043312560 error 4 slapd[13961]: segfault at 0000000000000000 rip 0000003cd747997a rsp 000000004230f4e8 error 4 slapd[14807]: segfault at 0000000000000048 rip 0000003cd8008950 rsp 0000000041523948 error 4 Please help me here to resolve this problem. Thx DevMan

1 0

(ITS#6712) dont-use-copy/syncrepl/chain hasSubordinates extra vals
by david.delaharpe.golden＠ichec.ie 17 Nov '10

17 Nov '10

Full_Name: David De La Harpe Golden (ICHEC) Version: 2.4.23 OS: debian/unstable URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (193.1.200.66) I was playing with the experimental "dont-use-copy" ldap control in conjunction with a basic test provider-consumer syncrepl setup and chain overlay back to the provider on the consumer. I realise the control is experimental and the issue is not major, but anyway, better to report these things: Seems that when the control is used in a search request to the consumer, hasSubordinates on the returned value is getting extra values. As hasSubordinates is AFAICS defined as a single-value attribute, that's strange. # e.g. Test using python-ldap import ldap from ldap.controls import LDAPControl class _ExpDontUseCopyControl(LDAPControl): controlType = '1.3.6.1.4.1.4203.666.5.15' provider = ldap.open('localhost', 3389) consumer = ldap.open('localhost', 389) provider.bind('cn=something,dc=example,dc=com', 'somepw') consumer.bind('cn=something,dc=example,dc=com', 'somepw') provider.search_ext_s('cn=foo,dc=example,dc=com', ldap.SCOPE_BASE, '(objectClass=*)', ['hasSubordinates'], serverctrls=[]) => [('cn=foo,dc=example,dc=com', {'hasSubordinates': ['FALSE']})] provider.search_ext_s('cn=foo,dc=example,dc=com', ldap.SCOPE_BASE, '(objectClass=*)', ['hasSubordinates'], serverctrls=[_ExpDontUseCopyControl(True)]) => [('cn=foo,dc=example,dc=com', {'hasSubordinates': ['FALSE']})] consumer.search_ext_s('cn=foo,dc=example,dc=com', ldap.SCOPE_BASE, '(objectClass=*)', ['hasSubordinates'], serverctrls=[]) => [('cn=foo,dc=example,dc=com', {'hasSubordinates': ['FALSE']})] consumer.search_ext_s('cn=foo,dc=example,dc=com', ldap.SCOPE_BASE, '(objectClass=*)', ['hasSubordinates'], serverctrls=[_ExpDontUseCopyControl(True)]) => [('cn=foo,dc=example,dc=com', {'hasSubordinates': ['FALSE', 'FALSE']})]

1 0

Jump to page:

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

openldap-bugs