Hi,
On 24/03/2021 09:19, Ralf Paffrath wrote:
Hi,
On 24 Mar 2021, at 08:55, Paul Dekkers paul.dekkers@surf.nl wrote:
Hi,
On 24/03/2021 06:10, Ralf Paffrath wrote:
Hi Paul,
On 23 Mar 2021, at 12:19, Paul Dekkers paul.dekkers@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?
Well this would be a simple example: server etlr1.eduroam.org { type tls tls edupki }
Can you try "statusServer on” ?
server dynamic { type tls
statusServer ontls edupki dynamicLookupCommand /etc/radsecproxy/naptr-eduroam-lowercase.sh}
What is the result?
For me with statusserver on the result is the same;
FWIW: I've sent a snippet of the log to Fabian offlist,
Paul