Patrick Wagner wrote:
This is entirely equivalent to the implementation Arran has suggested, enclosing sql and do_not_respond in a "redundant" block, correct?
Yes.
I hadn't realised that a fallback to REJECT instead of "do_not_respond" in case of a module error (="fail") is indeed a safer default, because I always only thought about the issue from the angle of multiple RADIUS servers providing fail-over for each other, in which case a "failed" RADIUS server pretending to know the answer and replying with a valid but factually incorrect RADIUS reply to a NAS client didn't make sense to me. But Arran and you cleared that up for me, thanks.
Yup. That's why we do what we do.
Yes, this makes sense now. I was confused as to why it wouldn't evaluate realmraute further down the config anymore in cases where SQL returned a "fail". It's all been fixed in our config and running fine now, at least as far as I'm able to test.
That's good to hear. Alan DeKok.