Reporting from logs

[Phil Mayers]

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.