On Sat, Sep 04, 2004 at 07:56:29PM +0200, Thor Spruyt wrote: > Paul Hampson wrote: > > New behaviour: (Replaces behaviour identical to <0 above) > > If the program returns 1 through RLM_MODULE_NUMCODES, return the > > appropriate code and attributes as expected. > > 1 RLM_MODULE_REJECT, /* immediately reject the request */ > > 2 RLM_MODULE_FAIL, /* module failed, don't reply */ > > 3 RLM_MODULE_OK, /* the module is OK, continue */ > > 4 RLM_MODULE_HANDLED, /* the module handled the request, so stop. > > */ 5 RLM_MODULE_INVALID, /* the module considers the request > > invalid. */ 6 RLM_MODULE_USERLOCK, /* reject the request (user > > is locked out) */ 7 RLM_MODULE_NOTFOUND, /* user not found */ > > 8 RLM_MODULE_NOOP, /* module succeeded without doing anything */ > > 9 RLM_MODULE_UPDATED, /* OK (pairs modified) */ > > Looks ok. > > > If it returns > RLM_MODULE_NUMCODES, return RLM_MODULE_OK. (as for 0) > > Maybe it's better to return RLM_MODULE_FAIL in this case. > > > This then leads the question, what return code do we want for when the > > child process terminates abnormally? (!WIFEXITED or rad_waitpid > > returns something other than the child's pid)... If we leave it as it > > is, it's RLM_MODULE_REJECT with the below patch... Would > > RLM_MODULE_FAIL be better? (Changes return 1 at src/main/exec.c:390 > > to return 2... This > > I guess RLM_MODULE_FAIL would be better here. > > -- > Regards, > > Thor Spruyt
I also agree with Thor's input. -- Kostas Zorbadelos Systems Developer, Otenet SA mailto: [EMAIL PROTECTED] Out there in the darkness, out there in the night out there in the starlight, one soul burns brighter than a thousand suns. - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
