> How are the load spread between http and ftp? I have choosen not run a
> ftp-service at apache.dc.luth.se because of the extra work maintaining a
> secure
> anonymous ftp-server. It would be interesting to know more about how many
> accesses different mirrors get and how they are distributed between http and
> ftp.
Everything available via FTP is also available via HTTP. We offer
both as a choice, with HTTP coming as the first choice. We think it's
important to provide FTP for those cases where you don't have a web
browser like Lynx handy to pull down the distribution during a remote
install, and of course for you mirror administrators. :)
> > 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?
>
> "We will now be running CGI scripts on mirror sites." Hmm, I don't think it's
> that easy. Apache is a great software in many ways, one of these ways is that
> with a little basic knowledge of the Apache system it's quite easy to maintain
> basic security. I would expect that most, if not all, mirrored www-sites won't
> let any executable file with cgi-suffix be executed by default. At least it
> wouldn't here at apache.dc.luth.se.
Okay, sounds like a solid vote against in-place CGI's. Several sites
do allow CGI's, and we will thoroughly examine whatever CGI's we give
you to run. For example, none of the CGI's being given you you
involve parsing or interpreting user input, so the chances for a
security hole to pop up is much smaller.
> I have made loose sketches on a simple distributed version of CPAN that
> wouldn't require every CPAN-like resolution go through one single point of
> failure and/or congestion. If there's enough interest in this idea I could
> perhaps pick this up again.
That would be interesting to see - the only other alternative, if we
are to try and rotate ranking of mirrors and give people a mirror
matching their country code, is to link back all the way to
www.apache.org for the "download" link, which would be silly.
We tossed around the idea of DNS round robin between the major US
hosts, i.e. for "download.apache.org", but punted for now because of
concerns that just a random IP number from the DNS is not likely to be
the closest one. Though there are a *few* browsers (like the CERN
line-mode browser, and the @Home version of Netscape!) which when
given multiple A records for a host will try and find the closest one,
or at least, try a second number if the first is not responding.
Brian
--=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=--
[EMAIL PROTECTED] www.apache.org hyperreal.com http://www.organic.com/JOBS
