Hey Dan,
I don't want to step on toes.It seems like the root problem here is to
fix the communication between the Radius server and the SQL server. Is it
some sort of remote link?
Regards,
Craig.
===
Archive at http://www.open.com.au/archives/radiator/
Announcements on [EMAIL PROTECTED]
To
.934.2800
1.888.ON.GO.YET
-Original Message-
From: Dan Melomedman [mailto:[EMAIL PROTECTED]
Sent: Monday, June 30, 2003 9:44 PM
To: [EMAIL PROTECTED]
Subject: Fwd: Re: (RADIATOR) Database support fault tolerance
Hugh Irvine wrote:
Hello Dan -
It would be fairly simple to have Radiator write
Hello Dan -
It seems to me there is a fundamental problem in trying to design
something that relies on an SQL database, but should keep working
without problems if the database goes away?
Most operators that I have worked with tend to run their databases on
large fault-tolerant SQL server mach
Hugh Irvine wrote:
>
> Hello Dan -
>
> It would be fairly simple to have Radiator write to a flat file for
> accounting, and then have a cron job or similar load the data into the
> database periodically. You will find a simple utility to do this in the
> file "goodies/radimportacct".
>
> reg
Hello Dan -
We try to make Radiator good at dealing with radius requests, while at
the same time providing you with a wide range of facilities allowing
you to interface with other systems. As mentioned previously there are
alternatives available if database access cannot be assured.
regards
H
ssage-
From: Dan Melomedman [mailto:[EMAIL PROTECTED]
Sent: Monday, June 30, 2003 9:44 PM
To: [EMAIL PROTECTED]
Subject: Fwd: Re: (RADIATOR) Database support fault tolerance
Hugh Irvine wrote:
>
> Hello Dan -
>
> It would be fairly simple to have Radiator write to a flat file for
>
Hugh Irvine wrote:
>
> Hello Dan -
>
> It would be fairly simple to have Radiator write to a flat file for
> accounting, and then have a cron job or similar load the data into the
> database periodically. You will find a simple utility to do this in the
> file "goodies/radimportacct".
I was h
Why not just use a redundant authenticator, most DBs including LDAP
engines can sync between multiple servers, then just point radiator at
each one and if it can not talk to the first it will fail over to the
next... Or better yet, just use a Foundry Server Iron (Layer 7 switch)
to sit between
Hello Dan -
It would be fairly simple to have Radiator write to a flat file for
accounting, and then have a cron job or similar load the data into the
database periodically. You will find a simple utility to do this in the
file "goodies/radimportacct".
regards
Hugh
On Tuesday, Jul 1, 2003, a
Our users are getting sick and tired due to RADIUS service
unavailability every time something happens to the network where the
database server sits, or the database server itself. To remind, we use
LDAP for authentication, and SQL Server for sessions/logging. LDAP has
been great, where database co
10 matches
Mail list logo