Jay Asworth wrote:
As long as the proxy supports IPv6, it can continue to talk to Apache
via IPv4; since WMF's internal network uses RFC1918 addresses, it won't be affected by IPv4 exhaustion.
It might; how would a 6to4NAT affect blocking?
If the XFF header is right, from mediawiki POV an IPv4 internal NAT is no different than being a native IPv6 server.
George Herbert wrote:
On Thu, Feb 3, 2011 at 1:05 PM, River Tarnell r.tarnell@ieee.org wrote:
Does any useful discussion still take place on that list?
- river.I don't know; did any ever? 8-)
It doesn't matter if Apache supports IPv6, since the Internet-facing HTTP servers for wikis are reverse proxies, either Squid or Varnish. I believe the version of Squid that WMF is using doesn't support IPv6.
As long as the proxy supports IPv6, it can continue to talk to Apache via IPv4; since WMF's internal network uses RFC1918 addresses, it won't be affected by IPv4 exhaustion.
Ah, yes. That problem. "We're" using that hacked up Squid 2.7, right?
They are two different branches. Seems WMF will need to move from squid package to squid3.
It is running with 9 custom patches. I thought more of them would have been included upstream.
02-dfl-error-dir.dpatch Trivial. But ./configure --datadir=/path should be used instead. 10-nozerobufs.dpatch It's probably merged in, since we got it from upstream. 20-wikimedia-errors.dpatch Easy. It uses language codes now. 21-nomangle-requestCC.dpatch Simple to patch. 21-nomanglerequestheaders.dpatch No longer needed. squid3 has a configuration option for this. 22-normalize-requestAE.dpatch It's easy to strip the other encodings. I'd drop the first piece. 22-udplog.dpatch Candidate for manual patching. parse_sockaddr_in_list is now parse_IpAddress_list_token, remember that parse_sockaddr is made from the piece taken from the previous function. 25-coss-remove-swap-log.dpatch Not applicable. No COSS support in squid3 23-variant-invalidation.dpatch 26-vary_options.dpatch Need to be reimplemented.