- openldap-bugs - openldap.org

Re: (ITS#6246) SSL fails over a network unless slapd runs with -d 2
by hyc＠symas.com 17 Aug '09

17 Aug '09

E.M. van Gasteren wrote: >>> server, and the answer is just to upgrade since .12 is rather out of >> >> Hm! I'll see if I can get the 2.4.15 openldap stuff from Fedora 11 >> repo's running on lt2 first. > > I ran into serious problems with lt2 and had to rebuild it. I took the > opportunity to use Fedora 11 with openldap 2.4.15. That seems to have > solved the problem. Thanks for the followup, glad it's working for you. 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

Re: (ITS#6246) SSL fails over a network unless slapd runs with -d 2
by Ed＠vanGasteren.net 17 Aug '09

17 Aug '09

On 08/11/2009 01:05 PM, E.M. van Gasteren wrote: > > > On 08/11/2009 04:44 AM, Howard Chu wrote: >> Ed(a)vanGasteren.net wrote: >>> Full_Name: Ed van Gasteren >>> Version: 2.4.12 and 2.4.15 >>> OS: linux (Fedora 10, 11) >>> URL: ftp://ftp.openldap.org/incoming/ >>> Submission from: (NULL) (85.223.76.221) >>> >>> >>> On system lt2 (up to date Fedora 10) I run openldap (2.4.12) server >>> and clients. >>> The configuration is such that things work as expected even with >>> security >>> tightened up to "TLSVerifyClient demand". ldapsearch (either to -H >>> ldaps or with >>> -ZZ), nss and gq with TLS work like a charm. >>> >>> On system lt1 (up to date Fedora 11) I run openldap clients (2.4.15), >>> gq and >>> Thunderbird connecting to the server on lt2. TLS/SSL only works if I >>> run slapd >>> with "-d 2". If I run slapd without it then ldapsearch hangs on "TLS >>> trace: >>> SSL_connect:SSLv3 read server certificate A". >>> >>> Seems as if the normal code path has a flaw which gets >>> corrected/bypassed by the >>> debugging code. >> >> Doesn't sound familiar, I've never had this problem. However, the TLS >> code was refactored in rev 2.4.14, and it's always possible we missed >> something in the churn. How does openssl s_client react under the same >> conditions? If it hangs the same way, then that points to a bug on the > > Should have mentioned that. It indeed hangs the same way, in the middle > of getting over the "Acceptable client certificate CA names". -- cut -- >> server, and the answer is just to upgrade since .12 is rather out of > > Hm! I'll see if I can get the 2.4.15 openldap stuff from Fedora 11 > repo's running on lt2 first. I ran into serious problems with lt2 and had to rebuild it. I took the opportunity to use Fedora 11 with openldap 2.4.15. That seems to have solved the problem.

1 0

Re: (ITS#4730) Overlay that generates operational attributes to support GUI interaction
by jonathan＠phillipoux.net 17 Aug '09

17 Aug '09

On 17/08/2009 11:09, michael(a)stroeder.com wrote: > masarati(a)aero.polimi.it wrote: >>> >>> I've added support for 'allowedAttributesEffective' in web2ldap recently >>> which >>> works with AD. I tried this overlay but it seg faults with recent OpenLDAP >>> version. Any chance to get this back on the radar? >> >> I've built and tested my copy of allowed.c with HEAD and re24 and it works >> as expected. However, I might have modified it to keep pace with baseline >> code evolution without resubmitting modifications. I can't check right >> now but I will. If needed, I'll resubmit the modified code, so consider >> it done. >> >> The main reason I didn't put it directly in contrib/ is that at that time >> I was considering the opportunity of packaging all contributions and >> customizations intended for samba4 in something as self contained as >> possible (in the end, supporting all samba4 related extensions may result >> in stacking dozens of overlays, which may result in overhead and possibly >> in incompatibilities, something we might need to deal with at some point). >> >> However, as your interest seems to revitalize this feature, I see no >> objection in putting it at least in contrib (if there's enough consensus). > > I'd highly appreciate to find copy under contrib/. Other people I know also > have interest in that. Many thanks. Absolutely, I for one am very interested. Looking forward to it :) Jonathan

1 0

Re: (ITS#4730) Overlay that generates operational attributes to support GUI interaction
by michael＠stroeder.com 17 Aug '09

17 Aug '09

masarati(a)aero.polimi.it wrote: >> >> I've added support for 'allowedAttributesEffective' in web2ldap recently >> which >> works with AD. I tried this overlay but it seg faults with recent OpenLDAP >> version. Any chance to get this back on the radar? > > I've built and tested my copy of allowed.c with HEAD and re24 and it works > as expected. However, I might have modified it to keep pace with baseline > code evolution without resubmitting modifications. I can't check right > now but I will. If needed, I'll resubmit the modified code, so consider > it done. > > The main reason I didn't put it directly in contrib/ is that at that time > I was considering the opportunity of packaging all contributions and > customizations intended for samba4 in something as self contained as > possible (in the end, supporting all samba4 related extensions may result > in stacking dozens of overlays, which may result in overhead and possibly > in incompatibilities, something we might need to deal with at some point). > > However, as your interest seems to revitalize this feature, I see no > objection in putting it at least in contrib (if there's enough consensus). I'd highly appreciate to find copy under contrib/. Other people I know also have interest in that. Many thanks. Ciao, Michael.

1 0

Re: (ITS#4730) Overlay that generates operational attributes to support GUI interaction
by masarati＠aero.polimi.it 17 Aug '09

17 Aug '09

> HI! > > I've added support for 'allowedAttributesEffective' in web2ldap recently > which > works with AD. I tried this overlay but it seg faults with recent OpenLDAP > version. Any chance to get this back on the radar? Michael, I've built and tested my copy of allowed.c with HEAD and re24 and it works as expected. However, I might have modified it to keep pace with baseline code evolution without resubmitting modifications. I can't check right now but I will. If needed, I'll resubmit the modified code, so consider it done. The main reason I didn't put it directly in contrib/ is that at that time I was considering the opportunity of packaging all contributions and customizations intended for samba4 in something as self contained as possible (in the end, supporting all samba4 related extensions may result in stacking dozens of overlays, which may result in overhead and possibly in incompatibilities, something we might need to deal with at some point). However, as your interest seems to revitalize this feature, I see no objection in putting it at least in contrib (if there's enough consensus). p.

1 0

Re: (ITS#6258) slaptest -f slapd.conf -F slapd.d returns errors without DB
by masarati＠aero.polimi.it 17 Aug '09

17 Aug '09

> Full_Name: Andrew Bartlett > Version: CVS HEAD > OS: Fedora 10 > URL: > Submission from: (NULL) (59.167.251.137) > > > When running slaptest to convert between slapd.conf and slapd.d format > configuration, before the databases exist, the slaptest returns with an > non-zero > error code and prints warnings. > > If I add -u to the command line, then it does not perform the conversion. > > In Samba4's provision system, I wish to run using cn=config from the very > start, > and so wish to do the conversion before the databases are created. > > I had expected -u to quiet the warnings, but it was unexpected that it > would > also not perform the conversion. (I understand it is also considered a > 'dry > run' parameter). > > Can I have a new parameter added to allow a behaviour of 'do the > conversion, > don't check the database vaildity'? I think having a "dry dun" that does no harm, and a "safe" (although perhaps overconservative) behavior are very important, so I wouldn't favor a modification of their behavior (let alone the implied behavioral change issues). However I don't see any issue in having a specific, well documented behavior implemented within a specific option. Perhaps, given it is a specific and not recommended behavior in normal (read: overconservative) use, it could go under the "-o" switch, which is a catchall for specific options. p.

1 0

(ITS#6258) slaptest -f slapd.conf -F slapd.d returns errors without DB
by abartlet＠samba.org 16 Aug '09

16 Aug '09

Full_Name: Andrew Bartlett Version: CVS HEAD OS: Fedora 10 URL: Submission from: (NULL) (59.167.251.137) When running slaptest to convert between slapd.conf and slapd.d format configuration, before the databases exist, the slaptest returns with an non-zero error code and prints warnings. If I add -u to the command line, then it does not perform the conversion. In Samba4's provision system, I wish to run using cn=config from the very start, and so wish to do the conversion before the databases are created. I had expected -u to quiet the warnings, but it was unexpected that it would also not perform the conversion. (I understand it is also considered a 'dry run' parameter). Can I have a new parameter added to allow a behaviour of 'do the conversion, don't check the database vaildity'? Thanks, Andrew Bartlett

1 0

Re: (ITS#6247)
by daniel＠pluta.biz 16 Aug '09

16 Aug '09

Howard Chu schrieb: > Kurt(a)OpenLDAP.org wrote: >> With that, I leave determination of the technical suitability to the >> Project. @Kurt: my given copyright notices meet my intentions. > I'm not sure why the 2 additional syntaxes are useful. If you want to > define a generalizedTime attribute that cannot be compared for ordering, > simply omit the ORDERING rule from the attribute's definition. I thought, that it is possible to "overwrite" the ORDERING (even if its left empty) by using any kind of syntax-related matching rule assertion... This is a quite old posting from the list but nevertheless I would like to cite it: http://www.openldap.org/lists/openldap-devel/200010/msg00092.html ------8<-------8<------ >Also, I have found this interesting section in RFC 2252: > >----- >8. Matching Rules > > Servers which implement the extensibleMatch filter SHOULD allow all > the matching rules listed in this section to be used in the > extensibleMatch. In general these servers SHOULD allow matching > rules to be used with all attribute types known to the server, when > the assertion syntax of the matching rule is the same as the value > syntax of the attribute. Yes. That is, if the held value is syntax X, one should be able to use any matching rule in which the assertion syntax X. ------8<-------8<------ > The use of negatives is rather confusing. In the example, instead of > "nowNotBefore" and "nowNotAfter" I would simply have called them > "startDate" and "endDate". In general, the names indeed sound quite strange. But that seems only a matter of style. NotAfter and NotBefore is borrowed from ssl certificates' validNotBefore/-After fields. As I've called the module "now" I just replaced "valid" by "now"... On the other hand I wanted to be sure to not collide with some might be existing attribute definitions. > The language is also confusing in other areas, I don't understand what > property you're trying to convey with the terms "dead center attribute" simply the lower and the upper limits of a time period (lower: nowNotBefore, upper: nowNotAfter) > or "syntactically standalone attribute". All I've ment is just a new syntax name to differentiate regarding the special use of "now" and to avoid the possibility regarding my (possibly wrong) assumption that matching rules can be "overwritten". > On a slightly related note, in the context of time-relative ACLs, it > would be worthwhile to define a behavior for time-of-day comparisons > (i.e., just compare hours:minutes:seconds, excluding year/month/day). This kind of feature sounds fine to me, too. Perhaps something like this could be implemented by introducing some kind of officeHourSyntax + matching rule which operates on e.g. "day(s)_of_week#hh:mm:ss#hh:mm:ss" attribute values (just my first thought and very simplified). On the other side, using only one attribute which stores a start as well as an end timestamp is not what I originally wanted for "now" because I would like to have the possibility to track period extensions using the multi-valued upper dead center attribute. > Companies often want to limit access to resources to only a set of > office hours, etc. Of course to properly handle the "office hours" case > would also require day-of-week matching. That may be getting to be too > complicated for this particular submission, but it seems closely related > so I mention it here. In my opinion your suggestion sounds really interesting. I personally just had searched for some kind of solution to get rid of the just-in-time event-triggered dependencies regarding provisioning of interconnected (not replicated) IDM-systems. So "now's" scope targets to longer (more static, not often changing) time-distances. The check for the "office hours case" could be handled by an all-in-wonder (multi-valued) attribute which stores "day(s)#start#end". Many thanks for your feedback. Some additional feedback/clarification regarding the above mentioned "overwriting" of matching rules would be very fine, too (e.g. a link where I can get the detailed specs).

1 0

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

16 Aug '09

> On a slightly related note, in the context of time-relative ACLs, it would > be > worthwhile to define a behavior for time-of-day comparisons (i.e., just > compare hours:minutes:seconds, excluding year/month/day). Companies often > want > to limit access to resources to only a set of office hours, etc. Of course > to > properly handle the "office hours" case would also require day-of-week > matching. That may be getting to be too complicated for this particular > submission, but it seems closely related so I mention it here. Howard, I was also thinking of something like that. Since we basically have a field available in the matching rule (the asserted value), I suggested to add an assertion syntax defaulting to the empty value. I was planning to turn this assertion syntax into a timestamp mask that allows to filter what fractions should be asserted. Another possibly related issue is locale: the time of slapd is supposed to be UTC, but filtering on working hours and so should be done keeping into account timezone, daylight saving and so. The assertion syntax could handle this in a user-friendly manner. Probably, I better step off and formalize things before further coding. p.

1 0

(ITS#6257) libldap: getopt flag to return the SASL username
by michael＠stroeder.com 16 Aug '09

16 Aug '09

Full_Name: Michael Ströder Version: HEAD OS: URL: Submission from: (NULL) (84.163.93.2) libldap should be capable of returning SASL username obtained with sasl_getprop( sasl_context, SASL_USERNAME, ... ) as result of ldap_get_option()

1 0

Re: (ITS#6247)
by hyc＠symas.com 16 Aug '09

16 Aug '09

Kurt(a)OpenLDAP.org wrote: > With that, I leave determination of the technical suitability to the > Project. It took me several passes through this discussion and the README to understand what the intent of this code is. Just to make sure I get it, let me restate what I saw: 3 extended matching rules for comparing a timestamp attribute to the server's current clock. I'm not sure why the 2 additional syntaxes are useful. If you want to define a generalizedTime attribute that cannot be compared for ordering, simply omit the ORDERING rule from the attribute's definition. The use of negatives is rather confusing. In the example, instead of "nowNotBefore" and "nowNotAfter" I would simply have called them "startDate" and "endDate". The language is also confusing in other areas, I don't understand what property you're trying to convey with the terms "dead center attribute" or "syntactically standalone attribute". On a slightly related note, in the context of time-relative ACLs, it would be worthwhile to define a behavior for time-of-day comparisons (i.e., just compare hours:minutes:seconds, excluding year/month/day). Companies often want to limit access to resources to only a set of office hours, etc. Of course to properly handle the "office hours" case would also require day-of-week matching. That may be getting to be too complicated for this particular submission, but it seems closely related so I mention it here. -- -- 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 15 Aug '09

15 Aug '09

Daniel, While I understand you to have both some IPR concerns and technical concerns with what Ando proposed, I will only concern myself to the IPR issues. Thank you for updating your contribution to provide the required notices. I have provided guidance to Ando on how to create a work derived from your submission which, I believe, mets the terms of the license, the OpenLDAP Public License, you granted. In particular, I provided him guidance on how to properly "retain your copyright statement and notices". Presuming your notices are properly retained, I see no IPR issue here in the project accepting your contribution and/or Ando's derived work, and the Foundation distributing either or both. I do regularly review commits to our source repository to ensure IPR issues are adequately addressed, but do feel free to raise any issue you see in how we handle materials which you have copyright interest in. Beyond that, I leave it to the Project to determine the technical suitability of these contributions and what, if any, modifications should be made prior to inclusion in OpenLDAP Software. Given your license grant, the Foundation sees no obligation to seek further permission from you and hence will not seek additional permission before redistributing your work, with or without modification. If it was your intent to require those redistributing your work, with or without modification, to obtain some additional permission from you, please immediately advise us that your copyright statement and notice do not reflect your intentions. If immediately advised, we will try to honor your intentions. Otherwise, we will continue to assume, as we do now, that your copyright statement and notice reflect your intentions at the time of your contribution was offered. With that, I leave determination of the technical suitability to the Project. Regards, Kurt

1 0

Re: (ITS#4730) Overlay that generates operational attributes to support GUI interaction
by masarati＠aero.polimi.it 15 Aug '09

15 Aug '09

> HI! > > I've added support for 'allowedAttributesEffective' in web2ldap recently > which > works with AD. I tried this overlay but it seg faults with recent OpenLDAP > version. Any chance to get this back on the radar? Not *now*, possibly shortly. p.

1 0

(ITS#6256) segfault in syncrepl_add
by jonathan＠phillipoux.net 15 Aug '09

15 Aug '09

Full_Name: Jonathan Clarke Version: RE24 and HEAD from today OS: URL: ftp://ftp.openldap.org/incoming/jonathan-clarke-syncrepl-20090815.patch Submission from: (NULL) (88.164.187.72) syncinfo_free attempts: sie->si_cookieState->cs_ref-- Although si_cookieState may be NULL. When adding a syncrepl consumer (either through slapd.conf or online via cn=config), if the syncrepl config line causes a parse error, syncinfo_free is called and makes slapd segfault. Other paths through syncrepl_add may cause this too. The patch above corrects this.

1 0

Re: (ITS#6225) GSSAPI support for client library (fixes)
by mimir＠samba.org 15 Aug '09

15 Aug '09

--fUYQa+Pmc3FrFX/N Content-Type: text/plain; charset=iso-8859-2 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Fri, Jul 24, 2009 at 09:20:46PM -0700, Howard Chu wrote: > mimir(a)samba.org wrote: >> Full_Name: Rafal Szczesniak >> Version: Stable (2.4.16) >> OS: GNU/Linux >> URL: http://www.samba.org/~mimir/gssapi-bugfix.diff >> Submission from: (NULL) (67.51.54.234) >> >> >> This is a bugfix patch for OpenLDAP's gssapi support. >> > One of these patches appears to duplicate ITS#6092. As the original=20 > author of this code, could you also take a look at #6091 and #6093? Yes, will do. Sorry about late reply, but first I was travelling and then I went for a holidays. cheers, --=20 Rafal Szczesniak Samba Team member http://www.samba.org Likewise Software http://www.likewise.com --fUYQa+Pmc3FrFX/N Content-Type: application/pgp-signature; name="signature.asc" Content-Description: Digital signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (GNU/Linux) iD8DBQFKhpcNHvdfyv3qiKkRAnssAKCaoT2CpqhPfHkmx1sATZBQREFgIQCfVKz6 L6ab8DXdz3XlCQqrRsul6Cw= =MklT -----END PGP SIGNATURE----- --fUYQa+Pmc3FrFX/N--

1 0

(ITS#6247)
by daniel＠pluta.biz 15 Aug '09

15 Aug '09

I've just removed four unnecessary Debug() statements (to get rid of the warnings during the build). ftp://ftp.openldap.org/incoming/daniel-pluta-now-090815-2.tgz Please note there are still only dummy values assigned as OIDs.

1 0

(ITS#6247)
by daniel＠pluta.biz 15 Aug '09

15 Aug '09

I've just removed four ugly Debug() statements. ftp://ftp.openldap.org/incoming/daniel-pluta-now-090815-2.tgz BTW: There are still only DUMMY-Values assigned as OIDs.

1 0

(ITS#6247)
by daniel＠pluta.biz 15 Aug '09

15 Aug '09

Dear Pierangelo, (dear Kurt), first of all my special thanks belong to both of you for your contribution to the on going discussions. Secondly I want to take the opportunity just right now to clarify that I do not agree to your idea or suggestion to extend the copyright in direction of a dual-portion-copyright statement. Based on my analysis of your surprisingly fast submitted code sample I came to the following conclusion and justification regarding my decision above: Last but not least I would have appreciated it if you would have contacted me *before* changing the code and not to mention my copyright notice. Thanks Kurt for your intervention. Besides this, as time, discussion and development has continuously moved on (even before your kind of "uncoordinated emergency submit") it seems to me that your sudden sample code does not cover any of my primary intentions already rudimentary contained in "now.c" and mentioned during the discussion: - there's no kind of inheritance of matching rules (all are directly associated to generalizedTime / CSN) - additionally the nowOrLater *and* the nowOrEarlier-rules are associated simultaneously to one and the same attribute (what makes no difference for single-valued attribute and thus could be done. On the other hand this leads to false positively reported valid but indeed invalid entries in case of multi-valued attributes - details see below). - you have not implemented any sort of possibility to allow the definition of separate "syntactically standalone" attributes (derived from generalizedTime/CSN, by independent syntax) to limit LE/GE filtering for both dead center attributes. (limiting search access using ACLs would obviously not work because the extensible search needs to be allowed). - multi-valued upper dead center timestamp attributes can not be handled correctly by your code. I have not investigated in deep but it is clear to me that in case of multiple values whereas one or more timestamp/CSN values are in the past, while at least one is in the future leads to the above mentioned false positive reporting in your code. - It seems to me that you have not tested the behavior of your suggested code properly in this short period of time (your tests have only seem to cover createTimestamp - which btw do not make any sense in concern to now.c's common intention in case the createTimestamp's value has not been faked ;-)). - as your code changes significantly changes the behavior and intention of now.c your submit also lacks any kind of documentation (besides the code, which I had to analyze first). In my opinion your submit sadly does not represent a very useful enhancement nor a functional extension (in the sense of the original goal of now.c) which could be integrated without major adaptations. That's the reason why I'm currently not see any reason to share my copyright notice. Nevertheless, as I've already told you before the discussion with you have always been very helpful for me so I've added you willingly to the acknowledgments section. I hope you understand my explanations and it will be fine for you. Of course I'm available and ready for further technical discussions ... Last but not least and from lessons learn: I think some kind of a formal specification (external to my head ;-)) would be very helpful to understand the design ideas, decisions as well as the new chances (and possible limitations) now.c introduces into LDAP. One or perhaps even more related I-Ds are currently a work in progress here at my side. I've uploaded a new version of now.c (as tgz because it contains various files, e.g. a sample schema in ldif- and schema-format for easier testing and perhaps as a basis for on going discussions). I hope I've correctly updated the IPR statement according my above expressed intention and according the needs of the OpenLDAP foundation. Kurt could you please have a look on it again? The updated version can be obtained from here: ftp://ftp.openldap.org/incoming/daniel-pluta-now-090815.tgz Thanks a lot and best regards Daniel -------- Original-Nachricht -------- Betreff: Re: [OFFLINE] Re: (ITS#6247) Datum: Thu, 13 Aug 2009 08:54:35 -0700 Von: Kurt Zeilenga <kurt(a)OpenLDAP.org> An: masarati(a)aero.polimi.it CC: daniel(a)pluta.biz Referenzen: <200908131112.n7DBCYIx025879(a)boole.openldap.org> <46026.93.149.38.235.1250177284.squirrel(a)www.aero.polimi.it> On Aug 13, 2009, at 8:28 AM, masarati(a)aero.polimi.it wrote: > Daniel (Kurt), > > (Note to Kurt: as there is no affiliation between Daniel and me, we > did > not coordinate anything, so we'll probably better do it now and > start from > scratch, instead of polluting the ITS). This needs to be done in two steps. 1) Daniel needs to address notices issues in his submission. 2) You need to address the notices issues in your derived submission. Daniel should follow the instructions I provide, and then you should follow the instructions I provide. These steps are simple, straight forward, and have a clear result. > I suggest Daniel evaluates the line I'm proposing No. This in no way fulfills the Foundation requirements. The line you are asking Daniel to evaluate is not a formal notice. You actually failed to met his license, which requires you to include a copy of his copyright notice in your work. You copied only an informal acknowledgement, not his copyright notice and license statement. > and, based on the file I > submitted, formalizes a definitive patch with appropriate copyrights > and > submits it along the guidelines of the OpenLDAP foundation. Your submission doesn't met the guidelines of the Foundation as it also doesn't include a notice of origin nor asserts your copyright, and worse, it failed to met the copying requirement Daniel placed on his submission (that his notice be included in copies).

1 0

Re: (ITS#4730) Overlay that generates operational attributes to support GUI interaction
by michael＠stroeder.com 14 Aug '09

14 Aug '09

HI! I've added support for 'allowedAttributesEffective' in web2ldap recently which works with AD. I tried this overlay but it seg faults with recent OpenLDAP version. Any chance to get this back on the radar? Ciao, Michael.

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

Fixed in HEAD; please test. Thanks, p.

1 0

(ITS#6255) translucent remote data overrides local in filter
by masarati＠aero.polimi.it 13 Aug '09

13 Aug '09

Full_Name: Pierangelo Masarati Version: HEAD/re24 OS: Linux x86 URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (93.149.38.235) Submitted by: ando Consider data as set up by test034; the remote server contains an entry "uid=danger,ou=users,o=translucent" with "cn=danger", while the local database contains the same entry with "cn=henry". Searching for "cn=danger" will return the local entry, whose "cn" is "henry" and not "danger", and thus does not match the search filter. p.

1 0

(ITS#6254) translucent returns all attributes, no matter what's requested
by masarati＠aero.polimi.it 13 Aug '09

13 Aug '09

Full_Name: Pierangelo Masarati Version: HEAD/re24 OS: Linux x86 URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (93.149.38.235) Submitted by: ando I've just noticed that slapo-translucent on search returns the entire entry, regardless of what attrs are requested. Tested with re24 (candidate for 2.4.18) and HEAD. 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 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

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

openldap-bugs