Beeblebrox wrote: > First off, thanks again for your help. I fully appreciate that you are > giving of your time to answer posts, when you really have no obligation > to do so. I know you are one of the developers or project leader since > your name keeps coming up on almost every web page that posts something > about Freeradius.
I started FreeRADIUS. I've written most of the code. I've been doing this for ~14 years. And now, probably 50% of the new RADIUS specifications are mine. > That said, I would like to comment on the documentation of your project. > It's quite extensive, but equally confusing (at least for me). http://freeradius.org/doc/ contains documentation for all of the problems you've seen so far. That documentation is given in pretty excruciating detail. "edit this, run that command, see this output". And yet... most people who have problems start off with third-party web sites that are *worse*, in my opinion. They tell you to do things which aren't necessary, and they give wrong explanations. > I am a > FreeBSD user and have a pretty good handle on many advanced issues in > that OS - so I think I am fairly capable of reading and implementing > documentation. However, I have found that your documentation assumes too > much, does not follow much of a logical path, is not organized by topic, > does not "get to the point" and does not have concrete examples / > solutions to at least recurring and common mistakes or errors. As I've been saying for !4 years: the community is free to write better documentation. No, that's not true... I've been *begging* for better documentation. It doesn't happen. > When > reading documentation, I'm not interested in becoming an expert in that > subject, I just want to get the damn thing up and working. So in > essence, I'm not able to find the answers I'm looking for in your > documentation, and that's frustrating. Please explain how the "pap" and "EAP" guides don't do what you're asking for. They follow a logical path. They are clearly labeled by topic. They get to the point. They give concrete examples. Now, much *else* in the server doesn't have that. But the issues you ran into are documented *exactly* as you want. For the rest, the comments in the configuration file describe in great detail how the server works, and what the configurations do. And about "becoming an expert"... it helps to *understand* what you're doing. Many of the problems people run into are because they read crappy third-party documentation, and are obsessed with implementing a particular solution. They don't care to listen to the experts *here* who are telling them to do something else. And they don't care to *understand* what they're doing, so that they can do it *right*. > I have found (in debugging other software problems) that it is very > important for the person who knows more and is assisting, to ask the > right questions. Honestly, I have understoode very little from your > posts in this thread (with exception of the last one). Asking some > specific questions, then posting relevant links to the wiki (depending > on the answers from the OP) would be immensly more helpful. I suggest > that you have links in your signature to the entry-level wiki pages > (like faq, debug, etc). So... I'm supposed to cut & paste links from the wiki, because you... what... don't want to look there? Can't use the "search" button on the wiki? And add *more* links saying "please read the FAQ"? That's a terrible suggestion. >> If you think my response is rude, keep it to yourself. > I don't think that at all and as stated, very much appreciated your > input and taking time (again, without obligation) to provide help. In > fact, I previously refrained on commenting on how I disliked the > documentation structure so as not to appear rude to you. It's a pro-active comment. Most of the time when I say "I REALLY MEAN READ THE DOCUMENTATION", people get offended and accuse me of being rude. >> will result in you being unsubscribed and banned. > Fascinating! I'm enthralled. It's the only way to convince certain people to READ THE DOCUMENTATION. It's not hard. Go to the web site. Click on "documentation". The PAP / EAP issues you were having are documented from there, in great detail, exactly how you want. What *else* should we be doing to convince people to READ IT? Write it on flaming letters 150 feet high? It's already in the "man" pages, web pages, daily posts to this list, top entries on google. Alan DeKok. - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html