670115 - [One Mozilla - Tracking Bug] Setup a stage site based on the "merge" mozilla.com branch

Status: RESOLVED FIXED

(www.mozilla.org :: General, defect, P1)

Description

[James Long (:jlongster)]

I have built a prototype of the merged mozilla.com/.org and it works.

http://etherpad.mozilla.com:9000/mozmerge

This bug will track the progress of getting this from my local computer to a staged version on Mozilla's servers.

I'm not sure what this looks like yet, because it will be tricky to keep this up-to-date with the live sites and to not commit breaking patches to the current .org site. But we need to figure that out.

Comment 1

[James Long (:jlongster)]

I found a better way to do this, disregard comment 1.

We should implement the redirects in Zeus, as that fits better with our production setup anyway. It's also completely transparent to both sites. It's also faster.

Jeremy, I assigned this to you because I need to work with someone from IT to get a testing environment setup for this. How can we go about installing a test site script in Zeus, to see if we can get the merge working correctly?

Comment 2

[James Long (:jlongster)]

Attachment: possible site script for merge

Comment 3

[James Long (:jlongster)]

I've attached what I think might work for a site script.

This is assuming that all requests to mozilla.org will serve from the mozilla.com codebase by default. For the specific URLs, does setting the "Host" header effectively route the request to be served from the mozilla.org codebase?

Comment 4

[mcbmoz]

Hey Jeremy,

This is the part of the project we were hoping to discuss with you today. Can you provide an ETA for this, so we can look ahead to where we might be for next Thursday's meeting?

Many thanks!
CB

Comment 5

[Jeremy Orem [:oremj]]

After talking with others, we are just going to host django/mozcom/mozorg code on the same server, so we will use apache rewrites instead of zeus to map old URLs.

I haven't seen any code for them mozilla.com, so right now dev and staging is blocked on that.

Comment 6

[James Long (:jlongster)]

