Matthew Schumacher <[EMAIL PROTECTED]> wrote: > > 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?
I don't see why. You should be able to do both. Log to the DB, unless the rate is too high. If it's too high, log to a "detail" file, and rely on an external program to feed the requests back in, when the rate drops. > 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. That helps, too. Machines are cheap. > 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. Hmm... I'm not sure that would work. The server *is* responding to some requests, so the NAS won't see it as being down. A related fix would be to change src/main/threads.c, so that if an Accounting-Request has been sitting in the queue for more than 5 seconds, it's discarded and *not* processed. That should help, as the NAS will be re-sending the packet. > 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. I agree. Alan DeKok. - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
