no logging => reject?
p.mayers at imperial.ac.uk
Tue Dec 18 17:07:23 CET 2007
Arran Cudbard-Bell wrote:
> Norbert Wegener wrote:
>> I am using a recent pre-2, authentication via a mysql database.
>> In post-auth I have a sql module, that reports accept/reject to a
>> another mysql database.
>> When this database is not available, the user is rejected, although I
>> get Auth-Type = Accept before.
>> Is this a desired behaviour, bug or feature?
Generally, failure of a module will result in failure of the request.
See doc/configurable_failover for info how to control this.
I would strongly recommend in your post-auth section doing what we did:
...that way, if sql actually fails, you just dump to a file. You can
monitor the file any number of ways to see how frequently (or not) this
However as Arran points out, if the module *blocks* rather than fails,
you may suffer a potentially arbitrarily long wait.
If your SQL server is routinely blocking then it is too slow and you
need to fix that, however if you want complete insurance against e.g.
unforseeable faults, I would use rlm_sql_log.
I was originally somewhat sceptical of it, however we recently moved a
~1M auths/day server from doing direct SQL writes to using sql_log in
order to be tolerant of SQL server drops, and I'm much (much!) happier
as a result.
What we actually do is this:
* a single central SQL server; two databases:
* radcheck - contains the SQL radcheck/reply & group tables
* radacct - contains the radacct & radpostauth tables
* 2 radius servers, each with a local read-only SQL replica of the
radcheck database; the radius processes are configured to read (do
lookups against) their local SQL, and write to the sql_log file
* copies of radsqlrelay pushing the accounting data to the central server
The time lag during normal loads is:
* central radcheck -> server radchecks: 0-10 seconds (postgres & slony)
* server sql-relay -> central radacct: 0-10 seconds (radsqlrelay)
During extended outages (such as the arranged maintenance in our
datacentre this weekend) the radius servers continue to chug away and
log to relay files, then replication & radsqlrelay spring back to life
and catch up later.
 One minor note - as per my recent post, the sql_log module cannot do
the "try update / except insert" technique that the sql module uses, so
I modified things slightly; I write the sql_log updates to a *2nd*
table, and use a TRIGGER on INSERT to update/insert the main radacct
table. It works very well.
As Alan pointed out in reply to my post, you could also run plain old
radrelay and an accounting-only radius server on the central database
server, however for various boring reasons I won't go into, that wasn't
an option for us.
More information about the Freeradius-Users