On Tuesday 27 May 2008 10:17:12 pm Russ Allbery wrote: > Jorge Armando Medina <jmedina@e-compugraf.com> writes: > > Why do you say the openldap version shipped with RHEL5.x is not usable > > as a server?, I don't use RHEL as my main directory server, but I would > > like to know why you affirm that. > > Even speaking as someone who helps (when he has time) to maintain packages > for a Linux distribution, for a serious server installation you are > probably best-off building OpenLDAP yourself or at least being prepared > to. You can do that based on the packaging done by your distribution, > ideally, but you still want to be prepared to update to the latest > release. > > I'd love to be able to provide a server with Debian releases that everyone > could just use always, but realistically, it's very difficult to do. > OpenLDAP is extremely well-maintained and vigorously-maintained software, > and it's also very complex software, which means that any given release at > any point in time has a potentially fairly significant set of undiscovered > bugs (not to mention missing new important features). When making a Linux > distirbution, you necessarily have to pick some release and freeze. That > freeze point is generally chosen by some distribution release schedule > rather than by anything related to OpenLDAP's development, and hence can > often accidentally pick a bad version. But more to the point, after that > freeze point, OpenLDAP moves on and the distribution cannot and still > maintain its stability guarantees. > > Distributions have a real challenge around fast-changing, > vigorously-maintained software, which is that upgrading to newer versions > is often desireable but also means introducing change into stable > releases, which is exactly opposite to the point of release stability. > Debian in particular takes a very hard line with this, keeping its stable > distribution extremely stable and only updating it for security > vulnerabilities and very significant bugs. In a lot of situations, this > is what you want -- for example, in practice, it works fairly well for the > client libraries. However, for the server, that means you get a server > with a fairly large collection of known bugs, none of which are completely > debilitating, but all of which collectively are often more than you should > have to deal with. > > Furthermore, just because Red Hat, or Debian, or Ubuntu, or any other > distribution picked some OpenLDAP version that happened to coincide with > their release cycle, that doesn't mean that the OpenLDAP project should > have to support it forever. That isn't at all fair to the OpenLDAP > developers, who have moved on and fixed all those bugs and are now working > on other things. That means that when you're running the distribution > version, you're frequently not running something that anyone on the > OpenLDAP lists can really support, and the first step in getting to a > supportable installation is to upgrade to the latest version. Again, the > server tends to be more of an issue than the client libraries simply > because it changes more. > > What this realistically means is that I hope that the server that ships > with any given Debian stable release is useful for small projects, small > sites, and people who just need a simple LDAP server, and hence aren't > likely to exercise most of the edge cases where bugs have since been > fixed. However, if you have a large site, a complicated installation, or > problems for which you need to seek help here, the first thing people are > likely going to want you to do is to update to a current version, and > that's entirely reasonable. Thank you Russ, that explanation really gave me more bases for not using redhat :D. But that takes me to the next question, if a lot of programs or even libraries are linked agains openldap's libriries, what happen when you install openldap from source? do you have to recompile this programas against the new openldap libraries? because if that is the case that would happen with all the distributions that support openldap. -- Jorge Armando Medina Computación Gráfica de México Web: www.e-compugraf.com Tel: 55 51 40 72 email: jmedina@e-compugraf.com GPG Key: 1024D/28E40632 2007-07-26 GPG Fingerprint: 59E2 0C7C F128 B550 B3A6 D3AF C574 8422 28E4 0632
Attachment:
signature.asc
Description: This is a digitally signed message part.