On 05/10/2012 11:12 AM, Eliezer Croitoru wrote:
On 10/05/2012 16:55, Chris Ross wrote:
Reviving this old question again. So, I understand that I can
make external ACLs, and from looking at the config documentation,
I suspect I can have a single external_acl_type definition, and
invoke the same class for N "acl external" lines.
So, I think I'll have to implement something internal to squid.
And, I think it shouldn't be ACL based, because the boolean nature
of ACLs just doesn't fit the arbitrary size of this problem space.
Thanks. And if anyone has any suggestions or sees something I
didn't think of, please let me know.
well as i recommended before you should use some either iptables or
route method.
i think that in this specific case you will need to use some helper to
match a client user name to source ip via some auth helper on squid or
iptables captive portal or a ldap database\radius that will be
updated\scanned once per minute\more\by change and.
this is a very very "specific" requirements case that will require a
unique config generator.
you can use some iteration code to build these specific ACLs in squid
but still it will require a lot of preparations and testings to make it
work flawlessly but i'm recommending a routed based rules that has some
series experience doing these kind of stuff.
it seems like not to be related to squid directly but squid can help in
auth with auth helper or external helper.
can you be more specific about the real needs for this environment you
are talking about?
Yes, my needs are very specific/unusual, I understand that. And I'm
happy to develop the solution myself. I just wanted to inquire of
those more familiar with the code and practices, to get any suggestions
of the best approach(es).
I'm afraid I can't be very specific, but the basics are that there is
a whole system in place, on the squid server and the edge router, that's
already doing fairly complicated routing and NAT'ing. But as they have
no [ability] knowledge of the layer 7 protocol and requirements, it
falls to squid to tell the layer 3 routing how the requests should be
routed. Currently, that's done by choosing [with rules] from a fair
number of existing IP addresses on an interface.
And I understand that whatever I do I'm going to want some automated
system to manage the configuration. But putting the functionality into
squid, or a helper, needs to be done before I try to configure it. :-)
just got into my mind that you can you can use the external_acl helper
to make sure that the routing is applied right to match specific
user\server and to always use a "OK" or "ERR" answer just to make the
helper run every time.
Yeah, I considered that as well. But as I mentioned above, I'm
concerned that making it ACL-based at all, whether internal or external,
will require iteration of all of the ACLs for each path, and the costs
of that will be too high. Iterating 2 or 5 ACLs, sure, but not dozens
or hundreds for each request passing through.
So I'm back to assuming I'll have to either extend
"tcp_outgoing_address" to effectively build a pool rather than
a single address, or have some other config parameter by which
I can build said pool of addresses.
Does anyone have any thoughts of what sort of tuning might be useful
for how to choose from an address pool? I know what my requirements
are for my case, and a predecessor here already took the simple
approach of just coding them into an earlier version of squid. I'm
just wondering if some sort of more general solution might make at
least some of the code get back into the core squid code-base.
Thanks again, all.
- Chris
