On 20/11/13 16:57, Jonathan Gazeley wrote:

It's getting a bit unwieldy to manage this block, so I'm looking for a better way of writing it. However it must be fast, as every eduroam user hits this, i.e. database lookups are unsatisfactory. Flat files might be

Shrug. We do a database lookup on source MAC, cached in an rlm_cache instance. It works fine. Get a faster database!

ok depending on how they cached.

A "files" module is loaded into RAM and keyed into a hash table. It'll be lightning fast. Something like this: modules { files uobmac { key = "%{UOB-Stripped-MAC}" filename = "..." } } ...and in the file: 20:10:7a:1a:89:1d Fall-Through := Non ...the in unlang: authorize { ... uobmac if (ok) { update control { UOB-Debug = "%{debug:9}" } } ... } However a "files" module is only reloaded on hup. If you want proper dynamism, use an SQL lookup and wrap it in rlm_cache e.g. modules { cache uobdebug { ... key = "%{UOB-Stripped-MAC}" update { request { Tmp-String-0 := "%{sql:select 'y' from debugmacs where mac='%{UOB-Stripped-Mac}'}" } } } authorize { ... uobdebug if (Tmp-String-0 == "y") { update control { UOB-Debug = "%{debug:9}" } } ... }

On 20 Nov 2013, at 16:57, Jonathan Gazeley <Jonathan.Gazeley@bristol.ac.uk> wrote:

Currently I have this code block in my eduroam outer server which compares the MAC address of the current authentication attempt to a list of known MAC addresses of test clients which are then used for debugging without having to disrupt service by stopping the daemon and running radiusd -X.

if( (UOB-Stripped-MAC == "20:10:7a:1a:89:1d") || (UOB-Stripped-MAC == "bc:cf:cc:a1:a4:10") || (UOB-Stripped-MAC == "e4:ce:8f:49:8c:ae") || (UOB-Stripped-MAC == "a0:ed:cd:5c:66:70") || (UOB-Stripped-MAC == "94:44:52:e7:17:78") || (UOB-Stripped-MAC == "8c:3a:e3:14:eb:10") || (UOB-Stripped-MAC == "bc:c6:db:c7:31:30") ) {

# Enable debug messages update control { UOB-Debug = "%{debug:9}" } }

It's getting a bit unwieldy to manage this block, so I'm looking for a better way of writing it.

LDAP.

However it must be fast, as every eduroam user hits this, i.e. database lookups are unsatisfactory.

I'm guessing this is for visitors too then. Realistically how many visitors do you have? You'll most likely already be pulling information about your own students, so you can just bundle a debug attribute into the list of attrs you pull from the user object. Only if you realised it wasn't a local student would you need to do another query in a different part of the tree. All those query results can be cached (using rlm_cache) for the length of an EAP auth session. I think the extra load for this would be minimal, but if you're paranoid about it, see below...

Flat files might be ok depending on how they cached.

Any suggestions for neatening this up a bit, without compromising performance?

Or just use the users file, the key values on the left hand side get put into a hash table, so lookups for Mac-Addresses will be very fast. Users files should be re-read on radmin -e 'hup' or kill -HUP. You should use version 3.0.x for this (or v3.0.x head). v2.0.x did support dynamic debug levels but many of the log messages used the server global logging macros. This meant that request debugging was missing a lot of important messages. In 3.x.x the vast majority of log calls use the R*DEBUG macros, and so will be included in request specific debug. In addition to this calls to REDEBUG and it's friends automatically add additional instances of Module-Failure-Message to the request list. This again ensures logging is far more comprehensive, and gives you a better chance of understanding what went wrong (provided you log Module-Failure-Message) when full request debug logging isn't enabled. -Arran Arran Cudbard-Bell <a.cudbardb@freeradius.org> FreeRADIUS Development Team