Re: organization squid.conf

[Amos Jeffries <squid3@xxxxxxxxxxxxx>]

Riccardo Castellani wrote:
> > Neither. Look at what the requirements are for each and create logical 
> > groupigs that do not interfere with each other and in order configured 
> > do what your policy requires.
> >
> > Also, be extremely careful about http_reply_access.
> >  It's often over-blocked by using rules that duplicate http_access. 
> > This can either prevent access denied pages getting out to bad 
> > viewers, or cause extra useless load.
> > Only use it to filter requests that cannot be checked earlier in 
> > http_access.
> >
> >
> > Amos
>
>
>
>
> Ok I can looking for requirements for all my acl, but what means creating
> logical groups ?
> It means that group can contain both acl and directives ?
>
> I thought acl should be next to directive where it's used so there is more
> cleaning. What do you think ?

I think I mean roughly the same thing with grouping the directives used 
for a particular purpose together. But going a little further than just acl.

What I mean is more like the way I've written the wiki ConfigExamples/* 
pages.

So that in later Squid people can place the whole directive group into a 
file and use "include" directive on the file at the right place of 
squid.conf.

for example...

/etc/squid/squid.conf.d/00-accel-website-X:
#
http_port 80 accel vhost
cache_peer X ...
#
acl Xdom ....
cache-peer_access X allow ...
http_access allow X

/etc/squid/squid.conf.d/cache:
#
cache_mem ...
#
cache_dir ...
#
maximum_object_size ...
#
cache allow all


squid.conf:
#
# local configuration
include /etc/squid/squid.conf.d/*
...


Amos

> ----- Original Message ----- From: "Amos Jeffries" <squid3@xxxxxxxxxxxxx>
> To: "Riccardo Castellani" <r.castellani@xxxxxxxxxxxxxxx>
> Cc: <squid-users@xxxxxxxxxxxxxxx>
> Sent: Wednesday, June 17, 2009 5:21 PM
> Subject: Re:  organization squid.conf
>
>
> > Riccardo Castellani wrote:
> > > What do you suggest to prepare a clean squid.conf ?
> > > I have many many ACL which I use in these directive:
> > >
> > > no_cache deny
> >
> > change #1:
> >   no_cache deny X
> > to:
> >   cache deny X
> >
> > no_cache is an obsolete option name.
> >
> > > http_access deny
> > > http_access allow
> > >
> > >
> > > 1- To collect ACL all together or I can insert specific ACL groups 
> > > next to
> > > directives where they are used, e.g.
> > >
> > >
> > > Acl A...
> > > Acl B...
> > > Acl C...
> > > no_cache deny A
> > > no_cache deny B
> > > no_cache deny C
> > >
> > > Acl E...
> > > Acl F..
> > > Acl G...
> > > http_access allow E
> > > http_access allow F
> > > http_access allow G
> > >
> > > Acl H...
> > > Acl I..
> > > Acl L...
> > > http_reply_access allow H
> > > http_reply_access allow I
> > > http_reply_access deny L
> >
> > Neither. Look at what the requirements are for each and create logical 
> > groupigs that do not interfere with each other and in order configured 
> > do what your policy requires.
> >
> > Also, be extremely careful about http_reply_access.
> >  It's often over-blocked by using rules that duplicate http_access. 
> > This can either prevent access denied pages getting out to bad 
> > viewers, or cause extra useless load.
> > Only use it to filter requests that cannot be checked earlier in 
> > http_access.
> >
> >
> > Amos
> > --
> > Please be using
> >   Current Stable Squid 2.7.STABLE6 or 3.0.STABLE16
> >   Current Beta Squid 3.1.0.8 


--
Please be using
  Current Stable Squid 2.7.STABLE6 or 3.0.STABLE16
  Current Beta Squid 3.1.0.8