Closed Bug 607129 Opened 14 years ago Closed 11 years ago

Domain Name Change - byob.mozilla.com to byob.mozilla.org

Categories

(Websites Graveyard :: byob.mozilla.com, defect)

Product:
Websites Graveyard
Component:
byob.mozilla.com
Type:
defect
Priority:
Not set
Severity:
normal

Tracking

(Not tracked)

Status:
RESOLVED WONTFIX

People

(Reporter: lforrest, Assigned: kev)

References

(Blocks 1 open bug,
URL
)

Details

Please change the domain name of byob.mozilla.com to byob.mozilla.org.

This is part of the overall domain name strategy project driven by the website
taskforce. 

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
Targeting a 11/5 live date for this switch. Let me know if more time will be needed.
We'll just need a heads-up on timing, as the application will need a config change as well. Is there a bug for procuring an SSL cert as well?
Chris, what is your thought on the cert?  Correct me if I'm wrong, but is there a wildcard *.mozilla.org cert available so we don't need a specific byob.mozilla.org cert?
FWIW: Although we could start also serving BYOB up at byob.mozilla.org, we can't *stop* serving it up at byob.mozilla.com.

Many browsers built by BYOB and in-use in the wild have the byob.mozilla.com hostname configured as part of the first-run URL.

Not sure off the top of my head what the apache config would be, but might be best to come up with a mod_rewrite formulation that redirects any *.com URL to its *.org counterpart.

Also FWIW: I expect every request to alter pre-existing URLs on other sites will run into some variation of this issue
In light of Les's comment #4, I think we should just add a ServerAlias to byob.mozilla.org and not do any hanky panky re-directs unless we have enough testing done or enough leeway to have stuff broken :)

That way the site lives on byob.mozilla.com and byob.mozilla.org, everyone wins and things keep working.
Re comment #4 and #5, that sounds fine to me.  I understand that certain sites have certain requirements so we need to take those into account.  If I understand correctly, if we did this we'd still be able to publicly refer to the site as byob.mozilla.org but non-public uses of the byob.mozilla.com link won't be interfered with.

