openldap-bugs August 2010

openldap-bugs@openldap.org

23 participants
68 discussions

Re: (ITS#6629) send_search_entry() does not clear controls
by quanah＠zimbra.com 25 Aug '10

25 Aug '10

--On August 26, 2010 3:44:02 AM +0000 masarati(a)aero.polimi.it wrote: > Full_Name: Pierangelo Masarati > Version: HEAD/re24 > OS: irrelevant > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (129.72.175.5) > Submitted by: ando > > > REP_CTRLS_MUSTBEFREED is only honored by send_ldap_response(); when > response controls are attached to slap_send_search_entry() it is not > honored. This does not surface because controls must be malloc'ed on the > slab; however, it clearly appears when built with SLAP_NO_SL_MALLOC. Interesting -- I'm seeing an issue where I can get slapd to consume all available memory on the system by using paged results. It takes a while to do so (depending on how much memory is available), but it's 100% repeatable. The more mixes of paged and non paged results there are with large result sets, the more quickly it happens. However, I do not build with SLAP_NO_SL_MALLOC (or at least, not intentionally ;) ). --Quanah -- Quanah Gibson-Mount Principal Software Engineer Zimbra, Inc -------------------- Zimbra :: the leader in open source messaging and collaboration

1 0

(ITS#6630) Support for draft-ietf-ldapext-ldapv3-dupent-08.txt
by masarati＠aero.polimi.it 25 Aug '10

25 Aug '10

Full_Name: Pierangelo Masarati Version: HEAD OS: irrelevant URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (129.72.165.68) Submitted by: ando I've just committed (to contrib/slapd-modules/dupent/) a nearly complete support for draft-ietf-ldapext-ldapv3-dupent-08.txt (expired) in form of an overlay. I'm not 100% sure about the format of the control request/response values, and I couldn't check interoperability with other software; I only tested it with ldapsearch passing it -E '2.16.840.1.113719.1.27.101.1=:<control request value>', so please use with care (and report). p.

1 0

(ITS#6629) send_search_entry() does not clear controls
by masarati＠aero.polimi.it 25 Aug '10

25 Aug '10

Full_Name: Pierangelo Masarati Version: HEAD/re24 OS: irrelevant URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (129.72.175.5) Submitted by: ando REP_CTRLS_MUSTBEFREED is only honored by send_ldap_response(); when response controls are attached to slap_send_search_entry() it is not honored. This does not surface because controls must be malloc'ed on the slab; however, it clearly appears when built with SLAP_NO_SL_MALLOC. p.

1 0

Re: (ITS#6628) Connection numbering starts at 1000
by quanah＠zimbra.com 24 Aug '10

24 Aug '10

--On Wednesday, August 25, 2010 3:12 AM +0200 masarati(a)aero.polimi.it wrote: >> --On Tuesday, August 24, 2010 5:47 PM -0700 Howard Chu <hyc(a)symas.com> >> wrote: >> >>> quanah(a)zimbra.com wrote: >>>> Full_Name: Quanah Gibson-Mount >>>> Version: 2.4.23 >>>> OS: Linux 2.6 >>>> URL: ftp://ftp.openldap.org/incoming/ >>>> Submission from: (NULL) (75.111.45.108) >>>> >>>> >>>> With OpenLDAP 2.4.23, new connections start numbered at 1000 instead of >>>> at 1 >>> >>> No. cvs log shows that this was patched about a year ago and first >>> released in 2.4.20. Not a bug, closing this ITS. >> >> Connections starting at 1000 is clearly a bug, regardless of when it was >> introduced. > > That was intended, to store connections as unsigned and reserve lower > numbers for special connections (e.g. internal operations and so). I > don't see how using an arbitrary offset in logs can be considered a bug. > 1000 is much like 10, 1024, 666 or 0xbad. Eh, I just need to re-write some scripts to start some things at 1000 then. ;) --Quanah -- Quanah Gibson-Mount Principal Software Engineer Zimbra, Inc -------------------- Zimbra :: the leader in open source messaging and collaboration

1 0

Re: (ITS#6628) Connection numbering starts at 1000
by masarati＠aero.polimi.it 24 Aug '10

24 Aug '10

> --On Tuesday, August 24, 2010 5:47 PM -0700 Howard Chu <hyc(a)symas.com> > wrote: > >> quanah(a)zimbra.com wrote: >>> Full_Name: Quanah Gibson-Mount >>> Version: 2.4.23 >>> OS: Linux 2.6 >>> URL: ftp://ftp.openldap.org/incoming/ >>> Submission from: (NULL) (75.111.45.108) >>> >>> >>> With OpenLDAP 2.4.23, new connections start numbered at 1000 instead of >>> at 1 >> >> No. cvs log shows that this was patched about a year ago and first >> released in 2.4.20. Not a bug, closing this ITS. > > Connections starting at 1000 is clearly a bug, regardless of when it was > introduced. That was intended, to store connections as unsigned and reserve lower numbers for special connections (e.g. internal operations and so). I don't see how using an arbitrary offset in logs can be considered a bug. 1000 is much like 10, 1024, 666 or 0xbad. p.

1 0

Re: (ITS#6628) Connection numbering starts at 1000
by quanah＠zimbra.com 24 Aug '10

24 Aug '10

--On Tuesday, August 24, 2010 5:47 PM -0700 Howard Chu <hyc(a)symas.com> wrote: > quanah(a)zimbra.com wrote: >> Full_Name: Quanah Gibson-Mount >> Version: 2.4.23 >> OS: Linux 2.6 >> URL: ftp://ftp.openldap.org/incoming/ >> Submission from: (NULL) (75.111.45.108) >> >> >> With OpenLDAP 2.4.23, new connections start numbered at 1000 instead of >> at 1 > > No. cvs log shows that this was patched about a year ago and first > released in 2.4.20. Not a bug, closing this ITS. Connections starting at 1000 is clearly a bug, regardless of when it was introduced. --Quanah -- Quanah Gibson-Mount Principal Software Engineer Zimbra, Inc -------------------- Zimbra :: the leader in open source messaging and collaboration

1 0

Re: (ITS#6628) Connection numbering starts at 1000
by hyc＠symas.com 24 Aug '10

24 Aug '10

quanah(a)zimbra.com wrote: > Full_Name: Quanah Gibson-Mount > Version: 2.4.23 > OS: Linux 2.6 > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (75.111.45.108) > > > With OpenLDAP 2.4.23, new connections start numbered at 1000 instead of at 1 No. cvs log shows that this was patched about a year ago and first released in 2.4.20. Not a bug, 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#6628) Connection numbering starts at 1000
by quanah＠zimbra.com 24 Aug '10

24 Aug '10

Full_Name: Quanah Gibson-Mount Version: 2.4.23 OS: Linux 2.6 URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (75.111.45.108) With OpenLDAP 2.4.23, new connections start numbered at 1000 instead of at 1 Aug 24 16:10:03 zre-ldap001 slapd[10200]: @(#) $OpenLDAP: slapd 2.4.23 (Aug 6 2010 12:44:14) $#012#011root@zre-ubuntu10-64:/home/build/p4/GNR/ThirdParty/openldap/openldap-2.4.23.2z/servers /slapd Aug 24 16:10:03 zre-ldap001 slapd[10201]: slapd starting Aug 24 16:10:08 zre-ldap001 slapd[10201]: conn=1000 fd=12 ACCEPT from IP=10.137.242.51:40585 (IP=10.137.242.51:389) Aug 24 16:10:08 zre-ldap001 slapd[10201]: conn=1000 op=0 BIND dn="" method=128 Aug 24 16:10:08 zre-ldap001 slapd[10201]: conn=1000 op=0 RESULT tag=97 err=0 text= Aug 24 16:10:08 zre-ldap001 slapd[10201]: conn=1000 op=1 SRCH base="" scope=0 deref=0 filter="(objectClass=*)" Aug 24 16:10:08 zre-ldap001 slapd[10201]: conn=1000 op=1 SEARCH RESULT tag=101 err=0 nentries=1 text= Aug 24 16:10:08 zre-ldap001 slapd[10201]: conn=1000 op=2 UNBIND Aug 24 16:10:08 zre-ldap001 slapd[10201]: conn=1000 fd=12 closed Aug 24 16:13:43 zre-ldap001 slapd[10201]: daemon: shutdown requested and initiated. Aug 24 16:13:43 zre-ldap001 slapd[10201]: slapd shutdown: waiting for 0 operations/tasks to finish Aug 24 16:13:43 zre-ldap001 slapd[10201]: slapd stopped. Aug 24 16:14:14 zre-ldap001 slapd[10305]: @(#) $OpenLDAP: slapd 2.4.23 (Aug 6 2010 12:44:14) $#012#011root@zre-ubuntu10-64:/home/build/p4/GNR/ThirdParty/openldap/openldap-2.4.23.2z/servers /slapd Aug 24 16:14:14 zre-ldap001 slapd[10306]: slapd starting Aug 24 16:14:19 zre-ldap001 slapd[10306]: conn=1000 fd=12 ACCEPT from IP=10.137.242.51:55960 (IP=10.137.242.51:389) Aug 24 16:14:19 zre-ldap001 slapd[10306]: conn=1000 op=0 BIND dn="" method=128 Aug 24 16:14:19 zre-ldap001 slapd[10306]: conn=1000 op=0 RESULT tag=97 err=0 text= Aug 24 16:14:19 zre-ldap001 slapd[10306]: conn=1000 op=1 SRCH base="" scope=0 deref=0 filter="(objectClass=*)" Aug 24 16:14:19 zre-ldap001 slapd[10306]: conn=1000 op=1 SEARCH RESULT tag=101 err=0 nentries=1 text= Aug 24 16:14:19 zre-ldap001 slapd[10306]: conn=1000 op=2 UNBIND Aug 24 16:14:19 zre-ldap001 slapd[10306]: conn=1000 fd=12 closed Aug 24 16:15:57 zre-ldap001 slapd[10306]: daemon: shutdown requested and initiated. Aug 24 16:15:57 zre-ldap001 slapd[10306]: slapd shutdown: waiting for 0 operations/tasks to finish Aug 24 16:15:57 zre-ldap001 slapd[10306]: slapd stopped. Aug 24 16:17:02 zre-ldap001 slapd[10554]: @(#) $OpenLDAP: slapd 2.4.23 (Aug 6 2010 12:44:14) $#012#011root@zre-ubuntu10-64:/home/build/p4/GNR/ThirdParty/openldap/openldap-2.4.23.2z/servers /slapd Aug 24 16:17:02 zre-ldap001 slapd[10555]: slapd starting Aug 24 16:17:07 zre-ldap001 slapd[10555]: conn=1000 fd=12 ACCEPT from IP=10.137.242.51:55961 (IP=10.137.242.51:389) Aug 24 16:17:07 zre-ldap001 slapd[10555]: conn=1000 op=0 BIND dn="" method=128 Aug 24 16:17:07 zre-ldap001 slapd[10555]: conn=1000 op=0 RESULT tag=97 err=0 text= Aug 24 16:17:07 zre-ldap001 slapd[10555]: conn=1000 op=1 SRCH base="" scope=0 deref=0 filter="(objectClass=*)" Aug 24 16:17:07 zre-ldap001 slapd[10555]: conn=1000 op=1 SEARCH RESULT tag=101 err=0 nentries=1 text= Aug 24 16:17:07 zre-ldap001 slapd[10555]: conn=1000 op=2 UNBIND Aug 24 16:17:07 zre-ldap001 slapd[10555]: conn=1000 fd=12 closed

1 0

Re: (ITS#6626) NDB Backend with Syncrepl failure
by mhardin＠symas.com 24 Aug '10

24 Aug '10

This was an error on my part and I was promptly corrected by Howard Chu = (Thanks, Howard!). syncrepl is supported for back-ndb and did work when = the code was contributed. We don't know what's happened in the = intervening time, though. Perhaps George will open an ITS? Sorry for any confusion this may have caused. Cheers, -Matt Matthew Hardin Symas Corporation - The LDAP Guys http://www.symas.com On Aug 24, 2010, at 12:13 AM, gtzanetis(a)pylones.gr wrote: > I've received a confirmation from Symas, which is the back_ndb = developer th=3D > at replication does not apply to this backend. They explained that by = desig=3D > n each slapd instance is intended to connect directly to the NDB = cluster by=3D > way of back-ndb. High availability is handled by the cluster. >=20 >=20

1 0

RE: (ITS#6626) NDB Backend with Syncrepl failure
by gtzanetis＠pylones.gr 23 Aug '10

23 Aug '10

I've received a confirmation from Symas, which is the back_ndb developer th= at replication does not apply to this backend. They explained that by desig= n each slapd instance is intended to connect directly to the NDB cluster by= way of back-ndb. High availability is handled by the cluster.

1 0

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

openldap-bugs August 2010