Re: [RADIATOR] per-clause vs global Logs

2013-12-09 Thread Garry Shtern 
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

Re: [RADIATOR] per-clause vs global Logs

2013-12-07 Thread Heikki Vatiainen 
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

Re: [RADIATOR] per-clause vs global Logs

2013-12-05 Thread Garry Shtern 
Guys,

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.

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
___
radiator mailing list
radiator@open.com.au
http://www.open.com.au/mailman/listinfo/radiator

Re: [RADIATOR] per-clause vs global Logs

2013-11-26 Thread Heikki Vatiainen 
On 11/15/2013 09:15 PM, Heikki Vatiainen wrote:
 On 11/14/2013 11:41 PM, David Zych wrote:
 
 My problem with PacketTrace as currently implemented is that it adds packet 
 dumps to _every_ global logger, whereas I'd really like to control where 
 they go and e.g. not send them to syslog.

 I suggest a new config flag for LogGeneric which tells individual loggers 
 *not* to participate in PacketTrace, used like so:

 This new option will likely be added soon with the debug level
 enhancement for rejected requests.

IgnorePacketTrace is now in the latest patch set. It can be used with
any LogGenric derived module to e.g., disable packet tracing with Log
SYSLOG.

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

Re: [RADIATOR] per-clause vs global Logs

2013-11-15 Thread Heikki Vatiainen 
On 11/14/2013 11:41 PM, David Zych wrote:

 My problem with PacketTrace as currently implemented is that it adds packet 
 dumps to _every_ global logger, whereas I'd really like to control where they 
 go and e.g. not send them to syslog.
 
 I suggest a new config flag for LogGeneric which tells individual loggers 
 *not* to participate in PacketTrace, used like so:

Thanks for the idea. Logging improvements are always welcome, as are any
other ideas too. Good logging is especially important for this kind of
server.

 My (very simple) patch is below.  Confession: I have no idea what the 1 in 
 the arrayref signifies.

The last number sets the detail level used by Server HTTP. 0 is for
'Basic Options', 1 for 'Advanced Options', 2 for 'Very Advanced Options'
and finally 4 for 'Deprecated Options'.

In other words, the number does not affect what the option does. It is
only used for organising the web gui.

This new option will likely be added soon with the debug level
enhancement for rejected requests.

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

Re: [RADIATOR] per-clause vs global Logs

2013-11-14 Thread David Zych 
On 11/12/2013, Heikki Vatiainen wrote:
 On 11/12/2013 06:12 PM, David Zych wrote:
  Now, however, I'm trying to put my Radiator servers behind a server 
  load balancer (SLB); every few seconds, the SLB sends a health check 
  request which Radiator is configured to REJECT (this is safer than 
  ACCEPT and equally effective proof that the server is alive and 
  answering).  The problem is that each REJECT generates INFO-level log 
  output which is cluttering up my logs:
 
  Fri Nov  8 16:56:03 2013 416230: INFO: Access rejected for 
  SI_radius_keepalive: L7 Health Check from SLB
 
  would a good solution be to change the log
  level of reject messages to something else? What could be done is to
  make the log level of these messages configurable.
  
  This would be great!  (ideally as a per-Handler config option, so that I
  could set it to DEBUG for this one Handler but leave it alone for others)
 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.
 
 I'll get back to this when there is something to test.

Thanks!

On a separate but related note, my global DEBUG-level logger has become much 
less useful now that even my dev systems are receiving uninteresting requests 
from the SLB every 5 seconds, so I've started playing around with PacketTrace 
as a way to debug only the thing(s) I'm actually interested in at any given 
moment.

My problem with PacketTrace as currently implemented is that it adds packet 
dumps to _every_ global logger, whereas I'd really like to control where they 
go and e.g. not send them to syslog.

I suggest a new config flag for LogGeneric which tells individual loggers *not* 
to participate in PacketTrace, used like so:

# include PacketTrace debugging here
Log FILE
  Filename %L/general/%Y/%m/logfile.%Y-%m-%d
  LogFormat %Y-%m-%dT%H:%M:%S.%s %{Server:Identifier}: %1: %2
  Trace 2
