Tom Emerson <[EMAIL PROTECTED]> wrote:
> "...if no attribute (exists) then this attribute is added..." pretty much
> contradicts the theory "there is NOTHING in there which would make anyone
> believe attributes can be added to the incoming request",
If the wording is misleading or confusing, then it needs to be
updated. As I said before, I'm willing to to this.
> I think one thing that trips people up is the word "attribute" being used to
> describe different things, and you going ballistic over the fact that end
> users haven't mentally seperated the two meanings out in their head
> like you have.
Trust me, you haven't seen me go ballistic yet.
> You may have an almost religious conviction over not helping those
> who do not read, but you've got to realize "reading" alone is half
> the battle - comprehension must exist for the "reading" to have been
> of any use. Further, the fact that a particular person doesn't
> comprehend what you have written is not always an indication of that
> person's abilities, but often indicates what is written is not
> clear. [like this paragraph :) ]
Then suggest fixes for the parts of the documentation which are
confusing or misleading. Adding entries to the FAQ to counter
misleading "man" pages is less useful than fixing the source of the
problem.
> You have an almost dictionary-like definition of these, which may be fine for
> many people, but since this question DOES come up from time to time, not
> everyone sees the connection right off. Personally, I'd like to see a list
> of ALL attributes along with an indication of "this is an attribute to check
> against" or "this attribute is returned in the response". [and yes, I know
> the standard answer to THAT question is "buy the book (from amazon so we get
> the kickback)"]
The book documents only the RFC RADIUS attributes, not the
FreeRADIUS internal configuration attributes. In addition, if you go
to 'doc/rfc', and do 'make', you will get cross-referenced HTML
versions of the RFC's, which the book *doesn't* have. And the
following web page has a complete list of RFC attributes:
http://www.freeradius.org/rfc/attributes.html
I, too, would like to see a fully documented list of FreeRADIUS
configuration attributes. But since I know what they are, it's less
of a priority for me. And no one else has bothered supplying even a
partial list for inclusion in the documentation.
> OTOH, pointing out "common misconceptions" has its place as well. Part of
> what I snipped was your comment that "...people are hyper-afraid of stating
> their end goal..." I suspect in some (many?) cases a lot of people simply
> don't know what their "goal" is in the first place
Let me re-phrase that: They don't know the methods which will help
them solve their problems. My responses (unhelpful as they may seem
at times) are guided by the intent to help people solve the *root*
cause of many of their problems: bad methods.
People who have good methods usually get a one-line response like
"read this", or "yes", or "I'll add a patch tomorrow". Strangely,
they don't complain. But the first group of questioners usually
complains loudly about my answers. It's almost like they don't *want*
their problems to be solved.
Alan DeKok.
-
List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
