Yum, Proxy Cache Safety, Storage Backend
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
> 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
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.
More information about the devel