Les Mikesell wrote:
I'm missing something here. A cache is only going to resend what
it got
the first time. If the first user got the right thing, so will the
second. If the first user got something wrong, don't blame the cache
for it.
There can be a problem when the cache holds on to the "bad" data for
too long, serving that to other clients that ask for it later. The
way things are now, a cache has a good reason _not_ to look for fresh
data when the end users would like it to. In that case, some blame is
on the cache, and every once in a while I have to kick squid in the
butt because of that. Adjusting the tools used to update machines and
to create the repos in order to help the cache make better decisions
is a Good Thing.
General comments about this thread :
The default update scheme is to use multiple mirrors managed by an
intelligent script. Works for a lot of people, but not everyone.
I think there needs to be an assumption that some kind of
administrator is going to have to opt out of that default and opt
into any caching scheme. At that point the issue is how easy do we
make it for the administrator to do that ? What kind of changes need
to be made on the clients, and what additional infrastructure changes
need to be made ?
Instant Mirror is very easy right now, at least if you have any chops
as an admin. Install a rpm, twiddle the config, set up a host in DNS,
distribute a repo file for the clients. My view on the intent of Mr.
Togami's OP is to accept that level of ease-a-tude-inosity and make
the solution less error prone. Making the opt-in easier would only be
a bonus.
The way I use and configure squid for general web access caching
would not make it a good cache for updates. I would rather have a
separate update caching mechanism rather than try to make our squid
cache do double duty. I would want more control over that update
cache than whatever squid would supply automatically.
Charles Dostale
--
fedora-devel-list mailing list
fedora-devel-list@xxxxxxxxxx
https://www.redhat.com/mailman/listinfo/fedora-devel-list
