On 2007-07-29 19:13, Arran Cudbard-Bell wrote:
Hugh Messenger wrote:
A.L.M.Buxey@lboro.ac.uk said:
how about updating the NAS list from SQL via, for example, an SNMP write command or a special RADIUS command packet. both of these could have security protection to prevent DoS (eg the SNMP write from only certain locations (firewalled) and has password too of course... the RADIUS command packet could have a shared secret requirement and/or use the FR unlang/attribute protections for access/accept
I agree with Alan B, SNMP write is the way to go with this. It's a nice standard mechanism which can be triggered by almost anything. Generally in most implementations of an SQL based NAS list, some script somewhere is going to be adding rows to the SQL table, and adding a few extra lines into that script to poke the server isn't going to be very hard in any high level interpreted language. I'd settle for having it reload on a configurable amount of time ...
# time between NAS table reloads if using SQL # default is 1 hour # set to 0 to disable NAS table reloading nas_table_reload_time = 1h
So each request FR handles would start with this pseudo-code ...
if (nas_table_reload_time AND (last_nas_table_read < (NOW - nas_table_reload_time)) { reload_nas_table(); last_nas_table_read = NOW; }
IMHO this would be a good compromise. Easy to implement (for someone like Alan!), very low impact on the server (with the default setting), and allows the admin to set the reload time that suits their site. I'd set mine to 24h, as I hardly ever change my NAS setup, but some folk might need 15m if they have high NAS turnover.
I can't help but think there might be something more complicated to this, else it would have been done already. The mechanism by which a reloading of SQL clients is triggered could be quite arbitrary, but changing memory structures whilst processing a packet could cause some nasty issues... But i'm not a C programmer, and Alan Is.
Alan if you could explain the technical reason behind the difficulty in adding this feature, users might be in a better posistion to offer suggestions / patches.
I don't know freeradius source code very well but after briefly looking into the rlm_sql.c I think it is possible. It seems that currently rlm_sql simply adds one client after another: while(rlm_sql_fetch_row(sqlsocket, inst) == 0) { (...) c = rad_malloc(sizeof(RADCLIENT)); memset(c, 0, sizeof(RADCLIENT)); (...) c->next = mainconfig.clients; mainconfig.clients = c; } So, currently it may be hard to remove old ones since it is unknown if they comes from rlm_sql or a client file. I see two solutions: save somewhere original "mainconfig.clients" pointer or mark using additional flag clients with rlm_sql origin. Switching beetwen old and new nas table could be atomic and we can keep the old one for a while (for example to the next scheduled reload) to be sure that no one else is using it (client_find() and client_walk() callers). Best regards, Krzysztof Olędzki