From owner-freebsd-hubs@FreeBSD.ORG Sun Aug 10 11:50:11 2003 Return-Path: Delivered-To: freebsd-hubs@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 9AC1737B401 for ; Sun, 10 Aug 2003 11:50:11 -0700 (PDT) Received: from lurza.secnetix.de (mail2.secnetix.de [195.143.231.20]) by mx1.FreeBSD.org (Postfix) with ESMTP id B559D43F93 for ; Sun, 10 Aug 2003 11:50:09 -0700 (PDT) (envelope-from olli@lurza.secnetix.de) Received: from lurza.secnetix.de (gpkdap@localhost [127.0.0.1]) by lurza.secnetix.de (8.12.8p1/8.12.8) with ESMTP id h7AIo4gC032817; Sun, 10 Aug 2003 20:50:06 +0200 (CEST) (envelope-from oliver.fromme@secnetix.de) Received: (from olli@localhost) by lurza.secnetix.de (8.12.8p1/8.12.8/Submit) id h7AIo3K5032816; Sun, 10 Aug 2003 20:50:03 +0200 (CEST) From: Oliver Fromme Message-Id: <200308101850.h7AIo3K5032816@lurza.secnetix.de> To: jonny@jonny.eng.br (=?ISO-8859-1?Q?Jo=E3o_Carlos_Mendes_Lu=EDs?=) Date: Sun, 10 Aug 2003 20:50:03 +0200 (CEST) In-Reply-To: <3F35C87A.4050004@jonny.eng.br> from "=?ISO-8859-1?Q?Jo=E3o_Carlos_Mendes_Lu=EDs?=" at Aug 10, 2003 01:22:18 AM X-Mailer: ELM [version 2.5 PL3] MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit cc: freebsd-hubs@freebsd.org Subject: Re: Requirements Final Draft Attempt #2 :-/ X-BeenThere: freebsd-hubs@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: FreeBSD Distributions Hubs: mail sup ftp List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 10 Aug 2003 18:50:11 -0000 João Carlos Mendes Luís wrote: > - After discovering some "content directory", verify it's contents to > see if it's true. This is a little intrusive, but could be done by > verifying the presence and size of some file, for example. I was considering that, too. But it would increase the time of the collector run by an order of magnitude. Currently, it sends two LIST commands (for releases and for packages), then it proceeds sending LIST commands for every architecture it found, as well as for every ISO-IMAGES sub- directory. The last collector run took 3 hours 40 minutes (148 mirror hosts). If the collector was to check every directory it found, it would have to issue at least another LIST command for every release and every architecture on every host. The last collector run found 6755 directories (that's the number of lines in the log file). On average, a LIST command takes 2 - 3 seconds. For some hosts it takes considerably longer, depending on reachability and load of that server. To some countries, the RTTs from here are not very good. > - If a problem is found, send an email to the CC.freebsd.br hostmaster, > and to postmaster@ftpX.CC.freebsd.org. To be honest, I don't like the idea to spam people by using automated scripts. > The discussion about ftp holes and links reminded me about other > possible problem: Some ftp DNS names may point to multiple IP Addresses If that's done on purpose, then the responsible admins must make sure that all hosts under the same IP _must_ have the same content. Otherwise I would call it broken. > (I've seen this already, but do not know if it's valid), It's valid and called "DNS round-robin". It's a very simple way to provide load balancing among a set of hosts, but it has some limitations. Especially Windows boxes don't work very well with it. It's always preferable to use a "real" round-robin setup if possible, e.g. using L7 switches or a balancing proxy. > and some > multiple DNS names could point to the same IP (ftp3.de and ftp6.de > example). Right. The collector could be optimized to recognize that, so it doesn't check the same host twice. I'll try to implement that when I have a few more minutes of time ... However, I think it should list them twice, as if it were separate hosts. After all, from a user's perspective, they are different hosts (which happen to have the same content). Regards Oliver -- Oliver Fromme, secnetix GmbH & Co KG, Oettingenstr. 2, 80538 München Any opinions expressed in this message may be personal to the author and may not necessarily reflect the opinions of secnetix in any way.