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

Re: Openldap version (proxy cache)

--On Monday, February 28, 2005 2:38 -0800 Howard Chu <hyc@symas.com> wrote:

> Owen DeLong wrote:
>> Well... Those people are mistaken, obviously.  However, there is the
>> question
>> of how much investment should be required to get basic functionality.
>> The
>> reality is that if we can't make OpenLDAP and PAM_LDAP with LDAP/S and
>> Kerberos
>> at least as easy to set up as Active Directory (blech), we're going to
>> have
>> trouble making progress towards a larger percentage of the installed
>> base.
> I agree with you, but this is the wrong audience for this point. The
> OpenLDAP project is for OpenLDAP, period. The pam_ldap/nss_ldap resources
> are devoted to them, period. OpenSSL is its own project, Kerberos has its
> own project(s). None of them have a mission goal of integrating into a
> kitchen-sink resource. There are other places to go for such things, like
> PADL's XAD and Symas CDS. In my opinion, it takes more experience and
> resources to do a good job of integration than most hobby-level open
> source developers are able to bring to bear, which is why this level of
> integration tends to only show up in commercial packages.
This is the part where I think that the directory/authentication
open source packages are different from just about every open
source project I participate in.  For example, the Xastir project
resources are pretty much devoted to Xastir, but, if you're having
trouble getting OpenMotif working or ImageMagick working on your
system in order to compile Xastir, the users list is an OK place
to ask about that.  They're happy to help and usually find a
solution for the person fairly quickly.  OpenLDAP is, in most
situations, useless without at least one of the other packages
you mention above (nss_ldap, Kerberos, mod_auth_ldap, pam_ldap, etc.)
All of these packages have dependency relationships one way or the
other, yet, none of them seem to be interested in helping users
make them talk to each other.  That's sad and it reduces the
usefulness of all of the projects.

Yes, doing integration correctly is tough.  Yes, right now, it's
beyond the scope of a lot of open source projects.  However, lots
of open source projects have professional resources dedicated to
them, and, there's lots of integration being done in a variety
of other areas.  Actually, the Fedora project has done a reasonably
good job of integrating openLDAP.  A cookbook on a decent user schema
(instead of vague statements about how wonderful it is that you
can make any schema you want to with LDAP) would go a long way to
simplifying the process.  I think that generally, most of the
actual hard integration is done.  What is missing is a HowTo
guide that shows a basic common solution that can be used by
90+% of the userbase, and, some friendlier LDAP browser/editor
front ends with reasonable prototype ACLs and decent security.

>> OTOH, as an experienced UNIX admin with some familiarity and knowledge
>> about directories in general, and, substantial knowledge of PAM,
>> Cryptography,
>> some familiarity with SASL, and some Kerberos experience, it took several
>> days of research, multiple books, many web searches, several emails, and
>> a fair amount of guess work to get to the point where I had a fairly
>> minimal
>> LDAP configuration working the way I wanted it to with PAM, NSS_LDAP,
>> and Apache for a relatively small userbase on a single machine.
>> Imagine how completely intimidating (and insurmountable) this would be to
>> the average first-time LDAP administrator?
> Things have improved. It would improve faster if more people contributed
> to building the knowledge base. Having participated on this mailing list
> for the past 7 years I see that in general, people come in, get a couple
> questions answered, and are never heard from again.
Well... You'll notice that I got a couple of questions answered, and, I
got more vocal AFTER I got my stuff working than I was before.  I'm trying
to be part of the solution, not part of the problem.  I'm not ranting
because I want to complain.  I'm honestly trying to point out the
pain threshold and offer ways I see that it might be reduced from a
user's perspective.

>> I'm not unrealistic about "free" software, and, I'm not opposed to
>> putting
>> a certain amount of time and effort into it.  However, when I've got what
>> seems like a working binary in my distro, I have to see some real
>> advantage
>> to going out and grabbing source and trying to build my own before I will
>> take it on.
> Part of the problem is that using the distro tends to isolate you from
> seeing the advantage of using newer source. I often run into people who
> have no inkling that anything newer than 2.0.27 exists, have no notion
> that www.openldap.org exists. If you simply looked at the release
> announcements on the web site the advantages would be self-evident, but
> it seems most people (who haven't found their way onto this mailing list)
> just have no idea.
Well... I admit that it took quite a bit of searching before I found my
way onto this mailing list myself.  The FAQ-O-Matic doesn't seem to
refer you to it if you're stumped.  The majority of the web searches
I did for answers to questions about OpenLDAP turned up lots of other
mailing list archives, but, not this one.  There's nothing I found in
the HowTOs that came with the distro that referred me to this list, and,
even though I went to OpenLDAP.org, the site didn't exactly provide a
convenient way to find that there was a good source of answers here.

Frankly, this list is probably the best kept secret in OpenLDAP support.

>> OpenLDAP is one of the most difficult, confusing, poorly documented
>> (this applies
>> to LDAP in general, actually), and generally cryptic open source
>> packages I've
>> ever dealt with.  Even with the copious debugging output it is capable
>> of generating,
>> I find it lacks many of the things I want to know about why things are
>> going
>> wrong (have you ever tried to debug an ACL based on dynamic groups or
>> sets?)
> (yes, as a matter of fact...)
>> and isn't overly clear about the things it does tell you.
> You are always welcome to contribute patches. Doc enhancements,
> suggestions for better wording, etc. are frequently integrated into the
> source base. I make a point of adding notes to the man pages / admin
> guide / FAQ whenever I stumble over anything. But I'm just one person,
> and I don't stumble often. It takes a lot more input from more sectors to
> create documentation that serves all those sectors.

Agreed.  Should I just send them to this list, or, is there a more
appropriate destination that I am as yet unaware of?  I can't do much
about contributing code, I'm not really much of a developer, and, frankly,
I don't understand much of the pieces of openLDAP I've looked at (I tried
once to add some debugging statements to sets.c, and, couldn't make
the software compile afterwards).  I'm working on a cookbook for
building a basic LDAP Authentication configuration on Fedora.  When I
get it finished, I'll pass it along.  Perhaps it will be considered worthy
of further reference or publication.  Perhaps it will be another one of
those things not sufficiently narrowly focused to be considered useful,
since it talks about LDAP, Apache, mod_auth_ldap, pam_ldap, nss_ldap,
openSSL, dovecot, running a CA, and, making all of the above work with
SSL and a Self-Signed Root Certificate.

As I said, I'm willing to contribute what I can, but, from my perspective
as an end user, until I found this list, openLDAP was like an elite
private club as far as I could tell.


Version: GnuPG v1.2.3 (Darwin)