Yum, Proxy Cache Safety, Storage Backend

David Mansfield fedora at dm.cobite.com
Thu Jan 24 14:53:11 UTC 2008

On Wed, 2008-01-23 at 21:41 -0500, Warren Togami wrote:
> I just had an in-depth discussion with Henrik Nordström of the Squid
> project about how HTTP mirrors and the yum tool itself could be improved
> to safely handle proxy caches.  He gave me lots of good advice about how
> HTTP mirrors can be configured for cache safety, Squid can be configured
> for yum metadata cache safety, and yum itself can be improved to be more
> robust in dealing with proxy caches.

> "Cache-Control: max-age=0"
> ==========================
> This HTTP header directive can be either in the request or response.


> 3) yum can always include the HTTP directive in its request for
> repodata/* files.  Can we make this the default in future versions of
> yum?  I personally don't see a drawback (unless repodata becomes
> versioned, then we don't want this.)

I recommend this strongly as an option (instead of 'always') but I'd
love to be able to set this network wide (yum.conf over NIS? just

I currently have numerous problems with this because all my systems sit
behind a squid cache used only for caching yum packages, but we have in
internal repo here, and if I push changes to it 'too fast' I get in
trouble.  I've created a shell script which 'invalidates' the squid
cache for repos found in /etc/yum.repos.d using 'wget --no-cache' .
Script attached for instructional purposes.

Another problem not mentioned is the non-stable nature of mirrorlist.
If you use one mirror on one update, and another on the next, the cache
cannot help.

This requires some non-trivial (in terms of setup cost) fiddling with
the yum config on every host to change the way mirror (or baseurl)
selection works, and is brittle w.r.t future change.


-------------- next part --------------
A non-text attachment was scrubbed...
Name: refresh_squid_repo_data.sh
Type: application/x-shellscript
Size: 1197 bytes
Desc: not available
URL: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20080124/a9f9a750/attachment.bin>

More information about the fedora-devel-list mailing list