(RADIATOR) Multiple database failover

[Hugh Irvine]

Hello Elias -

This is most odd. Does the configuration work correctly without the 
ClientListSQL clause for both authentication and accounting to the same 
database? 

thanks

Hugh


On Mon, 11 Mar 2002 15:01, Elias wrote:
> Hi Hugh,
>
> The configuration I'm testing works if I remove the <ClientListSQL> clause.
> Any ideas why this is causing the config to not work? If I understand
> correctly, this query is only done once when Radiator first starts up
> right?
>
>
> - Elias -
>
>
> ----- Original Message -----
> From: "Hugh Irvine" <hugh at open.com.au>
> To: "Elias" <elias at tmnet.com.my>; "Radiator Mailing" <radiator at open.com.au>
> Sent: Saturday, March 09, 2002 7:20 AM
> Subject: Re: (RADIATOR) Multiple database failover
>
> > Hello Elias -
> >
> > This looks like a different error on the production machine. Does the SQL
> > database operate correctly prior to the error you show below?
> >
> > I would suggest you upgrade to Radiator 2.19 in any case, and let me know
>
> if
>
> > that makes a difference (there have been some SQL modifications).
> >
> > regards
> >
> > Hugh
> >
> > On Fri, 8 Mar 2002 19:11, Elias wrote:
> > > Hi Hugh,
> > >
> > > I'm trying to get Radiator (we're using 2.18.2) to authenticate against
> > > multiple databases in a failover mode. We have set up our SQL database
>
> and
>
> > > LDAP to sit on different networks. Normally Radiator would authenticate
> > > against the SQL and this works fine. We have 2 SQL databases for
> > > authentication and if the first one fails, Radiator will automatically
> > > switch to the second SQL database. This part works great.
> > >
> > > To add a second layer of redundancy, we have LDAP sitting on another
> > > network. When the whole network where the SQL sits fails, we want
>
> Radiator
>
> > > to switch automatically to LDAP. I've tested this setup using radpwtst
>
> on
>
> > > our development machines and it works. The problem is when I copy the
>
> exact
>
> > > config over to our production machines, it doesn't work. When the SQL
> > > network goes down, Radiator does not switch over to LDAP.
> > >
> > > Looking at the trace4 logs, I can see that everything is working ok in
>
> the
>
> > > development machine.
> > >
> > > Fri Mar  8 10:57:38 2002: ERR: Could not connect to SQL database with
> > > DBI->connect dbi:Oracle:host=xxx;sid=xxxx: timeout at Radius/SqlDb.pm
>
> line
>
> > > 120.
> > > Fri Mar  8 10:57:38 2002: ERR: Could not connect to any SQL database.
> > > Request is ignored. Backing off for 1 se
> > > conds
> > > Fri Mar  8 10:57:41 2002: ERR: Could not connect to SQL database with
> > > DBI->connect dbi:Oracle:host=yyy;sid=yyy: timeout at Radius/SqlDb.pm
>
> line
>
> > > 120.
> > > Fri Mar  8 10:57:41 2002: ERR: Could not connect to any SQL database.
> > > Request is ignored. Backing off for 1 se
> > > conds
> > > Fri Mar  8 10:57:44 2002: DEBUG: Handling with Radius::AuthLDAP2
> > > Fri Mar  8 10:57:44 2002: DEBUG: Connecting to xxxx
> > > Fri Mar  8 10:57:44 2002: DEBUG: Attempting to bind with cn=zzzzz
> > > Fri Mar  8 10:57:44 2002: DEBUG: Radius::AuthLDAP2 looks for match with
>
> zzz
>
> > > Fri Mar  8 10:57:44 2002: DEBUG: LDAP got result for uid=zzzz
> > >
> > > When testing in the production environment, I only get one line in the
>
> logs
>
> > > and Radiator just freezes and will not switch over to LDAP.
> > >
> > > Fri Mar  8 11:05:29 2002: ERR: Execute failed for 'select
> > > ENCRYPTEDPASSWORD, reply_attr from SUBSCRIBERS where LOGIN='DEFAULT'
> > > and STATUS=1': SQL Timeout
> > >
> > >
> > > --- Radiator config ---
> > >
> > > <AuthBy SQL>
> > >
> > >     Identifier SQL_auth
> > >     FailureBackoffTime      1
> > >
> > >     DBSource               xxx
> > >     DBUsername          xxx
> > >     DBAuth                  xxx
> > >     Timeout    3
> > >
> > >     DBSource               yyy
> > >     DBUsername          yyy
> > >     DBAuth                  yyy
> > >     Timeout    3
> > >
> > >     AuthSelect select .............
> > >     AuthColumnDef 0, .......
> > >
> > > </AuthBy>
> > >
> > >
> > > <AuthBy LDAP2>
> > >
> > >     Identifier LDAP_auth
> > >     Timeout  3
> > >
> > >     Host                    zzz
> > >     AuthDN              zzz
> > >     AuthPassword     zzz
> > >     BaseDN              .......
> > >
> > >     UsernameAttr    uid
> > >     PasswordAttr    userpassword
> > >
> > > </AuthBy>
> > >
> > >
> > > <Realm >
> > >         RejectHasReason
> > >         AuthByPolicy ContinueWhileIgnore
> > >         AuthBy SQL_auth
> > >         AuthBy LDAP_auth
> > > </Realm>
> > >
> > >
> > > - Elias -
> > >
> > > ===
> > > 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.
> >
> > --
> > 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.

-- 
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.