--- Forwarded mail from [EMAIL PROTECTED]
Date: Fri, 21 Jul 2000 11:40:30 +1000 (EST)
From: [EMAIL PROTECTED]
To: [EMAIL PROTECTED]
Subject: BOUNCE [EMAIL PROTECTED]: Non-member submission from [Chris M
<[EMAIL PROTECTED]>]
>From mikem Fri Jul 21 11:40:27 2000
Received: by oscar.open.com.au (8.9.0/8.9.0) id LAA09527
for [EMAIL PROTECTED]; Fri, 21 Jul 2000 11:40:22 +1000 (EST)
>Received: from gash2.peakpeak.com (gasherbrumII.peakpeak.com [207.174.178.17])
by perki.connect.com.au with ESMTP id LAA12726
(8.8.8/IDA-1.7 for <[EMAIL PROTECTED]>); Fri, 21 Jul 2000 11:27:07 +1000
(EST)
Received: from gash2.peakpeak.com (gasherbrumII.peakpeak.com [207.174.178.17])
by perki.connect.com.au with ESMTP id LAA12726
(8.8.8/IDA-1.7 for <[EMAIL PROTECTED]>); Fri, 21 Jul 2000 11:27:07 +1000
(EST)
Received: from [199.165.157.57] (lovetown.oneup.com [199.165.157.57])
by gash2.peakpeak.com (8.9.3/8.9.3) with ESMTP id TAA22819
for <[EMAIL PROTECTED]>; Thu, 20 Jul 2000 19:27:10 -0600
<[EMAIL PROTECTED]>
<0007210935034Z.00896@hugo>
Mime-Version: 1.0
X-Sender: [EMAIL PROTECTED] (Unverified)
Message-Id: <v04210183b59d56fa9810@[199.165.157.57]>
In-Reply-To: <0007210935034Z.00896@hugo>
References:
<[EMAIL PROTECTED]>
<0007210935034Z.00896@hugo>
Date: Thu, 20 Jul 2000 19:27:12 -0600
To: [EMAIL PROTECTED]
From: Chris M <[EMAIL PROTECTED]>
Subject: Re: (RADIATOR) Simultaneous-Use Problems - IMPORTANT
Content-Type: text/plain; charset="us-ascii" ; format="flowed"
>Hello David -
>
>On Fri, 21 Jul 2000, David Lloyd wrote:
> > On Thu, 20 Jul 2000, Hugh Irvine wrote:
> >
> > > A better approach to maintaining session database coherency is to use
> > > strict checking of the NAS. This is what the NasType parameter is used
> > > for in the Client clauses (see section 6.4.5 in the Radiator 2.16.1
> > > reference manual). Note that there is a new NasType of "Ping" in
> > > 2.16.1 that doesn't actually query the NAS (via finger, who, snmp or
> > > whatever), but simply pings the IP address (Framed-IP-Address) to see
> > > if it is still there. An additional trick that is useful is to have a
> > > special Handler(s) to catch bogus accounting records, and use a
> > > SessionDatabase INTERNAL in that Handler(s) to keep the bogus records
> > > away from the SQL session database.
> > >
> > > This subject was discussed on the list fairly comprehensively a couple
> > > of months ago, and several customers have reported very good success
> > > with an SQL session database (with a custom DeleteQuery to delete a
> > > record with an IP address and/or a NAS-IP-Address/NAS-Port) and a
> > > NasType of Ping.
> >
> > I agree absolutely... I would not even *consider* using Simultaneous-Use
> > without setting NASType in the Client clause. Radius accounting is not
> > exactly the kind of thing that I would call 'reliable'... and it's easy
> > for the database to get out of sync.
> >
> > One feature I think would be neat in Radiator, would be to send it a
> > signal and have it 'sync-up' the database automatically. That would be
> > pretty handy...
> >
>
>Hmmmm - how would we do it though? We have enough trouble already....
>
>anyway, thanks for the suggestion
>
>Hugh
Maybe as a timer-based callback, or something that happens periodically...
<SessionDatabase SQL>
# sync the database to the ports every 360 seconds
SyncInterval 360
...
</SessionDatabase SQL>
Chris
---End of forwarded mail from [EMAIL PROTECTED]
--
Mike McCauley [EMAIL PROTECTED]
Open System Consultants Pty. Ltd Unix, Perl, Motif, C++, WWW
24 Bateman St Hampton, VIC 3188 Australia http://www.open.com.au
Phone +61 3 9598-0985 Fax +61 3 9598-0955
Radiator: the most portable, flexible and configurable RADIUS server
anywhere. SQL, proxy, DBM, files, LDAP, NIS+, password, NT, Emerald,
Platypus, Freeside, TACACS+, PAM, external, Active Directory etc etc
on Unix, Win95/8, 2000, NT, MacOS 9, 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.
