openldap-bugs February 2016

openldap-bugs@openldap.org

15 participants
45 discussions

RE: (ITS#8374) LDAP_OPT_X_TLS_REQUIRE_CERT handling differences between ldaps:// and STARTTLS
by quanah＠zimbra.com 20 Feb '16

20 Feb '16

--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

1 0

RE: (ITS#8374) LDAP_OPT_X_TLS_REQUIRE_CERT handling differences between ldaps:// and STARTTLS
by dog＠pavlov.com 20 Feb '16

20 Feb '16

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

1 0

Re: (ITS#8374) LDAP_OPT_X_TLS_REQUIRE_CERT handling differences between ldaps:// and STARTTLS
by quanah＠zimbra.com 20 Feb '16

20 Feb '16

--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

1 0

Re: (ITS#8374) LDAP_OPT_X_TLS_REQUIRE_CERT handling differences between ldaps:// and STARTTLS
by michael＠stroeder.com 20 Feb '16

20 Feb '16

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.

1 0

(ITS#8374) LDAP_OPT_X_TLS_REQUIRE_CERT handling differences between ldaps:// and STARTTLS
by dog＠pavlov.com 19 Feb '16

19 Feb '16

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

1 0

Re: (ITS#8373) replica with multiple providers hits errors
by quanah＠zimbra.com 18 Feb '16

18 Feb '16

--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

1 0

Re: (ITS#8373) replica with multiple providers hits errors
by quanah＠zimbra.com 18 Feb '16

18 Feb '16

--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

1 0

Re: (ITS#8373) replica with multiple providers hits errors
by quanah＠zimbra.com 18 Feb '16

18 Feb '16

--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

1 0

(ITS#8373) replica with multiple providers hits errors
by quanah＠openldap.org 18 Feb '16

18 Feb '16

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

1 0

(ITS#8372) Incomplete members from dynlist group when Paged Results control is specified
by subbarao＠computer.org 15 Feb '16

15 Feb '16

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

1 0

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

openldap-bugs February 2016