Matthew Schumacher <[EMAIL PROTECTED]> wrote: ...
http://lists.freeradius.org/pipermail/freeradius-users/2004-June/032678.html
Alan DeKok.
I never saw that and assumed my message never made it... After fighting with the list trying to make it work I subscribed with another account and asked again. Sorry...
Anyway:
> Or, if the rate gets too high, *stop* logging to the database, and > use a "detail" file. Then, when the rate drops, feed the detail file > back into the server.
I know how to feed the detail file back to the server with the radrelay util, but wouldn't that require me to run two radius servers? One configured to accept accounting from the NAS logging to a detail file, and another configured to write to the DB? Also, say I did all that, the radrelay tool sends radius accounting messages even faster than the nas. Perhaps I'm missing something, but AFAIK the only way to ensure that the data is put in the database is to have a very fast database that can handle the connection rate of radrelay or a fast NAS with a zillion clients authenticating at once. It would be great if the server would reject accounting messages if there isn't a DB handle that way accounting would fail over to the secondary where the message is queued to be forwarded back to the primary when it comes back. This would make having a DB backend much more accurate for accounting.
I suppose sending everything to a server acting as a accounting proxy with network rate limiting between it and the server with the DB backend could work but that solution seems more complex than it should be.
thanks,
schu
- List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
