(RADIATOR) Radiator going down after Oracle SQL Timeout

[Mariano Absatz]

Hi John,

Thanx for your excellent advise... the point with this specific setup is 
that:

1) I don't have access to the oracle server (we are contractors and only have 
access to the Radius servers "on demand" and I don't even have a unix login 
on the Oracle server).

2) The authentication process is far more complicated that "username/password 
+ a bunch of attributes" and involves port limit checks, dynamic services 
(where some reply-attributes are bound to a service, not to a user, and some 
others are inferred from the servicem, not the user), dynamic IP address 
pools and the like.

3) Since the service is "re-sold" by my client to serveral other customers, 
they want to enforce all of this dynamic checks.

Oracle falls down relatively rarely and performance is, at least, quite 
adequate (when it's working, obviously). I shortened the back-off time to one 
minute (they have a kind of "cold/warm oracle stand-by", so, when it goes 
down, it comes up back quite fast.

My question was oriented to why Radiator was falling down in those cases 
(rather than simply backing off and not authenticating for a while).

As the time it took for me to get a login to the servers was rather long 
('cause my customer didn't think it was critical, since the service WAS up 
all of the time) I couldn't see the "supervise" logs (because they are 
autorotated and autoerased automatically). This logs capture all of the 
standard output and standard error from Radiator timestamping it. I increased 
the size and number of logs, so I will be able to see them the next time it 
happens (I hope).


El 15 Dec 2001 a las 18:43, John Coy escribió:

> > 
> > Hello Mariano -
> > 
> > What you describe below sounds to me like a problem with the DBD-Oracle
> >  module. I would suggest that you try to use the "restartWrapper"
> > program that  we provide in the distribution ("goodies/restartWrapper")
> > instead of  "supervise" (at least for debugging this problem). The
> > restartWrapper program  can be set up with a delay before restarting,
> > and it can also be configured  to email a designated email address with
> > the exit status and any error  messages that were written to stderr. We
> > should then be able to see what is  causing Radiator to die.
> > 
> > regards
> >
> 
> Hugh's answer is a good one, although you mentioned you're already using a 
> daemon-restart tool.
> 
> I'm replying because I am running about the same configuration you are -- 
> two RADIUS daemons (one for auth the other for accounting) and using an 
> Oracle database for the back-end.  Here's my approach for handling the 
> database being offline.
> 
> 1) Check to see why your database is offline =)  If it's going down often 
> enough you might want to spend some time troubleshooting that.  (ok, so 
> that's obvious, but I thought I'd state it anyhow just in case :-)
> 
> 2) Export your Oracle password file to a flat-file equivalent on a regular 
> basis.  My export simulates a traditional UNIX shadow file.  
> 
> This will allow you to use the <AuthBy GROUP> to chain together a couple of 
> <AuthBy> clauses.  The first clause will query your SQL server, the second 
> will query the flat file if the SQL server is unavailable.  An example cut 
> out of my "auth.cfg" file:
> 
> #
> # The <AuthBy GROUP> statement allows me to bundle the SQL 
> # authentication with the UNIX-style authentication in case the
> # SQL server is down.  SQL authentication is preferred and takes
> # precedence.
> #
> <AuthBy GROUP>
>         Identifier      ANCI-AuthSQLorUNIXPasswd
>         AuthByPolicy    ContinueWhileIgnore
> 
>         AuthBy          ANCI-AuthSQLPasswd
>         AuthBy          UNIX
> </AuthBy>
> 
> <AuthBy SQL>
>         Identifier      ANCI-AuthSQLPasswd
> 
>     ... all your SQL auth stuff here ...
> </AuthBy>
> 
> <AuthBy UNIX>
>         Identifier              UNIX
>         Filename                /usr/local/etc/shadow
>         GroupFilename           /usr/local/etc/group
> </Authby>
> 
> This gives you a bit of redundancy in case your Oracle database goes 
> offline.  Be sure your export routine does not clobber the file with empty 
> data if it cannot read from the database (or else you're back where you 
> started).
> 
> Hope that helps.
> 
> John
> Arkansas.Net


--
Mariano Absatz
El Baby
----------------------------------------------------------
Nobody has ever, ever, EVER learned all of WordPerfect. 


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