November 2008 - openldap-bugs

Re: (ITS#5828) Some slap* man pages only talk about slapd.conf

by ghenry＠OpenLDAP.org

----- "andrew findlay" <andrew.findlay(a)skills-1st.co.uk> wrote: > On Mon, Nov 24, 2008 at 10:02:56AM +0000, ghenry(a)OpenLDAP.org wrote: > > > The following man pages still talk about only slapd.conf: > > > Will fix. > > When doing so, would it be possible to avoid the duplication that > has started showing up in the Admin Guide? One section for doing a > job with slapd.conf and another one for the same job using cn=config > seems like a sure-fire way to get inconsistent information. It also > means that updates take (at least) twice as long to write. We should maybe just pick on configuration method and stick to it throughout the whole guide. POssibly cn=config, then point to the man pages for normal slapd.conf, or the other way round. slapd.conf is easier for just copying and pasting, but saying that, so is an LDIF. Gavin. -- Kind Regards, Gavin Henry. OpenLDAP Engineering Team. E ghenry(a)OpenLDAP.org Community developed LDAP software. http://www.openldap.org/project/

14 years, 4 months

1
0
0 / 0

Re: (ITS#5828) Some slap* man pages only talk about slapd.conf

by andrew.findlay＠skills-1st.co.uk

On Mon, Nov 24, 2008 at 10:02:56AM +0000, ghenry(a)OpenLDAP.org wrote: > The following man pages still talk about only slapd.conf: > Will fix. When doing so, would it be possible to avoid the duplication that has started showing up in the Admin Guide? One section for doing a job with slapd.conf and another one for the same job using cn=config seems like a sure-fire way to get inconsistent information. It also means that updates take (at least) twice as long to write. Andrew -- ----------------------------------------------------------------------- | From Andrew Findlay, Skills 1st Ltd | | Consultant in large-scale systems, networks, and directory services | | http://www.skills-1st.co.uk/ +44 1628 782565 | -----------------------------------------------------------------------

14 years, 4 months

1
0
0 / 0

Re: (ITS#5823) clients/tools don't honor ldap.conf defaults

by h.b.furuseth＠usit.uio.no

ghenry(a)OpenLDAP.org writes: > Cool. I say we rewrite it all in Java, this C stuff is hard to understand ;-) Perhaps we should take this to -devel now... -- Hallvard

14 years, 4 months

1
0
0 / 0

Re: (ITS#5825) syncrepl default is no retry

by h.b.furuseth＠usit.uio.no

hyc(a)symas.com writes: > Have to ensure that the default setting doesn't persist in cn=config, > so that it will keep warning until an explicit value is set. That's on my wish list for cn=config defaults in general. -- Hallvard

14 years, 4 months

1
0
0 / 0

(ITS#5828) Some slap* man pages only talk about slapd.conf

by ghenry＠OpenLDAP.org

Full_Name: Gavin Henry Version: OS: URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (212.159.59.85) Submitted by: ghenry The following man pages still talk about only slapd.conf: slapacl slapauth slapdn slappasswd slaptest Things like: "It opens the slapd.conf(5) configuration file," Will fix. Gavin.

14 years, 4 months

1
0
0 / 0

ITS#5039 Support config for start_tls in ldap.conf

by hyc＠symas.com

In 2.4.13 you can specify "starttls" as an URL extension for the URI in the config file. This was discussed in this thread http://www.openldap.org/lists/openldap-devel/200810/msg00053.html I think that's sufficient to fulfill this enhancement request. -- -- Howard Chu CTO, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc/ Chief Architect, OpenLDAP http://www.openldap.org/project/

14 years, 4 months

1
0
0 / 0

Re: (ITS#5827) Syncprov persistent operations info leaking

by hyc＠symas.com

hyc(a)symas.com wrote: > I don't think the current fix is complete. Due to the Abandon check at 1190, > it's possible (though extremely unlikely) for an Abandon to arrive between the > start and end of a mod op, and cause the final decrement to be skipped still. > Probably need to do some restructuring to catch this, I'll look at this some more. Never mind, syncprov_op_cleanup already catches these cases. -- -- Howard Chu CTO, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc/ Chief Architect, OpenLDAP http://www.openldap.org/project/

14 years, 4 months

1
0
0 / 0

Re: (ITS#5827) Syncprov persistent operations info leaking

by hyc＠symas.com

Pierangelo Masarati wrote: > hyc(a)symas.com wrote: >> ando(a)sys-net.it wrote: >>> Full_Name: Pierangelo Masarati >>> Version: >>> OS: >>> URL: ftp://ftp.openldap.org/incoming/ >>> Submission from: (NULL) (81.72.89.40) >>> Submitted by: ando >>> >>> >>> After heavily loading a MMR pool, valgrind finds the following: >>> >>> ==29650== 2,437 (240 direct, 2,197 indirect) bytes in 3 blocks are definitely >>> lo >>> st in loss record 13 of 15 >> Most likely because we increment s_inuse at line 1250, at the beginning of a >> non-Delete write op, and don't decrement it at the end of the op. I think this >> should be simple to fix, will take a look. > > Seems to work. Thanks, p. I don't think the current fix is complete. Due to the Abandon check at 1190, it's possible (though extremely unlikely) for an Abandon to arrive between the start and end of a mod op, and cause the final decrement to be skipped still. Probably need to do some restructuring to catch this, I'll look at this some more. -- -- Howard Chu CTO, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc/ Chief Architect, OpenLDAP http://www.openldap.org/project/

14 years, 4 months

1
0
0 / 0

Re: (ITS#5827) Syncprov persistent operations info leaking

by ando＠sys-net.it

hyc(a)symas.com wrote: > ando(a)sys-net.it wrote: >> Full_Name: Pierangelo Masarati >> Version: >> OS: >> URL: ftp://ftp.openldap.org/incoming/ >> Submission from: (NULL) (81.72.89.40) >> Submitted by: ando >> >> >> After heavily loading a MMR pool, valgrind finds the following: >> >> ==29650== 2,437 (240 direct, 2,197 indirect) bytes in 3 blocks are definitely >> lo >> st in loss record 13 of 15 > > Most likely because we increment s_inuse at line 1250, at the beginning of a > non-Delete write op, and don't decrement it at the end of the op. I think this > should be simple to fix, will take a look. Seems to work. Thanks, p. Ing. Pierangelo Masarati OpenLDAP Core Team SysNet s.r.l. via Dossi, 8 - 27100 Pavia - ITALIA http://www.sys-net.it ----------------------------------- Office: +39 02 23998309 Mobile: +39 333 4963172 Fax: +39 0382 476497 Email: ando(a)sys-net.it -----------------------------------

14 years, 4 months

1
0
0 / 0

Re: (ITS#5827) Syncprov persistent operations info leaking

by hyc＠symas.com

ando(a)sys-net.it wrote: > Full_Name: Pierangelo Masarati > Version: > OS: > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (81.72.89.40) > Submitted by: ando > > > After heavily loading a MMR pool, valgrind finds the following: > > ==29650== 2,437 (240 direct, 2,197 indirect) bytes in 3 blocks are definitely > lo > st in loss record 13 of 15 Most likely because we increment s_inuse at line 1250, at the beginning of a non-Delete write op, and don't decrement it at the end of the op. I think this should be simple to fix, will take a look. -- -- Howard Chu CTO, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc/ Chief Architect, OpenLDAP http://www.openldap.org/project/

14 years, 4 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 November 2008