Well, IMHO this is a really bad excuse and I was not expecting to hear that in this list.
Klements,
You can get slapd source packages and change the flags as you want. Serious distribution packages as Debian packages shouldn't be discouraged by OpenLDAP dev team as I'm seeing here. Debian packages policy are very strong and help a lot stable environments to be bug-free from recent less stable versions. I use Debian as a protection from that too early versions who can potentially threat my production environment and I was very successful with Debian packages in this attempt.
You can also look for support on Debian IRC channels and lists.
On Tue, Mar 16, 2010 at 3:05 PM, Quanah Gibson-Mount quanah@zimbra.comwrote:
--On Tuesday, March 16, 2010 8:34 AM +0100 Klemens Kittan < kittan@cs.uni-potsdam.de> wrote:
Sounds like you're mostly on the right track, but I didn't hear mention
of compiling with a suitable OPENLDAP_FD_SETSIZE. Are your CPPFLAGS set accordingly?
I use the OpenLDAP version from the distribution (Debian 5.0.4),
There's your first mistake.
http://www.openldap.org/faq/data/cache/1456.html
--Quanah
--
Quanah Gibson-Mount Principal Software Engineer Zimbra, Inc
Zimbra :: the leader in open source messaging and collaboration
--On Tuesday, March 16, 2010 7:21 PM -0300 Matheus Morais matheus.morais@gmail.com wrote:
Well, IMHO this is a really bad excuse and I was not expecting to hear that in this list.
Klements,
You can get slapd source packages and change the flags as you want. Serious distribution packages as Debian packages shouldn't be discouraged by OpenLDAP dev team as I'm seeing here. Debian packages policy are very strong and help a lot stable environments to be bug-free from recent less stable versions. I use Debian as a protection from that too early versions who can potentially threat my production environment and I was very successful with Debian packages in this attempt.
You can also look for support on Debian IRC channels and lists.
Hi Matheus,
I'll note that article was written by one of the Debian openldap package maintainers. And it is quite correct that anyone wanting to run a *stable* OpenLDAP production environment should most definitely *not* use the ones provided by most Linux OS providers, *particularly* Debian/Ubuntu. The reasons why this is the case have been hashed over many, many times. Particularly, the use of GnuTLS which is horribly broken being one of the major reasons. The fact that they are not kept up to date with current stable releases is another.
--Quanah
--
Quanah Gibson-Mount Principal Software Engineer Zimbra, Inc -------------------- Zimbra :: the leader in open source messaging and collaboration
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
I'll be honest: while LDAP does what I need it to, and is the only tool I've found that works well for my purposes, this is why I'm constantly looking for another option. Just about every request for help I see come across this list gets an initial response of "Oh, well, you're one or two minor versions out of date. You need to update to the newest version before we can help you."
Software that unstable is not, in my view, really suited to a production environment. If the OpenLDAP developers -- who, overall, do an excellent job -- can't come up with a stable release every six months or so, there's a problem. If there are so many major flaws that running a month old version means it's unsupportable, that's an even bigger problem.
I've been following the list for around a year, and I understand the difficulties involved in supporting old versions, but the simple fact is, most of us don't have time to custom compile all our server software. My Ubuntu-default installs of Apache, postfix, SSH, and just about everything else work fine and can be supported by their developers. It's only LDAP (and a few things in beta) that absolutely have to run the newest version at all times. I chose to accept a limited feature-set and bullied GnuTLS into working "well enough" for our limited LDAP environment, but if I ever find an alternative, I'll be moving away from LDAP to whatever that is.
And please -- nobody take this as an attack. I really do respect the OpenLDAP development team, and the people on this list do their best to help everyone, even those of us using old versions. I just question the long-term viability of a system that needs to be recompiled as often as OpenLDAP seems to.
- -Alex McKenzie
Quanah Gibson-Mount wrote:
--On Tuesday, March 16, 2010 7:21 PM -0300 Matheus Morais matheus.morais@gmail.com wrote:
Well, IMHO this is a really bad excuse and I was not expecting to hear that in this list.
Klements,
You can get slapd source packages and change the flags as you want. Serious distribution packages as Debian packages shouldn't be discouraged by OpenLDAP dev team as I'm seeing here. Debian packages policy are very strong and help a lot stable environments to be bug-free from recent less stable versions. I use Debian as a protection from that too early versions who can potentially threat my production environment and I was very successful with Debian packages in this attempt.
You can also look for support on Debian IRC channels and lists.
Hi Matheus,
I'll note that article was written by one of the Debian openldap package maintainers. And it is quite correct that anyone wanting to run a *stable* OpenLDAP production environment should most definitely *not* use the ones provided by most Linux OS providers, *particularly* Debian/Ubuntu. The reasons why this is the case have been hashed over many, many times. Particularly, the use of GnuTLS which is horribly broken being one of the major reasons. The fact that they are not kept up to date with current stable releases is another.
--Quanah
--
Quanah Gibson-Mount Principal Software Engineer Zimbra, Inc
Zimbra :: the leader in open source messaging and collaboration
Hi Alex,
I think this falls into the "you get what you pay for..." camp. On the support page, they list a number of companies that provide technical support services for OpenLDAP. If the price for stability is not worth engaging one of them, then you will need to keep your software up to a revision level that the developers will support. I am curious what constant issues/bugs are affecting you. Once we have a working version, it keeps on working and there is no need to constantly rebuild your software as new releases come out. The other option that we use here is the 389 Directory server, which might be an option for you to consider.
Regards, Ken
On Thu, Mar 18, 2010 at 08:46:38AM -0400, Alex McKenzie wrote:
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
I'll be honest: while LDAP does what I need it to, and is the only tool I've found that works well for my purposes, this is why I'm constantly looking for another option. Just about every request for help I see come across this list gets an initial response of "Oh, well, you're one or two minor versions out of date. You need to update to the newest version before we can help you."
Software that unstable is not, in my view, really suited to a production environment. If the OpenLDAP developers -- who, overall, do an excellent job -- can't come up with a stable release every six months or so, there's a problem. If there are so many major flaws that running a month old version means it's unsupportable, that's an even bigger problem.
I've been following the list for around a year, and I understand the difficulties involved in supporting old versions, but the simple fact is, most of us don't have time to custom compile all our server software. My Ubuntu-default installs of Apache, postfix, SSH, and just about everything else work fine and can be supported by their developers. It's only LDAP (and a few things in beta) that absolutely have to run the newest version at all times. I chose to accept a limited feature-set and bullied GnuTLS into working "well enough" for our limited LDAP environment, but if I ever find an alternative, I'll be moving away from LDAP to whatever that is.
And please -- nobody take this as an attack. I really do respect the OpenLDAP development team, and the people on this list do their best to help everyone, even those of us using old versions. I just question the long-term viability of a system that needs to be recompiled as often as OpenLDAP seems to.
- -Alex McKenzie
Quanah Gibson-Mount wrote:
--On Tuesday, March 16, 2010 7:21 PM -0300 Matheus Morais matheus.morais@gmail.com wrote:
Well, IMHO this is a really bad excuse and I was not expecting to hear that in this list.
Klements,
You can get slapd source packages and change the flags as you want. Serious distribution packages as Debian packages shouldn't be discouraged by OpenLDAP dev team as I'm seeing here. Debian packages policy are very strong and help a lot stable environments to be bug-free from recent less stable versions. I use Debian as a protection from that too early versions who can potentially threat my production environment and I was very successful with Debian packages in this attempt.
You can also look for support on Debian IRC channels and lists.
Hi Matheus,
I'll note that article was written by one of the Debian openldap package maintainers. And it is quite correct that anyone wanting to run a *stable* OpenLDAP production environment should most definitely *not* use the ones provided by most Linux OS providers, *particularly* Debian/Ubuntu. The reasons why this is the case have been hashed over many, many times. Particularly, the use of GnuTLS which is horribly broken being one of the major reasons. The fact that they are not kept up to date with current stable releases is another.
--Quanah
--
Quanah Gibson-Mount Principal Software Engineer Zimbra, Inc
Zimbra :: the leader in open source messaging and collaboration
-----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.8 (Darwin) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/
iEYEARECAAYFAkuiIK4ACgkQWFYfIucpZ2O70QCfYpCKXvpBy3jYu9q55AW3ER/Z OVsAnjWwqDeshYgYUiwCmdAZInwzhcLD =ygBw -----END PGP SIGNATURE-----
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
Right. But how much do I pay for Apache? How much do I pay for postfix, sendmail, qmail, or exim? How about MySQL, or Postgresql? The real issue, for me, is the version cycle. All of those packages have minor updates fairly regularly, but none of them change major functionality, and all of them provide packages to various linux distributions, including Debian and Ubuntu. And most of them have decent free support, at least via the sort of mailing list we're on now, that includes those distribution packages. They may well tell you you need to install the newest debian package, but they'll almost never tell you that you have to recompile for basic functionality.
Again: this is a decision the development team made. It's not because it's free, it's because they chose one particular mode of development. I'm not saying it's wrong, necessarily, but it drives a lot of people -- like me -- to look for alternatives. Right now, the system pretty much works, despite the fact that I'm using and older version (2.4.7-6Ubuntu3). The problem, for me, is that if I write to this list with a problem, I'll be told no one can help me unless I rebuild from scratch. So far, it's been easier to work around problems or look for help in the Ubuntu forums.
You're right that I don't need to keep rebuilding as new versions come out, but that's only as long as I don't want to ask for help: if I need to change how something works, or add functionality, even if it's present in the version I have installed, I have to upgrade.
Anyway: this is really all pretty much irrelevant to the list as a whole. I just wanted to make the point that this is an issue, and perhaps something the devels should think about. If they decide to continue on the way they have... well, that's their option. It's their project, and they can do what they want with it. But they should at least be aware that people are concerned about the current methods.
- -Alex
Kenneth Marshall wrote:
Hi Alex,
I think this falls into the "you get what you pay for..." camp. On the support page, they list a number of companies that provide technical support services for OpenLDAP. If the price for stability is not worth engaging one of them, then you will need to keep your software up to a revision level that the developers will support. I am curious what constant issues/bugs are affecting you. Once we have a working version, it keeps on working and there is no need to constantly rebuild your software as new releases come out. The other option that we use here is the 389 Directory server, which might be an option for you to consider.
Regards, Ken
On Thu, Mar 18, 2010 at 08:46:38AM -0400, Alex McKenzie wrote: I'll be honest: while LDAP does what I need it to, and is the only tool I've found that works well for my purposes, this is why I'm constantly looking for another option. Just about every request for help I see come across this list gets an initial response of "Oh, well, you're one or two minor versions out of date. You need to update to the newest version before we can help you."
Software that unstable is not, in my view, really suited to a production environment. If the OpenLDAP developers -- who, overall, do an excellent job -- can't come up with a stable release every six months or so, there's a problem. If there are so many major flaws that running a month old version means it's unsupportable, that's an even bigger problem.
I've been following the list for around a year, and I understand the difficulties involved in supporting old versions, but the simple fact is, most of us don't have time to custom compile all our server software. My Ubuntu-default installs of Apache, postfix, SSH, and just about everything else work fine and can be supported by their developers. It's only LDAP (and a few things in beta) that absolutely have to run the newest version at all times. I chose to accept a limited feature-set and bullied GnuTLS into working "well enough" for our limited LDAP environment, but if I ever find an alternative, I'll be moving away from LDAP to whatever that is.
And please -- nobody take this as an attack. I really do respect the OpenLDAP development team, and the people on this list do their best to help everyone, even those of us using old versions. I just question the long-term viability of a system that needs to be recompiled as often as OpenLDAP seems to.
-Alex McKenzie
Quanah Gibson-Mount wrote:
--On Tuesday, March 16, 2010 7:21 PM -0300 Matheus Morais matheus.morais@gmail.com wrote:
Well, IMHO this is a really bad excuse and I was not expecting to hear that in this list.
Klements,
You can get slapd source packages and change the flags as you want. Serious distribution packages as Debian packages shouldn't be discouraged by OpenLDAP dev team as I'm seeing here. Debian packages policy are very strong and help a lot stable environments to be bug-free from recent less stable versions. I use Debian as a protection from that too early versions who can potentially threat my production environment and I was very successful with Debian packages in this attempt.
You can also look for support on Debian IRC channels and lists.
Hi Matheus,
I'll note that article was written by one of the Debian openldap package maintainers. And it is quite correct that anyone wanting to run a *stable* OpenLDAP production environment should most definitely *not* use the ones provided by most Linux OS providers, *particularly* Debian/Ubuntu. The reasons why this is the case have been hashed over many, many times. Particularly, the use of GnuTLS which is horribly broken being one of the major reasons. The fact that they are not kept up to date with current stable releases is another.
--Quanah
--
Quanah Gibson-Mount Principal Software Engineer Zimbra, Inc
Zimbra :: the leader in open source messaging and collaboration
On 3/18/10 3:36 PM, Alex McKenzie wrote:
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
Again: this is a decision the development team made. It's not because it's free, it's because they chose one particular mode of development. I'm not saying it's wrong, necessarily, but it drives a lot of people -- like me -- to look for alternatives. Right now, the system pretty much works, despite the fact that I'm using and older version (2.4.7-6Ubuntu3). The problem, for me, is that if I write to this list with a problem, I'll be told no one can help me unless I rebuild from scratch. So far, it's been easier to work around problems or look for help in the Ubuntu forums.
I don't see whay you should blame the OpenLDAP developpers if Ubuntu/RH/Suse/Whateverix don't provide updated packages...
Or may be they just need people to compile and test the latest packages to add them in their distro.
You can volunteer, of course.
On Thu, Mar 18, 2010 at 10:36:09AM -0400, Alex McKenzie wrote:
perhaps something the devels should think about. If they decide to continue on the way they have... well, that's their option. It's their project, and they can do what they want with it. But they should at least be aware that people are concerned about the current methods.
I tend to agree with Alex, FWIW, but I too recognize that I get what I pay for.
danno -- Dan Pritts, Sr. Systems Engineer Internet2 office: +1-734-352-4953 | mobile: +1-734-834-7224
Internet2 Spring Member Meeting April 26-28, 2010 - Arlington, Virginia http://events.internet2.edu/2010/spring-mm/
Dan Pritts danno@internet2.edu writes:
On Thu, Mar 18, 2010 at 10:36:09AM -0400, Alex McKenzie wrote:
perhaps something the devels should think about. If they decide to continue on the way they have... well, that's their option. It's their project, and they can do what they want with it. But they should at least be aware that people are concerned about the current methods.
I tend to agree with Alex, FWIW, but I too recognize that I get what I pay for.
Out of fairness want to note that the most significant component of the problems with the OpenLDAP packages for Debian (and Ubuntu, to a somewhat lesser degree) is that the packaging team has basically no resources. Only two of us have done much work over the past year or two, and then only as we've found time, and neither of the two of us who are active have any free time to spare to increase the amount of work that we're doing significantly.
This is not something that either is the fault of the OpenLDAP project or something that any of the OpenLDAP developers can address even if they wanted to unless they wanted to become experts in Debian packaging. Debian and Ubuntu need more people with a thorough understanding of Debian packaging working on improving the packages.
At this point, nearly all complaints about the state of the Debian packages are rightfully directed at the lack of resources on the Debian side. There may be some issues that could be reasonably considered a shared responsibility were the packages in much better shape, but at this point they're swamped by the lack of volunteer resources to absorb new upstream releases and do reasonable bug triage.
Unfortunately, we're currently in a state where the people involved in the packaging don't have enough free time to teach even interested parties about packaging so that they can come up to speed and help. We really need volunteers who already know the packaging components and can start working at that level without needing much additional resources or training. Both Steve and I are already doing about a dozen other high-profile things for Debian and are both involved in the packaging of OpenLDAP primarily out of pure self-interest in not wanting to see the packages go completely untended, not because we have any realistic ability to maintain the packages as they properly should be maintained.
I do the Debian package maintenance for OpenAFS, which has a similar or higher change rate as OpenLDAP and also doesn't do a lot of support for old stable versions, but the end user experience is much, much better and the same complaints are not present simply because on the packaging side I'm able to apply more resources. I have the time to aggressively package new versions, pull up upstream changes inbetween releases (admittedly, made *far* easier than it would be for OpenLDAP by OpenAFS's use of Git), and backport newer versions for users of Debian stable. When Debian users of OpenAFS run into problems fixed in later versions, I can just tell them to go to the version from backports.org to solve their problem. This doesn't require any additional work from the OpenAFS upstream maintainers.
There's absolutely no reason why the same thing couldn't be true of the OpenLDAP packages for Debian and Ubuntu, without any changes whatsoever to how the OpenLDAP developers run their project. All it requires is volunteers and time.
First of all let me reconsider my opinion after a carefully read on Quanah arguments and references about OpenLDAP packages around some distros. I had read the archives of this list, specifically about GnuTLS problems with OpenLDAP on Debian and now I understand the point of view of OpenLDAP developers. In fact, not only understands as I fully support it now. So sorry if was missing the point at my first email.
I feel very sad to hear about the lack of resources on Debian and most sad with myself to not be involved on it as much as I wish. I use Debian every day on my work and I couldn't help the Debian community in the same way that the community help me. I hope that I can change this some day and become heavily involved to help in the packages maintenance.
Keep up with this great work in OpenLDAP development and support guys! :)
On Thu, Mar 18, 2010 at 8:38 PM, Russ Allbery rra@stanford.edu wrote:
Dan Pritts danno@internet2.edu writes:
On Thu, Mar 18, 2010 at 10:36:09AM -0400, Alex McKenzie wrote:
perhaps something the devels should think about. If they decide to continue on the way they have... well, that's their option. It's their project, and they can do what they want with it. But they should at least be aware that people are concerned about the current methods.
I tend to agree with Alex, FWIW, but I too recognize that I get what I pay for.
Out of fairness want to note that the most significant component of the problems with the OpenLDAP packages for Debian (and Ubuntu, to a somewhat lesser degree) is that the packaging team has basically no resources. Only two of us have done much work over the past year or two, and then only as we've found time, and neither of the two of us who are active have any free time to spare to increase the amount of work that we're doing significantly.
This is not something that either is the fault of the OpenLDAP project or something that any of the OpenLDAP developers can address even if they wanted to unless they wanted to become experts in Debian packaging. Debian and Ubuntu need more people with a thorough understanding of Debian packaging working on improving the packages.
At this point, nearly all complaints about the state of the Debian packages are rightfully directed at the lack of resources on the Debian side. There may be some issues that could be reasonably considered a shared responsibility were the packages in much better shape, but at this point they're swamped by the lack of volunteer resources to absorb new upstream releases and do reasonable bug triage.
Unfortunately, we're currently in a state where the people involved in the packaging don't have enough free time to teach even interested parties about packaging so that they can come up to speed and help. We really need volunteers who already know the packaging components and can start working at that level without needing much additional resources or training. Both Steve and I are already doing about a dozen other high-profile things for Debian and are both involved in the packaging of OpenLDAP primarily out of pure self-interest in not wanting to see the packages go completely untended, not because we have any realistic ability to maintain the packages as they properly should be maintained.
I do the Debian package maintenance for OpenAFS, which has a similar or higher change rate as OpenLDAP and also doesn't do a lot of support for old stable versions, but the end user experience is much, much better and the same complaints are not present simply because on the packaging side I'm able to apply more resources. I have the time to aggressively package new versions, pull up upstream changes inbetween releases (admittedly, made *far* easier than it would be for OpenLDAP by OpenAFS's use of Git), and backport newer versions for users of Debian stable. When Debian users of OpenAFS run into problems fixed in later versions, I can just tell them to go to the version from backports.org to solve their problem. This doesn't require any additional work from the OpenAFS upstream maintainers.
There's absolutely no reason why the same thing couldn't be true of the OpenLDAP packages for Debian and Ubuntu, without any changes whatsoever to how the OpenLDAP developers run their project. All it requires is volunteers and time.
-- Russ Allbery (rra@stanford.edu) http://www.eyrie.org/~eagle/
Matheus Morais matheus.morais@gmail.com writes:
First of all let me reconsider my opinion after a carefully read on Quanah arguments and references about OpenLDAP packages around some distros. I had read the archives of this list, specifically about GnuTLS problems with OpenLDAP on Debian and now I understand the point of view of OpenLDAP developers. In fact, not only understands as I fully support it now. So sorry if was missing the point at my first email.
I don't think anyone is happy about the multiple SSL library situation. We (Debian) believe that not using OpenSSL is legally required by the mixture of licenses in question and that we have no choice unless we were to remove from the distribution all software covered by the GPL and using the OpenLDAP libraries. Obviously, other people's legal advice differs, but we can only go with the legal framework that we have available.
Due to its nature, Debian has to be somewhat more conservative on legal questions since the project has no legal existence and hence no corporate or other organizational liability shield. If we screw up on legal questions, *individual people* potentially get sued. Although I note that Ubuntu (which I'm not involved in), which does have an organizational liability shield, is also taking the same stance.
It's one of those cases where the risk of an adverse event are very low, but the negative consequences are potentially high.
I do think that the security concerns with GnuTLS tend to be somewhat overstated on this list when summarized (and in a way that's not horribly helpful in improving the overall quality of the package, not that it's the obligation of anyone here to help with that). But, regardless, Debian, as the distributor who wants to use GnuTLS against the explicit advice of the OpenLDAP developers, should carry the burden of investigating, reducing to reproducible test cases, and reporting problems that are best corrected in the OpenLDAP side of the interface. That's not currently happening due to the same lack of volunteer time discussed in my previous message, and that's not the fault of the OpenLDAP maintainers.
On Mar 18, 2010, at 9:24 PM, Russ Allbery wrote:
we can only go with the legal framework that we have available.
Most certainly.
Often folks forget that there are both technical and non-technical reasons for taking courses of actions in software projects. A project need to do what it believes to be most appropriate.
As Howard notes, many software projects including the OpenLDAP Project ship only their source.
I note that here are both technical and non-technical reasons why a project might take such a course. For instance, lack of expertise in packaging for various platforms might be technical reason. Issues of legal liability might be a non-technical reason.
There are both technical and non-technical reasons behind the OpenLDAP Project practice to ship only source code to OpenLDAP Software.
Regards, Kurt
В Чтв, 18/03/2010 в 16:38 -0700, Russ Allbery пишет:
Dan Pritts danno@internet2.edu writes:
On Thu, Mar 18, 2010 at 10:36:09AM -0400, Alex McKenzie wrote:
perhaps something the devels should think about. If they decide to continue on the way they have... well, that's their option. It's their project, and they can do what they want with it. But they should at least be aware that people are concerned about the current methods.
I tend to agree with Alex, FWIW, but I too recognize that I get what I pay for.
Out of fairness want to note that the most significant component of the problems with the OpenLDAP packages for Debian (and Ubuntu, to a somewhat lesser degree) is that the packaging team has basically no resources. Only two of us have done much work over the past year or two, and then only as we've found time, and neither of the two of us who are active have any free time to spare to increase the amount of work that we're doing significantly.
This is not something that either is the fault of the OpenLDAP project or something that any of the OpenLDAP developers can address even if they wanted to unless they wanted to become experts in Debian packaging. Debian and Ubuntu need more people with a thorough understanding of Debian packaging working on improving the packages.
At this point, nearly all complaints about the state of the Debian packages are rightfully directed at the lack of resources on the Debian side. There may be some issues that could be reasonably considered a shared responsibility were the packages in much better shape, but at this point they're swamped by the lack of volunteer resources to absorb new upstream releases and do reasonable bug triage.
Is this issue filed on Debian bugtracker?
Unfortunately, we're currently in a state where the people involved in the packaging don't have enough free time to teach even interested parties about packaging so that they can come up to speed and help. We really need volunteers who already know the packaging components and can start working at that level without needing much additional resources or training. Both Steve and I are already doing about a dozen other high-profile things for Debian and are both involved in the packaging of OpenLDAP primarily out of pure self-interest in not wanting to see the packages go completely untended, not because we have any realistic ability to maintain the packages as they properly should be maintained.
I do the Debian package maintenance for OpenAFS, which has a similar or higher change rate as OpenLDAP and also doesn't do a lot of support for old stable versions, but the end user experience is much, much better and the same complaints are not present simply because on the packaging side I'm able to apply more resources. I have the time to aggressively package new versions, pull up upstream changes inbetween releases (admittedly, made *far* easier than it would be for OpenLDAP by OpenAFS's use of Git), and backport newer versions for users of Debian stable. When Debian users of OpenAFS run into problems fixed in later versions, I can just tell them to go to the version from backports.org to solve their problem. This doesn't require any additional work from the OpenAFS upstream maintainers.
There's absolutely no reason why the same thing couldn't be true of the OpenLDAP packages for Debian and Ubuntu, without any changes whatsoever to how the OpenLDAP developers run their project. All it requires is volunteers and time.
Покотиленко Костик casper@meteor.dp.ua writes:
В Чтв, 18/03/2010 в 16:38 -0700, Russ Allbery пишет:
At this point, nearly all complaints about the state of the Debian packages are rightfully directed at the lack of resources on the Debian side. There may be some issues that could be reasonably considered a shared responsibility were the packages in much better shape, but at this point they're swamped by the lack of volunteer resources to absorb new upstream releases and do reasonable bug triage.
Is this issue filed on Debian bugtracker?
Yes. http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=512360
As you can see, the bug has gotten a fair number of replies, but unfortunately so far they've not translated into more people with time to do work.
В Птн, 19/03/2010 в 10:01 -0700, Russ Allbery пишет:
Покотиленко Костик casper@meteor.dp.ua writes:
В Чтв, 18/03/2010 в 16:38 -0700, Russ Allbery пишет:
At this point, nearly all complaints about the state of the Debian packages are rightfully directed at the lack of resources on the Debian side. There may be some issues that could be reasonably considered a shared responsibility were the packages in much better shape, but at this point they're swamped by the lack of volunteer resources to absorb new upstream releases and do reasonable bug triage.
Is this issue filed on Debian bugtracker?
Yes. http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=512360
As you can see, the bug has gotten a fair number of replies, but unfortunately so far they've not translated into more people with time to do work.
Well, I see. I'm going to migrate setup in my organization to LDAP soon. So, I'm interested in the success of this, and by the way this is why I've subscribed to the list.
I have some questions not answered before I can migrate, will start new thread. Shortly, there is 200+ users with mix of UNIX, Samba, Postfix, Cyrus, eJabberd accounts.
Maybe I can help in testing. Need some invertigation of questions/bugs.
Russ Allbery wrote:
Dan Pritts danno@internet2.edu writes:
On Thu, Mar 18, 2010 at 10:36:09AM -0400, Alex McKenzie wrote:
perhaps something the devels should think about. If they decide to continue on the way they have... well, that's their option. It's their project, and they can do what they want with it. But they should at least be aware that people are concerned about the current methods.
I tend to agree with Alex, FWIW, but I too recognize that I get what I pay for.
Out of fairness want to note that the most significant component of the problems with the OpenLDAP packages for Debian (and Ubuntu, to a somewhat lesser degree) is that the packaging team has basically no resources.
In this case I'd prefer if a Linux distribution would not add a package at all. At least not a package which was obviously an experimental pre-release at that time. And not hacking the upstream software to work with components known to be buggy. This would save us all a lot of time.
Ciao, Michael.
В Птн, 19/03/2010 в 10:14 +0100, Michael Ströder пишет:
Russ Allbery wrote:
Dan Pritts danno@internet2.edu writes:
On Thu, Mar 18, 2010 at 10:36:09AM -0400, Alex McKenzie wrote:
perhaps something the devels should think about. If they decide to continue on the way they have... well, that's their option. It's their project, and they can do what they want with it. But they should at least be aware that people are concerned about the current methods.
I tend to agree with Alex, FWIW, but I too recognize that I get what I pay for.
Out of fairness want to note that the most significant component of the problems with the OpenLDAP packages for Debian (and Ubuntu, to a somewhat lesser degree) is that the packaging team has basically no resources.
In this case I'd prefer if a Linux distribution would not add a package at all. At least not a package which was obviously an experimental pre-release at that time. And not hacking the upstream software to work with components known to be buggy. This would save us all a lot of time.
Again, if not already done so, file a bug against distribution package and read thier considerations.
Michael Ströder michael@stroeder.com writes:
Russ Allbery wrote:
Out of fairness want to note that the most significant component of the problems with the OpenLDAP packages for Debian (and Ubuntu, to a somewhat lesser degree) is that the packaging team has basically no resources.
In this case I'd prefer if a Linux distribution would not add a package at all. At least not a package which was obviously an experimental pre-release at that time. And not hacking the upstream software to work with components known to be buggy. This would save us all a lot of time.
I understand this opinion, but don't share it. Sorry.
On Thu, Mar 18, 2010 at 04:38:32PM -0700, Russ Allbery wrote:
Out of fairness want to note that the most significant component of the problems with the OpenLDAP packages for Debian (and Ubuntu, to a somewhat lesser degree) is that the packaging team has basically no resources.
Interesting about the Debian situation. Another reminder to me of why I don't use Debian; the project's concerns about absolute "freedom" don't mesh with my concerns about getting real work done.
That said, I've seen similar "don't use the distro's package" notes about other distributions here, too.
I'm a redhat user. Of course, I should complain to redhat rather than here, but I only pay them the .edu rate for software updates with no support. I don't know the history of the particular (ancient at this point) version of openldap that RHEL5 includes, or what redhat has done behind the scenes to fix problems, but i have to say that in general their policy of stability makes running servers a lot easier.
Of course, redhat has its own ldap server, which might explain why they neglect their openldap packages.
Again though, I recognize that I get from openldap much more than I have paid to the project. Thanks for all your hard work developing the software. I suppose if it were super easy to make everything work, they wouldn't need me here and I'd be flipping burgers. :)
thanks danno -- Dan Pritts, Sr. Systems Engineer Internet2 office: +1-734-352-4953 | mobile: +1-734-834-7224
Internet2 Spring Member Meeting April 26-28, 2010 - Arlington, Virginia http://events.internet2.edu/2010/spring-mm/
Dan Pritts danno@internet2.edu writes:
On Thu, Mar 18, 2010 at 04:38:32PM -0700, Russ Allbery wrote:
Out of fairness want to note that the most significant component of the problems with the OpenLDAP packages for Debian (and Ubuntu, to a somewhat lesser degree) is that the packaging team has basically no resources.
Interesting about the Debian situation. Another reminder to me of why I don't use Debian; the project's concerns about absolute "freedom" don't mesh with my concerns about getting real work done.
Well, I certainly won't debate that here, but just to be clear, nothing that I said has anything whatsoever to do with Debian's definition of freedom or free software. Debian doesn't object to OpenSSL for any grounds related to free software definitions or licensing. Everyone agrees that the licenses of all software involved qualify as free software.
Debian doesn't distribute GPL'd software linked (via OpenLDAP) to OpenSSL because we believe doing so would be *illegal*. Not non-free, not falling astray of some Debian licensing principle, but an actual legal violation of the OpenSSL and GPL licenses for which we could be sued.
If you build the software yourself against OpenSSL but don't distribute it, the relevant clause of the GPL doesn't apply and there is no issue.
As mentioned previously, I understand that other people's lawyers have produced different answers.
Russ Allbery wrote:
Dan Prittsdanno@internet2.edu writes:
On Thu, Mar 18, 2010 at 04:38:32PM -0700, Russ Allbery wrote:
Out of fairness want to note that the most significant component of the problems with the OpenLDAP packages for Debian (and Ubuntu, to a somewhat lesser degree) is that the packaging team has basically no resources.
Interesting about the Debian situation. Another reminder to me of why I don't use Debian; the project's concerns about absolute "freedom" don't mesh with my concerns about getting real work done.
Well, I certainly won't debate that here, but just to be clear, nothing that I said has anything whatsoever to do with Debian's definition of freedom or free software. Debian doesn't object to OpenSSL for any grounds related to free software definitions or licensing. Everyone agrees that the licenses of all software involved qualify as free software.
Debian doesn't distribute GPL'd software linked (via OpenLDAP) to OpenSSL because we believe doing so would be *illegal*. Not non-free, not falling astray of some Debian licensing principle, but an actual legal violation of the OpenSSL and GPL licenses for which we could be sued.
If you build the software yourself against OpenSSL but don't distribute it, the relevant clause of the GPL doesn't apply and there is no issue.
Getting far into digression here, but this is another reason to switch to the nssov / nss-pam-ldapd model. Remove libldap from PAM/NSS and a lot of these linking issues disappear.
Howard Chu hyc@symas.com writes:
Getting far into digression here, but this is another reason to switch to the nssov / nss-pam-ldapd model. Remove libldap from PAM/NSS and a lot of these linking issues disappear.
Yes, amen to that. I'm *really* happy with that work, both for that reason and just for significant simplification of all sorts of linking issues. I'm not sure if it's enough to resolve the problems that Debian runs into due to the pile of GPL'd software that wants to link with the LDAP libraries, but it certainly resolves the problem enough that it might be on the table at some point, and even apart from that, it's simply a much better model.
So thank you very much to everyone who's been involved.
On Fri, Mar 19, 2010 at 04:04:45PM -0700, Russ Allbery wrote:
Debian doesn't distribute GPL'd software linked (via OpenLDAP) to OpenSSL because we believe doing so would be *illegal*. Not non-free, not falling
yes, that became clear from your later reply, I had just assumed it was due to some insufficiently-Free license that debian had rejected openssl.
sorry for spreading misinformation.
regards danno -- Dan Pritts, Sr. Systems Engineer Internet2 office: +1-734-352-4953 | mobile: +1-734-834-7224
Internet2 Spring Member Meeting April 26-28, 2010 - Arlington, Virginia http://events.internet2.edu/2010/spring-mm/
Dan Pritts wrote:
On Thu, Mar 18, 2010 at 04:38:32PM -0700, Russ Allbery wrote:
Out of fairness want to note that the most significant component of the problems with the OpenLDAP packages for Debian (and Ubuntu, to a somewhat lesser degree) is that the packaging team has basically no resources.
Interesting about the Debian situation. Another reminder to me of why I don't use Debian; the project's concerns about absolute "freedom" don't mesh with my concerns about getting real work done.
That said, I've seen similar "don't use the distro's package" notes about other distributions here, too.
I'm a redhat user. Of course, I should complain to redhat rather than here, but I only pay them the .edu rate for software updates with no support. I don't know the history of the particular (ancient at this point) version of openldap that RHEL5 includes, or what redhat has done behind the scenes to fix problems, but i have to say that in general their policy of stability makes running servers a lot easier.
Of course, redhat has its own ldap server, which might explain why they neglect their openldap packages.
RedHat's neglect goes back long before they bought Netscape. Anyone holding up their historical practice as a model of good open source behavior needs to look again. At least the Debian people are keeping in regular contact on these mailing lists now. When sticky questions come up, at least we have an established channel of communication with them. I think some RedHat folks have been doing better on the communication front recently, and I'm glad to see it. But it's still pretty minimal in comparison to other teams.
Again though, I recognize that I get from openldap much more than I have paid to the project. Thanks for all your hard work developing the software. I suppose if it were super easy to make everything work, they wouldn't need me here and I'd be flipping burgers. :)
Ultimately I'd like the software to work so perfectly that we don't need to provide support any more, and then I'll just spend my time playing fiddle.
For some level of users, we're already there - plenty of people use it without needing any help.
В Птн, 19/03/2010 в 10:44 -0400, Dan Pritts пишет:
On Thu, Mar 18, 2010 at 04:38:32PM -0700, Russ Allbery wrote:
Out of fairness want to note that the most significant component of the problems with the OpenLDAP packages for Debian (and Ubuntu, to a somewhat lesser degree) is that the packaging team has basically no resources.
Interesting about the Debian situation. Another reminder to me of why I don't use Debian; the project's concerns about absolute "freedom" don't mesh with my concerns about getting real work done.
The problem you are talking about is not Debian related, it's distribution related. Tommorow the situation may change to the opposite.
When you are not satisfied with the version in stable - the are backport. If there is no backport, there always is testing/unstable/experimental to manually make backport from, later always with most recent version in a resonable short delay.
Not sure about Redhat. I'm a Debian user.
That said, I've seen similar "don't use the distro's package" notes about other distributions here, too.
I'm a redhat user. Of course, I should complain to redhat rather than here, but I only pay them the .edu rate for software updates with no support. I don't know the history of the particular (ancient at this point) version of openldap that RHEL5 includes, or what redhat has done behind the scenes to fix problems, but i have to say that in general their policy of stability makes running servers a lot easier.
Of course, redhat has its own ldap server, which might explain why they neglect their openldap packages.
Again though, I recognize that I get from openldap much more than I have paid to the project. Thanks for all your hard work developing the software. I suppose if it were super easy to make everything work, they wouldn't need me here and I'd be flipping burgers. :)
thanks danno -- Dan Pritts, Sr. Systems Engineer Internet2 office: +1-734-352-4953 | mobile: +1-734-834-7224
Internet2 Spring Member Meeting April 26-28, 2010 - Arlington, Virginia http://events.internet2.edu/2010/spring-mm/
Alex McKenzie wrote:
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
Right. But how much do I pay for Apache? How much do I pay for postfix, sendmail, qmail, or exim? How about MySQL, or Postgresql? The real issue, for me, is the version cycle. All of those packages have minor updates fairly regularly, but none of them change major functionality, and all of them provide packages to various linux distributions, including Debian and Ubuntu. And most of them have decent free support, at least via the sort of mailing list we're on now, that includes those distribution packages. They may well tell you you need to install the newest debian package, but they'll almost never tell you that you have to recompile for basic functionality.
Most of those projects just release source code, like us. The packages you see on various distros are built by the distro packagers, not by the upstream projects.
We'd be happy to tell you to install the newest debian package, if it was ever new enough. Because it usually isn't, you usually need to recompile. How is this any different from any other software?
There haven't been any major changes to existing functionality in a couple of years now. Remember, in the X.Y.Z version number, the Z is just a patchlevel.
If you say "I hit thus-and-such bug in version X.Y.Z" and we say "that's fixed in X.Y.Z+10" and you don't want to sync up with that patch, that's your decision.
Again: this is a decision the development team made. It's not because it's free, it's because they chose one particular mode of development.
"Release early, release often." That's the most viable way forward for an open source project. I'd say our release frequency has been too slow, really.
I'm not saying it's wrong, necessarily, but it drives a lot of people -- like me -- to look for alternatives. Right now, the system pretty much works, despite the fact that I'm using and older version (2.4.7-6Ubuntu3). The problem, for me, is that if I write to this list with a problem, I'll be told no one can help me unless I rebuild from scratch.
So far, it's been easier to ... look for help in the Ubuntu forums.
As it should be. If you're running a package from a distro vendor, then you should be consuming their support resources, not ours. We don't know what all the distro packagers do, what options they use, what libraries they include. Some of them ship explicitly broken packages, despite our best efforts. (E.g., RedHat/CentOS, linking against Berkeley DB 4.3 when we know for a fact that this combination crashes, and have explicitly prevented using BDB 4.3 in our configure script.) If you have a problem with binaries from a distro packager, that's their responsibility, and we can't help you work past their mistakes unless you recompile the source and build it properly.
You're right that I don't need to keep rebuilding as new versions come out, but that's only as long as I don't want to ask for help: if I need to change how something works, or add functionality, even if it's present in the version I have installed, I have to upgrade.
Anyway: this is really all pretty much irrelevant to the list as a whole. I just wanted to make the point that this is an issue, and perhaps something the devels should think about. If they decide to continue on the way they have... well, that's their option. It's their project, and they can do what they want with it. But they should at least be aware that people are concerned about the current methods.
Your concerns are noted. But IMO they are misdirected. If your distro packager can't keep you up to date then that's an issue for you and them to deal with.
- -Alex
Kenneth Marshall wrote:
Hi Alex,
I think this falls into the "you get what you pay for..." camp. On the support page, they list a number of companies that provide technical support services for OpenLDAP. If the price for stability is not worth engaging one of them, then you will need to keep your software up to a revision level that the developers will support. I am curious what constant issues/bugs are affecting you. Once we have a working version, it keeps on working and there is no need to constantly rebuild your software as new releases come out. The other option that we use here is the 389 Directory server, which might be an option for you to consider.
Regards, Ken
On Thu, Mar 18, 2010 at 08:46:38AM -0400, Alex McKenzie wrote: I'll be honest: while LDAP does what I need it to, and is the only tool I've found that works well for my purposes, this is why I'm constantly looking for another option. Just about every request for help I see come across this list gets an initial response of "Oh, well, you're one or two minor versions out of date. You need to update to the newest version before we can help you."
Software that unstable is not, in my view, really suited to a production environment. If the OpenLDAP developers -- who, overall, do an excellent job -- can't come up with a stable release every six months or so, there's a problem. If there are so many major flaws that running a month old version means it's unsupportable, that's an even bigger problem.
I've been following the list for around a year, and I understand the difficulties involved in supporting old versions, but the simple fact is, most of us don't have time to custom compile all our server software. My Ubuntu-default installs of Apache, postfix, SSH, and just about everything else work fine and can be supported by their developers. It's only LDAP (and a few things in beta) that absolutely have to run the newest version at all times. I chose to accept a limited feature-set and bullied GnuTLS into working "well enough" for our limited LDAP environment, but if I ever find an alternative, I'll be moving away from LDAP to whatever that is.
And please -- nobody take this as an attack. I really do respect the OpenLDAP development team, and the people on this list do their best to help everyone, even those of us using old versions. I just question the long-term viability of a system that needs to be recompiled as often as OpenLDAP seems to.
-Alex McKenzie
Quanah Gibson-Mount wrote:
--On Tuesday, March 16, 2010 7:21 PM -0300 Matheus Morais matheus.morais@gmail.com wrote:
Well, IMHO this is a really bad excuse and I was not expecting to hear that in this list.
Klements,
You can get slapd source packages and change the flags as you want. Serious distribution packages as Debian packages shouldn't be discouraged by OpenLDAP dev team as I'm seeing here. Debian packages policy are very strong and help a lot stable environments to be bug-free from recent less stable versions. I use Debian as a protection from that too early versions who can potentially threat my production environment and I was very successful with Debian packages in this attempt.
You can also look for support on Debian IRC channels and lists.
Hi Matheus,
I'll note that article was written by one of the Debian openldap package maintainers. And it is quite correct that anyone wanting to run a *stable* OpenLDAP production environment should most definitely *not* use the ones provided by most Linux OS providers, *particularly* Debian/Ubuntu. The reasons why this is the case have been hashed over many, many times. Particularly, the use of GnuTLS which is horribly broken being one of the major reasons. The fact that they are not kept up to date with current stable releases is another.
--Quanah
--
Quanah Gibson-Mount Principal Software Engineer Zimbra, Inc
Zimbra :: the leader in open source messaging and collaboration
В Чтв, 18/03/2010 в 12:10 -0700, Howard Chu пишет:
Alex McKenzie wrote:
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
Right. But how much do I pay for Apache? How much do I pay for postfix, sendmail, qmail, or exim? How about MySQL, or Postgresql? The real issue, for me, is the version cycle. All of those packages have minor updates fairly regularly, but none of them change major functionality, and all of them provide packages to various linux distributions, including Debian and Ubuntu. And most of them have decent free support, at least via the sort of mailing list we're on now, that includes those distribution packages. They may well tell you you need to install the newest debian package, but they'll almost never tell you that you have to recompile for basic functionality.
Most of those projects just release source code, like us. The packages you see on various distros are built by the distro packagers, not by the upstream projects.
We'd be happy to tell you to install the newest debian package, if it was ever new enough. Because it usually isn't, you usually need to recompile. How is this any different from any other software?
There haven't been any major changes to existing functionality in a couple of years now. Remember, in the X.Y.Z version number, the Z is just a patchlevel.
If you say "I hit thus-and-such bug in version X.Y.Z" and we say "that's fixed in X.Y.Z+10" and you don't want to sync up with that patch, that's your decision.
This is probably an issue. If I'm correct Debian policy prevent version upgrade, say, if Lenny have 2.4.11 version, they can't put 2.4.17 in it. Instead, they can backport some patches from 2.4.17 back to 2.4.11 and make it 2.4.11-1+lenny1. "they" mean maintainers. On Debian there are a number of them, there is also a list which doesn't seem dead:
http://packages.debian.org/lenny/slapd http://lists.alioth.debian.org/pipermail/pkg-openldap-devel/
So, maybe a correct solution for this situation is to figure out what patch solves given issue and ask maintainers to backport it. Or maybe just file a bug on Debian.
Again: this is a decision the development team made. It's not because it's free, it's because they chose one particular mode of development.
"Release early, release often." That's the most viable way forward for an open source project. I'd say our release frequency has been too slow, really.
I'm not saying it's wrong, necessarily, but it drives a lot of people -- like me -- to look for alternatives. Right now, the system pretty much works, despite the fact that I'm using and older version (2.4.7-6Ubuntu3). The problem, for me, is that if I write to this list with a problem, I'll be told no one can help me unless I rebuild from scratch.
So far, it's been easier to ... look for help in the Ubuntu forums.
As it should be. If you're running a package from a distro vendor, then you should be consuming their support resources, not ours. We don't know what all the distro packagers do, what options they use, what libraries they include. Some of them ship explicitly broken packages, despite our best efforts. (E.g., RedHat/CentOS, linking against Berkeley DB 4.3 when we know for a fact that this combination crashes, and have explicitly prevented using BDB 4.3 in our configure script.) If you have a problem with binaries from a distro packager, that's their responsibility, and we can't help you work past their mistakes unless you recompile the source and build it properly.
You're right that I don't need to keep rebuilding as new versions come out, but that's only as long as I don't want to ask for help: if I need to change how something works, or add functionality, even if it's present in the version I have installed, I have to upgrade.
Anyway: this is really all pretty much irrelevant to the list as a whole. I just wanted to make the point that this is an issue, and perhaps something the devels should think about. If they decide to continue on the way they have... well, that's their option. It's their project, and they can do what they want with it. But they should at least be aware that people are concerned about the current methods.
Your concerns are noted. But IMO they are misdirected. If your distro packager can't keep you up to date then that's an issue for you and them to deal with.
- -Alex
Kenneth Marshall wrote:
Hi Alex,
I think this falls into the "you get what you pay for..." camp. On the support page, they list a number of companies that provide technical support services for OpenLDAP. If the price for stability is not worth engaging one of them, then you will need to keep your software up to a revision level that the developers will support. I am curious what constant issues/bugs are affecting you. Once we have a working version, it keeps on working and there is no need to constantly rebuild your software as new releases come out. The other option that we use here is the 389 Directory server, which might be an option for you to consider.
Regards, Ken
On Thu, Mar 18, 2010 at 08:46:38AM -0400, Alex McKenzie wrote: I'll be honest: while LDAP does what I need it to, and is the only tool I've found that works well for my purposes, this is why I'm constantly looking for another option. Just about every request for help I see come across this list gets an initial response of "Oh, well, you're one or two minor versions out of date. You need to update to the newest version before we can help you."
Software that unstable is not, in my view, really suited to a production environment. If the OpenLDAP developers -- who, overall, do an excellent job -- can't come up with a stable release every six months or so, there's a problem. If there are so many major flaws that running a month old version means it's unsupportable, that's an even bigger problem.
I've been following the list for around a year, and I understand the difficulties involved in supporting old versions, but the simple fact is, most of us don't have time to custom compile all our server software. My Ubuntu-default installs of Apache, postfix, SSH, and just about everything else work fine and can be supported by their developers. It's only LDAP (and a few things in beta) that absolutely have to run the newest version at all times. I chose to accept a limited feature-set and bullied GnuTLS into working "well enough" for our limited LDAP environment, but if I ever find an alternative, I'll be moving away from LDAP to whatever that is.
And please -- nobody take this as an attack. I really do respect the OpenLDAP development team, and the people on this list do their best to help everyone, even those of us using old versions. I just question the long-term viability of a system that needs to be recompiled as often as OpenLDAP seems to.
-Alex McKenzie
Quanah Gibson-Mount wrote:
--On Tuesday, March 16, 2010 7:21 PM -0300 Matheus Morais matheus.morais@gmail.com wrote:
> Well, IMHO this is a really bad excuse and I was not expecting to hear > that in this list. > > > Klements, > > > You can get slapd source packages and change the flags as you want. > Serious distribution packages as Debian packages shouldn't > be discouraged by OpenLDAP dev team as I'm seeing here. Debian packages > policy are very strong and help a lot stable environments to be bug-free > from recent less stable versions. I use Debian as a protection from that > too early versions who can potentially threat my production environment > and I was very successful with Debian packages in this attempt. > > > You can also look for support on Debian IRC channels and lists. Hi Matheus,
I'll note that article was written by one of the Debian openldap package maintainers. And it is quite correct that anyone wanting to run a *stable* OpenLDAP production environment should most definitely *not* use the ones provided by most Linux OS providers, *particularly* Debian/Ubuntu. The reasons why this is the case have been hashed over many, many times. Particularly, the use of GnuTLS which is horribly broken being one of the major reasons. The fact that they are not kept up to date with current stable releases is another.
--Quanah
--
Quanah Gibson-Mount Principal Software Engineer Zimbra, Inc
Zimbra :: the leader in open source messaging and collaboration
-- -- Howard Chu CTO, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc/ Chief Architect, OpenLDAP http://www.openldap.org/project/
On Thursday, 18 March 2010 20:10:32 Howard Chu wrote:
As it should be. If you're running a package from a distro vendor, then you should be consuming their support resources, not ours. We don't know what all the distro packagers do, what options they use, what libraries they include. Some of them ship explicitly broken packages, despite our best efforts. (E.g., RedHat/CentOS, linking against Berkeley DB 4.3 when we know for a fact that this combination crashes, and have explicitly prevented using BDB 4.3 in our configure script.)
Let's be careful about what we criticise some of the better open source companies of doing. While the Red Hat packages have historically left a *lot* to be desired (Red Hat 7.x/RHEL2.1 shipped OpenLDAP 2.0.x built against GNU gdbm!, RHEL3 shipped 2.0.x when 2.1 had been stable for a substantial amount of time), the RHEL4 packages of 2.2 built an internal copy of 4.2:
$ rpm -qlp /data/software/linux/redhat/rhel4es-64/RedHat/RPMS/openldap- servers-2.2.13-12.el4.x86_64.rpm |grep "lib.*db" /usr/lib64/libslapd_db-4.2.so /usr/lib64/tls/libslapd_db-4.2.so
and RHEL5 shipped 2.3 (granted, RHEL5.2 and earlier had a very old version, 2.3.27 I think) built with an internal copy of 4.4 (while the "system" copy of db was 4.3):
$ rpm -qlp /data/software/linux/redhat/rhel5.1-64/Server/openldap- servers-2.3.27-8.x86_64.rpm |grep "lib.*db" /usr/lib64/libslapd_db-4.4.so /usr/lib64/tls/libslapd_db-4.4.so
While Fedora may have shipped OpenLDAP built against db4.3, I can find no evidence of Red Hat having shipped that combination in any RHEL release.
As of 5.3, the OpenLDAP packages shipped by Red Hat are quite adequate (IMHO), even if there are some peculiarities and areas for improvement. In environments which don't justify 2.4, or where OpenLDAP isn't business- critical (where I still have RHEL4 boxes running 2.3.43 because I can't justify an OS upgrade yet), CentOS 5.3 with the supplied packages is quite adequate.
Of course, people who desire packages for 2.4 can get them from others, and people can argue the point that Red Hat should provide them. However Red Hat aims to provide some kind of stability, including version stability. And, in the same was as their OpenLDAP packages are still on 2.3, their samba packages (at least on RHEL 5.4) are still on 3.0 (when there is even *more* motivation to ship a newer version, due to compatibility with the new versions of the desktop software with the biggest market share).
If you have a requirement for 2.4, faced with the choices, I would *not* go with a distro that ships OpenLDAP built against gnutls, so my personal choices would be Mandriva or CentOS with my 2.4 packages (but, I could be biased).
Regards, Buchan
Alex McKenzie alex@chem.umass.edu writes:
I'll be honest: while LDAP does what I need it to, and is the only tool I've found that works well for my purposes, this is why I'm constantly looking for another option. Just about every request for help I see come across this list gets an initial response of "Oh, well, you're one or two minor versions out of date. You need to update to the newest version before we can help you."
Software that unstable is not, in my view, really suited to a production environment. If the OpenLDAP developers -- who, overall, do an excellent job -- can't come up with a stable release every six months or so, there's a problem. If there are so many major flaws that running a month old version means it's unsupportable, that's an even bigger problem.
I've been following the list for around a year, and I understand the difficulties involved in supporting old versions, but the simple fact is, most of us don't have time to custom compile all our server software. My Ubuntu-default installs of Apache, postfix, SSH, and just about everything else work fine and can be supported by their developers. It's only LDAP (and a few things in beta) that absolutely have to run the newest version at all times. I chose to accept a limited feature-set and bullied GnuTLS into working "well enough" for our limited LDAP environment, but if I ever find an alternative, I'll be moving away from LDAP to whatever that is.
And please -- nobody take this as an attack. I really do respect the OpenLDAP development team, and the people on this list do their best to help everyone, even those of us using old versions. I just question the long-term viability of a system that needs to be recompiled as often as OpenLDAP seems to.
If you don't want to, or don't need to maintain an uptodate openldap version, feel free to stick to your distribution, if you require support, ask your distribution maintainer or an appropriate mailing list of your distribution.
-Dieter
--On Thursday, March 18, 2010 8:46 AM -0400 Alex McKenzie alex@chem.umass.edu wrote:
I've been following the list for around a year, and I understand the difficulties involved in supporting old versions, but the simple fact is, most of us don't have time to custom compile all our server software. My Ubuntu-default installs of Apache, postfix, SSH, and just about everything else work fine and can be supported by their developers. It's only LDAP (and a few things in beta) that absolutely have to run the newest version at all times. I chose to accept a limited feature-set and bullied GnuTLS into working "well enough" for our limited LDAP environment, but if I ever find an alternative, I'll be moving away from LDAP to whatever that is.
For a moment, consider our frustration. Debian/Ubuntu, because of their issues with the OpenSSL license, build against GnuTLS. Which is a known security risk (http://www.openldap.org/lists/openldap-devel/200802/msg00072.html), and also known to have tons of problems in working with OpenLDAP. RedHat built their OpenLDAP against BDB 4.3 at one point, even though this was a known bad version of BDB, and the configure script would deliberately quit if it was encountered, so RH hacked configure instead of bothering to study why this was a problem. Distributions also make specific decisions on how to compile OpenLDAP (i.e., which options to use), that are not always best suited to end users who want a production LDAP server.
While I agree most applications are easily and readily used with what is compiled by OS distributors. But as is stated in the FAQ, and which is a point people still continue to miss, is that the builds from OS distros are geared toward providing the LDAP libraries for other clients (such as postfix, etc). They are not geared towards running OpenLDAP as a production service. Which is why we recommend over and over and over again to avoid using them. If they happen to work for you great. If they don't, then either support requests need to be taken to the distro provider, or a build of the latest stable release needs to be used.
Consider your case, where you are using OpenLDAP 2.4.7, which was the first public experimental release of 2.4. Read over the change log at the hundreds, if not over a thousand at this point, bugs that were fixed since then. As to your note about adding new features, all new branches, like 2.4 was at the time 2.4.7 was released, are open for new features until development is stabilized and it is feature frozen. OpenLDAP 2.4 has been feature frozen for a very long time now. This is not an unusual development pattern.
So yes, if someone wants support for a problem they are experiencing, then they need to show that the problem exists in the current stable release. This also is not an uncommon practice. You may find it frustrating, but we find it frustrating to be inundated with requests for help on issues that were long ago fixed.
--Quanah
--
Quanah Gibson-Mount Principal Software Engineer Zimbra, Inc -------------------- Zimbra :: the leader in open source messaging and collaboration
В Чтв, 18/03/2010 в 12:45 -0700, Quanah Gibson-Mount пишет:
--On Thursday, March 18, 2010 8:46 AM -0400 Alex McKenzie alex@chem.umass.edu wrote:
I've been following the list for around a year, and I understand the difficulties involved in supporting old versions, but the simple fact is, most of us don't have time to custom compile all our server software. My Ubuntu-default installs of Apache, postfix, SSH, and just about everything else work fine and can be supported by their developers. It's only LDAP (and a few things in beta) that absolutely have to run the newest version at all times. I chose to accept a limited feature-set and bullied GnuTLS into working "well enough" for our limited LDAP environment, but if I ever find an alternative, I'll be moving away from LDAP to whatever that is.
For a moment, consider our frustration. Debian/Ubuntu, because of their issues with the OpenSSL license, build against GnuTLS. Which is a known security risk (http://www.openldap.org/lists/openldap-devel/200802/msg00072.html), and also known to have tons of problems in working with OpenLDAP. RedHat built their OpenLDAP against BDB 4.3 at one point, even though this was a known bad version of BDB, and the configure script would deliberately quit if it was encountered, so RH hacked configure instead of bothering to study why this was a problem. Distributions also make specific decisions on how to compile OpenLDAP (i.e., which options to use), that are not always best suited to end users who want a production LDAP server.
While I agree most applications are easily and readily used with what is compiled by OS distributors. But as is stated in the FAQ, and which is a point people still continue to miss, is that the builds from OS distros are geared toward providing the LDAP libraries for other clients (such as postfix, etc). They are not geared towards running OpenLDAP as a production service. Which is why we recommend over and over and over again to avoid using them.
You would better recommend to file a bug so that maintainers would finally consider recommendations of development team.
Also It's strange maintainers are not members of this list, isn't it? :)
If they happen to work for you great. If they don't, then either support requests need to be taken to the distro provider, or a build of the latest stable release needs to be used.
Consider your case, where you are using OpenLDAP 2.4.7, which was the first public experimental release of 2.4. Read over the change log at the hundreds, if not over a thousand at this point, bugs that were fixed since then. As to your note about adding new features, all new branches, like 2.4 was at the time 2.4.7 was released, are open for new features until development is stabilized and it is feature frozen. OpenLDAP 2.4 has been feature frozen for a very long time now. This is not an unusual development pattern.
So yes, if someone wants support for a problem they are experiencing, then they need to show that the problem exists in the current stable release. This also is not an uncommon practice. You may find it frustrating, but we find it frustrating to be inundated with requests for help on issues that were long ago fixed.
--Quanah
--
Quanah Gibson-Mount Principal Software Engineer Zimbra, Inc
Zimbra :: the leader in open source messaging and collaboration
On Thursday, 18 March 2010 13:46:38 Alex McKenzie wrote:
I'll be honest: while LDAP does what I need it to, and is the only tool I've found that works well for my purposes, this is why I'm constantly looking for another option. Just about every request for help I see come across this list gets an initial response of "Oh, well, you're one or two minor versions out of date. You need to update to the newest version before we can help you."
Well, you haven't personally asked any questions on this list in the past 15 months (AFAICS), and I have personally attempted to provide alternative answers to many questions which otherwise got the "upgrade before you bug us further" response, besides spending time and effort on providing up-to-date packages for two different distributions.
Software that unstable is not, in my view, really suited to a production environment. If the OpenLDAP developers -- who, overall, do an excellent job -- can't come up with a stable release every six months or so, there's a problem.
Well, the 2.3.x series was very stable for me in production. 2.3.43 has been running flawlessly for almost 2 years, and I switched to 2.3 at around 2.3.11 (and experienced one or two real bugs which were fixed during 2.3.x).
If you don't need the latest features from 2.4, it is also quite stable. The multi-master code has taken a while to reach stability, but you should really consider carefully if you *need* it. With OpenLDAP almost never failing, environments that can't afford a few minutes of downtime a year for critical kernel security updates should consider HA solutions instead of MMR.
If there are so many major flaws that running a month old version means it's unsupportable, that's an even bigger problem.
I've been following the list for around a year, and I understand the difficulties involved in supporting old versions, but the simple fact is, most of us don't have time to custom compile all our server software. My Ubuntu-default installs of Apache, postfix, SSH, and just about everything else work fine and can be supported by their developers. It's only LDAP (and a few things in beta) that absolutely have to run the newest version at all times. I chose to accept a limited feature-set and bullied GnuTLS into working "well enough" for our limited LDAP environment, but if I ever find an alternative, I'll be moving away from LDAP to whatever that is.
Maybe you should consider a different distribution, at least for your LDAP servers, or consider spending your time improving the Debian/Ubuntu packages.
And please -- nobody take this as an attack. I really do respect the OpenLDAP development team, and the people on this list do their best to help everyone, even those of us using old versions. I just question the long-term viability of a system that needs to be recompiled as often as OpenLDAP seems to.
As I showed, depending on the features you need, this isn't a necessity. And, even if it is a necessity, there's no reason you should need to do it yourself. That's what distributions are for.
<punt> All supported versions of Mandriva typically get the latest version of OpenLDAP in their backports repo within 2 weeks of the upstream source release. Rebuilds of those packages for Red Hat/CentOS 5 follow as and when I have time to build and upload manually. </punt>
Regards, Buchan
Maybe you should consider a different distribution, at least for your LDAP servers, or consider spending your time improving the Debian/Ubuntu packages.
May I throw in that pkgsrc works on Linux, too? Their stable branch (2009Q4) is at 2.4.19, while HEAD is at 2.4.21, so this will go into 2010Q1 shortly.
openldap-software@openldap.org
-
Alex McKenzie -
Buchan Milne -
Dan Pritts -
Dieter Kluenter -
Edgar Fuß -
Emmanuel Lecharny -
Howard Chu -
Kenneth Marshall -
Kurt Zeilenga -
Matheus Morais -
Michael Ströder -
Quanah Gibson-Mount -
Russ Allbery -
Покотиленко Костик