On Jul 3, 2016, at 10:21 AM, Nathan Ward <lists+freeradius@daork.net> wrote:
There is (at least in my observation) an expectation on this list of a knowledge of the RADIUS protocol, and surrounding systems (importing Windows CA certs, for example). To me and to I imagine most others on this list, these sorts of things are pretty elementary, though of course there certainly are times when I read a post and go off and do a bit of research myself - this list has brought me a great many starting points for curious learning.
To a certain extent. The idea is that people should either know, *or* be prepared to learn. The people who have endless problems are the ones who aren't prepared to learn. The people who complain about how we're being mean aren't prepared to learn. It's that simple. Look at the comments on this thread: A: Have you done X? B: I did Y A: No, really, have you done X? B: I didn't understand X, so I did Z. There is just no excuse for such behaviour.
It seems to me that the documentation has a similar expectation.
That's why I wrote: http://networkradius.com/doc/FreeRADIUS-Technical-Guide.pdf New people should read it. It assumes pretty much nothing, and explains almost everything about RADIUS and how the server works. It doesn't discuss EAP, but that documentation is being worked on.
I’m not sure, but I don’t think that that same expectation exists on mailing lists for other open source software. It’s not clear to me whether that’s because of a decision to expect that level of knowledge, or if maybe it just seems that way because RADIUS is somewhat specialised so there are a lower % of people with high skill RADIUS/associated system knowledge (if you’re a corporate network admin, RADIUS is maybe 1% of your job, so it’s not something you’d deal with every day so there are few people with “expert” or even “good” knowledge).
I'm on a number of other open source lists. I just don't see the same level of bad questions, or the same push-back against *doing* anything. It's just not that difficult. When you ask a question, and get told to do something.... *do it*. Don't argue. Don't fight. 99.99% of the time, I start by being polite, and giving people help. But after 4-5 rounds of someone arguing and refusing to learn, my attitude changes to: follow instructions, or go away.
The skill level expectation for participants in this list and readers of the documentation is, to me, perfectly fine. FreeRADIUS is an implementation and is used as part of a solution, so should not be held responsible for the whole solution. People often post on this list and it’s clear that they’ve been told to “implement RADIUS” having no idea where to start, when really what they should have been told is to implement a solution for which a RADIUS server is a component.
That's fine. I used to be a teacher. I have endless patience for people who make forward progress. I was a RADIUS newbie once, too. It's OK to not be an expert. It's *not* OK to ignore the existing documentation, to ignore the help on the list, and then to complain we're being mean when we say "read the documentation". Again, the comments on this thread showed a mind-boggling refusal to follow the simplest of instructions: A: Put the CA cert on the Windows machine. B: OK, I put it on the AP. By the way, the documentation sucks because it doesn't say to put the CA cert on the AP A: It's not *supposed* to be on the AP, put it on the Windows machine! B: <cries hysterically> Why are you so mean? I'm going to run away and hide. Why? Just... why? I don't see such behaviour on other open source lists. Probably because the software is a lot simpler. DHCP and DNS are trivial compared to RADIUS. Create a config file, start the server, it serves data. With RADIUS, you have to understand not only client / server, but RADIUS client/server versus EAP client/server, SQL databases, LDAP certificates, and so on. There is a *huge* amount of knowledge required in order to configure something properly.
I do wonder whether it would be beneficial to have a more general use mailing list, maybe for beginner to medium skill level folks, where there is more expectation that we’ll have to explain things that seem to come up from time to time like in this thread. We could use this to build the wiki up - or perhaps another wiki so the FR wiki doesn’t get littered with 3rd party system mess - and start pointing users towards that.
I don't think another list is the solution. Even more documentation isn't necessarily the solution. There is a lot of documentation already. The people who have problems are the people who can't find it, or if they do find it, don't read it.
I’d be happy to help with this, and lend advice to folks who are looking for it. I have zero experience with corporate stuff (Windows, EAP, etc.), but 13 or so years on and off experience using FR in service provider environments in all manner of weird deployments.
Please. Any kind of documentation is always appreciated.
There is what seems to be pretty good, though somewhat outdated, documents on EAP TLS here https://freeradius.org/doc/EAPTLS.pdf , and an updated guide to some of the bits on the front page of http://deployingradius.com.
That would be appreciated.
Perhaps we can look to provide documentation or guides that start at a more fundamental and whole-solution level, for example explaining what a CA certificate is for in this context, what a client certificate is for, some diagrams of how the various systems interact (i.e. step by step where/what messages are sent) etc. Perhaps vendor specific implementation details (I certainly have a number of learnings about what does/doesn’t work well), etc.
That would be good.
Again, I don’t think this is the responsibility of the FreeRADIUS project team, but perhaps with the right forum the community could be better at this stuff so that the core team can focus on writing code.
We're already working on re-doing the web site, so the things *should* be easier to find. It will all be in github, and people will be able to submit pull requests. To start, even a few pages on the Wiki explaining EAP / certificates would be useful. We can then put links to that in the configuration files, so (hopefully) people will read them. Maybe even a big warning on the main web page saying "Here's a list of 20 technologies you may need to understand to use RADIUS. It's NOT just DHCP / DNS / web server. It's a LOT more complicated than that. Read, learn, and you can get it to do what you want". That will help. But there will always be the subset of people who just can't be bothered to read the documentation, even when pointed to it. Alan DeKok.