Fedora 7

Dax Kelson Dax at gurulabs.com
Fri Jan 5 21:39:06 UTC 2007


...... Original Message .......
On Fri, 5 Jan 2007 14:49:09 -0500 "Jesse Keating" <jkeating at redhat.com> 
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)




More information about the fedora-devel-list mailing list