Adding a NAS via SQL

[Krzysztof Olędzki]

On 2007-07-29 19:13, Arran Cudbard-Bell wrote:
> Hugh Messenger wrote:
>> A.L.M.Buxey at 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