(ITS#6716) syncprov sessionlog 'sl_mincsn' not assigned a value.
by cmikk＠qwest.net
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 );
12 years, 10 months
Re: ITS#6713
by devman1624＠yahoo.com
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.
12 years, 10 months
(ITS#6715) Broken 'sortvals' for attr with 1 value
by h.b.furuseth＠usit.uio.no
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.
12 years, 10 months
(ITS#6714) Patch - Mozilla NSS - implement full non-blocking semantics
by rmeggins＠redhat.com
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-semantic...
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.
12 years, 10 months
ITS#6712
by masarati＠aero.polimi.it
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.
12 years, 10 months
ITS#6713
by masarati＠aero.polimi.it
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.
12 years, 10 months
(ITS#6713) slad crashing automatically in production server
by devman1624＠yahoo.com
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
12 years, 10 months
(ITS#6712) dont-use-copy/syncrepl/chain hasSubordinates extra vals
by david.delaharpe.golden＠ichec.ie
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']})]
12 years, 10 months
(ITS#6711) Problems with ppolicy_forward_updates and starttls with certificate-based auth
by subbarao＠computer.org
Full_Name: Kartik Subbarao
Version: 2.4.23
OS: Debian Linux 5.0.5
URL: ftp://ftp.openldap.org/incoming/kartik_subbarao.101116.tgz
Submission from: (NULL) (76.99.175.5)
I'm trying to get a consumer server to forward ppolicy-related updates to its
provider server, and to use certificate-based authentication (SASL EXTERNAL)
over STARTTLS when authenticating to the provider.
I'm running into multiple problems here. The core problem seems to be that
enabling ppolicy_forward_updates breaks the chaining overlay such that it binds
anonymously instead of with SASL EXTERNAL. Another problem is that bind
operations to the consumer server start to return two result messages -- one
with the error code of the chained operation, and one with the error code of the
bind operation.
To simplify reproducing the problem, I've worked with test022-ppolicy in the
openldap test framework. Here, I ran into another issue. I can't seem to be able
to configure sasl external/starttls chaining properly with the cn=config style
configuration that test022-ppolicy applies. The self-signed cert that I'm using
works fine with replication, but it doesn't seem to work with chaining. This may
or may not be another issue that needs to be resolved.
In any case, with the attached files in the ITS, I hope that what I'm trying to
do and the results that I'm getting should be as clear as possible.
12 years, 10 months
