Hello Ricardo,
On Thu, Jul 23, 2020 at 05:52:55PM +0200, Ricardo Fraile wrote:
> Hello,
>
> On a complex configuration with multiples ACLs, is there a way to debug what
> of them are applied over a request?
Depending how you write them (and what version you are using), you may
be able to use the "debug" converter at the end of the expression to
capture the value and send it to a ring buffer that you can consult
elsewhere. You can also copy a value into a variable that you append
in the log.
> Is it possible to append the unique id of the ACLs to the line on the log?
Not really, the problem is that there isn't a single set of ACL, but a large
set which apply to many actions. I've seen configurations evaluating up to
6000 ACLs per request, it's definitely not even realistic to log anything
in such a mess. And there's no real "this use case is more common, let's
focus on it only" because there are many rulesets. In addition, anonymous
ACLs are fairly common, and sometimes more readable.
Cyril Bonté had worked on such a solution many years ago. By then we had
very few rulesets, and as we were adding new ones with many ACLs evaluated
for a single request, it quickly became difficult to exploit.
That's why I really encourage you to instead set a variable and log it.
There's even a "set-var" converter that duplicates the expression's
value into a variable. Thus for example, instead of doing :
use_backend foo if { path_beg /foo }
You could do:
use_backend foo if { path,set-var(txn.last_expr) -m beg /foo }
And log "var(txn.last_expr)" to always get the last evaluated ACL among
those you have instrumented.
This makes me think that it could be convenient to have a new converter
called "here" that, just like set-var() or debug(), passes the value and
stores the current config file's line number into a fixed variable so
that you could have it present in your logs.
You could then do something like:
use_backend foo if { path,here -m beg /foo }
If you'd place them on all final rules, you could easily detect what
rule was the one taking the final decision (redirect, deny, return,
etc). I suspect that we'd need a few sets, though (tcp-request,
http-request, tcp-response, http-response, use_backend, use-server).
But maybe in this case storing a history of the last 3-10 "here"
would help.
Note however that this would only be useful to know that a rule was
evaluated last. It doesn't guarantee that it matched, but if placed
on a final rule it will be reliable enough.
Hoping this helps, feel free to fuel the discussion with more ideas!
Willy
