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/
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.
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!
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.
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--
--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>
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--
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>