Re: Maintaining my own copy of UPDATES

Les Mikesell <[email protected]> writes:

> No one needs to know anything about the many ip addresses these
> requests may originate from.  All that needs to happen is that they
> are repeatable when going through proxies.

 <sarcasm>Oh, is that all. Like all I need to do is solve faster than
          light travel, and we're good to go?</sarcasm>

>  If you feel that you have
> to rotate/randomize the mirrorlist if one exists

 Yum doesn't do this and can't stop MirrorManager/whatever from doing
it (and MirrorManager does it for a _reason_, not just on a whim).

>, how about hashing
> the proxy name specified into an index for the starting attempt so
> every machine with the same proxy will make its first request to the
> same target?  Or use a token passed on the command line for that
> purpose.

 Again, you are assuming that "mirrorlists" is a static set of data
in the repo. ... this is _not true_.
 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). Even with the move to
metalink data, we can't make a syncronized DB out of the data we
have. And I'm sure I've explained exactly the above to you before.

 As I'm _sure_ you know, MirrorManager has options to allow the user
to pick a "best" mirror for IP ranges they own.

> 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.

-- 
James Antill -- [email protected]