In the past I used a manually configured Squid3 as a package cache. Recently that had to be migrated to a new host and I after not touching that setup for maybe a decade, I wanted to examine the squid config as a whole at first. After seeing what a time consuming endeavour that would have been, I luckily stumbled upon the squid-deb-proxy and squid-deb-proxy-client packages. And I confess: I rather lazily trust that, than reread over the loooong list of squid parameters. While I’m sceptical about infrastructure depending to much on automagical configuration (in this case avahi-daemon) using these packages allowed the replacement within a few minutes. On top of that, the packages usually don’t interfere with any squid already in place (seperate instance and port).

On the host serving the cache (here squid):

apt install squid-deb-proxy

Then collect and add all domains any client connects to below /etc/squid-deb-proxy/mirror-dstdomain.acl.d/ Either in the file already present or even better in seperate files (e.g., 20-cran-rproject, 30-postgres-upstream, 40-grnet)

On the clients it’s enough to

apt install squid-deb-proxy-client

After adding the necessary firewall rules for squid on the server it’s time for a testdrive. Suddenly missing Release files are a sign that the domain didn’t make it into the ACL directory. If no unusual warnings and errors appear squid:/var/cache/squid-deb-proxy/ should show the typical directory tree filling up:

squid:/var/cache/squid-deb-proxy# tree -L 1
.
├── 00
├── 01
├── 02
...
├── 0F
└── swap.state

Sofar that worked like a charm and IMO cannot be much easier.