- openldap-bugs - openldap.org

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

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

openldap-bugs