On Wed, Mar 11, 2015 at 01:14:07PM -0400, Alan DeKok wrote:
On Mar 11, 2015, at 12:06 PM, Phil Mayers <p.mayers@imperial.ac.uk> wrote:
However, I share some of the concerns in this thread. My gut feeling aligns with Matthew/Sam - this will confuse the (sadly very common) inexperienced and lazy first-time user. This is just a gut feeling, and I'd love to be proven wrong.
I’m almost OK with that. If you don’t have the time to understand *anything* about the software you’re using, you probably shouldn’t be using it.
Yes. It's just a shame that people still do. I guess it stems from the where RADIUS fits in. Many people likely have no interest in running a RADIUS server. Their job is, for example, to "get the wireless network working". A part of this is having to install this software they don't understand to link between the access points and whatever backend they have credentials in. The bit in the middle is just "magic". Trying to understand something you have no interest in is not easy. Especially when you're under pressure to provide the network. Admin is under-resourced? Probably, yes. Fact of life for us? Yes as well, unfortunately.
Maybe the server core *should* be a set of very low-level "receive" / "transmit" hooks, that call into a high-level processing language - a full-featured, complete, language, with robust threading, flow control and modern features, let's say an embedded JavaScript or Lua interpreter, for a straw man.
Arran and I have discussed that. It’s not a bad idea.
The problem is the protocol-specific mangling. i.e. EAP, SQL, etc. There’s a *reason* that complexity is hidden in modules. That’s hard to duplicate in lua.
I'm not sure it's even got to be that complex or deep. I sort of like the idea, though it may be adding complexity beyond what is needed. Not that hidden complexity is a bad thing to make the server flexible, but hopefully not at the expense of performance. The thing I usually think about with FreeRADIUS (and have never managed to actually fully document, though I nearly got there once) is that there is essentially a hard-coded script running behind the scenes. It goes something like when a packet is received: - go through authorize - check module return codes - if Proxy-To-Realm is set: - go through pre-proxy - proxy the packet - end - if Simultaneous-Use is set: - go through session - if Auth-Type is not set: - reject - if Auth-Type section does not exist: - reject - go through authenticate section based on Auth-Type - check module return codes - if success: - go through post-auth - else - go through post-auth/Fail - send response packet - end ... and the post-proxy bit, etc. There is definitely a coded flow through the server that isn't possible to change, but with hidden if()s coded in behind the scenes (such as checking Proxy-To-Realm). Maybe, then, rather than re-jigging the config file, abstract it slightly. Define what happens when packets come in/got out (this is then the "advanced adminstrator" bit: receive Access-Request { authorize if (Proxy-To-Realm) { pre-proxy proxy } else { authenticate(Auth-Type) } } send Access-Accept { post-auth } send Access-Reject { post-auth(Post-Auth-Fail) } the above (in unlang) doesn't call modules, but config sections. Basically, move the hidden server flow out into an unlang configuration. This then allows the config to be tidied, but still allow the existing configurations to work. Code like above matching the exact current flow is distributed with the server, but you could also completely change how the sections are called, e.g. the following would call a section "receive-access-request" and wouldn't ever be able to proxy anything: receive Access-Request { receive-access-request } If this lower-level could also call modules, you could easily hide some things in it, such as preprocess, that the vast majority of people never need to concern themselves with.
Anyone wanting to go beyond the default processing rules can locally fork the processing script and customise to hearts content.
You’re presuming they’ll read it. I’m not so optimistic.
No, they won't. But the idea would be that 99% of admins won't need to.
It might look something like this:
I’d find that confusing. A mish-mash of lua and calls out to FreeRADIUS modules...
It sort of looks nice - the lua (or whatever, maybe just unlang as above) defines which sections are called in what order. The defined sections _are_ the same as current config, so do call out to the current modules. A solution to this all might be as simple as renaming the config sections as originally suggested, and adding a "gosub" in unlang to call other config sections.
The current “default” server could be simplified I think. BUT at the expense of making it not work for some people.
The current default config, while very flexible for nearly any setup, is particularly long and complex. I remember looking at it the first time, and it was daunting. No idea where things hung together and where to start. There are so many comments it's hard to read through it. The comments are really good, don't get me wrong, but are a lot to wade through when you want to find something when you don't know where to look. One way to do it might be to break the default config up into simpler "examples". I keep meaning to try and start putting some sort of cookbook together, and this is really how it's likely to look. So instead of "default" and "inner-tunnel" you might have "wireless-802.1x-active-directory" "wireless-802.1x-ldap" "wireless-802.1x-local-auth" "adsl-chap-sql" ... etc "wireless-802.1x-active-directory" might look something like the following, with very few comments. modules { mschap { ... } eap { ... } } server default { listen { ... } authorize { filter_username preprocess eap files } authenticate { eap } post-auth { detail } } server inner-tunnel { authorize { mschap eap files } authenticate { eap } } The idea being that it's a full server config in one file, but as simple as possible. Then the existing config files are there as full reference guides with all the configs. Then the new admin edits wireless-802.1x-active-directory, drops it in sites-enabled, and hopefully is about the way to a working setup. No need to worry about configuring the right modules, etc - it's all in the one file. To me, that would have been much easier to begin with, as I wouldn't have been wading through many options that were totally irrelevant to what I was trying to do, and actually confused me a lot. It's trying to get a fine balance between easy for developers, easy for newcomers but customisable enough for advanced admins. That's hard. Matthew -- Matthew Newton, Ph.D. <mcn4@le.ac.uk> Systems Specialist, Infrastructure Services, I.T. Services, University of Leicester, Leicester LE1 7RH, United Kingdom For IT help contact helpdesk extn. 2253, <ithelp@le.ac.uk>