...... Original Message ....... On Fri, 5 Jan 2007 14:49:09 -0500 "Jesse Keating" <jkeating@xxxxxxxxxx> wrote: >On Friday 05 January 2007 14:43, Horst H. von Brand wrote: >> I'd like to do the following: Net-installing machine #1 gets the stuff >> required for that install (only!) and caches it, from cache install >> machines #2 .. #30. Now update machine #1, cache updates (so they can be >> used to update #2 .. #30, or even for fresh installs of #31 .. #35). >> If machine #20 needs some extra package, get and cache that one. If some >> machine asks for a package, look if what is up to date and hand that over; >> if not, get the last version. >> >> Sort of local-net /var/cache/yum (with a bit smarter handling ;-). Sure, >> it'll need some smarts to figure out that a package is obsoleted by another >> (version) to free space, but this might be handled by hand. Disk space is >> inexpensive, international network access is limited and expensive here >> (and it is probably much worse elsewhere). And it is not fun downloading >> the same files 30 times, or mirroring 10 files that aren't used locally to >> get the one you'll install 30 times. > >Er, how is this not possible with a sufficiently large squid caching proxy? It isn't that simple. The problem is that if client1 fetches an RPM from one mirror and client2 tries to fetch the same RPM from a different mirror, no caching is done. As I recall, Squid uses the MD5 of the entire URI as the unique object identifier. You need to have all the clients fetching from the same mirror AND ideally, this should happen automatically without config change on the clients. If I bring my laptop to the office, then it should use the local network cache automatically. When I go home, it should use the mirrors like normal. I figure I can implement that at the office with DNS hijacking plus using Squid as a transparent proxy. It is on my TODO list. ___ Dax Kelson Guru Labs Sent with my Treo (please pardon any brevity) -- fedora-devel-list mailing list fedora-devel-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/fedora-devel-list
