Update Reply returns noop

[Matthew Newton]

On Mon, Jul 25, 2016 at 08:47:21PM +0000, Anastasios Gryponisiotis wrote:
> Please appreciate that I need to understand what needs to be done, not
> mindlessly read documentation and change logic without knowing why/what I'm

But reading documentation helps you understand how things work :(

> For the record, Mathew did not suggest doing a if/elseif/else tree. He
> actually said that it would be too complicated to troubleshoot.

I didn't say *don't* do an if/elsif/else tree. Just that trying to
get the whole logic of that in one tree with rejects in the right
places can be too hard to do sometimes. Hence breaking it up into
smaller ifs, and setting other attributes to control whether you
reject or not at the end.

> My question all along is why an update reply statement returns noop
> although it is performing a change. I get this:
> 
> ++++[reply] returns noop

if() statements are not modules, so do not set module return
codes by themselves. Which is why you see "noop". You might see a
different result if the contents of the if returned something
different, as the if() will pass the contained module return
code back up.

In this case, "update" pretty much *always* returns code "noop",
which is why the if() also returns noop.

If you want to explicitly reject, you need to call a module that
sets the return code to "reject". Conveniently, the "reject"
module does this for you.

> I have read the documentation, which says that noop means "the module did
> nothing". Isn't updating the reply something?

There was no module. if() isn't a module, it's an unlang
statement. update{} updates the attribute lists (request, control,
or reply), and is also an unlang statement.

Modules set the return code, most unlang statements do not. At the
end of each section (authorize, post-auth, etc) the module return
code with the highest priority is used to determine which type of
RADIUS packet (Accept, Reject) to send back - not the attributes
that have been set (with update{} or otherwise). The attributes
from the reply list are put *in* the packet, but don't set the
*type* of the packet.

If you want to reject at some point, then call "reject".

As I said before, it looks like you've got some pretty complex
logic, so breaking that down to simpler stages, and using
meaningful attribute names, can make things much easier to follow
in your config.

Then put a short section at the end which explicitly does a
"reject" if required.

Matthew


-- 
Matthew Newton, Ph.D. <mcn4 at leicester.ac.uk>

Systems Specialist, Infrastructure Services,
I.T. Services, University of Leicester, Leicester LE1 7RH, United Kingdom

For IT help contact helpdesk extn. 2253, <ithelp at le.ac.uk>