(In reply to comment #5)
> After talking with others, we are just going to host django/mozcom/mozorg
> code on the same server, so we will use apache rewrites instead of zeus to
> map old URLs.
> 
> I haven't seen any code for them mozilla.com, so right now dev and staging
> is blocked on that.

So you want to proxy the mozilla.org site like this:

RewriteRule ^community(.*) http://localhost:8080/$1 [P]

I've benchmarked the performance hit, which is the only concern with this. It doesn't seem to be very large, on the magnitude of 5-10ms, so I think that's ok.

Jeremy: do you all have benchmarking tools? When we get this change staged, will you be able to benchmark the performance?

I will get my code together and attach a patch here soon.

Comment 7

[James Long (:jlongster)]

(In reply to comment #6)

> RewriteRule ^community(.*) http://localhost:8080/$1 [P]

Oops, that should be more like:

RewriteRule ^community(.*) http://localhost:8080/community$1 [P]

Comment 8

[James Long (:jlongster)]

One thing to note: if we use Apache, all resources (images, css, js) will be loaded through a proxy, so although one request has a minimal performance hit, the hit might be larger when loading everything for a page (~25 requests for a mozilla.org page).

Is there a way to config Apache to not use a proxy but still get this to work?

Comment 9

[Jeremy Orem [:oremj]]

I was hoping to do this with straight rewrite rules (no proxy) like we do for AMO, but I also forgot the amount of rewrites that mozilla.com has that will potentially conflict.

Do you think that is going to get too messy? We can probably go back to the original Zeus idea if so.

Comment 10

[James Long (:jlongster)]

(In reply to comment #9)
> I was hoping to do this with straight rewrite rules (no proxy) like we do
> for AMO, but I also forgot the amount of rewrites that mozilla.com has that
> will potentially conflict.

Cool! If you can make sure .com and .org are running on the same server, and not use a proxy, that works great.

> Do you think that is going to get too messy? We can probably go back to the
> original Zeus idea if so.

We'll have the same problem either way, and we'll have to resolve URL conflicts (like who owns /about). I've looked at all the URLs for both sites and the amount of conflicts is manageable, I think.

If doing it in Apache is just as easy, it's better to keep the rewrites in there. The amount of rewrites (top-level folders) is only about 25.

The messy part will be handling all the rewrites in mozilla.org's htaccess file, but again, we'll have the same problem whether we use Apache or Zeus.

How about I create a branch of mozilla.com, and you can create a site for it, make sure mozilla.org is on the same server, and we can go from there?

Comment 11

[James Long (:jlongster)]

Attachment: patch to mozilla.com to run mozorg as /org folder

Ok, so here's my current work to run mozilla.org from the subfolder /org in mozilla.com. There's a lot of hacks and magic to get all the URLs running at the top-level, but I think this is a pretty good solution.

There's a lot of ways to do this, and this seemed to be the least intrusive and breaking patch. I only know of one URL that breaks with this patch and it's fixable.

r? anyone? I'll describe it in more detail soon (other things pressuring right now)

Comment 12

[James Long (:jlongster)]

Attachment: patch to run mozilla.org as /org subfolder under mozcom

Added as patch type

Comment 13

[Fred Wenzel [:wenzel]]

Comment on attachment 547411 [details] [diff] [review]
patch to run mozilla.org as /org subfolder under mozcom

I checked out the patch and it makes sense to me (mind you, I didn't apply this to an Apache instance). A better solution that we've learned about earlier today might be RewriteMap, but let's figure out first if this is the right direction for IT.

Comment 14

[James Long (:jlongster)]

I'm making this bug be just for the new site based on the new "merge" branch in the mozilla.com SVN repo. The patches will be reviewed and edited in a different bug.

Jeremy, please make something like http://merge.stage.mozilla.com/ that updates from the "merge" branch.

Once you do that, please checkout the mozilla.org site as the subfolder "/org". When this is live that folder will need to auto-update in the same way mozilla.org currently does (immediately from trunk).

Comment 15

[Jake Maul [:jakem]]

Jeremy asked if I could work on this for him.

Comment 16

[Jake Maul [:jakem]]

This is largely complete. I have not yet set up appropriate cron jobs to auto-update the content, but a snapshot is in place, and the jobs should be simple "svn up" affairs.

http://www-dev.allizom.org/

There is one major problem with this as-is... no config.inc.php file.

I'm looking at the config.inc.php for www.mozilla.com, and there's a good bit of things here that I want to make sure of before putting into place. I'm not entirely sure what to change, and what should be left alone.

1)  * SMS settings: Ask [e-mail] for these. (username and password... don't know what this goes to)

2) recaptcha_pub_key and recaptcha_priv_key

3) static_prefix (CDN)... looks like this could probably just be set to an empty string for now. It might be possible to use as-is, but I'd be concerned about prod CDN content causing confusion on the stage site- things might look wrong.

4) funnelcake_suffix ... prod is an empty string.

5) pfs_endpoint ... could probably stay the same.

6) basket_url ... could probably stay the same.

7) responsys_id ... this one scares me. Will we break prod if this stage site tries to use this? I know absolutely nothing about responsys, but don't want to cause a licensing problem or something by accident.

8) SMTP host/username/password... set to smtp2301.socketlabs-od.com, probably should be something internal to mozilla, but probably not a major deal right now either.

Comment 17

[James Long (:jlongster)]

Awesome, thanks Jake!

A lot of those config values are deprecated, I think, and we really need to clean it up.

(In reply to comment #16)

> 1)  * SMS settings: Ask [e-mail] for these. (username and password...
> don't know what this goes to)

You can leave this blank. I don't know of anything that uses it, it's probably old.

> 2) recaptcha_pub_key and recaptcha_priv_key

Leave this with what prod has, I guess. Not sure where we use recaptcha.

> 3) static_prefix (CDN)... looks like this could probably just be set to an
> empty string for now. It might be possible to use as-is, but I'd be
> concerned about prod CDN content causing confusion on the stage site- things
> might look wrong.

Good point. Just leave it blank for now.

> 4) funnelcake_suffix ... prod is an empty string.

That's fine.

> 5) pfs_endpoint ... could probably stay the same.

