Craig wrote:
That comment was an inference from several web pages that I read. After Quanah's reply, I reread the man page for slapd and it's right there at the top.
Also, his comment about auditlog and accesslog overlays were cool. I'll look at those.
Thanx everyone for the help. (My apologies that most of it was RTFM.)
Same old story. You get perfectly good (and usually accurate) docs bundled with the source code. Why people start by searching the web, which is only going to return inaccurate/outdated cruft, written by people who aren't intimately familiar with the subject matter, just doesn't make any sense, and it really discourages/frustrates/pisses off those of us writing the docs (and the code).
I get a lot of complaints (mostly private, some public) for essentially telling people RTFM. Fact is, when I say it, it is the most appropriate statement. It's ok to ask a question, but to protest and reject the answers you get when they are complete, true, and accurate, is the height of unmitigated arrogance.
(Craig, this is not directed at you. Just that your email triggered this line of thought that's always percolating here anyway.)
Ignorance isn't a particular crime of course, nobody can know everything. But for the most part, LDAP is for sysadmins, and sysadmins have to have problem solving skills to be able to perform their jobs. It's not about knowing everything, it's about knowing how to find out what you need to know. That means knowing efficient processes for finding answers - knowing where to look, how to look, or how and what to ask.
When you're looking for a software feature, the manpages and Admin Guide should be your first resort. Pretty much every feature is documented. Some features exist that are undocumented; most of them are intentionally so, so don't give them a second thought. A web search should be your last resort.
When you're looking for info on a software failure, it's unlikely to be in any documentation. (Obviously, if we knew about the failure, we would fix it, not write a manpage about it. We don't call "bugs" "features", we fix them.) Here a web search probably should be your first or second stop. (Searching the mailing list archives would be the first stop, but most times Google is kind enough to do that for you.)
When a feature in the documentation isn't clear enough to you, it's fine to ask on the mailing list, but even better is to submit an ITS pointing out exactly what isn't clear. Sometimes we see problems on the list that we feel strongly enough about to fix without waiting, but ultimately someone needs to submit a bug report so that the problem and its resolution can be tracked.
Life is short, time is limited for every one of us. Make the most of the time available to you, don't waste it.