change to



Infrastructure & Operations
WebOps: Other
7 years ago
4 years ago


(Reporter: davedash, Assigned: phrawzty)



(Whiteboard: [after Fx11 launch]) needs to be permanently redirected to  We'll need to maintain the redirect for a while as well.

It should be a smart redirection:

e.g. ->
Isn't this an in-product URL? Has that been changed to 

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 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?


7 years ago
Assignee: server-ops → shyam
So I was going to do this :

1) Point DNS for to ( and
2) Setup a ServerAlias for

Now the issue is that when someone goes to over https, it'll fail...saying the certificate is only for

Do we want that? This is hard problem to solve without wasting another IP and getting another SSL certificate and have terminate there. 

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?
Blocks: 618157
Going to mark this incomplete, feel free to re-open when this is ready to go.
Assignee: shyam → server-ops
Last Resolved: 7 years ago
Resolution: --- → INCOMPLETE
Whiteboard: On Hold
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?
Resolution: INCOMPLETE → ---

Comment 7

6 years ago
I have added to ServerAlias for the 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.
Assignee: server-ops → nmaul
Whiteboard: On Hold
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).

Comment 10

6 years ago
HTTPS is supported, and does have an 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 and decided against it.

Can you do this for as well?

Comment 13

6 years ago
(In reply to Dave Dash [:davedash] from comment #12)
> Jakem,
> Can you do this for 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
> and decided against it.

The issue is that HTTPS is present and does work. If we don't do something, that will break.

The choices are:

1) Do nothing. Connections to 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).

Depends on: 697233

Comment 14

6 years ago
I have changed to point to the same IP as, 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

There is some miscellaneous renaming work that should happen at some point (some files and directories are named, 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:

Comment 16

6 years ago
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 to (/admin at least does this).

2) Change to be a redirect to, rather than a ServerAlias on the same VirtualHost.

3) Rename directories (and any other things, like the mana page) to instead of .com.
Whiteboard: [after Fx11 launch]
Fx11 is launched. I think we're ready to go.

Comment 18

6 years ago
@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:

(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 and that are just redirects (no DocumentRoot or logging needed)... something like this perhaps, each in the appropriate block:
Redirect permanent /
Redirect permanent /
Redirect permanent /
Redirect permanent /

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. :)
Assignee: nmaul → dmaher

Comment 19

6 years ago

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.

Comment 20

6 years ago
Mana updated; closing bug.
Last Resolved: 7 years ago6 years ago
Resolution: --- → FIXED does not resolve (alerts coming in),not sure if this intended (not needed?) or possible that was skipped.
Resolution: FIXED → ---

Comment 22

6 years ago
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).
Last Resolved: 6 years ago6 years ago
Resolution: --- → FIXED
This broke because they weren't present as servernames or aliases.
Resolution: FIXED → ---
And we should be good :

23:32:23] < nagios-phx1> | - is OK: HTTP OK: HTTP/1.1 200 OK - 50029 bytes in 0.018 second response time
Last Resolved: 6 years ago6 years ago
Resolution: --- → FIXED
Filed bug 747316 on the fallout.
Component: Server Operations: Web Operations → WebOps: Other
Product: → Infrastructure & Operations
You need to log in before you can comment on or make changes to this bug.