Page MenuHomePhabricator

wikiba.se should use HTTPS
Closed, ResolvedPublic

Description

The website wikiba.se seems not to be supporting HTTPS yet.

Related Objects

Event Timeline

There are a very large number of changes, so older changes are hidden. Show Older Changes
Restricted Application added a subscriber: Aklapper. · View Herald Transcript
abian renamed this task from Switch wikiba.se to HTTPS to wikiba.se should use HTTPS.Jan 15 2017, 5:44 PM

wikiba.se is not owned by WMF and doesn't point to WMF DNS servers and the IP it points to is also not under our control.

Therefore i don't really see how this is an Operations/Traffic thing or what is expected from ops at this stage.

Dzahn changed the task status from Open to Stalled.Jan 17 2017, 4:23 PM

wikiba.se is not owned by WMF and doesn't point to WMF DNS servers and the IP it points to is also not under our control.

Therefore i don't really see how this is an Operations/Traffic thing or what is expected from ops at this stage.

Neither do I. Those tags were automatically added. :S

Per H131 whenever a task has the tag HTTPS associated to it, Traffic is automatically added. Then on a next edition SRE is added because Traffic is present.

matmarex subscribed.

The description of HTTPS says "Issues about HTTPS and SSL encryption on Wikimedia servers.", so clearly the solution is to just remove it. :)

wikiba.se is not owned by WMF and doesn't point to WMF DNS servers and the IP it points to is also not under our control.

Just curious: who does? WMDE?

Just curious: who does? WMDE?

Yes.

Namn	Abraham Taherivand
Företag	Wikimedia Deutschland e.V.

Who controls this?
That copy of the site is out of date now and we should probably get rid of it, or update it, but at the end of the day solve T99531

Who controls this?

For unknown reasons the Horizon web interface doesn't show the proxy "wikibase.wmflabs.org" in the project "wikidata-dev" context. (bug)

But it could be found here: https://tools.wmflabs.org/openstack-browser/proxy/

The project is: https://tools.wmflabs.org/openstack-browser/project/wikidata-dev

You can see the list of admins there.

The puppet role is role(wikibase) which i once wrote and it's applied via "prefix puppet" on "all VMs in the wikidata-dev project whose names begin with 'wikibase'.".

What this role does is git clone the deploy repo (wikibase/wikiba.se-deploy). So if that's out of date then either the deploy repo is out of date or the git cloning stopped working.

What this role does is git clone the deploy repo (wikibase/wikiba.se-deploy). So if that's out of date then either the deploy repo is out of date or the git cloning stopped working.

Thanks, updated in https://gerrit.wikimedia.org/r/#/c/wikibase/wikiba.se-deploy/+/453684/

for status on HTTPs for that please see T99531#4511979

T199711 is a deployment task for wikimedia prod, I don't think it will affect this?

I added it because T99531#4511979 says resolving T199711 "makes this whole thing simpler and zero cert cost". and that would include this ticket here afaict.

Dzahn changed the task status from Stalled to Open.Apr 2 2019, 10:19 AM

This is now unstalled. We have a certificate now and it is basically in WMF prod, just DNS has not been switched yet and we need to add some redirects and HSTS.

06:06 < vgutierrez> so.. right now if you set wikiba.se in /etc/hosts or using curl --resolve to point to one of our text-lb you should get the wikiba.se hosted in WMF
06:06 < vgutierrez> something like curl --resolve wikiba.se:443:91.198.174.192 https://wikiba.se
06:06 < vgutierrez> currently the TLS certificate supports wikiba.se and www.wikiba.se

I am out of this. Currently, ns[0-2].wikimedia.org are authoritative for wikiba.se: T99531#4862262.

I guess we need to update operations/dns then?

that's right, operations/dns manages wikiba.se

I am out of this. Currently, ns[0-2].wikimedia.org are authoritative for wikiba.se: T99531#4862262.

Do you know anything about the domain ownership transfer though?

I guess we need to update operations/dns then?

