Last modified: 2014-08-11 16:37:39 UTC
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?
Btw this seems to be tracked (and acted upon?) at https://wikitech.wikimedia.org/view/Httpsless_domains
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
All merged and deployed
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 * 301 Moved Permanently https://noboard-chapters.wikimedia.org/ reedy@tin:~$
https://gerrit.wikimedia.org/r/143281 https://gerrit.wikimedia.org/r/#/c/134948/ Ok, so now https://noboard-chapters.wikimedia.org/ works. The redirect doesn't (SSL complains)
(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.
https://github.com/EFForg/https-everywhere/pull/345
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
