openldap-bugs

openldap-bugs@openldap.org

1 participants
20967 discussions

(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

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

23 Aug '10

I forgot to state that the operating system is Red Hat 5 Enterprise 64 bit -----Original Message----- From: openldap-its(a)OpenLDAP.org [mailto:openldap-its@OpenLDAP.org]=20 Sent: Friday, August 20, 2010 4:24 PM To: George Tzanetis Subject: Re: (ITS#6626) NDB Backend with Syncrepl failure *** THIS IS AN AUTOMATICALLY GENERATED REPLY *** Thanks for your report to the OpenLDAP Issue Tracking System. Your report has been assigned the tracking number ITS#6626. One of our support engineers will look at your report in due course. Note that this may take some time because our support engineers are volunteers. They only work on OpenLDAP when they have spare time. If you need to provide additional information in regards to your issue report, you may do so by replying to this message. Note that any mail sent to openldap-its(a)openldap.org with (ITS#6626) in the subject will automatically be attached to the issue report. mailto:openldap-its@openldap.org?subject=3D(ITS#6626) You may follow the progress of this report by loading the following URL in a web browser: http://www.OpenLDAP.org/its/index.cgi?findid=3D6626 Please remember to retain your issue tracking number (ITS#6626) on any further messages you send to us regarding this report. If you don't then you'll just waste our time and yours because we won't be able to properly track the report. Please note that the Issue Tracking System is not intended to be used to seek help in the proper use of OpenLDAP Software. Such requests will be closed. OpenLDAP Software is user supported. http://www.OpenLDAP.org/support/ -------------- Copyright 1998-2007 The OpenLDAP Foundation, All Rights Reserved.

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