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
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..
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
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
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.
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