Hi Heikki, I'll give this a shot.
Thanks. -----Original Message----- From: Heikki Vatiainen [mailto:h...@open.com.au] Sent: Saturday, December 07, 2013 7:23 AM To: Garry Shtern; radiator@open.com.au Subject: Re: [RADIATOR] per-clause vs global Logs 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-boun...@open.com.au > [mailto:radiator-boun...@open.com.au] On Behalf Of Heikki Vatiainen > Sent: Monday, November 25, 2013 8:48 AM > To: radiator@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 <h...@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@open.com.au > http://www.open.com.au/mailman/listinfo/radiator > -- Heikki Vatiainen <h...@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@open.com.au http://www.open.com.au/mailman/listinfo/radiator
