Possible bug in configurable failover

[Brian Candler]

> > I understand that, so let me write it more clearly:
> > 
> > 1. the 'reject' state is being set at the beginning
> 
>  No.  It definitely doesn't do that.

Here's the code:

int modcall(int component, modcallable *c, REQUEST *request)
{
        int myresult;
...
        myresult = stack.result[0] = default_component_results[component];


But to be 100% precise: the way I configured it, I'm calling pap {..} before
testing_module, and so pap is also setting reject.  But if I comment this
out:

authenticate {
        #
        #  PAP authentication, when a back-end database listed
        #  in the 'authorize' section supplies a password.  The
        #  password can be clear-text, or encrypted.
        Auth-Type PAP {
                #pap {
                #        ok = return
                #        reject = 1
                #}
                testing_module
        }


then what I said was correct (reject is being set up-front when modcall is
first entered)

> > 2. the 'update' module returns 'updated' but this is discarded,
> >    hence the return code remains at 'reject'
> 
>   "updated" is a lower priority than "reject".  See
> doc/configurable_failover.  It's obscure, but useful.

That's correct but irrelevant.

Here is the code again:

                if (child->type == MOD_UPDATE) {
                        int rcode;
                        modgroup *g = mod_callabletogroup(child);

                        rcode = radius_update_attrlist(request, g->cs,
                                                       g->vps, child->name);
                        if (rcode != RLM_MODULE_UPDATED) {
                                myresult = rcode;

That is: after a MOD_UPDATE, a return value of RLM_MODULE_UPDATED is
*explicitly* discarded. It's nothing to do with the relative priorities of
updated and reject.

> As always, patches are welcome for suggested behavior.

I am happy to do so, I was just trying to understand if there was any
reasoning behind the current behaviour. In particular:

(1) why is a return of RLM_MODULE_UPDATED from MOD_UPDATE being discarded?
(src/main/modcall.c line 468)

(2) why does RLM_COMPONENT_AUTH use the RLM_COMPONENT_AUTZ actions table?
(modcall.c line 1950 and 2131)

(3) why does an update {} section not set any actions?
(modcall.c, do_compile_update, doesn't copy actions)

(3) may be an oversight, but (1) and (2) are explicitly coded that way, so
there may be some reason for them which I can't see.  I guess I can patch it
to change it, and see what breaks :-)

Regards,

Brian.