[RADIATOR] DEBUG logging oddities

[Heikki Vatiainen]

On 18.2.2016 12.40, Karl Gaissmaier wrote:

> no official solution or ACK for this problem til now :-(

Huh, almost a week already. I have no official solution, but I can tell 
what we have been up to recently. The virtualisation work we have done 
has brought up similar requirements as what you describe. Don't hesitate 
to let us if you have comments on this.

There are the main two enhancements for logging in Radiator:
1. Message log for received and sent messages
2. Id that binds together at authentication and accounting in log 
messages, including multiround authentication such as EAP.

I think 1. would be what you need. You could use INFO level logging and 
use a specific logger to log the incoming and outgoing messages with as 
much detail as needed.

In other words, the requests and responses and their attributes would be 
available regardless of trace level and the rest of the logging.

2. means that the loggers, such as log to stdout, and their format 
hooks, etc. can display and have access to an id that's the same for all 
log messages that are related to each other. For example:

45e94fd0 Wed Feb 17 16:38:29 2016 876349: DEBUG: Packet dump:
*** Received from 127.0.0.1 port 50172 ....
...
45e94fd0 Wed Feb 17 16:38:29 2016 878402: DEBUG: Access accepted for mikem
45e94fd0 Wed Feb 17 16:38:29 2016 878763: DEBUG: Packet dump:
*** Sending to 127.0.0.1 port 50172 ....

String 45e94fd0 could then be used to get all log messages related to 
this authentication. The above is from stdout/file, but if you push logs 
to e.g., InfluxDB, the id could be a separate field there allowing for 
easier searching.

The goal is to have the id available over the authentication and 
accounting session. This would mean that 45e94fd0 could be used to look 
up all EAP requests and the subsequent accounting requests if it's an id 
for an EAP authentication that has a related accounting session.

> Currently I use the following homebrew workaround to get debug messages
> with trace level 4 in private log clauses:

That's a good trick. Hopefully the above will make it unnecessary, though :)

> # Gimmick to trick &main::willLog
> # has an unnecessary processing component, I know, but ...
> <Log FILE>
>          Trace           4
>          Identifier      NULL-LOGGER-GIMMICK
>          Filename        /dev/null
> </Log>
>
> # more global loggers for errors, warnings and notices:
> <Log FILE>
>           Trace           2
>           Identifier      radiatorlog
>           Filename        %L/radiatorlog
> </Log>
>
> <Log SYSLOG>
>           Trace                   2
>           IgnorePacketTrace
>           ...
> </Log>
>

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.