Last modified: 2014-08-11 16:37:39 UTC

Wikimedia Bugzilla is closed!

Wikimedia has migrated from Bugzilla to Phabricator. Bug reports should be created and updated in Wikimedia Phabricator instead. Please create an account in Phabricator and add your Bugzilla email address to it.
Wikimedia Bugzilla is read-only. If you try to edit or create any bug report in Bugzilla you will be shown an intentional error message.
In order to access the Phabricator task corresponding to a Bugzilla report, just remove "static-" from its URL.
You could still run searches in Bugzilla or access your list of votes but bug reports will obviously not be up-to-date in Bugzilla.
Bug 31335 - Rename wikis with multiple subdomains
Rename wikis with multiple subdomains
Status: RESOLVED FIXED
Product: Wikimedia
Classification: Unclassified
SSL related (Other open bugs)
unspecified
All All
: Normal normal with 1 vote (vote)
: ---
Assigned To: Sam Reed (reedy)
:
: 46056 (view as bug list)
Depends on: 38763 64977
Blocks: wikis-to-rename ssl 29896 31333
  Show dependency treegraph
 
Reported: 2011-10-03 20:39 UTC by Brion Vibber
Modified: 2014-08-11 16:37 UTC (History)
12 users (show)

See Also:
Web browser: ---
Mobile Platform: ---
Assignee Huggle Beta Tester: ---


Attachments

Description Brion Vibber 2011-10-03 20:39:30 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?
Comment 1 Nemo 2012-03-15 09:16:55 UTC
Btw this seems to be tracked (and acted upon?) at https://wikitech.wikimedia.org/view/Httpsless_domains
Comment 2 Daniel Zahn 2013-02-11 08:43:20 UTC
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.
Comment 3 Nemo 2013-02-11 08:51:54 UTC
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.
Comment 4 Daniel Zahn 2013-02-11 08:55:16 UTC
The idea was to move ALL wikimedia chapters and pseudo-chapters within the US to wikimedia.us.
Comment 5 Nemo 2013-02-11 09:09:12 UTC
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.
Comment 6 Daniel Zahn 2013-02-11 17:43:50 UTC
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..
Comment 7 Ryan Lane 2013-03-13 04:58:59 UTC
*** Bug 46056 has been marked as a duplicate of this bug. ***
Comment 8 Sam Reed (reedy) 2013-03-14 23:00:33 UTC
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',
Comment 9 Sam Reed (reedy) 2013-05-07 01:39:29 UTC
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..
Comment 10 Alex Monk 2013-08-25 15:19:47 UTC
(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?
Comment 11 Gerrit Notification Bot 2014-05-30 13:25:57 UTC
Change 53885 abandoned by Reedy:
Update wgServer, wgCanonicalServer for sub.subdomain wikis

Reason:
superseded

https://gerrit.wikimedia.org/r/53885
Comment 12 Sam Reed (reedy) 2014-06-25 00:53:37 UTC
All merged and deployed
Comment 13 Casey Brown 2014-06-30 21:20:20 UTC
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>.
Comment 14 Andre Klapper 2014-07-01 09:53:52 UTC
"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.
Comment 15 Sam Reed (reedy) 2014-07-01 12:19:20 UTC
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:~$
Comment 16 Sam Reed (reedy) 2014-07-01 12:24:56 UTC
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)
Comment 17 Alex Monk 2014-07-01 14:18:40 UTC
(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?
Comment 18 Sam Reed (reedy) 2014-07-01 14:33:29 UTC
(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.
Comment 19 Sam Reed (reedy) 2014-07-01 18:51:56 UTC
https://github.com/EFForg/https-everywhere/pull/345
Comment 20 Erlend Bjoertvedt 2014-08-11 16:10:13 UTC
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
Comment 21 Sam Reed (reedy) 2014-08-11 16:34:32 UTC
(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?
Comment 22 jeremyb 2014-08-11 16:37:39 UTC
(In reply to Sam Reed (reedy) from comment #21)
> Still? Could you ever?

in any case, file a new bug for that

Note You need to log in before you can comment on or make changes to this bug.


Navigation
Links