Might want to check out what www.stage.mozilla.com has for these kinds of settings.

> 6) basket_url ... could probably stay the same.

We don't use basket right now, so that can be left out.

> 7) responsys_id ... this one scares me. Will we break prod if this stage
> site tries to use this? I know absolutely nothing about responsys, but don't
> want to cause a licensing problem or something by accident.

It's fine to use what prod has. There's no licensing issues, and all that will happen is when we test the newsletter signup form on this site it will do a real signup. That's ok, and is kind of the point. Responsys will remove all bad emails addresses when they bounce back.

> 8) SMTP host/username/password... set to smtp2301.socketlabs-od.com,
> probably should be something internal to mozilla, but probably not a major
> deal right now either.

Yeah, not sure if this is even used. Copy whatever www.stage.mozilla.com has.

Comment 18

[James Long (:jlongster)]

There are two more config files that need updating, assuming mozilla.org was checking out in the /org subfolder.

I just realized that we need a way to serve the mozilla.org's media files. Can you make org-dev.allizom.org serve the mozilla.org site from the /org subfolder? Because basically we need a domain that we can set as the "CDN" so that media serves up. We can't use RewriteRule in Apache because the folders conflict with mozilla.com (for example, /style). But if we could server up http://org.mozilla.org/style/page.css from the mozilla.org codebase, that would work. I'm open to feedback on this.

/org/includes/config.inc.php

server_name = 'www-dev.allizom.org';
file_root = <path>;
js_prefix = img_prefix = style_prefix = <prefix>

Where <path> is the path to the /org subdirectory, and <prefix> is something like http://org.mozilla.org/ (see explanation above).

/org/thunderbird/includes/config.inc.php

server_name = 'www-dev.allizom.org';

The other defaults should be fine.

Comment 19

[Jake Maul [:jakem]]

