[RADIATOR] per-clause vs global Logs

Heikki Vatiainen hvn at open.com.au
Sat Dec 7 06:23:24 CST 2013


On 12/05/2013 07:23 PM, Garry Shtern wrote:

> What do you think about implementing an ability to log only specific transactions based on the request attributes.  For example, I would love to have an ability to enable more verbose logging based on specific source-ip or username.  This would allow me to leave debugging on for a long periods of time without worrying about performance issues and avoid having to sift through large logs looking for only particular transactions.  Perhaps, a new parameter called TraceFilter which would contain all of the attributes that have to be matched for logging, and ability to specify multiple of these parameters.

Hello Garry,

you could try something like this for RADIUS requests:

PreClientHook sub { my $p=${$_[0]}; \
              my $u = $p->get_attr('User-Name'); \
              if ($u eq 'mikem') { $p->{PacketTrace} = '1' } }

This enables PacketTrace for the request just like it had passed through
a clause with PacketTrace enabled. When PacketTrace is enabled with
PreClientHook, the it will log the incoming message giving you good view
on how the request processing goes.

Also, just this week we discussed with a client about possibilities to
suppress Trace 4 logging for some requests such as monitors, keep-alives
etc. This is more or less the opposite than what you are thinking since
the server would run by default with Trace 4 handling a moderate amount
of traffic.

One idea was to extend the way SIGUSR1 and SIGUSR2 use to increase and
decrease trace level. We could add a method to set the trace level and
could be called from e.g., Hooks.

Setting and resetting server trace level based on each incoming request
is easy but if the server needs to e.g., proxy the requests then the
replies from proxy and possible retransmissions by the server make
things a bit harder if the targeted debugging needed to cover those
cases too.

Thanks,
Heikki


> Thanks.
> 
> -----Original Message-----
> From: radiator-bounces at open.com.au [mailto:radiator-bounces at open.com.au] On Behalf Of Heikki Vatiainen
> Sent: Monday, November 25, 2013 8:48 AM
> To: radiator at open.com.au
> Subject: Re: [RADIATOR] per-clause vs global Logs
> 
> On 11/12/2013 10:43 PM, Heikki Vatiainen wrote:
> 
>> Global option would be possible at least. Lets see what it would take 
>> to have it as a per Handler option. Value for per Handler option 
>> should probably default to the global option so it can be overridden easily.
> 
> The patches now have changes that add new parameter LogRejectLevel. This allows setting a global or per Handler/Realm log level for 'Access rejected for $name: $reason' messages. The parameter value is an integer from 0 to 5: 0 for ERR, 1 for WARNING, etc.
> 
> The global value defaults to 3, which is the same as the current fixed
> value: INFO. The default for each Handler and Realm is the global value.
> 
> The new parameter does not affect AuthLog clauses.
> 
> Thanks,
> Heikki
> 
> --
> 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.
> _______________________________________________
> radiator mailing list
> radiator at open.com.au
> http://www.open.com.au/mailman/listinfo/radiator
> 


-- 
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.


More information about the radiator mailing list