[squid-users] Squid-deb-proxy legacy-tools_0.1_all.deb Size mismatch

Amos Jeffries squid3 at treenet.co.nz
Fri May 1 15:46:02 UTC 2015


On 2/05/2015 3:00 a.m., Eric Keller wrote:
> Hi everyone,
> 
> I did encounter a strange behavior with my squid-deb-proxy server.
> on the master Debian repository server I forced publish an already existing
> Debian package having the same version 0.1 (my bad, I won't do it again)
> 
> my squid-deb-proxy configuration looks like:
> 
> ...
> # refresh pattern for debs and udebs
> refresh_pattern deb$   129600 100% 129600
> refresh_pattern udeb$   129600 100% 129600
> refresh_pattern tar.gz$  129600 100% 129600
> 
> # always refresh Packages and Release files
> refresh_pattern \/(Packages|Sources)(|\.bz2|\.gz|\.xz)$ 0 0% 0
> refresh_pattern \/Release(|\.gpg)$ 0 0% 0
> refresh_pattern \/InRelease$ 0 0% 0
> ...
> 
> as far as I understand, the Packages and Release files are always refreshed
> from the master repository server, but I quite do not understand the
> meaning of "129600 100% 129600" for Debian packages.
> 
> I interpret that the Debian packages stay in the cache and are not
> refreshed. So my package legacy-tools_0.1_all.deb and Release file got
> updated on the master repository and only the Release file got updated
> through the squid-deb-proxy but the old version mismatching the Release
> size of the package is still available in the cache.
> 
> does this make sense?

Yes, and will remain in cache for 129600 minutes (90 days).

Good example of how forcing things to cache with refresh_pattern can
bite back badly.

If you know the exact URL of the object, you can do a force-reload like so:
 squidclient -H 'Cache-Control:no-cache\n' \
   http://.../legacy-tools_0.1_all.deb

Or, IMHO upload a new package with incremented version so any other
proxies that have picked it up by now can get fixed quietly as well.

Amos



More information about the squid-users mailing list