openldap-bugs November 2008

openldap-bugs@openldap.org

44 participants
242 discussions

(ITS#5827) Syncprov persistent operations info leaking
by ando＠sys-net.it 23 Nov '08

23 Nov '08

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 ==29650== at 0x40053C0: malloc (vg_replace_malloc.c:149) ==29650== by 0x825903B: ber_memalloc_x (memory.c:226) ==29650== by 0x80A743C: ch_malloc (ch_malloc.c:54) ==29650== by 0x82029CA: syncprov_op_search (syncprov.c:2200) ==29650== by 0x8104F7B: overlay_op_walk (backover.c:660) ==29650== by 0x81051B0: over_op_func (backover.c:722) ==29650== by 0x8105234: over_op_search (backover.c:744) ==29650== by 0x80897F6: fe_op_search (search.c:366) ==29650== by 0x8089196: do_search (search.c:217) ==29650== by 0x8085F41: connection_operation (connection.c:1090) ==29650== by 0x808641B: connection_read_thread (connection.c:1216) ==29650== by 0x8222E9C: ldap_int_thread_pool_wrapper (tpool.c:663) ==29650== by 0xDEB46A: start_thread (in /lib/libpthread-2.5.so) ==29650== by 0xD42DBD: clone (in /lib/libc-2.5.so) ==29594== 2,913 (160 direct, 2,753 indirect) bytes in 2 blocks are definitely lo st in loss record 10 of 15 ==29594== at 0x40053C0: malloc (vg_replace_malloc.c:149) ==29594== by 0x825903B: ber_memalloc_x (memory.c:226) ==29594== by 0x80A743C: ch_malloc (ch_malloc.c:54) ==29594== by 0x82029CA: syncprov_op_search (syncprov.c:2200) ==29594== by 0x8104F7B: overlay_op_walk (backover.c:660) ==29594== by 0x81051B0: over_op_func (backover.c:722) ==29594== by 0x8105234: over_op_search (backover.c:744) ==29594== by 0x80897F6: fe_op_search (search.c:366) ==29594== by 0x8089196: do_search (search.c:217) ==29594== by 0x8085F41: connection_operation (connection.c:1090) ==29594== by 0x808641B: connection_read_thread (connection.c:1216) ==29594== by 0x8222E9C: ldap_int_thread_pool_wrapper (tpool.c:663) ==29594== by 0xDEB46A: start_thread (in /lib/libpthread-2.5.so) ==29594== by 0xD42DBD: clone (in /lib/libc-2.5.so) p.

1 0

Re: (ITS#5825) syncrepl default is no retry
by ando＠sys-net.it 23 Nov '08

23 Nov '08

hyc(a)symas.com wrote: > ando(a)sys-net.it wrote: >> Full_Name: Pierangelo Masarati >> Version: irrelevant >> OS: irrelevant >> URL: ftp://ftp.openldap.org/incoming/ >> Submission from: (NULL) (82.63.140.131) >> Submitted by: ando >> >> >> Syncrepl by default uses no retry. This is extremely useless, as syncrepl with >> no retry will probably break, sooner or later, without notifying why it >> happened. > > Legacy behavior, since retry was added later... > >> I believe it would be safe to have either: >> >> - a "safe" retry value (not too often, e.g. every hour, forever) > > Sounds fine, just add it to the doc. > >> - a warning (or an error) if retry is not given when configuring syncrepl > > Sounds rather annoying. We could combine these: if no retry was configured, > give the warning and use a default of 1 hour. 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. > >> Another interesting feature would be to register syncrepl-specific parameters in >> back-monitor's entry of each database, that > >> - show the status of syncrepl (whether it's up, if rp) >> >> - show the timestamp of the last successful refresh >> >> - show the timestamp of the last failed attempt, and the reason of the failure > > Sounds fine, but unless you can add these quickly I don't see any reason to > hold 2.4.13 for it. Didn't mean to :) By now, only the warning is being issued. I don't think I can implement the rest for 2.4.13, will need to wait for next release. 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 -----------------------------------

1 0

Re: (ITS#5823) clients/tools don't honor ldap.conf defaults
by ghenry＠OpenLDAP.org 22 Nov '08

22 Nov '08

----- hyc(a)symas.com wrote: > h.b.furuseth(a)usit.uio.no wrote: > > Pierangelo Masarati writes: > >> -ZZ should be deprecated, and -Z should simply and strictly > require > >> StartTLS. > > > > Good point. Except then people who are used to new clients will > > make insecure connections when using old clients. Maybe -Z should > > be an error instead... > > > > What I'd really really like to do is throw away all the options, > > rename the programs, and start over. This time with the same > option > > names in ldap tools, slap tools, and slapd itself. Goes with the > > someday-in-the-future library rewrite, I suppose. > > OpenLDAP 3.0... > > The question is, when do we stop the 2.x stream and begin 3.0? Cool. I say we rewrite it all in Java, this C stuff is hard to understand ;-) -- Kind Regards, Gavin Henry. OpenLDAP Engineering Team. E ghenry(a)OpenLDAP.org Community developed LDAP software. http://www.openldap.org/project/

1 0

Re: (ITS#5825) syncrepl default is no retry
by hyc＠symas.com 22 Nov '08

22 Nov '08

ando(a)sys-net.it wrote: > Full_Name: Pierangelo Masarati > Version: irrelevant > OS: irrelevant > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (82.63.140.131) > Submitted by: ando > > > Syncrepl by default uses no retry. This is extremely useless, as syncrepl with > no retry will probably break, sooner or later, without notifying why it > happened. Legacy behavior, since retry was added later... > I believe it would be safe to have either: > > - a "safe" retry value (not too often, e.g. every hour, forever) Sounds fine, just add it to the doc. > - a warning (or an error) if retry is not given when configuring syncrepl Sounds rather annoying. We could combine these: if no retry was configured, give the warning and use a default of 1 hour. 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. > Another interesting feature would be to register syncrepl-specific parameters in > back-monitor's entry of each database, that > - show the status of syncrepl (whether it's up, if rp) > > - show the timestamp of the last successful refresh > > - show the timestamp of the last failed attempt, and the reason of the failure Sounds fine, but unless you can add these quickly I don't see any reason to hold 2.4.13 for it. -- -- 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#5826) syncrepl leaking filter in MMR
by ando＠sys-net.it 22 Nov '08

22 Nov '08

Full_Name: Pierangelo Masarati Version: HEAD/re24 OS: irrelevant URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (82.63.140.131) Submitted by: ando The filterstring is not freed if generated. A fix is coming. p.

1 0

(ITS#5825) syncrepl default is no retry
by ando＠sys-net.it 22 Nov '08

22 Nov '08

Full_Name: Pierangelo Masarati Version: irrelevant OS: irrelevant URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (82.63.140.131) Submitted by: ando Syncrepl by default uses no retry. This is extremely useless, as syncrepl with no retry will probably break, sooner or later, without notifying why it happened. I believe it would be safe to have either: - a "safe" retry value (not too often, e.g. every hour, forever) - a warning (or an error) if retry is not given when configuring syncrepl Another interesting feature would be to register syncrepl-specific parameters in back-monitor's entry of each database, that - show the status of syncrepl (whether it's up, if rp) - show the timestamp of the last successful refresh - show the timestamp of the last failed attempt, and the reason of the failure p.

1 0

ldap_domain2hostlist is for "ldap" service only
by Marc Lavergne 22 Nov '08

22 Nov '08

Have there been any considerations in providing a similar API for a service name other than "ldap"? For example, what if I wanted to find global catalog servers? Even though GCs are Active Directory specific, I don't see why OpenLDAP would not support that type of query. It seems like a new API where the service name can be passed in as a parameter (eg. "gc") would be useful. Before using ITS to issue a bug report, I thought I'd ask via this forum. Thanks.

4 4

Re: (ITS#5821) Small mistake in man page
by ando＠sys-net.it 22 Nov '08

22 Nov '08

andrew.findlay(a)skills-1st.co.uk wrote: > On Thu, Nov 20, 2008 at 02:43:22PM +0000, kkalev(a)gmail.com wrote: > >> In the manpage for slapd.conf (slapd.conf.5) in the limits directive description >> the value for the size.unchecked pattern should be disabled and not disable >> according to limits.c > > Well spotted! > > I am curious about why this feature was added. The man page says: > > If it is set to disable, the search is not even performed; this > can be used to disallow searches for a specific set of users. > > Disallowing searches seems more like an ACL job than a limit job > to me, so I did not mention this when writing up the Limits features > for the Admin Guide. > > Does anyone actually use unchecked=disabled and if so, why? ACLs act too late, after the search has been performed; this acts at the candidate selection level, and with similar granularity in terms of identity the request is performed as. Now, search access to the searchBase is checked, so a search can be stopped even earlier. This was not requested when this limits feature was introduced. 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 -----------------------------------

1 0

Re: (ITS#5821) Small mistake in man page
by andrew.findlay＠skills-1st.co.uk 21 Nov '08

21 Nov '08

On Thu, Nov 20, 2008 at 02:43:22PM +0000, kkalev(a)gmail.com wrote: > In the manpage for slapd.conf (slapd.conf.5) in the limits directive description > the value for the size.unchecked pattern should be disabled and not disable > according to limits.c Well spotted! I am curious about why this feature was added. The man page says: If it is set to disable, the search is not even performed; this can be used to disallow searches for a specific set of users. Disallowing searches seems more like an ACL job than a limit job to me, so I did not mention this when writing up the Limits features for the Admin Guide. Does anyone actually use unchecked=disabled and if so, why? 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 | -----------------------------------------------------------------------

1 0

Re: (ITS#5823) clients/tools don't honor ldap.conf defaults
by hyc＠symas.com 21 Nov '08

21 Nov '08

h.b.furuseth(a)usit.uio.no wrote: > Pierangelo Masarati writes: >> -ZZ should be deprecated, and -Z should simply and strictly require >> StartTLS. > > Good point. Except then people who are used to new clients will > make insecure connections when using old clients. Maybe -Z should > be an error instead... > > What I'd really really like to do is throw away all the options, > rename the programs, and start over. This time with the same option > names in ldap tools, slap tools, and slapd itself. Goes with the > someday-in-the-future library rewrite, I suppose. OpenLDAP 3.0... The question is, when do we stop the 2.x stream and begin 3.0? -- -- 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

← Newer
1
2
3
4
5
6
7
8
...
25
Older →

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