Next is deploying https://gerrit.wikimedia.org/r/c/operations/puppet/+/500715 for T99531#5077170

and then https://gerrit.wikimedia.org/r/c/operations/puppet/+/500695

and then WMDE and WMF have to agree on the domain transfer ownership (Lydia said she will ping some people to find out)

looks like we are not going to do https://gerrit.wikimedia.org/r/c/operations/puppet/+/500711

Also note since recently we now have wikibase.org (https://gerrit.wikimedia.org/r/c/operations/dns/+/503154)

  • done

and then https://gerrit.wikimedia.org/r/c/operations/puppet/+/500695

  • done

and then WMDE and WMF have to agree on the domain transfer ownership (Lydia said she will ping some people to find out)

  • still to do

looks like we are not going to do https://gerrit.wikimedia.org/r/c/operations/puppet/+/500711

  • stalled / abandon?

Also note since recently we now have wikibase.org (https://gerrit.wikimedia.org/r/c/operations/dns/+/503154)

  • I don't assume you guys are interested in switching domains? heh

I ran into this trying to link to https://wikiba.se when explaining Wikibase to someone on Twitter (in the context of use on WikiFur, tracking conventions and charity donations). T99531#5181555 suggests that WMDE isn't going to hand over the domain. So… does WMDE intend to set up Let's Encrypt on their own? It seems the appropriate resolution - WMF has said WMDE can't have their cake and eat it, and setting up Let's Encrypt should not be all that complicated. As it is, web browsers are now showing the site as "not secure", which is not great for a database product. 😼

Currently, the authoritatitative nameservers for wikiba.se are the WMF nameservers. I don't know what your NetOps configured there, so no, I cannot setup Let's Encrypt. Of course, I could configure the default nameservers again, point A and AAAA to some of our servers and deploy Let's Encrypt there, but I believe that wasn't the intention behind your suggestion, @GreenReaper.

Looks to me like it has the same IP address it did last year, which is in "United Domains via IP Exchange GmbH" space.

I don't think you need DNS control to do Let's Encrypt, you can use certbot in "webroot" mode if you have shell access. united-domains.de seems to offer both SSL and SSH access on its "Webspace-Packet" (is this what's in use?). I don't know if that extends to running certbot. However, you could run certbot on another computer and upload a challenge file via SFTP. Obviously that isn't ideal, but it could be scripted if necessary, at least to the point of getting an certificate (I don't know if united-domains's hosting has a scriptable way to change assigned SSL certificates).

That said, I did think about suggesting that switching or reverting nameservers might be appropriate if you don't plan to actually transition to WMF hosting. As a third-party from a non-Wikimedia project, I'm not sure if doing that would have any "political" fallout. I'm just trying to find a practical solution which results in having the HTTPS wikiba.se that I expected to see, given the stated constraints.

WMF nameservers. I don't know what your NetOps configured there

DNS zone files are in a public repo and can be git cloned (gerrit project "operations/dns")

wikiba.se zone is in templates/wikiba.se. It's possible to upload changes to code review.

your NetOps

Original version was uploaded by Addshore in https://gerrit.wikimedia.org/r/c/operations/dns/+/473543 and i don't think GreenReaper is on any side and just wants the issue to be fixed from a user perspective.

I cannot setup Let's Encrypt.

What GreenReaper said, you can use "webroot" authenticator with certbot so you don't need DNS for it, but if you want DNS then see above, that's also possible.

Here's an example config for certbot using webroot for renewal. As used on wikitech-static.wikimedia.org because that's outside our usual infra which uses acmechief.

https://gerrit.wikimedia.org/r/c/operations/wikitech-static/+/526200/2/letsencrypt/etc/letsencrypt/renewal/wikitech-static.wikimedia.org.conf

What GreenReaper said, you can use "webroot" authenticator with certbot so you don't need DNS for it, but if you want DNS then see above, that's also possible.

What I wanted to say: Without control over the zone I cannot know if our webroot will serve the domain. As far as I know migrating the zone was just the beginning of migrating everything wikiba.se-related to WMF. Of course I know how to use Let's Encrypt, but I don't know what the future brings for the content behind wikiba.se. Will it stay on our webspace? Will it be hosted by WMF? As I see it, the zone is currently in some kind of limbo – it still uses the zone file I provided last year, but that won't stay that way I think.

Right, it was the intention to move to WMF hosting. But it seems (as @WMDE-leszek recognised in the other thread), that it will *not* be hosted by WMF, because WMDE won't transfer the domain. I'm presuming this decision comes from their executive director because he was the one to register it.

This is fine, but it means that WMDE now need to decide how to achieve this task: HTTPS on wikiba.se. This can, technically, be done today, under the assumption that WMF won't just pull the rug out and remove the zone from their DNS servers. I appreciate your position that this is not an ideal course of action.

To me, the sensible option to resolve this is to do as you say: redirect DNS away from WMF's servers onto one that WMDE controls, so you can be sure that the IP doesn't change. Again, this is a decision WMDE must make, because it controls the domain registration as well as the current hosting. So maybe this bug needs to be assigned to one of its representatives.

There is I guess a wider issue of what "the Wikibase community" wants. I see a lot of WMDE people in Wikibase (3rd party installations), but I'm guessing not everyone involved is part of that. As I understand it, the website is under the GPL so it'd be possible to for WMF to host it on wikibase.org (which they own, apparently from September 2016) and use it instead for any internal links within its own properties. This could swiftly have HTTPS activated, and might reasonably be expected to gain prominence - in the UK, the MediaWiki.org page for Wikibase actually outranks wikiba.se for Google searches on "Wikibase".

Again, this is not strictly to do with HTTPS on wikiba.se. I only mention it because it seems (to me) more likely to happen if action is not taken by WMDE to resolve this.

Wikibase is getting bigger. Third-parties, such as myself, are deploying it, or at least thinking about doing so. It is a significant software project which deserves support on an organizational level. If WMDE intends to be that organization - and to me, they have indicated this by retaining the domain - they need to step up and help resolve such basic technical issues. Otherwise it's not fair to you and everyone else involved in the project.

Sounds like we should:

  • Leave this ticket open
  • Move the NS servers for wikiba.se back to the WMDE controlled ones
  • Remove the DNS stuff I added to wmf stuff for wikibase.se
  • Setup letsencrypt or something similar for wikiba.se as controlled by wmde
  • Close this ticket.

what the future brings for the content behind wikiba.se. Will it stay on our webspace? Will it be hosted by WMF?

I'm afraid this part is out of our control and up to c-levels in both WMF and WMDE, unfortunately it sounds like not going to happen, per T99531#5181555.

I want so support basically everything that @GreenReaper said above. WMDE can take control of DNS back or we can use wikibase.org at WMF. But nn both cases HTTPS can be fixed, which this ticket is about.

Also the plan from @Addshore sounds about right to me at this point. Since that means things will happen on the WMDE side i would like to unassign this ticket from me now.

Dzahn removed Dzahn as the assignee of this task.Aug 9 2019, 7:23 PM

https://wikiba.se now up and running. I think, it can be closed, then.

@abian Ah, I didn't configure www.wikiba.se. Now I ran into Let's Encrypt rate limiting because I didn't know how to properly configure multiple nginx server names with puppet. I will try again in an hour, but then it should be complete.

@abian Ah, I didn't configure www.wikiba.se. Now I ran into Let's Encrypt rate limiting because I didn't know how to properly configure multiple nginx server names with puppet. I will try again in an hour, but then it should be complete.

Thanks!

Change 532973 had a related patch set uploaded (by Dzahn; owner: Dzahn):
[operations/puppet@production] ATS/acme_chief/varnish: remove wikiba.se

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

Change 532973 merged by Vgutierrez:
[operations/puppet@production] ATS/acme_chief/varnish: remove wikiba.se

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