Date: Thu, 30 Jan 2003 11:49:50 -0800 From: Sean Chittenden <seanc@FreeBSD.org> To: hubs@FreeBSD.org Cc: Scott Long <scott_long@btc.adaptec.com> Subject: Re: Statement regarding FreeBSD release ISO images Message-ID: <20030130194950.GQ15936@perrin.int.nxad.com> In-Reply-To: <20030130155948.GL41512@genius.tao.org.uk> References: <3E2E58E8.7020903@btc.adaptec.com> <20030122191836.GC12075@perrin.int.nxad.com> <3E2EF005.9010107@btc.adaptec.com> <20030130155948.GL41512@genius.tao.org.uk>
next in thread | previous in thread | raw e-mail | index | archive | help
--H7cT1SUwsqXggVRO Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable > [followups directed to hubs@FreeBSD.org] >=20 > of the DNS name space in favour of sites that want to mirror only > certain architectures. In envisage ftp.alpha.uk.FreeBSD.org, or > ftp.ia64.uk.FreeBSD.org. Of course the DNS could be set up as: >=20 > ftp.alpha.uk.FreeBSD.org CNAME ftp.uk.FreeBSD.org > ftp.ia64.uk.FreeBSD.org CNAME ftp2.uk.FreeBSD.org >=20 > or other permutations. >=20 > Something like this would allow the installer software to still know > where to go to install the bits, but would give more freedom as to > who mirrors what. At the moment in the installer the user can > select a site to install from, but there's no guarantee that it has > the bits mirrored there. That makes a ton of sense from the front-end user/sysinstall perspective. In a related e-mail that I sent to Scott, I suggested something similar for the backend of the mirrors system. If FreeBSD started maintaining rsync template files (exclude/include files) for the various different levels of commitment that a mirror wanted to make, it would provide them for an easy way to always track the most up to date/insync bits that they have an interest in without manual administration. Here are the various important bits from the other e-mail: ## Begin snip Potential fix for the mirrors: The wording of the hubs article should be changed so that there is a notion of tier two hubs that are listed, this is something that isn't currently done as far as I can tell, but is something that's on the hot list from what I can tell. In terms of ways of mirroring, it should almost be a requirement that all mirrors use rsync (both for bandwidth reasons, and for maintenance reasons). If a mirror is using rsync, it would be trivial for someone on the FreeBSD to update a series of rsync templates that way when a site goes to update, they fetch a template file that matches their desires and then they use that template to sync their site. *poof* Problem solved. All we'd have to do is update their sync scripts to use at the least a four command shell script: /usr/bin/fetch http://www.freebsd.org/resources/mirrors/rsync/excludes/[mir= ror_class_of_choice].exclude /usr/bin/fetch http://www.freebsd.org/resources/mirrors/rsync/includes/[mir= ror_class_of_choice].include /usr/local/bin/rsync --include-from=3D[mirror_class_of_choice].include \ --exclude-from=3D[mirror_class_of_choice].exclude \ [rsync_options_of_choice] \ rsync://[mirror_of_choice]/FreeBSD/ \ /opt/mirrors/freebsd.org/ /bin/rm -f [mirror_class_of_choice].exclude [mirror_class_of_choice].include We could even specify geographic mirrors for them based off of their region of the globe and could do it automatically based off of the requesting IP address. Hell, it'd be possible to build in their hostname into the fetch request so that we can automatically determine when a mirror updates _and_ what type of mirror they are. It'd be nice if our docs were always 100% up to date with respect to mirrors. I agree that bandwidth is a donated resource, but the problem isn't size of ISOs, the problem is mirrors aren't regulating what they taken in and the current setup requires maintenance for hubs. Put some managed files on our www servers and the mirror operators can go back to sleep. ## end e-mail As for what classes of template files are, a few examples, ideas: -[BRANCH]-[arch] -[CVSup collection]-[TAG] Automatically generating these files would be trivial. They could also be dynamically generated at request time, along with a little logging to see when a mirror has checked in and updated (my preference). -sc --=20 Sean Chittenden --H7cT1SUwsqXggVRO Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Comment: Sean Chittenden <sean@chittenden.org> iD8DBQE+OYHdjoUuCl9bPssRAmDTAKCk3p8Pq/Kvsl3S4yTkngD1Xog4ygCgoK+e Ta5argBO5W3S2JD1h9/ELng= =P9cq -----END PGP SIGNATURE----- --H7cT1SUwsqXggVRO-- To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hubs" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20030130194950.GQ15936>