Les Mikesell <lesmikesell@xxxxxxxxx> writes: > James Antill wrote: >> Again, you are assuming that "mirrorlists" is a static set of data >> in the repo. ... this is _not true_. > > Isn't this specific to each particular disto/repo? Which one(s) are > you talking about? It doesn't matter, it's supported to do that and all of the important ones are dynamic. The former means your suggestion is the wrong thing to do by default, and the later means that there's little incentive to create a config. option to do "static mirrorlists that we should turn into a DHT to make proxies work, for the 2 people who are bothered about it but refuse to use/contribute the other known solutions". >> It is absolutely fine for two machines on the same network, using the >> same proxy, to get two completely different "mirrorlists" (or to have >> some of the same data in a different order). > > Why don't you permit this to be cached for some reasonable length of > time so things behind my cache will see the same version (because it > will only ask once)? This is a MirrorManager RFE, why are you asking here? Also metalink data is over https, so I'm not sure how that's going to get cached by anything. >> As I'm _sure_ you know, MirrorManager has options to allow the user >> to pick a "best" mirror for IP ranges they own. > > If it can do that, it could provide repeatable behavior on its > own. Hash the source IP into ranges, give out the same mirror order to > everyone in the same range. Again, this is a MirrorManager RFE, why are you asking here? >>> If you would permit caching to work the way it is intended, distros >>> probably wouldn't need all those mirrors anyway and other people >>> wouldn't have had to invent a dozen different ways to work around what >>> yum does when updating multiple machines. >> Sure, scaling out from a single point of reference is very easy in >> HTTP ... we/Fedora/CentOS/etc. are just too dumb to do it. As are all >> of Akami's customers. >> Feel free to enlighten us/Fedora/CentOS/etc. > > Starting from scratch, I'd have required mirrors to use the same > relative locations and returned a bunch of IP addresses in DNS > (possibly with some intelligent handler like the F5 GTM) the way every > other large scale http distribution works. Centos3 worked just great > that way. Of course, why didn't I think of that. Hmmm, maybe because: . Putting IP based dynamic info. into DNS is soooo much easier than doing the same from CGIs. . Having a single mirror failure stop all downloads wouldn't have you shouting that we're all morons. . Lack of ever being able to download from more than one mirror at once is obviously a good thing. . Forced use of a single protocol is obviously a good thing. . Lack of being able to do any kind of useful client side filtering is obviously a good thing (luckily noone uses fastestmirror plugin, and it wasn't considered so good that CentOS force installed it). . DNSSEC has been deployed for years now, so your suggestion is completely secure. . DNS is well known for caching/distributing multiple IPs for one name 100% fairly, and RFC3484 has done nothing but help. See: http://drplokta.livejournal.com/109267.html -- James Antill -- james@xxxxxxx _______________________________________________ Yum mailing list Yum@xxxxxxxxxxxxxxxxx http://lists.baseurl.org/mailman/listinfo/yum
