Closed Bug 609888 Opened 14 years ago Closed 14 years ago

550 error when trying to download the beta 7 Windows candidates

Categories

(mozilla.org Graveyard :: Server Operations, task)

x86
Windows 7
task
Not set
critical

Tracking

(Not tracked)

VERIFIED FIXED

People

(Reporter: kbrosnan, Assigned: justdave)

References

Details

QA is holding a testday for the beta 7 candidates, http://quality.mozilla.org/events/2010/11/03/test-day-friday-november-5-help-us-test-web-apps-in-the-firefox-4-beta/. 

We are having trouble with testers not being able to download the candidate builds, ftp://ftp.mozilla.org/pub/firefox/nightly/4.0b7-candidates/build1/win32/en-US/ yeilds a ftp 550 error and trying the http:// version directs to a wiki.m.o post about how beta 7 is not out yet.
I have looked at the permissions on ftp and it doesn't differ with beta6 candidates.

I can download the zip file but not the exe file.

Changing component to Server Operations, nobody assigned and raising the importance as this gets on the way for QA to test.
Assignee: justdave → server-ops
Severity: major → critical
Component: FTP: Mirrors → Server Operations
Blocks: 596259
This is caused because of Bug 609790
Assignee: server-ops → shyam
Comment #2 should have read, probably caused because of.

Still looking into this.
This seems to be by design. I don't think ftp urls were meant to be handed out.
For now we have managed to provide public facing win32 builds:
http://stage.mozilla.org/pub/mozilla.org/firefox/nightly/4.0b7-candidates/build1/win32/en-US/
that can be reach by the community (we are now out of the hole).

We believe that justdave (or someone else from IT) made the .exe files provided by ftp://ftp.m.o to be 550 intentionally. We will have to figure this out.

I will have to ask drivers to find out from now on what URL to provide for QA testdays.

fox2mike thanks for looking into this!
Status: NEW → RESOLVED
Closed: 14 years ago
Resolution: --- → WORKSFORME
(In reply to comment #4)
> This seems to be by design. I don't think ftp urls were meant to be handed out.

If by design, I would like to know more details in case we get asked by QA and/or rel-drivers (if they do).
We typically block the ftp downloads as we lead up to a public release in order to prevent people from linking to ftp.mozilla.org (because it doesn't have the capacity for it).  This is only intended for releases and not candidates.  For candidates, ftp.mozilla.org is the only place to get them so it makes no sense to block it.

It looks like what happened is the last time we had a release, someone tried to get smart with the block rule and put in a wildcard instead of the specific version number. This caused all of the beta downloads to get blocked and not just the most-recently-released version.

I changed the block rule to specifically block Beta 6 again.  It'll need to be changed to Beta 7 when the files get moved to /releases/ for the public release.
Assignee: shyam → justdave
Resolution: WORKSFORME → FIXED
Thanks for the clarification!
Thanks for the quick fix. Works fine.
Status: RESOLVED → VERIFIED
Product: mozilla.org → mozilla.org Graveyard
You need to log in before you can comment on or make changes to this bug.