Hello,
The Comms team is requesting a domain of wikimedia.social. Here are the Masto.host instructions on how to update the domain for the Mastodon host.
Hello,
The Comms team is requesting a domain of wikimedia.social. Here are the Masto.host instructions on how to update the domain for the Mastodon host.
Subject | Repo | Branch | Lines +/- | |
---|---|---|---|---|
Add wikimedia.social domain | operations/dns | master | +25 -0 |
Awesome! I'm wondering if it's been considered to use a non-software specific domain like "social.wikimedia.org" (I don't know if we already have wikimedia.social), for example OSI is https://social.opensource.org/; Mozilla is https://mozilla.social/; WMDE is https://social.wikimedia.de/ and WMES is https://social.wikimedia.es/ and so on...
Is there a place where we can read about this project and the general plan around it? Like, maybe we can link to the parent task?
Change 928901 had a related patch set uploaded (by BCornwall; author: BCornwall):
[operations/dns@master] Add mastadon.wikimedia.org domain
Change 928901 abandoned by BCornwall:
[operations/dns@master] Add mastadon.wikimedia.org domain
Reason:
It's clear there are some org issues that need to be addressed, mainly from comms.
On Gerrit @Dzahn wrote:
I don't think we can point .wikimedia.org subdomains to external IPs. This discussion has been had several times in the past. Just one issue is that we won't be handing out our TLS keys to an external party.
Yeah, for those not familiar, T128559 contains a very long and sad saga of futile attempts to get HSTS set up on store.wikimedia.org, with the eventual conclusion that it needs to be moved off *.wikimedia.org: T333591: Move Wikimedia store domain from store.wikimedia.org.
I thought masto.host met all those requirements, but I just ran https://www.ssllabs.com/ssltest/analyze.html?d=wikis.world and it complains about the HSTS policy being invalid :< (getting that fixed independently...)
But once the HSTS issue is resolved, starting on an external hoster like masto.host (I haven't evaluated other providers recently, I assume WMF did) seems pretty reasonable while figuring out a long-term maintenance/self-hosting plan. (And maybe with GitLab we'll have better internal support for Rails-based apps?)
Of course, if we can get a domain like wikimedia.social (like Mozilla did) that would nicely avoid all of these problems! It's kind of annoying to change domain names after the fact (though not impossible), so hopefully the extra bit of bikeshedding beforehand isn't too unreasonable and sets us up for success in the long-run.
Hi, @Dzahn my apologies for the delay. It took me a while to get in touch with comms and I was OOO all last week. Here is a general overview document of the project.
https://docs.google.com/document/d/1hLe2ANjQcAiiC9PTnaon6CP9EUIhrcUdf-1ILfI6K0Y/edit?usp=sharing
Comms also let me know that they are ok with using social.wikimedia.org as requested by @Legoktm
Thank you for the link, @NMariano-WMF . It's appreciated. Though I am not sure I see technical things on where and how to host it in there?
I would like to suggest what Legoktm suggested already as a fix to the problem:
Of course, if we can get a domain like wikimedia.social (like Mozilla did) that would nicely avoid all of these problems!
Best
Yeah, the document is pretty barren. It sounds like there needs to be a little bit more planning!
This document says:
Users will receive a NAME@wikimediafoundation handle.
Which suggests this should be at social.wikimediafoundation.org? I think that's also preferred on a technical side since that domain is already externally hosted?
it looks like the planning happened after the requirement for implementation:
Document details
Created on Jun 8, 2023
Thanks for that extra bit of information, @Mschon.
I'm going to close this as INVALID until there's something here to service.
Adding
@Abit @Bmueller & @AAlikhan for visibility into this and to answer any questions or concerns that may come up.
The Comms team is requesting a subdomain of mastodon.wikimedia.org (or social.wikimedia.org). We'd like to update our DNS records to reflect that subdomain. Here is the Masto.host instructions on how to update the subdomain for masto host. The hosting of the Mastodon server will be provided by masto host.
If we need to set up a meeting to help facilitate this please let me know. Thank you all for your attention to this matter.
Per above, I suggest to rename this ticket to buy a domain like wikimedia.social. That would be via the Legal team. Then once you have that you can let us know and we (SRE) add that to the DNS servers. That should be the easiest path forward for everyone.
Using a subdomain of wikimedia.org and pointing that to 3rd party is a non-starter I think. You wouldn't be able to have https on that.
Assigning to legal. There's nothing for us to service yet. Once Legal has serviced this and a more fleshed-out ticket is written then we can assign to SRE teams.
As the WMF-Legal project tag was added to this task, some general information to avoid wrong expectations:
Please note that public tasks in Wikimedia Phabricator are in general not a place where to expect feedback from the Legal Team of the Wikimedia Foundation due to the scope of the team and/or nature of legal topics. See the project tag description.
Please see https://meta.wikimedia.org/wiki/Legal for when and how to contact the Legal Team. Thanks!
I mean, it's obvious that doc was just created, but that doesn't mean planning just started now (c.f. wikimedia-l posts, etc.).
I think T337586#8929623 was overlooked. AIUI wikimediafoundation.org is already a 3rd party domain, so presumably it's acceptable to send social.wikimediafoundation.org to a different 3rd party (subject to whatever requirements we have for 3rd party hosts).
[off-topic] Has there been a recent policy change prohibiting 3rd party sites for wikimedia.org? There are numerous subdomains pointing to third parties, for example the various WP VIP sites.
Oh yea, that's totally possible that it always meant to be social.wikimediafoundation.org and not wikimedia.org.
citation needed. From what I see WP VIP is the only exception (go-vip.net) and until that was accepted there were extensive discussions involving meetings with the Traffic team. A big topic is how to handle TLS certs (and the keys for them) if you want https for it and it's hosted elsewhere. Also reputation of the domain. It has come up multiple years in the past when new services or sites were introduced by comms.
I am not the gatekeeper for this, but this kind of thing is why we are saying it's important to reach out early and speak with SRE (and traffic in particular) and have a discussion about hosting and tech before dropping new services. There is usually always more to it than just a quick DNS edit.
Legal does not track issues in Phabricator... As no active project tags are left, I'm closing this ticket for the time being.
Feel free to reopen and adjust project tags once initial requirements have been sorted out and a shared understanding how to proceed has been established.
FWIW, I've been told that the only way to really communicate with Legal regarding DNS changes *is* through phabricator (though there's some confusion on whether Legal uses their own internal tool as well, see T105829). It would be nice to sort this out as there's quite the backlog of DNS changes that we'd like to get done, possibly before this one!
omg, plus 100. It feels like whether we can or can NOT expect to contact legal via Phabricator has been unclear since forever. Fixing that would be awesome.
@BCornwall: If you are aware of any written documentation about contact workflows, apart from general https://phabricator.wikimedia.org/project/profile/28/ and non-public https://office.wikimedia.org/wiki/Legal#Contact_information , please share links. Thanks.
Related to this task: I've registered wikimedia.social, so we are free to use that to host a Mastodon server. I would recommend against using wikimediafoundation.org for this purpose, as volunteers having @wikimediafoundation.org handles could cause confusion about what their relationship with the Foundation is. If there are any other domain names we're considering using, let me know and I'll look into registering them.
Related to the general point about working with Legal on DNS-related tasks: I'm the point person in Legal for domain name registrations/management through the MarkMonitor portal, so I'm probably the person you need to bug about things if there is action needed from Legal (and if I'm not, I can help find the person who is). I'm not in Phabricator all the time, but I do get email alerts from it—if you need something from me, feel free to assign tasks to me or ping me in a comment. And if it looks like I've missed something here, you can reach out to me on email or Slack.
@CRoslof Thanks for chiming in! Is what you wrote documented in some place which is more discoverable than the URL https://phabricator.wikimedia.org/T337586#8936483 so the next person knows can find out what [not] to do? That would be great. :) See for example the two URLs I shared in my previous comment...
(I generally believe we need to shift more towards thinking in terms of places, not individual people to go to, as the latter doesn't scale very well.)
Wow, thanks! I think this was really the best solution and should unblock everyone involved.
Now SRE can add this to our zone files and point it to masto.host.
Comms, can you confirm you are ok with wikimedia.social? We can then follow the docs for a "root domain" at https://masto.host/dns/ and you should be good to go.
Change 928901 restored by BCornwall:
[operations/dns@master] Add mastadon.wikimedia.org domain
Ignore the gerritbot comment, it's been updated to use wikimedia.social. @Dzahn I'd love your re-review not only for the technical aspects but also to be sure that there isn't a conceptual issue remaining.
Change 928901 merged by BCornwall:
[operations/dns@master] Add wikimedia.social domain
$ drill -Q @ns{0..2}.wikimedia.org wikimedia.social 178.33.220.142 176.31.213.231
All set!
Name servers for the wikimedia.social domain still need to be updated to ns[0-2].wikimedia.org:
taavi@runko:~ $ whois wikimedia.social | grep "Name Server" Name Server: taavi@runko:~ $ host -tNS wikimedia.social Host wikimedia.social not found: 3(NXDOMAIN)
Yes, checking this with Chuck in private email as there was a notification sent to dns-admin@ and this ticket is public. Will update this task as we have more information.
dig wikimedia.social NS +short ns1.wikimedia.org. ns0.wikimedia.org. ns2.wikimedia.org.
dig wikimedia.social +short 178.33.220.142 176.31.213.231
This is now resolved. @NMariano-WMF, please let us know if you have any questions and feel free to re-open the task. (You will need to follow the next steps on masto.host.)
Came here from the post on en.wp's Signpost and I have looked over comments here. Is there a way to make an HTTP redirect from "https://mastodon.wikimedia.org/" to "https://wikimedia.social/"? Furthermore, it seems like "https://wikimedia.social/" should be some kind of landing page for any and all social media profiles and a Mastodon instance would be best at "https://mastodon.wikimedia.social/", but I suspect that ship has sailed.