RADIUS failing to start correctly when remote DB is unavailable.

[Sea Gull]

Hi Nick, Alan

Thank you both for your feedback. The first points mentioned by Nick to set
the read-clients as no, I have already implemented that earlier. I added
the following:

sql-remote {
     fail = 1
}

if (fail) {
     ... policy to handle database failure
     ok
}

This seemed to do the trick however, only when the connection timeout is
set explicitly in my sql_local and sql_remote files.
Now, if either of the DBs are unavailable, it will still proceed with
authorization. Accounting packets will be written to the details file,
which will populate the DBs when available.

Thanks and Regards,
SG

On Thu, Jan 12, 2023 at 3:14 PM Alan DeKok <aland at deployingradius.com>
wrote:

> On Jan 12, 2023, at 3:54 AM, Sea Gull <seagull0044 at gmail.com> wrote:
> > Yes indeed. RADIUS Authentication and Accounting servers are two
> different
> > physical machines,
>
>   OK.
>
> > which are connected to each other.
>
>   How?
>
>   I asked you to describe the system, and you don't do that.
>
> > ...  Now the issue is that when the remote database is for any
> > reason unreachable (could be firewall, maintenance, etc..) RADIUS will no
> > longer authenticate users.
>
>   Nick has told you how to help somewhat with that.
>
>   But realistically, if the authentication server *needs* the remote
> database to authenticate users, then when it's down... no one can
> authenticate.  This is how computers work.
>
>   If the authentication server doesn't need the remote database, then why
> is it using the remote database?
>
> > So what I'd like to establish is if there's a
> > way for RADIUS to continue with the authentication process of users
> without
> > having them accounted for, when the remote database is unavailable.
>
>   Either you're not describing what you have, or you're using the wrong
> words to describe things.
>
>   Reading between the lines, what I *think* you mean is:
>
> * RADIUS authentication and accounting are run on the same machine, by the
> same FreeRADIUS
>
> * the local database is used to authenticate users
>
> * the local database is used to store accounting data
>
> * the remote database is also used to store accounting data
>
>   Then, when the remote database is down, the RADIUS server blocks trying
> to reconnect, and it can't make progress on anything.  So authentication
> stops working, because all of the SQL connections are blocked trying to
> write accounting packets.
>
>   So if you describe the system accurately and correctly, it helps a lot.
>
>   The solution here is "don't have the remote database go down".  If the
> remote database is necessary, then it should stay up.
>
>   Another solution is to run a second copy of FreeRADIUS to write to the
> remote database.  See sites-available/decoupled-accounting.
>
>   The idea is that the main RADIUS server doesn't write to the remote DB.
> Instead it writes to a detail file.  The second RADIUS server then reads
> from the detail file, and writes to the remote DB.
>
>   That way if the remote DB is down, the detail file simply gets bigger.
> The main RADIUS server isn't blocked, and can continue running.
>
>   But this is just a guess, because you refuse to describe what your
> system is doing, or how it's configured.
>
>   Alan DeKok.
>
> -
> List info/subscribe/unsubscribe? See
> http://www.freeradius.org/list/users.html
>