/Log

# but not here
Log SYSLOG
  IgnorePacketTrace
  LogSock udp
  LogHost %{GlobalVar:LogHost}
  LogIdent %{Server:Identifier}
  Facility user
  Trace 2
/Log

My (very simple) patch is below.  Confession: I have no idea what the 1 in 
the arrayref signifies.

David


diff -ruN radiator-2013/radiator/lib/perl5/Radius/LogGeneric.pm 
radiator-2013.dmrzhacks/radiator/lib/perl5/Radius/LogGeneric.pm
--- radiator-2013/radiator/lib/perl5/Radius/LogGeneric.pm   2013-09-06 
07:58:30.0 -0500
+++ radiator-2013.dmrzhacks/radiator/lib/perl5/Radius/LogGeneric.pm 
2013-11-13 17:28:19.0 -0600
@@ -23,6 +23,9 @@
  ['integer', 
   'Sets the maximum length of log messages. All messages longer than 
MaxMessageLength characters wil be truncated to MaxMessageLength.', 
   1],
+ 'IgnorePacketTrace'  = 
+ ['flag', 
+  'Exclude this logger from PacketTrace debugging', 1],
  );
 
 # RCS version number of this module
@@ -78,7 +81,7 @@
 {
 my ($self, $priority, $p) = @_;
 
-return $priority = $self-{Trace} || ($p  $p-{PacketTrace});
+return $priority = $self-{Trace} || ($p  $p-{PacketTrace}  ! 
$self-{IgnorePacketTrace});
 }
 
 #
___
radiator mailing list
radiator@open.com.au
http://www.open.com.au/mailman/listinfo/radiator

Re: [RADIATOR] per-clause vs global Logs

2013-11-12 Thread Heikki Vatiainen 
On 11/12/2013 06:12 PM, David Zych wrote:

 Now, however, I'm trying to put my Radiator servers behind a server load 
 balancer (SLB); every few seconds, the SLB sends a health check request 
 which Radiator is configured to REJECT (this is safer than ACCEPT and 
 equally effective proof that the server is alive and answering).  The 
 problem is that each REJECT generates INFO-level log output which is 
 cluttering up my logs:

 Fri Nov  8 16:56:03 2013 416230: INFO: Access rejected for 
 SI_radius_keepalive: L7 Health Check from SLB

 would a good solution be to change the log
 level of reject messages to something else? What could be done is to
 make the log level of these messages configurable.
 
 This would be great!  (ideally as a per-Handler config option, so that I
 could set it to DEBUG for this one Handler but leave it alone for others)

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.

I'll get back to this when there is something to test.

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

Re: [RADIATOR] per-clause vs global Logs

2013-11-11 Thread Heikki Vatiainen 
On 11/09/2013 01:22 AM, David Zych wrote:

 Now, however, I'm trying to put my Radiator servers behind a server load 
 balancer (SLB); every few seconds, the SLB sends a health check request which 
 Radiator is configured to REJECT (this is safer than ACCEPT and equally 
 effective proof that the server is alive and answering).  The problem is that 
 each REJECT generates INFO-level log output which is cluttering up my logs:
 
 Fri Nov  8 16:56:03 2013 416230: INFO: Access rejected for 
 SI_radius_keepalive: L7 Health Check from SLB

 My questions:

 3. Is there a better way to accomplish this that I'm not seeing?

Skipping to this directly: would a good solution be to change the log
level of reject messages to something else? What could be done is to
make the log level of these messages configurable.

In many cases rejects are normal, there is no need to log each reject
with INFO level. There have been questions about this before too, e.g.,
on busy eduroam proxies, and adding an option to set the desired log
level for reject messages might be a better solution than add a number
of log clauses and options to work around the reject log messages and
miss some useful INFO messages while doing it.

There are quite likely people who use the INFO level reject messages for
monitoring their service, so the default would be to use INFO but it
would be possible to switch it to e.g., DEBUG and just use AuthLogs to
see all rejects and accepts.

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