(RADIATOR) Online SQL database
Leon Oosterwijk
leon at isdn.net
Thu May 10 09:33:47 CDT 2001
Griff,
We have run into this problem as well. We use our session database for
downstream customers to view their port usage. it is imperative that the
session database is accurate and does not contain stale entries. in response
I wrote a check program that polls the NAS units and find it's stale entries
using perl-SNMP. The script ususally finds about one stale entry per 5
minute period. Why would our network be dropping it's accounting packets
like this?
Leon
-----Original Message-----
From: Hugh Irvine [mailto:hugh at open.com.au]
Sent: Thursday, May 10, 2001 1:29 AM
To: Griff Hamlin; radiator at open.com.au
Subject: Re: (RADIATOR) Online SQL database
Hello Griff -
On Thursday 10 May 2001 10:51, Griff Hamlin wrote:
> Hello all,
>
> In using an SQL session database, and then a DefaultSimultaneousLogin
> with 3 servers (2 for authentication and 1 for accounting) I find that
> sometimes a stop record does not make it to the accounting server and
> there fore the user remains in the Session database and is denied
> further access. With as many routers and modems as we have that we do
> not own, it is not practical to have to querry them each time to see if
> the user is still on, we have to be able to trust the database. My
> question is, does Radiator provide facility to purge the database of
> records that are over 2 hours old, or some specified time. That way,
> customers whose stop records don't make it to us will still be
> authenticated when they try back later. Any help is appreciated. Thanks.
>
As you will have seen from the debug logs, Radiator tries to be self-healing
in the face of lost accounting packets by doing a preventative delete on the
session database for every new request (using the NAS/NAS-Port combination).
For further processing of the session database as you describe above, you
will have to write a cron job or similar to do whatever housekeeping you
wish
to undertake.
Otherwise if you get a support call from the customer, you could easily
provide a web page for your help desk staff so they could delete the stale
entry manually.
If I were you though, I would try to find out why you are losing stop
records.
regards
Hugh
--
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.
===
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.
More information about the radiator
mailing list