openldap-bugs

openldap-bugs@openldap.org

1 participants
20967 discussions

RE: (ITS#8609) segfault in mods.c - modify_add_values
by henson＠acm.org 15 May '17

15 May '17

> From: Quanah Gibson-Mount > Sent: Thursday, April 20, 2017 1:26 PM > > It's fine for there to be legacy entryCSNs and a contextCSN for serverID of > 0. However, it is not fine for any master in an MMR setup to have a > specific serverID of 0. If you're running with serverID's 0-3, I'd simply > try an ldapmodify on the server with 0 to set its serverID to 4, and then > do a modification against it, so it generates a new contextCSN that gets > pushed out to all nodes. I went ahead and updated the serverID from 0 to 4 when I dropped in the patched binary, it seems to have gone smoothly. I'm planning to migrate the memberOf configuration over the summer to the dynamic list implementation, which is going to require a dump to ldif and reload, I'll go ahead and strip out the legacy serverid 0 contextCSN's then. Thanks.

1 0

RE: (ITS#8609) segfault in mods.c - modify_add_values
by henson＠acm.org 15 May '17

15 May '17

> From: Ond=C5=99ej Kuzn=C3=ADk > Sent: Thursday, April 20, 2017 1:34 AM >=20 > Would you be able to try the patch I provided earlier on one of your > servers? Sorry for the long delay on this. I had built an updated binary with the = patch, but was waiting for the server to crash to drop it in. As luck = would have it, it went almost a month without crashing 8-/. It crashed = yesterday though, so it is now running with the patch = (Ondrej-Kuznik-20170327-ITS8609-ignore-invalid-accesslog-ops.patch), = although it might take some time to see if it makes any difference. Or = it might crash again tomorrow. <sigh>. Thanks much=E2=80=A6

1 0

Re: (ITS#8654) Option for LDAP client to bind to a local address.
by hyc＠symas.com 15 May '17

15 May '17

Daniel.Le(a)Exfo.com wrote: > Full_Name: Daniel Le > Version: 2.4.44 > OS: Linux > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (107.0.5.66) > > > Enhancement request to modify the ldap_set_option function to add support for a > multihomed client to bind to a specific local network address, similarly to > "telnet -b <client-local-address>" option or Microsoft LDAP client API function > ldap_set_option(LDAP_OPT_SOCKET_BIND_ADDRESSES). It might be helpful if you would link to the documentation for this option, so someone can write something compatible. -- -- 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

(ITS#8654) Option for LDAP client to bind to a local address.
by Daniel.Le＠Exfo.com 15 May '17

15 May '17

Full_Name: Daniel Le Version: 2.4.44 OS: Linux URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (107.0.5.66) Enhancement request to modify the ldap_set_option function to add support for a multihomed client to bind to a specific local network address, similarly to "telnet -b <client-local-address>" option or Microsoft LDAP client API function ldap_set_option(LDAP_OPT_SOCKET_BIND_ADDRESSES). Thank you.

1 0

(ITS#8653) ber_flus2 assertion fail leads to a crash of slapd
by mail＠artemil.de 15 May '17

15 May '17

Full_Name: Version: 2.4.44 OS: centos 7, sles 12.2 URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (91.224.226.197) Hello, we are trying to run openldap in a proxy mode to our AD as a virtual machine on a VMWARE ESXi 5.5. Unfortunately slapd crashes by receiving a SIGABRT very often, but not on every request. But the issue can be reproduced easily by just typing several times the "id corporateID" command. I reduced the configuration file to a minimum, - the issue remains. I'm running in to the same issue on SLES 12.2 with openldap 2.4.41 and also on a CentOS 7 with openldap 2.4.44 from the "tlb project". The crash happens, as far as i can determine, always in the ber_flush2 function after a failed assert. Here is the minimal config where the issue persists: include /usr/local/openldap/etc/openldap/schema/core.schema include /usr/local/openldap/etc/openldap/schema/cosine.schema include /usr/local/openldap/etc/openldap/schema/inetorgperson.schema include /usr/local/openldap/etc/openldap/schema/nis.schema include /usr/local/openldap/etc/openldap/schema/misc.schema pidfile /usr/local/openldap/var/run/slapd.pid argsfile /usr/local/openldap/var/run/slapd.args database ldap readonly yes protocol-version 3 rebind-as-user yes uri ldap://ldap.corp.de:389 suffix "DC=corp,DC=de" rootdn "DC=corp,DC=de?sub?&(memberof=CN=DMS-SSH-User,OU=administrative Gruppen\\, Admin- und Dienstkonten,OU=Berechtigungen,DC=corp,DC=de)" loglevel 256 Here comes the backtrace: (gdb) bt #0 0x00007ffff64281d7 in __GI_raise (sig=sig@entry=6) at ../nptl/sysdeps/unix/sysv/linux/raise.c:56 #1 0x00007ffff64298c8 in __GI_abort () at abort.c:90 #2 0x00007ffff6421146 in __assert_fail_base (fmt=0x7ffff65723a8 "%s%s%s:%u: %s%sAssertion `%s' failed.\n%n", assertion=assertion@entry=0x649ab8 "( (sb)->sb_opts.lbo_valid == 0x3 )", file=file@entry=0x649a21 "io.c", line=line@entry=224, function=function@entry=0x649be6 <__PRETTY_FUNCTION__.6214> "ber_flush2") at assert.c:92 #3 0x00007ffff64211f2 in __GI___assert_fail (assertion=assertion@entry=0x649ab8 "( (sb)->sb_opts.lbo_valid == 0x3 )", file=file@entry=0x649a21 "io.c", line=line@entry=224, function=function@entry=0x649be6 <__PRETTY_FUNCTION__.6214> "ber_flush2") at assert.c:101 #4 0x00000000005b95d8 in ber_flush2 (sb=0x7fffe40000d8, ber=0x7fffe4119d40, freeit=freeit@entry=0) at io.c:224 #5 0x00000000005a3491 in ldap_int_flush_request (ld=ld@entry=0x7fffe8102800, lr=lr@entry=0x7fffe410d570) at request.c:186 #6 0x00000000005a38fa in ldap_send_server_request (ld=ld@entry=0x7fffe8102800, ber=ber@entry=0x7fffe4119d40, msgid=msgid@entry=134, parentreq=parentreq@entry=0x0, srvlist=srvlist@entry=0x0, lc=0x7fffe4116f70, lc@entry=0x0, bind=bind@entry=0x0, m_noconn=m_noconn@entry=0, m_res=m_res@entry=0) at request.c:408 #7 0x00000000005a3aa8 in ldap_send_initial_request (ld=ld@entry=0x7fffe8102800, msgtype=msgtype@entry=99, dn=dn@entry=0x7fffe4002e48 "dc=corp,dc=de", ber=0x7fffe4119d40, msgid=134) at request.c:169 #8 0x00000000005946e4 in ldap_pvt_search (ld=0x7fffe8102800, base=0x7fffe4002e48 "dc=corp,dc=de", scope=2, filter=filter@entry=0x7fffe40031a8 "(&(objectClass=group)(gidNumber=20000)(&(OBJECTCATEGORY=group)(gidNumber=*)))", attrs=attrs@entry=0x7fffe4003170, attrsonly=0, sctrls=0x0, cctrls=cctrls@entry=0x0, timeout=0x7ffff35d07f0, sizelimit=1, deref=0, msgidp=msgidp@entry=0x7ffff35d07cc) at search.c:128 #9 0x00000000004c902d in ldap_back_search (op=0x7fffe40028e0, rs=<optimized out>) at search.c:233 #10 0x0000000000442f41 in fe_op_search (op=0x7fffe40028e0, rs=0x7ffff35d19a0) at search.c:402 #11 0x0000000000442926 in do_search (op=0x7fffe40028e0, rs=0x7ffff35d19a0) at search.c:247 #12 0x00000000004407de in connection_operation (ctx=ctx@entry=0x7ffff35d1ad0, arg_v=arg_v@entry=0x7fffe40028e0) at connection.c:1158 #13 0x0000000000440aba in connection_read_thread (ctx=0x7ffff35d1ad0, argv=0xd) at connection.c:1294 #14 0x00000000005901c9 in ldap_int_thread_pool_wrapper (xpool=0x969360) at tpool.c:696 #15 0x00007ffff7896dc5 in start_thread (arg=0x7ffff35d2700) at pthread_create.c:308 #16 0x00007ffff64ea73d in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:113 Here is a full backtrace: https://pastebin.com/Ya3F3WAW Thank you!

1 0

Re: (ITS#6798) Mutex starvation on two-level referral for SASL connection
by jhrozek＠redhat.com 11 May '17

11 May '17

On Wed, May 10, 2017 at 01:19:50PM -0400, Stephen Gallagher wrote: > > > On 05/10/2017 01:13 PM, Quanah Gibson-Mount wrote: > > --On Wednesday, May 10, 2017 2:09 PM -0400 Stephen Gallagher > > <sgallagh(a)redhat.com> wrote: > > > >> Sorry, I'm not sure why you're directing this at me? I've not been > >> involved with this bug at all. > > > > Hi Stephen, > > > > I'm not sure what you mean by "not involved". You are the one who > > filed the bug report with us. Here is a direct link for a refresher: > > > > <http://www.openldap.org/its/index.cgi/?findid=6798> > > > In your previous email, you sent me the ITS number 8648. I missed that > this was in reference to 6798 which I filed in 2011. > > I'm not sure if we still have a reproducer; I think we gave up years ago > on using the built-in referral tracking of libldap. I'm CCing Jakub > Hrozek who is the current tech lead on SSSD to see if he can still > reproduce the issue. I'm sorry, but I couldn't reproduce the issue any longer either. I remember from some of RH customers that they were occasionally hitting this (or similar?) issue and working around it by disabling the LDAP referral chasing in SSSD but I couldn't reproduce now on demand, sorry.

1 0

Re: (ITS#6798) Mutex starvation on two-level referral for SASL connection
by sgallagh＠redhat.com 10 May '17

10 May '17

This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --HHc3bK7tdjOA64tcVjmTOngCrPgq87MTg Content-Type: multipart/mixed; boundary="VicgVXOp2ABP8hIiqjm4ijIANjXR7KCdV"; protected-headers="v1" From: Stephen Gallagher <sgallagh(a)redhat.com> To: Quanah Gibson-Mount <quanah(a)symas.com>, openldap-its(a)openldap.org, Jakub Hrozek <jhrozek(a)redhat.com> Message-ID: <4b76c423-a4c3-9fc7-64e2-883388b3e65f(a)redhat.com> Subject: Re: (ITS#6798) Mutex starvation on two-level referral for SASL connection References: <D6162EF94C4315CF6F656712(a)[192.168.1.19]> <777f871f-f77e-7041-dc6a-895e1edb56a6(a)redhat.com> <WM!63a01a37caa0c6690c38e83fd6e7322d72410d224d2fdeade3b0aba909282919d8d93ff608eaaa443968f6d4f6936856!(a)mailstronghold-1.zmailcloud.com> <838E0287ACCF76C2266EC803(a)[192.168.1.19]> In-Reply-To: <838E0287ACCF76C2266EC803(a)[192.168.1.19]> --VicgVXOp2ABP8hIiqjm4ijIANjXR7KCdV Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Content-Language: en-US On 05/10/2017 01:13 PM, Quanah Gibson-Mount wrote: > --On Wednesday, May 10, 2017 2:09 PM -0400 Stephen Gallagher > <sgallagh(a)redhat.com> wrote: > >> Sorry, I'm not sure why you're directing this at me? I've not been >> involved with this bug at all. > > Hi Stephen, > > I'm not sure what you mean by "not involved". You are the one who > filed the bug report with us. Here is a direct link for a refresher: > > <http://www.openldap.org/its/index.cgi/?findid=3D6798> In your previous email, you sent me the ITS number 8648. I missed that this was in reference to 6798 which I filed in 2011. I'm not sure if we still have a reproducer; I think we gave up years ago on using the built-in referral tracking of libldap. I'm CCing Jakub Hrozek who is the current tech lead on SSSD to see if he can still reproduce the issue. --VicgVXOp2ABP8hIiqjm4ijIANjXR7KCdV-- --HHc3bK7tdjOA64tcVjmTOngCrPgq87MTg Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- iFwEARECAB0WIQQ0v96iCbHqLp/cLlN6JVViNrqjowUCWRNLtgAKCRB6JVViNrqj o8toAJiFVe4hmZE+5WazEAf1UrguCR0fAKCUxCVSXwgdL5eWpMtFPPgkqqaY0g== =vdhI -----END PGP SIGNATURE----- --HHc3bK7tdjOA64tcVjmTOngCrPgq87MTg--

1 0

Re: (ITS#6798) Mutex starvation on two-level referral for SASL connection
by quanah＠symas.com 10 May '17

10 May '17

--On Wednesday, May 10, 2017 2:09 PM -0400 Stephen Gallagher <sgallagh(a)redhat.com> wrote: > Sorry, I'm not sure why you're directing this at me? I've not been > involved with this bug at all. Hi Stephen, I'm not sure what you mean by "not involved". You are the one who filed the bug report with us. Here is a direct link for a refresher: <http://www.openldap.org/its/index.cgi/?findid=6798> Regards, Quanah -- Quanah Gibson-Mount Product Architect Symas Corporation Packaged, certified, and supported LDAP solutions powered by OpenLDAP: <http://www.symas.com>

1 0

Re: (ITS#6798) Mutex starvation on two-level referral for SASL connection
by sgallagh＠redhat.com 10 May '17

10 May '17

This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --ijumfDLdJ6N1xL1tHwFiTBhCBA9VnmThW Content-Type: multipart/mixed; boundary="rw1j2W5jTxST7ATlUt2I8c5Ena44RM7Vs"; protected-headers="v1" From: Stephen Gallagher <sgallagh(a)redhat.com> To: Quanah Gibson-Mount <quanah(a)symas.com>, openldap-its(a)openldap.org Message-ID: <777f871f-f77e-7041-dc6a-895e1edb56a6(a)redhat.com> Subject: Re: (ITS#6798) Mutex starvation on two-level referral for SASL connection References: <D6162EF94C4315CF6F656712(a)[192.168.1.19]> In-Reply-To: <D6162EF94C4315CF6F656712(a)[192.168.1.19]> --rw1j2W5jTxST7ATlUt2I8c5Ena44RM7Vs Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Content-Language: en-US Sorry, I'm not sure why you're directing this at me? I've not been involved with this bug at all. On 05/10/2017 12:56 PM, Quanah Gibson-Mount wrote: > Hi Stephen, > > Would you be able to check and confirm if the fix for ITS#8648 that > has been checked into RE24 resolves this issue? > > Thanks, > Quanah > > --=20 > > Quanah Gibson-Mount > Product Architect > Symas Corporation > Packaged, certified, and supported LDAP solutions powered by OpenLDAP: > <http://www.symas.com> > --rw1j2W5jTxST7ATlUt2I8c5Ena44RM7Vs-- --ijumfDLdJ6N1xL1tHwFiTBhCBA9VnmThW Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- iF0EARECAB0WIQQ0v96iCbHqLp/cLlN6JVViNrqjowUCWRNJVwAKCRB6JVViNrqj o3iuAJ40OLMe/nQHhjOAO7Uhuaxj8OWnxgCeJqR819BAH7lwMmVsOqyhRGCdJXA= =oyIK -----END PGP SIGNATURE----- --ijumfDLdJ6N1xL1tHwFiTBhCBA9VnmThW--

1 0

Re: (ITS#6798) Mutex starvation on two-level referral for SASL connection
by quanah＠symas.com 10 May '17

10 May '17

Hi Stephen, Would you be able to check and confirm if the fix for ITS#8648 that has been checked into RE24 resolves this issue? Thanks, Quanah -- Quanah Gibson-Mount Product Architect Symas Corporation Packaged, certified, and supported LDAP solutions powered by OpenLDAP: <http://www.symas.com>

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