[Date Prev][Date Next]
[Chronological]
[Thread]
[Top]
RE: Answering frequently asked questions
I agree. I'll add to it, in 2+ years, I still can't figure it out.
Sticking points were/are:
(1) Generating CERTS (you mean the comment / common name is *extremely* important?)
(2) what does what and how?
(a) pam?
(b) gssapi?
(c) kerberos?
(3) how to know *what* you're supposed to do.
Basically, one can get an individual component of the entire whole and fiddle with it - and perhaps
even get this single component to compile (!!) and perhaps even do something. But how does one
combine the parts? How does one combine the parts and yet be able to test each component?
I've seen docs that say "follow this magic recipe to the letter and you'll have a working system"...
well, it might have worked for the author - or the working system might be what the author needs,
but if you change any one thing - it breaks, etc.
Better/proper error codes... that perhaps reference a correct manual or faq or url or ANYTHING.
Should one really have to be a kernel coder just to install this app?
A document that does this would be great:
(1) Here's how to compile/install/configure openldap.
(2) Here's how to use/test/break/unbreak openldap
(3) Here's an example how to integrate this system into
(a) sun/solaris password/group/netgroup/automount/motd
(b) micros* active directory!!!
(c) tru64 password/group/netgroup/automount/motd
(d) redhat/suse password/group/netgroup/automount/motd
(e) freebsd password/group/netgroup/automount/motd
(f) OSX password/group/netgroup/automount/motd
(g) otherOS otherFile
(4) Here's how to get/compile/configure kerberos
(a) here's why you'd want to use MIT
(b) here's why you'd want to use heimdal
(5) Here's how to use/test/break/unbreak kerberos
(6) Here's an example how to integrate kerberos into
(a) sun/solaris password
(b) etc
(7) Here's how to combine kerberos and openldap
I'm sure I'll be told that kerberos is not appropriate for this list, blah blah blah.
You know, I use to live out west where the phone company was "US West" -
perhaps the worst phone company around. I had a 25 phone lines from my
apartment to a 66 punch down at the dmark and US West had a 66 punch-down
at the dmark, but my contractor wouldn't link 12 inches from my 66 punchdown
to the US West one, and vice versa... each claimed it was the other's responsibility.
I can't write docs like the above, because I haven't ever been able to get a
working system... by the time I get anything working - the underlying code
has changed and I basically have to start from scratch.
Basically, with old SunOS, you could read a single man page, and turn on
NIS. With NIS+, you had to jump through a bunch of hoops, but for a flat
hierarchy, it was mostly painless. For LDAP? You either get something
pre-configured by someone else that works, or you hire out to get it done.
I don't want to go on and on rehashing what appears to be well known...
but I could. It would be all too easy.
Scott
-----Original Message-----
From: Tony Earnshaw [mailto:tonye@billy.demon.nl]
Sent: Monday, December 22, 2003 4:24 AM
To: openldap-software@OpenLDAP.org
Subject: Re: Answering frequently asked questions
lør, 20.12.2003 kl. 16.18 skrev Pierangelo Masarati:
> The first type is always ahead of code (unless expired,
> deprecated or so), the last type always lags behind.
>
> That's why Howard insists in telling you to read the code.
> In a perfect world, each release, even minor, would be based
> on carefully examining well thought documents of the first
> type, and come along with fully up-to-date documentation
> of the second type.
>
> Since this doesn't even happen for commercial software,
> despite the price you may get charged for, don't expect
> it from open-source projects.
I know it's not fair picking and choosing a single point, possibly out
of context, from a comprehensive set, but the above argument fails on
its own inconsequentiality. Like "it's rubbish". Your answer is simply
an excuse for having done something badly.
Examples of Open Source projects that provide excellent and
understandable documentation (and for many, the mailing list users are
told to read the docs before posting questions) are:
- Postfix, where the developers produce patches for the docs along with
code patches;
- Exim, where the docs (spec.txt, NewStuff) are completely reviewed with
each minor change;
- mod_apache/ssl, which surely has the best documentation available
anywhere;
- Apache itself;
- kernel.org kernel docs;
- The newer ISC BIND (9.2.3 is the latest, and the one I use from
preference),
etc. etc.
Arguably, the hardest part of Openldap to understand and implement for
mortals (apart from difficulties with compiles on non-standard OSs) are
the ACLs. Good and understandable docs *are* needed badly. If no-one but
the developers are capable of writing these in clear and good English,
then the developers should write them *and* have the result vetted by a
native English speaker - preferably a "tame" documentation expert.
No way can you shove the blame for not understanding the implementation
of the tools you supply in Openldap onto the end user by telling
[him|her] to read the code (why have any docs, man pages in the first
place? "Just read the code, man!"). To do so smacks of the sort of very
bad excuse that one might expect from a juvenile.
--Tonni
--
mail: billy - at - billy.demon.nl
http://billy.demon.nl
________________________________________________________________________
This email has been scanned for all viruses by the MessageLabs Email Security System.
________________________________________________________________________
This mail message originated outside Commerzbank via the Internet. As a result, the sender's address is not verifiable.
**********************************************************************
This communication is confidential and is intended only for the person to whom it is addressed. If you are not that person you are not permitted to make use of the information and you are requested to notify Commerzbank Aktiengesellschaft, New York Branch immediately that you have received it and then to destroy the copy in your possession. Views expressed in this e-mail do not necessarily reflect the views of Commerzbank AG.
**********************************************************************