This doesn't address the issue of the cert though, I believe.  If the site is living at both addresses we'd still need a cert on both?  Can someone confirm that we do have a wildcard *.mozilla.org cert that will work or if we don't.
Assignee: server-ops → shyam
(In reply to comment #6)
> This doesn't address the issue of the cert though, I believe.  If the site is
> living at both addresses we'd still need a cert on both?  Can someone confirm
> that we do have a wildcard *.mozilla.org cert that will work or if we don't.

We do have a *.mozilla.org certificate, but I'm going to do some poking around on this (wrt to having 2 certs..since I don't think it'll work) and update the bug.
You'll have to have two IPs for this and I suspect we'll end up doing two host specific certs instead.

clyon can confirm.
Just pinging for an update -- do we have an ETA for when we'll resolve the questions about the cert?
When do you need this pushed out by?
The only way to do this is with two separate certs and ip's.
So we'll burn two IPs for this site and spend money to get two new SSL certs.  That's what's blocking this, assuming the app can already grok two different hostnames.

Can the app already support this?
(In reply to comment #12)
> So we'll burn two IPs for this site and spend money to get two new SSL certs. 
> That's what's blocking this, assuming the app can already grok two different
> hostnames.

I'm confused why this app needs new certs. It's already using the existing *.mozilla.com wildcard cert. Can't it just use the *.mozilla.org wildcard cert on the second IP?

As for IPs, if this app isn't deemed to need separate IPs, couldn't it just reuse the existing star-based IPs for *.mozilla.com and *.mozilla.org?

In other notes, https://byob.mozilla.com/en-US has mixed-content SSL on the front page. Seems like that should be fixed if SSL is such a big deal for this site.
(In reply to comment #13)
> I'm confused why this app needs new certs. It's already using the existing
> *.mozilla.com wildcard cert. Can't it just use the *.mozilla.org wildcard cert
> on the second IP?

No.  It will use host specific certs.


> As for IPs, if this app isn't deemed to need separate IPs, couldn't it just
> reuse the existing star-based IPs for *.mozilla.com and *.mozilla.org?

You lost me.  Any existing IP certainly doesn't have byob as a backend server.  Point's moot though since it'll have host specific certs.
(In reply to comment #12)
> So we'll burn two IPs for this site and spend money to get two new SSL certs. 
> That's what's blocking this, assuming the app can already grok two different
> hostnames.
> 
> Can the app already support this?

No, the app can't support this - it needs a single domain name. That's why I assumed it would be Apache rewrite/redirect rules that handled the transition
> In other notes, https://byob.mozilla.com/en-US has mixed-content SSL on the
> front page. Seems like that should be fixed if SSL is such a big deal for this
> site.

It's caused by the video, and it was viewed as acceptable for where the app is now (and is the only page with that particular issue). Patches welcome, and it's not so much that SSL is a big deal (but it should be used), it's that we're trying to accommodate legacy users and the renaming of .com to .org, which wasn't one of the design criteria we had up front.
(In reply to comment #15)

> No, the app can't support this - it needs a single domain name. That's why I
> assumed it would be Apache rewrite/redirect rules that handled the transition

Then I'd not be in favour of changing stuff here. SSL connections that come in as byob.mozilla.org will continue as byob.mozilla.org and if the app can't handle that, there is no point of doing this. If a blanket 302 on / will work, maybe we can give that a shot.
(In reply to comment #17)
> (In reply to comment #15)
> 
> > No, the app can't support this - it needs a single domain name. That's why I
> > assumed it would be Apache rewrite/redirect rules that handled the transition
> 
> Then I'd not be in favour of changing stuff here. SSL connections that come in
> as byob.mozilla.org will continue as byob.mozilla.org and if the app can't
> handle that, there is no point of doing this. If a blanket 302 on / will work,
> maybe we can give that a shot.

I'm under the impression that the .com-to-.org transition is primarily one of messaging & marketing, no? 

If that's the case, a blanket redirect of byob.mozilla.org to byob.mozilla.com should serve that purpose - so we can talk about byob.mozilla.org in public, but nothing else breaks (ie. deployed browser repacks).

If we want to get fancy, I think we could have a rewrite rule that redirects any byob.mozilla.org/{foo} to byob.mozilla.com/{foo}, so that then something like byob.mozilla.org/profiles/blah/8675309 ends up in the appropriate place.
I support Les' idea of sending a redirect from byob.mozilla.ORG to byob.mozilla.COM.  Significantly easier to implement.
Then I'd probably just do this on virtual-redirect and call it fixed.
Re comment #18, this domain name switch is a messaging issue and the general goal is to no longer use mozilla.com domains for public sites.  Having byob.mozilla.org be the URL we use in public and have that redirect to byob.mozilla.com is certainly a good step.

That doesn't fix this bug though, but we can revisit actually having the site live at a mozilla.org domain later if that's not feasible now.
(In reply to comment #21)
> Re comment #18, this domain name switch is a messaging issue and the general
> goal is to no longer use mozilla.com domains for public sites.  Having
> byob.mozilla.org be the URL we use in public and have that redirect to
> byob.mozilla.com is certainly a good step.
> 
> That doesn't fix this bug though, but we can revisit actually having the site
> live at a mozilla.org domain later if that's not feasible now.

I think we might have it backwards. Unless I'm missing something, what we *could* do is:

* Switch the production site to byob.mozilla.org - that involves an update to apache and app config.

* Redirect any pattern of http(s?)://byob.mozilla.com/{...} to https://byob.mozilla.org/{...} - ie. not a blanket 302 on / but a rewrite regex sending all .com traffic to .org

Since the firstrun page is really the only thing I can think of requiring the .com domain to stick around, this should be okay for as long as we have deployed browser repacks.

Would that fix this bug?
From an end-user perspective this sounds like it would work. 

Is there another technical person (I am not one) that can confirm this?
From my side and probably webdev, just missing prioritization.  This is currently pretty low on the schedule (at the top is making sure Fx4 gets out).
Regardless of prioritization, there seems to be an open question relating to the technical approach we take in comment #22.
(In reply to comment #22)
> * Switch the production site to byob.mozilla.org - that involves an update to
> apache and app config.
> 
> * Redirect any pattern of http(s?)://byob.mozilla.com/{...} to
> https://byob.mozilla.org/{...} - ie. not a blanket 302 on / but a rewrite regex
> sending all .com traffic to .org

Les,

If you're sure this can be done without hosing the site, then I'd be happy to implement these changes. Have a re-write rule handy? 

I suggested the blanket 302 because that ensures that nothing breaks and (for the time being) allows people to say we have a public site at byob.mozilla.org
(In reply to comment #26)
 
> Les,
> 
> If you're sure this can be done without hosing the site, then I'd be happy to
> implement these changes. Have a re-write rule handy? 

Don't have one handy. I could probably spend some time to come up with one, but mod_rewrite-fu is not strong.

> I suggested the blanket 302 because that ensures that nothing breaks and (for
> the time being) allows people to say we have a public site at byob.mozilla.org

Missed this in my bugmail until now...

Safest and easiest is a redirect from byob.mozilla.org to the existing byob.mozilla.com site, which shouldn't break anything.

What I suggested in comment 22 (.com -> .org) is a more complex jugging of site config and redirects, which shouldn't (but could) break things

If anything, I'd just say set up .org as a redirect to .com for now to at least satisfy the messaging issue without introducing any potential breakage.
Assignee: shyam → ayounsi
Is it good like that? .org now redirects to .com
It's great that byob.mozilla.org nows resolves to the site, but as mentioned in comment #21 this bug isn't fixed.  The goal is to not use the mozilla.com domain on a public site.  If that's not possible now, we can certainly revisit at a later time.
While not fixed, it does allow us to refer to it publicly using the changed URLs, and completing the changes to the app that are required, while still allowing us to support legacy configs, will take development. It's something that can be done, but we'll need to plan and have some kind of legacy app for serving up start pages. Les, maybe we can discuss live next week.


(In reply to comment #29)
> It's great that byob.mozilla.org nows resolves to the site, but as mentioned in
> comment #21 this bug isn't fixed.  The goal is to not use the mozilla.com
> domain on a public site.  If that's not possible now, we can certainly revisit
> at a later time.
So I think we can close this bug, feel free to reopen if IT can do anything.
Status: NEW → RESOLVED
Closed: 14 years ago
Resolution: --- → FIXED
Reopening.  Maybe I missed something, but I thought comment #29 and comment #30 both said this wasn't fixed yet?

Instead of closing it, it sounds like there's nothing left for server ops to do right now so we should reassign.  Maybe it makes sense for Kev or Les to take this?
Status: RESOLVED → REOPENED
Resolution: FIXED → ---
I'll take it, and we'll leave it open until we make a determination of how/when we can implement per intent.
Assignee: ayounsi → kev
Component: Server Operations → byob.mozilla.com
Product: mozilla.org → Websites
QA Contact: mrz → byob-mozilla-com
also.. thanks, Arzhel :)
The project is shut down according to http://byob.mozilla.com/. Unless it will resurrect it makes no sense to change the domain. I'd say either the bug summary should be updated (remove the DNS entry) or this bug should be WONTFIX?
Or should it just 301 to the pertinent blog post (http://kev.deadsquid.com/?p=1219)?
http://kev.deadsquid.com/?p=1219
Status: REOPENED → RESOLVED
Closed: 14 years ago → 11 years ago
Resolution: --- → WONTFIX
Product: Websites → Websites Graveyard
You need to log in before you can comment on or make changes to this bug.