sqlippool reject authentication if no IP?

[Hugh Messenger]

Peter Nixon <listuser at peternixon.net> said:
> On Thu 28 Jun 2007, Alan DeKok wrote:
> > Hugh Messenger wrote:
> > > With my current configuration, if sqlippool cannot assign an IP, the
> > > authentication still succeeds.
> >
> >   The module returns NOOP.  It could arguable return "fail".

Just a nitpick, but for pool depletion it returns 'notfound'.

> > > How can I set things up so if no IP is available, the authentication
> > > will fail with some informative Reply-Message, like the simultaneous
> use
> > > session control does?
> >
> >   Use configurable failover (see doc/configurable_failover).  It's not
> > yet integrated into the unlang nicely.  I'd like to do that before
> > releasing -pre2.
> 
> Yeah. Its currently designed to allow you to run two copies of the module
> side by side and have the second one assign the IP if the first one
> doesn't
> (Simply by listing one module after the other). This is to allow
> replicated
> pools on 2 different physical database servers. Additionally I use it with
> one table for dynamic ips, and a separate table for "static" ips.

OK, that makes sense.  I see why it returns 'NOOP' rather than 'fail'.

Wow, that was easy!  Freeradius rocks.  I just skimmed the
configurable_failover doc, and tried this:

post-auth {
        #  Get an address from the IP Pool.
        sqlippool {
                # not much point auth'ing them if we can't give them an IP
                notfound = reject
                noop = reject
        }
        ...
}

... which seems to do exactly what I need.  When I add a second sql server,
I'll work out how to handle the noop so it fails over, whilst still
rejecting on a notfound.

OK, that's the functionality.  How about setting the "informative
Reply-Message"?  Even if the customer doesn't see them, at least it'll be in
my Mtik logs.

Speaking of which.  What would be the simplest way of having an email alert
if a 'notfound' happens?  This is all for PPPOE wireless clients, which are
carefully provisioned.  So we should never end up running out of dynamic
pool space, and I need to know about it if we do.

> Peter Nixon
> http://www.peternixon.net/
> PGP Key: http://www.peternixon.net/public.asc

   -- hugh