February 2016 - openldap-bugs

RE: (ITS#8374) LDAP_OPT_X_TLS_REQUIRE_CERT handling differences between ldaps:// and STARTTLS

by quanah＠zimbra.com

--On Saturday, February 20, 2016 6:06 PM +0000 dog(a)pavlov.com wrote: > > Hi, > > The box was running Ubuntu vivid so bumped to wily, which took openldap > to 2.4.41, and the results are identical. > > If I get time I'll run up a test platform and install from source, then > drop you a line with the results. Again, you could just install the builds from the LTB project. In any case, all options work fine for me with a self-signed cert with ldaps:/// URIs. (2.4.44, linked to OpenSSL). --Quanah -- Quanah Gibson-Mount Platform Architect Zimbra, Inc. -------------------- Zimbra :: the leader in open source messaging and collaboration A division of Synacor, Inc

7 years, 9 months

1
0
0 / 0

RE: (ITS#8374) LDAP_OPT_X_TLS_REQUIRE_CERT handling differences between ldaps:// and STARTTLS

by dog＠pavlov.com

Hi, The box was running Ubuntu vivid so bumped to wily, which took openldap to 2.4.41, and the results are identical. If I get time I'll run up a test platform and install from source, then drop you a line with the results. Martin...

7 years, 9 months

1
0
0 / 0

Re: (ITS#8374) LDAP_OPT_X_TLS_REQUIRE_CERT handling differences between ldaps:// and STARTTLS

by quanah＠zimbra.com

--On Friday, February 19, 2016 4:02 PM +0000 dog(a)pavlov.com wrote: > Full_Name: Martin O'Neal > Version: openldap-2.4.31 As already noted by Michael, that is an ancient release. In addition, since you're using a build provided by Debian/Ubuntu, it links to GnuTLS which has its own numerous issues. I'd strongly advise you: (a) Use a current OpenLDAP release (b) Use an OpenLDAP release that is linked to OpenSSL rather than GnuTLS If after both of those conditions are true you can still reproduce a problem, please follow up. If building OpenLDAP software is not in your line of expertise, you may wish to examine the options from the LTB project or Symas. <http://ltb-project.org/wiki/download#openldap> <https://symas.com/products/openldap-directory/> --Quanah -- Quanah Gibson-Mount Platform Architect Zimbra, Inc. -------------------- Zimbra :: the leader in open source messaging and collaboration A division of Synacor, Inc

7 years, 9 months

1
0
0 / 0

Re: (ITS#8374) LDAP_OPT_X_TLS_REQUIRE_CERT handling differences between ldaps:// and STARTTLS

by michael＠stroeder.com

dog(a)pavlov.com wrote: > Full_Name: Martin O'Neal > Version: openldap-2.4.31 Note that 2.4.31 is almost for years old. Hence the standard question: Can you reproduce this with current release 2.4.44? Ciao, Michael.

7 years, 9 months

1
0
0 / 0

(ITS#8374) LDAP_OPT_X_TLS_REQUIRE_CERT handling differences between ldaps:// and STARTTLS

by dog＠pavlov.com

Full_Name: Martin O'Neal Version: openldap-2.4.31 OS: ubuntu wily URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (82.68.2.190) The handling of the LDAP_OPT_X_TLS_REQUIRE_CERT option appears to be different between servers accessed via ldaps:// and ldap:// (plus STARTTLS) URIs. When accessing server with a self-signed certificate, the results are: ldaps:// never OK hard Error: can't contact LDAP server demand Error: can't contact LDAP server allow OK try Error: can't contact LDAP server ldap:// plus explicit ldap_start_tls_s() never OK hard OK demand OK allow OK try OK

7 years, 9 months

1
0
0 / 0

Re: (ITS#8373) replica with multiple providers hits errors

by quanah＠zimbra.com

--On Friday, February 19, 2016 12:37 AM +0000 quanah(a)zimbra.com wrote: > --On Thursday, February 18, 2016 11:01 PM +0000 quanah(a)openldap.org wrote: So I can trivially reproduce this. I make a change on each master, and boom, they go out of sync and everything's broken. --Quanah -- Quanah Gibson-Mount Platform Architect Zimbra, Inc. -------------------- Zimbra :: the leader in open source messaging and collaboration A division of Synacor, Inc

7 years, 9 months

1
0
0 / 0

Re: (ITS#8373) replica with multiple providers hits errors

by quanah＠zimbra.com

--On Thursday, February 18, 2016 11:01 PM +0000 quanah(a)openldap.org wrote: > Master SID1: > [zimbra@zre-ldap005 ~]$ ldapsearch -x -LLL -H ldapi:// -D cn=config -w > zimbra -s base -b "" contextCSN > dn: > contextCSN: 20160218220547.523250Z#000000#001#000000 > contextCSN: 20160218220604.321502Z#000000#002#000000 > > [zimbra@zre-ldap005 ~]$ ldapsearch -x -LLL -H ldapi:// -D cn=config -w > zimbra -s base -b "cn=accesslog" contextCSN > dn: cn=accesslog > contextCSN: 20160217223749.648918Z#000000#001#000000 > contextCSN: 20160218220604.321502Z#000000#002#000000 Ooops, clearly a difference here between the main db and the accesslog DB. However, nothing was logged, error wise. Here is this modification: Feb 18 16:05:47 zre-ldap005 slapd[10555]: slap_queue_csn: queueing 0x3ce84c0 20160218220547.523250Z#000000#001#000000 Feb 18 16:05:47 zre-ldap005 slapd[10555]: slap_graduate_commit_csn: removing 0x3ce84c0 20160218220547.523250Z#000000#001#000000 Feb 18 16:05:47 zre-ldap005 slapd[10555]: syncprov_sendresp: cookie=rid=100,sid=001 Feb 18 16:05:47 zre-ldap005 slapd[10555]: syncprov_sendresp: to=002, cookie=rid=100,sid=001 On the other master, we have: Feb 18 16:05:47 zre-ldap003 slapd[6947]: do_syncrep2: rid=100 cookie=rid=100,sid=001 Feb 18 16:05:47 zre-ldap003 slapd[6947]: slap_queue_csn: queueing 0x36d58c0 20160218220547.523250Z#000000#001#000000 Feb 18 16:05:47 zre-ldap003 slapd[6947]: slap_queue_csn: queueing 0x36d5800 20160218220547.523250Z#000000#001#000000 Feb 18 16:05:47 zre-ldap003 slapd[6947]: syncprov_matchops: skipping original sid 001 Feb 18 16:05:47 zre-ldap003 slapd[6947]: slap_graduate_commit_csn: removing 0x36d5800 20160218220547.523250Z#000000#001#000000 Feb 18 16:05:47 zre-ldap003 slapd[6947]: slap_graduate_commit_csn: removing 0x36d58c0 20160218220547.523250Z#000000#001#000000 Feb 18 16:05:47 zre-ldap003 slapd[6947]: syncrepl_message_to_op: rid=100 be_modify cn=admins,cn=zimbra (0) Feb 18 16:05:47 zre-ldap003 slapd[6947]: syncprov_sendresp: cookie=rid=101,sid=002,csn=20160218220547.523250Z#000000#001#000000 In the accesslog, we have: dn: reqStart=20160218220547.523064Z,cn=accesslog objectClass: auditModify structuralObjectClass: auditModify reqStart: 20160218220547.523064Z reqEnd: 20160218220547.523558Z reqType: modify reqSession: 1027 reqAuthzID: cn=config reqDN: cn=admins,cn=zimbra reqResult: 0 reqMod: description:= admin accounts reqMod: entryCSN:= 20160218220547.523250Z#000000#001#000000 reqMod: modifiersName:= cn=config reqMod: modifyTimestamp:= 20160218220547Z reqEntryUUID: c3fbf53a-6a0c-1035-9563-ef445d2cc3b6 entryCSN: 20160218220547.523250Z#000000#001#000000 entryUUID: 822e1680-6ad7-1035-8bac-2751986a6fb8 creatorsName: cn=config createTimestamp: 20160218220547Z modifiersName: cn=config modifyTimestamp: 20160218220547Z --Quanah -- Quanah Gibson-Mount Platform Architect Zimbra, Inc. -------------------- Zimbra :: the leader in open source messaging and collaboration A division of Synacor, Inc

7 years, 9 months

1
0
0 / 0

Re: (ITS#8373) replica with multiple providers hits errors

by quanah＠zimbra.com

--On Thursday, February 18, 2016 11:01 PM +0000 quanah(a)openldap.org wrote: After stopping all servers, and restarting the masters, I see the same error (53) being returned when zre-ldap003 tries to connect to zre-ldap005. So this is not specific to the replica or the change to cn=config I made on the replica. --Quanah -- Quanah Gibson-Mount Platform Architect Zimbra, Inc. -------------------- Zimbra :: the leader in open source messaging and collaboration A division of Synacor, Inc

7 years, 9 months

1
0
0 / 0

(ITS#8373) replica with multiple providers hits errors

by quanah＠openldap.org

Full_Name: Quanah Gibson-Mount Version: 2.4.44 OS: Linux 3.13 URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (75.111.52.177) I have a MMR setup, with two providers, zre-ldap003 and zre-ldap005. I have a single replica, zre-ldap002, which is configured to pull updates from both providers. However, it continually gets an error 53 from zre-ldap005 after writing an update to zre-ldap003. As far as I can tell, all contextCSN data is correct on all nodes. replica: zimbra@zre-ldap002:~$ ldapsearch -x -LLL -H ldapi:// -D cn=config -w zimbra -s base -b "" contextCSN dn: contextCSN: 20160218220547.523250Z#000000#001#000000 contextCSN: 20160218220604.321502Z#000000#002#000000 Master SID1: [zimbra@zre-ldap005 ~]$ ldapsearch -x -LLL -H ldapi:// -D cn=config -w zimbra -s base -b "" contextCSN dn: contextCSN: 20160218220547.523250Z#000000#001#000000 contextCSN: 20160218220604.321502Z#000000#002#000000 [zimbra@zre-ldap005 ~]$ ldapsearch -x -LLL -H ldapi:// -D cn=config -w zimbra -s base -b "cn=accesslog" contextCSN dn: cn=accesslog contextCSN: 20160217223749.648918Z#000000#001#000000 contextCSN: 20160218220604.321502Z#000000#002#000000 Master SID2: [zimbra@zre-ldap003 ~]$ ldapsearch -x -LLL -H ldapi:// -D cn=config -w zimbra -s base -b "" contextCSN dn: contextCSN: 20160218220547.523250Z#000000#001#000000 contextCSN: 20160218220604.321502Z#000000#002#000000 [zimbra@zre-ldap003 ~]$ ldapsearch -x -LLL -H ldapi:// -D cn=config -w zimbra -s base -b "cn=accesslog" contextCSN dn: cn=accesslog contextCSN: 20160218220547.523250Z#000000#001#000000 contextCSN: 20160218220604.321502Z#000000#002#000000%%0 Note all contextCSNs have the same value everywhere. However, when the replica attempts to replicate off of zre-ldap005, we get the following error: Feb 18 16:50:34 zre-ldap005 slapd[10555]: conn=1191 fd=18 ACCEPT from IP=10.137.242.52:38979 (IP=10.137.242.55:389) Feb 18 16:50:34 zre-ldap005 slapd[10555]: conn=1191 op=0 EXT oid=1.3.6.1.4.1.1466.20037 Feb 18 16:50:34 zre-ldap005 slapd[10555]: conn=1191 op=0 STARTTLS Feb 18 16:50:34 zre-ldap005 slapd[10555]: conn=1191 op=0 RESULT oid= err=0 etime=0.000071 text= Feb 18 16:50:34 zre-ldap005 slapd[10555]: conn=1191 fd=18 TLS established tls_ssf=128 ssf=128 tls_proto=TLSv1.2 tls_cipher=SEED-SHA Feb 18 16:50:34 zre-ldap005 slapd[10555]: conn=1191 op=1 BIND dn="uid=zmreplica,cn=admins,cn=zimbra" metho3D3D128 Feb 18 16:50:34 zre-ldap005 slapd[10555]: conn=1191 op=1 BIND dn="uid=zmreplica,cn=admins,cn=zimbra" mech=SIMPLE ssf=0 Feb 18 16:50:34 zre-ldap005 slapd[10555]: conn=1191 op=1 RESULT tag=97 err=0 etime=0.000154 text= Feb 18 16:50:34 zre-ldap005 slapd[10555]: conn=1191 op=2 SRCH base="cn=accesslog" scope=2 deref=0 filter="(&(objectClass=auditWriteObject)(reqResult=0))" Feb 18 16:50:34 zre-ldap005 slapd[10555]: conn=1191 op=2 SRCH attr=reqDN reqType reqMod reqNewRDN reqDeleteOldRDN reqNewSuperior entryCSN Feb 18 16:50:34 zre-ldap005 slapd[10555]: conn=1191 op=2 SEARCH RESULT tag=101 err=53 etime=0.000177 nentries=0 text=consumer state is newer than provider! Feb 18 16:50:34 zre-ldap005 slapd[10555]: conn=1191 op=3 UNBIND Feb 18 16:50:34 zre-ldap5 5 slapd[10555]: conn=1191 fd=18 closed This started happening after I made a modification on zre-ldap005 followed by a modification on zre-ldap003. In that case, the following was logged on zre-ldap002: Feb 18 16:06:04 zre-ldap002 slapd[11266]: do_syncrep2: rid=101 cookie=rid=101,sid=002,csn=20160218220604.321502Z#000000#002#000000 Feb 18 16:06:04 zre-ldap002 slapd[11266]: slap_queue_csn: queueing 0x3589880 20160218220604.321502Z#000000#002#000000 Feb 18 16:06:04 zre-ldap002 slapd[11266]: do_syncrep2: rid=100 cookie=r%3=100,sid=001,csn=20160218220604.321502Z#000000#002#000000 Feb 18 16:06:04 zre-ldap002 slapd[11266]: slap_graduate_commit_csn: removing 0x3589880 20160218220604.321502Z#000000#002#000000 Feb 18 16:06:04 zre-ldap002 slapd[11266]: syncrepl_message_to_op: rid=101 be_modify cn=admins,cn=zimbra (0) Feb 18 16:06:04 zre-ldap002 slapd[11266]: slap_queue_csn: queueing 0x3589740 20160218220604.321502Z#000000#002#000000 Feb 18 16:06:04 zre-ldap002 slapd[11266]: slap_graduate_commit_csn: removing 0x3589740 20160218220604.321502Z#000000#002#000000 Feb 18 16:06:04 zre-ldap002 slapd[11266]: do_syncrep2: rid=100 CSN pending, ignoring 20160218220604.321502Z#000000#002#000000 (reqStart=20160218220604.326527Z,cn=accesslog) So we see the write accepted from one master, and correctly rejected (not replayed) from the other. After this, there were no more modifications made to either master. However, I *did* make a modification to cn=config on the replica. After that was done, is when the error(53) started getting triggered: Feb 18 16:27:12 zre-ldap002 slapd[11266]: slap_queue_csn: queueing 0x3587a40 20160218222712.155976Z#000000#000#000000 Feb 18 16:27:12 zre-ldap002 slapd[11266]: slap_graduate_commit_csn: removing 0x3587a40 20160218222712.155976Z#000000#000#000000 Feb 18 16:27:12 zre-ldap002 slapd[11266]: do_syncrep2: rid=100 LDAP_RES_SEARCH_RESULT Feb 18 16:27:12 zre-ldap002 slapd[11266]: do_syncrep2: rid=100 LDAP_RES_SEARCH_RESULT (53) Server is unwilling to perform Feb 18 16:27:12 zre-ldap002 slapd[11266]: do_syncrep2: rid=100 (53) Server is unwilling to perform Feb 18 16:27:12 zre-ldap002 slapd[11266]: do_syncrepl: rid=100 rc -2 retrying

7 years, 9 months

1
0
0 / 0

(ITS#8372) Incomplete members from dynlist group when Paged Results control is specified

by subbarao＠computer.org

Full_Name: Kartik Subbarao Version: 2.4.41 OS: Ubuntu 14.04.3 LTS URL: ftp://ftp.openldap.org/incoming/kartik-subbarao-160215.tgz Submission from: (NULL) (173.75.228.155) When the Paged Results control (1.2.840.113556.1.4.319) is specified, dynlist groups after the first page return fewer numbers than should be present. I have uploaded slapd.conf and example.ldif files that can be used to reproduce the problem. Search with a page size of 1 and the filter (objectclass=groupOfURLs). The member for group1 is returned successfully, whereas no members for group2 are returned. If the page size is set to 2 or higher, the member for group2 is properly returned. ftp://ftp.openldap.org/incoming/kartik-subbarao-160215.tgz: slapd.conf example.ldif For additional context, see this post to the openldap-technical mailing list: http://www.openldap.org/lists/openldap-technical/201602/msg00102.html

7 years, 9 months

1
0
0 / 0

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

openldap-bugs February 2016