no AuthLog (was Re: (RADIATOR) filtered logs?)

[Mariano Absatz]

Speaking about logs...

Hugh,
did you had the time to check what could possibly be happening with mine 
(disappearing) authlog? (see attached message)

Thanx.

El 10 Aug 2001, a las 10:51, Hugh Irvine escribió:

> 
> Hello Mark -
> 
> Advanced logging features in Radiator have been requested quite often, and 
> adding this functionality is on our list of things to do. However, it will 
> probably only happen in Radiator 3.0 when we implement multi-threading and 
> Diameter support (ie. it is some way off still).
> 
> In the meantime you could use a Log SQL perhaps? Although I personally find 
> "grep" to be as good as anything, and I agree that wading through large log 
> files is not fun.
> 
> regards
> 
> Hugh
> 
> On Thursday 09 August 2001 20:01, Mark O'Leary wrote:
> > 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.
> 
> -- 
> Radiator: the most portable, flexible and configurable RADIUS server 
> anywhere. Available on *NIX, *BSD, Windows 95/98/2000, NT, MacOS X.
> -
> Nets: internetwork inventory and management - graphical, extensible,
> flexible with hardware, software, platform and database independence.
> ===
> 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.


--
Mariano Absatz
El Baby
----------------------------------------------------------
Backups? We doan *NEED* no steenking baX%^~,VbKx NO CARRIER 


-------------- next part --------------
An embedded message was scrubbed...
From: Mariano Absatz <radiator at lists.com.ar>
Subject: Re: Fwd: (RADIATOR) log files behavior
Date: Mon, 6 Aug 2001 11:40:16 -0300 
Size: 24344
URL: <http://www.open.com.au/pipermail/radiator/attachments/20010810/8f4a3b1f/attachment.mht>