[RADIATOR] Changing log level for an authby internal statement
Hugh Irvine
hugh at open.com.au
Tue Dec 8 14:38:20 CST 2009
Hello Alex -
The way to do this is as follows:
.....
# global logging
LogFile /dev/null
# define Log FILES in an AuthBy GROUP
<AuthBy GROUP>
<Log FILE>
Identifier HealthCheck
Trace ....
Filename ......
</Log>
<Log FILE>
Identifier NormalService
Trace .....
Filename ......
</Log>
.....
</AuthBy>
.....
<Handler Client-Identifier = HealthCheck>
Log HealthCheck
<AuthBy INTERNAL>
.....
</AuthBy>
</Handler>
......
<Handler ......>
Log NormalService
.....
</Handler>
.....
hope that helps
regards
Hugh
On 9 Dec 2009, at 04:29, Alex Sharaz wrote:
> Hi,
> I've got a number of radiator servers sitting behind a serveriron (SI)
> hardware load balancer. The SI periodically sends a radius authentication
> health check using an invalid userid and password. In radiator i have
>
> <AuthBy INTERNAL>
> DefaultResult REJECT
> Reject Reason "Health Check"
> </AuthBy>
>
> Which is invoked whenever i see an incoming auth request from the load
> balancer. This all works just fine and during normal operation (trace level
> 3) I see a log message saying
>
> <date and time>: INFO: Access rejected for <serveriron userid>: "Health
> Check"
>
> For real user authentication I've also set up some INFO level messages that
> show the status of each auth request being processed e.g.
>
> <date and time>: INFO: Authentication request from Student house : Salmon
> Grove : 17 Salmon Grove
> <date and time>: INFO: Using database stored auth vlanid - 1200
>
> The problem is that the logs are getting swamped with the health check
> statements. Is there any way of either changing the trace level to 2 for
> the AuthBy statement or in the Handler that calls the Authby statement? I've
> tried Trace 2 in both of these but radiator (4.5) complains that they're
> invalid statements.
>
> Alex
>
> _______________________________________________
> radiator mailing list
> radiator at open.com.au
> http://www.open.com.au/mailman/listinfo/radiator
NB:
Have you read the reference manual ("doc/ref.html")?
Have you searched the mailing list archive (www.open.com.au/archives/radiator)?
Have you had a quick look on Google (www.google.com)?
Have you included a copy of your configuration file (no secrets),
together with a trace 4 debug showing what is happening?
--
Radiator: the most portable, flexible and configurable RADIUS server
anywhere. Available on *NIX, *BSD, Windows, MacOS X.
Includes support for reliable RADIUS transport (RadSec),
and DIAMETER translation agent.
-
Nets: internetwork inventory and management - graphical, extensible,
flexible with hardware, software, platform and database independence.
-
CATool: Private Certificate Authority for Unix and Unix-like systems.
More information about the radiator
mailing list