> You can pull out all rows relating to the groups a user is a member of, > and process them on the RADIUS server using the group name as a key. > This could be done in one query if you were feeling adventurous, or > probably more easily with two.
That's a very reasonable suggestion, and would not I suspect be hard to code. However, I think it would prevent certain types of dynamic processing in the SQL side, so it would ideally be an optional configuration e.g. "bulk_query_groups = yes/no" or something. > Another possible alternative improvement using the current scheme,would > be to bring all the rows relating to a group down, then evaluate them, > and only continue querying if fall-through was true, or the check items > didn't match. Good suggestion - but it already does that. See lines 610 (the "for" loop dependent on the dofallthrough flag being 1) and 665/699 (setting of the dofallthrough flag based on the per-group Fall-Through reply items) of rlm_sql.c in todays CVS checkout. I'm fairly sure the CVS module has done that for months > > > Our SQL server is running on the campus webserver, it's horribly > overloaded and horribly slow. Then frankly I'm surprised you aren't experiencing more problems > > Don't get me wrong, I appreciate you fixing the horribly broken SQL > code, I was just suggesting some things that might improve efficiency. I didn't fix it - the only code I've ever contributed to FreeRadius has been tiny 1-liners in the bug tracker. I was speaking up in support of whoever did. - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html