[Yum] Maintaining my own copy of UPDATES

[James Antill]

Les Mikesell <lesmikesell at gmail.com> 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 at and.org