[RADIATOR] logging (radiator and authlog) and accounting to ElasticSearch

[Heikki Vatiainen]

On 04/03/2014 12:28 PM, Hartmaier Alexander wrote:

> I just checked, LogFormat is indeed defined in LogFILE.pm, I thought it
> is shared by different logging classes and defined in a base class.

You are correct, there's no common class for LogFILE but the common
class is LogGeneric instead. And since logs can be pushed to for
example, SQL, LogFormat is only defined in LogFILE.

> I don't care so much where it is defined but how.
> Do you think configuring a Perl sub that returns a serialized string is
> the way to go for structured logging?

I guess that would be like a in-line Hook? Maybe it could be configured
as a hook type of parameter with a default value. See for example,
SqlDb.pm and how ConnectionAttemptFailedHook is initialised with a
default hook code.

> I was thinking about writing a Log module that uses Log::Any, Log4perl
> or Log::Dispatch so that you can do everything these modules support.
> My only concern is that the logging module affects Radiator and if e.g.
> RabbitMQ is down and logs can't be stored Radiator stops working.
> This might be intended if logging is an absolute requirement, but others
> might prefer availability over logging. Ideally this should be configurable.

Indeed. As noted below, LogSQL can be configured with so that it won't
make everything stop unless required so.

> What happens for the LogSQL class if the database goes down?

It uses the functions defined in SqlDb.pm which for example, AuthBy SQL
uses. Because of this, LogSQL respects FailureBackoffTime, Timeout and
other common parameters AuthBy SQL uses.

> Is there some documentation how to write a Log class? I looks like It
> only has to have the ConfigKeywords hash, subclass from
> Radius::LogGeneric and an initialize and log sub.

I'd say the existing Log* files are the best example.

> Is there anything special I need to do to allow a ConfigKeyword to hold
> a Perl sub?

Maybe create it as a Hook? That should help not duplicating existing
functionality.

Thanks,
Heikki


> BR Alex
> 
>>
>>
>> Thanks,
>> Heikki
>>
> 
> 
> 
> *"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*
> T-Systems Austria GesmbH Rennweg 97-99, 1030 Wien
> Handelsgericht Wien, FN 79340b
> *"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*
> Notice: This e-mail contains information that is confidential and may be privileged.
> If you are not the intended recipient, please notify the sender and then
> delete this e-mail immediately.
> *"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*
> 


-- 
Heikki Vatiainen <hvn at open.com.au>

Radiator: the most portable, flexible and configurable RADIUS server
anywhere. SQL, proxy, DBM, files, LDAP, NIS+, password, NT, Emerald,
Platypus, Freeside, TACACS+, PAM, external, Active Directory, EAP, TLS,
TTLS, PEAP, TNC, WiMAX, RSA, Vasco, Yubikey, MOTP, HOTP, TOTP,
DIAMETER etc. Full source on Unix, Windows, MacOSX, Solaris, VMS,
NetWare etc.