Closed
Bug 1392765
Opened 7 years ago
Closed 7 years ago
Please add firefox-source-docs.mozilla.org CNAME d2r03xnqvbcxrv.cloudfront.net
Categories
(Infrastructure & Operations :: SSL Certificates, task)
Infrastructure & Operations
SSL Certificates
Tracking
(Not tracked)
RESOLVED
FIXED
People
(Reporter: gps, Assigned: joeyk)
References
Details
(Whiteboard: [kanban:https://webops.kanbanize.com/ctrl_board/2/5278])
The Firefox source repository has in-tree Sphinx docs. We've been generating and hosting these at https://gecko.readthedocs.org/ for a few years. We've been hitting scaling limits with Read The Docs and want to transition our documentation generation and hosting to something under Mozilla's control. In bug 1382729 we taught TaskCluster to upload generated docs to an S3 bucket. They can be accessed at http://gecko-docs.mozilla.org.s3.amazonaws.com/. We'd like to expose that S3 bucket under a proper Mozilla hostname with TLS protection. In this bug, I'm requesting DNS (which implies a hostname) and a certificate for an official home for these Firefox docs. I'm not sure exactly how the DNS will work. In bug 1389341, Dustin said we may want to put CloudFront in front of the S3 bucket. I'm not sure which AWS account should host that. But first thing's first: we need a hostname. A good hostname likely has "firefox" in it. It probably also has at least one of "docs" or "dev" or "source" in it. Some suggestions: * firefox-docs.mozilla.org * firefox-dev-docs.mozilla.org * firefox-source-docs.mozilla.org We could potentially use .developer.mozilla.org: * firefox-docs.developer.mozilla.org * firefox-dev.developer.mozilla.org Naming things is hard. I'm also not sure what domain names are appropriate.
Reporter | ||
Comment 1•7 years ago
|
||
I should clarify next steps for this bug: * I would like someone with knowledge of "infrastructure requirements" to state which domains are appropriate for this use case. And to clarify, this well be a user-visible hostname and we expect there to eventually be many links to it. * Wait for a reasonable quorum of agreement on a desired hostname. I'd like some subset of {mhoye, rhelmer, dustin, gps, ted} to agree on something (that being the set who have expressed interest in this topic before). https://gecko.readthedocs.org/ is hard failing today and I've had a handful of people ping me about it. So I'd like to have some resolution by the end of the week, if possible. We don't need TLS this week: I'd settle for plain text http:// if it means we can start advertising the new hostname to users sooner. Also, a working URL to the S3 bucket is http://gecko-docs.mozilla.org.s3.amazonaws.com/index.html.
Comment 2•7 years ago
|
||
I like any of the first three names, with preference for the third (firefox-source-docs). I think we should steer clear of developer.m.o to avoid confusion with mdn. TC can host the cloudfront endpoint since that's where the bucket lives. In fact, I've already created it. Whatever hostname we choose, it should be a CNAME to d2r03xnqvbcxrv.cloudfront.net. Once there's a TLS certificate, I can add that too.
Comment 3•7 years ago
|
||
(In reply to Gregory Szorc [:gps] from comment #1) > > end of the week, if possible. We don't need TLS this week: I'd settle for plain > text http:// if it means we can start advertising the new hostname to users > sooner. > That would be ideal as we are trying to finalize the Privacy Notice overhaul for 56, which was planned to include links to RTD.
Comment 4•7 years ago
|
||
In the absence of other arguments, perhaps we should get get started with firefox-source-docs.mozilla.org? https://github.com/taskcluster/taskcluster-docs/pull/201 just came in, and I'm concerned that dozens of other links are getting modified to point to the temporary URL in comment 1. I'd like to rename the bucket to firefox-source-docs for consistency, which will break that link.
Reporter | ||
Comment 5•7 years ago
|
||
+1 to firefox-source-docs.mozilla.org.
Retitling to reflect comment 6, and I advise y'all to issue your own Digicert for this (Releng has a couple admins who can do that, or if not, we need to fix the Releng admins in Digicert).
Summary: Hostname and certificate for Firefox source documentation → firefox-source-docs.mozilla.org CNAME d2r03xnqvbcxrv.cloudfront.net
Summary: firefox-source-docs.mozilla.org CNAME d2r03xnqvbcxrv.cloudfront.net → Please add firefox-source-docs.mozilla.org CNAME d2r03xnqvbcxrv.cloudfront.net
Comment 8•7 years ago
|
||
Ok from a security standpoint. However, once it has a certificate in place, let's add it to the set of monitored subdomains for Observatory scores and try to get it up to a B on https://observatory.mozilla.org
Assignee | ||
Comment 9•7 years ago
|
||
CNAME added to Inventory FQDN Target firefox-source-docs.mozilla.org CNAME d2r03xnqvbcxrv.cloudfront.net
Comment 10•7 years ago
|
||
(In reply to Tristan Weir [:weir] (use NEEDINFO) from comment #8) > Ok from a security standpoint. However, once it has a certificate in place, > let's add it to the set of monitored subdomains for Observatory scores and > try to get it up to a B on https://observatory.mozilla.org Good idea - could you submit a pull request to the Observatory for this? No need to wait for the CNAME.
Flags: needinfo?(tweir)
Comment 11•7 years ago
|
||
It's worth noting that with static hosting from S3 most of the observatory stuff is difficult or impossible -- we had to go to more expensive active hosting for https://tools.taskcluster.net for that. So I'm not sure if a B is possible -- at least not without setting up an Express or Flask service in Heroku or something to host this.
Comment 12•7 years ago
|
||
TLS is deploying in cloudfront now. Should be up in 10-20 minutes.
Comment 13•7 years ago
|
||
You have to use API Gateway in front of S3 to add the headers to the response, FWIW.
Comment 14•7 years ago
|
||
(In reply to Richard Soderberg [:atoll] from comment #10) > Good idea - could you submit a pull request to the Observatory for this? No > need to wait for the CNAME. Added to dashboard: https://github.com/mozilla/http-observatory-dashboard/pull/21 You can scan it directly here: https://observatory.mozilla.org/analyze.html?host=firefox-source-docs.mozilla.org
Flags: needinfo?(tweir)
Comment 15•7 years ago
|
||
Seems like there's no more work for Webops to do here. Dustin, there's an option to use Lambda to insert relevant security headers as well, which might be easier. https://medium.com/@tom.cook/edge-lambda-cloudfront-custom-headers-3d134a2c18a2 might point you in the right direction, account might need Lambda@Edge enabled for this to work.
Assignee: server-ops-webops → jkrejci
Status: NEW → RESOLVED
Closed: 7 years ago
Resolution: --- → FIXED
You need to log in
before you can comment on or make changes to this bug.
Description
•