Re: Doubts on Squid Configuration Parameters

squidinfo wrote:

> Could someone give me a concrete example when to use these
> parameters, and in what sequesnce ?

Did you - per chance - get a de-commentarized version of squid.conf as
some Linux distributions provide? If yes, do get the original Squid
source,
and read the squid.conf.default. Examples are in there. And complain to
your distributor!

> Could anyone throw some light on these parameters ( with example usage ):

Well, they are documented quite well in squid.conf.default, and more
stuff in the FAQ, but anyway. Before proceeding, you should first
familiarize yourself with the OR-logic when defining ACLs and the
AND-logic when using ACLs. That is definitely covered in the FAQ:

        http://www.squid-cache.org/Doc/FAQ/FAQ.html

> hierarchy_stoplist

A list of words which will have your squid directly contact the origin,
if any of the words are found in the URL.

        hierarchy_stoplist cgi ?

If a question mark or the word "cgi" (as is, string comparison) is found
in the URL, no parent cache will be bothered. TTBOMN, hierarchy_stoplist
does not allow for regular expressions.

> no_cache

Used with (previously defined) ACLs. If the ACL set matches (they can
match
virtually anything from client address to server name, daytime, URL,
etc,
see the ACL section in squid.conf.default), the corresponding object
will not be stored on your disks. Beware, if it is already on your
disks,
they will *not* be removed immediately, only eventually.

        acl QUERY urlpath_regex cgi-bin \? cgi$ asp$ php3$ [sp]html$
        no_cache deny QUERY

If any of the regular expressions cgi-bin, question mark, URLs ending in
cgi or asp or php or php3 or shtml or phtml, the object will not be
stored on the disk. Please note the "double negative" wording of the
"no_cache" rule. Read the "no_cache" as if it said
"should_I_store_this_on_your_disks".

> always_direct

Used with (previously defined) ACLs. If the ACL set matches, all peer
caches will be skipped, and the origin site is contacted directly for
the request.

        acl LOCAL dst 130.75.0.0/16
        always_direct allow LOCAL

For any destination (origin site) in the 130.75.0.0-130.75.255.255
network, go directly to the origin. The option is very useful for any
site within your own network. It becomes really powerful, if combined
with the AS ACLs:

        acl whois proto whois
        always_direct allow whois
        acl dst_dfn dst_as 1275 1754 5520 8450 553 680
        always_direct allow dst_dfn
        as_whois_server <any.radb.whoisd>

The above says, for any whois request, go directly to the whois server
(specified by the as_whois_server line), and for any destination in
the autonomous systems 1275 to 680 (the German E&R network), go to
the destination directly (do not go via Start, to not get $0). The
rule is valid for any cache *within* the German E&R network, as for
most dst_dfn destinations, using the backbone is faster than going
via a parent cache (also in the backbone, but still slower). The AS
number are *once* resolved during startup into the corresponing
networks - the reason you need a RADB compatible whois server, see
www.irrd.net for a free daemon.

Small hint: Recent versions of Squid need the first two lines of
the example above in order to use the AS feature correctly - assuming
you are not behind a firewall.

> never_direct

The reverse of "always_direct". For matches of the ACL set, never ever
contact the origin site directly. This is useful, if you are behind
a firewall and must use the fw proxy for outside connections. It can
also become useful for certain kinds of request routing.

Beware of specifying rules that would match both, "always_direct" and
"never_direct". Squid does complain bitterly about those glitches,
because it sits between the chairs.

> prefer_direct

prefer_direct is a switch to change the behaviour of the peer selection
scheme. By default, Squid prefers to go directly to the origin site
instead
of asking a parent. If you are member of a caching hierarchy (not the
top
level node), it is good to set prefer_direct to "off" in order to
utilize
your parent caches.

        prefer_direct off

> I am not clear as to how is "hierarchy_stoplist" and "no_cache" different in
> terms of functionality ?

They are unrelated, the actions are unrelated.

> Also "always_direct", "never_direct" and "prefer_direct" have very similar
> behaviours.

"always_direct" and "never_direct" are, in a way but not completely,
opposite
sides of a coin (read squid.conf.default for details), whereas
"prefer_direct"
is a switch to control the peer selection scheme.

-- 
Le deagh dhùrachd,
Dipl.-Ing. Jens-S. Vöckler (voeckler@rvs.uni-hannover.de)
Institute for Computer Networks and Distributed Systems
University of Hanover, Germany; +49 511 762 4726