Re: [RADIATOR] DEBUG logging oddities

[Karl Gaissmaier]

Hi Heikki,

Am 18.02.2016 um 12:37 schrieb 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.

see it as a compliment. With 'normal' companies such delays and even 
much longer delays or total ignorance are 'normal', but not for the 
RADIATOR team!

For me it's enough to hear that you ACKed my problem as a general 
problem and yes, both points (recv/sent messages log and stateful Ids) 
sounds fine.

Best Regards
Charly

RADIATOR, the software with the world best supporting team!
___
radiator mailing list
radiator@open.com.au
http://www.open.com.au/mailman/listinfo/radiator

Re: [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 ::willLog
> # has an unnecessary processing component, I know, but ...
> 
>  Trace   4
>  Identifier  NULL-LOGGER-GIMMICK
>  Filename/dev/null
> 
>
> # more global loggers for errors, warnings and notices:
> 
>   Trace   2
>   Identifier  radiatorlog
>   Filename%L/radiatorlog
> 
>
> 
>   Trace   2
>   IgnorePacketTrace
>   ...
> 
>

Thanks,
Heikki

-- 
Heikki Vatiainen 

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] DEBUG logging oddities

[Karl Gaissmaier]

Hi,

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

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


# Gimmick to trick ::willLog
# has an unnecessary processing component, I know, but ...

Trace   4
Identifier  NULL-LOGGER-GIMMICK
Filename/dev/null


# more global loggers for errors, warnings and notices:

 Trace   2
 Identifier  radiatorlog
 Filename%L/radiatorlog



 Trace   2
 IgnorePacketTrace
 ...



Best Regards
Charly

> Hi RADIATOR Team,
>
> I would like to dump the packet attributes within ServerRADSEC or
> AuthRADSEC but without overwhelming packet hexdumps.
>
> Therefore I can't/won't use PacketTrace in the clauses.
>
> I configured a clause specific Logger with 'Trace 4' but the 'sub
> main::willLog' doesn't honor the settings in the clause loggers, instead
> it checks just the global logger(s) und shortcuts the calls to
> recv_debug_dump in the Modules:
>
>> Radius/AuthRADIUS.pm:   $p->recv_debug_dump($self)  if 
>> (main::willLog($main::LOG_DEBUG, $p));
>> Radius/AuthRADSEC.pm:   $p->recv_debug_dump($self)  if 
>> (main::willLog($main::LOG_DEBUG, $p));
>> Radius/Client.pm:   $p->recv_debug_dump($self)  if 
>> (main::willLog($main::LOG_DEBUG, $p));
>> Radius/ServerRADSEC.pm: $tp->recv_debug_dump($self) if 
>> (main::willLog($main::LOG_DEBUG, $tp));
>>
>> #
>> # Return true if at least one logger is required to log
>> # Can be a shortcut to prevent length logging calculations
>> sub main::willLog
>> {
>>my ($priority, $p) = @_;
>>  return 1
>>if ($main::config->{LogStdout}&& ($priority <= $main::config->{Trace}
>>   || ($p && $p->{PacketTrace})))
>>   || grep $_->willLog($priority, $p), @{$main::config->{Log}};
>> }
>
>
> 
> Please see my stripped down test setting:
> 
>
>> BindAddress 127.0.0.1
>> AuthPort 1812
>> AcctPort 1813
>>
>> LogDir /tmp/radiator/log
>> DbDir  /tmp/radiator/etc
>>
>>
>> # disable global logfile for tests, in production I use a global file logger 
>> and syslog logger with Trace 2
>> LogFile
>> # I'll just see warnings and errors in the global log or during this tests 
>> on stdout
>> Trace 2
>> Foreground
>> LogStdout
>>
>> PidFile%D/radiusd.pid
>> DictionaryFile %D/my-very-short-dict-for-running-under-perl-debugger
>>
>> # AuthBy gimmick to define referable, non global loggers, thanks Hugh!
>> 
>>
>>  Identifier DEBUG-LOGGER
>>  Trace 4
>>  Filename %L/debug-logger
>>
>> 
>>
>> 
>>Identifier AUTHBY_TEST
>> 
>>
>> 
>># I'm interested in the radius code and attributes, not in SSL hexdumps
>>Log DEBUG-LOGGER
>>Secret radsec
>>Identifier AUTHBY_RADSEC
>>
>>UseStatusServerForFailureDetect
>>KeepaliveTimeout 10
>>FailureBackoffTime 10
>>NoreplyTimeout 10
>>
>>LocalAddress 127.0.0.1
>>Host 127.0.0.1
>>
>># test settings, in production use valid certs and CN checks!!!
>>UseTLS
>>TLS_CAFile %D/certificates/demoCA/cacert.pem
>>TLS_ExpectedPeerName .*
>>
>>TLS_CertificateFile %D/certificates/cert-clt.pem
>>TLS_CertificateType PEM
>>TLS_PrivateKeyFile %D/certificates/cert-clt.pem
>>TLS_PrivateKeyPassword whatever
>> 
>>
>> #
>>
>> 
>>Identifier HANDLER_FROM_RADSEC
>>AuthBy AUTHBY_TEST
>> 
>>
>> 
>>Identifier HANDLER_TO_RADSEC
>>AuthBy AUTHBY_RADSEC
>> 
>>
>> 
>>Identifier HANDLER_DEFAULT
>>AuthBy AUTHBY_TEST
>> 
>>
>> #
>>
>> 
>>Identifier DEFAULT
>>Secret mysecret
>>Log DEBUG-LOGGER
>> 
>>
>> 
>># I'm interested in the radius code and attributes, not in SSL hexdumps
>>Log DEBUG-LOGGER
>>
>>Identifier RADSEC_SERVER
>>BindAddress 127.0.0.1
>>Port 2083
>>Secret radsec
>>
>>AddToRequest Connect-Info=RADSEC
>>AddToReply Connect-Info=RADSEC
>>
>>UseTLS
>>TLS_CAFile %D/certificates/demoCA/cacert.pem
>>TLS_CertificateFile %D/certificates/cert-srv.pem
>>TLS_CertificateType PEM
>>TLS_PrivateKeyFile %D/certificates/cert-srv.pem
>>TLS_PrivateKeyPassword whatever
>>TLS_RequireClientCert
>>TLS_ExpectedPeerName .*
>> 
>> 
>
>
>
> and then test it with radpwtst
>
>> $ radpwtst -bind_address 127.0.0.1 -s 127.0.0.1 -noacct -auth_port 1812 
>> -user foo@radsec
>
> Any hint how to solve this problem?
>
> Please rethink your ::willLog(...) and btw, in my opinion, the
> whole logging deserves refactoring ;-(