Closed Bug 618153 Opened 15 years ago Closed 11 years ago

Domain Name Change - crash-stats.mozilla.com to crash-stats.mozilla.org

Categories

(Infrastructure & Operations :: SSL Certificates, task)

task
Not set
normal

Tracking

(Not tracked)

RESOLVED FIXED

People

(Reporter: lforrest, Assigned: Atoll)

References

(Blocks 1 open bug, )

Details

(Whiteboard: [kanban:https://webops.kanbanize.com/ctrl_board/2/169] [post fx4])

Please change the domain name of crash-stats.mozilla.com to crash-stats.mozilla.org. This is part of the overall domain name strategy project driven by the website taskforce. Please have the .com redirect to the .org. More details here: https://wiki.mozilla.org/Websites/Taskforce/Proposals/Domain_Name_Strategy Here's a link to the overall tracking bug for this project: https://bugzilla.mozilla.org/show_bug.cgi?id=606278
Component: other.mozilla.org → Server Operations
Product: Websites → mozilla.org
QA Contact: other-mozilla-org → mrz
Version: unspecified → other
crash-stats.mozilla.COM is an in-product hostname. about:crashes references the .COM hostname. There's no part of the product that's been QA'd to accept a 302/301 redirect for this. I can CNAME .ORG to .COM but this should not redirect. The app also needs to support this and I don't know if that's already the case.
Whiteboard: [cname only, app fixes?]
Don't forget about the need for crash-stats to have a separate SSL certificate all to itself, so you'll need to blow another IP and buy another special certificate just for the .org version.
Blocks: 618185
That's only for the submission URL, which isn't displayed to the user at all, so we could leave that at .com. We can change the in-product links to .org easily.
Indeed, I had forgotten that. So, yeah, there shouldn't be any problem changing this from .com to .org then and adding a redirect.
Whiteboard: [cname only, app fixes?]
the submission url is "crash-reports.mozilla.com", while the "crash-stats.mozilla.com" is the Socorro UI. The later is likely easier to change than then former.
Assignee: server-ops → nobody
Severity: normal → enhancement
Component: Server Operations → Server Operations: Projects
Whiteboard: [post fx4]
I'm not talking about the submission URL. I'm talking about the "retrieve my crash from about:crashes" URL. That's .com now and I don't see any bug about changing it or the backend server to support it (or if there's any work there to be done).
bug 618185 covers about:crashes.
That bug has a patch, FWIW (which was pretty trivial), but it's blocked by making https://crash-stats.mozilla.org/ have a valid cert, which is this bug.
Assignee: nobody → server-ops-webops
Component: Server Operations: Projects → WebOps: SSL and Domain Names
Product: mozilla.org → Infrastructure & Operations
Whiteboard: [post fx4] → [kanban:https://webops.kanbanize.com/ctrl_board/2/169] [post fx4]
Assignee: server-ops-webops → gozer
Status: NEW → ASSIGNED
Done.
Status: ASSIGNED → RESOLVED
Closed: 11 years ago
Resolution: --- → FIXED
It's still redirecting to crash-stats.mozilla.com for me. Are you sure this fix was complete?
Flags: needinfo?(gozer)
QA Contact: mzeier → nmaul
(In reply to Ted Mielczarek [:ted.mielczarek] from comment #8) > That bug has a patch, FWIW (which was pretty trivial), but it's blocked by > making https://crash-stats.mozilla.org/ have a valid cert, which is this bug. I was going by that comment. Thought the only issue was getting the SSL cert to be a valid cert. What's needed here? Instead of a redirect, it should just point at the same back end nodes that are currently serving crash-stats.m.c ?
Status: RESOLVED → REOPENED
Flags: needinfo?(gozer)
Resolution: FIXED → ---
(In reply to Philippe M. Chiasson (:gozer) from comment #11) > (In reply to Ted Mielczarek [:ted.mielczarek] from comment #8) > > That bug has a patch, FWIW (which was pretty trivial), but it's blocked by > > making https://crash-stats.mozilla.org/ have a valid cert, which is this bug. > > I was going by that comment. Thought the only issue was getting the SSL cert > to be a valid cert. > > What's needed here? Instead of a redirect, it should just point at the same > back end nodes that are currently serving crash-stats.m.c ? Based on bug 606278 (the meta parent of this), the goal is to rename crash-stats.mozilla.com to crash-stats.mozilla.org in the codebase. So pointing at the same backend nodes would be the next step, and then someday making crash-stats.m.c redirect to .m.o would be the presumably final step.
Assignee: gozer → server-ops-webops
Assignee: server-ops-webops → rsoderberg
The next-steps I see here are: - create a new traffic group IP for crash-stats.m.org, copying any necessary configs from the .com trafficip - copy the vserver config for crash-stats.m.com to a new crash-stats.m.org vserver - attach the crash-stats.m.org SSL certificate to the .org vserver - attach the crash-stats.m.com pool to the .org vserver
:jakem points out that the cert deployed for crash-stats.mozilla.com already supports BOTH .org AND .com, so this is actually far easier. The next steps, then: - alter the DNS for crash-stats.mozilla.org from the static-redirect cluster to the same IP as crash-stats.mozilla.com - client testing - clean up the redirect after a while
Talked with #breakpad and proceeding. DNS CNAME record replaces with A record matching crash-stats.m.c. To test the client, alter about:config value breakpad.reportURL, restart Firefox, go to about:crashes, and verify that clicking the link brings up the site. Waiting for DNS to rebuild and ship out, but this should be ready to go shortly.
DNS rebuilt. Altered socorro local.py per Mana and rhelmer: 12:14 <atoll> BROWSERID_AUDIENCES = ['https://crash-stats.mozilla.com', 'https://crash-stats.mozilla.org'] 12:14 <atoll> ALLOWED_HOSTS = ['crash-stats.mozilla.com', 'crash-stats.mozilla.org'] And it's working correctly for my crashes, and rhelmer verified it seems okay there as well. So this bug is good to go. Someday, in at least a month, we should set up a redirect from .com to .org, so that the canonical site is .com. But that isn't for today.
Status: REOPENED → RESOLVED
Closed: 11 years ago11 years ago
Resolution: --- → FIXED
You need to log in before you can comment on or make changes to this bug.