(RADIATOR) AcctSQLStatement ONLY AuthBy?

[Mariano Absatz]

El 27 Jul 2001, a las 9:17, Hugh Irvine escribió:

> 
> Hello Mariano -
> 
> Yes you can certainly have any number of AcctSQLStatement's without an 
> AccountingTable and AcctColumnDef's.
> 
> You might want to think about using Handlers to process your requests.
> 
> Something like this:
> 
> # define Handler to process accounting stops
> 
> <Handler Acct-Status-Type = Stop>
>  .....
> </Handler>
> 
> # define Handler to process other accounting requests
> 
> <Handler Request-Type = Accounting-Request>
>  .....
> </Handler>
Yes...
but nonetheless, I want to apply all of the processing of <Handler Request-
Type = Accounting-Request> to the same packets that also match <Handler Acct-
Status-Type = Stop> and it is "cleaner" (at least for my eye) if I have one 
<AuthBy OnlyDoThisWithStops> and one <AuthBy DoThisWithEveryAcctPack> and use 
both in the <Handler Request-Type = Accounting-Request>.

> 
> # define Handlers for everything else
> 
> <Handler .....>
>  .....
> </Handler>
> 
> <Handler>
>  .....
> </Handler>
> 
> hth
> 
> Hugh
> 
> 
> On Friday 27 July 2001 03:20, Mariano Absatz wrote:
> > Hi,
> >
> > is it possible to have an <AuthBy SQL> that doesn't even have
> > AccountingTable and AcctColumnDef, but only AcctSQLStatement? The manual
> > seems to say "no".
> >
> > Here's what I want to do:
> >
> > I already have my "main" accounting only <AuthBy SQL> that processes
> > Start's Stop's and, if they are there, Alive's.
> >
> > Now I want to do a couple of AcctSQLStatement's but I want them only to be
> > executed when I get a Stop packet (to do time-block and also "byte"-block)
> >
> > I want to use AccountingStopsOnly in my new <AuthBy SQL> especially trying
> > to avoid Alive packets that would make accumulative substract time when I
> > shouldn't.
> >
> > I don't want to ignore altogether alive packets because billing will use
> > them if the Stop packet gets lost...
> >
> > Any ideas?
> >
> > TIA
> > --
> > Mariano Absatz
> > El Baby
> > ----------------------------------------------------------
> >
> > The generation of random numbers is too important to be left to chance.
> > -Robert R. Coveyou Oak Ridge National Laboratory
> >
> > ===
> > 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.
> 
> -- 
> 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.


--
Mariano Absatz
El Baby
----------------------------------------------------------
Error, no keyboard - press F1 to continue. 

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