openldap-bugs November 2012

openldap-bugs@openldap.org

30 participants
100 discussions

Start a nNew thread

Re: (ITS#7431) seg fault in constraint_check_restrict at constraint.c:713
by michael＠stroeder.com 04 Nov '12

04 Nov '12

It also works when using constraint.c of OpenLDAP release 2.4.33. Maybe it's caused by fix for ITS#7418?

1 0

Re: (ITS#7431) seg fault in constraint_check_restrict at constraint.c:713
by michael＠stroeder.com 04 Nov '12

04 Nov '12

It works when using constraint.c of OpenLDAP release 2.4.32.

1 0

(ITS#7431) seg fault in constraint_check_restrict at constraint.c:713
by michael＠stroeder.com 04 Nov '12

04 Nov '12

Full_Name: Version: RE24 8f66d7dbad977c9186e010a52f0183b5d532acc9 OS: openSUSE 12.2 x86_64 URL: Submission from: (NULL) (79.227.185.139) I get a seg fault when adding group entries with some regex-constrained attributes. This is RE24 with the recent fixes for slapo-constraint. The constraint setup works with 2.4.31. Strange thing is that the entry is added to the database. So it seems to me that the seg fault happens after that while checking constraints for what slapo-memberof does? As often this is a complex customer setup. So it's not that easy to narrow down the config and strip aways private customer data in a full traceback. I will do if really necessary. Maybe this gives a first hint where to look: No symbol "info" in current context. (gdb) info threads Id Target Id Frame 8 Thread 0x7faed2024700 (LWP 25001) 0x00007faee54448f4 in pthread_cond_wait@@GLIBC_2.3.2 () from /lib64/libpthread.so.0 7 Thread 0x7faed1823700 (LWP 25002) 0x00007faee54448f4 in pthread_cond_wait@@GLIBC_2.3.2 () from /lib64/libpthread.so.0 6 Thread 0x7faed2825700 (LWP 25000) 0x00007faee54448f4 in pthread_cond_wait@@GLIBC_2.3.2 () from /lib64/libpthread.so.0 5 Thread 0x7faed8d6a700 (LWP 24999) 0x00007faee54448f4 in pthread_cond_wait@@GLIBC_2.3.2 () from /lib64/libpthread.so.0 4 Thread 0x7faedc62d700 (LWP 24998) 0x00007faee44ce8a3 in epoll_wait () from /lib64/libc.so.6 3 Thread 0x7faee41d2700 (LWP 24995) 0x00007faee5441fef in pthread_join () from /lib64/libpthread.so.0 2 Thread 0x7faed1022700 (LWP 25003) 0x00007faee54448f4 in pthread_cond_wait@@GLIBC_2.3.2 () from /lib64/libpthread.so.0 * 1 Thread 0x7faecbfff700 (LWP 25004) 0x00007faedfeccf89 in constraint_check_restrict (op=0x7faecbffdd80, c=0xf8c550, e=0x0) at constraint.c:713

1 0

(ITS#7430) building with gnutls-3.0.x fails
by travisghansen＠yahoo.com 03 Nov '12

03 Nov '12

Full_Name: Travis Glenn Hansen Version: openldap-2.4.33 OS: gentoo ~arch URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (63.248.41.91) http://www.gnu.org/software/gnutls/manual/html_node/Upgrading-from-previous… It appears a handful of calls have new/updated renditions per the above link including (but not limited to) gnutls_certificate_get_x509_cas. Thanks! libtool: link: x86_64-pc-linux-gnu-gcc -march=native -O2 -pipe -D_GNU_SOURCE -Wl,-O1 -o .libs/apitest apitest.o -Wl,--as-needed ./.libs/libldap.so /var/tmp/portage/net-nds/openldap-2.4.33/work/openldap-2.4.33/libraries/liblber/.libs/liblber.so ../../libraries/liblber/.libs/liblber.so ../../libraries/liblutil/liblutil.a /usr/lib64/libsasl2.so -ldl -lgnutls -lgcrypt -lcrypt -lresolv ./.libs/libldap.so: undefined reference to `gnutls_certificate_get_x509_cas' collect2: ld returned 1 exit status make[2]: *** [ftest] Error 1 make[2]: *** Waiting for unfinished jobs.... libtool: link: x86_64-pc-linux-gnu-gcc -march=native -O2 -pipe -D_GNU_SOURCE -Wl,-O1 -o .libs/dntest dntest.o -Wl,--as-needed ./.libs/libldap.so /var/tmp/portage/net-nds/openldap-2.4.33/work/openldap-2.4.33/libraries/liblber/.libs/liblber.so ../../libraries/liblber/.libs/liblber.so ../../libraries/liblutil/liblutil.a /usr/lib64/libsasl2.so -ldl -lgnutls -lgcrypt -lcrypt -lresolv libtool: link: x86_64-pc-linux-gnu-gcc -march=native -O2 -pipe -D_GNU_SOURCE -Wl,-O1 -o .libs/urltest urltest.o -Wl,--as-needed ./.libs/libldap.so /var/tmp/portage/net-nds/openldap-2.4.33/work/openldap-2.4.33/libraries/liblber/.libs/liblber.so ../../libraries/liblber/.libs/liblber.so ../../libraries/liblutil/liblutil.a /usr/lib64/libsasl2.so -ldl -lgnutls -lgcrypt -lcrypt -lresolv ./.libs/libldap.so: undefined reference to `gnutls_certificate_get_x509_cas' collect2: ld returned 1 exit status make[2]: *** [apitest] Error 1 libtool: link: x86_64-pc-linux-gnu-gcc -march=native -O2 -pipe -D_GNU_SOURCE -Wl,-O1 -o .libs/ltest test.o -Wl,--as-needed ./.libs/libldap.so /var/tmp/portage/net-nds/openldap-2.4.33/work/openldap-2.4.33/libraries/liblber/.libs/liblber.so ../../libraries/liblber/.libs/liblber.so ../../libraries/liblutil/liblutil.a /usr/lib64/libsasl2.so -ldl -lgnutls -lgcrypt -lcrypt -lresolv ./.libs/libldap.so: undefined reference to `gnutls_certificate_get_x509_cas' collect2: ld returned 1 exit status make[2]: *** [dntest] Error 1 ./.libs/libldap.so: undefined reference to `gnutls_certificate_get_x509_cas' collect2: ld returned 1 exit status make[2]: *** [urltest] Error 1 ./.libs/libldap.so: undefined reference to `gnutls_certificate_get_x509_cas' collect2: ld returned 1 exit status make[2]: *** [ltest] Error 1 make[2]: Leaving directory `/var/tmp/portage/net-nds/openldap-2.4.33/work/openldap-2.4.33/libraries/libldap' make[1]: *** [all-common] Error 1 make[1]: Leaving directory `/var/tmp/portage/net-nds/openldap-2.4.33/work/openldap-2.4.33/libraries' make: *** [all-common] Error 1

1 0

(ITS#7429) MDB crashing with slapo-valsort
by marco.pizzoli＠gmail.com 02 Nov '12

02 Nov '12

Full_Name: Marco Pizzoli Version: 2.4.33 OS: Linux 64bit URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (194.11.209.11) Hi, I'm aware I'm not providing a complete bug report, but as I wrote on the mailing list I'm in a situation where I simply can't do it. Feel free to close if not enough information will be provided or try to ask me other infos if it could be worth the doing. I slapadd-ed a pre-existent OpenLDAP database (2.4.16) on a new test system (2.4.33). The new setup uses back-mdb as database. I created a second specular system and successfully completed a sync-replication from the first of the servers. Repeated the procedure (drop/populate the db) 5 or 6 times, without any problem. I decided to enable the valsort overlay, instanciated on the mdb db. My configuration was simply: overlay valsort valsort-attr member dc=company,dc=XX alpha-ascend Now I have the slave always crashing at almost 70% of progress. I produced a "bt full" (which I can't copy/paste here) of the core and I can see in the "mdb_search <cut> search.c:352" section a lot of rows similar to this one: isc{ bv_val = 0x8 <Address 0x8 out of bounds>}, {bv_len = 140172391141264, bv_val = 0x7f7c6e041000 <Address 0x7f7c6e041000 out of bounds>},[cut] I would be happy to provide other infos but I can't copy paste the entire "bt full" output. I'm sorry about that. Thanks Marco Pizzoli

1 0

AW: (ITS#7426) contraints blocks syncreplication
by Sascha.Kuehndel＠deka.de 02 Nov '12

02 Nov '12

Hi Howard, today, i have tested the patch. 1) make test -> successful 2) sync in small example -> successful 3) sync in the real configuration -> successful, too Thanks to all, Sascha

1 0

Re: (ITS#7426) contraints blocks syncreplication
by hyc＠symas.com 01 Nov '12

01 Nov '12

michael(a)stroeder.com wrote: > hyc(a)symas.com wrote: >> Sascha.Kuehndel(a)deka.de wrote: >>> the problem is the order of the sync process. >>> First the users are sync. At this moment the consumer don't have any group entry. >>> So the constraints checks the dekanetZielgruppenDN against a not existing subtree. >>> The result is: the user entry is not added. >> >> Yes, but that's irrelevant. Even if the groups were fully replicated already, >> if the provider sent an invalid user, this constraint overlay on the consumer >> would correctly reject it and replication would still break. > > IMO Sascha says that the group and user entries were written in correct order > to the first provider, successfully passed the constraints there but are then > replicated in different order to the second provider which also checks the > same constraints again. Since the order is significant for the constraint it > fails on the second provider. (Both are configured with same constraints.) > > The solution would be to not check constraints for replicated ops. It's > similar to the problem space when/whether to apply slapo-refint, > slapo-memberof etc. in case of replicated ops. OK, that sounds fine. The corresponding fix is now in git master, please test. commit b4126863a4443630392afc50de65b0c90de2304f -- -- 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#7426) contraints blocks syncreplication
by michael＠stroeder.com 01 Nov '12

01 Nov '12

hyc(a)symas.com wrote: > Sascha.Kuehndel(a)deka.de wrote: >> the problem is the order of the sync process. >> First the users are sync. At this moment the consumer don't have any group entry. >> So the constraints checks the dekanetZielgruppenDN against a not existing subtree. >> The result is: the user entry is not added. > > Yes, but that's irrelevant. Even if the groups were fully replicated already, > if the provider sent an invalid user, this constraint overlay on the consumer > would correctly reject it and replication would still break. IMO Sascha says that the group and user entries were written in correct order to the first provider, successfully passed the constraints there but are then replicated in different order to the second provider which also checks the same constraints again. Since the order is significant for the constraint it fails on the second provider. (Both are configured with same constraints.) The solution would be to not check constraints for replicated ops. It's similar to the problem space when/whether to apply slapo-refint, slapo-memberof etc. in case of replicated ops. Ciao, Michael.

1 0

Re: (ITS#7428) libldap: use non-blocking IO during TLS handshake
by rhafer＠suse.de 01 Nov '12

01 Nov '12

I've just uploaded: ftp://ftp.openldap.org/incoming/rhafer-Use-non-blocking-IO-during-SSL-Hands… which tries to address the issue. If LDAP_OPT_NETWORK_TIMEOUT is set ldap_int_tls_start will switch to non-blocking IO and call ldap_int_tls_connect as often as needed unless it times out inbetween. Currently I have only tested this with openssl but AFAICS this should also work with the NSS and gnutls backends Please review and comment. Ralf

1 0

(ITS#7428) libldap: use non-blocking IO during TLS handshake
by rhafer＠suse.de 01 Nov '12

01 Nov '12

Full_Name: Ralf Haferkamp Version: HEAD OS: URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (92.252.80.202) Currently libldap is using blocking IO when performing the SSL handshake for ldaps:// connections (and when performing the StartTLS operation). The can lead to the client blocking forever in the ssl lib (in SSL_connect in case of openssl) if e.g. the server for whatever reason stops responding. It would be very helpful if libldap would use non-blocking IO during the handshake at least when LDAP_OPT_NETWORK_TIMEOUT (or LDAP_OPT_TIMEOUT?) are set.

1 0

← Newer
1
2
3
4
5
6
7
8
9
10
Older →

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

openldap-bugs November 2012