openldap-bugs

openldap-bugs@openldap.org

1 participants
21146 discussions

(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

Re: AW: WG: AW: (ITS#7426) contraints blocks syncreplication
by quanah＠zimbra.com 01 Nov '12

01 Nov '12

--On Thursday, November 01, 2012 4:47 PM +0000 Sascha.Kuehndel(a)deka.de wrote: > Hi, > > in real it is a multi-master-replication. > So the constraints have to define on both sides. If you could provide your exact config and the LDIF files you are loading, that would help. Please strip out any passwords and other individual identifying information. Thanks. --Quanah -- Quanah Gibson-Mount Sr. Member of Technical Staff Zimbra, Inc A Division of VMware, Inc. -------------------- Zimbra :: the leader in open source messaging and collaboration

1 0

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

01 Nov '12

Hi, in real it is a multi-master-replication. So the constraints have to define on both sides. I have check the entry, more than one time. (many more) so i really sure, it is valid. (changed the attribute to another value and back on the procurer) I think it is a tricky timing problem, and it appears only in special situations. I found it, in a restore of a system with an backup. After imported it in the procurer1, I started the second one. At the next morning the sync wasn't complete. And I wondered why. Another test shows the problem, a little bit more. I changed the order of the entries in the initial.ldif (groups in front of users), and the sync works. In the last message, was a little type. In the database only 6 entries (not 56) Sascha PS: sorry my English is not very well

1 0

Jump to page:

2026

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

openldap-bugs