(RADIATOR) filtered logs?

[Mark O'Leary]

On 9 Aug 2001, at 12:15, Hugh Irvine wrote:

> the only way to understand what the NAS is doing is to look at a trace 4
> debug from Radiator (or the output from your favourite packet 
> sniffer) to see what attributes are present

This may either be a help enquiry or a request for a new feature. ;)

As noted above there are many instances were a high level trace of 
transactions for a particular user (or, in this case, for the class of users 
doing multilink PPP) are required to troubleshoot a config - or indeed just a 
user with a login problem.

However, I find that in trying to follow the transactions for a single user 
on a production service with reasonably high traffic levels, I'm wading 
through loads of irrelevant transactions in trying to reconstruct the 
sequence of communications for a single user.

What would be particularly useful is to be able to specify a temporary 
logfile which could be filtered for a particular username, or a particular 
class of connection, or a particular realm - as flexible as possible really. 
Then I could leave my standard logging as it is, and just have a *relevant* 
trace 4 or 5 for the particular problem I'm looking at for as long as I need 
it.

I've faked this in the past by creating a "troubleshooting" realm and asking 
only the user with a problem to try connecting with that realm. Then I can 
test each of our AuthBY methods one at a time by altering the realm config, 
and generate a realm-specific log. But its a long-winded way to achieve it, 
and an artificial setup. (and I can't get a level 4 or 5 trace for the realm 
without increasing the 'global' level correspondingly and altering all my 
main logs for as long as I test).

Are any alternatives possible?

M.

-- 
Mark O'Leary, Manchester Computing, UK
PGP Key and Further Details: 
http://lucy.mcc.ac.uk/mark/mark.html
===
Archive at http://www.open.com.au/archives/radiator/
Announcements on radiator-announce at open.com.au
To unsubscribe, email 'majordomo at open.com.au' with
'unsubscribe radiator' in the body of the message.