- openldap-bugs - openldap.org

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

30 Apr '10

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

1 0

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

29 Apr '10

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

1 0

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

29 Apr '10

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

1 0

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

29 Apr '10

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

1 0

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

29 Apr '10

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

1 0

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

29 Apr '10

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

1 0

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

29 Apr '10

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

1 0

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 27 Apr '10

27 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 25 Apr '10

25 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 25 Apr '10

25 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 25 Apr '10

25 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 23 Apr '10

23 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

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

openldap-bugs