Brian Candler wrote:
I queried this a while ago, and it seems to be intentional (albeit sparsely documented) behaviour.
I agree. I have people working on documentation. But it still requires my input, and I'm all over the place with a number of projects.
I wonder if this could all be made to work in a more intuitive way - for example, once a module has set "reject = 1" this status sticks until another 'real' module is called, as opposed to just update { ... } sections.
It's hard to change in a stable version, because we should NOT be breaking peoples configurations. That being said, the new module handling code is a lot clearer than the previous code. So it may be worth making this change for 3.0. I've looked at the "weird" behavior with empty sections. The good news is changing that is easy, and won't break working configurations. So from now on, when you have: module1 if (1) { } module2 The "if" section gets skipped, and doesn't change the return code.
Anyway, this is just something I've had to grit my teeth and bear with. It seems really weird, but eventually makes sort of sense. I ended up having to write a test suite (invoking radclient with all the different cases) to make sure they all worked the way I wanted.
Yeah. That code goes back to the earliest versions of the server, and largely hasn't changed. The good news is that it works. The bad news is that it's fairly opaque. But I think it's been a big benefit to the server. The ability to configurably process a list of modules is *very* useful. Alan DeKok.