On 25/09/12 15:34, Matthew Newton wrote:
Hi,
On Tue, Sep 25, 2012 at 03:00:26PM +0100, Phil Mayers wrote:
On 25/09/12 14:39, Matthew Newton wrote:
How do you relay post-auth? That's one of the main reasons we still
use rlm_sql_log, as opposed to the built in "detail" listener.
Pure total hackery.
linelog can include '\n' in the output so can simlulate the detail
module for given attributes. The relayed auth packets are sent on
the wire as acct packets...
You, sir, win a prize! That's simultaneously clever and vile. I'm
disappointed I didn't think of it!
My reason for avoiding SQL was because I didn't want an SQL
problem to slow down or stop the main RADIUS servers, either in
the event of database failure, or just database slowness. Writing
Absolutely. Writing to an intermediate non-blocking location is, IMO,
essential at any scale.
We started with rlm_sql_log back in the 1.1.x days. We needed to
replicate post-auth as well as accounting packets, because some of our
NASes [some switches doing mac-auth] don't generate accounting - just
re-auth ever half hour. We simulate an accounting update-or-insert on
the central SQL server using a trigger for these devices.
I almost wonder if an "rlm_inject" might not be generally useful; in
particular, we could generate our simulated accounting internally to the
radius servers, rather than via an SQL procedure:
modules {
inject fake_acct {
type = acct
virtual_server = blah
attrs = {
Acct-Status-Type = "%{...}"
}
}
}
server blah {
accounting {
# something else reads/relays the detail file
detail
}
post-auth {
if (Crappy-NAS) {
fake_acct
}
}
}
Doesn't look hard; maybe I'll take a look at it.
-
List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
