Re: Adding a NAS via SQL

[Krzysztof Olędzki <krzysztof.oledzki@axelspringer.pl>]

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