On Tuesday 27 May 2008 11:09:30 am Quanah Gibson-Mount wrote:

--On Tuesday, May 27, 2008 5:01 PM +0530 Aravind Arjunan

aravind.arjunan@gmail.com wrote:

...

hi,

am configuring openldap 2.3 in RHEL 5 operating system. I need the configuration file for master and slave slapd.conf file for reference.

I suggest you read the documentation.

I also suggest you install your own openldap and not use the version shipped with RHEL5, since it is not usable as a server.

Hi Quanah,

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.

Thanks

--Quanah

--

Quanah Gibson-Mount Principal Software Engineer Zimbra, Inc

---

Zimbra :: the leader in open source messaging and collaboration

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.

Jorge Armando Medina jmedina@e-compugraf.com writes:

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.

In general, for Red Hat, you probably want to keep using the system LDAP libraries for all the clients and only use the new libraries for the LDAP server. You have to be careful about any clients that would get loaded into the server's namespace (libnss-ldap is the most common possible culprit, but I think Red Hat links it statically to avoid this) since otherwise there will be conflicts. So basically you install the server and its libraries in a different path and things will usually just work.

It would be very nice if the OpenLDAP libraries supported and used symbol versioning to make this somewhat more robust.

Howard Chu hyc@symas.com writes:

Russ Allbery wrote:

...

It would be very nice if the OpenLDAP libraries supported and used symbol versioning to make this somewhat more robust.

symbol versioning isn't a portable or universal concept.

True, you need Autoconf logic to only use it where available.

The entire issue is outside our scope anyway, since it's a packaging matter.

Hm, well, that's contrary to the stance taken by most other library maintainers. Symbol versioning is generally the responsibility of the maintainer of the library since they're in full possession of information about the expected public ABI. For example, both MIT Kerberos and Heimdal use symbol versioning in their libraries and maintain it as part of the project.

Among other things, maintaining the symbol versioning as part of the OpenLDAP library build process means a consistent ABI across different Linux distributions, whereas treating it as a packaging matter and having distribution packagers introduce symbol versioning independently (which I assume is what you mean by a packaging matter -- maybe I'm confused?) doesn't provide that guarantee.

Symbol versioning is particularly useful for OpenLDAP since the OpenLDAP libraries have regular SONAME changes (one for every major release), which means that having two versions of the library around temporarily during transitions and upgrades is common. It's also very useful given the recommendation to not use the distribution packages, since it lets two different OpenLDAP libraries coexist on the system safely even if (through dynamic loading or plugins) both are loaded into the same process namespace. As more libraries and programs support plugins and dependency chains get longer and more complicated, it's increasingly tricky to avoid that entirely.