openldap-bugs

openldap-bugs@openldap.org

1 participants
20960 discussions

Re: (ITS#6243) back-monitor fails to report entry cache usage
by quanah＠zimbra.com 13 Aug '09

13 Aug '09

--On Thursday, August 13, 2009 8:56 PM +0200 masarati(a)aero.polimi.it wrote: > >> A quick hack consists in removing the test for SLAP_GLUE_SUBORDINATE() in >> monitor_subsys_database_init(). This will expose subordinate databases >> and thus should allow back-bdb and back-hdb to hook their cache stats >> stuff. Probably this is the best approach. I would complement it by >> adding a olmIsSubordinate attribute with TRUE value, and/or a >> olmSuperiorSuffix containing the suffix of the superior. > > An even better approach would be to append subordinate databases below the > superior one... but I'd leave this for 2.5 :) Thanks for handling this. :) --Quanah -- Quanah Gibson-Mount Principal Software Engineer Zimbra, Inc -------------------- Zimbra :: the leader in open source messaging and collaboration

1 0

Re: (ITS#6243) back-monitor fails to report entry cache usage
by masarati＠aero.polimi.it 13 Aug '09

13 Aug '09

> A quick hack consists in removing the test for SLAP_GLUE_SUBORDINATE() in > monitor_subsys_database_init(). This will expose subordinate databases > and thus should allow back-bdb and back-hdb to hook their cache stats > stuff. Probably this is the best approach. I would complement it by > adding a olmIsSubordinate attribute with TRUE value, and/or a > olmSuperiorSuffix containing the suffix of the superior. An even better approach would be to append subordinate databases below the superior one... but I'd leave this for 2.5 :) p.

1 0

Re: (ITS#6243) back-monitor fails to report entry cache usage
by masarati＠aero.polimi.it 13 Aug '09

13 Aug '09

> Any chance we can get this fixed for 2.4.18 for the real backends? I > think > making it so you can see the counters per-real backend should definitely > be > in place. How to handle the frontend is interesting and definitely should > be addressed as well but isn't (to me at least) quite as crucial at this > moment. ;) A quick hack consists in removing the test for SLAP_GLUE_SUBORDINATE() in monitor_subsys_database_init(). This will expose subordinate databases and thus should allow back-bdb and back-hdb to hook their cache stats stuff. Probably this is the best approach. I would complement it by adding a olmIsSubordinate attribute with TRUE value, and/or a olmSuperiorSuffix containing the suffix of the superior. p.

1 0

Re: (ITS#6243) back-monitor fails to report entry cache usage
by quanah＠zimbra.com 13 Aug '09

13 Aug '09

--On Thursday, August 06, 2009 7:25 PM +0200 masarati(a)aero.polimi.it wrote: >> >> >> --On August 5, 2009 7:17:43 PM +0000 masarati(a)aero.polimi.it wrote: >> >>>> This may be specific to glued databases (databases rooted at ""). >>> >>> The problem could be partially addressed by telling back-bdb (who's >>> maintaining this data in the monitor backend) to check subordinates as >>> soon as it discovers it's a glue instance. However, this poses two >>> different problems: >>> >>> - is the aggregate information resulting from adding all glued databases >>> cache usage still useful? >>> >>> - what happens if heterogeneous databases are glued? Significantly, >>> what >>> if the superior database is not bdb/hdb? >>> >>> Probably, the monitor database should also present subordinate databases >>> as separate entries. >> >> Interestingly, in my case, there's only one real database in play for the >> glue as it is, since it's rooted at "". All other database definitions >> come before it (cn=config, cn=accesslog, cn=monitor). > > but... are you actually gluing something? In any case, this is not > specific to the case of empty suffix in the glue database. I could easily > reproduce it with a "normal" glued setup, and I was about to start fixing > things when the two above questions came to my mind. > >> I'm also curious why back-monitor develops stats for the other caches but >> specifically not for entry cache. > > I haven't looked in detail, but it makes sense that some operation occurs > within the glue database which requires caching something, but not > entries. > > - The entry cache monitor shows the value of bdb->bi_cache.c_cursize; > > - the DN cache monitor shows the value of bdb->bi_cache.c_eiused, which > should be the number of entryinfo structures used; > > - the IDL cache monitor shows the value of bdb->bi_idl_cache_size. > > In my very simple tests, I only saw something populating the DN cache, > which means some internal operation required to allocate some entryinfo > structures that remain 'round. > > In any case, it's only showing information related to its database > structure, it is by no means collecting info from the glued databases. Any chance we can get this fixed for 2.4.18 for the real backends? I think making it so you can see the counters per-real backend should definitely be in place. How to handle the frontend is interesting and definitely should be addressed as well but isn't (to me at least) quite as crucial at this moment. ;) --Quanah -- Quanah Gibson-Mount Principal Software Engineer Zimbra, Inc -------------------- Zimbra :: the leader in open source messaging and collaboration

1 0

Re: (ITS#6190) back-meta tls start only works when set before any target specification
by masarati＠aero.polimi.it 13 Aug '09

13 Aug '09

Fixed in HEAD, please test. Thanks, p.

1 0

Re: (ITS#6253) sizelimit is enforced before applying local filters with a translucent overlay
by hyc＠symas.com 13 Aug '09

13 Aug '09

masarati(a)aero.polimi.it wrote: >> If a 'sizelimit' is required in a query to an LDAP server that uses a >> translucent overlay, and the filter has to be split between a remote >> filter and >> a local filter, and the remote filter returns more than 'sizelimit' >> objects, you >> will get a 'sizelimit' error even if the local filter would have filtered >> out >> enough objects to keep the number of objects under the sizelimit. >> >> In my case I have an LDAP holding basic posixAccount information plus a >> translucent holding Samba information. >> >> The following query: >> % ldapsearch -z 1 -x -s one -b 'ou=Users,dc=hq,dc=eboxhq,dc=com' -H >> 'ldap://127.0.0.1:1390' >> '(&(objectClass=posixAccount)(sambaSID=S-1-5-21-3818554400-921237426-3143208535-5004))' >> uid >> >> only matches one object in the LDAP directory, but it will fail because >> the >> remote LDAP will return every user and then the 'sizelimit' is immediately >> enforced before applying the local (sambaSID) filter. >> >> The result with -z 1 is: >> # search result >> search: 2 >> result: 4 Size limit exceeded >> >> # numResponses: 1 >> >> The result without the -z option is: >> # bar, Users, hq.eboxhq.com >> dn: uid=bar,ou=Users,dc=hq,dc=eboxhq,dc=com >> uid: bar >> >> # search result >> search: 2 >> result: 0 Success >> >> # numResponses: 2 >> # numEntries: 1 >> >> I think the 'sizelimit' should only be applied to the last set of results >> and >> not to the number of results in intermediate steps. > > This could be partially cured by removing any size limit while propagating > the request to the remote server. Please note that, however, this would > not prevent the remote server from applying administrative size limits > regardless of what the client is requesting. And I would probably use the unchecked sizelimit within the overlay as well. -- -- 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

Re: (ITS#6247)
by Kurt＠OpenLDAP.org 13 Aug '09

13 Aug '09

On Aug 13, 2009, at 7:24 AM, masarati(a)aero.polimi.it wrote: > Please check the code, and see if you agree in the attributions > (significantly, in releasing the copyright to the OpenLDAP > foundation). No. Once Daniel corrects his submission, and the Foundation finds it acceptable, it can be used in OpenLDAP with or without modification. No further of legal agreement with Daniel is needed and hence should not be requested. That is, Daniel's copyright notice must provide and must be relied on to give appropriate license. The notice you include in your submission would (assuming Daniel's submission is accepted, and your submission is derived (in the copyright sense) from his) would be wrong as it doesn't preserve his notice. The end result in OpenLDAP Software would be something like: * Copyright 2009 The OpenLDAP Foundation. * Portions Copyright 2009 Daniel Pluta. * Portions Copyright 2009 Pierangelo Masarati * All rights reserved. ... The PORTIONS COPYRIGHT: comment must be removed. Instead, the ACKNOWLEDGEMENT section should include whatever attribution (in the non-copyright sense) is appropriate in this case. Something like: This work was developed by Pierangelo Masarati based upon a previous work developed by Daniel Pluta. Both this and the previous work were developed for inclusion in OpenLDAP Software. > Also, note that an OID from OpenLDAP's devel arc has been used, but > not > yet allocated. I plan to do it shortly. > > p. > >

1 0

Re: (ITS#6247)
by Kurt＠OpenLDAP.org 13 Aug '09

13 Aug '09

On Aug 12, 2009, at 1:12 PM, daniel(a)pluta.biz wrote: > Hi, > > I've just uploaded an updated version. > > Changes regarding schema: > - Added EQ-Matching rule to both nowNot{Before|After} attributes > - changed attribute nowNotAfter from single- into multi-value > > ftp://ftp.openldap.org/incoming/daniel-pluta-now-090812.tgz > This submission, aside from not being in the form of a patch, doesn't include "notice of origin" as required by our contributing guidelines <http://www.openldap.org/devel/contributing.html >. Also, your tarball contains a source file that includes a copyright notice, the tarball includes other file(s). This makes it non-obvious as to whether your copyright notice is intended to apply only to the source file but to the tarball as a whole (including the other file(s)). (This is why our guidelines ask for patches with notices at top, it makes it more clear as to what copyright you are asserting.) As an alternative to reworking your submission as a patch, you can instead include a file called COPYRIGHT which contains both of the required notices. Please revise your contribution so that it may be properly considered. Consideration of Ando's submission will be deferred until such time as your contribution is accepted (as it appears to be based upon yours). -- Kurt

1 0

Re: (ITS#6247)
by masarati＠aero.polimi.it 13 Aug '09

13 Aug '09

Please see <ftp://ftp.openldap.org/incoming/pierangelo-masarati-2009-08-13-now2.1.c> for a minimal implementation that instantiates a specific syntax (that only allows the empty string) and works for generalizedTime as well as CSN syntaxes. Valid filters are (createTimestamp:nowOrEarlier:=) (entryCSN:nowOrLater:=) Please check the code, and see if you agree in the attributions (significantly, in releasing the copyright to the OpenLDAP foundation). Also, note that an OID from OpenLDAP's devel arc has been used, but not yet allocated. I plan to do it shortly. p.

1 0

Re: (ITS#6253) sizelimit is enforced before applying local filters with a translucent overlay
by masarati＠aero.polimi.it 13 Aug '09

13 Aug '09

> If a 'sizelimit' is required in a query to an LDAP server that uses a > translucent overlay, and the filter has to be split between a remote > filter and > a local filter, and the remote filter returns more than 'sizelimit' > objects, you > will get a 'sizelimit' error even if the local filter would have filtered > out > enough objects to keep the number of objects under the sizelimit. > > In my case I have an LDAP holding basic posixAccount information plus a > translucent holding Samba information. > > The following query: > % ldapsearch -z 1 -x -s one -b 'ou=Users,dc=hq,dc=eboxhq,dc=com' -H > 'ldap://127.0.0.1:1390' > '(&(objectClass=posixAccount)(sambaSID=S-1-5-21-3818554400-921237426-3143208535-5004))' > uid > > only matches one object in the LDAP directory, but it will fail because > the > remote LDAP will return every user and then the 'sizelimit' is immediately > enforced before applying the local (sambaSID) filter. > > The result with -z 1 is: > # search result > search: 2 > result: 4 Size limit exceeded > > # numResponses: 1 > > The result without the -z option is: > # bar, Users, hq.eboxhq.com > dn: uid=bar,ou=Users,dc=hq,dc=eboxhq,dc=com > uid: bar > > # search result > search: 2 > result: 0 Success > > # numResponses: 2 > # numEntries: 1 > > I think the 'sizelimit' should only be applied to the last set of results > and > not to the number of results in intermediate steps. This could be partially cured by removing any size limit while propagating the request to the remote server. Please note that, however, this would not prevent the remote server from applying administrative size limits regardless of what the client is requesting. p.

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