On Tuesday 01 June 2004 00:41, jesk wrote:
> On Monday 31 May 2004 16:58, jesk wrote:
> > On Sunday 30 May 2004 14:07, Gary McKinney wrote:
> > > Hmmm -
> > >
> > > The "logic" of the request does not really make much sense... If the
> > > FreeRadius
> > > server is responding to the NAS but the mysql server back-end is not
> > > responding
> > > that does not mean the "radius" server is broken...
> > >
> > > I would think you could setup to authenticate through multiple mysql
> > > backend servers
> > > to handle the event of the primary being offline or down instead of
> > > forcing a purfectly
> > > good working radius server to "act" like it was down.... and if you
> > > setup a secondary
> > > freeradius server to handle the event of the primary going down you can
> > > use the
> > > mysql servers that the first radius server points to for authentication
> > > by the second
> > > radius server so they have a common shared database (double
> > > redundancy).
> > >
> > > Check the email archives - I remember someone answered how to setup
> > > multiple sql servers to be used for user authentication in freeradius
> > > (which is what you really
> > > want to do here)... if the first mysql server is not responding the
> > > second (or next in line)
> > > will perform the response instead....
> > >
> > > gm...
> > >
> > > ----- Original Message -----
> > > From: "jesk" <[EMAIL PROTECTED]>
> > > To: <[EMAIL PROTECTED]>
> > > Sent: Sunday, May 30, 2004 6:38 AM
> > > Subject: Re: mysql failover
> > >
> > > > On Friday 28 May 2004 17:36, jesk wrote:
> > > > > hi everybody,
> > > > >
> > > > > is there a way to configure freeradius to NOT answer to a NAS if
> > > > > the mysql-backend is down, so that the nas can switch to the next
> > > > > secondary configured freeradius server with its own mysql-backend?
> > > > > i tested freeradius and shutted down the mysqlserver, the request
> > > > > from the nas came in and freeradius rejected the request in cause
> > > > > of the closed mysqldb-handle, now the nas rejected the ppp session
> > > > > and didnt requested the secondary freeradius.
> > > > > can somebody help me?
> > > > >
> > > > >
> > > > > thanks in advance,
> > > > >
> > > > > christian
> > > > >
> > > > >
> > > > > -
> > > > > List info/subscribe/unsubscribe? See
> > > > > http://www.freeradius.org/list/users.html
> > > >
> > > > no way?
> > > >
> > > > -
> > > > List info/subscribe/unsubscribe? See
> > >
> > > http://www.freeradius.org/list/users.html
> > >
> > >
> > > -
> > > List info/subscribe/unsubscribe? See
> > > http://www.freeradius.org/list/users.html
> >
> > hi,
> >
> > my intend was to setup 2 freeradius server, both server have to local its
> > own mysql-db. both mysqlserver are used to handle all 3 kinds of "aaa".
> > the replication for accounting data is done with radrelay, this works
> > very fine. but now there is this problem with the potentiality breakdown
> > of a mysqlserver. if iam handling this like you said, then i couldnt log
> > accounting data, in cause of the radrelay i think, accounting data would
> > be logged twice. is there no easy way to come around this circumstances?
> > i use the mysql for all accounts only the DEFAULT entry is in the USER
> > file.
> >
> > thanks for any hints!
> >
> > regards,
> > christian
> >
> > -
> > List info/subscribe/unsubscribe? See
> > http://www.freeradius.org/list/users.html
>
> hi,
>
> i configured the "always" module with handled in the authorize section:
> --------------------------------
> redundant {
> sql
> handled
> }
> --------------------------------
>
> i believed that that would do nothing if the mysql module would fail, but
> it return a reject to the mysql client:
>
> --------------------------------
> radius_xlat: 'SELECT id,UserName,Attribute,Value,op FROM radcheck WHERE
> Username = 'test' ORDER BY id'
> rlm_sql (sql): Ignoring unconnected handle 4..
> rlm_sql (sql): Ignoring unconnected handle 3..
> rlm_sql (sql): Ignoring unconnected handle 2..
> rlm_sql (sql): Ignoring unconnected handle 1..
> rlm_sql (sql): Ignoring unconnected handle 0..
> rlm_sql (sql): There are no DB handles to use! skipped 5, tried to connect
> 0 modcall[authorize]: module "sql" returns fail for request 0
> modcall[authorize]: module "handled" returns handled for request 0
> modcall: group redundant returns handled for request 0
> modcall: group authorize returns handled for request 0
> There was no response configured: rejecting request 0
> Server rejecting request 4.
> Finished request 4
> Going to the next request....
> --------------------------------
>
> can somebody say me what im doing wrong?
>
> thanks and regards,
>
> christian
>
> -
> List info/subscribe/unsubscribe? See
> http://www.freeradius.org/list/users.html
hi again,
i wrote a mistake:
> i believed that that would do nothing if the mysql module would fail, but
> it return a reject to the mysql client:
right it should be:
i believed that that would do nothing if the mysql module would fail, but
it returns a reject to the NAS client.
furthermore i looked in the mail archive and find in the past the same
question about the always handled module, but didnt find any helpful answers
if it is now possible to do it or not :(
in the doc/rlm_always file i read that its possible to do this:
quote :
-------------------
authenticate {
authtype SQL {
redundant {
sql1 # try module sql1
sql2 # if that's down, try module sql2
handled # otherwise the request is "handled"
}
}
}
This configuration says:
Try module sql1. If that's down, try module sql2, if that's down,
then the 'always' module will mark the request as 'handled', and the
server will stop ALL processing, INCLUDING any response to the
client.
This allows you to configure the server to have it appear to be
down (i.e. not responding to requests) when the SQL servers which it
depends on are down. When the SQL servers come back up, then the
RADIUS server will also start responding to requests.
------------------------
thanks for any further tips to become this running!
best regards,
christian
-
List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html