[Date Prev][Date Next]
Re: cn=config example
> >> I've often thought about this, as Samba do similar at:
> >> http://wiki.samba.org/index.php/Main_Page as do other major OSS projects.
> > But, then if we look at a page relevant to *this* project, you get something
> > like:
> > http://wiki.samba.org/index.php/Samba_%26_LDAP#Setting_up_PAM_and_NSS_to_use_LDAP
> > Which is incomplete, misleading, and wrong on all distributions but SUSE.
> > Or, you follow links on some of the other resources that have been posted in
> > this thread, and you get something like this:
> > http://fedoranews.org/mediawiki/index.php/How_to_setup_and_maintain_OpenLDAP_server_for_your_network#Scripts_to_make_your_life_easier
> > or this part:
> > http://fedoranews.org/mediawiki/index.php/How_to_setup_and_maintain_OpenLDAP_server_for_your_network#Testing
> > And, they missed the usual advice of editing migrate_common.ph (instead of the
> > easier method of setting the LDAP_BASEDN environment variable), by only using
> > the dc=example,dc=com example, thus ensuring all other users will be confused
> > later:
> > http://fedoranews.org/mediawiki/index.php/How_to_setup_and_maintain_OpenLDAP_server_for_your_network
The date on the aforementioned page is also "2005-10-25", so it is
pretty darn old. I've got no problem with people publishing anything
they want, but it is also reasonable to expect people [users, certainly
administrators] to pay attention to things like published date. I have
an owner's manual for my 1919 Model-T Ford, but I don't expect it to be
helpful in fixing my 2007 Ford Mustang. If a reader ignores the fact
that a document is stale it is no ones fault but the readers, and if
they complain about it they should be dope slapped.
> Appreciated comments, but these projects *never* come to us and ask us
> to review anything. Are we expected to spend all our time reviewing and
> editing others work?
> >> Here are the issues with your appreciated suggestions:
> >> 1. The OpenLDAP project do not support 3rd Party software
> > While I don't have a problem with this, the question is why should this
> > prevent OpenLDAP project documentation (with suitable disclaimers) from
> > covering how to allow OpenLDAP to support other LDAP client software.
> But how many times do we need to cover it? No matter what client or
> software using a Directory, it's always the same; custom schema (give or
> take), relevant indexes and ACLs etc. Another client, another day.
Exactly. If you understand LDAP *AND* the service you are configuring
(Samba, NSS, PAM, RADIUS, etc...) then *MOST* stuff is pretty obvious
and even drearily redundant after awhile. What I see is that allot of
people want to skip one or both sides of the equation - if they want to
do that they should hire a consultant.
> > For
> > example, the only documentation available for configuring Solaris for using
> > LDAP for user/group accounts assumes you use JES LDAP. Sun certainly isn't
> > going to write any, and I would like to put the details somewhere before I
> > forget them.
> But isn't that the duty of the authors of said software that provide
> this functionality.
> >> 3. We have to find the time to fight the wiki spam
> > Not if you limit contributions to authenticated users. And there is the LDAP
> > authentication plugin for mediawiki ...
> Yes, we could do invite only or get a new contributor to justify their
> addition. But again, we have a great FAQ system for this.
Ditto, there is a FAQ.
> >> 4. We have to find the time to keep the howtos updated
> > As the scratchpad wiki proves, I don't have *much* time ... but if a few
> > people can spare a small amount of time, it may be viable.
> We all seem to think we don't have a system in place for this, namely
> the FAQ. I've only mentioned a wiki, as people are talking about it.
> We've had the FAQ for years and years now, but people are still shy.
Maybe if we just rename the FAQ and call it a Wiki then people will be
> >> 5. Resources, lack of resources, need more resources.
> >> 6. etc.....
> >> *My* first and foremost priority is to finish the Admin Guide, keep it
> >> accurate and up to date.
> >> I think, as we have done all along, we leave the 3rd party integration
> >> to the 3rd party projects (like the wiki mentioned above).
> > Which obviously isn't doing such a great job.
It has worked for me any many others. I've migrated almost all our
services to use OpenLDAP.
> > Or, is this
> > an area nss_ldap should cover (including the indexes, ACLs etc. that should
> > be configured on the server side)?
Yes, it is.
> >> What we don't
> >> want is a wiki where people come along and start posting How tos that we
> >> don't have time to vet, which in turn starts to dilute the OpenLDAP
> >> quality brand and take our time away with the little resources we have.
> > It may be better than having hundreds of howtos out there in random places of
> > much worse quality, leaving the impression that the OpenLDAP project prefers
> > this to one authoritative place, where at least contributors or experts can
> > correct mistakes (which we can't do for all the broken howtos).
What i don't understand is that (a) there is an official place for Samba
documentation (b) there is an official place for PAM documentation (c)
there is an official place for NSS documentation (d) there is an
official place for ISC Bind documentation (e) there is an official place
for ISC DHCPd documentation (f) there is an official place for Cyrus
IMAPd documentation........... so what is the problem? Either (1) the
user chose not to look in the official place or (2) the project chose
not to provide documentation related to LDAP. #1 is the user's problem
and for #2 the user should contact that project, not complain to their
If the user chose to look in "random places" they must expect
documentation of "random" quality.
> >> It's all very good having in depth guides, but sometimes it's better to
> >> get something running and come back to the main docs.
Disagree; that is just a sloppy approach to system administration.
Adam Tauno Williams, Network & Systems Administrator
Consultant - http://www.whitemiceconsulting.com
Developer - http://www.opengroupware.org