no logging => reject?

[Phil Mayers]

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:

post-auth {
   redundant {
     sql
     detail
   }
}

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

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[1]

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

[1] 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.

HTH