Page MenuHomePhabricator

Rename wikis with multiple subdomains
Closed, ResolvedPublic

Description

As seen on bug 29896 comment 4 about https://arbcom.de.wikipedia.org/ :

Ryan Lane 2011-10-03 13:03:22 PDT

Ugh. Wikis with subdomain names like this are seriously problematic. If you
notice, HTTPS works, but there's a certificate error since it doesn't match
*.wikipedia.org.

We should actually look at moving sub-subdomains like this to some other name.
arbcom-de maybe?


Version: unspecified
Severity: normal

Details

Reference
bz31335

Related Objects

StatusSubtypeAssignedTask
ResolvedNone
InvalidNone
ResolvedNone
ResolvedNone
DeclinedNone
DeclinedNone
InvalidNone
InvalidNone
Declined brion
Resolvedyuvipanda
DeclinedNone
ResolvedNone
ResolvedNone
ResolvedNone
ResolvedNone
Resolved Tfinc
ResolvedNone
DeclinedNone
ResolvedNone
ResolvedRyanLane
ResolvedNone
ResolvedReedy
ResolvedNone
ResolvedNone
ResolvedCatrope

Event Timeline

bzimport raised the priority of this task from to Medium.Nov 21 2014, 11:54 PM
bzimport added a project: HTTPS.
bzimport set Reference to bz31335.

Yes, we would still like to move those domains to something else. I suggest moving pa.us.wikimedia to pa.wikimedia.us (yes, we have wikimedia.us too). And moving arbcom to arbcom-de. There shouldn't be too many other sub.sub domains, now that *.planet.wm is fixed.

It would be better to centralise them all under wikimedia.org with dashes: pa.wikimedia.us would be extremely confusing, as all chapters and pseudo-chapters with wiki at WMF have them under wikimedia.org; if they didn't, it would be hard for the user to tell which wikis are hosted by WMF and which aren't.

The idea was to move ALL wikimedia chapters and pseudo-chapters within the US to wikimedia.us.

Yes but we still have dozens of non-USA chapters with wiki hosted by WMF. That's the confusion I'm referring to. Without a clear boundary, we'd start getting a bunch of confused questions to WMF sysadmins (but also stewards and whatnot) about chapter wikis they don't control, or vice versa questions to chapters about software things they don't control (for chapter wikis hosted by WMF).
The projects' domains should be clean too, there's no acceptable reason for organisational wikis to be under wikipedia.org domain.

I understand your point. Yeah, but when it comes to questions who "controls" a site, we already have maximum confusion. Some chapters are completely controlled by chapters (incl. domain and DNS servers), some don't own the domain names, some do, some point to WMF name servers, some don't and so on..

*** Bug 46056 has been marked as a duplicate of this bug. ***

Looks like the remaining double subdomain ones are:

'arbcom_dewiki' => 'arbcom.de.wikipedia.org',
'arbcom_enwiki' => '
arbcom.en.wikipedia.org',
'arbcom_fiwiki' => 'arbcom.fi.wikipedia.org',
'arbcom_nlwiki' => '
arbcom.nl.wikipedia.org',

'wg_enwiki' => 'wg.en.wikipedia.org',
'noboard_chapterswikimedia' => '
noboard.chapters.wikimedia.org',

Bar giving notice (though, if the redirects are in place, it shouldn't really matter), these can all be renamed fairly simply, as they don't require their actual databases renaming.

There is bug 46746, but is a relatively small issue..

(In reply to comment #9)

There is bug 46746, but is a relatively small issue..

Why are private wikis even on the WikiSet manager anyway?

Change 53885 abandoned by Reedy:
Update wgServer, wgCanonicalServer for sub.subdomain wikis

Reason:
superseded

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

bugs wrote:

The Norwegian chapter's board site looks to be broken after this bug was fixed, see https://noboard.chapters.wikimedia.org and https://noboard-chapters.wikimedia.org.

"noboard.chapters.wikimedia.org uses an invalid security certificate."
followed by "No wiki found".

(In reply to Sam Reed (reedy) from comment #12)

All merged and deployed

Reedy: Gerrit links very welcome to be able to see what code actually changed.

https://gerrit.wikimedia.org/r/#/c/134939/

Just noticed an issue in InitialiseSettings.php

But the apache config looks broken...

reedy@tin:~$ apache-fast-test ~/urls.txt pybal
testing 2 urls on 192 servers, totalling 384 requests
spawning threads.............

https://noboard-chapters.wikimedia.org

  • 404 Not Found

https://noboard.chapters.wikimedia.org

reedy@tin:~$

(In reply to Sam Reed (reedy) from comment #16)

The redirect doesn't (SSL complains)

I'm pretty sure that's to be expected, isn't it? Is this bug fixed properly now?

(In reply to Alex Monk from comment #17)

(In reply to Sam Reed (reedy) from comment #16)

The redirect doesn't (SSL complains)

I'm pretty sure that's to be expected, isn't it? Is this bug fixed properly
now?

Mmm. I wasn't sure if there might be a way to get our SSL termination (whether standalone or on varnish) to do a redirect before the handshaking, but it's not doable (Checked with Ops for any bright ideas). So I guess it is fixed.

To this extent though, I'll add (and get backported) rulesets for HTTPS Everywhere to redirect these away.

Due to the relatively small number of users of these wikis, it should be easier to just tell them to update bookmarks to use the new proper urls, and maybe get someone to have a look for any obvious outbound links to those wikis that needs updating.

erlend wrote:

Regarding noboards at:
https://noboard-chapters.wikimedia.org/

It is still not possible to upload images to the site. This is a substantial problem, since we use noboards to store all the documents of WMNO.

Is there any way this could be fixed...?

Kind regards

Erlend Bjørtvedt
WMNO

(In reply to Erlend Bjoertvedt from comment #20)

Regarding noboards at:
https://noboard-chapters.wikimedia.org/

It is still not possible to upload images to the site. This is a substantial
problem, since we use noboards to store all the documents of WMNO.

Is there any way this could be fixed...?

Kind regards

Erlend Bjørtvedt
WMNO

Still? Could you ever?

(In reply to Sam Reed (reedy) from comment #21)

Still? Could you ever?

in any case, file a new bug for that