Comment 17 is done. The main site (.com, aka http://www-dev.allizom.org/) is working.

Working on getting /org to work. At the moment, it is being redirected to /en-US/org, which does not exist. I'm trying to find that redirect and add an exclusion to it.

The config file for /org is in place. I'm not sure what the problem here is... why do we need a separate domain for those things? Is there a reason they can't be pointed at "http://www-dev.allizom.org/org/<whatever>"? That looks pretty straightforward to me, and it looks like /org/thunderbird is set up that way by default (since it's already living in a subdirectory).

Comment 20

[Jake Maul [:jakem]]

This redirect is being caused by /includes/prefetch.php. It redirects any request to any file ending in .html. So, this works:

http://www-dev.allizom.org/org/README

but this doesn't:

http://www-dev.allizom.org/org/ (because it goes to index.html)


In addition to the main version of this file in /includes/prefetch.php, there is also /org/includes/prefetch.php and /org/thunderbird/includes/prefetch.php.

The /org/ one includes a simple conditional at the top to make sure the thunderbird one gets run as necessary. A similar conditional in the top level one might be the best solution here.

Note that there might be a problem with where these prefetch.php scripts are choosing to insert the language into the URL. This should become more obvious once it's loading the right prefetch.php in the first place. It might be curable with a simple setting... for instance, /org/thunderbird/includes/config.inc.php includes a 'static_prefix' setting which presumably gets put into the right place in the final rewritten URL.

Comment 21

[James Long (:jlongster)]

Jake, you are right, /org should not work right. I have a patch which implements Apache and PHP magic to serve everything under /org as top-level URLs on the new merged site.

See my attachment here: https://bugzilla.mozilla.org/show_bug.cgi?id=670775

I just need it setup this way so I can apply my patch and start testing it from there. I will commit it to the branch tomorrow or Thursday. Thanks!

Is auto-updating setup too?

Comment 22

[Jake Maul [:jakem]]

It is set up to auto-update... the root is updated from:
URL: http://svn.mozilla.org/projects/mozilla.com/branches/merge

the /org subdirectory is updated from:
URL: http://svn.mozilla.org/projects/mozilla.org/trunk

This happens every 10 minutes.

Consequently I can't really effectively apply this (or any) patches to this merged site... the changes will be wiped out within 10 minutes. Is it possible for you to just apply the patch to the "merge" branch and be done with it?

Comment 23

[James Long (:jlongster)]

Perfect!

(In reply to comment #22)
> Consequently I can't really effectively apply this (or any) patches to this
> merged site... the changes will be wiped out within 10 minutes. Is it
> possible for you to just apply the patch to the "merge" branch and be done
> with it?

Yep, that's what I intend to do, sorry I didn't make that clear.

Comment 24

[Jake Maul [:jakem]]

I think Infra's work here is done, then. Since this isn't in our product/component, I'll leave it open for someone else to decide how to handle it, and just unassign myself. Let me know if you need anything else from us. Thanks!

Comment 25

[John Slater]

What's the next step here then?

Thanks all-

Comment 26

[James Long (:jlongster)]

Jake,

I broke the site somehow. I was having major SVN problems with the branch and I had to recreate it from trunk. The site is now throwing a 403 forbidden. Can you look into it?

Also, there's another tweak to the Apache config file. Please add the following lines to the VirtualHost:

RewriteMap org-urls-410 txt:<root>/org-urls-410.txt
RewriteMap org-urls-301 txt:<root>/org-urls-301.txt

Where <root> is the path to the site.

I committed the apache/php magic to run everything under one domain in r93027.

The new branch was created from trunk@r93011.

Comment 27

[James Long (:jlongster)]

Jake has fixed the site (http://www-dev.allizom.org), thanks!

In addition to the Apache tweak in comment 26, the config file at /org/includes/config.inc.php need the following values changed:

$config['js_prefix'] = '/org';
$config['img_prefix'] = '/org';
$config['style_prefix'] = '/org';

I believe that's all the tweaks.

Comment 28

[Jake Maul [:jakem]]

You should be able to put those changes right in the .htaccess file... That's managed by SVN, so it would be better if you add it. I'd prefer to keep all the rewrite logic done that way, at least for now, because that's where all the existing redirect logic is. It also keeps you self-sufficient, and those changes won't block on me or Infra. :)

I fixed a bug in my cron job that was causing this to not auto-update as expected. So if you tried this before and it didn't work, it should now. Sorry!

Comment 29

[Jake Maul [:jakem]]

(In reply to comment #27)
> $config['js_prefix'] = '/org';
> $config['img_prefix'] = '/org';
> $config['style_prefix'] = '/org';

All done.

Comment 30

[James Long (:jlongster)]

(In reply to comment #28)
> You should be able to put those changes right in the .htaccess file...
> That's managed by SVN, so it would be better if you add it. I'd prefer to
> keep all the rewrite logic done that way, at least for now, because that's
> where all the existing redirect logic is. It also keeps you self-sufficient,
> and those changes won't block on me or Infra. :)

Agreed, but you can't put RewriteMap directives in htaccess files, they must be in the Apache config. All it does is specify an external file which lists all the rewrites, which is managed by SVN and we can change all we want. These options shouldn't ever change. Can you add them?

RewriteMap org-urls-410 txt:/data/www/www-dev.allizom.org/org-urls-410.txt
RewriteMap org-urls-301 txt:/data/www/www-dev.allizom.org/org-urls-301.txt

> I fixed a bug in my cron job that was causing this to not auto-update as
> expected. So if you tried this before and it didn't work, it should now.
> Sorry!

Thanks! Everything looks great.

Comment 31

[Jake Maul [:jakem]]

Ah, okay... didn't realize that. Have never used RewriteMap before. :)

Done.

One other note: I am likely to become fairly unresponsive soon, due to some personal stuff. If you need something urgent, hit up cshields or oremj for a faster response. :)

Comment 32

[James Long (:jlongster)]

Thanks!

This bug should be a good transcript for how the merged site works.

Comment 33

[David Boswell]

Great to see this bug resolved :)

James, would you like us to start testing stage at this point and letting you know of any issues or would you like us to wait for now?

Comment 34

[James Long (:jlongster)]

David, please start testing! The sooner we find problems, the better!