Henrik Nordstrom escreveu:
mån 2007-01-15 klockan 23:09 -0200 skrev Tom Lobato:
Well, I already read about external_acl_type, but as far as I
understood, each one and all requests (so, all objects within a page)
are processed by it.
Not quite. Only every unique combination of the parameters given to
external_acl_type, once per ttl. I.e. if you use %DST with a ttl of 3600
(the default) then there is one query per visited site per hour, for all
users of this proxy.
Oh good. It must to lower the number of requests to send to the helper.
So, I realized it would create much delay and
bandwidth, since each one have to send to the central squid, processed
and returned. So I opted to store ACLs locally.
The queries are not sent to the central Squid, it's sent to the helper
specified in external_acl_type. How that helper finds the answer is
outside of Squid and up to the implementation of the helper. It could be
Yes, I read this, but since I need centralized/syncronized
configuration, again I fall in the same problem: I need to implement a
system to update all from central. Or downloading the data and accessing
locally or accessing the central on demand (per request to the helper).
Since I'm avoiding the second case, external_acl_type give me one more
way to make the first case. So, between one way (use it) or other (not
use it) to make the first case, I think its better not to use
helper/external_acl_type. Why?
If I use external_acl_type, I have to download the data (permissions,
user/pass) to local machine, and when squid calls the helper, it has to
"assimilate"/proccess the data for answer to squid. Well, I would be
putting in the helper code a programmation that squid already does (when
parsing its acls in squid.conf). It would be create a unnecessary layer
between central squid data and clients squidnt.
Sure, if I missed something, tell me.
PS: sorry my english =)
querying an database at your central office, or some distributed
resource, it's all up to how you implement the helper.
Regards
Henrik
Tom Lobato
