May we have this ticket assigned to (someone of) the ops team?

Any idea if and when this will happen? Thanks!

Imported to RT for ops and CC'ed Kelson and Richard: RT #6853

Reedy, is this renaming feasible?

Change 113877 had a related patch set uploaded by Jeremyb:
redirect ukwikimedia to wikimedia.org.uk

https://gerrit.wikimedia.org/r/113877

(In reply to jeremyb from comment #4)

Reedy, is this renaming feasible?

"Probably" more trouble than it's worth. I guess we wouldn't know for sure unless it was actually attempted.

Please use another wiki on the cluster (e.g. enwiki, metawiki) for sending new passwords to stragglers. (by special:emailuser) Very few users would have only a ukwikimedia account and not also one on those other wikis. (especially with automatic creation)

Taking.

Change 113878 had a related patch set uploaded by Jeremyb:
close ukwikimedia

https://gerrit.wikimedia.org/r/113878

FYI: ~500 users didn't have a global account.

@Kelson, how many of those have actually made any edits?

jeremyb, Reedy or any other ops reading,

We are happy for the old wiki to be closed and the old URL redirected to wikimedia.org.uk as per the attached patches by jeremyb. Please action this as soon as you are able anytime after this weekend.

Regards,

Katie Chan
Volunteer Support Organiser
Wikimedia UK

(In reply to Katie Chan from comment #10)

Please action this
as soon as you are able anytime after this weekend.

To clarify:

This should be done at any time or only be done *after* 2014-02-23?

After 2014-02-23, but as soon as from that point, to give a final chance to those ~500 users without an unified account to claim it. That's the go live date, any intermediate steps (if there's any) could be done before that with no problem.

Is this no longer a request to rename uk.wikimedia.org to sth else? It's mentioned in comment 6 but without answer.

(In reply to MF-Warburg from comment #13)

Is this no longer a request to rename uk.wikimedia.org to sth else? It's
mentioned in comment 6 but without answer.

IMHO we should skip the rename entirely. The UK's requested timeline for the redirect accounts for losing access (i.e. not doing a rename) after the 23rd. See below:

(In reply to Katie Chan from comment #12)

to give a final chance to
those ~500 users without an unified account to claim it

(In reply to MF-Warburg from comment #13)

Is this no longer a request to rename uk.wikimedia.org to sth else? It's
mentioned in comment 6 but without answer.

MF-Warburg, that's correct. Given a choice between waiting indefinitely for a possible rename and a much quicker redirect only, we are going for the redirect only option.

Katie Chan
Volunteer Support Organiser
Wikimedia UK

So the old wiki should be deleted?

Keep a backup of the db somewhere, otherwise yes.

Why couldn't this be a DNS redirect (CNAME) of an HTTP permanent redirect that requires performing two separate sessions to separate servers ?

No more trafic reaching WMF servers (except to its third-party DNS hosting service), all the trafic goes directly to WMUK.

Caveat: the WMUK webserver would have to accept HTTP queries whose "Host:" header still uses the former domain name, and to solve it correctly, would host the HTTP redirect itself (so that clients get informed of the change of domain name and can fix their URLs) to specify the correct "Host:" value to use.

The HTTP redirect performed on WMUK servers themselves will be necessary if WMUK wants to be accessible via HTTPS, in order to validate their own security certificate (which cannot be issued by them for a subdomain of wmimedia.org owned and controled by the WMF).

@Philippe

Indeed, this seems to be a pretty elegant solution to me. I have configured the WMUK web server in that way.

So if your web WMUK server is ready, you can now request to the WMF to reconfigure its DNS domain zone with the DNS CNAME

Then the WMF will be able to eliminate completely the HTTP redirect from its web servers (after several weeks, the time for the existing DNS info in remote DNS caches to expire). At the same time it will be purged from the front proxies (Squid) of the WMF.

The WMUK HTTP server is already correctly configured, you can check it if you want by modify your local hosts file and make uk.wikimedia.org pointing to 37.188.117.184.

But:
1 - Do we have a backup somewehere of uk.wikimedia.org? If the WMF is not willing to host it, would that be possible for WMUK to get it?
2 - We request this DNS change. May this bug report plays this role?

In my opinion; each web site should configure itself its own remote backup solution; this is independant of the web hosting or DN hosting: the backup is compeltely hidden to visitors and it's up to you to configure it privately.

Of course you may backup your site to WMF servers (on WikiTech&Labs?), but for most frequent usage you'll want to create a first level fast backup using a more local server (and then send a compressed protected archived to USA).

Note that your wiki ''may'' also contain private data that you don't want (or cannot legally share to US without users consent, or some legal data required in your country, including tax forms or local billings for your hosting or credit reports from your bank) so this backup to US may require you encrypt this archive before sending it remotely. But all this will never concern visitors of your site.

(In reply to Philippe Verdy from comment #22)

In my opinion; each web site should configure itself its own remote backup
solution;

I think you may have misunderstood Emmanuel's question in comment 21.

There are two wikis:

• the old one at uk.wikimedia.org that is hosted by the WMF
• the new one at wikimedia.org.uk that is hosted by WMUK

The old, WMF-hosted, wiki was closed in September but it still features prominently in search engine results etc. despite doing nothing but displaying a message telling users they need to visit the new, WMUK-hosted, wiki. This bug is about a request to change that so that all visitors to the old wiki are automatically redirected to the new wiki (various methods for doing this have been discussed, but the objective is the same).

The old wiki though does still have history from before September, and it is a backup of this that comment 21 is talking about. Obviously a backup of the new wiki is a Good Thing, but it is not relevant to this request AIUI.

Note: the former security certificates for uk.wikimedia.org will no longer validate in your new domain.
If the WMF reconfigure its DNS to redirect the trafic to uk.wikimedia.org to the new domain wikimedia.org.uk, then the HTTPS trafic trying to connect to uk.wikimedia.org will reach your webserver (accepting HTTP connections to the old domain in order to redirect it to the locally hosted new domain).
But HTTPS may not work for two reasons:

• you don't have the security keys needed to sign your new site certificate, so the new server may be considered as if it was attempting to still the former domain.
• IPSEC may have been activated in the former domain, and changing the former canonical subdomain to make it a CNAME aliaed to a new canonical domain may cause IPSEC to return an error, and the browser to reject the connections (or warn the user that the new domain may have been illegitimitately redirected).
• You webserver still needs to perform an HTTP(S) redirect of the queries host to the new domain.
• Your redirector should preserve the protocol (when querying initially the old domain on your web server with HTTPS, you should redirect to the new domain using also HTTPS instead of HTTP).
• You need a new certificate for the HTTPS protocol used by your webserver for your new domain. This certificate is independant of the certificate issued for authenticating domains of the WMF (but the WMF may add its own signature to approve your new domain as being legitimate for the two redirection performed on the WMF DNS *and* on your web server)

So I recommand you really test the connection (using the local hostfile solution temporarily) to make sure that HTTPS links from pages in Wikipedia will not invalidate some checks performed by web servers, or plugins or other antivirus tools checking sites authenticity.

(In reply to Chris McKenna from comment #23)

(In reply to Philippe Verdy from comment #22)

In my opinion; each web site should configure itself its own remote backup
solution;

I think you may have misunderstood Emmanuel's question in comment 21.

There are two wikis:

• the old one at uk.wikimedia.org that is hosted by the WMF
• the new one at wikimedia.org.uk that is hosted by WMUK

I had fully understood this. My comments were relevant since the beginning, including when I replied to the question related to remote backups of the newer WMUK website.

Thank you for your advice, concerns, warning etc. etc. Can we just do it without further discussion? If things are done correctly on WMF side and something doesn't work because of a misconfiguration on WMUK side, then we'll fix it. Thank you!

Katie Chan
Volunteer Support Organiser
Wikimedia UK

(In reply to Katie Chan from comment #26)

Can we just do it
without further discussion?

Sure, but I won't be involved any further. I can't think of any way that deploying as is will cause permanent harm and if you want to debate further some other way to do things that could continue after the redirect is in place.

(or you could debate now and redirect later. but not too much on this bug. find some other place to develop consensus / a plan, tell us where that's happening so we can still comment on your plans, and then once you know definitively what you want you can let us know)

I wrote (but didn't send) a big rant about how this bug has gotten out of control. There's no way you could justify discussing backups for the new site on this bug given what you say you already understood (comment 25) when you wrote that. In any case, (regardless of relevance) some comments on this bug are overly and unnecessarily verbose/long.

Do you think that my suggestion in comment 18 is overlong when it includes also the warning about the possible caveat (that should probably not be forgotten during the migration of the discussed chapter website)? And where's then the link on the new WMUK site (or on Meta) to track the other discussions that may be needed outside this bugtracker which currently asks for "patch review"?

(In reply to Philippe Verdy from comment #28)

And
where's then the link on the new WMUK site (or on Meta) to track the other
discussions that may be needed outside this bugtracker which currently asks
for "patch review"?

I don't know, feel free to ask the WMUK team directly. This bug definitely isn't the place. (but you could put a pointer to that place here)

Do you think that my suggestion in comment 18 is overlong when it includes
also the warning about the possible caveat (that should probably not be
forgotten during the migration of the discussed chapter website)?

That makes me wonder again if you're really clear that the migration is already essentially complete? (the last thing to wrap it up is this bug)

Maybe comment 18 was too long. Hard to say because I don't know what you meant for some parts. (see below for some questions) That may be an example where length can be somewhat mitigated by clearly delineating some sections from other. Like you would use <h#> headings in HTML. In this case some readers could ignore the caveats if they're uninterested in doing a CNAME.

(In reply to Philippe Verdy from comment #18)

Why couldn't this be a DNS redirect (CNAME) of an HTTP permanent redirect
that requires performing two separate sessions to separate servers ?

Either way is 2 separate requests (what does session mean?) and probably 2 separate connections. [[HTTP pipelining#Implementation status]] currently indicates that most proxies and browsers (except Opera) either don't support pipelining or have it disabled by default. Also, maybe some implementations will make a different connection per hostname? (idk what the specs have to say about that)

So (even assuming the CNAME route) most (all?) requests by actual users for the old domain will be done without pipelining. (we don't care about perf for googlebot, right? and if this *is* about perf maybe WMF perf is *better* than WMUK?)

We can safely discard the 2 sessions argument.

No more trafic reaching WMF servers (except to its third-party DNS hosting
service), all the trafic goes directly to WMUK.

Why does this matter? That should be answered up front. (I'm not necessarily saying it doesn't. but if we're going to spend cycles figuring out a more complicated solution than what was originally requested (comment 0) there should be some reason for it)

For the record, WMF has no 3rd party DNS hosting. (All DNS is served from WMF boxes in WMF racks. Where did that idea come from?)

Caveat: the WMUK webserver would have to accept HTTP queries whose "Host:"
header still uses the former domain name, and to solve it correctly, would
host the HTTP redirect itself (so that clients get informed of the change of
domain name and can fix their URLs) to specify the correct "Host:" value to
use.

The HTTP redirect performed on WMUK servers themselves will be necessary if
WMUK wants to be accessible via HTTPS, in order to validate their own
security certificate (which cannot be issued by them for a subdomain of
wmimedia.org owned and controled by the WMF).

I have no idea what that last paragraph means.

FWIW, there's plenty of precedent for using the main WMF cluster for redirect-only domains pointing to off-cluster services and that trend is increasing. See e.g. bugzilla.mediawiki.org, doc.mediawiki.org, labs.wikimedia.org, it.wikimedia.org, hu.wikimedia.org, ch.wikimedia.org, etc.

There's only one active precedent I can find for CNAME from a chapter country code subdomain of wikimedia.org to an off-cluster target. That's cs/cz which both have the same target which doesn't even listen to port 443 at all.

If you do care at all about HTTPS clients hitting the legacy hostname then I advise against a CNAME. (especially because AFAIK there's not an actual argument in favor of the CNAME. Please point it out if one does exist)

I don't know why this request has gotten so overly complicated. WMUK decided it might want to start hosting its own website, and so discussed with WMF that possibility. WMUK is not the first chapter to do so, and probably won't be the last. From the very start, the plan has always involved eventually shutting down ukwikimedia and redirecting uk.wikimedia.org to wikimedia.org (the opposite to what was previously happening).

When this bug were initially filed, we additionally requested ukwikimedia to be moved to a different domain. On finally being informed that a ukwikimedia rename was "probably more trouble than it's worth", we agreed to only go with the URL redirect, which again was always in the plan, we're just wanting it a bit earlier than we had originally planned to.

So can we do this already? Thanks!

Katie Chan
Volunteer Support Organiser
Wikimedia UK

Change 113877 merged by Faidon Liambotis:
redirect ukwikimedia to wikimedia.org.uk

https://gerrit.wikimedia.org/r/113877

Change 113878 merged by jenkins-bot:
close ukwikimedia

https://gerrit.wikimedia.org/r/113878

My only comment about this approach is that we now have a *.wikimedia.org domain pointing directly to a server in the UK. Given that politicians on both sides of the Atlantic have gone bonkers with internet regulation proposals, this DNS redirect could expose both WMF and WMUK to more legal complications.

Then I thought about it again: if those nutjob politicians want to screw the internet over, they are able to do that regardless.

(In reply to Deryck Chan from comment #33)

If I judge based on merged https://gerrit.wikimedia.org/r/113877
then it's not a DNS redirect, but only a standard 301 permanent redirect (in difference to what described in this report)