> -----Original Message----- > From: Jonathan Marsden [mailto:[EMAIL PROTECTED]
> On 5 Mar 2003, Howard Chu writes: > > Note that OpenLDAP 2.0.X does not work with Cyrus SASL 2.1.x anyway, > > so you need OpenLDAP 2.1 if you're already using SASL 2.1. > I believe this general statement to be incorrect. As you've pointed out, I am a member of the OpenLDAP core team, and I know exactly what's in the OpenLDAP source code. > That combination certainly seems to work fine here, in a multi-server > multi-domain international directory and email deployment. OpenLDAP > 2.0.27 and cyrus-sasl-2.1.7 or -2.1.10 or -2.1.12 have all worked > (currently on Red Hat 7.3, on x86 SMP hardware). Please could you > provide specific details on how and why this "does not work"? Thanks. I suggest, since you haven't had any problems with your setup, that your OpenLDAP package was not built with SASL support. In fact, in OpenLDAP 2.0.26 we added a test to the configure script to *deliberately fail the build* if you attempted to use a version of SASL other than 1.5. We also added a runtime check to libldap to *fail to execute* if the wrong SASL library version is linked. This prevents picking up the wrong shared library, if all else fails. As has been explained many times on the SASL and OpenLDAP mailing lists, there was a huge change in the SASL API between Cyrus 1.5 and 2.1. It required a fair amount of rewriting/new code to make it work properly. Since the OpenLDAP 2.0 source stream has been in "bugfix only" mode for a while, none of that new code went in. Only OpenLDAP 2.1 has this new code. The biggest difference between the two is in memory management, and if you somehow manage to make OpenLDAP 2.0.27 build and link with Cyrus 2.1, you will have memory leaks/corruption/etc. errors everywhere. But as I said before, we changed the build environment to prevent such a build from succeeding. It is possible that RedHat and other packagers has patched their source trees to override the safety checks we built in, but I doubt it. Most likely you just don't have SASL linked into your OpenLDAP package. > Recommending that sysadmins 'throw away' the mainstream and well > understood way of doing something, in favour of the 'latest and > greatest', is not always appropriate. Working with bleeding edge > software, perhaps not available in the packaging format your chosen OS > distribution uses, is likely to be inconvenient at best, and lead to > increased maintenance costs over time. > > Red Hat 8.0 ships with OpenLDAP 2.0.27 too, so using that distribution > it may still be appropriate to stay with that version of OpenLDAP. > Even the current Red Hat 8.1 beta release, Phoebe, sticks with > OpenLDAP 2.0.27. I would guess that this is because RedHat and other OS distribution packagers simply haven't had time to update their distributions. The bloodstains on the "bleeding edge" dried up a long time ago and OpenLDAP 2.1 is well-documented to be both faster and more stable than any 2.0 release. By any measure, OpenLDAP 2.0 is obsolete, and even OpenLDAP 2.1 is in "bugfix only" mode now. By the way, Symas Corp. provides native packages of current OpenLDAP builds. (RPMs for Linux, SysV pkgs for Solaris, sw depots for HP-UX, etc...) So the issue of package availability and increased maintenance costs is invalid, I believe. (We provide OpenLDAP fully integrated with Cyrus SASL, OpenSSL, Heimdal K5. We also provide fully integrated pam and nss, even though I think pam_ldap is junk.) > It might also have been helpful to state that you are an OpenLDAP > developer, and so are naturally interested in getting people to > migrate to the current release of your software :-) I am naturally interested in creating the best possible solution for a given problem. Whether people use it or not is up to them, but when someone asks "what's the best way to do X?" I assume they actually want to know the best way. -- Howard Chu Chief Architect, Symas Corp. Director, Highland Sun http://www.symas.com http://highlandsun.com/hyc Symas: Premier OpenSource Development and Support