sql returns fail for some stop requests

Alan DeKok aland at deployingradius.com
Tue Jul 24 15:24:42 CEST 2012


Amir Tal wrote:
> After additional debugging the fault seems to be with a rouge backup
> process running on DB host, causing it to be slow to un-responsive for
> 10-20 minutes.

  Stop that.  The database used by the RADIUS server should ONLY be used
by the RADIUS server.

> This is easy to fix, but I'm looking for a way to make a fail-safe
> solution.

  Don't shut down the database while the RADIUS server is using it.

> There can always be occasions where DB connection is momentarily slow
> due to some other issue like network or storage,

  Then the DB isn't that important, is it?

  I've never understood why people do that with critical systems.
They're critical, but NON-critical traffic takes them down.  The
solution for them is to BUTCHER the critical system, rather than
separating it from the non-critical systems.

> Since SQL is used here only for accounting data, is there a way to set
> the radius to accept all users (or reject all) in case DB is
> not-available,

  You do know that accounting is not authentication?  Saying "accept all
users for accounting" makes no sense.

> possibly keeping a buffer of accounting data to be
> written when DB access is restored?

  Stop that.  FIX THE SYSTEM SO IT WORKS.

> I am currently considering two possible solitions:

  No.  BOTH solutions are wrong.

  Fix your SQL database so that it doesn't go down.  Fix the network so
that it doesn't starve the RADIUS-SQL connection.

  ADDING complexity to the system means it is LESS stable than before.

  Alan DeKok.


More information about the Freeradius-Users mailing list