<picking up a month old thread :-)>
Hi *,
any reason not to create the accounting table the following
way instead ?
#
# Table structure for table 'ACCOUNTING'
#
CREATE TABLE ACCOUNTING (
USER_NAME char(50) DEFAULT '' NOT NULL,
TIMESTAMP int(11) DEFAULT '0' NOT NULL,
ACCT_AUTHENTIC char(30),
ACCT_SESSION_ID char(30) DEFAULT '' NOT NULL,
ACCT_SESSION_TIME int(11),
[...]
CALLING_STATION_ID char(30),
KEY ACCOUNTING_I (USER_NAME),
UNIQUE USER_NAME (USER_NAME,TIMESTAMP,ACCT_SESSION_ID)
);
- any reason for not using TIMESTAMP instead of NASIDENTIFIER
(in the table -or- in the your delete statement) ?
- any performance penalty ? (besides extra WARNINGS in logs)
- ...
I'll have to choose one of them (UNIQUE in table -or- delete
statement in .cfg file). Could you please advice in which one is
"best" ?
kind regards,
</canau
On Fri, Nov 10, 2000 at 03:11:45PM +1100, Hugh Irvine wrote:
>
> Hello Edgar, Hello Everyone -
>
> I have recently come across a clever way to deal with this in the
> standard AuthBy SQL clause.
>
> Here is what to do (you will need to tweak it for your own requirements):
>
> <AuthBy SQL>
> DBSource .....
> DBUsername .....
> DBAuth .....
>
> AuthSelect .....
> AuthColumnDef .....
> .....
>
> AcctSQLStatement delete from ACCOUNTING where \
> USERNAME='%{User-Name}' and \
> ACCTSESSIONID='%{Acct-Session-Id}' and \
> NASIDENTIFIER='%{NAS-IP-Address}'
>
> AcountingTable ACCOUNTING
> AcctColumnDef .....
> .....
> </AuthBy>
>
>
> NOTE: this only works because the AcctSQLStatement(s) is executed
> *before* the normal accounting processing.
>
> Thanks to the folks at austar.com.au for the suggestion.
>
> regards
>
> Hugh
>
>
> At 7:44 +0800 00/11/10, Edgar R Gutierrez wrote:
> >Hi Hugh,
> >
> >Again, we need your company's help.
> >We are in the process of providing PREPAID service to the market.
> >But apparently, from the duplicate logging that is happening, we will be
> >in a bad position to offer the service now not unless, we come up of
> >a solution
> >in ensuring that DUPLICATE accounting records are ignored and not
> >logged at all.
> >
> >OUr billing system is currently MYSQL based. This makes it very easy for us to
> >do real time accounting/billing for our current customers. But
> >unfortunately, like I mentioned,
> >there are cases wherein our RAS re-sends accounting packets, which
> >RADIATOR (using our postauthhook) eventually
> >logs to our accounting database.
> >
> >Is there anyway using a hook or an external program, or anything
> >inherent to RADIATOR by which RADIATOR
> >could ignore or drop the duplicate accounting request before it
> >reaches our POSTAUTHHOOK program.
> >
> --
> --
> Radiator: the most portable, flexible and configurable RADIUS server
> anywhere. SQL, proxy, DBM, files, LDAP, NIS+, password, NT, Emerald,
> Platypus, Freeside, Interbiller, TACACS+, PAM, external, etc, etc.
> Available on Unix, Linux, FreeBSD, Windows 95/98/2000, NT, MacOS X.
===
Archive at http://www.starport.net/~radiator/
Announcements on [EMAIL PROTECTED]
To unsubscribe, email '[EMAIL PROTECTED]' with
'unsubscribe radiator' in the body of the message.
