FR 3.0: Fall back to proxy if SQL returns no result

[Alan DeKok]

I'm (still) working on migrating an existing Radiator setup to FreeRADIUS, and after some deliberation it was felt that the best way to handle the transition would be to have FreeRADIUS use the existing setup as proxies and configure it to fall back to said proxies when rlm_sql returns no hits.

That's good.

I've managed to set up the proxies thanks to the example in proxy.conf and the documentation in https://wiki.freeradius.org/config/Proxy, but all the instructions for /using/ the proxy pool involve setting specific realms rather than fallback, and I'm not sure if I'm even using the right search terms.

You can add a realm that isn't used anywhere else. e.g. "FALLBACK". Then, use that for proxying.

If you're worried about people using it, just check for users logging in as the FALLBACK realm, and reject them.

Then, do:

redundant {
sql
update control {
Proxy-To-Realm := "FALLBACK"
}
}

Additionally, looking through the freeradius -X debug log I notice that while it does recognize the home_server stanzas I added to the virtual host, it does /not/ acknowledge the home_server_pool stanza in the same file. Have I missed something?

The home_server and home_server_pool configuration blocks can appear in any file. They *can't* be used inside of a "server { ...}" section.

Alan DeKok.


-
List info/subscribe/unsubscri

[Alan DeKok]

server radius-test { # from file /etc/freeradius/3.0/sites-enabled/radius-test
# Loading authenticate {...}
# Loading authorize {...}
/etc/freeradius/3.0/sites-enabled/radius-test[179]: redundant sections cannot contain a "update" statement
/etc/freeradius/3.0/sites-enabled/radius-test[154]: Errors parsing authorize section.

Hmm... I guess that's there to catch people doing bad things. No worries, just do:

redundant {
sql
group {
update control {
Proxy-To-Realm := "FALLBACK"
}
}
}

And that should work.

Alan DeKok.


-
List info/subscribe/unsubs

[Alan DeKok]

If I'm reading the debug info right, what happens is that the rlm_sql module returns an "ok" status because it executed correctly - it found no entry in the database, but that isn't an incorrect answer - so the redundant stanza didn't see a need to try the fallback...

Then read "man unlang" about module return codes. This is documented.

sql
if (ok) {
update control ...
}

Alan DeKok.


-
List info/subscribe/unsubscribe? See http://www.freerad