Alan DeKok wrote: > If "preacct" says that the request should be proxied, we probably > shouldn't even run "accounting" at all.
I think there are some cases when there is a need to do both logging and proxying. (for example if the server and the proxy belong to different ISP) In those cases logging could be done in pre-proxy section instead of accounting, but currently not all the modules have a method for both accounting and pre-proxy. (for example rlm_sql can do accounting only) I've never understood why we have pre-proxy and post-proxy for accounting requests. As it is now, everything done in pre-proxy can be done in accounting, too. And post-proxy is meaningless since Accounting-Response packets are empty. > That will let people log local accounting data only for > requests that are handled locally. For now that can be achieved using Acct-Type stanzas. > That sounds reasonable, except for FAIL. If we fail to log > accounting data, it's even more useful to proxy it. I understand your reasons. The logs of the proxy may be incoherent, but that's probably better than to have nothing at all. > And most of those return codes don't make sense for accounting > requests. Since accounting just does logging, the return codes should > be: > > FAIL, OK, HANDLED, INVALID, NOOP. I agree. It should be the same for preacct modules, too. > REJECT doesn't make sense. USERLOCK doesn't make sense, and I'm not > sure what UPDATED means. Comments in modules.h says UPDATED is "OK (pairs modified)". However if a module returns REJECT or USERLOCK, it just means the module is seriously broken. It's unclear whether the packet should be proxied in this case. If something that shouldn't happen actually happens, I would vote to drop the packet. -- Nicolas Baradakis - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
