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 <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