[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]

Re: Yum, Proxy Cache Safety, Storage Backend



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 redhat com


[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]