Re: confused about always_direct

Duane Wessels wrote:
>
> Henrik Nordstrom writes:
>
> >John Line (as web server manager) wrote:
> >
> >> acl local-domain dstdomain cam.ac.uk ac.uk ja.net
> >...
> >> (a) a Squid bug in handling a perfectly valid ACL that should have worked, or
> >
> >Looks like it. Perhaps the splay tree sorting is confused by the two
> >.ac.uk entries and only finds cam.ac.uk...
>
> Yes, this is the problem. SPLAY trees requires "orderable" keys.
> But it is wrong to say that "ac.uk" is less-than, equal-to, or
> greater-than "cam.ac.uk".

Mmm... in the particular context, "equal-to" in the (non-literal) sense of
"redundant-with" would seem appropriate (by which I mean Squid could
sensibly issue a "this is pointless, ignored" warning and forget about the
cam.ac.uk definition since it's inherently covered by the ac.uk one). It
certainly should avoid looking like it's working and doing "the wrong thing"
from the server admin's perspective. :-)

> So, this seems to be a case of "can't have your cake and eat it too."
> If you want "fast" tree indexing, instead of linked lists, then you can
> not have one key (domain name) that is a subset of another in the same
> ACL entry. Squid should probably try to detect this condition and then
> complain.

The only place I've seen the different tree, list, etc., options for
organising Squid ACLs mentioned has been on this list. No hint (that I
recall) anywhere else, so installers cannot be expected to know about them
and in consequence its especially important that Squid should diagnose (or
handle sensibly, if unambiguous) any problem cases. Documenting the
limitations (presumably as comments in the sample configuration file) would
be a good idea, too, so people can avoid the problems rather than tripping
over them.

For the particular case I hit, it looks like Squid could sensibly issue a
warning and ignore the redundant ACL entry (that is covered by a more
general one), but I don't know where else splay trees may be used and
whether in those cases it may not be so simple. (Presumably also for client
access control by hostname, at least, but the situation should be the same
there with x.y.z redundant and ignorable if y.z is specified.)

Especially where ACLs are built by scripts from totally unrelated
configuration files, or where lists are simply long (and unordered) so a
person adding an entry may not notice it is redundant or makes an existing
entry reedundant. Also, I feel you should not be forced to delete redundant
entries where there are good reasons (in terms of the logic of the list's
content) for them being there. E.g. if x.y.z was in the list and y.z was
added temporarily for some reason by person A, if x.y.z was removed because
it was redundant it could easily not get reinstated when person B later
removes y.z. So unless anyone sees a problem with doing it, I'd issue
a warning ("x.y.z is redundant with y.z, ignored") and ignore the redundant
entry, rather than treat it as a fatal error that must be "corrected".

[I think that's sort-of what happened in my case; cam.ac.uk should
definitely be always_direct at all times, whereas especially when trying out
Squid 1 initially the ac.uk entry would sometimes be there, sometimes not,
so having the sometimees-redundant entry there explicitly was the safest
option. And, of course, it worked with the different Squid 1 setup.]

> If, for some reason, you wanted to, you could probably rewrite your
> access list as follows:
>
> acl local1 dstdomain ac.uk
> acl local2 dstdomain cam.ac.uk
> acl local3 dstdomain ja.net
> ...
> http_access allow local1
> http_access allow local2
> http_access allow local3
> ...

With the substitution of always_direct for http_access, since it was a
routing control decision rather than an access control one that I wanted,
and with the cam.ac.uk entry still first as in the original, that's what I
tried "on spec" and it worked. As noted above, I think the original logic
was to have a clear reminder (and automatic safeguard) that cam.ac.uk should
be kept in the list even if, at times, ac.uk was removed, so I'm inclined to
keep it...

Thank you to those who have commented on the problem!

                                John Line

-- 
University of Cambridge WWW manager account (usually John Line)
Send general WWW-related enquiries to webmaster@ucs.cam.ac.uk