On Sat July 12 2003 16:19, Peter Nixon wrote: > On Sat July 12 2003 01:16, Alex Chen wrote: > > I agree about the dictionary part since it will be a 'read-only' table > > and practically > > will not change at all. > > > > But I think it will be more scalable and manageable if the clients.conf > > part can be configured to stored in DB's nas table, i.e. radiusd.conf > > includes clients.conf, > > which can have some kind of syntax to indicate that the information is to > > be read from a 'nas' > > tables in DB through 'sql' module. > > Of course this will be configurable, so is the table name, like other > > parts of radiusd.conf. > > > > If a new NAS needs to be added to the server, we only need to add a row > > into the DB. The server can cache the NAS information retrieved from DB > > during startup, like it > > does with the clients.conf file currently. When it gets a request packet > > from a unknown NAS > > client, i.e. which does not exist in its cache, it can do another query > > from the 'nas' > > table to refresh the cache and proceed with the > > authorization/authentication/accounting. > > If the NAS still does not exist in the latest DB query, the server does > > whatever it does > > to unknown NAS now. > > This sounds like a resonable solution to me. I already have a table listing > my NASes anyway for reporting and query purposes, it would certainly make > things neater if radius could use the same table. Especially for cases > where you have more than radius server accessing a single DB backend.
I have modified the postgres schema in CVS to have the following: CREATE TABLE nas ( id SERIAL PRIMARY KEY, nasname VARCHAR(128), shortname VARCHAR(32) NOT NULL, ipaddr inet NOT NULL, type VARCHAR(30), ports int4, secret VARCHAR(60) NOT NULL, community VARCHAR(50), snmp VARCHAR(10), naslocation VARCHAR(32) ); This now has the capability of being a useful table for reporting (I use a similar table to run reports per city by listing City in naslocation and then doing a JOIN against the accounts table on ipaddr then a GROUP BY naslocation. -- Peter Nixon http://www.peternixon.net/ PGP Key: http://www.peternixon.net/public.asc - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
