openldap-bugs

openldap-bugs@openldap.org

1 participants
21001 discussions

Re: (ITS#8897) Delta syncrepl + refreshOnly segfault if 2 servers receive same group modification operation within interval
by Mark.Cairney＠ed.ac.uk 13 Aug '18

13 Aug '18

Hi Quanah, It certainly sounds very similar from the description. I've applied the patch on our Dev systems and tried to recreate the crash but this time they don't crash and the change appears to make it to all 4 servers. Based on that I'm happy to close it as a duplicate. For completeness here's the log snippet from one of the 2 servers not to get the change directly: 2018-08-13T15:51:41.309019+01:00 bonsai.authorise-dev.is.ed.ac.uk slapd[33415]: conn=2891 op=1 SEARCH RESULT tag=101 err=0 nentries=0 text= 2018-08-13T15:51:41.310958+01:00 bonsai.authorise-dev.is.ed.ac.uk slapd[33415]: conn=2891 op=2 UNBIND 2018-08-13T15:51:41.311320+01:00 bonsai.authorise-dev.is.ed.ac.uk slapd[33415]: conn=2891 fd=17 closed 2018-08-13T15:52:18.347529+01:00 bonsai.authorise-dev.is.ed.ac.uk slapd[33415]: do_syncrep2: rid=003 cookie=rid=003,sid=00a,csn=20180810152745.105428Z#000000#009#000000 2018-08-13T15:52:18.347925+01:00 bonsai.authorise-dev.is.ed.ac.uk slapd[33415]: do_syncrep2: rid=003 CSN too old, ignoring 20180810152745.105428Z#000000#009#000000 (reqStart=20180810152801.000001Z,cn=accesslog) 2018-08-13T15:52:19.361612+01:00 bonsai.authorise-dev.is.ed.ac.uk slapd[33415]: do_syncrep2: rid=004 cookie=rid=004,sid=00c,csn=20180813145040.294725Z#000000#00c#000000 2018-08-13T15:52:19.361936+01:00 bonsai.authorise-dev.is.ed.ac.uk slapd[33415]: slap_queue_csn: queueing 0x4279380 20180813145040.294725Z#000000#00c#000000 2018-08-13T15:52:19.362187+01:00 bonsai.authorise-dev.is.ed.ac.uk slapd[33415]: syncrepl_message_to_op: rid=004 tid 6f1f6700 2018-08-13T15:52:19.378677+01:00 bonsai.authorise-dev.is.ed.ac.uk slapd[33415]: slap_queue_csn: queueing 0x3e067c0 20180813145040.294725Z#000000#00c#000000 2018-08-13T15:52:19.380316+01:00 bonsai.authorise-dev.is.ed.ac.uk slapd[33415]: slap_graduate_commit_csn: removing 0x3e067c0 20180813145040.294725Z#000000#00c#000000 2018-08-13T15:52:19.380570+01:00 bonsai.authorise-dev.is.ed.ac.uk slapd[33415]: slap_graduate_commit_csn: removing 0x4279380 20180813145040.294725Z#000000#00c#000000 2018-08-13T15:52:19.380819+01:00 bonsai.authorise-dev.is.ed.ac.uk slapd[33415]: syncrepl_message_to_op: rid=004 be_modify uid=jaw,ou=people,ou=central,dc=authorise-dev,dc=ed,dc=ac,dc=uk (0) 2018-08-13T15:52:19.381044+01:00 bonsai.authorise-dev.is.ed.ac.uk slapd[33415]: slap_queue_csn: queueing 0x419d5c0 20180813145040.294725Z#000000#00c#000000 2018-08-13T15:52:19.385145+01:00 bonsai.authorise-dev.is.ed.ac.uk slapd[33415]: slap_graduate_commit_csn: removing 0x419d5c0 20180813145040.294725Z#000000#00c#000000 2018-08-13T15:52:19.385403+01:00 bonsai.authorise-dev.is.ed.ac.uk slapd[33415]: do_syncrep2: rid=004 LDAP_RES_SEARCH_RESULT 2018-08-13T15:52:19.385654+01:00 bonsai.authorise-dev.is.ed.ac.uk slapd[33415]: do_syncrep2: rid=004 cookie=rid=004,sid=00c,csn=20120217162731.749366Z#000000#000#000000;20180701051000.119854Z#000000#003#000000;20180711011500.114848Z#000000#004#000000;20180710075708.402194Z#000000#005#000000;20180703112408.905121Z#000000#006#000000;20180813144557.086593Z#000000#009#000000;20180813145034.034818Z#000000#00b#000000;20180813145040.294725Z#000000#00c#000000 Kind regards, Mark On 10/08/18 17:00, Quanah Gibson-Mount wrote: > --On Friday, August 10, 2018 4:41 PM +0000 Mark.Cairney(a)ed.ac.uk wrote: > >> Full_Name: Mark Cairney >> Version: 2.4.46 >> OS: Centos 7 >> URL: >> Submission from: (NULL) (129.215.149.98) >> >> >> In a MMR setup of >=3 servers (4 in this case) you can cause a segfault >> if you issue the same modification to 2 separate servers within your >> replication interval. >> It seems like it's the last server to receive the change falls over when >> it receives the change from one of the other servers during replication: > > Hi Mark, > > I'm pretty sure you're reporting ITS#8843. I suggest applying this patch: > > <https://www.openldap.org/devel/gitweb.cgi?p=openldap.git;a=commit;h=cc24cf6…> > > > --Quanah > > > > -- > > Quanah Gibson-Mount > Product Architect > Symas Corporation > Packaged, certified, and supported LDAP solutions powered by OpenLDAP: > <http://www.symas.com> > > -- /**************************** Mark Cairney ITI Enterprise Services Information Services University of Edinburgh Tel: 0131 650 6565 Email: Mark.Cairney(a)ed.ac.uk PGP: 0x435A9621 *******************************/ The University of Edinburgh is a charitable body, registered in Scotland, with registration number SC005336.

1 0

Re: (ITS#8897) Delta syncrepl + refreshOnly segfault if 2 servers receive same group modification operation within interval
by quanah＠symas.com 10 Aug '18

10 Aug '18

--On Friday, August 10, 2018 4:41 PM +0000 Mark.Cairney(a)ed.ac.uk wrote: > Full_Name: Mark Cairney > Version: 2.4.46 > OS: Centos 7 > URL: > Submission from: (NULL) (129.215.149.98) > > > In a MMR setup of >=3 servers (4 in this case) you can cause a segfault > if you issue the same modification to 2 separate servers within your > replication interval. > It seems like it's the last server to receive the change falls over when > it receives the change from one of the other servers during replication: Hi Mark, I'm pretty sure you're reporting ITS#8843. I suggest applying this patch: <https://www.openldap.org/devel/gitweb.cgi?p=openldap.git;a=commit;h=cc24cf6…> --Quanah -- Quanah Gibson-Mount Product Architect Symas Corporation Packaged, certified, and supported LDAP solutions powered by OpenLDAP: <http://www.symas.com>

1 0

(ITS#8897) Delta syncrepl + refreshOnly segfault if 2 servers receive same group modification operation within interval
by Mark.Cairney＠ed.ac.uk 10 Aug '18

10 Aug '18

Full_Name: Mark Cairney Version: 2.4.46 OS: Centos 7 URL: Submission from: (NULL) (129.215.149.98) In a MMR setup of >=3 servers (4 in this case) you can cause a segfault if you issue the same modification to 2 separate servers within your replication interval. It seems like it's the last server to receive the change falls over when it receives the change from one of the other servers during replication: 2018-08-10T16:01:39.461367+01:00 spruce.authorise-dev.is.ed.ac.uk slapd[11286]: conn=1004 op=3 BIND authcid="mcairney(a)EASE.ED.AC.UK" authzid="mcairney(a)EASE.ED.AC.UK" 2018-08-10T16:01:39.461843+01:00 spruce.authorise-dev.is.ed.ac.uk slapd[11286]: conn=1004 op=3 BIND dn="uid=mcairney,ou=people,ou=central,dc=authorise-dev,dc=ed,dc=ac,dc=uk" mech=GSSAPI sasl_ssf=256 ssf=256 2018-08-10T16:01:39.462205+01:00 spruce.authorise-dev.is.ed.ac.uk slapd[11286]: conn=1004 op=3 RESULT tag=97 err=0 text= 2018-08-10T16:01:39.462858+01:00 spruce.authorise-dev.is.ed.ac.uk slapd[11286]: conn=1004 op=4 MOD dn="cn=marksgroup,ou=ug,ou=iti,ou=is,dc=authorise-dev,dc=ed,dc=ac,dc=uk" 2018-08-10T16:01:39.463268+01:00 spruce.authorise-dev.is.ed.ac.uk slapd[11286]: conn=1004 op=4 MOD attr=member 2018-08-10T16:01:39.463703+01:00 spruce.authorise-dev.is.ed.ac.uk slapd[11286]: slap_queue_csn: queueing 0x46a1a00 20180810150139.461113Z#000000#00c#000000 2018-08-10T16:01:39.464026+01:00 spruce.authorise-dev.is.ed.ac.uk slapd[11286]: slap_queue_csn: queueing 0x46a0540 20180810150139.461113Z#000000#00c#000000 2018-08-10T16:01:39.464554+01:00 spruce.authorise-dev.is.ed.ac.uk slapd[11286]: slap_graduate_commit_csn: removing 0x46a0540 20180810150139.461113Z#000000#00c#000000 2018-08-10T16:01:39.464922+01:00 spruce.authorise-dev.is.ed.ac.uk slapd[11286]: conn=1004 op=4 RESULT tag=103 err=0 text= 2018-08-10T16:01:39.465271+01:00 spruce.authorise-dev.is.ed.ac.uk slapd[11286]: slap_graduate_commit_csn: removing 0x46a1a00 20180810150139.461113Z#000000#00c#000000 2018-08-10T16:01:39.465647+01:00 spruce.authorise-dev.is.ed.ac.uk slapd[11286]: conn=1004 op=5 UNBIND 2018-08-10T16:01:39.465962+01:00 spruce.authorise-dev.is.ed.ac.uk slapd[11286]: conn=1004 fd=12 closed 2018-08-10T16:01:59.042478+01:00 spruce.authorise-dev.is.ed.ac.uk slapd[11286]: conn=1005 fd=12 ACCEPT from IP=129.215.17.49:59638 (IP=129.215.17.52:636) 2018-08-10T16:01:59.045948+01:00 spruce.authorise-dev.is.ed.ac.uk slapd[11286]: conn=1005 fd=12 TLS established tls_ssf=256 ssf=256 2018-08-10T16:01:59.046828+01:00 spruce.authorise-dev.is.ed.ac.uk slapd[11286]: conn=1005 op=0 BIND dn="cn=manager,dc=authorise-dev,dc=ed,dc=ac,dc=uk" method=128 2018-08-10T16:01:59.052303+01:00 spruce.authorise-dev.is.ed.ac.uk slapd[11286]: conn=1005 op=0 BIND dn="cn=manager,dc=authorise-dev,dc=ed,dc=ac,dc=uk" mech=SIMPLE ssf=0 2018-08-10T16:01:59.052924+01:00 spruce.authorise-dev.is.ed.ac.uk slapd[11286]: conn=1005 op=0 RESULT tag=97 err=0 text= 2018-08-10T16:01:59.053419+01:00 spruce.authorise-dev.is.ed.ac.uk slapd[11286]: conn=1005 op=1 SRCH base="cn=accesslog" scope=2 deref=0 filter="(&(objectClass=auditWriteObject)(reqResult=0))" 2018-08-10T16:01:59.053912+01:00 spruce.authorise-dev.is.ed.ac.uk slapd[11286]: conn=1005 op=1 SRCH attr=reqDN reqType reqMod reqNewRDN reqDeleteOldRDN reqNewSuperior entryCSN 2018-08-10T16:01:59.054366+01:00 spruce.authorise-dev.is.ed.ac.uk slapd[11286]: Entry reqStart=20180810144019.000000Z,cn=accesslog CSN 20180810144019.929847Z#000000#00c#000000 older or equal to ctx 20180810144019.929847Z#000000#00c#000000 2018-08-10T16:01:59.054902+01:00 spruce.authorise-dev.is.ed.ac.uk slapd[11286]: Entry reqStart=20180810144922.000002Z,cn=accesslog CSN 20180810144822.605802Z#000000#009#000000 older or equal to ctx 20180810150125.942413Z#000000#009#000000 2018-08-10T16:01:59.055330+01:00 spruce.authorise-dev.is.ed.ac.uk slapd[11286]: syncprov_search_response: cookie=rid=004,sid=00c,csn=20120217162731.749366Z#000000#000#000000;20180701051000.119854Z#000000#003#000000;20180711011500.114848Z#000000#004#000000;20180710075708.402194Z#000000#005#000000;20180703112408.905121Z#000000#006#000000;20180810144822.605802Z#000000#009#000000;20180711161057.835548Z#000000#00b#000000;20180810150139.461113Z#000000#00c#000000 2018-08-10T16:01:59.055753+01:00 spruce.authorise-dev.is.ed.ac.uk slapd[11286]: conn=1005 op=1 SEARCH RESULT tag=101 err=0 nentries=1 text= 2018-08-10T16:01:59.056308+01:00 spruce.authorise-dev.is.ed.ac.uk slapd[11286]: conn=1005 op=2 ABANDON msg=2 2018-08-10T16:01:59.056735+01:00 spruce.authorise-dev.is.ed.ac.uk slapd[11286]: conn=1005 op=3 SRCH base="dc=authorise-dev,dc=ed,dc=ac,dc=uk" scope=2 deref=0 filter="(objectClass=*)" 2018-08-10T16:01:59.057148+01:00 spruce.authorise-dev.is.ed.ac.uk slapd[11286]: conn=1005 op=3 SRCH attr=* + 2018-08-10T16:02:06.066075+01:00 spruce.authorise-dev.is.ed.ac.uk slapd[11286]: do_syncrep2: rid=002 LDAP_RES_SEARCH_RESULT 2018-08-10T16:02:06.075530+01:00 spruce.authorise-dev.is.ed.ac.uk slapd[11286]: do_syncrep2: rid=001 cookie=rid=001,sid=009,csn=20180810150125.942413Z#000000#009#000000 2018-08-10T16:02:06.076055+01:00 spruce.authorise-dev.is.ed.ac.uk slapd[11286]: slap_queue_csn: queueing 0x46a0380 20180810150125.942413Z#000000#009#000000 2018-08-10T16:02:06.076275+01:00 spruce.authorise-dev.is.ed.ac.uk slapd[11286]: syncrepl_message_to_op: rid=001 tid f8504700 The following gets logged in /var/log/messages: 2018-08-10T15:22:25.582679+01:00 spruce.authorise-dev.is.ed.ac.uk su: (to ldap) root on pts/0 2018-08-10T15:59:50.381730+01:00 spruce.authorise-dev.is.ed.ac.uk su: (to ldap) root on pts/0 2018-08-10T16:02:06.076563+01:00 spruce.authorise-dev.is.ed.ac.uk kernel: slapd[11289]: segfault at 1c ip 000000000051c6d4 sp 00007fcbf85022b0 error 4 in slapd[400000+21e000] Even worse is that because the change is stuck in it's accesslog if you try and restart slapd it just falls over again: 2018-08-10T16:12:06.020868+01:00 spruce.authorise-dev.is.ed.ac.uk slapd[11451]: @(#) $OpenLDAP: slapd 2.4.46 (Mar 27 2018 09:23:46) $#012#011mockbuild@harmon.is.ed.ac.uk:/builddir/build/BUILD/openldap-2.4.46/servers/slapd 2018-08-10T16:12:06.052521+01:00 spruce.authorise-dev.is.ed.ac.uk slapd[11453]: slapd starting 2018-08-10T16:12:06.067909+01:00 spruce.authorise-dev.is.ed.ac.uk slapd[11453]: do_syncrep2: rid=002 cookie=rid=002,sid=00b,csn=20180810150125.942413Z#000000#009#000000 2018-08-10T16:12:06.068382+01:00 spruce.authorise-dev.is.ed.ac.uk slapd[11453]: slap_queue_csn: queueing 0x4252a40 20180810150125.942413Z#000000#009#000000 2018-08-10T16:12:06.068652+01:00 spruce.authorise-dev.is.ed.ac.uk slapd[11453]: syncrepl_message_to_op: rid=002 tid ce43f700 2018-08-10T16:12:06.068871+01:00 spruce.authorise-dev.is.ed.ac.uk slapd[11453]: do_syncrep2: rid=001 cookie=rid=001,sid=009,csn=20180810150125.942413Z#000000#009#000000 Finally you can bring the server back up if you clear out the accesslog and restart again. The ldif to trigger it was simply: dn: cn=marksgroup,ou=ug,ou=iti,ou=is,dc=authorise-dev,dc=ed,dc=ac,dc=uk changetype: modify add: member member: uid=mcairney,ou=people,ou=central,dc=authorise-dev,dc=ed,dc=ac,dc=uk - Applied using ldapmodify -H ldaps://<server>.authorise-dev.is.ed.ac.uk:636 -f file.ldif Deleting a member also triggers the same behaviour Changing user attributes e.g. mail in the same manner also triggers the issue. Adding/deleting an object doesn't cause a segfault but simply triggers a resync on each server.

1 0

Re: (ITS#8896) scale() uninitialized j
by hyc＠symas.com 09 Aug '18

09 Aug '18

ethanms(a)gmail.com wrote: > Full_Name: Ethan Schorer > Version: since 2.4 > OS: Linux > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (194.29.45.108) > > > In libraries/liblutil/utils.c in the function scale() the code defines "int i, > j;". > > Then, i gets set in a for loop, but j only gets set if prev->len > 1. Wrong. j gets set if prev->len >= 1. > And then, j is used even if it wasn't initialized. Isn't this a bug? No. > Shouldn't j be set to 0 when defined? Or don't use it? There is no bug here. Closing this ITS. -- -- 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#8896) scale() uninitialized j
by ethanms＠gmail.com 09 Aug '18

09 Aug '18

Full_Name: Ethan Schorer Version: since 2.4 OS: Linux URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (194.29.45.108) In libraries/liblutil/utils.c in the function scale() the code defines "int i, j;". Then, i gets set in a for loop, but j only gets set if prev->len > 1. And then, j is used even if it wasn't initialized. Isn't this a bug? Shouldn't j be set to 0 when defined? Or don't use it?

1 0

Re: (ITS#8895) LMDB bug on Windows 64 when built by MSVC
by hyc＠symas.com 08 Aug '18

08 Aug '18

hrissan(a)mail.ru wrote: > Full_Name: Hrissan > Version: lmdb commit 26c7df88e44e31623d0802a564f24781acdefde3 > OS: Windows 7 64-bit > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (108.61.166.173) > > > Dear Howard, lots of thanks for quick fix of ITS#8891, now another issue... > > I know your position that Microsoft Visual Studio is crap (it may be, but not > everyone has a choice), but here is the problem: > > When building LMDB targeting Win64 using 64-bit compiler in Microsoft Visual > Studio, the database will still be limited to just 2 gigabytes, with mdb_put > returning error as soon as database attempts to grow beyond that. > > The problem is "off_t" is incorrectly defined as "long" in MSVC posix > compatibility layer, and long is 32-bit on windows 64-bit build. As a result > mdb_page_flush (and other functions using off_t) become broken. > > I understand this is Microsoft's, not LMDB issue, but still LMDB source contains > lots of workarounds, so probably adding one will save the day for many ppl. > Microsoft has this issue since at least 2008 (And it is still there in latest > Visual Studio Community 2017 version 15.7.6), so no hope for fix from them. > I propose the following fix (as narrow as possible - for example no fix for > MinGW on Windows or MSVC on Linux) There's no logic in this proposal. The bug is clearly in the MS header files; the correct fix is to edit the MS header files and use the proper definition. Fix the actual bugs. Report the actual bugs to the people that are actually responsible for them. > > #if defined(_WIN32) && defined(_MSC_VER) > typedef long long int lmdb_off_t; // 64-bit on both 32- and 64- bit Windows > #else > typedef off_t lmdb_off_t; > #endif > > And using lmdb_off_t instead of off_t on 4 occasions where it is used. > > -- -- 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#8895) LMDB bug on Windows 64 when built by MSVC
by hrissan＠mail.ru 08 Aug '18

08 Aug '18

Full_Name: Hrissan Version: lmdb commit 26c7df88e44e31623d0802a564f24781acdefde3 OS: Windows 7 64-bit URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (108.61.166.173) Dear Howard, lots of thanks for quick fix of ITS#8891, now another issue... I know your position that Microsoft Visual Studio is crap (it may be, but not everyone has a choice), but here is the problem: When building LMDB targeting Win64 using 64-bit compiler in Microsoft Visual Studio, the database will still be limited to just 2 gigabytes, with mdb_put returning error as soon as database attempts to grow beyond that. The problem is "off_t" is incorrectly defined as "long" in MSVC posix compatibility layer, and long is 32-bit on windows 64-bit build. As a result mdb_page_flush (and other functions using off_t) become broken. I understand this is Microsoft's, not LMDB issue, but still LMDB source contains lots of workarounds, so probably adding one will save the day for many ppl. Microsoft has this issue since at least 2008 (And it is still there in latest Visual Studio Community 2017 version 15.7.6), so no hope for fix from them. I propose the following fix (as narrow as possible - for example no fix for MinGW on Windows or MSVC on Linux) #if defined(_WIN32) && defined(_MSC_VER) typedef long long int lmdb_off_t; // 64-bit on both 32- and 64- bit Windows #else typedef off_t lmdb_off_t; #endif And using lmdb_off_t instead of off_t on 4 occasions where it is used.

1 0

(ITS#8894) git clone fails
by openldap＠openldap.org 07 Aug '18

07 Aug '18

Full_Name: Version: OS: URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (2a02:587:390c:800:299:99ff:fe99:9999) Cloning into 'openldap'... fatal: dumb http transport does not support shallow capabilities

1 0

(ITS#8893) New LDAP option to support binding to specific IPv4/IPv6 address at client side
by sudhir.singam＠gmail.com 06 Aug '18

06 Aug '18

Full_Name: sudhir reddy singam Version: master branch OS: fedora URL: Submission from: (NULL) (131.228.66.13) The attached file is derived from OpenLDAP Software. All of the modifications to OpenLDAP Software represented in the following patch(es) were developed by NOKIA. NOKIA has not assigned rights and/or interest in this work to any party. I, SINGAM SUDHIR REDDY authorized by NOKIA, my employer, to release this work under the following terms. NOKIA 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. **** Description: This is continuation to ITS#8847. NOKIA has decided to contribute on this small feature, that is, providing new LDAP option to be able to set the source bind IP address at openldap client side. Following are the design details of what we are planning to do. Please provide your comments for the design, so that we can proceed with the implementation. Details: Requirement: User shall be able to set multiple IPv4/IPv6 socket bind addresses, to be able to route the LDAP traffic via desired network interface. Based on the target IP address type, first matching and valid source IP address will be picked for explicit binding at client side. Work items: 1) LDAP option to set the IPv4/IPv6 socket bind addresses. Format: space separated list of IP addresses New configuration option LDAP_OPT_SOCKET_BIND_ADDRESSES (0x5013) will be introduced (in ldap.h) to be used via ldap_set_option. For example, char* p = 10.24.56.34 2001:0db8:85a3:0000:0000:8a2e:0370:7334; ldap_set_option(NULL, LDAP_OPT_SOCKET_BIND_ADDRESSES, p); Bind addresses can also be provided in ldap.conf file via the option SOCKET_BIND_ADDRESSES, for example, SOCKET_BIND_ADDRESSES 10.24.56.45 10.24.56.46 2001:0db8:85a3:0000:0000:8a2e:0370:7334 Note : Option set to ldap handle will override the global option. Setting the option multiple times will override the previous values but does not append. 2) Parsing & validations Space separated IP addresses will be parsed & validated. IPv4 and IPv6 addresses are stored separately for easy of access during connection. Basic syntax validation will be done for IPv4 or IPv6 addresses, if any error, setting of the option will fail and LDAP client will use the default IP address. ldapoptions structure in ldap-int.h will be modified to add new members "char *ldo_local_IPV4_addresses" -> to hold client local IPv4 bind addresses "char *ldo_local_IPV6_addresses" -> to hold client local IPv6 bind addresses Any new function ldap_options_parseBindAddress () will be introduced in options.c to parse, validate and store the IP addresses to respective variables. This function will be similar to ldap_url_parseHosts. Memory for ldo_local_IPV4_addresses & ldo_local_IPV6_addresses is dynamically allocated in the form of array for easy access. If any validation failure, no new memory will be allocated and existing values will be retained. 3) Using Bind IP addresses during connection File:os-ip.c Function: ldap_connect_to_host - After the connection socket is created (ldap_int_socket) and before it is connected (ldap_pvt_connect). Check if the target address family type, If it is AF_INET, IPv4 bind address list will be used. - If the list is empty and LDAP option was set successfully earlier (IPv6 was set), binding will fail and error is returned. - If the list is not empty and not able to bind to any of the provided IPv4 addresses, connection will fail. - If the list is empty and LDAP option setting failed earlier (during syntax validation), LDAP client will continue to use the kernel provided IPv4 address. If it is AF_INET6, IPv6 bind address list will be used. - If the list is empty and LDAP option was set successfully earlier (IPv4 was set), binding will fail and error is returned. - If the list is not empty and not able to bind to any of the provided IPv6 addresses, connection will fail. - If the list is empty and LDAP option setting failed earlier (during syntax validation), LDAP client will continue to use the kernel provided IPv6 address.

1 0

Re: (ITS#8892) ISC dhcpd cannot start TLS session to 389-DS after updating openldap rpm
by quanah＠symas.com 06 Aug '18

06 Aug '18

--On Monday, August 06, 2018 3:42 PM +0000 krejci(a)i3.cz wrote: > Full_Name: Mira Krejci > Version: 2.4.44-15 > OS: CentOS Linux release 7.5.1804 > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (93.99.54.254) Hello, This is likely due to RedHat's customizations to the OpenLDAP libldap library. In their most recent builds, they switched from MozNSS to OpenSSL as the underlying TLS library and wrote their own custom bridging function for this change. It has apparently caused various problems for end users. I would suggest contacting RedHat or using an unmodified version of OpenLDAP. --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