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)

task
Not set
normal

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.
Whiteboard: [kanban:https://webops.kanbanize.com/ctrl_board/2/5278]
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.
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.
(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.
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.
+1 to firefox-source-docs.mozilla.org.
OK!  Webops, please add the CNAME as described in comment 2.
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
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
CNAME added to Inventory

FQDN 		Target 	
firefox-source-docs.mozilla.org 	CNAME 	d2r03xnqvbcxrv.cloudfront.net
(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)
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.
TLS is deploying in cloudfront now.  Should be up in 10-20 minutes.
You have to use API Gateway in front of S3 to add the headers to the response, FWIW.
(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)
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.