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