Hi all, First of all, I'll mention that I've read the information on the download page about "stable" vs "release" and I understand the difference. I've also read the FAQ-o-matic entries on the topic.
I'm working towards upgrading our OpenLDAP software (currently 2.3.24). Since we are utterly dependant on OpenLDAP for many things, policy is to go with "stable".
However, I noticed a few days ago that somebody said in another thread:
Look into syncrepl (make sure to upgrade to 2.3.30 first)
Are there problems with syncrepl in 2.3.27? Our plan is to move from slurpd to syncrepl with this upgrade. Perhaps the comment was simply made in the spirit of generally keeping up to date, but if there is a potential issue we'd like to know about it.
We operate a single master with about 80 identical replicas and some local schema additions, and have about 8000-9000 records. There's nothing particularly special or fancy about any of it as far as I'm aware. All running on Debian 3.1 except the master which is still 3.0 (upgrading RSN).
Thanks in advance for any insights.
Lesley W
Lesley Walker wrote:
Hi all, First of all, I'll mention that I've read the information on the download page about "stable" vs "release" and I understand the difference. I've also read the FAQ-o-matic entries on the topic.
I'm working towards upgrading our OpenLDAP software (currently 2.3.24). Since we are utterly dependant on OpenLDAP for many things, policy is to go with "stable".
However, I noticed a few days ago that somebody said in another thread:
Look into syncrepl (make sure to upgrade to 2.3.30 first)
Are there problems with syncrepl in 2.3.27? Our plan is to move from slurpd to syncrepl with this upgrade. Perhaps the comment was simply made in the spirit of generally keeping up to date, but if there is a potential issue we'd like to know about it.
Read the Change log http://www.openldap.org/software/release/changes.html
Look for "syncrepl"...
See http://www.openldap.org/software/release/changes.html
[2.3.31 fixes] Fixed slapd syncrepl logging (ITS#4755)
[2.3.30 fixes] Fixed slapd syncrepl consumer memory leaks (ITS#4746)
[2.3.29 fixes] Fixed libldap use keepalive for syncrepl (ITS#4708) Fixed slapd syncrepl modrdn new superior (ITS#4695) Fixed slapo-syncprov deadlock (ITS#4720)
Now, these are just the changes that say 'sync'. There are other likely relevant changes, such as a hdb livelock (#4738), that are fixed after 2.3.27. Quite a few of these changes are based off actual production impacting-bugs found at our various sites (new features are headed towards 2.4/HEAD, not 2.3). Can any of us say with certainty that you're going to run into these issues? Of course not. But if you _do_ run into those issues, it's going to feel pretty silly to have chosen to upgrade a few minor releases off from the already-known fix...
Aaron Richton wrote:
Thanks, I should have thought of that myself (d'oh!)
Can any of us say with certainty that you're going to run into these issues? Of course not.
I'll read the ITS notes which hopefully will help us to judge their relevance to our setup.
But if you _do_ run into those issues, it's going to feel pretty silly to have chosen to upgrade a few minor releases off from the already-known fix...
Absolutely! It would feel even sillier if I hadn't asked the question, too.
But it would feel equally silly if we went with the latest release and encountered a new bug that appeared since the "stable" release that just happened to be triggered by something that turned out to be weird in our environment and nobody else noticed it before. :-)
Thanks for the comments, I appreciate your time.
Lesley W
--On Thursday, December 21, 2006 6:35 PM +1300 Lesley Walker lesley.walker@opus.co.nz wrote:
But it would feel equally silly if we went with the latest release and encountered a new bug that appeared since the "stable" release that just happened to be triggered by something that turned out to be weird in our environment and nobody else noticed it before. :-)
Since new point releases are regressions against the last release (i.e., bug fixes for bugs found since that last release, as opposed to new features), the likely hood of this occurring is minimal. Not to say that it isn't possible that a bug fix may introduce other issues, but that is generally unlikely. What not running the latest release generally means though, is that if you encounter a problem, the first response to that issue if you ask for help is most likely going to be *upgrade* to the latest release and then verify it occurs there. So, why not just run the latest one? ;)
--Quanah
-- Quanah Gibson-Mount Principal Software Developer ITS/Shared Application Services Stanford University GnuPG Public Key: http://www.stanford.edu/~quanah/pgp.html
Quanah Gibson-Mount wrote:
So, why not just run the latest one? ;)
As Lesley wrote in his first e-mail:
Since we are utterly dependant on OpenLDAP for many things, policy is to go with "stable".
At the moment in the 2.3 release branch the stable tag should IMO be officially forwarded to the last releases. It's way behind the current recommendations on the list. IMO the current situation is confusing for deployers.
Ciao, Michael.
--On Thursday, December 21, 2006 12:37 PM +0100 Michael Ströder michael@stroeder.com wrote:
Quanah Gibson-Mount wrote:
So, why not just run the latest one? ;)
As Lesley wrote in his first e-mail:
Since we are utterly dependant on OpenLDAP for many things, policy is to go with "stable".
At the moment in the 2.3 release branch the stable tag should IMO be officially forwarded to the last releases. It's way behind the current recommendations on the list. IMO the current situation is confusing for deployers.
Yeah, my point is that I generally find the "stable" tag misleading, in that the revision often marked "stable" is known to have any variety of issues. In particular right now, there is a known DoS vulnerability in 2.3.27, which to me means in no way would I even deploy it, since there's an existing exploit. The general policy Lesley is using I think is flawed. ;)
Stanford, obviously, uses OpenLDAP heavily, and there are literally hundred of applications, as well as all email delivery to @stanford addresses, that depends on it. My job is to ensure it is available 24/7. Thus, I monitor the dev & software lists, CVS commits, etc, to make sure that I'm very aware of what is happening, so that I can provide the best service possible to my clients.
--Quanah
-- Quanah Gibson-Mount Principal Software Developer ITS/Shared Application Services Stanford University GnuPG Public Key: http://www.stanford.edu/~quanah/pgp.html
Quanah wrote:
Yeah, my point is that I generally find the "stable" tag misleading, in that the revision often marked "stable" is known to have any variety of issues.
According to the FAQ: | The term "stable" refers to the last "general use" release | that has demonstrated itself as being reliable in real | world environments.
I'm curious. How is that tested, and whose "real world environments" provide the litmus test?
In particular right now, there is a known DoS vulnerability in 2.3.27, which to me means in no way would I even deploy it, since there's an existing exploit.
In your environment that makes a lot of sense. In mine, that would be less of a concern.
The general policy Lesley is using I think is flawed. ;)
The policy is based on comments such as the above quoted from the FAQ. Personally, I feel a little nervous about rolling out a 4-points-old release. My employer feels nervous about rolling out a newer release that hasn't had as much real-world bedding-in time, and I can see his point.
The outcome is that we will continue to go with "stable". We will easily be able to roll back to our current release if there are problems that are immediately evident. But I may well build a later release and have it on hand "just in case".
Thanks for input, everyone.
Lesley W
On 12/21/06, Lesley Walker lesley.walker@opus.co.nz wrote:
Quanah wrote:
Yeah, my point is that I generally find the "stable" tag misleading, in that the revision often marked "stable" is known to have any variety of issues.
According to the FAQ: | The term "stable" refers to the last "general use" release | that has demonstrated itself as being reliable in real | world environments.
I'm curious. How is that tested, and whose "real world environments" provide the litmus test?
In particular right now, there is a known DoS vulnerability in 2.3.27, which to me means in no way would I even deploy it, since there's an existing exploit.
In your environment that makes a lot of sense. In mine, that would be less of a concern.
The general policy Lesley is using I think is flawed. ;)
The policy is based on comments such as the above quoted from the FAQ. Personally, I feel a little nervous about rolling out a 4-points-old release. My employer feels nervous about rolling out a newer release that hasn't had as much real-world bedding-in time, and I can see his point.
The outcome is that we will continue to go with "stable". We will easily be able to roll back to our current release if there are problems that are immediately evident. But I may well build a later release and have it on hand "just in case".
Thanks for input, everyone.
I think 2.3 was feature-frozen a while ago (2.3.20?), so everything is now bug-fixes. This bit of knowledge might make rolling out the more current version sit better.
openldap-software@openldap.org
-
Aaron Richton -
Howard Chu -
Lesley Walker -
matthew sporleder -
Michael Ströder -
Quanah Gibson-Mount