- openldap-bugs - openldap.org

Re: (ITS#6247)
by daniel＠pluta.biz 02 May '10

02 May '10

Kurt Zeilenga schrieb: > On May 1, 2010, at 12:31 PM, daniel(a)pluta.biz wrote: > >> 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 > > Your comments imply these rules could be used as attribute type > equality and ordering rules. In general my intention is neither to violate X.501 nor changing the ASN.1 Generalized Time syntax. Instead the introduction of a compatible/similar/derived attribute value syntax (e.g. generalizedTime') which supports matching against client-side known time-stamps *and* server-relative time-stamps (like NOW or NOW-1Y3M... or X.680 period formats) seems to be fine for me. In the following generalizedTime' is such a kind of a (very) similar syntax to the well-defined generalizedTime. Regarding the EQ/ORD matching rule applicability: The attribute type is generalizedTime' and the assertion value is for example NOW which server-internally implicitly also represents a (at least some kind of possibly not ITU specified?) generalizedTime' conform assertion value: NOW is the at client side unknown current time of the server in generalizedTime'. What's your suggestion regarding a possible solution on how to support EQ and ORD matching of attribute values compared to the server side current time? > I don't believe the met the > requirements (see X.501) to be used in that manner. That is, they > only make sense as extensible matching rules. I really would like to try to understand your concerns. Could you please give me some links to chapters/sections in X.501 where I can find more details. Note: I've currently only access to the standard of the year 2006. The class is generalizedTime' and during EQ/ORD matching two instances of generalizedTime' are compared: 1. Attribute value of an entry (generalizedTime') 2. Assertion value aka expanded-NOW (generalizedTime') >> 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 > > #ifdef's should, IMO, be generally avoided. it will be removed as soon as the above mentioned bug is fixed in HEAD >> To extend generalizedTime attribute types to also support "NOW" as >> assertion value: >> - use -DCTM_RFC4517_MR_AV_SYNTAX_VIOLATION > > The generalized time syntax is not ours to alter. Introduction of > such a change would, it seem, lead to interoperability problems. In my opinion the chosen name for the #ifdef is more than obvious. Additionally the related comment in the patch's source already say's that this "extension" is more a violation than an extension. That's why the #ifdef currently is and probably stays in action (or will be removed) in the future. As a side-effect this #ifdef could possibly invoke some disussions... ;-) It's probably worth to discuss this (violation) in more detail to provide a solution in regard to a broader applicability of this matching feature in LDAP. Broader/easier usage/readbility is also the background I've decided to skip the extensible matching rules and introduce EQ and ORD instead. E.g. Clients that are connecting to a server that announces the supportedFeature "current time matching" could make notice of that and also support "NOW" as assertion value for createTimestamp and so on... (I've not very well thought about that in detail, yet). You are right, it's just a work in progress and you are very welcome to join the discussion on ldapext.

1 0

Re: (ITS#6542) Segmentation Fault if config file (ldif) got changed
by hyc＠symas.com 01 May '10

01 May '10

felix.schuster(a)gmx.at wrote: > Full_Name: Felix > Version: 2.4.19 > OS: Linux/Gentoo > URL: > Submission from: (NULL) (78.142.131.97) > > > Using the new configuration scheme, I changed > /etc/openldap/slapd.d/cn=config/olcDatabase={1}hdb.ldif of a running openldap > instance. When I tried to restart openldap it gaves me a Segmentation Fault > error. Even if I called the changes off, openldap refused to start (furthermore > segfaulted). I needed to get a copy of the original configuration file from my > backup to successfully start openldap again. > I think it's somewhere ok to deny working with a hand-changed configuration, but > I think we will need a friendly advise, no unfriendly Segementation Fault error. > cn=config is an LDAP database. Like any other LDAP database, you are only supposed to use ldapadd/modify/delete to write to it while slapd is running. You would probably get segfaults if you hand-edited the data files in a back-bdb database too. And no, we will not add code to protect from such misuse. -- -- 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#6542) Segmentation Fault if config file (ldif) got changed
by felix.schuster＠gmx.at 01 May '10

01 May '10

Full_Name: Felix Version: 2.4.19 OS: Linux/Gentoo URL: Submission from: (NULL) (78.142.131.97) Using the new configuration scheme, I changed /etc/openldap/slapd.d/cn=config/olcDatabase={1}hdb.ldif of a running openldap instance. When I tried to restart openldap it gaves me a Segmentation Fault error. Even if I called the changes off, openldap refused to start (furthermore segfaulted). I needed to get a copy of the original configuration file from my backup to successfully start openldap again. I think it's somewhere ok to deny working with a hand-changed configuration, but I think we will need a friendly advise, no unfriendly Segementation Fault error.

1 0

Re: (ITS#6247)
by Kurt＠OpenLDAP.org 01 May '10

01 May '10

On May 1, 2010, at 12:31 PM, daniel(a)pluta.biz wrote: > Hi, >=20 > just some changes and cleanups according the still ongoing discussion = on=20 > ldapext. I recommend consideration of this patch be deferred until the = specification is less of a work-in-a-progress. >=20 > The patch can be downloaded here:=20 > ftp://ftp.openldap.org/incoming/daniel-pluta-100501.patch >=20 > Changes: > - removed extensible matching rules strictly associated with=20 > dedicated syntaxes > - added two universal matching rules instead: > - nowMach (equality matching rule) > - nowOrdering (ordering matching rule) > - these two rules also support extensible match filters Your comments imply these rules could be used as attribute type equality = and ordering rules. I don't believe the met the requirements (see = X.501) to be used in that manner. That is, they only make sense as = extensible matching rules. >=20 > 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 #ifdef's should, IMO, be generally avoided. >=20 >=20 > To extend generalizedTime attribute types to also support "NOW" as=20 > assertion value: > - use -DCTM_RFC4517_MR_AV_SYNTAX_VIOLATION The generalized time syntax is not ours to alter. Introduction of such = a change would, it seem, lead to interoperability problems. >=20 >=20 > Beware of patching conflicts in schema_init.c: > This patch contains small redundant parts from my parallel = contribution=20 > in ITS#6532 >=20 > Regards, > Daniel >=20 >=20

1 0

(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 29 Apr '10

29 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

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

28 Apr '10

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#6540) test022-ppolicy is flawed, masks serious stability issue
by ryans＠aweber.com 28 Apr '10

28 Apr '10

> Date: Wed, 28 Apr 2010 21:20:38 +0200 (CEST) > Subject: ITS#6540 > From: masarati(a)aero.polimi.it > To: ryans(a)aweber.com > Cc: openldap-its(a)openldap.org > > Please do not report issues related to old releases. Current is 2.4.22. > Please test and report whether the issue persists. > > p. I checked my version of back-ldap/chain.c and back-ldap/config.c, and there have been no changes that in any way apply to or address the serious problem I've encountered. For reference, my chain.c is version 1.52.2.10, and config.c is version 1.115.2.14

1 0

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

28 Apr '10

The other thing I should note is initially, everything seemed to work, but became prevalent the very first time I restarted slapd after adding the chaining configurations from test022-ppolicy. That's when all the errors started with slapcat. The second time I restarted it (to try and fix the issue), slapd would not start at all, as described above.

1 0

ITS#6540
by masarati＠aero.polimi.it 28 Apr '10

28 Apr '10

Please do not report issues related to old releases. Current is 2.4.22. Please test and report whether the issue persists. p.

1 0

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

28 Apr '10

I should also note that a slapcat of the config database fails too in the exact same manner. I'm guessing this is somehow related to the fact that the chain module/overlay is located within the back_ldap module, but I'm not sure how to work around the issue yet, so at this time slapd will not start on the slave server on which slapd was stopped after adding the chaining configuration as is documented in test022-ppolicy.

1 0

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

28 Apr '10

Full_Name: Ryan Steele Version: 2.4.18 OS: Ubuntu Server URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (207.106.239.81) When the chaining configuration for cn=config is added, as is done in test022-ppolicy, the process of adding the module and overlay succeed, but subsequent slapcat operations will fail with: root@nebula:~# slapcat -n1 slapd-chain: first underlying database "olcDatabase={0}ldap,olcOverlay={0}chain,olcDatabase={-1}frontend,cn=config" cannot contain attribute "olcDbURI". config error processing olcDatabase={0}ldap,olcOverlay={0}chain,olcDatabase={-1}frontend,cn=config: slapcat: bad configuration file! Additionally, if slapd is stopped after adding the configuration in test022-ppolicy, the server will not start again, and on the foreground shows: slapd-chain: first underlying database "olcDatabase={0}ldap,olcOverlay={0}chain,olcDatabase={-1}frontend,cn=config" cannot contain attribute "olcDbURI". : config_add_internal: DN="olcDatabase={0}ldap,olcOverlay={0}chain,olcDatabase={-1}frontend,cn=config" no structural objectClass add function config error processing olcDatabase={0}ldap,olcOverlay={0}chain,olcDatabase={-1}frontend,cn=config: send_ldap_result: conn=-1 op=0 p=0 send_ldap_result: err=65 matched="" text="" slapd destroy: freeing system resources. slapd stopped. connections_destroy: nothing to destroy. The reason test022-ppolicy does not catch this is because an ldapsearch will still work. In fact, the chaining operations still succeed (writes are ferried off to the upstream server). But, this is a very grave problem, as it can cause the slapd server to stop functioning completely.

1 0

RE: (ITS#6537) arl[authority revocation list] issue during opneldap upgrade
by masarati＠aero.polimi.it 28 Apr '10

28 Apr '10

> Hi, > > I upgraded the version to openldap 2.4.22 and now I could add the ldif > file with the arl in with slapcat command > > Previously the same was not working, so I guess the bug in 2.4.21 is fixed > in 2.4.22 version > > You may treat the call as closed and thanks for your prompt response Probably a dup of ITS#6466. Closed, thanks. p.

1 0

RE: (ITS#6537) arl[authority revocation list] issue during opneldap upgrade
by mmishra＠isabel.eu 28 Apr '10

28 Apr '10

Hi, I upgraded the version to openldap 2.4.22 and now I could add the ldif file= with the arl in with slapcat command Previously the same was not working, so I guess the bug in 2.4.21 is fixed = in 2.4.22 version You may treat the call as closed and thanks for your prompt response Regards Mayashankar Mishra -----Original Message----- From: masarati(a)aero.polimi.it [mailto:masarati@aero.polimi.it] Sent: 2010-04-27 18:13 To: Mayashankar Mishra Cc: openldap-its(a)openldap.org Subject: RE: (ITS#6537) arl[authority revocation list] issue during opnelda= p upgrade One of us is clearly doing something wrong. Can you please check if the is= sue also appears with 2.4.22? I can't rebuild 2.4.21 right now, and since = 2.4.22 works for me, it would be pointless to track any issue that was fixe= d since 2.4.21. p. > See the error when I try to add > > > [root@ldap ~]# ldapadd -x -H ldap://:389 -D <Manager DN > -W -f > aaa.ldif Enter LDAP Password: > adding new entry "cn=3Dca,l=3Disabel,l=3Dbe" > ldap_add: Invalid syntax (21) > additional info: authorityRevocationList;binary: value #0 > invalid per syntax > > [root@ldap ~]# cat aaa.ldif > dn: cn=3Dca,l=3Disabel,l=3Dbe > changetype: add > objectClass: cRLDistributionPoint > authorityRevocationList;binary:: MIIBwTCBqgIBATANBgkqhkiG9w0BAQUFADBUM > QswCQYDVQQGEwJCZTEPMA0GA1UEBxMGSXNhYmVsMQswCQYDVQQKEwJDYTEnMCUGA1UEAx > MeSXNhYmVsIENlcnRpZmljYXRpb24gQXV0aG9yaXR5Fw0wNTEyMDIwNDAwNTRaFw0wNTE > yMDMwNDAwMDBaMACgIDAeMA8GA1UdIwQIMAaABENBMDIwCwYDVR0UBAQCAgzSMA0GCSqG > SIb3DQEBBQUAA4IBAQALWRmn79TNllOD+oOqv7r64NSFdBGo/8fCQAykbjcNMJHRjTOSq > fU0amv2hS509I68/VhwfwHw9NzNsnPEevWkb1oFWSLvZ6FuWXTNOV5n9aY/bMqJX5gPtw > lNWez/ATv99M5WbUUKPjDxpc90bd2xjMoKBhlsrykMg0DXaRkiYYREl3lXF0wr4F/FsfO > 7QS+fzkifmI09Z7zCIc2043xl2RpXvRostzrq8ncQdjBh5UdHj3qW0HQfkCaNxiIy3eZY > 4JKyCqW97nTyh9v5As1X2mvujbTtKW5i5lnXeHDtjOdufva86TbZvSyQyikxLRlpQle+Y > i5x6NWdDN7Sz9LO > > > > > > > > > Mayashankar Mishra > Consultant > E-mail : mmishra(a)isabel.eu > Tel : +32 (0)2 403.18.84 > Fax : +32 > > Isabel NV/S.A. > Keizerinlaan 13-15 Boulevard de l'Imp=E9ratrice 1000 Brussels - Belgium > RPR Bruxelles / RPM Brussel: BE 0455 530 509 > http://www.isabel.eu/ http://www.zoomit.eu/ > > Zoomit is a Registered Trademark of Isabel NV/S.A. > Disclaimer : http://www.isabel.eu/gps/en/disclaimer/mailing.php > > -----Original Message----- > From: masarati(a)aero.polimi.it [mailto:masarati@aero.polimi.it] > Sent: 2010-04-27 17:41 > To: Mayashankar Mishra > Cc: openldap-its(a)openldap.org > Subject: RE: (ITS#6537) arl[authority revocation list] issue during > opneldap upgrade > >> uploaded the arl on ftp server > > I could load it without any problem. LDIF: > > dn: cn=3Dtest,dc=3Dexample,dc=3Dcom > changetype: add > objectClass: cRLDistributionPoint > authorityRevocationList;binary:: MIIBwTCBqgIBATANBgkqhkiG9w0BAQUFADBUM > QswCQYDVQQGEwJCZTEPMA0GA1UEBxMGSXNhYmVsMQswCQYDVQQKEwJDYTEnMCUGA1UEAx > MeSXNhYmVsIENlcnRpZmljYXRpb24gQXV0aG9yaXR5Fw0wNTEyMDIwNDAwNTRaFw0wNTE > yMDMwNDAwMDBaMACgIDAeMA8GA1UdIwQIMAaABENBMDIwCwYDVR0UBAQCAgzSMA0GCSqG > SIb3DQEBBQUAA4IBAQALWRmn79TNllOD+oOqv7r64NSFdBGo/8fCQAykbjcNMJHRjTOSq > fU0amv2hS509I68/VhwfwHw9NzNsnPEevWkb1oFWSLvZ6FuWXTNOV5n9aY/bMqJX5gPtw > lNWez/ATv99M5WbUUKPjDxpc90bd2xjMoKBhlsrykMg0DXaRkiYYREl3lXF0wr4F/FsfO > 7QS+fzkifmI09Z7zCIc2043xl2RpXvRostzrq8ncQdjBh5UdHj3qW0HQfkCaNxiIy3eZY > 4JKyCqW97nTyh9v5As1X2mvujbTtKW5i5lnXeHDtjOdufva86TbZvSyQyikxLRlpQle+Y > i5x6NWdDN7Sz9LO > > command: > > ldapadd -x -H ldap://:9011 -D <manager DN> -w <password> -f <LDIF > file> > > using HEAD and re24 (basically, 2.4.22). > > I think this ITS should definitely be closed, and you should > eventually discuss your issue on the openldap-software mailing list, > as there appears to be no software bug. > > p. > > > > > > >

1 0

RE: (ITS#6537) arl[authority revocation list] issue during opneldap upgrade
by masarati＠aero.polimi.it 27 Apr '10

27 Apr '10

One of us is clearly doing something wrong. Can you please check if the issue also appears with 2.4.22? I can't rebuild 2.4.21 right now, and since 2.4.22 works for me, it would be pointless to track any issue that was fixed since 2.4.21. p. > See the error when I try to add > > > [root@ldap ~]# ldapadd -x -H ldap://:389 -D <Manager DN > -W -f aaa.ldif > Enter LDAP Password: > adding new entry "cn=ca,l=isabel,l=be" > ldap_add: Invalid syntax (21) > additional info: authorityRevocationList;binary: value #0 invalid > per syntax > > [root@ldap ~]# cat aaa.ldif > dn: cn=ca,l=isabel,l=be > changetype: add > objectClass: cRLDistributionPoint > authorityRevocationList;binary:: MIIBwTCBqgIBATANBgkqhkiG9w0BAQUFADBUM > QswCQYDVQQGEwJCZTEPMA0GA1UEBxMGSXNhYmVsMQswCQYDVQQKEwJDYTEnMCUGA1UEAx > MeSXNhYmVsIENlcnRpZmljYXRpb24gQXV0aG9yaXR5Fw0wNTEyMDIwNDAwNTRaFw0wNTE > yMDMwNDAwMDBaMACgIDAeMA8GA1UdIwQIMAaABENBMDIwCwYDVR0UBAQCAgzSMA0GCSqG > SIb3DQEBBQUAA4IBAQALWRmn79TNllOD+oOqv7r64NSFdBGo/8fCQAykbjcNMJHRjTOSq > fU0amv2hS509I68/VhwfwHw9NzNsnPEevWkb1oFWSLvZ6FuWXTNOV5n9aY/bMqJX5gPtw > lNWez/ATv99M5WbUUKPjDxpc90bd2xjMoKBhlsrykMg0DXaRkiYYREl3lXF0wr4F/FsfO > 7QS+fzkifmI09Z7zCIc2043xl2RpXvRostzrq8ncQdjBh5UdHj3qW0HQfkCaNxiIy3eZY > 4JKyCqW97nTyh9v5As1X2mvujbTtKW5i5lnXeHDtjOdufva86TbZvSyQyikxLRlpQle+Y > i5x6NWdDN7Sz9LO > > > > > > > > > Mayashankar Mishra > Consultant > E-mail : mmishra(a)isabel.eu > Tel : +32 (0)2 403.18.84 > Fax : +32 > > Isabel NV/S.A. > Keizerinlaan 13-15 Boulevard de l'Impératrice > 1000 Brussels - Belgium > RPR Bruxelles / RPM Brussel: BE 0455 530 509 > http://www.isabel.eu/ http://www.zoomit.eu/ > > Zoomit is a Registered Trademark of Isabel NV/S.A. > Disclaimer : http://www.isabel.eu/gps/en/disclaimer/mailing.php > > -----Original Message----- > From: masarati(a)aero.polimi.it [mailto:masarati@aero.polimi.it] > Sent: 2010-04-27 17:41 > To: Mayashankar Mishra > Cc: openldap-its(a)openldap.org > Subject: RE: (ITS#6537) arl[authority revocation list] issue during > opneldap upgrade > >> uploaded the arl on ftp server > > I could load it without any problem. LDIF: > > dn: cn=test,dc=example,dc=com > changetype: add > objectClass: cRLDistributionPoint > authorityRevocationList;binary:: MIIBwTCBqgIBATANBgkqhkiG9w0BAQUFADBUM > QswCQYDVQQGEwJCZTEPMA0GA1UEBxMGSXNhYmVsMQswCQYDVQQKEwJDYTEnMCUGA1UEAx > MeSXNhYmVsIENlcnRpZmljYXRpb24gQXV0aG9yaXR5Fw0wNTEyMDIwNDAwNTRaFw0wNTE > yMDMwNDAwMDBaMACgIDAeMA8GA1UdIwQIMAaABENBMDIwCwYDVR0UBAQCAgzSMA0GCSqG > SIb3DQEBBQUAA4IBAQALWRmn79TNllOD+oOqv7r64NSFdBGo/8fCQAykbjcNMJHRjTOSq > fU0amv2hS509I68/VhwfwHw9NzNsnPEevWkb1oFWSLvZ6FuWXTNOV5n9aY/bMqJX5gPtw > lNWez/ATv99M5WbUUKPjDxpc90bd2xjMoKBhlsrykMg0DXaRkiYYREl3lXF0wr4F/FsfO > 7QS+fzkifmI09Z7zCIc2043xl2RpXvRostzrq8ncQdjBh5UdHj3qW0HQfkCaNxiIy3eZY > 4JKyCqW97nTyh9v5As1X2mvujbTtKW5i5lnXeHDtjOdufva86TbZvSyQyikxLRlpQle+Y > i5x6NWdDN7Sz9LO > > command: > > ldapadd -x -H ldap://:9011 -D <manager DN> -w <password> -f <LDIF file> > > using HEAD and re24 (basically, 2.4.22). > > I think this ITS should definitely be closed, and you should eventually > discuss your issue on the openldap-software mailing list, as there appears > to be no software bug. > > p. > > > > > > >

1 0

RE: (ITS#6537) arl[authority revocation list] issue during opneldap upgrade
by mmishra＠isabel.eu 27 Apr '10

27 Apr '10

See the error when I try to add [root@ldap ~]# ldapadd -x -H ldap://:389 -D <Manager DN > -W -f aaa.ldif Enter LDAP Password: adding new entry "cn=3Dca,l=3Disabel,l=3Dbe" ldap_add: Invalid syntax (21) additional info: authorityRevocationList;binary: value #0 invalid p= er syntax [root@ldap ~]# cat aaa.ldif dn: cn=3Dca,l=3Disabel,l=3Dbe changetype: add objectClass: cRLDistributionPoint authorityRevocationList;binary:: MIIBwTCBqgIBATANBgkqhkiG9w0BAQUFADBUM QswCQYDVQQGEwJCZTEPMA0GA1UEBxMGSXNhYmVsMQswCQYDVQQKEwJDYTEnMCUGA1UEAx MeSXNhYmVsIENlcnRpZmljYXRpb24gQXV0aG9yaXR5Fw0wNTEyMDIwNDAwNTRaFw0wNTE yMDMwNDAwMDBaMACgIDAeMA8GA1UdIwQIMAaABENBMDIwCwYDVR0UBAQCAgzSMA0GCSqG SIb3DQEBBQUAA4IBAQALWRmn79TNllOD+oOqv7r64NSFdBGo/8fCQAykbjcNMJHRjTOSq fU0amv2hS509I68/VhwfwHw9NzNsnPEevWkb1oFWSLvZ6FuWXTNOV5n9aY/bMqJX5gPtw lNWez/ATv99M5WbUUKPjDxpc90bd2xjMoKBhlsrykMg0DXaRkiYYREl3lXF0wr4F/FsfO 7QS+fzkifmI09Z7zCIc2043xl2RpXvRostzrq8ncQdjBh5UdHj3qW0HQfkCaNxiIy3eZY 4JKyCqW97nTyh9v5As1X2mvujbTtKW5i5lnXeHDtjOdufva86TbZvSyQyikxLRlpQle+Y i5x6NWdDN7Sz9LO Mayashankar Mishra Consultant E-mail : mmishra(a)isabel.eu Tel : +32 (0)2 403.18.84 Fax : +32 Isabel NV/S.A. Keizerinlaan 13-15 Boulevard de l'Imp=E9ratrice 1000 Brussels - Belgium RPR Bruxelles / RPM Brussel: BE 0455 530 509 http://www.isabel.eu/ http://www.zoomit.eu/ Zoomit is a Registered Trademark of Isabel NV/S.A. Disclaimer : http://www.isabel.eu/gps/en/disclaimer/mailing.php -----Original Message----- From: masarati(a)aero.polimi.it [mailto:masarati@aero.polimi.it] Sent: 2010-04-27 17:41 To: Mayashankar Mishra Cc: openldap-its(a)openldap.org Subject: RE: (ITS#6537) arl[authority revocation list] issue during opnelda= p upgrade > uploaded the arl on ftp server I could load it without any problem. LDIF: dn: cn=3Dtest,dc=3Dexample,dc=3Dcom changetype: add objectClass: cRLDistributionPoint authorityRevocationList;binary:: MIIBwTCBqgIBATANBgkqhkiG9w0BAQUFADBUM QswCQYDVQQGEwJCZTEPMA0GA1UEBxMGSXNhYmVsMQswCQYDVQQKEwJDYTEnMCUGA1UEAx MeSXNhYmVsIENlcnRpZmljYXRpb24gQXV0aG9yaXR5Fw0wNTEyMDIwNDAwNTRaFw0wNTE yMDMwNDAwMDBaMACgIDAeMA8GA1UdIwQIMAaABENBMDIwCwYDVR0UBAQCAgzSMA0GCSqG SIb3DQEBBQUAA4IBAQALWRmn79TNllOD+oOqv7r64NSFdBGo/8fCQAykbjcNMJHRjTOSq fU0amv2hS509I68/VhwfwHw9NzNsnPEevWkb1oFWSLvZ6FuWXTNOV5n9aY/bMqJX5gPtw lNWez/ATv99M5WbUUKPjDxpc90bd2xjMoKBhlsrykMg0DXaRkiYYREl3lXF0wr4F/FsfO 7QS+fzkifmI09Z7zCIc2043xl2RpXvRostzrq8ncQdjBh5UdHj3qW0HQfkCaNxiIy3eZY 4JKyCqW97nTyh9v5As1X2mvujbTtKW5i5lnXeHDtjOdufva86TbZvSyQyikxLRlpQle+Y i5x6NWdDN7Sz9LO command: ldapadd -x -H ldap://:9011 -D <manager DN> -w <password> -f <LDIF file> using HEAD and re24 (basically, 2.4.22). I think this ITS should definitely be closed, and you should eventually dis= cuss your issue on the openldap-software mailing list, as there appears to = be no software bug. p.

1 0

RE: (ITS#6537) arl[authority revocation list] issue during opneldap upgrade
by masarati＠aero.polimi.it 27 Apr '10

27 Apr '10

> uploaded the arl on ftp server I could load it without any problem. LDIF: dn: cn=test,dc=example,dc=com changetype: add objectClass: cRLDistributionPoint authorityRevocationList;binary:: MIIBwTCBqgIBATANBgkqhkiG9w0BAQUFADBUM QswCQYDVQQGEwJCZTEPMA0GA1UEBxMGSXNhYmVsMQswCQYDVQQKEwJDYTEnMCUGA1UEAx MeSXNhYmVsIENlcnRpZmljYXRpb24gQXV0aG9yaXR5Fw0wNTEyMDIwNDAwNTRaFw0wNTE yMDMwNDAwMDBaMACgIDAeMA8GA1UdIwQIMAaABENBMDIwCwYDVR0UBAQCAgzSMA0GCSqG SIb3DQEBBQUAA4IBAQALWRmn79TNllOD+oOqv7r64NSFdBGo/8fCQAykbjcNMJHRjTOSq fU0amv2hS509I68/VhwfwHw9NzNsnPEevWkb1oFWSLvZ6FuWXTNOV5n9aY/bMqJX5gPtw lNWez/ATv99M5WbUUKPjDxpc90bd2xjMoKBhlsrykMg0DXaRkiYYREl3lXF0wr4F/FsfO 7QS+fzkifmI09Z7zCIc2043xl2RpXvRostzrq8ncQdjBh5UdHj3qW0HQfkCaNxiIy3eZY 4JKyCqW97nTyh9v5As1X2mvujbTtKW5i5lnXeHDtjOdufva86TbZvSyQyikxLRlpQle+Y i5x6NWdDN7Sz9LO command: ldapadd -x -H ldap://:9011 -D <manager DN> -w <password> -f <LDIF file> using HEAD and re24 (basically, 2.4.22). I think this ITS should definitely be closed, and you should eventually discuss your issue on the openldap-software mailing list, as there appears to be no software bug. p.

1 0

RE: (ITS#6537) arl[authority revocation list] issue during opneldap upgrade
by mmishra＠isabel.eu 27 Apr '10

27 Apr '10

uploaded the arl on ftp server Mayashankar Mishra Consultant E-mail : mmishra(a)isabel.eu Tel : +32 (0)2 403.18.84 Fax : +32 Isabel NV/S.A. Keizerinlaan 13-15 Boulevard de l'Imp=E9ratrice 1000 Brussels - Belgium RPR Bruxelles / RPM Brussel: BE 0455 530 509 http://www.isabel.eu/ http://www.zoomit.eu/ Zoomit is a Registered Trademark of Isabel NV/S.A. Disclaimer : http://www.isabel.eu/gps/en/disclaimer/mailing.php -----Original Message----- From: Mayashankar Mishra Sent: 2010-04-27 17:28 To: openldap-its(a)openldap.org Cc: 'masarati(a)aero.polimi.it' Subject: RE: (ITS#6537) arl[authority revocation list] issue during opnelda= p upgrade -----Original Message----- From: masarati(a)aero.polimi.it [mailto:masarati@aero.polimi.it] Sent: 2010-04-27 17:19 To: Mayashankar Mishra Cc: openldap-its(a)openldap.org Subject: RE: (ITS#6537) arl[authority revocation list] issue during opnelda= p upgrade Please reply to openldap-its; the "T" stands for "Tracking", if you don't p= ost there, tracking becomes impossible. > > > Hi, > > But same arl work in openldap 2.2.26 In 2.2.26 certificate list was something like int certificateListValidate() { return LDAP_SUCCESS; } I would be surprised it failed. > I could treat with openssl command to > convert to variuos format That's another point. If openssl tools can operate on that CL, then it mig= ht not strictly comply with X509 but be somehow tolerated. We need to insp= ect the certificate in order to find out why it fails. Unless its disclosure violates any confidentiality you're bound to, please = upload it to ftp.openldap.org *in binary form* following these instructions= <http://www.openldap.org/devel/contributing.html#submitting>, then post a message to the ITS with the URL of the file you uploaded. If you're not allowed to upload the offending CL, you'll have to inspect it= yourself. Run slapd under gdb; find out where the failure occurs (running= with "-d stats,trace,args" should suffice); place a breakpoint at the offe= nding call (should be either certificateListValidate() or certificateListEx= actNormalize()), step through the function and see where it fails. We migh= t need to request you to print specific values of variables inside those fu= nctions. > But then whats wrong I maens what it means binary value # 0 This sentence is definitely obscure to me. Please clarify. p.

1 0

RE: (ITS#6537) arl[authority revocation list] issue during opneldap upgrade
by mmishra＠isabel.eu 27 Apr '10

27 Apr '10

Mayashankar Mishra Consultant E-mail : mmishra(a)isabel.eu Tel : +32 (0)2 403.18.84 Fax : +32 Isabel NV/S.A. Keizerinlaan 13-15 Boulevard de l'Imp=E9ratrice 1000 Brussels - Belgium RPR Bruxelles / RPM Brussel: BE 0455 530 509 http://www.isabel.eu/ http://www.zoomit.eu/ Zoomit is a Registered Trademark of Isabel NV/S.A. Disclaimer : http://www.isabel.eu/gps/en/disclaimer/mailing.php -----Original Message----- From: masarati(a)aero.polimi.it [mailto:masarati@aero.polimi.it] Sent: 2010-04-27 17:19 To: Mayashankar Mishra Cc: openldap-its(a)openldap.org Subject: RE: (ITS#6537) arl[authority revocation list] issue during opnelda= p upgrade Please reply to openldap-its; the "T" stands for "Tracking", if you don't p= ost there, tracking becomes impossible. > > > Hi, > > But same arl work in openldap 2.2.26 In 2.2.26 certificate list was something like int certificateListValidate() { return LDAP_SUCCESS; } I would be surprised it failed. > I could treat with openssl command to > convert to variuos format That's another point. If openssl tools can operate on that CL, then it mig= ht not strictly comply with X509 but be somehow tolerated. We need to insp= ect the certificate in order to find out why it fails. Unless its disclosure violates any confidentiality you're bound to, please = upload it to ftp.openldap.org *in binary form* following these instructions= <http://www.openldap.org/devel/contributing.html#submitting>, then post a message to the ITS with the URL of the file you uploaded. If you're not allowed to upload the offending CL, you'll have to inspect it= yourself. Run slapd under gdb; find out where the failure occurs (running= with "-d stats,trace,args" should suffice); place a breakpoint at the offe= nding call (should be either certificateListValidate() or certificateListEx= actNormalize()), step through the function and see where it fails. We migh= t need to request you to print specific values of variables inside those fu= nctions. > But then whats wrong I maens what it means binary value # 0 This sentence is definitely obscure to me. Please clarify. p.

1 0

RE: (ITS#6537) arl[authority revocation list] issue during opneldap upgrade
by masarati＠aero.polimi.it 27 Apr '10

27 Apr '10

Please reply to openldap-its; the "T" stands for "Tracking", if you don't post there, tracking becomes impossible. > > > Hi, > > But same arl work in openldap 2.2.26 In 2.2.26 certificate list was something like int certificateListValidate() { return LDAP_SUCCESS; } I would be surprised it failed. > I could treat with openssl command to > convert to variuos format That's another point. If openssl tools can operate on that CL, then it might not strictly comply with X509 but be somehow tolerated. We need to inspect the certificate in order to find out why it fails. Unless its disclosure violates any confidentiality you're bound to, please upload it to ftp.openldap.org *in binary form* following these instructions <http://www.openldap.org/devel/contributing.html#submitting>, then post a message to the ITS with the URL of the file you uploaded. If you're not allowed to upload the offending CL, you'll have to inspect it yourself. Run slapd under gdb; find out where the failure occurs (running with "-d stats,trace,args" should suffice); place a breakpoint at the offending call (should be either certificateListValidate() or certificateListExactNormalize()), step through the function and see where it fails. We might need to request you to print specific values of variables inside those functions. > But then whats wrong I maens what it means binary value # 0 This sentence is definitely obscure to me. Please clarify. p.

1 0

RE: (ITS#6537) arl[authority revocation list] issue during opneldap upgrade
by mmishra＠isabel.eu 27 Apr '10

27 Apr '10

--_002_3CDE8F636E09F24F90BE98063FB0AD9D76545E3903ISAMAILisabel_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable I have attached the arl, and its valid but can't be validated . Can you tell me what can be the issue Thanks Mayashankar Mishra Mayashankar Mishra Consultant E-mail : mmishra(a)isabel.eu Tel : +32 (0)2 403.18.84 Fax : +32 Isabel NV/S.A. Keizerinlaan 13-15 Boulevard de l'Imp=E9ratrice 1000 Brussels - Belgium RPR Bruxelles / RPM Brussel: BE 0455 530 509 http://www.isabel.eu/ http://www.zoomit.eu/ Zoomit is a Registered Trademark of Isabel NV/S.A. Disclaimer : http://www.isabel.eu/gps/en/disclaimer/mailing.php -----Original Message----- From: masarati(a)aero.polimi.it [mailto:masarati@aero.polimi.it] Sent: 2010-04-27 16:43 To: Mayashankar Mishra Cc: openldap-its(a)openldap.org Subject: Re: (ITS#6537) arl[authority revocation list] issue during opnelda= p upgrade > Full_Name: Mayashankar Mishra > Version: 2.4.21 > OS: rhel5 > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (195.122.110.8) > > > Hi, > > I have to upgrade the openldap from version 2.2.26 to 2.4.21 All goes > fine except for the arl[authority revocation list] failed to get added > in new database. > > I see the binary version of arl from old openldap, its fine. > > When i try to upload the same on openldap 2.4.21 it provides the error > Root error: [LDAP: error code 21 - authorityRevocationList;binary: > value #0 invalid per syntax] > > > Note the same arl when added in older version of openldap works fine > > Any guess what could be the reason This is not a bug, but likely invalid data. Certificate list syntax valida= tor and all related routines were stubs until 2.4, so basically everything = was treated as valid. Now the syntax is validated thoroughly. This ITS will be closed. Please continue discussion on openldap-software, = if needed. Only in case a valid certificate list is not correctly validate= d (i.e. you detect an actual bug in that code), this ITS can be revitalized= . p. --_002_3CDE8F636E09F24F90BE98063FB0AD9D76545E3903ISAMAILisabel_ Content-Type: application/octet-stream; name="authm.arl" Content-Description: authm.arl Content-Disposition: attachment; filename="authm.arl"; size=612; creation-date="Tue, 27 Apr 2010 12:51:37 GMT"; modification-date="Tue, 27 Apr 2010 13:58:42 GMT" Content-Transfer-Encoding: base64 TUlJQndUQ0JxZ0lCQVRBTkJna3Foa2lHOXcwQkFRVUZBREJVTVFzd0NRWURWUVFHRXdKQ1pURVBN QTBHQTFVRUJ4TUdTWE5oWW1WcwpNUXN3Q1FZRFZRUUtFd0pEWVRFbk1DVUdBMVVFQXhNZVNYTmhZ bVZzSUVObGNuUnBabWxqWVhScGIyNGdRWFYwYUc5eWFYUjVGdzB3Ck5URXlNREl3TkRBd05UUmFG dzB3TlRFeU1ETXdOREF3TURCYU1BQ2dJREFlTUE4R0ExVWRJd1FJTUFhQUJFTkJNREl3Q3dZRFZS MFUKQkFRQ0FnelNNQTBHQ1NxR1NJYjNEUUVCQlFVQUE0SUJBUUFMV1Jtbjc5VE5sbE9EK29PcXY3 cjY0TlNGZEJHby84ZkNRQXlrYmpjTgpNSkhSalRPU3FmVTBhbXYyaFM1MDlJNjgvVmh3ZndIdzlO ek5zblBFZXZXa2Ixb0ZXU0x2WjZGdVdYVE5PVjVuOWFZL2JNcUpYNWdQCnR3bE5XZXovQVR2OTlN NVdiVVVLUGpEeHBjOTBiZDJ4ak1vS0JobHNyeWtNZzBEWGFSa2lZWVJFbDNsWEYwd3I0Ri9Gc2ZP N1FTK2YKemtpZm1JMDlaN3pDSWMyMDQzeGwyUnBYdlJvc3R6cnE4bmNRZGpCaDVVZEhqM3FXMEhR ZmtDYU54aUl5M2VaWTRKS3lDcVc5N25UeQpoOXY1QXMxWDJtdnVqYlR0S1c1aTVsblhlSER0ak9k dWZ2YTg2VGJadlN5UXlpa3hMUmxwUWxlK1lpNXg2TldkRE43U3o5TE8K --_002_3CDE8F636E09F24F90BE98063FB0AD9D76545E3903ISAMAILisabel_--

1 0

Re: (ITS#6537) arl[authority revocation list] issue during opneldap upgrade
by masarati＠aero.polimi.it 27 Apr '10

27 Apr '10

> Full_Name: Mayashankar Mishra > Version: 2.4.21 > OS: rhel5 > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (195.122.110.8) > > > Hi, > > I have to upgrade the openldap from version 2.2.26 to 2.4.21 > All goes fine except for the arl[authority revocation list] failed to get > added > in new database. > > I see the binary version of arl from old openldap, its fine. > > When i try to upload the same on openldap 2.4.21 it provides the error > Root error: [LDAP: error code 21 - authorityRevocationList;binary: value > #0 > invalid per syntax] > > > Note the same arl when added in older version of openldap works fine > > Any guess what could be the reason This is not a bug, but likely invalid data. Certificate list syntax validator and all related routines were stubs until 2.4, so basically everything was treated as valid. Now the syntax is validated thoroughly. This ITS will be closed. Please continue discussion on openldap-software, if needed. Only in case a valid certificate list is not correctly validated (i.e. you detect an actual bug in that code), this ITS can be revitalized. p.

1 0

(ITS#6537) arl[authority revocation list] issue during opneldap upgrade
by mmishra＠isabel.be 27 Apr '10

27 Apr '10

Full_Name: Mayashankar Mishra Version: 2.4.21 OS: rhel5 URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (195.122.110.8) Hi, I have to upgrade the openldap from version 2.2.26 to 2.4.21 All goes fine except for the arl[authority revocation list] failed to get added in new database. I see the binary version of arl from old openldap, its fine. When i try to upload the same on openldap 2.4.21 it provides the error Root error: [LDAP: error code 21 - authorityRevocationList;binary: value #0 invalid per syntax] Note the same arl when added in older version of openldap works fine Any guess what could be the reason

1 0

(ITS#6536) Autogroup overlay enhancement
by raphael.ouazana＠linagora.com 27 Apr '10

27 Apr '10

Full_Name: Raphael Ouazana Version: 2.4.21 OS: Linux URL: ftp://ftp.openldap.org/incoming/raphael-ouazana-autogroup-100427.patch Submission from: (NULL) (213.41.232.151) Hi, The attached patch allow the autogroup overlay to handle correctly the attr part of the URL ldap://dc=example,dc=com?attr?sub?(filter). Before this patch, the attr part was simply ignored. Now the group entry is populated by the values of the attribute attr in the resulting entries. Implementation details: Some cases (modify, delete) are harder to handle when you store values instead of dn. In this cases the overlay try to detect if groups have been modified and then simply refresh them. This can cause performance hits if the search specified by the URL deals with an important number of entries. Legal notice: This patch file is derived from OpenLDAP Software. All of the modifications to OpenLDAP Software represented in this following patch were developed by Raphael Ouazana raphael.ouazana(a)linagora.com. These modifications are not subject to any license of Linagora. The attached modifications to OpenLDAP Software are subject to the following notice: Copyright 2010 Raphael Ouazana, Linagora Redistribution and use in source and binary forms, with or without modification, are permitted only as authorized by the OpenLDAP Public License.

1 0

Re: (ITS#6535) OpenLDAP fails to build with back-ndb enabled
by hyc＠symas.com 26 Apr '10

26 Apr '10

giesen(a)snickers.org wrote: > Full_Name: Gary T. Giesen > Version: 2.4.21 > OS: RHEL 6 Beta 1 > URL: > Submission from: (NULL) (66.135.102.175) > > > OpenLDAP 2.4.21 (as well as 2.4.19) fails to configure or build on RHEL6 with > back-ndb support enabled. I've solved the problem with configure by applying a > modified version of the patch found here: > > http://lists.freebsd.org/pipermail/freebsd-ports-bugs/2010-March/184248.html That patch is invalid. The current code configures and builds properly with a recent mysql-cluster. It was developed originally against cluster 6.0.x. I have tested it again with the current MySQL Cluster 7.1.3 available here http://mysql.com/downloads/cluster/ > However, when building, I get the following error: > This occurs with rebuilding the 2.4.19 SRPM, using the openldap.org 2.4.19 > tarball, and the openldap 2.4.21 tarball. I'm using the Redhat-supplied > mysql-cluster. Your MySQL package is obsolete by at least 2 years. This ITS will be closed. If you need more assistance talk to your distro vendor. As a side note, if your distro vendor is unable to help you, supported RPMs of OpenLDAP with back-ndb are available from Symas Corp. -- -- 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#6535) OpenLDAP fails to build with back-ndb enabled
by giesen＠snickers.org 26 Apr '10

26 Apr '10

Full_Name: Gary T. Giesen Version: 2.4.21 OS: RHEL 6 Beta 1 URL: Submission from: (NULL) (66.135.102.175) OpenLDAP 2.4.21 (as well as 2.4.19) fails to configure or build on RHEL6 with back-ndb support enabled. I've solved the problem with configure by applying a modified version of the patch found here: http://lists.freebsd.org/pipermail/freebsd-ports-bugs/2010-March/184248.html However, when building, I get the following error: cd back-ndb; make -w all make[3]: Entering directory `/home/ggiesen/openldap-2.4.21/servers/slapd/back-ndb' rm -f version.c ../../../build/mkversion -v "2.4.21" back_ndb > version.c /bin/sh ../../../libtool --tag=disable-shared --mode=compile g++ -g -O2 -I../../../include -I../../../include -I.. -I./.. -I/usr/include/mysql -I/usr/include/mysql/storage/ndb -I/usr/include/mysql/storage/ndb/ndbapi -c init.cpp g++ -g -O2 -I../../../include -I../../../include -I.. -I./.. -I/usr/include/mysql -I/usr/include/mysql/storage/ndb -I/usr/include/mysql/storage/ndb/ndbapi -c init.cpp -o init.o init.cpp:65: error: expected constructor, destructor, or type conversion before '*' token init.cpp: In function 'int ndb_back_initialize(BackendInfo*)': init.cpp:366: warning: deprecated conversion from string constant to 'char*' init.cpp:366: warning: deprecated conversion from string constant to 'char*' init.cpp:366: warning: deprecated conversion from string constant to 'char*' init.cpp:366: warning: deprecated conversion from string constant to 'char*' init.cpp:366: warning: deprecated conversion from string constant to 'char*' init.cpp:366: warning: deprecated conversion from string constant to 'char*' init.cpp:366: warning: deprecated conversion from string constant to 'char*' init.cpp:366: warning: deprecated conversion from string constant to 'char*' init.cpp:376: error: 'ndb_lastrow_code' was not declared in this scope init.cpp:376: error: expected type-specifier before 'NdbInterpretedCode' init.cpp:376: error: expected ';' before 'NdbInterpretedCode' make[3]: *** [init.lo] Error 1 make[3]: Leaving directory `/home/ggiesen/openldap-2.4.21/servers/slapd/back-ndb' make[2]: *** [.backend] Error 1 make[2]: Leaving directory `/home/ggiesen/openldap-2.4.21/servers/slapd' make[1]: *** [all-common] Error 1 make[1]: Leaving directory `/home/ggiesen/openldap-2.4.21/servers' make: *** [all-common] Error 1 This occurs with rebuilding the 2.4.19 SRPM, using the openldap.org 2.4.19 tarball, and the openldap 2.4.21 tarball. I'm using the Redhat-supplied mysql-cluster.

1 0

(ITS#6534) bad ifdef/elif clause in liblutil
by quanah＠OpenLDAP.org 26 Apr '10

26 Apr '10

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: #ifdef HAVE_SETSID (void) setsid(); #elif TIOCNOTTY if ( (sd = open( "/dev/tty", O_RDWR )) != -1 ) { (void) ioctl( sd, TIOCNOTTY, NULL ); (void) close( sd ); } #endif The elif should be #elif defined(TIOCNOTTY)

1 0

Re: (ITS#6474) test004 (hdb) crashes when slapd is compiled with -D_FORTIFY_SOURCE=2
by Ralf Haferkamp 26 Apr '10

26 Apr '10

It seems the fix (in r1.169 of back-bdb/dn2id.c, unfortunately the commit messages did refer the wrong ITS :( ) didn't make in into 2.4.22. Was it overlooked or left out intentionally?

1 0

Re: (ITS#6531) Modify updateref to generate referrals on the backend
by rein＠basefarm.no 26 Apr '10

26 Apr '10

On 04/25/2010 12:49 AM, hyc(a)symas.com wrote: > Also in terms of logical abstraction the current behavior is wrong; the > frontend should of course generate the default_referral responses but > updateref is a per-backend item and should be generated at the backend layer. > Ideally this would all have been fixed to behave correctly by moving all > replication support into an overlay, where it properly belongs. As an interim > step it would be trivial to write an updateref overlay that supersedes the > current updateref behavior. Updateref processing should imo be kept out of any replication modules, it is needed in databases where syncrepl isn't configured too. I'm using it on my subordinate databases (with an artificial updatedn so that slapd accepts it..) when syncrepl is configured on the superior glue database without managing all of the subordinate databases. I.e, the infamous test058... I was having the same "chain only on some of the databases" requirement and is using a patch that allows it. I consider this patch more of a hack than a correct solution, which is why I haven't contributed it. A separate updateref overlay apear to me as the best solution. But for what it's worth, my patch is now in: ftp://ftp.openldap.org/incoming/rein-ITS6531.patch An advantage with this patch over a new overlay is that it should be usable without any configuration changes (provided the chain overlay have already been configured in the databases and found to not work as expected there that is ... ;-). Rein

1 0

Re: (ITS#6531) Modify updateref to generate referrals on the backend
by masarati＠aero.polimi.it 25 Apr '10

25 Apr '10

[snip] >> Although redesigning referral generation in slapd could streamline >> things, >> I don't quite see what issues can't be addressed using a global instance >> of slapo-chain. You can configure referral chasing differently for >> different domains using the chain-uri directive. I favor fixing only >> what's actually broken. > > The request revolves around having different behavior for different > databases. > With a global slapo-chain you cannot turn off referral chasing; URIs that > are > not explicitly configured will still be chased. > > Also in terms of logical abstraction the current behavior is wrong; the > frontend should of course generate the default_referral responses but > updateref is a per-backend item and should be generated at the backend > layer. > Ideally this would all have been fixed to behave correctly by moving all > replication support into an overlay, where it properly belongs. As an > interim > step it would be trivial to write an updateref overlay that supersedes the > current updateref behavior. As I said, I recognize the usefulness of such a change: I first moved replication into an overlay (ITS#4261). I'm questioning its need for the case at hand. Perhaps allowing slapo-chain to ignore some URIs would be easier to implement, and generally useful in other applications. In any case, I might spare some time to revitalize (ITS#4261), now that slurpd is no longer around and thus things simplify significantly. p.

1 0

Re: (ITS#6533) add rid to syncrepl config logs
by masarati＠aero.polimi.it 25 Apr '10

25 Apr '10

Patched in HEAD. Thanks, p.

1 0

(ITS#6533) add rid to syncrepl config logs
by jonathan＠phillipoux.net 25 Apr '10

25 Apr '10

Full_Name: Jonathan Clarke Version: RE24 OS: URL: ftp://ftp.openldap.org/incoming/jonathan-clarke-syncrepl-log-20100425.patch Submission from: (NULL) (88.164.187.72) Hi, Currently, when a syncrepl statement is added, the following is output on log level config: Config: ** successfully added syncrepl "ldap://localhost:9011/" In the case of setups replicating several databases from the same server (multimaster with cn=config and a database for example), this leads to confusing identical messages. I attach a patch to add the RID to this line, like this: Config: ** successfully added syncrepl "ldap://localhost:9011/" (rid=001) Please consider this for inclusion. Thanks, Jonathan

1 0

(ITS#6532) Support for common orderingMatching rules in extensible match filters
by daniel＠pluta.biz 25 Apr '10

25 Apr '10

Full_Name: Daniel Pluta Version: HEAD OS: Linux URL: ftp://ftp.openldap.org/incoming/servers-slapd-schema_init.patch Submission from: (NULL) (2001:470:9feb:ff02:f435:4e97:f213:bc9e) In regard to http://www.openldap.org/lists/openldap-technical/201004/msg00228.html I've uploaded a patch which enables support for octetStringOrderingMatch to be used in combination with extensible match filters. According RFC4517 section 4.1 the following ordering matching rules currently available in slapd are affected by this patch: caseIgnoreOrderingMatch caseExactOrderingMatch In addition I've added this kind of support to generalizedTimeOrderingMatch, too. The patch can be downloaded here: ftp://ftp.openldap.org/incoming/servers-slapd-schema_init.patch Note: RFC4517 section 4.1 also lists some substring matching rules which also SHOULD be supported in extensible match filters. slapd as well as my patch currently do not offer support for them.

1 0

Re: (ITS#6531) Modify updateref to generate referrals on the backend
by hyc＠symas.com 24 Apr '10

24 Apr '10

masarati(a)aero.polimi.it wrote: >> Full_Name: Ryan Steele >> Version: 2.4.18 >> OS: Ubuntu Server >> URL: ftp://ftp.openldap.org/incoming/ >> Submission from: (NULL) (207.106.239.81) >> >> >> Per conversation on the #openldap IRC channel on Freenode with Howard Chu, >> it >> has been deemed appropriate to modify the behavior of updateref to answer >> referrals on the backend. This would allow one to use updateref to >> automatically chase referrals for individual backends, instead of it being >> all >> or nothing. Here is the tail end of the channel conversation: >> >> >> <hyc> when you configure an updateref on a backend, that referral is only >> generated in the frontend so putting the overlay on the database, misses >> it... >> >> <rgsteele> Well, I am intending to set an updateref on that backend >> >> <hyc> then you have a problem >> >> <rgsteele> Hm, so you can't do automatic referrals on individual backends >> then? >> >> <rgsteele> That was my original question, or at least the intent of it. >> >> <hyc> not using updateref, no >> >> <rgsteele> Does your response imply there's another way? >> >> <hyc> probably we should fix updateref to be generated at the backend >> level >> >> <rgsteele> That would be good - I'd be happy to write tests or something >> to help >> with that. >> >> <hyc> the "other way" is the normal referral mechanism - using referral >> entries >> inside a database >> >> <hyc> but like I said, updateref is a relic, we've carried it forward >> without >> really adapting it >> >> <hyc> probably should file an ITS about this >> >> <rgsteele> Interesting, I wasn't aware of that method. I'll have to do >> some >> research on that - thanks! Also, is there anything I can do to help get >> the >> process of fixing updateref to generate referrals on the backend? >> >> <rgsteele> I can file the ITS if you like? >> >> <hyc> go ahead > > It is correct that referrals are generated by the frontend, but the > frontend uses information contained in the updateref of each database. > The slapo-chain needs to be global, in order to intercept those referrals. > > Although redesigning referral generation in slapd could streamline things, > I don't quite see what issues can't be addressed using a global instance > of slapo-chain. You can configure referral chasing differently for > different domains using the chain-uri directive. I favor fixing only > what's actually broken. The request revolves around having different behavior for different databases. With a global slapo-chain you cannot turn off referral chasing; URIs that are not explicitly configured will still be chased. Also in terms of logical abstraction the current behavior is wrong; the frontend should of course generate the default_referral responses but updateref is a per-backend item and should be generated at the backend layer. Ideally this would all have been fixed to behave correctly by moving all replication support into an overlay, where it properly belongs. As an interim step it would be trivial to write an updateref overlay that supersedes the current updateref behavior. -- -- 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#6531) Modify updateref to generate referrals on the backend
by masarati＠aero.polimi.it 24 Apr '10

24 Apr '10

> Full_Name: Ryan Steele > Version: 2.4.18 > OS: Ubuntu Server > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (207.106.239.81) > > > Per conversation on the #openldap IRC channel on Freenode with Howard Chu, > it > has been deemed appropriate to modify the behavior of updateref to answer > referrals on the backend. This would allow one to use updateref to > automatically chase referrals for individual backends, instead of it being > all > or nothing. Here is the tail end of the channel conversation: > > > <hyc> when you configure an updateref on a backend, that referral is only > generated in the frontend so putting the overlay on the database, misses > it... > > <rgsteele> Well, I am intending to set an updateref on that backend > > <hyc> then you have a problem > > <rgsteele> Hm, so you can't do automatic referrals on individual backends > then? > > <rgsteele> That was my original question, or at least the intent of it. > > <hyc> not using updateref, no > > <rgsteele> Does your response imply there's another way? > > <hyc> probably we should fix updateref to be generated at the backend > level > > <rgsteele> That would be good - I'd be happy to write tests or something > to help > with that. > > <hyc> the "other way" is the normal referral mechanism - using referral > entries > inside a database > > <hyc> but like I said, updateref is a relic, we've carried it forward > without > really adapting it > > <hyc> probably should file an ITS about this > > <rgsteele> Interesting, I wasn't aware of that method. I'll have to do > some > research on that - thanks! Also, is there anything I can do to help get > the > process of fixing updateref to generate referrals on the backend? > > <rgsteele> I can file the ITS if you like? > > <hyc> go ahead It is correct that referrals are generated by the frontend, but the frontend uses information contained in the updateref of each database. The slapo-chain needs to be global, in order to intercept those referrals. Although redesigning referral generation in slapd could streamline things, I don't quite see what issues can't be addressed using a global instance of slapo-chain. You can configure referral chasing differently for different domains using the chain-uri directive. I favor fixing only what's actually broken. p.

1 0

cn=monitor attributes (monitorOpInitiated for example) missing in cn=Subschema
by Cannady, Mike 24 Apr '10

24 Apr '10

I'm using openldap-stable-20100219.tgz build. When I look at cn=Monitor with browsing tools (like Softerra LDAP browser) I do see entries for monitorOpInitiated and monitorOpCompleted in DN cn=Operations,cn=Monitor. When I look at cn=SubSchema, I do not see any definitions of these two attributes. Using (unfortunately) Microsoft's VBScript, ADODB, and ADsDSOOBJECT to access to access cn=Monitor, I can access everything that is defined in the subschema (entryDN, modifyTimestamp, etc); however, I cannot access MonitorOpInitiated and such. Looking at the logs, It looks like the query never gets to the ldap server because MS checks it against the cn=subschema. I saw ITS#4947 and ITS#5576 which sounds like what my problem is (attributes not published). Is there a fix for this and what would that fix be? My OS for the ldap server is Redhat Enterprise 5.4. At the end of this email is my redacted slapd.conf file. ---Thanks Mike Cannady Information Services Horry Telephone Cooperative (HTC) Phone: (843)369-8212 Email: Mike.Cannady(a)htcinc.net [root@vmLDAPdev2 openldap]# cat slapd.conf # # See slapd.conf(5) for details on configuration options. # This file should NOT be world readable. # include /usr/local/etc/openldap/schema/core.schema include /usr/local/etc/openldap/schema/cosine.schema include /usr/local/etc/openldap/schema/inetorgperson.schema include /usr/local/etc/openldap/schema/nis.schema include /usr/local/etc/openldap/HTC/iaaa-radius.schema include /usr/local/etc/openldap/HTC/radius.schema include /usr/local/etc/openldap/HTC/users.schema # Allow LDAPv2 client connections. This is NOT the default. allow bind_v2 loglevel 0x100 #loglevel any sizelimit unlimited # Do not enable referrals until AFTER you have a working directory # service AND an understanding of referrals. #referral ldap://root.openldap.org ServerID 002 pidfile /usr/local/var/run/slapd.pid argsfile /usr/local/var/run/slapd.args access to * by dn.one="ou=replicants,ou=admin,dc=htc,dc=com" read by * break access to dn.subtree="dc=htc,dc=com" by dn.one="ou=admin,dc=htc,dc=com" manage by self write by anonymous auth access to * by self write by users read by anonymous auth ####################################################################### # database definitions ####################################################################### database bdb suffix "dc=htc,dc=com" rootdn "cn=Manager,dc=htc,dc=com" # Cleartext passwords, especially for the rootdn, should # be avoided. See slappasswd(8) and slapd.conf(5) for details. # Use of strong authentication encouraged. # rootpw secret # rootpw {crypt}ijFYNcSNctBYg rootpw {xxxxxxx}xxxxxxxxxxxxxxxxxxxxxxxxxx # The database directory MUST exist prior to running slapd AND # should only be accessible by the slapd and slap tools. # Mode 700 recommended. directory /usr/local/var/openldap-data cachesize 50000 dncachesize 50000 idlcachesize 150000 checkpoint 1024 5 # Indices to maintain for this database index objectClass eq,pres index ou,cn,mail,surname,givenname eq,pres,sub index uidNumber,gidNumber,loginShell eq,pres index uid,memberUid eq,pres,sub index nisMapName,nisMapEntry eq,pres,sub index entryCSN eq index entryUUID eq # Replicas of this database syncrepl rid=001 provider=ldap://vmldapdev1.htc.external:389 type=refreshAndPersist retry="5 5 300 +" searchbase="dc=htc,dc=com" attrs="*,+" bindmethod=simple binddn="uid=vmldapdev2,ou=replicants,ou=admin,dc=htc,dc=com" credentials=atest2 mirrormode TRUE overlay syncprov syncprov-checkpoint 1000 1 database monitor [root@vmLDAPdev2 openldap] ********************************************************************** HTC Disclaimer: The information contained in this message may be privileged and confidential and protected from disclosure. If the reader of this message is not the intended recipient, or an employee or agent responsible for delivering this message to the intended recipient, you are hereby notified that any dissemination, distribution or copying of this communication is strictly prohibited. If you have received this communication in error, please notify us immediately by replying to the message and deleting it from your computer. Thank you. **********************************************************************

2 1

(ITS#6531) Modify updateref to generate referrals on the backend
by ryans＠aweber.com 23 Apr '10

23 Apr '10

Full_Name: Ryan Steele Version: 2.4.18 OS: Ubuntu Server URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (207.106.239.81) Per conversation on the #openldap IRC channel on Freenode with Howard Chu, it has been deemed appropriate to modify the behavior of updateref to answer referrals on the backend. This would allow one to use updateref to automatically chase referrals for individual backends, instead of it being all or nothing. Here is the tail end of the channel conversation: <hyc> when you configure an updateref on a backend, that referral is only generated in the frontend so putting the overlay on the database, misses it... <rgsteele> Well, I am intending to set an updateref on that backend <hyc> then you have a problem <rgsteele> Hm, so you can't do automatic referrals on individual backends then? <rgsteele> That was my original question, or at least the intent of it. <hyc> not using updateref, no <rgsteele> Does your response imply there's another way? <hyc> probably we should fix updateref to be generated at the backend level <rgsteele> That would be good - I'd be happy to write tests or something to help with that. <hyc> the "other way" is the normal referral mechanism - using referral entries inside a database <hyc> but like I said, updateref is a relic, we've carried it forward without really adapting it <hyc> probably should file an ITS about this <rgsteele> Interesting, I wasn't aware of that method. I'll have to do some research on that - thanks! Also, is there anything I can do to help get the process of fixing updateref to generate referrals on the backend? <rgsteele> I can file the ITS if you like? <hyc> go ahead

1 0

Re: (ITS#4685) Updated changelog overlay by Neil Dunbar
by sebastian＠rieger.info 23 Apr '10

23 Apr '10

sorry... the last update was broken. I've uploaded a new version to: <ftp://ftp.openldap.org/incoming/rieger-changelog-2.4.21-pkg-100423.tgz> this version compiles and runs smoothly with 2.4.21. Also I fixed a minor memory leak. Any feedback is welcome ;)

1 0

Re: (ITS#6151) Update cosine.schema to RFC 4524
by Kurt＠OpenLDAP.org 22 Apr '10

22 Apr '10

On Apr 22, 2010, at 2:58 PM, Michael Str=F6der wrote: > Kurt Zeilenga wrote: >> One additional note, I generally would advise that a schema-aware = client >> not alter it's update behavior of elements based upon whether said = elements >> are active or inactive (OBSOLETE) in the schema.=20 >=20 > I disagree especially for cases when new data is added. I think you're trying to make the client far smarter than it really = ought to be. If the clients configured to place say place element of data in = attribute x, it shouldn't try to put it elsewhere. It should fail. While certainly one could design a client such as it could be configured = with fallbacks for attributes, and fallback for fallbacks, etc., this is = an unnecessarily complication IMO. Also, note that were a client to attempt the above, it could still fail = due to an element being marked inactive between the time it read the = schema and the time it tried the DIT update. Of course, one could = complicate the client further by trying to handle this as well. >=20 >> Instead, they should just >> try the update and, if it fails, report it as they normally would. >=20 > Modifying existing data I first have to think about... >=20 >> Handling the inactive condition locally hides the error from the = directory=20 >> administrator, who is likely relying on directory server logs to find=20= >> applications which using inactive schema. >=20 > Hmm, that's not the case with a schema-aware client anyway which = guides the > user *not* to use OBSOLETE schema elements. I generally assume the user is not selecting which attribute to store = some piece of information into. I assume the client been programmed to = collect a piece of information and configured (or programmed) where to = store it. The client you refer to is what I would call an application-neutral LDAP = directory administration tool. For such a tool, it might be reasonable = to warn the user (whose generally an "administrator" of some sort as = opposed to a "normal" user). =20 > You're likely talking about > detecting pre-configured applications with hard-coded use of OBSOLETE = object > classes and attribute types. > Most times these are not schema-aware at all. Well, pre-configured applications may be schema-aware but maybe not as = fully as an LDAP directory administration tool might be. They might = check that the element they were configured to use is appropriate for = that use by examining its specification in the subschema. -- Kurt=

1 0

Re: (ITS#6151) Update cosine.schema to RFC 4524
by michael＠stroeder.com 22 Apr '10

22 Apr '10

Kurt Zeilenga wrote: > One additional note, I generally would advise that a schema-aware client > not alter it's update behavior of elements based upon whether said elements > are active or inactive (OBSOLETE) in the schema. I disagree especially for cases when new data is added. > Instead, they should just > try the update and, if it fails, report it as they normally would. Modifying existing data I first have to think about... > Handling the inactive condition locally hides the error from the directory > administrator, who is likely relying on directory server logs to find > applications which using inactive schema. Hmm, that's not the case with a schema-aware client anyway which guides the user *not* to use OBSOLETE schema elements. You're likely talking about detecting pre-configured applications with hard-coded use of OBSOLETE object classes and attribute types. Most times these are not schema-aware at all. Ciao, Michael.

1 0

Re: (ITS#6530) Controls in successful bind response are discarded by proxy backends
by masarati＠aero.polimi.it 22 Apr '10

22 Apr '10

> --On Thursday, April 22, 2010 3:57 PM +0000 masarati(a)aero.polimi.it wrote: > >> Full_Name: Pierangelo Masarati >> Version: HEAD/re24 >> OS: irrelevant >> URL: ftp://ftp.openldap.org/incoming/ >> Submission from: (NULL) (129.72.165.211) >> Submitted by: ando >> >> >> Related to ITS#6166; in the meanwhile, a specific fix is coming. > > ITS#6166 is marked RE25/RE30. Is this fix appropriate for RE24? As soon as ITS#6166 is fixed in re25, ITS#5630 is a re24-only issue. If successful bind response were returned by backends/overlays instead of the frontend, this issue wouldn'd have appeared. This does not mean we need to rush it into 2.4.22. It passed all tests for me, and showed no leaks or so when proxying binds with password policy control, but I'd like it to be reviewed. p.

1 0

Re: (ITS#6530) Controls in successful bind response are discarded by proxy backends
by quanah＠zimbra.com 22 Apr '10

22 Apr '10

--On Thursday, April 22, 2010 3:57 PM +0000 masarati(a)aero.polimi.it wrote: > Full_Name: Pierangelo Masarati > Version: HEAD/re24 > OS: irrelevant > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (129.72.165.211) > Submitted by: ando > > > Related to ITS#6166; in the meanwhile, a specific fix is coming. ITS#6166 is marked RE25/RE30. Is this fix appropriate for RE24? --Quanah -- Quanah Gibson-Mount Principal Software Engineer Zimbra, Inc -------------------- Zimbra :: the leader in open source messaging and collaboration

1 0

Re: (ITS#6151) Update cosine.schema to RFC 4524
by Kurt＠OpenLDAP.org 22 Apr '10

22 Apr '10

On Apr 22, 2010, at 10:20 AM, Kurt Zeilenga wrote: > The purpose of the OBSOLETE (inactive) flag is to support transition = away from a particular schema element. Basically, if one no longer = wants to use the attribute type 'x' in their directory, they should 1) = mark x as inactive in the subschema, 2) then remove all uses of x, 3) = then remove x from the subschema. One additional note, I generally would advise that a schema-aware client = not alter it's update behavior of elements based upon whether said = elements are active or inactive (OBSOLETE) in the schema. Instead, they = should just try the update and, if it fails, report it as they normally = would. Handling the inactive condition locally hides the error from the = directory administrator, who is likely relying on directory server logs = to find applications which using inactive schema. He may well not have = access to all the clients' logs. -- Kurt=

1 0

Re: (ITS#6151) Update cosine.schema to RFC 4524
by Kurt＠OpenLDAP.org 22 Apr '10

22 Apr '10

On Apr 22, 2010, at 9:58 AM, Michael Str=F6der wrote: > Kurt Zeilenga wrote: >>=20 >> On Apr 22, 2010, at 1:34 AM, michael(a)stroeder.com wrote: >>=20 >>> Kurt Zeilenga wrote: >>>> obsoletes !=3D OBSOLETE, so no. That is, the meaning of the term >>>> 'obsolete' is quite different in these two contexts. >>>>=20 >>>> The latter context the term is defined as follows: The OBSOLETE = field, if >>>> present, indicates the element is not active. >>>=20 >>> I agree that OBSOLETE should not be set in this case. >>>=20 >>>> For user application attribute types, whether the type is active or = not is, >>>> I think, best left to the schema administrator. >>>=20 >>> Who is the schema administrator? >>=20 >> Generally speaking, the OpenLDAP admin administrates which schema = elements >> to load into the schema and whether each such element is active and >> inactive. >=20 > What does "active and inactive" mean exactly? Does that include = changing the > OBSOLETE keyword in schema files? I hope not... The purpose of the OBSOLETE (inactive) flag is to support transition = away from a particular schema element. Basically, if one no longer = wants to use the attribute type 'x' in their directory, they should 1) = mark x as inactive in the subschema, 2) then remove all uses of x, 3) = then remove x from the subschema. The directory prevents all non-removal updates to inactive elements, = allowing 2 to be well performed. >=20 >> While in some cases a schema admin might design schema elements, I = consider >> schema admin and schema element designer to be two separate roles. >=20 > Agreed. >=20 >>> I'm nitpicking here because on the OpenLDAP >>> lists we all keep telling OpenLDAP admins not to mess with the = standard schema >>> at all. >>=20 >> We often advise admins to load various schema elements into their = schemas. >=20 > The role for loading the shipped schema files is not the question = here. >=20 >> When at I say "don't mess with standard schema elements", what I mean = is >> don't change aspects of schema specifications which are consider per = the >> technical specifications to be immutable on published in a technical >> specification (or otherwise broadly published). >=20 > Does "immutable" include OBSOLETE? I hope so... OBSOLETE is one of the mutable properties of a schema element (because = otherwise it couldn't support local movements away from arbitrary schema = elements). -- Kurt >=20 > Ciao, Michael.

1 0

Re: (ITS#6151) Update cosine.schema to RFC 4524
by michael＠stroeder.com 22 Apr '10

22 Apr '10

Kurt Zeilenga wrote: > > On Apr 22, 2010, at 1:34 AM, michael(a)stroeder.com wrote: > >> Kurt Zeilenga wrote: >>> obsoletes != OBSOLETE, so no. That is, the meaning of the term >>> 'obsolete' is quite different in these two contexts. >>> >>> The latter context the term is defined as follows: The OBSOLETE field, if >>> present, indicates the element is not active. >> >> I agree that OBSOLETE should not be set in this case. >> >>> For user application attribute types, whether the type is active or not is, >>> I think, best left to the schema administrator. >> >> Who is the schema administrator? > > Generally speaking, the OpenLDAP admin administrates which schema elements > to load into the schema and whether each such element is active and > inactive. What does "active and inactive" mean exactly? Does that include changing the OBSOLETE keyword in schema files? I hope not... > While in some cases a schema admin might design schema elements, I consider > schema admin and schema element designer to be two separate roles. Agreed. >> I'm nitpicking here because on the OpenLDAP >> lists we all keep telling OpenLDAP admins not to mess with the standard schema >> at all. > > We often advise admins to load various schema elements into their schemas. The role for loading the shipped schema files is not the question here. > When at I say "don't mess with standard schema elements", what I mean is > don't change aspects of schema specifications which are consider per the > technical specifications to be immutable on published in a technical > specification (or otherwise broadly published). Does "immutable" include OBSOLETE? I hope so... Ciao, Michael.

1 0

(ITS#6530) Controls in successful bind response are discarded by proxy backends
by masarati＠aero.polimi.it 22 Apr '10

22 Apr '10

Full_Name: Pierangelo Masarati Version: HEAD/re24 OS: irrelevant URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (129.72.165.211) Submitted by: ando Related to ITS#6166; in the meanwhile, a specific fix is coming. p.

1 0

Re: (ITS#6151) Update cosine.schema to RFC 4524
by hyc＠symas.com 22 Apr '10

22 Apr '10

masarati(a)aero.polimi.it wrote: > 4) This, IMHO, implies that we need to provide two separate files, to > allow DSA admins to either load strict RFC4524 schema (no obsolete items) > or loose RFC4524 (entire RFC1274 schema). > > Now, we have different options to arrange the resulting schema files > (names used below are only an example, the final name can be discussed > when there's consensus on the approach): > > a) cosine.schema (== RFC1274) > cosine4524.schema (== RFC4524) > mutually exclusive (Kurt does not like this) > > b) cosine4524.schema (== RFC4524) > cosine.schema (== RFC1274 - RFC4524) > the latter includes the former > > c) cosine4524.schema (== RFC4524) > cosine1274.schema (== RFC1274 - RFC4524) > > (there might be more) Yes, cosine.schema wrapping cosine4524.schema and cosine1274.schema might be best. > Cases (a) and (b) have advantages: loading cosine.schema loads all RFC1274 > schema, thus existing configurations surely do not break. I concur case > (a) would cause a lot of complaints from people loading all available > schema files and having conflicts. Case (c) needs to modify > configuration, but avoids file nesting, if that's a problem at all. File nesting has some implications in cn=config, which is why I made the above suggestion. -- -- 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#6151) Update cosine.schema to RFC 4524
by Kurt＠OpenLDAP.org 22 Apr '10

22 Apr '10

On Apr 22, 2010, at 1:34 AM, michael(a)stroeder.com wrote: > Kurt Zeilenga wrote: >> obsoletes !=3D OBSOLETE, so no. That is, the meaning of the term >> 'obsolete' is quite different in these two contexts. >>=20 >> The latter context the term is defined as follows: The OBSOLETE = field, if >> present, indicates the element is not active. >=20 > I agree that OBSOLETE should not be set in this case. >=20 >> For user application attribute types, whether the type is active or = not is, >> I think, best left to the schema administrator. >=20 > Who is the schema administrator? Generally speaking, the OpenLDAP admin administrates which schema = elements to load into the schema and whether each such element is active = and inactive. While in some cases a schema admin might design schema elements, I = consider schema admin and schema element designer to be two separate = roles. > I'm nitpicking here because on the OpenLDAP > lists we all keep telling OpenLDAP admins not to mess with the = standard schema > at all. We often advise admins to load various schema elements into their = schemas. We generally assume admins run have only active elements in = the their schema as the need for inactive elements can generally be = avoided. When at I say "don't mess with standard schema elements", what I mean is = don't change aspects of schema specifications which are consider per the = technical specifications to be immutable on published in a technical = specification (or otherwise broadly published). There certainly are = other changes one can make to standard schema elements without violating = the technical specifications (e.g., changing the DESC value), and if = such case were to arise more generally, I might be more precise in my = general advice. That is, I rather only raise exceptions in advice when = it's actually applicable to the situation raised by the admin. -- Kurt=

1 0

Re: (ITS#6517) undefined references to ldif_*
by masarati＠aero.polimi.it 22 Apr '10

22 Apr '10

> > --=-hLLTpGMzur3nD+xeX+/o > Content-Type: text/plain; charset="UTF-8" > Content-Transfer-Encoding: quoted-printable > > Using these instructions, the issue remains with current CVS: Should be (re-)fixed in HEAD (pull out libraries/librewrite/Makefile.in). The issue emerged when ldifutil.c (who pulls in ldif_* from liblutil) was also added to libldap_r; this broke librewrite. It happened after ITS#6517 was closed. Please test. Thanks, p. > I have had it sometimes build from an old tree, but this from scratch > does not: > > =3D=3DGetting OpenLDAP=3D=3D > This guide presumes you are running OpenLDAP CVS HEAD from after 22 > April 2010 (or a release after that date) > > You need the 'deref' and 'rdnval' overlay. This may be in your packaged > version, but if not your must rebuild. > > To get OpenLDAP from CVS run: > > CVSROOT=3D:pserver:anonymous@cvs.OpenLDAP.org:/repo/OpenLDAP > export CVSROOT > cvs login > > You will need to enter at the prompt: > Password: (enter OpenLDAP) > > Then check out the tree > cvs -z3 checkout -P openldap > > Then change to the newly created 'openldap' directory: > cd openldap > > To update your OpenLDAP checkout (discarding local conflicts) from CVS > run: > > cvs -z9 update -dP 2>&1 | grep ^C | cut -b3-| xargs rm > cvs -z9 update -dP > > To build it run: > > CFLAGS=3D"-fno-omit-frame-pointer" `dirname $0`/configure > --enable-overlays=3Dmod --enable-modules --enable-dynamic || exit 1 > make clean all AC_CFLAGS=3D-g > > --=20 > Andrew Bartlett http://samba.org/~abartlet/ > Authentication Developer, Samba Team http://samba.org > Samba Developer, Cisco Inc. > > > --=-hLLTpGMzur3nD+xeX+/o > Content-Type: application/pgp-signature; name="signature.asc" > Content-Description: This is a digitally signed message part > > -----BEGIN PGP SIGNATURE----- > Version: GnuPG v2.0.14 (GNU/Linux) > > iD8DBQBL0BYkz4A8Wyi0NrsRAuntAKCf7rc4Q9IQrpMwcTeY6cOQIaSgnQCeOGh2 > FxErm+tMjQUnb0y7Hmgs9n8= > =zuyi > -----END PGP SIGNATURE----- > > --=-hLLTpGMzur3nD+xeX+/o-- > > > >

1 0

Re: (ITS#6151) Update cosine.schema to RFC 4524
by masarati＠aero.polimi.it 22 Apr '10

22 Apr '10

> Kurt Zeilenga wrote: >> obsoletes != OBSOLETE, so no. That is, the meaning of the term >> 'obsolete' is quite different in these two contexts. >> >> The latter context the term is defined as follows: The OBSOLETE field, >> if >> present, indicates the element is not active. > > I agree that OBSOLETE should not be set in this case. > >> For user application attribute types, whether the type is active or not >> is, >> I think, best left to the schema administrator. > > Who is the schema administrator? I'm nitpicking here because on the > OpenLDAP > lists we all keep telling OpenLDAP admins not to mess with the standard > schema > at all. IMO this includes setting OBSOLETE. I Think there's a misunderstanding. My understanding (and intention) is 1) You said you pulled in revisited cosine.schema also elements that were dropped in RFC4524. 2) I was asking whether the fact they were dropped implied they were OBSOLETE (i.e. had to be marked as OBSOLETE in their schema definition) 3) Kurt replied that they MUST NOT be marked as OBSOLETE. Whether they are loaded or not in a DSA's schema is at the DSA schema administrator's choice 4) This, IMHO, implies that we need to provide two separate files, to allow DSA admins to either load strict RFC4524 schema (no obsolete items) or loose RFC4524 (entire RFC1274 schema). Now, we have different options to arrange the resulting schema files (names used below are only an example, the final name can be discussed when there's consensus on the approach): a) cosine.schema (== RFC1274) cosine4524.schema (== RFC4524) mutually exclusive (Kurt does not like this) b) cosine4524.schema (== RFC4524) cosine.schema (== RFC1274 - RFC4524) the latter includes the former c) cosine4524.schema (== RFC4524) cosine1274.schema (== RFC1274 - RFC4524) (there might be more) Cases (a) and (b) have advantages: loading cosine.schema loads all RFC1274 schema, thus existing configurations surely do not break. I concur case (a) would cause a lot of complaints from people loading all available schema files and having conflicts. Case (c) needs to modify configuration, but avoids file nesting, if that's a problem at all. p.

1 0

(ITS#6517) undefined references to ldif_*
by abartlet＠samba.org 22 Apr '10

22 Apr '10

--=-hLLTpGMzur3nD+xeX+/o Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Using these instructions, the issue remains with current CVS: I have had it sometimes build from an old tree, but this from scratch does not: =3D=3DGetting OpenLDAP=3D=3D This guide presumes you are running OpenLDAP CVS HEAD from after 22 April 2010 (or a release after that date) You need the 'deref' and 'rdnval' overlay. This may be in your packaged version, but if not your must rebuild. To get OpenLDAP from CVS run: CVSROOT=3D:pserver:anonymous@cvs.OpenLDAP.org:/repo/OpenLDAP export CVSROOT cvs login You will need to enter at the prompt: Password: (enter OpenLDAP) Then check out the tree cvs -z3 checkout -P openldap Then change to the newly created 'openldap' directory: cd openldap To update your OpenLDAP checkout (discarding local conflicts) from CVS run: cvs -z9 update -dP 2>&1 | grep ^C | cut -b3-| xargs rm cvs -z9 update -dP To build it run: CFLAGS=3D"-fno-omit-frame-pointer" `dirname $0`/configure --enable-overlays=3Dmod --enable-modules --enable-dynamic || exit 1 make clean all AC_CFLAGS=3D-g --=20 Andrew Bartlett http://samba.org/~abartlet/ Authentication Developer, Samba Team http://samba.org Samba Developer, Cisco Inc. --=-hLLTpGMzur3nD+xeX+/o Content-Type: application/pgp-signature; name="signature.asc" Content-Description: This is a digitally signed message part -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.14 (GNU/Linux) iD8DBQBL0BYkz4A8Wyi0NrsRAuntAKCf7rc4Q9IQrpMwcTeY6cOQIaSgnQCeOGh2 FxErm+tMjQUnb0y7Hmgs9n8= =zuyi -----END PGP SIGNATURE----- --=-hLLTpGMzur3nD+xeX+/o--

1 0

Re: (ITS#6151) Update cosine.schema to RFC 4524
by michael＠stroeder.com 22 Apr '10

22 Apr '10

Kurt Zeilenga wrote: > obsoletes != OBSOLETE, so no. That is, the meaning of the term > 'obsolete' is quite different in these two contexts. > > The latter context the term is defined as follows: The OBSOLETE field, if > present, indicates the element is not active. I agree that OBSOLETE should not be set in this case. > For user application attribute types, whether the type is active or not is, > I think, best left to the schema administrator. Who is the schema administrator? I'm nitpicking here because on the OpenLDAP lists we all keep telling OpenLDAP admins not to mess with the standard schema at all. IMO this includes setting OBSOLETE. Ciao, Michael.

1 0

Re: (ITS#6151) Update cosine.schema to RFC 4524
by kurt＠OpenLDAP.org 21 Apr '10

21 Apr '10

On Apr 21, 2010, at 6:03 PM, masarati(a)aero.polimi.it wrote: >> Kurt Zeilenga wrote: >>>=20 >>> On Jun 1, 2009, at 4:30 AM, michael(a)stroeder.com wrote: >>>> Updated schema file cosine-update.schema attached. >>>=20 >>> I note that differs are generally preferred, even where the file is >>> mostly changed. This helps ensure changes that others might make to = the >>> file you started with are not lost. >>=20 >> I thought about sending a diff but the file in this form is more >> readable for easy review. Could someone please look at it whether = that's >> ok? >=20 >> Another approach would be to have two schema files, one which only >> contains the schema descriptions from RFC 4524 and one with the = missing >> schema descriptions from RFC 1274 with the latter obviously being >> dependent on the former. >=20 > I have one preliminary question for Kurt: since rfc4524 obsoletes = rfc1274, > should those schema items that were not brought forward be marked as > OBSOLETE? obsoletes !=3D OBSOLETE, so no. That is, the meaning of the term = 'obsolete' is quite different in these two contexts. The latter context the term is defined as follows: The OBSOLETE field, if present, indicates the element is not active. For user application attribute types, whether the type is active or not = is, I think, best left to the schema administrator. (Update operations = upon an inactive element is limited to removal of the element.) > If yes, then all schema could fit in one file. I'd like a > clear way to separate valid from obsolete schema. The obsolete items > should be available for backwards compatibility. As an alternative, = I'd > like to have a "slim" (without obsolete) and a complete version of the > file. I rather no element be specified in multiple files. > Could you please upload the file? Through the ITS attachments > don't work too well. >=20 >>>> IPR notice: >>>> This patch file is derived from OpenLDAP Software and RFC 4524 and = RFC >>>> 1274. All of the modifications to OpenLDAP Software represented in = the >>>> attached file were developed by Michael Str=F6der = <michael(a)stroeder.com>. >>>> I have not assigned rights and/or interest in this work to any = party. >>>=20 >>> While this notice of origin is fine, you did not include a rights >>> statement. >>=20 >> I, Michael Str=F6der, hereby place the modified schema file = cosine.schema >> attached to ITS#6151 (and only these modifications) into the public >> domain. Hence, these modifications may be freely used and/or >> redistributed for any purpose with or without attribution and/or = other >> notice. >=20 > Am I right in assuming this IPR is fine? Thanks, p. Yes. - Kurt

1 0

ITS#6250
by masarati＠aero.polimi.it 21 Apr '10

21 Apr '10

Why is this ITS in software development, and open? Anyone intends to develop that feature, despite the discussion? p.

1 0

Re: (ITS#6151) Update cosine.schema to RFC 4524
by masarati＠aero.polimi.it 21 Apr '10

21 Apr '10

> Kurt Zeilenga wrote: >> >> On Jun 1, 2009, at 4:30 AM, michael(a)stroeder.com wrote: >>> Updated schema file cosine-update.schema attached. >> >> I note that differs are generally preferred, even where the file is >> mostly changed. This helps ensure changes that others might make to the >> file you started with are not lost. > > I thought about sending a diff but the file in this form is more > readable for easy review. Could someone please look at it whether that's > ok? > Another approach would be to have two schema files, one which only > contains the schema descriptions from RFC 4524 and one with the missing > schema descriptions from RFC 1274 with the latter obviously being > dependent on the former. I have one preliminary question for Kurt: since rfc4524 obsoletes rfc1274, should those schema items that were not brought forward be marked as OBSOLETE? If yes, then all schema could fit in one file. I'd like a clear way to separate valid from obsolete schema. The obsolete items should be available for backwards compatibility. As an alternative, I'd like to have a "slim" (without obsolete) and a complete version of the file. Could you please upload the file? Through the ITS attachments don't work too well. >>> IPR notice: >>> This patch file is derived from OpenLDAP Software and RFC 4524 and RFC >>> 1274. All of the modifications to OpenLDAP Software represented in the >>> attached file were developed by Michael Ströder <michael(a)stroeder.com>. >>> I have not assigned rights and/or interest in this work to any party. >> >> While this notice of origin is fine, you did not include a rights >> statement. > > I, Michael Ströder, hereby place the modified schema file cosine.schema > attached to ITS#6151 (and only these modifications) into the public > domain. Hence, these modifications may be freely used and/or > redistributed for any purpose with or without attribution and/or other > notice. Am I right in assuming this IPR is fine? Thanks, p.

1 0

Re: (ITS#6529) slapcat: bad configuration file!
by masarati＠aero.polimi.it 21 Apr '10

21 Apr '10

> Full_Name: SLava > Version: 2.4.21 > OS: Gentoo Linux > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (77.120.255.22) > > > My aim is to regularly backup openldap database, so I created a special > backup-user to do that. But while doing this command: "slapcat -f > /etc/openldap/slapd.conf -b "dc=my,dc=domain,dc=com" -l backup.ldif - I > get this > error: "/etc/openldap/slapd.conf: line 77: invalid path: Permission denied > slapcat: bad configuration file!". I watched my conf file and there is > "directory /var/lib/openldap-data/my-domain-com" string in line 77. I > looked for > permission rights and all seems to be properly. Don't know what to do... > > By the way, the same command under "root" works perfectly. Your file permissions are obviously inappropriate for the operation you're trying to perform. There is no evidence of an OpenLDAP bug; there is not even an evidence of an LDAP-related issue. This ITS will be closed. p.

1 0

Re: (ITS#6472) Syncrepl : loop problem with moddn on a new node
by masarati＠aero.polimi.it 21 Apr '10

21 Apr '10

This is a known issue. That patch is now obsoleted by the code that has been committed to HEAD and ported to re24 for release. Please test re24 out of the CVS, or apply the corresponding modifications to slapd/syncrepl.c to 2.4.21, and test. Please note that test018 has been modified to reproduce and test the problem you highlighted. If you run the new test18 with 2.4.21 it should consistently fail, while it passes with the new code. p. > Hello, > > Le 17/04/2010 22:00, > masarati(a)aero.polimi.it (par Internet) a écrit : >> A fix is in HEAD, please test > > I have tried the compilaltion of the source 2.4.21 with your patch, > "make test" failed on "test020-proxycache for bdb" with this error : > > >>>>> Starting test020-proxycache for bdb... > Starting master slapd on TCP/IP port 9011... > Using ldapsearch to check that master slapd is running... > Using ldapadd to populate the master directory... > Starting proxy cache on TCP/IP port 9012... > Using ldapsearch to check that proxy slapd is running... > Making queries on the proxy cache... > Query 1: filter:(sn=Jon) attrs:all (expect nothing) > Query 2: filter:(|(cn=*Jon*)(sn=Jon*)) attrs:cn sn title uid > Query 3: filter:(sn=Smith*) attrs:cn sn uid > ./scripts/test020-proxycache: line 173: 16714 Erreur de segmentation > $SLAPD -f $CONF2 -h $URI2 -d $LVL -d pcache > $LOG2 2>&1 > ldapsearch failed (255)! > ./scripts/test020-proxycache: line 177: kill: (16714) - Aucun processus > de ce type > >>>>> ./scripts/test020-proxycache failed for bdb (exit 255) > make[2]: *** [bdb-mod] Erreur 255 > make[2]: quittant le répertoire « > /root/openldap/2.4.21-its6472/compil-upstream/openldap-2.4.21/tests » > make[1]: *** [test] Erreur 2 > make[1]: quittant le répertoire « > /root/openldap/2.4.21-its6472/compil-upstream/openldap-2.4.21/tests » > make: *** [test] Erreur 2 > > I have used this compilation steps : > tar -zxvf openldap-2.4.21.tgz > > cd openldap-2.4.21 > > patch -p0 < ../pierangelo-masarati-2010-04-17-sync-rename.1.patch > patching file servers/slapd/syncrepl.c > Hunk #2 succeeded at 2554 (offset -10 lines). > Hunk #3 succeeded at 2891 (offset -10 lines). > Hunk #4 succeeded at 3026 (offset -10 lines). > > ./configure --enable-debug --enable-dynamic --enable-syslog > --enable-proctitle --enable-ipv6 --enable-local --enable-slapd > --enable-aci --enable-cleartext --enable-crypt --disable-lmpasswd > --enable-spasswd --enable-modules --enable-rewrite --enable-rlookups > --enable-slapi --enable-slp --enable-wrappers --enable-backends=mod > --enable-ldbm=no --disable-ndb --enable-overlays=mod --with-subdir=ldap > --with-cyrus-sasl --with-threads --with-tls=openssl --with-odbc=unixodbc > > make depend > > make > > make test > > regards, > Julien > >

1 0

(ITS#6529) slapcat: bad configuration file!
by slava.kargaltsev＠gmail.com 21 Apr '10

21 Apr '10

Full_Name: SLava Version: 2.4.21 OS: Gentoo Linux URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (77.120.255.22) My aim is to regularly backup openldap database, so I created a special backup-user to do that. But while doing this command: "slapcat -f /etc/openldap/slapd.conf -b "dc=my,dc=domain,dc=com" -l backup.ldif - I get this error: "/etc/openldap/slapd.conf: line 77: invalid path: Permission denied slapcat: bad configuration file!". I watched my conf file and there is "directory /var/lib/openldap-data/my-domain-com" string in line 77. I looked for permission rights and all seems to be properly. Don't know what to do... By the way, the same command under "root" works perfectly.

1 0

Re: ITS#6055
by masarati＠aero.polimi.it 20 Apr '10

20 Apr '10

> Can you give me the exact commands I need to put into the wiki, for a > user to go from a checkout of OpenLDAP, to a build with this module > installed just like all the others? Assuming one builds in the tree, - follow instructions for anonymous CVS checkout of HEAD branch <http://www.openldap.org/software/repo.html#AnonCVS> - cd contrib/slapd-modules/samba4 - edit Makefile if needed; as it is, it assumes you build in tree, and installs in /usr/local/libexec/openldap - make; make install - in slapd.conf: modulepath /usr/local/libexec/openldap moduleload rdnval.la # ... database hdb # ... overlay rdnval That's it. p.

1 0

Re: ITS#6055
by abartlet＠samba.org 20 Apr '10

20 Apr '10

--=-GJES2Ff4FHn/Nl+ftOBF Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Wed, 2010-04-21 at 05:42 +0200, masarati(a)aero.polimi.it wrote: > > My eventual goal is that folks using a Ubuntu or Fedora system would > > have Samba4 'just work' with the packaged OpenLDAP. I can of course > > lobby them to get their packages updated to build from contrib, but it'= s > > easier if it's just in there.=3D20 > > > > Similarly, when I ask folks to configure with 'OpenLDAP HEAD' in the > > short term, it is of course easier for me if everything is already in > > place.=3D20 > > > > But this is your project, not mine, and I am happy with whatever we can > > make work.=3D20 >=20 > Right now, along the lines illustrated by Howard, I've committed > everything to contrib/slapd-modules/samba4. You may need to tweak the > Makefile if you are not building in the source tree (as I usually do; the= n > adjust LDAP_BUILD to your build tree), and if you wish to install modules > in some specific place (prefix, exec_prefix, ldap_subdir). >=20 > My medium term objective would be to have: >=20 > - generally useful modules built-in (e.g. slapo-deref) >=20 > - Samba4-specific modules all in one contrib directory, possibly > harmonized and consolidated when possible in a single module, to ease > configuration and maintenance >=20 > The latter could then have a specific configure, if needed, so that > packagers could make and install them as easily as possible. In the > meanwhile, we should live with this interim solution. Time permitting, I > see no issue in maintaining that code, much like we already do with the > other modules. Can you give me the exact commands I need to put into the wiki, for a user to go from a checkout of OpenLDAP, to a build with this module installed just like all the others? Thanks, --=20 Andrew Bartlett http://samba.org/~abartlet/ Authentication Developer, Samba Team http://samba.org Samba Developer, Cisco Inc. --=-GJES2Ff4FHn/Nl+ftOBF Content-Type: application/pgp-signature; name="signature.asc" Content-Description: This is a digitally signed message part -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.10 (GNU/Linux) iD8DBQBLznxIz4A8Wyi0NrsRAl6mAJ4+rykBiTBAhn3ANiDgEfc8dG1OAgCghGeg ycx5bF3Vlb1Yx3OMwa3p13k= =XUh6 -----END PGP SIGNATURE----- --=-GJES2Ff4FHn/Nl+ftOBF--

1 0

Re: ITS#6055
by masarati＠aero.polimi.it 20 Apr '10

20 Apr '10

> My eventual goal is that folks using a Ubuntu or Fedora system would > have Samba4 'just work' with the packaged OpenLDAP. I can of course > lobby them to get their packages updated to build from contrib, but it's > easier if it's just in there.=20 > > Similarly, when I ask folks to configure with 'OpenLDAP HEAD' in the > short term, it is of course easier for me if everything is already in > place.=20 > > But this is your project, not mine, and I am happy with whatever we can > make work.=20 Right now, along the lines illustrated by Howard, I've committed everything to contrib/slapd-modules/samba4. You may need to tweak the Makefile if you are not building in the source tree (as I usually do; then adjust LDAP_BUILD to your build tree), and if you wish to install modules in some specific place (prefix, exec_prefix, ldap_subdir). My medium term objective would be to have: - generally useful modules built-in (e.g. slapo-deref) - Samba4-specific modules all in one contrib directory, possibly harmonized and consolidated when possible in a single module, to ease configuration and maintenance The latter could then have a specific configure, if needed, so that packagers could make and install them as easily as possible. In the meanwhile, we should live with this interim solution. Time permitting, I see no issue in maintaining that code, much like we already do with the other modules. p.

1 0

Re: ITS#6055
by abartlet＠samba.org 20 Apr '10

20 Apr '10

--=-dnOZfedjaeI8f/8PVlNm Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Wed, 2010-04-21 at 04:32 +0200, masarati(a)aero.polimi.it wrote: > > My only concern is that it be maintained, so that the OpenLDAP backend > > can be a supported part of Samba4 into the long term. (I know it's not > > been in good shape for the past while, but there is hope we can get it > > back on track). > > > > Do contrib modules come with this level of maintenance? >=20 > Inherently no, because they would not be configured/built along with the > rest of the package. Of course, as soon as users (possibly including > myself) notice issues, they would be maintained (see for example nssov). >=20 > The most straightforward way of having it routinely built is to place it > in slapd/overlays/; I guess this needs consensus from the rest of the > team. I'd vote in favor; please holler. My eventual goal is that folks using a Ubuntu or Fedora system would have Samba4 'just work' with the packaged OpenLDAP. I can of course lobby them to get their packages updated to build from contrib, but it's easier if it's just in there.=20 Similarly, when I ask folks to configure with 'OpenLDAP HEAD' in the short term, it is of course easier for me if everything is already in place.=20 But this is your project, not mine, and I am happy with whatever we can make work.=20 Andrew Bartlett --=20 Andrew Bartlett http://samba.org/~abartlet/ Authentication Developer, Samba Team http://samba.org Samba Developer, Cisco Inc. --=-dnOZfedjaeI8f/8PVlNm Content-Type: application/pgp-signature; name="signature.asc" Content-Description: This is a digitally signed message part -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.10 (GNU/Linux) iD8DBQBLzmzwz4A8Wyi0NrsRAomfAJ9J4b76Ujcu5fC3Yig3lgIBJ712ywCeOw3U fDuSKTOqEEfK1JEriBOcJ8g= =FSwh -----END PGP SIGNATURE----- --=-dnOZfedjaeI8f/8PVlNm--

1 0

Re: ITS#6055
by masarati＠aero.polimi.it 20 Apr '10

20 Apr '10

> masarati(a)aero.polimi.it wrote: >>> My only concern is that it be maintained, so that the OpenLDAP backend >>> can be a supported part of Samba4 into the long term. (I know it's not >>> been in good shape for the past while, but there is hope we can get it >>> back on track). >>> >>> Do contrib modules come with this level of maintenance? >> >> Inherently no, because they would not be configured/built along with the >> rest of the package. Of course, as soon as users (possibly including >> myself) notice issues, they would be maintained (see for example nssov). >> >> The most straightforward way of having it routinely built is to place it >> in slapd/overlays/; I guess this needs consensus from the rest of the >> team. I'd vote in favor; please holler. > > I think contrib is the right place for now. It seems to me that the > requirements here are still a moving target, so it's better in contrib. > (Contrib items are free to add new features independent of the rest of the > release cycle. Items in the main slapd/overlays are more constrained to > bugfixes-only within a release cycle.) Fair enough. I've started committing stuff to contrib/slapd-modules/samba4 p.

1 0

Re: ITS#6055
by hyc＠symas.com 20 Apr '10

20 Apr '10

masarati(a)aero.polimi.it wrote: >> My only concern is that it be maintained, so that the OpenLDAP backend >> can be a supported part of Samba4 into the long term. (I know it's not >> been in good shape for the past while, but there is hope we can get it >> back on track). >> >> Do contrib modules come with this level of maintenance? > > Inherently no, because they would not be configured/built along with the > rest of the package. Of course, as soon as users (possibly including > myself) notice issues, they would be maintained (see for example nssov). > > The most straightforward way of having it routinely built is to place it > in slapd/overlays/; I guess this needs consensus from the rest of the > team. I'd vote in favor; please holler. I think contrib is the right place for now. It seems to me that the requirements here are still a moving target, so it's better in contrib. (Contrib items are free to add new features independent of the rest of the release cycle. Items in the main slapd/overlays are more constrained to bugfixes-only within a release cycle.) -- -- 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#6055
by masarati＠aero.polimi.it 20 Apr '10

20 Apr '10

> My only concern is that it be maintained, so that the OpenLDAP backend > can be a supported part of Samba4 into the long term. (I know it's not > been in good shape for the past while, but there is hope we can get it > back on track). > > Do contrib modules come with this level of maintenance? Inherently no, because they would not be configured/built along with the rest of the package. Of course, as soon as users (possibly including myself) notice issues, they would be maintained (see for example nssov). The most straightforward way of having it routinely built is to place it in slapd/overlays/; I guess this needs consensus from the rest of the team. I'd vote in favor; please holler. p.

1 0

Re: ITS#6055
by abartlet＠samba.org 20 Apr '10

20 Apr '10

--=-plI2z6xrAOfHgQ7f8NT2 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Wed, 2010-04-21 at 03:44 +0200, masarati(a)aero.polimi.it wrote: > > On Tue, 2010-04-20 at 15:37 +0200, masarati(a)aero.polimi.it wrote: > >> > That's no problem at all. > >> > >> Good. This version explicitly check for instantiation as global, and > >> also > >> does some further sanity checks prior to startup. > >> > >> <ftp://ftp.openldap.org/incoming/pierangelo-masarati-2010-04-20-rdnval= .2.c> > >> > >> > It now just fails in the same was as without > >> > the patch. I'll mention it on openldap-technical if I can't get > >> > assistance on #ldap. > >> > >> Not quite clear what patch and what failure you refer to. Anyway, I'v= e > >> tested this version of the overlay as global (refuses to start) and on= a > >> database, either empty or populated, and it works as intended. Please > >> test and report. Thanks, p. > > > > It seems to be working well. When can I expect it to be in the tree? > > > > (I'll then require folks to use the current OpenLDAP CVS if they want t= o > > use the LDAP backend). >=20 > I can commit it in a minute. It's not 100% clear to me what's the most > appropriate location: slapd/overlays/ may not, as this looks like > something definitely specific to Samba4; probably, contrib/slapd-modules/ > is more appropriate. Perhaps, a contrib/slapd-modules/samba4/ would be > the most appropriate, along with future specific (i.e. not of general > usefulness) modules, as we did for the nssov module. >=20 > Comments? I mean, from others, not only from you :) My only concern is that it be maintained, so that the OpenLDAP backend can be a supported part of Samba4 into the long term. (I know it's not been in good shape for the past while, but there is hope we can get it back on track).=20 Do contrib modules come with this level of maintenance? Andrew Bartlett --=20 Andrew Bartlett http://samba.org/~abartlet/ Authentication Developer, Samba Team http://samba.org Samba Developer, Cisco Inc. --=-plI2z6xrAOfHgQ7f8NT2 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: This is a digitally signed message part -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.14 (GNU/Linux) iD8DBQBLzmHxz4A8Wyi0NrsRAlF3AKCXBqb/jzSgemy/GREWapoan6QkVwCgj1of Dmourk1xQiMAlvWFJocYuSQ= =rE8J -----END PGP SIGNATURE----- --=-plI2z6xrAOfHgQ7f8NT2--

1 0

Re: ITS#6055
by masarati＠aero.polimi.it 20 Apr '10

20 Apr '10

> On Tue, 2010-04-20 at 15:37 +0200, masarati(a)aero.polimi.it wrote: >> > That's no problem at all. >> >> Good. This version explicitly check for instantiation as global, and >> also >> does some further sanity checks prior to startup. >> >> <ftp://ftp.openldap.org/incoming/pierangelo-masarati-2010-04-20-rdnval.2.c> >> >> > It now just fails in the same was as without >> > the patch. I'll mention it on openldap-technical if I can't get >> > assistance on #ldap. >> >> Not quite clear what patch and what failure you refer to. Anyway, I've >> tested this version of the overlay as global (refuses to start) and on a >> database, either empty or populated, and it works as intended. Please >> test and report. Thanks, p. > > It seems to be working well. When can I expect it to be in the tree? > > (I'll then require folks to use the current OpenLDAP CVS if they want to > use the LDAP backend). I can commit it in a minute. It's not 100% clear to me what's the most appropriate location: slapd/overlays/ may not, as this looks like something definitely specific to Samba4; probably, contrib/slapd-modules/ is more appropriate. Perhaps, a contrib/slapd-modules/samba4/ would be the most appropriate, along with future specific (i.e. not of general usefulness) modules, as we did for the nssov module. Comments? I mean, from others, not only from you :) p.

1 0

Re: ITS#6055
by abartlet＠samba.org 20 Apr '10

20 Apr '10

--=-u2bdcYXWzM+LH/qgpb9q Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Tue, 2010-04-20 at 15:37 +0200, masarati(a)aero.polimi.it wrote: > > That's no problem at all. >=20 > Good. This version explicitly check for instantiation as global, and als= o > does some further sanity checks prior to startup. >=20 > <ftp://ftp.openldap.org/incoming/pierangelo-masarati-2010-04-20-rdnval.2.= c> >=20 > > It now just fails in the same was as without > > the patch. I'll mention it on openldap-technical if I can't get > > assistance on #ldap. >=20 > Not quite clear what patch and what failure you refer to. Anyway, I've > tested this version of the overlay as global (refuses to start) and on a > database, either empty or populated, and it works as intended. Please > test and report. Thanks, p. It seems to be working well. When can I expect it to be in the tree? (I'll then require folks to use the current OpenLDAP CVS if they want to use the LDAP backend). Andrew Bartlett --=20 Andrew Bartlett http://samba.org/~abartlet/ Authentication Developer, Samba Team http://samba.org Samba Developer, Cisco Inc. --=-u2bdcYXWzM+LH/qgpb9q Content-Type: application/pgp-signature; name="signature.asc" Content-Description: This is a digitally signed message part -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.14 (GNU/Linux) iD8DBQBLzldRz4A8Wyi0NrsRAgzTAJ4lv6P1wia2JLA7L2jPNkpgEvX3FwCgqyY0 jrguLg5MsW14D6wPlNThuko= =F1ZZ -----END PGP SIGNATURE----- --=-u2bdcYXWzM+LH/qgpb9q--

1 0

Re: (ITS#6165) Support offline modify (slapmodify) for cn=config
by quanah＠zimbra.com 20 Apr '10

20 Apr '10

--On Tuesday, April 20, 2010 4:03 AM +0000 masarati(a)aero.polimi.it wrote: > >> Very cute, but it fails the second portion of the requirement, which is >> command validation. ;) > > Here's a poor man's implementation. It *should* work for add & modify; > don't quite know how to delete entries; this also implies renaming. > probably, this would need be_tool_rename & be_tool_delete hooks. Cannot > compete in efficiency with slapadd; uses newly added ldifutil stuff > (ITS#6194). Please test. Cool, thanks! I'll give it a spin :) I believe delete support was added to back-ldif in HEAD, but I'm not sure how it works either. --Quanah -- Quanah Gibson-Mount Principal Software Engineer Zimbra, Inc -------------------- Zimbra :: the leader in open source messaging and collaboration

1 0

Re: ITS#6055
by masarati＠aero.polimi.it 20 Apr '10

20 Apr '10

> That's no problem at all. Good. This version explicitly check for instantiation as global, and also does some further sanity checks prior to startup. <ftp://ftp.openldap.org/incoming/pierangelo-masarati-2010-04-20-rdnval.2.c> > It now just fails in the same was as without > the patch. I'll mention it on openldap-technical if I can't get > assistance on #ldap. Not quite clear what patch and what failure you refer to. Anyway, I've tested this version of the overlay as global (refuses to start) and on a database, either empty or populated, and it works as intended. Please test and report. Thanks, p.

1 0

Re: ITS#6055
by abartlet＠samba.org 19 Apr '10

19 Apr '10

--=-8VSfpSadYnNS78ACEBD7 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Tue, 2010-04-20 at 07:11 +0200, masarati(a)aero.polimi.it wrote: > > On Mon, 2010-04-19 at 02:15 +0200, masarati(a)aero.polimi.it wrote: > >> Refactored rdnval.c available at > >> > >> <ftp://ftp.openldap.org/incoming/pierangelo-masarati-2010-04-18-rdnval= .c> > >> > >> attempts to repair the database at startup; useful when the overlay is > >> configured for an existing database. Please test. > > > > Sadly it segfaults on startup (we don't have the DB at startup - we > > expect the first operations to create them). >=20 > It's not that sad: this overlay is not intended to be used as global. Yo= u > should use it within any database you want the rdnvalue stored. I haven'= t > considered yet how hard it would be to allow it to be global, and if it's > worth. Since it needs to write operational attributes to the directory, > it may run into issues in case non-local storage databases are used, and > it'd definitely risk to suffer from authentication issues. Does it make > sense for you to add an instance in each database you need rndvalue for? That's no problem at all. It now just fails in the same was as without the patch. I'll mention it on openldap-technical if I can't get assistance on #ldap. Then, when I get past that, I'll get back to this! Andrew Bartlett --=20 Andrew Bartlett http://samba.org/~abartlet/ Authentication Developer, Samba Team http://samba.org Samba Developer, Cisco Inc. --=-8VSfpSadYnNS78ACEBD7 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: This is a digitally signed message part -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.14 (GNU/Linux) iD8DBQBLzU0sz4A8Wyi0NrsRAu1jAKCZMe8/cj55Qm+nFk1lZ0nRDnvQWACfXKCh jbVrJNvjzyeb5W6fOR49u58= =UMuS -----END PGP SIGNATURE----- --=-8VSfpSadYnNS78ACEBD7--

1 0

Re: ITS#6055
by masarati＠aero.polimi.it 19 Apr '10

19 Apr '10

> On Mon, 2010-04-19 at 02:15 +0200, masarati(a)aero.polimi.it wrote: >> Refactored rdnval.c available at >> >> <ftp://ftp.openldap.org/incoming/pierangelo-masarati-2010-04-18-rdnval.c> >> >> attempts to repair the database at startup; useful when the overlay is >> configured for an existing database. Please test. > > Sadly it segfaults on startup (we don't have the DB at startup - we > expect the first operations to create them). It's not that sad: this overlay is not intended to be used as global. You should use it within any database you want the rdnvalue stored. I haven't considered yet how hard it would be to allow it to be global, and if it's worth. Since it needs to write operational attributes to the directory, it may run into issues in case non-local storage databases are used, and it'd definitely risk to suffer from authentication issues. Does it make sense for you to add an instance in each database you need rndvalue for? p. > I produced the environment with Samba4 from master > (538a07a80aae72b57e5c23133158c7f214d0c27a) with the attached additional > patch > > TEST_LDAP=yes OPENLDAP_SLAPD=/usr/local/libexec/slapd make quicktest > > This ran: > '/usr/local/libexec/slapd' > '-F/scratch/samba-2/source4/st/dc/private/ldap/slapd.d' '-h' 'ldapi://% > 2Fscratch%2Fsamba-2%2Fsource4%2Fst%2Fdc%2Fprivate%2Fldap%2Fldapi' '-d0' > > and running that under gdb produced > > Program received signal SIGSEGV, Segmentation fault. > 0x000000000057ba54 in rdnval_repair (be=0x7fffffffdbe0) at rdnval.c:466 > 466 op->o_req_dn = op->o_bd->be_suffix[ 0 ]; > Missing separate debuginfos, use: debuginfo-install > glibc-2.11.90-17.x86_64 libgcc-4.4.3-12.fc13.x86_64 > libicu-4.2.1-7.fc12.x86_64 libicu-4.2.1-8.fc13.x86_64 libstdc > ++-4.4.3-12.fc13.x86_64 libtool-ltdl-2.2.6-18.fc12.x86_64 > libtool-ltdl-2.2.6-18.fc13.x86_64 libuuid-2.17.2-1.fc13.x86_64 > mysql-libs-5.1.45-2.fc13.x86_64 postgresql-libs-8.4.3-1.fc13.x86_64 > (gdb) p op > $1 = (Operation *) 0x7fffffffd4d0 > (gdb) p op->o_bd > $2 = (BackendDB *) 0x0 > (gdb) p *op > $3 = {o_hdr = 0x7fffffffd640, o_tag = 99, o_time = 1271737105, o_tincr = > 1, o_bd = 0x0, o_req_dn = {bv_len = 0, bv_val = 0x0}, o_req_ndn = > {bv_len = 0, bv_val = 0x0}, o_request = {oq_add = {rs_modlist = 0x0, > rs_e = 0x0}, oq_bind = { > rb_method = 0, rb_cred = {bv_len = 0, bv_val = 0x0}, rb_edn = > {bv_len = 0, bv_val = 0x0}, rb_ssf = 0, rb_mech = {bv_len = 0, bv_val = > 0x0}}, oq_compare = {rs_ava = 0x0}, oq_modify = {rs_mods = {rs_modlist = > 0x0, > rs_no_opattrs = 0 '\000'}, rs_increment = 0}, oq_modrdn = > {rs_mods = {rs_modlist = 0x0, rs_no_opattrs = 0 '\000'}, rs_deleteoldrdn > = 0, rs_newrdn = {bv_len = 0, bv_val = 0x0}, rs_nnewrdn = {bv_len = 0, > bv_val = 0x0}, > rs_newSup = 0x0, rs_nnewSup = 0x0}, oq_search = {rs_scope = 0, > rs_deref = 0, rs_slimit = 0, rs_tlimit = 0, rs_limit = 0x0, rs_attrsonly > = 0, rs_attrs = 0x0, rs_filter = 0x0, rs_filterstr = {bv_len = 0, bv_val > = 0x0}}, > oq_abandon = {rs_msgid = 0}, oq_cancel = {rs_msgid = 0}, oq_extended > = {rs_reqoid = {bv_len = 0, bv_val = 0x0}, rs_flags = 0, rs_reqdata = > 0x0}, oq_pwdexop = {rs_extended = {rs_reqoid = {bv_len = 0, bv_val = > 0x0}, rs_flags = 0, > rs_reqdata = 0x0}, rs_old = {bv_len = 0, bv_val = 0x0}, rs_new = > {bv_len = 0, bv_val = 0x0}, rs_mods = 0x0, rs_modtail = 0x0}}, o_abandon > = 0, o_cancel = 0, o_groups = 0x0, o_do_not_cache = 0 '\000', > o_is_auth_check = 0 '\000', > o_dont_replicate = 0 '\000', o_acl_priv = ACL_NONE, o_nocaching = 0 > '\000', o_delete_glue_parent = 0 '\000', o_no_schema_check = 0 '\000', > o_no_subordinate_glue = 0 '\000', o_ctrlflag = '\000' <repeats 31 > times>, > o_controls = 0x7fffffffd788, o_authz = {sai_method = 0, sai_mech = > {bv_len = 0, bv_val = 0x0}, sai_dn = {bv_len = 0, bv_val = 0x0}, sai_ndn > = {bv_len = 0, bv_val = 0x0}, sai_ssf = 0, sai_transport_ssf = 0, > sai_tls_ssf = 0, > sai_sasl_ssf = 0}, o_ber = 0x0, o_res_ber = 0x0, o_callback = 0x0, > o_ctrls = 0x0, o_csn = {bv_len = 0, bv_val = 0x0}, o_private = 0x0, > o_extra = {slh_first = 0x0}, o_next = {stqe_next = 0x0}} > (gdb) > > > -- > Andrew Bartlett http://samba.org/~abartlet/ > Authentication Developer, Samba Team http://samba.org > Samba Developer, Cisco Inc. > >

1 0

Re: ITS#6055
by abartlet＠samba.org 19 Apr '10

19 Apr '10

--=-JaZE3OeFLXsBmyVf+gjk Content-Type: multipart/mixed; boundary="=-5geAzHYesMuCPweb8j5I" --=-5geAzHYesMuCPweb8j5I Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Mon, 2010-04-19 at 02:15 +0200, masarati(a)aero.polimi.it wrote: > Refactored rdnval.c available at >=20 > <ftp://ftp.openldap.org/incoming/pierangelo-masarati-2010-04-18-rdnval.c> >=20 > attempts to repair the database at startup; useful when the overlay is > configured for an existing database. Please test. Sadly it segfaults on startup (we don't have the DB at startup - we expect the first operations to create them).=20 I produced the environment with Samba4 from master (538a07a80aae72b57e5c23133158c7f214d0c27a) with the attached additional patch TEST_LDAP=3Dyes OPENLDAP_SLAPD=3D/usr/local/libexec/slapd make quicktest This ran:=20 '/usr/local/libexec/slapd' '-F/scratch/samba-2/source4/st/dc/private/ldap/slapd.d' '-h' 'ldapi://% 2Fscratch%2Fsamba-2%2Fsource4%2Fst%2Fdc%2Fprivate%2Fldap%2Fldapi' '-d0' and running that under gdb produced Program received signal SIGSEGV, Segmentation fault. 0x000000000057ba54 in rdnval_repair (be=3D0x7fffffffdbe0) at rdnval.c:466 466 op->o_req_dn =3D op->o_bd->be_suffix[ 0 ]; Missing separate debuginfos, use: debuginfo-install glibc-2.11.90-17.x86_64 libgcc-4.4.3-12.fc13.x86_64 libicu-4.2.1-7.fc12.x86_64 libicu-4.2.1-8.fc13.x86_64 libstdc ++-4.4.3-12.fc13.x86_64 libtool-ltdl-2.2.6-18.fc12.x86_64 libtool-ltdl-2.2.6-18.fc13.x86_64 libuuid-2.17.2-1.fc13.x86_64 mysql-libs-5.1.45-2.fc13.x86_64 postgresql-libs-8.4.3-1.fc13.x86_64 (gdb) p op $1 =3D (Operation *) 0x7fffffffd4d0 (gdb) p op->o_bd $2 =3D (BackendDB *) 0x0 (gdb) p *op $3 =3D {o_hdr =3D 0x7fffffffd640, o_tag =3D 99, o_time =3D 1271737105, o_ti= ncr =3D 1, o_bd =3D 0x0, o_req_dn =3D {bv_len =3D 0, bv_val =3D 0x0}, o_req_ndn =3D {bv_len =3D 0, bv_val =3D 0x0}, o_request =3D {oq_add =3D {rs_modlist =3D 0= x0, rs_e =3D 0x0}, oq_bind =3D { rb_method =3D 0, rb_cred =3D {bv_len =3D 0, bv_val =3D 0x0}, rb_edn = =3D {bv_len =3D 0, bv_val =3D 0x0}, rb_ssf =3D 0, rb_mech =3D {bv_len =3D 0, bv= _val =3D 0x0}}, oq_compare =3D {rs_ava =3D 0x0}, oq_modify =3D {rs_mods =3D {rs_modl= ist =3D 0x0,=20 rs_no_opattrs =3D 0 '\000'}, rs_increment =3D 0}, oq_modrdn =3D {rs_mods =3D {rs_modlist =3D 0x0, rs_no_opattrs =3D 0 '\000'}, rs_deleteold= rdn =3D 0, rs_newrdn =3D {bv_len =3D 0, bv_val =3D 0x0}, rs_nnewrdn =3D {bv_len= =3D 0, bv_val =3D 0x0},=20 rs_newSup =3D 0x0, rs_nnewSup =3D 0x0}, oq_search =3D {rs_scope =3D 0= , rs_deref =3D 0, rs_slimit =3D 0, rs_tlimit =3D 0, rs_limit =3D 0x0, rs_attr= sonly =3D 0, rs_attrs =3D 0x0, rs_filter =3D 0x0, rs_filterstr =3D {bv_len =3D 0,= bv_val =3D 0x0}},=20 oq_abandon =3D {rs_msgid =3D 0}, oq_cancel =3D {rs_msgid =3D 0}, oq_ext= ended =3D {rs_reqoid =3D {bv_len =3D 0, bv_val =3D 0x0}, rs_flags =3D 0, rs_reqda= ta =3D 0x0}, oq_pwdexop =3D {rs_extended =3D {rs_reqoid =3D {bv_len =3D 0, bv_val = =3D 0x0}, rs_flags =3D 0,=20 rs_reqdata =3D 0x0}, rs_old =3D {bv_len =3D 0, bv_val =3D 0x0}, rs_= new =3D {bv_len =3D 0, bv_val =3D 0x0}, rs_mods =3D 0x0, rs_modtail =3D 0x0}}, o_ab= andon =3D 0, o_cancel =3D 0, o_groups =3D 0x0, o_do_not_cache =3D 0 '\000', o_is_auth_check =3D 0 '\000',=20 o_dont_replicate =3D 0 '\000', o_acl_priv =3D ACL_NONE, o_nocaching =3D 0 '\000', o_delete_glue_parent =3D 0 '\000', o_no_schema_check =3D 0 '\000', o_no_subordinate_glue =3D 0 '\000', o_ctrlflag =3D '\000' <repeats 31 times>,=20 o_controls =3D 0x7fffffffd788, o_authz =3D {sai_method =3D 0, sai_mech = =3D {bv_len =3D 0, bv_val =3D 0x0}, sai_dn =3D {bv_len =3D 0, bv_val =3D 0x0}, = sai_ndn =3D {bv_len =3D 0, bv_val =3D 0x0}, sai_ssf =3D 0, sai_transport_ssf =3D 0, sai_tls_ssf =3D 0,=20 sai_sasl_ssf =3D 0}, o_ber =3D 0x0, o_res_ber =3D 0x0, o_callback =3D 0= x0, o_ctrls =3D 0x0, o_csn =3D {bv_len =3D 0, bv_val =3D 0x0}, o_private =3D 0x= 0, o_extra =3D {slh_first =3D 0x0}, o_next =3D {stqe_next =3D 0x0}} (gdb)=20 --=20 Andrew Bartlett http://samba.org/~abartlet/ Authentication Developer, Samba Team http://samba.org Samba Developer, Cisco Inc. --=-5geAzHYesMuCPweb8j5I Content-Disposition: attachment; filename="add-rdnval.patch" Content-Transfer-Encoding: base64 Content-Type: text/x-patch; name="add-rdnval.patch"; charset="UTF-8" ZGlmZiAtLWdpdCBhL3NvdXJjZTQvc2V0dXAvc2xhcGQuY29uZiBiL3NvdXJjZTQvc2V0dXAvc2xh cGQuY29uZg0KaW5kZXggMDA3N2EyMi4uZTVmY2QwNiAxMDA2NDQNCi0tLSBhL3NvdXJjZTQvc2V0 dXAvc2xhcGQuY29uZg0KKysrIGIvc291cmNlNC9zZXR1cC9zbGFwZC5jb25mDQpAQCAtNDksNiAr NDksNyBAQCBkZWZhdWx0c2VhcmNoYmFzZSAke0RPTUFJTkROfQ0KIHJvb3RkbiBjbj1NYW5hZ2Vy DQogDQogb3ZlcmxheSBkZXJlZg0KK292ZXJsYXkgcmRudmFsDQogDQogJHtSRUZJTlRfQ09ORklH fQ0KIA0K --=-5geAzHYesMuCPweb8j5I-- --=-JaZE3OeFLXsBmyVf+gjk Content-Type: application/pgp-signature; name="signature.asc" Content-Description: This is a digitally signed message part -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.14 (GNU/Linux) iD8DBQBLzS/Pz4A8Wyi0NrsRApX6AJ0cG3n8qHNNN8TgvyQDIQD9wWTkXQCfbGgW rlvjjg0JC8ufGPwfp5709c8= =LCEs -----END PGP SIGNATURE----- --=-JaZE3OeFLXsBmyVf+gjk--

1 0

Re: (ITS#6165) Support offline modify (slapmodify) for cn=config
by masarati＠aero.polimi.it 19 Apr '10

19 Apr '10

> Very cute, but it fails the second portion of the requirement, which is > command validation. ;) Here's a poor man's implementation. It *should* work for add & modify; don't quite know how to delete entries; this also implies renaming. probably, this would need be_tool_rename & be_tool_delete hooks. Cannot compete in efficiency with slapadd; uses newly added ldifutil stuff (ITS#6194). Please test. p.

1 0

Re: (ITS#6165) Support offline modify (slapmodify) for cn=config
by quanah＠zimbra.com 19 Apr '10

19 Apr '10

--On Sunday, April 18, 2010 10:17 PM +0200 masarati(a)aero.polimi.it wrote: >> Full_Name: Quanah Gibson-Mount >> Version: 2.4.16 >> OS: NA >> URL: ftp://ftp.openldap.org/incoming/ >> Submission from: (NULL) (75.111.29.239) >> >> >> The slapmodify function already exists, but we've never built a tool >> around it. >> It would be useful to be able to have a utility that validates commands >> that >> users can use to modify cn=config while slapd is offline, rather than >> resorting >> to text editors that don't do validation of the changes being made. > > What about this? > > <ftp://ftp.openldap.org/incoming/slapmodify> Very cute, but it fails the second portion of the requirement, which is command validation. ;) --Quanah -- Quanah Gibson-Mount Principal Software Engineer Zimbra, Inc -------------------- Zimbra :: the leader in open source messaging and collaboration

1 0

ITS#5804
by masarati＠aero.polimi.it 19 Apr '10

19 Apr '10

The syntax added by ITS#5804 has never been documented. A patch to slapd.access(5) is about to be committed. p.

1 0

Re: (ITS#6482) slapcat doesn't continue with -c after the first corrupted database entry
by sysadmin＠htl-leonding.ac.at 18 Apr '10

18 Apr '10

I had restarted the server many times and it still worked, so I don't think the data was cached. Maybe the different method of access caused the difference, because the non-corrupted entries were still accessible via their id, so direct access worked. Could it be that slapcat doesn't correctly handle the case of invalid entries (entries with decoding errors)? Before this generic patch, I checked if the current entry had the id of the first invalid entry and in this case I incremented the ID by three, got the resulting entry and continued the export --> slapcat "skipped" the entries which it couldn't decode and then continued processing normally. Sorry that I can't test catastrophic recovery any more, because I have deleted the corrupted database, but I think that the main problem was that slapcat (and also other ldap-tools) wasn't able to decode the few damaged entries and didn't try to work around that problem.

1 0

ITS#6055
by masarati＠aero.polimi.it 18 Apr '10

18 Apr '10

Refactored rdnval.c available at <ftp://ftp.openldap.org/incoming/pierangelo-masarati-2010-04-18-rdnval.c> attempts to repair the database at startup; useful when the overlay is configured for an existing database. Please test. p.

1 0

Re: ITS#6017
by masarati＠aero.polimi.it 18 Apr '10

18 Apr '10

> > --=-Ga69RST1xu0P4I4ibWcD > Content-Type: text/plain; charset="UTF-8" > Content-Transfer-Encoding: quoted-printable > > On Sun, 2010-04-18 at 22:59 +0200, masarati(a)aero.polimi.it wrote: >> Still needed? Would the entryUUID of the parent stored in a >> "parentUUID" >> attribute fit? > > While we may change our minds again, Samba4 currently does not require > parentUUID to be stored. We now calculate it dynamically at runtime.=20 OK, thanks. In any case, while refactoring the rdnval.c (ITS#6055), I also implemented this <ftp://ftp.openldap.org/incoming/pierangelo-masarati-2010-04-18-pguid.c>. It keeps the parentUUID in sync, and repairs the database at startup (useful when the overlay is added on existing databases). p.

1 0

Re: ITS#6017
by abartlet＠samba.org 18 Apr '10

18 Apr '10

--=-Ga69RST1xu0P4I4ibWcD Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Sun, 2010-04-18 at 22:59 +0200, masarati(a)aero.polimi.it wrote: > Still needed? Would the entryUUID of the parent stored in a "parentUUID" > attribute fit? While we may change our minds again, Samba4 currently does not require parentUUID to be stored. We now calculate it dynamically at runtime.=20 Andrew Bartlett --=20 Andrew Bartlett http://samba.org/~abartlet/ Authentication Developer, Samba Team http://samba.org Samba Developer, Cisco Inc. --=-Ga69RST1xu0P4I4ibWcD Content-Type: application/pgp-signature; name="signature.asc" Content-Description: This is a digitally signed message part -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.14 (GNU/Linux) iD8DBQBLy49wz4A8Wyi0NrsRAgxwAJ96NWo95lkdiVV2WSpz9F/EdKaDfwCeO6Y3 +zF9u9EWpDvziGGAsOAyB8Q= =a/rb -----END PGP SIGNATURE----- --=-Ga69RST1xu0P4I4ibWcD--

1 0

ITS#6017
by masarati＠aero.polimi.it 18 Apr '10

18 Apr '10

Still needed? Would the entryUUID of the parent stored in a "parentUUID" attribute fit? p.

1 0

Re: (ITS#6165) Support offline modify (slapmodify) for cn=config
by masarati＠aero.polimi.it 18 Apr '10

18 Apr '10

> Full_Name: Quanah Gibson-Mount > Version: 2.4.16 > OS: NA > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (75.111.29.239) > > > The slapmodify function already exists, but we've never built a tool > around it. > It would be useful to be able to have a utility that validates commands > that > users can use to modify cn=config while slapd is offline, rather than > resorting > to text editors that don't do validation of the changes being made. What about this? <ftp://ftp.openldap.org/incoming/slapmodify> ;) p.

1 0

Re: (ITS#6482) slapcat doesn't continue with -c after the first corrupted database entry
by masarati＠aero.polimi.it 18 Apr '10

18 Apr '10

> The main point wasn't to tell you how important the data was, but that > tools like ldapsearch or other tools connecting to slapd using port 389 > still saw the good data. Because it was cached? Was this true after restarting the server? > And slapd never complained about a corrupted > database. As a result of that the data corruption was hidden (all other > programs worked, only three non-important entries were not accessible) > until I tried to use slapcat to export the data for an upgrade. > > Regarding "If the underlying database fails, there's little slapcat can > do.": As long as slapd sees the data, because it sends it in responses > to ldap-queries, the database hasn't failed so much, that slapcat > couldn't retrieve those data. Well, as I said in my previous message, slapcat is asking the underlying database to provide entries. If the underlying database fails, there's little slapcat can do. When the underlying database is back-bdb/hdb, slapd accesses data using indexes (dn/filter indexes mapped to IDs; the entry is then accessed using BDB in DB_SET mode), while slapcat accesses it using BDB cursors in DB_NEXT mode. Your approach of guessing IDs in the hope it works sounds a bit naive; I think in your case it worked by chance. Perhaps, a more "robust" approach would be to have back-bdb/hdb bi_tool_entry_next() to try to use itself the DB_SET approach instead of the DB_NEXT when the latter fails, with slapcat only knowing about the failure (so it can abort if -c is not passed). > Regarding "any garbage coming out of a corrupted database": slapd never > complained about the database being corrupted, it started without any > problems (except that three entries were unreadable), the entries after > those damaged entries made sense and weren't garbage. Berkeley's > db_tools claimed that there were some errors in the db, but slapd worked > without problems, only slapcat (and ldapdelete when trying to delete > those entries) complained that it couldn't decode them (which seems to > be rather a problem of the application layer than of the database layer, > but might have been caused by some little db corruption). When things go wrong, and specifically when this happens outside the code of our pertinence (in this case BDB), usually the best we can do is to rely on what any diagnostics/recovery capability they provide. Again, what worked for you may not work for another kind of corruption. Actually, going on might provide inconsistent data, something as bad as data loss. > I tried tools like "db_recover", but they didn't help, What about catastrophic recovery, using archived log files? > so I wanted to > extract the good ldap entries (using slapcat ...) to drop the database > and recreate it with the exported ldif, which failed because slapcat > stopped after the first failure (even with -c). Using the submitted > patch I was able to export all readable data into a ldif-file and to > recreate the database. > > summary: > * slapd never complained, ldapsearch listed the data, only few entries > were missing (because for them following was true: > > <= entry_decode: slap_str2undef_ad(object�..!p): > AttributeDescription > contains inappropriate characters) > > --> it seems that some attribute-values were damaged, but not the dn? > > * if ldapsearch is able to retrieve the data, slapcat should also do In general, I concur. However, slapd and tools access data in a slightly different manner, so this may not be trivial, and might require a redesign. > * I don't know how you want to recover an corrupted database. I tried to > recover all good entries and then to recreate it. And for that I wanted > to use slapcat (or is there any other tool for exporting data from the > ldap database than slapcat with option -c)? None I know about. > * maybe the way -c works shouldn't be changed, but there should be an > option for trying data recovery harder without having to patch openldap > (which is complicated for users of other distros not working directly > with the sources, but with precompiled packages) I'd take this as a feature request for redesigning the tools iteration procedure in order to try to overcome minor db corruptions. p.

1 0

Re: (ITS#6528) test020 with hdb: Query 15: ldapsearch failed (4)
by michael＠stroeder.com 18 Apr '10

18 Apr '10

Seems to work now with recent checkout. Ciao, Michael.

1 0

Re: (ITS#6225) GSSAPI support for client library (fixes)
by mimir＠samba.org 18 Apr '10

18 Apr '10

--LZvS9be/3tNcYl/X Content-Type: text/plain; charset=iso-8859-2 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Howard, 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 > author of this code, could you also take a look at #6091 and #6093? I'm really sorry but after I looked at current code in HEAD and I thought I= liked it (the actual issue was fixed), following with this thread completely went of= f my radar. I've found it while looking through my mailbox. The last chunk of this its' patch still applies though. It's a minor thing = but fixes potential memory leak. I can open a separate ITS for it if you like. As for the other patches - #6091 is (was) convenient but not absolutely nec= essary and #6093 is interesting but I'm not sure if it isn's a bit too much. If yo= u're connecting invalid (from kerberos point of view) hostname then, well, find out what's = the correct=20 hostname first. This its # can be closed of course. cheers, --=20 Rafal Szczesniak Samba Team member http://www.samba.org Likewise Software http://www.likewise.com --LZvS9be/3tNcYl/X Content-Type: application/pgp-signature; name="signature.asc" Content-Description: Digital signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.10 (GNU/Linux) iD8DBQFLy1e3Hvdfyv3qiKkRAk7ZAJ0VPkzc89VAxXh/AF4EZVCJTvS/fgCfeZK7 TULoTjp8aXQkK0oGZNShxsY= =zucU -----END PGP SIGNATURE----- --LZvS9be/3tNcYl/X--

1 0

Re: (ITS#6482) slapcat doesn't continue with -c after the first corrupted database entry
by sysadmin＠htl-leonding.ac.at 18 Apr '10

18 Apr '10

This is a multi-part message in MIME format. --------------020204070007000004050507 Content-Type: text/plain; charset=ISO-8859-15; format=flowed Content-Transfer-Encoding: 7bit The main point wasn't to tell you how important the data was, but that tools like ldapsearch or other tools connecting to slapd using port 389 still saw the good data. And slapd never complained about a corrupted database. As a result of that the data corruption was hidden (all other programs worked, only three non-important entries were not accessible) until I tried to use slapcat to export the data for an upgrade. Regarding "If the underlying database fails, there's little slapcat can do.": As long as slapd sees the data, because it sends it in responses to ldap-queries, the database hasn't failed so much, that slapcat couldn't retrieve those data. Regarding "any garbage coming out of a corrupted database": slapd never complained about the database being corrupted, it started without any problems (except that three entries were unreadable), the entries after those damaged entries made sense and weren't garbage. Berkeley's db_tools claimed that there were some errors in the db, but slapd worked without problems, only slapcat (and ldapdelete when trying to delete those entries) complained that it couldn't decode them (which seems to be rather a problem of the application layer than of the database layer, but might have been caused by some little db corruption). I tried tools like "db_recover", but they didn't help, so I wanted to extract the good ldap entries (using slapcat ...) to drop the database and recreate it with the exported ldif, which failed because slapcat stopped after the first failure (even with -c). Using the submitted patch I was able to export all readable data into a ldif-file and to recreate the database. summary: * slapd never complained, ldapsearch listed the data, only few entries were missing (because for them following was true: <= entry_decode: slap_str2undef_ad(object�..!p): AttributeDescription contains inappropriate characters) --> it seems that some attribute-values were damaged, but not the dn? * if ldapsearch is able to retrieve the data, slapcat should also do * I don't know how you want to recover an corrupted database. I tried to recover all good entries and then to recreate it. And for that I wanted to use slapcat (or is there any other tool for exporting data from the ldap database than slapcat with option -c)? * maybe the way -c works shouldn't be changed, but there should be an option for trying data recovery harder without having to patch openldap (which is complicated for users of other distros not working directly with the sources, but with precompiled packages) --------------020204070007000004050507 Content-Type: text/html; charset=ISO-8859-15 Content-Transfer-Encoding: 7bit <!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN"> <html> <head> <meta http-equiv="content-type" content="text/html; charset=ISO-8859-15"> </head> <body bgcolor="#ffffff" text="#000000"> The main point wasn't to tell you how important the data was, but that tools like ldapsearch or other tools connecting to slapd using port 389 still saw the good data. And slapd never complained about a corrupted database. As a result of that the data corruption was hidden (all other programs worked, only three non-important entries were not accessible) until I tried to use slapcat to export the data for an upgrade. Regarding "If the underlying database fails, there's little slapcat can do.": As long as slapd sees the data, because it sends it in responses to ldap-queries, the database hasn't failed so much, that slapcat couldn't retrieve those data. Regarding "any garbage coming out of a corrupted database": slapd never complained about the database being corrupted, it started without any problems (except that three entries were unreadable), the entries after those damaged entries made sense and weren't garbage. Berkeley's db_tools claimed that there were some errors in the db, but slapd worked without problems, only slapcat (and ldapdelete when trying to delete those entries) complained that it couldn't decode them (which seems to be rather a problem of the application layer than of the database layer, but might have been caused by some little db corruption). I tried tools like "db_recover", but they didn't help, so I wanted to extract the good ldap entries (using slapcat ...) to drop the database and recreate it with the exported ldif, which failed because slapcat stopped after the first failure (even with -c). Using the submitted patch I was able to export all readable data into a ldif-file and to recreate the database. summary: * slapd never complained, ldapsearch listed the data, only few entries were missing (because for them following was true: <pre><= entry_decode: slap_str2undef_ad(object&#65533;..!p): AttributeDescription contains inappropriate characters) --> it seems that some attribute-values were damaged, but not the dn? </pre> * if ldapsearch is able to retrieve the data, slapcat should also do * I don't know how you want to recover an corrupted database. I tried to recover all good entries and then to recreate it. And for that I wanted to use slapcat (or is there any other tool for exporting data from the ldap database than slapcat with option -c)? * maybe the way -c works shouldn't be changed, but there should be an option for trying data recovery harder without having to patch openldap (which is complicated for users of other distros not working directly with the sources, but with precompiled packages) </body> </html> --------------020204070007000004050507--

1 0

Re: (ITS#6482) slapcat doesn't continue with -c after the first corrupted database entry
by masarati＠aero.polimi.it 18 Apr '10

18 Apr '10

> Maybe I haven't described the situation correctly: > The database was used for managing user accounts (via nss_ldap). The > database seems to had three corrupted entries in the middle (good > entries were following after that). The command "getent passwd" i.e. > still listed all users except those three with corrupted entries, but > export via slapcat and reimport of the data would have led to loss of > many more accounts. Lossing half your data is not the expected behaviour > for a tool, which should list all the existing (or at least somehow > readable) database entries. I'm not questioning the importance of the data slapcat couldn't export. > The important point is that slapcat cancelled the export at the first > corrupted database entry and didn't even try to get to the non-corrupted > database entries (which were seen by the other LDAP-tools). This is not correct. Slapcat tries. It asks the underlying backend to provide the subsequent entries. If the underlying database fails, there's little slapcat can do. > It didn't > even try in "continuation" mode, so there was no way to rescue all the > readable data via slapcat. I've tested slapcat in continuation mode by forcibly having be_entry_get() return NULL, and it works as expected: it continues to the next one, as soon as be_entry_next() is able to return a valid ID. if it can't, then anything you'd get from be_entry_next() with an arbitrary ID is unreliable. > For slapcat all entries occuring after the > first corrupt entry were lost. As the remaining good entries were still > accessible and visible via the other tools communicating with slapd via > the port 389, the expected behaviour for slapcat would have been to try > harder to ignore the damaged entries and to recover the remaining > readable entries after them. Maybe slapcat really failed to extract the > next entries id, but in "continuation"-mode it should try hard to > workaround any errors caused by non-readable entries. In case of an > non-readable entry my patch continues stupidly incrementing the id by 1 > and trying to read that entry. As soon as it can extract an entry, it > continues processing. If by "try hard" you mean that any garbage coming out of a corrupted database would be fine for you, then you can fix your patch by having it stop when id == NOID. To me, it sounds a bit too hard. What about recovering the database first, did you try? p.

1 0

Re: (ITS#6528) test020 with hdb: Query 15: ldapsearch failed (4)
by masarati＠aero.polimi.it 18 Apr '10

18 Apr '10

Thanks, I'm working at this. p. > Full_Name: Michael Ströder > Version: HEAD > OS: > URL: > Submission from: (NULL) (84.163.121.239) > > > Note: It seems to work with back-bdb > > $ ./run -b hdb test020 > Cleaning up test run directory leftover from previous run. > Running ./scripts/test020-proxycache for hdb... > Starting master slapd on TCP/IP port 9011... > Using ldapsearch to check that master slapd is running... > Using ldapadd to populate the master directory... > Starting proxy cache on TCP/IP port 9012... > Using ldapsearch to check that proxy slapd is running... > Making queries on the proxy cache... > Query 1: filter:(sn=Jon) attrs:all (expect nothing) > Query 2: filter:(|(cn=*Jon*)(sn=Jon*)) attrs:cn sn title uid > Query 3: filter:(sn=Smith*) attrs:cn sn uid > Query 4: filter:(sn=Doe*) attrs:cn sn title uid > Query 5: filter:(uid=johnd) attrs:mail postaladdress telephonenumber cn > uid > Query 6: filter:(mail=*@mail.alumni.example.com) attrs:cn sn title uid > Query 7: filter:(mail=*) attrs:cn sn title uid > Query 8: filter:(mail=*example.com) attrs:cn sn title uid > ldapsearch failed (4) > Query 9: filter:(uid=b*) attrs:mail > ldapsearch failed (4) > Query 1 not cacheable > Query 2 cacheable > Query 3 cacheable > Query 4 cacheable > Query 5 cacheable > Query 6 cacheable > Query 7 not cacheable > Query 8 cacheable > Query 9 cacheable > Successfully verified cacheability > Query 10: filter:(|(cn=*Jones)(sn=Jones)) attrs:cn sn title uid > Query 11: filter:(sn=Smith) attrs:cn sn title uid > Query 12: filter:(uid=bjorn) attrs:mail postaladdress telephonenumber cn > uid > Query 13: filter:(mail=jaj@mail.alumni.example.com) attrs:cn sn title uid > Query 14: filter:(mail=*example.com) attrs:cn sn title uid > ldapsearch failed (4) > Query 15: filter:(uid=b*) attrs:mail > ldapsearch failed (4) > Query 10 answerable > Query 11 answerable > Query 12 answerable > Query 13 not answerable > Query 14 not answerable > Query 15 answerable > Successfully verified answerability > Filtering ldapsearch results... > Filtering original ldif... > Comparing filter output... > Comparison failed > > >

1 0

Re: (ITS#6527) Build errors in function � slap_cf_aux_table_unparse�
by masarati＠aero.polimi.it 18 Apr '10

18 Apr '10

Thanks, Quanah is working at this. p. > Full_Name: Michael Ströder > Version: RE24 > OS: openSUSE 11.2 Linux > URL: > Submission from: (NULL) (84.163.121.239) > > > HEAD builds and make test works. > > RE24 fails to build since recent check-ins (anon CVS) yesterday: > > make[3]: Leaving directory > `/usr/src/michael/openldap/OPENLDAP_REL_ENG_2_4/openldap/servers/slapd/overlays' > ../../build/mkversion -v "2.4.X" -s -n Versionstr slapd > version.c > cc -g -O2 -DSLAP_SCHEMA_EXPOSE -I../../include -I. -I./slapi -I. > -I../../include > -c -o main.o main.c > cc -g -O2 -DSLAP_SCHEMA_EXPOSE -I../../include -I. -I./slapi -I. > -I../../include > -c -o globals.o globals.c > cc -g -O2 -DSLAP_SCHEMA_EXPOSE -I../../include -I. -I./slapi -I. > -I../../include > -c -o bconfig.o bconfig.c > cc -g -O2 -DSLAP_SCHEMA_EXPOSE -I../../include -I. -I./slapi -I. > -I../../include > -c -o config.o config.c > config.c: In function �slap_cf_aux_table_unparse�: > config.c:1575: error: duplicate case value > config.c:1547: error: previously used here > make[2]: *** [config.o] Error 1 > make[2]: Leaving directory > `/usr/src/michael/openldap/OPENLDAP_REL_ENG_2_4/openldap/servers/slapd' > make[1]: *** [all-common] Error 1 > make[1]: Leaving directory > `/usr/src/michael/openldap/OPENLDAP_REL_ENG_2_4/openldap/servers' > make: *** [all-common] Error 1 > > >

1 0

(ITS#6528) test020 with hdb: Query 15: ldapsearch failed (4)
by michael＠stroeder.com 18 Apr '10

18 Apr '10

Full_Name: Michael Ströder Version: HEAD OS: URL: Submission from: (NULL) (84.163.121.239) Note: It seems to work with back-bdb $ ./run -b hdb test020 Cleaning up test run directory leftover from previous run. Running ./scripts/test020-proxycache for hdb... Starting master slapd on TCP/IP port 9011... Using ldapsearch to check that master slapd is running... Using ldapadd to populate the master directory... Starting proxy cache on TCP/IP port 9012... Using ldapsearch to check that proxy slapd is running... Making queries on the proxy cache... Query 1: filter:(sn=Jon) attrs:all (expect nothing) Query 2: filter:(|(cn=*Jon*)(sn=Jon*)) attrs:cn sn title uid Query 3: filter:(sn=Smith*) attrs:cn sn uid Query 4: filter:(sn=Doe*) attrs:cn sn title uid Query 5: filter:(uid=johnd) attrs:mail postaladdress telephonenumber cn uid Query 6: filter:(mail=*@mail.alumni.example.com) attrs:cn sn title uid Query 7: filter:(mail=*) attrs:cn sn title uid Query 8: filter:(mail=*example.com) attrs:cn sn title uid ldapsearch failed (4) Query 9: filter:(uid=b*) attrs:mail ldapsearch failed (4) Query 1 not cacheable Query 2 cacheable Query 3 cacheable Query 4 cacheable Query 5 cacheable Query 6 cacheable Query 7 not cacheable Query 8 cacheable Query 9 cacheable Successfully verified cacheability Query 10: filter:(|(cn=*Jones)(sn=Jones)) attrs:cn sn title uid Query 11: filter:(sn=Smith) attrs:cn sn title uid Query 12: filter:(uid=bjorn) attrs:mail postaladdress telephonenumber cn uid Query 13: filter:(mail=jaj@mail.alumni.example.com) attrs:cn sn title uid Query 14: filter:(mail=*example.com) attrs:cn sn title uid ldapsearch failed (4) Query 15: filter:(uid=b*) attrs:mail ldapsearch failed (4) Query 10 answerable Query 11 answerable Query 12 answerable Query 13 not answerable Query 14 not answerable Query 15 answerable Successfully verified answerability Filtering ldapsearch results... Filtering original ldif... Comparing filter output... Comparison failed

1 0

Re: (ITS#6482) slapcat doesn't continue with -c after the first corrupted database entry
by sysadmin＠htl-leonding.ac.at 18 Apr '10

18 Apr '10

Maybe I haven't described the situation correctly: The database was used for managing user accounts (via nss_ldap). The database seems to had three corrupted entries in the middle (good entries were following after that). The command "getent passwd" i.e. still listed all users except those three with corrupted entries, but export via slapcat and reimport of the data would have led to loss of many more accounts. Lossing half your data is not the expected behaviour for a tool, which should list all the existing (or at least somehow readable) database entries. The important point is that slapcat cancelled the export at the first corrupted database entry and didn't even try to get to the non-corrupted database entries (which were seen by the other LDAP-tools). It didn't even try in "continuation" mode, so there was no way to rescue all the readable data via slapcat. For slapcat all entries occuring after the first corrupt entry were lost. As the remaining good entries were still accessible and visible via the other tools communicating with slapd via the port 389, the expected behaviour for slapcat would have been to try harder to ignore the damaged entries and to recover the remaining readable entries after them. Maybe slapcat really failed to extract the next entries id, but in "continuation"-mode it should try hard to workaround any errors caused by non-readable entries. In case of an non-readable entry my patch continues stupidly incrementing the id by 1 and trying to read that entry. As soon as it can extract an entry, it continues processing.

1 0

(ITS#6527) Build errors in function �slap_cf_aux_table_unparse�
by michael＠stroeder.com 18 Apr '10

18 Apr '10

Full_Name: Michael Ströder Version: RE24 OS: openSUSE 11.2 Linux URL: Submission from: (NULL) (84.163.121.239) HEAD builds and make test works. RE24 fails to build since recent check-ins (anon CVS) yesterday: make[3]: Leaving directory `/usr/src/michael/openldap/OPENLDAP_REL_ENG_2_4/openldap/servers/slapd/overlays' ../../build/mkversion -v "2.4.X" -s -n Versionstr slapd > version.c cc -g -O2 -DSLAP_SCHEMA_EXPOSE -I../../include -I. -I./slapi -I. -I../../include -c -o main.o main.c cc -g -O2 -DSLAP_SCHEMA_EXPOSE -I../../include -I. -I./slapi -I. -I../../include -c -o globals.o globals.c cc -g -O2 -DSLAP_SCHEMA_EXPOSE -I../../include -I. -I./slapi -I. -I../../include -c -o bconfig.o bconfig.c cc -g -O2 -DSLAP_SCHEMA_EXPOSE -I../../include -I. -I./slapi -I. -I../../include -c -o config.o config.c config.c: In function slap_cf_aux_table_unparse: config.c:1575: error: duplicate case value config.c:1547: error: previously used here make[2]: *** [config.o] Error 1 make[2]: Leaving directory `/usr/src/michael/openldap/OPENLDAP_REL_ENG_2_4/openldap/servers/slapd' make[1]: *** [all-common] Error 1 make[1]: Leaving directory `/usr/src/michael/openldap/OPENLDAP_REL_ENG_2_4/openldap/servers' make: *** [all-common] Error 1

1 0

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

openldap-bugs