On 2024-04-14 17:23, Andre Bolinhas wrote:
Any tip on this matter? I want to upgrade to squid 6.9 but due to this
issue, i'm stuck.
Hi Andre,
Please note that I did _not_ receive your email quoted below. It is
in the email archive, so the problem is not on your end, but I just
wanted to mention that I was not (knowingly) ignoring you.
> I have re-uploaded the cache.log files.
The files have expired again. I have reviewed the diff you shared, but
cannot make further progress without those test logs. Hopefully, your
next list post reaches me.
Alex.
On 01/04/2024 11:53, Andre Bolinhas wrote:
Hi Alex
Thanks for your help on the matter.
The logs archive you shared previously has expired, so I cannot
double check, but from what I remember, the shared logs did not
support the above assertion, so there may be more to the story here.
However, to make progress, let's assume that v5 configuration files
are identical to v6 configuration files.
If you want, I can run the same test with in a different debug
parameters, just tell which ones.
I have re-uploaded the cache.log files.
https://we.tl/t-AB4XuUwuf7
One way to answer all of the above questions is to look at the
following output:
squid -k parse ... |& grep Processing:.http_access
There is no diff between both squid version, you can check it here
DiffNow - Compare Files, URLs, and Clipboard Contents Online
<https://www.diffnow.com/report/jsrva>
The logs archive you shared previously has expired, so I cannot
double check, but from what I remember, the shared logs did not
support the above assertion, so there may be more to the story here.
However, to make progress, let's assume that v5 configuration files
are identical to v6 configuration files.
The configuration files / folder are the same, the server is the same,
the only thing that changes is the Squid version
On 29/03/2024 17:40, Alex Rousskov wrote:
On 2024-03-25 15:13, Bolinhas André wrote:
Yes, the configuration is the same for both versions.
The logs archive you shared previously has expired, so I cannot
double check, but from what I remember, the shared logs did not
support the above assertion, so there may be more to the story here.
However, to make progress, let's assume that v5 configuration files
are identical to v6 configuration files.
1. Is there an "http_access allow all AnnotateFinalAllow" rule?
2. Is there an "http_access deny HTTP Group38 AnnotateRule28" rule?
3. Assuming the answers are "yes" and "yes", which rule comes first?
If you use include files, this question applies to the imaginary
preprocessed squid.conf file with all the include files inlined
(recursively if needed). That kind of preprocessed configuration is
what Squid effectively sees when compiling http_access rules, one by
one. Which of the two rules will Squid see first?
One way to answer all of the above questions is to look at the
following output:
squid -k parse ... |& grep Processing:.http_access
Replace "..." with your regular squid startup command line options
and adjust standard error redirection (|&) as needed for your shell.
Run the above command for both Squid v5 and v6 binaries. You should
see output like this:
2024/03/29 13:31:05| Processing: http_access allow manager
2024/03/29 13:31:05| Processing: http_access deny all
HTH,
Alex.
------------------------------------------------------------------------
*De:* Alex Rousskov <rousskov@xxxxxxxxxxxxxxxxxxxxxxx>
*Enviado:* segunda-feira, 25 de março de 2024 19:12
*Para:* squid-users@xxxxxxxxxxxxxxxxxxxxx
*Assunto* Re: ACL / http_access rules stop work using
Squid 6+
On 2024-03-22 09:38, Andre Bolinhas wrote:
> In previous versions of squid, from 3 to 5.9, I use this kind of
deny
> rules and they work like charm
>
> acl AnnotateRule28 annotate_transaction accessrule=Rule28
> http_access deny HTTP Group38 AnnotateRule28
>
> This allows me to deny objects without bump / show the error page
> (deny_info)
>
> But using squid 6+ this rules stop to work and everything is
allowed.
>
> Example:
> Squid 5.9 (OK)
> https://ibb.co/YdKgL1Y
>
> Squid 6.8 (NOK)
> https://ibb.co/tbyY2GV
>
> Sample of both cache.log in debug mode
>
> https://we.tl/t-T7Nz1rVbVu
In you v6 logs, most logged transactions are allowed because a rule
similar to the one reconstructed below is matching:
http_access allow all AnnotateFinalAllow
There are similar cases in v5 logs as well, but most denied v5
transactions match the following rule instead (i.e. the one you shared
above):
http_access deny HTTP Group38 AnnotateRule28
In your Squid configuration, v6 allow rule is listed much higher
than v5
deny rule (#43 vs #149). I do not see any signs of Group38 or
AnnotateRule28 ACL evaluation in v6 logs, as if the rule sets are
different for two different Squid instances. Are you using the same set
of http_access rules for both Squid versions?
Alex.
_______________________________________________
squid-users mailing list
squid-users@xxxxxxxxxxxxxxxxxxxxx
https://lists.squid-cache.org/listinfo/squid-users
_______________________________________________
squid-users mailing list
squid-users@xxxxxxxxxxxxxxxxxxxxx
https://lists.squid-cache.org/listinfo/squid-users
_______________________________________________
squid-users mailing list
squid-users@xxxxxxxxxxxxxxxxxxxxx
https://lists.squid-cache.org/listinfo/squid-users
_______________________________________________
squid-users mailing list
squid-users@xxxxxxxxxxxxxxxxxxxxx
https://lists.squid-cache.org/listinfo/squid-users