[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