Yum, Proxy Cache Safety, Storage Backend
Warren Togami
wtogami at redhat.com
Thu Jan 24 17:21:58 UTC 2008
Les Mikesell wrote:
>
> Even a postman is going to have trouble when you randomize the addresses...
>
The real solution that you need is within MirrorManager. Perhaps today
MirrorManager will not do what you need. Let us define the
functionality that you do need:
"Users should be able to define their own site-local netblock and
associate it with a preferred public mirror. That preferred public
mirror will then *always* show up as the first mirror, followed by
others in the region."
https://fedorahosted.org/mirrormanager
Want to help write this option into MirrorManager? The code is open.
>> Tim "Proxies is nothing but trouble" :)
The yum developers have an erroneous assumption that only "broken"
proxies are at fault for yum problems. I have described at the
beginning of this thread that this assumption is false. *Any* proxy
server that does caching will occasionally cause the partial sync yum
failure, or resigned RPMS will cause a failure.
Fortunately, the yum developers were already thinking about using unique
(probably SHA1) names of repodata as of yum-3.2.9 for other reasons.
This should solve the common partial sync failure in Fedora 9+.
However, there remains no good solution for the resigned RPMS case other
than falling back to the next mirror. Fortunately this is a rare
problem with our stable releases, it mainly effects our development and
testers.
>
> Note that if yum acted intelligently with proxies, the whole concept of
> mirror management could be replaced by appropriately placed squid (or
> similar) proxies with no configuration/maintenance other than setting
> them to cache large files and restricting public ones to certain
> targets. Then if yum noticed that no local proxy was being used, it
> could use some mirrorlist-like mechanism to find one nearby and use it
> explicitly, eliminating any need for a reverse-proxy setup on the proxy
> server side.
>
I can't begin to respond to this because of how misguided it is.
Warren Togami
wtogami at redhat.com
More information about the fedora-devel-list
mailing list