Closed Bug 1198296 Opened 9 years ago Closed 9 years ago

stage.mozilla.org:http - 301 /(.*) to archive.mozilla.org/$1

Categories

(Infrastructure & Operations Graveyard :: WebOps: Product Delivery, task)

task
Not set
normal

Tracking

(Not tracked)

RESOLVED FIXED

People

(Reporter: oremj, Assigned: cliang)

Details

(Whiteboard: [kanban:https://webops.kanbanize.com/ctrl_board/2/1626] )

Please redirect all stage.mozilla.org traffic to archive.mozilla.org as described in the bug summary.
Nick, does this change sound alright?
Flags: needinfo?(nthomas)
Whiteboard: [kanban:https://webops.kanbanize.com/ctrl_board/2/1626]
Yes, I think so. There may be some differences in caching config in Zeus, or vhoss, but I can't recall what use cases that would be for.

Please inform #releng when this change is made.
Flags: needinfo?(nthomas)
Assignee: server-ops-webops → cliang
The change to a redirect hosted on the static cluster has been made.  I gave a brief heads-up in #releng and will hang about in there for today in case of any issues.

There are some older rewrite rules on stage.mozilla.org that I did not propagate:
    RewriteCond %{REQUEST_URI} !.*\.mar$
    RewriteRule ^/pub/mozilla\.org/firefox/nightly/3\.0b2-candidates/ http://developer.mozilla.org/devnews/index.php/2007/12/10/firefox-3-beta-2-expected-in-late-december/ [R,L]
    RewriteRule ^/pub/mozilla.org/mozilla/VMs/CentOS5-ReferencePlatform-rc1.zip http://ftp.mozilla.org/pub/mozilla.org/mozilla/VMs/CentOS5-ReferencePlatform-rc1.zip [R,L]
    RewriteRule ^/pub/mozilla.org/firefox/releases/12.0/win32/zh-CN/Firefox\ Setup\ 12.0.exe http://download.mozilla.org/?product=firefox-12.0&os=win&lang=zh-CN [R,L]

If I should add them back in, please let me know.
Change backed out.  stage.mozilla.org is pointed back to the uploads VIP to due issues with builds failing to be written.
Information on what broke:

releng buildbot masters upload files to stage.mozilla.org via ssh connections. Reading this (in hindsight), it wasn't clear to me that we were changing anything other than http/https redirection. We actually changed the IP address of stage.mozilla.org to point to a machine that the buildbot masters could not upload to due to firewall restrictions. This caused buildbot to break. We saw our first alert in #buildduty at 10:21:

Thu 10:21:30 PDT [4051] buildbot-master78.bb.releng.usw2.mozilla.com:Command Queue is WARNING: oldest item is 609526s old (http://m.mozilla.org/Command+Queue)

It took some time to track down the root cause (normally this kind of error points at network or mysql failures). Cause was discovered at 11:02, correlation was noted with the issues ftp and git were seeing at the same time.

I'm not sure what the correct solution is for upload1.mozilla.org is, so I'll let someone with more intimate knowledge of the project plan and requirements chime in.
The correct solution in this case seems to be to run a local apache instance that does a re-direct instead of using our usual methods.
We need to keep DNS the same, so ssh continues to be available. Assuming ports 80/443 are directed at ftp*.dmz.scl3, we will need to split out stage.mozilla.org in to its own vserver and add the 302s there.

Sorry for the confusion.
At 10:20 AM PDT, I added TrafficScript rule on the load balancer to handle redirection of the traffic.  This is applied on *just* the virtual server handling http traffic.
I haven't heard any yelps of pain so I *think* this is done.  Please re-open and flag me down in IRC if you discover otherwise.
Status: NEW → RESOLVED
Closed: 9 years ago
Resolution: --- → FIXED
Product: Infrastructure & Operations → Infrastructure & Operations Graveyard
You need to log in before you can comment on or make changes to this bug.