Yum, Proxy Cache Safety, Storage Backend

chasd chasd at silveroaks.com
Tue Jan 29 14:35:47 UTC 2008


Les Mikesell wrote:

> This could work on a typical home network.  In a larger office I'd
> expect subneting and firewalling to block most auto-discovery  
> mechanisms
>   between a lot of machines that would still have fast internal
> connections and share outbound internet traffic.

My presumption is that an entity where servers are  
"difficult" ( SOHO, education ) also probably has a flat network  
topology for this to work. My target was a rpm installation that  
would enable this, so anyone could set it up without much other  
intervention. Shoot, it might work if you had several Fedora users at  
the same Starbucks.

> Would there still be a
> way to explicitly provide the dns name or IP address of the server in
> this case?

I thought about that a little bit.
If there was a server on the same subnet, it could use the same  
discovery and retrieve any rpms it didn't have from the various  
client nodes. That way as nodes appeared and disappeared from the  
network, there would be some stability of the cached rpms available.  
You could make that server the default repo in yum.repos.d, so that  
if the mdns-avahi-Bonjour thingy didn't work or wasn't installed on a  
node, yum would have a fallback to a "regular" repo that had many  
cached files.

If the network had subnets etc., then the client nodes would have to  
"phone home" to a server giving the server a list of its cached rpms  
because the server would not be able to discover all client nodes.  
The server could then compare the list on the client node with its  
own list and retrieve any it was missing. A scheduled rsync from the  
client to the server might work too. That same cron script could dump  
the client cache because those rpms would still be available on the  
local network from the server it pushed them to.

Integrating a server into this idea was secondary from my point of  
view. There's a bit of work just to get the clients talking to each  
other, at least with my skill set.


Charles Dostale




More information about the fedora-devel-list mailing list