Thanks for the confirmation.
Would it be something to change the behaviour of squid-deb-proxy, matching the master repository Package.gz file for checksum when the cache gets hit and force re cache of the package if it's different?
Have a good day
--
Eric
On Fri, May 1, 2015, 17:46 Amos Jeffries <squid3@xxxxxxxxxxxxx> wrote:
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
_______________________________________________
squid-users mailing list
squid-users@xxxxxxxxxxxxxxxxxxxxx
http://lists.squid-cache.org/listinfo/squid-users
_______________________________________________ squid-users mailing list squid-users@xxxxxxxxxxxxxxxxxxxxx http://lists.squid-cache.org/listinfo/squid-users
