Bugzilla – Full Text Bug Listing
| Summary: | Remove PHP files from being redirected to IBM internal mirrors | ||
|---|---|---|---|
| Product: | Community | Reporter: | Denis Roy <denis.roy> |
| Component: | Servers | Assignee: | Eclipse Webmaster <webmaster> |
| Status: | RESOLVED FIXED | QA Contact: | |
| Severity: | normal | ||
| Priority: | P3 | CC: | david_williams, kim.moir, mark_martin, mmo |
| Version: | unspecified | ||
| Target Milestone: | --- | ||
| Hardware: | PC | ||
| OS: | Linux | ||
| Whiteboard: | |||
|
Description
Denis Roy
Kim, Mark, do you have any opinion on this? If excluding PHP files from the rewrite rules solves the problem, great. Otherwise I will have to upgrade my mirror from RHEL4 to RHEL5, which I would prefer not to due if other solutions are available. As long as we are still redirected to download the zips from the internal mirrors. That's where we save the time and bandwidth :-) If only *something* finally happens re. this issue! It's getting REALLY annoying always having to wait and download certain projects from home only. I consider escalating this if this issue doesn't get resolved soon! Kim and Mark, you folks can perhaps validate the country -> fullmoon rules I have below to make sure they make sense, and perhaps propose others? For instance, torolab is the default mirror for fr.ibm.com and uk.ibm.com -- would they be better served by the Ottawa mirror?
# IBM Ottawa and IBM Zurich redirect to Ottawa
RewriteCond %{SCRIPT_FILENAME} !\.php$
RewriteCond %{REMOTE_ADDR} 204.138.97.7 [OR]
RewriteCond %{REMOTE_HOST} .zurich.ibm.com [OR]
RewriteCond %{REMOTE_HOST} .oti.com
RewriteRule ^/(.*)$ http://fullmoon.ottawa.ibm.com/$1 [R,L]
# IBM US and IBM Switzerland redirect to RTP
RewriteCond %{SCRIPT_FILENAME} !\.php$
RewriteCond %{REMOTE_HOST} .us.ibm.com [OR]
RewriteCond %{REMOTE_HOST} .ch.ibm.com
RewriteRule ^(.*)$ http://fullmoon.rtp.raleigh.ibm.com/$1 [R,L]
# All other IBMs redirect to torolab
RewriteCond %{SCRIPT_FILENAME} !\.php$
RewriteCond %{REMOTE_HOST} .ibm.com
RewriteRule ^(.*)$ http://fullmoon.torolab.ibm.com/$1 [R,L]
Are these rules last in the "list of rules". In other words, do these rules "catch" the case if someone specifies only a URL, such as http://download.eclipse.org/webtools/committers/ which must hit some other rule to try http://download.eclipse.org/webtools/committers/index.php So, at that point, will that index.php be re-ran through the rules? We are seeing http://download.eclipse.org/webtools/committers/ being re-directed to mirror, whereas we did not, as of a few days ago. (In reply to comment #6) > Are these rules last in the "list of rules". In other words, do these rules > "catch" the case if someone specifies only a URL, such as > http://download.eclipse.org/webtools/committers/ > which must hit some other rule to try > http://download.eclipse.org/webtools/committers/index.php > > So, at that point, will that index.php be re-ran through the rules? > > We are seeing > http://download.eclipse.org/webtools/committers/ > being re-directed to mirror, whereas we did not, as of a few days ago. > I think I answered my own question. After posting the above, realized I could VNC to my IBM machine to test, and sure enough http://download.eclipse.org/webtools/committers/ was redirected to fullmoon, but not if I spelled out index.php http://download.eclipse.org/webtools/committers/index.php (In reply to comment #7) > (In reply to comment #6) > > I think I answered my own question. After posting the above, realized I could > VNC to my IBM machine to test, and sure enough > > http://download.eclipse.org/webtools/committers/ > was redirected to fullmoon, but not if I spelled out index.php > http://download.eclipse.org/webtools/committers/index.php > Oh, and I should have added, we depend pretty heavily on the "sparse" URL form, using it in a lot of links to/from other "download" pages, so, ideally that can be fixed, otherwise, we'd have to investigate if we could change all our web pages (that is, it's not just a matter of what the User bookmarks or types in to their browser). Denis
Your rewrite rules are on the right track, but you need to make the following changes to the Ottawa and Zurich rules:
Delete RewriteCond %{REMOTE_ADDR} 204.138.97.7 [OR]
Change
RewriteCond %{REMOTE_HOST} .oti.com
to
RewriteCond %{REMOTE_HOST} .ottawa.ibm.com
The rest looks good.
> RewriteCond %{REMOTE_HOST} .ottawa.ibm.com Mark, when Sonia's RSYNC process connects, this is what I see in the logs: rsync to eclipseDownloads from sdimitro@fw54.torolab.ibm.com (199.246.40.54) I'm afraid that if I use .ottawa.ibm.com all the Ottawa lab traffic will be redirected to fullmoon.torolab as it doesn't match .ottawa.ibm.com. Can you confirm? While we wait for Mark to confirm, I have changed the rules to something like this:
# IBM Ottawa and IBM Zurich redirect to Ottawa
RewriteCond %{REQUEST_FILENAME} \.(zip|jar|gz|gif|jpg|doc|swf)$
RewriteCond %{REMOTE_HOST} .ottawa.ibm.com [OR]
RewriteCond %{REMOTE_HOST} .zurich.ibm.com
RewriteRule ^/(.*)$ http://fullmoon.ottawa.ibm.com/$1 [R,L]
It was easier to choose which file extensions to redirect rather than those to *not* redirect. These extensions cover the bulk of the bandwidth anyway.
David, can you confirm that PHP files and access to directories (http://download.eclipse.org/webtools/committers/) are *not* redirected, but that ZIP downloads *still are*?
In the Raleigh area, the directories and PHP files are not redirected to the mirrors, but neither are the zips for the builds. Thanks, John. Can you access this page, just so I can find you in my logs: http://download.eclipse.org/testjohn.zip Thanks Sorry, this is working properly, I was thinking I would see a mirror selection page, but I am auto redirected to the fullmoon raleigh server on the zips. Thanks! Sorry for the confusion. I can confirm John's observation that it's working well, PHP's are our full PHP's from Eclipse, and zip's and a tar.gz come from fullmoon. One nice thing about redirecting the big things, instead of not redirecting PHPs, is that the checksum MD5 files still some from eclipse, which is the preferred way to check for download integrity. Very nice solution ... gee, why didn't we ask for your help earlier :) Hi Denis I did a little more digging into redirecting Ottawa users, and the short answer is since we now use the Torolab gateway, there doesn't seem to be a way to redirect them to the Ottawa server. I'm not sure that this is really much of a problem, fullmoon.torolab "should" be identical to the Ottawa server, just a little slower for us to download from. Thanks, Mark. For now I added the IP address from comment 10 so that the Ottawa lab uses the Ottawa server. Closing as fixed. Thanks. Moving all these to Servers. The new Torolab mirror is running RHEL 5 and the latest PHP released by Red Hat. Is there a specific config required for PHP to work with these downloads? |