Tom Lobato wrote:
Henrik Nordstrom escreveu:
mån 2007-01-15 klockan 23:09 -0200 skrev Tom Lobato:
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
As Henrik said at the end. Its all up to how you implement the helper.
How the data of GOOD/BAD gets from HQ to the office. That depends on
exactly what ACL you want to implement.
The simplest alternative to external_acl is a single configuration file
(making sure that each remote proxy is the same version) which gets
pulled via ssh at regular intervals from HQ.
Some types of ACL can be publicly published for remote reference, some
must be private, and some should be sent to each office over an
encrypted link at intervals (the squid.conf entire transfer mentioned
above).
For Example;
Clients are to be protected from visiting known phishing and spam
websites.
=> I created a helper that checks requested domains against the SURBL
RBL in DNS. It will only allow you to check domain names against an RBL
(you could make a private one).
Also, certain clients want remote access through the cache.
=> I had to setup a secure database request from the proxy server to an
SQL database at HQ where the logins are kept for auth.
You see? none of it is squid. All of it is the custom scripted external_acl.
AYJ
