syslog patch to rlm_detail in 1.1.0

[Geoff Silver]

Alan DeKok wrote:
> Geoff Silver <geoff+freeradius at uslinux.net> wrote:
>   
>> I had to patch rlm_detail.c so that our auth and accounting logs are
>> sent to a central syslog server.  We have about two dozen radius
>> servers around the world, so auditing their access is painful.
>>     
>
>   radrelay?  Have a central RADIUS server that does nothing but
> accounting, and use radrelay to send the data there.  That server can
> be made to do syslog (if you care).
>
>   But I wouldn't suggest anyone use syslog like this.
>   

There are a couple issues with relaying our accounting logs.  One is 
security (it's far easier for me to get firewall holes open from India 
or Brzail for syslog than for radius - actually, we already have these 
open) and another (more importantly) is redundancy (using syslog lets me 
use syslog-ng for instance, which tcp-based is far less likely to drop 
records).  I presume it's possible to have radrelay send to multiple end 
radiusd's?  That's something I know syslog can do for us.   Also a plus, 
the patch lets me relay all auth failures and successes, so we can 
monitor for brute force password cracking and do real-time trending.

I certainly wasn't trying to impose syslog on people, but I know I've 
seen discussions about patching radiusd or writing rlm's to do syslog 
previously on the mailing lists, so obviously people *want* to do this.  
I'd be happy to make some changes to it if it would help get it 
accepted, but if what I'm hearing is "no freakin' way" then I'll just 
maintain the patch seperately. 

For us, it's important to get this data into a syslog feed so that we 
can leverage the tools that already exist across our organization.  Yes, 
we might truncate a few messages, but overall it's a huge win because 
nobody has the time or resources to write tools to index and parse 
terrabytes of radius accounting logs every month or watch them in 
real-time, yet we *have* tools designed to do just that. 
>> In order to avoid duplicating code, rlm_detail now builds a string and then
>> prints it or syslog's it, rather than printing as it goes along.
>>     
>
>   Many syslog servers have size limitations on the strings they can
> handle.  They may not be able to take a full RADIUS attribute, much
> less a list of RADIUS attributes in one string.
>
>   Alan DeKok.
>
>   
I did consider that, though in testing I didn't have any issues on 
Linux.  I do agree for it to be right, it would probably need to split 
the message based on the max syslog message size if necessary, though I 
wasn't sure what that max message size should be.