input.mozilla.com needs to be permanently redirected to input.mozilla.org. We'll need to maintain the redirect for a while as well. It should be a smart redirection: e.g. input.mozilla.com/foo -> input.mozilla.org/foo
Isn't this an in-product URL? Has that been changed to input.mozilla.org? This is why this wasn't changed the last time this whole mass of .com to .org domain changes were made.
Shyam it is in product. Maybe instead of doing a redirect we could do this in two phases. 1. have input.mozilla.org point and input and support the two URLs for a while, and once it's rolled into the product, we can start doing the redirect and make .org canonical?
So I was going to do this : 1) Point DNS for input.mozilla.org to 220.127.116.11 (input.mozilla.com) and 2) Setup a ServerAlias for input.mozilla.org Now the issue is that when someone goes to input.mozilla.org over https, it'll fail...saying the certificate is only for input.mozilla.com. Do we want that? This is hard problem to solve without wasting another IP and getting another SSL certificate and have input.mozilla.org terminate there. Thoughts?
We're not actively using HTTPS... let's hold off on this. Aakash, can you mark the product fix bug as a blocker of this?
Going to mark this incomplete, feel free to re-open when this is ready to go.
Hi this is ready to go, if possible we want this ready around November 1, but if it's sooner/later that's fine too. Is there a way, before we change this on the DNS level, that we can add .org to the vhost, so I can test the app using an /etc/hosts hack?
I have added input.mozilla.org to ServerAlias for the input.mozilla.com VirtualHost blocks. It'll take a bit to propagate out, but once it does you should be good to test it with /etc/hosts changes.
Just making sure we have bases covered here : 1) Is this being changed in-product as well? 2) Are we getting new SSL certs?
1. Yup, the blocker is scheduled to land into nightly soon, and then appropriately board the train. 2. No logged in users, so we aren't using HTTPS. I'm going to specifically be looking for redirection-hell in the app code (e.g. making sure we don't redir from .org to .com in the app).
HTTPS is supported, and does have an input.mozilla.com cert. If we don't fix this, we may get complaints from people using HTTPS Everywhere-type addons. However, it shouldn't be a big deal to get a replacement cert with both names on it. I think it's worthwhile to do so. If we don't update the cert or we disable HTTPS, we're almost certain to get complaints (bugs) about it in short order.
Hey Shyam and Jaye, why do we need certs? Input doesn't require log-in except for the admin interface. We've had this discussion before https://bugzilla.mozilla.org/show_bug.cgi?id=583011 and decided against it.
Jakem, Can you do this for m.input.mozilla.org as well?
(In reply to Dave Dash [:davedash] from comment #12) > Jakem, > > Can you do this for m.input.mozilla.org as well? Committed. Should be visible shortly. (In reply to Aakash Desai [:aakashd] from comment #11) > Hey Shyam and Jaye, why do we need certs? Input doesn't require log-in > except for the admin interface. We've had this discussion before > https://bugzilla.mozilla.org/show_bug.cgi?id=583011 and decided against it. The issue is that HTTPS is present and does work. https://input.mozilla.com/. If we don't do something, that will break. The choices are: 1) Do nothing. Connections to https://input.mozilla.org/ will throw errors (once the redirect is removed and i.m.o becomes canonical). 2) Disable HTTPS. This will stop complaints about a bad SSL cert... instead we might get complaints about HTTPS no longer working from people who actually are using it (if any). 3) Get a new cert (either for i.m.o alone or a SAN cert for i.m.o + i.m.c... in which case maybe it should have m.i.m.o on it as well). 2)
6 years ago
I have changed input.mozilla.org to point to the same IP as input.mozilla.com, and it is already set up as a ServerAlias. As far as I can see there is only one redirect set up in Apache for this now: /admin redirects to https://input.mozilla.com/. There is some miscellaneous renaming work that should happen at some point (some files and directories are named input.mozilla.com), but the two names should be working side-by-side within a half-hour. Since this is an in-product URL, we'll want to wait a while before setting up a redirect for .com->.org... long enough for most folks to have upgraded, at least. What version of Firefox will have the new URL? That'll determine the timeline on the next steps here.
The patch for the in-product URL is ready to go. We'd wait for Firefox 11 (which is on nightlies starting today) and let the change vet through as we pass from channel to channel until major release. Here's the bug for the in-product URL: https://bugzilla.mozilla.org/show_bug.cgi?id=618189
Okay, in that case, this bug is effectively on hold until after Fx11 launches, at least. We'll probably want to give it at least a couple weeks after Fx11 so that most people have upgraded. So that I don't have to wade through all the comments, I'll summarize what's left: 1) Change any redirects going to input.mozilla.com to input.mozilla.org (/admin at least does this). 2) Change input.mozilla.com to be a redirect to input.mozilla.org, rather than a ServerAlias on the same VirtualHost. 3) Rename directories (and any other things, like the mana page) to input.mozilla.org instead of .com.
Fx11 is launched. I think we're ready to go.
@Dan: assigning this to you... pm me if you need any help. :) The SSL cert already works both ways, so no problems there. DNS points to the same IP for both, so that's done as well. The Apache config is in puppet: sysadmins/puppet/trunk/files/generic/httpd-app-input/etc-httpd/conf/domains (it's not using our newer "webapp" module, but the older/legacy layout) There's one redirect in there that I see, for /admin... simple matter to change it to org instead of com. Then I would make some new VirtualHost blocks for input.mozilla.com and m.input.mozilla.com that are just redirects (no DocumentRoot or logging needed)... something like this perhaps, each in the appropriate block: Redirect permanent / http://input.mozilla.org/ Redirect permanent / http://m.input.mozilla.org/ Redirect permanent / https://input.mozilla.org/ Redirect permanent / https://m.input.mozilla.org/ Feel free to combine VirtualHost containers and/or use mod_rewrite if you prefer... I just like to be explicit. The main point is that protocol and mobile/non-mobile is preserved across the redirect. I would recommend skipping the #3 I listed in comment 16, at least insofar as Apache and filesystem... too easy to break stuff, for minimal gain. Can't break anything by renaming the Mana page though. :)
Hello, I have made the appropriate modifications to the Apache config, as noted in comment 18; following your advice, I have _not_ changed any of the filesystem paths / names. See rev 34752 for details. I'll make the appropriate changes in Mana shortly.
Mana updated; closing bug.
m.input.mozilla.org does not resolve (alerts coming in),not sure if this intended (not needed?) or possible that m.input.mozilla.org was skipped.
Gah... that's what we get for trusting me. This record didn't exist... I just added it. Should be visible in a couple minutes (internal propagation).
This broke m.input.mozilla.com/org because they weren't present as servernames or aliases.
And we should be good : 23:32:23] < nagios-phx1> | input.zlb.phx.mozilla.net:http_string - m.input.mozilla.org is OK: HTTP OK: HTTP/1.1 200 OK - 50029 bytes in 0.018 second response time
Filed bug 747316 on the fallout.