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(a)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.