(RADIATOR) Track daily/monthly usage

[Hugh Irvine]

Hello Joe -

Could you please tell me the name of the registered company that has  
purchased this copy of Radiator?

Please reply to me directly.

In answer to your question,

you could add a set of tables to your database like ACCOUNTING01,  
ACCOUNTING02, ACCOUNTING03, ....

and then have a second AuthBy SQL clause that you would run in  
addition to your normal accounting like this:


<AuthBy SQL>
	Identifier DailyAccounting
	.....
	AccountingTable ACCOUNTING%d
	AcctColumnDef ....
	.....
</AuthBy>


This would give you a snapshot of every day that you could post- 
process as required.

See section 5.29.8 in the Radiator 3.14 reference manual ("doc/ 
ref.html").

hope that helps

regards

Hugh


On 29 May 2006, at 04:45, Joe Hughes wrote:

> Hi All
>
> We record all our accounting information in a MS-SQL database,
> including start, stop and alive packets at 1 hour intervals for each
> session. In addition to the accounting data, I also record individual
> sessions detailing the start and end dates, the input/output octs and
> some other basic information. Periodically I flush the accounting
> table of old data. This all works fine.
>
> I'd like to go one step further and record daily usage for each user.
> So for a given user I could see something like;
>
> UserA    2006-05-28    2000   2000
> UserA    2006-05-29    1000   1500
> UserA    2006-05-30    5000   4500
>
> I could then do a SUM() using the month to view monthly summaries.
> There's also the possibility to use triggers to flag users exceeding
> quotas.
>
> Now I understand this can get quite complicated when sessions run from
> one day to the next, one month to the next and perhaps multiple
> sessions per day.
>
> I'd be interested in finding out if anybody else is doing this, or
> whether this isn't the best way of doing things, I may explore using
> SNMP, although in some cases SNMP isn't an option with some of our NAS
> devices.
>
> I know I could do it using a combination of triggers, hard work and
> various additional database logic, but it may introduce a lot of
> overhead on the database, especially with a lot of concurrent
> sessions. One option may be to increase the interim accounting
> interval.
>
> Cheers
>
> Joe
>
> --
> 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.


NB:

Have you read the reference manual ("doc/ref.html")?
Have you searched the mailing list archive (www.open.com.au/archives/ 
radiator)?
Have you had a quick look on Google (www.google.com)?
Have you included a copy of your configuration file (no secrets),
together with a trace 4 debug showing what is happening?

-- 
Radiator: the most portable, flexible and configurable RADIUS server
anywhere. Available on *NIX, *BSD, Windows, MacOS X.
-
Nets: internetwork inventory and management - graphical, extensible,
flexible with hardware, software, platform and database independence.
-
CATool: Private Certificate Authority for Unix and Unix-like systems.


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