Bug #2591
closed
Squid3 can't listen on a CARP VIP
Added by Adam Thompson over 12 years ago.
Updated over 8 years ago.
Description
The squid3 package allows syncing between HA peers, but .../squid.xml only allows selection of physical interfaces, and does not permit listening on a CARP VIP. So what's the point in having the XMLRPC sync capability, then?
Running "2.1-BETA0 (amd64) built on Tue Aug 14 12:18:46 EDT 2012 FreeBSD 8.3-RELEASE-p4" with squid3 pkg version "3.1.20 pkg 2.0.5_3".
- Target version deleted (
2.1)
- Affected Version deleted (
2.1)
probably better off posting this to the packages board on the forum, the maintainers tend to not look here.
- Status changed from New to Closed
That's nice, but nothing in that thread addresses the problem; JimP completely missed the point. And I believe you're dead wrong - there is something to failover here with Squid.
Browsers are configured to talk to a proxy at a known IP address. Browsers do not have the capability (except through a WPAD script) to failover to another configured proxy IP address. Therefore, if I have a pfSense HA pair running Squid, the only LAN-side IP address that fails over from system A to system B is the CARP VIP.
The aim is to not have to reconfigure every single browser when an HA failover takes place. I don't care about state, I only care about Squid still being reachable at that single configured address.
And, my original question remains - and is also not addressed by JimP's response in that thread - what's the point of config sync on a package that can't usefully fail over?
The XMLRPC sync is there to synchronize configuration. You will NOT get any failover with Squid, as already explained on the thread... Use WPAD or whatever.
For those getting bit by the missing CARP interfaces, a viable workaround is to
- Bind Squid to Loopback (127.0.0.1) interface.
- Create a port forward from <CARP IP>:3128 to 127.0.0.1:3128.
- Have your users hit <CARP IP>:3128.
You will obviously not get any kind of graceful/stateful failover (i.e. all in-transit HTTP transfers will be aborted) but when your end-users retry their HTTP request (or when their webapp retries it in the background) they will succeed and not call you to complain at 03:00.
Also available in: Atom
PDF