openldap-bugs

openldap-bugs@openldap.org

1 participants
20967 discussions

(ITS#5178) [feature request] pcache stats & monitoring
by ando＠sys-net.it 09 Oct '07

09 Oct '07

Full_Name: Pierangelo Masarati Version: HEAD/re24 OS: irrelevant URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (193.203.230.29) Submitted by: ando This is a feature request for stats and monitoring capabilities for pcache; basically: - the number of cached queries - the number of cached entries - possibly, a list of cached queries in cachedQueryURL form - how many times each cached query was used instead of re-running the request - the ratio answerable / cacheable for each cacheable query - some global figure like the average response time (send searchResult time - start caching time) for each query, and the overall average. Adding per-query info could be done by either extending the cachedQueryURL format or by adding a child entry for each cached query (like connections and other dynamic info). p.

1 0

Re: (ITS#4860) Sets' enhancement
by ando＠sys-net.it 09 Oct '07

09 Oct '07

> Howard Chu a écrit : > Unfortunately, it's currently heavily dependant on one of our customer's > specific schema extensions and data tree structure. The ACLs in use > implement a lot of the logic specific to their environment, therefore I > can't send them as is. > > However, I will see if I can "translate" some of the more complicated > ACLs (with sets) to perform on a simple data set for inclusion in the > test suite. > > Could some examples such as these also fit your documentation request > for sets and their applications [1]? Assuming this is the case, I will > try and provide at least a subset of our test set soon. > > Cheers, > Jon > > [1] http://www.openldap.org/lists/openldap-software/200709/msg00310.html Let me state first that right now I believe sets do not belong to slapd(8); they should rather move into a module, under the dynacl umbrella. And, as such, they should be documented separately from slapd.access(5), mostly because having them in slapd.access(5) would sort of encourage unexperienced people into (ab-)using them. Also, I'd like sets' users to document them (especially in terms of useful hints, scenarios, case studies and so), as they probably best know what one can gain from their use. Otherwise, a bare description of the syntax, although necessary, would hardly be useful to most of the users. 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 Email: pierangelo.masarati(a)sys-net.it ---------------------------------------

1 0

Re: (ITS#4860) Sets' enhancement
by hyc＠symas.com 09 Oct '07

09 Oct '07

jclarke(a)linagora.com wrote: > However, I will see if I can "translate" some of the more complicated > ACLs (with sets) to perform on a simple data set for inclusion in the > test suite. > > Could some examples such as these also fit your documentation request > for sets and their applications [1]? Assuming this is the case, I will > try and provide at least a subset of our test set soon. Absolutely. Thanks... > > Cheers, > Jon > > [1] http://www.openldap.org/lists/openldap-software/200709/msg00310.html -- -- Howard Chu Chief Architect, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc/ Chief Architect, OpenLDAP http://www.openldap.org/project/

1 0

Re: (ITS#4860) Sets' enhancement
by jclarke＠linagora.com 09 Oct '07

09 Oct '07

Howard Chu a écrit : > jclarke(a)linagora.com wrote: >> Got this one: it was a double-free in sets.c occuring after a >> slap_set_join() with lset or rset empty - the non empty set was >> returned, and then freed, causing a double-free error or segfault. >> >> The patch attached corrects this problem on RE23 and HEAD for me and >> doesn't have any side effects on our test set. However, it may not be >> the "right" way - please correct if necessary! > > Is your test set something you can clean up for inclusion in our test > suite? Unfortunately, it's currently heavily dependant on one of our customer's specific schema extensions and data tree structure. The ACLs in use implement a lot of the logic specific to their environment, therefore I can't send them as is. However, I will see if I can "translate" some of the more complicated ACLs (with sets) to perform on a simple data set for inclusion in the test suite. Could some examples such as these also fit your documentation request for sets and their applications [1]? Assuming this is the case, I will try and provide at least a subset of our test set soon. Cheers, Jon [1] http://www.openldap.org/lists/openldap-software/200709/msg00310.html -- Jonathan Clarke Cellule OSSA - Groupe LINAGORA 27 rue de Berri, 75008 Paris Tél: 01 58 18 68 28, fax: 01 58 18 68 29 http://www.linagora.com - http://www.08000linux.com

1 0

Re: (ITS#4860) Sets' enhancement
by ando＠sys-net.it 09 Oct '07

09 Oct '07

> jclarke(a)linagora.com a écrit : >> Pierangelo Masarati a écrit : >>> Should be fixed now in HEAD/re24/re23. Please test. p. >> >> I've been testing (at last, sorry for the delay), and I've come across >> another memory problem. Backtrace is below, and valgrind output is >> attached. > > Got this one: it was a double-free in sets.c occuring after a > slap_set_join() with lset or rset empty - the non empty set was > returned, and then freed, causing a double-free error or segfault. > > The patch attached corrects this problem on RE23 and HEAD for me and > doesn't have any side effects on our test set. However, it may not be > the "right" way - please correct if necessary! Thanks for spotting it - I had no time to look at your last report. I'll check the fix and eventually apply it. > Your recent fixes have solved all the issues from our test cases we were > encountering. Thank you very much for them. Sure. Cheers, 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 Email: pierangelo.masarati(a)sys-net.it ---------------------------------------

1 0

Re: (ITS#4860) Sets' enhancement
by hyc＠symas.com 09 Oct '07

09 Oct '07

jclarke(a)linagora.com wrote: > Got this one: it was a double-free in sets.c occuring after a > slap_set_join() with lset or rset empty - the non empty set was > returned, and then freed, causing a double-free error or segfault. > > The patch attached corrects this problem on RE23 and HEAD for me and > doesn't have any side effects on our test set. However, it may not be > the "right" way - please correct if necessary! Is your test set something you can clean up for inclusion in our test suite? > Your recent fixes have solved all the issues from our test cases we were > encountering. Thank you very much for them. > > Jon -- -- Howard Chu Chief Architect, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc/ Chief Architect, OpenLDAP http://www.openldap.org/project/

1 0

Re: (ITS#4860) Sets' enhancement
by jclarke＠linagora.com 09 Oct '07

09 Oct '07

This is a multi-part message in MIME format. --------------080102080503050601010703 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit jclarke(a)linagora.com a écrit : > Pierangelo Masarati a écrit : >> Should be fixed now in HEAD/re24/re23. Please test. p. > > I've been testing (at last, sorry for the delay), and I've come across > another memory problem. Backtrace is below, and valgrind output is attached. Got this one: it was a double-free in sets.c occuring after a slap_set_join() with lset or rset empty - the non empty set was returned, and then freed, causing a double-free error or segfault. The patch attached corrects this problem on RE23 and HEAD for me and doesn't have any side effects on our test set. However, it may not be the "right" way - please correct if necessary! Your recent fixes have solved all the issues from our test cases we were encountering. Thank you very much for them. Jon -- Jonathan Clarke Cellule OSSA - Groupe LINAGORA 27 rue de Berri, 75008 Paris Tél: 01 58 18 68 28, fax: 01 58 18 68 29 http://www.linagora.com - http://www.08000linux.com --------------080102080503050601010703 Content-Type: text/x-patch; name="jonathan-clarke-071008.patch" Content-Transfer-Encoding: 7bit Content-Disposition: inline; filename="jonathan-clarke-071008.patch" --- servers/slapd/sets.c.orig 2007-10-08 18:20:08.000000000 +0200 +++ servers/slapd/sets.c 2007-10-08 18:22:29.000000000 +0200 @@ -261,11 +261,15 @@ } else { set = set_dup( cp, lset, SLAP_SET_LREF2REF( op_flags ) ); + /* set array reference has been copied - don't free */ + op_flags |= SLAP_SET_LREFVAL | SLAP_SET_LREFARR; break; } } else if ( j == 0 ) { set = set_dup( cp, rset, SLAP_SET_RREF2REF( op_flags ) ); + /* set array reference has been copied - don't free */ + op_flags |= SLAP_SET_RREFVAL | SLAP_SET_RREFARR; break; } --------------080102080503050601010703--

1 0

Re: (ITS#4940) libldap doesn't wait for server's TLS close_notify
by hyc＠symas.com 09 Oct '07

09 Oct '07

Philip Guenther wrote: > Anyway, this issue isn't worth keep an ITS open about, as it doesn't > actually cause failures or visible errors. I might someday chase down a > clean way of implementing this second option, but only after the much more > useful work of coming up with a reasonable API to let event-driven apps do > STARTTLS without blocking. Someday. Ah yes, Someday. Drop by this page when you get a chance: http://scratchpad.wikia.com/wiki/LDAP_C_API Some day it'll be more than just a single page... -- -- Howard Chu Chief Architect, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc/ Chief Architect, OpenLDAP http://www.openldap.org/project/

1 0

Re: (ITS#4940) libldap doesn't wait for server's TLS close_notify
by guenther+ldapdev＠sendmail.com 09 Oct '07

09 Oct '07

On Mon, 8 Oct 2007, Howard Chu wrote: ... >> There are a number of ways this can be handled: >> 1) change the client to wait until it sees the server's close_notify alert >> by >> replacing "SSL_shutdown( p->ssl );" in tls.c with the two lines: >> if (SSL_shutdown( p->ssl ) == 0) >> SSL_shutdown( p->ssl ); >> (I have confirmed that this works. As documented, the first call >> will return 1 if the server's close_notify has already been >> received, if not, the second call will block until it is received.) > > So if the server doesn't send one, the client will be stuck waiting forever? It would also unblock if the server closed the connection. One downside of this option that I thought of later is that it shifts the TCP CLOSE_WAIT state from the client to the server. Fixing that would add more complexity to the sockbuf layer than this entire change is worth. Having chatted with Kurt about this at the last IETF meeting and pondered failure modes, I'm no longer in favor of this option. >> 2) change the client to not bother to send a close_notify alert when >> it's just going to close() the connection; change the server to not >> send a close_notify if it didn't get one. <...> > > Sounds like a change in the SSL library, not something for us to worry > about. Since "send a close_notify alert" == "call SSL_shutdown() for the first time", it would be a change in how the SSL library was used by libldap. Anyway, this issue isn't worth keep an ITS open about, as it doesn't actually cause failures or visible errors. I might someday chase down a clean way of implementing this second option, but only after the much more useful work of coming up with a reasonable API to let event-driven apps do STARTTLS without blocking. Someday. Philip Guenther

1 0

Re: ITS#5174 openldap.schema entry not valid per RFC 4512
by ando＠sys-net.it 09 Oct '07

09 Oct '07

> The reason I reported it was that I wrote a parser for LDAP schema > based directly on the formal grammar, downloaded all the schema from > OpenLDAP as a test, and that was the only schema that broke, and only > on the one element. I did not have any trouble with the OpenLDAP > software accepting the schema. If you use a grammar builder (I used > ANTLR) rather than a hand-coded parser, being permissive makes it a > bit more complex. Allowing the elements to appear in any order would > be easy to parse for the RFC 4512 elements, because they happen to be > defined with markers ("NAME", "DESC" and so on) that makes them easy > to differentiate, but then enforcing at-most-once semantics on the > elements requires either an additional pass or some hand coded > predicates to check for duplicates in a data structure being built on- > the-fly. Thanks for the feedback. It's now fixed in HEAD/re24. 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 Email: pierangelo.masarati(a)sys-net.it ---------------------------------------

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