openldap-bugs

openldap-bugs@openldap.org

1 participants
20960 discussions

(ITS#6247)
by daniel＠pluta.biz 01 May '10

01 May '10

Hi, just some changes and cleanups according the still ongoing discussion on ldapext. The patch can be downloaded here: ftp://ftp.openldap.org/incoming/daniel-pluta-100501.patch Changes: - removed extensible matching rules strictly associated with dedicated syntaxes - added two universal matching rules instead: - nowMach (equality matching rule) - nowOrdering (ordering matching rule) - these two rules also support extensible match filters To publish a correct server current time time-stamp value within Root-DSE: - apply the bugfix from ITS#6541 - and use -DCTM_G_DIFFERENTIAL_SERVERTIME To extend generalizedTime attribute types to also support "NOW" as assertion value: - use -DCTM_RFC4517_MR_AV_SYNTAX_VIOLATION Beware of patching conflicts in schema_init.c: This patch contains small redundant parts from my parallel contribution in ITS#6532 Regards, Daniel

1 0

(ITS#6541) liblutil/ultils.c: lutil_localtime() <g-differential> timestamp format bug
by daniel＠pluta.biz 01 May '10

01 May '10

Full_Name: Daniel Pluta Version: HEAD OS: - URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (2001:470:9feb:ff02:91d5:32:f2b:def0) Hi, for a description and a possible patch (to small for an upload ;-)) please see: http://www.openldap.org/lists/openldap-devel/201003/msg00012.html Cheers

1 0

Re: (ITS#6534) bad ifdef/elif clause in liblutil
by h.b.furuseth＠usit.uio.no 30 Apr '10

30 Apr '10

quanah(a)zimbra.com writes: > Actually, the issue seems to be name changes in the header files under BSD. > This causes TIOCNOTTY to end up being undefined. That would not give the error message shown in <http://www.mail-archive.com/debian-bugs-dist@lists.debian.org/msg776021.html>: build/buildd-openldap_2.4.21-1-kfreebsd-amd64-VWAqZY/openldap-2.4.21/libraries/liblutil/detach.c:131:7: error: missing binary operator before token "long" Line 131 is "#elif TIOCNOTTY". There's no 'long' there is TIOCNOTTY is undefined, it'd just evaluate to #elif 0. So my guess is that TIOCNOTTY somewhere is defined to expand to an expression involving a (long) cast. -- Hallvard

1 0

Re: (ITS#6456) Feature Request
by j＠gropefruit.com 30 Apr '10

30 Apr '10

It works exactly as I had hoped. Thank you for implementing this, I = believe it will be an asset to others besides myself. J > This is now implemented in back-ldap (idassert-passthru, = olcDbIDAssertPassThru, undocumented yet). > Basically, identities matching rules formally identical to those of = idassert-authz=46rom do not undergo identity assertion. =20 > This rule is checked before idassert-authzFrom, so in case an identity = matches both, passthru wins. Please test and report. > p.=20

1 0

Re: (ITS#6540) test022-ppolicy is flawed, masks serious stability issue
by quanah＠zimbra.com 29 Apr '10

29 Apr '10

--On Thursday, April 29, 2010 5:38 PM +0000 ryans(a)aweber.com wrote: > Great, many thanks for your efforts in confirming. Just out of > curiosity, when the fix is actually committed, will the commit number or > source code file be present in the ITS, so that one can easily > cross-reference the ITS with a particular file or set of files from CVS > HEAD? And again, please let me know if there's anything I can do to help > facilitate the process, or make it easier for you and/or the other > developers. I'm happy to test, patch the test scripts, et cetera. Unfortunately no, that type of commit -> bug integration does not currently exist, although I think it is a highly desirable feature and one that has been discussed for implementation. --Quanah -- Quanah Gibson-Mount Principal Software Engineer Zimbra, Inc -------------------- Zimbra :: the leader in open source messaging and collaboration

1 0

Re: (ITS#6540) test022-ppolicy is flawed, masks serious stability issue
by ryans＠aweber.com 29 Apr '10

29 Apr '10

> Date: Thu, 29 Apr 2010 17:30:42 +0200 (CEST) > Subject: Re: (ITS#6540) test022-ppolicy is flawed, > masks serious stability issue > From: masarati(a)aero.polimi.it > To: ryans(a)aweber.com > Cc: openldap-its(a)openldap.org > >> I already >> figured out myself how to reproduce the issue you're having, so you don't >> need to rebuild yet. You'll have to as soon as the issue is fixed. > > Try this patch: > > <ftp://ftp.openldap.org/incoming/pierangelo-masarati-2010-04-29-chain.1.patch> > > It removes the offending check. I don't quite remember the reason (it > dates 4.5 years ago). However, I've checked and all tests pass fine, > including the one you pointed out. To reproduce, I modified test022 to > write the configuration on disk (-F option to consumer slapd); at the end > of the test, I tried slapd on the resulting database. Fails with > 2.4.22/HEAD, succeeds with this patch. > > Please test and report. > > p. > Sure, will do that now and report back. Thanks. -Ryan

1 0

Re: (ITS#6540) test022-ppolicy is flawed, masks serious stability issue
by ryans＠aweber.com 29 Apr '10

29 Apr '10

> Date: Thu, 29 Apr 2010 15:41:48 +0200 (CEST) > Subject: Re: (ITS#6540) test022-ppolicy is flawed, > masks serious stability issue > From: masarati(a)aero.polimi.it > To: ryans(a)aweber.com > Cc: openldap-its(a)openldap.org > > Let me first explain one thing. If you have one problem and you don't > have time to rebuild from source, then it's very likely you'll have to > live with your problem. Yeah, I don't have a problem with rebuilding from source. Even with a patch, that would have to be done. I was just trying to, in the interest of urgency, avoid having to rebuild from 100% brand new source, instead of being able to patch the relevant code and tests and rebuild from that codebase. This would preclude having to worry about distinguishing new problems from the existing problem, or diagnosing and fixing additional and unrelated problems along the way, making it potentially easier isolate the issue. > The only difference between you and me is that if I find a solution, I > can commit the fix. For the rest, your time is valuable exactly as > mine, and I probably get paid less than you get paid, but to fix my > problems, not yours. Sure, but in this kind of scenario, aren't they one and the same? The burden of identifying and fixing bugs in the code is (in spirit, at least, unless there is a contract or legally binding agreement involved) shared by both developers and community users as we strive towards a common goal, although the nature of the responsibility varies to some degree. I agree, however, that in most circumstances the contributions made by community members and developers are of their own volition and centric to, if not completely predicated upon, their needs and interests. Because commits do necessitate developer involvement and thus ultimately depend on the allocation of their limited and valuable time, it is my belief that community users bear some responsibility in this process to help reduce the load on the developers, and should exercise due diligence when submitting ITS's and contributing to their solutions. Up to this point, I have tried to adhere to this self-subscribed policy as best as I can for this ITS, and am more than happy to contribute wherever possible, especially on things for which a seasoned OpenLDAP developer's experience and knowledge are a less important pre-requisite (like patching test022-ppolicy, or documentation, for example). So, please let me know if there's anything I can do to help facilitate this process. I know that nobody here is obligated, nor are their services free, so all time and effort expended is very valuable and highly appreciated - I can't stress any of those points enough! Also, completely OT but with respect to the 'salary' comment, if you're not getting paid at least as well or more than I am to teach aerospace engineering, it is a shame, but not all that surprising. Nobody in academia (at least in the United States) seems to get paid nearly what they're worth, regardless of the position (grade school teacher like my wife, or university professor such as yourself) or the degree of difficulty of the subject. We grumble about it every so often in our household - but I digress... > It just happened that tracking someone's issue, upgrading just solved > it (ITS#6537, which ended up being a duplicate of another, already > solved issue). In order to save the very scarce, unpaid manpower we > can dedicate to fixing others' issues, our policy is to avoid tracking > issues in old releases, because we don't backport fixes so, in the best > case, the issue will be solved in the next one, and you'll have to > upgrade anyway. Sure, and that's why I did my very best to review the source, and verify that the changelogs, diffs, and source relevant to the behavior had remained unchanged. But I submit that even with the most painstaking and diligent scrutiny of the code, it still holds true that "the proof is in the pudding", and few test are more ironclad than actually building the newest source and comparing the behavior. I did actually rebuild slapd this morning as requested, though, and still had the same issue (2.4.22), but when I went to update the ticket, I saw that you had already confirmed what I suspected prior to doing so. > After this lengthy preamble, thanks to your prompt response I already > figured out myself how to reproduce the issue you're having, so you don't > need to rebuild yet. You'll have to as soon as the issue is fixed. Great, many thanks for your efforts in confirming. Just out of curiosity, when the fix is actually committed, will the commit number or source code file be present in the ITS, so that one can easily cross-reference the ITS with a particular file or set of files from CVS HEAD? And again, please let me know if there's anything I can do to help facilitate the process, or make it easier for you and/or the other developers. I'm happy to test, patch the test scripts, et cetera. -Ryan > p. > >> It is also bears mentioning that test022-ppolicy has not changed at all >> since 2.4.18, and so would never detect this >> problem, even using the most recent stable version. As I mentioned, >> ldapsearch does not trigger any errors - only >> slapcat does (and of course, starting slapd, which fails as is detailed >> above). >> >> >> If you really want to test this, you must restart the server on which the >> chaining configuration from test022-ppolicy >> has been added, and then run slapcat. I am not the only one to run in to >> this; for example, this individual has the >> exact same issue, with no resolution: >> http://www.openldap.org/lists/openldap-software/200907/msg00118.html >> >> >> I'd be more than happy to patch the source, if such a patch existed. But >> since nothing seems to have changed in the >> relevant bits of code that would affect this behavior, and no >> corresponding ITS exists, that would lead me to believe it >> is thusly undocumented, except for similar on-list complaints. If you can >> show me where in the back-ldap code you >> believe I've missed said patch or refactoring, I've got no problem >> admitting I missed it, but I don't see any such >> modification(s). >> >> >> I'm sure not everybody has the time to build from completely new source >> every time a bug is unearthed, and while I do >> not object to doing that as soon as I can, right now I have a slapd server >> that is down because of this, so top priority >> is to evaluate the code to figure out where this bug is stemming from and >> fix it so I can restart slapd. Next priority >> is building and testing new packages. I mean no disrespect by this, but >> dropping everything to do this and work out any >> new issues, bugs, and compatibility problems and separate those from this >> pre-existing buggy behavior, seems hasty at >> best, especially when there's no concretely identified reason for doing so >> (i.e., this revision had change X, which >> fixes problem Y). >> >> >> I'm still reviewing the relevant code (which AFAICT hasn't changed) to >> figure out what's going on here and put out the >> immediate fire so that I can at least restore services, at which point I >> will obviously have to make the time to >> completely upgrade it all. >> >> Thanks >>

1 0

Re: (ITS#6534) bad ifdef/elif clause in liblutil
by quanah＠zimbra.com 29 Apr '10

29 Apr '10

--On Monday, April 26, 2010 3:10 PM +0000 quanah(a)OpenLDAP.org wrote: > Full_Name: Quanah Gibson-Mount > Version: 2.4.21 > OS: NA > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (75.111.45.108) > > > The following if/elif clause in liblutil is wrong: Actually, the issue seems to be name changes in the header files under BSD. This causes TIOCNOTTY to end up being undefined. Here's the header information: kibi@kbsd:~$ grep TIOCNOTTY /usr/include/ -r /usr/include/sys/ttycom.h:#define TIOCNOTTY _IO('t', 113) /* void tty association */ kibi@kbsd:~$ grep ttycom.h -r /usr/include/ /usr/include/sys/tty.h:#include <sys/ttycom.h> /usr/include/bits/ioctls.h:#include <sys/ttycom.h> So we either need <bits/ioctls.h> or <sys/ttycom.h> to be included on this particular platform. My guess is the latter would be most appropriate. --Quanah -- Quanah Gibson-Mount Principal Software Engineer Zimbra, Inc -------------------- Zimbra :: the leader in open source messaging and collaboration

1 0

Re: (ITS#6540) test022-ppolicy is flawed, masks serious stability issue
by masarati＠aero.polimi.it 29 Apr '10

29 Apr '10

> I already > figured out myself how to reproduce the issue you're having, so you don't > need to rebuild yet. You'll have to as soon as the issue is fixed. Try this patch: <ftp://ftp.openldap.org/incoming/pierangelo-masarati-2010-04-29-chain.1.patch> It removes the offending check. I don't quite remember the reason (it dates 4.5 years ago). However, I've checked and all tests pass fine, including the one you pointed out. To reproduce, I modified test022 to write the configuration on disk (-F option to consumer slapd); at the end of the test, I tried slapd on the resulting database. Fails with 2.4.22/HEAD, succeeds with this patch. Please test and report. p.

1 0

Re: (ITS#6540) test022-ppolicy is flawed, masks serious stability issue
by masarati＠aero.polimi.it 29 Apr '10

29 Apr '10

Let me first explain one thing. If you have one problem and you don't have time to rebuild from source, then it's very likely you'll have to live with your problem. The only difference between you and me is that if I find a solution, I can commit the fix. For the rest, your time is valuable exactly as mine, and I probably get paid less than you get paid, but to fix my problems, not yours. It just happened that tracking someone's issue, upgrading just solved it (ITS#6537, which ended up being a duplicate of another, already solved issue). In order to save the very scarce, unpaid manpower we can dedicate to fixing others' issues, our policy is to avoid tracking issues in old releases, because we don't backport fixes so, in the best case, the issue will be solved in the next one, and you'll have to upgrade anyway. After this lengthy preamble, thanks to your prompt response I already figured out myself how to reproduce the issue you're having, so you don't need to rebuild yet. You'll have to as soon as the issue is fixed. p. > It is also bears mentioning that test022-ppolicy has not changed at all > since 2.4.18, and so would never detect this > problem, even using the most recent stable version. As I mentioned, > ldapsearch does not trigger any errors - only > slapcat does (and of course, starting slapd, which fails as is detailed > above). > > > If you really want to test this, you must restart the server on which the > chaining configuration from test022-ppolicy > has been added, and then run slapcat. I am not the only one to run in to > this; for example, this individual has the > exact same issue, with no resolution: > http://www.openldap.org/lists/openldap-software/200907/msg00118.html > > > I'd be more than happy to patch the source, if such a patch existed. But > since nothing seems to have changed in the > relevant bits of code that would affect this behavior, and no > corresponding ITS exists, that would lead me to believe it > is thusly undocumented, except for similar on-list complaints. If you can > show me where in the back-ldap code you > believe I've missed said patch or refactoring, I've got no problem > admitting I missed it, but I don't see any such > modification(s). > > > I'm sure not everybody has the time to build from completely new source > every time a bug is unearthed, and while I do > not object to doing that as soon as I can, right now I have a slapd server > that is down because of this, so top priority > is to evaluate the code to figure out where this bug is stemming from and > fix it so I can restart slapd. Next priority > is building and testing new packages. I mean no disrespect by this, but > dropping everything to do this and work out any > new issues, bugs, and compatibility problems and separate those from this > pre-existing buggy behavior, seems hasty at > best, especially when there's no concretely identified reason for doing so > (i.e., this revision had change X, which > fixes problem Y). > > > I'm still reviewing the relevant code (which AFAICT hasn't changed) to > figure out what's going on here and put out the > immediate fire so that I can at least restore services, at which point I > will obviously have to make the time to > completely upgrade it all. > > Thanks > > > >

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