[radsecproxy] Re: dynamic lookups are not blocking, causes first auth to fail with fallback
24 Mar
2021
24 Mar
'21
9:28 a.m.
Hi,
On 24/03/2021 09:19, Ralf Paffrath wrote:
Hi,
For me with statusserver on the result is the same;
FWIW: I've sent a snippet of the log to Fabian offlist,
Paul
On 24 Mar 2021, at 08:55, Paul Dekkers
<paul.dekkers(a)surf.nl> wrote:
Hi,
On 24/03/2021 06:10, Ralf Paffrath wrote:
Can you try "statusServer on” ?
Hi Paul,
Well this would be a simple
example:
server etlr1.eduroam.org {
type tls
tls edupki
}
On 23 Mar 2021, at 12:19, Paul Dekkers
<paul.dekkers(a)surf.nl> wrote:
Hi,
If you have this realm block:
realm /@.+\..+$/ {
server dynamic
server fallback.server.here
accountingResponse on
}
radsecproxy will start to send the request to fallback.server.here because the dynamic
part didn't resolve yet: it's not blocking. Only as soon as the config for the
dynamic realm is in place, when the dynamicLookupCommand had a result, it will continue
with that host.
This results in part of the conversation going via one path, part of it via another.
I can’t notice this behaviour. But maybe I misunderstand you.
What is your dynamic server block configuration? server dynamic {
type tls
statusServer on
tls edupki
dynamicLookupCommand /etc/radsecproxy/naptr-eduroam-lowercase.sh
}
What is the result?