From owner-freebsd-hackers Mon Feb 5 16:12:15 1996 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.7.3/8.7.3) id QAA08804 for hackers-outgoing; Mon, 5 Feb 1996 16:12:15 -0800 (PST) Received: from time.cdrom.com (time.cdrom.com [192.216.222.226]) by freefall.freebsd.org (8.7.3/8.7.3) with SMTP id QAA08795 for ; Mon, 5 Feb 1996 16:12:11 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by time.cdrom.com (8.6.12/8.6.9) with SMTP id QAA26090; Mon, 5 Feb 1996 16:11:48 -0800 To: John Polstra cc: hackers@freebsd.org Subject: Re: sup is broken? In-reply-to: Your message of "Mon, 05 Feb 1996 10:01:57 PST." <199602051801.KAA05372@austin.polstra.com> Date: Mon, 05 Feb 1996 16:11:47 -0800 Message-ID: <26087.823565507@time.cdrom.com> From: "Jordan K. Hubbard" Sender: owner-hackers@freebsd.org Precedence: bulk > Jordan wrote: > > > PLEASE DON'T USE SUP.FREEBSD.ORG TO UPDATE YOURSELF! > > Good evening, my name is John, and I use sup.freebsd.org to update > myself. > > [ embarrassed applause from the other supaholics in the audience ] Hey, OK, let's be honest here - *I* use sup.freebsd.org to update myself (it would be silly otherwise, given that my SLIP line goes directly into that machine, but that's another matter) and a number of other core team people do as well. I didn't mean to imply that using sup.freebsd.org was a mark of shame, simply that the "mainstream" should no longer consider it the one and only place to come for their bits. We've gotten too big for that scheme to work any longer.. :-( That said: > Jordan, I would be more than happy to switch to an alternate sup > server, if only the other ones would work worth a sh*t! I know that there are still some problems with the other sup sites, and it's more than likely that some additional shuffling of the servers and name space will be required until we have fairly beefy and reliable machines serving sup2.freebsd.org and sup3.freebsd.org at a minimum. We're just starting out with this here, more in panic reaction to freefall melting down than anything else, and it's going to take a little longer to work the bugs out. I didn't say that this was all going to work right away! :-) Nonetheless, even without fully functional backup, it's clear that sup.freebsd.org is now too overloaded to even use for most people and we have to do the best we can with the alternative resources available. We have no other choice! On the brighter side, someone just volunteered to create a sup server at a fairly well-connected spot (and I'll be coy about it for now to avoid potentially jeopardizing these arrangements during their vulnerable boost phase) and that may go a fair ways towards solving these problems. Not that more sup servers aren't needed! They are. We could easily use *3 times* the number of sup sites we currently have since freefall clearly turns away more people than it's able to service these days, and even Paul Traina's sup2.freebsd.org has been full on more than one occasion. Even with a well-distributed load we'll still have more than we can handle, so if you'd like to create a sup server at your regional NAP (dream :) or well-connected ISP as a public service then please, by all means do so! How does it work? At the risk of repeating myself, here are the basic details: 1. You need to be willing to host at least 10 bandwidth-sucking connections from your machine. Sup is not a "light" service, and it would be dishonest of me not to point that out in advance to prospective server volunteers. You also need about 300-600MB of disk space, depending on how many of the collections you intend to offer. If you've got the CPU power and bandwidth to spare and this still doesn't scare you off, then your next step is: 2. Grab the following tarball: ftp://freefall.freebsd.org/pub/FreeBSD/sup-server-kit.tar.gz Unpacked, this will contain some instructions on setting up a sup server and preparing the "collections" that it provides to its clients. You should also mirror your own trees from sup.freebsd.org, and at some point we'll be restricting access to ONLY sup mirrors so that they can get in reliably. Part of the problem we have now is a chicken-and-egg transition problem: Most people want to use the sup mirrors but they're often incomplete, a result of the mirror site not being able to update itself. It can't update itself because there are too many users using the primary site due to the incomplete nature of the mirrors! :-) 3. Once your site is up and passing its initial client tests, send details to myself and Justin Gibbs , the supmeister. We'll figure out what "class" of site it is (based on which collections it provides and number of simultaneous users allowed) and then send a request to David Greenman who manages the name space for freebsd.org. He'll add in a new sup.freebsd.org entry pointing to the new sup site, with the lower numbers being allocated to the higher-bandwidth servers. We're also especially interested in foreign sup sites, since they prevent an otherwise expensive and slow hop across the pond to the U.S. sites. I believe we have sup.de.freebsd.org and sup.au.freebsd.org in operation now, though there's a conspicuous lack of entries for: sup.br.freebsd.org sup.ca.freebsd.org sup.dk.freebsd.org sup.fi.freebsd.org (*) sup.fr.freebsd.org sup.hk.freebsd.org sup.jp.freebsd.org (**) sup.nl.freebsd.org sup.ru.freebsd.org sup.uk.freebsd.org * May already have nic.funet.fi, but the DNS primary for fi.freebsd.org hasn't added this. ** These folks actually need at least 2 or 3 servers to start with. You'll note that I also haven't mentioned every major country here - no offense to those countries intended! :-) I'm merely pointing out the "higher traffic" countries here and suggesting that they could most immediately benefit from having a local sup server. Finally, a note to existing sup server maintainers: I have noticed myself that sup3.freebsd.org and sup4.freebsd.org have incomplete or small collections. I think that we should try and get everyone to offer at least -stable and -current now, especially since the CVS tree has been opened up and it's actually quite easy to offer multiple collections now. Simply sup only one tree, the CVS tree, and then use it locally from cron to check out your own -stable and -current trees. You don't have to sup all 3 trees from freefall! :-) Ideally, if we could get everyone to look and work identically to sup.freebsd.org then John wouldn't have his gripes at all - it would be transparent. Ideally.. :-) Volunteers? This is your resource, constructed for your benefit, after all! :-) Jordan