[Date Prev][Date Next] [Chronological] [Thread] [Top]

Re: Openldap version (proxy cache)

Owen DeLong wrote:

Guess it depends on your environment. In a university where you can depend
on having an abundance of users with malicious intent and too much time on
their hands, such exploits are common place. In a business, OTOH, where you
have limited administrative resources and the LDAP server needs to be
a functional unit, not a hobby/project, a precompiled working server is
often very desirable, even with a few bugs as you describe. Sure, the latest
greatest stable CVS release is desirable, but, compiling openLDAP from scratch
is not for the timid. It has gotten better, but, between the large list
of documented dependencies and the not-so-well-documented dependencies
of those packages, it can take quite a bit of effort to get to the point
where you can actually build OpenLDAP. Then, the myriad configure options
required just to get an installable SLAPD can take a fair amount of time
to digest.

In a lot of instances, it's well worth the time tradeoff to just accept
that although a bit behind, the Fedora team has taken care of building the
things most people need into a working slapd in a precompiled package with
a reasonable default slapd.conf.

Again, YMMV, but, it is very clear to me that a lot of the LDAP community
just sort of seems to assume that everyone has infinite time to invest in
dealing with LDAP.  This simply isn't the case in the real world.

I see the situation you're looking at a bit differently... A lot of people seem to assume that because the software was bundled on their OS distro, it's both (a) suitable and (b) ready for use. They assume that they can just switch it on without investing anything into its operation. Just like people tend to misinterpret the "Free" in "Free Software." The fact is that any tool requires an investment on the part of the user. An investment of time to learn how to use it, time to set it up, and time to maintain its regular operation. There is seldom any real substitute for this investment; a distro packager may mitigate some of the setup time, but the end user still must cover the learning and the maintenance. Frequently a cost/benefit analysis will show that it's better to invest money into applying someone else's time to the situation, rather than spending your own (irreplaceable) time. At this point a lot of people stumble, again because they expect all of this to work "for free." And *that* simply is not the case in the real world.

 -- Howard Chu
 Chief Architect, Symas Corp.       Director, Highland Sun
 http://www.symas.com               http://highlandsun.com/hyc
 Symas: Premier OpenSource Development and Support