www-mirrors mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Brian Behlendorf <br...@organic.com>
Subject Re: some updates
Date Fri, 13 Jun 1997 08:22:51 GMT
On Fri, 13 Jun 1997, Ira Abramov wrote:
> On Thu, 12 Jun 1997, Brian Behlendorf wrote:
> > The release of 1.2.0 caused an unprecedented amount of traffic on our
> > site; so much so that the bandwidth provider for www.apache.org has
> > begun to grumble.  To address this, we have taken some measures to bolster
> > the effectiveness of the site in supporting mirrors:
> why am I not surprised? ;)
> If netscape can do it, so can we... I think the load on apache's central
> site means that it shouldn't even be linked as a download site, (smart
> users will go directly to the FTP, but web surfers will never be turned
> directly to ftp://www.apache.org).

Heh - bandwidth has calmed down quite a bit since we've made the
changes, but this is something we'll consider.

> > 1) We will now be running CGI scripts on mirror sites.  Previously all CGI
> > scripts, such as the search field and bug database, had an explicit link
> > back to www.apache.org.  These CGI scripts only rely upon perl 4 (or 5)
> > being at "/usr/local/bin/perl".  Is this a problem?
> I imagine every perl installation around has either the binary or a link
> there, to support the many scripts out there.

One other thing this has brought up - apparently some mirrors are not
preserving file permissions, so some of the CGI's are apprently not
executable.  In addition, the "index.cgi" in the /mirrors/ directory
is not being executed.  Looks like we have two more dependencies:

.cgi being able to run anywhere
DirectoryIndex index
Options Multiviews turned on.

Eek.  This fancy mirror strategy is looking to be a boondoggle.  What
do you all think?

> > 2) Sites which pull down their content via ProxyPass will not have
> > dynamically generated mirror pages, though they should be cacheable.
> I hope I'm not out of my line here: is this method at all realistic for
> this use? sounds to me like a cool way to mirror joe's page of jokes, not
> a busy site such as Apache is.

Not out of line at all.  In theory, this should be a very slick

> > There may be more issues brought up by this than I anticipated - let's
> first: where are the CGI's going to sit permanently? if there is a cgi-bin
> dir, we should make sure there is a ScriptAlias for it, otherwise make
> *.cgi executable in the apache dir (default for me, but not for some).

Right.  I am so used to sprinkling .cgi's throughout the site, I
didn't even think about that.  I had abolished /cgi-bin/ long ago :)
The problem is that if we do that, everyone will have a different
/cgi-bin/ directory they'll have to configure, since many people have
their apache mirror a few directory levels down.  That will make
several things difficult.

> maybe make sure through a .htaccess to cover at least SOME of the holes.
> (assuming it's allowed to override)

Hmm, maybe if we put a .htaccess in the apache directory with these
directives, things would be a lot smoother.  How many out there use

brian@organic.com  www.apache.org  hyperreal.com  http://www.organic.com/JOBS

View raw message