On Saturday 19 July 2003 8:13 am, Alan DeKok wrote: > "Alexander M. Pravking" <[EMAIL PROTECTED]> wrote: > > > SOME attributes can be set: configuration items. Some cannot be: > > > attributes in the request. > > > > Alan, could you please describe the difference between them and put it > > in the FAQ? > > See the 'man' page for the 'users' file. The document described how > the 'users' file is processed. There is NOTHING in there which would > make anyone believe that attributes can be added to the incoming > request.
Hmmm...
$ man 5 users
[...]
OPERATORS
Additional operators other than = may be used for the
attributes in either the check item, or reply item list.
[...]
Attribute := Value
Always matches as a check item, and replaces in the
configuration items any attribute of the same name.
[emphassize]
If no attribute of that name appears in the request,
then this attribute is added.
[/emphasize]
As a reply item, it has an identical meaning, but for
the reply items, instead of the request items.
"...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", or am I reading
this wrong? Or perhaps the text for "+=" is misleading as well when it says
"always matches and adds the attribute..."
Now, if your going to gripe about the fact I cut off the quote before it said
"...to the list of configuration items", consider that the "question" posed
was "SOME attributes can be set: configuration items. Some cannot be:
attributes in the request." ... "could you please describe the difference
between them and put it in the FAQ?"
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. 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 :) ]
As much as I hate to say it, as a software & support supplier, you MUST endure
the "dumb" questions -- in fact, they are often more important than the
involved questions because they indicate errors in the documentation [and
writing for people is far harder than writing for computers -- a computer
will either understand or it won't, and if it doesn't, you get immediate
feedback (a syntax error); OTOH, a person may understand something OTHER than
what you meant, but won't give any "feedback" that they might not have
understood what YOU meant.]
The thing is, you will NEVER get a 100% "correct" document. The worse part
about the whole process is that the closer to 100% you get, the more "dumb"
questions you're going to have to field -- your two standard answers are
"it's in the document" or "(free)Radius doesn't do that to begin with". As
more and more people begin to understand "the document", you get fewer and
fewer of those questions, leaving you with relatively more "it isn't designed
for that" questions instead.
[...]
> > Q. What are request attributes?
> > Q. What are config/check items for?
>
> This is covered in the 'man' page for the 'users' file.
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)"] Of course, "all" is a tall order since various NAS makers
can create their own "vendor-specific" request/response attributes, but
indicating whether a vendor-specific attribute is a request or response item
is the responsibility of the vendor.
> Q: Can radiusd be used to do DHCP?
heh heh heh -- but you know "in a limited sense, it can..." as most people
think of DHCP as "supplying an IP address" and forgetting that DHCP also
includes DNS and routing info. :) "for just an IP address", you can specify
back to the NAS what IP address the client should use, which may satisfy or
confuse the end user...
> Q: Can radiusd be used to filter network traffic?
I'm almost tempted to say, "now you're just being silly...", but I see your
point (and I hope everyone else reading along does too) in that
packet-filtering is a far cry from user authentication, authorization, and
accounting, but what about a hybrid solution: using radius to determine what
users are "granted access" through a firewall [in either direction] (umm,
that would be the "authorization" part, right? ;) ) In this case, the "NAS",
per se, isn't a hardware box with modem lines attached, but rather a software
manifestation running "somewhere" and deciding on how to alter firewall rules
based on a user id/password combo [and, I presume, source IP address :) ]
[...]
> The solution is NOT to document each and every dumb thing that
> people try to do. [...] documenting the wrong things is an endless
> treadmill that leads nowhere, and helps no one.
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 -- configuring radius is a
"black art" to them, but their boss got this wild hair growing someplace and
mandated a "radius server", and the rest, as they say, is history... :)
> ... I'm NOT willing to add documentation which assumes that the user [is]
> an idiot ...
There is a saying well known in the computer industry [or, at least, it should
be well known] "it is very hard to make something idiot proof, because
idiots are so damn ingenius." There are those that argue that perhaps we
"coddle" idiots a bit much [like stamping, "warning -- hot" on a cup of
McDonald's coffee] and that if we didn't we'd "cull the gene pool" a bit :)
but let's face it: intelligence in one area doesn't translate to intelligence
in all areas -- you ARE going to get a "well respected" idiot trying to use
your program from time to time :)
--
Yet another Blog: http://osnut.homelinux.net
pgp00000.pgp
Description: signature
