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

Re: BINDDN in ldap.conf

Craig White wrote:

No amount of documentation will make up for people who don't read it, and people who skim are more likely to miss even more as the volume of documentation increases.

you are assuming that those who read that, understood what the context
of 'user' was - I most assuredly did not until now. Unfortunately, many
of use don't come from UNIX backgrounds and though pick up on many
things, some things which seem basic to you guys elude us for some time.

I am one of those idiots that never understood that BINDPW in ldap.conf
didn't work.

Even in this email thread people are demonstrating their lack of attention to detail. The topic of this thread is BINDDN. BINDPW is not a part of this discussion. This is not even a matter of *understanding* simple English, it's a matter of actually *reading* the words on the page in front of you. All this merely underscores my initial point, above.

For the record, OpenLDAP software does not support a "BINDPW" keyword at all. Not in ldap.conf nor in .ldaprc. It has never supported such a keyword, in any version.

In fact, the default /etc/ldap.conf on every Red Hat system
that I have looked at actually references the variable - which leads the
unwashed like me to believe that it might actually work. I don't know if
that variable comes from (or came from) the openldap client
/openldap.com but I would bet that it does.

Anyone who's been watching this list for more than a few weeks should by now realize that what Red Hat does with OpenLDAP in no way resembles what a competent OpenLDAP administrator would do. The fact that they blithely mix non-OpenLDAP config directives with OpenLDAP software is an issue for you to take up with them, it's not under our control. One might make a case that the OpenLDAP Foundation should take an interest in what other organizations are doing with OpenLDAP software, insofar as poorly packaged distributions reflect poorly on the Foundation even though the Foundation was not responsible for creating the packages in question. But that's fodder for a separate discussion.

Thank you for this discussion as it has clarified some issues for me and
I appeal to Kurt and Howard to look gently towards those of us who are
ignorant and yet eager to do things right.

I hear what you're saying. Everyone has to start somewhere. But people who blame their troubles on poor documentation should suggest how to fix it. This is what's commonly called "constructive criticism" and it's a major force in improving any project.

People who blame their problems on missing information, when the info is in fact present, really have only themselves to blame.
-- Howard Chu
Chief Architect, Symas Corp. Director, Highland Sun
http://www.symas.com http://highlandsun.com/hyc
Symas: Premier OpenSource Development and Support